S3ブロックパブリックアクセスは有効化すべき？古いアカウントの注意点と安全な進め方

安藤翔一

2025年11月17日

Amazon S3は柔軟で強力なストレージサービスですが、「誤ってデータを公開してしまう」リスクが常に存在します。これを根本的に防ぐ仕組みとして、2018年に導入されたのがS3 Block Public Access（ブロックパブリックアクセス、以下 BPA）です。
新しいアカウントではデフォルトで有効になっていますが、古いアカウントでは無効のまま運用されているケースがあり、有効化の仕方を誤るとサービス障害につながるリスクもあります。

本記事では、BPAが何を意味するのか、なぜ有効化が推奨されるのか、古いアカウントで安全に有効化するためのステップを解説します。

パブリックアクセスとは？

S3における「パブリックアクセス」とは、認証なしで誰でもオブジェクトにアクセスできる状態を指します。
たとえば、

https://<BUCKET_NAME>.amazonaws.com/<OBJECT_NAME>

に誰でもアクセスできるようになってしまうような状況です。

パブリックアクセスは以下のケースで発生します。

パブリックACLをバケットあるいはオブジェクトに設定（例: --acl public-read を指定してアップロード）
パブリックなバケットポリシーを設定（例: Principal: "*" に s3:GetObject を許可）
S3静的ウェブサイトホスティング（公開前提の設定になりやすい）

一方で、IAMユーザーや署名付きURLなどの認証付きアクセスはパブリックアクセスには含まれません。
※認証されていないアクセスでも狭い範囲の固定IPアドレスからのアクセスに制限した場合は非パブリックアクセスとなるケースもあります

※参考：https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html?utm_source=chatgpt.com#access-control-block-public-access-policy-status

ACLの種類とリスク

S3 ACLにはいくつかのプリセットがあり、意図せず公開につながるものがあります。

左右にスクロールしてご覧ください。

ACL 名	内容	リスク
private	所有者のみアクセス可能	安全（デフォルト）
public-read	誰でも読み取り可能	公開ファイル配布に使われるが誤設定リスク大
public-read-write	誰でも読み取り＋書き込み可能	匿名ユーザーがアップロード/削除できてしまい極めて危険
authenticated-read	AWS 認証済みユーザー全員が読み取り可能	「任意の AWS 利用者」＝事実上インターネット公開に近い

特にバケットに対するpublic-read-writeの適用は、EDoSの原因ともなりうるため絶対に避けるべきです。
また、authenticated-readは誤解されやすく、「自分のアカウントのユーザーだけに限定される」と思われがちですが、実際は全AWS利用者に公開されるのと同義です。

バケットポリシーでパブリックアクセスとなる例

次にパブリックアクセスとなりうるバケットポリシー例を記載します。

典型的なパブリック設定

読み取りを全員に許可

{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*"
}

書き込みを全員に許可

{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::example-bucket/*"
}

制限付きでもパブリック扱いになる例

バケットポリシーではConditionによる制限をかけたとしてもパブリック扱いとなる例があります。

IpAddressとして広いCIDRを指定（パブリック扱い）

{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*",
    "Condition": {
        "IpAddress": { "aws:SourceIp": "0.0.0.0/0" }
    }
}

NotIpAddressとして広いCIDRを指定（パブリック扱い）

{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*",
    "Condition": {
        "NotIpAddress": { "aws:SourceIp": "203.0.113.25/32" }
    }
}

非パブリック設定ではロールを指定すること

推奨される構成としてはS3バケット操作できるIAMロールを固定することが望ましいです。

{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::123456789012:role/AppRole" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-bucket/*"
}

認証付きアクセスとの違い

以下のようなアクセスは「パブリックアクセス」には含まれません。

IAMユーザーやロールによる認証付きアクセス
一時認証（STS）を経由したアクセス
署名付きURLによる期限付きアクセス

※誤解されがちですが、パブリックアクセスは「匿名ユーザーがアクセスできる状態」に限定されます
※例外的にauthenticated-readもパブリックアクセスとして定義されています

BPAの仕組み

BPAはこうしたパブリックアクセス設定の誤用を根本的に防ぐための仕組みです。

左右にスクロールしてご覧ください。

項番	設定項目	内容
1	BlockPublicAcls	新しいパブリック ACL を拒否
2	IgnorePublicAcls	既存のパブリック ACL を無視
3	BlockPublicPolicy	パブリックアクセスを許すポリシー適用を拒否
4	RestrictPublicBuckets	パブリックアクセスを許すポリシーが設定済みのバケットへアクセス不可

上記の1および2に関してはACLを対象としたもので、3および4はバケットポリシーおよびアクセスポイントポリシーを対象とした設定です。
1および3については既に設定済みのACL、各ポリシーには影響を与えません。つまり、現在パブリックアクセスが許可されているスコープに対しては継続的にパブリックアクセスを許可します。設定されているACL、各ポリシーが正しい状態であり、動的に変更しないものである場合、これらを適用することによるデメリットはなく、誤設定を防止できるというメリットのみを享受できます。ACL、各ポリシーに誤りがある場合は変更操作も拒否されてしまうため注意が必要です。また、ACLや各ポリシーを動的に変更することがあればBPAは適用できません。
2および4については現在設定されているACL、各ポリシーに対しても影響を与えます。2および4についてはバケットと同アカウントの認証ユーザーからのみのアクセスに制限され、クロスアカウントアクセスも遮断されます。
図に起こすと以下のようになります。

なぜ古いアカウントでは有効化しづらいのか

BPAを一括有効化すると、次のようなシステムでアクセス不可による障害に発展する可能性があります。

アップロード時に `--acl public-read` を付与
バケット作成時に `--acl public-read` を指定
静的ウェブサイトホスティングを直接利用
クロスアカウントアクセスをACLで制御

関連製品

CSPM/ASMサービス「クラウドパトロール」の詳細はこちら

安全にBPAを有効化する手順

以下の手順で現状の把握から設定の適用まで行い、パブリックアクセスによる意図しない情報公開、情報漏えいの危険性を下げることができます。

現状の把握

aws s3api get-bucket-policy-status / get-bucket-acl で公開状況を確認
IAM Access Analyzer for S3 / Security Hub で確認

アップロード方式の見直し

public-read / public-read-write / authenticated-read といったACL指定を使うものがあるか確認する
認証付きアップロード（IAM 権限・署名付き URL）に統一する

公開しなければいけないリソースの配信経路を移行

CloudFront + OAC に切り替え、S3 は非公開にする

段階的にBPAを有効化し、影響を観察しながら適用

既存バケットへBlockPublicAclsを適用
既存バケットへBlockPublicPolicyを適用
既存バケットへIgnorePublicAclsを適用
既存バケットへRestrictPublicBucketsを適用
アカウント全体においても同様の順番で適用

関連製品

CSPM/ASMサービス「クラウドパトロール」の詳細はこちら

パブリックアクセスによる公開が必要な場合

ここまでパブリックアクセスとBPAについて説明してきましたが、パブリックアクセスによる公開が必要な場合、BPAを有効化するとS3単体でのオブジェクト公開や静的ウェブサイト公開ができないため、CloudFront + OAC (Origin Access Control) を利用する構成が推奨されています。

※参考：https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#create-oac-overview-s3

構成上、CloudFrontをデプロイすることによる費用増となりますが、公開するオブジェクトへのアクセス頻度が多い場合やファイルサイズが大きい場合は、CloudFrontのキャッシュ機能で費用減となるケースもあります。

参考）
簡易シミュレーション（100万リクエスト/100GB 転送）
S3直接公開: 約 $11.8/月
CloudFront経由: 約 $12.1/月

関連製品

CSPM/ASMサービス「クラウドパトロール」の詳細はこちら

アップロードはどうなる？

BPAを有効化しても、認証付きのアップロード（PUT/POST）には影響しません。
ブロックされるのは、公開ACLを伴うアップロードや匿名書き込みです。
そのため、現在のシステムやユーザーが「認証つきの正規手順」でアップロードしている限り、BPA有効化によってアップロードが止められることはありません。

関連製品

CSPM/ASMサービス「クラウドパトロール」の詳細はこちら

まとめ

BPAはS3に対するパブリックアクセスを制御するための機能であり、現在はデフォルトで有効化されていますが、古いアカウントでS3を作成していた場合はデフォルト有効となっておらず、有効化するために調査と段階を踏んだ適用が必要であることをご説明しました。
バケットポリシーが適切に設定できていればBPAを有効にしても影響は出ませんが、バケットポリシーの設定は不適切な設定を行ってしまうと、rootユーザーしかアクセスできなくなることもあります。設定次第ではとても複雑な条件設定もできるため、サンプルを鵜呑みにせず要求仕様に応じて適切に設計および設定することを推奨します。
当社サービスのCSPM/ASMサービス「クラウドパトロール」では、アカウント内のS3リソースの棚卸しや設定状況の確認を行うことが可能です。
BPAは現在の設定値だけでなく、今後運用していくにあたっての誤設定防止にも役立ちます。実体験としてはAWS初心者が生成AIを使ってAWS S3ストレージを取り扱った怖い話にも記載しておりますのでご確認いただけると幸いです。

関連製品