Intro

CTO室所属の@ken5scal(鈴木研吾)です。

自分が携わったO’Reillyのゼロトラストネットワークの初版が発刊されて１年（と３ヶ月）が経過しました。この１年は、大小多くのサイバーセキュリティインシデントが起こり、同時にコロナ禍といった災害に遭うなど、様々な方が考え方を見つめ直さざるを得なかったかもしれません。そのせいもあってか自分が想像していた以上に広く認知されたゼロトラスト(=以下「ZT」)について、今回は取り上げたいと思います。

とはいえ「ZTとは何か」という資料は数多くあります。特に去年発刊された日経ムックの「すべてわかるゼロトラスト大全 さらばVPN・安全テレワークの切り札 」は、ZTのコンセプト、ZTのコンポーネント、コンポーネントごとの製品群、それらを組み合わせた事例紹介が集められており、非常におすすめです。これからZTをゼロから知りたい方や、具体的な導入イメージを持たれたい方には、すでに優れたものがありますので、当ブログであらためて語る必要はないかと思われます。

ただ、私が気になるところは苦労して学習・導入したZTが、2020年に発生した多くのサイバーインシデントに対して効果があったか、という点です。インシデントを直接的にZTにつなげようとした刊行物が多かったわけではありませんが、インシデントは不安を駆り立てるものであり、不安は直情的で本質を見失った対応を招きがちです。GitHub利用禁止のような、まるで原因と関係ない結果や、多くの予算と貴重な工数をかけてまでガチガチに固めた施策が思うような効果を挙げられない結果を見て、モヤッとされた経験はないでしょうか。そこで本稿は2020年のインシデントを振り返りつつ、改めてWhy ZTを考えつつ、個人的に集中すべきと思う対策についてお話しようと思います。

2020年の国内インシデント

ざっと、国内企業で目立ったインシデントをリストアップしてみましょう。

1.ランサムウェア感染による情報漏洩
2.VPNをまたいだ国外支社経由の不正アクセス
3.銀行の口座認証突破からのキャッシュレス事業者経由の不正出金
4.証券会社のユーザー認証突破からの銀行口座経由の不正出金
5.ドメインレジストラ上の自ドメインレコードの不正変更
6.導入サービス運営会社経由の情報漏洩
7.導入サービスにおける挙動の変更による情報漏洩
8.導入サービスにおける構成不備による情報漏洩
9.クラウドサービスの認証・認可連携におけるフィッシング

事業者名こそ記載されていませんが、メジャーな新聞やオンラインニュースでも報道されたものばかりです（どの事件のことかわからない方は、TwitterのDMで聞いていただいてもおｋです）。

これらのインシデントに、（やや乱暴なまとめ方ですが）「何も信頼しない」コンセプトのZTであれば、適切に対応できたものはあるでしょうか。
もちろん全インシデントが最終レポートを公開しているわけではありません。むしろインシデント発生に関する第一報から続報待ち状態のインシデントのほうが多いでしょう。公開情報だけで是非を判断するのは、インシデントの分析には本来はよろしくありません。加えてサービス環境におけるインシデントも混在しています。しかし、本ブログの目的であるZTの立ち位置を語るために、あえてやります。

まずはZTでは対処しきれなかったものから始めます。結論からいうと3~8は、仮にZTを完璧にやれたところで、対応がしきれたとは言えません。3~6は複数の業界に所属する組織間で発生したインシデントで、単一の組織のセキュリティレベルが高かったとしても意味がないからです。例えば4ですと、証券口座からの出金時の認証がセキュアで、かつ、振り込み先の銀行口座開設のための身元確認のレベルが高くなければなりません。同時に、証券口座と銀行口座の所持者が一致するための連携方式もセキュアである必要があります。１つの銀行口座が厳しい身元確認をしていたところで、別の銀行の身元確認が脆弱であれば、エンドユーザーの手元からお金がなくなるリスクは、依然としてあり得るのです。勿論、クレジットカードのように保証制度を用意することで、顧客を保護する事も考えられますが、業界をまたいだ場合の保護が不十分であったことは、3の初期顧客対応からみても明らかでしょう。

重要なことは、責任の所在ではなく、スコープが組織単位になっているZT及びソリューションの帰結として、複数の主体をまたがるセキュリティ・インシデントは十分な効力をあげにくい、ということです。

では、１つの組織内でおきた6~8のケースではどうでしょう。利用しているSaaSのデフォルト構成による外部に情報漏えいが発生する場合、自社のポリシーと実装間でのギャップがあるということです。要件と実装間の違反、つまりコンプライアンスポリシー違反、といってもいいかもしれません。今までZTの範疇に含めた書籍等を筆者は見たことはありません。

ビジネスを含む周辺環境が大きく、そして劇的に変わるにつれ、物理的な調達とOSやミドルウェア周りの構成をしなくて済むクラウドサービスの利用は、かなり合理的な選択になっています。その波は、スタートアップのような小規模民間にとどまらず、行政にも及んでいます。素早く価値がだせるということは導入当初からリスクがあるということです。コロナ禍でのヒューマンリソースの不足から、物理的に広範囲で利用可能なクラウドサービスを導入したものはいいものの、構成が不十分でありリスクが顕在化してしまったインシデントも、多かった印象を受けました。一方、クラウドサービスが突然そのデフォルト値を変えることもあり、意図しない結果に陥ってしまった事例もありました。初期導入か継続導入に限らず、今後はポリシーと実装のミスマッチを可能な限り素早く検知することが、組織の安定につながると予想しています。

最後に1と2を見てみましょう。ランサムウェア感染や導入サービス運営会社経由の不正アクセスはZTを適切に実装すれば防げるかもしれません。Device Hygieneの考えにもとづいたMDM/UEMやEDRといったコンポーネントが役立つでしょう。不審なシグナルを発しているサーバーや感染状況から端末を隔離したり、あるいはインベントリに記録されたOSやソフトウェア情報と脅威DBとを照合してリスク値を上げるのもいいでしょう。

今後

今回は、ZTの有効性を、国内のインシデントから考えてみました。国内のインシデントから読み取れることは、複数ステークホルダーの要件が絡むとき、ZTによって担保しようとした自組織のセキュリティが崩れる余地がありそうです。
また別のインシデントからは、自組織内でしっかりポリシーを定義していたとしても、何らかの要因により実装が要求事項とずれることがあることがわかりました。要件と実装のギャップというリスクそのものを、ZTでは検知できません。

一方、専用線やグループ会社間での感染拡大等には、ZTの「何も信頼しない」アプローチはフィットしそうです。

これらのことから、ZTがその有効性を発揮するには、以下の状態を維持する必要があるように思えます。

1.サイバーセキュリティ対策のスコープが自組織内のリソースに限定
2.構成が意図通りに実装できている

自組織をまたいだサービス全体で対策をしたい場合、現状は、複数事業者間での連絡体制や業界横断的な団体による対策推進をしていくしか、現実的な対処がなさそうです。
構成を意図通りに実装するには、定期的な監査やチェックという形で現在は対処しているかと思いますが、その頻度は1年に1回などしか実施されず、リアルタイム性に欠けています。リアルタイム性にかけるということはARO（年間発生回数）が高いということであり、ビジネスサイクルを早めようとしているスタートアップなどの環境では、最終的に算出されるリスクが高くなります。よってチェック回数を高め、違反時にできるだけ早く発見する発見的統制を高める必要があります。個人的には、Infrastructure as Codeとよばれる構成をコードで管理する方法に加えて、Policy as Codeというポリシーをコードに落とし込む分野に注目しています。Policy as Codeの話はまた別の機会に書きたいと思います。