【クラウド資産偵察編】S3・ECR・メタデータの覗き穴|CTF思考フレームワーク R09
こんにちは、アンペンです!偵察ルートR09はクラウド資産編。S3バケット・コンテナレジストリ・メタデータサービスといった『クラウド特有の入口』を扱います。サーバが頑丈でも設定一つで中身が丸見えになる——クラウドならではの攻撃面を読み解きます。
『クラウドは大手が守ってくれるから安全』——半分は本当で、半分は危険な思い込みです。たしかに建物(基盤)は事業者ががっちり守ってくれます。でも、部屋の鍵をどう設定するか、何を置くかは“利用者の責任”。これを『責任共有モデル』と呼びます。つまり、いくら頑丈なビルでも、住人が鍵を開けっ放しにしていたら中身は丸見え。クラウドの事故の多くは、ハッキングではなく、この“設定の緩み”から起きているんです。

クラウドって安全なんじゃないの?大手が守ってくれてるんでしょ?

基盤は強い。でもクラウドは責任共有モデル——基盤はクラウド事業者、設定とデータは利用者の責任なんだ。S3バケットの公開設定ミスでファイルが丸見え、なんて事故は今も世界中で起きてる。だから偵察側は『設定の緩み』を、守る側は『既定で閉じる』を見るんだ。
クラウド資産の偵察とは「クラウド特有の入口の設定ミスを探すこと」。要は3系統——①ストレージバケット(S3/GCS/Blob)の公開設定、②コンテナ/レジストリに焼き込まれた認証情報、③メタデータサービス(IMDS:169.254.169.254)からの一時認証情報漏れ。とくにIMDSはSSRFと組むと一時キーを奪われ権限奪取に直結する。クラウドは責任共有モデルで、設定とデータは利用者の責任。守る側は『Block Public Accessを既定ON+IMDSv2強制+イメージにシークレットを焼かない+最小権限と短命トークン』。
この記事で分かること
- クラウド特有の攻撃面3系統(バケット/レジストリ/メタデータ)
- S3公開設定ミスでなぜファイルが丸見えになるか
- IMDSとSSRFが組むとなぜ権限奪取に直結するか
- 責任共有モデル——どこからが利用者の責任か
- 守る側の「既定で閉じる」チェックリスト
📖 はじめてのWebセキュリティR09|クラウド資産編
クラウド特有の入口を読み、設定の緩みを先回りで閉じる。 シリーズ一覧を見る →
⚠️ 大事なお約束
他人のクラウドアカウントやバケットへのアクセスは不正アクセス禁止法に直結します。本記事の手法は自分が作ったテスト環境・CTF・書面で許可された調査に限定してください。匿名アクセスできるバケットでも、無断で中身を取得すれば違法です。「できる」と「やってよい」は全く別です。
クラウド特有の攻撃面:3系統
- ①ストレージバケット:S3/GCS/Azure Blobの公開設定ミス。バケット名は
company-backupのように推測されやすく、公開ACLだと匿名でファイル一覧・ダウンロードが可能になる - ②コンテナ/レジストリ:公開Dockerイメージや各レイヤーに焼き込まれた認証情報。ECRやDocker Hubの公開リポジトリに、privateのつもりのイメージが出ていることも
- ③メタデータサービス(IMDS):
169.254.169.254。インスタンスに紐づく一時認証情報を返す内部専用エンドポイント。SSRFで踏まれるとキーが盗まれ、クラウド全体へ横展開される
3つを一言で押さえると、バケットは『置きっぱなしのファイルが公開される』、レジストリは『イメージに鍵が焼き込まれる』、メタデータは『内部専用の合鍵が外に漏れる』。どれも“サーバを破る”話ではなく、“設定や置き場所のうっかり”が原因です。クラウドの偵察は、難しい攻撃というより『緩んだ設定を探す宝探し』に近い、と思っておくと理解しやすいですよ。

ここで覚える用語:S3バケットと公開設定(Public Access)
意味:S3バケットはAWSのオブジェクトストレージの「入れ物」。バケットポリシーやACLで公開範囲を決めますが、設定を誤ると誰でも匿名で読める状態になります。
例:company-dev-backupがpublic-read設定→aws s3 ls s3://company-dev-backup --no-sign-requestで認証なしにファイル一覧が見えてしまう。
使いどころ:守る側はアカウント全体でBlock Public Accessを既定ONにし、公開は例外として個別承認制に。バケット名にも推測されにくい乱数を混ぜます。
なぜクラウドは「設定」で漏れるのか
クラウドは巨大な貸倉庫ビルです。建物自体(=基盤)は事業者が頑丈に守ってくれます。でも各部屋の鍵設定(=バケットポリシー)はあなたの責任。うっかり「誰でも開く」のまま放置すれば、部屋の中身は丸見えです。さらに厄介なのが管理人室のインターホン(=メタデータサービス)。本来は内部の人専用ですが、配達員(=SSRFを起こすWebアプリ)に「代わりに押して」と頼めると、合鍵(=一時認証情報)がポロッと出てきてしまう。建物が頑丈でも、鍵設定の緩みと内部インターホンの油断で中身は漏れる——これがクラウド特有の攻撃面です。

3系統の中でも、断トツで“事故ったときのダメージが大きい”のが、次に扱うメタデータサービスです。バケットの公開ミスは『そのファイルが見られる』で済みますが、メタデータが漏れると『クラウドアカウントの合鍵そのもの』を奪われる。被害の桁が一つ違うので、ここだけは特に丁寧に見ていきます。
メタデータサービスとSSRF:一番危険な連鎖
クラウド偵察で最も重い結果につながるのがメタデータサービス×SSRFの組み合わせです。Webアプリに「指定URLを取りに行く」機能があり、そこに内部アドレスを差し込めると、本来外から触れないはずの一時認証情報が引き出せてしまいます。ここを理解すると、なぜIMDSv2という改良版が必須なのかが腑に落ちます。
SSRFという言葉が出てきました。ざっくり言うと、『サーバに“このURLを取ってきて”と頼める機能を悪用して、本来アクセスできない内部アドレスを代わりに叩かせる』攻撃です。たとえばWebアプリの“画像URLを入力してプレビュー”という親切機能。ここに内部の 169.254.169.254 を入れさせると、アプリが律儀にそこへ取りに行き、一時認証情報を“代理で”持ってきてしまう。配達員に『管理人室のインターホン、代わりに押してきて』と頼むようなものです。だからこそ、内部宛てのリクエストは最初から遮断するのが鉄則になります。
ここで覚える用語:IMDSとSSRF
意味:IMDS(Instance Metadata Service)はクラウドのインスタンスに、自分の情報や一時認証情報を返す内部エンドポイント(169.254.169.254)。SSRF(Server-Side Request Forgery)は、サーバに任意のリクエストを代理送信させる脆弱性です。
例:WebアプリのSSRF→http://169.254.169.254/latest/meta-data/iam/security-credentials/を読ませる→一時キーを奪取→S3やDBへアクセスし権限を横展開。
使いどころ:守る側はIMDSv2(トークン必須・ホップ制限1)を強制し、IMDSv1を無効化。さらにSSRF自体を塞ぎ、内部IPへの送信を遮断します。
CTFでやってみよう:自分のクラウドで設定差を体感
「設定一つで見え方がどう変わるか」を手を動かして確かめる
対象は必ず自分が作ったテスト環境かCTFです。攻撃者が見る順で、自分のクラウド設定の緩みを先回りで点検します。各ステップに「なぜやるか」を添えました。
- 自分のテスト用S3バケットに
aws s3 ls s3://名前 --no-sign-request→ なぜ:匿名アクセスの可否を体感するため - Block Public AccessのON/OFFで挙動の差を観察 → なぜ:既定で閉じる重要性を知るため
cloud_enum/s3scannerで自分の命名のバケット可視性を確認 → なぜ:推測されやすい命名の危険を知るため- 自分の公開テストDockerイメージをDLし
docker historyでレイヤー確認 → なぜ:イメージに何が残るか見るため trufflehogでイメージ内のシークレットを走査 → なぜ:レイヤーに鍵が残る実感を得るため- 自分のテストインスタンスでIMDSv1とv2の応答差を確認 → なぜ:v2強制の効果を知るため
- SSRF練習用CTFでメタデータ読み出しの連鎖を体験 → なぜ:権限奪取の流れを理解するため
- CloudTrail等の監査ログに自分の操作が残るか確認 → なぜ:検知の仕組みを知るため
では守り方ですが、合言葉はたった一つ、『既定で閉じる』です。攻撃面のほとんどは“うっかり開けっ放し”が原因なので、最初から全部閉じておいて、必要なものだけ意識して開ける。この順番にするだけで、事故は激減します。次のチェックリストも、すべてこの『デフォルトで閉じる』という発想で並んでいます。
守る側:既定で閉じる
- Block Public Accessを既定ON:公開は例外として個別承認制にする
- バケット名に乱数を混ぜる:
company-backupのような推測されやすい命名を避ける - IMDSv2を強制:トークン必須・ホップ制限1。IMDSv1は無効化する
- SSRF対策:内部IP(
169.254.169.254等)へのリクエストをアプリ側で遮断 - イメージにシークレットを焼かない:ビルド時マウントやSecrets機能を使う
- 公開レジストリへの誤公開を防ぐ:privateイメージの公開設定を定期監査
- 最小権限IAM+短命トークン:万一漏れても被害範囲と時間を限定
- CSPMで設定を自動監査:公開バケット・過剰権限を継続検知する


基盤が強くても「設定」で漏れるんだね。既定で閉じるのが大事って腑に落ちたよ。

その通り!クラウドは『設定が境界線』だよ。次はR10、パッシブ偵察総まとめ編。R01〜R09で学んだ受動的な偵察を一本の地図に束ね、攻撃面管理(ASM)の発想で締めくくるよ。
まとめ:クラウドは『設定が境界線』
- クラウドの攻撃面はバケット・レジストリ・メタデータの3系統
- S3公開設定ミスで匿名にファイルが丸見えになる
- IMDS×SSRFは一時キー奪取→権限横展開に直結
- クラウドは責任共有モデル——設定とデータは利用者の責任
- 守りは既定で閉じる・IMDSv2・シークレットを焼かない・最小権限
今日の持ち帰りは『クラウドは設定が境界線』。攻撃者はサーバの脆弱性より先に、“開けっ放しのバケット”や“弱いIMDS”といった設定の緩みを探します。だから守りの第一歩は、攻撃者と同じ目で自分のクラウドを点検し、『開いているもの』を洗い出すこと。頑丈な基盤に乗っていても、鍵をかけるのは自分の仕事なんです。
次はR10、パッシブ偵察総まとめ編。R01〜R09の受動偵察を束ね、攻撃面を継続的に管理する発想で締めくくります。
