ファイアウォール機器の活用を最大化する：高度なセキュリティ対策

デフォルト設定を超えて

デフォルトのファイアウォール設定は、システムを迅速かつスムーズに起動させるという明確な目的で設計されています。しかし、それはあくまで出発点であり、最終的な状態ではありません。ほとんどのファイアウォール機器に同梱されるデフォルトルールセットは、多様な環境で動作することを前提としています。つまり、セキュリティよりも接続性を重視しており、初期導入を容易にするために広範なアクセスを許可しています。これらの設定をそのまま放置すると、不必要なセキュリティリスクが生じます。

ファイアウォールの効果を最大限に引き出すには、デフォルト設定を超えて考える必要があります。つまり、保護対象となるネットワークの具体的なトラフィックパターンを理解し、それに応じてルールを細かく調整することです。また、「最小権限の原則」を単なる理論ではなく実践に移すことも重要です。つまり、明示的に必要とされるものだけを許可し、それ以外はすべて拒否するという運用です。こうした取り組みにかかる労力は、得られるセキュリティ向上に比べればごくわずかです。

ルールセットの「衛生管理」：蓄積された不要なルールを整理する

ファイアウォールのルールセットは、時間とともに自然に肥大化していく傾向があります。たとえば、ベンダー訪問のための一時的なルールが恒久化したり、新アプリケーションのテスト用に追加されたルールが、そのアプリケーションが本稼働した後も長期間残り続けたりします。例外ルールが次々と積み重なり、それぞれが複雑さと潜在的なリスクを増幅させます。その結果、誰も全体を完全に把握できず、必要以上に多くの通信を許可してしまうルールセットが出来上がってしまうのです。

この問題に対処するには、定期的なルールセットの見直しが有効です。手順はシンプルで、現在のルールセットをエクスポートし、各ルールが実際にどのような機能を果たしているかを文書化したうえで、それぞれのルールが依然として必要かどうかを確認し、不要なものは削除または厳格化します。初回の見直しでは、最も大幅な削減効果が得られることが多く、多くの組織でルールの20～30％を削除または統合できることが分かっています。その後の見直しでは、小さな冗長性が蓄積して規模を拡大する前に、それを早期に検出し対応できます。

ログ記録：活用されない診断ツール

ファイアウォールのログには、多くの導入環境で十分に活用されていない豊富な情報が含まれています。許可された接続、ブロックされた試行、ルールにマッチしたすべてのイベントは、それぞれログとして記録されます。これらのログは、通常のトラフィックパターンを記録し、異常な活動を明らかにし、問題が発生した際の証拠にもなります。しかし、多くの組織では、ログ記録を運用上の有効なツールではなく、単なるコンプライアンス対応のチェックボックスと見なしています。

効果的なログ管理は、まず何が記録されているかを理解することから始まります。すべてのイベントに同じ詳細レベルのログが必要なわけではありません。高トラフィック環境で許可された接続をすべて記録すると、ストレージの課題が生じます。一方、ブロックされた接続や異常なイベントのみを記録すれば、オーバーヘッドを抑えつつ、実践的に役立つ情報を得られます。鍵となるのは、適切なログレベルの設定です。つまり、有用であるのに十分な詳細さを持ちながら、管理可能な範囲に収まるよう選択的であること。また、定期的なログレビュー（短時間でも構いません）を実施することで、自動アラートでは見逃されがちな問題を早期に発見できます。

産業用プロトコル検査：ポート番号に基づくルールを越えて

ポート番号に依存する従来型のファイアウォールルールでは、産業用ネットワークを十分に保護できません。攻撃者は、標準のModbusポートであるポート502を経由して悪意あるModbusコマンドを送信できますが、ポート番号のみをチェックするルールでは、そのようなトラフィックを無批判に通過させてしまいます。ファイアウォールは正しいポート番号を認識するだけで、通信内容を検査することなく許可してしまうのです。

プロトコルを理解する機能を備えた産業用ファイアウォールは、産業用プロトコルメッセージの内容を検査します。たとえば、Modbusリクエストの構造、PROFINETのコマンドセット、EtherNet/IPのデータフォーマットなどを正確に把握しています。この知識により、異常な動作を検出できます。具体的には、読み取り専用レジスタへのModbus書き込みコマンド、通常の運用パターンと合わないコマンドの連続実行、あるいは許容されるサイズ制限を超えるメッセージなどです。こうした異常は、設定ミスか、あるいは積極的な攻撃のどちらかを示唆しています。プロトコルを理解する検査機能は、両方のケースを検知します。

IEC 62443規格では、ゾーン間におけるこのような制限付きデータフローの強制を明示的に要求しています。ポートベースのルールでは、この規格の要件を満たすことができませんが、プロトコルを認識した検査（プロトコル・アウェア・インスペクション）であれば可能です。コンプライアンス要件の対象となる組織は、自社のファイアウォール機器がこの機能をサポートしていること、および適切に設定されていることを確認する必要があります。

冗長性とフェイルオーバー：避けられない事態への備え

ファイアウォール機器はいずれ故障します。電源ユニットは劣化します。ファームウェア更新で不具合が発生することもあります。設定ミスにより管理者がアクセスできなくなる場合もあります。問題は「故障が起きるかどうか」ではなく、「故障が起きた際にネットワークが引き続き保護されるかどうか」です。

高可用性構成では、ファイアウォール装置をアクティブ・パッシブ方式またはアクティブ・アクティブ方式でペアリングすることで、この課題に対応します。アクティブ・パッシブ方式では、一方の装置がすべてのトラフィックを処理し、もう一方は待機状態にあります。アクティブな装置に障害が発生した場合、パッシブな装置が即座に引き継ぎ、サービス中断を最小限に抑えます。一方、アクティブ・アクティブ方式では、両装置にトラフィックを分散させることで、負荷分散と冗長性の両方を実現します。

構成作業は決して簡単ではありません。障害発生時のフェイルオーバー時に既存の接続が維持されるよう、状態テーブルを装置間で同期させる必要があります。また、アクティブな装置の変更をルーティングが正しく反映できるよう設定する必要があります。さらに、フェイルオーバーが想定通りに動作することを確認するためのテストも不可欠です。しかし、たとえば深夜2時における電源ユニットの故障といった緊急事態が発生しても、生産が途切れることなく継続されるという成果を得られるため、その労力は十分に報われます。

実際の事例：適切に実装されたリモートアクセス

中規模の都市圏に給水サービスを提供する水道事業体は、機器ベンダーおよび保守契約業者に対してリモートアクセスを提供する必要がありました。当初のソリューションでは、広範なアクセス制御ルールを備えたVPNアプライアンスが使用されており、認証済みユーザーであればOTネットワーク上の任意のデバイスにアクセス可能でした。この方式は機能しましたが、大きなセキュリティリスクを抱えていました。たとえば、ベンダーのアカウントが侵害された場合、制御システム全体への不正アクセスが可能となっていたのです。

当該事業体は、細かいアクセス制御機能を備えたファイアウォール機器を活用して、リモートアクセスのアーキテクチャを再設計しました。各ベンダーには、自社が対応する必要のある特定のシステムのみへのアクセス権が付与されました。また、保守契約業者は、自社が担当する施設に設置された機器のみにアクセスできるよう制限されました。ファイアウォールは、こうした制限をネットワークレベルで強制し、従来のVPNによる認証に加えて、認証済みユーザーが実際に実行可能な操作を制限する承認ルールを補完しました。この新しい構成により、正当な利用者にとっての複雑さを増すことなく、攻撃対象領域（アタックサーフェス）を大幅に縮小することができました。

実際に役立つ監視とアラート

ファイアウォール機器は、調査が必要な事象に注意を向けるため、意図してアラートを生成します。しかし、アラート疲労は現実の問題です。アラートが多すぎたり、質の低いものが多いと、通知が無視され、重大な事象を見逃す結果を招きます。効果的なアラート運用には、適切な調整が不可欠です。つまり、誤検知を減らし、重要な事象を優先し、アラートが適切な担当者に確実に届くようにする必要があります。

まず、アラートを重要度別に分類しましょう。設定変更、管理者によるログイン、重大な障害などは即時の対応が必要です。一方、外部アドレスからの繰り返しのログイン失敗は調査対象ではありますが、真夜中2時に緊急連絡するほどの緊急性はないかもしれません。また、通常とは異なる宛先へのトラフィック急増は、その中間的な位置付けになるでしょう。この分類は、組織のリスク許容度や運用上の制約を反映させる必要があります。24時間稼働の製造現場と、日中のみ運用されるオフィスネットワークでは、アラート要件が明らかに異なります。

定期的なアラートレビュー会議（週1回または月1回）では、個々のアラートだけでは明らかにならない傾向を特定できます。例えば、複数の異なるソースから発生した軽微な重要度のアラートが連続して発生している場合、それは組織的な攻撃を示唆している可能性があります。また、このレビュープロセスを通じて、アラート設定の最適化に向けたフィードバックも得られます。つまり、繰り返し無関係と判明するアラートは、無効化したり、再設定したりすることが可能です。