今後の運用キーワード「マイクロセグメンテーション」、得られるさまざまな成果を解説

セキュリティ対策にあたって重要な視点は、セキュリティ強度、コスト、利便性の3つです。昨今では、この軽視されがちな「利便性」を考慮し直す傾向です。理由としては2つあります。

1つはエンドユーザーからみて使い勝手が悪いと本来のサービスを使わず独自の方法、すなわちシャドーITとして行ってしまうことです。もう1つは管理者からみて作業の負担が高い（運用性が悪い）と保守が疎かになります。その結果、本来意図したセキュリティを保つことができず、気づきづらいセキュリティホールを作ってしまい、結果としてセキュリティ強度が下がります。

重要なことは、欲張りすぎない、運用を意識するということです。過度にセキュリティ強度を高くしても利便性や運用性が悪くなってしまうと、逆にセキュリティ強度は下がります。また、自動化を見据えた設計は運用の面からも重要です。

以前のセグメンテーション製品は、設計の容易さ、運用性が良いとは言えませんでしたが、Akamai Guardicore Segmentation（以下、AGS）は、それを改善し、新しく生まれ変わったマイクロセグメンテーションソリューションとして登場しました。AGSには以下の2つの特徴があります。

• ゼロトラストセキュリティの新常識：社内の重要なリソースの発見と通信の健全化を実現
• ランサムウェアの予防、拡散対策：多角的なラテラルムーブメントの遮断

本記事では、新たな考え方であるマイクロセグメンテーションを使ってシステムの設計、運用の効率化をするポイントを、AGSの例を持ってお伝えします。

従来のセグメンテーションと課題

マイクロセグメンテーションという言葉を初めて聞いた方もいると思いますが、既にマイクロセグメンテーションに似た考え方を実際のシステムの運用に取り入れていることは珍しくありません。

セグメント、セグメンテーションとは区分や分割、階層を意味しますが、ネットワークやセキュリティの世界では、システムやサーバの用途や運用を考えてグループ化（＝セグメント化）することを意味します。

マイクロセグメンテーションは、今までのセグメントより更に狭く定義することで、サーバの堅牢性を高めます。古くからこの考えを基にアクセス制限をすることはありましたが、課題も多くありました。図1は現在のデータセンター内でのセグメントを表しています。

従来の運用方法

• ネットワーク担当者やセキュリティ担当者、サーバ担当者が担当する分野の製品でアクセス制限を実施
• アクセス制限は、ファイアウォール、スイッチ、ミドルウェア、OSなどの機能を利用
• セキュリティポリシーを製品の機能に合わせて設定を実施

従来の課題点

• 各製品に依存した異なるセキュリティ機能で共通したセキュリティポリシーを作成
• IPアドレス依存の設定のため、システム更新などネットワーク変更が発生すると影響範囲が広い
• 全体像が把握できず、重複や抜けなどのミスが発生しやすい

以前のセグメントはIPアドレスをベースとし、サブネットワークとほぼ同義語でした。当初のネットワーク設計は現在ほど複雑ではなく、またそれほどシステム更新も多くなかったため、それで問題はありませんでした。しかし現在は、システム拡張・変更やクラウドへの移行のためIPアドレスの変更が多く発生し、様々なシステムが複雑に連携し、色々な視点でのセグメントが要求されている中、1つのサーバを1つの視点でIPアドレスを利用することが難しくなってきました。

新しいセグメントの考え方にはIPアドレスベースではない基準が必要となります。

従来のセグメンテーションの導入ステップ

従来のセグメンテーションソリューションの多くは、デバイスに複数のセグメントを割り当てることが困難でした。そのため、まずグループを構成する「最小範囲」を見つけ、それを定義する必要がありました。

例えば図2を例にすると、最初にセグメントAを定義しますと、その後、A3のDBサーバに対するアクセス制限を行おうとした場合、セグメントAでは広すぎます。そのため、セグメントA1、A2、A3を定義し、その後に、A1、A2、A3を1つのグループAとすることで対応してきました。（もちろん先にAを作成後、A1、A2、A3に分割する考え方もありますが、機能制限により大幅な作業を強いられ設定変更は簡単ではありませんでした。）

その結果、全てを事前に把握しないとセグメントの設計が難しく、最初のステップで全ての通信の情報収集をする必要があるため非常に多くの時間が必要となりました。

AGSのセグメンテーションの導入ステップ

AGSは、複数のセグメントに所属させることができます。

図2を使って説明すると、Aシステムに対してアクセス制限が必要になれば、Aシステム内のサーバにセグメントAを割り当てます。次にA3のDBサーバに対してのアクセス制限が必要になった場合は、A3のサーバにセグメントA3を「更に」割り当てます。つまり、A3のDBサーバは、システムの区分としてのセグメントAとサーバの役割としてのセグメントA3の2つのセグメントに所属します。

こうすることで、全てのシステムを事前に全て知る必要はなく、優先度の高いシステムから導入できるため導入期間を短縮できます。

さらに、従来は広く守るか、狭く守るか「粒度」の視点でセグメンテーションを行ってきましたが、AGSは、セグメントの粒度だけでなく、脆弱性の有無、コンプライアンスの準拠の可否、レガシーシステムか否か、などの様々な視点での運用に沿ったセグメンテーションができ、それらを重ね合わせもできます。

セグメントを決めるためのユースケース

セグメントを決めるためには、最初にポリシーを決定します。「何を守りたいのか（対象サーバ）」「どんな制御をするのか（対象ポリシー）」「何処まで確認するか（プロセス検査）」を決めます。

以下の表1を見ていただくと分かりますが今までのセキュリティ製品の導入時と同じ考え方で進められます。少し違うのは、L4（IPアドレス+ポート）かL7（IPアドレス+ポート+プロセス）の部分になります。

項目	説明
対象サーバ	受発注システムのサーバ全て
対象ポリシー	既存の通信を除き、対象サーバへのあらゆる通信を遮断+警告にする。アプリケーションの内部通信やサーバからの通信は制御しない。
プロセス検査	実施。可能な限りフルパスのプロセス情報を含める（L4レベルか、L7レベルか）

セキュリティポリシーを考える場合にいくかの視点がありますが、アカマイではその視点をユースケースと呼んでいます。このユースケースはいくつかありますが、その中で代表的な6つを紹介します。

サーバの用途によるセグメント

表2の上位3つのユースケース、「1. セグメント」「2. アプリケーションの防御」「3. マイクロセグメンテーション」は守りたい範囲の大きさです。従来のデータセンターにあるファイアウォールやスイッチで行っているアクセス制限にあたります。

これらは階層化されており、一番範囲の広い「環境」、システムごとに区分される「アプリ」、DBなどのサーバの用途で区分される「役割」と順に守る範囲が狭くなります。

Roleは、サーバの用途分けに使用します。例えば3層構造であれば、プレゼンテーション層、アプリケーション層、データ層がそれぞれの役割に相当します。

これらは重ね合わせて使用できるので、サーバによっては3つのセグメントに所属することになります。

セキュリティの観点でのセグメント

表2の下位3つのユースケース、「4. 管理者特権」、「5. ベストプラクティス」、「6. ランサムウェア対策」はサーバの用途に関係なく、共通するサービスの提供や脆弱性からの保護など横断した保護を意識したセグメントです。

これらを説明にするあたり、ランサムウェア対策を例に説明します。典型的なランサムウェアの攻撃は5つのステップを踏みます。

この攻撃ステップにおいて、Step.2で「4. 管理者特権」、Step.4で「5. ベストプラクティス」のユースケースが有効となります。

「4. 管理者特権」	「5. ベストプラクティス」
一般端末から管理者特権での接続を制限	狙われやすいプロトコルの利用範囲を最小化

もちろん、Step.4の対策としてより特定のプロトコルに特化した「6. ランサムウェア対策」の選択もあります。

ゼロデイアタックを含めたアセット情報でのセグメント

これら各ユースケースで示したセグメントは、従来の範囲を超えた全体に影響します。今まではこの視点でのセグメントは難しかったですが、AGSでは簡単に行えます。これを実現するのがラベルという概念です。

ラベルによるセグメント

AGSでは、セグメントを分けるのにラベルを使用します。ラベルは、Key:Value形式になっており、Keyの視点でValueごとにグループが作られます。つまりValueの値が同じだと同じグループとなります。

例えば図2を使って説明します。A3にあるサーバは、DBの役割をもっているので、Role:DBというラベルがそれぞれのサーバに付与されます。同様に、A1にあるサーバは、ウェブサーバなので、Role:webがそれぞれにラベルが付与されます。A1もA3もシステムAの構成要素なので、App:SystemAのラベルを付与します。

一方、B1、B2、B3はシステムBに所属しているので、App:SystemBのラベルを付与します。システムAとシステムBの通信を遮断する場合は、App:SystemAとApp:SystemBを使います。また、A1とA3の通信を制限する場合は、Role:webとRole:DBを使用します。もちろん、App:SystemBとRole:webの組み合わせも可能ですし、App:SystemA & Role:webのようなアンド条件でより限定させることもできます。

表3の例では、背景が赤色の部分がユースケースの1から3にあたり、セグメントの粒度になります。青色の部分はSBOM（Software Bill of Materials）との相性が良い情報になります。オレンジ色の部分は脆弱性管理となります。

ラベルの用途

表3を見ていただくと分かりますが、ラベルの用途は単純なセグメント分け以外にも使用できます。

• 可視化と可読性
• セグメントのためのポリシー作成
• アセット管理
• 権限委譲のためのロールベースアクセス制御（RBAC）
• 脆弱性管理など

ラベルによるグルーピングでネットワーク上の通信フローとアセット（サーバや端末）の関係が明確になり、何が問題か、普段と何が違うかが分かりやすくなります。もちろん、そのラベルを通信制御にも活かせます。また、実際の通信制御に関連しない管理用の付加情報としても活用できます。

連携と自動化

セキュリティを運用する上で自動化は重要な要素だと考えます。日々、様々なセキュリティ製品から通知されるインシデントを自動で整理し、各セキュリティ製品にフィードバックできることは理想です。昨今、様々なインシデントの第一次処理のためにSOAR（Security Orchestration, Automation and Response）やSIEM（Security Information and Event Management）システムの導入が増えてきました。

また、それ以外にも脆弱性管理システムの製品もいくつかあります。それらの製品で端末のリスクなどを分析し、AGSのラベルにフィードバックさせることは簡単にできます。図11は、AGSがログとAPIを通じて外部システムと連携する際のイメージです。

AGSで作成されたログやインシデントをSOARやSIEMに送ります。またSOAR/SIEMはAGSだけでなく、EDRなどのログも収集します。SOAR/SIEMではこれらのログを解析し、リスクの高いサーバを見つけ出します。その結果をラベルとしてAGSにフィードバックすることで、予め用意されたポリシーに適用させることができます。

AGSでは、エコシステムパートナーも30社以上を数え、製品によっては予めプラグインが用意されているので簡単に連携させることもできます。

おわりに

以上、駆け足ですがAGSを導入し、運用する上でのポイントを紹介しました。新しくなったセグメンテーションの考え方をイメージしてもらえれば幸いです。

製品選定や運用において重要なことは、1つの製品で100％の対応を目指さないことです。1製品で完全を目指すと利便性や運用性が極端に悪くなることが多いからです。大体8割を目安にし、足りない部分はその分野に強い製品を選び連携して補えば、利便性、運用性を下げずに、比較的簡単に安全性の向上を図れます。マイクロセグメンテーションはインフラのレイヤーで実装され適用範囲が広いため、最初に選択していただくセキュリティ製品に向いていると考えております。ぜひマイクロセグメンテーションの良さを実感し、AGSを検討ください。

これまでの連載

• ゼロトラストセキュリティの新常識、社内リソース間の通信健全化を実現するマイクロセグメンテーション
• 連載：ランサムウェア対策の本命「マイクロセグメンテーション」第一回「侵入後がしつこい！ランサムウェア解説」
• 連載：ランサムウェア対策の本命「マイクロセグメンテーション」第二回「どうやって内部通信が制御されるのか？」