マイクロセグメンテーションとは
マイクロセグメンテーションとは、ネットワークをより細かく分けることを意味します。
従来の方法では、より細かく分けたネットワークセグメントに対して、ネットワークの境界にFW（Firewall）を設置してアクセス制御を行ってきました。
また、仮想サーバー上では、SDNを利用して仮想ネットワークを構築し、論理的にネットワークを分離する構成も取られてきました。
このマイクロセグメンテーションの技術は次の段階に進化しており、具体的には エージェント型によるセグメンテーション が使われるようになりました。
今回は、そのエージェント型のマイクロセグメンテーションについて紹介したいと思います。
なぜマイクロセグメンテーションが必要なのか
インフラエンジニアとして保護しなければいけない部分は、サーバーやその上に構築されるシステムです。
システムへ接続させる通信は、iptablesで特定の通信のみを許可したり、もしくはFWで外部からアクセスするサービスに対して接続を許可するのが一般的な手法です。
インターネットからサーバーへの接続に関しては、iptablesやFWのルールを厳しく設定している場合が多いです。
しかしながら、サーバー間通信において細かくiptablesを設定して運用している構成は少なく、ネットワークとしても厳密な制御はせず、疎通制を重視した構成がほとんどかと思います。
このサーバー間の通信をより広く行える状態が、悪意ある攻撃者にとっては好都合な環境となります。
昨今のランサムウェアなどの攻撃は侵入を伴うため、ネットワークがより接続しやすい環境であればあるほど、感染は広まります。
そのため、インフラエンジニアとしては 重要なシステムへの通信に関しては、必要最小限に制限すること がセキュリティ対策として求められてきます。
インフラエンジニアが何を管理することを求められるのか
システムを保護するため通信の制限を行う際には、どのシステムからのアクセスを許可するかを厳密に管理していくことが必要です。
情報としては、送信元IP・送信先IP、ポート番号、プロトコルで制限するのが一般的です。
しかしながら、この制限を運用途中から管理することは難しく、特にシステム全体が大規模になればなるほど、何がアクセスしているか特定できず制限の追加が行えないことが多いです。
特に古いシステムになればなるほど、誰が管理しているか不明なシステムがあったりなど、様々な問題があることが多く制限の追加は困難です。
エージェント型のマイクロセグメンテーションは何を解決できるのか
エージェント型のマイクロセグメンテーションは、エージェント型のFWのクラウサービスによる統合管理 と捉えるとわかりやすいです。
今までのマイクロセグメンテーションはネットワーク上のFWで制御するか、論理的にネットワークを分割することで対応してきました。
しかし、ネットワークを分割する手法では、物理的な投資を大きく行う必要がありました。
エージェント型のFWでは、ネットワークはただの通信できる”土管”として活用し、制限をサーバー上で行えるようになります。
これでは、iptablesの管理と変わらないのではと思うかもしれませんが、そうではありません。
マネージドサービスであるため、その 運用を効率化させる機能が備えられているのがエージェント型のFW です。
エージェント型のFWで一番はじめに行うことは、サーバーにエージェントを導入することです。
エージェントの通信ログをクラウド上の管理サーバーが収集し、その情報を元にネットワーク全体を一元的に把握できる通信マップを作成することができます。
そのマップされた情報を元に、制限の追加が行えるようになるのがエージェント型のFWです。
今までのネットワーク制限の追加では、追加する前に様々な関連箇所に通信は何が必要なのか確認することが求められていましたが、エージェント型ではその**初期調査を省くことができます。**
実際に通信されている状態を可視化してから、何を許可すればよいのか、拒否すればよいのか、あとから突き詰めていくことが可能です。
この機能によりインフラエンジニアは古いシステムに対しても、接続制限が行いやすくなります。
エージェント型のFWに変化することによって、通信の制限がより細かにできる
今までのマイクロセグメンテーションは通信経路上で行うものだったため、IPやポートを中心とした制限となっておりました。
しかし、エージェント型では、サーバーに対してインストールして利用するため、OS上のプロセス情報も取得できるようになりました。
この機能により、送信元IP+送信先IP+ポート番号+プロセスの要素で通信の制限を行えるようになります。
またこれにより、不正なプロセスからの通信を拒否したりすることができ、よりシステムに対しての制限を厳密に管理することができるようになります。
より厳密に管理していくことの運用負荷について
システムに対して、厳密にアクセス制限していくということは、どこのIPからアクセスを許可すれば良いのか、より多くの情報を登録しなければならないという運用負荷をインフラエンジニアは気にする必要があります。
本来管理したい情報粒度としては、何の役割を持ったアプリのアクセスは許可し、それ以外は拒否などのルールを設定できること が理想です。
ですが、現実は、どこからのIPからの通信を許可するなど、膨大なIPアドレスの管理をしていくことが求められます。
エージェント型のFWでは、IPの運用からラベルベースの運用 に置き換わることで、その運用負荷は軽減されます。
本来管理したい情報は「開発WebサーバーのApacheから開発DBサーバーのMySQLのPort3306にTCPでアクセスできる＝どこからどこにアクセス可能」という情報のみです。
インフラエンジニアはIPアドレスを気にすることなく本来管理したい情報のみをルール化できるのが、ラベルベースの管理の特長です。
マイクロセグメンテーションはゼロトラストなのか
現在セキュリティ業界の主流となりつつあるゼロトラストに関して、様々な解釈がある中でマイクロセグメンテーションはゼロトラストとしてどのような役割を補えるのか検討しました。
検討する土台としては、「NIST SP 800-207: Zero Trust Architecture (ZTA)」を参考とします。
NIST SP800-207では、信頼されていないネットワークから暗黙のトラストゾーンの接続に接続する際に、PEP(ポリシー実行ポイント)とPDP(ポリシー定義ポイント)を用意し、すべての通信を認証認可する仕組みが記載されています。
リソース間が通信する「暗黙のトラストゾーン」はPEP/PDPレベルの信頼されている領域であり、暗黙のトラストゾーンは可能な限り小さくすることがSP 800-207では求められています 。
そこで、一つの方法として提示されているのがエージェント型のマイクロセグメンテーションです。
他にもNISTが出している、「NIST SP 800-204B Attribute-based Access Control for Microservices-based Applications using a Service Mesh」なども参考になりますが、同資料ではシステムをマイクロサービス化していくことが求められています。
これですと既存の全システムの更改が必要となるため、現実的な手法とは言い難いです。
既存のシステムを維持したまま、暗黙のトラストゾーンを極限まで小さくすることができれば、ゼロトラスト化も実施しやすいと言えます。
暗黙のトラストゾーンを小さくするエージェント型FWのマイクロセグメンテーション
エージェント型のFWでは、既存のシステムに手を加えることなく、リソース間の通信を制限することができるため、暗黙のトラストゾーンを極限まで小さくすることができます。
これにより、大規模なマイクロサービス化の改修を行わなくても、マイクロセグメンテーション化を進めることができます。
エージェント型のFWを選定していく上で必要なこと
ラベルの付与に制限がないこと
ラベルベースに変更する際には、様々な環境(Prd/Stg/Dev)や様々なロール(Web/DB/Cache)など自分たちの思い描く役割を付与して制限を行う必要があります。
そのため、その付与するラベルに制限がないことが重要です。
様々なOSにエージェントが対応していること
エージェント型のFWでは、様々なOS、特にレガシーOSに対応している製品を選定することが重要です。
また、DockerやKubernetesなどの最新の環境へ適用できることも確認する必要があります。
エージェントが導入できない機器に対して、どのようにアプローチしていく必要があるかも確認することが重要です。
処理が高速であること
エージェント型の場合には、FWの処理負荷は各エージェントが担う必要があります。
そのため、なるべく軽量でなおかつ、iptablesなどより高速な処理を行えることが理想的です。
どの程度の負荷、処理速度なのか確認しておくことが重要です。
Akamai Segmentation
今回、エージェント型FWの機能を兼ね備えたマイクロセグメンテーションのソリューションが、Akamai Guardicore Segmentationです。
まとめ
私自身、初めてマイクロセグメンテーションを学んだ際に、何をどのように管理すれば良いのかわかっていませんでした。
今回の記事の内容で少しでもマイクロセグメンテーションについて理解を深めていただければ幸いです。