AWS RAM の用語と概念 - AWS Resource Access Manager
リソースの共有共有アカウントコンシューマープリンシパルリソースベースのポリシー管理アクセス許可管理アクセス許可のバージョン

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS RAM の用語と概念

以下の概念は、AWS Resource Access Manager (AWS RAM) を使用したリソース共有の理解に役立ちます。

リソースの共有

AWS RAM を使用してリソース共有を作成することで、リソースを共有できます。リソース共有には次の 3 つの要素があります。

  • 共有する 1 つまたは複数の AWS リソースのリスト。

  • アクセスが付与される 1 つまたは複数のプリンシパルのリスト。

  • 共有に含める各リソースタイプの管理アクセス許可。各管理アクセス許可は、リソース共有内の対象タイプのすべてのリソースに適用されます。

AWS RAM を使用してリソース共有を作成した後は、リソース共有で指定されたプリンシパルに共有のリソースへのアクセスを付与できます。

  • AWS Organizations で AWS RAM 共有を有効にし、共有先のプリンシパルが共有アカウントと同じ組織に所属している場合、アカウント管理者が AWS Identity and Access Management (IAM) アクセス許可ポリシーを使用してリソースを使用するアクセス許可を付与すると、それらのプリンシパルはすぐにリソースにアクセスできるようになります。

  • Organizations で AWS RAM 共有を有効にしない場合でも、組織内の個々の AWS アカウント とはリソースを共有できます。コンシューマーアカウントの管理者は、リソース共有に参加するための招待状を受け取ります。管理者が招待状を承諾すると、リソース共有で指定されたプリンシパルは共有リソースにアクセスできるようになります。

  • リソースタイプでサポートされている場合は、組織外のアカウントと共有することもできます。コンシューマーアカウントの管理者は、リソース共有に参加するための招待状を受け取ります。管理者が招待状を承諾すると、リソース共有で指定されたプリンシパルは共有リソースにアクセスできるようになります。このタイプの共有がサポートされているリソースタイプについては、「共有可能な AWS リソース」の「組織外のアカウントと共有可能」列を参照してください。

共有アカウント

共有アカウントには共有リソースが含まれており、AWS RAM 管理者はこのリソースで AWS RAM を使用して AWS リソースを作成します。

AWS RAM 管理者は、AWS アカウント でリソース共有を作成および設定するアクセス許可を持つ IAM プリンシパルです。AWS RAM は、リソースベースのポリシーをリソース共有内のリソースにアタッチすることで機能するため、AWS RAM 管理者はリソース共有に含まれるリソースタイプごとに AWS のサービス で PutResourcePolicy を呼び出すアクセス許可も必要です。

コンシューマープリンシパル

コンシューマーアカウントは、リソースの共有先の AWS アカウント です。リソース共有は、アカウント全体をプリンシパルとして指定することも、リソースタイプによってはアカウント内の個々のロールやユーザーを指定することもできます。このタイプの共有がサポートされているリソースタイプについては、「共有可能な AWS リソース」の「IAM ロールおよびユーザーと共有可能」列を参照してください。

また AWS RAM は、リソース共有のコンシューマーとしてのサービスプリンシパルもサポートしています。このタイプの共有がサポートされているリソースタイプについては、「共有可能な AWS リソース」の「サービスプリンシパルと共有可能」列を参照してください。

コンシューマーアカウントのプリンシパルは、以下の両方のアクセス許可で許可されているアクションのみを実行できます。

  • リソース共有にアタッチされた管理アクセス許可。これは、コンシューマーアカウントのプリンシパルに付与できる最大のアクセス許可を指定します。

  • コンシューマーアカウントの IAM 管理者が個々のロールまたはユーザーにアタッチする IAM ID ベースのポリシー。これらのポリシーは、指定されたアクションと、共有アカウントのリソースの Amazon リソースネーム (ARN) への Allow アクセスを許可する必要があります。

AWS RAM は、リソース共有のコンシューマーとして、次の IAM プリンシパルタイプをサポートします。

  • 別の AWS アカウント - リソース共有により、共有アカウントに含まれるリソースをコンシューマーアカウントで使用できるようになります。

  • 別のアカウントの個々の IAM ロールまたはユーザー — 一部のリソースタイプでは、個々の IAM ロールまたはユーザーとの直接共有がサポートされています。このプリンシパルタイプは ARN で指定します。

    • IAM ロール – arn:aws:iam::123456789012:role/rolename

    • IAM ユーザー – arn:aws:iam::123456789012:user/username

  • サービスプリンシパル — リソースを AWS サービスと共有して、サービスにリソース共有へのアクセスを許可します。サービスプリンシパルと共有することで、AWS サービスがユーザーに代わってアクションを実行できるため、運用上の負荷を軽減することができます。

    サービスプリンシパルと共有するには、[すべてのユーザーとの共有を許可] を選択して、[プリンシパルタイプの選択] のドロップボックスリストで [サービスプリンシパル] を選択します。サービスプリンシパルの名前を次の形式で指定します。

    • service-id.amazonaws.com

    混乱した代理のリスクを軽減するため、リソースポリシーでは aws:SourceAccount 条件キーにリソース所有者のアカウント ID が表示されます。

  • 組織内のアカウント — 共有アカウントが AWS Organizations で管理されている場合、リソース共有は組織のすべてのアカウントと共有する組織の ID を指定できます。リソース共有では、組織単位 (OU) ID を指定して、その OU 内のすべてのアカウントと共有することもできます。共有アカウントは、自分の組織または自分の組織内の OU ID とのみ共有できます。組織または OU の ARN で組織内のアカウントを指定します。

    • 組織内のすべてのアカウント — 以下は、AWS Organizations にある組織の ARN の例です。

      arn:aws:organizations::123456789012:organization/o-<orgid>

    • 組織単位内のすべてのアカウント — 以下は、OU ID の ARN の例です。

      arn:aws:organizations::123456789012:organization/o-<orgid>/ou-<rootid>-<ouid>

    重要

    組織または OU と共有し、スコープにリソース共有を所有するアカウントが含まれる場合、共有アカウントのすべてのプリンシパルは、共有内のリソースに自動的にアクセスできるようになります。付与されるアクセスは、共有に関連付けられている管理アクセス許可によって定義されます。これは、共有内の各リソースに AWS RAM がアタッチするリソースベースのポリシーで "Principal": "*" が使用されるためです。詳細については、「"Principal": "*" をリソースベースのポリシーで使用することの影響」を参照してください。

    他のコンシューマーアカウントのプリンシパルは、共有のリソースにすぐにはアクセスできません。他のアカウントの管理者は、まず ID ベースのアクセス許可ポリシーを適切なプリンシパルにアタッチする必要があります。これらのポリシーは、リソース共有内の個々のリソース ARN への Allow アクセスを付与する必要があります。これらのポリシーのアクセス許可は、リソース共有に関連付けられた管理アクセス許可で指定されているアクセス許可を超えることはできません。

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

リソースベースのポリシーは、IAM ポリシー言語を実装する JSON テキストドキュメントです。IAM ロール/ユーザーなど、プリンシパルにアタッチする ID ベースのポリシーとは異なり、リソースベースのポリシーをリソースにアタッチします。AWS RAM は、ユーザーがリソース共有で指定した情報に基づいて、ユーザーに代わってリソースベースのポリシーを作成します。ユーザーは、リソースにアクセスできるユーザーを決定する Principal ポリシー要素を指定する必要があります。詳細については、「IAM ユーザーガイド」の「アイデンティティベースおよびリソースベースのポリシー」を参照してください。

AWS RAM で生成されたリソースベースのポリシーは、他のすべての IAM ポリシータイプとともに評価されます。これには、リソースへのアクセスを試みているプリンシパルにアタッチされているすべての IAM ID ベースのポリシーと、AWS アカウント に適用される可能性のある AWS Organizations のサービスコントロールポリシー (SCP) が含まれます。AWS RAM で生成されたリソースベースのポリシーは、他のすべての IAM ポリシーと同じポリシー評価ロジックで評価されます。ポリシー評価の詳細結果および結果から導かれるアクセス許可の決定については、「IAM ユーザーズガイド」の「ポリシーの評価論理」を参照してください。

AWS RAM は、使いやすい抽象化リソースベースのポリシーを提供することで、シンプルで安全なリソース共有を実現します。

リソースベースのポリシーをサポートするリソースタイプについては、AWS RAM は自動的にリソースベースのポリシーを作成し管理します。指定されたリソースで、AWS RAM はそのリソースを含むすべてのリソース共有からの情報を組み合わせて、リソースベースのポリシーを作成します。例えば、2 つの異なるリソース共有を含み、AWS RAM を使用して共有する Amazon SageMaker Pipelines を考えてみましょう。1 つのリソース共有を使用して、組織全体に読み取り専用アクセス権を付与できます。その後、もう 1 つのリソース共有を使用して、1 つのアカウントに SageMaker の実行アクセス許可のみを付与できます。AWS RAM は、これら 2 つの異なるアクセス許可セットを複数のステートメントで 1 つのリソースポリシーに自動的に結合します。その後、結合されたリソースベースのポリシーをパイプラインリソースにアタッチします。ユーザーは、GetResourcePolicy を呼び出すことで基盤となるこのリソースポリシーを表示できます。次に AWS のサービス は、このリソースベースのポリシーを使用して、共有リソースに対してアクションの実行を試みるプリンシパルを承認します。

リソースベースのポリシーを手動で作成し、PutResourcePolicy を呼び出してリソースにアタッチすることもできますが、以下の利点があるため AWS RAM を使用することを推奨します。

  • 共有コンシューマーの見つけやすさ — AWS RAM を使用してリソースを共有する場合、ユーザーは、共有されたすべてのリソースをリソースを所有するサービスのコンソールや API オペレーションで、あたかもそのリソースがユーザーのアカウント内に存在するかのように表示することができます。例えば、AWS CodeBuild プロジェクトを別のアカウントと共有する場合、コンシューマーアカウントのユーザーは、CodeBuild コンソールや CodeBuild API の実行結果でプロジェクトを表示することができます。リソースベースのポリシーを直接アタッチして共有したリソースは、この方法では表示されません。代わりに、リソースを探し、ARN を使用して明示的にリソースを参照する必要があります。

  • 共有所有者の管理しやすさ — AWS RAM を使用してリソースを共有する場合、共有アカウントのリソースの所有者は、どのアカウントがリソースにアクセスできるかを一元的に確認できます。リソースベースのポリシーを使用してリソースを共有する場合、関連するサービスコンソールまたは API で個々のリソースのポリシーを調べることによってのみ、コンシューマーアカウントを確認できます。

  • 効率性 — AWS RAM を使用してリソースを共有する場合、共有する複数のリソースを 1 つのリソースとして管理できます。リソースベースのポリシーのみを使用してリソースを共有する場合は、共有するすべてのリソースに個別のポリシーをアタッチする必要があります。

  • シンプルさ — AWS RAM を使用すると、JSON ベースの IAM ポリシー言語を理解する必要はありません。AWS RAM は、リソース共有にアタッチするアクセス許可を選択できる、すぐに使用できる AWS 管理アクセス許可を提供します。

AWS RAM を使用すると、リソースベースのポリシーをサポートしていないリソースタイプを共有することもできます。このようなリソースタイプでは、AWS RAM は実際のアクセス許可を表すリソースベースのポリシーを自動的に生成します。ユーザーは、GetResourcePolicy を呼び出してこれを表示できます。これには、次のリソースタイプが含まれます。

  • Amazon Aurora – DB クラスター

  • Amazon EC2 — キャパシティ予約と専有ホスト

  • AWS License Manager – ライセンス設定

  • AWS Outposts - ローカルゲートウェイルートテーブル、アウトポスト、サイト

  • Amazon Route 53 – 転送ルール

  • Amazon Virtual Private Cloud — カスタマーが所有する IPv4 アドレス、プレフィックスリスト、サブネット、トラフィックミラーターゲット、トランジットゲートウェイ、トランジットゲートウェイマルチキャストドメイン

AWS RAM で生成されたリソースベースのポリシーの例

EC2 Image Builder のイメージリソースを個々のアカウントと共有する場合、AWS RAM は次の例のようなポリシーを生成し、リソース共有に含まれるすべてのイメージリソースにアタッチします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
            "Action": [
                "imagebuilder:GetImage",
                "imagebuilder:ListImages",
            ],
            "Resource": "arn:aws:imagebuilder:us-east-1:123456789012:image/testimage/1.0.0/44"
        }
    ]
}

EC2 Image Builder のイメージリソースを別の AWS アカウント の IAM ロールまたはユーザーと共有する場合、AWS RAM は次の例のようなポリシーを生成し、リソース共有に含まれるすべてのイメージリソースにアタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/MySampleRole"
      },
      "Action": [
          "imagebuilder:GetImage",
          "imagebuilder:ListImages",
      ],
      "Resource": "arn:aws:imagebuilder:us-east-1:123456789012:image/testimage/1.0.0/44"
    }
  ]
}

EC2 Image Builder のイメージリソースを組織のすべてのアカウント、または OU アカウントと共有する場合、AWS RAM は次の例のようなポリシーを生成し、リソース共有に含まれるすべてのイメージリソースにアタッチします。

注記

このポリシーは "Principal": "*" を使用し、その後 "Condition" 要素を使用して、指定された PrincipalOrgID と一致する ID のアクセス許可を制限します。詳細については、「"Principal": "*" をリソースベースのポリシーで使用することの影響」を参照してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "imagebuilder:GetImage",
                "imagebuilder:ListImages",
            ],
            "Resource": "arn:aws:imagebuilder:us-east-1:123456789012:image/testimage/1.0.0/44"
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-123456789"
                }
            }
        }
    ]
}

"Principal": "*" をリソースベースのポリシーで使用することの影響

"Principal": "*" をリソースベースのポリシーに含めると、そのポリシーは、Condition 要素が存在する場合、その要素によって課せられる制限に従い、リソースを含むアカウント内のすべての IAM プリンシパルにアクセスを付与します。呼び出し元のプリンシパルに適用されるポリシーの明示的な Deny ステートメントは、このポリシーによって付与されたアクセス許可を上書きします。ただし、すべての適用可能な ID ポリシーでの 暗示的な Deny (つまり明示的な Allow の欠如)、アクセス許可の境界、またはプリンシパルに対して Deny しないセッションポリシーは、そのようなリソースベースのポリシーによってアクションへのアクセスを付与します。

この動作がユースケースで適切でない場合は、関連するロールやユーザーに影響を与える明示的な Deny ステートメントを ID ポリシー、アクセス許可の境界、またはセッションポリシーに追加することで、この動作を制限できます。

管理アクセス許可

管理アクセス許可は、リソース共有内のサポートされているリソースタイプに対して、プリンシパルがどのような条件でアクションを実行できるかを定義します。リソース共有を作成する際に、リソース共有に含まれるリソースタイプごとに、どの管理アクセス許可を使用するかを指定する必要があります。管理アクセス許可には、プリンシパルが AWS RAM を使用してリソース共有で実行できる一連の actions と条件が含まれます。

リソース共有では、リソースタイプごとに 1 つの管理アクセス許可のみをアタッチすることができます。特定のタイプの一部のリソースである管理アクセス許可を使用し、同じタイプの他のリソースでは別の管理アクセス許可を使用するようなリソース共有を作成することはできません。これを行うには、2 つの異なるリソース共有を作成し、それらのリソースを分割して、それぞれのセットに異なる管理アクセス許可を付与する必要があります。管理アクセス許可には、2 つの異なるタイプがあります。

AWS 管理アクセス許可

AWS 管理アクセス許可は、AWS が作成および管理し、一般的なユーザーシナリオ向けのアクセス許可を付与します。AWS RAM は、サポートされているすべてのリソースタイプに対して少なくとも 1 つの AWS 管理アクセス許可を定義します。リソースタイプによっては、複数の AWS 管理アクセス許可をサポートし、そのうちの 1 つの管理アクセス許可を AWS デフォルトとして指定しているものもあります。特に指定しない限り、デフォルトの AWS 管理アクセス許可が関連付けられます。

カスタマー管理アクセス許可

カスタマー管理アクセス許可は、AWS RAM で共有リソースを使用する場合に、どのような条件下でどのアクションを実行できるかを正確に指定する、ユーザーが作成し管理する管理アクセス許可です。例えば、大規模な IP アドレスの管理に役立つ Amazon VPC IP Address Manager (IPAM) プールの読み取りアクセスを制限する場合を考えてみます。IP アドレスの割り当てはできるものの、他の開発者アカウントが割り当てた IP アドレスの範囲は表示できないようなカスタマー管理アクセス許可を開発者に対して作成することができます。最小特権のベストプラクティスに従って、必要なアクセス許可のみを付与し、共有リソースでタスクを実行できるような環境を構築することができます。

グローバルコンテキストキーやサービス固有のキーなどの条件を追加して、プリンシパルがリソースにアクセスする条件を指定するオプションを使用して、リソース共有内のリソースタイプに対して独自のアクセス許可を定義します。これらのアクセス許可は、1 つまたは複数の AWS RAM 共有で使用できます。カスタマー管理アクセス許可はリージョンに固有のものです。

AWS RAM は、管理アクセス許可を入力として使用し、共有するリソースに関するリソースベースのポリシーを作成します。

管理アクセス許可のバージョン

管理アクセス許可を変更すると、管理アクセス許可の新しいバージョンが作成されます。新しいバージョンはすべての新しいリソース共有のデフォルトになります。各管理アクセス許可には、必ず 1 つのバージョンがデフォルトバージョンとして指定されています。ユーザーまたは AWS が管理アクセス許可の新しいバージョンを作成する際、既存のリソース共有ごとに管理アクセス許可を明示的に更新する必要があります。リソース共有に適用する前に、この手順で変更を評価できます。すべての新しいリソース共有は、対応するリソースタイプ用の新しいバージョンの管理アクセス許可を自動的に使用します。

AWS 管理アクセス許可のバージョン

AWS は、AWS 管理アクセス許可へのすべての変更を処理します。このような変更で、新しい機能への対応や発見された不具合の除去を行うことができます。リソース共有には、デフォルトの管理アクセス許可のバージョンのみを適用できます。

カスタマー管理アクセス許可のバージョン

カスタマー管理アクセス許可へのすべての変更は、ユーザーが行います。ユーザーは、新しいデフォルトバージョンを作成したり、古いバージョンをデフォルトとして設定したり、リソース共有に関連付けられていないバージョンを削除したりできます。各カスタマー管理アクセス許可には最大 5 つのバージョンを作成できます。

リソース共有を作成または更新する場合、指定した管理アクセス許可のデフォルトバージョンのみをアタッチできます。詳細については、「AWS 管理アクセス許可を新しいバージョンに更新する」を参照してください。