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

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

前のセクションで説明したように、お客様はセキュリティサービス全体 AWS について考え、戦略的に整理するための追加の方法を探しています。現在の最も一般的な組織的アプローチは、各サービスの動作に応じて、セキュリティサービスをプライマリ機能別にグループ化することです。CAF のセキュリティの観点からは、ID とアクセスの管理、インフラストラクチャの保護、データ保護、脅威の検出など、9 AWS つの機能を示しています。これらの機能 AWS のサービス と組み合わせることは、各領域で実装を決定する実用的な方法です。例えば、ID とアクセスの管理を検討する場合、IAM と IAM アイデンティティセンターは考慮すべきサービスです。脅威検出アプローチを設計するときは、GuardDuty を最初に検討してください。

この機能ビューの補完として、クロスカット構造ビューでセキュリティを表示することもできます。つまり、「アイデンティティ、論理アクセス、または脅威検出メカニズムを制御および保護するためにどの を使用する 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 組織内の複数のアカウント (組織全体または特定の OUs を含む) にガバナンスと制御機能またはガードレールを適用するように設計された AWS のサービス および 機能があります。サービスコントロールポリシー (SCPs) とリソースコントロールポリシー (RCPs) は、予防的で AWS 組織全体のガードレールを提供する IAM 機能の好例です。 は、 のベースライン設定を大規模 AWS のサービス に一元的に定義して適用する宣言型ポリシー AWS Organizations も提供します。もう 1 つの例は CloudTrail です。CloudTrail は、その組織内のすべての のすべてのイベントを記録する組織の証跡を通じてモニタリングを提供します。 AWS アカウント AWS この包括的な証跡は、各アカウントで作成される可能性のある個々の証跡とは異なるものです。3 番目の例は AWS Firewall Manager、 AWS 組織内のすべてのアカウントで複数のリソースを設定、適用、管理するために使用できる です。 AWS WAF ルール、 AWS WAF Classic ルール、 AWS Shield Advanced 保護、Amazon Virtual Private Cloud (Amazon VPC) セキュリティグループ、 AWS Network Firewall ポリシー、DNS Firewall Amazon Route 53 Resolver ポリシーです。

次の図のアスタリスク (*) でマークされたサービスは、組織全体とアカウントに焦点を当てた 2 つのスコープで動作します。これらのサービスは、個々のアカウント内のセキュリティを基本的にモニタリングまたは制御するのに役立ちます。ただし、一元化された可視性と管理のために、複数のアカウントの結果を組織全体のアカウントに集約する機能もサポートしています。わかりやすくするために、OU 全体 AWS アカウント、または AWS 組織全体に適用される SCPs を検討してください。対照的に、GuardDuty は、アカウントレベル (個々の検出結果が生成される場所) と、検出結果を集計して表示および管理できる AWS 組織レベル (委任管理者機能を使用) の両方で設定および管理できます。

AWS アカウント

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

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

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

プリンシパルとリソース

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

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

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

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

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