はじめに

こんにちは、クラウド事業部のおほりです。

S3 は AWS の中で最も歴史あるサービスで、3月14日に17周年を迎えます。人間なら高校2年生くらいですね！日付にちなんで "AWS Pi Day" なんて名前がついたお誕生日会が開催されたりもします。

pages.awscloud.com

そんなS3ですが長い歴史のせいでアクセス制御周りが複雑化していて、アクセスコントロールリスト、バケットポリシー、ブロックパブリックアクセス、ニンニクマシマシアブラカラメ、、、、、一体何をどうしたら良いのだ！と混乱しがちです。

ここらで簡単にまとめてセキュリティの不安を払拭しましょう。

はじめに

概要

S3のアクセス制御方法は以下の2種類です
- アクセスコントロールリスト(ACL)
- バケットポリシー
ブロックパブリックアクセスを有効化しましょう
ACLは無効化しましょう
便利なサービスに頼りましょう
- IAMアクセスアナライザー
- AWS SecurityHub
- Amazon GuardDuty

アクセスコントロールリスト(ACL)

アクセスコントロールリスト (ACL) の概要 - Amazon Simple Storage Service

(ACLは古い方式のアクセス制御なので、今後の利用は非推奨となっています。)

ACLは簡単に言うと「アクセスしてOKな人リスト」で、バケットとオブジェクトひとつひとつに対して紐づいています。もう少し難しく言うと「被付与者(grantee)に対するアクセス許可(grant)を羅列したもの」です。

コンソールのACL設定画面が一番分かりやすいのでお見せしましょう。

バケットのACL

バケットのACL設定画面です。それぞれの被付与者に対して何種類かのアクセスを許可できるようになっていることがお分かりいただけると思います。

被付与者

被付与者	説明
バケット所有者(AWSアカウント)	このバケットを所有しているAWSアカウント
全員	全世界のあらゆる人
Authenticated Users グループ	全世界のAWSアカウントを持っている人
S3ログ配信グループ	S3のサーバーアクセスログを書き込むAWSのシステム
他のAWSアカウント	任意のAWSアカウント

アクセス

アクセス	説明
オブジェクトのリスト	バケット内のオブジェクト一覧を取得できる※
オブジェクトの書き込み	バケットにオブジェクトを追加できる
ACLの読み込み	バケットのACLを取得できる
ACLの書き込み	バケットのACLを変更できる

※一覧するだけです。オブジェクトのデータを読み込むには、オブジェクトのACLで許可されていないといけません。

ホワイトアウトしているチェックボックスがありますが、これは事故防止のためコンソールから設定できないようになっているだけで、CLIから操作できます。("全員"に対する"オブジェクトの書き込み"など)

オブジェクトのACL

こちらはあるオブジェクトに紐づいているACLの設定画面です。

アクセス	説明
オブジェクトの読み込み	オブジェクトのデータを読むことができる
ACLの読み込み	オブジェクトのACLを取得できる
ACLの書き込み	オブジェクトのACLを変更できる

バケットのACLで「オブジェクトのリスト」を許可していなくても、オブジェクトのACLで「オブジェクトの読み込み」を許可しているとデータを読み取れてしまうので注意しなければなりません。

ホワイトアウトしているチェックボックスはバケットのACL同様事故防止の意味合いのものと、バケットにブロックパブリックアクセスが設定されていることに起因するものがあります。(後述)

バケットポリシー

バケットポリシーはバケット単位で設定できるポリシーです。個々のオブジェクトに紐づくものではありませんが、オブジェクト単位のアクセス制御もひとつのバケットポリシー内に記述できます。
ACLとの大きな違いは AWS IAM (Identity and Access Management) と統合されている点で、S3のバケットポリシーはIAMで言うところのリソースベースポリシーにあたります。ですから、IDベースのポリシー(IAMポリシー)とバケットポリシー両方で許可されていなければS3へ操作を行うことはできません。

また、IAMの評価フローについては以下をご参照ください。

docs.aws.amazon.com

ブロックパブリックアクセス

Amazon S3 ストレージへのパブリックアクセスのブロック - Amazon Simple Storage Service

ブロックパブリックアクセスはS3が外部公開状態になるのを防ぐガードレール的な機能です。ここでいう「パブリック」は

ACLにおいては、「全員」あるいは「Authenticated Users」グループに対する許可すべて
バケットポリシーにおいては、ソースを一切絞らないような記述※

を指します。つまり「不特定多数」とも言い換えられるでしょう。

※ソースを一切絞らないような記述というのは

Principal

Condition

両方にワイルドカード(*)を用いている状態のことです
{
      "Principal": "*", 
      "Resource": "*", 
      "Action": "s3:PutObject", 
      "Effect": "Allow", 
      "Condition": { "StringLike": {"aws:SourceVpc": "vpc-*"}}
}
引用: Amazon S3 ストレージへのパブリックアクセスのブロック - Amazon Simple Storage Service

この状態ではPrincipal (アクセス元)でも Condition (追加条件)でもワイルドカードを使用してしまっているので、このポリシーではどんなVPCからでも ≒ 全世界の誰でもこのS3バケットにアクセスできる状態です。ワイルドカードを使わずに具体的な Principal を指定するか、Conditionで具体的なVPCに絞れば不特定多数ではなくなりますので、「パブリック」と見なされません。

ブロックパブリックアクセスは

将来のACL
既存のACL
将来のバケットポリシー
既存のバケットポリシー

における「パブリック」な設定を無視・無効化することで、バケットを全世界に公開してしまうことを防ぎます。特段理由なき場合はブロックパブリックアクセスをすべて有効化しておくことをお勧めします。

デフォルト設定

(2023-03-15現在の情報です)
何も設定を変えずにS3バケットを作成したとき、

ACLが無効
ブロックパブリックアクセスが全て有効

となります。すなわちデフォルトではバケットポリシーのみでアクセスが制御され、不特定多数への公開は常に防止される状態です。
初期設定ではバケットポリシーは空なので、そのバケットを作ったアカウントのプリンシパルだけがアクセスできるようになっています。

S3のセキュリティ強化に役立つサービス

S3のアクセス制御について述べましたが、複数のバケットを管理している場合、それらひとつひとつの設定を確認するのは現実的ではありません。しかしIAMアクセスアナライザーを用いれば、S3バケットへの外部アクセスをまとめて分析できます。
誰に対してどのような操作を許可しているのかをコンソールから簡単に確認できますので、定期的に確認を行うことをおすすめします。

aws.amazon.com

また、AWS SecurityHubを使ってS3のセキュリティベストプラクティスに沿っているかチェックができますし、Amazon GuardDutyで不審なアクセスを発見できます。

docs.aws.amazon.com

これらのサービスを使って、楽に、継続的にセキュリティガバナンスを向上させていきましょう。