ゼロトラストとは？NISTの7原則とCISA成熟度モデルで作る導入ロードマップ

従来は、社内ネットワークの内側は安全、外側は危険という前提で、境界（ファイアウォールやVPN）で出入りを制御して守る方法が一般的でした。クラウドサービスの利用とリモートワークが広がり、守るデータとアクセスの経路が社外へ分散すると、境界だけに頼る守り方では対応しにくくなります。委託先や関係会社との接続を経由した不正アクセスの公表事例は、情報漏洩の原因とは？被害事例から見る侵入経路と対策で整理しています。

境界型の構成でも、内部のネットワークを分けたり、サーバーごとにアクセスを制御したりしている場合があります。両者の違いは、ネットワークの内側にいることを信頼の根拠にするかどうかです。また、SaaSの利用が増えると、社外のサービスへの通信までVPNを経由させる構成では、回線や機器が混雑しやすくなります。これも、ゼロトラストを検討するきっかけの一つです。

米国国立標準技術研究所（NIST）のSP 800-207「Zero Trust Architecture」（2020年8月公表）は、ゼロトラストのアーキテクチャを設計・導入するときに従う基本原則として、次の7つを挙げています。原則の訳と、各項目の補足はこの記事によるものです。

1. すべてのデータソースとコンピューティングサービスをリソースとみなす
   社内のサーバーに加えて、クラウドのサービスやデータも、アクセスを管理する対象として扱います。
2. ネットワークの場所にかかわらず、すべての通信を保護する
   ネットワーク上の場所は、それだけでは信頼の根拠になりません。社内ネットワークに接続していることだけを理由に、端末を信頼することはしません。
3. 企業の個々のリソースへのアクセスは、セッション単位で許可する
   許可する前に要求者を評価し、作業に必要な最小限の権限で許可します。あるリソースへの認証・認可が、別のリソースへのアクセスを自動的に許可するわけではありません。
4. リソースへのアクセスは、動的なポリシーで決める
   ポリシーは、利用者のID、アプリケーションやサービス、要求元の端末の観測できる状態に基づき、振る舞いや環境（接続元、時刻など）の属性を含む場合があります。
5. 所有・関連するすべての資産の完全性とセキュリティの状態を監視・測定する
   本来的に信頼される資産はなく、アクセスの要求を評価するときに、端末などの資産の状態を評価します。
6. すべてのリソースの認証と認可を、アクセスの許可前に動的かつ厳格に行う
   これには、一部またはすべてのリソースへのMFAが含まれます。利用中もポリシーに応じて監視し、再認証・再認可を行う場合があります。
7. 資産、ネットワーク基盤、通信の現状について可能な限り情報を集め、セキュリティの改善に使う
   集めた情報を、ポリシーの作成や見直しに使います。

NISTは、これらの原則を目指す姿として示しており、すべてを完全な形で実装できるとは限らないとしています。また、ゼロトラストへの移行は段階的に進めるもので、既存の基盤や手順を一度に置き換えるものではないとし、多くの組織は長い期間、境界型の構成と併用して運用するとしています。移行を業務プロセスごとに進める形にも触れています（第7章）。

NISTは、アクセスの可否を判断する仕組み（ポリシー決定ポイント。ポリシーエンジンとポリシー管理者からなる）と、その判断に従って接続を有効にし、監視し、終了する仕組み（ポリシー実施ポイント）を分けて説明しています。判断には、ID管理の仕組み、資産の状態を監視する仕組み、脅威情報、アクセスのログなど、複数の情報源が使われます。この記事のPhase 2では、この区別を使って説明します。

米国のサイバーセキュリティ・インフラストラクチャ安全保障庁（CISA）のゼロトラスト成熟度モデル バージョン2.0（2023年4月）は、ゼロトラストの実装を5つの柱に分け、柱ごとの機能について成熟度の段階を示しています。5つの柱は、ID（Identity）、端末（Devices）、ネットワーク（Networks）、アプリとワークロード（Applications and Workloads）、データ（Data）です。

5つの柱に共通する機能として、可視化と分析、自動化とオーケストレーション、ガバナンスの3つが示されています。成熟度は、従来（Traditional）を出発点に、初期（Initial）、高度（Advanced）、最適（Optimal）の段階へ進むものとして説明されています。柱ごとに異なるペースで進めてよいとされる一方、段階が上がるほど、柱をまたいだ連携が求められます。

このモデルは米国の連邦政府機関向けに作られたものですが、CISAはほかの組織にも内容の検討を勧めており、厳密な要件ではなく一般的な指針として扱うよう述べています。この記事の3段階は、CISAの段階を言い換えたものではありません。Phase 1はID、Phase 2は端末とアクセスの判断を中心に扱いますが、どちらを終えても、CISAのどの段階に達したかを示すものにはなりません。

ゼロトラストは、全社の棚卸しが終わるのを待たずに始められます。NISTも、移行は段階的に進めるものとしています。まず、重要な業務を1つと、その業務で使うアプリを1つに対象を絞り、次の項目を確認してから着手します。VPN機器の脆弱性への対応やパッチの適用など、急ぐ対応はこの整理と並行して進めます（日常の運用は管理者と従業員のランサムウェア対策で扱っています）。

記録した内容をもとに、どこから始めるかを次の目安で決めます。

• 利用者やアプリが分からない：対象範囲の棚卸しから始めます（上の表を埋めます）。
• 対象は分かるが、IDの停止や認証の運用が安定していない：Phase 1から始めます。
• IDの運用はできるが、端末や接続先を制御できていない：Phase 2の試行へ進みます。
• 制御は導入済みだが、拒否の理由や例外を追えない：Phase 3を重点的に確認します。

これは始める位置の目安で、前の段階の確認を省いてよいという意味ではありません。Phase 2から始める場合も、対象アプリでIDを停止できることなど、Phase 1の完了条件を満たしているかを先に確かめます。

この記事では、中小企業が進めやすい順序として、次の3段階を提案します。順序と、各段階の成果物・完了条件は、いずれもこの記事の提案で、NISTの原則やCISAのモデルが定めた手順ではありません。CISAの成熟段階とも一対一には対応しません。また、各段階の完了とは、選んだ対象範囲で次の段階へ進める状態になったことを指し、会社全体のゼロトラストが完成したという意味ではありません。

1. 着手前の整理：対象範囲シートを作ります。対象と担当者が決まったら、次へ進みます。
2. Phase 1：ID・認証・権限：対象アプリの利用者と権限を管理し、利用が終わったときにIDを止められる状態にします。テスト用IDで、停止と、役割ごとの操作の許可・拒否を確認できたら、次へ進みます。
3. Phase 2：端末とアクセス条件：利用者と端末の条件で、アクセスを許可・拒否します。VPNなど別の経路も含めて許可・拒否を確認し、切り戻しを試したら、次へ進みます。
4. Phase 3：監視・例外・見直し：記録を確認し、例外と方針を見直し続けます。テストのイベントを担当者の対応まで追えたら、ほかのアプリや利用者へ広げます。

各段階は、着手条件、実施すること、成果物、完了条件と確認方法、条件を満たさない場合の対応の順に説明します。完了したかどうかは、製品を導入したことや設定を終えたことでは判断せず、担当者が確かめた動作と、その記録で判断します。

着手条件

対象範囲シートで、対象アプリ、利用者、管理者、業務責任者が決まっている。

実施すること

• 既存のID基盤（Microsoft Entra ID、Google Workspace、Oktaなど）と、契約しているプランで使える機能を、管理画面と公式資料で確認する。
• 対象アプリの利用者・管理者・権限を整理し、役割ごとに許可する操作を対応表に記録する。不要な権限は外す。
• MFAの適用範囲と、適用しない例外（理由・担当者・見直し期限）を決める。
• 入社・異動・退職・委託終了のときの、IDの追加・変更・停止の手順を決める。
• 管理者権限を持つ人と、ID基盤やMFAが使えないときの緊急時のアクセス手段を確認する。

成果物

利用者・アプリ・権限（許可する操作）の対応表 / MFAの適用範囲と例外一覧 / IDの追加・変更・停止の手順 / 緊急時の復旧手順

完了条件と確認方法

• 対象アプリの利用者と管理者を、対応表で説明できる。
• 対象者へのMFAの設定を、テスト用のIDで確認できた。
• 役割の異なるテスト用ID（一般利用者と管理者など）で、許可した操作が成功し、許可していない操作が拒否されることを確認した。
• テスト用のIDを停止し、対象アプリにアクセスできなくなることを確認した。
• 既存のセッションやアプリ独自のIDが残る場合の対処（アプリ側での停止やサインアウトなど）を確認した。
• 例外のすべてに、担当者・理由・見直し期限がある。

条件を満たさない場合

• 利用者や管理者を説明できない：対象アプリの管理画面と社内の台帳を突き合わせ、対象範囲シートを直す。
• IDを停止してもアクセスが残る：アプリ側での停止やセッションの終了を、IDの停止手順に組み込む。
• 許可していない操作ができる：アプリ側の役割と権限の設定を見直す。アプリで役割を分けられない場合は、利用者の範囲を絞るなど構成を見直し、残るリスクを業務責任者と確認する。
• 例外に理由や期限がない：例外を承認する担当者を決め、期限を付けてから次へ進む。

MFAやログインが成功しても、確かめられるのは本人かどうか（認証）までで、どの操作を許可するか（認可）は別に確かめる必要があります。作業に必要な最小限の権限で許可するというNISTの原則は、対象アプリでは役割ごとの操作のテストで確かめます（テストの方法はこの記事の提案です）。ID基盤でIDを無効にしても、各アプリで確立済みのセッションがすぐに終了するとは限りません。挙動はアプリごとに異なるため、対象アプリで確かめます。この段階では、すべてのSaaSをSSOに対応させることや、全社のIDを1つのID基盤にまとめることまでは求めません。入社・異動・退職の運用フローはSaaSアカウント管理の記事で扱っています。

着手条件

対象アプリでPhase 1の完了条件を満たしている（IDの停止、役割ごとの操作の許可・拒否、例外の管理を確認できている）。

実施すること

• 重要性と試しやすさから、対象アプリと、試行する少人数の利用者を選ぶ。
• 許可する条件（利用者、権限、端末の状態、接続元など）と、条件を満たさないときの扱いを決める。端末の条件は、構成で実際に取得・判定できる状態（端末管理への登録、ディスクの暗号化、OSの更新状況など）から選び、状態を取得できない端末の扱いも決める。
• VPNなど残す経路や、アプリ独自のログイン方法がある場合は、そこからも意図した制御が適用されるかを確認する。
• 構成に合う方法を検討する。ID基盤の条件付きアクセス、ZTNA（ゼロトラストネットワークアクセス）、IAP（ID認識型プロキシ）などがあり、名称・機能・必要な契約は製品によって異なる。
• 少人数で試し、業務への影響と、問題が起きたときの切り戻しの方法を確かめる。

成果物

アクセス条件表 / 許可・拒否・例外のテスト記録 / 接続経路の簡単な構成図 / 例外台帳と切り戻しの手順

完了条件と確認方法

• 許可すべきアクセスが成功する。
• 停止したIDと、設定した端末の条件を満たさないアクセスを拒否できる。
• 拒否の理由をログで確認できる。
• 残したVPNなど別の経路から接続しても、社員には同じ端末条件が適用され、条件を満たさなければ拒否される。
• アプリ独自のID・パスワードによるログインなど別の入口から、社員向けの制御を迂回できない。
• 委託先などの例外は、対象者・権限・接続先・期限が限定され、社員の制御と区別して適用されている。私物端末と緊急時の利用の扱いも決まっている。
• 障害時の復旧（切り戻し）を実際に試した。
• VPNを残すアプリと、その理由、VPN経由の接続に適用される制御を説明できる。

条件を満たさない場合

• 端末の状態をアクセスの判断に使えない：端末の登録と管理の範囲を先に整えるか、対象を社給端末に限って試す。
• 拒否の理由がログで分からない：対象アプリのログの取得と確認の方法を先に決める。
• VPN経由や別のログイン方法で、社員向けの制御を迂回できる：アプリ側で認証の方法や利用者を区別して制御できるかを確認する。区別できない場合は、経路を分ける、委託先に別の接続方法を用意するなど、構成を見直す。例外台帳への記録だけでは、技術的な制限にならない。
• 委託先や私物端末の扱いが決まらない：試行の対象から外し、その利用者の接続方法を、対象者・権限・接続先・期限で限定できるかを確認する。
• 切り戻しを試していない：対象を広げない。

端末の状態を集める仕組み（MDMやEDRなど）は、アクセスを判断するための情報源の一つです。NISTの説明に当てはめると、判断はポリシー決定ポイントが、接続の許可・遮断はポリシー実施ポイントが担います。そのため、MDMやEDRを入れただけでは、アクセスの許可・拒否は行われません。端末の状態が判断に使われ、条件を満たさない端末が実際に拒否されることを、テストで確認します。アクセス条件表や例外台帳を作っても、それだけで制御が働くわけではないため、表のとおりに動くかを別に確かめます。残したVPNの経路も安全とはみなさず、同じテストの対象にします。VPNの全面的な廃止や、ZTNA製品の購入は、この段階の完了条件には含まれません。

着手条件

対象アプリで、許可・拒否・例外をPhase 2のテスト記録で確認できている。

実施すること

• 確認するログを選ぶ（認証、アクセスの許可・拒否、管理者による設定の変更など）。
• 誰が、何を、どの頻度で確認するかを決める。
• 異常や問い合わせの連絡先と、判断の手順を決める。
• 権限・例外・ポリシーを定期的に見直す。
• 遮断などの自動対応は、影響範囲と解除・復旧の方法を確認できたものから行う。

成果物

ログの取得元・確認担当・保存方針の一覧 / 通知と対応の手順 / 例外の見直し記録 / 対応訓練と設定改善の記録

完了条件と確認方法

• テストのイベント（例：停止したIDでのアクセス）を、記録→通知→担当者の対応まで追跡できる。
• 例外の期限切れを確認する運用がある。
• ポリシーの変更を記録し、元に戻せる。
• 自動対応を行う場合は、対象範囲と、解除・復旧の方法を検証した。

条件を満たさない場合

• 通知が届かない、確認する人が決まらない：対象を広げず、確認する担当と頻度を先に決める。
• 期限切れの例外が残る：見直しの担当を決め、期限切れの例外を停止するか、理由を確認して再承認する。
• 変更を戻せない：変更前の設定を記録する手順を先に作る。

この段階では、SIEMやSOARの購入や、24時間の監視までは共通の条件として求めません。ログの保存期間や対応までの時間に一律の数値はなく、業務の重要度、契約、法令などから決めます。侵入された後に被害が広がる要因は情報漏洩の原因の記事で整理しています。

ここからは、進め方を具体的に示すための説明用の例です。社員と委託先が社外からSaaSの業務アプリを使っていて、アプリ側では会社のVPNを経由した接続だけを許可している場合を考えます。

着手前の整理：対象範囲シートを作り始めた時点では、委託先の利用者の範囲、利用が終わったときの連絡経路、アプリ独自の管理者ID、障害時の連絡先がまだ確認できていなかったとします。これらを確認した後の記入例は、次のとおりです。

Phase 1：対応表を作り、役割ごとに許可する操作を記録します。担当範囲で閲覧や更新を制限できるかはアプリによって異なります。この例では、対象アプリでその設定ができ、テストで確かめられるものとします。

委託先のIDにもMFAを適用します。アプリ独自のIDでMFAを使えるかはアプリによって異なるため、管理画面で確認し、使えない場合はID基盤との連携を検討します。委託先とは、利用が終わったときに誰がどの方法で連絡するかを決めておきます。IDを止めても確立済みのセッションが残る場合は、アプリの管理画面でセッションを終了する操作を、停止の手順に加えます。テストは、役割の異なるテスト用IDで次のように行います。

Phase 2：社員を対象に、端末の条件でアクセスを制御します。この例では、社員の認証をID基盤に集め、ID基盤でログインするときに端末の条件を判定します。社員の接続経路をVPN経由のまま残す場合も、インターネットからの直接接続に切り替える場合も、この認証を通らなければログインできないようにします。アプリ独自のID・パスワードでのログインは、社員には使わせません。

委託先の端末は会社から状態を確認できないため、端末条件の試行からは外し、委託先との取り決めがまとまるまでVPN経由の接続を残します。委託先は例外として、対象者、権限、接続先、期限を限定し、社員の制御とは分けて適用します。アプリ側で認証の方法や利用者を区別して制御できない場合は、社員と委託先の経路を分ける、委託先に別の接続方法を用意するなど、構成を見直します。VPNを残したり、例外台帳に記録したりするだけでは、技術的な制限にはなりません。

社員の端末条件は、たとえば次のように具体的に決めます。これはこの記事の設定例で、NISTやCISAが定めた一律の条件ではありません。取得できる情報、判定の方法、状態が更新される間隔は構成によって異なるため、対象の構成で実際に取得・判定できる項目を選びます。

• 会社の端末管理の仕組みに登録されている。
• ディスクの暗号化が有効である。
• OSの更新が、会社で定めた適用基準を満たしている（基準となる版や猶予期間は自社で決める）。
• 判定に必要な状態を取得できない端末は、条件を満たした端末として扱わず、通常の許可の対象にしない。

社給PCであることや、端末管理に登録したことだけでは許可せず、条件に適合していると判定された端末だけを許可します。アクセス条件表とテスト記録は、たとえば次のように作ります。

Phase 3：認証のログと、アクセスを拒否したログを、誰がどの頻度で確認するかを決めます。停止したIDでのアクセスをテストとして起こし、記録、通知、担当者の確認まで追えることを確かめます。例外台帳の期限は、見直しの担当が確認します。

次のいずれかに当てはまるうちは、ほかのアプリや利用者へ広げません。

• IDの停止後に、確立済みのセッションが残る問題を解消していない。
• 一般利用者のIDで、許可していない操作が拒否されることを確認していない。
• 社員がVPN経由や別のログイン方法で、端末条件を迂回できないことを確認していない。
• 委託先の例外が、対象者・権限・接続先・期限で限定されていない。
• 拒否の理由をログで確認できない。
• 切り戻しを試していない。
• 委託先の利用終了を知らせる連絡経路が決まっていない。

成果物と確認の結果があるかを確かめるための項目です。チェックの数で安全性や成熟度を判定するものではありません。未確認の項目は、どの段階の何を整えるかを決める材料にします。