ネットワーク&エンドポイント

ゼロトラスト・セキュリティーの要諦

記事をシェアする:

ゼロトラスト・セキュリティーが求められる背景

近年、企業における働き方改革やクラウド活用の促進などにより、保有する情報資産の配置場所や、情報資産へアクセスするクライアント・デバイスの場所は多様化しています。これらの変化に伴い、従来、企業内のオフィス・ネットワークに配置されたクライアント・デバイスや、企業内のサーバー・ネットワークに配置されたサーバーに対するセキュリティー対策を、根本的に変えていくことが求められています。

従来の境界対策モデルを標準とし、例外的な接続のみを考慮していればよかった時代とは異なり、クライアント・デバイスと接続する情報資産の形態の組み合わせが時間と共に変化・多様化していく中では、これらの多様化を前提としたモデルの選択が必要です。このような状況において、2010年にForrester Research社により提唱された「ゼロトラスト・セキュリティー」の概念が再び脚光を浴びつつあります。

本記事では、ゼロトラスト・セキュリティーの考え方を整理し、企業においてゼロトラスト・セキュリティーの考え方を適用する場合のデザインの留意点について記載します。

ゼロトラスト・セキュリティーとは

従来、企業は信頼のおけないネットワーク空間(例:Internet)との間に境界を設け、境界の内側は信頼できるゾーンとして定義してきました(境界型セキュリティー・モデル)。しかしながら、クラウド利用の促進や、働き方改革により、企業内からではなくInternet上から企業の情報資産にアクセスするケースが急増し、境界の内と外という概念のみでセキュリティー・モデルを維持できない状況となっています。

このような状況下では、境界内が安全であるという接続環境の前提に立ったモデルではなく、全ての情報資産へのアクセスは前提を置かないモデルを採用する必要があります。

2010年にForester Research社により提唱されたゼロトラスト・セキュリティーの概念は、全ての情報資産へのアクセスは信頼でできないことを前提とし、1つ1つのアクセスに対してチェックを行い、信頼できるものだけにアクセスを許可するというセキュリティー・モデルです。ゼロトラスト・セキュリティーの概念が脚光を浴びている背景として、境界内が安全であるという前提を置くセキュリティー・モデルが破綻しつつあるということが考えられます。

ゼロトラスト・セキュリティーの背景

Fig 1. ゼロトラスト・セキュリティーの背景

ゼロトラスト・セキュリティー・モデル

ゼロトラスト・セキュリティーは、アクセス時の信頼をゼロとして必要なセキュリティー上のチェックを行い、チェックをクリアしたアクセスのみが信頼された(信頼がゼロではない)アクセスとして情報資産へのアクセスを可能にするモデルです。状態遷移で表現すると、ゼロトラスト状態(初期状態)から、アクセスのチェックをクリアした場合に、トラスト状態に遷移します。

重要となるのは、トラスト状態に遷移する際に行うチェックをどの程度まで実施するかです。

トラストレベルと状態遷移

Fig 2. トラストレベルと状態遷移

チェック項目を増やした分だけ信頼性は上がるものの、チェックを満たすための対策を実装するためのコストや、ユーザ側の利便性が低下する可能性への配慮も必要です。

これらの対策をどこまで実装すべきかは、従来同様、アクセスすべき情報資産の重要度や、想定する脅威の発生頻度を考慮に入れたリスク評価を行った上で定めるべきです。なお、トラスト状態とは、リスクが一定水準以下に抑えられている状態であり、決してリスクゼロの状態ではないことに注意する必要があります。

トラスト状態のリスクレベルは、企業が持つ情報資産の重要度やセキュリティーにかけるコストの大きさ、リスクの許容度に依存するため、ゼロトラスト・セキュリティーを導入しようとする企業は、リスク評価に基づいたセキュリティー設計を行うことが求められます。

ゼロトラスト・セキュリティーのデザイン

ゼロトラスト・セキュリティーをデザインする上で重要となるポイントは、トラスト状態へ遷移させるアクセスのリスクレベルを判断することです。リスクレベルを判断する上で参考になるのは、現状のオンプレミス環境におけるセキュリティー上の前提条件と、何をチェックしているのかという点の分析になります。

前提(例)

  • 社内利用されているPCはラベルが貼ってある会社貸与PCのみである
  • 会社貸与PCは必要なセキュリティー対策が実施された上で貸与されている

チェックされている内容(例)

  • ユーザID、パスワードで本人認証をおこなっている
  • ウィルス対策やHDDの暗号化をPC起動時にチェックしている

ゼロトラストの基本は、上述の前提が無くなることが根本的な考え方であるため、以下のようなチェックをシステム上で実装することになります。

  • アクセス元の端末は会社貸与のPCか(アクセスを許可された正式な端末か)
  • アクセス元のセキュリティー対策は適切に実施されているか(ウィルス対策、HDD、そのほか対策)
  • アクセス元のユーザはアクセスを許可された者か(ユーザID、パスワードによる認証)

上述のチェックだけでは十分ではなく、例えばInternetからの接続を前提とする場合は脅威の発生可能性が高くなるため、デザイン上は、認証強度の強化(多要素認証の採用)なども含めて検討を行うことが必要となります。

デザインの流れとしては、現状のオンプレミス環境でのセキュリティー上のチェック項目および、前提としてチェックを省いている項目の洗い出しを行ったうえで、新しくデザインするゼロトラスト・セキュリティーのチェック項目との間に、リスクレベルでの差異が無いことを目標としてデザインを行います。

ゼロトラスト・セキュリティーのモデルの実装は、機能面、アーキテクチャー面での制約を受ける可能性があるため、ゼロトラストへの移行に際して、現状よりもセキュリティーレベルが下がる場合は、セキュリティーリスクの受容や別のリスク低減策を講じることが必要です。デザインの中では、それらの差異を明確にし、企業としての判断を行うことが必要となります。

Draft 800-207 Zero Trust Architecture

ゼロトラスト・セキュリティーに関しては、NISTからもドラフト版ではありますが、考え方が提示されています。全体で7章構成ですが、2章がゼロトラスト・ネットワーク・アーキテクチャーとなっており、大まかな考え方について示されています。2章では、端末から守るべき資産(データ)に対してのアクセスが行われる際に、必ずチェックが行われるべきであると述べられており、データへのアクセス前に、アクセスの信頼性と妥当性を確認するモデルが提示されています。

Zero Trust Access(NIST SP800-207参照)

Fig 3. Zero Trust Access(NIST SP800-207参照)

さらにこの章の中で、ゼロトラストの考え方として、6つの基本的な考え方の原則が示されています。この考え方において特徴的なのは、信頼性はネットワークに依存するものではないと言及されていることです。他方、アクセスしてくるユーザーに付随するさまざまな属性に基づき、リスクレベルが想定の基準を満たしているのかを判断されるべきであるとも述べられています。

信頼性がネットワークに依存するものではないことが記載されていますが、反面、特定のネットワークからくるということは、その事実自体がユーザーに付随する属性とも言えます。アクセスしてくるユーザーが属するネットワーク上で担保されている信頼性は、ユーザーに付随する属性の一つであり(ユーザーがどこから来たかという属性)、そのネットワークで担保されているセキュリティー上のチェック内容などは信頼性の評価のベースになりうると考えることも可能です。

つまり、あるネットワークでは十分強力なチェックが行われており、ウィルス対策ソフトが導入されていることを担保しているとしたら、そのネットワークから来たというユーザーの属性は、ウィルス対策ソフトが導入されているということを保証することになるという解釈も可能です。

接続元によるトラストレベルの開始点の差

Fig 4. 接続元によるトラストレベルの開始点の差

この辺は、ユーザーの属性のチェックの結果、リスクレベルが想定の基準を満たしていることを条件にアクセスを許容する旨が記載されており、若干あいまいな表現となっています。

ゼロトラストにおいて、良い設計を行うためには、本質の部分を理解する必要があると考えます。ただ闇雲にネットワークは信頼しない、全てゼロからチェックするというような、字面通りの解釈をせずに、設計していくことが重要であると考えます。本質的には、ゼロトラスト・セキュリティーは、環境の変化を機に、企業としてのアクセスをリスクベースで考え直すことが必要であることを示唆しています。

ゼロトラストの検討例

ゼロトラスト・セキュリティーでは、全てのアクセスを信頼できないものとして設計を行っていくため、実際に考慮しなければならない対策はアクセスのチェック以外にも多くあります。一般的には、「接続元アイデンティティーの正当性検証」、「ネットワークのセグメント化」、「権限の最小化」、「活動の可視化(ログの収集・分析)」などが必要といわれていますが、本稿では、「接続元アイデンティティーの正当性検証」に焦点を当てて、実際のお客様においてゼロトラスト・セキュリティーを検討した際の紹介を行います。

検討は、以下のステップで行いました。

 (1) アクセスパターンの整理
 (2) 検証機能のデザイン
 (3) アクセスパターンの集約

(1) アクセスパターンの整理
最初に具体的なアクセスパターン(現状と将来実現したいアクセス)の定義を行いました。

アクセスパターンの整理

例示は3パターンに簡略化しているが、実際の検討の中では、26パターンの実アクセスケースについて検討を行っている。それら26のケースを抽象化、モデル化していく過程で本例は3パターンにまで整理されたアクセスパターンの例となる。
※ 実際の検討ではインターネットから社内システムを使うケースなども含めたパターン等、3パターン以上のケースがモデルとして残ったが、便宜上、本記事では3パターンのみの例示とする

Fig 5. アクセスパターンの整理

アクセスパターン例 From → To
パターン1: 社内ネットワーク → 社内情報資産(既存)
パターン2: 社内ネットワーク → クラウド情報資産(既存)
パターン3: Internet → クラウド情報資産(新規)

従来、社内ネットワークからの接続のみを想定していたお客様ですが、ワークスタイルの変化により、直接Internetから情報資産へ接続する方法をとることになりました(既存では、Internetから接続する場合は、社内ネットワークにVPN接続してからInternet上の情報資産を利用するルールとなっていました)。

(2) 検証機能のデザイン
検証機能のデザインは、既存のアクセスパターンに対する検証機能の調査を行い、必要な検証機能項目の洗い出しを実施しました。同等の信頼性を確保するため、新しいアクセスパターンにおいては、以下の検証を行うこととしました。

新しいアクセスパターンに必要とされる検証機能
✓ 接続ユーザの正当性(多要素認証)
✓ 接続デバイスの正当性
✓ 接続デバイス上で実施されているセキュリティー対策の正当性

(3) アクセスパターンの集約
最後に、アクセスパターンの集約を検討しました。各パターンが新しく作る検証機能を利用した場合の、既存システムへの影響、利便性への影響などを評価の上で、集約検討した結果、社内からのクラウド利用(パターン2)は、新しく実装する検証機能を利用する結論となりました。

全てのエンドポイントからのアクセスを信頼出来ない前提でチェックするトラスト検証機能を用意すれば、全てのパターンを1つに集約することも可能となりますが、既存の枠組みやユーザの利便性を考慮してデザインを行うことが重要です。

ゼロトラストの概念の最も大きなメリットは、トラスト検証を行う機能を統合化、一元化することにより、接続元、接続先の変化を吸収できることと考えます。ワークスタイルの変化、クラウドの活用、将来的にはIoTの活用などを視野に入れると、トラスト検証を行う機能を実装することのメリットを十分に享受できると考えます。

但し、コスト面、利便性から、今までのレガシーな仕組みも活かした形で実装を行っていくことも重要となるため、このお客様の例では、1つのパターンにまとめることなく、旧来のレガシーな接続パターンは活かしつつ、新しいトラスト検証機能を実装する方向性を取る結果となりました。

アクセスパターンの集約アーキテクチャー

既存のオンプレ上に構築されていた機能は、Internetからの接続のケースと統合し廃止としました。
Internetからの利用を考慮した場合に、Internet上から直接クラウドサービスの利用が必要であったため、SaaS型のPDP/PEDの採用を決定しました。

Fig 6. アクセスパターンの集約アーキテクチャー

最後に

ゼロトラストは、「あくまでアクセスしてくるものは信頼性が無いものと考えるという考え方です。この考え方は、内部不正等の権限を持った人間の不正行為に対する有効性は低いものと考えられます(内部不正に対する対策が行われているのかのチェックは可能)。ゼロトラストの考え方を内部不正対策に適用する場合、コストや利便性においてある程度の妥協が必要になるため、場所を固定した従来型の境界対策は依然として有効です。

ゼロトラストは、働き方改革やクラウド化において検討すべき基本となるセキュリティーの考え方であり、ゼロトラスト・セキュリティーを導入しようとする企業は、情報資産の重要度やセキュリティーにかけるコストの大きさ、リスクの許容度を含め、リスク評価に基づいたセキュリティー設計を行うことが求められます。

最後に、IBMでは、ゼロトラスト・セキュリティーの導入に関連して、以下のソリューションおよび、ソリューション導入に際してのコンサルティング・サービスを提供することが可能です。

1. ID検証の強化

2. 機密データのセグメント化

3. アクセス・行動履歴の精査

また、これらのソリューションに限らず、ゼロトラスト・セキュリティーの考え方を取り入れたセキュリティー・コンサルティングやアセスメント、セキュリティー・インフラやアーキテクチャーの設計支援など、さまざまなサービスの提供が可能です。

【関連情報】

【お問い合わせ】

日本アイ・ビー・エム株式会社 セキュリティー事業本部 セキュリティ&リスクコンサルティング部長 中島大輔まで、にてお問い合わせください。

【著者情報】


川端 邦明

執筆者

川端 邦明
日本アイ・ビー・エム株式会社
セキュリティー事業本部
コンサルティング&システム・インテグレーション
シニアマネージングコンサルタント

2001年に日本アイ・ビー・エム株式会社に入社。IAM分野のシステム設計、開発、構築に携わったのちに、2010年より、IBM グローバルビジネスサービスにて、セキュリティコンサルタントとして活動。
IAM分野、セキュリティ・アセスメント、CSIRT構築等、広い分野でのコンサルティングプロジェクトに携わる。IAM分野および、アセスメント分野におけるコンサルタントとしての豊富な経験を有している。


中島 大輔

サービス責任者

中島 大輔
日本アイ・ビー・エム株式会社
セキュリティー事業本部
コンサルティング&システム・インテグレーション
セキュリティ&リスクコンサルティング部長

1991年に日本アイ・ビー・エム株式会社に入社。お客様担当SEとして主にネットワーク・インフラ分野の設計・構築を担当後、2003年よりセキュリティー・コンサルタントとして、グローバル・セキュリティー管理態勢整備、CSIRT構築、セキュリティー・アセスメント、リスク分析、プライバシー保護、技術情報保護など、業種、分野問わず、サイバーセキュリティーにかかわる数多くのコンサルティングやプロジェクトをリードし、チームビルディングや組織マネージメントに豊富な実績を有している。


小川 真毅

事業責任者

小川 真毅
日本アイ・ビー・エム株式会社
セキュリティー事業本部
コンサルティング&システム・インテグレーション
理事/パートナー
CISSP CISA CISM CBCI PMP MBA

More ネットワーク&エンドポイント stories
2024-02-27

大規模言語モデル(LLM)の隠れたリスク:催眠術をかけられたAIの実状

この記事は英語版 Security Intelligenceブログ「Unmasking hypnotized AI: The hidden risks of large language models」(2023年8月8 […]

さらに読む

2023-02-22

IBM Security Trusteer Rapport (ラポート)のダウンロードおよび購入を騙る不審サイトにご注意ください

架空の団体から贈与金を受け取れる等のフィッシング・メールが届き、メール本文に記載されたリンクをクリックすると不正サイトへ誘導され、金銭を安全に受け取るためと称して IBM Security Trusteer Rappor […]

さらに読む

2022-03-17

ゼロトラスト・セキュリティーの実現に向けたSASE導入ポイント

  1. はじめに Tokyo2020に向けて一部の企業がリモートワークを推進してきましたが、2020年初頭からCOVID-19の流行によりテレワークのニーズが急速に高まったのは記憶に新しいと思います。 またそ […]

さらに読む