Zero Trust Networkで実現するアプリケーションサービス

Zero Trust Networkで実現するアプリケーションサービス

伊藤悠紀夫氏：みなさんこんにちは。F5の伊藤と申します。私も実はテーマが同じで、Zero Trust Networkのアーキテクチャの部分です。前半は概要をお話しさせていただきまして、後半は実際にやってみたということで、1つのサンプルの実装例をご紹介させていただきたいと思います。よろしくお願いいたします。

まず簡単に自己紹介をします。F5でソリューションアーキテクトを担当している伊藤と申します。実は今も関西に在住していまして、今日も出張で東京に来ております。

仕事柄全国を飛び回っておりまして、移動するとけっこう肩が凝っちゃうんです。実は私の週末の楽しみはスーパー銭湯です。いわゆる温泉に行くことを趣味とさせていただいています。

ほぼ5年間毎週欠かさず、必ず土日はどこかのスーパー銭湯に行っていまして。先日も実は年明けから行ってきました。みなさんスーパー銭湯は行かれますか？　あまり行かないですかね。

けっこうスーパー銭湯でイベントをやってまして、そこでガラガラ抽選会とかやってるんです。実は1週間前に当たりまして、岩盤浴の回数券が当たってしまったんですね！　なのでまた行くしかないということで、いい理由ができたなというのが、最近の私の中でのうれしいニュースです。

一方で実は悲しいニュースが今日ありました。こちらのイベントに1時間ほど早く着いちゃったので、そこのカフェでパンを買おうとしたら、「ここはPayPayしか受け付けておりません。現金ダメです」と言われました。ガーンと（笑）。

私はまだPayPayに登録してなかったので、そこで登録させていただきました。もしまだPayPayに登録されていない方がいらっしゃいましたら、ぜひ登録いただければと思います。なんのコマーシャルかよくわからないんですけれども（笑）。

Zero Trust Networkとは何か

では本題に入ります。今日はZero Trust Networkということで、Microsoftの吉松さんからも概要の説明がございましたが、私のほうからも改めて簡単にご紹介させていただきます。

まずこちらの絵をご覧いただきたいと思います。

この絵をパッと見て「あ、行ったことある」という方がいたらびっくりするんですけれども。何かと言うと、ある中東で造られた、丘の上に建っているお城のイメージになります。

当時戦国時代で、敵の侵入を防ぐために大きなお城を建てて外と中を分けていました。そちらのイメージ図を用いて、こちらの写真を持ってまいりました。

この絵で申したいことは、ネットワークの世界ですと、このお城がいわゆるファイヤーウォールになります。みなさん外と中で、一般的にはファイヤーウォールを作ってアクセス制限をしています。

当時の戦国時代もそういったかたちで堅牢なお城、ファイヤーウォールを作っていたんですが、のちほどのお話でこのお城は陥落します。実は外からのアクセスではなくて内部でクーデターが起こってしまいました。要は残念ながらお城の中から、内部犯行的にといいますか、侵入されて陥落したという歴史がございます。

このお話をZero Trustとどう結び付けるか。いわゆるZero Trustという考え方ですと、先ほどのお城の外と中には境界は関係ありません。中にいても信頼してはいけない。

先ほど境界線という言葉が出てきましたが、境界線に関係なく、何かサービスとかアプリケーションにアクセスするときには、「本当にその人は信頼されていますか？」「場所に関係なくすべてチェックしたほうがいいのでは？」という考えることがZero Trustの基本的な方針になります。

今までのネットワーク、インフラの内部アクセスですと、先ほどオレオレ詐欺とかすごくいい例がありましたが、性善説に基づいて作られているケースが非常に多いんです。

例えばみなさんの会社の中のネットワークであれば、まさか悪さをする人はいないと思って、会社の中ででかいファイヤーウォールを作ってアプリケーションを制限しているかと言うと、必ずしもそうではないと考えられます。でも実際に最近のセキュリティのインシデントを見てみますと、残念ながら内部犯行が多くて、かなり大きな被害を受けてしまうというニュースが増えております。

実際のセキュリティのインシデントを少し掘り下げてみますと、例えば標的型攻撃のメールを誤ってクリックしてしまうと、内部のパソコンが感染してしまいます。そこから不正ログインされて個人情報が抜き取られてしまう。

内部からのアクセスなのでとくにWebアプリケーションファイヤーウォールや多要素認証ログインもないので簡単に漏れてしまう。「内部ネットワーク、本当に安心ですか？」という提唱が基本的な考え方です。

一方で境界線のネットワークという観点で考えますと、日々みなさまがアクセスしているアプリケーションはどこにありますか？　昔はプライベートのオンプレミスだけだったかもしれませんが、今はさまざまなパブリッククラウドですとか、あるベンダー様のクラウドサービス上にある場合もあります。

そしてアプリケーション自体も仮想マシンからコンテナ、マイクロサービスといったかたちでいろいろな場所に散らばっている状態です。このバラバラな中でそれぞれ境界線を作って違うポリシーでアクセス制限をするかというと、そこは課題になってきます。

Zero Trustアーキテクチャ

こういった中で、Zero Trust自体は実は今から9年前にForresterというリサーチ会社のJohnという方が提唱したものになります。

繰り返しになりますが考え方自体は、ちょっと刺激的なキーワードですけれども、「ネットワークは、常に敵意に満ちている」。

要は「信頼してはいけません」「内部からのアクセスであっても二要素認証をするなど、信頼情報を得たうえでアクセスをしたほうがいいのでは？」と提唱されています。

アクセス元というと、一般的には我々一人ひとりの人間を考えるんですが、この考えの中では人間・ユーザーだけでなく「どんなデバイスからアクセスしていますか？」もしくは「ふだんと違う場所からのアクセスですか？」といった「さまざまな複合要因」を使って信頼情報を確認するという考えが提唱されています。

具体的に「さまざまな複合要因」とは何かと申しますと、現実社会で考えると住宅ローンの審査だと思ってください。みなさまが住宅ローンの審査を受けるときにどういう評価をされるかというと、「どれくらいの年収をもらっていますか？」「ほかに借金ありますか？」「家族構成どうなってますか？」といったいろんなメトリックで住宅ローンの審査が下りてます。

それとまったく同じ考え方で、ID・パスワードだけではなくて、「会社支給のパソコンですか？」「個人のパソコンですか？」もしくは「日本からアクセスしてますか？」「海外ですか？」といったさまざまなメトリックに点数を付けるんです。

この例ですと、「ユーザーが合っていれば10点」「正式なデバイスであれば10点」、そして「50点以上入手したアクセス元であればこのアプリケーションにアクセスさせよう」と。これが信頼度スコアという考え方になります。

トラフィックのセキュリティ化

そしてそのとき認証済みと認定されたユーザーもしくはデバイスですが、ちゃんと暗号化されたうえでその処理はされているかが大事なファクターになります。

「アクセス元とアクセス先がすべて暗号化保護されていること」ということで、一般的なWebアプリケーションですとインターネットから内部に入るときに443番SSLで保護されています。

ただ内部に入って、例えばなんらかのWebサーバー、……シンプルに申しますとApacheにアクセスするときに、「そこは80番で通信されていませんか？」「SSLオフロードは内部でされていますか？」というのは昔の考え方です。

Zero Trustですと、境界線ベースで暗号化をやめるのではなくて、内部のアクセスであっても常にEnd to Endで、やはり443番SSLで保護したほうがいいという考え方があります。そのあたりが信頼モデルの変更ということで、双方向でSSLで保護しましょうということを提唱されています。

時間がありませんので、このあたりはスキップさせていただきます。

これはネクストジェネレーションファイアウォールの一例です。製品によっては先ほどのユーザーIDとデバイスを使ってファイヤーウォールのルールを定義し、アクセス制御を行う製品を出されているメーカー様もいらっしゃいます。これはファイヤーウォールの設定の一例になります。

どうやって実現するか？

ではここから「実際にどうやって作るんですか？」というお話に入ってまいります。アーキテクチャを考えたときに重要なファクターとしては、先ほど申しましたユーザーとデバイスのチェック。それからその間のネットワークの暗号化のチェック。そして「アクセスするサービス自身がちゃんと動いてますか？」「死んでませんか？」というヘルスチェックの3つが重要なファクターになります。

ここから若干アーキテクチャの絵が出てきます。実はいま申しましたZero Trustを支えるPaaSです。今日は最初のセッションでも「PaaSすごい！」という話があったんですけれども、こういうPaaSがあります。具体的には先ほどのセッションで説明いただきましたAzureですね。Azureでも実はもうPaaSのサービスがございます。

こちらを使っていただきますと、先ほどの信頼度スコアなどをチェックしたうえでクラウドサービスにアクセスしたり、オンプレミスのアプリケーションにアクセスすることができるというアーキテクチャになっております。

しかし私はこの絵を見てずっと1つだけ疑問に思っていました。それはここです。

PaaSのサービスを使ってクラウドにアクセスするときはいいんですが、どうやってPaaSから社内のオンプレのアプリにアクセスしますか？　

もちろん「事前にL2トンネリングで結んでますよ」ということであればいいんですが、L2で結んであると全体でアクセスしてしまいますので、どうやってアプリケーション単位に制限するのかがわからなかったんですよ。

実際にやってみた

ということでやってみました。先ほどのセッションで「この絵出るかな？」と心配していたんですが、出なかった。被らなくてよかったということでちょっと安心しているんですけれども。

MicrosoftさんのPaaSの例でお話をさせていただきますと、実はMicrosoft Azure Active Directory条件付きアクセスというものがサービスとして提供されていらっしゃいます。

これは何かと言うとAzureのクラウドサービスの中にみなさんのID・パスワードを同期します。オンプレにもしID・パスワードがあればまず同期します。

その条件として、例えば私伊藤であれば、「日本からアクセスしてますか？」それとも「会社のパソコンからアクセスしてますか？」といった条件のルールをコードに書いちゃいます。

その条件によっては証明書の提示を求めたり、もしくは必要なアプリに許可をさせなくするといったところをクラウドで管理する。これがMicrosoft AzureのActive Directory条件付きアクセスというものになります。

「ここにVPNを絡めたいときどうしますか？」ということで、こちらはMicrosoftさんのホームページから拝借したんですが。

この絵で言うと5番目の「VPNサーバーとどうやって連携するのかな？」ということで実際にテストしてみました。

簡単な流れをご紹介させていただきますと、VPNを使って社内のアプリにアクセスしたいときに1回MicrosoftのAzureにアクセスできます。ID・パスワードを入れて、デバイスのチェックもAzure側で行います。

それが終わるとクライアント自身を証明するクライアント証明書を内部のローカルストアに保存します。そしてその証明書を使ってVPNサーバーにアクセスします。調べてみるとこのようなフローでアクセスしていました。

ただこれを見てもなかなかイメージがつかないと思いますので、ちょっとスナップショットを撮ってきました。これはWindows10で試したときのスナップショットなんですが、どういう動きになるかと言うと……。

まず普通にVPNアクセスをします。通常であればID・パスワードを入れる画面が出るんですが、Azureにログインするときの「サインインしましょう」という画面が出ます。ここでふだんみなさんが使っているメール・パスワードを入力します。

そうすると条件によっては私のモバイル端末にワンタイムパスワードが来まして、さらにそれを入れてOKと押すとVPNにつながるといった仕組みになります。

この仕組みをうまく使っていただきますと、先ほどのPaaSを使ったZero Trustに応じた認証にしたがってクラウドサービスやオンプレサービス、同じセキュリティポリシーにアクセスできるようになりました。こちらが1つのアーキテクチャになります。

サービスメッシュ間のセキュリティ

「F5はどう絡んでるの？」ということで、あまり絡んでいないんですが……、今回の例で言うとVPNのサーバーでうまくZero Trustに沿ったかたちでご利用いただくことができますということが1つのアプリケーションになります。

ここまでがZero Trustに関するお話になります。お時間があと1分ほど余ってますので簡単にこのスライドだけご紹介させてください。今のお話は実際にアプリを使う方がネットワーク上のZero Trustセキュリティを実装する方法でした。

ただ「アプリケーション間のセキュリティってどうするんですか？」と。とくにサービスメッシュですね。「コンテナ間の通信ってどうやって管理するんですか？」という疑問がおそらく出てくると思います。

みなさんご存知のとおりISTIOというオープソースのツールがございまして、こちらを使っていただきますとサービスメッシュ間の可視化ができます。ただ文献を読んでもよくわからなかったので実際にやってみました。

やってみるとこういったかたちで、ISTIOという本のレビューのサンプルアプリがあるんですけれども、そちらがどういうふうに動いているのかとか、「どこのコンテナといいますか、サービスが遅延していることによってサービス全体に影響が出ているのか」を可視化することができます。こちらがISTIOの基本的な概要になります。

可視化をして、この下の赤になっている部分がおかしいなと思ってダブルクリックをすると、詳細ログが出まして。「ああ、ここが何ミリセック遅延しているので問題でしたね」といったことを視覚的に確認することができるようになっております。

OSSですので、すぐに試していただくことができます。ご自身ですぐこの環境をビルドするのが難しい場合は、この上にBETAと書いてあるんですけれども、我々はAspenMeshというパッケージのようなものを作成しておりまして、ベータ版で無償公開しています。気軽に触ってみたいなということがあれば試していただければ幸いでございます。

ということでお時間になりました。Zero Trustセキュリティ、「誰も信頼してはいけない」とはなかなか言いづらいんですけれども（笑）。セキュリティを大事にしましょうということで、本日の私のセッションは終了とさせていただきます。ありがとうございました。

（会場拍手）