翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# の用語と概念 AWS RAM
以下の概念は、 AWS Resource Access Manager (AWS RAM) を使用してリソースを共有する方法を説明するのに役立ちます。
## リソースの共有
を使用してリソースを共有するには AWS RAM 、*リソース共有*を作成します。リソース共有には次の 3 つの要素があります。
+ 共有する 1 つ以上の AWS リソースのリスト。
+ アクセスが付与される 1 つまたは複数の[プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying)のリスト。
+ 共有に含める各リソースタイプの[管理アクセス許可](#term-managed-permission)。各管理アクセス許可は、リソース共有内の対象タイプのすべてのリソースに適用されます。
AWS RAM を使用してリソース共有を作成すると、リソース共有で指定されたプリンシパルに共有のリソースへのアクセスを許可できます。
+ と AWS RAM の共有を有効にし AWS Organizations、共有するプリンシパルが共有アカウントと同じ組織にある場合、アカウント管理者が AWS Identity and Access Management (IAM) アクセス許可ポリシーを使用してリソースを使用するアクセス許可を付与すると、それらのプリンシパルはすぐにアクセスできるようになります。
+ Organizations と AWS RAM の共有を有効にしない場合でも、組織 AWS アカウント 内の個人とリソースを共有できます。コンシューマーアカウントの管理者は、リソース共有に参加するための招待状を受け取ります。管理者が招待状を承諾すると、リソース共有で指定されたプリンシパルは共有リソースにアクセスできるようになります。
+ リソースタイプでサポートされている場合は、組織外のアカウントと共有することもできます。コンシューマーアカウントの管理者は、リソース共有に参加するための招待状を受け取ります。管理者が招待状を承諾すると、リソース共有で指定されたプリンシパルは共有リソースにアクセスできるようになります。このタイプの共有がサポートされているリソースタイプについては、「[共有可能な AWS リソース](shareable.md)」の「**組織外のアカウントと共有可能**」列を参照してください。
## 共有アカウント
*共有アカウント*には、共有されているリソースと、 AWS RAM 管理者が を使用してリソース共有を作成する AWS リソースが含まれています AWS RAM。
AWS RAM 管理者は、 でリソース共有を作成および設定するアクセス許可を持つ IAM プリンシパルです AWS アカウント。はリソースベースのポリシーをリソース共有のリソースにアタッチすることで AWS RAM 機能するため、 AWS RAM 管理者はリソース共有に含まれる各リソースタイプの AWS のサービス で `PutResourcePolicy`オペレーションを呼び出すアクセス許可も必要です。
## コンシューマープリンシパル
*消費アカウント*は、リソースが共有される AWS アカウント です。リソース共有は、アカウント全体をプリンシパルとして指定することも、リソースタイプによってはアカウント内の個々のロールやユーザーを指定することもできます。このタイプの共有がサポートされているリソースタイプについては、「[共有可能な AWS リソース](shareable.md)」の「**IAM ロールおよびユーザーと共有可能**」列を参照してください。
AWS RAM は、リソース共有のコンシューマーとしてサービスプリンシパルもサポートしています。このタイプの共有がサポートされているリソースタイプについては、「[共有可能な AWS リソース](shareable.md)」の「**サービスプリンシパルと共有可能**」列を参照してください。
コンシューマーアカウントのプリンシパルは、以下の***両方の***アクセス許可で許可されているアクションのみを実行できます。
+ リソース共有にアタッチされた管理アクセス許可。これは、コンシューマーアカウントのプリンシパルに付与できる*最大*のアクセス許可を指定します。
+ コンシューマーアカウントの IAM 管理者が個々のロールまたはユーザーにアタッチする IAM ID ベースのポリシー。これらのポリシーは、指定されたアクションと、共有アカウントのリソースの [Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) への `Allow` アクセスを許可する必要があります。
AWS RAM は、リソース共有のコンシューマーとして次の IAM プリンシパルタイプをサポートしています。
+ **もう AWS アカウント** 1 つ — リソース共有は、共有アカウントに含まれるリソースを消費アカウントで利用できるようにします。
+ **別のアカウントの個々の 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-`
+ **組織単位内のすべてのアカウント** — 以下は、OU ID の ARN の例です。
`arn:aws:organizations::123456789012:organization/o-/ou--`
**重要**
組織または OU と共有し、スコープにリソース共有を所有するアカウントが含まれる場合、共有アカウントのすべてのプリンシパルは、共有内のリソースに自動的にアクセスできるようになります。付与されるアクセスは、共有に関連付けられている管理アクセス許可によって定義されます。これは、共有内の各リソースにア AWS RAM タッチするリソースベースのポリシーが を使用するためです`"Principal": "*"`。詳細については、「["Principal": "\*" をリソースベースのポリシーで使用することの影響](#term-principal-star)」を参照してください。
他のコンシューマーアカウントのプリンシパルは、共有のリソースにすぐにはアクセスできません。他のアカウントの管理者は、まず ID ベースのアクセス許可ポリシーを適切なプリンシパルにアタッチする必要があります。これらのポリシーは、リソース共有内の個々のリソース ARN への `Allow` アクセスを付与する必要があります。これらのポリシーのアクセス許可は、リソース共有に関連付けられた管理アクセス許可で指定されているアクセス許可を超えることはできません。
## リソースベースのポリシー
リソースベースのポリシーは、IAM ポリシー言語を実装する JSON テキストドキュメントです。IAM ロールやユーザーなど、プリンシパルにアタッチするアイデンティティベースのポリシーとは異なり、リソースベースのポリシーをリソースにアタッチします。 は、リソース共有に提供した情報に基づいて、ユーザーに代わってリソースベースのポリシー AWS RAM を作成します。ユーザーは、リソースにアクセスできるユーザーを決定する `Principal` ポリシー要素を指定する必要があります。詳細については、「*IAM ユーザーガイド*」の「[アイデンティティベースおよびリソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)」を参照してください。
によって生成されたリソースベースのポリシー AWS RAM は、他のすべての IAM ポリシータイプとともに評価されます。これには、リソースにアクセスしようとしているプリンシパルにアタッチ AWS Organizations された IAM アイデンティティベースのポリシーと、 に適用される可能性のある のサービスコントロールポリシー (SCPs) が含まれます AWS アカウント。によって生成されたリソースベースのポリシーは、他のすべての IAM ポリシーと同じポリシー評価ロジック AWS RAM に参加します。ポリシー評価の詳細結果および結果から導かれるアクセス許可の決定については、「**IAM ユーザーズガイド」の「[ポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
AWS RAM は、easy-to-use抽象化リソースベースのポリシーを提供することで、シンプルで安全なリソース共有エクスペリエンスを提供します。
リソースベースのポリシーをサポートするリソースタイプの場合、 はリソースベースのポリシー AWS RAM を自動的に構築および管理します。指定されたリソースで、 AWS RAM はそのリソースを含むすべてのリソース共有からの情報を組み合わせて、リソースベースのポリシーを作成します。たとえば、 を使用して共有 AWS RAM し、2 つの異なるリソース共有に含める Amazon SageMaker AI パイプラインを考えてみましょう。1 つのリソース共有を使用して、組織全体に読み取り専用アクセス権を付与できます。その後、他のリソース共有を使用して、1 つのアカウントに SageMaker AI 実行アクセス許可のみを付与できます。 は、これらの 2 つの異なるアクセス許可セット AWS RAM を複数のステートメントを持つ 1 つのリソースポリシーに自動的に結合します。その後、結合されたリソースベースのポリシーをパイプラインリソースにアタッチします。この基盤となるリソースポリシーを表示するには、 [https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourcePolicies.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourcePolicies.html)オペレーションを呼び出します。 AWS のサービス 次に、そのリソースベースのポリシーを使用して、共有リソースに対してアクションを実行しようとするプリンシパルを承認します。
リソースベースのポリシーを手動で作成し、`PutResourcePolicy` を呼び出してリソースにアタッチすることもできますが、以下の利点があるため AWS RAM を使用することを推奨します。
+ **共有コンシューマーの検出可能性** – を使用してリソースを共有すると AWS RAM、ユーザーは、共有されているすべてのリソースを、リソースを所有するサービスのコンソールおよび API オペレーションで、それらのリソースがユーザーのアカウントに直接あったかのように直接表示できます。例えば、 AWS CodeBuild プロジェクトを別のアカウントと共有する場合、消費アカウントのユーザーはCodeBuild コンソールと実行された CodeBuild API オペレーションの結果でプロジェクトを表示できます。リソースベースのポリシーを直接アタッチして共有したリソースは、この方法では表示されません。代わりに、リソースを探し、ARN を使用して明示的にリソースを参照する必要があります。
+ **共有所有者の管理性** – を使用してリソースを共有すると AWS RAM、共有アカウントのリソース所有者は、自分のリソースにアクセスできる他のアカウントを一元的に確認できます。リソースベースのポリシーを使用してリソースを共有する場合、関連するサービスコンソールまたは API で個々のリソースのポリシーを調べることによってのみ、コンシューマーアカウントを確認できます。
+ **効率** – を使用してリソースを共有する場合 AWS RAM、複数のリソースを共有して 1 つのユニットとして管理できます。リソースベースのポリシーのみを使用してリソースを共有する場合は、共有するすべてのリソースに個別のポリシーをアタッチする必要があります。
+ **シンプル –** では AWS RAM、JSON ベースの IAM ポリシー言語を理解する必要はありません。 は、リソース共有にアタッチするために選択できるready-to-use AWS 管理アクセス許可 AWS RAM を提供します。
を使用すると AWS RAM、リソースベースのポリシーをまだサポートしていない一部のリソースタイプを共有することもできます。このようなリソースタイプの場合、 は実際のアクセス許可の表現としてリソースベースのポリシー AWS RAM を自動的に生成します。ユーザーは、[https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourcePolicies.html](https://docs.aws.amazon.com/ram/latest/APIReference/API_GetResourcePolicies.html) を呼び出してこれを表示できます。これには、次のリソースタイプが含まれます。
+ 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 を生成し、リソース共有に含まれるイメージリソースにアタッチします。
------
#### [ JSON ]
****
```
{
"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 イメージリソースを別の の ***IAM ロールまたはユーザー***と共有する場合 AWS アカウント、 は次の例のようなポリシー AWS RAM を生成し、リソース共有に含まれるイメージリソースにアタッチします。
------
#### [ JSON ]
****
```
{
"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": "\*" をリソースベースのポリシーで使用することの影響](#term-principal-star)」を参照してください。
------
#### [ JSON ]
****
```
{
"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` ステートメントは、このポリシーによって付与されたアクセス許可を上書きします。ただし、該当するアイデンティティポリシー、アクセス許可の境界ポリシー、またはセッションポリシーが***暗黙的***な `Deny` の（つまり、*明示的な* `Allow` が存在しない）場合でも、そのリソースベースのポリシーによってアクションへのアクセスを付与されているプリンシパルに対して `Deny` が適用されることには***なりません***。
この動作がユースケースで適切でない場合は、関連するロールやユーザーに影響を与える****明示的な** `Deny` ステートメントを ID ポリシー、アクセス許可の境界、またはセッションポリシーに追加することで、この動作を制限できます。
## 管理アクセス許可
管理アクセス許可は、リソース共有内のサポートされているリソースタイプに対して、プリンシパルがどのような条件でアクションを実行できるかを定義します。リソース共有を作成する際に、リソース共有に含まれるリソースタイプごとに、どの管理アクセス許可を使用するかを指定する必要があります。管理アクセス許可は、プリンシパルが を使用して共有リソースで実行できる一連の `actions` および *条件*を一覧表示します AWS RAM。
リソース共有では、リソースタイプごとに 1 つの管理アクセス許可のみをアタッチすることができます。特定のタイプの一部のリソースである管理アクセス許可を使用し、同じタイプの他のリソースでは別の管理アクセス許可を使用するようなリソース共有を作成することはできません。これを行うには、2 つの異なるリソース共有を作成し、それらのリソースを分割して、それぞれのセットに異なる管理アクセス許可を付与する必要があります。管理アクセス許可には、2 つの異なるタイプがあります。
**AWS マネージドアクセス許可**
AWS 管理アクセス許可は、 によって作成および管理 AWS され、一般的な顧客シナリオに対するアクセス許可を付与します。 は、サポートされているリソースタイプごとに少なくとも 1 つの AWS 管理アクセス許可 AWS RAM を定義します。一部のリソースタイプは、複数の AWS 管理アクセス許可をサポートし、1 つの管理アクセス許可を AWS デフォルトとして指定します。特に指定しない限り、[デフォルトの AWS 管理アクセス許可](security-ram-permissions.md#permissions-types)は関連付けられます。
**カスタマー管理アクセス許可**
カスタマー管理アクセス許可は、 AWS RAMで共有リソースを使用する場合に、どのような条件下でどのアクションを実行できるかを正確に指定する、ユーザーが作成し管理する管理アクセス許可です。例えば、大規模な IP アドレスの管理に役立つ Amazon VPC IP Address Manager (IPAM) プールの読み取りアクセスを制限する場合を考えてみます。IP アドレスの割り当てはできるものの、他の開発者アカウントが割り当てた IP アドレスの範囲は表示できないようなカスタマー管理アクセス許可を開発者に対して作成することができます。最小特権のベストプラクティスに従って、必要なアクセス許可のみを付与し、共有リソースでタスクを実行できるような環境を構築することができます。
[グローバルコンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)や[サービス固有のキー](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)などの条件を追加して、プリンシパルがリソースにアクセスする条件を指定するオプションを使用して、リソース共有内のリソースタイプに対して独自のアクセス許可を定義します。これらのアクセス許可は、1 つ以上の AWS RAM 共有で使用できます。カスタマー管理アクセス許可はリージョンに固有のものです。
AWS RAM は、共有する[リソースのリソースベースのポリシー](#term-resource-based-policy)を作成するための入力としてマネージドアクセス許可を取得します。
## 管理アクセス許可のバージョン
管理アクセス許可を変更すると、管理アクセス許可の新しいバージョンが作成されます。新しいバージョンはすべての新しいリソース共有のデフォルトになります。各管理アクセス許可には、必ず 1 つのバージョンがデフォルトバージョンとして指定されています。または が新しいマネージドアクセス許可バージョン AWS を作成する場合は、既存のリソース共有ごとにマネージドアクセス許可を明示的に更新する必要があります。リソース共有に適用する前に、この手順で変更を評価できます。すべての新しいリソース共有は、対応するリソースタイプ用の新しいバージョンの管理アクセス許可を自動的に使用します。
**AWS マネージドアクセス許可バージョン**
AWS は、 AWS マネージドアクセス許可に対するすべての変更を処理します。このような変更で、新しい機能への対応や発見された不具合の除去を行うことができます。リソース共有には、デフォルトの管理アクセス許可のバージョンのみを適用できます。
**カスタマー管理アクセス許可のバージョン**
カスタマー管理アクセス許可へのすべての変更は、ユーザーが行います。ユーザーは、新しいデフォルトバージョンを作成したり、古いバージョンをデフォルトとして設定したり、リソース共有に関連付けられていないバージョンを削除したりできます。各カスタマー管理アクセス許可には最大 5 つのバージョンを作成できます。
リソース共有を作成または更新する場合、指定した管理アクセス許可のデフォルトバージョンのみをアタッチできます。詳細については、「[AWS マネージドアクセス許可を新しいバージョンに更新する](working-with-sharing-update-permissions.md)」を参照してください。