セキュリティ監視・運用・診断｜知る×学ぶ
【運用編】マイクロセグメンテーションの新常識｜運用ポイントとは
はじめに
セキュリティ対策にあたって重要な視点は、セキュリティ強度、コスト、利便性の 3つです。昨今では、この軽視されがちな「利便性」を考慮し直す傾向です。理由としては 2つあります。 1つはエンドユーザーからみて使い勝手が悪いと本来のサービスを使わず独自の方法 – シャドーIT を行ってしまうことです。もう1つは管理者からみて作業の負担が高い (運用性が悪い) と保守が疎かになります。その結果、本来意図したセキュリティを保つことができず、気づきづらいセキュリティホールを作ってしまい、結果、セキュリティ強度が下がります。
重要なことは、欲張りすぎない、運用を意識する、ということです。過度にセキュリティ強度を高くしても利便性や運用性が悪くなってしまうと逆にセキュリティ強度は下がります。また、自動化を見据えた設計は運用の面からも重要です。
以前のセグメンテーション製品は、設計の容易さ、運用性があまり良くはありませんでしたが、Akamai Guardicore Segmentation (AGS) は、それを改善し、新しく生まれ変わったマイクロセグメンテーション ソリューションとして登場しました。AGS には以下の 2つの特徴があります。
- ゼロトラストセキュリティの新常識: 社内の重要なリソースの発見と通信の健全化を実現
- ランサムウェアの予防、拡散対策: 多角的なラテラルムーブメントの遮断
本記事では、新たな考え方であるマイクロセグメンテーションを使ってシステムの設計、運用の効率化をするポイントを、Akamai Guardicore Segmentation の例を持ってお伝えします。
▼ 目次
１．従来のセグメンテーションと課題
２．従来のセグメンテーションの導入ステップ
３．AGS のセグメンテーションの導入ステップ
４．セグメントを決めるためのユースケース
５．サーバーの用途によるセグメント
６．セキュリティの観点でのセグメント
７．ゼロデイアタックを含めたアセット情報でのセグメント
８．ラベルによるセグメント
９．ラベルの用途
１０．連携と自動化
１．従来のセグメンテーションと課題
マイクロセグメンテーションという言葉を初めて聞いた方もいると思いますが、既にマイクロセグメンテーションに似た考え方を実際のシステムの運用に取り入れていることは珍しくありません。
セグメント、セグメンテーションとは区分や分割、階層を意味しますが、ネットワークやセキュリティの世界では、システムやサーバーの用途や運用を考えてグループ化 (=セグメント化) することを意味します。マイクロセグメンテーションは、今までのセグメントより更に狭く定義することで、サーバーの堅牢性を高めます。古くからこの考えを基にアクセス制限をすることはありましたが、課題も多くありました。図1は現在のデータセンター内でのセグメントを表しています。
図 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 に分割する考え方もありますが、機能制限により大幅な作業を強いられ設定変更は簡単ではありませんでした。）
図 2. セグメンテーション定義
その結果、全てを事前に把握しないとセグメントの設計が難しく、最初のステップで全ての通信の情報収集する必要があるため非常に多くの時間が必要となりました。
図 3. 従来の導入ステップ
３．AGS のセグメンテーションの導入ステップ
Akamai Guardicore Segmentation (AGS) は、複数のセグメントに所属させることができます。図2 を使って説明すると、 Aシステムに対してアクセス制限が必要になれば、Aシステム内のサーバーにセグメント A を割り当てます。次に A3 の DBサーバーに対してのアクセス制限が必要になった場合は、A3のサーバーに セグメント A3 を「更に」割り当てます。つまり、A3 のDB サーバーは、システムの区分としてのセグメント A とサーバーの役割としてのセグメントA3 の二つのセグメントに所属します。
こうすることで、全てのシステムを事前に全て知る必要はなく、優先度の高いシステムから導入できるため導入期間を短縮できます。
図 4. AGS の導入ステップ
更に、従来は広く守るか、狭く守るか「粒度」の視点でセグメンテーションを行ってきましたが、AGS は、セグメントの粒度だけでなく、脆弱性の有無、コンプライアンスの準拠の可否、レガシーシステムか否か、などの様々な視点での運用に沿ったセグメンテーションができ、それらを重ね合わせもできます。
４．セグメントを決めるためのユースケース
セグメントを決めるためには、最初にポリシーを決定します。「何を守りたいのか (対象サーバー) 」、「どんな制御をするのか (対象ポリシー)」、「何処まで確認するか (プロセス検査) 」を決めます。以下の表1 を見て頂くと分かりますが今までのセキュリティ製品の導入時と同じ考え方で進められます。少し違うのは、L4 (IPアドレス+ポート) か L7 (IPアドレス+ポート+プロセス)の部分になります。
表 1. ポリシー例
セキュリティポリシーを考える場合にいくかの視点がありますが、アカマイではその視点をユースケースと呼んでいます。このユースケースはいくつかありますが、その中で代表的な 6つを紹介します。
表 2. 代表的な6つのユースケース
５．サーバーの用途によるセグメント
表2 の上位 3つのユースケース、「1. セグメント」、「2. アプリケーションの防御」、「3. マイクロセグメンテーション」は守りたい範囲の大きさです。従来のデータセンターにあるファイアウォールやスイッチで行っているアクセス制限にあたります。これらは階層化されており、一番範囲の広い「環境」、システム毎に区分される「アプリ」、DBなどのサーバーの用途で区分される「役割」と順に守る範囲が狭くなります。
図 5. 階層化されたセグメント
Environment は、いくつかのシステムを纏める場合に使用します。分割した環境は通常お互いの通信は制限されています。例えば、本番環境と開発環境、B2B/B2C とB2E などに相当します。
Application は、1システム毎に区分されます。例えば、CRMシステム、認証システム、バックアップシステムなどです。これらのシステム間の不要な通信を制御するために使用します。
Role は、サーバーの用途分けに使用します。例えば 3層構造であれば、プレゼンテーション層、アプリケーション層、データ層がそれぞれの役割に相当します。
これらは重ね合わせて使用できるので、サーバーによっては 3つのセグメントに所属することになります。
図 6. 各階層のセグメントと通信制御例
６．セキュリティの観点でのセグメント
表2の下位 3つのユースケース、「4. 管理者特権」、「5. ベストプラクティス」、「6. ランサムウェア対策」はサーバーの用途に関係なく、共通するサービスの提供や脆弱性からの保護など横断した保護を意識したセグメントです。
これらを説明にするあたり、ランサムウェア対策を例に説明します。典型的なランサムウェアの攻撃は５つのステップを踏みます。
図 7. 典型的なランサムウェアの攻撃
この攻撃ステップにおいて、Step. 2 で「4. 管理者特権」、 Step.4 で「5. ベストプラクティス」のユースケースが有効となります。
図 8. セキュリティ観点でのユースケース
もちろん、Step.4 の対策としてより特定のプロトコルに特化した「6. ランサムウェア対策」の選択もあります。
７．ゼロデイアタックを含めたアセット情報でのセグメント
図 9. 脆弱性ソフトの状態によるセグメント
2021年にあった Apache Log4j のような新しい脆弱性が報告された場合にもセグメントが威力を発揮します。
ここの例では、アセット (情報資産＝サーバーや端末) の持つ情報から分類します。脆弱性対象のソフトの使用 / 未使用、ソフトの修正済 / 未修正をセグメントで分類され、他サーバーや外部への通信のアクセス制限を目的とした隔離です。脆弱性ありで未修正は厳しく隔離し、修正済は隔離を緩和、対象外については隔離を行わないという制限が横断的に適用できます。また、修正済みの進捗度合いとしても利用できます。
これら各ユースケースで示したセグメントは、従来の範囲を超えた全体に影響します。今まではこの視点でのセグメントは難しかったですが、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. ラベル例
９．ラベルの用途
表3 を見ていただくと分かりますが、ラベルの用途は単純なセグメント分け以外にも使用できます。
- 可視化と可読性
- セグメントのためのポリシー作成
- アセット管理
- 権限委譲のためのロールベースアクセス制御 (RBAC)
- 脆弱性管理
など
ラベルによるグルーピングでネットワーク上の通信フローとアセット (サーバーや端末) の関係が明確になり、何が問題か、普段と何が違うかが分かりやすくなります。もちろん、そのラベルを通信制御にも活かせます。また、実際の通信制御に関連しない管理用の付加情報としても活用できます。
図 10. ラベルによる権限委譲
ラベルによりセグメントを分割すると同時にそのセグメントの管理の権限を委譲することもできます。共通インフラについては、会社のコンプライアンスとしてIT部門が設定し、各アプリについては各アプリの担当者で細かい設定を行うこともできるので、全体で一貫したポリシー作成も簡単に行えます。
１０．連携と自動化
セキュリティを運用する上で自動化は重要な要素だと考えます。日々、様々なセキュリティ製品から通知されるインシデントを自動で整理し、各セキュリティ製品にフィードバックできることは理想です。昨今、様々なインシデントの第一次処理のためにSOARやSIEM システムの導入が増えてきました。またそれ以外にも脆弱性管理システムの製品もいくつかあります。それらの製品で端末のリスクなどを分析し、AGS のラベルにフィードバックさせることは簡単にできます。図11 は、AGS がログとAPIを通じて外部システムと連携する際のイメージです。
図 11. API を利用した連携
AGS で作成されたログやインシデントをSOARやSIEM に送ります。またSOAR/SIEM は AGS だけでなく、EDRなどのログも収集します。SOAR/SIEMではこれらのログを解析し、リスクの高いサーバーを見つけ出します。その結果をラベルとしてAGS にフィードバックすることで、予め用意されたポリシーに適用させることができます。
AGSでは、エコシステムパートナーも 30社以上を数え、製品によっては予めプラグインが用意されているので簡単に連携させることもできます。
漫画でよりわかりやすくまとめております。以下よりご覧いただけます。
おわりに
以上、駆け足ですが Akamai Guardicore Segmentation を導入し運用する上でのポイントをご紹介させていただきました。新しくなったセグメンテーションの考え方をイメージしていただけたでしょうか？
製品選定や運用において重要なことは、1製品で100％を目指さないことです。1製品で100％を目指すと利便性や運用性が極端に悪くなる事が多いです。大体８0％を目安にし、足りない部分をその分野で強い製品を選定し連携させることで、利便性、運用性を下げずに安全性を向上させることが簡単にできます。マイクロセグメンテーションはインフラのレイヤーで実装され適用範囲が広いため、最初に選択して頂くセキュリティ製品に向いていると考えております。是非マイクロセグメンテーションの良さを実感し、Akamai Guardicore Segmentation を選択して頂ければ幸いです。
関連記事
【導入編】ゼロトラストセキュリティの新常識｜マイクロセグメンテーションとは
【入門編1】ランサムウェア対策の本命「マイクロセグメンテーション」｜ランサムウェア解説編
【入門編2】ランサムウェア対策の本命「マイクロセグメンテーション」｜内部通信制御解説編
Akamai Guardicore Segmentaionの詳細については、以下よりご覧いただけます。
ここまで読んでいただき、マイクロセグメンテーションに関してより詳細な情報を入手したいお客様はぜひ弊社にお問合せください。マイクロセグメンテーション製品の具体的な情報提供や製品デモなどを実施させていただきます。
