SEC03-BP08 組織内でリソースを安全に共有する
ワークロードの数が増えるにつれて、それらのワークロードのリソースへのアクセスを共有したり、複数のアカウントでリソースを複数回プロビジョニングしたりする必要が生じます。開発環境、テスト環境、本番環境などの環境を区分けするための構造があるかもしれません。ただし、分離構造があっても、安全に共有する能力は制限できません。重複するコンポーネントを共有することにより、運用諸経費を削減し、同一リソースを複数回作成する間に見逃したものを推測しなくても、一貫したエクスペリエンスを実現できます。
期待される成果: 安全な方法を使用して組織内でリソースを共有し、データ損失防止イニシアチブを支援することで、意図しないアクセスを最小限に抑えます。個々のコンポーネントを管理するのと比較して、運用諸経費を削減し、同じコンポーネントを何度も手動で作成することによるエラーを減らし、ワークロードのスケーラビリティを向上させることができます。削減できた時間を活用して、マルチポイント障害シナリオを解決し、自信を持ってコンポーネントが不要になるときを判断できるようになります。外部共有リソースの分析に関する規範ガイダンスについては、「SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析」を参照してください。
一般的なアンチパターン:
-
継続的にモニタリングして、予定外の外部共有が生じたときに自動的にアラートを発動するプロセスがない。
-
共有すべき/すべきでない内容に関する基準がない。
-
必要な時点で明示的に共有するのではなく、広く開かれたポリシーをデフォルトとしている。
-
必要に応じて重複する基本的リソースを手動で作成する。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
アクセスコントロールとパターンを構築し、信頼できるエンティティとのみ共有リソースの消費を安全に管理します。共有リソースをモニタリングして、継続的に共有リソースアクセスをレビューし、不適切なまたは予想外の共有があればアラートを発動します。「パブリックおよびクロスアカウントアクセスの分析」を確認し、ガバナンスを確立して、外部アクセスを必要なリソースのみに減らします。また、継続的かつ自動的にアラートをモニタリングするプロセスを確立します。
AWS Organizations 内のクロスアカウント共有は、AWS Security Hub、Amazon GuardDuty、AWS Backup など、多数の AWS サービスでサポートされています。これらのサービスを使用すると、中央アカウントでデータを共有し、中央アカウントからアクセス可能、あるいは中央アカウントからリソースとデータを管理できます。例えば、AWS Security Hub は個別アカウントから中央アカウントに検出結果を送信するため、すべての検出結果を確認することができます。AWS Backup は、リソースのバックアップを取り、アカウント全体で共有します。AWS Resource Access Manager
アカウントが組織内のリソースのみを共有するように制限するには、サービスコントロールポリシー (SCP) を使用して、外部プリンシパルへのアクセスを防止します。リソースを共有するときは、アイデンティティベースのコントロールとネットワークコントロールを組み合わせて組織のデータ境界を作成し、意図しないアクセスから保護します。データ境界とは、信頼できるアイデンティティのみが、期待されるネットワークから信頼できるリソースにアクセスするよう徹底するのに役立つ予防的な一連のガードレールです。これらのコントロールは、どのリソースが共有可能かについて適切な制限を設け、共有や公開が許可されるべきでないリソースについてはそれを禁止する必要があります。例えば、データ境界の一部として、VPC エンドポイントポリシーと AWS:PrincipalOrgId 条件を使用して、Amazon S3 バケットにアクセスする ID が組織に属していることを確認できます。SCP はサービスにリンクされたロールまたは AWS サービスプリンシパルには適用されないことにご注意ください。
Amazon S3 を使用する場合は、Amazon S3 バケット ACL をオフにし、IAM ポリシーを使用してアクセスコントロールを定義します。Amazon CloudFront
場合によっては、組織外のリソースを共有したり、リソースにサードパーティーのアクセスを付与したりするかもしれません。外部でリソースを共有するアクセス許可を管理するための規範ガイダンスについては、「アクセス許可の管理」を参照してください。
実装手順
-
AWS Organizations を使用する: AWS Organizations は、ユーザーが作成する組織に、複数の AWS アカウント を統合し、一元管理できるアカウント管理サービスです。アカウントを組織単位 (OU) にグループ化し、OU ごとに異なるポリシーをアタッチすることにより、予算、セキュリティ、コンプライアンスのニーズに対応できます。また、AWS 人工知能 (AI) と機械学習 (ML) サービスがどのようにデータを収集して保管するかをコントロールし、Organizations と統合された AWS サービスのマルチアカウント管理を使用できます。
-
AWS Organizations と AWS サービスの統合: 組織のメンバーアカウントで自動的にタスクを実行するために AWS サービスを使用すると、AWS Organizations はそのサービス用のサービスにリンクされた IAM ロール (SLR) を各メンバーアカウントに作成します。AWS Management Console、AWS API、または AWS CLI を使用して、信頼できるアクセスを管理する必要があります。信頼されたアクセスを有効にするための規範ガイダンスについては、「AWS Organizations を AWS の他のサービスと併用する」および「Organizations と併用できる AWS サービス」を参照してください。
-
データ境界を確立する: データ境界は、信頼と所有権の明確な境界を提供します。AWS では、通常、AWS リソースにアクセスするオンプレミスネットワークまたはシステムと共に、AWS Organizations によって管理される AWS Organization として表されます。このデータ境界の目標は、アイデンティティが信頼され、リソースが信頼され、さらにネットワークが予想されている場合に、そのアクセスが許可されていることを検証することです。ただし、データ境界を確立することは、万能なアプローチではありません。AWS ホワイトペーパーの「境界の構築」に記載されているコントロール目標を、特定のセキュリティリスクモデルと要件に基づいて評価し、採用します。リスクに対する企業固有の姿勢を慎重に検討し、セキュリティニーズに沿った境界コントロールを実装する必要があります。
-
AWS サービスでリソース共有を使用し、必要に応じて制限する: 多くの AWS サービスでは、リソースを別のアカウントと共有できます。また、Amazon マシンイメージ (AMI) および AWS Resource Access Manager (AWS RAM) など別のアカウントのリソースをターゲットにできます。
ModifyImageAttributeAPI を制限して、AMI を共有する信頼されたアカウントを指定します。AWS RAM を使用して組織への共有のみを制限する場合は、信頼できない ID からのアクセスを防ぐためにram:RequestedAllowsExternalPrincipals条件を指定します。規範ガイダンスと考慮事項については、「リソース共有と外部ターゲット」を参照してください。 -
AWS RAM を使用して、アカウントまたは他の AWS アカウント と安全に共有する: AWS RAM
は、作成したリソースをアカウント内のロールやユーザー、他の AWS アカウント ととも安全に共有できます。マルチアカウント環境の場合、AWS RAM ではリソースを作成したら、それを他のアカウントと共有できます。このアプローチにより、運用諸経費を削減し、Amazon CloudWatch および AWS CloudTrail との統合を通じて、一貫性、可視性、監査可能性を提供することができます。これは、クロスアカウントアクセスを使用している場合は享受できません。 リソースベースのポリシーを使用して過去に共有したリソースが存在する場合、
PromoteResourceShareCreatedFromPolicyAPI または同等機能を使用して、リソース共有を完全な AWS RAM リソース共有に昇格できます。場合によっては、リソースを共有するための追加ステップが必要かもしれません。例えば、暗号化されたスナップショットを共有するには、AWS KMS キーを共有する必要があります。
リソース
関連するベストプラクティス:
関連ドキュメント:
関連動画:
関連ツール:
