こんにちは！インフラやセキュリティの世界へようこそ。
新しいシステムの開発やクラウド環境の構築、毎日ワクワクしながらも「本当にこれでセキュリティは大丈夫かな…？」と、ちょっと不安になることはありませんか？
今回は、クラウドの世界（AzureやGCP）で使われる「クラウドネイティブなファイアウォール（Azure Firewall / GCP Cloud Firewall）」と、その中でも特に大切な「FQDNフィルタリング」について、身近な防犯の仕組みに例えながら、一緒に優しく紐解いていきたいと思います。
一歩ずつ、確実にセキュリティのコツを掴んでいきましょうね！
—
1. 家の防犯に例えて理解する「クラウドの境界防御」
まずは、私たちが普段暮らしている「お家」を想像してみてください。
頑丈な玄関のドアには鍵をかけますよね。さらに、マンションならオートロックがあり、不審者が簡単に建物に入れないようになっています。これが、従来のオンプレミス（自社サーバー）における「社内ネットワークの境界を守るファイアウォール」です。
しかし、クラウド（AzureやGCP）の世界はどうでしょう？
クラウド上のサーバーたちは、世界中のどこからでもアクセスできる「広大なインターネットという大草原」の中にぽつんと建っているようなものです。玄関の鍵（従来のIPアドレス制限）だけでは、こんな問題が起きます。
- 「あの怪しい悪党（攻撃者のサーバー）のIPアドレスは分かったからブロックしよう！」
- ──でも、攻撃者はすぐに別の新しい家（新しいIPアドレス）を借りて、平然と攻撃を続けてきます。これではイタチごっこですよね。
そこで登場するのが、今回主役となる「FQDNフィルタリング」と「集中管理型ファイアウォール」です。
—
2. FQDNフィルタリングってなに？（住所ではなく「宛先の名前」で縛る技術）
IPアドレスが「家の緯度・経度（数字の住所）」だとすれば、FQDN（Fully Qualified Domain Name）は「〇〇株式会社のビル」といった「建物の名前（ドメイン名）」です。
例えば、皆さんの開発したクラウドサーバーが、外部の便利なAPIサービス（例: api.example.com）や、OSのアップデートをダウンロードするために特定の安全なサイトへ通信するとします。
従来のIPアドレスによる制限だと、そのAPIサービスが裏側でサーバーの引越し（IPアドレスの変更）をした途端に、通信ができなくなったり、逆にセキュリティの穴が生まれたりしていました。
しかし、FQDNフィルタリングを使えば、こう指示できます。
「うちのサーバーから外に出ていいのは、許可された名前（FQDN）の場所だけ！それ以外への宛先は、どんなにIPアドレスが綺麗に見えても一切シャットアウト！」
これは、お家の郵便受けに「〇〇郵便局からの手紙以外は、すべて受け取り拒否！」と名前で指定するようなものです。泥棒が差出人の名前を偽って手紙を送ろうとしても、名前がリストになければ門前払いできますよね。
—
3. Azure / GCPでの実践：ポリシー設定の具体例
それでは、実際のクラウド環境でどのように設定するのか、雰囲気を覗いてみましょう。小難しい設定に見えるかもしれませんが、考え方はとってもシンプルです。
Azure Firewall の場合（アプリケーションルール）
Azureでは、IPアドレスだけでなく「ドメイン名（FQDN）」を指定して通信をコントロールする「アプリケーションルールコレクション」という機能を使います。
{
"ruleCollectionName": "Allow-Safe-Updates-And-APIs",
"action": {
"type": "Allow" // 通信を許可する
},
"rules": [
{
"name": "Allow-OS-Updates",
"sourceAddresses": [
"10.0.1.0/24" // 社内・クラウド内の特定のサブネット（出発地）
],
"targetFqdns": [
"*.ubuntu.com", // Ubuntuの安全なアップデートサーバーのドメイン
"download.microsoft.com" // Microsoft公式のダウンロードサイト
],
"protocols": [
{
"protocolType": "Https",
"port": 443
}
]
}
]
}この設定では、「10.0.1.0/24 という部屋にいるサーバーたちは、安全が確認されたアップデート用ドメイン（*.ubuntu.com など）にだけ、HTTPS（ポート443）で外へお出かけしていいよ」と許可しています。これ以外への寄り道はすべて禁止されます。
—
GCP Cloud Firewall の場合（階層型ファイアウォールポリシー）
GCPでは、プロジェクトごとにバラバラになりがちなファイアウォール設定を、組織全体で一元管理できる「階層型ファイアウォールポリシー」が強力な武器になります。
GCPのコンソールや gcloud コマンドを使って、組織全体に適用するルールを書くイメージを見てみましょう。
# 組織全体に適用するファイアウォールルールの作成例
gcloud compute firewall-policies create "corp-global-security-policy" \
--organization="123456789012" \
--description="組織全体の通信をガバナンスするための集中管理ポリシー"
# 外部への不正な通信をブロックし、特定のFQDN/FQDNグループのみを許可するルールを追加
# （※GCPではSecure Web ProxyやCloud FirewallのFQDNベースの拡張機能を組み合わせて制御します）現場でありがちな失敗は、「プロジェクトAの担当者は自由にファイアウォールを緩くしてしまったが、プロジェクトBの担当者は厳しくしていた」というルールのバラつき（ガバナンスの欠如）です。
集中管理型ファイアウォールを使えば、セキュリティチームが「全社一律の強力な鍵」を上からガッチリかけることができるため、新人の開発者うっかりミスを防ぐことができます。
—
4. 現場のインシデントから学ぶ「落とし穴」
ここで、実際の現場で私がよく目にする「ちょっと痛い失敗談」をシェアしますね。
ある開発チームが、新しいマイクロサービスをクラウド上で立ち上げました。彼らは「セキュリティを頑張ろう！」と意気込み、ファイアウォールで外部への通信をすべてブロックしました。
しかし、アプリを動かしてみると……動かない！
原因を調べると、アプリが利用している外部の決済代行サービスが、内部で参照しているCDN（コンテンツ配信ネットワーク）のドメインや、裏側のIPアドレスをこっそり変更していたのです。
慌てた開発者は、面倒になって一時的にファイアウォールの制限を 0.0.0.0/0（どこへでも通信OK）に戻してしまいました。……これでは、せっかくの要塞化が台無しですね。
対策はどうすればよかったのか？
1. FQDNフィルタリングを正しく活用する：宛先がIPアドレスではなくドメイン名で変わる可能性がある場合でも、FQDNベースであればワイルドカード（*.payment-gateway.comなど）を使って柔軟かつ安全に追従できます。
2. ログを監視する：Azure Firewallなら「Log Analytics」、GCPなら「VPCフローログ」や「ファイアウォールルールロギング」を有効にし、「今、どのサーバーがどこへ行こうとしてブロックされたか」を常に可視化しておきます。
—
まとめ：一歩ずつ、セキュアなクラウド環境へ
いかがでしたでしょうか？
クラウドネイティブなファイアウォールやFQDNフィルタリングは、最初は難しく感じるかもしれませんが、要するに「信頼できるお友達（ドメイン）の名前だけをリスト化して、それ以外は一切通さない強力な門番」をクラウド上に置くということです。
新人のIT担当者や開発者の皆さんが、こうした仕組みを少しずつ理解し、日々のインフラ構築に組み込んでいくことで、企業のセキュリティは劇的に強固になります。
焦らず、一つひとつの設定の意味を確かめながら、安全で快適なクラウドライフを作っていきましょう！応援しています！
コメント