Amazon S3では、オブジェクト（ファイル）のアップロード、ストレージクラスの選択、アクセス権限の設定、自動削除の構成など、さまざまな操作が可能です。課金は時間単位で、不要になったオブジェクトはいつでも削除でき、削除した時点でストレージ料金の発生は止まります。
AWSが提供する機能の一つに Object Lock があります。これはオブジェクトの削除や上書きを防ぐ仕組みで、コンプライアンスやアーカイブ目的で長期保存するデータを、誤操作や悪意ある削除から守ることを目的としています。
バケット作成時には、Object Lockの保持モード（Retention Mode）を選択でき、これによってAWSがオブジェクトの削除をどのように制限するかが決まります。
- ガバナンスモード — オブジェクトは書き込み保護されますが、特別な権限を持つユーザーであればロックを上書きまたは解除できます。
- コンプライアンスモード — 設定した保持期間中、オブジェクトは完全に変更不可となります。ルートアカウントユーザーやAWSサポートであっても、期間中は削除できません。
いずれのモードでも、保持期間は1日から100年までの範囲で設定でき、各オブジェクトがS3にアップロードされた時点から個別にカウントされます。
バケットでObject Lockを有効化すると、アップロード時にオブジェクトごとのロックモードと保持期間を指定できます。指定しなかった場合は、デフォルト設定が適用されます。
後からデフォルト設定を変更しても、影響を受けるのは新規オブジェクトのみです。既存のオブジェクトは、アップロード時に設定されたロック構成のまま保持されます。
ここではコンプライアンスモードに焦点を当てます。
このモードを有効にすると、アップロード後のオブジェクトは、IAMロールやユーザーはもちろん、ルートユーザーであっても保持期間が終わるまで削除できません。AWSサポートに依頼しても、期限前の削除は不可能です。
削除しようとすると、次のエラーが返されます。
「Access Denied because object protected by object lock.」
なぜブロックすべきなのか？
AWSアカウントが侵害された際の被害を最小限に抑えるためです。
少し説明します。攻撃者がAWSアカウントへのアクセスを得た場合、典型的な手口は次の3つです。
- 身代金要求と破壊: バックアップを暗号化し、身代金を要求するとともに、リソースを削除して混乱を引き起こす。
- 暗号資産マイニング: 利用可能なすべてのリージョンで高額なGPUコンピューティングインスタンスを起動し、暗号資産をマイニングする。
- 金銭的消耗: メタルインスタンスや大容量EBSボリュームなどの高コストなリソースをプロビジョニングしたり、Redshift Reserved Nodeを購入したりして、請求額を膨らませる。
中でも特に悪質な手口が、コンプライアンスモードで長期の保持期間を設定したObject Lock付きS3バケットを作成し、乗っ取ったEC2インスタンスから巨大なファイル、場合によっては保持自体が違法なコンテンツをアップロードする、というものです。
その後、コストレビューや異常検知の際に、削除不可能な大量のデータを抱えたバケットが発覚し、月額数千ドルから数万ドルのコストがかかっているにもかかわらず、手の打ちようがないという事態に陥りかねません。
では、コンプライアンスモードで保護されたオブジェクトを含むバケットを削除するには？
削除できません。
唯一の方法は、AWSアカウントごとすべてのリソースを閉鎖することです。本番環境ではとりわけ大きな負担となります。
workloads全体を新しいAWSアカウントへ移行する必要があり、フルスケールの環境移行と同様、数週間から数か月を要するプロセスになります。
ブロックする方法は？
Resource Control Policies (RCP) を活用します。これはAWS Organizationsの機能で、組織内のアカウント（管理アカウントを除く）に対し、S3バケットなどのリソースに対するポリシーを強制適用できます。
Object Lockの有効化を一切拒否するリソースポリシーを作成できます（残念ながらコンプライアンスモードのみに限定することはできません）。適用を試みると、Access Deniedエラーが返されます。
ワンポイント: 特定のユーザー（たとえばセキュリティチーム）にのみこの制限の回避を許可し、それ以外はすべてブロックする運用も可能です。こうすることで、不要なリスクにアカウントをさらすことなく、統制を維持できます。
以下は、既存・新規いずれのバケットに対してもコンプライアンスモードの利用を完全にブロックするRCPの例です。
このポリシーを適用したうえで新しいバケットを作成し、コンプライアンスモードを有効化しようとしたところ、次のエラーが表示されました。
まとめ
設定ミスや不正アクセスによる長期的な金銭的被害を最小限に抑えたいのであれば、このポリシーの適用を強くおすすめします。
なお、コンプライアンスモードはS3に限った機能ではなく、以下にも存在します。
- EBS Snapshots — EC2ボリューム（ディスク）のバックアップ
- AWS Backup Vault — AWS Backupサービス
自社のリスク許容度に応じて、これらについてもブロックを検討する価値があります。
さらに役立つリソースは doit.com/services でご覧いただけます。成功への次の一手を、ぜひこちらから。