GudardDutyのログは仕様上暗号化されてS3に出力される。そのログをS3レプリケーションで別のAWSアカウントにレプリケーションしたい
アカウントA ==> アカウントB
環境
-
アカウントA
- GuardDutyログを暗号化するKMSキー：gd-test-src
- GuardDutyログを保存するS3バケット：gd-src
- GuardDuty有効化
-
アカウントB
- KMSキー：gd-test-dst
- アカウントAのGuardDutyログのレプリ先S3バケット：gd-test-dst
S3バケット作成
アカウントBで操作
S3バケットgd-dstを作成
バージョニング有効化
KMSの作成
アカウントAで操作
CMKを"gd-test-src"で作成
キーポリシーに以下を追加
{
"Sid": "Allow GuardDuty to use the key",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "kms:GenerateDataKey",
"Resource": "*"
}
アカウントBで操作
CMKを"gd-test-dst"で作成
このCMKのARNをコピーしておく
arn:aws:kms:ap-northeast-1:xxxxxxxxxxxx:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
GuardDuty設定
アカウントAで操作
GuardDutyを有効化
S3バケット設定：「今すぐ設定する」をクリックし"gd-src"のバケットを新規作成
S3のバケットポリシーが勝手に入る
このバケットのバージョニングを有効化しておく
KMS:"gd-test-src"を選択
GuardDutyでサンプル実行してS3ログ出力を確認しといてもよい(S3出力されるまでに多少ディレイ有り)
S3レプリケーション設定
アカウントAで操作
S3バケットで、レプリケーション->ルールの追加
"gd-src"の全てのコンテンツ
"KMSで暗号化されたオブジェクトを複製する"にチェック
キーに"gd-test-src"
バケット名(アカウントIDとバケット名)
アカウントBのKMS CMKのARNを入れ、"オブジェクト所有者を送信先バケット所有者に変更"にチェックを入れる
"新しいロールを作成"を選びS3ロールを自動作成
"s3crr_role_for_gd-src_to_gd-test-dst"と言うロールが作成される
https://aws.amazon.com/jp/blogs/news/replicating-existing-objects-between-s3-buckets/
自動作成されたIAMロールのARNはコピーしておく
arn:aws:iam::xxxxxxxxxxxx:role/service-role/s3crr_role_for_gd-src_to_gd-test-dst
送信先用のバケットポリシーは後でコピーできるので無視し
KMSキーポリシーは手元にコピーしておき、KMS CMKの"gd-test-src"のキーポリシーに追加しておく
[次へ]->[完了]をクリックする。次の画面になる。
S3バケットレプリケーション設定
アカウントBで操作
レプリ先S3バケットの、レプリケーション->アクション->"オブジェクトの受信"をクリックする
この操作を行うことで、簡単に送信先用のS3バケットポリシーの設定などを行える
送信元のAWSアカウントIDを入れる。するとその送信元AWSアカウントIDを踏まえたバケットポリシーが作成される。[設定の適用]をクリックすると自動作成されたバケットポリシーが適用される。[設定の適用]をクリックする
KMSのキーポリシーは手元にコピーし、KMS CMKの"gd-test-dst"に追記しておく
ただ、rootが付いたprincipalになっているので、より操作を制限したいのであれば、送信元で作成したレプリケーション用のIAMロールで絞る。
※"arn:aws:iam::accountid:root"のrootが付いたプリンシパルは、"arn:aws:iam::accountid"と意味は同じです。
これはアカウント自体を示すもので、ARNで示してるアカウントから見て当該バケットを所有しているのと同じアクセス権限設定が可能。
このアカウントのユーザーでちゃんとこのS3バケットに権限があれば(またはadministrator権限があるなど)、アクセスできる。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns
※ドキュメントのロール名の書き方サンプルが少し分かりづらいので注意
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/replication-walkthrough-2.html
ドキュメントには以下のように書かれているが
arn:aws:iam::source-bucket-acct-ID:source-acct-IAM-role
実際の自動作成されるIAMロールのARNは以下のように"service-role"という箇所が入っているので注意
arn:aws:iam::xxxxxxxxxxxx:role/service-role/s3crr_role_for_gd-src_to_gd-test-dst
動作確認
アカウントAで操作
GDのサンプル生成
S3に出力されてる確認
アカウントBで操作
S3にレプリされてる確認
参考
手動でレプリケーション用のIAMロール作成
S3がレプリする際に使うIAMロールの作成(サービスロール)
手動作成の公式ドキュメント
ロールとポリシーと信頼関係を作ってる
これらの権限を付与してます↓
アクセスポリシーは、以下のアクションに対するアクセス許可を付与します。
s3:GetReplicationConfiguration および s3:ListBucket — レプリケート元バケットでのこれらのアクションのアクセス許可により、Amazon S3 はレプリケーション設定とリストバケットのコンテンツを取得できます (現在のアクセス許可モデルでは、削除マーカーにアクセスするには s3:ListBucket アクセス許可が必要です)。
s3:GetObjectVersion および s3:GetObjectVersionAcl — すべてのオブジェクトに付与されているこれらのアクションのアクセス許可により、Amazon S3 はオブジェクトに関連付けられた特定のオブジェクトバージョンおよびアクセスコントロールリスト (ACL) を取得することができます。
s3:ReplicateObject および s3:ReplicateDelete — レプリケート先バケットのオブジェクトに対するこれらのアクションのアクセス許可により、Amazon S3 はレプリケート先バケットにオブジェクトまたは削除マーカーをレプリケートできます。削除マーカーの詳細については、「削除オペレーションがレプリケーションに与える影響」を参照してください。