翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 新しいクロスアカウントサブスクリプションの設定
次のセクションの手順に従って、新しいクロスアカウントログサブスクリプションを設定します。
**Topics**
+ [ステップ 1: 送信先を作成する](CreateDestination-Account.md)
+ [ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole-Account.md)
+ [ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)
+ [ログイベントの送信を検証](ValidateLogEventFlow-Account.md)
+ [ランタイムの送信先のメンバーシップを変更](ModifyDestinationMembership-Account.md)
# ステップ 1: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
この例では、ログデータ受信者アカウントの AWS アカウント ID は 999999999999 で、ログデータ送信者 AWS アカウント ID は 111111111111 です。
この例では、RecipientStream という Amazon Kinesis Data Streams ストリームと、CloudWatch Logs によるデータの書き込みを可能にするロールを使用して送信先を作成します。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. 受信者アカウントで、Amazon Kinesis Data Streams で送信先ストリームを作成します。コマンドプロンプトで、次のように入力します。
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. ストリームがアクティブになるまで待ちます。**aws kinesis describe-stream** コマンドを使用して、**StreamDescription.StreamStatus** プロパティをチェックできます。さらに、**StreamDescription.StreamARN** の値は、後で CloudWatch Logs に渡すので書き留めておいてください。
```
aws kinesis describe-stream --stream-name "RecipientStream"
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RecipientStream",
"StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "34028236692093846346337460743176EXAMPLE",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
}
}
]
}
}
```
ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. ストリームにデータを置くアクセス権限を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Action": "sts:AssumeRole"
}
}
```
1. **aws iam create-role** コマンドを使用して、信頼ポリシーファイルを指定する IAM ロールを作成します。返された Role.Arn 値を書き留めておきます。これも後で CloudWatch Logs に渡されるからです。
```
aws iam create-role \
--role-name CWLtoKinesisRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Principal": {
"Service": "logs.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **aws iam put-role-policy** コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。ペイロードで返された **DestinationArn** を書き留めておいてください。
```
aws logs put-destination \
--destination-name "testDestination" \
--target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
--role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
{
"DestinationName" : "testDestination",
"RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
}
```
1. ステップ 7a が完了したら、ログデータの受取人アカウントで、アクセスポリシーを送信先に関連付けます。このポリシーでは、送信者アカウントが送信先にアクセスするためのアクセス許可が付与され、**logs:PutSubscriptionFilter** アクションが指定されている必要があります。
このポリシーは、ログを送信する AWS アカウントにアクセス許可を付与します。ポリシーの中で対象のアカウントを 1 つだけ指定してもよいですが、送信者アカウントが組織のメンバーのものである場合は組織 ID を指定することもできます。このように、ポリシーを 1 つ作成するだけで、1 つの組織内の複数のアカウントが送信先アカウントにログを送信できるように設定できます。
テキストエディタを使用して `~/AccessPolicy.json` という名前のファイルを作成し、以下のいずれかのポリシーステートメントを使用します。
この最初の例のポリシーでは、組織内で `o-1234567890` という ID を持つすべてのアカウントが、受信者アカウントにログを送信することを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
次の例では、ログデータの送信者アカウント (111111111111) がログデータの受信者アカウントにログを送信できるようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "111111111111"
},
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. 前のステップで作成したポリシーを送信先に添付します。
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
このアクセスポリシーにより、ID 111111111111 の AWS アカウントのユーザーは、ARN arn:aws:logs:*region*:999999999999:destination:testDestination の送信先に対して **PutSubscriptionFilter** を呼び出すことができます。他のユーザーがこの送信先に対して PutSubscriptionFilter を呼び出そうとしても、それは却下されます。
アクセスポリシーに照らし合わせてユーザーの権限を検証するには、「*IAM ユーザーガイド*」の「[Using Policy Validator](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html)」(Policy Validator の使用) を参照してください。
完了したら、クロスアカウントのアクセス許可 AWS Organizations に を使用している場合は、「」の手順に従います[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole-Account.md)。組織を使用せずに他のアカウントに直接アクセス許可を付与する場合は、そのステップを飛ばして「[ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)」に進みます。
# ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)
前のセクションで アカウント `111111111111` に直接アクセス許可を付与するのではなく、アカウント `111111111111` が属する組織にアクセス許可を付与するアクセスポリシーを使用することにより送信先を作成した場合は、このセクションのステップを実行します。それ以外の場合は、「[ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)」に進みます。
このセクションのステップにより、CloudWatch が想定する IAM ロールを作成し、送信者アカウントが受信者の送信先に対してサブスクリプションフィルターを作成する権限を持っているかどうかを検証できます。
このセクションの手順は、送信者アカウントで実行してください。ロールは送信者アカウントに存在する必要があり、このロールの ARN はサブスクリプションフィルターで指定します。この例では、送信者アカウントは `111111111111` です。
**を使用してクロスアカウントログサブスクリプションに必要な IAM ロールを作成するには AWS Organizations**
1. 以下の信頼ポリシーを作成し、`/TrustPolicyForCWLSubscriptionFilter.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. アクセス許可ポリシーを作成して、CloudWatch Logs がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForCWLSubscriptionFilter.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス許可ポリシーを、ステップ 2 で作成したロールに関連付けます。
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
終了したら、「[ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)」に進みます。
# ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する
送信先を作成したら、ログデータの受信者アカウントは、送信先の ARN (arn:aws:logs:us-east-1:999999999999:destination:testDestination) を他の AWS アカウントと共有できるようになります。これにより、これらのアカウントは同じ送信先にログイベントを送信できます。この後、これらの他の送信アカウントのユーザーは、この送信先に対するサブスクリプションフィルタをそれぞれのロググループに作成します。サブスクリプションフィルタは、特定のロググループから特定の送信先へのリアルタイムログデータの送信をすぐに開始します。
**注記**
サブスクリプションフィルターのためのアクセス許可を組織全体に付与する際は、[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole-Account.md) で作成した IAM ロールの ARN を使用する必要があります。
次の例では、アカウントレベルのサブスクリプションフィルターポリシーが送信アカウントで作成されます。フィルターは送信者アカウント `111111111111` に関連付けられ、フィルターと選択基準に一致するすべてのログイベントが以前に作成した送信先に配信されます。この送信先は、「RecipientStream」という ストリームをカプセル化します。
`selection-criteria` フィールドはオプションですが、サブスクリプションフィルターから無限のログ再帰を引き起こす可能性のあるロググループを除外するための重要なフィールドです。この問題および除外するロググループを判断する方法については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。現在、NOT IN は `selection-criteria` でサポートされている唯一の演算子です。
```
aws logs put-account-policy \
--policy-name "CrossAccountStreamsExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
送信者アカウントのロググループと送信先は同じ AWS リージョンに存在している必要があります。ただし、送信先は、別のリージョンにある Amazon Kinesis Data Streams ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信を検証
アカウントレベルのサブスクリプションフィルターポリシーを作成したら、CloudWatch Logs が、フィルタパターンおよび選択基準と一致するすべての受信ログイベントを、送信先ストリーム内でカプセル化されている「**RecipientStream**」という名前のストリームに転送します。送信先所有者は、**aws kinesis get-shard-iterator** コマンドを使用して Amazon Kinesis Data Streams シャードを取得し、**aws kinesis get-records** コマンドを使用して Amazon Kinesis Data Streams レコードを取得することで、これが起こっていることを確認できます。
```
aws kinesis get-shard-iterator \
--stream-name RecipientStream \
--shard-id shardId-000000000000 \
--shard-iterator-type TRIM_HORIZON
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}
aws kinesis get-records \
--limit 10 \
--shard-iterator
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```
**注記**
Amazon Kinesis Data Streams がデータを返す前に、`get-records`コマンドを数回再実行する必要がある場合があります。
Amazon Kinesis Data Streams レコードの配列を含むレスポンスが表示されます。Amazon Kinesis Data Streams レコードのデータ属性は gzip 形式で圧縮され、base64 でエンコードされます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"RecipientStream"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
データ構造の主な要素は次のとおりです。
**messageType**
データメッセージは、"DATA\$1MESSAGE" 型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。"id" プロパティは、各ログイベントの一意識別子です。
**policyLevel**
ポリシーが適用されたレベル。「ACCOUNT\$1LEVEL\$1POLICY」は、アカウントレベルのサブスクリプションフィルターポリシーの `policyLevel` です。
# ランタイムの送信先のメンバーシップを変更
所有する送信先のユーザーのメンバーシップを追加または削除する必要がある場合があります。新しいアクセスポリシーを使用して、送信先で `put-destination-policy` コマンドを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **222222222222** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testDestination"
{
"Destinations": [
{
"DestinationName": "testDestination",
"RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
"AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **222222222222** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "222222222222"
},
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. **PutDestinationPolicy** を呼び出して、**NewAccessPolicy.json** ファイルで定義されているポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **222222222222** の所有者がサブスクリプションフィルターを作成すると、すぐに **222222222222** からのログイベントが送信先に送信されるようになります。