ファイアウォールのドメイン許可について

ファイアウォールのアクセス制御は本来 IPアドレス を基準に行われます。

しかし、近年はクラウドサービスやAPI、CDN の普及により、1つのサービスが多数のIPを持ち、しかも動的に変化することが当たり前になりました。

この状況を前提とすると、「固定IPを許可する」という従来の方法では限界があります。

そこで登場するのが ドメイン（FQDN）ベースのフィルタリングです。

なぜドメイン許可が必要なのか

クラウドサービスは IP が固定されない

Microsoft 365、Google Workspace、Slack、ChatGPT API など、ほぼすべてのクラウドサービスは

• グローバルCDN
• Anycast構成
• 負荷分散による動的IP
  を前提に動作しています。

このため、IPアドレスを固定ホワイトリスト化することはほぼ不可能で、サービスが公開するドメイン（FQDN）を許可する手法が必須になります。

ドメイン許可の仕組み：DNS で IP を収集して許可する

FQDNを許可するといっても、ファイアウォールがドメイン名そのものを直接通しているわけではありません。

実際には、

1. FQDN → IP アドレスへ DNS で名前解決
2. 解決された IP をファイアウォール内部のリストへ登録
3. 通信の宛先IPがそのリストに含まれていれば許可する

という仕組みです。

つまり、DNS の動作が非常に大きく影響します。

影響する要素の例

• DNS の TTL
• ファイアウォールのリフレッシュ間隔
• ラウンドロビンで返る IP のバラツキ
• CDN の構成変更

これらの条件が合わないと、「昼間だけ接続できない」などの不安定な挙動が起きます。

製品ごとの FQDN 対応の違い

ファイアウォールには、FQDN を扱う方法にも差があります。

主要製品の傾向は次の通りです。

FortiGate

• FQDN / ワイルドカード FQDN をサポート
• DNSトラフィックを解析し、FQDN の IP を動的に収集する機能を持つ
• 一部機能では「逆引き（IP→ドメイン）」を利用するケースもある

Palo Alto

• FQDNオブジェクトをネイティブにサポート
• 定期的に DNS を引き直し、IPリストを最適化
• クラウドサービス前提の設計が強い

Cisco ASA

• FQDNオブジェクトはACLで利用可能
• ただし、VPN split tunneling など、使えないシナリオが一部存在する

Windows Defender Firewall

• 従来は IP ベースが主流
• 現在は dynamic keywords により FQDN を扱う高度な設定も可能
• ただし一般的な GUI では依然として IP / アプリ中心

製品間の挙動や対応範囲は意外に差があるため、自分のFWが “FQDNの動的更新” に対応しているかが最初の重要ポイントになります。

ワイルドカードFQDN（*.example.com）の注意点

ワイルドカードで一括許可すると便利に見えますが、実際には次のようなリスクがあります。

DNSで問い合わせたサブドメインすべてのIPが蓄積される

FortiGateなどでは
*.service.com を許可すると、クライアントが問い合わせた
a.service.com
b.service.com
c.service.com
…
すべてのIPが徐々に登録されます。

CDNサービスでは広大なIP帯を許可する結果になりやすい

SaaSやCDNが内部で大量のサブドメインを使っている場合、その分だけIPレンジが増えるため、結果的に「許可範囲が広すぎるFW設定」になり得ます。

結論
ワイルドカード許可は極力避け、サービスが公開している正確なFQDNのみ許可するのがベスト。

実運用で起こりがちな問題と対処法

（現象1）特定の時間帯だけ接続が不安定

原因

• DNS の TTL が短い
• FW の更新間隔がTTLより長い
• CDN が時間帯でルーティングを変えている

対策

• TTL を調査し、FW側の「FQDN更新間隔」を合わせる
• ネームサーバーを適切なものに変更する

（現象2）同じサービスの一部だけ繋がらない

原因

• サブドメインごとにCDNが異なる
• APIエンドポイントだけ別IP帯

対策

• dig などで全サブドメインを調査
• 公式ドキュメントのFQDN一覧を確認

（現象3）サービスが突然使えなくなった

原因

• SaaS側のドメイン構造やIPレンジが変更
• 古いFQDNが非推奨になっている

対策

• 半年ごとに許可ドメインリストを棚卸し
• 公式の更新情報を追跡

ベストプラクティス

必ず「サービスの公式ドキュメント」を参照する

Microsoft 365 や Google などは、許可すべきFQDNリストを公式公開しており、最も信頼できます。

FQDNのDNS構造を必ず調査

nslookup
dig
dig +trace
などで、DNSの動きを確認しておくとトラブルを大幅に減らせます。

ワイルドカード許可は最後の手段

セキュリティリスク・運用リスクが大きい。

クラウド向けのFWやSWGを検討

Zscaler
Cloudflare Zero Trust
Cisco Umbrella
などは、FQDN前提の世界で最も安定して動く設計です。

まとめ

ドメイン許可（FQDN フィルタリング）は、クラウド時代に必須の機能ですが、DNS への深い理解がなければ安定動作しません。

重要ポイントをまとめると、

• FQDN → DNS → IP の仕組みで動作する
• TTL とFWの更新間隔が安定性を左右する
• 逆引きやDNS解析を利用する製品もある
• ワイルドカードFQDNは慎重に取り扱う
• 公式ドメインリストを必ず参照
• 半年に1回は棚卸しする
• 必要に応じてクラウド型FW/SWGも選択肢に入れる

この理解があるだけで、ファイアウォール設定の品質は大きく向上します。

以上、ファイアウォールのドメイン許可についてでした。

最後までお読みいただき、ありがとうございました。