同一セキュリティゾーン内の検査も可能、一元管理でシンプルな設計・設定に　現状のセグメンテーションの課題を解消する「エージェント型セグメンテーション」

本セッションの概要

金子春信氏：セキュリティのプロダクトマーケティングを担当している金子と申します。このセッションでは大和総研の山野さまより、最新の技術であるマイクロセグメンテーション、そして弊社のソリューションの「Guardicore」（「Akamai Guardicore Segmentation」）の実際の評価についてお話しいただくのがメインです。

その前に、Guardicore製品自体がどんなものなのかある程度わかっていないと伝わりづらいということで、僭越ながら私のほうで最初に15分ほどお話しをして、その後に山野さまから20分お話しいただく流れで進めます。よろしくお願いします。

「Akamai Guardicore Segmentation」の利用用途の例

さっそくですが、Akamai Guardicore Segmentationということで、製品としてはマイクロセグメンテーションを提供するものです。マイクロセグメンテーションというと、セグメンテーション、つまり企業の内部のネットワークの通信制御を行うようなところですが、その進化系です。

この技術が出てきた当初、どちらかというとざっくりしていたセグメントを、もっとマイクロに管理できるみたいな色が強かったので、技術の名前としてはマイクロセグメンテーションという名前になっています。

実際にグローバルで数百のお客さまに利用いただいていますが、それらの利用の実態を見ると、必ずしもマイクロにするだけではない。現在はどちらかというと自社のデータセンターだけではなくて、AWSやAzure、Google Cloudなど、いろいろなところに分散してしまっているワークロードを自在に通信制御できる、セグメントできるというような技術だという色が非常に強くなっています。

（スライドを示して）マイクロセグメンテーションという言葉で最初に誤解が生まれないようにですね、私たちのお客さまの中で使われているような、主要なユースケースをスライドで並べています。一つひとつ個々に長く説明していくと時間がかかりすぎてしまうので、さらっといきます。

利用用途として非常に多いのが、ランサムウェア対策。昨今の侵入型ランサムウェアということで、ネットワーク内部に入ってきて、そこからネットワーク内のスキャンやラテラルムーブメント、いわゆるサーバー間の移動をして情報を盗み出すという、内部に入ってからの行動がかなり長いということで、この内部通信制御によってランサムウェア対策をするというところが1つ、コンペリングイベントという言い方をしますが、重要な導入の要因として挙げられています。

ただ、この理由1つだけで入れるというよりは、先ほど言ったように、いろいろなところに分散してしまっているワークロードを管理する手法がなくなってきている。従来のやり方ではできなくなってきている。なので、そこの見直しみたいなモチベーションと併せてやることが多い傾向があります。

これが利用用途の2つ目と3つ目ですが、いろいろなところに分散しているマルチクラウドのワークロードを見えるようにする、可視化する、「どことどこがどう通信しているのか」を把握するために入れるケースが非常に多くなっています。

見えたものに対して、「じゃあどことどこが通信しているのか」というポリシーを適用する。その内部通信のポリシーの適用って、従来は内部ファイアウォールとかでやってきたところだと思います。

今までオンプレミスの1ヶ所のデータセンターだった時は、ファイアウォールアプライアンスを買ってきて、ネットワークチョークポイントを設けて、そこを通る時だけ必ず検査をするというやり方を内部ファイアウォールではやってきていました。

これがオンプレの内部ファイアウォールではできなくなってきているので、分散した環境で、内部通信制御、内部ファイアウォールの進化系として適用するというようなところが、かなり主要な使い方になってきておりますと。

金融系とかであれば、SWIFTとかPCIみたいな、ほかと分けなければいけない環境をこの技術を使って自在にセグメントしたり、レガシーシステムが残っている場合は、そのレガシーシステムの環境をほかからアクセスできないようにセグメントするとか。

あと、インシデントが起きた時に、インシデントの環境をほかと隔離してセグメントするとか、そういう応用系にいくんですが、コアになるのは、今、把握すること自体難しくなってきているワークロードをきちんと1ヶ所から把握して、それらに対して一貫した通信制御を行うこと。これを実現するのがマイクロセグメンテーションのような技術になっています。

現状のセグメンテーションはどんな課題があるのか

このセグメンテーションから簡単におさらいしたいと思うんですが、現状のセグメンテーションにどんな課題があるのかを、2枚のスライドで少しだけ話したいと思います。

現状よりちょっと古いかもしれないですが、従来型のセグメンテーションは、スイッチとかのレイヤーではネットワークを物理的にスイッチを分けたり、もしくはスイッチ内で論理的にVLANで分けたりして、セグメントを作ります。

そのセグメント間で通信をする時に、アクセスコントロールをかける。それをスイッチのレイヤーでやる場合もあれば、マルチレイヤスイッチの場合もあれば、ルーターなど、もう1段高い場所でやる場合もありますが、セグメントを分けて通信制御する。

一番セキュアなパターンとしては、内部ファイアウォールでそれを行うようなかたちが従来取られてきたような手法かと思います。

これを少し抽象化した絵を使って、この従来型の課題を表現したいと思います。先ほどVLANのところで分けていたようなネットワークのサブネットがあって、そのサブネットをいくつかまとめてセキュリティゾーンというかたちで定義します。

例えばフロントエンドゾーン、アプリケーションゾーン、データベースゾーンみたいな感じで分かれていて、その間を通信していく時に検査を行う。これがいわゆるチョークポイントでの検査になります。

このやり方だと、まず1つ目。同一のサブネット内、もしくは同一のセキュリティゾーン内は検査が行われないということで、昨今の高度な攻撃でランサムウェアに感染した場合、同一セキュリティゾーン内は容易に拡散が行われてしまうというのが1つ目の課題になります。

2つ目の課題は、通信制御は間に入っているファイアウォールでやりますが、超単純化したこの絵だけでも、3台のファイアウォールを通っています。

みなさんの企業は実際どうでしょうか？　この10倍から100倍の規模があると思うんですが、その数のファイアウォールに対して、ネットワークのIPアドレス、サブネット、もしくはポートなどを使ったルールを無数に書いていって、分散したルールを管理するというようなかたちは、私が現場にいた頃、もう15年以上前からネットワークセキュリティのやり方としてあり、当時から複雑性が課題視されていました。複雑になりすぎてしまうというのが2つ目の課題です。

3つ目は、こうやってオンプレだけでやっていなくて、複雑な管理をした上にAWSやAzureではVPCであったりセキュリティグループというような別の通信制御を行わなければならないということで、従来のやり方が破綻している。そんな中で攻撃が高度化しているので、内部通信をきちんと把握することも制御できなくなってきている。

エージェント型セグメンテーションの利点・欠点

そこで出てきたのがマイクロセグメンテーション技術です。今日は時間が限られているので、いろいろな種類のマイクロセグメンテーションのやり方を説明できないですが、やり方として、エージェントソフトウェアを入れて展開するというのが、弊社のGuardicoreのやり方になっています。

これが弊社だけではなくて、昨今利用が広がっているマイクロセグメンテーションの最も新しいかたちであり、かつ最も支持されているようなかたちです。

それがなぜかというと、先ほど挙げた3つの課題。同一のサブネットや同一のセキュリティゾーン内は検査ができないという課題は、エージェントを展開するというかたちを取るので、守りたい対象の端末単位、そして弊社の場合、さらにその中で動いているアプリケーションのサービスやプロセスの単位での制御まで可能になります。

それに加えて設計、設定が分散して、かつ複雑になるという部分も、エージェントとしては数をたくさんばらまく感じになりますが……。この後簡単に画面も見てもらいますが、これを全部1ヶ所から一元管理するので、全体としての可視性が得られて、設計、設定がむしろシンプルになります。

良いこと尽くめなことばっかり言っていると信用し難いと思うので、少し補足すると、設計の仕方とかが変わってくるので、そういった意味で最初に従来と変えることは発生しますが、その後に作ったものは全体を一元的に管理できるようになるという特徴があります。

3番目はエージェントを展開するというかたちなので、オンプレに縛られず、クラウド上であっても場所を問わずに展開できるということで、エージェント型のマイクロセグメンテーションが非常に支持されているようなかたちになります。

「Akamai Guardicore Segmentation」のシステム概要

このシステムの概要ですが、基本はエージェントソフトウェアをOS上にインストールするということで、仮想マシンであれ、ハードウェアサーバーであれ、IaaS、AWS、Azure、Google Cloudであれエージェントを入れるので、オンプレミスの場所に制限されることなく、どこでも展開できるようになっています。

話が複雑になってしまうのであまり深掘りできませんが、エージェントが入れられないような環境は、それはそれで収容できるようなエージェントレスの仮想アプライアンスを提供するとか、AWSとかAzureとAPIのほうで通信してエージェントレスでも制御するというような開発も行っているんですが、今日はいったん「Guardicoreはエージェントで制御する」という感じで把握してもらえればと思います。

「Akamai Guardicore Segmentation」の3つの特徴

このアーキテクチャを使って提供している弊社のソリューションの3つの特徴。今見てもらったのはエージェントが通信の管理を行うんですが、通信の管理というのは、「こことここの通信を許可するとか拒否する」とか、それだけを管理するシンプルなオーバーレイのレイヤーを作れる感じになっています。

これは何を言っているかというと、従来のファイアウォールとかを通信の中に入れるというかたちは、通信の疎通性、リーチャビリティと、それからその上で行うアクセス制御を同時に管理するという両面が同時にあって、非常にセンシティブな作業になっていました。Guardicoreでは、疎通は確保した上で、通信の制御のみを行うというようなかたちで、シンプルに管理できるようになります。

あとは、エージェントで展開しますが、そのエージェントの対応環境を非常に広く開発しているので、レガシーのUNIXベースなものから、DockerやKubernetesなどのコンテナの環境まで幅広くサポートが可能になっています。

3つ目が、この後のPoCの話にもけっこう出てくると聞いていますが、ラベルを使って属性を与えて、アイデンティティを与えて、それに応じた通信の制御を行えるのが1つポイントになっています。

ラベルのところだけ少し補足すると、今まで見ていたように、IPアドレスとかサブネットとか、そういうもので通信のルールをそういうもので定義していました。

例えばサーバー管理者視点だと、データベースサーバー、Webサーバー、DNSサーバーとか、そういったところからどこに対しての通信か。インフラ管理者だと、それが動いている環境、AWSとかオンプレとか、そこの間でどう通信が発生しているか。セキュリティ管理者の観点だと、脆弱性が出たような環境かどうかとか。

そういうさまざまな属性を割り当てて、それに応じて自社のネットワークを可視化して把握したり、もしくは通信制御ができるというのが、このラベル部分の強みになっています。

「Akamai Guardicore Segmentation」のデモ

最後にデモだけして、私のこの説明のパートは終わりたいと思います。（画面を示して）これが実際のGuardicoreの管理画面になっています。先ほどから繰り返し言っていた、「分散している環境の通信を全部見える化する」というのがこちらのイメージになっています。

ネットワークの可視化の技術はいろいろと存在していると思うんですが、このソリューションですごく強みがあるのは、「どことどこが通信しているか」という可視化の能力が非常に長けていることです。オンプレで動いているものもあれば、AWSで動いているものも混在しているんですが、「どことどこがエンドツーエンドで通信が行われているか」を容易に見ることができます。

（画面を示して）例えばこの「CRM-db」。こうやって見ると、CRMのデータベースに関しては、インターネットに向かって、「ポート 123」で時間を取りにいくようなプロトコルが動いている。あと「TCPポート 443」のHTTPSの通信が行われている。「CRM-web」っていうところからは「TCPポート 2701717」というところに通信が入ってきているということを見ることができます。

この間には、実際たくさんの通信機器が入っていますが、セキュリティ観点では間になにが入っているかというよりは、どことどこが通信しているかが非常に重要で、そこを可視化できます。

可視化の後に重要なのがラベルで、ここにいろいろな属性を割り当てることができます。Environment、つまり環境としてはProduction、本番環境ということだったり、アプリケーションとしてはCRM、役割としてはデータベースといった属性を割り当てることができます。

この属性を基に環境を整理すると、数十台あったサーバーの環境が集約されます。

ここにあるようなProduction、つまり本番環境の中に、先ほどのCRM-dbのサーバーも入っているんですが、ほかにも29台のサーバーが入っている。

（画面を示して）こうやって見ると、本番環境とインターネット、本番環境と開発環境、「どことどこが通信しているか」というのが、このラベルをもって必要なところに絞って、必要な観点で見ることができます。見ていくことで、ラベルをスタックできます。この本番環境には、ほかに6つのアプリケーションがある。

先ほど挙げたCRMには5個のサーバーがあって、その中にデータベースがあって、本番環境、CRMアプリケーション、Role:DBに先ほどのCRM-dbがある。同一のCRMアプリケーションのWebから来ているので、先ほどのWebから来ていた通信は、なんの問題もない通信であることがこれで容易にわかるかたちになります。