SEC03-BP08 リソースを安全に共有する

アカウント間または AWS Organizations 内の共有リソースの消費を管理します。共有リソースをモニタリングし、共有リソースへのアクセスを確認します。

一般的なアンチパターン:

このベストプラクティスが確立されていない場合のリスクレベル: 低

実装のガイダンス

複数の AWS アカウントを使用してワークロードを管理するとき、アカウント間でのリソースの共有が必要になる場合があります。多くの場合、これは AWS Organizations 内でのクロスアカウント共有です。AWS の複数のサービス ( AWS Security Hub、Amazon GuardDuty、 AWS Backup など) には Organizations と統合されたクロスアカウント機能があります。そのため、 AWS Resource Access Manager を使用して、その他の一般的なリソースを共有します。例えば、 VPC サブネットや Transit Gateway アタッチメント、AWS Network Firewall、 Amazon SageMaker Runtime パイプラインなどです。アカウントで Organizations 内のリソースのみを共有する場合は、 サービスコントロールポリシー (SCP) を使用して外部プリンシパルへのアクセスを禁止することをお勧めします。

リソースを共有するとき、意図しないアクセスから保護するための手段を講じる必要があります。アイデンティティベースのコントロールとネットワークコントロールを組み合わせて 組織のデータ境界を作成することをお勧めします。これらのコントロールは、どのリソースが共有可能かを厳格に制限し、共有や公開が許可されるべきでないリソースについてはそれを禁止する必要があります。例えば、データ境界の一部として、VPC エンドポイントポリシーと aws:PrincipalOrgId 条件を使用すると、組織に属しているアイデンティティのみが Amazon S3 バケットにアクセスするように設定できます。

場合により、Organizations 外部でリソース共有を許可したり、アカウントへのアクセス権を第三者に付与したりする必要があるかもしれません。例えば、パートナーが提供する監視ソリューションが、貴社のアカウント内のリソースにアクセスする必要があるかもしれません。そのような場合、第三者にとって必要な権限のみを含む IAM クロスアカウントロールを作成する必要があります。また、外部 ID 条件を使用して信頼ポリシーを作成する 必要もあります。外部 ID を使用する際は、第三者それぞれに固有の ID を生成する必要があります。固有の ID は第三者によって提供、制御されるべきではありません。第三者が貴社の環境にアクセスする必要がなくなった場合は、ロールを削除する必要があります。また、いずれの場合も、第三者に長期的な IAM 認証情報を提供することは避ける必要があります。共有をネイティブにサポートする他の AWS サービスを継続的に把握しておきます。例えば、AWS Well-Architected Tool では、 他の AWS アカウントとワークロードを共有できます。

Amazon S3 などのサービスを使用する際は、 Amazon S3 バケットの ACL を無効にし、 IAM ポリシーを使用してアクセスコントロールを定義することをお勧めします。Amazon S3 オリジンが Amazon CloudFront からアクセスされることを制限するには、オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) に移行します。OAC では AWS KMS を使用したサーバー側暗号化を含む追加機能がサポートされています。を使用します。

リソース

関連するドキュメント:

関連動画: