─ ─ ─ ─ 信頼境界（外部） ─ ─ ─ ─
┌──────┐                                          ┌──────────┐
│ 患者  │──HTTPS──→┌───────────┐                   │ 決済     │
└──────┘          │ API       │──API Call──→       │ サービス  │
┌──────┐          │ Gateway   │                    │ (Stripe) │
│ 医師  │──HTTPS──→│           │                    └──────────┘
└──────┘          └─────┬─────┘
┌──────┐                │
│ 管理者 │──HTTPS──→     │
└──────┘     ─ ─ ─ ─ ─ ┼ ─ ─ ─ 信頼境界（内部） ─ ─ ─
                        │
               ┌────────▼─────────┐
               │ 認証サーバー       │
               └────────┬─────────┘
                        │
          ┌─────────────┼─────────────┐
          │             │             │
    ┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
    │ 予約API   │ │ 決済API   │ │ 通知      │
    │           │ │           │ │ サービス   │
    └─────┬─────┘ └─────┬─────┘ └───────────┘
          │             │
    ┌─────▼─────┐ ┌─────▼─────┐
    │ ユーザーDB │ │ 予約DB    │
    │ 診療記録DB │ └───────────┘
    └───────────┘

信頼境界:
- 外部境界: インターネット ↔ API Gateway
- 内部境界: API Gateway ↔ 内部サービス群
- データ境界: サービス ↔ データベース

ポイント：

• 信頼境界を3層で定義（外部、内部、データ）
• 外部エンティティと内部プロセスを明確に分離
• 決済サービスは外部エンティティとして扱う

予約APIプロセスのSTRIDE分析：

認証サーバーのSTRIDE分析：

診療記録DBのSTRIDE分析：

分析の根拠：

• 診療記録は医療情報（HIPAA対象）のため被害が最大
• IDORは再現性が高く、自動ツールで発見しやすい
• ブルートフォースはツールで自動化可能だが影響は個別ユーザー

SEC-DATA-001: 診療記録の暗号化

• カテゴリ: データ保護
• STRIDE: I（情報漏洩）
• DREADスコア: 7.4
• 受け入れ基準:
  • 診療記録はAES-256-GCMで暗号化して保存する
  • 暗号化キーはAWS KMSで管理する
  • 復号はアプリケーション経由でのみ可能
  • DBの直接参照では暗号文のみ表示される
• 優先度: Must

SEC-AUTHZ-001: 予約情報のアクセス制御

• カテゴリ: 認可
• STRIDE: I（情報漏洩）/ E（権限昇格）
• DREADスコア: 7.6
• 受け入れ基準:
  • 患者は自分の予約のみ閲覧・変更可能
  • 医師は自分に関連する予約のみ閲覧可能
  • 他の患者の予約IDでアクセスすると403エラー
  • 全APIエンドポイントで所有者チェックを実施
• 優先度: Must

SEC-AUTH-001: ブルートフォース対策

• カテゴリ: 認証
• STRIDE: S（なりすまし）
• DREADスコア: 7.0
• 受け入れ基準:
  • 5回連続失敗でアカウントを30分間ロック
  • IPベースのレートリミット（1分間に10回まで）
  • ログイン失敗を監査ログに記録
  • CAPTCHA（3回失敗後に表示）
• 優先度: Must

// 1. ゲートキーパーパターン：全リクエストの認証・認可チェック
const securityMiddleware = [
  rateLimiter({ windowMs: 60000, max: 60 }),
  helmet(),
  authenticate,
  auditLogger,
];

// 2. 入力バリデーションパイプライン
const appointmentSchema = z.object({
  doctorId: z.string().uuid(),
  date: z.string().datetime(),
  reason: z.string().min(1).max(500),
});

// 3. リソースの所有者チェック（IDORの防止）
const ownershipCheck = (resourceType: string) => {
  return async (req: Request, res: Response, next: NextFunction) => {
    const resource = await getResource(resourceType, req.params.id);
    if (!resource) return res.status(404).json({ error: "Not found" });

    const canAccess =
      resource.patientId === req.user.id ||
      resource.doctorId === req.user.id ||
      req.user.role === "admin";

    if (!canAccess) {
      return res.status(403).json({ error: "Forbidden" });
    }
    next();
  };
};

// 4. 診療記録の暗号化
const encryptMedicalRecord = (record: string, key: Buffer): string => {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv("aes-256-gcm", key, iv);
  const encrypted = Buffer.concat([
    cipher.update(record, "utf8"),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();
  return `${iv.toString("hex")}:${tag.toString("hex")}:${encrypted.toString("hex")}`;
};

適用パターンの対応：