リモートワークとSaaSの定着で「社内ネットワーク内なら安全」という前提が崩れ、ゼロトラスト型のセキュリティモデルへの移行を検討する組織が急速に増えています。

しかし「ゼロトラスト製品をすべて入れ替える」と聞いて尻込みする情シス担当者も多く、何から手をつければよいかが見えないまま検討が止まっているケースも珍しくありません。ゼロトラストは概念であり、段階的に積み上げる進め方こそが現実解です。

本記事ではゼロトラスト導入を6つの実行ステップに分解し、優先順位の付け方、各ステップで使う代表的なツール、SaaS管理プラットフォームとの組み合わせまで、情シスがロードマップに落とし込むための材料を整理します。

ゼロトラスト導入の旗振り役を担う情報システム部門・セキュリティ責任者の方を主な読者として想定しています。

 先に結論を整理します。ゼロトラスト導入の方法は次の3点に集約されます。

• 進め方: ID統制 → デバイス統制 → ネットワーク再設計 → アプリ・データ保護 → ログ統合 → 運用最適化の6ステップ。1ステップずつ価値を出しながら積み上げる
• 設計の検証軸: 米国NISTの標準文書「SP 800-207」が定める7つの基本原則。自社の計画がこの7項目を満たすかで抜け漏れを点検する
• 最初の関門: 原則を満たす前提となる「資産・利用者・業務プロセスの棚卸し」。ここが不完全だとポリシーが決まらず、導入が止まる

この記事では6ステップの具体化に加えて、NIST SP 800-207の7原則、デジタル庁・IPAが公開している日本語の公的ガイドライン、フェーズ別の導入チェックリストまでを通しで扱います。 

ゼロトラストとは

ゼロトラストはネットワークの内部・外部を問わず、すべてのアクセスを信頼せずに検証し続けるセキュリティモデルです。米国Forrester Researchのジョン・キンダーバーグ氏が2010年に提唱し、2020年代にクラウド・SaaS・リモートワークの普及を背景に主流の考え方になりました。

概念としての位置づけは、米国国立標準技術研究所（NIST）が2020年8月に公開した標準文書「SP 800-207 Zero Trust Architecture」で整理されています。同文書はゼロトラストを「単一のアーキテクチャではなく、ワークフロー・システム設計・運用の指針となる原則の集合」と定義し、技術の一括置き換えでは達成できないと明記しています。製品を買えば完成するものではない、という前提はここから来ています。

概念そのものをより詳しく確認したい場合は、ゼロトラストセキュリティとは何かを整理した記事を先に読むと本記事の導入手順が理解しやすくなります。

従来型との違い

従来型の「境界防御モデル」は社内ネットワークを安全圏、外部を危険圏として扱う前提で設計されていました。ゼロトラストはこの境界だけへの依存をやめ、ユーザー・デバイス・アプリケーション・データの各層で都度認証・認可を行う方式に切り替えます。

両者の違いは、設計思想のレベルで整理すると導入計画に落としやすくなります。

表の最下段にある「すでに攻撃者がいる前提」が、ゼロトラストで最も実務に影響する差分です。侵入を防ぎ切る設計から、侵入されても被害を広げない設計へ発想を切り替える必要があります。

ゼロトラストが必要になった背景

クラウドSaaSの利用拡大、リモートワーク常態化、ランサムウェア被害の急増という3つの環境変化により、社内ネットワーク境界を防御線にする発想が機能しなくなりました。境界の代わりに「アイデンティティが新しい境界」と位置づけ、IDとアクセスの統制を中心にセキュリティを再設計するのがゼロトラストの基本姿勢です。

この「アイデンティティが境界になる」という前提は、認証情報そのものが攻撃対象になっている現実を踏まえたものです。ジョーシスが2026年に225社を対象に実施した調査では、99%の企業で自社の認証情報がダークウェブなどに流出している状態が確認されました。認証情報の流出をゼロにする前提は現実的ではなく、流出しても悪用させないためにアクセス側で検証し続けるという設計に、ゼロトラストの必要性が集約されています。

ゼロトラストセキュリティモデルを構成する3つの論理コンポーネント

ゼロトラストセキュリティモデルを製品名ではなく機能で理解しておくと、自社に何が足りないかを判断できるようになります。NIST SP 800-207は、ゼロトラストアーキテクチャの中核となる論理コンポーネントを3つに分けて定義しています。

判断（PE・PA）と執行（PEP）が分離しているのが要点です。加えてPEは、資産の状態を集める仕組み（CDM）、業界コンプライアンス要件、脅威インテリジェンス、ネットワークとシステムの活動ログ、データアクセスポリシーといった入力を受けて判断します。つまり「誰に何を許可するか」を決めるには、資産の状態とログが揃っていることが前提になります。ここが揃っていない状態でZTNAやIdPだけを導入しても、判断材料がないため静的なルールしか書けません。

参考：ゼロトラストとは - リコー  参考：SP 800-207 Zero Trust Architecture - NIST

ゼロトラスト導入の6ステップ

ゼロトラスト導入は「ID統制→デバイス統制→ネットワーク再設計→アプリ・データ保護→ログ統合→運用最適化」の6ステップで進めるのが、本記事で整理する実務上の取り組みやすいロードマップです。1段ずつ価値を出しながら積み上げる前提で計画します。

ステップ1：ID統制（IDaaSとMFAの導入）

最初に取り組むのがID統制です。Microsoft Entra ID、Okta、HENNGE OneなどのIDaaSを導入し、SSOで主要SaaSのログイン窓口を統一したうえで、多要素認証（MFA）を全社展開します。

退職者アカウントの無効化（IdP上での停止）、特権アカウントへの追加認証、レガシー認証プロトコルのブロックは初期フェーズの優先項目です。これらを整備することで、侵入リスクを下げやすくなります。

このステップを最初に置く理由は、NIST SP 800-207が原則6で「すべてのリソースの認証と認可は動的に行われ、アクセス許可の前に厳格に執行される」と定め、その手段として多要素認証の利用を挙げているためです。ID統制はゼロトラストの土台にあたり、ここが緩いままでは後続のデバイス統制やネットワーク再設計を積んでも判断の起点が信頼できません。

着手時の実務メモは次の3点です。

• 対象SaaSの棚卸しを先に済ませる: SSO対応可否・SCIM対応可否・管理者アカウント数を一覧化する。SSOに載せられないSaaSは個別対応リストとして分けて管理する
• MFAの方式を決めておく: 認証アプリ・FIDO2セキュリティキー・パスキーなど方式ごとに耐性が異なる。SMSワンタイムパスワードのみで統一するのは避ける
• 例外運用のルールを最初に決める: 共有アカウント、業務委託先、システム間連携用アカウントは例外が発生しやすい。例外台帳と棚卸し頻度を決めてから展開する

仕組みの詳細はIDaaSとは何かを解説した記事とMFA（多要素認証）の仕組みを整理した記事で確認できます。

ステップ2：デバイス統制（MDMとEDRの整備）

次にデバイス側の統制に進みます。Microsoft IntuneやJamf、Omnissa Workspace ONEなどのMDM（Mobile Device Management）を入れ、社用デバイスの構成・暗号化・パッチ適用を一元管理します。

並行してEDR（Endpoint Detection and Response）製品で、不審な挙動の検知と対応を自動化します。条件付きアクセスと組み合わせれば、未管理デバイスからの機密データアクセスをブロックできます。

デバイス統制がゼロトラストで重視されるのは、NIST SP 800-207の原則5が「組織は自社が所有・関連するすべての資産の完全性とセキュリティ状態を監視し測定する」と定めているためです。同文書は、侵害されている・既知の脆弱性がある・組織が管理していないと判明した資産は、最も安全な状態にある資産とは異なる扱い（すべての接続の拒否を含む）をしてよいとしています。

実務上の順序は「台帳を作る → 構成を配布する → 状態をアクセス判断に接続する」です。台帳が不完全なままEDRを入れても、どの端末が未導入なのかを特定できません。MDMの選定観点はMDMとは何かを整理した記事にまとめています。

ステップ3：ネットワークの再設計（ZTNAとSASE）

VPN中心の構成からZTNA（Zero Trust Network Access）への移行を進めます。Zscaler、Cloudflare Access、Cisco Duoなどのソリューションを使い、アプリケーションごとに最小権限のアクセスを許可する方式に切り替えます。

通信の出入口をクラウドプロキシに統合してSWG・CASB・FWaaSを束ねるSASE（Secure Access Service Edge）アーキテクチャを採用すると、本社・拠点・在宅を一貫して保護できます。

VPNからZTNAへ移行する優先度が高いのは、VPN機器の脆弱性が侵入経路として繰り返し悪用されているためです。ただし一括置き換えは業務停止リスクが大きいため、対象アプリケーションを絞った並行運用から始めます。

移行の判断材料として、既存VPNの「誰が・どのアプリに・どの頻度でアクセスしているか」を先に可視化しておくと、切り替え対象の優先順位が付けられます。SASEの構成要素の関係はSASEとは何かを整理した記事で確認できます。

ステップ4：アプリ・データ保護

SaaSや内製アプリへのアクセスをCASB（Cloud Access Security Broker）やDLP（Data Loss Prevention）で監視・制御します。機密データの分類とラベリング、外部共有の自動検知、未認可SaaSの利用ブロックといった具体策が中心になります。

ファイル単位での暗号化や情報権利管理（IRM）も、要件に応じて段階的に組み合わせます。

このステップで詰まりやすいのは、技術ではなくデータ分類の設計です。全ファイルを対象にすると運用が破綻するため、「持ち出されたら事業影響が出るデータ」を先に特定し、そこから保護範囲を広げます。分類の粒度は3〜4段階に抑え、ラベル付けを自動化できる条件（保存場所・拡張子・キーワード）を先に決めておくと定着します。

ステップ5：ログ統合とSIEM

各製品が出力するログをSIEM（Security Information and Event Management）に集約し、相関分析と異常検知を回します。Microsoft Sentinel、Splunk、Datadog Cloud SIEMなどが代表的です。

UEBA（User Entity Behavior Analytics）機能で、通常パターンから外れた挙動を自動的にアラート化できると、SOC運用の負荷が大きく下がります。

ログ統合はゼロトラストの原則7「組織は資産・ネットワークインフラ・通信の現在の状態について可能な限り多くの情報を収集し、セキュリティ態勢の改善に利用する」に直接対応します。つまりログは監査用の記録ではなく、アクセス判断の精度を上げるための入力です。

集約対象として最初に押さえるのは、IdPの認証ログ、デバイス管理の状態ログ、主要SaaSの監査ログの3系統です。特にSaaS側の監査ログは取得方法と保持期間がサービスごとに異なるため、設計段階で確認が必要になります。取得の実務はSaaSの監査ログの取り方を整理した記事にまとめています。

ステップ6：運用最適化と継続改善

ゼロトラストは入れて終わりではなく、ポリシーの定期見直し、アクセスレビュー、ペネトレーションテストを通じて継続的に磨き続ける運用です。四半期ごとに棚卸しを実施し、形骸化を防ぐ仕組みを最初から組み込んでおくのが推奨されます。

NIST SP 800-207も、初期展開の段階では一定期間「レポートのみのモード」で運用し、実際のアクセス要求とポリシーの想定を突き合わせてから執行を強めることを推奨しています。最初のポリシーセットが完全であることはまずないという前提に立ち、観測しながら締めていく手順を計画に織り込んでおきます。

6ステップの優先順位の付け方

6ステップをすべて同じ熱量で進めることは現実的ではありません。優先順位は「攻撃面の縮小効果 ÷ 実装負荷」で判断すると迷いが減ります。

順序を判断するときの原則は「アクセス判断に必要な情報を先に揃える」ことです。ID・デバイス・ログの3つが揃うと、ポリシーを動的にできる範囲が一気に広がります。

社内ネットワークにゼロトラストを適用する手順

既存の社内ネットワークが残っている状態からゼロトラストへ移行する場合、ネットワーク側だけを作り替えても効果は出ません。NIST SP 800-207は、境界防御型のネットワークにゼロトラストを導入する手順を7段階で示しています。

1. 組織内の利用者（アクター）を特定する。人だけでなくサービスアカウントなどの非人格エンティティも含める
2. 組織が所有する資産を特定する。端末・アカウント・アプリケーション・証明書に加え、把握できていないシャドーITも可能な範囲で台帳化する
3. 主要な業務プロセスを特定し、それを実行するリスクを評価する
4. 最初の適用候補について、ポリシーを策定する
5. 候補となるソリューションを選定する
6. 初期展開を行い、監視する（当初はレポートのみのモードから始める）
7. 適用範囲を拡大する

社内ネットワークに適用する場合の実務ポイントは、いきなり全体を対象にせず「クラウド中心の業務」または「リモートワーカーが多い業務」から始めることです。NIST SP 800-207も、主にクラウド上にあるリソースやリモート利用者が中心の業務プロセスは、利用者とリソースが既に境界の外側にあるためゼロトラスト適用の効果が出やすい候補だとしています。

もう1点重要なのが、社内ネットワークを「暗黙の信頼ゾーンとして扱わない」という前提です。同文書は、資産は常に攻撃者がネットワーク上にいるかのように振る舞うべきであり、すべての接続を認証し通信を暗号化することを求めています。社内セグメントに置いたファイルサーバーや業務システムも、認証・認可の対象から外さない設計にします。

参考：ゼロトラストの導入方法：5つのステップ - Cato Networks  参考：SP 1800-35 Implementing a Zero Trust Architecture - NIST 

NIST SP 800-207が示すゼロトラストの7原則

自社の導入計画に抜けがないかを点検するとき、最も使いやすい基準はNIST SP 800-207が定める7つの基本原則です。同文書は、ゼロトラストアーキテクチャはこの7原則に沿って設計・展開されると定義しています。あわせて「これらの原則は理想的な目標であり、特定の戦略においてすべての原則が純粋な形で完全に実装されるとは限らない」とも明記しています。満点を取るための基準ではなく、設計の抜け漏れを見つけるための点検軸として使うのが実務的です。

7原則の一覧と実務での読み替え

原文の主旨を保ったまま、情シスの実務に読み替えた対応表です。

7項目のうち、日本企業で最も落ちやすいのは原則1と原則5です。保護対象の一覧と資産の状態把握はゼロトラスト製品を買っても自動的には埋まらず、台帳整備という地道な作業が必要になります。

原則1〜3：リソースの定義とセッション単位の認可

原則1は、ネットワーク上のあらゆるデータソースとコンピューティングサービスをリソースとして扱うことを求めます。NIST SP 800-207は、組織が私物端末を「組織のリソースにアクセスできるならリソースとして分類する」判断をしてよいとも述べています。BYODを黙認したまま管理対象から外すのではなく、リソースとして定義してから統制方法を決める順序になります。

原則2は、通信の保護をネットワークの場所と切り離す原則です。同文書は「ネットワークの場所だけでは信頼を意味しない」とし、社内ネットワーク上の資産からのアクセス要求にも、社外からのアクセス要求と同じセキュリティ要件を満たすことを求めています。VPNで社内に入ればフリーパスという構成は、この原則に反します。

原則3は、アクセス許可をセッション単位にする原則です。要求元への信頼は許可前に評価され、権限は「そのタスクを完了するために必要な最小限」で与えられます。そして1つのリソースへの認証・認可が、別のリソースへのアクセスを自動的に許可することはありません。権限設計の考え方は最小権限の原則を解説した記事で詳しく扱っています。

原則4〜5：動的ポリシーと資産の状態監視

原則4は、アクセスを動的なポリシーで決めることを求めます。入力になるのは、クライアントのアイデンティティやアプリケーション・サービスの観測可能な状態、要求元の資産の状態であり、さらに振る舞いや環境の属性を含めてよいとされています。資産の状態には、インストール済みソフトウェアのバージョン、ネットワーク上の位置、要求の日時、過去に観測された振る舞い、格納された資格情報などが含まれます。

ここで重要なのは、動的ポリシーは「作れる」ものではなく「材料が揃って初めて作れる」ものだという点です。端末のパッチ状況を取得できていなければ、パッチ状況を条件にしたポリシーは書けません。

原則5は、組織が所有・関連するすべての資産の完全性とセキュリティ状態を監視・測定する原則です。同文書は、いかなる資産も本質的に信頼されることはないとし、資産の状態を継続的に把握して必要なパッチや修正を適用する仕組み（CDMまたは同等の仕組み）を確立すべきだとしています。原則4と原則5はセットで、資産管理の精度がそのままポリシーの精度になります。

原則6〜7：厳格な認証認可と情報収集による改善

原則6は、すべてのリソースの認証と認可を動的に行い、アクセスを許可する前に厳格に執行する原則です。NIST SP 800-207はこれを「アクセスを取得し、脅威をスキャンして評価し、適応し、進行中の通信における信頼を継続的に再評価する、絶え間ないサイクル」と表現しています。あわせて、ゼロトラストアーキテクチャを実装する組織にはICAM（アイデンティティ・クレデンシャル・アクセス管理）と資産管理の仕組みが備わっていることが期待され、一部または全部のリソースへのアクセスに多要素認証を用いることが含まれるとしています。

重要なのは、再認証・再認可のトリガーをポリシーで定義することです。同文書は、時間経過、新しいリソースの要求、リソースの変更、異常な振る舞いの検知などをトリガーの例として挙げ、セキュリティ・可用性・使いやすさ・コスト効率のバランスを取るべきだとしています。認証を厳しくするだけでは運用が回らないという前提が、標準文書の側にも書かれている点は押さえておく価値があります。

原則7は、資産・ネットワークインフラ・通信の現在の状態について可能な限り多くの情報を収集し、セキュリティ態勢の改善に使う原則です。収集したデータはアクセス要求の文脈情報としても使われます。ログを貯めるだけで改善に回していない状態は、この原則を満たしていません。

原則を満たすうえで最初に崩れるのは「資産の把握」

7原則を並べたときに、多くの組織で最初に崩れるのが資産の把握です。NIST SP 800-207自身が、ゼロトラストアーキテクチャへの移行には資産・利用者・業務プロセスに関する詳細な知識が必要であり、知識が不完全な場合はポリシーエンジンが情報不足でアクセスを拒否し、業務プロセスの失敗につながると警告しています。そして「組織内に把握されていないシャドーITの展開がある場合は特に問題になる」と明示し、組織所有のシャドーITも可能な限り台帳化すべきだとしています。

つまり、シャドーITの棚卸しはゼロトラスト導入の前提条件です。この観点は製品カタログには載らない部分で、導入プロジェクトが止まる原因の上位に入ります。検出の具体的な方法はシャドーITの検出方法を解説した記事にまとめています。

参考：SP 800-207 Zero Trust Architecture（本文PDF） - NIST 

公的ガイドラインで読むゼロトラスト導入マニュアル

「ゼロトラストの導入マニュアルが欲しい」という要望に対して、日本語で参照できる公的資料は複数公開されています。ベンダー資料だけで計画を組むと製品構成に引っ張られるため、公的ガイドラインを土台に置き、製品選定はその上に載せる順序が安全です。ここでは実務で使える4本を整理します。

NIST SP 800-207（標準の原典）

2020年8月公開。ゼロトラストとゼロトラストアーキテクチャの定義、7つの基本原則、論理コンポーネント、想定ユースケース、脅威、そして境界防御型ネットワークからの移行手順までを扱う原典です。英語文書ですが、7原則と移行7ステップの部分だけでも読む価値があります。

用途は「自社の設計が原則に照らして抜けていないかを確認する」ことです。製品選定の指針としては具体性が足りないため、そこは後述のNIST SP 1800-35や国内ガイドラインで補います。

NIST SP 1800-35（実装事例集）

2025年6月に最終版が公開された実践ガイドです。NISTのNCCoE（National Cybersecurity Center of Excellence）が24社の商用パートナーと共同で構築した19の実装例をもとに、技術モデルとベストプラクティス、ゼロトラスト原則と既存セキュリティ標準とのマッピングを示しています。

SP 800-207が「何を満たすべきか」を示す文書であるのに対し、SP 1800-35は「どう組むか」に踏み込んだ文書です。オンプレミスとクラウドが混在した環境での構成例を探している段階で参照すると効率が良くなります。

デジタル庁「ゼロトラストアーキテクチャ適用方針」

2022年6月30日公開。政府情報システムの標準ガイドライン群（DS-210）に位置づけられた文書で、クラウドサービスの利用拡大とリモートワークの普及を踏まえ、ゼロトラストの考え方をどう適用するかと、その実装の考え方が日本語で整理されています。

行政機関向けの文書ですが、民間企業でも「経営層や監査部門への説明資料の根拠」として使いやすいのが実務上の利点です。ベンダー資料ではなく公的文書を根拠に方針を説明できると、社内合意の形成が進みやすくなります。

IPAの指南書・移行ガイドと本記事6ステップの対応

IPA（独立行政法人情報処理推進機構）の産業サイバーセキュリティセンター中核人材育成プログラムからは、ゼロトラストに関する成果物が2本公開されています。

• ゼロトラスト導入指南書（2021年6月24日公開・4期生成果物）: ゼロトラストの基本的な考え方、構成要素、モデルケース、導入方法を扱う。ページ上で有効期限を過ぎた旨が示されているため、現在は参考資料として読む前提になる
• ゼロトラスト移行のすゝめ（2022年公開・5期生成果物）: 組織がゼロトラストへ移行する際の課題を扱った、より新しい成果物

日本語で通読できる資料としては入りやすく、社内勉強会の教材にも使えます。公的資料と本記事の6ステップの対応は次のとおりです。

この対応表を使えば、公的ガイドラインの記述と自社のロードマップを同じ枠で説明できるようになります。稟議や監査対応の場面で、方針の裏付けを示す材料として機能します。

参考：ゼロトラストアーキテクチャ適用方針（DS-210） - デジタル庁

参考：ゼロトラストという戦術の使い方（ゼロトラスト導入指南書） - IPA

参考：ゼロトラスト移行のすゝめ - IPA 

ゼロトラスト導入チェックリスト（フェーズ別）

ここまでの内容を、着手前から運用までのフェーズ別チェックリストにまとめます。すべてに一度で丸を付ける必要はありません。フェーズ0が埋まっていない状態で製品選定に進むと、ポリシーが決まらず手戻りするという点だけ押さえてください。

フェーズ0：着手前の棚卸し

NIST SP 800-207が移行の前提として挙げている「資産・利用者・データフロー・業務プロセスの調査」に相当します。

• 利用しているSaaSを種類単位で一覧化し、契約部署・利用者数・管理者を把握しているか
• 情シスが把握していない部門契約のSaaS（シャドーIT）を検出する手段があるか
• 業務端末の台数と、MDM未導入端末の数を把握しているか
• サービスアカウント・システム連携用アカウントを含めて、特権アカウントを一覧化しているか
• 業務委託先・退職予定者を含む外部アクセスの経路を把握しているか
• 「持ち出されたら事業影響が出るデータ」がどこに保管されているかを特定しているか
• 最初にゼロトラストを適用する候補業務を1つ決めているか

最後の項目が抜けやすいポイントです。全社一括ではなく候補業務を1つ選ぶことが、NIST SP 800-207が示す移行手順の前提になっています。

フェーズ1：ID・デバイス統制

攻撃面の縮小効果が最も大きいフェーズです。

• 主要SaaSをIdPのSSO配下に載せているか（載せられないSaaSを別管理にしているか）
• 全社員にMFAを適用しているか。特権アカウントには追加の認証要件を設定しているか
• レガシー認証プロトコルをブロックしているか
• 退職・異動時にIdPでアカウントを停止するフローが定義され、実行記録が残っているか
• MDMで構成・暗号化・パッチ適用を配布し、未管理端末を検出できているか
• EDRの導入率を把握し、未導入端末を潰し込めているか
• 端末の状態（パッチ・暗号化・EDR稼働）をアクセス条件に接続しているか

最後の項目まで到達すると、原則4と原則5の「動的ポリシー」が実際に機能する状態になります。

フェーズ2：ネットワーク・アプリ／データ保護

業務影響の調整に時間がかかるフェーズです。並行運用の期間を計画に入れます。

• ZTNAの適用対象アプリケーションを決め、アクセス実績にもとづく優先順位を付けているか
• VPNの縮退計画（並行運用期間と停止条件）を文書化しているか
• 社内セグメント上のシステムも認証・認可の対象に含めているか
• データ分類の段階（3〜4段階）とラベル付与の自動条件を定義しているか
• SaaSの外部共有設定を検知・是正する仕組みがあるか
• 未認可SaaSの利用を検知したときの対応手順（許可・代替提示・ブロック）が決まっている

3つ目の「社内セグメント上のシステム」は取り残されやすい領域です。原則2に照らすと、ここを例外にした時点でゼロトラストは成立しません。

フェーズ3：ログ統合と運用

改善サイクルを回すためのフェーズです。

• IdP・デバイス管理・主要SaaSの3系統のログを集約しているか
• SaaSごとのログ保持期間を把握し、必要な期間を確保しているか
• 初期展開をレポートのみのモードで運用し、実際のアクセス要求とポリシーの差分を確認したか
• アクセス権の棚卸しを定期実行し、実施記録を残しているか
• ポリシー変更の申請・承認・記録のフローが定義されているか
• 検知したインシデントをポリシー改善に反映する場（定例会など）があるか

アクセス権の棚卸しは、監査対応と運用改善の両方を兼ねる作業です。実施手順はアクセス権限の棚卸し方法を解説した記事にまとめています。

進捗をどう測るか（KPIの置き方）

ゼロトラストは完成状態が定義しにくいため、進捗を測る指標を最初に決めておかないと「やっている感」だけが残ります。導入プロジェクトで置きやすい指標は次のようなものです。

これらの分母はいずれも「把握している総数」です。分母が曖昧なままでは指標が動いても意味を持たないため、フェーズ0の棚卸しがKPI設計の前提になります。

ゼロトラスト導入で陥りやすい落とし穴

導入プロジェクトが頓挫する典型パターンを把握しておくと、計画段階でリスクを回避できます。情シスが特に注意すべきポイントを3つ紹介します。

製品の同時多発導入

「ゼロトラスト＝大量の新製品導入」と捉えてしまうと、半年でツール疲れを起こします。ID統制から1ステップずつ価値を出しながら進める方が、現場の理解と運用定着の両方で成果につながりやすくなります。

既存運用の引き継ぎ漏れ

既存のVPN、ファイアウォール、認証基盤を一気に廃止しようとすると、引き継ぎ漏れで業務停止リスクが顕在化します。並行運用期間を3〜6か月確保し、段階的に旧基盤を縮退させる進め方が安全です。

経営層・部門の巻き込み不足

ゼロトラストはユーザー体験を変える施策が多く（MFA要求の増加、未管理デバイスのブロックなど）、現場部門の協力がないと運用が空洞化します。経営層と部門責任者を巻き込み、変更管理を計画段階から組み込むのが鉄則です。

シャドーITを棚卸ししないまま進める

製品導入の前に潰しておくべきなのが、把握できていないSaaSと端末です。現場で起きるのは次のような事象です。部門が独自契約したSaaSがSSO配下に入っていないため、MFA適用の対象から漏れる。退職者のアカウントがIdPには存在しないため停止対象に上がらない。ZTNAへ移行した際、ポリシーに登録されていないシステムが突然使えなくなる。いずれも技術の失敗ではなく、台帳の欠落が原因です。

対策は、ゼロトラストの計画着手と同時にSaaSと端末の棚卸しを走らせることです。ゼロトラスト製品の選定を止める必要はありませんが、棚卸しを「後回しにできるタスク」として扱わないことが重要です。

MFA導入後に増える攻撃を想定していない

MFAを入れれば認証は安全になる、という前提で計画を止めると運用でつまずきます。攻撃側はMFAを前提とした手法に移っており、代表的なものが認証承認のプッシュ通知を大量に送って利用者に承認させる手口（MFA疲労攻撃・プッシュ通知爆撃）や、認証を中継して正規セッションを奪う中間者型のフィッシングです。

対策の方向は、方式の選定と検知の両方にあります。方式面ではフィッシング耐性の高い認証（FIDO2セキュリティキーやパスキー）へ寄せる、番号照合を有効にするといった選択肢があります。検知面では、短時間に連続する認証要求や普段と異なる場所からのセッション確立をログから拾う設計が有効です。

これはNIST SP 800-207の原則6が求める「継続的な再認証・再認可」と原則7の「情報収集による態勢改善」を、MFA導入後の運用として具体化する作業にあたります。導入時点の設計で終わらせず、攻撃手法の変化に合わせて方式と検知を見直す前提を置いてください。

参考：ゼロトラスト移行のすゝめ - IPA 

ゼロトラストの推進体制と運用の回し方

ゼロトラストは製品構成の話に見えて、実際には推進体制と運用設計で成否が分かれます。導入後に何を誰が回すのかを決めていないと、ポリシーが更新されないまま形骸化します。

推進体制の作り方（誰が旗を振るか）

ゼロトラストの推進は情シス単独では完結しません。ユーザー体験の変更、業務プロセスの変更、予算の確保がいずれも部門横断の論点になるためです。最低限そろえたい役割は次の4つです。

• 意思決定者: CIO・CISO・情報システム部門長など。適用範囲と許容するリスクの水準を決める
• 推進実務者: 情シスのプロジェクト担当。ロードマップ、ポリシー案、製品検証を回す
• 業務部門の代表: 適用対象業務の部門担当者。業務影響の判断と現場周知を担う
• 監査・法務の接点: 内部監査部門や法務。ログ取得やモニタリングに伴う手続き面を確認する

推進の起点となる文書としては、情報セキュリティポリシーの改定とセットで進めるのが実務的です。ポリシー文書の作り方は情報セキュリティポリシーの作り方を解説した記事にまとめています。

運用フェーズで回す4つの定例業務

導入後の運営は、次の4つを定例化すると回り始めます。

このうち資産台帳の更新は最も地味で、最も手を抜かれやすい業務です。ここが止まると原則5の状態監視が崩れ、動的ポリシーの前提が失われます。手作業での更新を前提にせず、自動収集できる範囲を広げる設計にしてください。

ポリシーの見直しサイクルと形骸化の防ぎ方

ポリシーが形骸化する典型パターンは、例外申請が積み上がって実質的に無制限になることです。防ぐには、例外に必ず期限と再審査の条件を付けます。

• 例外には有効期限を設定し、期限到来時に自動で失効させる
• 例外台帳に「理由・申請者・承認者・期限・代替策」を記録する
• 四半期のポリシー見直しで、例外件数の推移を指標として確認する
• 同じ理由の例外が3件以上続いたら、ポリシー側の修正を検討する

最後の運用が効きます。例外が繰り返されるのは、多くの場合ポリシーが業務実態に合っていないサインです。個別に承認を積み上げるのではなく、ポリシーを直す判断に切り替える基準を持っておくと、運用が持続します。

参考：ゼロトラストアーキテクチャ適用方針（DS-210） - デジタル庁

ゼロトラスト導入のメリット

ゼロトラスト型に移行することで、セキュリティ・運用効率・コンプライアンスの3軸で成果が現れます。導入提案時の論点整理にも活用できます。

セキュリティの構造的強化

ランサムウェア・標的型攻撃・退職者による情報持ち出しといった代表的な脅威に対して、ID・デバイス・ネットワーク・データの各層で多重防御が機能します。1つの突破では全体が落ちない構造になります。

この効果は、NIST SP 800-207がゼロトラストアーキテクチャを「データ侵害を防ぎ、内部での横方向の移動を制限するために設計されたエンタープライズのサイバーセキュリティアーキテクチャ」と定義していることに対応します。侵入をゼロにするのではなく、侵入後の横展開を止めるのが構造上の狙いです。

運用効率の改善

VPNの帯域逼迫やパスワードリセット問い合わせの削減で、情シスの運用工数が減ります。SSOでログイン窓口を統一すると、利用者が入力するパスワードの数そのものが減るため、パスワード忘れに起因する問い合わせも減少します。ただしMFAの追加によって認証の手間が増える面もあるため、フィッシング耐性の高い方式を選びつつ、再認証の頻度をポリシーで調整して負荷を抑える設計が必要です。

コンプライアンス対応の効率化

J-SOX、ISMS、SOC 2、PCI DSSといった監査要件に対し、ゼロトラスト基盤のログを使えば証跡取得とアクセスレビューが標準化されます。監査時の資料作成工数も大きく削減できます。

ジョーシスのプラットフォームを使えば、ゼロトラスト基盤の中核となるSaaS管理を一元化できます。資料ダウンロードは5分でわかるJosysからどうぞ。

ゼロトラスト導入だけでは解決できないSaaS管理の課題

ゼロトラストはアクセス制御を統一しますが、SaaSの利用状況、ライセンスコスト、契約・更新管理、シャドーITの可視化といったSaaS固有のライフサイクルまでは守備範囲外です。利用しているSaaSが30種類を超える組織では、ゼロトラスト基盤とSaaS管理プラットフォーム（SMP）の組み合わせ運用が現実解になります。

SaaSライセンスコストの可視化

ゼロトラスト基盤はアクセス可否は判断できますが、ライセンスの利用率や有償ライセンスの過剰契約までは追えません。年間SaaS支出の最適化には別の仕組みが必要です。

シャドーITの検知

部門が情シスに無断で契約したSaaSは、ゼロトラスト基盤の管理対象に入ってきません。クレジットカード明細やSaaS購買データを横断的に取得する仕組みが必要になります。

前述のとおりNIST SP 800-207もシャドーITの台帳化を求めており、ゼロトラストの設計要件そのものがSaaSの可視化を前提にしているという整理になります。

契約・更新の管理

SaaSごとの契約期間、解約タイミング、更新前のコスト比較といった商務情報はゼロトラスト基盤の対象外です。契約書管理と利用実態の突き合わせをセットで運用する必要があります。

SaaS管理プラットフォームが補う領域

ジョーシスのプラットフォームは350以上のアプリ連携（31カテゴリ）を備え、認証管理・アカウント発行削除・ライセンス最適化など、ゼロトラスト基盤がカバーしないSaaSライフサイクルを横断管理できる設計です。国内外1,000社以上の導入実績があり、IT工数を最大50%、ITコストを最大75%削減した事例も報告されています。

ゼロトラスト導入の文脈で効くのは、フェーズ0の棚卸しとフェーズ3の運用です。具体的には、SaaSの利用実態とアカウント一覧を継続的に収集して原則1の「保護対象の一覧」を維持する、入退社に連動したアカウント発行・削除で原則3のセッション単位の権限管理を実務に落とす、アクセス権の棚卸し記録を残して原則7の改善サイクルに接続する、といった使い方です。導入事例では、Anker JapanでITコスト75%削減、Sales MarkerでIT工数約50%削減という実績が公開されています。

無料デモはJosys デモ予約から日程を選べます。

ゼロトラスト導入についてよくある質問

検討フェーズで担当者から多く寄せられる質問を整理しました。

‍

• ゼロトラスト導入には何年かかりますか
• 組織規模と既存基盤の状況によりますが、ID統制と多要素認証の整備で半年、デバイス・ネットワーク統制まで含めて1〜2年が一般的な目安です。完全移行ではなく、優先順位を付けた継続改善として捉えるのが現実的です。
• ゼロトラスト製品を全部買う必要がありますか
• 必要ありません。NIST SP 800-207も、ゼロトラストへの移行は技術の一括置き換えでは達成できず、多くの組織はすでにゼロトラストアーキテクチャの要素を自社インフラに持っていると述べています。既存基盤を活かし、不足部分だけを補う進め方が推奨されます。たとえばMicrosoft 365を利用している組織であれば、Entra IDでID統制、Intuneでデバイス統制、Microsoft Defender製品群で検知を担わせることで、6ステップの前半をおおむね既存ライセンスの範囲でカバーできる構成になります。
• 中小企業でもゼロトラストは必要ですか
• リモートワークやSaaSを活用する組織であれば規模に関係なく必要です。ただし全製品を導入する必要はなく、IDaaSとMFA、MDMといった最初の2ステップだけでも防御力は大きく上がります。
• VPNはすぐに廃止すべきですか
• すぐの廃止は推奨されません。ZTNAへの段階移行と並行運用を経て、利用状況を確認しながら3〜6か月かけて縮退するのが安全です。
• ゼロトラストの導入マニュアルはどこで入手できますか
• 公的資料としては、NIST SP 800-207（原則と移行手順）、NIST SP 1800-35（実装事例集）、デジタル庁「ゼロトラストアーキテクチャ適用方針」（2022年6月30日）、IPAの「ゼロトラスト導入指南書」および「ゼロトラスト移行のすゝめ」があります。日本語で通読したい場合はデジタル庁とIPAの資料から入るのが現実的です。ベンダー資料は製品構成に沿った内容になるため、方針は公的資料で固めてから参照してください。
• ゼロトラストの7原則は全部満たさないといけませんか
• NIST SP 800-207は、7原則は理想的な目標であり、特定の戦略においてすべての原則が純粋な形で完全に実装されるとは限らないと明記しています。満点を目指す基準ではなく、自社の設計に抜けがないかを点検する軸として使ってください。特に原則1（保護対象の一覧）と原則5（資産の状態監視）は台帳整備が前提になるため、優先して着手する価値があります。
• どの業務からゼロトラストを適用すればよいですか
• NIST SP 800-207は、主にクラウド上にあるリソースやリモート利用者が中心の業務プロセスを、ゼロトラスト適用の良い候補として挙げています。利用者とリソースが既に社内ネットワークの外側にあるため、効果が出やすいという理由です。全社一括ではなく、対象業務を1つ選んで初期展開し、そこから範囲を広げる順序を取ってください。
• ゼロトラスト推進の体制は何人必要ですか
• 人数よりも役割の充足が重要です。意思決定者、情シスの推進実務者、適用対象業務の部門代表、監査・法務の接点という4つの役割が埋まっていれば、少人数でも進行できます。逆に情シスだけで進めると、業務影響の判断と現場周知が滞り、運用フェーズで形骸化しやすくなります。

まとめ

ゼロトラスト導入はID統制・デバイス統制・ネットワーク再設計・アプリ/データ保護・ログ統合・運用最適化の6ステップで段階的に進めるのが現実解です。最初に取り組むべきはIDaaSとMFAによるID統制で、ここを固めるだけでも攻撃面を大幅に絞り込めます。

計画の抜け漏れを点検するときは、NIST SP 800-207の7原則を軸に使ってください。そのうえで着手前の棚卸し（フェーズ0）を飛ばさないことが、導入が止まらないための最大の条件になります。資産・利用者・業務プロセスの把握が不完全だと、ポリシーの判断材料が揃わず、製品を入れても静的なルールしか書けません。

ただしゼロトラスト基盤だけではSaaSのライセンス管理やシャドーIT可視化までは届かないため、SaaS管理プラットフォームとの組み合わせ運用が現実解になります。自社のSaaS環境を統合的に整備したい場合は、5分でわかるJosysから検討を始めるのが近道です。