が IAM と AWS Billing Conductor 連携する方法

Billing Conductor へのアクセスを管理するために IAM を使用する前に、 Billing Conductor で使用できる IAM 機能を理解しておく必要があります。Billing Conductor およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには、IAM ユーザーガイドのAWS 「IAM と連携する のサービス」を参照してください。

Billing Conductor のアイデンティティベースのポリシー

IAM アイデンティティベースのポリシーでは許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。Billing Conductor は、特定のアクション、リソース、条件キーをサポートしています。JSON ポリシーで使用するすべての要素については、「IAM ユーザーガイド」の「IAM JSON ポリシー要素のリファレンス」を参照してください。

アクション

管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

JSON ポリシーの Action 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連付けられた AWS API オペレーションと同じです。一致する API オペレーションのない許可のみのアクションなど、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは依存アクションと呼ばれます。

このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

Billing Conductor のポリシーアクションは、アクション Billing Conductor: の前に次のプレフィックスを使用します。たとえば、 Amazon EC2 RunInstances API オペレーションで Amazon EC2 インスタンスを実行するためのアクセス許可をユーザーに付与するには、ポリシーに ec2:RunInstances アクションを含めます。ポリシーステートメントには、Action または NotAction エレメントを含める必要があります。Billing Conductor は、このサービスで実行できるタスクを記述する独自のアクションのセットを定義します。

単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。

"Action": [
      "ec2:action1",
      "ec2:action2"

ワイルドカード (*) を使用して複数アクションを指定できます。例えば、Describe という単語で始まるすべてのアクションを指定するには次のアクションを含めます。

"Action": "ec2:Describe*"

Billing Conductor アクションのリストを確認するには、IAM ユーザーガイドの AWS Billing Conductor で定義されるアクションを参照してください。

リソース

管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

Resource JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ステートメントにはResource または NotResource 要素を含める必要があります。ベストプラクティスとして、Amazon リソースネーム (ARN) を使用してリソースを指定します。これは、リソースレベルの許可と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。

オペレーションのリスト化など、リソースレベルの権限をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (*) を使用します。

"Resource": "*"

Amazon EC2 インスタンスのリソースには次のような ARN があります:

arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId}

ARN の形式の詳細については、「Amazon リソースネーム (ARNs AWS 「サービス名前空間」を参照してください。

例えば、ステートメントで i-1234567890abcdef0 インスタンスを指定するには、次の ARN を使用します。

"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"

特定のアカウントに属するすべてのインスタンスを指定するには、ワイルドカード (*) を使用します。

"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"

リソースを作成するためのアクションなど、一部の Billing Conductor は特定のリソースでは実行できません。このような場合はワイルドカード *を使用する必要があります。

"Resource": "*"

Amazon EC2 API アクションの多くが複数のリソースと関連します。例えば、AttachVolume では Amazon EBS ボリュームをインスタンスにアタッチするため、IAM ユーザーはボリュームおよびインスタンスを使用する権限が必要です。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。

"Resource": [
      "resource1",
      "resource2"

Billing Conductor リソースタイプとその ARNs、IAM ユーザーガイドの AWS Billing Conductor で定義されるリソースを参照してください。各リソースの ARN を指定できるアクションについては、AWS 「Billing Conductor で定義されるアクション」を参照してください。

条件キー

管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

Condition 要素 (または Condition ブロック) を使用すると、ステートメントが有効な条件を指定できます。Condition 要素はオプションです。イコールや未満などの 条件演算子 を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。

1 つのステートメントに複数の Condition 要素を指定する場合、または 1 つの Condition 要素に複数のキーを指定する場合、 AWS では AND 論理演算子を使用してそれらを評価します。1 つの条件キーに複数の値を指定すると、 は論理ORオペレーションを使用して条件 AWS を評価します。ステートメントの権限が付与される前にすべての条件が満たされる必要があります。

条件を指定する際にプレースホルダー変数も使用できます。例えば IAM ユーザーに、IAM ユーザー名がタグ付けされている場合のみリソースにアクセスできる権限を付与することができます。詳細については、「IAM ユーザーガイド」の「‬IAM ポリシーの要素: 変数およびタグ‭」‬を参照してください。

AWS は、グローバル条件キーとサービス固有の条件キーをサポートしています。すべての AWS グローバル条件キーを確認するには、「IAM ユーザーガイド」のAWS 「グローバル条件コンテキストキー」を参照してください。

Billing Conductor は独自の条件キーのセットを定義し、一部のグローバル条件キーの使用をサポートしています。すべての AWS グローバル条件キーを確認するには、IAM ユーザーガイドのAWS 「グローバル条件コンテキストキー」を参照してください。

すべての Amazon EC2 アクションは aws:RequestedRegion および ec2:Region 条件キーをサポートします。詳細については、「例: 特定のリージョンへのアクセスの制限」を参照してください。

Billing Conductor の条件キーのリストを確認するには、IAM ユーザーガイドの AWS Billing Conductor の条件キーを参照してください。条件キーを使用できるアクションとリソースについては、AWS 「Billing Conductor で定義されるアクション」を参照してください。

例

Billing Conductor のアイデンティティベースのポリシー例を確認するには、「AWS Billing Conductor アイデンティティベースのポリシーの例」を参照してください。

Billing Conductor のリソースベースのポリシー

リソースベースのポリシーとは、指定されたプリンシパルが Billing Conductor リソースに対して、実行できるアクションとその条件を指定する JSON ポリシードキュメントです。Amazon S3 は、Amazon S3 バケットに関するリソースベースのアクセス許可ポリシーをサポートします。リソースベースのポリシーでは、リソースごとに他の アカウントに使用許可を付与することができます。リソースベースのポリシーを使用して、 AWS サービスが Amazon S3 バケットにアクセスすることを許可することもできます。

クロスアカウントアクセスを有効にするには、アカウント全体、または別のアカウントの IAM エンティティをリソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる AWS アカウントにある場合は、プリンシパルエンティティにリソースへのアクセス許可も付与する必要があります。アクセス許可は、アイデンティティベースのポリシーをエンティティにアタッチすることで付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、ID ベースのポリシーをさらに付与する必要はありません。詳細については、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

Amazon S3 サービスは、バケットポリシーと呼ばれるリソースベースのポリシーの 1 つのタイプのみサポートし、それがバケットにアタッチされます。このポリシーは、 Billing Conductor に対してアクションを実行できるプリンシパルエンティティ (アカウント、ユーザー、ロール、フェデレーションユーザー) を定義します。

例

Billing Conductor のリソースベースのポリシー例を確認するには、「AWS Billing Conductor リソースベースのポリシーの例」を参照してください。

アクセスコントロールリスト (ACL)

アクセスコントロールリスト (ACL) は、リソースにアタッチできる被付与者のリストです。これらは、アタッチされているリソースにアクセスするための権限をアカウントに付与します。Amazon S3 バケットリソースに ACL をアタッチできます。

Amazon S3 アクセスコントロールリスト (ACL) を使用すると、バケットリソースへのアクセスを管理できます。各バケットには、サブリソースとして ACL がアタッチされています。アクセス権が付与される AWS アカウント、IAM ユーザーまたはユーザーのグループ、または IAM ロールと、アクセス権のタイプを定義します。リソースのリクエストを受信すると、 は対応する ACL AWS をチェックして、リクエスタに必要なアクセス許可があることを確認します。

バケットリソースを作成すると、Amazon S3 は、リソースに対する完全なコントロールをリソース所有者に付与するデフォルト ACL を作成します。次のバケットの ACL 例では、John Doe がバケットの所有者として表示され、そのバケットに対する完全な制御が許可されています。1 つの ACL には最大 100 個の許可を指定することができます。

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://Billing Conductor.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>c1daexampleaaf850ea79cf0430f33d72579fd1611c97f7ded193374c0b163b6</ID>
    <DisplayName>john-doe</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xsi:type="Canonical User">
        <ID>c1daexampleaaf850ea79cf0430f33d72579fd1611c97f7ded193374c0b163b6</ID>
        <DisplayName>john-doe</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy> 

ACL の ID フィールドは、 AWS アカウントの正規ユーザー ID です。所有しているアカウントでこの ID を表示する方法については、AWS 「アカウント正規ユーザー ID の検索」を参照してください。

Billing Conductor タグに基づく承認

Billing Conductor リソースにタグをアタッチしたり、 Billing Conductor へのリクエストでタグを渡したりすることができます。タグに基づいてアクセスを制御するにはBilling Conductor:ResourceTag/key-name、aws:RequestTag/key-name、または aws:TagKeys の条件キーを使用して、ポリシーの条件要素でタグ情報を提供します。

Billing Conductor の IAM ロール

IAM ロールは、特定のアクセス許可を持つ AWS アカウント内のエンティティです。

Billing Conductor での一時的な認証情報の使用

一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するには、AssumeRole や GetFederationToken などの AWS STS API オペレーションを呼び出します。

Billing Conductor では、一時的な認証情報の使用がサポートされています。

サービスにリンクされた役割

サービスにリンクされたロールを使用すると、 AWS サービスは他の サービスのリソースにアクセスして、ユーザーに代わってアクションを実行できます。サービスリンクロールは IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールの許可を表示できますが、編集することはできません。

サービス役割

この機能により、ユーザーに代わってサービスがサービス役割を引き受けることが許可されます。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービス役割はIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、それにより、サービスの機能が損なわれる場合があります。

Billing Conductor では、サービスロールがサポートされています。

Billing Conductor での IAM ロールの選択

Billing Conductor でリソースを作成する場合、 Billing Conductor ユーザーに代わって Amazon EC2 にアクセスすることを許可するロールを選択します。サービスロールまたはサービスにリンクされたロールを以前に作成している場合、 Billing Conductor は選択できるロールのリストを表示します。Amazon EC2 インスタンスの起動と停止のためのアクセスを、許可するロールを選択することが重要です。