ストーリー

セキュリティ要件の構造

機能要件と非機能要件

セキュリティ要件の記述テンプレート

security_requirement:
  id: "SEC-AUTH-001"
  category: "認証"
  title: "API認証の必須化"
  description: |
    すべてのAPIエンドポイント（/healthを除く）で
    JWT Bearer トークンによる認証を必須とする
  threat_ref: "STRIDE-S-001"  # 対応する脅威ID
  priority: "Critical"
  acceptance_criteria:
    - "未認証リクエストに対して HTTP 401 を返す"
    - "期限切れトークンに対して HTTP 401 を返す"
    - "不正な署名のトークンに対して HTTP 401 を返す"
  verification_method: "自動テスト（DAST + 単体テスト）"
  compliance_ref: "PCI-DSS 8.3"

要件カテゴリ別の定義

1. 認証要件

2. 認可要件

3. データ保護要件

4. ログ・監査要件

5. 入力検証要件

脅威から要件への変換プロセス

STRIDE → 要件マッピング

脅威分析結果 → セキュリティ要件への変換:

[S] なりすまし脅威
    │
    ├── 脅威: 攻撃者が正規ユーザーのセッションを乗っ取る
    │   └── 要件: SEC-AUTH-005（セッションタイムアウト）
    │         SEC-AUTH-002（MFA導入）
    │
    └── 脅威: APIキーの漏洩による不正アクセス
        └── 要件: SEC-AUTH-001（JWT認証必須化）
              SEC-DATA-001（TLS暗号化）

[T] 改ざん脅威
    │
    ├── 脅威: リクエストパラメータの改ざん
    │   └── 要件: SEC-INPUT-001（入力バリデーション）
    │         SEC-AUTHZ-002（リソースレベル権限チェック）
    │
    └── 脅威: ログの改ざんによる証拠隠滅
        └── 要件: SEC-LOG-003（ログ改ざん防止）

[I] 情報漏洩脅威
    │
    ├── 脅威: APIレスポンスに不要な情報が含まれる
    │   └── 要件: SEC-DATA-003（PIIマスキング）
    │
    └── 脅威: エラーメッセージによる内部情報の漏洩
        └── 要件: SEC-INPUT-001 + カスタムエラーハンドリング

セキュリティ要件の優先順位付け

リスクベースの優先順位付け

要件トレーサビリティマトリクス

脅威 ──→ 要件 ──→ 設計 ──→ 実装 ──→ テスト

STRIDE-S-001 ──→ SEC-AUTH-001 ──→ JWT Middleware ──→ auth.ts ──→ auth.test.ts
STRIDE-I-003 ──→ SEC-DATA-003 ──→ PII Filter    ──→ filter.ts ──→ filter.test.ts
STRIDE-T-002 ──→ SEC-LOG-003  ──→ Immutable Log ──→ logger.ts ──→ log.test.ts

「要件のトレーサビリティは監査のためだけではない。なぜこのコードが存在するのか、どの脅威への対策なのかを全員が理解するための仕組みだ」 — 田中VPoE

まとめ

チェックリスト

• セキュリティ要件の記述テンプレートを理解した
• 5つの要件カテゴリの代表的な要件を把握した
• STRIDE脅威から要件への変換プロセスを理解した
• 要件の優先順位付け基準を理解した

次のステップへ

次は「コンプライアンスマッピング」を学びます。セキュリティ要件を各種規制・基準にマッピングする方法を身につけましょう。

推定読了時間: 30分