AWS ID 管理の概要: ユーザー
AWS アカウント への特定のユーザーにアクセス権を付与し、そのユーザーに AWS アカウント 内のリソースにアクセスするための特定の権限を与えることができます。IAM と AWS IAM Identity Center の両方を使用して、新しいユーザーを作成したり、既存のユーザーを AWS にフェデレートしたりできます。この 2 つの主な違いは、IAM ユーザーには AWS リソースへの長期認証情報が付与されるのに対し、IAM Identity Center のユーザーにはユーザーが AWS にサインインするたびに確立される一時的な認証情報が付与されることです。ベストプラクティスとして、一時的な認証情報の使用により AWS にアクセスするには、人間のユーザーに対して IAM ユーザーではなく ID プロバイダーとのフェデレーションの使用を必須とします。IAM ユーザーは主に、IAM ロールを使用できないワークロードに AWS のサービスに対して API または CLI を使用したプログラムによるリクエストを可能にする場合に使用します。
初回アクセスのみ: ルートユーザーの認証情報
AWS アカウント を作成する場合、このアカウントのすべての AWS のサービス とリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。このアイデンティティは AWS アカウントのルートユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインすることによってアクセスできます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザーの認証情報を保護し、それらを使用してルートユーザーのみが実行できるタスクを実行してください。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「IAM ユーザーガイド」の「ルートユーザー認証情報が必要なタスク」を参照してください。ルートユーザーに付与されるアクセス許可を制限できるのは、組織内のサービスコントロールポリシー (SCP) のみです。
IAM ユーザーと IAM Identity Center 内のユーザー
IAM ユーザーは個別のアカウントではなく、アカウント内のユーザーです。各ユーザーには、AWS Management Console にアクセスするための、独自のパスワードを割り当てることができます。また各ユーザーには、お客様のアカウントのリソースをプログラムによりリクエストできるように、個別のアクセスキーを作成できます。
IAM ユーザーには、AWS リソースへの長期的な認証情報が付与されます。ベストプラクティスとして、ヒューマンユーザー用の長期認証情報を使用して IAM ユーザーを作成しないでください。代わりに、人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用が必要です。
注記
プログラムによるアクセスや長期的な認証情報を持つ IAM ユーザーが必要なシナリオでは、必要な時にアクセスキーを更新することをお勧めします。詳細については、「アクセスキーの更新」を参照してください。
対照的に、AWS IAM アイデンティティセンターのユーザー には、AWS リソースに短期間の認証が付与されます。一元的なアクセス管理を行うには、AWS IAM Identity Center (IAM Identity Center) を使用して、ご自分のアカウントへのアクセスと、それらのアカウント内でのアクセス許可を管理することをお勧めします。IAM Identity Center は、デフォルトの ID ソースとして Identity Center ディレクトリで自動的に設定され、ユーザーやグループを作成し、AWS リソースへのアクセスレベルを割り当てることができます。詳細については、AWS IAM Identity Center ユーザーガイドの AWS IAM Identity Center とは を参照してください。
既存のユーザーのフェデレーション
組織内のユーザーが、企業ネットワークにサインインするなどして認証される方法を既に持っている場合、個別の IAM ユーザーまたは IAM Identity Center でそれらのユーザーを作成する必要はありません。代わりに、IAM または AWS IAM Identity Center のいずれかを使用して、これらのユーザー ID を AWS にフェデレートすることができます。
以下の図では、ユーザーが一時的に AWS セキュリティ認証情報を取得する方法を示しています。この情報により、ユーザーは AWS アカウント のリソースにアクセスできるようになります。
フェデレーションは以下の場合に特に便利です。
-
ユーザーがすでに社内ディレクトリに所有している。
社内ディレクトリが Security Assertion Markup Language 2.0 (SAML 2.0) と互換性がある場合は、ユーザーに AWS Management Console へのシングルサインオン (SSO) アクセスを許可するように、社内ディレクトリを設定できます。詳細については、「一時的な認証情報の一般的なシナリオ」を参照してください。
社内ディレクトリが SAML 2.0 と互換性がない場合は、ユーザーに AWS Management Console へのシングルサインオン (SSO) アクセスを許可するために、ID ブローカーアプリケーションを作成できます。詳細については、「カスタム ID ブローカーに対する AWS コンソールへのアクセスの許可」を参照してください。
社内ディレクトリが Microsoft Active Directory である場合は、AWS IAM Identity Center を使用して、Active Directory の自己管理型ディレクトリや「AWS Directory Service
」のディレクトリを接続し、社内ディレクトリと AWS アカウント との間で信頼関係を確立できます。 Okta や Microsoft Entra などの外部 ID プロバイダー (IdP) を使用してユーザーを管理している場合は、AWS IAM Identity Center を使用して IdP と AWS アカウント 間の信頼を確立できます。詳細については、AWS IAM Identity Center ユーザーガイドの「外部の ID プロバイダーに接続」を参照してください。
-
ユーザーがすでにインターネットの ID を所有している。
作成するモバイルアプリケーションやウェブベースのアプリケーションで、Login with Amazon、Facebook、Google などの OpenID Connect (OIDC) 互換 ID プロバイダーのようなインターネット ID プロバイダーから、ユーザーがログインして認証されるようにする場合、アプリケーションからフェデレーションを使用して AWS へのアクセスが可能になります。詳細については、「OIDC フェデレーション」を参照してください。
ヒント
インターネット ID プロバイダーによる ID フェデレーションを使用するには、Amazon Cognito を使用することをお勧めします。
アクセスコントロール方法
ここでは、AWS リソースへのアクセスをコントロールする方法について説明します。
| ユーザーアクセスのタイプ | なぜ、使用するのか？ | どこで、詳細情報を取得できるか？ |
|---|---|---|
|
IAM Identity Center を使用した、従業員など人間のユーザーによる、AWS リソースに対するシングルサインオンでのアクセス |
IAM Identity Center はユーザーと AWS アカウント へのアクセス、クラウドアプリケーションの管理を一元化する場所を提供します。 IAM Identity Center 内に ID ストアを設定することも、既存の ID プロバイダー (IdP) とのフェデレーションを設定することもできます。セキュリティ上のベストプラクティスとしては、人間のユーザーに付与する AWS リソースに対する認証情報は、必要に応じて限定されたものであることが推奨されます。 これにより、ユーザーのサインインが簡素化されるとともに、リソースへのアクセスの管理を単一のシステムから実行できるようになります。IAM Identity Center では、追加のアカウントセキュリティとして多要素認証 (MFA) もサポートしています。 |
IAM Identity Center の設定の詳細については、「AWS IAM Identity Centerユーザーガイド」の「Getting Started」(使用開始) を参照してください。 IAM Identity Center での MFA の使用方法については、「AWS IAM Identity Center ユーザーガイド」の「Multi-factor authentication」(多要素認証) を参照してください。 |
IAM ID プロバイダーを使用した、従業員など人間のユーザーによる、AWS サービスに対するフェデレーションされたアクセス |
IAMは、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートします。IAM ID プロバイダーを作成したら、フェデレーションユーザーに動的割り当てが可能な、1 つ以上の IAM ロールを作成する必要があります。 |
IAM ID プロバイダーおよびフェデレーションの詳細については、「ID プロバイダーとフェデレーション」を参照してください。 |
|
AWS アカウント 間でのクロスアカウントアクセス |
特定の AWS リソースへのアクセスを、他の AWS アカウント のユーザーと共有したい場合があります。 クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の AWS サービスでは、リソースにポリシーを直接アタッチすることができます (ロールをプロキシとして使用する代わりに)。これらはリソースベースのポリシーと呼ばれます。 |
IAM ロールの詳細については、「IAM ロール」を参照してください。 サービスにリンクされたロールの詳細については、「サービスリンクロールの使用」を参照してください。 サービスにリンクされたロールの使用をサービスでサポートするには、「IAM と連携する AWS のサービス」を参照してください。[サービスにリンクされたロール] 列が「はい」になっているサービスを見つけます。サービスにリンクされたロールのドキュメントをサービスで表示するには、その列の「はい」に関連するリンクを選択します。 |
|
AWS アカウント の専有 IAM ユーザー向けの長期的な認証情報 |
特定のユースケースでは、AWS の IAM ユーザーに長期的な認証情報が必要となることがあります。これらの IAM ユーザーを AWS アカウント に作成するために IAM を使用し、また、そのユーザーのアクセス許可を IAM により管理できます。ユースケースには次のようなものがあります。
ベストプラクティスとして、プログラムによるアクセスと長期的な認証情報を持つ IAM ユーザーが必要なシナリオでは、必要な時にアクセスキーを更新することをお勧めします。詳細については、「アクセスキーの更新」を参照してください。 |
IAM ユーザー設定の詳細については、「AWS アカウント での IAM ユーザーの作成」を参照してください。 IAM ユーザーのアクセスキーの詳細については、「IAM ユーザーのアクセスキーの管理」を参照してください。 AWS CodeCommit または Amazon Keyspaces サービス固有の認証情報の詳細については、「CodeCommit での IAM の使用: Git 認証情報、SSH キー、および AWS アクセスキー」および「Amazon Keyspaces での IAM の使用（Apache Cassandra 用）」を参照してください。 |
