# SEC 3 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。権限を分けることで、どのような条件で誰が何にアクセスできるかを制御します。
**Topics**
+ [SEC03-BP01 アクセス要件を定義する](sec_permissions_define.md)
+ [SEC03-BP02 最小特権のアクセスを付与します](sec_permissions_least_privileges.md)
+ [SEC03-BP03 緊急アクセスのプロセスを確立する](sec_permissions_emergency_process.md)
+ [SEC03-BP04 アクセス許可を継続的に削減する](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 組織のアクセス許可ガードレールを定義する](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 ライフサイクルに基づいてアクセスを管理する](sec_permissions_lifecycle.md)
+ [SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 リソースを安全に共有する](sec_permissions_share_securely.md)
# SEC03-BP01 アクセス要件を定義する
ワークロードの各コンポーネントまたはリソースには、管理者、エンドユーザー、またはその他のコンポーネントからアクセスする必要があります。各コンポーネントにアクセスできるユーザーや内容を明確に定義し、適切な ID タイプと認証および承認の方法を選択します。
**一般的なアンチパターン:**
+ シークレットをハードコーディングする、またはアプリケーション内に格納する
+ 各ユーザーにカスタムのアクセス許可を付与する
+ 永続的な認証情報を使用する
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードの各コンポーネントまたはリソースには、管理者、エンドユーザー、またはその他のコンポーネントからアクセスする必要があります。各コンポーネントにアクセスできるユーザーや内容を明確に定義し、適切な ID タイプと認証および承認の方法を選択します。
組織内の AWS アカウントへの通常のアクセスは、 [フェデレーションアクセス](https://aws.amazon.com/identity/federation/) または一元化された ID プロバイダーを使用して提供する必要があります。また、アイデンティティ管理を一元化し、AWS へのアクセスを従業員のアクセスライフサイクルに統合するための確立されたプラクティスを整備する必要があります。例えば、従業員がアクセスレベルの異なる職種に異動するときは、そのグループメンバーシップも新しいアクセス要件を反映するように変更される必要があります。
非人間アイデンティティのアクセス要件を定義するときは、どのアプリケーションとコンポーネントがアクセスを必要としているか、またアクセス許可をどのように付与するかを決定します。お勧めのアプローチは、最小特権アクセスモデルで構築された IAM ロールを使用する方法です。[AWS マネージドポリシー](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) は、最も一般的なユースケースをカバーする定義済みの IAM ポリシーを提供します。
AWS のサービス ( [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) や [AWS Systems Manager パラメータストア) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)を使用すると、IAM ロールの使用が不可能なケースで、シークレットをアプリケーションやワークロードから安全に切り離すことができます。Secrets Manager では、認証情報の自動ローテーションを確立できます。Systems Manager でパラメータの作成時に指定した一意の名前を使用することで、スクリプト、コマンド、SSM ドキュメント、設定、オートメーションワークフロー内のパラメータを参照できます。
AWS Identity and Access Management Roles Anywhere を使用すると、 [IAM 内の一時的なセキュリティ認証情報を取得して、](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) AWS の外部で実行されるワークロードに使用できます。ワークロードに使用できる [IAM ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) および [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) は、AWS アプリケーションが AWS リソースにアクセスするために使用するものと同じです。
可能な場合は、長期の静的な認証情報よりも、短期の一時的な認証情報を優先します。IAM ユーザーに、プログラムによるアクセスと長期の認証情報を付与する必要がある場合は、 [最後に使用されたアクセスキーの情報を使用し、](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) アクセスキーのローテーションと削除を行います。
## リソース
**関連するドキュメント:**
+ [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [AWS Managed policies for IAM Identity Center (IAM アイデンティティセンター用の AWS マネージドポリシー)](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS IAM policy conditions (AWS IAM ポリシー条件)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [IAM ユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [必要でない認証情報を削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [「IAM ポリシーを管理する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [How to control access to AWS resources based on AWS アカウント, OU, or organization (AWS アカウント、OU、または組織に基づいて AWS リソースへのアクセスを制御する方法)](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identify, arrange, and manage secrets easily using enhanced search in AWS Secrets Manager (AWS Secrets Manager の拡張検索を使用してシークレットを容易に特定、調整、管理する)](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**関連動画:**
+ [Become an IAM Policy Master in 60 Minutes or Less (60 分以内に IAM ポリシーマスターになる)](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD (職務分離、最小特権、委任、および CI/CD)](https://youtu.be/3H0i7VyTu70)
+ [Streamlining identity and access management for innovation (アイデンティティとアクセスの管理を合理化してイノベーションを実現)](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 最小特権のアクセスを付与します
特定の条件下で特定の AWS リソースに対する特定のアクションを許可して、アイデンティティに必要なアクセスのみを付与します。グループと ID 属性を利用して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じてアクセス許可を動的に設定します。たとえば、開発者のグループに、扱うプロジェクトのリソースのみを管理することを許可できます。これにより、開発者がグループから削除されると、アクセスポリシーに変更を加えることなく、そのグループがどこでアクセスコントロールに使用されたかを問わず、開発者のアクセスが取り消されます。
**一般的なアンチパターン:**
+ デフォルトでユーザーに管理者アクセス許可を付与する
+ ルートアカウントを日常業務に使用する
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
最小権限の [原則を設定することで、](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 特定のタスクを実行するための必要最小限の機能セットのみを実行する許可が ID に与えられるようになり、使いやすさと効率のバランスを取ることができます。この原則を適用すると、意図しないアクセスは制限され、誰がどのリソースにアクセス権限があるかを監査できます。AWS では、ルートユーザー以外のアイデンティティは、デフォルトではアクセス許可を持ちません。ルートユーザーの認証情報は、厳重に制御し、 [特定のタスクにのみ使用する必要があります](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)。
ポリシーを使用して、フェデレーティッド ID、マシン、リソース (S3 バケットなど) が使用する IAM ロールなどの IAM またはリソースエンティティにアタッチされたアクセス許可を明示的に付与できます。ポリシーの作成およびアタッチでは、AWS がアクセスを許可するために必要なサービスアクション、リソース、条件を指定できます。AWS では、アクセスを最小限にするために役立つさまざまな条件を用意しています。例えば、 `PrincipalOrgID ` [条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を使用すると、AWS Organizations の識別子が検証されるため、AWS 組織内でアクセスを付与できます。
AWS のサービスがユーザーに代わって行うリクエスト (AWS CloudFormation による AWS Lambda 関数の作成など) を制御するには、 `CalledVia ` 条件キーを使用します。さまざまなポリシータイプを積み重ねて、アカウント内でアクセス許可すべてを効果的に制限する必要があります。例えば、アプリケーションチームが独自の IAM ポリシーを作成できるようにする一方、 [アクセス許可の境界](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) を使用して、そのチームが付与できる最大限のアクセス許可を制限できます。
アクセス許可の管理をスケールして最小特権の原則を遵守するのに役立つ AWS の機能がいくつかあります。[属性ベースのアクセスコントロール](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) では、リソースの *[タグ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)* に基づいてアクセス許可を制限できます。リソースに適用されるタグと呼び出し側の IAM プリンシパルに基づいた認可の決定が可能となります。それにより、タグ付けとアクセス許可ポリシーを組み合わせて、多数のカスタムポリシーを必要としない、きめ細かいリソースアクセスを実現できます。
また、最小特権ポリシーの作成を迅速に行うために、アクティビティの実行後に CloudTrail のアクセス許可に基づいてポリシーを作成することもできます。[IAM Access Analyzer は、アクティビティに基づいて IAM ポリシーを自動生成できます](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)。また、IAM アクセスアドバイザーを組織レベルまたは個々のアカウントレベルで使用して [最終アクセスの情報を追跡し、特定のポリシーを適用できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)。
これらの詳細を確認して不必要なアクセス許可を削除する頻度を定めます。AWS 組織内でアクセス許可のガードレールを確立し、すべてのメンバーアカウント内で最大限のアクセス許可を制御する必要があります。例えば [AWS Control Tower などのサービスには、規範に基づいて管理される予防的コントロールが含まれており、](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 独自のコントロールを定義できます。
## リソース
**関連するドキュメント:**
+ [IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques for writing least privilege IAM policies (最小特権の IAM ポリシーを作成するテクニック)](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity (IAM Access Analyzer は、アクセスアクティビティに基づいて IAM ポリシーを生成することにより、最小特権のアクセス許可の実装を容易にする)](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [最終アクセス情報を使用した AWS のアクセス許可の調整](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM でのポリシータイプと使用する状況](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [IAM Policy Simulator を使用した IAM ポリシーのテスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [AWS Control Tower のガードレール](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Zero Trust architectures: An AWS perspective (ゼロトラストアーキテクチャ: AWS の視点)](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [How to implement the principle of least privilege with CloudFormation StackSets (CloudFormation StackSets を使用して最小特権の原則を実装する方法)](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
**関連動画:**
+ [Next-generation permissions management (次世代のアクセス許可管理)](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: An AWS perspective (ゼロトラスト: AWS の視点)](https://www.youtube.com/watch?v=1p5G1-4s1r0)
+ [How can I use permissions boundaries to limit IAM users and roles to prevent privilege escalation? (アクセス許可の境界を使用して IAM ユーザーとロールの範囲を限定し、権限の昇格を防ぐにはどうすればよいですか?)](https://www.youtube.com/watch?v=omwq3r7poek)
**関連サンプル:**
+ [ラボ: ロールの作成を委任する IAM アクセス許可の境界](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html)
# SEC03-BP03 緊急アクセスのプロセスを確立する
自動プロセスまたはパイプラインの問題が発生した場合に、ワークロードへの緊急アクセスを許可するプロセス。これにより、最小権限のアクセスを利用しながら、ユーザーは必要なときに適切なレベルのアクセスを取得できます。例えば、アクセス用の緊急 AWS クロスアカウントロール、または管理者が緊急リクエストの検証と承認を行う際の特定のプロセスなど、管理者がリクエストを確認して承認するプロセスを確立します。
**一般的なアンチパターン:**
+ 既存の ID 設定を使用して停止状態から復旧するための緊急プロセスを整備していない。
+ トラブルシューティングや復旧の目的で長期昇格のアクセス許可を付与する。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
緊急アクセスの確立では、複数のケースに備える必要があります。まず、プライマリ ID プロバイダーの障害です。このケースでは、復旧のためのアクセス許可が必須となる第 2 のアクセス方法を用いる必要があります。この方法では、バックアップ ID プロバイダーまたは IAM ユーザーを使用できます。第 2 の方法が用いられる場合には、 [厳格に制御、監視され、通知する](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 必要があります。緊急アクセス ID は、この目的に固有のアカウントに属し、復旧に特化したロールを引き受けるためのアクセス許可のみを持つ必要があります。
また、緊急アクセスのために管理アクセス権の一時的な昇格が求められるケースにも備える必要があります。一般的なシナリオでは、変更のデプロイに使用される自動プロセスへのアクセス許可に変更を加えることを制限します。このプロセスで問題が発生した場合、ユーザーはアクセス許可を復元機能に昇格させることをリクエストしなければならない可能性があります。このケースでは、ユーザーがアクセス権の昇格をリクエストし、管理者が検証して承認することができるプロセスを確立します。アクセスの事前プロビジョニングと緊急の *break-glass* ロールの設定に関して、ベストプラクティスのガイダンスを説明する実装計画が含まれています [SEC10-BP05 アクセスを事前プロビジョニングする](sec_incident_response_pre_provision_access.md)。
## リソース
**関連するドキュメント:**
+ [Monitor and Notify on AWS (AWS アカウントのルートユーザーアクティビティの監視と通知)](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity)
+ [Managing temporary elevated access (アクセス権の一時的な昇格の管理)](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
**関連動画：**
+ [Become an IAM Policy Master in 60 Minutes or Less (60 分以内に IAM ポリシーマスターになる)](https://youtu.be/YQsK4MtsELU)
# SEC03-BP04 アクセス許可を継続的に削減する
チームとワークロードが必要とするアクセスを決定したら、不要になったアクセス許可を削除し、最小権限のアクセス許可を達成するためのレビュープロセスを確立します。未使用の ID とアクセス許可を継続的にモニタリングし、削減します。
チームやプロジェクトが開始した直後には、イノベーションと俊敏性を引き出すため、幅広いアクセス権 (開発またはテスト環境で) の付与を選択する場合があります。アクセス権を継続的に評価し、必要な許可のみにアクセスを制限し、最小権限を付与することをお勧めします。AWS では、未使用のアクセス権を特定するのに役立つアクセス分析機能を提供しています。未使用のユーザー、ロール、アクセス許可、および認証情報を特定しやすくするため、AWS はアクセスアクティビティを分析し、最後に使用されたアクセスキーとロールの情報を提供します。最終アクセスタイムスタンプ [を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) と、 [未使用のユーザーとロールを識別し、](http://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/)それらを削除できます。さらに、サービスとアクションの最終アクセス時間情報を確認し、 [特定のユーザーおよびロールのアクセス許可を厳密に識別できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).たとえば、最終アクセス時間情報を使用して、アプリケーションロールが必要とする特定の Amazon Simple Storage Service (Amazon S3) アクションを特定し、それらのアクションのみにアクセスを制限できます。これらの機能は、AWS マネジメントコンソール およびプログラムで使用でき、インフラストラクチャワークフローや自動化ツールに組み込むことができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ AWS Identity and Access Management (IAM) Access Analyzer を設定する: AWS IAM Access Analyzer は、Amazon Simple Storage Service (Amazon S3) バケットや IAM ロールなど、外部エンティティと共有されている組織のリソースとアカウントを特定するのに役立ちます。
+ [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
## リソース
**関連するドキュメント:**
+ [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [最小権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [必要でない認証情報を削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [「IAM ポリシーを管理する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
**関連動画:**
+ [Become an IAM Policy Master in 60 Minutes or Less (60 分以内に IAM ポリシーマスターになる)](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD (職務分離、最小特権、委任、および CI/CD)](https://youtu.be/3H0i7VyTu70)
# SEC03-BP05 組織のアクセス許可ガードレールを定義する
組織内のすべての ID へのアクセスを制限する共通コントロールを確立します。例えば、特定の AWS リージョン へのアクセスを制限したり、中央セキュリティチームが使用する IAM ロールなどの一般的なリソースをオペレータが削除できないようにしたりできます。
**一般的なアンチパターン:**
+ ワークロードを組織の管理者アカウントで実行する
+ 本番稼動のワークロードと非本番稼動のワークロードを同じアカウントで実行する
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
AWS で管理するワークロードの増加に伴い、アカウントを使用してワークロードを分離し、AWS Organizations を使用してそのアカウントを管理する必要があります。組織内のすべての ID へのアクセスを制限するために、共通のアクセス許可ガードレールの確立を推奨しています。例えば、特定の AWS リージョンへのアクセスを制限したり、中央セキュリティチームが使用する IAM ロールなどの共通リソースをチームのメンバーが削除できないようにしたりできます。
これを実行するには、ユーザーによるキーサービスの無効化を防止するなどの、サービスコントロールポリシーの例を実装します。SCP は IAM ポリシー言語を使用し、すべての IAM プリンシパル (ユーザーとロール) が遵守するコントロールを確立します。特定の条件に基づいて、特定のサービスアクションおよびリソースへのアクセスを制限することによって、組織のアクセスコントロールのニーズを満たすことができます。ガードレールには、必要に応じて例外を定義できます。例えば、アカウント内の特定の管理者ロールを除くすべての IAM エンティティに対して、サービスアクションを制限します。
管理アカウントでのワークロードの実行は避けることをお勧めします。管理アカウントは、メンバーアカウントに影響を及ぼすセキュリティガードレールを統制およびデプロイするために使用する必要があります。一部の AWS サービスでは、委任された管理者アカウントの使用がサポートされています。この委任アカウントを使用できる場合は、管理アカウントの代わりに使用する必要があります。組織の管理者アカウントへのアクセスは、厳しく制限する必要があります。
マルチアカウント戦略を用いると、ワークロードにガードレールを適用する際の柔軟性が大幅に向上します。AWS Security Reference Architecture では、アカウント構造の設計方法に関する規範ガイダンスが提供されます。AWS Control Tower などの AWS サービスは、組織全体で予防的コントロールと発見的コントロールの両方を一元管理する機能を提供します。組織内の各アカウントまたは OU の明確な目的を定義し、その目的に沿ってコントロールを制限します。
## リソース
**関連するドキュメント:**
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
+ [Get more out of service control policies in a multi-account environment (マルチアカウント環境でサービスコントロールポリシーをさらに活用する)](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/)
+ [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html)
**関連動画:**
+ [Enforce Preventive Guardrails using Service Control Policies (サービスコントロールポリシーを使用して予防的ガードレールを適用する)](https://www.youtube.com/watch?v=mEO05mmbSms)
+ [Building governance at scale with AWS Control Tower (AWS Control Tower を使用したガバナンスの大規模な構築)](https://www.youtube.com/watch?v=Zxrs6YXMidk)
+ [AWS Identity and Access Management deep dive (AWS Identity and Access Management の深堀り)](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP06 ライフサイクルに基づいてアクセスを管理する
アクセスコントロールをオペレーター、アプリケーションのライフサイクル、一元化されたフェデレーションプロバイダーと統合します。たとえば、ユーザーが組織を離れるとき、またはロールを変更するときに、ユーザーのアクセス権を削除します。
複数のアカウントでワークロードを管理する場合、それらのアカウント間でリソースを共有するケースがあります。リソースの共有には、 [AWS Resource Access Manager (AWS RAM) を使用することをお勧めします](http://aws.amazon.com/ram/).このサービスを使用すると、AWS Organizations 組織および組織単位内で AWS リソースを簡単かつ安全に共有できます。AWS RAM を使用すると、共有されている組織または組織単位内外へのアカウントの移動に伴い、共有リソースへのアクセスの許可または取り消しが自動的に行われます。これで、意図したアカウントのみとのリソースの共有を確実に行えます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ユーザーアクセスのライフサイクル: 新しいユーザーの参加、職務の変更、退職するユーザーに対するユーザーアクセスライフサイクルポリシーを実装して、現在のユーザーのみがアクセスできるようにします。
## リソース
**関連するドキュメント:**
+ [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [最小権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [必要でない認証情報を削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [「IAM ポリシーを管理する」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
**関連動画:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
# SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析
パブリックおよびクロスアカウントアクセスに焦点を当てた結果を継続的にモニタリングします。パブリックアクセスとクロスアカウントアクセスを減らして、このタイプのアクセスを必要とするリソースのみへのアクセスに限定します。
**一般的なアンチパターン:**
+ クロスアカウントのアクセスとリソースへのパブリックアクセスを統制するためのプロセスを遵守しない。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
AWS では、別のアカウントにあるリソースへのアクセス権を許可できます。直接的なクロスアカウントアクセスを許可するには、リソース ([Amazon Simple Storage Service (Amazon S3) バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)など) にアタッチされたポリシーを使用するか、アイデンティティが別のアカウントの IAM ロールを引き受けることを許可します。リソースポリシーを使用するときは、組織内のアイデンティティにアクセスが許可されており、リソースをパブリックアクセス可能にする意図があることを確認します。パブリックアクセス可能にする必要があるすべてのリソースを承認するプロセスを定義します。
[IAM Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) は [証明可能セキュリティ](https://aws.amazon.com/security/provable-security/) を使用して、アカウントの外部からリソースへのすべてのアクセスパスを識別します。また、リソースポリシーの継続的な確認と、パブリックおよびクロスアカウントアクセスの結果の報告により、広範囲なアクセス権の分析をしやすくします。すべてのアカウントについて表示できることを確認するために、AWS Organizations で IAM Access Analyzer を設定することを検討します。IAM Access Analyzer では、 [リソースのアクセス許可をデプロイする前に Access Analyzer の調査結果を](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)プレビューすることもできます。これにより、ポリシー変更によって、意図されたパブリックアクセスおよびクロスアカウントアクセスのみがリソースに付与されていることを検証できます。マルチアカウントアクセスについて設計するときは、 [ロールを引き受け可能なケースを制御するために信頼ポリシーを使用できます](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)。例えば、ロールの引き受けを特定の送信元 IP 範囲に限定できます。
また、 [AWS Config を使用して、](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) AWS Config ポリシーチェックで、リソースに意図しないパブリックアクセス設定があればレポートを生成し、修復することができます。例えば、 [AWS Control Tower](https://aws.amazon.com/controltower) および [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) などのサービスでは、AWS Organizations 全体でチェックとガードレールのデプロイが簡素化され、パブリックにアクセスできるリソースを特定および修復できます。例えば、AWS Control Tower にはマネージド型のガードレールが含まれており、 [Amazon EBS スナップショットがすべての AWS アカウントで復元可能かどうかを検出できます](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)。
## リソース
**関連するドキュメント:**
+ [AWS Identity and Access Management Access Analyzer を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower のガードレール](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Foundational Security Best Practices 標準](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config マネージドルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [AWS Trusted Advisor チェックリファレンス](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
**関連動画:**
+ [Best Practices for securing your multi-account environment (マルチアカウント環境を守るためのベストプラクティス)](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer (IAM Access Analyzer を深堀りする)](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 リソースを安全に共有する
アカウント間または AWS Organizations 内の共有リソースの消費を管理します。共有リソースをモニタリングし、共有リソースへのアクセスを確認します。
**一般的なアンチパターン:**
+ 第三者にクロスアカウントアクセスを許可する際に、デフォルトの IAM 信頼ポリシーを使用する
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
複数の AWS アカウントを使用してワークロードを管理するとき、アカウント間でのリソースの共有が必要になる場合があります。多くの場合、これは AWS Organizations 内でのクロスアカウント共有です。AWS の複数のサービス ( [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html)、[Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html)、 [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html) など) には Organizations と統合されたクロスアカウント機能があります。そのため、 [AWS Resource Access Manager](https://aws.amazon.com/ram/) を使用して、その他の一般的なリソースを共有します。例えば、 [VPC サブネットや Transit Gateway アタッチメント](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall)、 [Amazon SageMaker Runtime パイプライン](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)などです。アカウントで Organizations 内のリソースのみを共有する場合は、 [サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) を使用して外部プリンシパルへのアクセスを禁止することをお勧めします。
リソースを共有するとき、意図しないアクセスから保護するための手段を講じる必要があります。アイデンティティベースのコントロールとネットワークコントロールを組み合わせて [組織のデータ境界を作成することをお勧めします](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)。これらのコントロールは、どのリソースが共有可能かを厳格に制限し、共有や公開が許可されるべきでないリソースについてはそれを禁止する必要があります。例えば、データ境界の一部として、VPC エンドポイントポリシーと `aws:PrincipalOrgId` 条件を使用すると、組織に属しているアイデンティティのみが Amazon S3 バケットにアクセスするように設定できます。
場合により、Organizations 外部でリソース共有を許可したり、アカウントへのアクセス権を第三者に付与したりする必要があるかもしれません。例えば、パートナーが提供する監視ソリューションが、貴社のアカウント内のリソースにアクセスする必要があるかもしれません。そのような場合、第三者にとって必要な権限のみを含む IAM クロスアカウントロールを作成する必要があります。また、外部 ID 条件を使用して信頼ポリシーを作成する [必要もあります](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)。外部 ID を使用する際は、第三者それぞれに固有の ID を生成する必要があります。固有の ID は第三者によって提供、制御されるべきではありません。第三者が貴社の環境にアクセスする必要がなくなった場合は、ロールを削除する必要があります。また、いずれの場合も、第三者に長期的な IAM 認証情報を提供することは避ける必要があります。共有をネイティブにサポートする他の AWS サービスを継続的に把握しておきます。例えば、AWS Well-Architected Tool [では、](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) 他の AWS アカウントとワークロードを共有できます。
Amazon S3 などのサービスを使用する際は、 [Amazon S3 バケットの ACL を無効にし、](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) IAM ポリシーを使用してアクセスコントロールを定義することをお勧めします。[Amazon S3 ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) オリジンが [Amazon CloudFront](https://aws.amazon.com/cloudfront/) からアクセスされることを制限するには、オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) に移行します。OAC では [AWS KMS を使用したサーバー側暗号化を含む追加機能がサポートされています。](https://aws.amazon.com/kms/)を使用します。
## リソース
**関連するドキュメント:**
+ [バケット所有者が所有権のないオブジェクトへのクロスアカウントアクセス許可を付与する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM (IAM ロールと信頼ポリシーを使用する方法)](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Building Data Perimeter on AWS (AWS でのデータ境界の構築)](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
**関連動画:**
+ [Granular Access with AWS Resource Access Manager (AWS Resource Access Manager を使用したきめ細かいアクセス)](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Securing your data perimeter with VPC endpoints (VPC エンドポイントを使用したデータ境界の保護)](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Establishing a data perimeter on AWS (AWS でのデータ境界の確立) ](https://www.youtube.com/watch?v=SMi5OBjp1fI)