山野氏の自己紹介
金子春信氏（以下、金子）：ここから、PoCの内容について山野さんにお話しいただきたいと思います。
山野葉子氏（以下、山野）：ありがとうございます。ただいま紹介いただいた山野と申します。今日はこのような場でお話しする機会をいただき、Akamaiさま、本当にありがとうございます。
それでは私から、「Akamai Guardicore Segmentation」のPoCをした内容についてお話ししたいと思っています。はじめに簡単に自己紹介をします。私、株式会社大和総研のフロンティア研究開発センターに所属している山野葉子と申します。よろしくお願いします。
私のキャリアですが、まず大和総研に入社して、証券会社さま向けのオンライントレードのシステム開発に従事した後、企画部門で金融機関さま向けのDXソリューションの企画などに携わってきました。
フロンティア研究開発センターには2016年ぐらいから、セキュリティやDX、クラウド関係の先端事例の調査や検証などを行っています。また、プリセールスなどでお客さまのDXの支援をするようなこともあります。
私はセキュリティグループのリーダーを務めていますが、私自身はセキュリティのキャリアがまだまだ短くて。「会社に入ってからずっとセキュリティやっています」という方がけっこういて（笑）。私なんかはまだまだ勉強中の身です。
今日は私たちで行ったPoCについて、簡単ではありますが紹介したいと思います。
まずはじめに簡単に弊社とフロンティア研究開発センターの取り組みについて2、3分時間をいただいて紹介した後、「Guardicore SegmentationでこんなPoCをしました」という話をできればと思います。
株式会社大和総研について
山野：株式会社大和総研という会社ですが、大和証券グループの中の1社になっていて、システム部門、リサーチ部門、コンサルティング部門の3部門からなる会社です。大和証券グループ各社、および大和証券グループ以外のお客さまに向けて、DXのソリューションや基幹業務ソリューション、IT基盤のソリューションなどを提供する会社です。
いずれも大和証券向けの取り組みにはなりますが、最近では、ゼロトラストセキュリティの導入をしたり、「ChatGPT」の導入支援するような取り組みを弊社でしています。
私の所属するフロンティア研究開発センターですが、大和証券グループのR&Dの位置付けの部門になっていて、産学連携や海外IT企業さまとの技術協力を行ったり、あるいは国内大手のIT企業さまと連携したり、ITリサーチを行ってお客さまに紹介したりしています。
また、私自身はセキュリティのグループに所属しているんですが、昨今ではサイバー攻撃の状況や対策を季刊でお客さまに紹介するようなレポートも行っていて、私も記事を執筆したりしています。
セキュリティの業界に深く足を踏み入れている方は、たぶん知っている内容ばかりになっているんですが、セキュリティをやっていない部門からセキュリティの部門に急に来て、勉強中の方もいるかなと思うんです。
そういった方に向けて、我々はリサーチの部門も持っているので、「法制度の観点からこういうような取り組みを政府は推進しているよ」ということであったり、「最近こんなインシデントが起きているので、セキュリティの業界に携わる人なら押さえておいたほうがいいよね」というようなトピックスの紹介をしています。（スライドを示して）QRコードからアクセスしてもらえればと思います。
PoCに至るまでの経緯
山野：前段が長くなってしまって恐縮ですが、Akamai Guardicore SegmentationのPoCについて紹介したいと思います。
まずPoCに至る経緯です。我々は研究開発部門になっているわけですが、クラウドに移行するとか、あるいはテレワークが普及して、弊社グループの中でも2in1端末という端末を配り、「どこでも仕事ができますよ」というような話をしているんですが、そういったゼロトラストの仕組みを導入すると、アクセスの制御要件が非常に複雑になってくるような課題感が（現場部門には）あります。
また、先ほど金子さんのほうから説明いただきましたが、ネットワークの管理って非常に複雑で、IPアドレスのリストを見せられても、なんだかよくわからないという点、つまりネットワークの可視化には非常に課題感を持っていました。
より細かい単位でアクセス制御を実現する手段として、先ほどエージェント型のマイクロセグメンテーションの製品の紹介がありましたが、2021年ぐらいからマイクロセグメンテーション製品の調査を実施し、製品の比較を行った上でAkamaiのGuardicore SegmentationのPoCの計画に着手したという状況です。
その他の課題の認識としては、先ほど金子さんからも紹介があったとおり、最近のサイバー攻撃は標的型攻撃が非常に増加していて、ゼロトラストの環境による対策は広く求められていると感じています。
例えば、最近はサプライチェーンのリスクがあります。従業員や外部委託先に貸与したデバイスは本当に管理しきれているのか。その端末がマルウェアに感染してしまった場合、端末間の通信による被害の拡大、予期せぬ情報漏洩の発生などのリスクに対して、我々としても強い課題感はありました。
PoCの目的とスコープ
山野：PoCの目的とスコープについて2点設定しました。先ほどから「ネットワークの可視化」と説明いただいていますが、「本当に可視化できるのか？」「すごく大変ではないのか？」という疑問。次に取引先のアクセス制御、例えば業務で利用するシステムごとに個別のアクセス権を柔軟に付与したいというようなケースに対してこの製品がどの程度有効に使用できるのか検証をしました。
（スライドを示して）PoCのスコープとして記載していますが、我々の社内環境を使い、先ほど紹介があったAgentをクライアント端末や社内システムのサーバーに導入しました。Aggregatorでそれらの通信を集約し、Managementという管理コンソールで通信状況を確認します。いずれも仮想環境の構成で検証しました。
PoCの結果
山野：PoCの結果ですが、非常に良い製品だと感じてこの場でお話しをさせてもらっています。「いい製品でした」と言うのもちょっと出来が良すぎるんじゃないかという話ですが（笑）。率直に言って、我々は非常にそう感じました。
ネットワークの可視化では、やはり実態の把握がしやすい、つまり視認性や可読性が高いという点。またエビデンス、あるいは証跡としての利用価値があるのではないか。結果として内部アタックサーフェスの減少につながるような対策を取ることができる製品だと感じています。
またアクセス制御に関しても、（社外の人に対して）特定の要件で、かつ特定のシステムだけを使わせたいケースを想定してPoCをしたのですが、そういうようなケースに対しても、本当にネットワークの作業が不要で、「ボタン1つで」はちょっと大袈裟になりますが、先ほど紹介があった設定画面からできるというところが、PoCの結果になっています。
まずネットワークの可視化から話すと、先ほども話がありましたが、通常、ネットワークの通信要件というのは、弊社であれば開発やお客さま先の要件として、「この端末からこのサーバーに関しては、こういう通信をしてほしい」とか、「このサーバー間であればこの通信は許可してほしい、あるいは拒否してほしい」という通信要件をネットワークチームに渡し、ネットワークチームがそれに基づいて設定作業をするというような流れになっています。
依頼元からすると、例えば疎通確認をして、「この通信は通っている」「通したくないところには通っていない」という確認はできるのですが、アクションとしての確認はできても、「本当にそれだけか？」という全量は把握が難しいものでした。
したがって、作業はしてくれているが、通信レイヤーの大量のログを見せられてもいまいち納得感が得られなかったのが実状です。
この製品を利用すると、依頼どおり本当に通信が通ったのか、また不要な通信が発生していないのかを、先ほど金子さんからも紹介してもらった画面によって、本当に一目でわかるようになったというのが（スライドの）右側の図になります。
ラベルの機能が我々は本当に優れていると感じていて、ExcelのIPアドレスが書かれている通信のリストを見ずとも、こちらが伝えたい要件どおりに通信ができているのか、できていないのか、その他の通信が遮断されているのかを簡単に見ることができるというところが非常に優れた製品であると感じました。
結果として内部アタックサーフェスを減少させられるという話ですが、「そんなのは設定でやりなさい」ということは正論としては非常によくわかる。我々もそれをする努力はもちろんあるわけですが、プロセスとかポートレベルで見ると、不要な通信はどうしても存在する。
ネットワークのチームの方と話すと、遮断する判断が非常に難しい。「何かでもう使っているかもしれない」という懸念が出てきてしまい、なかなか判断できない。
ただ、前のセッションでも話があったとおり、不要な通信経路の存在は攻撃対象領域、アタックサーフェスを無駄に広げてしまうようなリスクがあるので、これはなるべく遮断させたいです。
この製品は、ラベルの機能により通信がわかりやすく可視化されるため、「この通信が必要だ」とか、「この通信は必要ではなかった」というような通信の遮断の可否を容易に特定して判断することができると考えています。
最初はアラートモードで動作させて、「本当に必要ない」と判断できたらブロックするというような設定を画面のコンソールから簡単にすることができるということで、非常に効果的な製品であると感じました。
ネットワークが仮想化されていたとしても、物理の作業が残ってしまうレイヤーはどうしてもあります。そういったところで、従来であればネットワークの作業となると、コストであったり時間であったりが非常にかかってくるというところで、ビジネスを加速させることができるような製品なんじゃないかなと感じました。
（2つ目の目的であった）「特定の要件で社外の人に対してシステムを使わせるようなケース」を我々はPoCで検証しました。（背景としては、）我々が社内から「土曜日が出勤」の申請をした場合、社外のビルの管理の方にその申請を見せたいが、他のシステムはアクセスさせたくない、という要件がありました。
つまり特定のシステムは外部の人にもアクセスさせたい。でも、例えばファイルサーバーやインターネットの閲覧のようなことはさせたくないという要件があった場合に、利用する人のエージェントに対してルールを設定してさえあげれば、この要件を簡単に実現できます。
おそらく従来のやり方であっても実現はできたとは思いますが、この製品を使うことでよりシンプルに、簡単にできるというところが、我々としては非常に便利な製品だなと感じました。
「先ほどから褒めてばかりじゃないか」というところですが（笑）。「この製品はすごく細やかな設定ができます」という話をしていますが、まさにポリシー設計が非常に難しいとも感じていて、細やかな設計ができてしまうがゆえに、細かく設定してしまうとやはり管理が大変になる。
多くのサーバーを運用していくにあたり、先ほどから紹介があるラベル機能などの仕組みを、どう効果的に使っていくのかが、この製品を活用する上では非常に大切であろうと感じています。
PoC全体を通じて「Akamai Guardicore Segmentation」はとても良かった
山野：PoC全体を通じて、可視性の観点、あるいはアクセス制御の観点から、ユーザビリティについてお話しします。先ほど金子さんから紹介があったデモの場面を見て、「ふーん」と思っている方も多いのではないかと思います。
我々も、まさに自分たちの社内のシステムがあのようなかたちで管理されています。（加えて、）データセンターも複数あるので、ラベルを割り当てて、拠点間の通信を視覚的に確認できました。
一部の機能について、日本語が未対応でしたが、利用上は特に弊害は感じませんでした。
機能性の観点からお話ししているラベルやポリシー設定が、プロセス、プロトコル、ポートのレベルで通信が可視化されるのが非常におもしろいなと思っています。
また、保守運用の観点から、機能面で「もう少しこういう機能があったら良い」というものはありました。ほかにはエージェントのインストールについては、心理的な障壁がどうしてもありました。
しかし、インストールされた端末についても、CPUの使用率、あるいはメモリの使用率についても、そこまで大きく上振れするようなものでもありませんでしたし、パフォーマンスへの影響は非常に軽微なものでした。
コンポーネントのインストールの手順なども、Akamaiさまから提供いただいたものが非常にわかりやすかったので、我々としては特にPoCをするに際してハードルを感じることなくできました。
今後の展開として考えていること
山野：総評と今後の展開ですが、我々はこの製品でネットワークの可視化や侵入前の予防、侵入後の対応、つまり侵入してきた通信に対して、「この通信が悪いんだ」というところを即座に判断できるため、Webの画面から（当該通信を）ブロッキングできることは非常に役に立つ製品だなと感じました。
また、想定される導入障壁として、先ほどもお話しした「エージェントのインストールは避けたい」という点は、我々のお客さまと話をしていてもどうしてもある抵抗感なので、こちらについてはPoCなどを検討して、実際に自身の環境で検証するのが良いと思います。
ラベル、ポリシーの設計は非常に肝要で、この部分は簡単ではないなと感じます。設計や運用を考慮すると、「ラベルはどの単位で付けてるのか？」「業務的な観点からどの通信が必要なのか？」、その両方の知見のあるメンバーが、導入の際はプロジェクトにジョインする必要があるだろうと感じています。
我々はこの製品をひとまずPoCとして検証しましたが、社内システムがオンプレで動いている部分がまだあります。これらはクラウド移行を予定していますが、オンプレの環境の中でどういう通信が発生しているかを可視化する上で、まず利用していこうと考えています。インストールされているエージェントの数を徐々に増やし、実運用での効果検証を計画しています。
私が話すセッションはこれでおしまいです。ご清聴ありがとうございました。
