AWS Identity and Access Management
ユーザーガイド

ロールに関する用語と概念

ロールの操作に役立つ基本的な用語を紹介します。

ロール

AWS のアクションおよびリソースへのアクセスを許可する一連のアクセス許可です。これらのアクセス許可は、IAM ユーザーまたはグループではなくロールにアタッチされます。ロールを使用できるのは、以下のものです。

  • ロールと同じ AWS アカウントの IAM ユーザー

  • ロールとは異なる AWS アカウントの IAM ユーザー

  • Amazon Elastic Compute Cloud など、AWS が提供するウェブサービス (Amazon EC2)

  • SAML 2.0 または OpenID Connect と互換性のある外部 ID プロバイダー (IdP) サービスによって認証される外部ユーザー、またはカスタム作成された ID ブローカー。

     

AWS サービスロール

サービスがお客様に代わってお客様のアカウントでアクションを実行するために引き受けるロールです。ほとんどの AWS のサービス環境を設定するときに、サービスが引き受けるロールを定義する必要があります。このサービスロールには、サービスが必要とする AWS のリソースにサービスがアクセスするために必要なすべてのアクセス許可を含める必要があります。サービスロールはサービスによって異なりますが、多くのサービスロールでは、そのサービスの文書化された要件を満たしている限り、アクセス許可を選択することができます。サービスロールは、お客様のアカウント内のみでアクセスを提供します。他のアカウントのサービスへのアクセス権を付与するためにサービスロールを使用することはできません。IAM 内部からロールを作成、修正、削除できます。

EC2 インスタンスの AWS サービスロール

アプリケーションを実行する Amazon EC2 インスタンスを起動するためにサービスが引き受ける特殊なタイプのサービスロールです。このロールは EC2 インスタンスにその起動時に割り当てられます。AWS はロールにアタッチされた一時的セキュリティ認証情報を自動的に提供し、アプリケーションに代わって EC2 インスタンスがその認証情報を使用できるようにします。EC2 インスタンスのサービスロールの使用の詳細については、「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する」を参照してください。

AWS サービスにリンクされたロール

AWS サービスに直接リンクされた一意のタイプのサービスロールです。サービスにリンクされたロールは、サービスによって事前定義されており、お客様の代わりにサービスから他の AWS サービスを呼び出す必要のあるアクセス権限がすべて含まれています。このリンクされたサービスでも、サービスにリンクされたロールを作成、変更、削除する方法を定義しています。サービスによって、ロールが自動的に作成または削除される場合があります。そのため、ウィザードの一部、またはサービスのプロセスとして、ロールを作成、変更、削除できる場合があります。または、ロールを作成または削除するには、IAM を使用する必要がある場合があります。メソッドに関係なく、サービスにリンクされたロールにより必要なアクセス許可を手動で追加する必要がなくなるため、サービスの設定が簡単になります。

注記

サービスにリンクされたロールのサポートを開始する時点ですでにサービスを使用している場合は、アカウントの新しいロールに関する E メールが送信されることがあります。この場合、サービスにリンクされたロールは、サービスによって自動的にアカウントに作成されています。このロールをサポートするために必要な操作はありません。また、手動でロールを削除しないでください。詳細については、「AWS アカウントに新しいロールが表示される」を参照してください。

サービスにリンクされたロールの使用をサポートするサービスについては、「IAM と連携する AWS のサービス」を参照してください。これらのサービスでは、「サービスにリンクされたロール」列が「はい」になっています。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、[はい] リンクを選択します。サービスにリンクされたロールの作成、変更、削除に関するドキュメントがサービスに含まれていない場合は、IAM コンソール、AWS CLI、または API を使用できます。詳細については、「サービスにリンクされたロールの使用」を参照してください。

ロールの連鎖

ロールの連鎖は、AWS CLI または API を使用して 2 つ目のロールを引き受けるロールを使用する場合に発生します。たとえば、User1 に、RoleA および RoleB を引き受けるアクセス許可があるとします。さらに、RoleA には RoleB を引き受けるアクセス許可があるとします。AssumeRole API オペレーションで User1 の長期的なユーザー認証情報を使用して RoleA を引き受けることができます。このオペレーションは RoleA の短期的な認証情報を返します。ロールの連鎖を行うには、RoleA の短期認証情報を使用して RoleB を引き受けます。

ロールの連鎖では、AWS CLI または API ロールセッションは最長 1 時間に制限されます。AssumeRole API オペレーションを使用してロールを引き受ける場合は、DurationSeconds パラメータを使用してロールセッションの期間を指定できます。パラメータの値は、ロールの最大セッション期間設定によって、最大 43200 秒 (12 時間) まで指定できます。ただし、ロールの連鎖を使用してロールを引き受ける場合、DurationSeconds パラメータ値で 1 時間を超える値を指定すると、オペレーションは失敗します。

委任

委任により、制御するリソースへのアクセスを許可するユーザーにアクセス許可を付与できます。委任では、リソースを所有するアカウント (信頼するアカウント) と、リソースへアクセスする必要のあるユーザーを含むアカウント (信頼されたアカウント) との間に信頼を設定する必要があります。信頼するアカウントと信頼されたアカウントには、以下のいずれかを指定できます。

  • 同じアカウント。

  • 組織の制御下にある別々のアカウント。

  • 異なる組織によって所有される 2 つのアカウント。

リソースに対するアクセス許可を委任するには、2 つのポリシーがアタッチされた信頼されるアカウントの IAM ロールを作成します。アクセス許可ポリシーは、リソースに対して目的のタスクを実行するために必要なアクセス許可をロールのユーザーに付与します。信頼ポリシーは、信頼されたアカウントのどのメンバーにロールを割り当てることができるかを指定します。

信頼ポリシーを作成するときは、プリンシパルとしてワイルドカード (*) を指定することはできません。信頼ポリシーは、信頼するアカウントのロールにアタッチされ、アクセス許可の半分です。残りの半分は、ユーザーがロールを切り替えることができる、またはロールを引き受けることができる信頼されたアカウントのユーザーにアタッチされたアクセス許可ポリシーです。ロールを引き受けるユーザーの各自のアクセス権限は一時的に無効になりますが、その代わりにロールのアクセス権限を取得します。ユーザーがロールの使用を終了または停止すると、元のユーザーアクセス権限に戻ります。外部 ID という追加パラメータは、同じ組織がコントロールしていないアカウント間でロールを安全に利用するのに役立ちます。

フェデレーション

外部 ID プロバイダーと AWS との間に信頼関係を作成することです。ユーザーはウェブ ID プロバイダー (Login with AmazonFacebookGoogleOpenID Connect (OIDC) 互換の任意の IdP など) にサインインできます。また、Microsoft Active Directory フェデレーションサービスなど、Security Assertion Markup Language(SAML)2.0 互換の企業の ID システムにサインインすることもできます。OIDC および SAML 2.0 を使用して、このような外部 ID プロバイダーと AWS との信頼関係を設定する場合、ユーザーは IAM ロールに割り当てられます。ユーザーは一時的な認証情報を受け取り、これを使用して AWS リソースにアクセスすることもできます。

信頼ポリシー

ロールを引き受けるユーザーを定義する JSON 形式のドキュメント。この信頼されたエンティティは、ドキュメントの Principal 要素として、ポリシーに含まれています。ドキュメントは IAM ポリシー言語のルールに従って記述されます。

アクセス許可ポリシー

ロールで使用できるアクションやリソースを定義する JSON 形式のアクセス許可に関するドキュメント。ドキュメントは IAM ポリシー言語のルールに従って記述されます。

アクセス許可の境界

ポリシーを使用してロールに許可されるアクセス許可の上限を設定するアドバンスド機能。この境界は、AWS Organizations 組織に適用するか、IAM ユーザーまたはロールに適用できます。アクセス許可の境界をサービスにリンクされたロールに適用することはできません。詳細については、「IAM アイデンティティのアクセス許可の境界」を参照してください。

Principal

アクションを実行してリソースにアクセスできる AWS 内のエンティティです。AWS アカウントのルートユーザー、IAM ユーザー、またはロールをプリンシパルにすることができます。以下の 2 つの方法のいずれかを使用して、リソースに対するアクセス許可を付与できます。

  • ユーザー(直接、またはグループ経由で間接的に)またはロールに対し、アクセス権限ポリシーをアタッチすることができます。

  • リソースベースのポリシーをサポートするサービスについては、リソースにアタッチされているポリシーの Principal 要素でプリンシパルを指定できます。

AWS アカウントをプリンシパルにする場合、通常はアカウント内で定義されているすべてのプリンシパルが対象となります。

注記

ロールの信頼ポリシーのPrincipalエレメントでワイルドカード (*) を使用することはできません。

クロスアカウントアクセスのロール

あるアカウントのリソースに対するアクセス権限を、別のアカウントの信頼されるプリンシパルに付与します。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、AWS が提供する一部のウェブサービスでは、 (ロールをプロキシとして使用するのではなく) リソースにポリシーを直接アタッチすることができます。これらはリソースベースのポリシーと呼ばれ、別の AWS アカウントのプリンシパルにリソースへのアクセスを許可するために使用できます。Amazon Simple Storage Service (S3) バケット、Glacier、ボールト、Amazon Simple Notification Service (SNS) トピック、Amazon Simple Queue Service (SQS) キューの各サービスでは、指定されたリソースのリソースベースのポリシーがサポートされます。詳細については、「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。