アクセス権を委任するポリシーの例

以下の例では、AWS アカウント に別の AWS アカウント のリソースへのアクセスを許可する方法を示しています。これらの例の JSON ポリシードキュメントを使用して IAM ポリシーを作成する方法については、「JSON エディターを使用したポリシーの作成」を参照してください。

ロールを使用して他の AWS アカウント のリソースへのアクセス権を委任する

IAM ロールを使用し、あるアカウントに属しているユーザーに、他のアカウントに属している AWS リソースへのアクセスを許可する方法のチュートリアルについては、「IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」を参照してください。

重要

特定のロールまたはユーザーの ARN を、ロールの信頼ポリシーの Principal 要素に含めることができます。ポリシーを保存すると、AWS は ARN を一意のプリンシパル ID に変換します。これにより、ロールまたはユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ARN への逆変換が行われるためです。ただし、ロールまたはユーザーを削除すると、関係が壊れます。ポリシーは、ユーザーまたはロールを再作成しても適用されません。これは、信頼ポリシーに保存されているプリンシパル ID に一致しないためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの Principal 要素で指し示しているユーザーまたはロールを削除し、再作成する場合、ロールを編集して ARN を置き換える必要があります。ポリシーを保存するときに、ARN は新しいプリンシパル ID に変換されます。

ポリシーを使用してサービスへのアクセスを委任する

次の例では、ロールにアタッチできるポリシーを示します。ポリシーは、Amazon EMR および AWS Data Pipeline の 2 つのサービスを有効にして、ロールを想定します。これらのサービスは、ロールに割り当てられた権限ポリシー (表示されていない) によって付与されたタスクを実行できます。複数のサービスプリンシパルを指定する場合に、2 つの Service 要素は指定できません。1 つのみ指定できます。代わりに、1 つの Service 要素の値として複数のサービスのプリンシパルのアレイを使用します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

リソースベースのポリシーを使用して他のアカウントの Amazon S3 バケットへのアクセス権を委任する

この例では、アカウント A はリソースベースのポリシー (Amazon S3 バケットポリシー) を利用して、アカウント A の S3 バケットへのフルアクセスをアカウント B に許可します。次に、アカウント B が IAM ユーザーポリシーを作成して、アカウント A のバケットへのアクセス権をアカウント B のいずれかのユーザーに委任します。

アカウント A の S3 バケットポリシーは以下のポリシーのようになります。この例では、アカウント A の S3 バケットの名前を mybucket とし、アカウント B のアカウント番号は 111122223333 とします。この番号は、アカウント B の個々のユーザーまたはグループではなく、アカウント自体のみを指定します。

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }
}

また、アカウント A は Amazon S3 アクセスコントロールリスト (ACL) を使用して、アカウント B に S3 バケットまたはバケット内の 1 つのオブジェクトへのアクセスを許可することもできます。この場合、唯一変更する点は、アカウント A がアカウント B にアクセス権を付与する方法です。ただし、この例の 2 番目の部分で説明したように、アカウント B はポリシーを使用して、アカウント B の IAM グループにアクセス権を委任することになります。S3 バケットとオブジェクトのアクセス制御の詳細については、Amazon Simple Storage Service ユーザーガイドのアクセス制御を参照してください。

アカウント B の管理者が、次のサンプルポリシーを作成するとします。このポリシーでは、アカウント B のグループまたはユーザーに読み取りアクセスが許可されます。前のポリシーでは、アカウント B へのアクセスが許可されます。ただし、アカウント B の個々のグループとユーザーは、グループまたはユーザーポリシーでリソースへの明示的なアクセス許可が付与されるまで、リソースにアクセスできません。このポリシーのアクセス許可は、前のクロスアカウントポリシーのアクセス許可のサブセットとしてのみ付与できます。アカウント B はそのグループとユーザーに、最初のポリシーでアカウント A から付与されたものよりも多くのアクセス権限を付与することはできません。このポリシーでは、Action アクションのみを許可するように List 要素が明示的に定義されます。このポリシーの Resource 要素は、アカウント A が実装するバケットポリシーの Resource に一致します。

このポリシーを実装するには、アカウント B は IAM を使用して、アカウント B の該当するユーザー (またはグループ) にそのポリシーをアタッチします。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }
}

リソースベースのポリシーを使用して他のアカウントの Amazon SQS キューへのアクセス権を委任する

以下の例では、アカウント A には Amazon SQS キューがあり、キューにアタッチされているリソースベースのポリシーを使用して、キューへのアクセスをアカウント B に許可します。その後で、アカウント B が IAM グループポリシーを使用して、アカウント B のグループにアクセス許可を委任します。

下記の例のキューポリシーでは、アカウント B にアカウント A の queue1 というキューで SendMessage および ReceiveMessage のアクションを実行するアクセス許可が付与されます。ただし、この許可が有効なのは、2014 年 11 月 30 日の正午から午後 3 時の間だけです。アカウント B のアカウント番号は 1111-2222-3333 です。アカウント A は、Amazon SQS を使用して、このポリシーを実装します。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

アカウント B のグループにアクセス権を委任するアカウント B のポリシーは、以下の例のようになります。アカウント B は、IAM を使用して、このポリシーをグループ（またはユーザー）にアタッチします。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

上記の IAM ユーザーポリシーの例では、アカウント B はワイルドカードを使用して、属しているユーザーに、アカウント A のキューに対するすべての Amazon SQS アクションへのアクセスを許可しています。ただし、アカウント B は、アカウント B にアクセス許可が付与されている範囲においてのみ、アクセスを委任できます。2 つ目のポリシーを持つアカウント B グループは、2014 年 11 月 30 日の正午から午後 3 時の間だけキューにアクセスできます。ユーザーが実行できるのは、アカウント A の Amazon SQS キューポリシーで定義されている SendMessage および ReceiveMessage アクションのみです。

アカウントがアクセスを拒否されているとアクセス権を委任できない

AWS アカウント は、自リソースへのアクセスをユーザーの親アカウントに対して明示的に拒否している場合、自リソースへのアクセス権をそれらのユーザーに委任することはできません。この拒否は、アクセス権を付与する既存のポリシーをユーザーが持っているかどうかにかかわらず、そのアカウントのユーザーにも反映されます。

たとえば、アカウント A は自身の S3 バケットについて、アカウント B からのアクセスを明示的に拒否するバケットポリシーを作成するとします。ただし、アカウント B は、アカウント B のユーザーにアカウント A のバケットへのアクセス権を付与する IAM ユーザーポリシーを作成しています。アカウント A の S3 バケットに適用される明示的な拒否は、アカウント B のユーザーにも反映され、アカウント B のユーザーにアクセス権を付与する IAM ユーザーポリシーよりも優先されます (アクセス許可の評価方法については、「ポリシーの評価論理」を参照してください)。

アカウント A のバケットポリシーは、以下のポリシーになります。この例では、アカウント A の S3 バケットの名前を mybucket とし、アカウント B のアカウント番号は 1111-2222-3333 とします。アカウント A は、Amazon S3 を使用して、このポリシーを実装します。

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::mybucket/*"
  }
}

この明示的な拒否は、アカウント A の S3 バケットにアクセスする権限を提供するアカウント B のポリシーをオーバーライドします。