# 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)