ゼロトラストという概念は、Forrester ResearchのアナリストであるJohn Kindervagがゼロトラスト・セキュリティモデルを考案した2010年から存在している。しかし、壊滅的な被害をもたらしたColonial Pipelineへの攻撃から2年が経ち、米国政府などが強く推進しているにもかかわらず、ゼロトラスト・アーキテクチャが広く導入される時期は、いまだに近づいているとは言い難い。
例外はクラウドサービスプロバイダーだけのようだ。クラウドサービスプロバイダーは、Googleの継続的なパッチ適用のような厳格なセキュリティ対策によって、サイバーセキュリティに関して羨むべき実績を誇っている。
セキュリティ侵害が毎時間のように発生し続ける中、社会への影響とコストを考えれば、遅かれ早かれゼロトラストの要件はすべての組織に強制されることになる。バイデン政権はすでに野心的なサイバーセキュリティ法案を推進しているが、現在の米国議会では大きな進展は見込めそうにない。私は、サイバー保険業界がいまだにゼロトラスト・アーキテクチャを要求していないことに非常に驚いている。しかし、先週業界側に不利な判決が下された14億ドルのMerck判決が、状況を変え始めるきっかけになるのかもしれない。
中心となる疑問は、どの組織でもゼロトラストのフルスタックを実装し、さまざまなベンダーからハードウェアとソフトウェアを購入して組み合わせることができるのか、それともゼロトラスト・セキュリティを実現するには、私たち全員がクラウドサービスプロバイダー（CSP）へ移行しなければならないのか、ということだ。
クラウドの利益率がいずれオンプレミスのITインフラをより安価な選択肢に見せることになるという従来の議論では、セキュリティが極めて困難になり、正しく対処できるのがクラウドサービスプロバイダーだけになる時代を予測できなかった。そのことはITの未来に多大な影響を及ぼす。これから詳しく見ていこう。
ゼロトラストの7原則
NISTと米国国防総省（DoD）は、ゼロトラストの要件に関するガイドラインを公開している。NISTのガイダンスはこちらで確認できる。
NISTにはゼロトラストの7原則がある。ここでは簡単に取り上げるが、詳細は文書の16ページに記載されている。
- すべてのデータソースとコンピューティングサービスをリソースとみなす。
- ネットワーク上の場所にかかわらず、すべての通信を保護する。ネットワーク上の場所だけで信頼を示すことはできない。
- 個々のエンタープライズリソースへのアクセスは、セッションごとに許可する。アクセスを許可する前に、要求者の信頼性を評価する。
- リソースへのアクセスは動的なポリシーによって決定する。そこには、クライアントのID、アプリケーション／サービス、要求元のアセットの観測可能な状態が含まれ、その他の行動属性や環境属性を含める場合もある。
- エンタープライズは、所有するすべてのアセットと関連するすべてのアセットの完全性およびセキュリティ態勢を監視・測定する。いかなるアセットも本質的に信頼してはならない。
- すべてのリソース認証と認可は動的に行い、アクセスを許可する前に厳格に適用する。
- エンタープライズは、アセット、ネットワークインフラ、通信の現在の状態について可能な限り多くの情報を収集し、それをセキュリティ態勢の改善に利用する。
以下は、DoDによるNISTスタックの図だ。
DoDの文書は、具体的な要件と実装方法を定義しており、非常に優れている。文書はこちらで確認できる。ワークフローの好例は28ページに記載されている。
米国政府は、ここまでこの分野を先導してきた点で素晴らしい成果を上げている。これは、政府が共通アプリケーションインターフェース向けのPOSIX標準の策定を主導した1980年代と同様だ。
ゼロトラストは「非常に複雑」
言うまでもなく、ゼロトラストは非常に複雑だ。標準権限のユーザーから高い権限を持つユーザーまで、まずユーザーを起点として、あらゆるものを追跡・認証する必要がある。ネットワークはセグメント化して認証しなければならない。サプライチェーンの妥当性も検証する必要がある。環境全体を暗号化する必要があり、つまり鍵管理も非常に複雑なプロセスになる。
これらすべてを追跡し、ネットワークとシステムにはポリシーを動的に実装しなければならない。新しいジョブが実行され、異なる方法でリソースを使用した結果、ポリシーマネージャーがその新しいジョブを侵入者と判断してシステム全体を停止させたらどうなるだろうか。これは簡単に起こり得る。さらに、第三者への依存も複雑さを増す。例えば、多要素認証に使っているソフトウェアパッケージの1つがハッキングされたらどうなるだろうか（Okta）、そして誰かがゼロトラストの境界を回避してシステムに侵入できてしまったらどうなるだろうか。
これらはすべて極めて複雑であり、大規模な組織には大勢のITスタッフとテスト環境が必要になる。大手銀行や医療システムは、実施しないわけにはいかないため、これを実行する余裕があるかもしれない。しかし、小規模企業やITの重要度が比較的低い組織には、財務的に実施する余裕がないことが多い。
ゼロトラストが必要だった組織の例としては、Colonial Pipelineのような重要インフラ、さまざまな学校システム、そして世界各地の州政府・地方自治体が挙げられる。これらはハッキングされ、私たち全員に影響を及ぼしてきた。私が住む地域の公立学校でさえハッキングされた。複雑な世界でワークロードを処理するために必要なシステムの複雑さを考えると、小規模な組織がゼロトラストスタックを実装するためのITスタッフとハードウェアリソースを、どうすれば用意できるというのだろうか。
もちろん、今日行われているハッキングの多くは、クリックすべきでないメールのリンクを誰かがクリックするという単純なものだ。しかしそれもゼロトラストの一部であり、ハッカーは日々手口を高度化させ、より巧妙になっている。例えば学校システムがゼロトラストスタックを構築するなら、ハードウェアとソフトウェアすべてについてゼロトラストスタックの原則を統合し、環境全体に多要素認証を実装する必要がある。学校システムのIT管理者をしているいとこがいるが、彼にはこれを検討する予算もリソースもない。幸い、今のところ彼のシステムはハッキングされていない。
関連記事：ランサムウェアに強いアーキテクチャの構築
クラウドサービスプロバイダーはどうなのか？
クラウドサービスプロバイダー（CSP）は、従来型のハードウェア（サーバーとネットワーク）ベンダーやソフトウェアベンダーに対して、数多くの理由から大きな優位性を持っている。
- CSPが管理し、大部分を自社で開発している単一のソフトウェアスタックがあり、監視向けに統合できる。ネットワーク監視、多要素認証の監視、OS監視などを個別に用意する必要はなく、CSP自身がそれらを統合・調整・相関付けしている。
- ハードウェアスタックはクラウドサービスプロバイダーが管理している。CSPは大部分のハードウェアを自社で構築しており、CPUまで自社開発している。ネットワーク機器、NVMe SSD、マザーボードも自社で構築する。ファームウェア、署名、サプライチェーンを管理している。すべてがCSPによって統合されている。
- エントリーポイントは厳重に監視されている。CSPに接続すると、すべてがクラウドサービスプロバイダーによって監視される。侵害が発生した場合、異常な挙動があればCSPのほうが先に検知するため、あなたが気づく前に把握している可能性もある。
確かに、クラウドサービスプロバイダーの利用は、自社でITインフラを所有するよりも高くつく可能性がある。しかし、そのコストによって、ほとんどの組織が負担できず、実現も望めないほど高いレベルのセキュリティが得られる。そのため、コスト差はかつてほど大きくないのかもしれない。CSPはハッキングされたことがあるのか。ある。ただし、最後の大規模な侵害はGoogleに対する2009年の中国発ハッキングだった。それ以降、CSPに対する大規模なハッキングが公になった例はない。例外は、顧客サイトに侵入してからCSPや、CSPの顧客が公開状態にしていたデータベースに侵入した攻撃だ。もちろん、私たちが知らない事例が存在する可能性はある。しかし、私たちが把握している限り、Colonial Pipelineのような侵害はCSP環境では発生していない。
これらすべてが意味すること
私の見方では（半ば引退して考える時間がたっぷりあることも付け加えておこう）、この状況が意味するのは、2つのうちどちらかが起きなければならないということだ。
- 現在のハードウェアおよびソフトウェアベンダーは一丸となり、統合され安全なゼロトラスト環境を構築しなければならない。それは、各家庭のPCから中堅・中小企業、大企業まで、誰もが実装できるものである必要がある。企業や組織向けのテスト環境を用意し、アップグレードや新しいワークロードのテストを確実に行えるよう、予算を定義しなければならない。特に難しい作業の1つは、顧客の現在および将来のワークロードを再現するテストスイートを開発し、自動ポリシー生成によってシステムが不必要に停止されないことを確認することだ。
- あるいは、ゼロトラストスタックを備え、あらゆる種類のワークロードジェネレーターを持ち、現在および将来の顧客ワークロードを経験している可能性が高いポリシー管理システムも備えた大手クラウドベンダーへ、全員が移行すべきだ。
仏陀には申し訳ないが、中間の道はない。現在の状況を続けることはできず、何かが変わることになる。
ゼロトラストが将来の要件になるなら、そして私はそうなると考えているが、従来型の商用オフザシェルフ（COT）オンプレミスベンダーは、ゼロトラストスタックを開発するために一丸とならなければならない。これには、ネットワーク、サーバー、ストレージ、ファイアウォールなどのハードウェアベンダー、LinuxとWindowsの双方を扱うOSベンダー、多要素認証、メトリクス、ポリシーなどのソフトウェアベンダーが含まれるが、これらに限られない。これは巨大な統合作業であり、それに加えてワークロードのエミュレーションシステムも作成しなければならない。
金融サービスや医療など、一部の大規模なオンプレミス組織には、これを自力で実施する要件とリソースがある。しかし小規模な組織にはなく、その多くが攻撃を受けてきたし、これからも受けるだろう。私から見れば、代替策は明らかだ。ゼロトラストが要件であるなら、CSPはCOTベンダーをはるかに先行している。COTベンダーは協力して標準と、すべてのプラットフォームで機能するフレームワークを開発する必要がある。これは、CSPベンダーがすでに投資してきたと思われる大規模な取り組みだ。
セキュリティは無料ではない
セキュリティは無料ではなく、支払った分だけのものしか得られない。クラウドサービスプロバイダーが自社のセキュリティ上の優位性をもっとアピールしないことには、いささか驚いている。同時に、COTベンダーがゼロトラストに取り組むため、これまで以上に迅速に団結しないことにも驚いている。しかし最も驚いているのは、誰もがゼロトラストへ移行し、現在の攻撃手法に対して一歩でも二歩でも先んじ、攻撃対象領域を今よりはるかに小さくするよう求める圧力が欠如していることだ。私は、保険会社が保険契約を結ぶ組織にゼロトラストを義務付けるのを待っている。Merck判決を受けて、サイバー保険会社はついにそれを実行する金銭的インセンティブを得たのかもしれない。
詳しくはゼロトラスト・セキュリティの主要ソリューションを参照されたい。