翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# クロスアカウント、クロスリージョンのサブスクリプション
別の AWS アカウントの所有者と協力して、Amazon Kinesis または Amazon Data Firehose ストリーム (これはクロスアカウントデータ共有と呼ばれます) などの AWS リソースでログイベントを受信できます。たとえば、このログイベントデータは、一元化された Amazon Kinesis Data Streams または Firehose ストリームから読み取り、カスタム処理と分析を実行できます。カスタム処理は、多数のアカウントが協力しデータを分析する場合に特に便利です。
たとえば、ある会社の情報セキュリティグループがリアルタイムで侵入または異常な挙動を検出するためにデータを分析するとします。この場合、会社の全部署のアカウントのフェデレーションされた本稼働ログを中央処理のために収集することによって、これらのアカウントの監査を行うことができます。これらのアカウント全体のイベントデータのリアルタイムストリームをアセンブルして情報セキュリティグループに配信できます。情報セキュリティグループは、Amazon Kinesis Data Streams を使用して既存のセキュリティ分析システムにデータをアタッチできます。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。次のセクションの例では、リージョン固有のリソースはすべて米国東部 (バージニア北部) で作成されます。
メンバーアカウントを設定 AWS Organizations して操作している場合は、ログの一元化を使用して、ソースアカウントから中央モニタリングアカウントにログデータを収集できます。
一元化されたロググループを使用する場合は、サブスクリプションフィルターを作成する際にこれらのシステムフィールドのディメンションを使用できます。
+ `@aws.account` - このディメンションは、ログイベントの発生元の AWS アカウント ID を表します。
+ `@aws.region` - このディメンションは、ログイベントが生成された AWS リージョンを表します。
これらのディメンションはログデータのソースを特定するのに役立ちます。これにより、一元化されたログから派生したメトリクスのフィルタリングと分析をさらに細かく行えるようになります。
**Topics**
+ [Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンログデータ共有](CrossAccountSubscriptions-Kinesis.md)
+ [Firehose を使用したクロスアカウント、クロスリージョンのログデータ共有](CrossAccountSubscriptions-Firehose.md)
+ [Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンアカウントレベルのサブスクリプション](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Firehose を使用したクロスアカウント、クロスリージョン、アカウントレベルのサブスクリプション](CrossAccountSubscriptions-Firehose-Account.md)
# Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンログデータ共有
クロスアカウントサブスクリプションを作成するときに、単一のアカウントまたは組織を送信者として指定できます。組織を指定した場合、この手順により組織内のすべてのアカウントがレシーバーアカウントにログを送信できるようになります。
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ **[Log data sender] **(ログデータの送信者) — 受信者から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
1 つの組織で複数のアカウントを 1 つの受信者アカウントにログを送信する場合は、組織内のすべてのアカウントに対して受信者アカウントにログを送信するアクセス許可を付与するポリシーを作成することができます。引き続き、送信者アカウントごとに個別のサブスクリプションフィルターを設定する必要があります。
+ **ログデータ受信者** - Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 999999999999 で表示されます。
クロスアカウントのユーザーからのログイベントの受け取りを開始するには、ログデータの受取人がまず CloudWatch Logs 送信先を作成する必要があります。各送信先は以下のキー要素で構成されています。
**送信先名**
作成する送信先の名前。
**ターゲット ARN**
サブスクリプションフィードの送信先として使用するリソースの Amazon AWS リソースネーム (ARN)。
**ロールの ARN**
選択したストリームにデータを配置するために必要なアクセス許可を CloudWatch Logs に付与する AWS Identity and Access Management (IAM) ロール。
**アクセスポリシー**
送信先に書き込むことが許可されている一連のユーザーを管理する IAM ポリシードキュメント (IAM ポリシー構文を使用して記述された JSON 形式のドキュメント）。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。次のセクションの例では、リージョン固有のリソースはすべて米国東部 (バージニア北部) で作成されます。
**Topics**
+ [新しいクロスアカウントサブスクリプションの設定](Cross-Account-Log_Subscription-New.md)
+ [既存のクロスアカウントサブスクリプションの更新](Cross-Account-Log_Subscription-Update.md)
# 新しいクロスアカウントサブスクリプションの設定
次のセクションの手順に従って、新しいクロスアカウントログサブスクリプションを設定します。
**Topics**
+ [ステップ 1: 送信先を作成する](CreateDestination.md)
+ [ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole.md)
+ [ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions.md)
+ [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)
+ [ログイベントの送信を検証](ValidateLogEventFlow.md)
+ [ランタイムの送信先のメンバーシップを変更](ModifyDestinationMembership.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": "2015-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",
"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",
"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.md)。組織を使用せずに他のアカウントに直接アクセス許可を付与する場合は、そのステップを飛ばして「[ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)」に進みます。
# ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)
前のセクションで アカウント `111111111111` に直接アクセス許可を付与するのではなく、アカウント `111111111111` が属する組織にアクセス許可を付与するアクセスポリシーを使用することにより送信先を作成した場合は、このセクションのステップを実行します。それ以外の場合は、「[ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.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
```
終了したら、「[ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)」に進みます。
# ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する
AWS クロスアカウントポリシーの評価ロジックに従って、クロスアカウントリソース (サブスクリプションフィルターの送信先として使用される Kinesis または Firehose ストリームなど) にアクセスするには、クロスアカウントの送信先リソースへの明示的なアクセスを提供する ID ベースのポリシーを送信アカウントに含める必要があります。ポリシーの評価論理の詳細については、「[クロスアカウントポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」を参照してください。
ID ベースのポリシーは、サブスクリプションフィルターの作成に使用している IAM ロールまたは IAM ユーザーにアタッチできます。送信アカウントにこのポリシーが存在する必要があります。管理者ロールを使用してサブスクリプションフィルタを作成している場合は、このステップをスキップして [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md) に進んでください。
**クロスアカウントに必要な IAM アクセス許可を追加または検証するには**
1. 次のコマンドを入力して、 AWS ログコマンドの実行に使用されている IAM ロールまたは IAM ユーザーを確認します。
```
aws sts get-caller-identity
```
このコマンドにより、以下のような出力が返されます。
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
*RoleName* または *UserName* で表される値を書き留めておいてください。
1. 送信アカウント AWS マネジメントコンソール で にサインインし、ステップ 1 で入力したコマンドの出力で返された IAM ロールまたは IAM ユーザーを使用して、アタッチされたポリシーを検索します。
1. このロールまたはユーザーにアタッチされたポリシーが、クロスアカウントの宛先リソースで `logs:PutSubscriptionFilter` を呼び出すための明示的なアクセス許可が付与されていることを確認します。
次のポリシーは、1 つの AWS アカウント、アカウント でのみ、任意の送信先リソースにサブスクリプションフィルターを作成するアクセス許可を提供します`999999999999`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAccountResources",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
次のポリシーは、単一の AWS アカウント、アカウント `sampleDestination`で という名前の特定の送信先リソースに対してのみサブスクリプションフィルターを作成するアクセス許可を提供します`123456789012`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersonAccountResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:sampleDestination"
]
}
]
}
```
------
# ステップ 4: サブスクリプションフィルターを作成する
送信先を作成したら、ログデータの受信者アカウントは、送信先の ARN (arn:aws:logs:us-east-1:999999999999:destination:testDestination) を他の AWS アカウントと共有できるようになります。これにより、これらのアカウントは同じ送信先にログイベントを送信できます。この後、これらの他の送信アカウントのユーザーは、この送信先に対するサブスクリプションフィルタをそれぞれのロググループに作成します。サブスクリプションフィルタは、特定のロググループから特定の送信先へのリアルタイムログデータの送信をすぐに開始します。
**注記**
サブスクリプションフィルターのためのアクセス許可を組織全体に付与する際は、[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole.md) で作成した IAM ロールの ARN を使用する必要があります。
次の例では、サブスクリプションフィルターが送信アカウントに作成されます。フィルターはイベントを含む AWS CloudTrail ロググループに関連付けられ、「ルート AWS 」認証情報によって行われたすべてのログアクティビティが、以前に作成した送信先に配信されます。この送信先は、「RecipientStream」という ストリームをカプセル化します。
以降のセクションの残りのステップは、「AWS CloudTrail ユーザーガイド**」の「[CloudWatch Logs への CloudTrail イベントの送信](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html)」の指示に従って、CloudTrail イベントを含むロググループが作成済みであることを前提としています。そのステップでは、ロググループに `CloudTrail/logs` という名前を付けることになっています。
次のコマンドを入力するときは、必ず IAM ユーザーとしてサインインしているか、[ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions.md) にポリシーを追加した IAM ロールを使用してサインインしていることを確認してください。
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail/logs" \
--filter-name "RecipientStream" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
ロググループと送信先は同じ 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\"}"
}
]
}
```
このデータ構造のキー要素は以下のとおりです。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**messageType**
データメッセージは、「DATA\$1MESSAGE」型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。ID プロパティは、各ログイベントの一意の識別子です。
# ランタイムの送信先のメンバーシップを変更
所有する送信先のユーザーのメンバーシップを追加または削除する必要がある場合があります。新しいアクセスポリシーを使用して、送信先で `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",
"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** からのログイベントが送信先に送信されるようになります。
# 既存のクロスアカウントサブスクリプションの更新
送信先アカウントが特定の送信者アカウントにのみアクセス許可を付与しているクロスアカウントのログサブスクリプションがあり、このサブスクリプションを更新して送信先アカウントが組織内のすべてのアカウントにアクセスできるようにする場合は、このセクションのステップを実施します。
**Topics**
+ [ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter.md)
+ [ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy.md)
# ステップ 1: サブスクリプションフィルターを更新する
**注記**
この手順は、[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md) に記載されているサービスによって作成されたログのクロスアカウントのサブスクリプションにのみ必要です。これらのロググループのいずれかで作成されたログを操作していない場合は、[ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy.md) にスキップできます。
場合によっては、送信先アカウントにログを送信する、すべての送信者アカウントのサブスクリプションフィルターを更新する必要があります。この更新により IAM ロールが追加されます。IAM ロールは CloudWatch が引き受けることができ、送信者アカウントが受信者アカウントにログを送信する権限を持っていることを検証できます。
すべての送信者アカウントについてクロスアカウントサブスクリプションのアクセス許可に組織 ID を使用するように更新するには、このセクションのステップを実施します。
このセクションの例では、2 つのアカウント `111111111111` と `222222222222` は、アカウント `999999999999` にログを送信するために作成されたサブスクリプションフィルターをすでに持っています。既存のサブスクリプションフィルター値は次のとおりです。
```
## Existing Subscription Filter parameter values
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
現在のサブスクリプションフィルターパラメータ値を見つける必要がある場合は、次のコマンドを入力します。
```
aws logs describe-subscription-filters
\ --log-group-name "my-log-group-name"
```
**サブスクリプションフィルターを更新して、クロスアカウントログの権限で組織 ID の使用をスタートする方法**
1. 以下の信頼ポリシーを作成し、`~/TrustPolicyForCWL.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` 値の `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.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
```
1. 次のコマンドを入力して、サブスクリプションフィルターを更新します。
```
aws logs put-subscription-filter
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
\ --role-arn "arn:aws:iam::111111111111:role/CWLtoSubscriptionFilterRole"
```
# ステップ 2: 既存の送信先アクセスポリシーを更新する
すべての送信者アカウントのサブスクリプションフィルターを更新した後、受信者アカウントの送信先アクセスポリシーを更新できます。
以下の例では、受信者アカウントは `999999999999`、送信先は `testDestination` となっています。
この更新により、ID `o-1234567890` を持つ組織に属するすべてのアカウントが、受信者アカウントにログを送信できるようになりました。サブスクリプションフィルターが作成されたアカウントのみが、実際に受信者アカウントにログを送信します。
**受信者アカウントの送信先アクセスポリシーを更新して、権限の組織 ID の使用をスタートする方法**
1. 受信者アカウントで、テキストエディタを使用して、以下の内容の `~/AccessPolicy.json` ファイルを作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
1. 次のコマンドを入力して、先ほど作成したポリシーを既存の送信先にアタッチします。特定の AWS アカウント ID を一覧表示するアクセスポリシーではなく、組織 ID を持つアクセスポリシーを使用するように送信先を更新するには、 `force`パラメータを含めIDs。
**警告**
にリストされている AWS サービスによって送信されたログを使用している場合は[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md)、このステップを実行する前に、「」で説明されているように、まずすべての送信者アカウントのサブスクリプションフィルターを更新しておく必要があります[ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter.md)。
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Firehose を使用したクロスアカウント、クロスリージョンのログデータ共有
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ [**Log data sender (ログデータの送信者)**] — 受取人から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
+ **ログデータ受信者** — Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 222222222222 で表示されます。
このセクションの例では、Amazon S3 ストレージで Firehose 配信ストリームを使用しています。異なる設定で Firehose 配信ストリームを設定することもできます。詳細については、「[Creating a Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。
**注記**
***[同じアカウント]*** と ***[クロスリージョン]*** 配信ストリームに対して Firehose サブスクリプションフィルターがサポートされています。
**Topics**
+ [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream.md)
+ [ステップ 2: 送信先を作成する](CreateFirehoseStreamDestination.md)
+ [ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilterFirehose.md)
+ [ログイベントの送信の検証](ValidateLogEventFlowFirehose.md)
+ [実行時の送信先のメンバーシップの変更](ModifyDestinationMembershipFirehose.md)
# ステップ 1: Firehose 配信ストリームを作成する
**重要**
以下の手順を実行する前に、Firehose が Amazon S3 バケットにアクセスできるように、アクセスポリシーを使用する必要があります。詳細については、「[Amazon Data Firehose 開発者ガイド](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3)」の「*Controlling Access*」を参照してください。
このセクションのすべての手順 (ステップ 1) は、ログデータの受取人アカウントで行われます。
次のサンプルコマンドでは、米国東部 (バージニア北部) が使用されています。このリージョンを、デプロイに適したリージョンに置き換えます。
**送信先として使用する Firehose 配信ストリームを作成するには**
1. Amazon S3 バケットの作成
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. バケットにデータを配置するためのアクセス許可を Firehose に付与する IAM ロールを作成します。
1. まず、テキストエディタを使用して、ファイル `~/TrustPolicyForFirehose.json` で信頼ポリシーを作成します。
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. 作成したばかりの信頼ポリシーファイルを指定して、IAM ロールを作成します。
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. このコマンドの出力は、次のようになります。ロール名とロール ARN を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. アクセス許可ポリシーを作成し、Firehose がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForFirehose.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。ユースケースによっては、このファイルにさらにアクセス権限を追加する必要がある場合があります。
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス権限ポリシーを IAM ロールに関連付けます。
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. 次のコマンドを入力して、Firehose 配信ストリームを作成します。*my-role-arn* および *amzn-s3-demo-bucket2-arn* をデプロイに適した値に置き換えます。
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
出力は次の例に類似したものになります:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# ステップ 2: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream.md) で作成した Firehose ストリームがアクティブになるまで待ちます。次のコマンドを使用して、**StreamDescription.StreamStatus** プロパティを確認できます。
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
さらに、後の手順で使用する必要があるため、**DeliveryStreamDescription.DeliveryStreamARN** 値を書き留めます。このコマンドの出力例:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
配信ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. 配信ストリームがアクティブになったら、Firehose ストリームにデータを置くためのアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。テキストエディタを使用してこのポリシーを作成します。CloudWatch Logs エンドポイントの詳細については、[Amazon CloudWatch Logs エンドポイントおよびクォータ](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)を参照してください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. **aws iam create-role** コマンドを使用して、作成した信頼ポリシーファイルを指定して IAM ロールを作成します。
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
以下は出力例です。後のステップで使用する必要があるため、`Role.Arn` の戻り値を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2021-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. 次のコマンドを入力して、アクセス権限ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Firehose 配信ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。後のステップでこれを `destination.arn` として使用するため、ペイロードで返される新しい宛先の ARN を書き留めます。
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. 前のステップが完了したら、ログデータ受取人アカウント (222222222222) で、アクセスポリシーを送信先に関連付けます。
このポリシーにより、ログデータの送信者アカウント (111111111111) に対し、ログデータの受信者アカウント (222222222222) にある送信先にアクセスすることを許可します。テキストエディタを使用して、このポリシーを **\$1/AccessPolicy.json** ファイルに配置できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. これにより、誰が送信先に書き込むことができるかを定義するポリシーが作成されます。このポリシーでは、送信先にアクセスするための **logs:PutSubscriptionFilter** アクションが指定されている必要があります。クロスアカウントのユーザーは、**PutSubscriptionFilter** アクションを使用して送信先にログイベントを送信します。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する
AWS クロスアカウントポリシーの評価ロジックに従って、クロスアカウントリソース (サブスクリプションフィルターの送信先として使用される Kinesis または Firehose ストリームなど) にアクセスするには、クロスアカウントの送信先リソースへの明示的なアクセスを提供する ID ベースのポリシーを送信アカウントに含める必要があります。ポリシーの評価論理の詳細については、「[クロスアカウントポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」を参照してください。
ID ベースのポリシーは、サブスクリプションフィルターの作成に使用している IAM ロールまたは IAM ユーザーにアタッチできます。送信アカウントにこのポリシーが存在する必要があります。管理者ロールを使用してサブスクリプションフィルタを作成している場合は、このステップをスキップして [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md) に進んでください。
**クロスアカウントに必要な IAM アクセス許可を追加または検証するには**
1. 次のコマンドを入力して、 AWS ログコマンドの実行に使用されている IAM ロールまたは IAM ユーザーを確認します。
```
aws sts get-caller-identity
```
このコマンドにより、以下のような出力が返されます。
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
*RoleName* または *UserName* で表される値を書き留めておいてください。
1. 送信アカウント AWS マネジメントコンソール で にサインインし、ステップ 1 で入力したコマンドの出力で返された IAM ロールまたは IAM ユーザーを使用して、アタッチされたポリシーを検索します。
1. このロールまたはユーザーにアタッチされたポリシーが、クロスアカウントの宛先リソースで `logs:PutSubscriptionFilter` を呼び出すための明示的なアクセス許可が付与されていることを確認します。
次のポリシーは、1 つの AWS アカウント、アカウント でのみ、任意の送信先リソースにサブスクリプションフィルターを作成するアクセス許可を提供します`999999999999`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAnyResourceInOneSpecificAccount",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
次のポリシーは、単一の AWS アカウント、アカウント `sampleDestination`で という名前の特定の送信先リソースに対してのみサブスクリプションフィルターを作成するアクセス許可を提供します`123456789012`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnSpecificResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:amzn-s3-demo-bucket"
]
}
]
}
```
------
# ステップ 4: サブスクリプションフィルターを作成する
送信側のアカウント (この例では 111111111111) に切り替えます。次に、送信側のアカウントにサブスクリプションフィルターを作成します。この例では、フィルターは AWS CloudTrail イベントを含むロググループに関連付けられているため、「ルート AWS 」認証情報によって行われたログに記録されたすべてのアクティビティが、以前に作成した送信先に配信されます。CloudWatch Logs に AWS CloudTrail イベントを送信する方法の詳細については、*AWS CloudTrail 「 ユーザーガイド*[」のCloudTrail イベントを CloudWatch Logs に送信する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html)」を参照してください。
次のコマンドを入力するときは、必ず IAM ユーザーとしてサインインしているか、[ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions-Firehose.md) にポリシーを追加した IAM ロールを使用してサインインしていることを確認してください。
```
aws logs put-subscription-filter \
--log-group-name "aws-cloudtrail-logs-111111111111-300a971e" \
--filter-name "firehose_test" \
--filter-pattern "{$.userIdentity.type = AssumedRole}" \
--destination-arn "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
```
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先は、別のリージョンにある Firehose ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信の検証
サブスクリプションフィルターを作成すると、CloudWatch Logs は、フィルタパターンに一致するすべての受信ログイベントを Firehose 配信ストリームに転送します。データは、Firehose 配信ストリームに設定されている時間バッファ間隔に基づいて、Amazon S3 バケットに順次表示されます。十分な時間が経過すると、Amazon S3 バケットをチェックしてデータを確認できます。バケットを確認するには、次のコマンドを入力します。
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
そのコマンドの出力は、次のようになります。
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2021-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
その後、次のコマンドを入力して、バケットから特定のオブジェクトを取得できます。`key` の値を、前のコマンドで検索した値に置き換えます。
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Simple Storage Service (Amazon S3) オブジェクトのデータは、gzip 形式で圧縮されます。raw データは、コマンドラインから次のコマンドを使用して調べることができます。
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
所有している送信先からログ送信者を追加または削除しなければならない状況が発生することがあります。新しいアクセスポリシーが関連付けられている送信先に対して **PutDestinationPolicy** アクションを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **333333333333** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **333333333333** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. 次のコマンドを使用して、**NewAccessPolicy.json** ファイルで定義されたポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **333333333333** の所有者がサブスクリプションフィルターを作成すると、すぐに **333333333333** からのログイベントが送信先に送信されるようになります。
# Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンアカウントレベルのサブスクリプション
クロスアカウントサブスクリプションを作成するときに、単一のアカウントまたは組織を送信者として指定できます。組織を指定した場合、この手順により組織内のすべてのアカウントがレシーバーアカウントにログを送信できるようになります。
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ **[Log data sender] **(ログデータの送信者) — 受信者から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
1 つの組織で複数のアカウントを 1 つの受信者アカウントにログを送信する場合は、組織内のすべてのアカウントに対して受信者アカウントにログを送信するアクセス許可を付与するポリシーを作成することができます。引き続き、送信者アカウントごとに個別のサブスクリプションフィルターを設定する必要があります。
+ **ログデータ受信者** - Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 999999999999 で表示されます。
クロスアカウントのユーザーからのログイベントの受け取りを開始するには、ログデータの受取人がまず CloudWatch Logs 送信先を作成する必要があります。各送信先は以下のキー要素で構成されています。
**送信先名**
作成する送信先の名前。
**ターゲット ARN**
サブスクリプションフィードの送信先として使用するリソースの Amazon AWS リソースネーム (ARN)。
**ロールの ARN**
選択したストリームにデータを配置するために必要なアクセス許可を CloudWatch Logs に付与する AWS Identity and Access Management (IAM) ロール。
**アクセスポリシー**
送信先に書き込むことが許可されている一連のユーザーを管理する IAM ポリシードキュメント (IAM ポリシー構文を使用して記述された JSON 形式のドキュメント）。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。次のセクションの例では、リージョン固有のリソースはすべて米国東部 (バージニア北部) で作成されます。
**Topics**
+ [新しいクロスアカウントサブスクリプションの設定](Cross-Account-Log_Subscription-New-Account.md)
+ [既存のクロスアカウントサブスクリプションの更新](Cross-Account-Log_Subscription-Update-Account.md)
# 新しいクロスアカウントサブスクリプションの設定
次のセクションの手順に従って、新しいクロスアカウントログサブスクリプションを設定します。
**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** からのログイベントが送信先に送信されるようになります。
# 既存のクロスアカウントサブスクリプションの更新
送信先アカウントが特定の送信者アカウントにのみアクセス許可を付与しているクロスアカウントのログサブスクリプションがあり、このサブスクリプションを更新して送信先アカウントが組織内のすべてのアカウントにアクセスできるようにする場合は、このセクションのステップを実施します。
**Topics**
+ [ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy-Account.md)
# ステップ 1: サブスクリプションフィルターを更新する
**注記**
この手順は、[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md) に記載されているサービスによって作成されたログのクロスアカウントのサブスクリプションにのみ必要です。これらのロググループのいずれかで作成されたログを操作していない場合は、[ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy-Account.md) にスキップできます。
場合によっては、送信先アカウントにログを送信する、すべての送信者アカウントのサブスクリプションフィルターを更新する必要があります。この更新により IAM ロールが追加されます。IAM ロールは CloudWatch が引き受けることができ、送信者アカウントが受信者アカウントにログを送信する権限を持っていることを検証できます。
すべての送信者アカウントについてクロスアカウントサブスクリプションのアクセス許可に組織 ID を使用するように更新するには、このセクションのステップを実施します。
このセクションの例では、2 つのアカウント `111111111111` と `222222222222` は、アカウント `999999999999` にログを送信するために作成されたサブスクリプションフィルターをすでに持っています。既存のサブスクリプションフィルター値は次のとおりです。
```
## Existing Subscription Filter parameter values
{
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"FilterPattern": "{$.userIdentity.type = Root}",
"Distribution": "Random"
}
```
現在のサブスクリプションフィルターパラメータ値を見つける必要がある場合は、次のコマンドを入力します。
```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```
**サブスクリプションフィルターを更新して、クロスアカウントログの権限で組織 ID の使用をスタートする方法**
1. 以下の信頼ポリシーを作成し、`~/TrustPolicyForCWL.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` 値の `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.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
```
1. 次のコマンドを入力して、サブスクリプションフィルターポリシーを更新します。
```
aws logs put-account-policy \
--policy-name "CrossAccountStreamsExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "{$.userIdentity.type = Root}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
# ステップ 2: 既存の送信先アクセスポリシーを更新する
すべての送信者アカウントのサブスクリプションフィルターを更新した後、受信者アカウントの送信先アクセスポリシーを更新できます。
以下の例では、受信者アカウントは `999999999999`、送信先は `testDestination` となっています。
この更新により、ID `o-1234567890` を持つ組織に属するすべてのアカウントが、受信者アカウントにログを送信できるようになりました。サブスクリプションフィルターが作成されたアカウントのみが、実際に受信者アカウントにログを送信します。
**受信者アカウントの送信先アクセスポリシーを更新して、権限の組織 ID の使用をスタートする方法**
1. 受信者アカウントで、テキストエディタを使用して、以下の内容の `~/AccessPolicy.json` ファイルを作成します。
------
#### [ 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"
]
}
}
}
]
}
```
------
1. 次のコマンドを入力して、先ほど作成したポリシーを既存の送信先にアタッチします。特定の AWS アカウント ID を一覧表示するアクセスポリシーではなく、組織 ID を持つアクセスポリシーを使用するように送信先を更新するには、 `force`パラメータを含めIDs。
**警告**
にリストされている AWS サービスによって送信されたログを使用している場合は[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md)、このステップを実行する前に、「」で説明されているように、まずすべての送信者アカウントのサブスクリプションフィルターを更新しておく必要があります[ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter-Account.md)。
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Firehose を使用したクロスアカウント、クロスリージョン、アカウントレベルのサブスクリプション
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ [**Log data sender (ログデータの送信者)**] — 受取人から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
+ **ログデータ受信者** — Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 222222222222 で表示されます。
このセクションの例では、Amazon S3 ストレージで Firehose 配信ストリームを使用しています。異なる設定で Firehose 配信ストリームを設定することもできます。詳細については、「[Creating a Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。
**注記**
***[同じアカウント]*** と ***[クロスリージョン]*** 配信ストリームに対して Firehose サブスクリプションフィルターがサポートされています。
**Topics**
+ [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream-Account.md)
+ [ステップ 2: 送信先を作成する](CreateFirehoseStreamDestination-Account.md)
+ [ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilterFirehose-Account.md)
+ [ログイベントの送信の検証](ValidateLogEventFlowFirehose-Account.md)
+ [実行時の送信先のメンバーシップの変更](ModifyDestinationMembershipFirehose-Account.md)
# ステップ 1: Firehose 配信ストリームを作成する
**重要**
以下の手順を実行する前に、Firehose が Amazon S3 バケットにアクセスできるように、アクセスポリシーを使用する必要があります。詳細については、「[Amazon Data Firehose 開発者ガイド](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3)」の「*Controlling Access*」を参照してください。
このセクションのすべての手順 (ステップ 1) は、ログデータの受取人アカウントで行われます。
次のサンプルコマンドでは、米国東部 (バージニア北部) が使用されています。このリージョンを、デプロイに適したリージョンに置き換えます。
**送信先として使用する Firehose 配信ストリームを作成するには**
1. Amazon S3 バケットの作成
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. バケットにデータを配置するためのアクセス許可を Firehose に付与する IAM ロールを作成します。
1. まず、テキストエディタを使用して、ファイル `~/TrustPolicyForFirehose.json` で信頼ポリシーを作成します。
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. 作成したばかりの信頼ポリシーファイルを指定して、IAM ロールを作成します。
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. このコマンドの出力は、次のようになります。ロール名とロール ARN を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. アクセス許可ポリシーを作成し、Firehose がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForFirehose.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。ユースケースによっては、このファイルにさらにアクセス権限を追加する必要がある場合があります。
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス権限ポリシーを IAM ロールに関連付けます。
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. 次のコマンドを入力して、Firehose 配信ストリームを作成します。*my-role-arn* および *amzn-s3-demo-bucket2-arn* をデプロイに適した値に置き換えます。
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
出力は次の例に類似したものになります:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# ステップ 2: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream-Account.md) で作成した Firehose ストリームがアクティブになるまで待ちます。次のコマンドを使用して、**StreamDescription.StreamStatus** プロパティを確認できます。
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
さらに、後の手順で使用する必要があるため、**DeliveryStreamDescription.DeliveryStreamARN** 値を書き留めます。このコマンドの出力例:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
配信ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. 配信ストリームがアクティブになったら、Firehose ストリームにデータを置くためのアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。テキストエディタを使用してこのポリシーを作成します。CloudWatch Logs エンドポイントの詳細については、[Amazon CloudWatch Logs エンドポイントおよびクォータ](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)を参照してください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. **aws iam create-role** コマンドを使用して、作成した信頼ポリシーファイルを指定して IAM ロールを作成します。
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
以下は出力例です。後のステップで使用する必要があるため、`Role.Arn` の戻り値を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2023-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. 次のコマンドを入力して、アクセス権限ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Firehose 配信ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。後のステップでこれを `destination.arn` として使用するため、ペイロードで返される新しい宛先の ARN を書き留めます。
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. 前のステップが完了したら、ログデータ受取人アカウント (222222222222) で、アクセスポリシーを送信先に関連付けます。このポリシーにより、ログデータの送信者アカウント (111111111111) に対し、ログデータの受信者アカウント (222222222222) にある送信先にアクセスすることを許可します。テキストエディタを使用して、このポリシーを `~/AccessPolicy.json` ファイルに配置できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. これにより、誰が送信先に書き込むことができるかを定義するポリシーが作成されます。このポリシーでは、送信先にアクセスするための `logs:PutSubscriptionFilter` および `logs:PutAccountPolicy` アクションを指定する必要があります。クロスアカウントのユーザーは、`PutSubscriptionFilter` および `PutAccountPolicy` アクションを使用して送信先にログイベントを送信します。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する
送信側のアカウント (この例では 111111111111) に切り替えます。次に、送信側のアカウントにアカウントレベルのサブスクリプションフィルターポリシーを作成します。この例では、フィルターにより、2 つを除くすべてのロググループに含まれる文字列 `ERROR` を含むすべてのログイベントが、以前に作成した送信先に配信されます。
```
aws logs put-account-policy \
--policy-name "CrossAccountFirehoseExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination", "FilterPattern": "{$.userIdentity.type = AssumedRole}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
送信アカウントのロググループと送信先は同じ AWS リージョンに存在している必要があります。ただし、送信先は、別のリージョンにある Firehose ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信の検証
サブスクリプションフィルターを作成すると、CloudWatch Logs から、フィルタパターンと選択基準に一致するすべての受信ログイベントが Kinesis Data Firehose 配信ストリームに転送されます。データは、Firehose 配信ストリームに設定されている時間バッファ間隔に基づいて、Amazon S3 バケットに順次表示されます。十分な時間が経過すると、Amazon S3 バケットをチェックしてデータを確認できます。バケットを確認するには、次のコマンドを入力します。
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
そのコマンドの出力は、次のようになります。
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2023-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
その後、次のコマンドを入力して、バケットから特定のオブジェクトを取得できます。`key` の値を、前のコマンドで検索した値に置き換えます。
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Simple Storage Service (Amazon S3) オブジェクトのデータは、gzip 形式で圧縮されます。raw データは、コマンドラインから次のコマンドを使用して調べることができます。
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
所有している送信先からログ送信者を追加または削除しなければならない状況が発生することがあります。新しいアクセスポリシーが関連付けられている送信先に対して **PutDestinationPolicy** および `PutAccountPolicy` アクションを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **333333333333** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
```
返されたデータは、次のように表示される場合があります。
```
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **333333333333** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. 次のコマンドを使用して、**NewAccessPolicy.json** ファイルで定義されたポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **333333333333** の所有者がサブスクリプションフィルターを作成すると、すぐに **333333333333** からのログイベントが送信先に送信されるようになります。