はじめに
こんにちは、クラウド事業部のおほりです。
S3 は AWS の中で最も歴史あるサービスで、3月14日に17周年を迎えます。人間なら高校2年生くらいですね! 日付にちなんで "AWS Pi Day" なんて名前がついたお誕生日会が開催されたりもします。
そんな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の評価フローについては以下をご参照ください。
ブロックパブリックアクセス
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 SecurityHubを使ってS3のセキュリティベストプラクティスに沿っているかチェックができますし、Amazon GuardDutyで不審なアクセスを発見できます。
これらのサービスを使って、楽に、継続的にセキュリティガバナンスを向上させていきましょう。
おわりに
私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
https://www.ap-com.co.jp/service/utilize-aws/
また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。