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

ストーリー

あなた

従来のセキュリティは”城と堀”のモデルだった。ファイアウォールという城壁の中は安全、外は危険。でも…

あ

高橋アーキテクトが図を描き始めました。

高

高橋アーキテクト

クラウド、リモートワーク、マイクロサービス。もはや”城壁の中”と”外”の区別が曖昧になった。そこで生まれたのがゼロトラストだ

あなた

ゼロトラスト…何も信頼しないということですか？

あ

高

高橋アーキテクト

その通り。ネットワークの場所に関係なく、全てのアクセスを検証する。“Never Trust, Always Verify”が基本原則だ

従来型（境界型）セキュリティの限界

従来型：城と堀モデル
┌──────────────────────────────────┐
│  社内ネットワーク（信頼ゾーン）      │
│                                  │
│  ユーザー → サーバー → DB         │
│  （認証なしでアクセス可能）          │
│                                  │
└────────────┬─────────────────────┘
             │ ファイアウォール（堀）
             │
     インターネット（非信頼ゾーン）

限界となった理由

変化	影響
クラウド移行	リソースが社内ネットワーク外に
リモートワーク	ユーザーが社外からアクセス
マイクロサービス	サービス間通信の増加
内部犯行	社内にいるだけでは信頼できない
VPN突破	VPNが突破されると全てにアクセス可能

ゼロトラストの基本原則

3つの柱

原則	説明
Never Trust, Always Verify	全てのアクセスを常に検証する
Least Privilege Access	最小権限を動的に付与する
Assume Breach	侵害されている前提で設計する

// ゼロトラストの実装イメージ
interface ZeroTrustPolicy {
  // 1. 全リクエストで認証を検証
  verifyIdentity: (token: string) => Promise<Identity>;

  // 2. コンテキストに基づく認可（場所、時間、デバイス）
  evaluateAccess: (context: AccessContext) => Promise<AccessDecision>;

  // 3. 最小権限のアクセストークン発行
  grantMinimalAccess: (identity: Identity, resource: string) => Promise<Token>;

  // 4. 全アクセスのログ記録
  logAccess: (entry: AccessLog) => Promise<void>;
}

interface AccessContext {
  identity: Identity;
  resource: string;
  action: string;
  deviceTrust: "managed" | "unmanaged" | "unknown";
  location: string;
  time: Date;
  riskScore: number;
}

interface AccessDecision {
  allowed: boolean;
  reason: string;
  conditions?: {
    mfaRequired?: boolean;
    sessionDuration?: number; // 分
    dataAccess?: "full" | "limited" | "none";
  };
}

ゼロトラストのコンポーネント

1. アイデンティティプロバイダー（IdP）

// 統合的なアイデンティティ管理
interface IdentityProvider {
  // ユーザー認証
  authenticate(credentials: Credentials): Promise<Identity>;

  // MFA検証
  verifyMFA(userId: string, code: string): Promise<boolean>;

  // デバイス認証
  verifyDevice(deviceId: string): Promise<DeviceTrust>;

  // リスクベースの評価
  evaluateRisk(context: AccessContext): Promise<number>;
}

2. ポリシーエンジン

// コンテキストベースのアクセス制御ポリシー
const accessPolicies: Policy[] = [
  {
    name: "管理者APIアクセス",
    conditions: {
      role: "admin",
      deviceTrust: "managed",     // 管理端末のみ
      mfaVerified: true,          // MFA必須
      locationAllowed: ["office", "vpn"], // 許可された場所のみ
    },
    effect: "allow",
    resources: ["/api/admin/**"],
  },
  {
    name: "一般ユーザーアクセス",
    conditions: {
      role: "user",
      mfaVerified: true,
    },
    effect: "allow",
    resources: ["/api/users/me/**", "/api/orders/me/**"],
  },
  {
    name: "高リスクアクセスの制限",
    conditions: {
      riskScore: { gt: 70 },
    },
    effect: "deny",
    resources: ["/**"],
    action: "step-up-auth", // 追加認証を要求
  },
];

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

// サービス間通信のゼロトラスト
// 各サービスは独自のアイデンティティを持つ
interface ServiceIdentity {
  serviceId: string;
  certificate: string; // mTLS証明書
  allowedTargets: string[]; // 通信可能なサービス
}

const servicePermissions: Record<string, string[]> = {
  "order-service": ["user-service", "payment-service", "inventory-service"],
  "user-service": ["notification-service"],
  "payment-service": ["ledger-service"],
  // order-serviceからledger-serviceへの直接通信は不可
};

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

ステップ	内容
1. 資産の棚卸し	保護対象のリソース・データを特定
2. アイデンティティ基盤	IdP + MFA + SSO を整備
3. デバイス管理	管理端末と非管理端末を識別
4. ネットワークセグメント	マイクロセグメンテーション導入
5. ポリシーエンジン	コンテキストベースの認可を実装
6. 継続的な監視	全アクセスのログ収集と分析

まとめ

ポイント	内容
ゼロトラスト	全てのアクセスを常に検証する
3つの柱	Always Verify, Least Privilege, Assume Breach
コンポーネント	IdP, ポリシーエンジン, マイクロセグメンテーション
導入	段階的に資産の棚卸しから始める

チェックリスト

従来型セキュリティの限界を理解した
ゼロトラストの3つの柱を暗記した
コンテキストベースのアクセス制御を理解した
マイクロセグメンテーションの概念を把握した

次のステップへ

次は「RBAC/ABACの設計」を学びます。ゼロトラストの認可部分を、具体的な権限モデルとして設計する方法を身につけましょう。

推定読了時間: 30分