こんにちは！西川です！
S3の「オブジェクトロック」は、名前のイメージだとオブジェクトの上書きができないように思ってしまいますが、実際にはできてしまいます。
今回は、S3のアクセスログ用のバケットで、上書きさせないような設定を実際にやってみたので紹介します。
本記事でわかること
- オブジェクトロックで上書きや削除ができてしまう理由
- アクセスログ用バケットで上書き・削除を禁止するポリシー設定
- 設定をミスるとルートアカウント降臨？Denyポリシーの注意点
- 万が一の悪意に備えてオブジェクトロックを併用する理由
オブジェクトロックで上書き・削除ができてしまう理由
オブジェクトロックを使うには、前提としてS3の「バージョニング機能」を有効にする必要があります。
バージョニングが有効な状態では、削除の操作をしても、データは直接消えません。「削除マーカー」が最新の履歴として追加されるだけで、画面からは消えたように見えます。上書きの操作も同様に、既存のデータが上書きされるのではなく、新しいデータが最新のバージョンとして追加されます。
オブジェクトロックによって過去のバージョンが完全に削除されることからは保護できますが、画面上での「上書きや削除という操作そのもの（＝新しい履歴を追加する操作）」までを禁止できるわけではないのです。
上書きも削除もさせないためにバケットポリシーを設定してみた
「見た目上であっても、人間による上書き操作や削除操作自体を完全に禁止したい！」
そう思った私は、アクセスログ用のバケットにバケットポリシーを設定して、明示的に拒否（Deny）する方法を試しました。
AWSのログ配信サービス（logging.s3.amazonaws.com）からの書き込みだけを許可し、ログ配信サービス以外からの書き込み・削除操作を拒否するという設定です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ServerAccessLogsPolicy",
"Effect": "Allow",
"Principal": {
"Service": "logging.s3.amazonaws.com"
},
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/EXAMPLE-LOGGING-PREFIX*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-source-bucket"
},
"StringEquals": {
"aws:SourceAccount": "SOURCE-ACCOUNT-ID"
}
}
},
{
"Sid": "DenyManualDeleteAndUpload",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:PutObject",
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalServiceName": "s3.amazonaws.com"
}
}
}
]
}バケットポリシー設定後、ファイルをアップロードするとアクセスが拒否されてエラーになります。
【大注意】Denyポリシーの設定ミスは命取り！
ここで、検証中に本当にヒヤッとした注意点があります。
Deny（拒否）のポリシーは想像以上に強力です。もし間違えて「すべてのユーザーのバケットポリシー更新を拒否」した状態でポリシーを保存してしまうと、管理者権限を持つ自分自身であっても二度とバケットポリシーを触れなくなります。
こうなってしまうと、通常のIAMユーザーやIAMロールでは修正できず、AWSアカウントのルートユーザー（メールアドレスでログインする特権アカウント）やOrganizationsの管理アカウントのユーザーでしか触れなくなるので、設定時は注意してください！
本記事で紹介したバケットポリシーでは、バケットポリシーの更新までは禁止していないのでご安心ください。
万が一の「悪意あるポリシー更新」に備えてオブジェクトロックを併用する
「バケットポリシーを変更できるほどの強い権限を持った人が、悪意をもってポリシーを更新（削除）してからログを改ざんする」というケースに備えるために、オブジェクトロックを併用することをお勧めします。
まとめ
今回は、S3のアクセスログバケットを絶対に改ざんされないように設定してみました。
オブジェクトロックは名前のイメージ通りには動かない部分もありますが、バケットポリシーによる操作禁止（Deny）と組み合わせることで、お互いの弱点を補い合う最強の「多層防御」が実現できます。
Denyポリシーの設定ミスによるロックアウトには十分注意しながら、ぜひみなさんの環境でも試してみてください！
コメント