ゼロトラストとは？従来型セキュリティとの違いと発注者が確認すること

「ゼロトラストでセキュリティを再構築します」。ベンダーから受け取った提案書にそう書かれていて、何から確認すればよいか迷っていないでしょうか。ファイアウォールとVPNで社内ネットワークを守ってきた情報システム担当者にとって、「ゼロトラスト」という言葉は具体像がつかみづらく、提案の良し悪しを判断する軸も持ちにくい領域です。

一方で、クラウドサービスの利用拡大やテレワークの常態化を背景に、経営層からは「時代に合わせたセキュリティ強化」を求められます。社内にセキュリティアーキテクトがいないまま、複数ベンダーの提案を比較・意思決定しなければならない立場にある方は少なくありません。

この記事が最も避けたいのは、「ゼロトラストは内外を区別しない新しい考え方です」という抽象論で終わることです。それではベンダー提案を前にしたときの判断軸になりません。むしろ必要なのは、「従来の境界型と実装レベルで何が変わるのか」「どの要素を優先的に揃えるべきか」「提案書のどこを読めば筋の良さが分かるのか」という、発注者としての視点です。

本記事では、ゼロトラストの定義と基本思想を短時間で整理したうえで、境界型セキュリティとの違いを発注者が判断に使える5つの観点で比較します。さらに、乱立する用語（IAM・ZTNA・SASE・EDRなど）を優先度マップで整理し、最後にベンダー提案を評価するための10のチェックリストを提示します。提案書をレビューする際に、そのまま手元で使える内容を目指しています。

執筆者

秋霜堂株式会社 代表 石川瑞起

中学生でプログラミングを独学で習得し、HP制作やアプリ開発の事業を開始。 大学入学後に事業を売却し、トヨクモ株式会社へ入社。 3年間にわたり1製品の開発責任者を務めたのち秋霜堂株式会社を設立し、多数の企業をサポートしている。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード

ゼロトラストとは何か — 「信頼しない」を前提にする新しいセキュリティの考え方

ゼロトラストは、「社内ネットワークの内側であっても自動的には信頼しない」という前提からセキュリティを設計し直す考え方です。単一の製品名ではなく、複数の技術要素と運用ルールを組み合わせて実現する「設計思想」「アーキテクチャ」である点が、まず押さえるべきポイントになります。

ゼロトラストの定義（"Verify and Never Trust"）

ゼロトラストという用語は、米国の調査会社Forrester Researchのジョン・キンダーバーグ氏が2010年に提唱したとされています。基本的な原則は「決して信頼せず、常に検証する（Never Trust, Always Verify）」というものです。ユーザー・デバイス・通信・アプリケーションといったあらゆるアクセス要素について、アクセスのたびに都度検証し、条件を満たした場合にのみ最小限のアクセス権を与える、という設計を目指します。

その後、米国国立標準技術研究所（NIST）が2020年に「SP 800-207 Zero Trust Architecture」を公開し、ゼロトラストの7つの基本原則が世界的な参照軸になりました（PwC Japan: NIST SP800-207 解説）。以降、各ベンダーの製品やサービスは、このNIST SP800-207をベースに「どの原則をどう実装しているか」で語られることが多くなっています。

なぜ今ゼロトラストが注目されるのか

ゼロトラストが急速に広まった背景には、働き方とITインフラの前提が変わったという事情があります。

• クラウドサービスの利用拡大: 業務データやアプリケーションが社内ネットワークの外（SaaS・IaaS）に分散し、「社内だけ守ればよい」という前提が崩れた
• テレワークの常態化: 社外からのアクセスが例外ではなく日常になり、VPN集中による回線負荷・運用負荷が増した
• サイバー攻撃の高度化: 認証情報の窃取やサプライチェーン攻撃によって、境界の内側にまで攻撃者が入り込むケースが増えた

つまり、「境界型が弱くなった」というより「守るべき対象がそもそも境界の外にある」状況が広がったため、アクセスごとに検証するアプローチが現実解として選ばれるようになったわけです。

ゼロトラストは「製品」ではなく「設計思想」である

発注者としてまず押さえておきたいのは、「ゼロトラスト」という名前の単一パッケージ製品は存在しない、という事実です。実際に現場で構築する際は、ID管理・デバイス管理・ネットワーク制御・ログ監視など複数のコンポーネントを組み合わせます。ベンダーが「当社のゼロトラスト製品」と呼んでいる場合でも、その中身は複数要素のスイートであるか、ZTNA・SASEといった特定領域の製品であることが大半です。

この前提を知っているだけで、提案書を読むときの視点が変わります。「この提案は、ゼロトラストのどの領域をカバーしているのか」「カバーしていない領域はどう補うのか」を確認できるようになるからです。

境界型セキュリティとの違い — 発注者が押さえるべき5つの観点

ゼロトラストと境界型の違いを「内外を区別しない」という抽象論で済ませてしまうと、提案書の評価には使えません。ここでは、発注者が実装レベルで判断に使える5つの観点で整理します。

比較表で俯瞰する5つの観点

この表で重要なのは、「ゼロトラストは境界型の上位互換」という見方ではなく、「前提としている環境そのものが違う」と捉えることです。社内リソースがすべてオンプレで閉じている企業では境界型が今でも有効に機能しますし、SaaS中心の環境ではゼロトラストの考え方が必然になります。

VPN・ファイアウォールは不要になるのか？（共存のリアル）

「ゼロトラストを導入したらVPNを撤廃できるのか」という疑問は発注者からよく出ます。結論としては、多くの企業では段階的な共存が現実解になります。

ZTNA（Zero Trust Network Access）はVPNの代替候補として語られることが多い技術ですが、社内にレガシーシステムが残っている場合はVPN経由のアクセスを当面維持したうえで、新規のSaaS・業務アプリから順次ZTNAに置き換えるアプローチが一般的です。ファイアウォールも同様で、データセンター内部のセグメンテーションや外部公開サービスの保護には引き続き役割があります。「ゼロトラスト＝VPN・ファイアウォール廃止」と単純化せず、「どの通信をどの仕組みで守るか」をマッピングする発想が重要です。

Active Directoryなど既存認証基盤はどうなる？

既存のActive Directory（AD）やオンプレミスのID管理基盤も、多くの場合は廃止ではなく「ゼロトラスト構成の土台として活用」します。具体的には、Microsoft Entra ID（旧Azure AD）などのクラウドID基盤とADを連携させ、ユーザー情報の同期やシングルサインオン（SSO）基盤として既存資産を活かす構成が主流です。オンプレADを残したまま、クラウド側で多要素認証（MFA）やアクセス条件ポリシーを強化するパターンも広く採用されています。

ベンダー提案の中で「既存ADは廃止してクラウド一本化」と書かれている場合は、移行コスト・業務アプリへの影響・ネットワーク認証（Kerberos依存のオンプレサービス）への影響を必ず確認してください。

境界型が「弱くなった」のではなく「前提が変わった」ことの意味

最後に押さえておきたいのは、境界型セキュリティそのものが無価値になったわけではない、という点です。適切に運用されたファイアウォール・IDS/IPSは今でも有効な防御層です。変わったのは、守るべき資産とアクセスパターンが境界の外に広がったために、「境界だけでは守りきれない」状況が生まれた点にあります。

発注者としては「境界型を捨ててゼロトラストに置き換える」という極端な提案よりも、「境界型をどこで残し、どこをゼロトラスト的に再設計するか」の設計方針を示せるベンダーのほうが、現実的で信頼できると判断できます。

ゼロトラストを構成する主要要素 — 用語の優先度マップ

ゼロトラスト領域では、IAM・ZTNA・SASE・EDR・SWG・CASB・UEMなど略語が乱立します。ここでは単に列挙するのではなく、どの順番で着手すべきかという優先度の視点で整理します。

全体マップ（5レイヤーで俯瞰する）

ゼロトラストを構成する技術要素は、大きく以下の5レイヤーに分類できます。

提案書を読むときは、このマップに照らして「どのレイヤーをカバーしているのか」「抜けているレイヤーをどう補うのか」を確認すると、検討の抜け漏れを防げます。

まず着手すべき"土台" — IAM（ID管理・多要素認証・SSO）

ゼロトラストを進める際、最も優先度が高いのはIAM（Identity and Access Management）の整備です。ゼロトラストのすべての判断は「このユーザーは本当に本人か」「このアクセス要求は妥当か」というID検証から始まるため、ここが弱いと他の投資が活きません。

IAMの中核要素は以下の3つです。

• 多要素認証（MFA）: ID・パスワードに加えて、スマートフォンアプリ・生体認証などを組み合わせて本人確認を強化する
• シングルサインオン（SSO）: 一度の認証で複数のサービスにアクセスできるようにする。管理対象IDを集約することで、退職者アカウントの即時無効化など運用も改善する
• 条件付きアクセス（動的アクセスポリシー）: ユーザー・デバイス・場所・時間などの属性からリスクを評価し、ハイリスクの場合のみ追加認証を要求する

ベンダー提案に「ZTNAを導入してセキュリティを高めます」とある場合でも、IAMが未整備だと効果は半減します。提案を受けたら「ID管理の現状をどう診断・整備するのか」を必ず確認してください。

ネットワーク層 — ZTNA / SASE / SWG / CASBの違いと使い分け

ネットワーク層の用語は特に混乱しやすいので、整理しておきます。

• ZTNA（Zero Trust Network Access）: ユーザー・デバイスを都度検証したうえで、特定アプリケーションへのアクセスのみを許可する仕組み。VPNの代替候補として語られることが多い
• SWG（Secure Web Gateway）: Webアクセスを監視・フィルタリングし、悪意あるサイトへのアクセスを防ぐ
• CASB（Cloud Access Security Broker）: SaaS利用の可視化・制御を行う。シャドーITの検出・データ流出防止に使う
• SASE（Secure Access Service Edge）: 上記のZTNA・SWG・CASB・ファイアウォールなどをクラウドで統合提供するアーキテクチャの呼称

関係性としては、ZTNAはゼロトラストの原則をネットワークアクセスに適用した技術、SASEはZTNAを含む複数機能を統合した包括的フレームワークと整理できます（IIJ: SASEとZTNAの違い）。提案書で「SASEで一括解決」と書かれていても、実態としてベンダーが強い領域（ZTNA中心、SWG中心など）があるため、どの機能の完成度が高いかを個別に確認する必要があります。

デバイス層 — EDR / UEMの役割

アクセス元デバイスの状態を検証するのもゼロトラストの重要要素です。

• EDR（Endpoint Detection and Response）: エンドポイント（PC・サーバー）の振る舞いを監視し、マルウェア感染・不審な挙動を検知・対応する
• UEM / MDM（Unified Endpoint Management / Mobile Device Management）: デバイスの構成・パッチ適用状況・暗号化状態などを一元管理する

ゼロトラストでは「このデバイスは管理下にあり、最新パッチが適用されているか」をアクセス判定条件の一つに使います。そのためEDR・UEMはIAMと並んで早期に整備すべき領域です。

監視・可視化層 — SIEM / ログ統合の必要性

各レイヤーから出るログを統合し、異常を検知する仕組みも不可欠です。代表例がSIEM（Security Information and Event Management）です。ゼロトラストでは「動的にアクセスを評価する」という性質上、ログが劇的に増えるため、単純にログを貯めるだけではなく相関分析・自動検知・インシデント対応の体制（SOC）までセットで設計する必要があります。

ベンダー提案に「ログは出力可能です」とだけ書かれている場合、誰がそのログを分析し、誰がインシデント対応を担うのかの責任分界を必ず確認してください。

参考: NIST SP800-207の7原則との対応

NIST SP800-207の7原則は、提案書の根幹を評価するうえでの共通言語として使えます。要約すると以下の通りです（NIST SP800-207 原則の解説）。

1. すべてのデータソース・コンピューティングサービスをリソースとみなす
2. ネットワークの場所に関わらず、すべての通信を保護する
3. 企業リソースへのアクセスはセッション単位で付与する
4. リソースへのアクセスは動的ポリシーで決定する（ID・デバイス状態・行動属性等を加味）
5. すべての資産の整合性・セキュリティ動作を監視・測定する
6. すべてのリソースの認証・認可を動的に、厳格に実施する
7. 資産・ネットワーク・通信の現状情報を収集し、セキュリティ態勢の改善に利用する

ベンダー提案の設計思想が、これら7原則のどこを重点的にカバーしているかを確認すると、提案の筋の良し悪しを判断しやすくなります。

ゼロトラスト導入で実際に変わること — 発注者が把握すべきインパクト

ゼロトラストを導入すると、システム設計・運用・ユーザー体験のそれぞれに具体的な変化が起きます。コスト・スケジュール感を見積もるためにも、どこがどう変わるかを発注者として把握しておきましょう。

システム設計への影響（アプリ単位のアクセス制御）

最も大きな変化は、アクセス制御の粒度がネットワークセグメントからアプリケーション単位に細かくなることです。従来の「VPN接続すれば社内全体のネットワークにアクセス可能」という設計から、「ユーザーAはアプリXにのみアクセス可能、ユーザーBはアプリYとZ」という設計に変わります。これはマイクロセグメンテーションとも呼ばれ、仮に認証情報が漏洩しても被害範囲を最小化できる利点があります。

一方、アプリケーションの棚卸し・アクセス権限設計の工数が大きくなります。移行プロジェクトの初期には、既存業務アプリのインベントリ整備と利用者マッピングに相応の時間を割くと認識しておく必要があります。

運用への影響（ログ監視・ポリシー運用）

ゼロトラストは「動的にアクセスを評価する」仕組みのため、運用負荷のポイントが従来と変わります。

• ポリシー運用: 誰がどのリソースにアクセスできるかのルールを継続的に見直す運用が必須になる
• ログ監視: アクセスごとの検証結果が大量に記録されるため、SIEM等で相関分析・自動化する体制が必要
• インシデント対応: 「怪しい挙動を検知した際に誰が何を判断するか」の責任分界を事前に定義しておく必要がある

社内にSOC（Security Operation Center）機能を持たない場合は、マネージドサービス（MDR・MSS）の併用が現実的な選択肢になります。

ユーザー体験への影響（多要素認証・デバイス検査の頻度）

ゼロトラストは検証を増やす仕組みである以上、ユーザーから見ると「ログインの手間が増えた」と感じる場面が発生します。これを最小化するには、リスクベース認証（普段と同じ端末・場所からのアクセスでは追加認証をスキップする仕組み）の活用が鍵になります。提案書では、利便性と安全性のバランスをどう取る設計かを確認してください。

一括導入ではなく段階導入が現実解である理由

全社一斉に全レイヤーを入れ替えるプロジェクトは、コスト・リスク・現場負荷の面で成立しにくいのが実情です。現実的なアプローチは、IAM整備 → デバイス管理 → ネットワーク制御 → ログ監視統合のように優先度をつけて段階的に導入するものです。ベンダー提案が「一気に全面刷新」型であれば、段階導入の選択肢も提示するよう求めるほうが安全です。

クラウドやSaaSの利用拡大と並行して、生成AIのセキュリティリスクへの対応もゼロトラスト導入を後押しする背景の一つになっています。

ゼロトラスト導入を検討すべき企業・場面

すべての企業が今すぐフルスケールでゼロトラストを導入する必要があるわけではありません。事業環境によって優先度は大きく変わります。

検討優先度が高いケース

以下に当てはまる企業は、ゼロトラスト化の優先度を上げたほうがよい代表例です。

• クラウド移行・SaaS利用が進んでいる: 業務データが社外に分散しており、境界型では守りきれない
• テレワーク・ハイブリッドワークが常態化: 社外アクセスが日常であり、VPN集中の限界が見えている
• 機密情報・個人情報を大量に扱う: 金融・医療・法務など、漏洩時の影響が甚大
• M&A・グループ会社統合が多い: 複数ドメインのユーザー・端末を統合管理する必要がある

段階的でよいケース

反対に、以下のような環境では境界型の維持+部分的ゼロトラスト化が現実的です。

• 閉域ネットワーク中心の基幹業務: 工場制御系・OTネットワークなど、外部接続が限定的
• 物理拠点が少なく、社外アクセスがほぼ発生しない: 本社1拠点のみで完結する業務など
• 既存境界型セキュリティが十分機能しており、直近のインシデントがない: リスクと投資のバランスを見極める余地がある

業界別の典型パターン

参考までに、業界ごとの典型的な優先領域を示します。

自社がどのパターンに近いかを整理したうえでベンダーと議論することで、提案の解像度が上がります。

発注者がベンダー提案で確認すべきポイント — 10のチェックリスト

ここまでの内容を、提案書レビュー時にそのまま使えるチェックリストにまとめます。本記事で最も実務に直結するセクションです。提案書を読みながら、各項目に対するベンダーの回答・記載の有無を確認してください。

設計思想レベルの確認項目

既存資産との整合

運用体制の確認

段階導入計画の妥当性

コスト構造の透明性

このチェックリストを手元に、ベンダーとの打ち合わせで順番に確認していくと、提案の穴や説明の弱い部分が浮かび上がります。すべての項目で満点の提案は稀ですが、項目6〜10の運用・コストに関する記述がどれだけ具体的かが、ベンダーの実装経験と誠実さを測る最も良い目安になります。

なお、ベンダー提案を評価する前段としてセキュリティ要件定義を整備しておくと、チェックリストをより実効性の高いものとして活用できます。

まとめ — ゼロトラストは「単一製品」ではなく「発注者の判断軸」で捉える

ゼロトラストは、特定のパッケージ製品を指す言葉ではなく、「信頼せず都度検証する」設計思想です。境界型セキュリティとの違いは、単に「内外を区別しない」という抽象論ではなく、アクセス制御の粒度・認証頻度・前提環境といった実装レベルで現れます。

発注者として重要なのは、ゼロトラストの知識を網羅的に覚えることではなく、自社の環境と既存資産を踏まえ、ベンダー提案のどこを評価すればよいかの判断軸を持つことです。本記事で紹介した5レイヤーの構成要素マップ、段階導入の現実解、そして10のチェックリストを、提案書レビューの手元資料として使ってみてください。

ゼロトラストは一度導入して終わるものではなく、継続的なポリシー運用と技術アップデートが必要な領域です。単発プロジェクトとしてではなく、中長期のセキュリティロードマップとして設計できるベンダーと組めるかが、導入成否を左右します。

秋霜堂株式会社は、システム開発のプロフェッショナルとして、ゼロトラスト導入を含むセキュリティ設計・要件定義から開発・運用まで一貫して支援しています。ベンダー提案の評価や要件整理からご相談いただくことも可能です。詳しくは秋霜堂株式会社のサービス紹介をご覧ください。

無料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

詳しく見る

お名前

お名前

会社名

会社名

メールアドレス

メールアドレス

電話番号（任意）

電話番号（任意）

具体的なお悩みがあればご記入ください

具体的なお悩みがあればご記入ください

プライバシーポリシーに同意する

無料ダウンロード