GCPの「階層型ファイアウォール」で、セキュリティ管理の迷路から脱出しよう！
こんにちは！SRE兼クラウドアーキテクトの筆者です。
クラウドインフラの世界に飛び込むと、最初に出会う大きな壁のひとつが「ネットワークの制御」です。「どのサーバーに、誰が、どこからアクセスできるのか？」を管理するファイアウォール。最初は数台のサーバーなら手作業でもなんとかなりますが、プロジェクトが増え、システムが巨大化してくると、あちこちにルールが散らばり、「今、どのルールが優先されているんだっけ？」とパニックになることはありませんか？
そんな状況を救ってくれるのが、GCP（Google Cloud）の階層型ファイアウォールポリシー（Hierarchical Firewall Policies）です。今回は、この強力な仕組みを、私たちの身近な「郵便配達」に例えて紐解いていきましょう！
—
そもそも「階層型」ってどういうこと？
想像してみてください。あなたは巨大なマンションの管理人です。
- 組織（Organization）: マンション全体
- フォルダ（Folder）: 各フロア
- プロジェクト（Project）: 各部屋
もし、マンション全体で「怪しい訪問者はシャットアウト！」というルールを決めたいとき、全戸のドアに個別に張り紙をしますか？そんなの面倒ですよね。
GCPの階層型ファイアウォールは、「入り口（組織レベル）で全体ルールを決め、あとは下の階層で細かいルールを足していく」という、非常に理にかなった仕組みなんです。
継承という名の「お墨付き」
階層型ポリシーの最大の特徴は「継承（Inheritance）」です。
上のレベルで「この通信は禁止！」と決めたルールは、下のプロジェクトに自動的に引き継がれます。個別のプロジェクトでいちいち同じ設定を書く必要はありません。これが、セキュリティの「統制」というやつです。
—
パケットの気持ちになって考えてみる
ネットワークの世界では、パケットという「手紙」が常に飛び交っています。
1. 組織レベルの検問: 「まず、マンションの門番がチェック！」（全プロジェクト共通のセキュリティ）
2. フォルダレベルの検問: 「次に、フロアの管理人さんがチェック！」（部署ごとのルール）
3. プロジェクト（VPC）レベルの検問: 「最後に、部屋のドアマンがチェック！」（個別のアプリごとのルール）
このように、上から順にパケットを検査していくことで、上位の管理者が決めた「安全基準」を、下位のプロジェクトが勝手に破れないようにすることができます。これが企業レベルでのセキュリティガバナンスにおける最強の武器になります。
—
さっそく設定してみよう：コマンドの基本
では、実際に組織レベルで「SSH（ポート22番）の通信を全プロジェクトで制限する」といったポリシーを作ってみましょう。gcloud コマンドを使えば、直感的に操作できます。
# 1. 組織レベルでファイアウォールポリシーを作成する
gcloud compute network-firewall-policies create "global-security-policy" \
--global \
--description="全プロジェクト共通のセキュリティガードレール"
# 2. ルールを追加する（例：特定のIP以外からのSSH接続を拒否する）
gcloud compute network-firewall-policies rules create 100 \
--firewall-policy="global-security-policy" \
--global-firewall-policy \
--action="deny" \
--direction="INGRESS" \
--src-ip-ranges="0.0.0.0/0" \
--layer4-configs="tcp:22" \
--priority=1000 \
--description="全プロジェクトでSSHを制限する"ポイント解説
--priority: 数字が小さいほど優先されます。郵便配達で例えるなら、数字が小さいルールほど「最優先の特急便」として扱われます。--action="deny": これが強力です。「拒否」ルールを上位で設定すれば、下のプロジェクトでどんなに「許可」設定をしても、上位の「拒否」が優先されるケース（オーバーライド）を制御できます。
—
なぜSREは「階層型」を推すのか？
現場のSREとして、なぜ私がこの機能を推すのか。それは、「後からやってくる開発者やエンジニアが、知らず知らずのうちに穴を開けるのを防げるから」です。
プロジェクト単位でファイアウォールを管理していると、誰かがテストのために「とりあえず全開放（0.0.0.0/0）」なんて設定を入れがちです。しかし、組織レベルで「階層型ポリシー」を適用しておけば、そんなミスも未然に防ぐことができます。
- 一元管理: 設定場所が1箇所に集約されるので、監査が圧倒的に楽になる。
- ガードレール効果: 開発者が自由に設定しても、上位ポリシーが「それはダメ！」とガードしてくれる。
—
まとめ：一歩ずつ理解を深めよう
最初は「階層？継承？難しそう…」と感じたかもしれません。でも、「マンション全体（組織）のルールと、各部屋（プロジェクト）のルールを分ける」と考えれば、これほど便利なものはありません。
1. まずは、最も重要な「全プロジェクト共通の禁止事項」を組織レベルで定義する。
2. その次に、プロジェクトごとの細かい設定をVPCのファイアウォールで行う。
この2段構えを意識するだけで、あなたのクラウド環境は格段に堅牢になります。まずは小さなポリシーから試して、その「守られている安心感」をぜひ体感してみてください！
これからも、インフラの泥臭い悩みや、現場で使える知恵を分かりやすくお届けしていきます。それでは、次回の記事もお楽しみに！
コメント