はじめに

2025年11月、AWSはAmazon S3 Block Public Access（以下S3 BPA）に対して、組織単位の実行がサポートされたことを発表しました。これにより、マルチアカウント環境におけるパブリックアクセス制御の一元管理が可能になり、これまで個別アカウントで設定漏れを防ぐために工夫してきた運用負荷が大きく改善されます。

公式リリースでは次のように説明されています。

“Use organization-level enforcement of Amazon S3 Block Public Access to centrally manage and automatically apply public access settings across all accounts in your organization.”
（組織単位のブロックパブリックアクセスを利用して、組織内のすべてのアカウントに自動的にパブリックアクセス設定を適用できます）

この記事では、この機能の背景、仕組み、導入前の検討ポイントを整理します。

S3ポリシーとは何か

S3ポリシーで何ができるのか？

S3 BPAは、バケットやアカウント単位でS3のパブリックアクセスを一括で制御する仕組みです。今回のアップデートで、このS3 BPAをAWS Organizations（以下Organizations）のポリシーとしてOUやルートに一元適用できるようになりました。

ポリシーでどう管理されるのか？

これまでのS3 BPAは、単体のS3バケットに対して設定するバケット単位と、AWSアカウント全体に対して設定するアカウント全体の2つのレイヤーで設定できました。しかし、これらは各アカウントごとの設定であるため、マルチアカウント環境では設定漏れやバラつき、変更管理が課題になりがちでした。

これまでのS3 BPAの位置づけ

バケットレベルのS3 BPA

単体のS3バケットに設定する「バケットレベルのS3 BPA」は、現在では新規に作成されるS3バケットのデフォルト設定となっています。2023年4月以降は、新規バケットが作成された時点でS3 BPAが有効になり、あわせてACLが無効化された状態で作成されるようになりました。これにより、意図せずパブリック公開される事故は起きにくくなっています。

アカウントレベルのS3 BPA

AWSアカウント全体を対象に設定できる「アカウントレベルのS3 BPA」を有効化すると、バケット単位でS3 BPAを無効化することを防止でき、アカウント内のすべてのS3バケットに対してより強い制御をかけられます。そのため、組織としてはアカウントレベルのS3 BPAを有効化するという運用を採用していたケースも多かったと思います。

それでも残っていた課題

ただし、アカウントレベルのS3 BPAには構造的な弱点がありました。アカウントレベルのS3 BPAはあくまで設定であり、設定そのものを無効化されてしまえば、それで統制が崩れてしまいます。つまり、S3 BPAが有効かどうかは最終的には各アカウントの状態に依存するという課題が残っていました。

また、新規にAWSアカウントを作成した場合も、アカウントレベルのS3 BPAは何らかの手段で明示的に有効化する必要があり、この点でも運用上の手間や抜け漏れリスクが発生していました。

これまではSCPで制御していた

こうした弱点を補うため、実務ではOrganizationsのSCPを使ってS3の操作自体を制御する運用を採用していたケースもあったと思います。たとえばs3:PutBucketPublicAccessBlockやs3:PutAccountPublicAccessBlockといった、S3 BPAを無効化するためのAPIを明示的にDenyするSCPをOUやルートにアタッチすることで、S3 BPAを意図せず無効化されることを防いだり、組織全体で最低限のガードレールを敷いたりしてきました。

この方法は、IAM権限設計に依存せず強制力を持たせられること、そして組織全体に一律で制御をかけられることから、非常に有効でした。一方で、SCPには限界もあります。SCPは「操作を禁止する」仕組みであり、「あるべき設定状態を強制する」ことはできません。そのため、S3 BPAが本当に有効かどうかは別途監査が必要になり、SCPは予防的なガードレールにはなるものの、設定状態の一貫性までは担保できないという課題がありました。

SCPとS3ポリシーの違い

今回登場したS3ポリシーは、こうしたSCPの課題を補完する位置づけにあります。

観点	SCP	S3ポリシー
制御対象	IAMプリンシパルの操作	S3の設定状態
何を止めるか	「できない操作」を定義	「あるべき設定」を強制
設定の統一	間接的	直接的
既存設定への影響	変更不可	組織レベルで上書き

今回のアップデートによって、OUやルート配下のすべてのアカウントに対してS3 BPAを「設定として」強制適用できるようになり、SCPだけでは実現できなかった設定状態の一貫性を担保できるようになりました。

S3 BPAの仕組みをおさらい

S3 BPAで制御する主な設定は次の4つです。

設定項目	何を制御するか
BlockPublicAcls	ACLによるパブリックアクセスを禁止
IgnorePublicAcls	パブリックACLを無視
BlockPublicPolicy	バケットポリシーでのパブリックアクセス指定を禁止
RestrictPublicBuckets	公開ポリシー付きバケットへのアクセスを制限

これらをS3ポリシーとしてOUやルートに付与すると、該当階層配下のすべてのアカウントに対して優先的に適用されます。

S3ポリシーの書き方の例

OrganizationsにおけるS3ポリシーはJSON形式で記述します。S3 BPAに関する設定はs3_attributes配下のpublic_access_block_configurationで定義されます。ここで@@assignを使うことで、S3 BPAの適用方法を組織レベルで制御できます。

まず、組織レベルでS3 BPAをすべて有効化し、OUやルート配下のアカウントに対して強制適用する最もシンプルな例は次のとおりです。

{
  "s3_attributes": {
    "public_access_block_configuration": {
      "@@assign": "all"
    }
  }
}

このポリシーをOUまたはルートにアタッチすると、その配下のすべてのAWSアカウントに対してS3 BPAの4つの設定が一括で有効化されます。各アカウント側でS3 BPAを無効化しようとしても、このポリシーが優先されるため、設定状態を組織として保証できます。

一方で、組織レベルの強制を解除し、各アカウントがS3 BPAの設定を管理できる状態に戻したい場合は、@@assignにnoneを指定します。

{
  "s3_attributes": {
    "public_access_block_configuration": {
      "@@assign": "none"
    }
  }
}

実際の運用では、最初からルートにアタッチするのではなく、特定OUに対して段階的に適用し、業務要件への影響がないことを確認しながら展開していく構成が取りやすくなります。

何が嬉しいのか？

S3ポリシーの価値は、「操作を縛る」だけではなく「設定状態そのものを組織で保証できる」点にあります。現場の運用で効いてくるポイントを、次の表に整理します。

観点	従来（バケット/アカウントレベルS3 BPA+必要に応じてSCP）	今回（S3ポリシー）
設定漏れの起きやすさ	新規アカウント作成後にアカウントレベルS3 BPAの有効化を忘れたり、アカウント間で設定が揃わなかったりする余地が残る。監査で検知して是正する運用になりやすい。	OUやルートで設定を強制できるため、配下のアカウントは同じ前提で守られ続ける。設定のばらつきが起きにくい。
運用負荷	アカウント作成時の初期設定、定期監査、是正対応といった運用が発生しやすい。無効化を防ぐためにSCPを追加し、管理対象が増えることもある。	「一度付与すれば配下が守られる」状態に近づくため、初期設定の抜け漏れ対策や定期的な確認や是正の頻度を下げやすい。
基準の統一	組織として“あるべき姿”を定義しても、実装は各アカウント依存になりやすく、結果として統一にコストがかかる。	OU単位で基準を実装できるため、組織としてのセキュリティ基準を構造的に統一しやすい。

S3ポリシーを導入する前に考えたいこと

S3ポリシーは組織に対して設定を強制する仕組みであるため、導入前には「どこまでを共通ルールとして適用するのか」を段階的に整理することが重要です。ここでは、業務要件、適用方針、適用範囲の3つの観点から考えていきます。

業務要件への影響を明確にする

S3 BPAは、パブリックアクセスを制限する強力な制御です。業務要件としてS3バケットをパブリックに公開しなければならない場合、S3ポリシーの適用によって既存の構成が成立しなくなる可能性があります。

そのため、まずは現在の利用状況を確認し、「パブリック公開が必要なバケットは存在するのか」、「代替手段に変更できるのか」、「どうしても例外として残す必要があるのか」といった観点で、S3ポリシーで守る設計と、業務要件として残さざるを得ない例外の境界を明確化しておく必要があります。

組織全体に適用できるかを判断する

次に考えるべきなのは、そのポリシーをすべてのアカウントで共通の前提として適用できるかです。

組織内の大半のアカウントで同じ前提で運用できるのであれば、Organizationsのポリシーとして一元的に導入する価値があります。一方で、アカウントごとに例外が多く発生する前提で導入すると、管理が複雑になり、運用負荷が増えてしまいます。

例外のアカウントが増えるほど、「なぜこのアカウントだけ設定が異なるのか」という説明や管理のコストが継続的に発生します。そのため、OrganizationsレベルでS3ポリシーを導入するのは、原則として全アカウントで共通のルールとして適用できる場合に限るという考え方が現実的です。これはセキュリティ強度というよりも、長期的な運用のしやすさを重視した判断と言えます。

もし例外となるアカウントが存在することを前提とする場合は、Organizations全体ではなく、限定されたOUやアカウント単位で適用する設計とすることで、S3ポリシーを「特定の前提を満たした環境に対するガードレール」として活用できます。