ストーリー
佐
佐藤CTO
前のステップで脅威を分析する方法を学んだ。次は守り方の哲学を変えよう
佐藤CTOがホワイトボードに城の絵を描き、それに大きくバツ印をつけました。
佐
佐藤CTO
従来のセキュリティは城壁モデルだった。内部は安全、外部は危険。でもクラウド、リモートワーク、マイクロサービスの時代に、この考え方はもう通用しない
あなた
内部にいるから安全とは限らない、ということですか?
あ
佐
佐藤CTO
その通り。Never Trust, Always Verify — 全てのアクセスを検証する。これがゼロトラストだ
従来の境界防御モデルの限界
城壁モデル(Perimeter Security)
graph LR
External["外部(危険)"]
External -->|ファイアウォール| Internal
subgraph Internal["信頼されたネットワーク(内部 = 安全)"]
Servers["社内サーバー群<br/>- DB<br/>- アプリケーション<br/>- ファイルサーバー"]
end
classDef external fill:#e94560,stroke:#c23050,color:#fff
classDef internal fill:#198754,stroke:#146c43,color:#fff
classDef server fill:#0d6efd,stroke:#0a58ca,color:#fff
class External external
class Internal internal
class Servers server
| 問題点 | 説明 |
|---|
| 内部脅威に無防備 | 一度内部に入れば自由にアクセス可能 |
| ラテラルムーブメント | 侵入後に横方向に移動し被害拡大 |
| リモートワーク非対応 | VPN経由で全アクセスを許可する必要 |
| クラウド非対応 | データが社外に分散し境界が曖昧 |
| BYOD非対応 | 個人デバイスの信頼性を保証できない |
ゼロトラストの基本原則
NIST SP 800-207: Zero Trust Architecture
NIST(米国国立標準技術研究所)が2020年に発行したゼロトラストアーキテクチャの標準です。
| 原則 | 説明 |
|---|
| 全てのリソースはリソースとみなす | デバイス、サービス、データ全て |
| 全ての通信は安全でない前提 | ネットワークの場所に関係なく暗号化・検証 |
| リソースへのアクセスはセッション単位 | リクエストごとに認証・認可 |
| アクセスはポリシーによって決定 | ユーザー属性、デバイス状態、振る舞いを評価 |
| 全てのリソースの整合性を監視 | 継続的なモニタリングと評価 |
| 認証・認可は動的に実施 | 静的なルールではなくコンテキストベース |
| データ収集と改善 | セキュリティ体制を継続的に改善 |
ゼロトラストの3つの柱
graph TD
Title["ゼロトラストアーキテクチャ"]
Title --- Identity["アイデンティティ<br/>・強力な認証<br/>・MFA<br/>・SSO<br/>・条件付きアクセス"]
Title --- Device["デバイス<br/>・デバイス登録<br/>・コンプライアンスチェック<br/>・MDM/EDR"]
Title --- Network["ネットワーク<br/>・マイクロセグメント<br/>・暗号化<br/>・最小アクセス<br/>・東西トラフィック制御"]
Title --- App["アプリケーション<br/>・アクセス制御<br/>・API保護<br/>・WAF<br/>・シャドーIT検出"]
Title --- Data["データ<br/>・分類とラベリング<br/>・暗号化<br/>・DLP<br/>・権限管理"]
Title --- Visibility["可視化と分析<br/>・ログの集約<br/>・異常検知<br/>・SIEM<br/>・SOAR"]
classDef title fill:#1a1a2e,stroke:#e94560,color:#fff
classDef pillar fill:#0f3460,stroke:#16213e,color:#fff
class Title title
class Identity,Device,Network,App,Data,Visibility pillar
BeyondCorp — Googleのゼロトラスト実装
BeyondCorpは、GoogleがVPNを廃止し全社員のアクセスをゼロトラストベースに移行したプロジェクトです。
BeyondCorpの仕組み
graph TD
User["ユーザー<br/>(どこからでも)"] --> Proxy["Access Proxy<br/>(Identity-Aware Proxy)"]
Proxy --> App["アプリケーション<br/>(社内リソース)"]
Proxy --> ACE["Access Control Engine<br/>・ユーザー認証<br/>・デバイス信頼度<br/>・アクセスレベル<br/>・コンテキスト"]
classDef user fill:#6c757d,stroke:#495057,color:#fff
classDef proxy fill:#0d6efd,stroke:#0a58ca,color:#fff
classDef app fill:#198754,stroke:#146c43,color:#fff
classDef engine fill:#e94560,stroke:#c23050,color:#fff
class User user
class Proxy proxy
class App app
class ACE engine
| コンポーネント | 役割 |
|---|
| Access Proxy | 全てのアクセスの単一入口点(VPN不要) |
| Device Inventory | 全デバイスの登録・管理 |
| Trust Engine | ユーザーとデバイスの信頼度をスコアリング |
| Access Policy | コンテキストに基づくアクセス制御 |
従来モデルとの比較
| 観点 | 従来(VPN + 境界防御) | BeyondCorp(ゼロトラスト) |
|---|
| ネットワーク | 社内 = 信頼済み | ネットワーク位置は無関係 |
| 認証 | VPN接続 + ID/PW | MFA + デバイス証明書 |
| 認可 | ネットワークセグメント | リソースごとのポリシー |
| デバイス | 社用PCのみ | 信頼度スコアで判定 |
| リモートアクセス | VPN必須 | どこからでも同じ方法 |
ゼロトラストの実装パターン
パターン1: Identity-Aware Proxy(IAP)
// Identity-Aware Proxy の概念実装
import express from 'express';
import { OAuth2Client } from 'google-auth-library';
interface AccessContext {
userId: string;
email: string;
deviceId: string;
deviceTrustLevel: 'high' | 'medium' | 'low' | 'untrusted';
ipAddress: string;
location: string;
riskScore: number;
}
interface AccessPolicy {
resource: string;
requiredTrustLevel: AccessContext['deviceTrustLevel'];
requiredRoles: string[];
allowedLocations?: string[];
maxRiskScore: number;
mfaRequired: boolean;
}
function evaluateAccess(context: AccessContext, policy: AccessPolicy): boolean {
const trustLevels = { high: 3, medium: 2, low: 1, untrusted: 0 };
// デバイス信頼度チェック
if (trustLevels[context.deviceTrustLevel] < trustLevels[policy.requiredTrustLevel]) {
return false;
}
// リスクスコアチェック
if (context.riskScore > policy.maxRiskScore) {
return false;
}
// 場所制限チェック
if (policy.allowedLocations && !policy.allowedLocations.includes(context.location)) {
return false;
}
return true;
}
// ゼロトラストミドルウェア
function zeroTrustMiddleware(policy: AccessPolicy) {
return async (req: express.Request, res: express.Response, next: express.NextFunction) => {
const context: AccessContext = {
userId: req.user!.id,
email: req.user!.email,
deviceId: req.headers['x-device-id'] as string,
deviceTrustLevel: await getDeviceTrustLevel(req.headers['x-device-id'] as string),
ipAddress: req.ip!,
location: await geolocate(req.ip!),
riskScore: await calculateRiskScore(req),
};
if (!evaluateAccess(context, policy)) {
securityLogger.warn('ACCESS_DENIED', { context, policy: policy.resource });
return res.status(403).json({
error: 'Access denied',
reason: 'Device trust level or risk score does not meet policy requirements',
});
}
next();
};
}
パターン2: マイクロセグメンテーション
# Kubernetes NetworkPolicy によるマイクロセグメンテーション
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: order-service-policy
namespace: production
spec:
podSelector:
matchLabels:
app: order-service
policyTypes:
- Ingress
- Egress
ingress:
# API Gatewayからのみ受信を許可
- from:
- podSelector:
matchLabels:
app: api-gateway
ports:
- protocol: TCP
port: 8080
egress:
# 注文DBへの接続のみ許可
- to:
- podSelector:
matchLabels:
app: order-database
ports:
- protocol: TCP
port: 5432
# 決済サービスへの接続を許可
- to:
- podSelector:
matchLabels:
app: payment-service
ports:
- protocol: TCP
port: 8080
# DNS解決を許可
- to:
- namespaceSelector: {}
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
ゼロトラスト成熟度モデル
CISA(米国サイバーセキュリティ・インフラストラクチャセキュリティ庁)が公開するゼロトラスト成熟度モデルです。
| レベル | 名称 | 特徴 |
|---|
| Level 1 | Traditional | 境界防御中心、静的なアクセス制御 |
| Level 2 | Initial | 一部のリソースでIDベースのアクセス制御を導入 |
| Level 3 | Advanced | 自動化されたポリシー適用、デバイス信頼度の評価 |
| Level 4 | Optimal | コンテキストベースの動的認可、AIによる異常検知 |
各レベルの具体的な対策
// ゼロトラスト成熟度の自己評価チェックリスト
interface ZeroTrustMaturityAssessment {
identity: {
mfaEnabled: boolean; // Level 2+
ssoImplemented: boolean; // Level 2+
conditionalAccess: boolean; // Level 3+
continuousVerification: boolean; // Level 4
passwordless: boolean; // Level 4
};
device: {
inventoryManaged: boolean; // Level 2+
complianceChecked: boolean; // Level 3+
edrDeployed: boolean; // Level 3+
trustScoring: boolean; // Level 4
autoRemediation: boolean; // Level 4
};
network: {
encryptionInTransit: boolean; // Level 2+
microSegmentation: boolean; // Level 3+
sdnImplemented: boolean; // Level 3+
dynamicPolicies: boolean; // Level 4
};
application: {
apiGateway: boolean; // Level 2+
wafDeployed: boolean; // Level 2+
runtimeProtection: boolean; // Level 3+
adaptiveAccess: boolean; // Level 4
};
data: {
classificationDefined: boolean; // Level 2+
encryptionAtRest: boolean; // Level 2+
dlpImplemented: boolean; // Level 3+
automaticLabeling: boolean; // Level 4
};
}
ゼロトラスト導入のロードマップ
段階的な導入計画例
Phase 1: 基盤整備(1-3ヶ月)
| タスク | 説明 |
|---|
| 資産のインベントリ作成 | 全てのユーザー、デバイス、アプリケーション、データを棚卸し |
| IDプロバイダーの統合 | Azure AD / Okta / Auth0 で認証を一元化 |
| MFAの全社展開 | 全ユーザーに多要素認証を必須化 |
| ネットワーク可視化 | トラフィックフローの把握と分析 |
Phase 2: コア実装(3-6ヶ月)
| タスク | 説明 |
|---|
| IAP(Identity-Aware Proxy)導入 | 主要アプリケーションへのアクセスをIAP経由に |
| デバイス管理の強化 | MDM/EDR導入、コンプライアンスチェック |
| マイクロセグメンテーション | 重要システム間のネットワーク分離 |
| データ分類とラベリング | 機密データの特定と分類 |
Phase 3: 最適化(6-12ヶ月)
| タスク | 説明 |
|---|
| 条件付きアクセスポリシー | コンテキストに基づく動的認可 |
| VPNの段階的廃止 | IAP経由のアクセスに完全移行 |
| SIEM/SOAR統合 | セキュリティイベントの集約と自動対応 |
| 継続的改善 | メトリクスに基づくポリシーの最適化 |
まとめ
| ポイント | 内容 |
|---|
| 従来モデルの限界 | 境界防御はクラウド・リモートワーク時代に不十分 |
| ゼロトラストの原則 | Never Trust, Always Verify — 全アクセスを検証 |
| NIST SP 800-207 | ゼロトラストの7つの原則を標準化 |
| BeyondCorp | Googleのゼロトラスト実装、VPNを廃止 |
| 成熟度モデル | Traditional → Initial → Advanced → Optimal の4段階 |
チェックリスト
次のステップへ
次は「認証・認可の設計」を学びます。ゼロトラストの中核となるアイデンティティ管理の具体的な実装方法を身につけましょう。
推定読了時間: 40分