# ID とアクセス管理
**Topics**
+ [SEC 2 人とマシンの認証の管理はどのようにすればよいですか?](w2aac19b7b7b5.md)
+ [SEC 3 人とマシンのアクセス許可はどのように管理すればよいでしょうか?](w2aac19b7b7b7.md)
# SEC 2 人とマシンの認証の管理はどのようにすればよいですか?
AWS ワークロードを安全に運用するには、2 種類の ID を管理する必要があります。管理およびアクセス権を付与する必要があるアイデンティティのタイプを理解することで、適切な ID が適切な条件下で適切なリソースにアクセスできるようになります。
ユーザー ID: 管理者、開発者、オペレーター、エンドユーザーは、AWS 環境とアプリケーションにアクセスするために ID を必要とします。これらは、組織のメンバー、または共同作業を行う外部ユーザーであり、ウェブブラウザ、クライアントアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースを操作する人たちです。
マシン ID: サービスアプリケーション、運用ツール、ワークロードには、データの読み取りなどのために、AWS のサービスにリクエストを送信するための ID が必要です。このような ID には、Amazon EC2 インスタンスや AWS Lambda 関数など、AWS 環境で実行されているマシンが含まれます。また、アクセスを必要とする外部関係者のマシン ID を管理することもできます。さらに、AWS 環境にアクセスする必要があるマシンが AWS 外にある場合もあります。
**Topics**
+ [SEC02-BP01 強力なサインインメカニズムを使用する](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 一時的な認証情報を使用する](sec_identities_unique.md)
+ [SEC02-BP03 シークレットを安全に保存して使用する](sec_identities_secrets.md)
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](sec_identities_identity_provider.md)
+ [SEC02-BP05 定期的に認証情報を監査およびローテーションする](sec_identities_audit.md)
+ [SEC02-BP06 ユーザーグループと属性を活用する](sec_identities_groups_attributes.md)
# SEC02-BP01 強力なサインインメカニズムを使用する
パスワードに最小の長さを設定し、よくあるパスワードや再利用を避けるようにユーザーを教育します。ソフトウェアまたはハードウェアのメカニズムを使用した Multi-Factor Authentication (MFA) を強制して、検証を追加します。例えば、IAM アイデンティティセンターをアイデンティティソースとして使用する場合、MFA の「コンテキストアウェア」または「常時オン」設定でユーザーに独自の MFA デバイスの登録を許可すると、すばやく使用開始できます。外部の ID プロバイダー (IdP) を使用する場合は、IdP を MFA 用に設定します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ MFA サインインを強制するアクセス管理 (IAM) ポリシーを作成する: ユーザーが [マイセキュリティ資格情報] ページでロールを引き受け、自分の認証情報を変更し、MFA デバイスを管理できるようにするものを除いて、すべての IAM アクションを禁止するカスタマー管理 IAM ポリシーを [作成します](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1).
+ ID プロバイダーで MFA を有効にする: [MFA](https:/aws.amazon.com/iam/details/mfa) を、アイデンティティプロバイダーや使用する [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/step1.html)などのシングルサインオンサービスで有効にします。
+ 強力なパスワードポリシーを設定する: [強力なパスワードポリシーを](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html?ref=wellarchitected) IAM やフェデレーテッド ID システムで設定して、総当たり攻撃から守ります。
+ [認証情報を定期的にローテーションする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials): ワークロードの管理者が、パスワードとアクセスキー (使用されている場合) を定期的に変更するようにします。
## リソース
**関連するドキュメント:**
+ [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html?ref=wellarchitected)
+ [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html?ref=wellarchitected)
+ [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html?ref=wellarchitected)
+ [セキュリティパートナーソリューション: アクセスおよびアクセスコントロール](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
**関連動画:**
+ [シークレットを大規模に管理、取得、変更するためのベストプラクティス](https://youtu.be/qoxxRlwJKZ4)
+ [IAM Identity Center を使用した大規模なユーザー権限の管理](https://youtu.be/aEIqeFCcK7E)
+ [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP02 一時的な認証情報を使用する
ID を要求して一時的な認証情報を [動的に取得します](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html).ワークフォース ID の場合、AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) ロールとのフェデレーションを使用して AWS アカウント にアクセスします。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや AWS Lambda 関数などのマシン ID の場合、長期的なアクセスキーを持つ IAM ユーザーではなく IAM ロールを使用する必要があります。
AWS マネジメントコンソール を使用するユーザー ID の場合、ユーザーは一時的な認証情報の取得と AWS へのフェデレーションが必要です。これは、AWS IAM アイデンティティセンター ユーザーポータルを使用して実行できます。CLI アクセスを必要とするユーザーの場合は、 [AWS CLI v2](http://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-generally-available/)(IAM Identity Center との直接統合をサポートする) を使用していることを確認してくださいユーザーは、IAM アイデンティティセンターアカウントおよびロールにリンクされた CLI プロファイルを作成できます。CLI は AWS の認証情報を IAM Identity Center から自動的に取得し、ユーザーに代わってその情報を更新します。これにより、 コンソールから一時的な AWS の認証情報をコピーして貼り付ける作業を省略できます。SDK については、ユーザーは AWS Security Token Service (AWS STS) を使用して、一時的な認証情報を取得するロールを引き受ける必要があります。場合によって、一時的な認証情報が使用できないこともあります。アクセスキーを保存するリスクに注意しながら頻繁に更新し、可能なら多要素認証 (MFA) を条件として設定する必要があります。最後に評価した情報を使って、アクセスキーを変更または削除するタイミングを決定します。
AWS リソースへのアクセス権を一般ユーザーに付与する必要がある場合は、 [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html) ID プールを使用して、AWS リソースにアクセスするための、権限が制限されている一時的な認証情報のセットを割り当てます。各ユーザーの権限は、作成した [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) で制御されます。ユーザーのロールを選択するルールは、ユーザーの ID トークンの登録に基づいて定義します。認証済みユーザーにはデフォルトのロールを定義します。認証されていないゲストユーザーには、制限付きのアクセス権限を持つ IAM ロールを個別に定義できます。
マシン ID に AWS へのアクセス許可を付与するには IAM ロールが必要です。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの場合は、 [Amazon EC2 用のロールを使用できます](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).IAM ロールを Amazon EC2 インスタンスにアタッチすると、Amazon EC2 で実行されているアプリケーションは、AWS がインスタンスメタデータサービス (IMDS) を通して自動的に作成、配布、ローテーションする一時的なセキュリティ認証情報を使用できるようになります。それらの [IMDS の最新バージョンを](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/) 使用すると、臨時の認証情報を公開する脆弱性から保護できるため、実装する必要があります。キーまたはパスワードを使用して Amazon EC2 インスタンスにアクセスする場合、[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、保存されたシークレットなしで、インストール済みエージェントを使用してインスタンスにアクセスし管理するためのより安全な方法として使用できます。さらに、AWS Lambda などの AWS のサービスでは、IAM サービスロールを設定して、一時的な認証情報でサービスに AWS アクションを実行する権限を与えることができます。臨時の認証情報を使用できない状況では、 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)のようなプログラムツールを使って、認証情報の変更と管理を自動化します。
**定期的に認証情報を監査およびローテーションする: **正しい制御が実施されていることを確認するには、定期的な検証、できれば自動化されたツールによる検証が必要です。ユーザー ID の場合、ユーザーにはパスワードの定期的な変更と、一時的な認証情報を優先したアクセスキーの削除を要求する必要があります。IAM ユーザーから一元化されたアイデンティティに移行しているため、 [認証情報レポートを生成して ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)IAM ユーザーを監査できます。また、ID プロバイダーの MFA 設定を矯正することを推奨します。次の [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) をセットアップして、これらの設定をモニタリングできます。マシン ID の場合、IAM ロールを使用した一時的な認証情報を使用する必要があります。それが不可能なときは、アクセスキーの監査および更新の頻度を高めることが重要です。
**シークレットを安全に保存して使用する:** IAM に関連せず、臨時認証情報を利用できない認証情報 (データベースのログインなど) については、シークレット管理用に設計されたサービス [Secrets Manager](https://aws.amazon.com/secrets-manager/)。Secrets Manager では、サポートされているサービスを使用して、暗号化されたシークレットの管理、ローテーション、安全な保管を簡単に [行うことができます](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html).シークレットにアクセスするための呼び出しは、監査用に AWS CloudTrail に記録されます。IAM のアクセス許可を使用すれば、それに最小権限のアクセス許可を付与することが可能です。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 最小権限ポリシーを実装する: IAM グループおよびロールに最小権限のアクセスポリシーを割り当てて、定義したユーザーのロールまたは機能を反映します。
+ [最小権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ 必要でないアクセス許可を削除する: 不要なアクセス許可を削除して、最小権限を実装します。
+ [ユーザーアクティビティを確認してポリシーの範囲を削減する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [ロールアクセスを表示する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#roles-delete_prerequisites)
+ アクセス許可の境界を考慮する: アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する管理ポリシーを使用するための高度な機能です。エンティティのアクセス許可の境界では、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。
+ [ラボ: ロールの作成を委任する IAM アクセス許可境界](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html)
+ アクセス許可のリソースタグを検討する: タグを使用して、タグ付けをサポートする AWS リソースへのアクセスを制御できます。また、IAM ユーザーとロールにタグ付けして、ユーザーがアクセスできる内容を制御することもできます。
+ [ラボ: EC2 の IAM タグベースのアクセスコントロール](https://wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html)
+ [Attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
## リソース
**関連するドキュメント:**
+ [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [セキュリティパートナーソリューション: アクセスおよびアクセスコントロール](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
**関連動画:**
+ [シークレットを大規模に管理、取得、変更するためのベストプラクティス](https://youtu.be/qoxxRlwJKZ4)
+ [AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理](https://youtu.be/aEIqeFCcK7E)
+ [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP03 シークレットを安全に保存して使用する
サードパーティー製アプリケーションのパスワードなど、シークレットを必要とするユーザー ID とマシン ID については、最新の業界標準を用いた自動ローテーションで保管します。IAM に関連せず、データベースのログインなど一時的な認証情報を活用できないものについては、AWS Secrets Manager のようなシークレットの管理に対応したサービスを使用します。Secrets Manager では、サポートされているサービスを使用して、暗号化されたシークレットの管理、ローテーション、安全な保管を簡単に行うことができます。 シークレットにアクセスするための呼び出しは、監査用に AWS CloudTrail に記録されます。IAM 権限により、最小限の権限でアクセスできるようにすることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ AWS Secrets Manager を使用する: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、機密情報の管理を容易にする AWS のサービスです。シークレットとは、データベース認証情報、パスワード、サードパーティ API キー、任意のテキストなどです。
## リソース
**関連するドキュメント:**
+ [AWS Secrets Manager の開始方法 ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
**関連動画:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4)
# SEC02-BP04 一元化された ID プロバイダーを利用する
ユーザー ID の場合、ID を一元管理できる ID プロバイダーを利用します。一つの場所から権限の作成、管理、取り消しを行うため、複数のアプリケーションおよびサービスに影響する権限を効率的に管理できます。たとえば誰かが組織を離れる場合、すべてのアプリケーションとサービス (AWS を含む) へのアクセスを一つの場所で取り消すことができます。これにより、複数の認証情報を用意する必要性がなくなり、既存の人事 (HR) プロセスと統合できる可能性が生まれます。
AWS の個別アカウントのフェデレーションでは、AWS Identity and Access Management を使った SAML 2.0 ベースのプロバイダーで AWS の一元化された ID を使用できます。SAML 2.0 プロトコルと互換性のあるプロバイダーであればいずれも使用できます。AWS でホストされているかどうか、AWS 外部にあるかどうか、AWS Partner パートナーネットワーク (APN) から提供されているかどうかは問いません [SAML 2.0 ベースのプロバイダーで、](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html) 。AWS アカウントと選択したプロバイダーのフェデレーションを使用して、SAML アサーションで一時的なセキュリティ認証情報を取得すれば、ユーザーまたはアプリケーションに AWS API オペレーションを呼び出すアクセス権限を付与できます。ウェブベースのシングルサインオンもサポートされており、ユーザーはサインインウェブサイトから AWS マネジメントコンソールにサインインできます。
AWS Organizations の複数のアカウントへのフェデレーションの場合は、 [AWS IAM アイデンティティセンター (IAM Identity Center) で ID ソースを設定して、](http://aws.amazon.com/single-sign-on/)ユーザーとグループの保存場所を指定できます。設定が完了すると、ID プロバイダーが信頼できる [ソースになり、](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) System for Cross-domain Identity Management (SCIM) v2.0プロトコルを利用して情報を同期できます。その後ユーザーまたはグループを検索し、AWS アカウントやクラウドアプリケーションへの IAM Identity Center アクセスを付与できます。
IAM Identity Center は AWS Organizations と統合され、ID プロバイダーを一度設定してから、 [組織で管理している既存および新規のアカウントへの](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html) アクセス権を付与できます。IAM Identity Center には、ユーザーとグループの管理に使用できるデフォルトストアがあります。IAM Identity Center ストアを使用する場合は、ユーザーとグループを作成してから、最小権限のベストプラクティスに基づきそのアクセスレベルを必要な AWS アカウントとアプリケーションに割り当てます。または、 [SAML 2.0 を利用して ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)外部の ID プロバイダーに [接続するか、](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) AWS Directory Service を使用して Microsoft AD ディレクトリに接続するかを選択できます。設定が完了したら、一元化された ID プロバイダーで認証すれば、AWS マネジメントコンソール、AWS モバイルアプリにサインインできるようになります。
モバイルアプリなどのワークロードのエンドユーザー管理には、 [Amazon Cognito](http://aws.amazon.com/cognito/)。このサービスには、ウェブおよびモバイルアプリケーションの認証、承認、ユーザー管理の機能があります。ユーザーは、ユーザー名とパスワードを使用して直接サインインするか、Amazon、Apple、Facebook、Google などのサードパーティーを通じてサインインできます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ 管理アクセスを一元化する: Identity and Access Management (IAM) アイデンティティプロバイダーエンティティを作成して、AWS アカウント とアイデンティティプロバイダー (IdP) 間に信頼される関係を確率します。IAM は、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートします。
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ アプリケーションアクセスを一元化する: アプリケーションアクセスの一元化には Amazon Cognito を考慮します。ユーザーのサインアップやサインイン、アクセスコントロールをモバイルアプリやウェブアプリに簡単に追加できます。 [Amazon Cognito](https://aws.amazon.com/cognito/) は、数百万人のユーザーに対応し、Facebook、Google、Amazon などのソーシャル ID プロバイダーや、SAML 2.0 によるエンタープライズ ID プロバイダーとのサインインをサポートします。
+ 旧 IAM ユーザーおよびグループを削除する: ID プロバイダー (IdP) の使用を開始したら、不要になった IAM ユーザーとグループを削除します。
+ [未使用の認証情報の検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html)
+ [IAM グループの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html)
## リソース
**関連するドキュメント:**
+ [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Security Partner Solutions: Access and Access Control (セキュリティパートナーソリューション: アクセスおよびアクセスコントロール)](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
**関連動画:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4)
+ [Managing user permissions at scale with AWS IAM アイデンティティセンター (AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理)](https://youtu.be/aEIqeFCcK7E)
+ [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP05 定期的に認証情報を監査およびローテーションする
一時的な認証情報に頼れず、長期的な認証情報が必要な場合は、認証情報を監査して、定義された管理方法、たとえば多要素認証 (MFA) が実施され、定期的にローテーションされ、アクセスレベルが適切であることを確認する必要があります。正しい制御が実施されていることを確認するには、定期的な検証、できれば自動化されたツールによる検証が必要です。ユーザー ID の場合、ユーザーにはパスワードの定期的な変更と、一時的な認証情報を優先したアクセスキーの削除を要求する必要があります。AWS Identity and Access Management (IAM) ユーザーから一元化されたアイデンティティに移行しているため、 [認証情報レポートを生成して ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)IAM ユーザーを監査できます。また、ID プロバイダーで MFA 設定を実施することをお勧めします。次の [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) をセットアップして、これらの設定をモニタリングできます。マシン ID の場合、IAM ロールを使用した一時的な認証情報を使用する必要があります。それが不可能なときは、アクセスキーの監査および更新の頻度を高めることが重要です。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 認証情報を定期的に監査する: 認証情報レポートと Access Management (IAM) Access Analyzer を使用して、IAM 認証情報とアクセス許可を監査します。
+ [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [認証情報レポートの取得](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
+ [ラボ: IAM ユーザーの自動クリーンアップ](https://wellarchitectedlabs.com/Security/200_Automated_IAM_User_Cleanup/README.html?ref=wellarchitected-tool)
+ アクセスレベルを使用して IAM アクセス許可を確認する: AWS アカウント のセキュリティを向上させるには、各 IAM ポリシーを定期的に確認してモニタリングします。ポリシーが、必要なアクションのみを実行するために必要な最小権限を付与していることを確認します。
+ [アクセスレベルを使用して IAM アクセス許可を確認する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-access-levels-to-review-permissions)
+ IAM リソースの作成と更新の自動化を検討する: AWS CloudFormation を使用すると、テンプレートを検証してバージョンを管理できるため、ロールやポリシーを含む IAM リソースのデプロイを自動化して、人為的ミスを減らすことができます。
+ [ラボ: IAM グループとロールの自動デプロイ](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_IAM_Groups_and_Roles/README.html)
## リソース
**関連するドキュメント:**
+ [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Security Partner Solutions: Access and Access Control (セキュリティパートナーソリューション: アクセスおよびアクセスコントロール)](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
**関連動画:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4)
+ [Managing user permissions at scale with AWS IAM アイデンティティセンター (AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理)](https://youtu.be/aEIqeFCcK7E)
+ [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 ユーザーグループと属性を活用する
管理対象のユーザー数が増えるにつれて、大規模な管理ができるユーザー管理方法が必要となります。一般的なセキュリティ要件を持つユーザーを ID プロバイダーで定義したグループに分け、アクセスコントロールに使用される可能性のあるユーザー属性 (部署や場所など) を最新で正確な状態に保つメカニズムを導入します。アクセス制御には、個々のユーザーではなくこのグループと属性を使用します。こうすると、アクセス許可セットを使用してユーザーのグループメンバーシップや属性を一度変更するだけで [アクセスを一元管理でき、](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html)ユーザーのアクセスに変更が必要なときに多数のポリシーを個別に更新せずに済みます。ユーザーグループや属性の管理に AWS IAM アイデンティティセンター (IAM Identity Center)を使用できます。IAM Identity Center は、一般的に使用されている属性に対応しています。ユーザー作成時の手動入力も、クロスドメイン ID 管理システム (SCIM) 仕様などで定義された同期エンジンを使用した自動プロビジョニングも可能です。
一般的なセキュリティ要件を持つユーザーを ID プロバイダーで定義したグループに分け、アクセスコントロールに使用される可能性のあるユーザー属性 (部署や場所など) を最新で正確な状態に保つメカニズムを導入します。アクセスを制御するには、個々のユーザーではなくこれらのグループと属性を使用します。これにより、ユーザーのアクセスニーズが変化したときに多くの個別のポリシーを更新することなく、ユーザーのグループメンバーシップや属性を 1 回変更することで、アクセスを一元管理できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ AWS IAM アイデンティティセンター (IAM Identity Center)を使用している場合、グループを設定します: IAM Identity Center では、ユーザーのグループを設定し、必要なレベルのアクセス許可をグループに割り当てることができます。
+ [AWS シングルサインオン - アイデンティティの管理](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ 属性ベースのアクセスコントロール (ABAC) について学ぶ: ABAC は、属性に基づいてアクセス許可を定義する認証戦略です。
+ [AWS の ABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [ラボ: EC2 の IAM タグベースのアクセスコントロール](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html)
## リソース
**関連するドキュメント:**
+ [AWS Secrets Manager の開始方法](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
**関連動画:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale (シークレットを大規模に管理、取得、変更するためのベストプラクティス)](https://youtu.be/qoxxRlwJKZ4)
+ [Managing user permissions at scale with AWS IAM アイデンティティセンター (AWS IAM アイデンティティセンター を使用した大規模なユーザー権限の管理)](https://youtu.be/aEIqeFCcK7E)
+ [すべての層での ID の把握](https://www.youtube.com/watch?v=vbjFjMNVEpc)
**関連する例:**
+ [ラボ: EC2 の IAM タグベースのアクセスコントロール](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html)
# 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)