ゼロトラスト 2025 - NIST SP 1800-35と19の実装パターン

NIST最新ガイダンス発表

2025年6月10日、NISTは「Implementing a Zero Trust Architecture (SP 1800-35)」を発表。4年間のプロジェクトで24社の業界パートナーと協力し、19の実装例を含む包括的なガイダンスです。

ゼロトラストの基本原則

「暗黙の信頼は一切与えない」

核心となる考え方

従来のセキュリティ:
  ネットワーク境界内 = 信頼
  境界外 = 不信頼

ゼロトラスト:
  すべてのアクセス = 検証が必要
  位置や所有権に関係なく認証・認可

NIST SP 800-207の定義

• ネットワーク上の位置に基づく暗黙の信頼を排除
• 資産やユーザーアカウントの所有権だけでは信頼しない
• リソースへのセッション確立前に認証・認可を実行
• リソース（資産、サービス、ワークフロー）の保護に焦点

ゼロトラストアーキテクチャの構成

核心コンポーネント

graph TB
    PE["Policy Engine<br/>ポリシーエンジン"]

    subgraph PDP["Policy Decision Point<br/>ポリシー決定ポイント"]
        subgraph PIP["Policy Information Points"]
            IP[Identity Provider]
            TI[Threat Intelligence]
            CD[Compliance Data]
            AL[Activity Logs]
        end
    end

    subgraph PEP["Policy Enforcement Point<br/>ポリシー実施ポイント"]
        E1[接続の有効化]
        E2[監視]
        E3[接続の終了]
    end

    TZ["Trust Zone<br/>リソース"]

    PE --> PDP
    PDP --> PEP
    PEP --> TZ

19の実装パターン

SP 1800-35では、商用ツールを使った19の具体的な構成例を提供。

主要な構成カテゴリ

実装例

継続的認証

# 継続的認証の概念コード
class ContinuousAuthentication:
    def __init__(self, policy_engine):
        self.policy_engine = policy_engine
        self.risk_threshold = 0.7

    async def evaluate_session(self, session):
        """
        セッション中も継続的にリスク評価
        """
        risk_signals = await self.collect_signals(session)

        risk_score = self.policy_engine.calculate_risk({
            "device_posture": risk_signals.device_health,
            "user_behavior": risk_signals.behavior_anomaly,
            "location": risk_signals.geo_anomaly,
            "time": risk_signals.time_anomaly,
            "network": risk_signals.network_risk
        })

        if risk_score > self.risk_threshold:
            return self.require_step_up_auth(session)

        return self.continue_session(session)

    def require_step_up_auth(self, session):
        """高リスク時の追加認証"""
        return {
            "action": "step_up",
            "methods": ["mfa", "biometric"],
            "reason": "Elevated risk detected"
        }

マイクロセグメンテーション

# Kubernetesネットワークポリシー例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-server-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
    - Egress

  ingress:
    # API Gatewayからのみ許可
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 8080

  egress:
    # データベースへのみ許可
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432

    # 外部通信を制限
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8

デバイスポスチャー検証

// デバイス健全性チェック
interface DevicePosture {
  osVersion: string;
  patchLevel: string;
  antivirus: {
    installed: boolean;
    updated: boolean;
  };
  encryption: {
    diskEncrypted: boolean;
    algorithm: string;
  };
  firewall: boolean;
  jailbroken: boolean;
}

function evaluateDevicePosture(posture: DevicePosture): {
  compliant: boolean;
  issues: string[];
} {
  const issues: string[] = [];

  // OSバージョンチェック
  if (!isRecentOS(posture.osVersion)) {
    issues.push("OS version is outdated");
  }

  // アンチウイルスチェック
  if (!posture.antivirus.installed || !posture.antivirus.updated) {
    issues.push("Antivirus not up to date");
  }

  // ディスク暗号化チェック
  if (!posture.encryption.diskEncrypted) {
    issues.push("Disk encryption required");
  }

  // ジェイルブレイク検出
  if (posture.jailbroken) {
    issues.push("Jailbroken/rooted device not allowed");
  }

  return {
    compliant: issues.length === 0,
    issues
  };
}

導入ステップ

NISTの推奨アプローチ

Phase 1: 評価
├── 現状のアーキテクチャ分析
├── 保護対象リソースの特定
├── アクセスパターンの把握
└── ギャップ分析

Phase 2: 計画
├── 優先順位付け
├── ツール選定
├── ポリシー設計
└── 移行計画策定

Phase 3: 実装
├── パイロット導入
├── 段階的展開
├── 監視体制構築
└── インシデント対応準備

Phase 4: 運用
├── 継続的モニタリング
├── ポリシー改善
├── 脅威対応
└── 定期的な見直し

専門家の声

「従来の保護からゼロトラストへの移行には多くの変更が必要です。誰が何のリソースに、なぜアクセスしているかを理解する必要があります。また、各組織のネットワーク環境は異なるため、すべてのZTAはカスタムビルドです。」 — Alper Kerman, NIST コンピュータサイエンティスト

CSFとSP 800-53との対応

SP 1800-35は以下との対応付けを提供:

• NIST Cybersecurity Framework (CSF)
• NIST SP 800-53r5（セキュリティコントロール）
• NISTクリティカルソフトウェアセキュリティ対策

今後の展望

量子暗号への移行

NISTは2030年までに従来の暗号（RSA、ECDSA）を非推奨とし、ポスト量子暗号への移行を義務付けることを発表。

# 暗号移行計画
crypto_migration:
  timeline:
    assessment: 2025
    pilot: 2026-2027
    migration: 2028-2029
    completion: 2030

  priorities:
    - key_exchange: Kyber
    - signatures: Dilithium
    - hash: SHA-3

参考リソース

参考: NIST - Implementing a Zero Trust Architecture

まとめ

2025年のNIST SP 1800-35は、ゼロトラストを概念から実装へ導く包括的なガイドです。19の具体的な構成例と24社の協力により、組織は自社環境に適したゼロトラストアーキテクチャを構築できるようになりました。「暗黙の信頼をゼロに」という原則のもと、段階的かつ計画的な導入を進めましょう。