第６３回ニッポンクラウドワーキンググループ会合報告

『ゼロトラストを理解し、クラウドにフルトラストをもたらせ！』をテーマに
ニッポンクラウドワーキンググループ第６３回会合をオンラインにて開催いたしました。

テーマ：『ゼロトラストを理解し、クラウドにフルトラストをもたらせ！』
日　時：２０２１年３月３日（水）１７：００～１８：００（オンライン会合）
　　　　１８：００～１９：３０（オンライン懇親会）
場　所：オンライン（ZOOMミーティング利用）

【司会者のご紹介】
司会　副会長　野元　恒志

１．開会のご挨拶
NCWG副会長　藤田　浩之

皆さん、本日はニッポンクラウドワーキンググループ第６３回会合にお集まりいただきありがとうございます。２０２１年も、もう３月３日のひな祭りなのですが、今年最初の会合ということで、皆さん今年もよろしくお願いいたします。

緊急事態宣言がなかなか解除されないのでオンライン会合とさせていただいていますが、ニッポンクラウドワーキンググループは可能であればリアルな会合を開催したいと思っています。既に会場の準備など進めていまして、５月の会場はいくつか押さえている状況です。オンラインばかりだとメンタルがもたないので、オフラインに戻しますという会社もよく聞きますが、ニッポンクラウドワーキンググループも早くリアルで皆さんにお会いできるような状況になってほしいと思います。引き続き状況を見ながら、もちろんリアルに開催する場合はフェイスシールドを全員に配るなど感染対策をしっかりとして安全に開催をしていきたいと思っています。今後ともぜひ皆さんご参加ください。

今回の会合は『ゼロトラストを理解し、クラウドにフルトラストをもたらせ！』というテーマです。今回の講演はサムライクラウド部会発表ということで、サムライクラウド部会のメンバーである福原さんにお話しいただきます。ゼロトラストはワードとしてはかなり目にするようになってきて、皆さんも耳にしたことがあると思いますが、私は詳しいところまでは理解をしていなく、皆さんもおそらくそうなのではないかと思います。サムライクラウド部会はゼロトラストアーキテクチャーについて部会で議論を重ねていますので、今回はその内容を皆さんに知ってもらうために企画されました。結果として皆さんのクラウドケイパビリティ、クラウド提供能力をアップさせて新たな価値をつくるということにつながればと考えています。ということで今回の会合をはじめさせていただきたいと思います。よろしくお願いいたします。

２．部会報告

サムライクラウド部会
部会長　野元　恒志

サムライクラウド部会に関しては基本的にはブレません。元々SAML、シングルサインオンといったコアテクノロジーを中心に、特に今年度の活動はセキュリティ面（セキュリティと言う言い方をしてしまうと言葉が広くて難しいのですが）、その中でも特にゼロトラストアーキテクチャー（ZTA）をテーマにしています。

セロトラストは昨今のコロナ渦にあって特に突き詰めるべきテーマなのかなと思いますが、「信用できるところがない」というところから、企業のネットワークや利用するアプリケーションの環境を整えるというようなことをテーマの根幹に据えています。関わるテクノロジーに関してもすべて議論の対象にしていますので、SAML、0authなどの認証基盤や認証技術、または端末認証みたいなものまで踏み込んで議論をしているというのが活動になっています。

直近での議題では、昨年の１１月の全体の年度報告会でサムライクラウド部会として、ゼロトラスト標準化の準備を行い提言の準備をすることを発表させてもらっていますが、２０２１年はこのゼロトラストをどういうふうに運用・実践すべきなのかというものをまとめた形で皆さんに提示、または世界に発信するということをやっていきたいと思っていますので、その議論を中心にしています。

あとは、プログラマブルネットワーク、端末認証などの話もしています。また、普通に使われているZIP暗号化（PPAP）も我々の部会ではあまりセキュリティ的な価値が高くないのでネガティブに捉えていまして、やめたほうがいいのではないかというような話もしています。

次回の部会は３月２６日（金）を予定しています。せっかくゼロトラストの話がこの後にありますので、中身は福原さんにお任せしたいと思いますが、皆さんも気付きを得る機会にしていただければと思います。最近バズワード化（朝のメールマガジンの多くにゼロトラストというキーワードが書いてある）しているようなイメージもありますが、そのようなものとは一線を画すお話をいただけると思いますので、皆さん楽しみにしていただければと思います。

クラウドアプリケーション部会
部会長　尾鷲　彰一

クラウドアプリケーション部会では、本当は昨年雨量センサーで雨量を測ることをやろうとしていたのですが、コロナ渦でなかなか集まることが出来ずに実施できませんでしたので、今年度も引き続きゲリラ豪雨を雨量センサーで探すことを進めていきます。

課題が２つありまして、Arduinoの使い方と雨量計自体をどう設置するかということです。この辺を進めていかなければいけないのですが、コロナの影響でなかなか集まって実施することのメドが立たないので、私の方で環境を構築し採ったデータに対してオンラインで勉強会を行う予定でいます。４月、６月、８月、１０月の４回を予定していまして、開催の前には皆さんにご連絡をしますので、その際にはご参加をよろしくお願いいたします。

クラウドビジネス推進部会
部会長　藤田　浩之

今期はコロナ渦で部会のあり方についてどのような形がいいかいろいろ悩んだのですが、いまだからこそメンバー相互の交流の機会を積極的に作りたいという思いがあります。従来ですとリアルに集まって勉強会という形をとって部会後に親睦会を開催していたのですが、オンラインでの勉強会は敷居が高いと思いますので、もっと気軽に参加していただけるように「クラウドビジネスサロン」という形でオンラインで開催することにしました。

内容としては予めクラウドビジネスに関するテーマを決めておいて飲みながら語り合うようなことをイメージしています。例えば「今、一押しのクラウドサービス」のようなものをテーマにして定期的に開催したいと思っています。開催日については決まり次第メールなどでご案内しますので、ぜひ皆さん集まっていただいてクラウドビジネスについて語り合いたいと思っています。ぜひご参加ください。よろしくお願いいたします。

３．サムライクラウド部会発表
テーマ：Zero Trust Architecture
　　　　『クラウド利用にあたっての「ゼロトラスト」の現状と実質的な対応は？』
公立大学法人会津大学　客員上級准教授
株式会社コンピュート　取締役
三井物産セキュアディレクション株式会社　プリンシパル・コンサルタント
福原　英之　氏

＜ゼロトラストとは？＞
ゼロトラストとという言葉自体は、２０１０年に米国の調査会社フォレスター・リサーチのジョン・キンダーバグ氏が提唱した概念／造語です。“never trust, always verify”、すべてのデバイス、サーバー、ネットワークからのアクセスを「信頼できない」前提でセキュリティ対策を講じることを提唱しました。

その後、１０年以上たってベンダー各社がいろいろ言い始めました。ベンダー各社が言い始めたおかげでNIST（National Institute of Standards and Technology、アメリカ国立標準技術研究所）がゼロトラストアーキテクチャーという名称で標準化のレポートを出しました。1stドラフトが２０１９年９月に出て、その後2ndドラフトが出て、昨年２０２０年８月１１日にファイナルの正式版レポートが出されています。NISTが標準化のレポートを出すと、世の中はそれを元に議論が始まるので、各ベンダーがいろいろ言っていることはここに集約されているということを前提に、NISTが言うゼロトラストアーキテクチャーとはどういうものかを、まずは理解することが大切だと思います。レポートの中身はよくできていて、特に最初のコンセプト、背景は非常によくできています。後半に実装例が掲載されていますが、実装例はあくまで例で完璧なものではありません。その辺を絵を使っていろいろ言い始めているのが各ベンダーの状況だと思っていただいていいと思います。

ZTAの基本概念（SP800-207）のミニマムの絵にすべてが集約されています。絵は左と右にわかれていて、左側に端末の絵、真ん中にGatewayのような箱があり、右側にDBのような絵があります。ゼロトラストアーキテクチャーでは、左側の端末の部分を“Subject”、右側のDBのような部分を“Resource”と呼びます。Subjectには、端末だけではなく、人、ネットワークも含まれます。Resourceには、システム、サーバー、OS、アプリケーション、データのすべてが含まれます。真ん中の画像のGatewayが一番大事で、Policy Decision Point（PDP）というものとPolicy Enforcement Point（PEP）というもの２つが一緒になってGatewayを作っています。さらに、左側のZoneはUntrusted Zone（信用しないゾーン）、Gatewayの右側はImplicit Trust Zone（（暗黙的に）信用するゾーン）という言い方をしています。要するに、Gatewayの左側は誰も信用しません、右側は全幅の信頼を置きますというセグメンテーションをされているのがゼロトラストアーキテクチャーのコアです。簡単に言うとこれだけですが、これを実現するためにどうするのかというのが実は難しいです。そこの内容を次からお話しします。

＜ゼロトラストの背景＞
その前に、なぜゼロトラストが出てきたのかの話をします。皆さんご存知の通り境界防御というのが、サイバーセキュリティのこれまでのトレンドでした。過去、インターネットが普及しはじめた２０００年くらいから未だにそうです。ファイアウォール、IDS、IPSはここに含まれています。

但し、マルウェアが高度化し入り込んで内部から攻撃されてしまう、内部犯による攻撃、標的型攻撃の高度化（昨年、本田技研の工場が数日間止められたなどの事例がある）などがあり、境界防御ではない次の防御を考えなくてはいけないというのがまずあります。次は、SOA（Service-Oriented Architecture）の成熟があります。Web-APIやマイクロサービス化があってはじめて今回のようなPDP、PEPが使えます。それから認証（AAA）技術の普及です。PDP、PEPの中では人とデバイスの認証が大事になるので、ここも２０年くらいかけてやっと普及してきたということがあります。そして何よりクラウドサービスの普及です。クラウドサービスのおかげで、「社内」というものが「社内」ではなくなったというのが一番大きいと思います。

＜ZTAの実装＞
現状を整理すると、最初に野元さんが言ってくれた通りZTAは言葉が先行する完全なバズワードです。バズワードを元に各ベンダーは自己主張をしています。「micro segmentationには次世代FW」「個人認証にはIDMサービス」「クラウドにも対応するにはCASB（Cloud Access Security Broker）」などですが、どれも実は片手落ちです、全部やらなくてはいけないので。こういうのには踊らされないようにしてください。それから、ZTAそのものは考え方、個々のテクノロジーもまったく新しいものはありません。すべてが新しい概念ではなく、組み合わせた総括するようなセキュリティの考え方だと思ってください。また、ZTAは１つの製品では実現できません。とはいえ、ZTA実装によって間違いなくセキュリティレベルの向上が期待できます。

どこをやるのか？ということですが先程紹介したZTAのモデルで言うと、ユーザーとデバイスは１つにまとまっていて（Subject）、アプリケーションサービスとその後ろのデータコンテンツは１つのResourceにまってまっています。現在議論しているのは真ん中のポイント（デバイスとアプリケーションサービスの境界）だけですが、実際には、場合によってはアプリケーションサービスとデータコンテンツの間にゼロトラストの境界があってもいいはずです。このように、いろんな場所にあってもいいんですよというのも、もう１つ考えていいのではないかと私は思います。

次にZTAに絶対必要な要素ですが、「リソースの閉域化」「PEPの配置」「PDPの配置」「アクセスポリシー」「アクセス可否を判断する情報」の５つをあげさせてもらいました。左にSubject、右にResourceがあった場合、何が必要か。リソースを完全に閉域化すること、PEPを通らないでこのリソースにアクセスできてはいけませんということです。さらに、PEPとリソースの間は絶対に信頼できる接続がないといけません。それと、PDPという脳も配置しなくてはいけません。次の２つが実は結構軽視されています。ここでアクセスさせていい／させていけないというポリシーがないことにはPDPはディシジョンできません。ポリシーがあるということが大前提です。その上でPDPでこういうポリシーでアクセスさせたいとしたところで、ポリシーを検証できる情報がないことにはディシジョンできません。なので、Subject側の人とかデバイスが今どうなっているという情報をリアルタイムに見れるとか、Resource側はデータの中身ごとにこの人に出していいかの判断ができるラベルがされているとかという情報がないことにはディシジョンできません。これをやるのが実は一番大切なことです。

先程言ったとおりにZTAは「アクセスポリシー」次第です。これをどう考えるかがすべてだと思っています。仮にアクセスポリシーが、Subjectの要件が「IPアドレスが社内」、Resourceの条件が「すべてにアクセス」というものを作ると、いままでの境界防御と同じセキュリティ環境がZTAで実現できます（このようなことをする人はいませんが）。ではどうするかですが、アクセスポリシーの要件が増えるほど、判断のための情報も増えます。Subject要件を「登録ユーザーである」とすると「リアルタイムのユーザー一覧」の情報が必要になり、「安全な端末である」とすると「リアルタイムの端末のバッチ情報、アンチウイルスの情報」が必要になり、「攻撃者のIPでない」とすると「Threat Inteligence（脅威情報）」が必要になります。Resource条件を「機密情報である」とすると「機密情報の一覧・ラベル」が必要になり、「時間制限」とすると「開示時間情報」がラベル単位で必要になり、「頻度制限」とすると「許容アクセス頻度情報（アクセス許容をする頻度を１分間に何度かなどを決め、それをメジャーメントできなくてはいけない）」が必要になります。このようなものが求められます。

ZTAは境界防御の崩壊といいながら、実は境界防御が必要になります（完全な閉域網を作らなくてはいけないので）。言葉だけだと矛盾しているように思えますが、「PEPの後ろ側は完全に無防備」「セキュリティコンポーネント間通信は絶対の信頼が必要」「Resourceへのバックドアがあると論外」などのことがあるためです。さらにクラウド間を跨いでシステムが作られている場合があるので、その際の物理セキュリティをどうすればいいのか、Software Define Perimeter（ソフトウェアで境界を作る）、Data Encryption（データの暗号化）など、いろいろと課題があります。この辺をクリアしなくてはいけません。

また、例えば完全な閉域の中のシステムがクラウドの向こうにクラウドサービスを利用していた場合、これをどう防御するのかという課題もあります。ベンダーはSoftware Define Perimeterでといいますが、心配ではあります。

厳格な個人認証は絶対に大事です。誰が使用しているのかということを間違いなく認証できないと何もできません。いままでサムライクラウド部会で議論してきたID管理、認証の仕方などがとても大事になってきますし、それができないとZTAの実現などは無理な話になります。もう１つは、いままで「認証」という言葉の中に隠れていましたが「権限の管理」も非常に大事になってくるというのが浮き彫りになってきます。IDを持っている人の属性に従って論理的に権限が決定できるのかどうか、例外をどういうふうに排除するビジネスモデルを作るのか（例外を必要とするのであれば自動的にディシジョンできなくなってしまうので）なども課題になってきます。

具体的にどのようにうすればZTAを実装できるかと言うと、例えばアクセスポリシーとして「二要素認証した正規ユーザー」「社給PC」「PCはウイルスチェック済」「PCはセキュリティパッチ適用済」「サービスへのアクセスのあるユーザー」「サービス内のデータはアクセス権による」というものを作ろうとすると、リクエストをする順番で言うと、まず「二要素認証のユーザー認証（検証）」をします。次に「リソースに対するアクセス」を要求します、要求の中にはユーザーの情報以外にも端末の情報とかアクセスする先のリソースの情報を含めてリクエストをします。それをPEP（後ろにPDPがいます）でリクエスト毎に、その権限を確認してリソースへのアクセスを許可し、リソースからのデータを端末側に表示させてあげますという流れが実装をするための１つの例です。ここで何を使うかというと、例えば認証システムにADFSを使うとか、Azure ADを使うのは構わないと思います。PEPのところにはリバースプロキシを使って、その後ろはマイクロセグメンテーションをしてアクセスをさせます、というような実装になると思います。

＜今後の展望＞
まず、「ZTAは必要か？」といことですけど、私の答えは「Yes！」です。必要以前にZTAは実はセキュリティ対策としてすでに始まっています。いままでやってきたことの延長線上にあるのがZTAだと思ってください。もう１つは、ZTAという考え方を１つのツールとして、これまでのセキュリティ対策やアーキテクチャを見直すことに使えるのだと思います。

ZTAの実現に向けたステップですが、順番で言うと「実装」は最終段階です。最終段階の前に「基礎的な準備」があり、「環境の整備」があり、実装があります。基礎的な準備は、既存システムが何であるかをまず知る、ID管理システムを作成する、認証システムを作成することです。その上で環境の整備として、アクセスポリシーを作る、アクセスポリシーに従って必要情報の集約ができるシステム・環境を作ることが必要です。それができて初めてPEP周辺の実装ができるようになります。まずは、「基礎的な準備」「環境の整備」の２つをきちんと固めて、フィロソフィー（哲学）を固めて進めることが大切です。理想論からのドルルダウンでは難しいので、いまあるものからどう進めるか、現状からの「順時移行」が一番良いと思っています。

まとめると、ZTAはテクノロジーではないし、新しいものでもありません。アクセスポリシーの策定が最重要です。アクセスポリシーの実現のためには情報集約強化やシステムアーキテクチャーの見直しが必要になります。このへんとことを考えて（ZTAの核心を捉えて）、ベンダーのバズワードに踊らされずに対応していくことが大事です。

※発表資料はこちら

■Q&A
Q1：ZTAを導入すると想定した場合に、絶対的な閉域というお話しがありましたが、どのような環境にするのが望ましいのでしょうか？
A1：いわゆるネットワーク的な閉域網です。そこの閉域の中には決められた場所からの通信しかこないということが保証されている場所です。物理的なネットワークを組むのであれば、そこに入れるのは目の前のファイアーウォール、もしくはIDSを通したところ１箇所だけ（他の線は通っていない）というような環境です。論理的なネットワークの話をしましたが、物理的な線も大事なので、ファシリティのセキュリティが保たれているという大前提があります。

Q2：自治体のZTA導入状況はどうでしょうか？
A2：大手企業でもZTAの概念を深堀りして実装しているところはまだ少ないと思います。自治体はまだだと思います。まず、自治体はID管理ができていません。GPKI（政府認証基盤）を見てもわかるとおり、個人ではなく役職に紐づくという考え方から脱却できないためです（本来は「個人の属性が役職」というようにできればいいのですが）。GPKIでは「知事」「副知事」という個人証明書を発行したりします。そういう考え方が抜けていません。

４．会長からの総括
会長　小堀　吉伸

福原さんありがとうございました。おつかれさまでした。もうすでに３月ではあるのですが、今年度２０２１年の初めての会合です。本来、早い段階でお会いすれば「おめでとうございます」という感じになると思うのですが、このような状況で去年１１月にパーティーはできませんでしたが設立九周年の年度報告会・特別講演会を開催させていただき、今年に入って１月、２月といろいろなことが動きが取れない状況でしたので、３月開催が今年初めてとなりました。実は福原さんにはゼロトラストアーキテクチャーについて、以前からぜひお話しをしていただきたいということで進めてきたのですが、次のときにはぜひリアルの場で面と向かってお話しを聞かせていただきたいと思っています。もう３月なので、今年ももう三分の一が終了してしまいましたが、オンラインでもやれることはいっぱいあるなと思いながらももどかしい状況が続いています。世の中の状況を勘案すると当面は主戦場はオンラインになるという判断をせざるを得なく、１０月までは１０年目の活動になりますが、状況によって可能であればリアルの場でも活動していきたいと思っています。

今日お話しいただいたゼロトラストアーキテクチャーについては、福原さんよりサムライクラウド部会の中でいろいろお話しいただいていています。先程、お話しいただいたポイント制のZTAに関するテストなのですが、あのように数値化できるのは非常に興味深く、ビジネス化できるかなと思ったりしました。リモートワーク、それからクラウドコンピューティングの利活用が広まる中で、この１５年のZTAについて語ることができきれば一番いいのですが、まずはZTAを知り、サービスに組み込んだりという視点があればいいなと思います。幸い福原さんはサムライクラウド部会のメンバーで近いところでお付き合いしていただいているので、皆さんも引き続きお付き合いをしながら知見を深めていただければと思います。福原さん、引き続きよろしくお願いいたします。

オンラインではありますが、ニッポンクラウドワーキンググループはクローズドで引き続き活動をしていきます。皆さんに参加していただくことが会の推進力につながるということは変わりませんので引き続きよろしくお願いします。福原さん、どうもありがとうございました。

５．懇親会

オンライン会合終了後に今回もオンライン懇親会を開催し、大いに盛り上がり、メンバー・ご協賛の方々との積極的な交流を図ることができました。
皆さん、お疲れ様でした。

【NCWG実行委員　報告書作成者】
実行委員　佐々木　泰（株式会社クオリティア）