ゼロトラストとは？新時代のセキュリティモデルを導入する

Verizon 2024 DBIRは「侵害の68%に人の要素が関与」と報告し¹、IBM Cost of a Data Breach 2023は平均被害額を445万ドルと示しました²（最新版でも高止まりの傾向は続いています）。境界の内側は安全という前提は、SaaSとリモートワークの常態化、サプライチェーン連携の拡大、そして攻撃者の認証回避手口の洗練により、事実上成立しなくなっています⁸⁹。Forresterが提唱し、NIST SP 800-207が定義したゼロトラスト（Zero Trust Architecture, ZTA）は、この現実を踏まえた設計原則です³。信頼は初期付与ではなく継続検証、アクセスはネットワーク位置ではなくコンテキストに基づく、権限は最小化し用途ごとに限定する。言い換えると、守る単位を境界から主体（人・デバイス・ワークロード）とデータへと張り替えるのが出発点です。

ゼロトラストの定義と背景

ゼロトラストは製品名でも単一機能でもありません。NIST SP 800-207は、ポリシー決定点（PDP: Policy Decision Point）とポリシー実行点（PEP: Policy Enforcement Point）を中心に、アイデンティティ（IdP: アイデンティティプロバイダ）、デバイス状態、アプリ、ネットワーク、データ保護、可観測性の各プレーンが連携するアーキテクチャとして整理しています³。重要なのは、パケット到達と認可は別物だと割り切ることです。トンネルが張れたからといってアクセスが許されるわけではなく、アクセスのたびに主体とリスクを評価し、許可・条件付き許可・拒否を迅速に判断し続けます（ZTNA: Zero Trust Network Accessは到達制御の一部を担う実装パターンです）。

歴史を振り返ると、GoogleのBeyondCorpが社内VPNの置き換えとして2010年代前半に公開知見を蓄積しました⁴。米国政府はCISAのZero Trust Maturity Model 2.0で成熟度を段階化し、連邦機関に移行を求めています⁵。エンタープライズでもSaaS化とクラウド移行により、IDプロバイダが実質的なコントロールプレーンとなり、ゼロトラストはネットワーク再設計ではなく認証・認可と可観測性の再設計という意味合いを強めています⁷。近年はパスキー（FIDO2/WebAuthn）普及や短命トークン運用、データ中心の保護（DLP/DSPM）へのシフトが進み、実装の選択肢も成熟してきました。

なぜ今、境界では守れないのか

攻撃はフィッシングによるセッション乗っ取り、MFA疲労の悪用、ブラウザトークンの窃取など、レイヤ7の人とアプリを狙う形へとシフトしました⁶。インフォスティーラーによるCookie/トークン窃取や不正同意（OAuth consent phishing）はSSOの弱点を突き、IaaS内の東西移動はメッシュやサービス間認証が未整備な領域を突きます。SaaS間連携ではOAuth許可の過剰付与がリスクを増幅します。ゼロトラストはこの攻撃面に直接対応します。具体的には、パスワード依存を止めてFIDO2/パスキーを既定にする⁶、デバイス整合性と脆弱性状態をトークン発行条件に組み込む³、ワークロード間通信をmTLS（相互TLS）とポリシーで制御する³、データの機密度に応じてダウンロードやコピーの挙動を分ける⁵、といった制御を常時かつコンテキスト依存で行います。

アーキテクチャとコアコンポーネント

現実的な設計では、PDPはIdP、デバイス管理（MDM/MAM）、脅威シグナル、データ分類（DLP/DSPM）、権限管理（IAM/IGA）から入力を受け、ポリシーエンジンで意思決定します³。PEPはアイデンティティプロキシ、アプリゲートウェイ、サービスメッシュ、APIゲートウェイ、エンドポイントエージェントなどで実装され、PDPの決定を強制します。全体を貫くのはテレメトリと自動化で、SIEM/UEBA（ユーザー・エンティティ行動分析）で検知し、SOAR（運用自動化）またはワークフローで隔離や権限剥奪、再認証要求を即時に実行します⁵。パフォーマンスの観点では、設計目安としてポリシー評価はおおむね50ms以内、mTLSの再ハンドシェイクは1秒未満、条件付きアクセスの再評価間隔はユーザ体験を損なわない5〜15分程度を目安にし、ハイリスク検知時は即時トリガで上書きするのが実運用での落としどころです（実値はワークロードと実装に依存します）。

PDP/PEPとシグナル駆動の認可

意思決定の核は属性ベース認可（ABAC: Attribute-Based Access Control）とリスクスコアの組み合わせです³。ユーザ属性、所属、ロール、デバイス健全性、位置やネットワーク、行動異常、リソースの機密度を掛け合わせ、リクエスト単位で決定します。ポリシーは人が読める定義として管理し、Git管理とCIで検証・配布します（いわゆるGitOps）。インフラ側はサービス間通信にmTLSと短命トークンを用い、鍵はKMSとHSMで管理します。人の高権限は常設しない前提で、JIT（Just-In-Time）付与とセッション録画、承認フローの三点を基準化します。

Policy as Codeの具体例

アプリ側のゲートでコンテキストを評価する例として、OPA/Regoによる認可を示します。部門とデバイス整合性、データ分類に応じて操作を制限します。

package access

import future.keywords.if

default allow = false

# 入力例: {
#   "user": {"dept": "finance", "mfa": true},
#   "device": {"compliant": true},
#   "resource": {"classification": "confidential"},
#   "action": "download"
# }

allow if {
  input.user.mfa
  input.device.compliant
  input.user.dept == "finance"
  input.resource.classification == "internal"
  input.action == "download"
}

# 機密データは閲覧のみ許可
allow if {
  input.user.mfa
  input.device.compliant
  input.resource.classification == "confidential"
  input.action == "view"
}

サービス間通信の最小権限をIstioのAuthorizationPolicyで表現すると次のようになります。特定のサービスアカウントからのPOSTのみを許可し、mTLSとJWTの双方を前提にします。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: orders-allow-from-payments
  namespace: prod
spec:
  selector:
    matchLabels:
      app: orders
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["spiffe://cluster.local/ns/prod/sa/payments-sa"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/v1/settle"]
    when:
    - key: request.auth.claims["aud"]
      values: ["orders.api"]

IaaSやSaaSの権限はJSONで明示します。IAMポリシーの例では、読み出しに限定し、条件でリソースタグの整合性を求めます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::corp-data/*",
      "Condition": {
        "StringEquals": {"s3:ExistingObjectTag/classification": "internal"}
      }
    }
  ]
}

ユーザアクセスの連続評価はシグナル合成で実現します。簡略化した疑似コードでは、MFA、デバイス、行動のシグナルからリスクを算出し、閾値でステップアップ認証か隔離を選びます。

function riskScore(ctx) {
  let score = 0;
  if (!ctx.mfaStrong) score += 30;
  if (!ctx.device.compliant) score += 40;
  if (ctx.geo.anomalous) score += 20;
  if (ctx.login.velocity > 3) score += 15;
  return score;
}

function decide(ctx) {
  const r = riskScore(ctx);
  if (r >= 70) return "block";
  if (r >= 40) return "step-up";
  return "allow";
}

データ損失対策はコンテンツの機密度に応じた操作制御が鍵です。HTTPプロキシでのマスクやエクスポート抑止は、分類ラベルをポリシーに取り込み、クライアントでのコピーや印刷の許否まで含めて一貫管理します⁵（CASB/SSEと組み合わせるとSaaS面の可視化と制御が補完されます）。

導入ロードマップとROI

ロードマップは在庫の見える化から始まります。人・デバイス・アプリ・データの台帳を整え、アイデンティティを単一の制御面に収斂させます。ここでのポイントは、まずすべての人のサインオンをSSOに統合し、パスワードレスとフィッシング耐性MFA（FIDO2/パスキー）へ移行することです⁶。次に、会社管理デバイスは整合性チェック（MDM/EDR）を必須にし、BYODはブラウザ分離やアプリケーションプロキシ、ZTNAによる条件付きアクセスで分けて扱います。ネットワークはVPNを温存しつつも、社内からの特権は撤廃し、アプリ単位のプロキシ経由に切り替えます⁴。ワークロードについてはサービスメッシュでのmTLS強制と、名前空間やアカウント単位のマイクロセグメンテーションを先に行い、その上に認可ポリシーを重ねます³。最後にデータの分類を機密・社外秘・内部・公開のように粗くでも定義し、操作ルールを結びつけます⁵。順番を間違えると装飾的なダッシュボードだけが増え、実効性は上がりません。

90日間で着手する最小構成としては、コアSaaSのSSO統合とFIDO2の既定化、エンドポイントの基本姿勢チェック連携、管理対象外デバイスからの高リスク操作の抑止、代表的な社内アプリ一つのプロキシ化、クラウド内の一つの命名境界のmTLS強制までを範囲に置くと現実的です。6〜12カ月で、JITの特権付与と承認ワークフロー、サービス間のABAC拡充、データ分類に基づくDLPの適用、SIEM/UEBAとSOAR連携による自動隔離まで拡張すると、攻撃面の縮小とインシデント時の封じ込め力が目に見えて高まります⁵。レガシーについては、リフト＆シフトでゲートウェイ背後に収容し、認可は外だししつつ、アプリ自体の近代化計画と併走させるのが妥協点です。

ROIは三つの観点で可視化します。第一に回避コストで、フィッシング成功率の低下やセッション乗っ取りの遮断率、横展開の封じ込め時間短縮が該当します。例えば、MFA疲労対策とFIDO2導入でなりすましの成功率が低下し、平均検出時間が日単位から時間単位へ短縮できれば、それだけで重大インシデントの確率と影響範囲を同時に削れます。第二に運用コストで、VPNの同時接続と帯域の縮小、アクセス申請の処理時間短縮、監査証跡の自動化などが効いてきます。第三に生産性で、再認証の頻度最適化、SaaS間移動の摩擦低減、開発環境へのセルフサービス付与が寄与します。定量化する際は、月次で強制再認証の一人あたり回数、P1/P2インシデントのMTTD/MTTR、ゼロタッチ復旧の割合、承認に要する中央値、プロキシ遅延の95パーセンタイルといった指標を使います。実務では、認証遅延の95パーセンタイルを300ms以下、ポリシー配布のSLOを5分、リスク高検知から権限剥奪までを1分未満にする、といった目標を置くと意思決定がしやすくなります。

導入でつまずくのは、人とポリシーとテレメトリの三点です。人の側では、頻繁なポップアップや地点変化での再認証が反発を生みます。ここは信号に応じた再評価間隔の調整と、仕事の流れを止めない段階的なステップアップ認証で折り合いをつけます。ポリシーは増える一方になりがちですが、リソースタイプごとに共通ガードレールと例外の二層に分け、命名規則と所有権を明確にします。テレメトリは収集し過ぎて見ない問題が起きがちです。ゼロトラストに本当に必要な信号、例えば認証イベント、トークン再利用、OS整合性、脆弱性重大度、データ分類の変更、メッシュでのDENYログなどに絞り、ダッシュボードは運用アクションと1対1で結びつけると機能します。

まとめ

ゼロトラストは導入した瞬間に完成する製品ではなく、環境に合わせて継続的に磨く設計原則です³。だからこそ、最初の一歩は小さくても構いません。社内で最も影響が大きいSaaSのパスワードレス化と、代表的ワークロードのmTLS化から着手し、意思決定の核となるポリシーをコードとして管理し始めるだけで、攻撃面は確実に縮みます。次にどの信号を足すか、どの権限をJIT化するか、どのセグメントを細かく切るかを、指標に基づいて一つずつ進めましょう。いまのチーム構成とツールの組み合わせで、90日後にどの指標がどれだけ改善していると理想かを言語化できれば、移行の推進力は手に入っています。あなたの組織にとっての信頼の単位を定義し直すこと、それがゼロトラストの核心です。

参考文献

1. Verizon. 2024 Data Breach Investigations Report (DBIR) — EMEA summary. https://www.verizon.com/about/news/2024-data-breach-investigations-report-emea
2. IBM Newsroom. Cost of a Data Breach Report 2023. https://it.newsroom.ibm.com/CODB2023
3. NIST Special Publication 800-207: Zero Trust Architecture (Final). https://csrc.nist.gov/pubs/sp/800/207/final
4. Google Cloud Blog. How to use BeyondCorp to ditch your VPN, improve security, and go cloud. https://cloud.google.com/blog/topics/inside-google-cloud/how-use-beyondcorp-ditch-your-vpn-improve-security-and-go-cloud
5. CISA. Zero Trust Maturity Model Version 2 (2023). https://www.cisa.gov/news-events/alerts/2023/04/11/cisa-releases-zero-trust-maturity-model-version-2
6. Microsoft Tech Community (Microsoft Entra Blog). Defend your users from MFA fatigue attacks. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/defend-your-users-from-mfa-fatigue-attacks/2365677
7. ArXiv. Identity has emerged as the new perimeter in Zero Trust (v1, 2025). https://arxiv.org/html/2504.17759v1
8. 内閣官房IT総合戦略室（CIOポータル）. ゼロトラストの考え方と政府情報システムへの適用（dp2020_03）. https://cio.go.jp/dp2020_03/
9. IIJ. ゼロトラストとは（特集ページ）. https://www.iij.ad.jp/svcsol/focus/theme/zerotrust/