# ID とアクセス管理
**Topics**
+ [SEC 2. 人とマシンの認証の管理はどのようにすればよいですか?](sec-02.md)
+ [SEC 3. 人とマシンのアクセス許可をどのように管理するのですか。](sec-03.md)
# SEC 2. 人とマシンの認証の管理はどのようにすればよいですか?
安全な AWS ワークロードの運用へのアプローチでは、管理が必要な 2 つのタイプの ID があります。
+ **人的 ID:** AWS 環境やアプリケーションへのアクセスを必要とする人間の ID は、ワークフォース、サードパーティー、ユーザーの 3 つのグループに分類できます。
*ワークフォース*グループには、組織のメンバーである管理者、デベロッパー、オペレーターが含まれます。AWS リソースを管理、構築、運用するためのアクセス権が必要です。
*サードパーティー*とは、請負業者、ベンダー、パートナーなどの外部協力者です。サードパーティーは、組織とのエンゲージメントの一環として AWS リソースとやり取りします。
*ユーザー*とは、アプリケーションの消費者です。ウェブブラウザ、クライアントアプリケーション、モバイルアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースにアクセスします。
+ **マシン ID:** ワークロードアプリケーション、運用ツール、コンポーネントには、データ読み取りなどのため、AWS のサービスにリクエストを送信できる ID が必要です。これらの ID には、Amazon EC2 インスタンスや AWS Lambda 関数などの AWS 環境で実行中のマシンも含まれます。また、AWS 環境へのアクセスを必要とする外部関係者のマシン ID、または AWS 外のマシンのマシン ID を管理することもできます。
**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 強力なサインインメカニズムを使用する
サインイン (サインイン認証情報を使った認証) は、多要素認証 (MFA) などのメカニズムを使わない場合、特にサインイン認証情報が不用意に開示されたり、容易に推測されたりする場合に、リスクが発生する恐れがあります。MFA や強力なパスワードポリシーを要求することで、これらのリスクを軽減する強力なサインインのメカニズムを使用します。
**期待される成果:** [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) ユーザー、[AWS アカウントルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)、[AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)、およびサードパーティー ID プロバイダーに強力なサインインメカニズムを使用することで、AWS の認証情報への意図しないアクセスのリスクを軽減します。これは、MFA が必須となり、強力なパスワードポリシーが適用され、異常なログイン動作が検出されることを意味します。
**一般的なアンチパターン:**
+ 複雑なパスワードや MFA など、自分のアイデンティティに対して強力なパスワードポリシーを適用しない。
+ 複数のユーザー間で同一の認証情報を共有する。
+ 疑わしいサインインに対して検出コントロールを使用しない。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
人的 ID が AWS にサインインする方法は多数あります。AWS への認証時に、フェデレーション (AWS IAM と集中型 IdP 間の直接 SAML 2.0 フェデレーション、またはAWS IAM アイデンティティセンターを使用) を使用して一元化された ID プロバイダーに依存するのが AWS ベストプラクティスです。この場合、ID プロバイダーまたは Microsoft Active Directory を使って、セキュアなサインインプロセスを確立します。
最初に AWS アカウントを開いたとき、AWS アカウントルートユーザーから始めます。アカウントのルートユーザーは、ユーザー (および[ルートユーザーを必要とするタスク](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)) のアクセスを設定するときのみに使用することを推奨します。AWS アカウント を開いた直後にアカウントのルートユーザーに対して多要素認証 (MFA) を有効にし、[AWS ベストプラクティスガイド](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html)を使用してルートユーザーを保護することが重要です。
AWS IAM アイデンティティセンターはワークフォースユーザー向けに設計されており、サービス内でユーザー ID を作成および管理し、MFA を使用してサインインプロセスを保護できます。AWS一方、Cognito は、アプリケーションの外部ユーザー ID のユーザープールと ID プロバイダーを提供するカスタマー ID とアクセス管理 (CIAM) 用に設計されています。
AWS IAM アイデンティティセンターでユーザーを作成する場合は、そのサービスでサインインプロセスを保護し、[MFA をオン](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)にします。アプリケーション内の外部ユーザー ID については、[Amazon Cognito ユーザープール](https://docs.aws.amazon.com/cognito/index.html)を使用して、そのサービス内または Amazon Cognito ユーザープールがサポートする ID プロバイダーのいずれかを通じてサインインプロセスを保護できます。
さらに、AWS IAM アイデンティティセンターのユーザーの場合、[AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) を使用して、AWS リソースへのアクセス権が付与される前にユーザーの ID とデバイスの状態を検証して、セキュリティレイヤーを強化できます。
[AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) ユーザーを使用している場合、IAM を使用してサインインプロセスをセキュリティ保護することになります。
AWS IAM アイデンティティセンターとダイレクト IAM フェデレーションの両方を同時に使用して、AWS へのアクセスを管理できます。IAM フェデレーションを使用して AWS マネジメントコンソール およびサービスへのアクセスを管理し、IAM アイデンティティセンターを使用して Quick や Amazon Q Business などのビジネスアプリケーションへのアクセスを管理できます。
サインイン方法に関係なく、強力なサインインポリシーを適用することが不可欠です。
### 実装手順
一般的な強力なサインインに関する推奨事項は次のとおりです。実際に行う設定は、組織のポリシーによって設定するか、または [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html) のような標準を使います。
+ MFA が必要。人的 ID とワークロードに対しては、MFA を義務付けることが [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users)です。MFA を有効にすることで、追加のセキュリティ層が提供されます。この層では、ユーザーがサインイン認証情報、ワンタイムパスワード (OTP)、またはハードウェアデバイスから暗号的に検証および生成された文字列を提供することが求められます。
+ 最小パスワード文字数を適用します。これは、パスワードの強さにおける主な要素です。
+ パスワードの複雑性を適用すると、パスワードを推測しにくくなります。
+ 自分のパスワードの変更をユーザーに許可します。
+ 共有認証情報ではなく、個別の ID を作成します。個別の ID を作成することで、各ユーザーに固有のセキュリティ認証情報を付与することができます。個別のユーザーを作成することによって、各ユーザーのアクティビティを監査する機能が利用できます。
IAM アイデンティティセンターレコメンデーション:
+ IAM アイデンティティセンターは、デフォルトディレクトリを使用する際、パスワードの文字数、複雑性、および再使用要件を確立する、事前定義された[パスワードポリシー](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)を提供します。
+ [MFA を有効](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html)にし、アイデンティティソースがデフォルトディレクトリ、AWS Managed Microsoft AD、または AD Connector の場合、MFA に対してコンテキストアウェアまたは常時オン設定を行います。
+ ユーザーが[自分の MFA デバイスを登録](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html)できるようにします。
Amazon Cognito ユーザープールディレクトリのレコメンデーション:
+ [パスワードの強さ](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)設定を行います。
+ ユーザーに [MFA を義務付けます](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html)。
+ 疑わしいサインインをブロックできる[適応型認証](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html)などの機能に対して、Amazon Cognito ユーザープール[上級セキュリティ設定](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html)を使用します。
IAM ユーザーのレコメンデーション:
+ IAM アイデンティティセンターまたは直接フェデレーションを使用することが理想的です。しかし、IAM ユーザー向けのニーズもあるでしょう。その場合は、IAM ユーザー向けに[パスワードポリシーを設定します](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)。パスワードポリシーを使用して、最小文字数、またはアルファベット以外の文字が必要かどうかなどの要件を定義できます。
+ IAM ポリシーを作成して、[MFA サインインを適用](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1)し、ユーザーが自分のパスワードと MFA デバイスを管理できるようにします。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP03 シークレットを安全に保存して使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 組織内でリソースを安全に共有する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**関連ドキュメント:**
+ [AWS IAM アイデンティティセンターパスワードポリシー](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [IAM ユーザーのパスワードポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [AWS アカウントルートユーザーのパスワードの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Amazon Cognito パスワードポリシー](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [AWS 認証情報](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [ IAM セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
**関連動画:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP02 一時的な認証情報を使用する
何らかの認証を行う際、認証情報が誤って開示、共有、盗難されたりなどのリスクを軽減または排除するには、長期的認証情報ではなく一時的な認証情報を使うことが推奨されます。
**期待される成果:** 長期的認証情報のリスクを軽減するには、人的および機械両方の ID にできるだけ一時的な認証情報を使用するようにします。長期認証情報は、公開リポジトリへのアップロードによる情報漏洩など、多くのリスクが発生します。一時的な認証情報を使うことにより、認証情報が侵害されるリスクが大幅に減少します。
**一般的なアンチパターン:**
+ 開発者が、フェデレーションを使って CLI から一時的な認証情報を取得するのではなく、IAM ユーザーからの長期的なアクセスキーを使用する。
+ 開発者がコードに長期的アクセスキーを埋め込んで、そのコードをパブリック Git リポジトリにアップロードする。
+ 開発者が、モバイルアプリに長期的アクセスキーを埋め込んで、アプリストアで公開する。
+ ユーザーが長期的アクセスキーを他のユーザー、または従業員と共有し、長期的アクセスキーを所有したまま離職する。
+ 一時的認証情報を使用できるのに、マシン ID に対して長期的なアクセスキーを使用する。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
すべての AWS API と CLI リクエストに対して、長期的認証情報ではなく一時的なセキュリティ認証情報を使用します。AWS サービスに対する API および CLI リクエストは、ほとんどの場合、[AWS アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)を使って署名する必要があります。これらのリクエストの署名に使用する認証情報は、一時的でも長期的でもかまいません。長期的認証情報 (長期的アクセスキー) を使用すべき唯一の状況は、[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)または [AWS アカウントルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)を使用している場合です。AWS に対してフェデレーションを行うか、または他の方法により [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を担う場合、一時的認証情報が生成されます。サインイン認証情報を使って AWS マネジメントコンソールにアクセスしても、AWS サービスへのコールを行うために一時的な認証情報が生成されます。長期的認証情報が必要な状況はほとんどなく、一時的な認証情報でほとんどのタスクを遂行できます。
一時的な認証情報を優先して長期的な認証情報の使用を回避することは、フェデレーションと IAM ロールを優先して IAM ユーザーの使用を減少させる戦略と一致していなければなりません。IAM ユーザーは過去に人的とマシン ID 両方に対して使用されましたが、長期的アクセスキー使用におけるリスクを回避するため、それを使用しないよう推奨しています。
### 実装手順
#### 人的 ID
従業員、管理者、デベロッパー、およびオペレーターなどのワークフォース ID の場合:
+ [一元化された ID プロバイダーに依存して](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)、[人間ユーザーが一時的な認証情報を使って AWS にアクセスするには、ID プロバイダーにフェデレーションを使用することを義務付ける必要があります](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。ユーザーに対するフェデレーションは、[各 AWS アカウント の直接のフェデレーション](https://aws.amazon.com/identity/federation/)、または [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)と任意の ID プロバイダーを使用して行うことができます。フェデレーションは、長期的な認証情報を排除するだけでなく、IAM ユーザーを使用する場合と比較して多数の利点があります。ユーザーは[直接フェデレーション](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/)用のコマンド行から、または [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) を使用して、一時的な認証情報をリクエストすることができます。つまり、IAM ユーザーまたは、ユーザー向けの長期的認証情報を必要なケースはほとんどないということです。
サードパーティー ID の場合:
+ Software as a Service (SaaS) などのサードパーティーに、AWS アカウントのリソースへのアクセスを付与する際、[クロスアカウントロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)および[リソースベースポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)を使用できます。また、B2B SaaS の顧客またはパートナーには、[Amazon Cognito OAuth 2.0 付与](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html)クライアント認証情報フローを使用することもできます。
ウェブブラウザ、クライアントアプリケーション、モバイルアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースにアクセスするユーザー ID:
+ 消費者や顧客向けのアプリケーションに AWS リソースへのアクセスを許可する必要がある場合、[Amazon Cognito アイデンティティプール](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html)または [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)を使用して、一時的な認証情報を提供できます。認証情報に対するアクセス許可は、IAM ロールを介して設定されます。また、認証されていないゲストユーザーに対して、権限が制限された個別の IAM ロールを定義することもできます。
#### マシン ID
マシン ID の場合、長期的認証情報を使用しなければならない場合があります。これらの場合、[IAM ロールで AWS にアクセスする際に、ワークロードが一時的な認証情報を使用するよう義務付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles)必要があります。
+ [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2) の場合、[Amazon EC2 に対してロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)を使用できます。
+ [AWS Lambda](https://aws.amazon.com/lambda/) では、一時的な認証情報を使って AWS アクションを実行するための[サービス権限を付与する Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)を設定できます。AWS サービスが、IAM ロールを使って一時的な認証情報を付与する類似モデルは多数あります。
+ IoT デバイスの場合、[AWS IoT Core 認証情報プロバイダー](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)を使って、一時的な認証情報をリクエストできます。
+ オンプレミスのシステム、または AWS 外で実行され、AWS リソースへアクセスする必要があるシステムの場合、[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用できます。
一時的な認証情報がサポートされていないシナリオがあり、その場合は長期認証情報を使用する必要があります。これらの状況では、[定期的にこれらの認証情報を監査してローテーション](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)し、さらに[定期的にアクセスキーをローテーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)します。制限の厳しい IAM ユーザーアクセスキーについては、以下の追加のセキュリティ対策を検討してください。
+ 次のように、制限の厳しいアクセス許可を付与します。
+ 最小特権の原則 (アクション、リソース、条件を具体的に指定します) に従います。
+ IAM ユーザーに、特定の 1 つのロールに対する AssumeRole オペレーションのみを付与することを検討してください。オンプレミスアーキテクチャの一部では、このアプローチを使用することにより、長期 IAM 認証情報を分離して安全に保護できます。
+ IAM ロール信頼ポリシーで許可されるネットワークソースと IP アドレスを制限します。
+ 使用状況をモニタリングし、未使用のアクセス許可や誤使用に対してアラートを設定します (AWSCloudWatch Logs メトリクスフィルターとアラームを使用)。
+ [アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) を適用します (サービスコントロールポリシー (SCP) は粗く、アクセス許可の境界はきめ細かく、相互に補完する関係にあります)。
+ 認証情報をプロビジョニングして、安全に (オンプレミスのボールトに) 保存するプロセスを実装します。
長期認証情報が必要なシナリオのその他のオプションには、次のようなものがあります。
+ (Amazon API Gateway を使用して) 独自のトークン供給 API を構築する。
+ 長期認証情報や AWS アクセスキー以外の認証情報 (データベースログインなど) を使用する必要があるシナリオでは、[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) など、シークレット管理を処理するために設計されたサービスを使用できます。Secrets Manager は、暗号化されたシークレットの管理、ローテーション、安全なストレージを簡素化します。多くの AWS サービスでは、Secrets Manager との[直接統合](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html)をサポートしています。
+ マルチクラウド統合では、ソース認証情報サービスプロバイダー (CSP) の認証情報に基づいた ID フェデレーションを使用できます (「[AWS STS AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)」を参照)。
長期的認証情報のローテーションについては、「[アクセスキーのローテーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)」を参照してください。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP03 シークレットを安全に保存して使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 組織内でリソースを安全に共有する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**関連ドキュメント:**
+ [一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS 認証情報](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [IAM セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
+ [AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/)
+ [ID プロバイダーとフェデレーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [アクセスキーの更新](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)
+ [AWS セキュリティコンピテンシーパートナー](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Google Cloud Platform ネイティブワークロード ID を使用して AWS にアクセスする](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/)
+ [AWS Security Token Service を使用して Microsoft Entra ID テナントから AWS リソースにアクセスする方法](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/)
**関連動画:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP03 シークレットを安全に保存して使用する
ワークロードには、データベース、リソース、およびサードパーティーサービスにアイデンティティを証明するための自動機能が必要となります。これは、API アクセスキー、パスワード、および OAuth トークンなどの、シークレットアクセス認証情報を使って実現されます。これらの認証情報を保存、管理、ローテーションする専用のサービスを使用することで、認証情報が侵害される可能性を低減することができます。
**期待される成果:** 次の目標を達成するアプリケーションの認証情報を安全に管理するメカニズムを実装します。
+ ワークロードに必要なシークレットを特定する。
+ 長期的認証情報を短期的認証情報と置き換える (可能な場合) ことによりその数を減らす。
+ 安全なストレージと、残りの長期的認証情報の自動化されたローテーションを確立する。
+ ワークロードに存在するシークレットへのアクセスを監査する。
+ 開発プロセス中、ソースコードに組み込まれたシークレットがないことを継続的に監視する。
+ 認証情報が誤って開示される可能性を減らす。
**一般的なアンチパターン:**
+ 認証情報をローテーションしない。
+ ソースコードまたは設定ファイルに長期的認証情報を保管する。
+ 認証情報を暗号化せずに保管する。
**このベストプラクティスを活用するメリット:**
+ シークレットが、保管時と転送時に暗号化される。
+ 認証情報へのアクセスが、API (認証情報の自動販売機として捉える) 経由でゲート化される。
+ 認証情報へのアクセス (読み出しと書き込み) が監査およびログ記録される。
+ 懸念事項の分離: 認証情報のローテーションは、アーキテクチャの他の部分から分離できる別のコンポーネントによって実行されます。
+ シークレットは、ソフトウェアコンポーネントに対してオンデマンドで配布され、中央ロケーションでローテーションが発生する。
+ 認証情報へのアクセスは、非常にきめ細やかに制御できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
従来、データベースやサードパーティーの API、トークンなどの認証に使用する認証情報は、ソースコードや環境ファイルに埋め込まれている場合がありました。AWS は、これらの認証情報を安全に保管し、自動的にローテーションし、その使用を監査するメカニズムを複数提供しています。
シークレット管理に対する最善のアプローチは、削除、置換、ローテーションのガイダンスに従うことです。最も安全な認証情報は、保管、管理、処理が不要なものです。認証情報によっては、ワークロードの機能にとって不要となった、安全に削除できるものもあります。
ワークロードの正常な機能に依然として必要な認証情報については、長期的認証情報を一時的または短期的な認証情報と置換する機会があるかもしれません。例えば、AWS シークレットアクセスキーをハードコーディングする代わりに、IAM ロールを使って長期的認証情報を一時的認証情報と置換することを検討してみてください。
存続期間の長いシークレットによっては、削除も置換もできないものがあります。これらのシークレットは、[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) などのサービスに保管して、一元的に保管、管理したり、定期的にローテーションしたりすることができます。
ワークロードのソースコードと設定ファイルの監査を行うと、さまざまなタイプの認証情報が明らかになる可能性があります。次の表は、一般的なタイプの認証情報を取り扱うための戦略をまとめたものです。
| 認証情報のタイプ | 説明 | 推奨される戦略 |
| --- | --- | --- |
| IAM アクセスキー | ワークロード内で IAM ロールを引き受けるために使用される AWS IAM アクセスとシークレットキー | 置き換え: 代わりに、コンピューティングインスタンス ([Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) や [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) など) に割り当てられた [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html)を使用します。AWS アカウント内のリソースへのアクセスを必要とするサードパーティーとの相互運用性については、[AWS クロスアカウントアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)をサポートしているかどうかを確認してください。モバイルアプリの場合は、[Amazon Cognito アイデンティティプール (フェデレーティッド ID)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html) を介して一時的な認証情報を使用することを検討してください。AWS の外部で実行されているワークロードについては、[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) または [AWS Systems Manager ハイブリッドアクティベーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)を検討してください。コンテナについては、「[Amazon ECS タスクの IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)」または「[Amazon EKS ノードの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)」を参照してください。 |
| SSH キー | Linux EC2 インスタンスへの手動または自動プロセスの一環としてのログインに使用されるセキュアシェルプライベートキー | 置き換え: [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) または [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) を使用して、IAM ロールを使用して EC2 インスタンスへのプログラムおよび人間によるアクセスを提供します。 |
| アプリケーションとデータベースの認証情報 | パスワード – プレーンテキスト文字列 | ローテーション: 認証情報を [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) に保存し、可能であれば自動ローテーションを確立します。 |
| Amazon RDS と Aurora 管理データベースの認証情報 | パスワード – プレーンテキスト文字列 | 置き換え: [Secrets Manager と Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) または [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html) の統合を使用します。さらに、一部の RDS データベースタイプでは、一部のユースケースでパスワードの代わりに IAM ロールを使用できます (詳細については、[「IAM データベース認証](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)」を参照してください)。 |
| OAuth トークン | シークレットトークン – プレーンテキスト文字列 | ローテーション: トークンを [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) に保存し、自動ローテーションを設定します。 |
| API トークンとキー | シークレットトークン – プレーンテキスト文字列 | ローテーション: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) に保存し、可能であれば自動ローテーションを確立します。 |
一般的なアンチパターンは、ソースコード、設定ファイル、またはモバイルアプリ内に IAM アクセスキーを埋め込むことです。AWS サービスと通信するために IAM アクセスキーが必要な場合は、[一時的な (短期的な) セキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)を使用します。これらの短期認証情報は、[EC2 インスタンスの IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)、Lambda 関数[の実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)、モバイルユーザーアクセス用の [Cognito IAM ロール](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html)、および IoT デバイス用の [IoT Core ポリシー](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html)を通じて提供できます。サードパーティーとやり取りする場合は、IAM ユーザーをサーバーして、サードパーティーにそのユーザー向けのシークレットアクセスキーを送信するよりも、アカウントのリソースへの必要なアクセス権を持つ [IAM ロールにアクセスを委譲する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)方法を優先します。
ワークロードに、他のサービスやリソースとの相互運用に必要なシークレットの保管が必要となるケースが多数あります。[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) は、これらの認証情報の安全な管理、さらには API トークン、パスワード、およびその他の認証情報の保管、使用、ローテーション専用です。
AWS Secrets Manager には、機密認証情報の安全なストレージと処理を確保するための 5 つの主要な機能があります。[保管時の暗号化](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)、[転送中の暗号化](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html)、[包括的な監査](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)、[きめ細かなアクセスコントロール](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html)、および[拡張可能な認証情報ローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)です。AWS パートナーによるその他のシークレット管理サービス、または類似の機能や保証を提供するローカルで開発されたソリューションも使用できます。
シークレットを取得するときに、Secrets Manager のクライアント側のキャッシュコンポーネントを使用して、将来使用するためにキャッシュすることができます。キャッシュされたシークレットの取得は、Secrets Manager からの取得よりも高速です。さらに、Secrets Manager API を呼び出すにはコストがかかるため、キャッシュを使用するとコストを削減できます。シークレットを取得するすべての方法については、「[シークレットの取得](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)」を参照してください。
**注記**
一部の言語では、クライアント側のキャッシュ用に独自のインメモリ暗号化を実装する必要がある場合があります。
### 実装手順
1. [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/) などの自動ツールを使用して、ハードコードされた認証情報を含むコードパスを特定します。
1. Amazon CodeGuru を使って、コードリポジトリをスキャンします。レビューが完了したら、CodeGuru で Type=Secrets をフィルタリングして、問題のあるコード行を見つけます。
1. 削除または置換できる認証情報を特定します。
1. 既に不要な認証情報を特定して、削除用にマークします。
1. ソースコードに埋め込まれた AWS シークレットキーについては、必要なリソースに関連付けられた IAM ロールと置換します。ワークロードの一部が AWS 外であるにもかかわらず AWS リソースにアクセスする IAM 認証情報が必要な場合、[IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) または [AWS Systems Manager ハイブリッドアクティベーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)を検討してください。
1. ローテーション戦略を使用すべきその他のサードパーティー、存続期間の長いシークレットについては、Secrets Manager をコードに統合して、ランタイムにサードパーティーのシークレットを取得します。
1. CodeGuru コンソールは、検出された認証情報を使って [Secrets Manager にシークレットを作成](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)できます。
1. Secrets Manager から取得したシークレットをアプリケーションコードに統合します。
1. サーバーレス Lambda 関数では、言語に依存しない [Lambda 拡張機能](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)を使用できます。
1. EC2 インスタンスまたはコンテナに対しては、AWS が複数のよく使用されるプログラミング言語で、[Secrets Manager からシークレットを取得するためのクライアント側コード](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)の例を提供しています。
1. 定期的にコードベースをレビューして再スキャンすることで、コードに新たなシークレットが追加されていないことを確認します。
1. [git-secrets](https://github.com/awslabs/git-secrets) などのツールを使って、ソースコードリポジトリに新しいシークレットがコミットされるのを防止することを検討してください。
1. 予想外の使用、不適切なシークレットへのアクセス、またはシークレットの削除試行がないかどうか、[Secrets Manager アクティビティ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)をモニタリングします。
1. 認証情報に対する人的曝露を減少させます。この目的に特化した IAM ロールに対する認証情報を読み出し、書き込み、および変更するためのアクセスを制限し、一部の運用ユーザーにのみ、その役割を担うためのアクセスを提供します。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP02 一時的な認証情報を使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP05 定期的に認証情報を監査およびローテーションする](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)
**関連ドキュメント:**
+ [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)
+ [Amazon CodeGuru Introduces Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)
+ [AWS Secrets Manager での AWS Key Management Service の使用方法](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)
+ [Secret encryption and decryption in Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ [Secrets Manager ブログエントリ](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/)
+ [Amazon RDS と AWS Secrets Manager の統合を発表](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/)
**関連動画:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4)
+ [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs)
+ [Securing Secrets for Hybrid Workloads Using AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8)
**関連するワークショップ:**
+ [Store, retrieve, and manage sensitive credentials in AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US)
+ [AWS Systems Manager のハイブリッドアクティベーション](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html)
# SEC02-BP04 一元化された ID プロバイダーを利用する
ワークフォースユーザー ID (従業員と契約社員) の場合、ID を一元管理できる ID プロバイダーを利用します。一つの場所から権限の作成、割り当て、管理、取り消し、監査を行うため、複数のアプリケーションおよびシステムにまたがる権限を効率的に管理できます。
**期待される成果:** 一元化された ID プロバイダーを使用して、ワークフォースユーザー、認証ポリシー (多要素認証 (MFA) の要求など)、システムやアプリケーションへの承認 (ユーザーのグループメンバーシップや属性に基づくアクセスの割り当てなど) を一元管理します。ワークフォースユーザーは一元化された ID プロバイダーにサインインし、内部アプリケーションと外部アプリケーションにフェデレーション (シングルサインオン) します。これにより、ユーザーは複数の認証情報を覚えておく必要がなくなります。ID プロバイダーは人事 (HR) システムと統合されているため、人事上の変更は ID プロバイダーと自動的に同期されます。例えば、誰かが組織を離れた場合、フェデレーションされたアプリケーションやシステム (AWS を含む) へのアクセスを自動的に取り消すことができます。ID プロバイダーで詳細な監査ログを有効にし、これらのログでユーザーの異常な行動がないか監視します。
**一般的なアンチパターン:**
+ フェデレーションとシングルサインオンを使用しない。ワークフォースユーザーが、複数のアプリケーションやシステムで個別のユーザーアカウントと認証情報を作成する。
+ ID プロバイダーを人事システムに統合するなど、ワークフォースユーザーのアイデンティティのライフサイクルを自動化していない。ユーザーが組織を離れたり、役割を変更したりした場合に、複数のアプリケーションやシステムのレコードを手動のプロセスで削除または更新する。
**このベストプラクティスを活用するメリット:** 一元化された ID プロバイダーを使用することで、ワークフォースユーザーのアイデンティティとポリシーを 1 か所で管理でき、ユーザーやグループにアプリケーションへのアクセス権を割り当てたり、ユーザーのサインインアクティビティを監視したりできます。人事 (HR) システムと統合することで、ユーザーの役割が変更された場合は、これらの変更が ID プロバイダーと同期され、ユーザーに割り当てられたアプリケーションと権限が自動的に更新されます。ユーザーが組織を離れると、そのユーザーのアイデンティティは ID プロバイダーで自動的に無効になり、フェデレーションアプリケーションおよびシステムへのアクセス権が取り消されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
**AWS にアクセスするワークフォースユーザー向けのガイダンス**組織内の従業員や契約社員などのワークフォースユーザーは、AWS マネジメントコンソール または AWS Command Line Interface (AWS CLI) を使って職務を遂行するため、AWS へのアクセス権を必要とする場合があります。一元化された ID プロバイダーから 2 つのレベルで AWS にフェデレーションすることで、ワークフォースユーザーに AWS へのアクセス権を付与できます。1 つは各 AWS アカウントへの直接フェデレーション、もう 1 つは [AWS 組織](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)内の複数のアカウントへのフェデレーションです。
ワークフォースユーザーをそれぞれの AWS アカウントと直接フェデレーションするには、一元化された ID プロバイダーを使用して、そのアカウントの [AWS Identity and Access Management](https://aws.amazon.com/iam/) にフェデレーションできます。IAM の柔軟性により、[SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) または [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) という別々の ID プロバイダーを各 AWS アカウントで有効にして、アクセスコントロールにはフェデレーションユーザー属性を使用することができます。ワークフォースユーザーはウェブブラウザを使用し、認証情報 (パスワードや MFA トークンコードなど) を入力して ID プロバイダーにサインインします。ID プロバイダーは、AWS マネジメントコンソールのサインイン URL に送信される SAML アサーションをユーザーのブラウザに発行して、[IAM ロールを引き受けることで、ユーザーが AWS マネジメントコンソールにシングルサインオンできるようにします](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)。ユーザーは、[ID プロバイダーからの SAML アサーションを使用して、IAM ロールを引き受ける](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)ことで、[AWS CLI](https://aws.amazon.com/cli/) や [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) の [AWS SDK](https://aws.amazon.com/developer/tools/) で使用する 一時的な AWS API 認証情報を 取得することもできます。
ワークフォースユーザーを AWS Organization の複数のアカウントにフェデレーションするには、[https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) を使用して、AWS アカウント やアプリケーションへのワークフォースユーザーのアクセスを一元管理できます。組織のアイデンティティセンターを有効にし、ID ソースを設定します。IAM Identity Center は、ユーザーやグループの管理に使用できるデフォルトの ID ソースディレクトリを提供します。または、SAML 2.0 を使用して[https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)し、 SCIM を使用してユーザーとグループを[自動的にプロビジョニング](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)するか、または [Directory Service](https://aws.amazon.com/directoryservice/) を使用して [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html)することで、外部 ID ソースを選択することもできます。ID ソースを設定したら、[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)で最小権限ポリシーを定義して、ユーザーとグループに AWS アカウントへのアクセス権を割り当てることができます。ワークフォースユーザーは一元化された ID プロバイダーを通じて認証を行い、[AWS アクセスポータル](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html)にサインインして、自分に割り当てられた AWS アカウントとクラウドアプリケーションにシングルサインオンします。ユーザーは [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) を設定して、アイデンティティセンターで認証を行い、AWS CLI コマンドを実行するための認証情報を取得できます アイデンティティセンターでは、AWS アプリケーション ([Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) や [AWS IoT Sitewise Monitor ポータル](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html)など) へのアクセスにシングルサインオンも使用できます。
前述のガイダンスに従うと、ワークフォースユーザーは AWS でワークロードを管理する際、通常の操作で IAM ユーザーおよびグループを使用する必要がなくなります。管理するのではなく、ユーザーとグループは AWS の外部で管理され、ユーザーはフェデレーション ID として AWS リソースにアクセスできます。フェデレーション ID では、一元化された ID プロバイダーで定義されたグループを使用します。AWS アカウントで不要になった IAM グループ、IAM ユーザー、および永続的なユーザー認証情報 (パスワードとアクセスキー) を特定して削除する必要があります。また、[IAM 認証情報レポート](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)を使用して、[未使用の認証情報を検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html)し、[該当する IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html)や [IAM グループを削除できます。](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html)組織に[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を適用して、新しい IAM ユーザーやグループが作成されないようにし、フェデレーション ID を介した AWS へのアクセスを強制できます。
**注記**
SCIM アクセストークンのローテーションの処理については、[自動プロビジョニング](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)のドキュメントに記載されているようにユーザーが行う必要があります。さらに、ID フェデレーションをサポートする証明書のローテーションは、ユーザーが行う必要があります。
**アプリケーションのユーザー向けガイダンス**モバイルアプリなどのアプリケーションのユーザーの ID を管理するには、一元化された ID プロバイダーとして *[Amazon Cognito](https://aws.amazon.com/cognito/)* を使用できます。Amazon Cognito は、ウェブおよびモバイルアプリの認証、認可、およびユーザー管理を可能にします。Amazon Cognito は数百万人のユーザーにスケール可能な ID ストアを備え、ソーシャル ID フェデレーションとエンタープライズ ID フェデレーションをサポートし、ユーザーとビジネスの保護に役立つ高度なセキュリティ機能を提供します。カスタムのウェブまたはモバイルアプリケーションを Amazon Cognito と統合すると、アプリケーションへのユーザー認証とアクセスコントロールを数分で追加できます。SAML や Open ID Connect (OIDC) などのオープン ID 標準に基づいて構築された Amazon Cognito は、さまざまなコンプライアンス規制に対応し、フロントエンドおよびバックエンドの開発リソースと統合します。
### 実装手順
**ワークフォースユーザーの AWS へのアクセス手順**
+ 以下のいずれかの方法を使用し、一元化された ID プロバイダーを使用して、ワークフォースユーザーを AWS にフェデレーションします。
+ IAM Identity Center を使用し、ID プロバイダーとフェデレーションすることで、AWS 組織内の複数の AWS アカウントへのシングルサインオンを有効にします。
+ IAM を使用して、ID プロバイダーを各 AWS アカウントに直接接続し、フェデレーションによるきめ細かいアクセスを可能にします。
+ フェデレーション ID で置き換えられた IAM ユーザーとグループを特定して削除します。
**アプリケーションのユーザー向けの手順**
+ アプリケーション用の一元化された ID プロバイダーとして Amazon Cognito を使用します。
+ OpenID Connect と OAuth を使用して、カスタムアプリケーションを Amazon Cognito と統合します。認証のための Amazon Cognito など、さまざまな AWS サービスと統合するためのシンプルなインターフェイスを提供する Amplify ライブラリを使用して、カスタムアプリケーションを開発できます。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP06 ユーザーグループと属性を採用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html)
+ [SEC03-BP02 最小特権のアクセスを付与する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [SEC03-BP06 ライフサイクルに基づいてアクセスを管理する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
**関連ドキュメント:**
+ [AWS での ID フェデレーション](https://aws.amazon.com/identity/federation/)
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [AWS Identity and Access Managementベストプラクティス](https://aws.amazon.com/iam/resources/best-practices/)
+ [Getting started with IAM Identity Center delegated administration](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/)
+ [How to use customer managed policies in IAM Identity Center for advanced use cases](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/)
+ [AWS CLI v2: IAM Identity Center credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html)
**関連動画:**
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc)
**関連する例:**
+ [ワークショップ: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US)
**関連ツール**:
+ [AWS セキュリティコンピテンシーパートナー: ID およびアクセスの管理](https://aws.amazon.com/security/partner-solutions/)
+ [saml2aws](https://github.com/Versent/saml2aws)
# SEC02-BP05 定期的に認証情報を監査およびローテーションする
認証情報を定期的に監査およびローテーションして、リソースへのアクセスに認証情報を使用できる期間を制限します。長期的認証情報を使用すると多くのリスクが生じますが、これらのリスクは長期的認証情報を定期的にローテーションすることで軽減できます。
**期待される成果:** 長期的認証情報の使用に関連するリスクを軽減するために、認証情報のローテーションを実装します。認証情報ローテーションポリシーの不遵守を定期的に監査して、是正します。
**一般的なアンチパターン:**
+ 認証情報の使用を監査しない。
+ 必要がないのに長期的認証情報を使用する。
+ 長期的認証情報を使用しているが、定期的にローテーションしない。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
一時的な認証情報に頼れず、長期的認証情報が必要な場合は、認証情報を監査して、[多要素認証](https://aws.amazon.com/iam/features/mfa/) (MFA) などの定義された管理方法が実施され、定期的にローテーションされて、アクセスレベルが適切であることを確認する必要があります。
正しい管理方法が実施されていることを確認するには、定期的な検証、できれば自動化ツールによる検証が必要です。人的 ID の場合は、パスワードを定期的に変更し、一時的な認証情報を優先してアクセスキーを廃止するように、ユーザーに要求する必要があります。AWS Identity and Access Management (IAM) ユーザーから一元化された ID に移行すると、[認証情報レポートを生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)してユーザーを監査できます。
ID プロバイダーで MFA を実施およびモニタリングすることもお勧めします。[AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) を設定するか、[AWS Security Hub CSPM セキュリティ標準](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3)を使用して、ユーザーが MFA を設定しているかどうかをモニタリングできます。[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用して、マシン ID の一時的な認証情報を付与することを検討してください。IAM ロールと一時的な認証情報を使用できないときは、アクセスキーの監査とローテーションの頻度を高めることが重要です。
### 実装手順
+ **認証情報を定期的に監査する:** ID プロバイダーと IAM で設定されている ID を監査することで、認証された ID のみがワークロードにアクセスできるようになります。これらの ID は、IAM ユーザー、AWS IAM アイデンティティセンターユーザー、Active Directory ユーザー、またはさまざまなアップストリーム ID プロバイダーのユーザーを含みますが、これらに限定されるものではありません。例えば、組織を離れた人を削除したり、不要になったクロスアカウントのロールを削除したりします。IAM エンティティがアクセスするサービスへのアクセス許可を定期的に監査するプロセスを用意します。これにより、未使用のアクセス許可を削除するために変更する必要があるポリシーを特定できます。認証情報レポートと [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) を使用して、IAM 認証情報とアクセス許可を監査します。[Amazon CloudWatch を使用して、AWS 環境内で呼び出される特定の API コールのアラームを設定できます](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html)。[Amazon GuardDuty は、IAM 認証情報へのアクセスが過度に許可されているか、意図しないアクセスを示している可能性のある、予期しないアクティビティを警告することもできます](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html)。
+ **認証情報を定期的にローテーションする:** 一時的な認証情報を使用できない場合は、IAM アクセスキーを定期的に (最大 90 日ごとに) ローテーションします。知らない間にアクセスキーが開示された場合でも、ローテーションを行うことで、該当する認証情報を使用してリソースにアクセスされる期間を制限できます。アクセスキーのローテーションの詳細については、IAM ユーザーの「[アクセスキーのローテーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)」を参照してください。
+ **IAM アクセス許可を確認する:** AWS アカウントのセキュリティを改善するには、各 IAM ポリシーを定期的に確認してモニタリングします。ポリシーが最小特権の原則に従っていることを確認します。
+ **IAM リソースの作成と更新の自動化を検討する:** [IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)は、ロールやポリシーの管理など、多くの IAM タスクを自動化します。または、AWS CloudFormation を使用することで、テンプレートを検証してバージョンを管理できるため、ロールやポリシーを含む IAM リソースのデプロイを自動化して、人為的ミスが生じる可能性を軽減できます。
+ **IAM Roles Anywhere を使用してマシン ID の IAM ユーザーを置き換える:** [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用すると、オンプレミスサーバーなど、従来は使用できなかった領域でロールを使用できます。IAM Roles Anywhere は、信頼された [X.509 証明書を使用して](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification) AWS を認証し、一時的な認証情報を受け取ります。IAM Roles Anywhere を使用することで、長期的認証情報がオンプレミス環境に保存されなくなるため、これらの認証情報をローテーションする必要がなくなります。X.509 証明書の有効期限が近づいたら、モニタリングとローテーションが必要となることに注意してください。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP02 一時的な認証情報を使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP03 シークレットを安全に保存して使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.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_credentials_getting-report.html)
**関連動画:**
+ [シークレットを大規模に管理、取得、変更するためのベストプラクティス](https://youtu.be/qoxxRlwJKZ4)
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 ユーザーグループと属性を採用する
ユーザーグループと属性に従ってアクセス許可を定義すると、ポリシーの数と複雑度が軽減され、最小特権の原則を簡単に遵守できます。ユーザーグループを使用して、多数のユーザーのアクセス許可をそれぞれが組織内で果たす職務に基づいて 1 か所で管理できます。部門、プロジェクト、または場所などの属性は、ユーザーが同じような職務を果たすが、対象となるリソースのサブセットが異なる場合に、アクセス許可の範囲をさらに限定することができます。
**期待される成果:** 権限の変更を、職務に基づき、その職務を実行するすべてのユーザーに適用できます。グループのメンバーシップと属性によってユーザーのアクセス許可が管理されるため、個々のユーザーレベルでアクセス許可を管理する必要がなくなります。ID プロバイダー (IdP) で定義したグループと属性が、AWS 環境に自動的に反映されます。
**一般的なアンチパターン:**
+ 個々のユーザーのアクセス許可を管理し、複数のユーザーで重複作業をしている。
+ グループの定義が大まか過ぎるため、アクセス許可の付与範囲が広過ぎる。
+ グループの定義が細か過ぎるため、メンバーシップに関する重複や混乱が生じている。
+ 代わりに属性を使用できる場面でグループを使用し、リソースの複数のサブセットに対してグループが持つアクセス許可が重複している。
+ 標準に準拠した ID プロバイダーの AWS 環境への統合によるグループ、属性、メンバーシップの管理を行っていない。
+ AWS IAM アイデンティティセンターセッションを使用する際のロールチェーンの使用
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS アクセス許可は、ユーザー、グループ、ロール、リソースなどのプリンシパルに関連付けられている、*ポリシー*と呼ばれるドキュメントで定義されます。職務、ワークロード、および SDLC 環境に基づいてアクセス許可の割り当て (グループ、アクセス許可、アカウント) を整理することにより、アクセス許可管理をスケールすることができます。従業員に対しては、アクセス対象のリソースではなく、ユーザーが組織で果たす職務に基づいてグループを定義できます。例えば、WebAppDeveloper グループには、開発アカウント内で Amazon CloudFront などのサービスを設定するためのポリシーがアタッチされている場合があります。`AutomationDeveloper` グループには、`WebAppDeveloper` グループと重複するアクセス許可が付与されている場合があります。これらの共通のアクセス許可は、両方の職務のユーザーを `CloudFrontAccess` グループに所属させるのではなく、別々のポリシーで取得して両方のグループに関連付けることができます。
グループに加え、属性を使用してアクセスの範囲をさらに絞り込むことができます。例えば、`WebAppDeveloper` グループ内のユーザーに対して、プロジェクト固有のリソースへのアクセス範囲を限定するためのプロジェクト属性を設定できます。この手法を使用すれば、異なるプロジェクトで作業するアプリケーション開発者に対して、それ以外の点ではアクセス許可が同じ場合、別々のグループを用意する必要がなくなります。アクセス許可ポリシーで属性を参照する方法は、そのソースがフェデレーションプロトコル (SAML、OIDC、SCIM など) の一部として定義されているか、カスタム SAML アサーションとして定義されているか、IAM Identity Center 内で設定されているかに応じて異なります。
### 実装手順
1. グループと属性を定義する場所を確保します。
1. [SEC02-BP04 一元化された ID プロバイダーを利用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)のガイダンスに従って、ID プロバイダー内、IAM アイデンティティセンター内、または特定のアカウント内の IAM ユーザーグループを使用し、グループと属性を定義する必要があるかどうかを判断します。
1. グループの定義:
1. 必要な職務とアクセス範囲に基づいてグループを決定します。グループを効果的に整理するために、階層構造や命名規則を使用することを検討してください。
1. IAM Identity Center 内で定義する場合は、グループを作成し、アクセス許可セットを使用して、目的とするレベルのアクセス許可を関連付けます。
1. 外部の ID プロバイダー内で定義する場合は、プロバイダーが SCIM プロトコルをサポートしているかどうかを確認し、IAM Identity Center 内で自動プロビジョニングを有効にすることを検討してください。この機能は、プロバイダーと IAM Identity Center との間で、メンバーシップの作成、およびグループの削除を同期します。
1. 属性の定義:
1. 外部の ID プロバイダーを使用する場合、SCIM プロトコルと SAML 2.0 プロトコルは両方とも一部の属性をデフォルトで提供します。追加の属性は、`https://aws.amazon.com/SAML/Attributes/PrincipalTag` 属性名と SAML アサーションを使用して定義し、渡すことができます。カスタム属性の定義と設定に関するガイダンスについては、ID プロバイダーのドキュメントを参照してください。
1. IAM アイデンティティセンター内でロールを定義する場合は、属性ベースのアクセス制御 (ABAC) 機能を有効にし、必要に応じて属性を定義します。組織の構造またはリソースのタグ付け方法に沿った属性を検討してください。
IAM アイデンティティセンターで割り当てられた IAM ロールから IAM ロールチェーンが必要な場合は、`source-identity` や `principal-tags` などの値は反映されません。詳細については、「[アクセスコントロールのための属性の有効化と設定](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)」を参照してください。
1. グループと属性に基づいて、アクセス許可の範囲を設定します。
1. プリンシパルの属性と、アクセス対象のリソースの属性を比較する条件をアクセス許可ポリシーに含めることを検討してください。例えば、`PrincipalTag` 条件キーの値が同じ名前の `ResourceTag` キーの値と一致する場合にのみ、リソースへのアクセスを許可する条件を定義できます。
1. ABAC ポリシーを定義する場合は、[ABAC 認可](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)のベストプラクティスと例のガイダンスに従ってください。
1. 組織のニーズの変化に応じてグループと属性の構造を定期的に確認し、更新して、最適な権限管理を確保します。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP02 最小特権のアクセスを付与する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [COST02-BP04 グループとロールを実装する](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html)
**関連ドキュメント:**
+ [IAM ベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [IAM Identity Center で ID を管理する](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [AWS の ABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [IAM Identity Center - ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)
+ [ABAC ポリシーの例](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html)
**関連動画:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC 3. 人とマシンのアクセス許可をどのように管理するのですか。
アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。権限を使用すると、誰が何に、どのような条件でアクセスできるかを制御できます。特定のユーザー 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-BP09 サードパーティーとリソースを安全に共有する](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 アクセス要件を定義する
ワークロードの各コンポーネントやリソースには、管理者、エンドユーザー、またはその他のコンポーネントによるアクセスが必要です。各コンポーネントへのアクセス権のある人とマシンを明確に定義し、適切な ID のタイプと、認証および認可の方法を選択します。
**一般的なアンチパターン:**
+ シークレットをハードコーディングする、またはアプリケーション内に格納する
+ 各ユーザーにカスタムのアクセス許可を付与する
+ 永続的な認証情報を使用する
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードの各コンポーネントやリソースには、管理者、エンドユーザー、またはその他のコンポーネントによるアクセスが必要です。各コンポーネントへのアクセス権のある人とマシンを明確に定義し、適切な ID のタイプと、認証および認可の方法を選択します。
組織内の AWS アカウントへの定期的なアクセスは、[フェデレーションアクセス](https://aws.amazon.com/identity/federation/)か一元化された ID プロバイダーを使用して提供する必要があります。また、アイデンティティ管理を一元化し、AWS へのアクセスを従業員のアクセスライフサイクルに統合するための確立されたプラクティスを整備する必要があります。例えば、従業員がアクセスレベルの異なる職種に異動するときは、そのグループメンバーシップも新しいアクセス要件を反映するように変更される必要があります。
非人間アイデンティティのアクセス要件を定義するときは、どのアプリケーションとコンポーネントがアクセスを必要としているか、またアクセス許可をどのように付与するかを決定します。推奨されるアプローチは、最小特権アクセスモデルで構築されたロールを使用する方法です。[AWSマネージドポリシー](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)は、最も一般的なユースケースをカバーする、事前定義済みの IAM ポリシーを提供します。
[AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) や [AWS Systems Manager Parameter Store ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)などの AWS のサービスは、アプリケーションまたはワークロードからシークレットを安全に分離するのに役立ちます。Secrets Manager では、認証情報の自動ローテーションを確立できます。Secrets Manager でパラメータの作成時に指定した一意の名前を使用することで、スクリプト、コマンド、SSM ドキュメント、設定、自動化ワークフロー内のパラメータを参照できます。
[AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用すると、AWS の外部で実行されるワークロード [IAM における一時的セキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)を取得できます。ワークロードでは、AWS アプリケーションが 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)を使用できます。
可能な場合は、長期の静的な認証情報よりも、短期の一時的な認証情報を優先します。プログラムによるアクセスと長期的認証情報を持つユーザーが必要なシナリオでは、[アクセスキーが最後に使用した情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)を使用して、アクセスキーをローテーションおよび削除します。
AWS マネジメントコンソール の外部で AWS を操作するには、ユーザーはプログラムによるアクセスが必要です。プログラマチックアクセス権を付与する方法は、AWS にアクセスしているユーザーのタイプによって異なります。
ユーザーにプログラマチックアクセス権を付与するには、以下のいずれかのオプションを選択します。
****
| プログラマチックアクセス権を必要とするユーザー | 目的 | 方法 |
| --- | --- | --- |
| IAM | (推奨) 一時的な認証情報としてコンソール認証情報を使用して、AWS CLI、AWS SDK、または AWS API へのプログラマチックリクエストに署名します。 | 使用するインターフェイスの指示に従ってください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sec_permissions_define.html) |
| ワークフォースアイデンティティ (IAM アイデンティティセンターで管理されているユーザー) | 一時的な認証情報を使用して、AWS CLI、AWS SDK、または AWS API へのプログラマチックリクエストに署名します。 | 使用するインターフェイスの指示に従ってください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sec_permissions_define.html) |
| IAM | 一時的な認証情報を使用して、AWS CLI、AWS SDK、または AWS API へのプログラムによるリクエストに署名します。 | IAM ユーザーガイドの「[AWS リソースでの一時的な認証情報の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)」の指示に従ってください。 |
| IAM | (非推奨)長期的な認証情報を使用して、AWS CLI、AWS SDK、または AWS API へのプログラムによるリクエストに署名します。 | 使用するインターフェイスの指示に従ってください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sec_permissions_define.html) |
## リソース
**関連ドキュメント:**
+ [属性ベースのアクセスコントロール (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](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [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](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](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](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Streamlining identity and access management for innovation](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 最小特権のアクセスを付与します
ユーザーが特定の条件下で特定のリソースに対する特定のアクションを実行するために、必要なアクセス許可のみを付与します。グループと ID 属性を使用して、個々のユーザーのアクセス許可を定義するのではなく、規模に応じてアクセス許可を動的に設定します。例えば、デベロッパーのグループに、プロジェクトのリソースのみを管理するためのアクセスを許可することができます。これにより、デベロッパーがプロジェクトを離れると、基盤となるアクセスポリシーに変更を加えることなく、そのデベロッパーのアクセスは自動的に取り消されます。
**期待される成果:** ユーザーには、それぞれの職務に必要な最低限のアクセス許可のみが付与されます。デベロッパーを本番環境から分離するには、別個の AWS アカウント を使用します。デベロッパーが特定のタスクの本番環境にアクセスする必要がある場合、それらのタスクの期間中のみ、管理された制限付きのアクセス許可が付与されます。本番環境へのアクセスは、必要な作業が完了するとすぐに取り消されます。アクセス許可の定期的な見直しを行い、ユーザーがロールを変更したり組織を離れたりするなど、不要になったらすぐに取り消します。管理者権限を信頼できる小さなグループに限定することにより、リスクを最小限に抑えます。マシンまたはシステムのアカウントには、意図したタスクの実行に必要な最小限のアクセス許可のみを付与します。
**一般的なアンチパターン:**
+ デフォルトで、ユーザーに管理者のアクセス許可を付与する。
+ 通常のアクティビティには、ルートユーザーアカウントを使用する。
+ 適切な範囲を指定せずに、過度に許容されたポリシーを作成する。
+ アクセス許可のレビューは頻繁に行われないため、アクセス許可のクリープが発生する。
+ 環境の分離やアクセス許可の管理には、属性ベースのアクセスコントロールのみに依存している。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
[最小特権](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)の原則では、特定のタスクを実行するために必要な、最小限のアクションの実行のみを ID に許可する必要があると規定されています。これは、ユーザビリティ、効率性、セキュリティのバランスを取ります。この原則の下に運用すると、意図しないアクセスを制限し、誰がどのリソースにアクセスできるかを追跡するのに役立ちます。デフォルトでは、IAM ユーザーやロールにアクセス許可はありません。ルートユーザーにはデフォルトでフルアクセスがありますが、厳密に制御、モニタリングされ、[ルートアクセスを必要とするタスク](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)にのみ使用する必要があります。
IAM ポリシーは、IAM ロールまたは特定のリソースに明示的にアクセス許可を付与するために使用します。例えば、アイデンティティベースのポリシーは IAM グループにアタッチでき、S3 バケットはリソースベースのポリシーで制御できます。
IAM ポリシーの作成時に、サービスアクション、リソース、および AWS がアクセスを許可または拒否するために true が必須な条件を指定できます。AWS は、アクセスの範囲を絞り込むのに役立つさまざまな条件をサポートしています。例えば、PrincipalOrgID [条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を使用すると、リクエスタが AWS Organization の一部でない場合にアクションを拒否できます。
また、CalledVia 条件キーを使用して、AWS Lambda 関数を作成する AWS CloudFormation など、AWS サービスがユーザーに代わって行うリクエストを制御できます。異なるポリシータイプを層にして深層防御を確立し、ユーザーの全体的なアクセス許可を制限できます。どのアクセス許可がどのような条件の下で付与できるかも制限できます。例えば、ワークロードチームに対して、構築するシステムに独自の IAM ポリシーを作成することを許可できますが、その場合、付与できるアクセス許可の上限を制限する[アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)を適用する必要があります。
### 実装手順
+ **最小特権ポリシーを実装する**: IAM グループおよびロールに最小特権のアクセスポリシーを割り当てて、定義したユーザーのロールまたは機能を反映させます。
+ **別個の AWS アカウント を使用して開発環境と本番環境を分離する**: 開発環境と本番環境には別個の AWS アカウント を使用し、[サービスコントロールポリシー ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)、リソースポリシー、アイデンティティポリシーを使用して、開発環境と本番環境間のアクセスを制御します。
+ **API の使用状況に基づくポリシー**: 必要なアクセス許可を決定する 1 つの方法は、AWS CloudTrail ログを確認することです。このレビューを使用して、ユーザーが AWS 内で実際に実行するアクションに合わせて、カスタマイズしたアクセス許可を作成できます。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) は、アクセスアクティビティに基づいて IAM ポリシーを[自動生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)できます。組織またはアカウントレベルで IAM Access Advisor を使用し、[特定のポリシーの最終アクセス情報を追跡](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)できます。
+ **[ジョブ機能に AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)の使用を検討する**: きめ細かいアクセス許可ポリシーの作成を開始する場合は、請求、データベース管理者、データサイエンティストなどの一般的なジョブのロールに AWS マネージドポリシーを使用することを推奨します。これらのポリシーは、最小特権ポリシーの実装方法を決定する際に、ユーザーの持つアクセスを絞り込むことができます。
+ **不要なアクセス許可を削除する**: 未使用の IAM エンティティ、認証情報、アクセス許可を検出して削除し、最小特権の原則を実現します。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) を使用すると、外部アクセスと未使用のアクセスを識別でき、[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)によって、アクセス許可ポリシーのファインチューニングを行いやすくなります。
+ **ユーザーの本番環境へのアクセスが制限されていることを確認する:** ユーザーは、有効なユースケースを持つ本番環境にのみアクセスする必要があります。ユーザーが、本番稼働アクセスが必要な特定のタスクを実行した後は、アクセスを取り消す必要があります。本番環境へのアクセスを制限することは、本番に影響する意図しないイベントを回避するのに役立ち、意図しないアクセスの影響範囲を狭めます。
+ **アクセス許可の境界を考慮する**: [アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する、マネージドポリシーを使用するための機能です。エンティティのアクセス許可の境界により、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。
+ **属性ベースのアクセス制御とリソースタグを使用したアクセスの絞り込み** [サポートされている場合、リソースタグを使用した属性ベースのアクセス制御 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) を使用して、アクセス許可を絞り込むことができます。ABAC モデルを使用して、プリンシパルタグとリソースタグを比較し、定義したカスタムディメンションに基づいてアクセスを絞り込むことができます。このアプローチにより、組織内のアクセス許可ポリシーを簡素化し、その数を削減できます。
+ ABAC は、プリンシパルとリソースの両方が AWS Organization によって所有されている場合にのみ、アクセス制御に使用することを推奨します。外部関係者は、自分のプリンシパルとリソースに対して、組織と同じタグ名と値を使用できます。外部パーティのプリンシパルやリソースへのアクセス許可を付与する際に、これらの名前と値のペアのみに依存していると、意図しないアクセス許可を付与してしまう可能性があります。
+ **AWS Organizations のサービスコントロールポリシーを使用する:** [サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)は、組織のメンバーアカウントで利用できる最大のアクセス許可を一元管理します。重要なのは、サービスコントロールポリシーを使用すると、メンバーアカウントでルートユーザーのアクセス許可を制限できることです。AWS Organizations を強化する規範的マネージドコントロールを提供する、AWS Control Tower の使用も検討してください。Control Tower 内で独自のコントロールを定義できます。
+ **組織のユーザーライフサイクルポリシーを確立する:** ユーザーライフサイクルポリシーは、ユーザーが AWS にオンボーディングされたとき、ジョブロールまたはスコープを変更したとき、または AWS へのアクセスが不要になったときに実行するタスクを定義します。ユーザーのライフサイクルの各段階でアクセス許可のレビューを行い、アクセス許可が適切に制限されていることを検証して、アクセス許可のクリープを回避する必要があります。
+ **アクセス許可を見直して不要なアクセス許可を削除する:** ユーザーアクセスを定期的に見直して、ユーザーに過剰なアクセス許可がないことを確認する必要があります。[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) および IAM Access Analyzer は、ユーザーのアクセス許可を監査する際に役立ちます。
+ **ジョブロールマトリックスを確立する:** ジョブロールマトリックスは、AWS フットプリント内に必要なさまざまなロールとアクセスレベルを視覚化します。ジョブロールマトリックスにより、組織内でのユーザーの責任に基づいてアクセス許可を定義し、分離できます。個々のユーザーまたはロールにアクセス許可を直接適用するのではなく、グループを使用します。
## リソース
**関連ドキュメント:**
+ [最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [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/)
+ [Delegate permission management to developers by using IAM permissions boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [最終アクセス情報を使用した 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 ポリシーシミュレーターを使用した 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)
+ [ゼロトラストアーキテクチャ: AWS の視点](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [How to implement the principle of least privilege with CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [属性ベースのアクセスコントロール (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [ユーザーアクティビティを表示してポリシーの範囲を狭める](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)
+ [Use Tagging to Organize Your Environment and Drive Accountability](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [AWS タグ付け戦略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [AWS リソースのタグ付け](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**関連動画:**
+ [Next-generation permissions management](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: An AWS perspective](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 緊急アクセスのプロセスを確立する
一元化された ID プロバイダーで万一問題が発生した場合に備え、ワークロードへの緊急アクセスを許可するプロセスを作成します。
緊急事態につながる可能性のあるさまざまな障害モードに対応するプロセスを設計する必要があります。例えば、通常の状況では、従業員ユーザーは一元化された ID プロバイダー ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) を使用してクラウドにフェデレーションし、ワークロードを管理します。ただし、一元化された ID プロバイダーに障害が発生した場合や、クラウドのフェデレーションの設定が変更された場合、従業員ユーザーはクラウドにフェデレーションできなくなる可能性があります。緊急アクセスのプロセスでは、権限を持つ管理者がフェデレーション設定やワークロードの問題を解決するために、代替手段 (代替のフェデレーションやユーザーの直接アクセスなど) を通じてクラウドリソースにアクセスすることを許可します。緊急アクセスのプロセスは、通常のフェデレーションメカニズムが復旧するまで使用されます。
**期待される成果:**
+ 緊急事態とみなされる障害モードを定義して文書化します。通常の状況と、ユーザーがワークロードの管理に使用するシステムを考慮してください。それぞれの依存関係でどのように障害が発生しうるか、またその障害がどのように緊急事態を引き起こすかを検討します。[信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html)の質問とベストプラクティスは、障害モードを特定し、障害の可能性を最小限に抑えるための、より回復力のあるシステムの構築に役立ちます。
+ 障害が緊急事態であると確認する際に従うべき手順を文書化します。例えば、ID 管理者がプライマリ ID プロバイダーとスタンバイ ID プロバイダーのステータスを確認すること、両方とも使用できない場合は、ID プロバイダーに障害が発生した場合の緊急事態を宣言することを要求できます。
+ 各種の緊急モードまたは障害モードに固有の緊急アクセスプロセスを定義します。具体的に定義することで、ユーザーが緊急事態の種類にかかわらず一般的なプロセスを使いすぎる状況を減らすことができます。緊急アクセスのプロセスで、各プロセスを使用すべき状況、逆にそのプロセスを使用すべきでない状況、適用される可能性のある代替プロセスを説明します。
+ 詳細な指示とプレイブックを含めてプロセスが十分に文書化されており、迅速かつ効率的に実行できます。緊急事態はユーザーにとってストレスの多い時間であり、ユーザーは極度の時間的プレッシャーにさらされる可能性があるため、プロセスはできるだけシンプルに設計してください。
**一般的なアンチパターン:**
+ 緊急アクセスプロセスの文書化およびテストが不十分である。ユーザーは緊急事態への備えができておらず、緊急事態が発生しても即席のプロセスに従う。
+ 緊急アクセスのプロセスで、通常のアクセスメカニズムと同じシステム (一元化された ID プロバイダーなど) を使用する。これにより、このようなシステムの障害が、通常および緊急の両方のアクセスメカニズムに影響を及ぼし、障害からの回復能力が損なわれる可能性がある。
+ 緊急アクセスのプロセスが、緊急ではない状況で使用される。例えば、パイプラインを通じて変更を送信するよりも直接変更を加える方が簡単だと感じるため、ユーザーが頻繁に緊急アクセスプロセスを誤用する。
+ 緊急アクセスのプロセスで、プロセスを監査するための十分なログが生成されていない、またはログが監視されておらずプロセスの誤用の可能性についてアラートされない。
**このベストプラクティスを活用するメリット:**
+ 緊急アクセスのプロセスを十分に文書化し、十分にテストすることで、ユーザーが緊急事態に対応して解決するための時間を短縮できます。これにより、ダウンタイムが減少し、顧客に提供するサービスの可用性が高まります。
+ 緊急アクセスのリクエストをそれぞれ追跡し、緊急事態以外の場合にプロセスを誤用しようとする不正な試みを検出してアラートすることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
このセクションでは、AWS 上にデプロイされたワークロードに関連する複数の障害モードに対する緊急アクセスプロセス作成のためのガイダンスを提供します。すべての障害モードに適用される共通のガイダンスから始め、次に障害モードのタイプに基づいた具体的なガイダンスを示します。
**すべての障害モードに共通のガイダンス**
障害モードに対する緊急アクセスプロセスを設計する際は、次の点を考慮してください。
+ プロセスの前提条件と仮定事項 (プロセスを使用すべき場合と使用すべきでない場合) を文書化します。障害モードを詳しく説明し、他の関連システムの状態などの仮定事項を文書化しておくと役立ちます。例えば、障害モード 2 に対するプロセスでは、ID プロバイダーは使用可能だが、AWS の設定が変更されているか、有効期限が切れていることを仮定しています。
+ 緊急アクセスのプロセスで必要となるリソースを事前に作成しておきます ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html))。例えば、IAM ユーザーとロールを持つ緊急アクセス用の AWS アカウントと、すべてのワークロードアカウントでのクロスアカウントの IAM ロールを事前に作成します。これにより、緊急事態の発生時にリソースが準備され使用可能である状態を確保することができます。リソースを事前に作成することで、緊急時に使用できない可能性のある AWS [コントロールプレーン](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) API (AWS リソースの作成と変更に使用) への依存関係がなくなります。さらに、IAM リソースを事前に作成することで、[結果整合性による潜在的な遅延](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)を考慮する必要がなくなります。
+ インシデント管理計画に緊急アクセスのプロセスを含めます ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html))。緊急事態の追跡方法、同僚チームやリーダーシップなど組織内の他のメンバーや、該当する場合は外部の顧客やビジネスパートナーへの伝達方法を文書化します。
+ 既存のサービスリクエストワークフローシステム (ある場合) で緊急アクセスリクエストプロセスを定義します。通常、このようなワークフローシステムでは、リクエストに関する情報を収集する受付フォームを作成したり、ワークフローの各段階でリクエストを追跡したり、自動および手動の承認ステップを追加したりできます。各リクエストを、インシデント管理システムで追跡される、対応する緊急イベントに関連付けます。緊急アクセス用の統一されたシステムがあると、こうしたリクエストを単一のシステムで追跡し、使用傾向を分析して、プロセスを改善できます。
+ 緊急アクセスプロセスは権限を持つユーザーのみが開始できることと、必要に応じてそのユーザーの同僚または管理層の承認が必要であることを確認します。承認プロセスは、営業時間の内外で効果的に実施される必要があります。承認リクエストについて、一次承認者が不在の場合はどのように二次承認者を許可するのか、承認を受けるまで、どのように一連の管理層にリクエストをエスカレーションするのかを定義します。
+ 緊急アクセスのプロセスとメカニズムに対して、堅牢なログ記録、モニタリング、アラートメカニズムを実装します。緊急アクセスに成功した場合と失敗した場合のすべての試行について、詳細な監査ログを生成します。インシデント管理システムから進行中の緊急イベントとアクティビティを関連付け、想定期間外にアクションが発生した場合、または通常のオペレーション中に緊急アクセスアカウントが使用された場合にアラートを開始します。緊急アクセスアカウントは、Break Glass 手順がバックドアと見なされる可能性があるため、緊急時にのみアクセスする必要があります。セキュリティ情報イベント管理 (SIEM) ツールまたは [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) を統合して、緊急アクセス期間中のすべてのアクティビティをレポートおよび監査します。通常のオペレーションに戻ったら、緊急アクセス認証情報を自動的にローテーションし、関連するチームに通知します。
+ 緊急アクセスプロセスを定期的にテストして、手順が明確であること、適切なレベルのアクセス権を迅速かつ効率的に付与できることを確認します。緊急アクセスのプロセスは、インシデント対応シミュレーション ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) とディザスタリカバリテスト ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)) の一部としてテストする必要があります。
**障害モード 1: AWS へのフェデレーションに使用する ID プロバイダーが使用できない**
「[SEC02-BP04 一元化されたプロバイダーを使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)」で説明したとおり、ワークフォースユーザーをフェデレーションして AWS アカウントへのアクセス権を付与するには、一元化された ID プロバイダーを使用することを推奨します。IAM Identity Center を使用して AWS 組織内の複数の AWS アカウントにフェデレーションするか、IAM を使用して個別の AWS アカウントにフェデレーションすることができます。いずれの場合も、ワークフォースユーザーは、シングルサインオンのために AWS へのサインインエンドポイントにリダイレクトされる前に、一元化された ID プロバイダーで認証されます。
万一、一元化された ID プロバイダーが利用できなくなった場合、ワークフォースユーザーは AWS アカウントにフェデレーションすることも、ワークロードを管理することもできなくなります。こうした緊急事態には、AWS アカウントにアクセスするための緊急アクセスプロセスを少数の管理者に提供し、一元化された ID プロバイダーのオンライン復帰を待つ余裕のない重要なタスクを実行できるようにします。例えば、ID プロバイダーを 4 時間利用できない間に、顧客トラフィックの想定外の急増に対応するために、本番稼働用アカウントの Amazon EC2 Auto Scaling グループの上限を変更する必要が生じたとします。その場合、緊急管理者は、緊急アクセスプロセスに従って特定の本番稼働用 AWS アカウントへのアクセス権を取得し、必要な変更を加える必要があります。
緊急アクセスのプロセスでは、事前に作成された緊急アクセス用 AWS アカウントを使用します。このアカウントは緊急アクセスの目的でのみ使用され、緊急アクセスのプロセスに対応するための AWS リソース (IAM ロールや IAM ユーザーなど) が設定されています。通常の操作中は、誰も緊急アクセスアカウントにアクセスしてはならず、このアカウントの誤用については監視してアラートする必要があります (詳細については、前述の「共通のガイダンス」セクションを参照してください)。
緊急アクセスアカウントには、緊急アクセスを必要とする AWS アカウントでクロスアカウントロールを引き受ける権限を持つ、緊急アクセス IAM ロールがあります。これらの IAM ロールは事前に作成され、緊急アカウントの IAM ロールを信頼する信頼ポリシーで設定されます。
緊急アクセスプロセスでは、次のいずれかの方法を使用できます。
+ 緊急アクセスアカウントでは、関連する強力なパスワードと MFA トークンを使用して、緊急管理者用の一連の [IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)を事前に作成します。これらの IAM ユーザーには、IAM ロールを引き受け、緊急アクセスが必要な AWS アカウントへのクロスアカウントアクセスを許可する権限があります。このようなユーザーはできるだけ少人数にし、各ユーザーを 1 人の緊急管理者に割り当てることが推奨されます。緊急時には、緊急管理者ユーザーがパスワードと MFA トークンコードを使用して緊急アクセスアカウントにサインインし、緊急アカウントで緊急アクセス IAM ロールに切り替え、最後にワークロードアカウントで緊急アクセス IAM ロールに切り替えて、緊急の変更アクションを実行します。この方法の利点は、それぞれの IAM ユーザーが 1 人の緊急管理者によって割り当てられるため、CloudTrail イベントを確認することで、どのユーザーがサインインしたかを把握できることです。欠点は、複数の IAM ユーザーと、それぞれに関連付けられた永続的なパスワードおよび MFA トークンを管理する必要があることです。
+ 緊急アクセス [AWS アカウントルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)を使用して緊急アクセスアカウントにサインインし、緊急アクセスの IAM ロールを引き受け、ワークロードアカウントでクロスアカウントロールを引き受けることができます。ルートユーザーには強力なパスワードと複数の MFA トークンを設定することが推奨されます。また、パスワードと MFA トークンは、強力な認証と承認を実行する安全なエンタープライズ認証情報ボールトに保管することをお勧めします。パスワードと MFA トークンのリセット要因を確保する必要があります。アカウントの E メールアドレスを、クラウドセキュリティ管理者が監視するメール配布リストに設定し、アカウントの電話番号は、同様にセキュリティ管理者が監視する共有電話番号に設定します。この方法の利点は、管理するルートユーザーの認証情報が 1 セットだけであることです。欠点は、これが共有ユーザーであるため、複数の管理者がルートユーザーとしてサインインできてしまうことです。エンタープライズボールトのログイベントを監査して、どの管理者がルートユーザーのパスワードをチェックアウトしたかを特定する必要があります。
**障害モード 2: AWS の ID プロバイダー設定が変更された、または有効期限が切れている**
従業員ユーザーが AWS アカウントにフェデレーションできるようにするには、外部 ID プロバイダーを使用して IAM Identity Center を設定するか、IAM ID プロバイダーを作成します ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html))。通常、これらを設定するには、ID プロバイダーが提供する SAML メタデータ XML ドキュメントをインポートします。メタデータ XML ドキュメントには、ID プロバイダーが SAML アサーションの署名に使用するプライベートキーに対応する X.509 証明書が含まれています。
AWS 側でのこれらの設定は、管理者が誤って変更または削除する可能性があります。もう 1 つのシナリオとして、AWS にインポートされた X.509 証明書の有効期限が切れ、新しい証明書を含む新しいメタデータ XML が AWS にインポートされていない場合があります。いずれの場合も、ワークフォースユーザーの AWS へのフェデレーションが失敗し、緊急事態が発生する可能性があります。
こうした緊急事態には、フェデレーションの問題を解決するための AWS へのアクセスを ID 管理者に提供できます。例えば、ID 管理者は緊急アクセスプロセスを使用して緊急アクセス用 AWS アカウントにサインインし、アイデンティティセンター管理者アカウントのロールに切り替え、ID プロバイダーから提供された最新の SAML メタデータ XML ドキュメントをインポートして外部 ID プロバイダーの設定を更新することで、フェデレーションを再有効化することができます。フェデレーションが修正されたら、ワークフォースユーザーは引き続き通常の操作プロセスに従ってワークロードアカウントにフェデレーションします。
前述の「障害モード 1」で説明した方法に従って、緊急アクセスプロセスを作成できます。アイデンティティセンター管理者アカウントだけにアクセスし、そのアカウントでアイデンティティセンター上でのアクションを実行するための最小権限のアクセス権を、ID 管理者に付与できます。
**障害モード 3: ID センターの中断**
万一、IAM Identity Center または AWS リージョンが中断した場合に備えて、AWS マネジメントコンソールへの一時的なアクセスを提供するための構成を設定しておくことをお勧めします。
緊急アクセスのプロセスでは、ID プロバイダーから緊急アカウントの IAM への、直接フェデレーションを使用します。プロセスと設計上の考慮事項の詳細については、「[Set up emergency access to the AWS マネジメントコンソール](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)」を参照してください。
### 実装手順
**すべての障害モードで共通の手順**
+ 緊急アクセスプロセス専用の AWS アカウントを作成します。IAM ロール、IAM ユーザー、IAM ID プロバイダー (オプション) など、アカウントで必要となる IAM リソースを事前に作成しておきます。さらに、緊急アクセスアカウントで対応する IAM ロールとの信頼関係を持つクロスアカウントの IAM ロールを、ワークロード AWS アカウントで事前に作成します。[CloudFormation StackSets with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) を使用して、組織内のメンバーアカウントでこうしたリソースを作成できます。
+ メンバー AWS アカウント内のクロスアカウント IAM ロールの削除と変更を拒否する、AWS Organizations[ サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) を作成します。
+ 緊急アクセス AWS アカウントの CloudTrail を有効にし、ログ収集 AWS アカウントの中央の S3 バケットに証跡イベントを送信します。AWS Control Tower を使用して AWS マルチアカウント環境を設定・管理している場合は、AWS Control Tower を使用して作成した、または AWS Control Tower に登録したすべてのアカウントで CloudTrail がデフォルトで有効になっており、専用のログアーカイブ AWS アカウントの S3 バケットに送信されます。
+ 緊急 IAM ロールごとのコンソールログインと API アクティビティに一致する EventBridge ルールを作成して、緊急アクセスアカウントのアクティビティを監視します。インシデント管理システムで追跡されている進行中の緊急事態以外でアクティビティが発生した場合は、セキュリティオペレーションセンターに通知を送信します。
**「障害モード 1 : AWS へのフェデレーションに使用する ID プロバイダーが使用できない」、および「障害モード 2: AWS の ID プロバイダー設定が変更された、または有効期限が切れている」での追加手順**
+ 緊急アクセス用に選択したメカニズムに応じて、リソースを事前に作成します。
+ **IAM ユーザーを使用する:** 強力なパスワードおよび関連付けられた MFA デバイスを持つ IAM ユーザーを事前に作成します。
+ **緊急アカウントのルートユーザーを使用する:** ルートユーザーに強力なパスワードを設定し、そのパスワードをエンタープライズ認証情報ボールトに保存します。複数の物理 MFA デバイスをルートユーザーに関連付け、緊急管理チームのメンバーがすぐにアクセスできる場所に保管します。
**障害モード 3: ID センターの中断」での追加手順**
+ 「[Set up emergency access to the AWS マネジメントコンソール](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)」で説明しているとおり、緊急アクセス用の AWS アカウントで IAM ID プロバイダーを作成し、ID プロバイダーからの直接 SAML フェデレーションを有効にします。
+ ID プロバイダーでメンバーのいない緊急オペレーショングループを作成します。
+ 緊急アクセスアカウントで、緊急オペレーショングループに対応する IAM ロールを作成します。
## リソース
**関連する Well-Architected のベストプラクティス:**
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 最小特権のアクセスを付与する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 インシデント管理計画を作成する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 ゲームデーを実施する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**関連ドキュメント:**
+ [Set up emergency access to the AWS マネジメントコンソール](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [SAML 2.0 フェデレーティッドユーザーが AWS マネジメントコンソールにアクセス可能にする](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**関連動画:**
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
**関連する例:**
+ [AWS Break Glass Role](https://github.com/awslabs/aws-break-glass-role)
+ [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 アクセス許可を継続的に削減する
チームと必要とするアクセスを決定したら、不要になったアクセス許可を削除し、最小特権のアクセス許可を達成するためのレビュープロセスを確立します。人間とマシンアクセス両方について使用しないアイデンティティとアクセス許可を継続的にモニタリングして削除します。
**期待される成果:** アクセス許可ポリシーは、最小特権の原則に従う必要があります。職務やロールの定義がはっきりしてくるにつれ、アクセス許可ポリシーを見直し、必要でないアクセス許可を削除する必要があります。このアプローチにより、不注意による認証情報漏洩や不正アクセスによる影響を軽減することができます。
**一般的なアンチパターン:**
+ デフォルトでユーザーに管理者アクセス許可を付与する
+ 過度に寛容でありながら、完全な管理者権限がないポリシーを作成する。
+ 不要になった後もアクセス許可ポリシーを保持する。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
チームやプロジェクトが始まったばかりの場合、革新とアジリティを刺激するために、寛容な許可ポリシーが使われる可能性があります。例えば、開発またはテスト環境であれば、開発者にはさまざまな AWS サービスへのアクセスを付与できます。継続的にアクセスを評価し、アクセスを、現在のジョブを完了するために必要なサービスおよびサービスアクションのみに制限することが推奨されます。この評価は、人的およびマシン ID 両方にお薦めします。マシン ID は、システムまたはサービスアカウントと呼ばれることもありますが、AWS にアプリケーションまたはサービスへのアクセスを付与するアイデンティティです。このアクセスは、本稼働環境で特に重要です。ここでは、過剰に寛容なアクセス許可を使うと影響が大きく、顧客データを開示してしまう可能性があるためです。
AWS は、使用されていないユーザー、ロール、アクセス許可、および認証情報を特定するための方法を複数提供しています。AWS は、Amazon S3 バケットのオブジェクトなど AWS リソースへの関連付けられたアクセスキー、およびアクセスを含む、IAM ユーザーとロールのアクセス活動を分析するのにも役立ちます。AWS Identity and Access Management Access Analyzer ポリシー生成により、プリンシパルが実際にやりとりするサービスやアクションに基づいて、限定的な許可ポリシーを作成することができます。[属性ベースのアクセスコントロール (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) は、アクセス許可ポリシーを各ユーザーに直接アタッチするのではなく、属性を使用してユーザーにアクセス許可を付与できるため、アクセス許可の管理を簡素化するのに役立ちます。
### 実装手順
+ **[AWS Identity and Access Management Access Analyzer を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html):** IAM Access Analyzer の機能は、[外部エンティティと共有されている](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html) Amazon Simple Storage Service (Amazon S3) バケットや IAM ロールなど、組織とアカウントのリソースを識別するのに役立ちます。
+ **[IAM Access Analyzer ポリシー生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)を使用する:** IAM Access Analyzer ポリシー生成は、[IAM ユーザーまたはロールのアクセスアクティビティに基づいてきめ細かなアクセス許可ポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks)のに役立ちます。
+ **本番稼働前に下位環境全体のアクセス許可をテストする:** まず、[重要度の低いサンドボックス環境と開発環境](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html)で、IAM Access Analyzer を使用してさまざまなジョブ機能に必要なアクセス許可をテストします。その後、本番環境に適用する前に、これらのアクセス許可をテスト環境、品質保証環境、ステージング環境で段階的に強化して検証します。サービスコントロールポリシー (SCP) は、付与される最大アクセス許可を制限することによってガードレールを適用するため、環境が低いほど、最初はアクセス許可がより緩和されます。
+ **IAM ユーザーおよびロールの許容時間枠と使用ポリシーを決定する:** [最後にアクセスされたタイムスタンプ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html)を使用して、[未使用のユーザーとロールを特定](https://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 S3 アクションを特定し、それらのアクションのみにアクセスを制限できます。最終アクセス時間情報は、AWS マネジメントコンソールおよびプログラムで使用でき、インフラストラクチャワークフローや自動化ツールに組み込むことができます。
+ **[AWS CloudTrail でのデータイベントのログ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html)記録を検討する:** デフォルトでは、CloudTrail は Amazon S3 オブジェクトレベルのアクティビティ (`GetObject` や など `DeleteObject`) や Amazon DynamoDB テーブルアクティビティ (`PutItem` や `DeleteItem` など) などのデータイベントをログに記録しません。これらのイベントのログ記録を有効にして、特定の Amazon S3 オブジェクトまたは DynamoDB テーブルアイテムにアクティビティする必要があるユーザーとロールを決定します。
## リソース
**関連ドキュメント:**
+ [最小特権アクセス許可を適用する](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)
+ [What is AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [IAM ポリシーを管理する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [DynamoDB でのモニタリングとログ記録](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [S3 バケットとオブジェクトの CloudTrail イベントログ記録の有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [の認証情報レポートを生成します。AWS アカウント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.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)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 組織のアクセス許可ガードレールを定義する
アクセス許可ガードレールを使用して、プリンシパルに付与できるアクセス許可の範囲を縮小します。アクセス許可ポリシーの評価チェーンには、承認の決定を行う際のプリンシパルの有効なアクセス許可を決定するガードレールが含まれています。 ガードレールは階層型のアプローチで定義できます。一部のガードレールは組織全体に広く適用し、他のガードレールはきめ細かく一時的なアクセスセッションに適用します。
**期待される成果:** 個別の AWS アカウントを使用して環境を明確に分離できます。 サービスコントロールポリシー (SCP) を使用して、組織全体のアクセス許可ガードレールを定義します。比較的広範なガードレールは組織のルートに近い階層に設定し、比較的厳格なガードレールは各アカウントのレベルの近くで設定します。
リソースポリシー (サポートされている場合) で、プリンシパルがリソースにアクセスするために満たす必要がある条件を定義します。リソースポリシーは、許可される一連のアクションも適宜限定します。ワークロードのアクセス許可を管理するプリンシパルにアクセス許可境界を設けたうえで、アクセス許可管理が個々のワークロード所有者に委任されています。
**一般的なアンチパターン:**
+ [AWS Organization](https://aws.amazon.com/organizations/) 内に AWS アカウントメンバーを作成しているが、SCP を使用してルート認証情報で利用できる使用とアクセス許可を制限していない。
+ 最小特権に基づいてアクセス許可を割り当てているが、付与できるアクセス許可一式に上限を設けるガードレールが敷かれていない。
+ AWS IAM の暗黙的な拒否基盤に依存してアクセス許可を制限し、ポリシーが望ましくない明示的な許可のアクセス許可を付与しないことに頼る。
+ 同じ AWS アカウント内で複数のワークロード環境を実行していて、アクセス許可境界の設定は VPC、タグ、リソースポリシーなどのメカニズム頼みである。
**このベストプラクティスを活用するメリット:** アクセス許可ガードレールは、アクセス許可ポリシーが付与しようとしても、望ましくないアクセス許可を付与できないという確信を持つために役立ちます。 考慮する必要があるアクセス許可の最大範囲が縮小されるため、アクセス許可の定義と管理が簡単になります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
組織のアクセス許可ガードレールは、階層型のアプローチで定義することを推奨します。このアプローチでは、層を重ねるに従い、付与できるアクセス許可一式の上限が体系的に引き下げられます。最小特権の原則に基づいてアクセス権を付与できるため、ポリシーの設定ミスによる意図しないアクセスが起きるリスクが軽減されます。
アクセス許可ガードレールを敷くには、まず、ワークロードと環境を個別の AWS アカウントに分離します。1 つのアカウントのプリンシパルは、両方のアカウントが同じ AWS 組織または同じ[組織単位 (OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) にある場合でも、明示的なアクセス許可なしに別のアカウントのリソースにアクセスすることはできません。OU を使用して、管理対象の複数のアカウントを 1 つのユニットとしてグループ化できます。
次に、組織のメンバーアカウント内のプリンシパルに付与できるアクセス許可一式の上限を引き下げます。これには[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を使用できます。SCP は OU またはアカウントに適用できます。SCP では、特定の AWS リージョンへのアクセスを制限する、リソースが削除されないように防ぐ、リスクが懸念されるサービスアクションを無効にするなど、一般的なアクセス制御を適用できます。組織のルートに適用する SCP は、そのメンバーアカウントにのみ影響し、管理アカウントには影響しません。 SCP は組織内のプリンシパルにのみ適用されます。組織の外部からリソースにアクセスするプリンシパルは対象外です。
[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) を使用している場合は、アクセス許可ガードレールとマルチアカウント環境の基盤として、[コントロール](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work)と[ランディングゾーン](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)を活用できます。ランディングゾーンは、事前設定済みの安全なベースライン環境と、さまざまなワークロードやアプリケーション向けの個別のアカウントを提供します。ガードレールは、サービスコントロールポリシー (SCP)、AWS Config ルール、およびその他の設定を組み合わせて、セキュリティ、オペレーション、コンプライアンスに関する必須のコントロールを適用します。しかし、Control Tower のガードレールとランディングゾーンを組織独自の SCP と併用する場合は、競合を回避し、適切なガバナンスを確保するため、AWS のドキュメントに記載されているベストプラクティスに従うことが非常に重要です。Control Tower 環境内の SCP、アカウント、組織単位 (OU) の管理に関する詳細な推奨事項については、「[AWS Organizations の AWS Control Tower ガイダンス](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html)」を参照してください。
これらのガイドラインに従うことにより、Control Tower のガードレール、ランディングゾーン、カスタム SCP を効果的に活用しながら、競合を防止し、マルチアカウント AWS 環境の適切なガバナンスと管理を確保できます。
さらに、[IAM リソースポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)を使用して、管理対象のリソースに対して実行できるアクションと、動作するプリンシパルが満たす必要がある条件の範囲を絞り込むことができます。これは、プリンシパルが組織の一部である限り (PrincipalOrgId [条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を使用) すべてのアクションを許可するのと同じくらい広範囲にすることも、特定の IAM ロールによる特定のアクションのみを許可するのと同じくらい詳細にすることもできます。IAM ロールの信頼ポリシーの条件でも、同様のアプローチをとることができます。 リソースまたはロールの信頼ポリシーで、適用対象のロールまたはリソースと同じアカウントのプリンシパルの名前が明示的に指定されている場合、そのプリンシパルには同じアクセス許可を付与する IAM ポリシーをアタッチする必要はありません。 プリンシパルがリソースとは異なるアカウントにある場合は、該当するアクセス許可を付与する IAM ポリシーをプリンシパルにアタッチする必要があります。
多くの場合、ワークロードチームが担当ワークロードに必要なアクセス許可を管理することを望みます。 その場合は、そのチームが新しい IAM ロールとアクセス許可のポリシーを適宜作成する必要があります。 チームが [IAM アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)で付与できるアクセス許可の最大範囲をキャプチャし、このドキュメントをチームが IAM ロールとアクセス許可の管理に使用できる IAM ロールに関連付けることができます。 このアプローチにより、業務の完遂に必要な柔軟性をチームに与えつつ、IAM の管理権限を持つリスクを軽減できます。
よりきめ細かいステップが、*特権アクセス管理* (PAM) と*一時的な昇格アクセス管理* (TEAM) を実装する方法です。 PAM の一例としては、特権が必要なアクションの実行前にプリンシパルに多要素認証の実行を要求します。 詳細については、「[MFA 保護 API アクセスの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)」を参照してください。TEAM では、プリンシパルへの昇格アクセスの承認とそのアクセス権を持っていられる期間を管理するソリューションが必要です。 1 つの方法は、昇格アクセス権を持つ IAM ロールのロール信頼ポリシーにプリンシパルを一時的に追加することです。 もう 1 つの方法は、通常のオペレーションでは、[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)を使用して IAM ロールによってプリンシパルに付与されたアクセス許可の範囲を絞り込み、承認された時間枠内にこの制限を一時的に解除することです。AWS と特定のパートナーが検証したソリューションの詳細については、「[Temporary elevated access](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html)」を参照してください。
### 実装手順
1. ワークロードと環境を個別の AWS アカウントに分離します。
1. SCP を使用して、組織のメンバーアカウント内のプリンシパルに付与できるアクセス許可一式の上限を引き下げます。
1. SCP を定義して、組織のメンバーアカウント内のプリンシパルに付与できるアクセス許可の最大セットを削減するには、*許可リスト*または*拒否リスト*のアプローチを選択できます。許可リストによる方法では、許可するアクセスを明示的に指定し、それ以外のすべてのアクセスを暗黙的にブロックします。拒否リストによる方法は、許可しないアクセスを明示的に指定し、デフォルトで他のすべてのアクセスを許可します。どちらの方法にも利点とトレードオフがあり、どちらを選択するのが適切かどうかは、具体的な要件とリスクモデルによって異なります。詳細については、「[SCP の使用戦略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html)」を参照してください。
1. さらに、「[サービスコントロールポリシーの例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)」を確認して、SCP を効果的に構築する方法を理解します。
1. IAM リソースポリシーを使用して、リソースに対して許可されるアクションの範囲を限定し、その条件を指定します。 IAM ロールの信頼ポリシーで条件を指定して、ロールを引き受けた場合の制限を設けます。
1. IAM アクセス許可境界を IAM ロールに割り当てます。ワークロードチームがこのロールを使用して、各自のワークロードの IAM ロールとアクセス許可を管理できるようになります。
1. ニーズに基づいて PAM ソリューションや TEAM ソリューションを評価します。
## リソース
**関連ドキュメント:**
+ [Data perimeters on AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [データ境界を使用してアクセス許可のガードレールを確立する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [ポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**関連する例:**
+ [Service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**関連ツール:**
+ [AWS Solution: Temporary Elevated Access Management](https://aws-samples.github.io/iam-identity-center-team/)
+ [TEAM 用の検証済みセキュリティパートナーソリューション](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 ライフサイクルに基づいてアクセスを管理する
プリンシパル (ユーザー、ロール、グループ) に付与されるアクセス許可を、組織内での各々の全ライフサイクルにわたり監視し、調整します。ユーザーの役割の変更に応じてグループメンバーシップを調整し、ユーザーが組織を離れた時点でアクセス権を取り消します。
**期待される成果:** 組織内のプリンシパルのライフサイクルを通じてアクセス許可をモニタリングおよび調整し、不要な権限のリスクを減らします。ユーザーの作成時に適切なアクセス権が付与されます。ユーザーの責任が変わった時点でアクセス権を変更し、ユーザーが業務を遂行していないときや組織を離れたときはアクセス権を取り消します。ユーザー、ロール、グループに対する変更を一元管理します。自動化を使用して、AWS 環境に変更を反映します。
**一般的なアンチパターン:**
+ 初期段階で必要以上に過剰または広範なアクセス権限をアイデンティティに事前に付与している。
+ アイデンティティの役割と責任が経時的に変化しても、アクセス権限を見直したり調整したりしない。
+ 非アクティブまたは終了したアイデンティティに、アクティブなアクセス権限を与えたままにしている。これにより、不正アクセスのリスクが高まります。
+ ID のライフサイクル管理に自動化が活用されていない。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
アイデンティティ (ユーザー、ロール、グループなど) に付与するアクセス権限は、それらのライフサイクル全体にわたって慎重に管理および調整してください。このライフサイクルには、初期のオンボーディングフェーズ、役割と責任の継続的な変更、そして最終的なオフボーディングまたは終了が含まれます。ライフサイクルの段階に基づいてアクセス権をプロアクティブに管理し、適切なアクセスレベルを維持します。最小特権の原則に従い、過剰または不必要なアクセス権限が付与されるリスクを軽減してください。
IAM ユーザーのライフサイクルは AWS アカウント 内で直接管理することも、ワークフォース ID プロバイダーと [AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/)とのフェデレーションを通じて管理することもできます。IAM ユーザーの場合は、ユーザーと関連するアクセス許可を AWS アカウント内で作成、変更、削除できます。フェデレーションユーザーについては、IAM アイデンティティセンターを使用してライフサイクルを管理できます。その場合は、[System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) (SCIM) プロトコルを使用して、組織の ID プロバイダーからのユーザーとグループの情報を同期します。
SCIM は、さまざまなシステム間でユーザー ID のプロビジョニングとプロビジョニング解除を自動化するためのオープンスタンダードのプロトコルです。SCIM を使用して ID プロバイダーを IAM Identity Center に統合することで、ユーザーとグループの情報を自動的に同期し、組織の信頼できるアイデンティティソースにおける変更に基づいてアクセス権限が付与、変更、または取り消されているか検証できます。
組織内での従業員の役割と責任が変化したら、その従業員のアクセス権限を適宜調整してください。IAM Identity Center のアクセス許可セットを使用して、さまざまな職務または責任を定義し、それらに適切な IAM ポリシーやアクセス許可を関連付けることができます。従業員の役割が変更されたら、割り当てられているアクセス許可セットを更新して、その従業員の新しい責任を反映させることができます。最小特権の原則に従いながら、従業員に必要なアクセス権が与えられていることを確認してください。
### 実装手順
1. 初期アクセス権の付与、定期的なレビュー、オフボーディングの手順を含む、アクセス管理ライフサイクルのプロセスを定義し、文書化します。
1. [IAM ロール、グループ、アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)を実装して、アクセス許可を一元管理し、最大許容アクセスレベルを適用します。
1. [フェデレーティッド ID プロバイダー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (Microsoft Active Directory、Okta、Ping Identity など) を、ユーザーおよびグループ情報の信頼できるソースとして IAM アイデンティティセンターを使用して統合します。
1. [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) プロトコルを使用して、ID プロバイダーからのユーザー情報やグループ情報を IAM アイデンティティセンターの ID ストアに同期します。
1. IAM アイデンティティセンターで、組織内のさまざまな職務や責任を表す[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)を作成します。アクセス許可セットごとに適切な IAM ポリシーとアクセス許可を定義します。
1. 定期的なアクセスレビュー、迅速なアクセス取り消し、アクセス管理ライフサイクルプロセスの継続的な改善を実施します。
1. アクセス管理のベストプラクティスについて、従業員にトレーニングを行い、周知徹底させます。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP04 一元化された ID プロバイダーを利用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**関連ドキュメント:**
+ [ID ソースを管理する](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [IAM Identity Center で ID を管理する](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [AWS Identity and Access Management Access Analyzer の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**関連動画:**
+ [AWS re:Inforce 2023 - Manage temporary elevated access with AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - Harness power of IAM policies & rein in permissions w/Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析
パブリックおよびクロスアカウントアクセスに焦点を当てた結果を継続的にモニタリングします。パブリックアクセスとクロスアカウントアクセスを減らして、このアクセスを必要とする特定のリソースのみへのアクセスに限定します。
**期待される成果:** どの AWS リソースが誰と共有されているかを把握します。共有されたリソースを継続的にモニタリングおよび監査し、認証されたプリンシパルとのみ共有されていることを確認します。
**一般的なアンチパターン:**
+ 共有されたリソースのインベントリを保持しない。
+ リソースへのクロスアカウントまたはパブリックアクセスの承認のためのプロセスを遵守しない。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
アカウントが AWS Organizations にある場合、リソースへのアクセスを、組織全体、特定の組織単位、または個別のアカウントに付与することができます。アカウントが組織のメンバーでない場合、個別のアカウントとリソースを共有することができます。リソースベースのポリシー (例: [Amazon Simple Storage Service (Amazon S3) バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)) を使用して、または別のアカウントのプリンシパルがアカウントの IAM ロールを引き受けることを許可することで、クロスアカウントアクセスを直接付与できます。リソースポリシーを使用している場合、アクセスが認証済みのプリンシパルにのみ付与されていることを確認してください。パブリックアクセス可能にする必要があるすべてのリソースを承認するプロセスを定義します。
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) は[証明可能セキュリティ](https://aws.amazon.com/security/provable-security/)を使用して、アカウントの外部からリソースへのすべてのアクセスパスを識別します。また、リソースポリシーの継続的な確認と、パブリックおよびクロスアカウントアクセスの結果の報告により、広範囲なアクセス権の分析を単純化します。すべてのアカウントが表示可能であることを確認するために、IAM Access Analyzer で AWS Organizations を設定することを検討します。IAM 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/)を使用して、ロールを引き受けることができるケースを制御できます。例えば、[`PrincipalOrgId` 条件キーを使用して、AWS Organizations の外部からロールを割り当てる試みを拒否](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)できます。
[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/what-is-securityhub.html) などのサービスでは、AWS Organizations 全体でチェックとガードレールのデプロイが簡素化され、パブリックに公開されているリソースを特定、修復できます。例えば、AWS Control Tower には、[Amazon EBS スナップショットが AWS アカウントによって復元可能かどうかを検出できるマネージドガードレールがあります](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)。
### 実装手順
+ **[AWS Config に AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html) を使用することを検討する:** AWS Config では、AWS Organizations 内の複数のアカウントから委任された管理者アカウントに検出結果を集約できます。これにより、包括的なビューが提供され、[アカウント間で AWS Config ルール をデプロイして、パブリックにアクセス可能なリソースを検出](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)できます。
+ **AWS Identity and Access Management Access Analyzer を設定する:** IAM Access Analyzer は、[外部エンティティと共有](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)されている Amazon S3 バケットや IAM ロールなど、組織とアカウントのリソースを識別するのに役立ちます。
+ **AWS Config で自動修復を使用して、Amazon S3 バケットのパブリックアクセス設定の変更に対応する:** [Amazon S3 バケットのパブリックアクセスブロック設定を自動的にオンにできます](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)。
+ **モニタリングとアラートを実装して、Amazon S3 バケットがパブリックになったかどうかを確認する:** Amazon S3 パブリックアクセスブロックがオフになって、Amazon S3 バケットがパブリックになったかどうかを特定する[モニタリングとアラート](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/)を設定する必要があります。さらに、AWS Organizations を使用している場合は、Amazon S3 パブリックアクセスポリシーへの変更を防ぐ[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)を作成できます。[AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) は、オープンアクセス許可を持つ Amazon S3 バケットをチェックします。誰にでもアクセスを付与、アップロード、削除するバケット権限は、バケットのアイテムを誰でも追加、変更、または削除できるようにすることで、セキュリティ関連の問題の原因となることがあります。Trusted Advisor のチェックでは、バケットの明示的なアクセス許可を検証します。また、バケットに関連付けられたポリシーで、バケットのアクセス許可を上書きする可能性があるものについても検証します。また、AWS Config を使って、Amazon S3 バケットにパブリックアクセスがないかモニタリングできます。詳細については、「[パブリックアクセスを許可する Amazon S3 バケットを AWS Config でモニタリングおよび応答する方法](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)」を参照してください。
Amazon S3 バケットのアクセスコントロールを確認する場合は、バケット内に保存されているデータの性質を考慮することが重要です。[Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) は、個人を特定できる情報 (PII)、保護対象医療情報 (PHI)、プライベートキーや AWS アクセスキーなどの認証情報などの機密データを検出し、保護するのに役立つように設計されています。
## リソース
**関連ドキュメント:**
+ [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 controls library ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [AWS Foundational Security Best Practices standard](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 check reference](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [Monitoring AWS Trusted Advisor check results with Amazon EventBridge](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [Managing AWS Config Rules Across All Accounts in Your Organization](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config および AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [Amazon EC2 で使用するために AMI を公開する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**関連動画:**
+ [Best Practices for securing your multi-account environment](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 組織内でリソースを安全に共有する
ワークロードの数が増えるにつれて、それらのワークロードのリソースへのアクセスを共有したり、複数のアカウントでリソースを複数回プロビジョニングしたりする必要が生じます。開発環境、テスト環境、本番環境などの環境を区分けするための構造があるかもしれません。ただし、分離構造があっても、安全に共有する能力は制限できません。重複するコンポーネントを共有することにより、運用諸経費を削減し、同一リソースを複数回作成する間に見逃したものを推測しなくても、一貫したエクスペリエンスを実現できます。
**期待される成果:** 安全な方法を使用して組織内でリソースを共有し、データ損失防止イニシアチブを支援することで、意図しないアクセスを最小限に抑えます。個々のコンポーネントを管理するのと比較して、運用諸経費を削減し、同じコンポーネントを何度も手動で作成することによるエラーを減らし、ワークロードのスケーラビリティを向上させることができます。削減できた時間を活用して、マルチポイント障害シナリオを解決し、自信を持ってコンポーネントが不要になるときを判断できるようになります。外部共有リソースの分析に関する規範ガイダンスについては、「[SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](sec_permissions_analyze_cross_account.md)」を参照してください。
**一般的なアンチパターン:**
+ 継続的にモニタリングして、予定外の外部共有が生じたときに自動的にアラートを発動するプロセスがない。
+ 共有すべき/すべきでない内容に関する基準がない。
+ 必要な時点で明示的に共有するのではなく、広く開かれたポリシーをデフォルトとしている。
+ 必要に応じて重複する基本的リソースを手動で作成する。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
アクセスコントロールとパターンを構築し、信頼できるエンティティとのみ共有リソースの消費を安全に管理します。共有リソースをモニタリングして、継続的に共有リソースアクセスをレビューし、不適切なまたは予想外の共有があればアラートを発動します。「[パブリックおよびクロスアカウントアクセスの分析](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)」を確認し、ガバナンスを確立して、外部アクセスを必要なリソースのみに減らします。また、継続的かつ自動的にアラートをモニタリングするプロセスを確立します。
AWS Organizations 内のクロスアカウント共有は、[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) など、[多数の AWS サービス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)でサポートされています。これらのサービスを使用すると、中央アカウントでデータを共有し、中央アカウントからアクセス可能、あるいは中央アカウントからリソースとデータを管理できます。例えば、AWS Security Hub CSPM は個別アカウントから中央アカウントに検出結果を送信するため、すべての検出結果を確認することができます。AWS Backup は、リソースのバックアップを取り、アカウント全体で共有します。[AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS 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 AI Pipelines](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker) など、他の一般的なリソースを共有することができます。
アカウントが組織内のリソースのみを共有するように制限するには、[サービスコントロールポリシー (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 バケットにアクセスする ID が組織に属していることを確認できます。[SCP はサービスにリンクされたロールまたは AWS サービスプリンシパルには適用されない](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions)ことにご注意ください。
Amazon S3 を使用する場合は、[Amazon S3 バケット ACL をオフ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)にし、IAM ポリシーを使用してアクセスコントロールを定義します。[[Amazon CloudFront](https://aws.amazon.com/cloudfront/) から Amazon S3 オリジンに](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)アクセスされることを制限するには、オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) に移行します。OAC では [AWS Key Management Service](https://aws.amazon.com/kms/) によるサーバー側暗号化などの追加機能をサポートします。
場合によっては、組織外のリソースを共有したり、リソースにサードパーティーのアクセスを付与したりするかもしれません。外部でリソースを共有するアクセス許可を管理するための規範ガイダンスについては、「[アクセス許可の管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)」を参照してください。
### 実装手順
1. **AWS Organizations を使用する:** AWS Organizations は、ユーザーが作成する組織に、複数の AWS アカウント を統合し、一元管理できるアカウント管理サービスです。アカウントを組織単位 (OU) にグループ化し、OU ごとに異なるポリシーをアタッチすることにより、予算、セキュリティ、コンプライアンスのニーズに対応できます。また、AWS 人工知能 (AI) と機械学習 (ML) サービスがどのようにデータを収集して保管するかをコントロールし、Organizations と統合された AWS サービスのマルチアカウント管理を使用できます。
1. **AWS Organizations と AWS サービスの統合:** 組織のメンバーアカウントで自動的にタスクを実行するために AWS サービスを使用すると、AWS Organizations はそのサービス用のサービスにリンクされた IAM ロール (SLR) を各メンバーアカウントに作成します。AWS マネジメントコンソール、AWS API、または AWS CLI を使用して、信頼できるアクセスを管理する必要があります。信頼されたアクセスを有効にするための規範ガイダンスについては、「[AWS Organizations を AWS の他のサービスと併用する](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html)」および「[Organizations と併用できる AWS サービス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)」を参照してください。
1. **データ境界を確立する:** データ境界は、信頼と所有権の明確な境界を提供します。AWS では、通常、AWS リソースにアクセスするオンプレミスネットワークまたはシステムと共に、AWS Organizations によって管理される AWS Organization として表されます。このデータ境界の目標は、アイデンティティが信頼され、リソースが信頼され、さらにネットワークが予想されている場合に、そのアクセスが許可されていることを検証することです。ただし、データ境界を確立することは、万能なアプローチではありません。[AWS ホワイトペーパーの「境界の構築」](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html)に記載されているコントロール目標を、特定のセキュリティリスクモデルと要件に基づいて評価し、採用します。リスクに対する企業固有の姿勢を慎重に検討し、セキュリティニーズに沿った境界コントロールを実装する必要があります。
1. **AWS サービスでリソース共有を使用し、必要に応じて制限する:** 多くの AWS サービスでは、リソースを別のアカウントと共有できます。また、[Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) および [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html) など別のアカウントのリソースをターゲットにできます。`ModifyImageAttribute` API を制限して、AMI を共有する信頼されたアカウントを指定します。AWS RAM を使用して組織への共有のみを制限する場合は、信頼できない ID からのアクセスを防ぐために `ram:RequestedAllowsExternalPrincipals` 条件を指定します。規範ガイダンスと考慮事項については、「[リソース共有と外部ターゲット](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html)」を参照してください。
1. **AWS RAM を使用して、アカウントまたは他の AWS アカウント と安全に共有する:** [AWS RAM](https://aws.amazon.com/ram/) は、作成したリソースをアカウント内のロールやユーザー、他の AWS アカウント ととも安全に共有できます。マルチアカウント環境の場合、AWS RAM ではリソースを作成したら、それを他のアカウントと共有できます。このアプローチにより、運用諸経費を削減し、Amazon CloudWatch および AWS CloudTrail との統合を通じて、一貫性、可視性、監査可能性を提供することができます。これは、クロスアカウントアクセスを使用している場合は享受できません。
リソースベースのポリシーを使用して過去に共有したリソースが存在する場合、[`PromoteResourceShareCreatedFromPolicy` API](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) または同等機能を使用して、リソース共有を完全な AWS RAM リソース共有に昇格できます。
場合によっては、リソースを共有するための追加ステップが必要かもしれません。例えば、暗号化されたスナップショットを共有するには、[AWS KMS キーを共有](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key)する必要があります。
## リソース
**関連するベストプラクティス:**
+ [SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 サードパーティーとリソースを安全に共有する](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 ネットワークレイヤーを作成する](sec_network_protection_create_layers.md)
**関連ドキュメント:**
+ [例 4 - バケット所有者が所有権のないオブジェクトへのクロスアカウントアクセス許可を付与する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Building Data Perimeter on 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)
+ [AWS services you can use with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [Establishing a data perimeter on AWS: Allow only trusted identities to access company data](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**関連動画:**
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Securing your data perimeter with VPC endpoints](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**関連ツール**:
+ [Data Perimeter Policy Examples](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 サードパーティーとリソースを安全に共有する
クラウド環境のセキュリティは、組織内にとどまりません。組織が、データの一部を管理するのにサードパーティーに依存することもあります。サードパーティー管理システムの権限管理は、一時的な認証情報を使用する最小特権の原則を用いたジャストインタイムアクセスの実践に従う必要があります。サードパーティーと密に連携することにより、意図しないアクセスの影響が及ぶ範囲とリスクをともに縮小することができます。
**期待される成果:** アクセスキーやシークレットキーなどの長期 AWS Identity and Access Management (IAM) 認証情報は、悪用された場合にセキュリティリスクをもたらすため、使用を避けます。代わりに、IAM ロールと一時的な認証情報を使用してセキュリティ体制を強化し、長期的な認証情報を管理する運用上のオーバーヘッドを最小限に抑えます。サードパーティーにアクセス権を付与する場合は、IAM 信頼ポリシーの外部 ID として共通な一意の識別子 (UUID) を使用し、IAM ポリシーをコントロール下にあるロールにアタッチして、最小特権アクセスを確保します。外部で共有されているリソースの分析に関する規範ガイダンスについては、「[SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)」を参照してください。
**一般的なアンチパターン:**
+ 条件なしでデフォルトの IAM 信頼ポリシーを使用する。
+ 長期的 IAM 認証情報とアクセスキーを使う。
+ 外部 ID を再使用する。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS Organizations 外のリソースを共有したり、アカウントにサードパーティーのアクセスを付与したりする場合があります。例えば、サードパーティーが提供する監視ソリューションが、貴社のアカウント内のリソースにアクセスする必要があるかもしれません。そのような場合、サードパーティーにとって必要な権限のみを含む IAM クロスアカウントロールを作成します。さらに、[外部の ID 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)を使用して信頼ポリシーを定義します。外部 ID を使用すると、自分またはサードパーティーが各顧客、サードパーティー、またはテナンシーに対して一意の ID を生成できます。一意の ID を作成後は、自分以外の人物によってコントロールできなくなります。サードパーティーは、外部 ID を安全に、監査可能かつ再現可能な方法で顧客に関連付けるプロセスを実装する必要があります。
また、[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用すると、AWS API を使用している AWS の外部のアプリケーションの IAM ロールを管理できます。
サードパーティーが貴社の環境にアクセスする必要がなくなった場合は、ロールを削除します。サードパーティーに長期的な認証情報を提供することは避けてください。他の AWS アカウント と[ワークロードを共有](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html)できる AWS Well-Architected Tool や、所有する AWS リソースを他のアカウントと安全に共有できる [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) など、共有をサポートする他の AWS サービスについて把握しておきます。
### 実装手順
1. **クロスアカウントロールを使用して外部アカウントにアクセスできるようにします。**[クロスアカウントロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)を使用すると、顧客にサービスを提供する目的で外部アカウントやサードパーティーが保存している機密情報の量を、減らすことができます。クロスアカウントロールがあると、アクセスを管理および監査する能力を維持しながら、AWS パートナーまたは組織内の他のアカウントなど、アカウントの AWS リソースへのアクセスをサードパーティーに安全に付与できます。サードパーティーが、ハイブリッドインフラストラクチャからサービスを提供したり、オフサイトロケーションにデータをプルしたりする場合があります。[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用すると、サードパーティーのワークロードは AWS ワークロードと安全に通信でき、長期的な認証情報の必要性も削減できます。
外部アカウントアクセスを提供するために、ユーザーと関連付けられた長期的認証情報、またはアクセスキーを使用しないでください。かわりに、クロスアカウントロールを使ってクロスアカウントアクセスを提供します。
1. **デューデリジェンスを実施して、サードパーティーの SaaS プロバイダーの安全なアクセスを確保します。**サードパーティーの SaaS プロバイダーとリソースを共有する場合は、そのプロバイダーが AWS リソースにアクセスする際に安全で責任あるアプローチを取っていることを確認するために、徹底的なデューデリジェンスを実施します。責任共有モデルを評価し、どのようなセキュリティ対策が提供され、何が自社の責任に該当するかを理解します。SaaS プロバイダーについて、[外部 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) の使用や最小特権アクセス原則など、リソースにアクセスするために安全で監査可能なプロセスがあることを確認します。外部 ID を使用すると、[混乱した代理問題](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/) に対処できます。
サードパーティーの SaaS プロバイダーへのアクセスを許可する場合は、安全なアクセスと最小特権の原則の遵守を確保するため、セキュリティ対策を実施します。これには、外部 ID、共通の一意の識別子 (UUID)、およびアクセスを必要なもののみに厳格に制限する IAM 信頼ポリシーの使用が含まれます。SaaS プロバイダーと密接に連携して、安全なアクセスメカニズムを確立し、AWS リソースへのアクセスを定期的に見直し、監査を実施してセキュリティ要件へのコンプライアンスを確保します。
1. **顧客が提供する長期的認証情報を廃止します。**長期的認証情報の使用を廃止して、クロスアカウントロールまたは IAM Roles Anywhere を使用します。長期的認証情報を使用する必要がある場合、ロールベースのアクセスに移行する計画を立ててください。キー管理の詳細については、「[ID 管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html)」を参照してください。また、AWS アカウントチームおよびサードパーティーと連携して、リスク軽減ランブックを確立します。セキュリティインシデントの潜在的影響への対応とその軽減に関する規範的ガイダンスについては、「[インシデント対応](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)」を参照してください。
1. **セットアップに規範的ガイダンスがある、または規範的ガイダンスが自動化されていることを確認します。**外部 ID はシークレットとして取り扱われませんが、外部 ID は電話番号、氏名、アカウント ID など推測しやすい値であってはなりません。外部 ID を読み取り専用にすることで、設定のなりすましを目的として外部 ID が変更されないようにします。
ご自身またはサードパーティーが外部 ID を生成できます。ID 生成に責任がある担当者を決定するプロセスを定義します。外部 ID を作成するエンティティにかかわらず、サードパーティーは顧客間で一貫した一意性とフォーマットを適用します。
アカウントのクロスアカウントアクセス向けに作成されたポリシーは、[最小特権の原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)に従う必要があります。サードパーティーは、ロールポリシードキュメント、または AWS CloudFormation テンプレートまたは同等のものを使用する自動化されたセットアップメカニズムを提供する必要があります。これにより、手動ポリシー作成に関連してエラーが発生する可能性が減り、監査可能証跡を提供します。AWS CloudFormation テンプレートを使用してクロスアカウントロールを作成する方法の詳細については、「[Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/)」を参照してください。
サードパーティーは、自動化され、監査可能なセットアップメカニズムを提供する必要があります。ただし、必要なアクセスを概説したロールポリシードキュメントを使用することにより、ロールのセットアップを自動化する必要があります。AWS CloudFormation テンプレートまたは同等のものを使用して、監査業務の一環として、ドリフト検出で変化をモニタリングする必要があります。
1. **変更点を説明します。**アカウント構成、サードパーティーのニーズ、または提供されるサービスオファリングは変わる可能性があります。変更と障害を予想し、それに応じて適切な人材、プロセス、テクノロジーを計画する必要があります。定期的に提供するアクセスのレベルを監査し、予想外の変更があった場合にアラートを出す検出方法を実装します。外部 ID のロールとデータストアをモニタリングおよび監査します。予想外の変更やアクセスパターンの結果、サードパーティーのアクセスを一時的または恒久的に取り消す準備をしておく必要があります。また、実行にかかる時間、関与する人材、コスト、および他のリソースの影響など、取り消し操作の影響を測定します。
検知方法に関する規範的なガイダンスについては、「[検知](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)」内のベストプラクティスを参照してください。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP02 一時的な認証情報を使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 組織のアクセス許可ガードレールを定義する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 ライフサイクルに基づいてアクセスを管理する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 検知](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**関連ドキュメント:**
+ [例 4 - バケット所有者が所有権のないオブジェクトへのクロスアカウントアクセス許可を付与する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use trust policies with IAM roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [IAM チュートリアル: IAM ロールを使用した AWS アカウント 間でのアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [IAM を使用して別の AWS アカウント のリソースにアクセスするにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [クロスアカウントポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Securely Using External ID for Accessing AWS Accounts Owned by Others](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**関連動画:**
+ [How do I allow users or roles in a separate AWS アカウント access to my AWS アカウント?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**関連する例:**
+ [Amazon DynamoDB へのクロスアカウントアクセスを設定する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [AWS STS Network Query Tool](https://github.com/aws-samples/aws-sts-network-query-tool)