# IAM とは
AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。IAM は、AWS アカウントの認証と認可を制御するために必要なインフラストラクチャを提供します。
**ID**
AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
IAM を使用して、管理者、アナリスト、デベロッパーなどのルートユーザーに加えて他の ID をセットアップし、タスクを成功させるために必要なリソースへのアクセスを付与します。
**アクセス管理**
ユーザーが IAM でセットアップされると、サインイン認証情報を使用して AWS で認証されます。認証は、サインイン認証情報を AWS アカウント によって信頼されたプリンシパル (IAM ユーザー、AWS STS フェデレーティッドプリンシパル、IAM ロール、アプリケーション) と照合することで実行されます。次に、プリンシパルにリソースへのアクセスを許可するリクエストが行われます。ユーザーにリソースへのアクセス許可が付与されている場合、アクセスは認可リクエストに応じて付与されます。例えば、コンソールに初めてサインインしてコンソールのホームページを開いたときは、特定のサービスにアクセスしているわけではありません。サービスを選択すると、承認リクエストがそのサービスに送信され、ユーザーの ID が認可されたユーザーのリストに含まれているかどうか、付与されるアクセスレベルを制御するためにどのようなポリシーが適用されているか、そして、その他の有効なポリシーがないかが確認されます。承認リクエストは、AWS アカウント 内または信頼できる別の AWS アカウント プリンシパルが行うことができます。
承認されると、プリンシパルはユーザー内の AWS アカウント リソースに対してアクションを実行したり、操作を実行したりできます。例えば、プリンシパルは新しい Amazon Elastic Compute Cloud インスタンスを起動したり、IAM グループメンバーシップを変更したり、Amazon Simple Storage Service バケットを削除したりできます。
**ヒント**
AWS トレーニングと認定では、IAM の概要について説明する 10 分の動画を提供しています。
[AWS Identity and Access Management の概要](https://www.aws.training/learningobject/video?id=16448)
**サービスの可用性**
IAM は、他の多くの AWS サービスと同様に、[最終的に一貫性](https://wikipedia.org/wiki/Eventual_consistency)があります。IAM は、世界中の Amazon のデータセンター内の複数のサーバーにデータを複製することにより、高可用性を実現します。何らかのデータの変更リクエストが正常に受け付けられると、当該変更はコミットされ、安全に保管されます。ただし、変更は IAM 全体で複製される必要があり、これには多少時間がかかることがあります。このような変更には、ユーザー、グループ、ロール、またはポリシーの作成や更新が含まれます。アプリケーションの重要で高可用性のコードパスには、このような IAM の変更を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに IAM の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。詳細については、「[行った変更がすぐに表示されないことがある](troubleshoot.md#troubleshoot_general_eventual-consistency)」を参照してください。
**サービスのコストに関する情報**
AWS Identity and Access Management (IAM)、AWS IAM アイデンティティセンター および AWS Security Token Service (AWS STS) は、追加料金なしで提供される AWS アカウントの機能です。IAM ユーザーまたは AWS STS の一時的なセキュリティクレデンシャルを使用して他の AWS のサービスにアクセスした場合にのみ課金されます。
IAM Access Analyzer の外部アクセス分析は、追加料金なしで提供されます。ただし、未使用のアクセス分析とカスタマーポリシーチェックには料金がかかります。IAM Access Analyzer の料金および価格設定の完全なリストについては、「[IAM Access Analyzer pricing](https://aws.amazon.com/iam/access-analyzer/pricing)」を参照してください。
他の AWS 製品の料金設定については、[Amazon Web Services 料金設定ページ](https://aws.amazon.com/pricing/)を参照してください。
**他の AWS サービスとの統合**
IAM は多くの AWS サービスと統合されています。IAM と連携する AWS サービスのリストと、サービスがサポートする IAM 機能については、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。
# IAM を使用する理由
AWS Identity and Access Management は、AWS リソースへのアクセスを安全に管理するための強力なツールです。IAM を使用する主な利点の 1 つは、AWS アカウントへの共有アクセスを許可する機能です。さらに、IAM ではきめ細かなアクセス許可を割り当てることができるため、さまざまなユーザーが特定のリソースに対して実行できるアクションを正確に制御できます。このレベルのアクセスコントロールは、AWS 環境のセキュリティを維持する上で重要です。IAM には他にもいくつかのセキュリティ機能があります。保護を強化するために多要素認証 (MFA) を追加し、ID フェデレーションを活用することで、企業ネットワークや他の ID プロバイダーのユーザーをシームレスに統合できます。IAM は AWS CloudTrail とも統合されており、詳細なログ記録と ID 情報を提供し、監査とコンプライアンスの要件をサポートします。これらの機能を活用することで、重要な AWS リソースへのアクセスを厳密に制御し、安全を確保できます。
## AWS アカウント への共有アクセス
パスワードやアクセスキーを共有しなくても、お客様の AWS アカウントのリソースを管理および使用するためのアクセス許可を他の人に付与できます。
## 詳細なアクセス権限
リソースごとに、ユーザーごとに、さまざまなアクセス権限を付与できます。例えば、一部のユーザーは、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon Redshift、他の AWS のサービスへの完全なアクセスを許可する場合があります。他のユーザーには、一部の Amazon S3 バケットへの読み取り専用アクセス、一部の Amazon EC2 インスタンスのみへの管理アクセス、または請求情報のみへのアクセスを許可できます。
## Amazon EC2 で動作するアプリケーションから AWS リソースへの安全なアクセス
IAM の機能を使用して、EC2 インスタンスで実行されているアプリケーションの認証情報を安全に提供できます。これらの認証情報は、他の AWS リソースにアクセスするためにアプリケーションのアクセス許可を提供します。例として、S3 バケットや DynamoDB テーブルなどがあります。
## 多要素認証 (MFA)
アカウントおよび個々のユーザーに 2 エレメント認証を追加することで、セキュリティを強化できます。MFA を使用すると、ユーザーはお客様のアカウントで使用しているパスワードまたはアクセスキーの入力だけでなく、特別に設定されたデバイスからのコードの入力も必要になります。既に他のサービスで FIDO セキュリティキーを使用していて、AWS がサポートする設定がある場合、MFA セキュリティに WebAuthn を使用できます。詳細については、「[パスキーとセキュリティキーを使用するためのサポートされる設定](id_credentials_mfa_fido_supported_configurations)」を参照してください。
## ID フェデレーション
他の場所 (社内ネットワーク、インターネット ID プロバイダーなど) でパスワードを既に持つユーザーに、お客様の AWS アカウント への一時的なアクセスを許可できます。これらのユーザーには、IAM ベストプラクティスの推奨事項に準拠した一時的な認証情報が付与されます。ID フェデレーションを使用すると、AWS アカウントのセキュリティが向上します。
## 保証のための ID 情報
[AWS CloudTrail](https://aws.amazon.com/cloudtrail/) を使用している場合は、お客様のアカウントのリソースをリクエストしたユーザーに関する情報がログレコードに保存されます。その情報は IAM ID に基づきます。
## PCI DSS コンプライアンス
IAM は、マーチャントまたはサービスプロバイダーによるクレジットカードデータの処理、ストレージ、および伝送をサポートしており、Payment Card Industry (PCI) Data Security Standard (DSS) に準拠していることが確認されています。PCI DSS の詳細 (AWS PCI Compliance Package のコピーをリクエストする方法など) については、「[PCI DSS レベル 1](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)」を参照してください。
# IAM をいつ使用しますか？
AWS Identity and Access Management は、AWS 内部の ID に基づくアクセス制御の基盤を提供するコアインフラストラクチャサービスです。AWS アカウントにアクセスするたびに IAM を使用します。IAM の使用方法は、組織内の個々の責任と職務によって異なります。AWS サービスのユーザーは、管理者から適切な許可を付与されれば、IAM を使用して日常業務に必要な AWS リソースにアクセスできます。一方、IAM 管理者は、IAM ID を管理し、リソースへのアクセスを制御するポリシーを作成する責任があります。ロールにかかわらず、AWS リソースへのアクセスを認証および認可するときはいつでも IAM とやり取りすることになります。例えば、IAM ユーザーとしてサインインする、IAM ロールを引き受ける、ID フェデレーションを利用してシームレスなアクセスを行うなどの操作があげられます。AWS 環境への安全なアクセスを効果的に管理するには、さまざまな IAM 機能とユースケースを理解することが重要です。ポリシーとアクセス許可の作成に関しては、IAM は柔軟できめ細かなアプローチを提供します。信頼ポリシーを定義して、ユーザーまたはロールがアクセスできるアクションとリソースを指定する ID ベースのポリシーに加えて、ロールを引き受けることができるプリンシパルを制御できます。これらの IAM ポリシーを設定することで、必要なタスクを実行するための適切なレベルの許可がユーザーとアプリケーションに付与されるようにするのに役立ちます。
## さまざまな職務を遂行しているとき
AWS Identity and Access Management は、AWS 内部の ID に基づくアクセス制御の基盤を提供するコアインフラストラクチャサービスです。AWS アカウントにアクセスするたびに IAM を使用します。
IAM の用途は、AWS で行う作業によって異なります。
+ サービスユーザー – ジョブを実行するために AWS のサービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。より高度な機能を使用して仕事をするようになると、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者に適切なアクセス許可をリクエストするのに役に立ちます。
+ サービス管理者 - 社内で AWS リソースを担当している場合は、通常、IAM へのフルアクセスがあります。サービスのユーザーがどの IAM 機能やリソースにアクセスするかを決めるのは、管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。
+ IAM 管理者 – IAM 管理者であれば、IAM ID を管理し、IAM へのアクセスを管理するポリシーを記述できます。
## AWS リソースへのアクセスが許可されている場合
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、IAM ユーザー の AWS アカウントのルートユーザー として、または IAM ロールを引き受けることによって、認証される 必要があります。
AWS IAM アイデンティティセンター (IAM アイデンティティセンター)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
## IAM ユーザーとしてサインインした場合
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
## IAM ロールを引き受けるとき
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)、または AWS CLI や AWS API オペレーションを呼び出すことで、ロールを引き受けることができます。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーと許可を作成するとき
ポリシーを作成することで、ユーザーにアクセス許可を付与します。ポリシーは、ユーザーが実行できるアクションと、それらのアクションが影響を与えることができるリソースを登録したドキュメントです。明示的に許可されていないアクションやリソースはすべて、デフォルトで拒否されます。ポリシーは、プリンシパル (ユーザー、ユーザーグループ、ユーザーが引き受けるロール、およびリソース) に対して作成およびアタッチできます。
IAM ロールでは次のポリシーを使用できます。
+ **信頼ポリシー** — どの[プリンシパル](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal)がどのような条件でロールを引き受けることができるかを定義します。信頼ポリシーは、IAM ロール用の特定のタイプのリソースベースのポリシーです。ロールが持つことが可能な信頼ポリシーは 1 つのみです。
+ **ID ベースのポリシー (インラインおよび管理)** — これらのポリシーは、ロールのユーザーが実行できる (または実行が拒否される) 権限と、どのリソースに対して実行できるかを定義します。
[IAM アイデンティティベースのポリシーの例](access_policies_examples.md) を使用して、IAM ID のアクセス許可を定義するのに役立ちます。必要なポリシーを見つけたら、[View this policy (このポリシーを表示)] を選択してそのポリシーの JSON を表示します。JSON のポリシードキュメントをテンプレートとして使用して、独自のポリシーを作成できます。
**注記**
IAM Identity Center を使用してユーザーを管理している場合は、プリンシパルにアクセス許可ポリシーをアタッチするのではなく IAM ID Center で許可セットを割り当てます。アクセス許可セットをグループまたは AWS IAM アイデンティティセンターのユーザー に割り当てると、IAM Identity Center は、各アカウントに対応する IAM ロールを作成し、アクセス許可セットで指定されたポリシーをそれらのロールにアタッチします。IAM Identity Center がロールを管理し、定義した正規ユーザーがロールを引き受けることを可能にします。アクセス許可セットを変更すると、IAM Identity Center は、対応する IAM ポリシーとロールがそれに応じて更新されることを保証します。
IAM アイデンティティセンターの詳細については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」(IAM アイデンティティセンターとは) を参照してください。
# IAM の管理方法
AWS 環境内での AWS Identity and Access Management の管理には、さまざまなツールやインターフェイスの活用が含まれます。最も一般的な方法は、ユーザーとロールの作成からアクセス許可の設定まで、幅広い IAM 管理タスクを実行できるようにするウェブベースのインターフェイスである AWS マネジメントコンソール を使用することです。
コマンドラインインターフェイスを好むユーザー向けに、AWS には、AWS Command Line Interface と AWS Tools for Windows PowerShell の 2 つのコマンドラインツールセットが用意されています。これにより、IAM 関連のコマンドをターミナルから直接発行でき、コンソールを操作するよりも効率的です。さらに、AWS CloudShell では、コンソールのサインインに関連付けられたアクセス許可を使用して、ウェブブラウザから直接 CLI または SDK コマンドを実行できます。
コンソールとコマンドライン以外にも、AWS はさまざまなプログラミング言語用の Software Development Kit (SDK) を提供しており、IAM 管理機能をアプリケーションに直接統合できます。また、サービスに HTTPS リクエストを直接発行できる IAM Query API を使用して、プログラムにより IAM にアクセスできます。これらのさまざまな管理アプローチを活用することで、既存のワークフローやプロセスに IAM を柔軟に組み込むことができます。
## AWS マネジメントコンソール の使用
AWS 管理コンソールは、AWS リソースを管理するためのサービスコンソールの広範なコレクションで構成され、そのコレクションを参照するウェブアプリケーションです。最初にサインインすると、コンソールのホームページが表示されます。各サービスコンソールにアクセスできるホームページは、AWS に関連するタスクを実行するための情報にアクセスするための単一の場所として機能します。コンソールにサインインした後に、どのサービスとアプリケーションを利用できるようになるかは、アクセス権限を持っている AWS リソースによって異なります。リソースへのアクセス許可は、ロールを引き受けるか、権限を付与されたグループのメンバーになるか、明示的に権限を付与されるかのいずれかによって付与されます。スタンドアロン AWS アカウントでは、ルートユーザーまたは IAM 管理者がリソースへのアクセスを設定します。AWS Organizations では、管理アカウントまたは委任管理者がリソースへのアクセスを設定します。
AWS Management Console を使用して AWS リソースを管理する予定の場合は、セキュリティ上の[ベストプラクティス](best-practices.md)として、一時的な認証情報を使用してユーザーを設定することをおすすめします。ロール、フェデレーティッドプリンシパル、IAM ID センターのユーザーを引き受けた IAM ユーザーには一時的な認証情報がある一方、IAM ユーザーおよびルートユーザーには長期的な認証情報があります。ルートユーザーの認証情報は AWS アカウント へのフルアクセスを提供し、他のユーザーは IAM ポリシーによって付与されたリソースへのアクセスを提供する認証情報を持っています。
サインインの操作は、AWS マネジメントコンソール ユーザーのタイプによって異なります。
+ IAM ユーザーとルートユーザーは、メインの AWS サインイン URL (https://signin.aws.amazon.com) からサインインします。サインインすると、権限が付与されているアカウントのリソースにアクセスできるようになります。
ルートユーザーとしてサインインするには、ルートユーザーのメールアドレスとパスワードが必要です。
IAM ユーザーとしてサインインするには、AWS アカウント 番号またはエイリアス、IAM ユーザー名、IAM ユーザーパスワードが必要です。
アカウント内の IAM ユーザーは、緊急アクセスなど、長期的な認証情報を必要とする特定の状況に限定し、ルートユーザーは[ルートユーザーの認証情報を必要とするタスク](id_root-user.md#root-user-tasks)にのみ使用することをおすすめします。
利便性のため、AWS サインインページはブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。次回、ユーザーが任意のページに移動したとき、AWS マネジメントコンソール コンソールは Cookie を使用して、ユーザーをアカウントのサインインページにリダイレクトします。
セッションが終了したらコンソールからサインアウトして、前回のサインインが再利用されないようにします。
+ IAM Identity Center ユーザーは、組織固有の特定の AWS アクセスポータルを使用してサインインします。サインインすると、アクセスするアカウントまたはアプリケーションを選択できます。アカウントにアクセスする場合は、管理セッションに使用するアクセス許可セットを選択します。
+ カスタムのエンタープライズアクセスポータルを使用して AWS アカウント サインインにリンクされている、外部 ID プロバイダーで管理された OIDC および SAML のフェデレーティッドプリンシパル。ユーザーが利用できる AWS リソースは、組織によって選択されたポリシーに依存します。
**注記**
セキュリティレベルを高めるために、ルートユーザー、IAM ユーザー、IAM Identity Center のユーザーは、AWS リソースへのアクセスを許可する前に AWS による多要素認証 (MFA) の検証を受けることができます。MFA が有効になっている場合は、サインインするために MFA デバイスへのアクセス権も必要となります。
さまざまなユーザーが管理コンソールにサインインする方法について詳しくは、AWS サインインユーザーガイドの「[AWS 管理コンソールへのサインイン](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)」を参照してください。
## AWS コマンドラインツール
AWS コマンドラインツールを使用して、システムのコマンドラインでコマンドを発行することで、 IAM および AWS タスクを実行できます。コマンドラインを使用すると、コンソールよりも高速で便利になります。コマンドラインツールは、AWS のタスクを実行するスクリプトを作成する場合にも便利です。
AWS には、[AWS Command Line Interface](https://aws.amazon.com/cli/) (AWS CLI) と[AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/)という 2 セットのコマンドラインツールが用意されています。AWS CLI のインストールおよび使用の方法については、[AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/)を参照してください。Tools for Windows PowerShell のインストールおよび使用の方法については、[AWS Tools for PowerShellユーザーガイド](https://docs.aws.amazon.com/powershell/latest/userguide/)を参照してください。
コンソールにサインインすると、ブラウザから AWS CloudShell を使用して CLI または SDK コマンドを実行できます。AWS リソースにアクセスするためのアクセス許可は、コンソールへのサインインに使用した認証情報に基づいています。経験によっては、CLI の方がより効率的な AWS アカウント の管理方法である場合があります。詳細については、[AWS CloudShell を使用した AWS Identity and Access Management との連携](using-aws-with-cloudshell.md)を参照してください。
### AWS コマンドラインインターフェイス (CLI) と Software Development Kit (SDK)
IAM Identity Center と IAM ユーザーは、CLI または関連する SDK のアプリケーションインターフェイス (API) を使用して認証を行う場合、異なる方法を使用して認証情報を認証します。
認証情報と構成設定は、システム環境変数、ユーザー環境変数、ローカルの AWS 設定ファイルなど複数の場所にあり、コマンドラインでパラメータとして明示的に宣言される場合もあります。特定の場所が他の場所よりも優先されます。
IAM Identity Center と IAM はどちらも CLI または SDK で使用できるアクセスキーを提供します。IAM Identity Center アクセスキーは、自動的に更新できる一時的な認証情報であり、IAM ユーザーに関連する長期的なアクセスキーよりも推奨されます。
CLI または SDK を使用して AWS アカウント を管理するには、ブラウザから AWS CloudShell を使用できます。CloudShell を使用して CLI または SDK コマンドを実行する場合は、まずコンソールにサインインする必要があります。AWS リソースにアクセスするためのアクセス許可は、コンソールへのサインインに使用した認証情報に基づいています。経験によっては、CLI の方がより効率的な AWS アカウント の管理方法である場合があります。
アプリケーション開発では、CLI または SDK をコンピューターにダウンロードし、コマンドプロンプトまたは Docker ウィンドウからサインインできます。このシナリオでは、CLI スクリプトまたは SDK アプリケーションの一部として認証情報とアクセス認証情報を設定します。環境と利用可能なアクセス許可に応じて、リソースへのプログラムによるアクセスはさまざまな方法で設定できます。
+ AWS サービスを使用してローカルコードを認証するための推奨オプションは、IAM ID センターと IAM Roles Anywhere です。
+ AWS 環境内で実行されるコードを認証するための推奨オプションは、IAM ロールを使用するか、IAM Identity Center 認証情報を使用することです。
AWS アクセスポータルを使用してサインインする場合、アクセス許可セットを選択する場所のスタートページから短期的な認証情報を取得できます。これらの認証情報には有効期限が定義されており、自動的に更新されることはありません。これらの認証情報を使用する場合は、AWS ポータルにサインインした後に、AWS アカウント を選択し、権限セットを選択します。**[コマンドラインまたはプログラムによるアクセス]** を選択すると、プログラムまたは CLI から AWS リソースにアクセスするために使用できるオプションが表示されます。これらの方法の詳細については、IAM Identity Center ユーザーガイドの「[一時的な認証情報の取得と更新](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html#how-to-get-temp-credentials)」を参照してください。これらの認証情報は、アプリケーションの開発中にコードをすばやくテストするためによく使用されます。
AWS リソースへのアクセスを自動化すると自動的に更新される IAM Identity Center 認証情報を使用することをお勧めします。IAM Identity Center でユーザーと権限セットを設定している場合、`aws configure sso` コマンドを使ってコマンドラインウィザードを使用すると、利用可能な認証情報を特定してプロファイルに保存できます。プロファイルの設定について詳しくは、バージョン 2 用 AWS コマンドラインインターフェイスユーザーガイドの「[`aws configure sso` ウィザードによるプロファイルの設定](https://docs.aws.amazon.com/cli/latest/userguide/sso-configure-profile-token.html#sso-configure-profile-token-auto-sso)」を参照してください。
**注記**
多くのサンプルアプリケーションでは、IAM ユーザーまたはルートユーザーに関連する長期アクセスキーを使用しています。長期的な認証情報は、学習演習の一環としてサンドボックス環境内でのみ使用してください。[長期的なアクセスキーの代替手段](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)を確認し、コードをできるだけ早く移行することで、IAM Identity Center 認証情報や IAM ロールなどの代替認証情報を使用するようにすることを計画してください。コードを移行したら、アクセスキーを削除します。
CLI の設定の詳細については、AWS コマンドラインインターフェイス (バージョン 2) ユーザーガイドの「[AWS CLI の最新バージョンをインストールまたは更新する](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および、AWS コマンドラインインターフェイスユーザーガイドの「[認証とアクセス認証情報](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html)」を参照してください。
SDK の設定について詳しくは、AWS SDK とツールリファレンスガイドの「[IAM Identity Center 認証](https://docs.aws.amazon.com/sdkref/latest/guide/access-sso.html)」および、AWS SDK とツールリファレンスガイドの「[IAM Roles Anywhere](https://docs.aws.amazon.com/sdkref/latest/guide/access-rolesanywhere.html)」を参照してください。
## AWS SDK の使用
AWS には、さまざまなプログラミング言語およびプラットフォーム (Java、Python、Ruby、.NET、iOS、Android など) のライブラリとサンプルコードで構成された SDK (ソフトウェア開発キット) が用意されています。SDK は、IAM や AWS へのプログラムによるアクセス権限を作成する際に役立ちます。例えば、SDK は要求への暗号を使用した署名、エラーの管理、要求の自動的な再試行などのタスクを処理します。AWS SDK のダウンロードやインストールなどの詳細については、「[Amazon Web Services のツール](https://aws.amazon.com/tools/)」ページを参照してください。
## IAM クエリ API の使用
サービスに HTTPS リクエストを直接発行できる IAM Query API を使用して、プログラムにより IAM と AWS にアクセスできます。Query API を使用する場合は、認証情報を使用してリクエストにデジタル署名するコードを含める必要があります。詳細については、「[HTTP クエリリクエストを使用した IAM API の呼び出し](programming.md) および [IAM API リファレンス](https://docs.aws.amazon.com/IAM/latest/APIReference/)」を参照してください。
# IAM の仕組み
AWS Identity and Access Management は、AWS アカウントの認証と認可を管理するために必要なインフラストラクチャを提供します。
まず、人間のユーザーまたはアプリケーションがサインイン認証情報を使用して AWS と認証します。IAM は、サインイン認証情報を AWS アカウント によって信頼されたプリンシパル (IAM ユーザー、AWS STS フェデレーションユーザー、IAM ロール、アプリケーション) と照合し、AWS にアクセスする許可を認証します。
次に、IAM はリソースへのアクセスをプリンシパルに付与するようリクエストします。IAM は、認可リクエストに応じてアクセスを許可または拒否します。例えば、コンソールに初めてサインインしてコンソールのホームページを開いたときは、特定のサービスにアクセスしているわけではありません。サービスを選択すると、そのサービスの IAM に認可リクエストを送信することになります。IAM は、認可されたユーザーのリストにユーザーの ID が含まれていることを検証し、付与されるアクセスレベルを制御するポリシーを決定して、有効な他のポリシーを評価します。AWS アカウント 内のプリンシパルまたは信頼する他の AWS アカウント は認可リクエストを実行できます。
認可されると、プリンシパルはユーザー内の AWS アカウント リソースに対してアクションや操作を実行したりできます。例えば、プリンシパルは新しい Amazon Elastic Compute Cloud インスタンスを起動したり、IAM グループメンバーシップを変更したり、Amazon Simple Storage Service バケットを削除したりできます。次の図は、IAM インフラストラクチャを通じたこのプロセスを示しています。
![\[この図は、プリンシパルが IAM サービスによって認証および認可され、他の AWS サービスまたはリソースに対してアクションまたはオペレーションを実行する方法を示しています。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/intro-diagram _policies_800.png)
## リクエストのコンポーネント
プリンシパルが AWS マネジメントコンソール、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS に*リクエスト*を送信します。リクエストには、以下の情報が含まれます。
+ **[アクションまたはオペレーション]** – プリンシパルが実行するアクションまたはオペレーション (AWS マネジメントコンソール のアクション、AWS CLI または AWS API のオペレーションなど)。
+ **リソース** – プリンシパルがアクションまたはオペレーションの実行をリクエストする AWS リソースオブジェクト。
+ **プリンシパル** – エンティティ (ユーザーまたはロール) を使用してリクエストを送信するユーザーまたはアプリケーション。プリンシパルに関する情報には、許可ポリシーが含まれます。
+ **環境データ** – IP アドレス、ユーザーエージェント、SSL 有効化ステータス、およびタイムスタンプに関する情報。
+ **[リソースデータ]** – DynamoDB テーブル名や Amazon EC2 インスタンスのタグなど、リクエストされたリソースに関連するデータ。
AWS は、リクエスト情報を*リクエストコンテキスト*内に収集します。IAM は、リクエストを認可するためにこれを評価します。
## プリンシパルの認証方法
プリンシパルは、認証情報を使用して AWS にサインインします。IAM は、プリンシパルが AWS にリクエストを送信するのを許可するためにこの認証情報を認証します。Amazon S3 や AWS STS などの特定のサービスは、匿名ユーザーからの少数のリクエストを許可します。ただし、これは例外的です。各タイプのユーザーは認証を通過します。
+ **[ルートユーザー]** – 認証に使用されるサインイン認証情報は、AWS アカウント を作成するために使用したメールアドレスと、その時点で指定したパスワードです。
+ **フェデレーティッドプリンシパル** – ID プロバイダーはユーザーを認証し、認証情報を AWS に渡します。AWS に直接サインインする必要はありません。IAM ID センターと IAM は両方とも ID フェデレーションをサポートします。
+ **AWS IAM アイデンティティセンターディレクトリ のユーザー** *(フェデレーションユーザーではない)* – IAM アイデンティティセンターのデフォルトディレクトリで直接作成されたユーザーは、AWS アクセスポータルを使用してサインインし、ユーザー名とパスワードを指定します。
+ **[IAM ユーザー]** – アカウント ID またはエイリアス、ユーザー名、パスワードを指定してサインインします。API または AWS CLI からワークロードを認証するには、ロールの引き受けを通じて一時的な認証情報を使用することも、アクセスキーとシークレットキーを指定して長期的な認証情報を使用することもできます。
IAM エンティティの詳細については、「[IAM ユーザー](id_users.md)」および「[IAM ロール](id_roles.md)」を参照してください。
AWS では､すべてのユーザーで多要素認証 (MFA) を使用して、アカウントのセキュリティを強化することを推奨しています。MFA の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。
## 認可と許可ポリシーの基本
認可とは、リクエストを完了するために必要な許可を持つプリンシパルをいいます。認可中に、IAM はリクエストコンテキストの値を使用して、リクエストに適用されるポリシーを識別します。次に、ポリシーを使用してリクエストの許可または拒否を決定します。IAM は、ほとんどの許可ポリシーを、プリンシパルエンティティ用の許可を指定する [JSON ドキュメント](access_policies.md#access_policies-json)として保存します。
認可リクエストに影響を及ぼす可能性のある[ポリシーにはいくつかの種類](access_policies.md)があります。アカウント内の AWS リソースにアクセスするための許可をユーザーに付与するには、ID ベースのポリシーを使用できます。リソースベースのポリシーにより、[クロスアカウントアクセス](access_permissions-required.md#UserPermissionsAcrossAccounts)を付与できます。別のアカウントでリクエストを作成するには、他のアカウントのポリシーでリソースへのアクセスを許可する必要があります。また、リクエストを作成するために使用する IAM エンティティには、リクエストを許可する ID ベースのポリシーが必要です。
IAM は、リクエストのコンテキストに該当する各ポリシーをチェックします。IAM ポリシー評価では明示的な拒否が使用されます。つまり、1 つの許可ポリシーに拒否されたアクションが含まれている場合、IAM はリクエスト全体を拒否し、評価を停止します。リクエストはデフォルトで拒否されるため、IAM がリクエストを認可するようにするには、適用可能な許可ポリシーでリクエストのすべての部分を許可する必要があります。単一アカウント内のリクエストの評価ロジックは、以下の基本的なルールに基づきます。
+ デフォルトでは、すべてのリクエストが拒否されます。(通常、AWS アカウントのルートユーザー 認証情報を使用したアカウントのリソースに対するリクエストは常に許可されます)。
+ アクセス許可ポリシー (アイデンティティベースまたはリソースベース) に明示的な許可が含まれている場合、このデフォルト設定は上書きされます。
+ AWS Organizations サービスコントロールポリシー (SCP) またはリソースコントロールポリシー (RCP)、IAM アクセス許可の境界、またはセッションポリシーが存在する場合、許可がオーバーライドされます。上記のポリシータイプが 1 つ以上存在する場合は、そのすべてにおいてリクエストが許可されている必要があります。それ以外の場合、リクエストは暗黙的に拒否されます。SCP および RCP の詳細については、「*AWS Organizations ユーザーガイド*」の「[Authorization policies in AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html)」を参照してください。
+ ポリシーにおける明示的な拒否は、ポリシーの許可をオーバーライドします。
詳細については[ポリシーの評価論理](reference_policies_evaluation-logic.md)を参照してください。
IAM がプリンシパルを認証および認可すると、IAM は、プリンシパルに適用される許可ポリシーを評価することで、リクエスト内のアクションまたはオペレーションを承認します。各 AWS サービスは、サポートするアクション (オペレーション) を定義し、リソースの表示、作成、編集、削除など、リソースに対して実行できる操作が含まれます。プリンシパルに適用される許可ポリシーには、オペレーションを実行するために必要なアクションが含まれている必要があります。IAM が許可ポリシーを評価する方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
サービスは、プリンシパルが各リソースに対して実行できる一連のアクションを定義します。許可ポリシーを作成する際には、ユーザーに実行させたいアクションを必ず含めてください。例えば、IAM は、ユーザーリソースに対して、次の基本的なアクションを含む 40 超のアクションをサポートしています。
+ `CreateUser`
+ `DeleteUser`
+ `GetUser`
+ `UpdateUser`
さらに、リクエストが指定された条件を満たすときにリソースへのアクセスを付与する旨の条件を許可ポリシーで指定できます。例えば、特定の日付よりも後にポリシーステートメントを有効にしたり、API に特定の値が表示されたときにアクセスを制御したりする必要がある場合があります。条件を指定するには、ポリシーステートメントの [`Condition`](reference_policies_elements_condition_operators.md) 要素を使用します。
IAM がリクエスト内のオペレーションを承認すると、プリンシパルはアカウント内の関連リソースを操作できるようになります。リソースは、サービス内に存在するオブジェクトです。例として、Amazon EC2 インスタンス、IAM ユーザー、Amazon S3 バケットなどがあります。プリンシパルが許可ポリシーに含まれていないリソースに対してアクションを実行するリクエストを作成すると、サービスはリクエストを拒否します。例えば、IAM ロールを削除するための許可はあるが、IAM グループを削除するための許可がない場合に、IAM グループの削除をリクエストすると、リクエストは失敗します。さまざまな AWS サービスがサポートするアクション、リソース、および条件キーの詳細については、「[Actions, Resources, and Condition Keys for AWS Services](reference_policies_actions-resources-contextkeys.html)」を参照してください。
# IAM ID と認証情報を比較する
AWS Identity and Access Management で管理される ID は、IAM ユーザー、IAM ロール、IAM グループです。これらの ID は、AWS が AWS アカウント とともに作成したルートユーザーに追加的なものです。
日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことを強くお勧めします。代わりに、追加のユーザーをプロビジョニングし、必要なタスクを実行するために必要なアクセス許可を付与します。ユーザーを追加するには、IAM アイデンティティセンターディレクトリに人々を追加するか、IAM アイデンティティセンターまたは IAM で外部 ID プロバイダーをフェデレーションするか、最小特権の IAM ユーザーを作成します。
セキュリティを強化するために、AWS Organizations を使用して管理される AWS アカウント のルートユーザー認証情報を一元的に保護するのに役立つよう、ルートアクセスを一元化することをお勧めします。[メンバーアカウントのルートアクセスを一元管理](id_root-user.md#id_root-user-access-management) を使用すると、長期的なルートユーザー認証情報を一元的に削除して、そのリカバリを防止し、意図しないルートアクセスを大規模に防止できます。一元化されたルートアクセスを有効にすると、特権セッションを引き受けてメンバーアカウントでアクションを実行できます。
ユーザーのセットアップ後、特定のユーザーに AWS アカウント へのアクセス権を付与し、そのユーザーにリソースへのアクセス許可を与えることができます。
[ベストプラクティス](best-practices.md)として、AWS では、人間のユーザーが一時的な認証情報を使用するように、IAM ロールを引き受けて AWS にアクセスすることを推奨しています。IAM Identity Center ディレクトリで ID を管理している場合、または ID プロバイダーとのフェデレーションを使用している場合は、ベストプラクティスに従っています。
## 用語
これらの用語は、IAM ID と連携する際によく使用されます。
**IAM リソース**
IAM サービスはこれらのリソースを保存します。コンソールから、追加、編集、削除できます。
+ IAM ユーザー
+ IAM グループ
+ IAM ロール
+ アクセス許可ポリシー
+ ID プロバイダーオブジェクト
**IAM エンティティ**
AWS が認証に使用する IAM リソース。リソースベースのポリシーで、エンティティをプリンシパルとして指定します。
+ IAM ユーザー
+ IAM ロール
**IAM ID**
アクションの実行とリソースへのアクセスを行うためにポリシーで認可される IAM リソース。アイデンティティには、IAM ユーザー、IAM グループ、および IAM ロールが含まれます。
![\[この図は、IAM ユーザーと IAM ロールがプリンシパルであり、かつ、エンティティと ID でもあるが、ルートユーザーはエンティティでも ID でもないプリンシパルであることを示しています。この図は、IAM グループが ID であることも示しています。IAM 認証はポリシーを使用して ID のアクセスを制御しますが、ルートユーザーは AWS リソースに対するフルアクセスを持っており、ID またはリソースベースの IAM ポリシーによって制限することはできません。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/iam-terms-2.png)
**プリンシパル**
AWS リソースに対するアクションまたはオペレーションをリクエストできる AWS アカウントのルートユーザー、IAM ユーザー、または IAM ロール。プリンシパルには、人間のユーザー、ワークロード、フェデレーティッドプリンシパル、引き受けたロールが含まれます。認証後、IAM は、プリンシパルのタイプに応じて、AWS にリクエストを実行するための永続的または一時的な認証情報をプリンシパルに付与します。
人間のユーザーとは、人間 ID とも呼ばれ、人々、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーなどをいいます。
ワークロードとは、アプリケーション、プロセス、運用ツール、他のコンポーネントなど、ビジネス価値を提供するリソースとコードのコレクションをいいます。
*フェデレーティッドプリンシパル*とは、ID および認証情報が Active Directory、Okta、Microsoft Entra などの別の ID プロバイダーによって管理されているユーザーを指します。
IAM ロールとは、ユーザーがアカウントで作成できる IAM ID をいい、その ID が実行できることとできないことを決定する特定の許可を持ちます。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。
IAM は、IAM ユーザーとルートユーザーに長期的な認証情報を付与し、IAM ロールには一時的な認証情報を付与します。AWS IAM アイデンティティセンターのユーザー、OIDC、SAML のフェデレーティッドプリンシパルは、AWS にサインインする際に IAM ロールを引き受けます。これにより、一時的な認証情報が付与されます。[ベストプラクティス](best-practices.md)として、人間のユーザーとワークロードに一時的な認証情報を使用して AWS のリソースにアクセスさせることをお勧めします。
## IAM アイデンティティセンターの IAM ユーザーとユーザーの違い
**IAM ユーザー**は個別のアカウントではなく、アカウント内の個別のユーザーです。各ユーザーには、AWS マネジメントコンソール にアクセスするための独自のパスワードがあります。また各ユーザーには、お客様のアカウントのリソースをプログラムによりリクエストできるように、個別のアクセスキーを作成できます。
IAM ユーザーとそのアクセスキーには、AWS リソースへの長期的な認証情報が付与されています。IAM ユーザーは主に、IAM ロールを使用できないワークロードに AWS のサービスに対して API または CLI を使用したプログラムによるリクエストを可能にする場合に使用します。
**注記**
プログラムによるアクセスや長期的な認証情報を持つ IAM ユーザーが必要なシナリオでは、必要な時にアクセスキーを更新することをお勧めします。詳細については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。
ワークフォース ID (人々) とは、実行しているロールに応じて異なる許可のニーズを持ち、組織全体のさまざまな ** で作業できる AWS IAM アイデンティティセンターのユーザー**AWS アカウント をいいます。アクセスキーを必要とするユースケースがある場合は、AWS IAM アイデンティティセンターのユーザー でそれらのユースケースをサポートできます。AWS アクセスポータルを通じてサインインする人々は、AWS リソースへの短期的な認証情報を使用してアクセスキーを取得できます。一元的なアクセス管理を行うには、[AWS IAM アイデンティティセンター (IAM Identity Center)](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) を使用して、ご自分のアカウントへのアクセスと、それらのアカウント内でのアクセス許可を管理することをお勧めします。IAM アイデンティティセンターは、デフォルトの ID ソースとして アイデンティティセンターディレクトリで自動的に設定され、人々やグループを追加し、AWS リソースへのアクセスレベルを割り当てることができます。詳細については、「[AWS IAM アイデンティティセンター ユーザーガイド](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」の「*AWS IAM アイデンティティセンター とは?*」を参照してください。
これらの 2 種類のユーザーの主な違いは、IAM アイデンティティセンターのユーザーが管理コンソールまたは AWS リソースにアクセスする前に AWS にサインインすると、自動的に IAM ロールを引き受けるという点です。IAM ロールは、ユーザーが AWS にサインインするたびに一時的な認証情報を付与します。IAM ユーザーが IAM ロールを使用してサインインするには、ロールを引き受けたり、ロールを切り替えたりするための許可が必要です。また、AWS アカウントにアクセスした後に引き受けるロールに切り替えることを明示的に選択する必要があります。
## 既存の ID ソースからユーザーをフェデレーションする
組織内のユーザーが企業ネットワークにサインインする際に既に認証されている場合は、そのユーザーのために個別の IAM ユーザーまたは IAM アイデンティティセンターのユーザーを作成する必要はありません。代わりに、IAM または AWS IAM アイデンティティセンター のいずれかを使用して、これらのユーザー ID を AWS にフェデレートすることができます。OIDC および SAML のフェデレーティッドプリンシパルは、特定のリソースにアクセスする許可を付与する IAM ロールを引き受けます。ロールの詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」をご参照ください。
![\[この図では、フェデレーティッドプリンシパルが一時的に AWS セキュリティ認証情報を取得し、ユーザーの AWS アカウント のリソースにアクセスできる方法が示されます。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/iam-intro-federation.diagram.png)
フェデレーションは、次の場合に便利です。
+ **ユーザーがすでに社内ディレクトリに所有している。**
社内ディレクトリが Security Assertion Markup Language 2.0 (SAML 2.0) と互換性がある場合は、ユーザーに AWS マネジメントコンソール へのシングルサインオン (SSO) アクセスを許可するように、社内ディレクトリを設定できます。詳細については、「[一時的な認証情報の一般的なシナリオ](id_credentials_temp.md#sts-introduction)」を参照してください。
社内ディレクトリが SAML 2.0 と互換性がない場合は、ユーザーに AWS マネジメントコンソール へのシングルサインオン (SSO) アクセスを許可するために、ID ブローカーアプリケーションを作成できます。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
社内ディレクトリが Microsoft Active Directory である場合は、AWS IAM アイデンティティセンター を使用して、Active Directory の自己管理型ディレクトリや「[AWS Directory Service](https://aws.amazon.com/directoryservice/)」のディレクトリを接続し、社内ディレクトリと AWS アカウント との間で信頼関係を確立できます。
Okta や Microsoft Entra などの外部 ID プロバイダー (IdP) を使用してユーザーを管理している場合は、AWS IAM アイデンティティセンター を使用して IdP と AWS アカウント 間の信頼を確立できます。詳細については、AWS IAM アイデンティティセンター ユーザーガイドの「[外部の ID プロバイダーに接続](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)」を参照してください。
+ **ユーザーがすでにインターネットの ID を所有している。**
作成するモバイルアプリケーションやウェブベースのアプリケーションで、Login with Amazon、Facebook、Google などの OpenID Connect (OIDC) 互換 ID プロバイダーのようなインターネット ID プロバイダーから、ユーザーがログインして認証されるようにする場合、アプリケーションからフェデレーションを使用して AWS へのアクセスが可能になります。詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。
**ヒント**
インターネット ID プロバイダーによる ID フェデレーションを使用するには、[Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) を使用することをお勧めします。
## ユーザーアクセスを提供するさまざまな方法
ここでは、AWS リソースへのアクセスを提供する方法について説明します。
****
| ユーザーアクセスのタイプ | 使用されるタイミング | 詳細 |
| --- | --- | --- |
| IAM アイデンティティセンターを使用した、ワークフォースユーザーなどの人々による、AWS リソースに対するシングルサインオンアクセス | IAM Identity Center はユーザーと AWS アカウント へのアクセス、クラウドアプリケーションの管理を一元化する場所を提供します。 IAM Identity Center 内に ID ストアを設定することも、既存の ID プロバイダー (IdP) とのフェデレーションを設定することもできます。セキュリティに関するベストプラクティスでは、AWS リソースに対する限定的な認証情報を人間のユーザーに付与することが推奨されています。 これにより、人々のサインインが簡素化されるとともに、リソースへのアクセスの管理を単一のシステムから実行できるようになります。IAM Identity Center では、追加のアカウントセキュリティとして多要素認証 (MFA) もサポートしています。 | IAM Identity Center の設定の詳細については、「AWS IAM アイデンティティセンターユーザーガイド」の「[Getting Started](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」(使用開始) を参照してください。 IAM Identity Center での MFA の使用方法については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)」(多要素認証) を参照してください。 |
| IAM ID プロバイダー (IdP) を使用した、従業員など人間のユーザーによる、AWS サービスに対するフェデレーテッドアクセス | IAMは、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポートします。IAM ID プロバイダーを作成した後、フェデレーティッドプリンシパルに動的に割り当てが可能な IAM ロールを 1 つ以上作成します。 | IAM ID プロバイダーおよびフェデレーションの詳細については、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。 |
| AWS アカウント 間でのクロスアカウントアクセス | 特定の AWS リソースへのアクセスを、他の AWS アカウント のユーザーと共有したい場合があります。 クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の AWS サービスは、(ロールをプロキシとして使用する代わりに) ポリシーをリソースに直接アタッチすることを許可するリソースベースのポリシーをサポートしています。 | IAM ロールの詳細については、「[IAM ロール](id_roles.md)」を参照してください。 サービスにリンクされたロールの詳細については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。 サービスにリンクされたロールの使用をサービスでサポートするには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを見つけます。サービスにリンクされたロールのドキュメントをサービスで表示するには、その列の「**はい**」に関連するリンクを選択します。 |
| AWS アカウント の専有 IAM ユーザー向けの長期的な認証情報 | 特定のユースケースでは、AWS の IAM ユーザーに長期的な認証情報が必要となることがあります。これらの IAM ユーザーを AWS アカウント に作成するために IAM を使用し、また、そのユーザーのアクセス許可を IAM により管理できます。ユースケースには次のようなものがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_identity-management.html) [ベストプラクティス](best-practices.md)として、[プログラムによるアクセスと長期的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)を持つ IAM ユーザーが必要なシナリオでは、必要な時にアクセスキーを更新することをお勧めします。詳細については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。 | IAM ユーザー設定の詳細については、「[AWS アカウント で IAM ユーザーを作成する](id_users_create.md)」を参照してください。 IAM ユーザーのアクセスキーの詳細については、「[IAM ユーザーのアクセスキーを管理します。](id_credentials_access-keys.md)」を参照してください。 AWS CodeCommit または Amazon Keyspaces サービス固有の認証情報の詳細については、「[CodeCommit の IAM 認証情報: Git 認証情報、SSH キー、および AWS アクセス キー](id_credentials_ssh-keys.md)」および「[Amazon Keyspaces で IAM を使用する（Apache Cassandra の場合）](id_credentials_keyspaces.md)」を参照してください。 |
## プログラムによるユーザーアクセスをサポートする
AWS マネジメントコンソールの外部で AWS を操作するには、プログラムによるアクセスが必要です。プログラムによるアクセスを許可する方法は、AWS にアクセスしているユーザーのタイプによって異なります。
+ IAM Identity Center で ID を管理する場合、AWS API にはプロファイルが必要で、AWS Command Line Interface にはプロファイルまたは環境変数が必要です。
+ IAM ユーザーがいる場合、AWS API と AWS Command Line Interface にはアクセスキーが必要です。可能な限り、アクセスキー ID、シークレットアクセスキー、および認証情報の失効を示すセキュリティトークンが含まれる一時的な認証情報を作成します。
ユーザーにプログラムによるアクセス権を付与するには、以下のいずれかのオプションを選択します。
| プログラムによるアクセス権を必要とするユーザー | オプション | 詳細情報 |
| --- | --- | --- |
| ワークフォース ID (IAM アイデンティティセンターで管理される人々とユーザー) | 短期認証情報を使用して、AWS CLI または AWS API (直接または AWS SDK を使用して) へのプログラムによるリクエストに署名します。 | AWS CLI については、*AWS IAM アイデンティティセンター ユーザーガイド*の「[Getting IAM role credentials for CLI access](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtogetcredentials.html)」(CLI アクセス用の IAM ロール認証情報の取得) の指示に従ってください。 AWS API については、「*AWS SDK およびツールリファレンスガイド*」の「[SSO 認証情報](https://docs.aws.amazon.com//sdkref/latest/guide/feature-sso-credentials.html)」の指示に従ってください。 |
| IAM ユーザー | 短期認証情報を使用して、AWS CLI または AWS API (直接または AWS SDK を使用して) へのプログラムによるリクエストに署名します。 | 「[AWS リソースでの一時的な認証情報の使用](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_use-resources.html)」の指示に従ってください。 |
| IAM ユーザー | 長期間の認証情報を使用して、AWS CLI または AWS API (直接またはAWS SDK を使用して) へのプログラムによるリクエストに署名します。(非推奨) | 「[IAM ユーザーのアクセスキーの管理](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html)」の指示に従ってください。 |
| フェデレーテッドプリンシパル | AWS STS API オペレーションを使用して、アクセスキーペアやセキュリティトークンを含む一時的セキュリティ認証情報で新しいセッションを作成します。 | API オペレーションの説明については、「[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)」を参照してください |
# アクセス許可とポリシーがアクセス管理を提供する方法
AWS Identity and Access Management (IAM) のアクセス管理では、アカウントでプリンシパルエンティティが実行できる操作を定義します。プリンシパルエンティティとは、IAM エンティティ (IAM ユーザーまたは IAM ロール) を使用して認証されているユーザーまたはアプリケーションのことです。アクセス管理は、*認可*と呼ばれることもあります。AWS でのアクセスを管理するには、ポリシーを作成し、IAM アイデンティティ (IAM ユーザー、IAM グループ、または IAM ロール) または AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパルが IAM エンティティ (IAM ユーザーまたは IAM ロール) を使用してリクエストを行うと、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。ポリシーのタイプと用途の詳細については、「[AWS Identity and Access Management でのポリシーとアクセス許可](access_policies.md)」を参照してください。
## ポリシーとアカウント
AWS で 1 つのアカウントを管理する場合は、ポリシーを使用してそのアカウント内でアクセス許可を定義します。複数のアカウントをまたいでアクセス許可を管理する場合、IAM ユーザーのアクセス許可を管理するのが難しくなります。IAM ロール、リソースベースのポリシー、アクセスコントロールリスト (ACL) はクロスアカウントのアクセス許可で使用できます。ただし、複数のアカウントを所有している場合は、このようなアクセス許可を管理しやすいように AWS Organizations サービスを使用することをお勧めします。詳細については、「*AWS Organizations ユーザーガイド*」の「[What is AWS Organizations?](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)」を参照してください。
## ポリシーとユーザー
IAM ユーザーは AWS アカウント のアイデンティティです。IAM ユーザーを作成する場合、ユーザーはアクセス許可を付与されるまでアカウントのいずれのリソースにもアクセスできません。許可を IAM ユーザーに付与するには、ID ベースのポリシーを作成して、IAM ユーザーか、IAM ユーザーが属する IAM グループにアタッチします。以下の例で示す JSON ポリシーでは、`dynamodb:*` リージョン内の `Books` アカウントの `123456789012` テーブルに対してすべての Amazon DynamoDB アクション (`us-east-2`) を実行することを IAM ユーザーに許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
}
}
```
------
このポリシーを IAM ユーザーにアタッチすると、そのユーザーには、DynamoDB インスタンスの `Books` テーブルですべてのアクションを実行するための許可が付与されます。ほとんどの IAM ユーザーには、付与された許可の合計を表すために組み合わされた複数のポリシーがあります。
ポリシーによって明示的に許可されていないアクションやリソースは、デフォルトで拒否されます。例えば、前述のポリシーがユーザーにアタッチされた単一のポリシーである場合、そのユーザーは `Books` テーブルに対して DynamoDB アクションを実行できますが、他のテーブルに対してアクションを実行することはできません。同様に、そのユーザーは Amazon EC2、Amazon S3、または他の AWS サービスでアクションを実行することは許可されません。これらのサービスを利用するための許可はポリシーに含まれていないためです。
## ポリシーと IAM グループ
IAM ユーザーを IAM グループにまとめ、そのグループにポリシーをアタッチできます。その場合、個々の IAM ユーザーは、まだ独自の認証情報を持っていますが、その IAM グループのすべての IAM ユーザーは、IAM グループにアタッチされている許可を持っています。アクセス許可の管理を簡素化するために IAM グループを使用します。
![\[この図は、IAM ユーザーを IAM グループにまとめることで、許可の管理を簡素化できることを示しています。これは、各 IAM ユーザーが IAM グループに割り当てられた許可を持つようになるためです。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/iam-intro-users-and-groups.diagram.png)
IAM ユーザーまたは IAM グループには、さまざまなアクセス許可を付与する複数のポリシーをアタッチできます。その場合、ポリシーの組み合わせによって、プリンシパルの有効な許可が決まります。アクションとリソースの両方についての明示的な `Allow` 許可がプリンシパルに付与されていない場合、そのプリンシパルはそれらの許可を持ちません。
## フェデレーションユーザーのセッションとロール
フェデレーティッドプリンシパルは、IAM ユーザーとは異なり、AWS アカウント で永続的な ID を持っていません。フェデレーティッドプリンシパルにアクセス許可を割り当てるには、*ロール*と呼ばれるエンティティを作成し、ロールのアクセス許可を定義できます。SAML または OIDC のフェデレーティッドプリンシパルが AWS にサインインすると、ユーザーはロールに関連付けられて、ロールで定義されているアクセス許可が付与されます。詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」を参照してください。
## アイデンティティベースのポリシーとリソースベースのポリシー
アイデンティティベースのポリシーは、IAM アイデンティティ ( IAM ユーザー、グループ、ロールなど) にアタッチするアクセス許可ポリシーです。リソースベースのポリシーは、Amazon S3 バケットなどのリソースまたは IAM ロール信頼ポリシーにアタッチする許可ポリシーです。
***アイデンティティベースのポリシー***では、アイデンティティが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーはさらに次のように分類できます。
+ **管理ポリシー** - AWS アカウント 内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンのアイデンティティベースのポリシーです。次の 2 種類の管理ポリシーを使用できます。
+ **AWS 管理ポリシー** – AWS が作成および管理する管理ポリシー。ポリシーを初めて利用する場合は、AWS 管理ポリシーから開始することをお勧めします。
+ **カスタマー管理ポリシー** - AWS アカウント で作成および管理する管理ポリシー。カスタマー管理ポリシーでは、AWS 管理ポリシーに比べて、より正確にポリシーを管理できます。ビジュアルエディタで および IAM ポリシーを作成および編集することも、JSON ポリシードキュメントを直接作成することもできます。詳細については、「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](access_policies_create.md)」および「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
+ **インラインポリシー** – お客様が作成および管理するポリシーであり、単一のユーザー、グループ、またはロールに直接埋め込まれます。通常、インラインポリシーを使用することは推奨されていません。
***リソースベースのポリシー***では、指定されたプリンシパルが実行できるリソースと条件を制御します。リソースベースのポリシーはインラインポリシーであり、管理リソースベースのポリシーはありません。クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。****
IAM サービスは、ユーザーが IAM ロールにアタッチするロールの信頼ポリシーと呼ばれるリソースベースのポリシーの 1 つのタイプをサポートします。IAM ロールは、リソースベースのポリシーをサポートする ID かつリソースであるため、信頼ポリシーと ID ベースのポリシーのいずれも IAM ロールにアタッチする必要があります。信頼ポリシーは、ロールを引き受けることができるプリンシパルエンティティ (アカウント、ユーザー、ロール、AWS STS フェデレーションユーザーのプリンシパル) を定義します。IAM ロールと、他のリソースベースのポリシーとの違いについては、「[IAM でのクロスアカウントのリソースへのアクセス](access_policies-cross-account-resource-access.md)」を参照してください。
リソースベースのポリシーをサポートするサービスを確認するには､「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください｡ リソースベースのポリシーの詳細については、「[アイデンティティベースおよびリソースベースのポリシー](access_policies_identity-vs-resource.md)」を参照してください。
# ABAC 認可で属性に基づいてアクセス許可を定義する
属性ベースのアクセスコントロール (ABAC) は、属性に基づいて許可を定義する認可戦略です。AWS はこれらの属性をタグと呼んでいます。タグは、IAM エンティティ (IAM ユーザーまたは IAM ロール) を含めた IAM リソース、および AWS リソースにアタッチできます。IAM プリンシパルに対して、単一の ABAC ポリシー、または少数のポリシーのセットを作成できます。プリンシパルのタグがリソースタグと一致したら操作を許可する ABAC ポリシーを設計できます。詳細なユーザーコンテキストときめ細かなアクセスコントロールの両方を提供する ABAC の属性システム。ABAC は属性ベースであるため、アクセスをリアルタイムで付与または取り消すデータまたはアプリケーションについて動的認可を実行できます。ABAC は、スケールしている環境や、ID またはリソースポリシーの管理が複雑になった状況で役立ちます。
例えば、`access-project` タグキーを使用して 3 つの IAM ロールを作成できます。最初の IAM ロールのタグ値を `Heart`、2 番目を `Star`、3 番目を `Lightning` に設定します。その後、IAM ロールと AWS リソースにタグ値 `access-project` がある場合にアクセスを許可する単一のポリシーを使用できます。AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「[IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する](tutorial_attribute-based-access-control.md)」を参照してください。ABACをサポートするサービスについては、[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md) を参照してください。
![\[この図は、リソースに対する許可をユーザーに付与するために、プリンシパルに適用されるタグが、リソースに適用されるタグと一致する必要があることを示しています。タグは、IAM グループ、リソースグループ、個々のユーザー、個々のリソースに適用されます。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/tutorial-abac-concept-23.png)
## ABAC と従来の RBAC モデルの比較
IAM で使用される従来の認可モデルは、ロールベースのアクセスコントロール (RBAC) です。RBAC は、IAM ロールとは異なる、ユーザーの職務機能またはロールに基づいて許可を定義します。IAMには、RBACモデルのジョブ機能にアクセス許可を調整する[ジョブ機能の管理ポリシー](access_policies_job-functions.md)が含まれています。
IAM では、職務機能ごとに異なるポリシーを作成して RBAC を実装します。次に、ポリシーを ID (IAM ユーザー、IAM グループ、または IAM ロール) にアタッチします。[ベストプラクティス](best-practices.md)として、職務機能に必要な最小限のアクセス許可を付与します。これにより、[最小特権](best-practices.md#grant-least-privilege)アクセスを実現できます。各職務機能ポリシーには、そのポリシーに割り当てられた ID がアクセスできる特定のリソースがリストされます。従来の RBAC モデルを使用することの欠点は、管理者またはユーザーが環境に新しいリソースを追加する際に、それらのリソースへのアクセスを許可するためにポリシーを更新する必要があるということです。
たとえば、従業員が取り組んでいる `Lightning`、`Heart`、`Star`、という名前の 3 つのプロジェクトがあるとします。各プロジェクトの IAM ロールを作成します。次に、ポリシーを各 IAM ロールにアタッチして、IAM ロールを引き受けることができるすべてのユーザーがアクセスできるリソースを定義します。従業員が社内でジョブを変更した場合は、別の IAM ロールに割り当てます。複数の IAM ロールに人々またはプログラムを割り当てることができます。ただし、`Star` プロジェクトでは、新しい Amazon EC2 コンテナなどの追加のリソースが必要になる場合があります。その場合は、`Star` IAM ロールにアタッチされたポリシーを更新して、新しいコンテナリソースを指定する必要があります。そうしないと、`Star` プロジェクトメンバーは新しいコンテナにアクセスできません。
![\[この図は、ロールベースのアクセスコントロールでは、異なるリソースにアクセスするために、各 ID に特定の職務機能ベースのポリシーを割り当てる必要があることを示しています。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/tutorial-abac-rbac-concept-23.png)
**ABAC には、従来の RBAC モデルと比べて以下の利点があります。**
+ **ABAC のアクセス許可は、イノベーションに合わせてスケールされます。**新しいリソースへのアクセスを許可するために、管理者が既存のポリシーを更新する必要はありません。たとえば、`access-project` タグを使用して ABAC 戦略を設計したとします。開発者は、`access-project` = `Heart` タグで IAM ロールを使用します。`Heart` プロジェクトのユーザーが追加の Amazon EC2 リソースを必要とする場合、開発者は `access-project` = `Heart` タグを使用して新しい Amazon EC2 instances インスタンスを作成できます。その後は、タグ値が一致するため、 `Heart` プロジェクトのすべてのユーザーがこれらのインスタンスを起動および停止できます。
+ **ABAC では必要なポリシーが少なくなります。**職務機能ごとに異なるポリシーを作成する必要がないため、作成するポリシーは少なくなります。これらのポリシーは管理しやすくなります。
+ **ABAC を使用すると、チームは変化や成長に動的に対応できます。**新しいリソースについての許可は属性に基づいて自動的に付与されるため、ID にポリシーを手動で割り当てる必要はありません。たとえば、会社が ABAC を使用して `Heart` プロジェクトと `Star` プロジェクトをすでにサポートしている場合、新しい `Lightning` プロジェクトは簡単に追加できます。IAM 管理者は、`access-project` = `Lightning` タグを使用して新しい IAM ロールを作成します。新しいプロジェクトをサポートするためにポリシーを変更する必要はありません。IAM ロールを引き受けるアクセス許可を持っているユーザーは、 `access-project` = `Lightning` でタグ付けされたインスタンスを作成および表示できます。もう 1 つのシナリオは、チームメンバーが `Heart` プロジェクトから `Lightning` プロジェクトに移動する場合です。`Lightning` プロジェクトへのアクセスをチームメンバーに提供するために、IAM 管理者は、それらを別の IAM ロールに割り当てます。アクセス許可ポリシーを変更する必要はありません。
+ **ABAC を使用すると、きめ細かなアクセス許可が可能です。**ポリシーを作成するときは、 [最小限のアクセス許可を付与](best-practices.md#grant-least-privilege)することがベストプラクティスです。従来の RBAC では、特定のリソースへのアクセスを許可するポリシーを記述します。ただし、ABAC を使用する場合、リソースのタグがプリンシパルのタグと一致する場合、すべてのリソースでアクションを許可できます。
+ **ABAC を使用して、社内ディレクトリの従業員属性を使用します。**セッションタグを IAM に渡すよう SAML または OIDC プロバイダーを設定できます。従業員が AWS にフェデレーションすると、IAM は、結果として得られるプリンシパルに従業員の属性を適用します。その後、ABAC を使用して、これらの属性に基づいてアクセス許可を許可または拒否できます。
AWS の ABAC の使用方法を説明する詳細なチュートリアルについては、「[IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する](tutorial_attribute-based-access-control.md)」を参照してください。