翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のセキュリティ AWS Resource Access Manager
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、お客様と AWS お客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。
+ **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任があります AWS クラウド。 AWS また、 では、安全に使用できるサービスも提供しています。[「AWS 」 コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。 AWS Resource Access Manager (AWS RAM) に適用するコンプライアンスプログラムの詳細については、「[コンプライアンスプログラムによるAWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、 を使用する際の責任共有モデルの適用方法を理解するのに役立ちます AWS RAM。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成する AWS RAM ように を設定する方法を示します。また、 AWS RAM リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [でのデータ保護 AWS Resource Access Manager](data-protection.md)
+ [の ID とアクセスの管理 AWS Resource Access Manager](security-iam.md)
+ [AWS RAM でのログ記録とモニタリング](security-monitoring.md)
+ [のコンプライアンス検証 AWS Resource Access Manager](compliance-validation.md)
+ [の耐障害性 AWS Resource Access Manager](disaster-recovery-resiliency.md)
+ [のインフラストラクチャセキュリティ AWS Resource Access Manager](infrastructure-security.md)
+ [インターフェイスエンドポイント (AWS PrivateLink) AWS Resource Access Manager を使用した へのアクセス](vpc-interface-endpoints.md)
# でのデータ保護 AWS Resource Access Manager
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 でのデータ保護に適用されます AWS Resource Access Manager。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ を使用して API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS 暗号化ソリューションと、その中のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール AWS RAM 、API、または SDK を使用して AWS CLIまたは他の AWS のサービス を操作する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
# の ID とアクセスの管理 AWS Resource Access Manager
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するのに役立つ AWS サービスです。IAM の管理者は、誰を*認証* (サインイン) し、誰に AWS リソースの使用*を許可する* (アクセス許可を付与する) かを制御します。IAM を使用して、 のロール、ユーザー、グループなどのプリンシパルを作成します AWS アカウント。これらのプリンシパルが AWS リソースを使用してタスクを実行するためのアクセス許可を制御します。IAMは追加料金なしでご利用いただけます。カスタム IAM ポリシーの管理と作成の詳細については、「**IAM ユーザーズガイド」の「[IAM ポリシーを管理する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)」を参照してください。
**Topics**
+ [が IAM と AWS RAM 連携する方法](security-iam-policies.md)
+ [AWS の 管理ポリシー AWS Resource Access Manager](security-iam-awsmanpol.md)
+ [のサービスにリンクされたロールの使用 AWS RAM](using-service-linked-roles.md)
+ [の IAM ポリシーの例 AWS RAM](security-iam-policies-examples.md)
+ [AWS Organizations および のサービスコントロールポリシーの例 AWS RAM](security-scp.md)
+ [とのリソース共有の無効化 AWS Organizations](security-disable-sharing-with-orgs.md)
# が IAM と AWS RAM 連携する方法
デフォルトでは、IAM プリンシパルには AWS RAM リソースを作成または変更するアクセス許可はありません。IAM プリンシパルがリソースを作成または変更してタスクを実行できるようにするには、以下の手順のいずれかを実行します。これらのアクションは、特定のリソースおよび API アクションを使用するアクセス許可を付与します。
アクセスを提供するには、ユーザー、グループ、またはロールにアクセス許可を追加します。
+ 以下のユーザーとグループ AWS IAM アイデンティティセンター:
アクセス許可セットを作成します。「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)」の手順に従ってください。
+ IAM 内で、ID プロバイダーによって管理されているユーザー:
ID フェデレーションのロールを作成します。詳細については *IAM ユーザーガイド* の [サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) を参照してください。
+ IAM ユーザー:
+ ユーザーが担当できるロールを作成します。手順については *IAM ユーザーガイド* の [IAM ユーザーのロールの作成](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) を参照してください。
+ (お奨めできない方法) ポリシーをユーザーに直接アタッチするか、ユーザーをユーザーグループに追加します。*IAM ユーザーガイド* の [ユーザー (コンソール) へのアクセス許可の追加](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) の指示に従います。
AWS RAM には、多くのユーザーのニーズに対応するために使用できる AWS 管理ポリシーがいくつか用意されています。これらの詳細については、「[AWS の 管理ポリシー AWS Resource Access Manager](security-iam-awsmanpol.md)」を参照してください。
ユーザーに付与するアクセス許可を細かく制御する必要がある場合、IAM コンソールで独自のポリシーを構築できます。ポリシーを作成して IAM ロールとユーザーにアタッチする方法については、「**AWS Identity and Access Management ユーザーズガイド」の「[IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。
以下のセクションでは、IAM アクセス許可ポリシーを構築するための AWS RAM 具体的な詳細について説明します。
**Contents**
+ [ポリシーの構造](#structure)
+ [効果](#iam-policies-effect)
+ [Action](#iam-policies-action)
+ [[リソース]](#iam-policies-resource)
+ [Condition](#iam-policies-condition)
## ポリシーの構造
IAM アクセス許可ポリシーは 効果、アクション、リソース、および条件を含む JSON ドキュメントです。通常、IAM ポリシーは以下の形式をとります。
```
{
"Statement":[{
"Effect":"",
"Action":"",
"Resource":"",
"Condition":{
"":{
"":""
}
}
}]
}
```
### 効果
**効果文は、ポリシーでアクションを実行するプリンシパルアクセスを許可するか拒否するかを示します。指定できる値は、`Allow` および `Deny` などです。
### Action
*Action* ステートメントは、ポリシーがアクセス許可を許可または拒否する AWS RAM API アクションを指定します。許可されるアクションの詳細な一覧については、*IAM ユーザーガイド* の「[AWS Resource Access Managerで定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsresourceaccessmanager.html#awsresourceaccessmanager-actions-as-permissions)」を参照してください。
### [リソース]
Resource **ステートメントは、ポリシーの影響を受ける AWS RAM リソースを指定します。ステートメント内でリソースを指定するには、一意の Amazon リソースネーム (ARN) を使用する必要があります。許可されるリソースの詳細な一覧については、*IAM ユーザーガイド* の「[AWS Resource Access Managerで定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsresourceaccessmanager.html#awsresourceaccessmanager-resources-for-iam-policies)」を参照してください。
### Condition
*条件*ステートメントはオプションです。ポリシーが適用される条件をさらに絞り込むために使用できます。 は次の条件キー AWS RAM をサポートしています。
+ `aws:RequestTag/${TagKey}` - 指定されたタグキーを含むタグがサービスリクエストに存在し、指定された値があるかどうかをテストします。
+ `aws:ResourceTag/${TagKey}` — サービスリクエストの対象となるリソースに、ポリシーで指定したタグキーが付いたタグがアタッチされているかどうかをテストします。
次の条件例では、サービスリクエストで参照されているリソースに、キー名「Owner」、値「Dev Team」のタグがアタッチされているかどうかを確認します。
```
"Condition" : {
"StringEquals" : {
"aws:ResourceTag/Owner" : "Dev Team"
}
}
```
+ `aws:TagKeys` - リソース共有の作成またはタグ付けに使用すべきタグキーを指定します。
+ `ram:AllowsExternalPrincipals` - サービスリクエスト内のリソース共有が外部プリンシパルとの共有を許可しているかどうかをテストします。外部プリンシパルは、 の組織 AWS アカウント 外の です AWS Organizations。ここで `False` と評価された場合、このリソース共有は同じ組織内のアカウントでのみ共有できます。
+ `ram:PermissionArn` - サービスリクエストで指定されたアクセス許可 ARN が、ポリシーで指定した ARN 文字列と一致するかどうかをテストします。
+ `ram:PermissionResourceType` - サービスリクエストで指定されたアクセス許可が、ポリシーで指定したリソースタイプで有効かどうかをテストします。リソースタイプは、[共有可能なリソースタイプ](shareable.md)の一覧に示す形式に従って指定する必要があります。
+ `ram:Principal` - サービスリクエストで指定されたプリンシパルの ARN が、ポリシーで指定した ARN 文字列と一致するかどうかをテストします。
+ `ram:RequestedAllowsExternalPrincipals` - サービスリクエストに `allowExternalPrincipals` パラメータが含まれているかどうか、またその引数がポリシーで指定した値と一致するかどうかをテストします。
+ `ram:RequestedResourceType` - 処理対象リソースのリソースタイプが、ポリシーで指定したリソースタイプ文字列と一致するかどうかをテストします。リソースタイプは、[共有可能なリソースタイプ](shareable.md)の一覧に示す形式に従って指定する必要があります。
+ `ram:ResourceArn` - サービスリクエストの処理対象リソースの ARN が、ポリシーで指定した ARN と一致するかどうかをテストします。
+ `ram:ResourceShareName` - サービスリクエストの処理対象リソースの名前が、ポリシーで指定した文字列と一致するかどうかをテストします。
+ `ram:ShareOwnerAccountId` - サービスリクエストの処理対象リソースのアカウント ID 番号が、ポリシーで指定した文字列と一致するかどうかをテストします。
# AWS の 管理ポリシー AWS Resource Access Manager
AWS Resource Access Manager は現在、このトピックで説明されているいくつかの AWS RAM 管理ポリシーを提供しています。
**Topics**
+ [AWSResourceAccessManagerReadOnlyAccess](#security-iam-managed-policies-AWSResourceAccessManagerReadOnlyAccess)
+ [AWSResourceAccessManagerFullAccess](#security-iam-managed-policies-AWSResourceAccessManagerFullAccess)
+ [AWSResourceAccessManagerResourceShareParticipantAccess](#security-iam-managed-policies-AWSResourceAccessManagerResourceShareParticipantAccess)
+ [AWSResourceAccessManagerServiceRolePolicy](#security-iam-managed-policies-AWSResourceAccessManagerServiceRolePolicy)
+ [ポリシーの更新](#security-iam-awsmanpol-updates)
前のリストでは、最初の 3 つのポリシーを IAM ロール、グループ、およびユーザーにアタッチして、アクセス許可を付与できます。リスト内の最後のポリシーは、 AWS RAM サービスのサービスリンクロールです。
AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できるように、多くの一般的なユースケースにアクセス許可を付与するように設計されています。
AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS マネージドポリシーを更新する可能性が高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS マネージドポリシー: AWSResourceAccessManagerReadOnlyAccess
`AWSResourceAccessManagerReadOnlyAccess` ポリシーを IAM アイデンティティにアタッチできます。
このポリシーは、 AWS アカウントが所有するリソース共有について読み取り専用アクセス許可を提供します。
これは、`Get*` または `List*` オペレーションのいずれかを実行するアクセス許可を付与することによって実現されます。リソース共有を変更する機能は用意されていません。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ram` － プリンシパルは、アカウントが所有するリソース共有に関する詳細を表示できるようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ram:Get*",
"ram:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## AWS マネージドポリシー: AWSResourceAccessManagerFullAccess
`AWSResourceAccessManagerFullAccess` ポリシーを IAM アイデンティティにアタッチできます。
このポリシーでは、 AWS アカウントが所有するリソース共有を表示または変更できるフル管理アクセス権を提供します。
これは、あらゆる `ram` オペレーションを実行するアクセス許可を付与することで実現されます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ram` － プリンシパルは、 AWS アカウントが所有するリソース共有に関する情報を表示または変更できるようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ram:*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## AWS マネージドポリシー: AWSResourceAccessManagerResourceShareParticipantAccess
`AWSResourceAccessManagerResourceShareParticipantAccess` ポリシーを IAM アイデンティティにアタッチできます。
このポリシーにより、プリンシパルは、このポリシーと共有されているリソース共有を承諾または拒否したり AWS アカウント、これらのリソース共有の詳細を表示したりできます。これらのリソース共有を変更する機能は用意されていません。
これは、一部の `ram` オペレーションを実行するアクセス許可を付与することで実現されます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ram` － プリンシパルは、リソース共有の招待を受け入れるか拒否でき、アカウントと共有されているリソース共有の詳細を表示できるようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ram:AcceptResourceShareInvitation",
"ram:GetResourcePolicies",
"ram:GetResourceShareInvitations",
"ram:GetResourceShares",
"ram:ListPendingInvitationResources",
"ram:ListPrincipals",
"ram:ListResources",
"ram:RejectResourceShareInvitation"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## AWS マネージドポリシー: AWSResourceAccessManagerServiceRolePolicy
AWS 管理ポリシー`AWSResourceAccessManagerServiceRolePolicy`は、サービスにリンクされたロールでのみ使用できます AWS RAM。このポリシーをアタッチ、デタッチ、変更、または削除することはできません。
このポリシーは AWS RAM 、組織の構造への読み取り専用アクセスを に付与します。 AWS RAM と の統合を有効にすると AWS Organizations、 は [AWSServiceRoleForResourceAccessManager](https://console.aws.amazon.com/iam/home#/roles/AWSServiceRoleForResourceAccessManager) という名前のサービスにリンクされたロール AWS RAM を自動的に作成します。このロールは、 AWS RAM コンソールで組織の構造を表示する場合など、組織とそのアカウントに関する情報を検索する必要があるときにサービスが引き受けます。
これは、組織の構造とアカウントの詳細を提供する `organizations:Describe` と `organizations:List` のオペレーションを実行するための読み取り専用アクセス許可を付与することによって実現されます。
**アクセス許可の詳細**
このポリシーには以下のアクセス許可が含まれています。
+ `organizations` － プリンシパルは、組織単位を含む組織構造に関する情報、およびそれらに含まれる AWS アカウント を表示できるようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:ListAccounts",
"organizations:ListAccountsForParent",
"organizations:ListChildren",
"organizations:ListOrganizationalUnitsForParent",
"organizations:ListParents",
"organizations:ListRoots"
],
"Resource": "*"
},
{
"Sid": "AllowDeletionOfServiceLinkedRoleForResourceAccessManager",
"Effect": "Allow",
"Action": [
"iam:DeleteRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/ram.amazonaws.com/*"
]
}
]
}
```
------
## AWS RAM AWS 管理ポリシーの更新
このサービスがこれらの変更の追跡を開始 AWS RAM してからの の AWS 管理ポリシーの更新に関する詳細を表示します。このページの変更に関する自動アラートについては、 AWS RAM ドキュメント履歴ページの RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| AWS Resource Access Manager が変更の追跡を開始しました | AWS RAM は既存の管理ポリシーを文書化し、変更の追跡を開始しました。 | 2021 年 9 月 16 日 |
# のサービスにリンクされたロールの使用 AWS RAM
AWS Resource Access Manager は AWS Identity and Access Management (IAM)[ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスにリンクされたロールは、 AWS RAM サービスに直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは によって事前定義 AWS されており、ユーザーに代わって他の AWS サービスを呼び出す AWS RAM ために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、 の設定 AWS RAM が簡単になります。 は、サービスにリンクされたロールのアクセス許可 AWS RAM を定義します。特に定義されている場合を除き、 のみがサービスにリンクされたロールを引き受け AWS RAM ることができます。定義した許可には、信頼ポリシーと許可ポリシーの両方が含まれます。この許可ポリシーを他のIAM エンティティにアタッチすることはできません。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## のサービスにリンクされたロールのアクセス許可 AWS RAM
AWS RAM は、 との共有を有効にする`AWSServiceRoleForResourceAccessManager`ときに、 という名前のサービスにリンクされたロールを使用します AWS Organizations。このロールは、メンバーアカウントのリストや各アカウントが属する組織単位など、組織の詳細を表示するアクセス許可を AWS RAM サービスに付与します。
このサービスにリンクされたロールは、ロールの引き受けについて以下のサービスを信頼します。
+ `ram.amazonaws.com`
AWSResourceAccessManagerServiceRolePolicy という名前のロールアクセス許可ポリシーは、このサービスにリンクされたロールにアタッチされ、 AWS RAM は指定されたリソースに対して次のアクションを実行できます。
+ アクション: 組織構造の詳細を取得する読み取り専用アクション。アクションの完全なリストについては、IAM コンソールで [AWSResourceAccessManagerServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSResourceAccessManagerServiceRolePolicy$jsonEditor) を参照してください。
プリンシパルが組織内での AWS RAM 共有を有効にするには、そのプリンシパル (ユーザー、グループ、ロールなどの IAM エンティティ) に、サービスにリンクされたロールを作成するアクセス許可が必要です。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## のサービスにリンクされたロールの作成 AWS RAM
サービスリンクロールを手動で作成する必要はありません。で組織内での共有を有効にする AWS RAM か AWS マネジメントコンソール、 AWS CLI または AWS API を使用してアカウントで [EnableSharingWithAwsOrganization](https://docs.aws.amazon.com/ram/latest/APIReference/API_EnableSharingWithAwsOrganization.html) を実行すると、 によってサービスにリンクされたロール AWS RAM が作成されます。
`enable-sharing-with-aws-organizations` を呼び出、サービスにリンクされたロールをアカウントに作成します。
このサービスにリンクされたロールを削除すると、 には組織の構造の詳細を表示するアクセス許可 AWS RAM がなくなります。
## のサービスにリンクされたロールの編集 AWS RAM
AWS RAM では、AWSResourceAccessManagerServiceRolePolicy サービスにリンクされたロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## のサービスにリンクされたロールの削除 AWS RAM
IAM コンソール、、 AWS CLI または AWS API を使用して、サービスにリンクされたロールを手動で削除できます。
**サービスリンクロールを IAM で手動削除するには**
IAM コンソール、 AWS CLI、または AWS API を使用して、`AWSResourceAccessManagerServiceRolePolicy`サービスにリンクされたロールを削除します。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」の「*サービスリンクロールの削除*」を参照してください。
## AWS RAM サービスにリンクされたロールでサポートされているリージョン
AWS RAM は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。リージョンの詳細については、[AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html)*の「Amazon Web Services 全般のリファレンスリージョンとエンドポイント*」を参照してください。
# の IAM ポリシーの例 AWS RAM
このトピックでは、特定のリソースとリソースタイプの共有と共有の制限 AWS RAM を示す の IAM ポリシーの例を示します。
**Topics**
+ [特定のリソースの共有を許可する](#owner-share-specific-resources)
+ [特定のリソースタイプの共有を許可する](#owner-share-resource-types)
+ [外部との共有を制限する AWS アカウント](#control-access-owner-external)
## 例 1: 特定のリソースの共有を許可する
IAM アクセス許可ポリシーを使用して、特定のリソースのみをリソース共有に関連付けるようにプリンシパルを制限できます。
例えば、以下のポリシーでは、指定した Amazon リソースネーム (ARN) のリゾルバールールのみを共有するようにプリンシパルを制限しています。`StringEqualsIfExists` 演算子は、要求に `ResourceArn` パラメータが含まれていないか、またはパラメータが含まれている場合、値が指定された ARN と完全に一致する要求を許可します。
`...IfExists` 演算子を使用するタイミングと理由の詳細については、「**IAM ユーザーズガイド」の「[...IfExists 条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IfExists)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ram:CreateResourceShare", "ram:AssociateResourceShare"],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"ram:ResourceArn": "arn:aws:route53resolver:us-west-2:123456789012:resolver-rule/rslvr-rr-5328a0899aexample"
}
}
}]
}
```
------
## 例 2: 特定のリソースタイプの共有を許可する
IAM ポリシーを使用して、特定のリソースのみをリソース共有に関連付けるようにプリンシパルを限定できます。
アクション `AssociateResourceShare` および `CreateResourceShare` は、プリンシパルおよび `resourceArns` を独立した入力パラメータとして受け入れることができます。したがって、 は各プリンシパルとリソースを個別に AWS RAM 承認するため、複数の[リクエストコンテキスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-reqcontext.html)が存在する可能性があります。つまり、プリンシパルが AWS RAM リソース共有に関連付けられている場合、`ram:RequestedResourceType` 条件キーはリクエストコンテキストに存在しません。同様に、リソースが AWS RAM リソース共有に関連付けられている場合、`ram:Principal` 条件キーはリクエストコンテキストに存在しません。したがって、プリンシパルを AWS RAM リソース共有に関連付ける`CreateResourceShare`ときに `AssociateResourceShare`と を許可するには、 [`Null`条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null)を使用できます。
たとえば、次のポリシーでは、プリンシパルを Amazon Route 53 Resolver ルールのみ共有できるように制限し、プリンシパルをその共有に関連付けることができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowOnlySpecificResourceType",
"Effect": "Allow",
"Action": ["ram:CreateResourceShare", "ram:AssociateResourceShare"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ram:RequestedResourceType": "route53resolver:ResolverRule"
}
}
},
{
"Sid": "AllowAssociatingPrincipals",
"Effect": "Allow",
"Action": ["ram:CreateResourceShare", "ram:AssociateResourceShare"],
"Resource": "*",
"Condition": {
"Null": {
"ram:Principal": "false"
}
}
}
]
}
```
------
## 例 3: 外部との共有を制限する AWS アカウント
IAM ポリシーを使用して、プリンシパル AWS アカウント が AWS 組織外の とリソースを共有できないようにすることができます。
たとえば、次の IAM ポリシーは、プリンシパルがリソース共有 AWS アカウント に外部を追加できないようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ram:CreateResourceShare",
"Resource": "*",
"Condition": {
"Bool": {
"ram:RequestedAllowsExternalPrincipals": "false"
}
}
}]
}
```
------
# AWS Organizations および のサービスコントロールポリシーの例 AWS RAM
AWS RAM は、サービスコントロールポリシー (SCPsをサポートしています。SCP は、組織内のアクセス許可を管理する目的で組織内の要素にアタッチされるポリシーです。SCP は、 AWS アカウント [SCP をアタッチする要素の下にあるすべての ](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_inheritance_auth.html)に適用されます。SCP では、組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御できます。これらは、組織のアクセスコントロールガイドラインを確実に AWS アカウント 順守するのに役立ちます。詳細については、*AWS Organizations ユーザーガイド*の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_type-auth.html)」を参照してください。
## 前提条件
SCP を使用するには、まず以下のことをする必要があります。
+ 組織内のすべての機能の有効化。詳細については、[AWS Organizations ユーザーガイド](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)の「*組織内のすべての機能の有効化*」を参照してください。
+ SCP を有効にして組織内で使用できるようにするには 詳細については、*AWS Organizations ユーザーガイド*の「[ポリシータイプの有効化と無効化](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_enable-disable.html)」を参照してください。
+ 必要な SCP を作成します。SCP の作成の詳細については、*AWS Organizations ユーザーガイド*の「[SCP の作成および更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp-create.html)」を参照してください。
## サービスコントロールポリシーの例
**Contents**
+ [例 1: 外部共有を禁止する](#example-one)
+ [例 2: 組織外の外部アカウントからのリソース共有への招待をユーザーが受け付けないようにする](#example-two)
+ [例 3: 特定のアカウントに特定のリソースタイプの共有を許可する](#example-three)
+ [例 4: 組織全体または組織単位との共有を禁止する](#example-four)
+ [例 5: 特定のプリンシパルのみとの共有を許可する](#example-five)
+ [例 6: RetainSharingOnAccountLeaveOrganization を有効にしてリソース共有を防止する](#example-six)
以下の例では、組織内のリソース共有のさまざまな側面を制御する方法を説明します。
### 例 1: 外部共有を禁止する
以下の SCP は、共有ユーザーの組織外にいるプリンシパルとの共有を許可するリソース共有をユーザーが作成できないようにするものです。
AWS RAM はAPIs を個別に承認します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:UpdateResourceShare"
],
"Resource": "*",
"Condition": {
"Bool": {
"ram:RequestedAllowsExternalPrincipals": "true"
}
}
}
]
}
```
------
### 例 2: 組織外の外部アカウントからのリソース共有への招待をユーザーが受け付けないようにする
次の SCP は、影響を受けるアカウントのプリンシパルがリソース共有を使用する招待を受け入れることをブロックします。共有アカウントと同じ組織内の他のアカウントと共有されているリソース共有では招待状は生成されないため、この SCP の影響を受けません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ram:AcceptResourceShareInvitation",
"Resource": "*"
}
]
}
```
------
### 例 3: 特定のアカウントに特定のリソースタイプの共有を許可する
以下の SCP では、アカウント `111111111111` と `222222222222` *のみ*が、Amazon EC2 プレフィックスリストを共有する新しいリソース共有を作成し、プレフィックスリストを既存のリソース共有に関連付けることができます。
AWS RAM はAPIs を個別に承認します。
演算子 `StringEqualsIfExists` は、リクエストにリソースタイプパラメータが含まれていない場合、またはそのパラメータが含まれている場合はその値が指定したリソースタイプと完全に一致する場合に、リクエストを許可します。プリンシパルを含める場合は、`...IfExists` が必要です。
`...IfExists` 演算子を使用するタイミングと理由の詳細については、「**IAM ユーザーズガイド」の「[...IfExists 条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IfExists)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:AssociateResourceShare",
"ram:CreateResourceShare"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": [
"111111111111",
"222222222222"
]
},
"StringEqualsIfExists": {
"ram:RequestedResourceType": "ec2:PrefixList"
}
}
}
]
}
```
------
### 例 4: 組織全体または組織単位との共有を禁止する
次の SCP は、組織全体または任意の組織単位とリソースを共有するリソース共有をユーザーが作成できないようにします。ユーザーは、組織 AWS アカウント 内の個人、または IAM ロールまたはユーザーと共有*できます*。
AWS RAM はAPIs を個別に承認します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:AssociateResourceShare"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ram:Principal": [
"arn:aws:organizations::*:organization/*",
"arn:aws:organizations::*:ou/*"
]
}
}
}
]
}
```
------
### 例 5: 特定のプリンシパルのみとの共有を許可する
以下の SCP の例では、ユーザーは組織 `o-12345abcdef,`、組織単位 `ou-98765fedcba`、および AWS アカウント `111111111111` *のみ*とリソースを共有できます。
`StringNotEqualsIfExists` のような否定条件演算子を持つ `"Effect": "Deny"` 要素を使用している場合は、条件キーがなくてもリクエストが拒否されます。`Null` 条件演算子を使用して、認可時に条件キーが存在していないかどうかを確認します。
AWS RAM はAPIs を個別に承認します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:AssociateResourceShare",
"ram:CreateResourceShare"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"ram:Principal": [
"arn:aws:organizations::123456789012:organization/o-12345abcdef",
"arn:aws:organizations::123456789012:ou/o-12345abcdef/ou-98765fedcba",
"111111111111"
]
},
"Null": {
"ram:Principal": "false"
}
}
}
]
}
```
------
### 例 6: RetainSharingOnAccountLeaveOrganization を有効にしてリソース共有を防止する
次の SCP は、`ram:RetainSharingOnAccountLeaveOrganization`条件キーが に設定されている場合に、ユーザーがリソース共有を作成または変更できないようにします`true`。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:AssociateResourceShare",
"ram:DisassociateResourceShare"
],
"Resource": "*",
"Condition": {
"Bool": {
"ram:RetainSharingOnAccountLeaveOrganization": "true"
}
}
}
]
}
```
# とのリソース共有の無効化 AWS Organizations
以前に との共有を有効に AWS Organizations していて、組織全体または組織単位 (OUs) とリソースを共有する必要がなくなった場合は、共有を無効にすることができます。との共有を無効にすると AWS Organizations、作成したリソース共有からすべての組織または OUs が削除され、共有リソースにアクセスできなくなります。外部アカウント (招待によってリソース共有に追加されたアカウント) は影響を受けず、引き続きリソース共有に関連付けられます。
**との共有を無効にするには AWS Organizations**
1. AWS Organizations [disable-aws-service-access](https://docs.aws.amazon.com/cli/latest/reference/organizations/disable-aws-service-access.html) AWS CLI コマンド AWS Organizations を使用して、 への信頼されたアクセスを無効にします。
```
$ aws organizations disable-aws-service-access --service-principal ram.amazonaws.com
```
**重要**
への信頼されたアクセスを無効にすると AWS Organizations、組織内のプリンシパルはすべてのリソース共有から削除され、それらの共有リソースにアクセスできなくなります。
1. IAM コンソール、 AWS CLI、または IAM API オペレーションを使用して、**AWSServiceRoleForResourceAccessManager** サービスにリンクされたロールを削除します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
# AWS RAM でのログ記録とモニタリング
モニタリングは、AWS RAM と AWSソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。マルチポイント障害が発生した場合は、その障害をより簡単にデバッグできるように、AWS ソリューションのすべての部分からモニタリングデータを収集する必要があります。AWS には、AWS RAM リソースをモニタリングし、潜在的なインシデントに対応するための複数のツールが用意されています。
**Amazon EventBridge**
AWS リソースの変更を示すシステムイベントのほぼリアルタイムのストリームを提供します。EventBridge で自動イベント駆動型コンピューティングを有効にすると、特定のイベントを監視するルールを記述し、これらのイベントが発生したときに他の AWS のサービスで自動アクションをトリガーできます。詳細については、「[EventBridge AWS RAM を使用したモニタリング](using-eventbridge.md)」を参照してください。
**AWS CloudTrail**
AWS アカウント により、またはそのアカウントに代わって行われた API コールや関連イベントを取得し、指定した Amazon S3 バケットにログファイルを配信します。AWS を呼び出したユーザーとアカウント、呼び出し元の IP アドレス、および呼び出し日時を特定できます。詳細については、「[を使用した AWS RAM API コールのログ記録 AWS CloudTrail](cloudtrail-logging.md)」を参照してください。
# EventBridge AWS RAM を使用したモニタリング
Amazon EventBridge を使用して、 AWS RAM内にある特定のイベントに関する自動通知を設定できます。からのイベント AWS RAM は、ほぼリアルタイムで EventBridge に配信されます。イベントをモニタリングし、リソース共有の変更を示すイベントに応答してターゲットを呼び出すように EventBridge を設定できます。リソース共有への変更は、リソース共有の所有者およびリソース共有へのアクセスを許可されたプリンシパルの両方についてイベントをトリガーします。
イベントパターンを作成するとき、ソースは `aws.ram` です。
**注記**
これらのイベントに依存するコードの記述には注意が必要です。これらのイベントは保証されていませんが、ベストエフォートベースで送信されます。がイベントを出力 AWS RAM しようとしたときにエラーが発生した場合、サービスはさらに数回試行します。ただし、タイムアウトになり、その特定のイベントが失われる可能性があります。
詳細については、Amazon EventBridge ユーザーガイドを参照してください。
## 例: リソース共有障害時のアラート
Amazon EC2 のキャパシティ予約を組織の他のアカウントと共有するシナリオを考えてみましょう。これはコストを削減する良い方法です。
ただし、[キャパシティ予約を共有するための前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html#sharing-cr-prereq)をすべて満たしていない場合、リソース共有に関連する非同期タスクの実行が失敗する可能性があります。共有操作が失敗し、他のアカウントのユーザーがそれらのキャパシティ予約のいずれかでインスタンスを起動しようとすると、Amazon EC2 はキャパシティ予約を受け付けられない状態であるかのように動作し、代わりにオンデマンドインスタンスとしてインスタンスを起動します。その結果、想定以上のコストが発生する可能性があります。
リソース共有の失敗をモニタリングするには、 AWS RAM リソース共有が失敗したときに警告する Amazon EventBridge ルールを設定します。次のチュートリアルでは、Amazon Simple Notification Service (SNS) トピックを使用して、EventBridge がリソース共有障害を検出するたびに、トピックサブスクライバー全員に通知を送信します。Amazon SNS の詳細については、[Amazon Simple Notification Service デベロッパーガイド](https://docs.aws.amazon.com/sns/latest/dg/) を参照してください。
**リソース共有が失敗したときに通知するルールを作成するには**
1. [Amazon EventBridge コンソール](https://console.aws.amazon.com/events)を開きます。
1. ナビゲーションペインで **[ルール]** を選択し、**[ルール]** リストで **[ルールの作成]** を選択します。
1. 名前を入力し、必要に応じてルールの説明を入力して **[次へ]** を選択します。
1. **[イベントパターン]** ボックスまでスクロールして、**[カスタムパターン]** を選択します。
1. 以下のイベントパターンをコピーして貼り付けます。
```
{
"source": ["aws.ram"],
"detail-type": ["Resource Sharing State Change"],
"detail": {
"event": ["Resource Share Association"],
"status": ["failed"]
}
}
```
1. [**次へ**] を選択します。
1. **[ターゲット 1]** の **[ターゲットタイプ]** で、**AWS のサービス** を選択します。
1. **[ターゲットの選択]**で、**[SNS トピック]** を選択します。
1. **[トピック]** で、通知を送信する SNS トピックを選択します。このトピックはすでに作成されている必要があります。
1. **[次へ]** を選択し、もう一度 **[次へ]** を選択して設定を確認します。
1. オプションに問題がなければ、**[ルールの作成]** を選択します。
1. **[ルール]** ページに戻り、新しいルールが **[有効]** になっていることを確認します。必要な場合、ルール名の横にあるラジオボタンを選択し、**[有効]** を選択します。
そのルールが有効になっている限り、失敗した AWS RAM リソース共有は、公開したトピックの受信者に SNS アラートを生成します。
共有先のアカウントの [Amazon EC2 コンソールで共有されたキャパシティ予約を表示して](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html#identifying-shared-cr)、キャパシティ予約がアクセス可能であることを確認することもできます。
# を使用した AWS RAM API コールのログ記録 AWS CloudTrail
AWS RAM は、ユーザー AWS CloudTrail、ロール、または のサービスによって実行されたアクションを記録する AWS サービスである と統合されています AWS RAM。CloudTrail は、 AWS RAM のすべての API コールをイベントとしてキャプチャします。キャプチャされた呼び出しには、 AWS RAM コンソールからの呼び出しと AWS RAM API オペレーションへのコード呼び出しが含まれます。追跡を作成する場合は、 AWS RAMのイベントなど、指定する Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。証跡を設定しない場合でも、CloudTrail コンソールの **[イベント履歴]** で最新のイベントを表示できます。CloudTrail で収集された情報を使用して、リクエストの実行先 AWS RAM、リクエスト元の IP アドレス、リクエスタ、リクエストの実行日時などの詳細を確認します。
CloudTrail の詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。
## AWS RAM CloudTrail の情報
CloudTrail は、アカウントの作成 AWS アカウント 時に で有効になります。アクティビティが発生すると AWS RAM、そのアクティビティはイベント**履歴**の他の AWS サービスイベントとともに CloudTrail イベントに記録されます。で最近のイベントを表示、検索、ダウンロードできます AWS アカウント。詳細については、[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)を参照してください。
AWS RAMのイベントなど、 AWS アカウントのイベントの継続的な記録に対して、追跡を作成します。*証跡*により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。デフォルトでは、コンソールで証跡を作成すると、証跡はすべての AWS リージョンに適用されます。証跡は、 AWS パーティションのすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集されたイベントデータをさらに分析して処理するように他の AWS サービスを設定できます。詳細については次を参照してください:
+ [の証跡の作成 AWS アカウント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [AWS のサービス CloudTrail ログとの統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [CloudTrail 用 Amazon SNS 通知の構成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [CloudTrail ログファイルを複数のリージョンから受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)、[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
すべての AWS RAM アクションは CloudTrail によってログに記録され、 [AWS RAM API リファレンス](https://docs.aws.amazon.com/ram/latest/APIReference/)に記載されています。たとえば、`CreateResourceShare`、`AssociateResourceShare`、`EnableSharingWithAwsOrganization` の各アクションを呼び出すと、CloudTrail ログファイルにエントリが生成されます。
各イベントまたはログエントリには、リクエストを行ったユーザーに関する情報が含まれます。
+ AWS アカウント ルート認証情報
+ AWS Identity and Access Management (IAM) ロールまたはフェデレーティッドユーザーからの一時的なセキュリティ認証情報。
+ IAM ユーザーからの長期的なセキュリティ認証情報
+ 別の AWS サービス。
詳細については、「[CloudTrail userIdentity エレメント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。
## AWS RAM ログファイルエントリについて
「トレイル」は、指定した Amazon S3 バケットにイベントをログファイルとして配信するように設定できます。CloudTrail のログファイルは、単一か複数のログエントリを含みます。イベントは、任意の出典からの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストパラメータなどに関する情報が含まれます。CloudTrail ログファイルは、パブリック API 呼び出しの順序付けられたスタックトレースではないため、特定の順序では表示されません。
次の例は、`CreateResourceShare` アクションの CloudTrail ログエントリを示しています。
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "NOPIOSFODNN7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/admin",
"accountId": "111122223333",
"accessKeyId": "BCDIOSFODNN7EXAMPLE",
"userName": "admin"
},
"eventTime": "2018-11-03T04:23:19Z",
"eventSource": "ram.amazonaws.com",
"eventName": "CreateResourceShare",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.1.0",
"userAgent": "aws-cli/1.16.2 Python/2.7.10 Darwin/16.7.0 botocore/1.11.2",
"requestParameters": {
"name": "foo"
},
"responseElements": {
"resourceShare": {
"allowExternalPrincipals": true,
"name": "foo",
"owningAccountId": "111122223333",
"resourceShareArn": "arn:aws:ram:us-east-1:111122223333:resource-share/EXAMPLE0-1234-abcd-1212-987656789098",
"status": "ACTIVE"
}
},
"requestID": "EXAMPLE0-abcd-1234-mnop-987654567876",
"eventID": "EXAMPLE0-1234-abcd-hijk-543234565434",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
# のコンプライアンス検証 AWS Resource Access Manager
AWS のサービス が特定のコンプライアンスプログラムの範囲内にあるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによるスコープ](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照して、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# の耐障害性 AWS Resource Access Manager
AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。 は、低レイテンシー、高スループット、高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョン を提供します。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。
AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# のインフラストラクチャセキュリティ AWS Resource Access Manager
マネージドサービスである AWS Resource Access Manager は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して環境を AWS 設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が発行した API コールを使用して、ネットワーク AWS RAM 経由で にアクセスします。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。
# インターフェイスエンドポイント (AWS PrivateLink) AWS Resource Access Manager を使用した へのアクセス
を使用して AWS PrivateLink 、VPC と の間にプライベート接続を作成できます AWS Resource Access Manager。インターネットゲートウェイ、NAT デバイス、VPN 接続、または Direct Connect 接続を使用せずに、VPC 内にある AWS RAM かのように にアクセスできます。VPC 内のインスタンスは AWS RAMにアクセスするためにパブリック IP アドレスを必要としません。
このプライベート接続を確立するには、 AWS PrivateLinkを利用した*インターフェイスエンドポイント*を作成します。インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。これらは、 AWS RAM宛てのトラフィックのエントリポイントとして機能するリクエスタ管理型ネットワークインターフェイスです。
詳細については「*AWS PrivateLink ガイド*」の「[Access AWS のサービス through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。
## に関する考慮事項 AWS RAM
のインターフェイスエンドポイントを設定する前に AWS RAM、「 *AWS PrivateLink ガイド*」の[「考慮事項](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)」を参照してください。
AWS RAM は、インターフェイスエンドポイントを介したすべての API アクションの呼び出しをサポートしています。
VPC エンドポイントポリシーがサポートされています AWS RAM。デフォルトでは、インターフェイスエンドポイント経由での AWS RAM への完全なアクセスが許可されます。
## のインターフェイスエンドポイントを作成する AWS RAM
Amazon VPC コンソールまたは AWS Command Line Interface () AWS RAM を使用して、 のインターフェイスエンドポイントを作成できますAWS CLI。詳細については、「*AWS PrivateLink ガイド*」の「[インターフェイスエンドポイントを作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。
次のサービス名 AWS RAM を使用して のインターフェイスエンドポイントを作成します。
```
com.amazonaws.region.ram
```
インターフェイスエンドポイントのプライベート DNS を有効にすると、リージョンのデフォルト DNS 名を使用して、 AWS RAM への API リクエストを実行できます。例えば、`ram.us-east-1.amazonaws.com`。
## インターフェイスエンドポイントのエンドポイントポリシーを作成する
エンドポイントポリシーは、インターフェイスエンドポイントにアタッチできる IAM リソースです。デフォルトのエンドポイントポリシーでは、インターフェイスエンドポイント AWS RAM を介して へのフルアクセスを許可します。VPC AWS RAM から に許可されるアクセスを制御するには、カスタムエンドポイントポリシーをインターフェイスエンドポイントにアタッチします。
エンドポイントポリシーは以下の情報を指定します。
+ アクションを実行できるプリンシパル (AWS アカウント、IAM ユーザー、IAM ロール)。
+ 実行可能なアクション。
+ このアクションを実行できるリソース。
詳細については、*AWS PrivateLink ガイド*の[Control access to services using endpoint policies (エンドポイントポリシーを使用してサービスへのアクセスをコントロールする)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)を参照してください。
**例: AWS RAM アクションの VPC エンドポイントポリシー**
以下は、カスタムエンドポイントポリシーの例です。このポリシーをインターフェイスエンドポイントにアタッチすると、すべてのリソースのすべてのプリンシパルに対して、リストされた AWS RAM アクションへのアクセスが許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"ram:CreateResourceShare"
],
"Resource": "*"
}
]
}
```
------