CLOSE

シンプルに考えよう Zero Trust Network(全1記事)

NoOpsの視点で考える、Zero Trust Networkとセキュリティ

2019年2月5日、NoOps Japan Communityが主催する勉強会「NoOps Meetup Tokyo #4」が開催されました。「システム運用保守の"嬉しくないこと"をなくそう!」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有します。プレゼンテーション「シンプルに考えよう Zero Trust Network」に登壇したのは、日本マイクロソフト株式会社クラウドソリューションアーキテクトの吉松龍輝氏。講演資料はこちら

シンプルに考えよう Zero Trust Network

吉松龍輝氏:今からのお時間は、Zero Trust Networkについてのお話です。今日お集まりのみなさんはどちらかと言うとデベロッパー寄りの方が多いんじゃないかと思いますが、僕のセッションはどちらかと言うとややインフラ寄りの話になります。なるべくインフラの難しい話にならないようにセッションを用意したので、軽い気持ちで聞いていただければと思います。

MicrosoftでAzureのアーキテクトをしている吉松と申します。インフラ寄りのアーキテクトではあるんですが、もともと僕はサポート部門でWindowsのバグフィックスに関わる仕事をしていました。

日本マイクロソフトはサポート部門にWindowsのソースコードのアクセス権を持ってる人がいるんですね。僕はWindows NT4 Server から Windows Server 2008まで、自分のデスクトップにソースコードが入っていて、コードを見ながらWindowsのデバッグをしたりダンプを解析したりしていました。それで「あ、バグだな」というものがあったらMicrosoft本社のR&Dに「こういうふうに直してくれ」と依頼をする「CPR (Critical Problem Resolution) というチーム」というのがありまして、そこでWindowsのエスカレーションエンジニアをしてました。

そのあといろいろ役職が変わったんですけれども、今はAzureのアーキテクトをやっております。実は僕はMicrosoftに3回入社をしていまして、最近の入社が去年の11月でした。その前はパロアルトネットワークスというセキュリティの会社で、クラウドセキュリティのアーキテクトをしていました。なのでちょっとセキュリティもできます。

Azureのコミュニティだとたまに「メタル先輩」と呼ばれるんですけど、僕がデスメタルのバンドをやっているので、そのようなニックネームで呼ばれています。

もともとパロアルトネットワークスでクラウドアーキテクトをやっていたということもあるんですが、このNoOps Meetupの運営をされている川崎さんから「Zero Trust Networkのセッションをやってくれませんか」と依頼があって、「いいですよ」ということでこの時間をいただきました。

このスライドは、川崎さんと、先ほどオープニングでお話しをされていた岡さんのJapan Container Daysのセッション「NoOpsが目指す未来とコンテナ技術」のスライドから拝借したものになります。

このセッションの中で、「NoOpsを実現するにあたりセキュリティを考えなくちゃいけません。そこでセキュリティを考えるときに、Zero Trust Networkという考え方があるらしい。それはネットワークには常に敵が潜んでいて、通信は暗号化されデータも暗号化され……こういう世界を作ることができればNoOpsな世界の実現に近づけるんじゃないか」というお話があり、今回 Zero Trust Network について話をする機会をいただいたという経緯があります。

Zero Trust Networkの考え方

Zero Trust Networkにおいては「境界線」という考え方と「Zero Trust」という考え方があります。

境界線はいわゆるセキュリティの境界です。セキュリティの境界ごとにインフラ・アプリを構築・設計するというのが今までの考え方でしたが、「ネットワークの境界による防御」という考え方に価値がないとするのが、Zero Trustという考え方になります。

今日はネットワーク構成のような話は考慮せず、もっとシンプルに考えて、「Zero Trust Networkというのはそもそも何だろうか?」というところからお話しして、「じゃあNoOps的にZero Trustな世界を作るにはどうしたらいいのか?」という、入門編のお話で構成しています。

例えばこのスライドはAzureのネットワークの構成図なんですが、こういう構成図を読むのが苦手な方でもZero Trust Networkの考え方を説明できるようになるのが今日のゴールです。

「境界線」とはなにか?

「境界線」という考え方を身近な例で考えてみるところからお話しします。一番身近な境界線の例ですと、これは日本とお隣の韓国の地図になりますが、国境という考え方があります。

地理的な境界線は国境になりますが、ここにパスポートの絵も載せていますが、人にフォーカスした場合の境界が国籍です。

これをIT的に考えると、人の境界とはIDマネジメントで表すことができ、つまりID基盤で境界がわかれるということになります。一方で地理的な境界とは、いわゆるネットワークのセグメントという考え方です。

地理的な境界・国籍の境界は現実の世界にもある考え方ですが、一般的に従来から言われてるセキュリティの「境界」という考え方をちょっと絵にしてみます。

これはAzureのアイコンですが、1個1個がネットワークのセグメントだとイメージしていただければと思います。

韓国のネットワークと日本のネットワークの間に海があります。ネットワークの間の共有部分には世界共通のルールがあります。現実の世界だと、例えば韓国と日本の間では密入国の監視が行われています。国をまたいだ不正な行き来の監視が行われているわけですね。国をまたいでいる境界線、いわゆる国境の監視が、代表的なセキュリティの考え方になります。

一方で、パスポートという考え方を持ってくると、日本のパスポートは日本国が「あなたは日本人です」と証明するためのID基盤です。韓国にも国が発行するパスポートがあります。パスポートというIDの考え方が、日本と韓国でそれぞれあるんですね。

そして、このパスポートというIDマネジメントの考え方では、日本は韓国の、韓国は日本のルールを、お互いに尊重しようという信頼関係を持つことで、お互いにビザを発行することができます。パスポートという世界共通のID基盤の考え方に基づき、お互いにビザを発行することで自由に行き来ができるようになるというのが、実際にある仕組みです。

IDという考え方がないと単純に密入国の監視だけになってしまうんですが、IDという考え方を入れると、お互いに境界をまたいで行き来ができるようになる。これがセキュリティ境界の考え方です。

境界の周辺で起こる問題

境界をまたいで起こる問題としては、ニュースを見ていてもお感じになると思いますが、悪意を持った行為が多いと思うんですね。

いわゆるテロ行為や、このスライドには「薬物」と書いてありますが、禁止されているものの密輸、あとは情報を盗むといったスパイ活動が挙げられます。

境界をまたぐときの行為は、自分側と相手側で立場が違うといいますか、世界が違う人たちがお互いにやり取りをするので、悪意を持った攻撃が多い。これが境界をまたいで起こる問題ですね。従来の境界を意識したセキュリティは、「境界をまたいで行われる不正行為を防ぎましょう」という考え方です。IT的に考えますと、盗聴やデータの漏洩を境界の外にいる悪意を持った人から防ぎましょうというような考え方です。

一方で、境界の中で起こる問題もいくつかのパターンがあります。

1つは悪意がある人からの攻撃の話で、「境界内の同じ仲間だと思って安心してたら騙された」といったケースです。

代表的な例がオレオレ詐欺です。あたかも自分の家族のように電話をしてきて、「お金がなくて困っている」と言う。それに対して「ああ、わかったわかった」と、家族が困っているんだったらお金を用立ててあげようと思って振り込んだものの、実は電話してきた相手は家族じゃなかったというのがオレオレ詐欺です。同じ家族という境界内の人だと思ったら実は違ったというパターンの1つですね。

もう1つは「うっかりやらかした」というパターンです。これは悪意をもってやらかしたわけではなく、うっかり失敗してしまったというものです。(現実世界の)例としてはタバコの不始末などが挙げられます。

このように、境界をまたいで起こる問題と、境界の中で起こる問題では質が違うものが多いんですよね。結果的には何かが盗まれるとか、何かが壊れるということは同じかもしれないんですけど、そこに至るまでのプロセスが違うというのが、境界をまたぐ問題と境界内の問題の違いになります。

「なにか起こるかもしれない」という意識

すごくシンプルに考えると、Zero Trustは「『防犯』『防災』の意識をもつ」ということになります。

例えばこんな「誰か・見てるぞ」という看板を近所で見かけたことがあると思います。

Zero Trustを「誰も信用しない」という認識で考えると、考えなくてはならない対策が多すぎてキリがなくなってしまいますよね。例えば街中を歩いているときに、歩いている人を見て「この人は自分の家に盗みに入るかもしれない」と一人ひとり疑うかというと、別に疑わないと思います。でも一方で「防犯」という意識はみなさん持っていると思います。

なので、「誰も信用しない」というよりは「何か起こるかもしれない」という意識で対策した方が動きやすいのがZero Trustです。「誰も信用しない」と言われると身構えちゃうかもしれないんですけど、そうではありません。

ここからIT系のセキュリティの話をします。これはIPAというサイトに公開されている情報を参照したものです。

字が小さくて申しわけないのですが、先週の1月30日に公開されたばかりの情報でして、「情報セキュリティ10大脅威」という資料です。

代表的な脅威として、脆弱性をついた攻撃や、騙しリンク・騙しファイルが挙げられています。あたかも取引の見積書を装ったPDFが送られてきて、うっかりPDFを開いたら実はウイルスが仕込まれていたというやつです。こういった攻撃パターンの例がこの「10大脅威」で紹介されています。

脆弱性への対策

今日はあまり時間がないので、脆弱性への対策というトピックにフォーカスして考えてみます。セキュリティパッチが公開されてから、そのパッチによって修正される脆弱性を突く攻撃が開始されるまでにどのくらいの猶予があるかを、ラックさんが調査した結果が IPA のドキュメントに公開されています。

セキュリティパッチが公開されてから、それをバイナリで逆アセンブルなどすると、どのようなフィックスが行われたかがわかるんですね。ラックさんの調査結果からは、パッチが公開されてから攻撃が開始されるまでだいたい1日以内という猶予期間であることが分かっています。逆に言うと、パッチ適用の作業を1日以内で完了する必要があるということになります。

これをNoOps的に考えると、例えばMicrosoft AzureのPaaSの場合、いわゆるVMのような IaaSと違ってOSとかミドルウェアのセキュリティパッチの適用作業はMicrosoftが実施します。

なのでユーザーさんがパッチ適用する必要がないんです。PaaSを利用することによって、セキュリティパッチの適用作業のためにみなさんの手を煩わせることなくアプリケーションの開発・デプロイに集中できるという意味で、NoOps的な対処としてPaaSを利用するのはアリです。

実際にあった例で、去年の正月にMeltdownとかSpectreという、いわゆるCPUの脆弱性が発見されたときに、その脆弱性の情報をGoogleさんが公開しました。この情報が公開されてから1日以内に、Azureのセキュリティパッチの適用が開始されています。

なので、PaaSでパッチ適用をベンダーに任せることは、パッチの手間を省くという意味でもそうですが、セキュリティパッチの適用作業を完了させるまでの日数を短くするという意味でも有効ではないかと思っております。

セキュリティの各要素と関連性

最後に、今日のポイントをお話しします。Zero Trustは誰も信用しないというよりは、防犯や防災の意識を持ってシステムを運用・監視していくということが1つ目のポイントです。

また、Zero Trust Networkとは言いますけれども、ネットワークはセキュリティ要素の1つに過ぎません。

攻撃の経路としてネットワークが使われますが、攻撃の対象としては例えば前のセッションでも話があった、パッケージ中のバイナリであったり、データに対する攻撃というものもありますので、「Zero Trust ってネットワークだけの話じゃないですよ」というのがもう1つのポイントです。

もしまた機会があれば Zero Trust のお話をできればなと思いますが、次回はセキュリティ関連のディープダイブした話ができればと思います。

必ずしも、ネットワークだけの問題でセキュリティインシデントが起こるわけではありません。例えばIDの問題もあります。なので、セキュリティに関する運用手順のオートメーションやVMイメージのハーデニン、標準化などによって、なるべくオペレーションをかけない運用を目指すようなことができればよいのかなと思います。

今日は技術的に詳しいところはあまりお話しできず申しわけないのですが、今日のところは以上とさせていただきます。ありがとうございます。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!