はじめに
クラウド環境でシステムを構築していると、ほぼ必ず一度は出会う設定があります。ロードバランサ(ELB / ALB など)に紐づくセキュリティグループのインバウンドルールで、送信元(ソース)を 0.0.0.0/0 にする、というものです。
0.0.0.0/0 は「すべてのIPアドレス」、つまり インターネット上のどこからでも接続を許可する という意味です。設定画面上はチェックひとつ、CIDR をひとつ書くだけの作業ですが、この一行が持つ意味は決して小さくありません。
この記事では、「ELB のセキュリティグループで 0.0.0.0/0 を許可してよいのか?」という問いを題材に、
- 前半:そもそも何を許可しているのかという 基礎
- 後半:実務でどう判断するのかという 判断フレーム
の順で、初学者の方にも実務者の方にも役立つように整理していきます。
この記事は特定の案件を扱うものではなく、一般的な設計・運用の考え方を解説するものです。
第1部:基礎編 — 0.0.0.0/0 は何を許可しているのか
セキュリティグループとは何か
セキュリティグループ(Security Group、以下 SG)は、クラウド上のリソースに対する 仮想的なファイアウォール です。「どの送信元から、どのポートへの通信を許可するか」をルールとして定義します。
ここで押さえておきたいのは、SG が制御できるのは基本的に IPアドレス(L3)とポート番号(L4) のレイヤだということです。「このIPからこのポートへは通す/通さない」は判断できますが、「そのHTTPリクエストの中身が攻撃かどうか」までは見ません。中身の検査は後述する WAF などの役割になります。
0.0.0.0/0 の意味
CIDR 表記の 0.0.0.0/0 は、IPアドレス空間の すべて を指します。
| CIDR | 意味 |
|---|---|
203.0.113.10/32 | 特定の1台だけ |
203.0.113.0/24 | 特定の256アドレスの範囲 |
10.0.0.0/8 | 社内などの広い範囲 |
0.0.0.0/0 | 世界中のすべて |
つまり ELB の SG で 0.0.0.0/0 を許可するということは、「このポートについては、地球上のあらゆる場所からの接続を受け付けます」と宣言することに等しいわけです。
「インターネット公開サービスなら当然」なケースもある
ここで大事なのは、0.0.0.0/0 = 即座に悪、ではない ということです。
不特定多数の利用者に提供する公開Webサービス — たとえば一般向けのWebサイトや公開API — を考えてみましょう。利用者が世界中の誰なのか事前には分かりません。この場合、インターネット向け(internet-facing)の ELB で 443番ポート(HTTPS)を 0.0.0.0/0 に開けるのは、むしろ 設計上正しい 姿です。利用者を特定できないのに送信元を絞る方が不自然だからです。
したがって最初の結論はこうなります。
0.0.0.0/0の可否は、それ単体では決まらない。「何を、どんな状況で公開するのか」と「その先の守りが揃っているか」で決まる。
第2部:実務編 — どういうときに立ち止まるべきか
ここからは実務者向けに、セキュリティエンジニア(インシデント対応の観点)として「開放を承認する前に何を確認するか」を掘り下げます。
立ち止まるべき典型パターン
現場でリスクとして指摘したくなるのは、次のようなケースです。
(1) 本来は内部・限定向けなのに公開されている 管理画面、社内ツール、ステージング環境などが、うっかり全開放されているパターン。設定ミス起因のインシデントで非常に多い原因です。「公開サービスだから 0.0.0.0/0」と「内部システムがうっかり 0.0.0.0/0」は、見た目が同じ一行でも意味が正反対です。
(2) ポートが広い / 平文が混ざっている 80番(平文HTTP)、SSH(22)、RDP(3389)、DB系ポートなどが 0.0.0.0/0 で開いているのは明確に危険です。ELB に紐づく SG なら、原則 443 のみに絞るべきです。
(3) 送信元を絞れるのに絞っていない 利用者が特定の企業・拠点・取引先などに限られるなら、0.0.0.0/0 ではなく CIDR やマネージドのプレフィックスリストで絞れるはずです。絞れるのに絞っていないなら、それは是正対象になります。
特に注意したい状況:「防御が完成する前の全公開」
見落とされがちですが、実務でいちばん危ういのが 本命の防御機構がまだ有効になっていない期間に全公開する ケースです。
たとえば「本番稼働時には WAF を導入する設計だが、稼働前の検証・試用の期間だけ、WAF がまだ整っていない状態でインターネット公開したい」という要望はよくあります。一見もっともらしいのですが、これは設計上の前提(WAF ありき)を欠いた状態でアプリを世界に晒すことを意味します。
ここで効いてくるのが、第1部で触れた レイヤの話 です。
- SG が守れるのは L3/L4(IP・ポート)まで
- SQLインジェクション、XSS、認可不備、パスベースの攻撃といった L7(HTTP層)の攻撃は SG を素通りする
- その L7 を守るはずの WAF が未稼働なら、防御層が一枚まるごと空白になる
つまり「WAF が入る前に SG を 0.0.0.0/0 にする」という操作は、本来 WAF が担うはずの防御層が空白のまま、唯一残っている境界制御(SG)を最も緩い状態に設定する ことになります。守りの最終ラインを、一枚欠けたタイミングで全開にするわけです。
アタックサーフェスと時間の関係
インターネットに面したホストは、公開した直後から自動スキャンやボットの探索対象になります。未知の資産が発見され、攻撃試行が始まるまでの時間は、体感よりずっと短いと考えるべきです。
そのため、リスクは 「開放する範囲 × 開放している期間」 でおおよそ増えていくと捉えると分かりやすいです。
- 範囲:
0.0.0.0/0(全世界) vs 特定IPのみ - 期間:数時間 vs 数か月
「全世界 × 数か月」は、エクスポージャの観点でもっとも避けたい組み合わせになります。監視体制がまだ発展途上の検証・試用フェーズなら、なおさらです。
「一時的」という言葉のリスク
もうひとつ実務で繰り返し見るのが、「一時的に開けるだけです」という説明です。
期限・解除条件・棚卸しの責任者を明文化しない「一時的」開放は、運用上ほぼ確実に放置されます。「検証が終わったら閉じる」「WAF が稼働したら閉じる」といったトリガーで 自動的に閉じる設計 にしておかないと、当初の想定を超えて開放状態が恒常化します。これも設定ミス起因インシデントの典型パターンです。
第3部:再利用できる判断フレーム
以上を踏まえ、0.0.0.0/0 開放の可否を評価するときの軸を4つにまとめます。案件を問わず使える形にしてあります。
判断の4軸
- 意図性 — その公開は設計上意図されたものか? それとも運用都合の一時措置か?
- 防御の充足 — L7防御(WAF)・認証・バックエンド分離・監視が、開放と同時に有効になっているか?
- 最小化 — 送信元・ポート・プロトコルが必要最小限に絞られているか? 絞れる相手を絞っていないなら是正対象。
- 期間管理 — 開放に期限・解除条件・責任者があるか?
これらが揃えば、公開向け ELB の全開放は妥当です。欠ける項目があれば、そこが是正・協議の対象になります。とりわけ 「防御層が完成する前」「機微な情報を扱う」「期間が長い」 が重なる場合は、無条件で承認するのではなく、条件付きで協議する落としどころが妥当です。
やむを得ず全公開する場合の補完統制
「どうしても 0.0.0.0/0 が必要」という結論になった場合でも、次の統制を添えることで空白を最小化できます。
- 前段認証(SSO/IdP、最低でも Basic 認証)で未認証トラフィックを早期に遮断する
- ポート/プロトコルの最小化(原則 443 のみ。平文・管理用ポートは閉塞)
- バックエンド分離:背後のコンピュート層の SG を「ELB の SG からのみ許可」に限定し、ELB を経由しない直接到達を不可能にする
- ログと監視の強化(アクセスログ・フローログの取得と検知ルール整備)で、開放期間中の状態を可視化する
- 暫定的な L7 防御:本番 WAF が検証中でも、マネージドルールセットや地理ブロック、レート制限だけでも当てて空白を埋める
- DDoS/レート制限 で大量リクエスト系の被害を緩和する
- 期限の契約化:承認は期限付きとし、解除条件・終了日・棚卸し責任者を明文化して、自動的に閉じる運用にする
まず考えるべきは「送信元の限定」
補完統制の話をしましたが、実務でいちばん低コストかつ確実なのは、そもそも 送信元を絞ること です。
「公開が必要」= 「全世界に公開」ではありません。多くの場合、本当に必要なのは「想定している利用者・検証元に到達できること」だけです。利用者や検証元(外形監視ツールや診断元など)が特定できるなら、その IP を許可リスト化するだけで、L7防御が未完成でも攻撃機会そのものを大きく縮小できます。
「公開しないと検証できない」という要望が来たときは、それが本当に全世界公開を要求しているのか、要件を分解して確かめる。これが実務者としての腕の見せどころです。
まとめ
0.0.0.0/0は「全世界からの接続許可」。公開サービス向け ELB なら妥当な設計であり、それ単体では善悪を決められない。- SG が守れるのは L3/L4 まで。HTTP層(L7)の攻撃は WAF などが担う。WAF が入る前の全公開は、防御層が一枚欠けた状態での全開放になる。
- リスクは「開放範囲 × 開放期間」で増える。「全世界 × 長期間」は避けたい組み合わせ。
- 判断は 意図性・防御の充足・最小化・期間管理 の4軸で行う。
- 迷ったら、まず 送信元を絞れないか を考える。それだけで多くのリスクは下げられる。
セキュリティの設定は、たった一行が大きな意味を持つことがあります。0.0.0.0/0 はその代表例です。「なぜこの範囲なのか」を説明できる状態にしておくこと。それが、公開の可否を判断するうえでの出発点になります。
