私がMicro-segmentationという言葉を初めて聞いたのはVMware社がNicira社を買収してNSXとして販売し始めた頃だったと記憶しています。Micro-segmentationとはLayer7レベルの粒度で細かくApplicationを分割することですが、何故これが必要なのか再度考えてみました。
トレンド
先ずApplicationの多様化があると思います。一昔前までは、特に社員が利用するEnterprise Applicationは自社専用のDatacenterだけで稼働するケースが多く見られましたが、現在はCloudファーストの時代です。自社内のDatacenterにインフラストラクチャやプラットフォームを1から構築して、自社内で開発している、または買ってきたAppliationを配備して運用するのは稀で、既にあるSaaSを利用する、もしくはPaaS/IaaSにAppliationを配備してセキュリティ対策を含む運用負荷をCloud Providerにオフロードすることが常識になりました。
更にもう1段階層を上げて考えてみると、Softwareの内製化もあると思います。あり物のSaaSを使いこなしながら同時に痒い所に手が届くApplicationは自社で内製する必要もあるかと思います。開発の手法も1昔前の統制を重視したWaterfall型から強調を重視したAgile型にシフトして、体制も開発・セキュリティ・運用チームが一体となったDevSecOps型が主流になり、新しい機能や変更が本番環境に配備される頻度と速度は格段に上がりました。Appliationに求められるセキュリティ要件も日々変化します。
ギャップ
トレンドを踏まえてこれまでに従来型のSegmentationとのギャップを考えてみます。先ず可視化の不備と粒度があると思います。従来のSegmentationはApplicationやDataのコンテキスト(例/DataにどんなRegulationが影響するか、ApplicationでどんなProcessが稼働しているのか）を無視してVLANやFirewallで静的な区画を作ってApplication群を分割していました。Firewallに多数のRuleが実装されていて、数ヶ月前に実装したRuleを読んでも意味がわからず何となくRuleが積み上がっていて本来の意味を成しているかどうかは誰も判断できません。また粒度もLayer4のレベルで分割しているため、Appliationのコンテキストとは無関係です。
次にマルチプラットフォーム非対応があるかと思います。トレンドで触れたように、AppliationやDataは様々な場所に存在します。仮にApplicationやDataが自社内のDatacenterにだけしか存在しない場合、従来型のSegmentationでも何とかなるかもしれません。しかしながらそれらがあらゆる場所に存在するとなるとVLANやFirewallをプラットフォームの数だけ配備して区画を実装して運用し続けなければなりません。これはムダですね。
おわりに
昨今バズワード化しつつあるZero Trust Network Accessは、UserとApplicationの間で発生するトラフィックを安全に保つSolutionですが、他の数多あるSolutionと同じくこれも万能な神器ではありません。Accountの乗っ取りやPolicy破壊によりAppliationに不正にアクセスされてRansomewareに侵される驚異は残ります。従来型のSegmentationではRansomewareに侵されたApplicationから他のApplicationにも簡単に伝染してしまします。Micro-segmentationであればRansomewareの被害を最小限に抑えることができますね。