ゼロトラスト、ZTA、SASE、CARTA、リーントラスト……各セキュリティ用語の概要と違い（１）
従来の境界型防御では対策しきれないリスクの増大を受け、新しいセキュリティの概念やフレームワークが提唱されている。ゼロトラストとリーントラストの違いやZTAとSASE、CARTAの概要を3回に分けて解説する。
サイバーセキュリティとビジネスリスクが密接に関わる時代になり、情報セキュリティの高度化が進んでいます。「ゼロトラスト」や「リーントラスト」「SASE」「CARTA」といった新たなキーワードやフレームワークが提唱され、中には本来の意味を離れたバズワードになりかけているものも少なくありません。
これらの違いがわかりにくくなっているのは、ゼロトラストとゼロトラストアーキテクチャ（ZTA）が同義として述べられ、概念とフレームワークが混同されたり、SASEの要件の一部がCARTAに波及したり、CARTAがエンドポイントに限定されて議論されていたりするためでです。
そこで本稿では3回にわたり、それらの用語の違いと概要、アーキテクチャとしての実現方法などを具体的に紹介します。
著者プロフィール：遠藤 宗正（デジタルアーツ マーケティング部 プロダクトマネージャー）
2012年よりデジタルアーツ株式会社で、Webフィルタリング製品のプロダクトマネージャーとして従事。
内部情報漏洩対策・生産性向上のためのWebフィルタリングという製品ポジションから、外部からの悪意ある攻撃対策まで包含できる製品にシフトすべく、他社製品との連携も視野に入れて、セキュリティ市場の動向を日々伺う。
「ゼロトラスト」とは何か？ ZTAとの違いと実現する方法
各用語の詳細説明を始める前に、本記事で体系的に説明するZTA、SASE、CARTAについて下図にまとめます。
図1のうち、ゼロトラスト（ZTNA：Zero Trust Network Access）とは、既存の対策では防ぎきれないセキュリティリスクに対応するために考え出された概念です。
従来、ビジネスの情報を取り扱う場所は社内ネットワークに限定されていました。社外と社内の境界にファイアウォールを設置して社内の安全性を確保し、その中で機密情報を取り扱っていました。しかし昨今、クラウドサービスやスマートデバイス、テレワークの普及によってビジネスの現場が地理的制約を抜け、ユーザーが「正しい端末から正しいサービスに、正しくアクセスしているか」を手放しで信用できなくなりました。
アクセスを信用できる条件が変わり、従来の「境界防御」では防ぎきれないセキュリティリスクが増えたことを受けて考え出された概念が、ゼロトラストです。
境界防御の危険性は、2020年代からシスコシステムズなどが問題提起していました。ゼロトラストというキーフレーズは2010年に調査会社のForrester Researchが提唱したもので、現在は一般的な概念となっています。
ゼロトラストの対抗概念「リーントラスト」とは
リーントラスト（Lean Trust：最適化された信頼、無駄のない信頼）とは、2019年に提唱された新しい概念です。
ゼロトラストは、手放しに信頼できないアクセスをZTAやSASEなどのフレームワークで認証し、信頼を固定化することを目指すアプローチです。それに対してリーントラストは、あらゆるアクセスに信頼を求めるのではなく、信頼してもいいかどうかをリスクに応じて分けて検討し、信頼の最適化を目指します。
ゼロトラストとリーントラストの違いは、製造業における不良品や在庫管理の例で考えると分かりやすいと言われています。
| ゼロトラスト | リーントラスト | |
|---|---|---|
| 不良品に対する考え方 | 不良品を出さない | 不良品はどうしても出てしまう |
| 不良品の数 | 0 | 一定の割合 |
| 準備する在庫の数 | 0 | 適切な数 |
| 不良品が出てしまった場合 | 迅速に対応できない | 迅速に対応できる |
製造業においては「不良品ゼロを目指す」よりも「不良品が出ることを前提にした在庫計画を立てる」ことが合理的であるとされます。サイバーセキュリティにおいても、同様に「悪意あるアクセスを絶対に通さない」のではなく「悪意あるアクセスで生じるリスクを考慮して、合理的に対策する」ことを現実的と考えるのがリーントラストです。一定のリスクを許容して全体を守るため、エンドポイントのセキュリティも対象に含みます。
編集注：著作権者からの申し立てにより、一部の引用文を削除しました（2021年4月20日）
ZTA（ゼロトラストアーキテクチャ）とは
ZTA（Zero Trust Architecture）は、2020年にNIST（米国国立標準技術研究所）が「NIST SP 800-207」として発行した文書で定義された、「ゼロトラストを実現するためのガイドライン」です。
本稿はPwCコンサルティングが作成した同文書の日本語訳を基に、ZTAを実現するためには何が必要なのか、具体的な要件に焦点を絞って説明します。
ZTAは、認証と認可、暗黙のトラストゾーンの縮小に焦点を当てます。リクエストのアクションを実行するのに必要な最小限の権限を設定するため、アクセスルールは可能な限り細かいポリシー設定が必要です。アクセスの許可・不許可を決定する根拠は、下記の情報などが基になります。
- リクエストを送った主体の信頼度はどの程度か
- 主体の身元に対する信頼度を考慮した場合、リソースへのアクセスは許可されるか
- リクエストに使用されるデバイスは、適切なセキュリティ対策がなされているか
- その他に考慮すべき、信頼度を変化させる要因（例：時間、主体の場所、主体のセキュリティ態勢） はあるか
具体的なZTAを構成する理想の論理コンポーネントは、下図のように表現されます。
| 要素 | 概要 |
|---|---|
| PDP | Policy Decision Point：ポリシー決定ポイント。ユーザーや端末、サービスなどからのリソースに対するアクセスに対して、アクセスの許可・不許可を決定するシステム |
| PE | ZTAの頭脳。複数の外部ソースの入力を基にトラストアルゴリズムでリソースへのアクセスの許可・不許可を判定する |
| PA | 主体が企業リソースにアクセスするために使用する、セッション固有の認証トークンやクレデンシャルを生成し、セッションが許可されリクエストが認証されるとPAはPEPを設定してセッションの開始を許可する |
| PEP | Policy Enforcement Point：ポリシー適用ポイント。ユーザーや端末、サービスなどからのリソースに対するアクセスに対して、PDPの結果を基にアクセスの許可・不許可を実施するシステム |
| CDM | Continuous Diagnostics and Mitigation：継続的診断および対策。資産管理ソフトによる管理情報（パッチ適用済みか古いOSバージョンを利用しているかなど） |
| 業界コンプライアンス | 該当する可能性のある規制体制（例：連邦情報セキュリティマネジメント法（FISMA）、医療、金融業界の情報セキュリティ要件など） |
| 脅威インテリジェンス | 新たに発見された攻撃や脆弱性に関する情報を提供するサービス |
| アクティビティログ | 資産ログ、ネットワークトラフィック、リソース・アクセス・アクション、およびその他のイベントを集約したログ |
| データアクセスポリシー | リソースへのアクセスに関する属性、ルール、およびポリシー。企業内のアカウントやアプリケーション／サービスの基本的なアクセス権限を提供する、リソースへのアクセスを許可するための出発点 |
| PKI | Public Key Infrastructure：公開鍵基盤。リソース、主体、サービス、およびアプリケーションに対して発行した証明書を生成し、ログを取得する役割を担う |
| ID管理 | LDAPサーバなど、ユーザーアカウントおよびアイデンティティーレコードの作成、保存、管理の役割を担う |
| SIEM | Security Information and Event Management。ログを一元管理し、相関分析を行う |
さまざまな外部データソースの結果を基に、PEでのトラストアルゴリズムの判定結果を基にアクセスの許可・不許可が決定される必要があります。トラストアルゴリズムは下記の通りです。
| 要素 | 概要 |
|---|---|
| アクセスリクエスト | 主体からの実際のリクエスト。OSのバージョン、使用されているソフトウェア（例：リクエストするアプリケーションが承認済みアプリケーションリストに存在しているか）、およびパッチレベルなどのリクエスト元に関する情報と、リクエストされたリソースの情報が主に使用される |
| 主体データベースとヒストリー | リソースへのアクセスをリクエストしている主体の属性および権限。信頼度を導出する際に考慮することができるアイデンティティーの属性には、時間と地理的位置が含まれる |
| 資産DB | 組織が所有する物理的および仮想的資産（場合によってはBYOD端末を含む）の既知のステータスを格納したDB。リクエストを行った資産と比較され、OSのバージョン、ソフトウェアの存在、その完全性、位置 （ネットワークの位置とジオロケーション） 、およびパッチレベルの情報を含む |
| リソースポリシー要件 | ユーザーIDと属性データベースを補完し、リソースへのアクセスのための最低限の要件を定義する。要件には、MFAネットワークロケーション（例：海外IPアドレスからのアクセスを拒否する）、データの機密性、および資産構成のための要求などの認証保証レベルが含まれている場合がある |
| 脅威インテリジェンスとログ | インターネットで動作している一般的な脅威やアクティブなマルウェアに関する情報 |
ZTAのアプローチ方法の種類
ZTAを実現するための仕組みとしては、下記の3種類が挙げられます。
| 要素 | 概要 |
|---|---|
| IDガバナンスの拡張 | 全ての主体にネットワークアクセスは付与されるが、リソースへのアクセスは、適切なアクセス権限を持つIDに制限する手法。あらかじめAgentがインストールされた端末やポータルにログインできた主体のみにアクセスを許可することで限定する。オープンネットワークや、社外の訪問者によるアクセスやネットワークで企業が所有していないデバイスが頻繁に使用されるユースケースで有用である |
| マイクロセグメンテーション利用 | インテリジェントスイッチ（またはルーター）、次世代ファイアウォール（NGFW）などのゲートウェイ製品、もしくはエンドポイントのエージェントやファイアウォールなどのマイクロセグメンテーション機能を利用して主体に必要最低限のネットワーク構成しか与えない手法。代表的な製品としてVMware NSXなどがある |
| SDP利用 | SDP（Software Defined Perimeter：ソフトウェア定義境界）は、認証やアクセス制御を行うための制御チャネルと、実際にデータ通信を行うチャネルが独立しているため、物理境界に依存しないセキュリティを確保可能。この手法はOSI ７階層のアプリケーション層を利用する場合が多い。代表的な製品としてNetskope Private Accessなどがある |
また、ZTAを実現するための構成としては、下記の3種類が挙げられます。
| 要素 | 概要 |
|---|---|
| デバイスエージェントモデル | 端末にAgentをインストールし、Agent認証を利用する |
| リソースポータルモデル | データリソースにアクセスするためにポータルでの認証を利用する |
| サンドボックスモデル | 端末内のサンドボックス内で承認&検証済みのアプリからのみデータリースへのアクセスを許可する |
ZTAを実現するための要件は以上の通りです。これらの中から自社に最適な方法や構成を組み合わせて実現していく必要があります。SASE、CARTAを実現する要件は、次回に詳しく解説します。
Copyright © ITmedia, Inc. All Rights Reserved.