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

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

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

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

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

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

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

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

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

AWS アカウント

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

 

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

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

プリンシパルとリソース

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

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

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

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

次の図表は、アカウントリソースに対するサービスと機能を示してます。リソースベースのポリシーをリソースにアタッチします。例えば、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 リソース設定を継続的にモニタリングして記録し、記録された設定を目的の設定と照合して自動的に評価します。