はじめに
AWSのS3バケット内のデータ (オブジェクト) は、何かしらの目的を持って保管されていますので、情報漏洩などのセキュリティリスクからの保護だけでなく、運用時の誤削除からも保護する必要があります。
本記事では基本的な権限管理の考え方と、どのようにして誤削除から守るのかを記載します。
S3を取り巻くアクセス権限管理
AWSのS3バケットに関連するアクセス権限は、主に次の5箇所の設定で制御できます。
- IAMポリシー
- S3アクセスコントロールポリシー (ACL)
- S3バケットポリシー
- S3オブジェクトタグ
- S3アクセスポイント
本記事では、最も基本に立ち返り、IAMポリシーとS3バケットポリシーについて記述します。
IAMポリシーとS3バケットポリシーの違い
ここで、どちらもJSONで書くことは分かっているものの、何をどのように制御するためのものなのか混乱しやすい、IAMポリシーとS3バケットポリシーの違いを見ていきます。
これらを比較すると、様々なドキュメントでは同じ ACL という言葉で表現されているものですが、制御するアクセスの矢印が、両者で真逆であることが分かります。
-
IAMポリシー
- ユーザーなどのエンティティに対して許可する アクセス先と操作 を制御する
- 全てのAWSサービスに対する操作を制御する
- デフォルトでは全ての操作が拒否されている
- 必要な操作だけを許可する
- ユーザーなどのエンティティに対して許可する アクセス先と操作 を制御する
-
S3バケットポリシー
- S3バケットが受け入れる アクセス元と操作 を制御する
- IAMロールを必要とせずにクロスアカウントアクセスを制御する
- デフォルトでプライベート (パブリックアクセス不可)
ポリシーの基本
理解を容易にするため、以下のポリシーを参考にして見ていきます。
以下はS3バケットポリシーのサンプルです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "statement1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountB-ID:user/Dave"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::awsexamplebucket1/*",
"Condition": {
"StringEquals": {
"s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID"
}
}
}
]
}
引用: Amazon S3 条件キーの例
この後の理解を容易にするため、各項目の意味をおさらいします。
- Statement
- リストになっており、複数のアクセス制御の集合体です。
- Effect
- Allow (許可) または Deny (拒否) です。
- 常にDenyと書いたアクセス制御が優先されます。
- Principal
- AllowまたはDenyするエンティティです。
- Action
- AllowまたはDenyする操作です。
- Resource
- Actionが行われる対象のリソースです。
- Condition
- この定義されたアクセス制御が有効と判定される条件です。
S3バケットポリシーの場合 自らに対して行われるアクセスの制限 をします。
IAMポリシーの場合、アタッチされた エンティティが行うアクセスの制限 をします。
繰り返しになりますが、それぞれのポリシーで表現される アクセスの方向 (矢印) は真逆 です。
これこそが、別の記事 で書いたポリシーのカテゴリの違いであり、IDポリシーであるIAMポリシーと、リソースポリシーであるS3バケットポリシーでは、定義するアクセス制御の方向が異なります。
両方のポリシーが意図するものとなっていない場合、誤削除を含む意図しないアクセスが実行される可能性があります。
誤削除を防ぐアクセス制限の大原則
それではIAMポリシーとS3バケットポリシーの両方で、どのように制限すれば誤削除を防ぐことができるのかを考えていきます。
IAMポリシー
最も基本的な原則は、以下となります。
-
AllowするActionを、AWSの管理ポリシーである 「AmazonS3ReadOnlyAccess」 に限定します。
- この時点で少なくとも削除できなくなります。
- Access Denied になります。
つまり 「S3オブジェクトを削除されないようにしたい」 という要件が登場した瞬間に、とりあえずでもIAMポリシーで許可するS3のActionを 「AmazonS3ReadOnlyAccess」 に限定すれば、誤削除は防げます。
基本中の基本のことですが、これだけを覚えておくだけでも安心できます。
S3バケットポリシー
最も基本的な原則は、以下となります。
-
全てのPrincipalからの
s3:DeleteObjectをDenyします。- この時点で少なくとも削除できなくなります。
- Access Denied になります。
{
"Id": "Policy1645848096658",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1645848092234",
"Principal": "*",
"Action": [
"s3:DeleteObject"
],
"Effect": "Deny",
"Resource": "arn:aws:s3:::awsexamplebucket1/*"
}
]
}
つまり 「S3オブジェクトを削除されないようにしたい」 という要件が登場した瞬間に、とりあえずでもS3バケットポリシーで上記のポリシーを書いてしまえば、誤削除は防げます。
基本中の基本のことですが、これだけを覚えておくだけでも安心できます。
(参考) アクセス制御の判定フロー
IAMポリシーとS3バケットポリシーの両方で、どう誤削除からオブジェクトを保護するのかについて記載しました。
ここで、そもそもIAMポリシーとS3バケットポリシーはどのようにして評価され、最終的にアクセスがAllowまたはDenyされるのかについて振り返ってみます。
下の図は、2013年にAWSの公式ブログに掲載された、最も基本的なフローです。
引用: IAM Policies and Bucket Policies and ACLs! Oh, My! (Controlling Access to S3 Resources)
上記フローの(2)で、IAMポリシーとS3バケットポリシーが評価されます。
評価の結果、(3)でDenyがあればその時点でDeny、Denyが無いものは(4)でAllowがあればその時点でAllow、Allowも無いものは(5)でDenyとなります。
IAMポリシーの「AmazonS3ReadOnlyAccess」は読み取り制限ではありますが、Allowしている範囲が広めのポリシーです。
繰り返しになりますが、Denyが優先されますので、「AmazonS3ReadOnlyAccess」に記載されたActionの中で拒否したいものを個別にDenyすれば、Allowする範囲を狭めることができます。
なお(2)ではIAMポリシーとS3バケットポリシーの他、VPCエンドポイントポリシーとS3オブジェクトACLも評価の対象となりますが、本記事では割愛します。
誤削除を防ぐS3バケットの設定
次に、アクセス権限以外の観点でS3オブジェクトの誤削除を防止する方法を記載します。
S3オブジェクトのバージョニング
これも最も基本なことですが、バージョニングを設定すれば、S3オブジェクトがアップロードされた時に、現バージョンが単純に上書きされて消失してしまうことを防げます。
引用: S3 バージョニングの仕組み
まとめ
2022年現在、AWSにはService Control Policy、IAM Permission Boundary、S3オブジェクトロックなど、広い範囲をターゲットにしたアクセス制限が登場しており、何をどうすれば良いか分からないと悩まれている方も多いと思います。
紹介した内容は本当に基本的なことばかりですが、ここに記載した設定を行うだけでもS3オブジェクトの誤削除から守ることができます。
今はアクセス制限を行うために様々な機能があり、あれもこれもと手を出していきたくなりますが、まずは基本的なことができているかを確認することが最善です。