翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS 組織全体にセキュリティサービスを適用

前のセクションで説明したように、顧客は AWS セキュリティサービスのすべてについて考え、戦略的に整理するための新しい方法を求めています。今日最も一般的な組織的アプローチは、各サービスの機能に応じて、セキュリティサービスを主要な機能ごとにグループ化することです。AWS CAF のセキュリティの観点では、ID とアクセス管理、インフラストラクチャ保護、データ保護、脅威検出などの 9 つの機能が挙げられています。AWS のサービスとこれらの機能を組み合わせることは、各分野での実装上の決定を下すための実用的な方法です。たとえば、ID とアクセス管理を検討する場合、IAM と IAM Identity Center は考慮すべきサービスです。脅威検出アプローチを設計する際、最初に検討するのは Amazon GuardDuty かもしれません。

この機能的な見方を補完するものとして、セキュリティを横断的かつ構造的な視点で見ることもできます。つまり、「自分の ID、論理アクセス、または脅威検出メカニズムを制御および保護するには、どの AWS サービスを使用すべきか」という質問に加えて、 、「どの AWS サービスを自分の AWS 組織全体に適用すべきか?」と尋ねることもできます。 アプリケーションの中核にある Amazon EC2 インスタンスを保護するために、どのような防御層を設けるべきでしょうか?」 このビューでは、AWS のサービスと機能を AWS 環境のレイヤーにマッピングします。一部のサービスと機能は、AWS 組織全体に統制を実装するのに最適です。たとえば、Amazon S3 バケットへのパブリックアクセスをブロックすることは、このレイヤーでの特定の制御です。個々のアカウント設定の一部ではなく、ルート組織で行うのが望ましいです。他のサービスや機能は、AWS アカウント内の個々のリソースを保護するのに最適です。プライベート TLS 証明書を必要とする下位認証局 (CA) をアカウント内に実装するのもこのカテゴリの例です。もう 1 つ同様に重要なグループには、AWS インフラストラクチャの仮想ネットワークレイヤーに影響を与えるサービスがあります。次の図は、一般的な AWS 環境の 6 つのレイヤー (AWS 組織、組織単位 (OU)、アカウント、ネットワークインフラストラクチャ、プリンシパル、リソース) を示しています。

各レイヤーでの制御や保護を含め、この構造的なコンテキストでサービスを理解することは、AWS defense-in-depth 環境全体にわたる戦略の計画と実装に役立ちます。この観点では、トップダウンの両方の質問に答えることができます（たとえば、「AWS 組織全体にセキュリティコントロールを実装するためにどのサービスを使用していますか？」） そして下から上へ (たとえば、「この EC2 インスタンスの統制はどのサービスが管理しているのか?」)。このセクションでは、AWS 環境の要素について説明し、関連するセキュリティサービスと機能を特定します。もちろん、AWS サービスの中には幅広い機能セットを備え、複数のセキュリティ目標をサポートしているものもあります。これらのサービスは、お使いの AWS 環境の複数の要素をサポートしている場合があります。

わかりやすくするために、一部のサービスが定められた目的にどのように適合するかについて簡単に説明します。次のセクションでは、各 AWS アカウント内の個々のサービスについて詳しく説明します。

組織全体または複数のアカウント

最上位レベルには、ガバナンスとコントロールの機能、またはガードレールを AWS 組織の複数のアカウント (組織全体または特定の OU を含む) に適用するように設計された AWS のサービスと機能があります。サービスコントロールポリシー (SCP) は、AWS の組織全体に予防的なガードレールを提供する IAM 機能の好例です。もう 1 つの例が AWS です。これは CloudTrail、その AWS 組織内のすべての AWS アカウントのすべてのイベントを記録する組織証跡によるモニタリングを提供します。この包括的な証跡は、各アカウントで作成される可能性のある個々の証跡とは異なるものです。3 つ目の例は AWS Firewall Manager です。これを使用して、AWS 組織内のすべてのアカウントに複数のリソースを設定、適用、管理できます。これらのリソースには、AWS WAF ルール、AWS WAF クラシックルール、AWS Shield アドバンスドプロテクション、Amazon Virtual Private Cloud (Amazon VPC) セキュリティグループ、AWS Network Firewall ポリシー、Amazon Route 53 Resolver DNS ファイアウォールポリシーなどがあります。 

以下の図でアスタリスク* の付いたサービスは、組織全体を対象とするものとアカウントに焦点を当てたものの 2 つの範囲で運営されています。これらのサービスは、個々のアカウント内のセキュリティを基本的に監視または制御するのに役立ちます。ただし、複数のアカウントの結果を組織全体のアカウントに集約して、一元的な可視性と管理を実現する機能もサポートしています。わかりやすくするために、OU、AWS アカウント、または AWS 組織全体に適用される SCP を検討してください。対照的に、Amazonは、アカウントレベル（個別の調査結果が生成される）と、調査結果をまとめて表示および管理できるAWS 組織レベル（委任管理者機能を使用） GuardDuty の両方で設定および管理できます。

AWS アカウント

OU 内には、AWS アカウント内の複数のタイプの要素を保護するのに役立つサービスがあります。たとえば、AWS Secrets Manager は通常、特定のアカウントから管理され、そのアカウントのリソース (データベース認証情報や認証情報など)、アプリケーション、AWS サービスを保護します。AWS IAM Access Analyzer は、指定されたリソースが AWS アカウント外のプリンシパルによってアクセス可能になったときに結果を生成するように設定できます。前のセクションで説明したように、これらのサービスの多くは AWS Organizations 内で設定および管理できるため、複数のアカウントで管理できます。これらのサービスには、図ではアスタリスク (*) が付いています。また、複数のアカウントの結果を集約して 1 つのアカウントに配信することも容易になります。これにより、個々のアプリケーションチームは、各自のワークロードに固有のセキュリティニーズを柔軟かつ可視的に管理できると同時に、一元化されたセキュリティチームがガバナンスと可視性を得ることができます。Amazon GuardDuty はそのようなサービスの一例です。 GuardDuty1 つのアカウントに関連するリソースとアクティビティを監視し、複数のメンバーアカウント (AWS 組織内のすべてのアカウントなど) GuardDuty の結果を委任された管理者アカウントから収集、表示、管理できます。

 

仮想ネットワーク、コンピューティング、コンテンツ配信

ネットワークアクセスはセキュリティにおいて非常に重要であり、コンピューティングインフラストラクチャは多くのAWS ワークロードの基本的なコンポーネントであるため、これらのリソース専用のAWS セキュリティサービスと機能が多数あります。たとえば、Amazon Inspector は、AWS ワークロードの脆弱性を継続的にスキャンする脆弱性管理サービスです。これらのスキャンには、環境内の Amazon EC2 インスタンスへのネットワークパスが許可されていることを示すネットワーク接続性チェックが含まれます。Amazon Virtual Private Cloud (Amazon VPC) では、AWS リソースを起動できる仮想ネットワークを定義できます。この仮想ネットワークは従来のネットワークによく似ており、さまざまな機能と利点を備えています。VPC エンドポイントを使用すると、 PrivateLink インターネットへのパスを必要とせずに、VPC をサポートされている AWS サービスや AWS が提供するエンドポイントサービスにプライベートに接続できます。次の図は、ネットワーク、コンピューティング、コンテンツ配信インフラストラクチャに焦点を当てたセキュリティサービスを示しています。

プリンシパルとリソース

AWS プリンシパルと AWS リソース (および IAM ポリシー) は、AWS の ID とアクセス管理の基本的な要素です。AWS の認証されたプリンシパルは、アクションを実行したり、AWS リソースにアクセスしたりできます。プリンシパルは、AWS アカウントのルートユーザーまたは IAM ユーザーとして認証することも、ロールを引き受けることで認証することもできます。

AWS リソースは、AWS サービス内に存在し、操作可能なオブジェクトです。例としては、EC2 インスタンス、AWS CloudFormation スタック、Amazon Simple Notification Service (Amazon SNS) トピック、S3 バケットなどがあります。IAM ポリシーは、IAM アイデンティティ (ユーザー、グループ、ロール) または AWS リソースに関連付けられているときにアクセス許可を定義するオブジェクトです。アイデンティティベースのポリシーは、プリンシパル (ロール、ユーザー、ユーザーグループ) に添付するポリシードキュメントで、プリンシパルがどのアクションを、どのリソースで、どのような条件で実行できるかを制御します。リソースベースのポリシーは、S3 バケットなどのリソースにアタッチするポリシードキュメントです。これらのポリシーは、指定されたプリンシパルに、そのリソースに対して特定のアクションを実行する権限を付与し、その権限の条件を定義します。リソースベースのポリシーはインラインポリシーです。IAM リソース のセクションでは、IAM ポリシーの種類とその使用方法について詳しく説明します。

この説明を簡潔にするために、アカウントプリンシパルでの運用、またはアカウントプリンシパルへの適用を主な目的とする IAM エンティティ向けの AWS セキュリティサービスと機能を挙げています。IAM アクセス権限ポリシーの柔軟性と効果の幅広さを認識しつつ、そのシンプルさを保っています。ポリシー内の 1 つのステートメントが、複数の種類の AWS エンティティに影響を与える可能性があります。たとえば、IAM アイデンティティベースのポリシーは IAM エンティティに関連付けられていて、そのエンティティのアクセス許可 (許可、拒否) を定義していますが、そのポリシーは、指定されたアクション、リソース、条件のアクセス権限も暗黙的に定義します。このように、アイデンティティベースのポリシーは、リソースのアクセス権限を定義するうえで重要な要素となり得ます。

次の図は、AWS プリンシパル向けの AWS セキュリティサービスと機能を示しています。ID ベースのポリシーは、ユーザー、グループ、ロールなど、識別とグループ化に使用される IAM リソースオブジェクトにアタッチされます。これらのポリシーを使用すると、そのアイデンティティが実行できる内容 (そのアクセス許可) を指定できます。IAM セッションポリシーは、ユーザーがロールを引き受けるときにセッションに渡すインラインアクセス権限ポリシーです。ポリシーを自分で渡すこともできますが、ID が AWS にフェデレーションされるときにポリシーを挿入するように ID ブローカーを設定することもできます。これにより、複数のユーザーが同じロールを引き受けながら独自のセッション権限を持つことができるため、管理者は作成する必要のあるロールの数を減らすことができます。IAM Identity Center サービスは AWS Organizations および AWS API オペレーションと統合されており、AWS AWS Organizations 内の AWS アカウント全体の SSO アクセスとユーザー権限を管理するのに役立ちます。

次の図表は、アカウントリソースに対するサービスと機能を示してます。リソースベースのポリシーをリソースにアタッチします。たとえば、リソースベースのポリシーを S3 バケット、Amazon Simple Queue Service (Amazon SQS) キュー、VPC エンドポイント、および AWS KMS 暗号化キーにアタッチできます。リソースベースのポリシーを使用して、リソースにアクセスできるユーザーと、そのリソースに対して実行できるアクションを指定できます。S3 バケットポリシー、AWS KMS キーポリシー、VPC エンドポイントポリシーは、リソースベースのポリシーの一種です。AWS IAM Access Analyzer は、外部エンティティと共有されている S3 バケットや IAM ロールなど、組織やアカウント内のリソースを特定するのに役立ちます。これにより、セキュリティ上のリスクであるリソースやデータへの意図しないアクセスを特定できます。AWS Config では、AWS アカウント内のサポートされている AWS リソースの設定を評価、監査、評価できます。AWS Config は AWS リソースの設定を継続的に監視および記録し、記録された設定を希望の設定と照合して自動的に評価します。