Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. 【第3回】「Illumio」と「Netskope」の連携によるゼロトラストセグメンテーション(マイクロセグメンテーション)をリモートアクセス制御にも拡大

【第3回】「Illumio」と「Netskope」の連携によるゼロトラストセグメンテーション(マイクロセグメンテーション)をリモートアクセス制御にも拡大

投稿者:illumio担当

みなさん、こんにちは。社会人ウン年目のセキュリティチーム所属の八須です。

前回はIllumioを使って通信を制御をする方法をご紹介しました。

前回の記事はこちらです。

今回は同じく当社にて扱っているNetskopeをIllumioと連携させて、Illumioで管理されているワークロードへのアクセス制御をリモートアクセスでも行う方法をご紹介します。

2024年にIllumioとNetskopeの両社はサイバー攻撃に対する企業のレジリエンスを強化するためのゼロトラストパートナーシップ強化を発表しました。その取り組みはソリューション連携のケイパビリティ強化にも表れています。

以前から両ソリューションの連携統合はあるにはあったのですが、極めて限定されたユースケースでしか機能しないものでした。ついに今年は本命ともいえるZTNAによるリモートアクセスへの制御が連携可能になり、価値が大幅に高まっています。


1.ZTNAによるリモートアクセスとは

Illumioによるゼロトラストセグメンテーション(ZTS)は、技術的にはネットワークを越えての制御も可能でありながらも、主に組織のプライベートネットワーク内のホスト間のトラフィックの可視化と制御に視点がおかれます。

一方で、現在では場所にしばられない働き方としてのリモートワークが拡大しており、それにともなって不特定の場所からプライベートネットワーク内のリソースへのリモートアクセスも普及・拡大しています。

以前はリモートアクセスといえばリモートアクセスVPNでしたが、昨今ではリモートアクセスVPNを侵入経路にしたランサムウェア等のサイバー攻撃が多く発生していますので、侵入経路(攻撃対象領域)を減らすためより安全なゼロトラストネットワークアクセス(ZTNA)に移行する組織も増えてきています。

VPNが狙われたランサムウェア被害事例についてはこちらもご覧ください。

ZTNAは単体製品も存在しますがゼロトラストを意識したSASE/SSEに含まれることも多く、弊社でもSSEをお薦めしています。

NetskopeはZTNA機能(ZTNA Next L7)を備えていて、さらにIllumioと連携することでZTSで管理された構成をリモートアクセスのアクセス制御に反映させることができます。


2.連携の構成

今回実施する連携とは「Illumioの情報をNetskopeに連携する」という方向の連携になります。

登場人物としてはプライベートネットワーク内に設置されてVENが展開済みのワークロードと、ネットワークの場所を問わないがNetskopeClientが展開されたデバイスがあるとします。

そしてIllumioのPCEとNetskopeのMP、すなわち両サービスのマネジメントプレーンがクラウド型としてあるとします。このマネージメントプレーン間の情報連携を行います。

マネジメントプレーン同士の橋渡しをするためにNetskopeのソリューション連携用アプライアンスであるCloudExchangeをプライベートネットワークに設置します。

両クラウドサービスは各々APIを用意していますが、APIを実行するクライアントの役目を担う中継役が必要です。CloudExchangeはAPIをキックするプラグインが用意されている為、APIの中身を勉強してコマンドを実装しなくても連携が実現できるようになります。

※VENの展開については第一回のテックブログを参照してください。

※※構成は一例です。


3.連携の手順

今回は、サンプル設定を行い両者の連携を実際に確認していきます。

※今回ご紹介する手順とは別の手順でも実装できる場合があります。

 

Illumio PCEの設定

IllumioにおいてはNetskopeに連携する対象のラベルを決めておくことと、Netskopeがワークロード情報を取得する為のAPIキーの発行が必要となります。

前者はあくまで設計次第の決めごとです。今回はシンプルにNetskope連携テスト用ラベルを作成して、このラベルを付与されているワークロードをNetskopeに連携することにしました。

※ラベルの作成と付与については第一回のテックブログを参照してください。

APIキーの発行を実施していきます。

PCEにログインして、ユーザ名のドロップダウンメニュー > My API Keysを選択します。

APIキー一覧画面にてAddでキーを作成します。

他システムの為にキーを発行済みでも別々に発行してしておくとよいでしょう。

キー作成画面では定義名と説明に任意のテキストを入力します。定義名のみ必須項目です。

また、もしIllumioのOrg IDを普段把握していない場合はこの画面に表示されているIDを控えておいてください。後々使用します。

Createを実行するとキーが発行されます。

API Key Createdの画面が表示されたらキー発行は完了です。

この画面に表示されている「Authentication Username」「Secret」を控えておいてください。画面から任意のテキストファイルにテキストとしてコピー&ペーストすることも可能ですし、Download Credentialsを実行することで必要なパラメータが書かれたテキストファイルをダウンロードすることでも同じことが可能です。

この画面をCloseしてしまうと以降Secretの値は参照できない(キー自体を再発行することになる)ので確実に控えておいてください。

Closeによりキー一覧画面に追加されていることが確認できます。

Illumio PCEの設定は以上です。

Netskopeクラウドの設定

NetskopeクラウドでもAPI連携用トークンの発行が必要ですので発行します。

Netskope管理コンソールにログインして、Settings>Tools>REST API v2を選択します。

REST API v2 トークン一覧画面にてREST API STATUSがEnabledであることを確認してNEW TOKENを実行します。

※もしREST API STATUSがDisabledだった場合は横のペンアイコンを選択してEnableに変更しておく必要があります。

トークン作成画面では定義名、有効期間、権限(SCOPE)を設定します。

定義名は任意の値で問題ないですが、APIコールにより処理された際のNetskopeクラウド上のログではトークンの定義名が管理ユーザ名のように表示されるので、それを念頭においた値が良いでしょう。

有効期限は組織のポリシーに応じて設定します。

NetskopeではIllumioと異なりAPIトークン毎にアクセス権を設定する必要があります。

今回はIllumioとのZTNA連携に特化した設定ですので、「/api/v2/infrastructure/publishers」 にRead権限を、

「/api/v2/steering/apps/private/tags」「/api/v2/steering/apps/private」にRead+Write権限をそれぞれ設定します。

必要権限は連携する機能により変わりますのでよくお確かめの上ご設定ください。

パラメータを設定したらSAVEを実行してトークンを発行します。

Successの画面が表示されたらトークン発行は完了です。

この画面に表示されている COPY TOKEN を実行するとトークンがクリップボートにコピーされますので、任意のテキストファイルにテキストとしてペーストすることで控えておいてください。

OKを選択して画面を閉じてしまうとやはり以降はトークンの参照はできなくなるので確実に控えておいてください。

トークンを控えたらOKを選択して画面を閉じます。

一覧画面でもトークンが追加されていることが確認できます。

Netskopeクラウドの設定は以上です。

CloudExchangeの設定

CloudExchangeではIllumio/Netskope両クラウドへAPIアクセスするためのキーの登録と、両者の紐づけを行います。

これにより、Illumio PCEに向けた参照系APIコールによるワークロード情報を取得して→関係するNetskopeクラウドに向けた更新系APIコールによるポリシーオブジェクト(アクセス制御対象)の更新を実現します。

CloudExchange仮想アプライアンスのインストールと起動までは済んでいる前提として、当記事ではAPIパラメータの登録以降からの手順をご紹介します。

当記事ではCloudExchange v5.0.1を使用しています。以後はCloudExchangeをCEと表記します。

CEの管理コンソールにログインして、Settings>Generalを選択します。

CEには5つの機能モジュールの概念がありますがlllumioとの連携ではThreat Exchange(CTE)モジュールの稼働が必要ですので、有効になっていなければトグルスイッチを操作して有効にしてください。

次にIllumioと連携を行うNetskopeクラウドのテナント情報をCEに登録します。

他の連携で登録済みのテナントと連携させるのであれば省略可能です。

Settings>Netskope Tenants を選択して、Add Tenantを実行します。

テナント追加画面では各パラメータに値を入力します。

NameはCEの中での定義名ですので識別しやすい任意の値を入力できます。

Tenant NameはNetskope契約テナントのテナント名を入力します。goskope.comの部分は省略してください(契約テナントの管理コンソールのFQDNがmycompany.goskope.comである場合はTenant Nameにはmycompanyのみ入力します)

V2 API Tokenには先の手順で取得していたNetskope REST API V2のトークンを入力します。

他にもしCEがインターネットアクセスする際にプロキシを経由する必要がある場合はUse System Proxyにチェックを入れて情報を追加してください。

各項目を入力したらSaveを実行します。

なおSaveすると下記のメッセージが表示されることがありますが慌てず反映を待ちましょう。

一覧に追加されたことが確認できます。

次にプラグインを登録します。

CEでは各サービスへのAPIアクセスが「プラグイン」というかたちで提供されています。

まずはIllumioのプラグインを登録していきます。

Threat Exchange>Plugins に遷移します。Configure New Pluginを実行します。

※またはSettings>Pluginsでも同じ画面に遷移できます。

CEにて予め用意されているプラグインの一覧が表示されますので構成したいプラグインを選択します。

今回はIllumio(CTE)を選択します。

Illumioを選択するにあたっては全てのプラグイン一覧から捜してもよいですが、フィルター条件にIllumioなどとキーワードを入れると簡単に見つけることができます。

プラグインに応じた各項目を登録します。

まずはBasic Information。こちらは比較的素直に登録すれば問題ないです。

各項目を設定したらNextを実行します。

Nextを実行すると続いてConfiguration Parametersです。

こちらにIllumioのPCEで取得しておいた情報を登録していきます。

PCE URLには、PCEにログイン後のPCEのFQDNを入力します。覚えていない場合はPCEにログインすれば確認できます。

PCE Organization ID、API Authentication Username、API SecretはIllumioのAPIキー作成時に確認した「Org ID」「Authentication Username」「Secret」を入力します。

※Illumioの「Key ID」はNetskopeでは不要です。

Label ScopeではCEが取得するラベルを指定します。ここで指定したラベルが付与されたワークロードのみを取得しますのでここに何を設定するか設計が肝要となります。

今回は連携テスト用ラベルを適用します。

構文に注意が必要で、ラベルのタイプとラベル名をコロン区切りで指定します。カンマ区切りで複数のラベルを取得対象として指定することも可能です。

最後にSaveを実行します。

これでIllumioのプラグインが登録された状態になりました。

続いてNetskope接続用のプラグインも登録するので、再びConfigure New Pluginを実行します。もしIllumio以外のソリューションとの連携で既にCEにNetskope用プラグインが登録済みである場合は、必ずしも新規登録を行わずとも既存の登録を活かすことも可能です。

今度はNetskope(CTE)を選択します。Netskopeは先頭にあるので見つけやすいです。

Netskopeプラグインでも同じくBasic InformationとConfiguration Parametersを入力していきます。

Netskopeプラグインの場合はプラグインにAPI連携のキーパラメータを直接設定するのではなく、先に作成したテナント設定を紐づける形で設定することになります。

Tenantにて先に作成していたテナント定義をリストから選択します。

またType of Threat dataはBothもしくはURLを指定しておきます。

入力し終えたらSaveを実行します。

この時点で二つのサービスのマネジメントプレーンにCEがアクセスするための情報が登録できました。

次はいよいよ両者の連携、紐づけを行います。

左部のペインメニューからBusiness Rulesを選択してCreate New Ruleを実行します。

Business Ruleとは連携先に渡すIoCの抽出条件だと思えばよいかと思います。

今回はテスト用のためあまり抽出条件に拘る必要もないのですが、情報ソースがIllumio(プラグインのConfiguration Nameで指定します)であることと一応しておきます。

Saveを実行して保存します。

ルールが作成されました。

次に共有設定(Sharing Configuration)を作成します。

いよいよここでIllumioからの情報をNetskopeに渡す連携を設定します。

左部のペインメニューからSharingを選択してAdd Sharing Configurationを実行します。

Create Sharing Configuration画面で各項目を入力していきます。

IllumioとNetskopeの連携においては、連携の方向は”IllumioからNetskopeへ”になります。逆方向はありません。

SourceにはIllumioの、そしてDestinationにはNetskopeのプラグイン定義名を、それぞれ選択します。Sourceから先に選択する必要があります。

Business Ruleには作成したビジネスルールを選択します。

TargetとはDestination側のNetskopeの何に連携したいかを指すもので、今回はZTNA機能に連携するためAdd to Private App を選択します。

以降の設定項目はNetskopeのSettings>Security Cloud Platform>Traffic Steering>App Definition>Private Appsに設定する項目をCEで設定しているようなものです。つまり、ここで設定した内容でCEからAPIコールすることによりNetskopeのプライベートアプリ定義が作成・更新されることになります。

Private App Nameで更新をかけるNetskope側の既存プライベートアプリ定義名をリストから選択するか、Create New Private Appにより既存で存在しないアプリ定義をNetskopeに新規作成することも可能です。今回は後者を設定してみます。

Protocol以降はNetskopeのPrivate Appsの設定項目そのままです。Netskopeに設定する気持ちで指定します。

なおPrivate App NameとPublisherの設定値の選択肢リスト表示はNetskopeクラウドへ参照系APIを実行して既存の定義名を取得しています。このリスト表示が失敗する場合にはアクセス権が不足している可能性がありますのでNetskopeクラウドにてAPIトークンに付与したアクセス権を見直してみてください。

全ての入力を終えたらSaveを実行します。

共有設定が作成されました。

以上で連携の構成は完了です。

最後に、実際に連携をテストしてみます。

連携元であるIllumioにて、とあるワークロード1台に連携対象のラベルが付与されたとします。(今回は連携テスト用ラベルをPCEから手動で付与しています)

すると程なくしてNetskopeのPrivate Appに登録されました。Netskopeに宛先ホストとして登録されているIPアドレスはIllumioのVENにより収集されたワークロードのNICに設定されているIPアドレスです。

直接Netskopeに登録作業することなく、Illumioから連携されたIoC情報を宛先ホストとして自動登録することに成功しました。

実際の運用においては、このPrivate Appに対するZTNAのアクセスポリシーを予めNetskopeに作成しておくことで、デバイスからワークロードへのアクセス制御を動的に変化させることができます。


4.連携のユースケース(連携のメリット)

連携がどのように役立つのかユースケースを考えてみます。

ユースケース例①:ワークロードへの侵害発生時におけるZTNAアクセス制御の自動化

これがソリューション連携において最も期待されるケースだと考えられます。
Illumioにおいて”Quarantine”等の侵害されたワークロード向けのラベルを定義します。
CEにおいて前述のラベルをスコープとしてIllumioからNetskopeに連携するよう構成します。
さらに予めIllumioから連携されたワークロードを宛先ホストとしたZTNA拒否ポリシーをNetskopeに作成し、ZTNA許可ポリシーよりもより優先上位にオーダーします。
これによりいざIllumio管理ワークロードへの侵害もしくその疑いが発生した場合でもIllumio側でラベル付けがなされるだけで、対象ワークロードに対するNetskopeによるZTNAが自動的に拒否されるようになり、管理者はより少ない工数で迅速なインシデント対応を図ることができます。

ユースケース例②:平常時におけるZTNAのアクセス制御の自動化とワークロードへのZTSの強制

IllumioにおけるひとつもしくはいくつかのZTNAアクセスを許可するワークロード向けのラベルを定義します。
CEにおいて前述のラベルをスコープとしてIllumioからNetskopeに連携するよう構成します。
さらに予めIllumioから連携されたワークロードを宛先ホストとしたZTNA許可ポリシーをNetskopeに作成します。
これによりZTNAを許可したいワークロードを追加するという要件が発生した場合でもIllumio側でラベル付けがなされるだけで、都度Netskopeの管理コンソールから宛先ホスト登録作業を行う必要がなくなり、管理者はより少ない工数で運用を行うことができます。
さらにZTNAの宛先はNetskopeで直接定義することなくIllumioから受け取ることを前提としたNetskopeのポリシー構成を作成すると、ZTNAでのアクセスを受けるワークロードに対してIllumioのVENが予めインストールされてIllumioの管理下であることを事実上強制することもできます。


最後に

いかがでしたでしょうか。
このブログを通して、Illumioと他ソリューションの連携がさらなる価値をもたらす一例をご理解いただけたのではないでしょうか。

勿論、Illumioが連携できるのはNetskopeとだけではありません。他の分野のパートナーと連携して別の面での強化を図ることができるのですが、それはまたの機会に。

ページのトップへ