かつて、企業のセキュリティは「ファイアウォールの内側である社内ネットワークは安全な場所である」という、いわゆる「境界型防御」の前提の上に成り立っていました。しかし今、その前提だけでは組織を守りきれなくなっています。
巧妙化を極める標的型攻撃は、VPN装置の脆弱性や従業員の些細なミスを突いていとも簡単に社内へ侵入し、ランサムウェアによって組織の重要データを人質に取ります。一方で、ビジネスの現場ではテレワークが常態化し、業務システムはクラウドサービスへと移行したことで、単一の「境界線」だけでは守るべき対象を囲えなくなりました。
もはや「社内は安全」という神話は通用しません。これからの時代に求められるのは、ネットワークの場所や端末の所有者だけを根拠に暗黙の信頼を与えず、アクセスに必要な信頼を継続的に評価するセキュリティモデル、「ゼロトラスト(Zero Trust)」です。
近年、バズワードとしても頻繁に耳にするようになった「ゼロトラスト」ですが、その本質を正しく理解できているでしょうか?単に新しいツールを導入すれば実現できるものではありません。組織のセキュリティに対する考え方を根本から変える、アーキテクチャの変革が必要となります。
本記事では、実務・試験の両面で押さえておきたいテーマであるゼロトラストアーキテクチャ(ZTA)について、徹底的に解説します。その本質的な考え方から、実装の拠り所として世界的に参照されている米国NISTのガイドライン「NIST SP800-207」が定める7つの原則、そして具体的な構成要素や導入ステップまで。試験で問われるポイントを押さえつつ、実務にも役立つ体系的な知識を身につけましょう。
境界防御モデルの崩壊とゼロトラストの必然性
なぜ今、これまでのセキュリティ対策では不十分なのでしょうか。まずは、従来のモデルが抱える構造的な限界を理解する必要があります。
「城と堀」のモデル(境界防御)の限界
従来のセキュリティは、堅牢な「城壁(ファイアウォール)」と深い「堀(VPN)」で社内ネットワークを守る、いわば境界防御モデルでした。「門(認証)」さえ通過すれば、城内は安全な信頼できる領域と見なされていました。
しかし、現代のビジネス環境において、このモデルは多くの脆弱性を露呈しています。
内部侵入後の「ラテラルムーブメント(横展開)」の脅威
一度攻撃者に境界を突破されると、彼らは「信頼された内部ユーザー」になりすまし、ネットワーク内を自由に探索・移動して機密情報にアクセスしてしまいます。VPN装置の脆弱性などを突いて侵入した攻撃者が、内部で長期間検知されずに活動を続け、最終的に大量の情報が流出したという事例は、国内外で繰り返し報告されています。境界防御だけでは、こうした侵入後の活動や内部犯行への対処が不十分です。
クラウドシフトによる「境界」の消失
守るべき重要データが社内のサーバーから、Microsoft 365やSalesforceといった社外のクラウドサービス(SaaS)へ移行しました。従業員は本社のネットワークを経由せず、カフェや自宅から直接クラウドへアクセスします。単一の境界だけでは、保護対象を囲えなくなりました。
多様な働き方によるVPNの限界
自宅、カフェ、サテライトオフィス、海外拠点など、あらゆる場所からアクセスが行われるようになり、VPN装置の帯域不足が深刻化しています。さらに、VPNは接続後の到達範囲が広く設定されがちで、認証情報が漏洩した際の被害を拡大させるセキュリティホールの温床となっています。
ゼロトラストの核心:「決して信頼せず、常に検証する」
ゼロトラストとは、「暗黙の信頼を与えない」ことを出発点とするセキュリティの考え方です。後述するNISTのガイドラインでは、ネットワークの場所(社内か社外か)や資産の所有者(会社支給か個人所有か)だけを根拠に、利用者や端末を暗黙に信頼しないことと説明されています。境界防御やファイアウォールが不要になるわけではなく、ゼロトラストと併用して多層的に守ります。
ネットワークの内側か外側かに関わらず、リソースへのアクセスはセッションごとに認可し、その際に「本当に本人か?」「端末は安全か?」「そのアクセスは正当か?」を評価します。既存の認証結果や端末の状態も評価の材料になり、利用者への再認証・再認可はポリシーやリスクの変化に応じて求めます。
これが、「Never Trust, Always Verify(決して信頼せず、常に検証する)」というゼロトラストの基本原則です。
たとえば、営業部の田中さんが朝9時にオフィスから顧客データベースへアクセスする場合と、同じ田中さんが深夜2時に海外のホテルWi-Fiから同じデータベースへアクセスする場合では、認証の厳格さを動的に変化させます。後者の場合は追加認証を要求するか、アクセスそのものをブロックする判断を自動的に行うのです。

+おまけ:毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
NIST SP800-207が定める「7つの基本原則」を徹底解説
ゼロトラストを具体的にどのように実現するのか。その拠り所として世界的に広く参照されているのが、米国国立標準技術研究所(NIST)が2020年8月に発行したガイドライン「NIST SP 800-207, Zero Trust Architecture」です(国際規格ではなく、米国政府機関向けのガイドラインです)。
情報処理安全確保支援士試験の学習でも押さえておきたい、このドキュメントで定義されている「7つの原則(tenets)」を一つずつ深掘りしていきましょう。
原則①:すべてのデータ源とコンピューティングサービスをリソースと見なす
企業が扱うデータ源やコンピューティングサービスを、それぞれ保護すべき「リソース」と見なします。ネットワークの中にあるかどうかではなく、個々のリソースを単位にアクセス制御を考えるのがポイントです。
リソースの具体例:
- SaaS上の個別ファイル(SharePoint上の企画書、Salesforceの顧客レコード)
- オンプレミスのデータベース(人事DB、財務DB、開発用DB)
- APIエンドポイント(外部連携用REST API)
- IoTデバイス(監視カメラ、入退室管理システム、産業用センサー)
- 仮想マシン・コンテナ
それぞれのリソースに対して、個別のアクセス制御ポリシーを設定します。たとえば、人事部員は人事システムへアクセスできても、開発部のソースコードリポジトリへはアクセスできないよう、きめ細かく制御するのです。
原則②:ネットワークの場所に関わらず、通信をすべて保護する
「社内LANだから盗聴の心配はない」という前提を捨てます。社内・社外を問わず、すべての通信は、TLS 1.3などの安全なプロトコルを用いて暗号化され、保護されなければなりません。
実装の具体例:
- WebアプリケーションでHTTPSを提供し、HSTSを設定(初回接続の保護にはHSTSプリロードなども検討)
- サーバー間通信にmTLS(相互TLS認証)を適用
- 社内Wi-Fiにも適切な暗号化・認証を適用(新規導入ではWPA3-Enterpriseなどを検討)
- VPN接続時も追加でデバイス証明書による端末認証を必須化
たとえ同じオフィス内の数メートルの距離で通信する場合でも、暗号化は必須です。これにより、中間者攻撃(Man-in-the-Middle)や盗聴のリスクを最小化します。
原則③:リソースへのアクセスをセッションごとに決定する
「朝一度ログインしたから、夕方まで何でもアクセスできる」という状態は許容しません。個々のリソースへのアクセスはセッション単位で許可し、許可する前に要求者の信頼を評価します。あるリソースで認証・認可されても、別のリソースへのアクセスが自動的に許可されることはありません。
セッションベースアクセス制御の実例:
シナリオ1:営業担当者の業務
- 09:00 顧客管理システム(Salesforce)へログイン → 許可
- 09:30 営業資料フォルダ(SharePoint)を開く → 許可
- 10:00 人事評価システムへアクセス試行 → 権限なしで拒否
- 14:00 Salesforceへ再アクセス → デバイス状態を再確認して許可
シナリオ2:深夜の異常アクセス
- 02:00 同じ営業担当者が海外IPから機密情報へアクセス試行 → 異常と判断し追加認証要求またはブロック
このように、リソースへのアクセスはセッションごとに認可し、その際に既存の認証結果や端末の状態も評価します。利用者に毎回ログインを求めるわけではなく、再認証・再認可はポリシーやリスクの変化に応じて実施します。一度の認証だけを根拠に、広範囲のアクセス権を長時間与え続けることは避けます。許可は、その作業に必要な最小限の権限で行います。
原則④:動的なポリシーによってアクセスを決定する
これがゼロトラストの真骨頂です。アクセスの許可・拒否は、固定的なIDとパスワードだけでなく、その時の状況(コンテキスト)に応じて動的に判断されます。
評価される主要な要素:
アイデンティティ(誰が)
- ユーザーの役職・所属部署
- 雇用形態(正社員、契約社員、派遣社員、外部委託)
- 業務上の役割(Role-Based Access Control)
デバイスの状態(どんな端末で)
- OSバージョンとセキュリティパッチ適用状況
- ウイルス対策ソフトの稼働状態と定義ファイル更新日時
- 会社支給端末か個人所有端末(BYOD)か
- ジェイルブレイク・ルート化の有無
- デバイス証明書の有効性
- MDM(Mobile Device Management)登録状態
環境要因(どのような状況で)
- アクセス元の地理的位置(GPS、IPアドレスの国判定)
- アクセス時刻(営業時間内か、深夜・休日か)
- 接続元ネットワーク(信頼できる企業Wi-Fiか、公衆Wi-Fiか)
- 過去のアクセスパターンからの逸脱度(行動分析)
- 脅威インテリジェンス(接続元IPが既知の攻撃者リストに含まれているか)
動的判断の実例:
ケース1:通常業務(低リスク)
営業部の鈴木さんが、会社支給PC(セキュリティパッチ適用済み)から、本社オフィスのWi-Fi経由で、平日10時に顧客データベースへアクセス
→ リスクスコア:15点 → 即座に許可
ケース2:異常パターン(高リスク)
同じ鈴木さんが、個人のスマートフォン(MDM未登録)から、ロシアのIPアドレス経由で、日曜深夜2時に同じデータベースへアクセス
→ リスクスコア:92点 → 追加の生体認証要求または完全ブロック+管理者へアラート
(数値は説明用の例です)
この動的な判断により、正規ユーザーの利便性を保ちつつ、異常な状況での不正アクセスのリスクを低減します。
原則⑤:すべての資産の整合性とセキュリティ状態を監視する
アクセスしてくるデバイスが「健康」であることを常に確認します。セキュリティパッチが未適用であったり、マルウェア感染の疑いがある端末からのアクセスは、たとえID・パスワードが正しくても、リスクがあると判断してアクセスを拒否または制限します。
監視・評価する具体的項目:
デバイス健全性スコアの算出基準
- OSとアプリケーションのバージョン(最新から何世代遅れているか)
- セキュリティパッチ適用状況(Critical更新が未適用なら減点)
- ウイルス定義ファイルの更新日時(24時間以内に更新されていなければ減点)
- 不正なルート権限取得・ジェイルブレイクの有無(検出されたら大幅減点)
- ディスク暗号化の有効化状態(BitLocker、FileVault)
- 未承認アプリケーションのインストール検知
- ファイアウォール・セキュリティソフトの稼働状態
対応の自動化例:
EDR(Endpoint Detection and Response)などが算出したデバイスのリスク情報をMDM・IdP・PEPと連携し、事前に設定したポリシーによってアクセスを制限する例です。スコアが基準値(たとえば70点)を下回った場合、次のように制限します。
- スコア60〜69点:警告通知を表示し、機密データへのアクセスを制限
- スコア40〜59点:業務システムへのアクセスを読み取り専用に制限(読み取り専用化は、対象アプリ側がその制御に対応している必要があります)
- スコア39点以下:すべてのアクセスをブロックし、IT部門へアラート送信
(数値は説明用の例です)
これにより、脆弱な端末からの情報漏洩や感染拡大のリスクを低減します。
原則⑥:すべてのリソースの認証と認可を動的に行い、アクセスを許可する前に厳格に実施する
NIST SP800-207の原文は「All resource authentication and authorization are dynamic and strictly enforced before access is allowed.」です。認証・認可は一度きりで終わりではなく、アクセスを許可する前に、その時点の状況に応じて動的かつ厳格に実施します。そのうえで、「認証(Authentication:本人確認)」と「認可(Authorization:権限付与)」を明確に分離します。たとえ本人であることが確認できても、そのアクセスが業務上必要かどうかを別途判断するのです。
原文では、多要素認証(MFA)の活用に加え、時間の経過、新しいリソースの要求、異常な挙動の検知などを契機として、利用中にも再認証・再認可を行うことが挙げられています。
最小権限そのものは原則③④に明記された考え方で、原則⑥の動的な認可と組み合わせて実装します。
最小権限(最小特権)の原則(Principle of Least Privilege)の実装
ユーザーに付与する権限は、その時点で必要な作業を行うための最小限に留めます。
業務別の権限設計例:
経理担当者
- 会計システム:読み取り専用(月次レポート閲覧のみ)
- 請求書承認システム:承認権限あり
- 人事システム:アクセス不可
開発者
- 開発環境:読み取り・書き込み権限あり
- ステージング環境:読み取り専用
- 本番環境:原則アクセス不可(緊急時のみJITで一時的に許可)
外部委託先(デザイナー)
- 特定プロジェクトフォルダ:読み取り・アップロード権限あり
- 他プロジェクトフォルダ:アクセス不可
- 社内メール・Slackチャンネル:招待された特定チャンネルのみ参加可能
JIT(Just-In-Time)アクセスの活用
管理者権限が必要な作業(サーバーメンテナンス、緊急対応など)の際にのみ、申請・承認プロセスを経て一時的に権限を昇格させます。昇格した権限は、有効化から設定した時間(例:30分)が経過すると自動的に失効します。作業終了時に手動で無効化する運用も可能です。
これにより、「管理者権限の常時保持」という高リスク状態を回避し、権限の不正利用や誤操作のリスクを低減します。
原則⑦:資産・通信の状況について情報を収集し、継続的に改善する
ネットワーク全体のトラフィック、認証ログ、デバイスの状態などを常に収集・分析します。これにより、平常時のベースラインを把握し、そこから逸脱する微細な異常を検知できるようにするとともに、セキュリティポリシーの継続的な改善に役立てます。
収集・分析するデータ項目:
認証・アクセスログ
- ログイン試行(成功・失敗)の日時・ユーザー・IPアドレス
- アクセスしたリソースの種類と操作内容(閲覧、編集、削除)
- セッション継続時間
デバイス健全性ログ
- セキュリティスコアの時系列推移
- パッチ適用履歴
- 異常検知アラートの発生状況
ネットワークトラフィック
- 通信量の推移(平常時と比較した異常な増加を検知)
- 通信先(外部の不審なIPアドレスへの接続を検知)
- プロトコル分析(暗号化されていない通信を検知)
脅威インテリジェンス連携
- 外部の脅威情報データベースと照合
- 既知の攻撃キャンペーンのIndicators of Compromise(IoC)との一致確認
SIEM/SOARによる自動対応
これらのログをSIEM(Security Information and Event Management)で集約し、相関分析ルールや、製品によっては機械学習(UEBA)を用いた異常検知を行います。
異常検知の実例:
- 通常は東京オフィスからしかアクセスしない社員が、突然モスクワのIPアドレスからログイン試行
- 深夜2時に通常の100倍のファイルダウンロードが発生
- 同一アカウントで短時間に10回以上のログイン失敗
SOAR(Security Orchestration, Automation and Response)は、必要な連携・権限・プレイブックを設定した場合、異常の種類に応じて次のような初動対応を自動化できます。
- 該当アカウントを一時ロック
- 該当デバイスをネットワークから隔離
- セキュリティ担当者へアラート送信
- インシデント対応チケットを自動作成

ゼロトラストを実現する論理コンポーネント(PDPとPEP)
NIST SP800-207では、ゼロトラストを実現するための論理的なアーキテクチャも定義されています。これは、「判断する頭脳」と「実行する門番」に分けて考えると理解しやすくなります。
コントロールプレーン(制御面):判断する「頭脳」
ここがゼロトラストの司令塔です。すべてのアクセス要求に対して、許可すべきかどうかの判断を下します。この機能をPDP(Policy Decision Point:ポリシー決定ポイント)と呼びます。PDPはさらに二つの要素で構成されます。
ポリシーエンジン(Policy Engine:PE)
様々な情報(コンテキスト)を収集・分析し、ポリシーに基づいてアクセスの可否を決定する、まさに「頭脳」となる部分です。
PEが評価する情報源:
- IdP(Identity Provider)からのユーザー属性情報
- MDM/UEMからのデバイス健全性情報
- SIEMに集約されたログや、脅威インテリジェンスフィード
- 過去のアクセスログから算出した行動パターン
- 組織のセキュリティポリシー定義
これらを総合的に評価し、アクセスを「許可」するか「拒否」するか(既に許可したアクセスの取り消しを含む)を判断します。
ポリシーアドミニストレーター(Policy Administrator:PA)
ポリシーエンジンの決定を受け、実際に通信を制御するゲートウェイ(PEP)に対して、通信の許可・遮断の命令を出す「指揮官」の役割です。
PAが実行する処理:
- PEPへのセッション確立指示
- セッション固有の認証トークンや資格情報(クレデンシャル)の生成
- 通信経路の動的な設定
- セッション終了時の切断指示
データプレーン(データ面):実行する「門番」
実際にユーザーの端末とリソースの間のデータ通信が流れる経路です。ここに設置されるのがPEP(Policy Enforcement Point:ポリシー適用ポイント)です。
PEP(Policy Enforcement Point)
実際の通信経路上にあるゲートウェイやエージェントです。通信の許可・監視・終了を担い、アクセス要求をPAへ転送し、PAから指示を受けます。論理的な役割としては、PAから許可の指示があったセッションだけを通過させ、それ以外のアクセスは通さない「門番」です。
PEPの実装形態:
PDPとの連携、認証・認可、未許可アクセスの拒否を設定したプロキシやゲートウェイがPEPを担います。通常のリバースプロキシは、置いただけではPEPになりません。
- 認証・認可の連携を構成したリバースプロキシ・アクセスプロキシ(Cloudflare Accessなど)
- Software-Defined Perimeter(SDP)ゲートウェイ
- ポリシー連携を構成したNext-Generation Firewall(NGFW)
- インライン(プロキシ)方式のCASB(Cloud Access Security Broker)
- ゼロトラストネットワークアクセス(ZTNA)ゲートウェイ
動作フロー:
- ユーザーがリソース(業務アプリ)へのアクセスを試行
- PEPがアクセス要求を検知し、コントロールプレーン(PA)へ要求を転送
- PE(ポリシーエンジン)が各種情報を評価し、判断を下す
- PA(ポリシーアドミニストレーター)がPEPへ制御指示を送信
- PEPが指示に従い、セッションを確立(許可)または拒否
- セッション終了後、PEPは再び通信を遮断状態に戻す
この一連のプロセスは自動で実行されるため、利用者の負担を抑えられます。

ゼロトラストを実装する主要技術要素
ゼロトラストは単一の製品ではなく、複数の技術を組み合わせたアーキテクチャです。その核となる主要技術要素を詳しく見ていきましょう。
アイデンティティ管理(IdP: Identity Provider)
ゼロトラストにおいて、アイデンティティ(ID)は新しい「境界」となります。「誰が」アクセスしているかを確実に特定するための基盤がIdPです。
主要なIdP製品:
- Microsoft Entra ID(旧Azure AD)
- Okta
- Google Workspace
- OneLogin
- Ping Identity
IdPが提供する主要機能:
多要素認証(MFA: Multi-Factor Authentication)
次の3種類の認証要素のうち、異なる種類を2つ以上組み合わせます。パスワード(知識要素)に加えるなら、所持要素か生体要素を組み合わせます(パスワード+秘密の質問のように同じ知識要素を重ねても、多要素認証にはなりません)。
- 知識要素:パスワード、PIN、秘密の質問
- 所持要素:スマートフォンアプリ(Microsoft Authenticator、Google Authenticator)、ハードウェアトークン(YubiKey)
- 生体要素:指紋認証、顔認証、虹彩認証
シングルサインオン(SSO)
一度の認証で複数のシステムにアクセスできる仕組み。ユーザーは何度もログインする手間が省け、IT部門はパスワード管理の負担が軽減されます。ゼロトラストでもSSOは併用でき、IdPの認証結果を各リソースの認可判断の材料にします(リスクが変化したときは再認証を求めます)。
条件付きアクセス(Conditional Access)
ユーザーの属性やデバイス状態に応じて、アクセス制御ルールを動的に適用します。「管理者アカウントは必ずMFA必須」「海外からのアクセスは追加認証を要求」といったポリシーを柔軟に設定できます。
エンドポイント保護(EDR/MDM)
アクセスしてくる「端末」の安全性を担保します。
EDR(Endpoint Detection and Response)
従来のウイルス対策ソフトとは異なり、端末内部での不審な挙動をリアルタイムに検知・記録し、サイバー攻撃の予兆や侵入後の活動を早期に発見します。
主要EDR製品:
- CrowdStrike Falcon
- Microsoft Defender for Endpoint
- Carbon Black
- SentinelOne
- TrendAI Vision One(旧Trend Vision One)
EDRが検知する脅威例:
- ファイルレス攻撃(メモリ上でのみ動作するマルウェア)
- ランサムウェアの暗号化動作
- 不正なプロセスの実行
- 機密ファイルの大量コピー
- C&Cサーバーへの通信
問題のある端末は、ポリシーに応じて自動、または管理者の操作でネットワークから隔離し、感染拡大を防ぎます。
MDM/UEM(Mobile Device Management / Unified Endpoint Management)
会社支給の端末や個人所有端末(BYOD)を一元管理します。
主要MDM製品:
- Microsoft Intune
- Omnissa Workspace ONE(旧VMware Workspace ONE)
- Jamf(Apple製品特化)
- Ivanti Neurons for MDM(旧MobileIron)
MDMが実行する管理機能:
- セキュリティパッチの自動配信
- パスワードポリシーの強制
- 未承認アプリのインストール制限
- 紛失・盗難時のリモートワイプ(データ消去)
- 業務データと個人データの分離(コンテナ化)
クラウドセキュリティ(SASE/SSE)
SASE(Secure Access Service Edge)
ネットワーク機能とセキュリティ機能をクラウド上で統合したフレームワークです。Gartnerが2019年に提唱した概念で、「どこからのアクセスであっても、常に同じポリシーで安全性をチェックする」ことを実現します。
SASEの構成要素:
- SD-WAN(Software-Defined Wide Area Network):拠点間ネットワークの最適化
- SWG(Secure Web Gateway):Webトラフィックのフィルタリング
- CASB(Cloud Access Security Broker):クラウドサービスへのアクセス制御
- ZTNA(Zero Trust Network Access):VPNに代わるセキュアなリモートアクセス
- FWaaS(Firewall as a Service):クラウド型ファイアウォール
主要SASEベンダー:
- Zscaler
- Netskope
- Cloudflare
- Palo Alto Networks(Prisma Access)
- Cisco(Cisco Secure Access/Umbrellaの後継)
SSE(Security Service Edge)
SASEからSD-WAN機能を除いた、セキュリティ機能に特化したサービス群です。
SWG(Secure Web Gateway)の役割
Webトラフィックを検査・フィルタリングするゲートウェイです(クラウド型とオンプレミス型があり、SSEではクラウド型として提供されます)。インターネットへのアクセスをゲートウェイ経由にし、マルウェアサイトや不適切なコンテンツへのアクセスをブロックします。URLフィルタリング、サンドボックス解析、DLP(Data Loss Prevention)機能を提供します。
CASB(Cloud Access Security Broker)の役割
SaaSアプリケーション(Microsoft 365、Salesforce、Boxなど)へのアクセスを可視化・制御します。
CASBの主要機能:
- シャドーIT の発見(未承認クラウドサービスの利用検知)
- 機密データのアップロード制限
- 異常なアクセスパターンの検知
- コンプライアンス違反の防止
ZTNA(Zero Trust Network Access)
VPNに代わる次世代リモートアクセスソリューションです。ネットワーク全体へのアクセスを与えるのではなく、アプリケーション単位で必要最小限のアクセスのみを許可します。
VPNとZTNAの違い:
| 項目 | 従来型VPNの典型的な構成 | 継続評価を構成したZTNA |
|---|---|---|
| アクセス範囲 | ネットワーク全体(になりやすい) | 特定のアプリケーションのみ |
| 認証タイミング | 接続時のみ | セッションごと |
| デバイス検証 | なし、または接続時のみ | 継続的に評価 |
| 攻撃者の横展開 | 起きやすい(到達範囲が広い) | 大幅に抑制(許可されたアプリにしか到達できない) |
VPNでも、再認証や継続的な端末評価を構成できる製品があります。この表は典型的な構成どうしの比較です。
ゼロトラスト実装へのロードマップ
ゼロトラストへの移行は一足飛びにはいきません。現状を把握し、段階的に進めることが重要です。ここで示すフェーズの順序や期間は一例で、全社で共通の順序や期間があることがゼロトラストの要件ではありません。組織の状況に合わせて調整します。また、ログの収集・監視は初期から行い、後半のフェーズで統合と自動化の範囲を広げます。
フェーズ1:現状把握とアイデンティティ基盤の整備(3〜6ヶ月)
ステップ1:アセットとIDの可視化
まず、守るべきリソースは何か、誰がどのようなデバイスでアクセスしているのか、シャドーIT(未承認クラウドサービスの利用)はないか、現状を正確に把握することから始めます。
実施項目:
- すべてのユーザーアカウントの棚卸し
- 使用されているデバイスのリストアップ
- アクセスされている業務システム・SaaSの洗い出し
- ネットワークトラフィックの分析(CASBツールを活用)
- 認証ログ・アクセスログの収集と監視の開始
ステップ2:IdPの導入とMFAの全社展開
効果が高く、比較的着手しやすいのが認証の強化です。
実施項目:
- クラウド型IdP(Microsoft Entra ID(旧Azure AD)、Oktaなど)の導入
- 既存Active Directoryとの連携設定
- 多要素認証(MFA)の段階的展開
- 段階1:管理者アカウント
- 段階2:機密情報を扱う部署
- 段階3:全社員
- シングルサインオン(SSO)の設定
目標KPI:
- MFA有効化率:100%達成
- パスワードリセット依頼:60%削減
- 不正ログイン試行のブロック率:95%以上
(数値は説明用の例です)
フェーズ2:エンドポイントセキュリティの強化(6〜12ヶ月)
ステップ3:MDM/UEMの導入
すべてのデバイス(PC、スマホ、タブレット)を管理対象に登録します。
実施項目:
- MDM製品の選定・導入
- 会社支給端末の登録
- BYODポリシーの策定と個人端末の登録
- セキュリティパッチの自動配信設定
- ディスク暗号化の強制
ステップ4:EDRの全社展開
リアルタイムでマルウェアを検知・隔離するツールを導入します。
実施項目:
- EDR製品の選定・導入
- 全端末へのエージェントインストール
- SOC(Security Operations Center)との連携設定
- インシデント対応フローの整備
ステップ5:デバイスコンプライアンスポリシーの適用
健全性基準を満たさない端末のアクセスを自動制限します。
コンプライアンス基準の例:
- OSバージョン:最新から2世代以内
- セキュリティパッチ:30日以内に適用済み
- ウイルス定義ファイル:24時間以内に更新済み
- ディスク暗号化:有効
- ジェイルブレイク・ルート化:検出されない
目標KPI:
- デバイス登録率:95%以上
- セキュリティパッチ適用率:90%以上(30日以内)
- コンプライアンス違反端末のブロック率:100%
(数値は説明用の例です)
フェーズ3:ネットワークセキュリティの再構築(12〜18ヶ月)
ステップ6:SASE/SSEの導入
インターネットへの出口をクラウド型セキュリティゲートウェイに集約します。
実施項目:
- SASE/SSEベンダーの選定
- SWG(Secure Web Gateway)の設定
- CASB(Cloud Access Security Broker)の導入
- URLフィルタリング・DLPポリシーの設定
- 既存プロキシサーバーからの段階的移行
ステップ7:ZTNAの展開とVPN廃止
ZTNAへの適合性を検証したアプリケーションや利用者から、段階的にVPNをZTNAへ置き換えます。
実施項目:
- ZTNA製品の導入
- アプリケーション単位のアクセスポリシー設定
- パイロット部門での検証
- 段階的な全社展開
- 置き換えが完了した対象から従来VPNを廃止
ステップ8:マイクロセグメンテーション
ネットワークを業務単位やアプリケーション単位で細分化します。
実施項目:
- ネットワークセグメントの設計
- Software-Defined Networking(SDN)の導入
- セグメント間の通信ルール設定
- 最小権限通信の実装
セグメント例:
- 人事システムセグメント:人事部のみアクセス可
- 開発環境セグメント:開発部のみアクセス可
- 本番環境セグメント:通信元・宛先・サービスを制限(読み取り専用化や変更承認は、アプリ・DBの認可やPAM/JITと連携して実装)
- ゲストネットワークセグメント:インターネットのみアクセス可
目標KPI:
- VPNトラフィック削減率:80%以上
- 平均通信速度改善率:50%以上
- ラテラルムーブメント試行のブロック率:95%以上
(数値は説明用の例です)
フェーズ4:継続的な監視と改善(18ヶ月以降)
ステップ9:SIEM/SOARの本格運用
必要なログを集約し、相関分析ルールや、対応製品では機械学習を用いて異常を検知します。
実施項目:
- SIEM製品の導入・設定
- ログソースの統合(IdP、EDR、FW、CASB、アプリケーション)
- 相関分析ルールの作成
- SOAR(Security Orchestration, Automation and Response)による自動対応の実装
- SOCチームの体制整備
ステップ10:定期的なセキュリティ評価
継続的に脆弱性を洗い出し、ポリシーを最適化します。
実施項目:
- 四半期ごとのペネトレーションテスト(侵入テスト)
- CISAのZero Trust Maturity Model(Version 2.0、2023年4月)などによる自己評価
- セキュリティポリシーのチューニング
- 従業員向けセキュリティ教育の定期実施
目標KPI:
- セキュリティインシデント検知時間:80%短縮
- インシデント対応時間:80%短縮
- 誤検知件数:月間10件以下(例)
- セキュリティ教育受講率:100%
(数値は説明用の例です)
【演習】NIST SP800-207準拠 ゼロトラスト7原則 理解度チェック(全10問)
ゼロトラストの本質を理解する上で、米国NISTのガイドラインである「NIST SP800-207」の7原則は避けて通れません。本セクションでは、PDP・PEPの論理構成や、SASE、EDRといった主要技術の役割を10問の練習問題にまとめました。アウトプットを通じて、知識の定着度を確認してみましょう。
まとめ:ゼロトラストがもたらす「真の安心」と「自由な働き方」
「暗黙の信頼を与えない」という言葉は冷たく聞こえるかもしれません。しかし、ゼロトラストの本質は、人を疑うことではありません。
システムが検証を自動的かつ厳格に行うことで、ポリシーを満たす利用者・端末に場所に依存しにくいアクセスを提供し、安全性と利便性の両立を目指します。
境界防御の時代、私たちは「城壁の中にいる人は味方」と盲目的に信じていました。しかし、単一の城壁だけでは保護対象を囲えなくなり、利用者もデータも社外のクラウドへ広がっています。境界防御がなくなるわけではなく、ゼロトラストと併用して守りを重ねます。
ゼロトラストは、一人ひとりの身元とデバイスの状態を正確に確認し、必要な権限だけを与えることで、組織全体を守ります。それは決して「疑う」ためではなく、「安心して働ける環境を作る」ための仕組みなのです。
テレワークが当たり前になった今、セキュリティは「制約」ではなく「自由を支える基盤」です。ゼロトラストを正しく理解し、段階的に導入することで、場所に依存しにくい、柔軟で安全な働き方に近づけます。
ゼロトラストは、情報処理安全確保支援士試験の学習と実務の両面で押さえておきたいテーマです。本記事で解説したNIST SP800-207の7原則、PDP/PEPの論理構成、そして具体的な実装技術をしっかりと理解し、試験合格と実務での活躍を目指してください。
参考資料
- NIST SP 800-207, Zero Trust Architecture(https://doi.org/10.6028/NIST.SP.800-207)
- CISA Zero Trust Maturity Model(https://www.cisa.gov/zero-trust-maturity-model)
+おまけ:毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。