ストーリー

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

NexPayにおけるゼロトラストの原則

フィンテックプラットフォームでは、従来の境界防御モデル（ペリメーターセキュリティ）では不十分です。NexPayではゼロトラストの原則をすべてのレイヤーに適用します。

サービス間認証（mTLS）

# NexPay mTLS設計
service_mesh:
  type: "Istio"
  mtls_mode: "STRICT"

  # すべてのサービス間通信にmTLSを強制
  peer_authentication:
    - name: "default"
      namespace: "nexpay"
      mtls:
        mode: STRICT

  # 証明書管理
  certificate:
    provider: "AWS Private CA"
    rotation_interval: "24h"    # 24時間ごとに自動ローテーション
    key_size: 2048
    algorithm: "RSA"

  # 認可ポリシー
  authorization_policies:
    - name: "payment-to-account"
      from: "payment-service"
      to: "account-service"
      methods: ["POST /api/v1/debit", "POST /api/v1/credit"]

    - name: "investment-to-account"
      from: "investment-service"
      to: "account-service"
      methods: ["POST /api/v1/debit", "GET /api/v1/balance"]

「ゼロトラストで重要なのは”通信が内部ネットワーク上であっても信頼しない”という姿勢だ。特にフィンテックでは、内部犯行やラテラルムーブメントへの対策が規制で求められる」 — 佐藤CTO

PCI DSSスコープ最小化

CDEの設計

PCI DSS準拠のコストとリスクを最小化するには、カード会員データ環境（CDE）のスコープを極力小さくすることが最も重要な設計判断です。

NexPay PCI DSSスコープ設計:

┌─────────────────────────────────────────────────────────────┐
│  Non-CDE（PCI DSSスコープ外）                               │
│                                                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐      │
│  │ 送金     │ │ 投資     │ │ 通知     │ │ 分析     │      │
│  │ Service  │ │ Service  │ │ Service  │ │ Service  │      │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘      │
│       ↕ トークンのみ                                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Tokenization Gateway                               │   │
│  │  (PAN → Token変換。CDE外はトークンのみ使用)          │   │
│  └─────────────────────────────────────────────────────┘   │
│       ↕                                                     │
├─────────────────────────────────────────────────────────────┤
│  CDE（PCI DSSスコープ内 -- 最小化）                          │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌────────────┐  │  │
│  │  │ Card Vault  │  │ Payment     │  │ HSM        │  │  │
│  │  │ (カード情報 │  │ Processor   │  │ (鍵管理)   │  │  │
│  │  │  暗号化保管) │  │ (決済処理)  │  │            │  │  │
│  │  └─────────────┘  └─────────────┘  └────────────┘  │  │
│  │  独立VPC / 専用サブネット / 独立監査ログ              │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

トークン化戦略

// NexPayトークン化フロー
interface TokenizationDesign {
  // カード情報の入口: 最初のタッチポイントでトークン化
  entryPoint: {
    mobileApp: "SDK内でカード情報を暗号化 → Tokenization Gatewayに直送";
    merchantPOS: "P2PE対応端末 → カードネットワーク経由でトークン化";
    webForm: "PCI DSS準拠のiframe → Tokenization Gateway";
  };

  // トークンの種類
  tokenTypes: {
    paymentToken: {
      format: "tok_xxxxxxxxxxxx";
      scope: "単一トランザクション";
      ttl: "15分";
    };
    vaultToken: {
      format: "vault_xxxxxxxxxxxx";
      scope: "カード情報の永続参照";
      ttl: "カード有効期限まで";
    };
  };

  // CDE外のサービスはトークンのみ使用
  nonCdeServices: {
    transferService: "vault_tokenで残高引落を依頼";
    investmentService: "vault_tokenで投資口座入金を依頼";
    notificationService: "カード下4桁のみ参照（マスク済み）";
  };
}

暗号化設計

データの暗号化戦略

NexPayでは、データのライフサイクル全体を通じて暗号化を適用します。

鍵管理アーキテクチャ

# NexPay鍵管理設計
key_management:
  # 階層的な鍵構造
  hierarchy:
    master_key:
      storage: "AWS CloudHSM"
      type: "AES-256"
      rotation: "年次"
      access: "CDE内のPayment Processorのみ"

    data_encryption_key:
      storage: "AWS KMS (CMK)"
      type: "AES-256"
      rotation: "90日"
      access: "サービスごとに個別のCMK"

    transit_key:
      storage: "Istio Citadel"
      type: "RSA-2048 / ECDSA P-256"
      rotation: "24時間"
      access: "サービスメッシュ内自動管理"

  # サービス別の鍵割り当て
  per_service_keys:
    payment_service:
      kms_key: "arn:aws:kms:ap-northeast-1:xxx:key/payment-key"
      purpose: "決済トランザクションデータの暗号化"

    account_service:
      kms_key: "arn:aws:kms:ap-northeast-1:xxx:key/account-key"
      purpose: "口座情報・残高データの暗号化"

    user_service:
      kms_key: "arn:aws:kms:ap-northeast-1:xxx:key/user-key"
      purpose: "個人情報（PII）の暗号化"

Envelope Encryption（エンベロープ暗号化）

// NexPayにおけるEnvelope Encryptionの実装パターン
interface EnvelopeEncryption {
  // Step 1: KMSからデータキーを生成
  generateDataKey: {
    request: "KMS GenerateDataKey API";
    response: {
      plaintextKey: "メモリ上にのみ保持（ディスクに書かない）";
      encryptedKey: "暗号化済みデータキー（DBに保存）";
    };
  };

  // Step 2: データキーでデータを暗号化
  encrypt: {
    algorithm: "AES-256-GCM";
    input: "平文データ";
    output: "暗号化データ + IV + AuthTag";
  };

  // Step 3: 平文データキーを即座に破棄
  cleanup: "平文データキーをメモリから消去";

  // 保存形式
  storage: {
    encryptedData: "暗号化されたデータ本体";
    encryptedDataKey: "暗号化されたデータキー";
    iv: "初期化ベクトル";
    authTag: "認証タグ（改ざん検知用）";
    keyId: "使用したKMS CMKのARN";
  };
}

認証・認可設計

多層認証フロー

NexPay認証フロー:

[ユーザー] → [API Gateway] → [認証サービス] → [各サービス]
                  │                   │
                  │ (1) JWTの検証     │ (2) ユーザー認証
                  │ (3) Rate Limit    │ (4) MFA検証
                  │ (5) IP/Geo制限    │ (6) リスクベース認証
                  ▼                   ▼
             WAF/DDoS対策       Cognito + カスタム認証

認証レベル:
  Level 1: PIN/パスワード     → 残高照会、取引履歴
  Level 2: + 生体認証         → 決済（5万円未満）
  Level 3: + SMS OTP          → 送金、高額決済（5万円以上）
  Level 4: + デバイス認証     → 投資取引、口座設定変更

JWTトークン設計

// NexPay JWTペイロード設計
interface NexPayJwtPayload {
  // 標準クレーム
  sub: string;         // ユーザーID (UUID)
  iss: "nexpay.auth";  // 発行者
  aud: string[];       // 対象サービス ["payment", "transfer"]
  exp: number;         // 有効期限（アクセストークン: 15分）
  iat: number;         // 発行時刻
  jti: string;         // トークンID（リプレイ攻撃防止）

  // NexPayカスタムクレーム
  auth_level: 1 | 2 | 3 | 4;  // 認証レベル
  kyc_status: "verified" | "pending" | "rejected";
  permissions: string[];        // ["payment:create", "transfer:send"]
  device_id: string;            // 認証済みデバイスID
  risk_score: number;           // リスクスコア（0-100）
}

// トークン設計
interface TokenDesign {
  accessToken: {
    ttl: "15分";
    algorithm: "RS256";
    keyRotation: "7日";
  };
  refreshToken: {
    ttl: "30日";
    storage: "Secure Cookie (HttpOnly, SameSite=Strict)";
    rotation: "使用時にリフレッシュトークンも更新（Rotation）";
  };
}

不正検知とリアルタイム監視

不正検知アーキテクチャ

不正検知フロー:

[決済リクエスト]
      │
      ▼
┌──────────────────┐
│ ルールエンジン    │ ← 即座に判定（< 50ms）
│ (リアルタイム)    │   - 短時間での連続決済
│                  │   - 通常と異なる地域
│                  │   - 高額取引閾値超過
└──────┬───────────┘
       │
       ├─ PASS → 決済実行
       ├─ BLOCK → 即座にブロック + アラート
       └─ REVIEW → 決済保留 + 人的レビューキュー
              │
              ▼
       ┌──────────────────┐
       │ MLモデル          │ ← 非同期でスコアリング
       │ (バッチ/ストリーム) │   - 行動パターン分析
       │                  │   - アノマリー検出
       └──────────────────┘

セキュリティ監査ログ

PCI DSS要件に基づくログ設計

# 監査ログ設計
audit_log:
  # PCI DSS Requirement 10: ログ記録と監視
  required_events:
    - "ユーザー認証（成功/失敗）"
    - "カード会員データへのアクセス"
    - "権限変更"
    - "システム設定変更"
    - "監査ログへのアクセス"

  # ログ形式
  format:
    who: "ユーザーID / サービスID / IPアドレス"
    what: "操作内容 / APIエンドポイント"
    when: "タイムスタンプ（UTC、ミリ秒精度）"
    where: "サービス名 / ホスト名 / リージョン"
    result: "成功 / 失敗 / エラーコード"
    target: "対象リソースID（トークン化済み）"

  # 保管要件
  retention:
    online: "90日（即座に検索可能）"
    archive: "1年間（4時間以内に復元可能）"
    cold: "7年間（法的保管義務）"

  # 改ざん防止
  integrity:
    method: "Write Once Read Many (WORM)"
    storage: "S3 Object Lock (Governance Mode)"
    hash_chain: "前のログエントリのハッシュを含むチェーン構造"

まとめ

チェックリスト

• ゼロトラストの5原則とNexPayへの適用を理解した
• PCI DSSスコープ最小化の戦略（トークン化、ネットワーク分離）を設計できた
• 暗号化戦略（At Rest / In Transit / In Use）を整理した
• 鍵管理の階層構造とローテーション方針を設計した
• 認証レベルと不正検知のアーキテクチャを理解した

次のステップへ

次は「可観測性と運用設計」に進みます。NexPayの決済フロー全体を可視化するための分散トレーシングとSLI/SLOを設計しましょう。

推定読了時間: 40分