ファイアウォール
読み: ファイアウォール
ファイアウォールとは通信を防御
ファイアウォールはネットワークの境界に設置され、通過する通信を事前に定めたルールに基づいて許可または遮断するセキュリティ装置。外部からの不正アクセスを防ぐ最も基本的な防御手段であり、企業ネットワークの入口に必ず配置される。
かんたんに言うと
会社のネットワークの玄関に立つ門番のようなもの。「この通信は通してよい」「この通信は怪しいから止める」と、あらかじめ決められたルールに従って判断する。
パケットフィルタリングからステートフル検査への進化
最も古くから使われているのがパケットフィルタリング型である。通信の送信元IPアドレス、宛先IPアドレス、ポート番号を見て、許可リストに合致するかどうかだけで判断する。仕組みが単純なため処理速度は速いが、通信の中身までは見ない。
ステートフルインスペクション型はもう一歩進んで、通信の「状態」を追跡する。たとえば、社内のPCから外部サーバーに接続を開始した通信は、その応答パケットも自動的に許可する。1990年代にCheck Point社が商用化してから業界標準になった。
ただし、どちらもHTTPの中身、つまりWebアプリケーション層の攻撃には対応できない。SQLインジェクションやクロスサイトスクリプティングは正規のHTTP通信に見えるため、ポート番号やIP制御だけでは止められない。
WAFと次世代ファイアウォールの守備範囲
WebアプリケーションファイアウォールはHTTPリクエストの中身を解析し、悪意のあるパターンを検出して遮断する。ECサイトや会員制サービスなど、Webアプリケーションを公開している企業にとっては不可欠な存在になっている。
次世代ファイアウォールはさらに広い範囲をカバーする。アプリケーション識別、侵入防止、マルウェア検知、SSL通信の復号と検査までを1台でこなす。Palo Alto NetworksやFortinetの製品がこの分野では広く採用されている。
とはいえ、次世代ファイアウォールを入れれば安心かと言えば、そうでもない。暗号化されたC2通信やゼロデイ攻撃には依然として弱い。複数の防御層を組み合わせる多層防御の考え方が前提になる。
クラウド環境でのファイアウォール設計
オンプレミスでは物理的なアプライアンスをネットワークの境界に置けばよかった。クラウドに移行すると、そもそも「境界」の定義が曖昧になる。
AWSならセキュリティグループとネットワークACLがファイアウォールの役割を担う。セキュリティグループはインスタンス単位で適用され、ネットワークACLはサブネット単位で制御する。Azure NSGやGCP Firewallも基本的な考え方は同じである。
マルチクラウド環境ではクラウドごとにファイアウォールの設定体系が異なるため、Terraform等のIaCツールで一元管理しないと設定の不整合が起きやすい。本番環境のセキュリティグループを手動で変更して、意図しないポートが開いたまま放置されるという事故は珍しくない。
<a href="/ai-glossary/zero-trust/">ゼロトラスト</a>時代のファイアウォールの位置づけ
ゼロトラストは「社内ネットワークも信頼しない」という前提に立つ。従来のファイアウォールが「社外は危険、社内は安全」という境界防御モデルで機能していたのに対し、ゼロトラストでは通信の発生場所に関係なく毎回認証と認可を行う。
ではファイアウォールは不要になるのか。結論としては、補完関係にある。ゼロトラストがアイデンティティとアクセス制御を軸に防御するのに対し、ファイアウォールはネットワーク層で不要な通信を事前に遮断する。両方を組み合わせることで、攻撃者が突破しなければならない壁が増える。
実務では、ゼロトラストの導入が進んでいる企業でも、ファイアウォールを撤去した事例はほとんどない。段階的にゼロトラストの仕組みを導入しながら、ファイアウォールのルールを徐々に簡素化していくのが現実的な進め方になっている。
運用で見落としやすい落とし穴
ファイアウォールは導入して終わりではない。運用で最も多いミスはルールの肥大化である。
年月が経つにつれて「一時的に開けたポート」「退職者が使っていたVPN用ルール」「テスト用に追加したany許可」が放置され、誰もルールの全体像を把握できなくなる。ルール数が1,000を超えると、どのルールが実際に使われていてどれが死んでいるのか判別が困難になる。
定期的なルールの棚卸しと、未使用ルールの検出は必須の運用タスクである。Tufin、FireMonといったファイアウォール管理ツールはルールの可視化と最適化を支援してくれるが、最終的にルールを削除する判断は人間がやるしかない。「消して問題が起きたらどうしよう」という恐怖で誰も手を付けられない、というのが現場のリアルな姿である。
当社の見解
当社はAIの安全運用のために3層防御を設計・実装している。万が一インシデントが発生しても数分以内に復旧できるバックアップ体制を持つ。実際にAIが暴走してテスト環境を停止させた経験があり、その教訓から「失敗を防ぐ」だけでなく「失敗しても戻せる」設計が本質だと確信している。加えて、AIは事実でないことを断定する。この前提で事実/推測の強制分離とファクトチェックを実装した。安全性は仕組みで担保するものだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。