「ゼロトラストはセキュリティを高めるものではない」　特定の実装を指すものではないからこそ必要なキャッチアップ

鈴木氏の自己紹介と本セッションの概要

鈴木研吾氏：ただ今紹介いただきました、LayerXのSuzukiと申します。本日はこの場にお招きいただいて大変光栄です。

今日話す内容としては、あらためて2022年においてのゼロトラストを振り返り、自分が所属するところで今はどのような取り組みをしているかをお話できればと思います。

自己紹介ですが、Twitterやオンライン上のハンドル名は@ken5scalという名前でやっていて、LayerXでは2つの部に所属しています。1つ目がCTO室と、もう1つがFintech事業部というところです。今日お話しする内容としては、どちらかというとCTO室の性質が強いものになります。

同時に個人活動として技術系のサークルをやっています。技術書典とかでいろいろやらせてもらっていて、その一貫としてオライリーさまの『ゼロトラストネットワーク』を監訳させてもらいました。

本日は『ゼロトラストネットワーク』をふまえて、これが監訳されたのが2020年だったと思うので、そこから2年ちょっと経った今はどういったことをやっているのかをお話できればと思います。

（スライドを示して）具体的に言うと、だいたいこの3つに絞ってお話ししたいと思います。あらためて「ゼロトラストって何だっけ？」みたいなところ。昨今のマーケティングも国家的なシステム構成の戦略もふまえて、あくまでもこのスライドの中での「ゼロトラストは何だっけ？」というところを前提として揃えさせていただく。

その上で、私が取り組んでいるLayerX内でのゼロトラスト、主に辛いと思ったところ、課題をお話しします。今後やることは無限にありますが、その中で「特にこのあたりは他の方が話していない部分になるんじゃないかな」と思って持ってきた次第です。よろしくお願いいたします。

ゼロトラストはセキュリティを高めるものではない

LayerXはみなさん知っているとおり……と言うと、ちょっと違いますね。事業会社です。事業会社ということで、お客さまからさまざまなデータを受け取って、そこに付加価値を加えて提供しています。

同時に、その付加価値を提供する上でいろいろなデータを預かっているので、さまざまなリスクを内包していることを自覚していて、それに備えて機密性、完全性、可用性を全社一体で取り組んでいく方針を打ち出しています。

では、このような事業会社で果たしてゼロトラストは実現できるものなのかというと、自分の中で答えは明確になっていて、これはそういうものではありません。「ゼロトラストはセキュリティを高めるものではない」ということを、個人的にここで明言します。

そういったものがありつつ、いろいろ（なことに）取り組んでいるOktaのようなゼロトラストについて、特に業界をリードしているようなところでも、例えば従業員がフィッシングにあって、そこから内部情報が流れてしまうといったようなインシデントが実際には起こっています。

他にも、パスワードマネージャーのサービスだとかでそういったところでインシデントが起きている以上、セキュリティレベルが低いということが言いたいのではなくて、ゼロトラストそのものが、セキュリティに対してなんらかの対策になるということではない（ということだ）と個人的には考えています。

では、ゼロトラストとは何か？

じゃあ「そのゼロトラストって何でしたっけ？」というところから話します。先ほど言ったとおり（ゼロトラストは）特定の実装を指すものではなくて、あくまでも「だんだんとローカルのコンピューターから限定されたネットワークに業務環境が移り、そこからSaaSなどが爆発して、分散化されたネットワーク上で経済活動が（行われるようになり）、そこにシフトした環境に適応したシステム」的な考え方になると思っています。

なので個人的な意見としては、ネットワーク境界防御といったものを否定するものではなくて、あくまでも「それを踏襲した上での全体的なシステム保護」という考え方になります。ただ、環境が変わるということは、資産がどこにあるのか、脆弱性がどこにあるのか、脅威がどこにあるのかもどんどん変わっていき、当然リスクも変わっていきます。

原則として適用できる考え方は同じで、情報資産における機密性、完全性、可用性を守るために最小権限とか職務分掌を実現していこう。ただし、それを別の環境で、というのがゼロトラストの考え方だと思います。

（スライドを示して）ゼロトラストはけっこう題名が先行しがちですが、世の中ではこのようなパブリケーションがあります。

監訳した身で「ちゃんとした」と言うとちょっと違うなと思いますが、主にオライリーさまのものとか、あとはアメリカのNIST（National Institute of Standards and Technology）が出しているものとか、イギリスのサイバーセキュリティ庁みたいなところが出しているNCSC（National Cyber Security Centre）。そして、日本におけるデジタル庁みたいなところがアクセシビリティの高いゼロトラストのパブリケーションを出していると思います。

2017年から2020年にかけては、「ネットワーク」という用語がプリンシパルの最初のほうに出ていました。

2021年とか2022年においては、どちらかというと「ユーザーデバイスサービス」とか、「識別・特定できる状態、確認とか認証をしていきましょう」というところが上段にきて、それに続いて「そういったリソースのヘルス、状態を観測して、そこにポリシーを当てはめて認証とか認可をちゃんとやっていきましょう」というような書き方にシフトしてきているかと思います。

したがって、オライリーでもNISTでも優先順位としてはあとですが、結局のところは認証・認可とか、ポリシーとか、「状態を確認していこう」というところを掲げていることになります。

そういったところからふまえて、「ゼロトラストはユーザーとかデバイスとかリソースといったようなデジタル上の資産、あるいはリソースに着目して、それらをデジタルアイデンティティとみなし、しっかり事前に決められたポリシーをそこに当てはめて、最小権限と職務分掌を実現できるようなアクセス制御を実現する」ということが、現時点における自分の考え方になっています。

この考えを基にリスク対策をするということは、アクセス制御をちゃんとして、リスクや発生確率とか影響度を抑えていくかたちになるかと思っています。

（スライドを示して）現在、LayerXには右下の図のとおり特定の中央的なCTO室がありますが、各部で管理している資産管理とかアクセス制御みたいなものをできるだけ自身で管理していき、そこに提供するようなガイドラインとか、あるいは「それらがちゃんとしているよね」ということをCTO室が監査する体制づくりに取り組もうとしています。

LayerXにおけるゼロトラストの適用の歴史と現状

「取り組もうとしている」ということはこれからやろうということで、現時点で成功しているとは言い難い状態です。これはなにも当社がすでに漏洩を起こしているということではなくて、あくまでも既存のゼロトラストの考え方に基づいて実装してきたことが、当社の成長あるいは変化に伴ってキャッチアップできなくなっているという状態になっています。

LayerXにおけるゼロトラストの適用はわりと歴史が長いもので、創業4年の会社には（ここまでの歴史はふつう）ないと思いますが、2020年の段階からゼロトラストは推進していました。コアとなるデジタル・アイデンティティに着目して、最小限の法則とか職務分掌に務めています。

そういったところでリスクを低減するために、よくあるAWS上のorgを作って、Security Hubで全部を一括管理をして、そのあたりの変更管理とかをConfigでちゃんと見て、GuardDutyで変なものを見たらSlackに飛ばすみたいな。そのあたりは整えていました。

それと同時に、社内基盤に関しては、マイクロソフトさまのソリューションなどを使って、自動的にログを検知するみたいなところもわりと実行していきました。

AWS上においては、各種リソースに対してタグのルールを決めてそれを適用することで、「今のこのリソースがどういう状態なのか」を示せるような体制を構築してきたし、IaCによるソフトウェア化は進んでいました。そういった意味で、自動化を必要最低限にかつ必要十分に抑えて実施してきた状態になっていると自負しています。

ですが、2021年から当社は新しいSaaSを提供し始めて、それが幸いある程度市場に受け入れられ始めました。（スライドを示して）それと同時にチームも拡大していまして、それを端的に表すのが右下の図です。

2021年4月まではわりとステディですが、そこから1年のうちに一気に3倍ぐらい、ガッと人数が増えています。

それに伴ってチームが再編成されていきます。一気に編成されるのではなくて、編成と編成を繰り返していくことによって、だんだんアクセス制御のルールが崩れてきています。

IdP（Identify Provider）によるID情報のフェデレーションとか、グループを役割と見立てて作るRBAC（Role Based Access Control）とかは、わりとどこの企業さまでも実施されていることかと思います。

当社の場合は役職とか職務とかチームを区分で区切って、それに応じて特定のリソースに対してアクセス可能かを判定してアクセス可否と適用を実施してきました。（つまり）静的なポリシーによって、アクセス時のコンテキストを取り込んでいたということになります。

もともとはグループにメンバーシップを突っ込んで、そこに対して「メンバーシップにいるから、この人はこのロールを持っているね」というかたちでアクセス制御をしてきたということですね。

それが、先ほどお見せしたプロダクトの成長および組織の成長とともに、グループの区分が爆発的に増加しています。ちょっとさすがに変遷は追えませんでしたが、現在ではグループが「10近く」と（スライドに）書いてありますが、嘘です。100近くあります。

そんな中でチームの変更とか研修を実施する場合に、その変更対象のグループをポチポチいじってメンバーを変えるところでカバーしきれない状態に正直なってきています。

（スライドを示して）右下にある自分のSlackのポストが端的にそれを表していると思います。そうなると、グループによるアクセス制御が「実効性はちゃんとしているんだっけ？」という話につながってきてしまいます。

他にもグループ管理およびアクセス制御だけではなくて、先ほどお話したとおり、リスクというものは脆弱性と資産により多様です。

なので必ずしもアクセス制御だけではなくて、そこの資産における脆弱性がどれぐらいあるのか、残っているのかもチェックしていかなければなりません。各部でガッとチームが広がって、かつインフラチームも広がってある程度の権限を渡していくと、だんだんとタグが適用されないみたいな話とか、似たようなリソースがたくさんあるとか、「このアクセスポリシーは何を狙っているんだっけ？」みたいなことがどんどん起きていくということになります。

そんな感じで、組織の変化、業界の変化、プロダクトの変化とともに、もともとはゼロトラストに基づいてやっていた実装が、ぜんぜんキャッチアップできなくなっていくということです。

これ自体が悪いことではなくて、単純に「組織の変遷とともにそういったガバナンス部分もちゃんとアップデートしていかなきゃいけないんだよ」という話ではあります。

そういったアップデートに向けて、当社ではグループも資産化も脆弱性の管理の仕方が大絶賛大変中ということであります。

（次回に続く）