動的な世界における静的なルール：アセットベースのセキュリティという選択

Zero Trust は、脅威や変化、そして予測不能な事態に適応するために役立つはずのものです。しかし問題があります。ほとんどのポリシーは、そうした事態を想定して作られていません。静的で、ハードコードされ、変化が遅すぎるのです。静的ゾーン、固定 IP、常時有効なアクセスルールといったレガシーなネットワーク構成に依然として依存している点ほど、それが当てはまる領域はありません。ワークロードが「チケットのエスカレーション」と口にする間もなく起動し、移動し、消滅する世界において、これらを用いて信頼の判断を下しているのです。Zero Trust の土台に根本的な転換が必要な理由、そしてアセットベースのセキュリティがレガシーポリシーの硬直状態から真の Zero Trust の俊敏性へと橋渡しする理由について、今こそ考えるときです。

レガシーの錨：ゾーン、ネットワーク、そして制御という幻想

IP アドレス、ゾーン、ネットワークセグメントは、現代の環境においてポリシーの拠り所となるように作られたものではありません。これらは、ネットワークが静的で、アプリケーションが同じ場所にとどまり、クラウドといえば気象現象を指していた時代のために考案されました。今日のネットワークは伸縮自在です。コンテナの寿命は数時間。クラウドインスタンスは瞬く間に生成され、消えていきます。アプリケーションコンポーネントは地域、クラウドプロバイダー、信頼ゾーンをまたいで広がっています。その一方で、セキュリティポリシーはどうでしょうか。いまだに固定されたゾーンや IP ブロックにアクセスをマッピングしています。SDN オーバーレイやクラウドネイティブのツールを導入していても、実施レイヤーのポリシーの大半は、ビジネスの実態を反映していない構成に根ざしたままです。その結果は何か。意図と実施の乖離が変更を遅らせ、リスクにさらされる状態を招きます。

速度の不一致：アセットは変化し、ポリシーは変化しない

ゾーンはマクロなレベルでは優れていますが、ゾーンベースのセキュリティアーキテクチャは、アセットやその相互作用の変化に迅速に適応できません。それはネットワークチームの動きが遅いからではなく、ルールがハードコードされ、承認プロセスが硬直的で、あらゆる変更が意図しない影響というパンドラの箱を開けるように感じられるからです。対照的に、アセットそのもの（サーバー、アプリケーション、サービス）とその属性は速く動きます。アセットは絶えず変化します。

• 開発チームがテスト用に新しいコンテナ型サービスを立ち上げる。
• VM にパッチが適用され、リージョンをまたいで移設される。
• SaaS 連携によってアプリ間のデータの流れが変わる。

これらの出来事はいずれもセキュリティ上の影響を伴います。しかし、基盤となるポリシーは追随できません。ファイアウォールの変更は順番待ちとなり、承認は遅れ、ビジネス施策はセキュリティの対応を待たされます。それが誤りだからではなく、プロセスが脆いからです。Zero Trust はここで停滞することが少なくありません。原則の問題ではなく、実践の問題です。固定的な制御で適応的な信頼を実施することはできません。

アセットベースのセキュリティが転換点となる理由

アセットベースのセキュリティは、このモデルを反転させます。アクセスの判断をインフラ（ゾーンや IP など）に紐づけるのではなく、アセットそのもの、すなわちそれが何であり、何をしており、どの程度のリスクを持つのかに紐づけます。アセットがコンテキストとなります。そして Zero Trust においてコンテキストがすべてです。アセットベースのポリシーモデルは、次のような要素を活用します。

• タグ：クラウド、CMDB、インベントリシステムからのメタデータ
• ロール：業務機能またはアプリケーションのグループ
• ポスチャ：リスク指標、コンプライアンス状況、脆弱性に関する知見

これにより、セキュリティチームは次のようなポリシーを定義できます。

• 「データベーストラフィックは、ポスチャが健全で PCI タグが付与されたワークロードからのみ許可する。」
• 「脆弱性の深刻度が高いと示された重要アセットからの外部インターネットアクセスはすべて遮断する。」
• 「管理者ロールには、承認された保守ウィンドウの間のみジャストインタイムのアクセスを許可する。」

これらのポリシーは、アセットがどこに存在するかを問いません。クラウド、オンプレミス、ハイブリッド。いずれでも構いません。重要なのは、アセットのアイデンティティ、目的、状態です。こうして、静的な実施から適応的なガードレールへの移行が始まります。

ギャップを埋める：ファイアウォールがアセットと属性の言語を学ぶべき理由

明確にしておきます。これはファイアウォールを置き換えるという話ではありません。ファイアウォールに新しい言語、すなわちビジネスロジックとセキュリティの意図により近い言語を教えるという話です。今日、ネットワークセキュリティチームは、次のような要求を翻訳する作業を任されることが少なくありません。「新しい分析アプリから本番データベースへの接続を許可してほしい。」 これを次のような形に変換します。「10.42.0.0/16 から 172.19.8.0/24 への TCP ポート 5432 のトラフィックを許可する。」 この変換作業は誤りが生じやすく、時間がかかり、本来のビジネス上の意図から完全に切り離されています。さらに悪いことに、分析アプリが別のサブネットに移動したり、新しいリージョンが立ち上がったりすると、ポリシーは機能しなくなるか、あるいは開いたままになって露出を生み出します。アセットベースのポリシーは、この変換のギャップを解消します。アクセスをビジネスの言葉で記述し、実施システムがリアルタイムのアセット状態とインベントリに基づいて動的に解決します。いわば、ファイアウォールに現代のインフラを読み解くための解読リングを与えるようなものです。

ポリシーというボトルネックから、ビジネスの推進力へ

ネットワークポリシーが動的でアセットを認識するものになると、本質的な変化が起こります。セキュリティはボトルネックではなくなり、ビジネスを推進する存在になります。

• 開発者が手作業によるファイアウォールルール変更を待たされなくなり、俊敏性が高まります。
• 常時有効なアクセスが最小化され、アセットのポスチャの変化にポリシーが適応するため、リスクが低減します。
• 統制が、保護対象のシステムやデータに直接整合するため、コンプライアンスが向上します。

最も重要なのは、セキュリティがビジネスの速度で動けるようになることです。2 四半期遅れではなく。

FireMon の視点：ビジネスの言葉で考えるポリシー

FireMon は 20 年にわたり、セキュリティポリシーの混沌に秩序をもたらす支援を行ってきました。そこで明らかになったことが一つあります。Zero Trust を現実の環境で機能させたいのであれば、ポリシーを固定的なインフラに基づかせることはできず、動的なコンテキストを反映させる必要があるということです。それは次のことを意味します。

• アドレスではなく、アセットを中心にアクセスを管理する
• サブネットではなく、ビジネスロジックでポリシーを定義する
• 静的な前提ではなく、リスクとポスチャに基づいて統制を実施する

この考え方を取り入れることで、セキュリティチームは真の制御力を獲得できます。より厳しく締め付けることによってではなく、信頼の判断をより賢く行うことによってです。

静的なルールを手放すとき

静的なルールは、インフラが静的だった時代には理にかなっていました。しかし、その世界はもう存在しません。今日のセキュリティは、ユーザー、ワークロード、脅威、リスクの絶え間ない動きを反映しなければなりません。つまり、ポリシーは硬直的で受動的なものから、動的で記述的なものへと進化する必要があります。アセットベースのセキュリティは流行語ではなく、セキュリティをどう考えるかと、それをどう運用に落とし込むかをつなぐ橋です。もし Zero Trust の取り組みが行き詰まっていると感じるなら、自問してみてください。実施しているポリシーは、そのアセットがかつてどうであったかに基づくものか、それとも今この瞬間にどうであるかに基づくものか。その答えが、停滞を抜け出す鍵になるかもしれません。 インフラを置き換えずに近代化を進めたいとお考えですか。動的でアセットを認識するポリシーが、いかに真の Zero Trust の俊敏性を実現するかを FireMon がご説明します。 Book a demo（デモのご予約）は本日お申し込みください。