# IAM でのセキュリティのベストプラクティス
<a name="best-practices"></a>

AWS のリソースを保護するには、AWS Identity and Access Management (IAM) を使用する際の以下のベストプラクティスに従ってください。

**Topics**
+ [人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする](#bp-users-federation-idp)
+ [ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする](#bp-workloads-use-roles)
+ [多要素認証 (MFA) を必須とする](#enable-mfa-for-privileged-users)
+ [長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する](#update-access-keys)
+ [ルートユーザーの認証情報を保護するためのベストプラクティスに沿う](#lock-away-credentials)
+ [最小特権アクセス許可を適用する](#grant-least-privilege)
+ [AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する](#bp-use-aws-defined-policies)
+ [IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する](#bp-gen-least-privilege-policies)
+ [未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する](#remove-credentials)
+ [IAM ポリシーで条件を指定して、アクセスをさらに制限する](#use-policy-conditions)
+ [IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する](#bp-preview-access)
+ [IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する](#best-practice-policy-validation)
+ [複数のアカウントにまたがるアクセス許可のガードレールを確立する](#bp-permissions-guardrails)
+ [アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する](#bp-permissions-boundaries)

## 人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする
<a name="bp-users-federation-idp"></a>

人間のユーザーとは、*別名人間 ID* と呼ばれ、人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。人間のユーザーは AWS の環境とアプリケーションにアクセスするための ID を持っている必要があります。組織のメンバーである人間のユーザーは、*ワークフォースアイデンティティ*とも呼ばれます。人間のユーザーには、あなたと共同作業を行う外部ユーザーや、あなたの AWS のリソースを操作する外部ユーザーも含まれます。この操作は、ウェブブラウザ、クライアントアプリケーション、モバイルアプリ、またはインタラクティブなコマンドラインツールを介して実行できます。

人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用が必要です。一時的な資格情報を提供するロールを引き受けることで、人間のユーザーの ID プロバイダーを使用した AWS アカウント へのフェデレーションアクセスが可能になります。一元的なアクセス管理を行うには、[AWS IAM アイデンティティセンター (IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) を使用して、ご自分のアカウントへのアクセスと、それらのアカウント内でのアクセス許可を管理することをお勧めします。ユーザー ID を、IAM Identity Center を使用して管理することも、外部 ID プロバイダーから、IAM Identity Center 内のユーザー ID に付与するアクセス許可を管理することもできます。詳細については、「[AWS IAM アイデンティティセンター ユーザーガイド](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」の「*AWS IAM アイデンティティセンター とは?*」を参照してください。

ロールの詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」をご参照ください。

## ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする
<a name="bp-workloads-use-roles"></a>

*ワークロード*とは、アプリケーションやバックエンドプロセスなど、ビジネス価値を提供するリソースやコードの集合体のことです。ワークロードには、Amazon S3からデータを読み取るリクエストなど、AWS のサービス へのリクエストを行うために認証情報を必要とするアプリケーション、運用ツール、コンポーネントが含まれる場合があります。

Amazon EC2 や Lambda などの AWS コンピューティングサービスで を構築する場合、AWS はそのコンピューティングリソースに IAM ロールの一時的な認証情報を配信します。AWS SDK を使用して記述されたアプリケーションは、これらの一時的な認証情報を検出して使用して AWS リソースにアクセスします。そのため、AWS で実行されているワークロードに IAM ユーザーの長期的な認証情報を配布する必要はありません。

オンプレミスサーバー、他のクラウドプロバイダーのサーバー、マネージド継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームなど、AWS 環境外で実行されるワークロードは、引き続き一時的な認証情報を使用できます。ただし、これらの一時的な認証情報をワークロードに提供する必要があります。ワークロードに一時的な認証情報を提供する方法は次のとおりです。
+ IAM Roles Anywhere を使用して、パブリックキーインフラストラクチャ (PKI) から X.509 証明書を使用してワークロードの一時的な AWS 認証情報をリクエストできます。
+ AWS AWS STS`AssumeRoleWithSAML` API を呼び出して、AWS アカウント 内で設定された外部 ID プロバイダー (IdP) からの SAML アサーションを使用して、ワークロードの一時的な AWS 認証情報をリクエストできます\$1。
+ AWS AWS STS `AssumeRoleWithWebIdentity` API を呼び出して、AWS アカウント 内で設定された IdP から JSON ウェブトークン (JWT) を使用してワークロードの一時的な AWS 認証情報をリクエストできます。
+ AWS IoT Core を使用して、相互 Transport Layer Security (MTLS) 認証を使用して IoT デバイスから一時的な AWS 認証情報をリクエストできます。

一部の AWS のサービス は、AWS 環境外で実行されているワークロードに一時的な認証情報を配信するための統合もサポートしています。
+ [Amazon Elastic Container Service (Amazon ECS) Anywhere](https://aws.amazon.com/ecs/anywhere/) を使用すると、独自のコンピューティングリソースで Amazon ECS タスクを実行し、それらのコンピューティングリソースで実行されている Amazon ECS タスクに一時的な AWS 認証情報を配信できます。
+ [Amazon Elastic Kubernetes Service Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-overview.html) では、AWS 環境外で実行されているコンピューティングリソースをノードとして Amazon EKS クラスターに結合できます。Amazon EKS は、コンピューティングリソースで実行されている Amazon EKS ポッドに一時的な認証情報を提供できます。
+ [AWS Systems ManagerHybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html) では、SSM を使用して AWS 環境外で実行されているコンピューティングリソースを管理し、コンピューティングリソースで実行されている SSM エージェントに一時的な AWS 認証情報を配信できます。

## 多要素認証 (MFA) を必須とする
<a name="enable-mfa-for-privileged-users"></a>

AWS リソースにアクセスする人間のユーザーとワークロードの IAM ロールを使用して、一時的な認証情報を使用することをお勧めします。ただし、アカウントに IAM ユーザー またはルートユーザーが必要なシナリオでは、セキュリティを強化するために MFA が必要になります。MFA では、ユーザーは認証チャレンジに対するレスポンスを生成するデバイスを所有します。サインインプロセスを完了するには、各ユーザーの認証情報とデバイス生成のレスポンスの両方が必要です。詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。可能な限り、パスキーやセキュリティキーなどのフィッシング耐性のある MFA を使用することをお勧めします。詳細については、「[AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる](id_credentials_mfa_enable_fido.md)」を参照してください。

IAM Identity Center を使用して人間のユーザーによるアクセスを一元的に管理する場合、ID ソースが IAM Identity Center の ID ストア、AWS 管理の Managed Microsoft AD、または AD Connector で設定されていれば、 IAM Identity Center の MFA 機能を使用することができます。IAM Identity Center での MFA の詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[多要素認証](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)」を参照してください。

## 長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する
<a name="update-access-keys"></a>

可能であれば、アクセスキーなどの長期的な認証情報を作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、プログラムによるアクセスと長期的な認証情報を持つ IAM ユーザーが必要なシナリオでは、従業員が退職したときなど、必要に応じてアクセスキーを更新することをお勧めします。*IAM アクセス最終使用者情報*を利用して、アクセスキーを安全に更新して削除することをお勧めします。詳細については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。

AWS の IAM ユーザーとの長期的な認証情報が必要な特定のユースケースがあります。ユースケースには次のようなものがあります。
+ **IAM ロールを使用できないワークロード** – AWS へのアクセスが必要な場所から、ワークロードを実行する場合があります。状況によっては、IAM ロールを使用して WordPress プラグインなどに対して一時的な認証情報を提供することができない場合もあります。このような状況では、そのワークロードに対して IAM ユーザーの長期的なアクセスキーを使用して、AWS への認証を行います。
+ **サードパーティー AWS クライアント** – IAM Identity Center を使用したアクセスがサポートされていないツール (AWS でホストされていないサードパーティー AWS クライアントまたはベンダーなど) を使用している場合は、IAM ユーザーの長期的なアクセスキーを使用します。
+ **AWS CodeCommit アクセス** — CodeCommit を使用してコードを保存している場合、CodeCommit の SSH キーまたはサービス固有の認証情報を持つ IAM ユーザーを使用して、リポジトリへの認証を行うことができます。通常の認証に IAM Identity Center のユーザーを使用することに加えて、これを行うことをお勧めします。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。IAM ユーザーを設定せずに CodeCommit リポジトリへのアクセス許可をユーザーに付与するには、**git-remote-codecommit** ユーティリティを設定します。IAM および CodeCommit の詳細については、「[CodeCommit の IAM 認証情報: Git 認証情報、SSH キー、および AWS アクセス キー](id_credentials_ssh-keys.md)」を参照してください。**git-remote-codecommit** ユーティリティの設定についての詳細は、*AWS CodeCommit ユーザーガイド*の「[認証情報のローテーションを使用した AWS CodeCommit リポジトリへの接続](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials)」を参照してください。
+ **Amazon Keyspaces (Apache Cassandra 向け) へのアクセス** – IAM Identity Center 内のユーザーを使用できない状況 (Cassandra との互換性をテストする場合など) では、サービス専用の認証情報を持つ IAM ユーザーを使用して Amazon Keyspaces で認証できます。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。一時的な認証情報を使用して Amazon Keyspaces に接続することもできます。詳細については、「*Amazon Keyspaces (Apache Cassandra 向け) デベロッパーガイド*」の「[一時的な認証情報を使用して IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続する](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM)」を参照してください。

## ルートユーザーの認証情報を保護するためのベストプラクティスに沿う
<a name="lock-away-credentials"></a>

AWS アカウント を作成すると、AWS マネジメントコンソール にサインするためのルートユーザーの認証情報が設定されます。他の機密性の高い個人情報を保護するのと同じ方法で、ルートユーザーの認証情報を保護します。ルートユーザープロセスを保護してスケールする方法の詳細については、「[AWS アカウントのルートユーザーのベストプラクティス](root-user-best-practices.md)」を参照してください。

## 最小特権アクセス許可を適用する
<a name="grant-least-privilege"></a>

IAM ポリシーでアクセス許可を設定するときは、タスクの実行に必要なアクセス許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、*最小特権アクセス許可*とも呼ばれています。その際、ワークロードやユースケースに必要なアクセス許可を検討しながら、大まかなアクセス許可から始めるとよいでしょう。ユースケースが成熟してきたら、最小特権になるように付与する権限を減らしていくことができます。IAM を使用してアクセス許可を適用する方法については、「[AWS Identity and Access Management でのポリシーとアクセス許可](access_policies.md)」を参照してください。

## AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する
<a name="bp-use-aws-defined-policies"></a>

ユーザーやワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースに対してアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウント で使用できます。AWS 管理ポリシーは、すべての AWS のユーザーが使用できるため、特定のユースケースに対して最小特権のアクセス許可が付与されない場合があることに留意してください。そのため、ユースケースに応じた[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、「[AWS マネージドポリシー](access_policies_managed-vs-inline.md#aws-managed-policies)」を参照してください。特定のジョブ機能用に設計された AWS 管理ポリシーの詳細については、[AWSジョブ機能の 管理ポリシー](access_policies_job-functions.md) を参照してください。

## IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する
<a name="bp-gen-least-privilege-policies"></a>

タスクの実行に必要なアクセス許可のみを付与するには、AWS CloudTrail にログインしているアクセスアクティビティに基づいてポリシーを生成することができます。[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) は、IAM ロールが使用するサービスとアクションを分析し、使用可能な詳細なポリシーを生成します。生成された各ポリシーをテストしたら、ポリシーを本番環境にデプロイできます。これにより、ワークロードに必要なアクセス許可のみが付与されます。ポリシー生成の詳細については、「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。

## 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する
<a name="remove-credentials"></a>

AWS アカウント には、必要なくなった IAM ユーザー、ロール、アクセス許可、ポリシー、または認証情報がある可能性があります。IAM から提供される*最後にアクセスした情報*をもとに、この情報から不要になったユーザー、ロール、アクセス許可、ポリシー、および認証情報を特定し、削除できます。これにより、監視する必要のあるユーザー、ロール、アクセス許可、ポリシー、および認証情報の数を減らすことができます。この情報をもとに、最小特権のアクセス許可により適切に準拠できるように IAM ポリシーを調整することもできます。詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。

## IAM ポリシーで条件を指定して、アクセスをさらに制限する
<a name="use-policy-conditions"></a>

ポリシーステートメントが有効になる条件を指定することができます。これにより、アクションやリソースへのアクセスを許可することができますが、これは、アクセスのリクエストが特定の条件を満たしている場合に限られます。例えば、ポリシー条件を記述して、すべてのリクエストを TLS を使用して送信するように指定できます。また、条件を使用してサービスアクションへのアクセスを許可することもできますが、これは、CloudFormation などの特定の AWS のサービス を介して使用する場合に限られます。詳細については、「[IAM JSON ポリシー要素Condition](reference_policies_elements_condition.md)」を参照してください。

## IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する
<a name="bp-preview-access"></a>

AWS でパブリックアクセスまたはクロスアカウントアクセスのアクセス許可を付与する前に、そのアクセス許可が必要かどうかを確認することをお勧めします。IAM Access Analyzer を使用すると、サポートされているリソースタイプのパブリックアクセスとクロスアカウントアクセスをプレビューおよび分析できます。これを行うには、IAM Access Analyzer が生成する[調査結果](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)を確認します。これらの調査結果から、リソースアクセス制御が期待した通りにアクセスを許可しているかどうかを確認できます。さらに、パブリックおよびクロスアカウントのアクセス許可を更新すると、リソースに新しいアクセス制御をデプロイする前に、変更の効果を検証できます。また、IAM Access Analyzer は、サポートされているリソースタイプを継続的に監視し、パブリックアクセスまたはクロスアカウントアクセスを許可するリソースの調査結果を生成します。詳細については、「[Previewing access with IAM Access Analyzer APIs](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-preview-access-apis.html)」(IAM Access Analyzer API を使用したアクセスのプレビュー) を参照してください。

## IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する
<a name="best-practice-policy-validation"></a>

作成したポリシーを検証して、ポリシーが [IAM ポリシー言語](access_policies.md#access_policies-json) (JSON) と IAM のベストプラクティスに準拠していることを確認します。IAM Access Analyzer ポリシーチェックを使用して、ポリシーを検証できます。IAM Access Analyzer は 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーを作成できるようサポートします。コンソールで新しいポリシーをの作成や、既存のポリシーの編集を行う際に、IAM Access Analyzer は、ポリシーが保存される前にポリシーを調整して検証するのに役立つ推奨事項を提供します。既存のポリシーをすべて見直し、検証することをお勧めします。詳細については、「[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)」を参照してください。IAM Access Analyzer が提供するポリシーチェックの詳細については、「[IAM Access Analyzer ポリシーチェックリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html)」を参照してください。

## 複数のアカウントにまたがるアクセス許可のガードレールを確立する
<a name="bp-permissions-guardrails"></a>

ワークロードをスケールするときは、AWS Organizations で管理されている複数のアカウントを使用してワークロードを分離します。AWS Organizations の[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) を使用して、アカウント全体のすべてのプリンシパル (IAM ロールとユーザー) のアクセスを制御するための許可ガードレールを確立することをお勧めします。AWS Organizations の[リソースコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) (RCP) を使用して、組織全体の AWS リソースについてのアクセスを制御する許可ガードレールを確立することをお勧めします。SCP と RCP は、AWS 組織、組織単位 (OU)、またはアカウントレベルで組織内の許可を管理するために使用できる組織ポリシーの一種です。

ただし、SCP と RCP だけでは、組織内のプリンシパルとリソースに許可を付与するには不十分です。SCP および RCP によって許可は付与されません。許可を付与するには、IAM ユーザー、IAM ロール、またはアカウント内のリソースに [ID ベースまたはリソースベースのポリシー](access_policies_identity-vs-resource.md)をアタッチする必要があります。詳細については、「[SRA building blocks – AWS Organizations, accounts, and guardrails](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/organizations.html)」を参照してください。

## アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する
<a name="bp-permissions-boundaries"></a>

シナリオによっては、アカウント内のアクセス許可の管理を他の人に委任する場合があります。例えば、デベロッパーが自分のワークロードのロールを作成および管理できるようにすることができます。アクセス許可を他のユーザーに委任するときは、*アクセス権限の境界*を使用して、委任する権限の上限を設定します。アクセス許可の境界は、管理ポリシーを使用してアイデンティティベースのポリシーが IAM ロールに付与できるアクセス許可の上限を設定する高度な機能です。アクセス許可の境界自体は、アクセス許可を付与しません。詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」を参照してください。