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