2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
Zero Trust Networkで実現するアプリケーションサービス(全1記事)
リンクをコピー
記事をブックマーク
伊藤悠紀夫氏:みなさんこんにちは。F5の伊藤と申します。私も実はテーマが同じで、Zero Trust Networkのアーキテクチャの部分です。前半は概要をお話しさせていただきまして、後半は実際にやってみたということで、1つのサンプルの実装例をご紹介させていただきたいと思います。よろしくお願いいたします。
まず簡単に自己紹介をします。F5でソリューションアーキテクトを担当している伊藤と申します。実は今も関西に在住していまして、今日も出張で東京に来ております。
仕事柄全国を飛び回っておりまして、移動するとけっこう肩が凝っちゃうんです。実は私の週末の楽しみはスーパー銭湯です。いわゆる温泉に行くことを趣味とさせていただいています。
ほぼ5年間毎週欠かさず、必ず土日はどこかのスーパー銭湯に行っていまして。先日も実は年明けから行ってきました。みなさんスーパー銭湯は行かれますか? あまり行かないですかね。
けっこうスーパー銭湯でイベントをやってまして、そこでガラガラ抽選会とかやってるんです。実は1週間前に当たりまして、岩盤浴の回数券が当たってしまったんですね! なのでまた行くしかないということで、いい理由ができたなというのが、最近の私の中でのうれしいニュースです。
一方で実は悲しいニュースが今日ありました。こちらのイベントに1時間ほど早く着いちゃったので、そこのカフェでパンを買おうとしたら、「ここはPayPayしか受け付けておりません。現金ダメです」と言われました。ガーンと(笑)。
私はまだPayPayに登録してなかったので、そこで登録させていただきました。もしまだPayPayに登録されていない方がいらっしゃいましたら、ぜひ登録いただければと思います。なんのコマーシャルかよくわからないんですけれども(笑)。
では本題に入ります。今日はZero Trust Networkということで、Microsoftの吉松さんからも概要の説明がございましたが、私のほうからも改めて簡単にご紹介させていただきます。
まずこちらの絵をご覧いただきたいと思います。
この絵をパッと見て「あ、行ったことある」という方がいたらびっくりするんですけれども。何かと言うと、ある中東で造られた、丘の上に建っているお城のイメージになります。
当時戦国時代で、敵の侵入を防ぐために大きなお城を建てて外と中を分けていました。そちらのイメージ図を用いて、こちらの写真を持ってまいりました。
この絵で申したいことは、ネットワークの世界ですと、このお城がいわゆるファイヤーウォールになります。みなさん外と中で、一般的にはファイヤーウォールを作ってアクセス制限をしています。
当時の戦国時代もそういったかたちで堅牢なお城、ファイヤーウォールを作っていたんですが、のちほどのお話でこのお城は陥落します。実は外からのアクセスではなくて内部でクーデターが起こってしまいました。要は残念ながらお城の中から、内部犯行的にといいますか、侵入されて陥落したという歴史がございます。
このお話をZero Trustとどう結び付けるか。いわゆるZero Trustという考え方ですと、先ほどのお城の外と中には境界は関係ありません。中にいても信頼してはいけない。
先ほど境界線という言葉が出てきましたが、境界線に関係なく、何かサービスとかアプリケーションにアクセスするときには、「本当にその人は信頼されていますか?」「場所に関係なくすべてチェックしたほうがいいのでは?」という考えることがZero Trustの基本的な方針になります。
今までのネットワーク、インフラの内部アクセスですと、先ほどオレオレ詐欺とかすごくいい例がありましたが、性善説に基づいて作られているケースが非常に多いんです。
例えばみなさんの会社の中のネットワークであれば、まさか悪さをする人はいないと思って、会社の中ででかいファイヤーウォールを作ってアプリケーションを制限しているかと言うと、必ずしもそうではないと考えられます。でも実際に最近のセキュリティのインシデントを見てみますと、残念ながら内部犯行が多くて、かなり大きな被害を受けてしまうというニュースが増えております。
実際のセキュリティのインシデントを少し掘り下げてみますと、例えば標的型攻撃のメールを誤ってクリックしてしまうと、内部のパソコンが感染してしまいます。そこから不正ログインされて個人情報が抜き取られてしまう。
内部からのアクセスなのでとくにWebアプリケーションファイヤーウォールや多要素認証ログインもないので簡単に漏れてしまう。「内部ネットワーク、本当に安心ですか?」という提唱が基本的な考え方です。
一方で境界線のネットワークという観点で考えますと、日々みなさまがアクセスしているアプリケーションはどこにありますか? 昔はプライベートのオンプレミスだけだったかもしれませんが、今はさまざまなパブリッククラウドですとか、あるベンダー様のクラウドサービス上にある場合もあります。
そしてアプリケーション自体も仮想マシンからコンテナ、マイクロサービスといったかたちでいろいろな場所に散らばっている状態です。このバラバラな中でそれぞれ境界線を作って違うポリシーでアクセス制限をするかというと、そこは課題になってきます。
こういった中で、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セキュリティ、「誰も信頼してはいけない」とはなかなか言いづらいんですけれども(笑)。セキュリティを大事にしましょうということで、本日の私のセッションは終了とさせていただきます。ありがとうございました。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには