関連するソリューション
サイバーセキュリティ
ID-Ashura/セキュリティサービス
フェロー 関原 弘樹
多くの組織で年度末を迎える
3
月となりましたがメディアは新型コロナウイルスのニュース一色です。
多くの学校が休校となり数々のイベントが中止される中、みなさまも国や自治体の施策を含めた関連ニュースを注視されているのではないでしょうか。
この新型コロナウイルスに関する年初からのニュースや担当組織の動きを見ていると現実のウイルスもコンピュータウイルスも感染による被害を最小化するにはその初動がいかに大切かということがよくわかりますね。
また、○○がないとか、○○が対策になるという不確定な情報が飛び交い、それにより人々が行動するという有事の際のありがちなパターンを見るにつけ基本的な知識とリテラシーの重要性を再認識しました。
しばらくは窮屈な毎日となりますが、人との接触を避けつつ適度に体を動かしてストレス解消に努めたいものです。個人的には幸い寒さもだいぶ和らいでいることから早朝や夕方のウォーキングがおススメです。
さて、今回のコラムは「ゼロトラストアーキテクチャ」を取り上げます。
年明け後、まだ対面の打ち合わせを回避するような空気ではなかった頃にクラウドセキュリティベンダのカントリーマネージャの方とクラウドセキュリティについてディスカッションする機会がありました。
その中で最近のバズワード（？）「ゼロトラストによるセキュリティ」とはつまるところ何か？という話題になり、「アイデンティティ確認に関するセキュリティレイヤのシフトでありデータに隣接してセキュリティを担保する手法」だという議論になりましたが、個人的にはもやっとしたところが残りました。
それで関連し、
Web
を見渡してみるとタイミングよく
2020
年
2
月
13
日に
NIST
から
SP 800-207 Zero Trust Architecture (2nd Draft)
※という文書が発行されています。
ということで今回はここ
-NIST
が考えるゼロトラストアーキテクチャ（
ZTA
）とは何か？
-
を簡単ですが、スペースの許す限りみていきます。
出典： SP 800-207 Zero Trust Architecture (2nd Draft)
■NIST SP 800シリーズ
まずは前提となる本文書が含まれる
NIST SP 800
シリーズとなにかを簡単に。
・
NIST
とは ⇒
National Institute of Standards and Technology
（アメリカ国立標準技術研究所）
アメリカ合衆国商務省所管の機関。
U.S.
の技術的競争力を高めるために様々な規格やガイドラインを制定し発行している。
現在日本でも盛んに参照されている「サイバーセキュリティフレームワーク」（
CSF/Cyber Security Framework
）も
NIST
が発行している。
・
SP800
とは ⇒
NIST
内のコンピュータセキュリティ部門が発行したレポートに振られる番号
セキュリティ対策を実施する際に非常に有用とされ、全世界の様々な組織で参照される。
いまホットなものとしてはサプライチェーンのセキュリティに関して記載された
SP800-171
があげられる。
#詳細はこちらがよくまとまっています
■
SP 800-207 Zero Trust Architecture
目次から
まず本文書の目次から文書の構成をみていきましょう。なお、本稿はドラフトのため今後の稿では募集中のコメントにより修正が入る可能性があります。
1 Introduction - イントロ
2 Zero Trust Basics - ゼロトラストの基礎
3 Logical Components of Zero Trust Architecture - ZTA （ゼロトラストアーキテクチャ）の論理コンポーネント
4 Deployment Scenarios/Use Cases - 展開シナリオとユースケース
5 Threats Associated with Zero Trust Architecture - ZTA に関連する脅威
6 Zero Trust Architecture and Possible Interactions with Existing Federal - ZTA と既存の連邦政府間の影響の可能性
7 Migrating to a Zero Trust Architecture - ZTA への移行
Appendix A— Acronyms - 付録 頭字語
Appendix B— Identified Gaps in the Current State-of-the-Art in ZTA -
現状の技術で特定されている
ZTA
のギャップ
7つの章と
2
つの付録で概念的な部分から展開を完了させるまでが文書化されています。この中では２章、
3
章、
5
章あたりが興味を引きそうですね。
■
SP 800-207
の各章
各章をいくつか抜粋してみてみましょう。
★
1 Introduction -
イントロ
現在のシステムトポロジーの複雑さとサイバー攻撃の高度化による脅威に対抗するため、サイバーセキュリティの原則について新しいモデルの開発をしたという宣言があります。
それはこれまでのゾーンベース（つまり
IP
ネットワークをインフラに持つシステムであれば
IP
アドレスの範囲を基礎とした）のセキュリティから今後はデータに焦点を当てたアイデンティティの正当性の継続的な確認によるセキュリティへの移行を推進するということです。
★
2 Zero Trust Basics -
ゼロトラストの基礎
頭に近いところで
ZT
と
ZTA
の定義が記載されています。誤解を恐れず意訳するとこのようなニュアンスでしょうか。
ゼロトラスト（
ZT
）
⇒接続されるネットワークを信頼できないものとみなしたうえで、リクエストごとアクセス可否の判定をを実施する。その際に誤判定リスクを低減するために設計された概念とアイデアの集まり。
ゼロトラストアーキテクチャ（
ZTA
）
⇒
ZT
の概念をシステムへの実装したものであり、企業のサイバーセキュリティ計画そのもの。
この章ではゼロトラストの基礎は最小限の権限付与と継続的な権限の評価であるということが述べられています。実装のハードルはともかく海外のセキュリティフレームワークになじんでいる方にはなじみやすい考え方です。
また原則では保護すべきリソースのレベルに応じたマイクロセグメンテーション（個々のサーバでもセキュリティレベルが異なれば隔離する）による暗黙の信頼の最小化がポイントになるようです。
一つ特徴的なのはここでは（ネットワーク図上での）空間的な意味での隔離だけでなく（各セッションという）時間軸上での隔離も示唆されていることです。
そして、ここでは
PDP
（
Policy Decision Point/
ポリシーを決定する機能）
/PEP
（
Policy Enforcement Point
決定によりアクセスを制御する機能）という用語が出てきます。実装にはこれらをどのようにコントロールし、一貫したポリシーを適用していくかというところがテクニカルなポイントになりそうです。
この章最後では列挙となってしまいますが
ZTA
の基本的な
7
つの教義とネットワークインフラに関する前提条件についてピックアップします。
・ZTAにおける7つの教義
１．All data sources and computing services are considered resources.
すべてのデータソースとコンピューティングサービスはリソースと見なされる。
２．All communication is secured regardless of network location.
ネットワークの場所に関係なく、すべての通信が保護される。
３．Access to individual enterprise resources is granted on a per-session basis.
個々のエンタープライズリソースへのアクセスは、セッションごとに許可される。
４．Access to resources is determined by dynamic policy—including the observable state of client identity, application, and the requesting asset—and may include other behavioral attributes.
リソースへのアクセスは、動的なポリシー（クライアントID、アプリケーション、および要求元の資産の監視可能な状態を含む）によって決定され、他の動作属性を含めることができる。
５．The enterprise ensures that all owned and associated devices are in the most secure state possible and monitors assets to ensure that they remain in the most secure state possible.
企業は所有および関連するすべてのデバイスが可能な限り最も安全な状態であることを保証し、資産を監視し、それらが可能な限り最も安全な状態であることを確認する。
６．All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
リソースの認証と承認はすべて動的であり、アクセスが許可される前に厳密に実施される。
７．The enterprise collects as much information as possible about the current state of network infrastructure and communications and uses it to improve its security posture.
企業は、ネットワークインフラストラクチャと通信の現在の状態について可能な限り多くの情報を収集し、それを使用してセキュリティ体制を改善する。
・ネットワークインフラの前提
⇒エンタープライズ（企業自らが所有し管理）
１．The entire enterprise private network is not considered an implicit trust zone.
エンタープライズプライベートネットワーク全体は、暗黙の信頼ゾーンとは見なされない。
#イントラ内に既に侵入者がいることを念頭に置いている
２．
Devices on the network may not be owned or configurable by the enterprise
ネットワーク上のデバイスは、企業が所有または構成することはできない。
#BYODを筆頭に自社資産以外のリソースの利用を念頭に置いている
３．No resource is inherently trusted.
本質的に信頼されるリソースはない。
⇒非エンタープライズ（上記以外）
１．Not all enterprise resources are on enterprise-owned infrastructure.
すべてのエンタープライズリソースがエンタープライズ所有のインフラストラクチャ上にあるわけではない。
２．Remote enterprise users cannot fully trust the local network connection.
リモートのエンタープライズユーザーは、ローカルネットワーク接続を完全に信頼することはできない。
#これらはクラウドの利用やリモートアクセスを念頭に置いている
★3 Logical Components of Zero Trust Architecture - ZTA（ゼロトラストアーキテクチャ）の論理コンポーネント
ZTAの構成要素に関してのテクニカルな章になります。
スペースの関係で詳しくは語れませんが
中心となるのは先ほどのPDP/PEP
ということを示す図ですね。あくまでも論理モデルで各機能の配置は様々でしょう。
ただ、これだけ見るとアクセスフローがスクリーニングされているというよくあるセキュリティのパーミッションの図に見えます。また、曲線外部のコンポーネントとの連携で
ZTA
の原則を貫いた場合、どのようにスケールできるのかも実装の課題となりそうです。
また、ここではゼロトラストアーキテクチャアプローチのバリエーションについて述べられています。
サブタイトルを拾ってみると
3.1.1 ZTA Using Enhanced Identity Governance
リソースへのパーミッションを細分化し拡張された
ID
統治を中心としたモデル
3.1.2 ZTA Using Micro-Segmentation
リソースの隔離とゲートウェイへのアクセスを中心としたモデル
3.1.3 ZTA Using Network Infrastructure and Software Defined Perimeters
SDN（ソフトウェア定義ネットワーク）のオーバレイとアプリケーションのレイヤを連携させたモデル
というようになっています。
抽象アーキテクチャの展開に関するバリエーションでは
3.2.1 Device Agent/Gateway-Based Deployment
3.2.2 Enclave-Based Deployment
3.2.3 Resource Portal-Based Deployment
3.2.4 Device Application Sandboxing
とエンタープライズネットワークの機能の配置に応じた展開が解説されています。
そして、ここではなにを信頼するか
-
トラストアルゴリズム
-
のバリエーションについても述べられています。
主要な特性として「基準ベース
vs
スコアベースの評価」と「単一
vs
コンテキストベースの評価」という考え方が紹介されています。
この章最後はネットワーク
/
環境コンポーネントに関しての
10
の要件ですが、まあほとんどは当たり前といったところでしょうか。
１．Enterprise assets have basic network connectivity.
もちろん接続は必要です。
２．The enterprise must be able to distinguish between what assets are owned or managed by the enterprise and their current security posture.
資産のインベントリとポリシーは引き続き重要ですね。
３．The enterprise can capture all network traffic.
“Can”ですね…すべてのトラフィックのキャプチャ…どのように解釈すればいいのか注視したいです。
４．Enterprise resources should not be reachable without accessing a PEP.
コストとアベイラビリティのバランスがまず思い浮かびます。
５．The data plane and control plane are logically separate.
各プレーンの最終的なエンドポイントもロジカルでいいのかちょっと気になります。
６．Enterprise assets can reach the PEP component.
PEPによるアクセス制御の前提ですね。
７．The PEP is the only component that accesses the policy administrator as part of a business flow.
設計時の重要なポイントです。
８．Remote enterprise assets should be able to access enterprise resources without needing to traverse enterprise network infrastructure first.
クラウドサービス利用時のための項目でしょうか。
９．The infrastructure used to support the ZTA access decision process should be made scalable to account for changes in process load.
スケールする設計が必要なのはそうですが、ベストプラクティスがどうなるのか興味があります。
１０．Enterprise assets may not be able to reach certain PEPs due to observable factors.
NG対応も設計する必要があるということですか。
★4 Deployment Scenarios/Use Cases - 展開シナリオとユースケース
ここではテレワークを推進する企業やマルチクラウドを活用する企業、そしてパートナーへの委託業務が多い企業についての展開シナリオとユースケースが紹介されています。
ポイントは各リソースの位置関係とネットワークの所有者というところでしょうがか。
★5 Threats Associated with Zero Trust Architecture - ZTAに関連する脅威
高度化する脅威に対応するための新たなセキュリティ原則として提唱されている
ZTA
ですが、この
ZTA
を導入することで発生する新たなリスクというものも当然存在します。
本章ではその新たなリスクについて
7
つほどピックアップされています。
ただし、これらはすべて既存のセキュリティアーキテクチャにも当てはまります。あえて言うならば
5.5,5.6
あたりのスコープが広がったところかなというイメージです。
5.1 Subversion of ZTA Decision Process - ZTA
決定プロセスの転覆
ZTAを中心で支えるPDP/PEPの機能への攻撃が成功すれば当然すべてが危殆化します。
5.2 Denial-of-Service or Network Disruption -
サービス拒否またはネットワークの中断
火災発生時に施錠された扉の問題。オープンか？クローズか？テクノロジーに収束しない問題です。
5.3 Stolen Credentials/Insider Threat -
盗まれた資格情報/内部脅威
ZTA固有の問題には感じませんが、ZTAが認証・認可の強化という性質を持つ以上クレデンシャルの保全は既存のセキュリティアーキテクチャ以上に重要です。
5.4 Visibility on the Network -
ネットワーク上の可視性
分散型アーキテクチャでは避けて通ることができない通信経路の問題。エンタープライズネットワークでは最終的に誰がどのように可視化できるかという問題に収束しそうです。
5.5 Storage of Network Information -
ネットワーク情報の保存
ここはちょっと厄介な部分。守るべきものが増えたという感があります。
5.6 Reliance on Proprietary Data Formats -
独自のデータ形式への依存
今後ZTAが普及していくのであればこれまでのIoC（Indicator of Compromise/セキュリティ侵害インジケーター）の交換のように標準化が進む可能性があり、あまり問題ではないのでは？という印象です。
5.7 Use of Non-person Entities (NPE) in ZTA Administration - ZTA
管理での非個人エンティティ（NPE）の使用
AIによる自動化の問題としてとらえてみます。今後もフォルスポジティブの問題は収束することはないと考えていますが、自動化に全面的に依存しない場合ZTAのスケーラビリティへの影響が大きいということは言えるかもしれません。
また、判断を下すためのデータのかく乱（意図した偽データの混入）についてはZTAに限らず今後のセキュリティの一ジャンルとして考えるべきかもしれません。
★7 Migrating to a Zero Trust Architecture – ZTAへの移行
一つ飛ばして現状からの移行に関する章です。
以下の
2
つのアーキテクチャ（
ZTA
ピュアと
ZTA+
ゾーンベースのハイブリッド）が紹介されています。
7.1 Pure Zero Trust Architecture
7.2 Hybrid ZTA and Perimeter-Based Architecture
内容を見るとピュアはかなり導入のハードルが高いニュアンスになっていますね。
続いて以下のように展開の各フェーズが示されます。要件
/
要件定義・設計にあたるリスクアセスメント・ポリシー設定が重要なのはもちろんですが、その前段のアセスメントの枠内のビジネスプロセスレビューも必要なステークホルダを巻き込んで進める必要があるためかなり負荷が高くなりそうに感じます。
■まとめ
限られたスペース（と私の知識）で今後一定の話題となるであろう
NIST SP800-207 Zero Trust Architecture
のドラフト版についてみていきました。本コラムでゼロトラストアーキテクチャの概要を共有できれば幸いです。
しかしながら、規定される部分（というか私の理解）が概念的なものにとどまり、書いている中でも「まあ、これは相手を正しく認証して、その相手が持つべき最小限の権限だけを正しく渡す」というセキュリティの考え方では当たり前のことだよねと感じてしまうのも正直なところです。
現場でセキュリティを考える方々にとっては依然として正しい相手をどう確認するのか？何が最小限の権限なのか？というところを限られたコストと必要とされる可用性の間で解決していく必要があり、
ZTA
がすぐにバラ色の未来をもたらしてくれるかというと引き続き今後の展開を待つ必要があるのかなという印象となりました。
弊社コラムでは昨年、内山エバンジェリストが以下のようなコラムを執筆しております。こちらもぜひご覧ください。
また、
”
ゼロトラスト
”
とセキュリティに関する書籍では以下のようなものが出版されています。
ゼロトラストネットワーク
――境界防御の限界を超えるためのセキュアなシステム設計
■おわりに
免疫力が健康のための最大の武器と考えている私が新型コロナウイルス関連で今一番気になっていることは再発についての情報です。
本当に免疫反応の抑制機能があり同じウイルスに再感染しているのか、実はウイルスが残存しており検査でのウイルス検出力の問題で「回復宣言」が誤りだったのか続報を待ちたいです。
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
