AWS ドキュメント » AWS Identity and Access Management » ユーザーガイド » AWS Identity and Access Management のリファレンス情報 » IAM ID

IAM ID

IAM は、ユーザー、グループ、ロール、ポリシー、およびサーバー証明書に対していくつかの異なった ID を使います。このセクションでは、ID およびそれぞれの ID の使い方について説明します。

分かりやすい名前とパス

ユーザー、ロール、グループ、またはポリシーを作成するとき、あるいはサーバー証明書をアップロードするときは、Bob や TestApp1、Developers、ManageCredentialsPermissions、または ProdServerCert などのような分かりやすい名前を付けます。

IAM API または AWS Command Line Interface (AWS CLI) を使用して IAM エンティティを作成する場合、エンティティにオプションのパスを指定することもできます。単一のパスを使用することも、フォルダ構造であるかのように複数のパスを入れ子にすることもできます。たとえば、会社の組織構造に一致するように、入れ子パス /division_abc/subdivision_xyz/product_1234/engineering/ を使用できます。その後、パスのユーザーすべてが Policy Simulator API にアクセス許可するためのポリシーを作成できます。このポリシーを表示するには、IAM: ユーザーパスに基づいた Policy Simulator API へのアクセス を参照してください。パスの使用方法のその他の例については、IAM ARN を参照してください。

ユーザーとグループに同じパスを指定したからといって、自動的にそのユーザーがグループに分類されるわけではありません。たとえば、Developers グループを作成し、そのパスを /division_abc/subdivision_xyz/product_1234/engineering/ と指定したとします。Bob という名のユーザーを追加して同様のパスを与えたからといって、自動的に Bob が Developers グループに分類されるわけではありません。IAM では、パスに基づいてユーザー、またはグループ間に境界が設定されるわけではありません。パスの異なるユーザーでも（それらのリソースにアクセス権限さえ与えられていれば）、同じリソース使うこともできます。名前の制限の詳細については、IAM エンティティおよびオブジェクトの制限を参照してください。

IAM ARN

ほとんどのリソースはフレンドリ名を持っています (Bobという名前のユーザー、Developersという名前のグループなど)。ただし、アクセス許可ポリシー言語では、以下の Amazon リソースネーム (ARN) 形式を使用して、リソースを指定する必要があります。

arn:partition:service:region:account:resource

各パラメーターの意味は次のとおりです。

• partition は、そのリソースがあるパーティションを識別します。標準の AWS リージョンの場合、パーティションは aws です。他のパーティションにリソースがある場合、パーティションは aws-partitionname です。たとえば、中国 (北京) リージョンにあるリソースのパーティションは、aws-cn です。

• service は AWS 製品を示します。IAM リソースの場合、これは常に iam となります。

• region はリソースが置かれている領域です。IAM リソースの場合、これは常に空白となります。

• account は、ハイフンなしの AWS アカウント ID です (123456789012 など)。

• resource は、特定のリソースを名前で識別する部分です。

ユーザー (IAM ユーザーおよびフェデレーティッドユーザー)、グループ、ロール、ポリシー、インスタンスプロファイル、仮想 MFA デバイス、およびサーバー証明書に対して、IAM の ARN を使用できます。以下の表に、各リソースの ARN フォーマットとその例を示します。IAM リソースはグローバルに識別されるため、ARN のリージョンの割り当ては空白です。

注記

次の例の多くには、ARN のリソースパートにパスが含まれています。パスをAWS マネジメントコンソールで作成、操作することはできません。リソースでの作業でパスを使用するには、AWS、API、AWS CLI、または Tools for Windows PowerShell を使用する必要があります。

以下の例は、様々な種類の IAM リソースに対する ARN を示します。

• AWS アカウント - アカウント自体:

  arn:aws:iam::123456789012:root

• アカウントの IAM ユーザー:

  arn:aws:iam::123456789012:user/Bob

• 組織図を反映するパスを持つ別のユーザー:

  arn:aws:iam::123456789012:user/division_abc/subdivision_xyz/Bob

• IAM グループ:

  arn:aws:iam::123456789012:group/Developers

• パスを持つ IAM グループ:

  arn:aws:iam::123456789012:group/division_abc/subdivision_xyz/product_A/Developers

• IAM ロール:

  arn:aws:iam::123456789012:role/S3Access

• 管理ポリシー:

  arn:aws:iam::123456789012:policy/ManageCredentialsPermissions

• EC2 インスタンスと関連付けられるインスタンスプロファイル:

  arn:aws:iam::123456789012:instance-profile/Webserver

• 「Bob」として IAM で識別されるフェデレーティッドユーザー:

  arn:aws:sts::123456789012:federated-user/Bob

• 引き受けるロールが「Accounting-Role」、ロールのセッション名が「Mary」であるユーザーのアクティブセッション:

  arn:aws:sts::123456789012:assumed-role/Accounting-Role/Mary

• Bob という名前のユーザーに割り当てられた多要素認証デバイス:

  arn:aws:iam::123456789012:mfa/Bob

• サーバー証明書

  arn:aws:iam::123456789012:server-certificate/ProdServerCert

• 組織図を反映したパスを持つサーバー証明書:

  arn:aws:iam::123456789012:server-certificate/division_abc/subdivision_xyz/ProdServerCert

• ID プロバイダー (SAML および OIDC):

  arn:aws:iam::123456789012:saml-provider/ADFSProvider

  arn:aws:iam::123456789012:oidc-provider/GoogleProvider

以下に示すポリシーでは、Richard に対して、本人のアクセスキーを管理する権限を割り当てています。リソースは、IAM ユーザー Richard であることに注目してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ManageRichardAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:*AccessKey*",
                "iam:GetUser"
            ],
            "Resource": "arn:aws:iam::*:user/division_abc/subdivision_xyz/Richard"
        },
        {
            "Sid": "ListForConsole",
            "Effect": "Allow",
            "Action": "iam:ListUsers",
            "Resource": "*"
        }
    ]
}

注記

IAM ポリシー内でリソースを識別するための ARN を使用するとき、ポリシー変数を使用して ARN の一部としてランタイム情報 (ユーザー名など) のためのプレースホルダを含めることができます。詳細については、「IAM ポリシーエレメント: 変数およびタグ」を参照してください。

ARN の resource 部分でワイルドカードを使用して、複数のユーザー、グループ、またはポリシーを指定することもできます。例えば、product_1234 の作業に携わっている全ユーザーを表すには、次のように指定します。

arn:aws:iam::123456789012:user/division_abc/subdivision_xyz/product_1234/*

名前が app_ という文字列で始まる複数のユーザーがいるとします。この場合、次の ARN を使用すると全員の名前を表すことができます。

arn:aws:iam::123456789012:user/division_abc/subdivision_xyz/product_1234/app_*

AWS アカウントの全ユーザー、グループ、またはポリシーを表すには、それぞれ ARN の user/、group/、または policy に続けて、ワイルドカードを指定します。

arn:aws:iam::123456789012:user/*
arn:aws:iam::123456789012:group/*
arn:aws:iam::123456789012:policy/*

ARN の user/、group/、または policy 部分にワイルドカードを使用しないでください。つまり、以下の項目は禁止されています。

arn:aws:iam::123456789012:u*

例 プロジェクトベースのグループ用のパスと ARN の使用

パスをAWS マネジメントコンソールで作成、操作することはできません。リソースでの作業でパスを使用するには、AWS、API、AWS CLI、または Tools for Windows PowerShell を使用する必要があります。

この例では、Marketing_Admin グループの Jules が、/marketing/ パスにプロジェクトベースのグループを作成し、社内の異なる部門から招集したユーザーを割り当てます。この例では、ユーザーのパスが本人の所属する部門には関連のないことを示しています。

マーケティング部門には、リリース間近の新製品があり、そのため Jules は /marketing/ パスに Widget_Launch という新しいグループを作成します。次に、Jules は Widget_Launch グループに以下のポリシーを割り当てます。これにより、Widget_Launch グループには、新製品プロジェクト用に確保された example_bucket 領域のオブジェクトにアクセスできる権限が与えられます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example_bucket/marketing/newproductlaunch/widget/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket*",
      "Resource": "arn:aws:s3:::example_bucket",
      "Condition": {"StringLike": {"s3:prefix": "marketing/newproductlaunch/widget/*"}}
    }
  ]
}

そして Jules は、この新製品プロジェクトに参加しているユーザーを Widget_Launch グループに割り当てます。具体的には、/marketing/ パスから Patricia と Eli が、/sales/ パスからは Chris と Chloe が、/legal/ パスからは Aline と Jim が追加されます。

一意の ID

IAM がユーザー、グループ、ロール、ポリシー、インスタンスプロファイル、サーバー証明書を作成するとき、各エンティティには次の例のような一意の ID が割り当てられます。

AIDAJQABLZS4A3QDU576Q

ほとんどの場合、IAM エンティティで作業をするときはフレンドリ名と ARN を使用するため、特定のエンティティに対する一意の ID を知る必要はありません。しかしながら、フレンドリ名を用いることが実際的でないときなど、場合によっては一意の ID が役立つこともあります。

例としては、AWS アカウント内でフレンドリ名を再利用する場合が挙げられます。アカウント内において、ユーザー、グループ、またはポリシーに対するフレンドリ名は一意である必要があります。たとえば、David という IAM ユーザーを作成するとしましょう。会社は Amazon S3 を使用しており、各従業員のフォルダを格納したバケットがあります。バケットには、ユーザーがバケット内の自分のフォルダにのみアクセスするように制限するリソースベースのポリシー (バケットポリシー) が設定されています。そこで、David という名の従業員が退職することになり、あなたは関連する IAM ユーザーを削除するとします。しかし後に David という名前を持つ別の従業員が入社してきて、あなたは David という新しい IAM ユーザーを作成しました。バケットポリシーに David という名前の IAM ユーザーが指定されていると、ポリシーは新しい David に対して、Amazon S3 バケット内に前の David が残した情報へのアクセスを許可することになります。

一方で、新しい IAM ユーザーが以前削除したフレンドリ名を再利用したとしても、すべての IAM ユーザーが一意の ID を持っています。この例の場合、古い IAM ユーザーである David と、新しい IAM ユーザーである David の ID は異なります。Amazon S3 バケット用のリソースポリシーを作成し、ユーザー名だけではなく一意の ID によってアクセス許可を付与するポリシーを設定しておけば、アクセスする必要のない情報へのアクセス許可を従業員にうっかり付与することがなくなります。

また IAM ユーザー情報に関する独自のデータベース (またはその他のデータストア) を維持するときなども、ユーザー ID が役立ちます。前の例のように、時を経て同じ名前を再び使用する IAM ユーザーがいたとしても、一意の ID は、作成された IAM ユーザーごとに一意の識別子を提供します。

一意の ID プレフィックスを理解する

IAM は、一意の各 ID が適用するエンティティタイプを示すために、以下のプレフィックスを使用します。

プレフィックス	エンティティタイプ
AAGA	アクショングループ
ACCA	コンテキスト固有の認証情報
AGPA	グループ
AIDA	IAM ユーザー
AIPA	Amazon EC2 インスタンスプロファイル
AKIA	アクセスキー
ANPA	管理ポリシー
ANVA	管理ポリシーのバージョン
APKA	パブリックキー
AROA	ロール
ASCA	証明書
ASIA	一時 (AWS STS) キー

一意の ID を取得する

IAM エンティティに対する一意の ID は、IAM コンソールでは取得できません。一意の ID を取得するには、以下の AWS CLI または IAM API コールを使用します。

AWS CLI:

• get-group

• get-role

• get-user

• get-policy

• get-instance-profile

• get-server-certificate

IAM API:

• GetGroup

• GetRole

• GetUser

• GetPolicy

• GetInstanceProfile

• GetServerCertificate