演習：セキュリティ要件定義書を作成しよう

ストーリー

田

田中VPoE

脅威分析、セキュリティ要件、コンプライアンスマッピング。理論は一通り学んだ。ここからは実践だ。実際の組織シナリオを使って、セキュリティ要件定義書を作成してもらう

あなた

具体的なシステムの情報が与えられるんですね

あ

田

田中VPoE

そうだ。BtoB SaaS企業が新しいマイクロサービスを立ち上げるシナリオだ。脅威モデリングからコンプライアンスマッピングまで、一気通貫で要件を定義してくれ

あなた

Step 1で学んだすべてを統合する演習ですね

あ

田

田中VPoE

経営層やセキュリティ監査で使える品質のドキュメントを目指してくれ。「なんとなく安全」ではなく「なぜ安全なのか」を説明できる要件書だ

ミッション概要

項目	内容
演習タイトル	セキュリティ要件定義書の作成
想定時間	60分
成果物	セキュリティ要件定義書（脅威分析 + 要件一覧 + コンプライアンスマッピング）
対象システム	決済連携マイクロサービス

前提条件

システムの概要

対象システム: PayConnect（決済連携マイクロサービス）

機能概要:
  - 複数の決済プロバイダ（Stripe, PayPay, 銀行振込）との連携
  - 請求書の自動生成・送付
  - サブスクリプション課金管理
  - 売上レポートの生成

技術スタック:
  - TypeScript / Node.js（NestJS）
  - PostgreSQL（RDS）
  - Redis（ElastiCache）
  - AWS Lambda + API Gateway
  - Docker / ECS Fargate
  - GitHub Actions（CI/CD）

データフロー:
  [ユーザー] → [API Gateway] → [PayConnect API] → [決済プロバイダAPI]
                                      │
                                      ├── [PostgreSQL] ← 顧客情報、取引履歴
                                      ├── [Redis] ← セッション、キャッシュ
                                      └── [S3] ← 請求書PDF

取り扱うデータ:
  - 顧客の氏名、メールアドレス、住所（PII）
  - クレジットカードのトークン（PCI-DSSスコープ）
  - 銀行口座情報
  - 取引履歴・売上データ
  - APIキー・シークレット

利用者:
  - エンドユーザー（顧客企業の管理者） -- 約3,000社
  - 社内管理者 -- 約20名
  - 社内開発者 -- 約10名
  - 外部パートナー（決済プロバイダ） -- 3社

組織のセキュリティ状況

項目	現状
セキュリティチーム	3名（マネージャー1名、エンジニア2名）
既存のセキュリティポリシー	基本的なセキュリティガイドラインあり
コンプライアンス要件	PCI-DSS Level 2 準拠が必要、SOC 2 Type II取得を目指している
過去のインシデント	APIキーのGitHub公開（半年前）、XSS脆弱性（1年前）
セキュリティテスト	年1回の外部ペネトレーションテスト

Mission 1: 脅威モデリングの実施

要件

PayConnectシステムに対して、STRIDEモデルを使った脅威モデリングを実施してください。

**データフロー図（DFD）**の信頼境界を特定する（最低3つ）
STRIDEの6カテゴリそれぞれに対して、最低1つの具体的な脅威を特定する
各脅威についてDREADスコアを算出し、優先順位を付ける

解答例

信頼境界

境界名	内側	外側
TB-1: インターネット境界	API Gateway	エンドユーザー
TB-2: アプリケーション境界	PayConnect API	API Gateway
TB-3: データ境界	PostgreSQL / Redis	PayConnect API
TB-4: 外部サービス境界	PayConnect API	決済プロバイダAPI

STRIDE脅威分析

ID	STRIDE	脅威	対象コンポーネント	DREAD (D/R/E/A/D)	スコア
T-S-001	Spoofing	攻撃者がAPIトークンを窃取し正規ユーザーとしてアクセス	API Gateway	8/7/6/8/5	6.8
T-T-001	Tampering	決済金額パラメータの改ざん	PayConnect API	9/6/5/7/4	6.2
T-R-001	Repudiation	取引の否認（「購入していない」と主張）	取引ログ	7/5/4/6/3	5.0
T-I-001	Info Disclosure	SQLインジェクションによる顧客PII漏洩	PostgreSQL	10/8/7/10/6	8.2
T-I-002	Info Disclosure	APIキーのログ出力による漏洩	ログシステム	8/9/3/5/7	6.4
T-D-001	DoS	API Gatewayへの大量リクエスト攻撃	API Gateway	6/9/8/8/8	7.8
T-E-001	Elevation	一般ユーザーが管理者APIにアクセス	PayConnect API	9/6/5/9/4	6.6

優先順位

優先度	脅威ID	スコア	対応期限
Critical	T-I-001	8.2	即時
High	T-D-001	7.8	1週間以内
High	T-S-001	6.8	2週間以内
High	T-E-001	6.6	2週間以内
Medium	T-I-002	6.4	1ヶ月以内
Medium	T-T-001	6.2	1ヶ月以内
Medium	T-R-001	5.0	次の四半期

Mission 2: セキュリティ要件の定義

要件

Mission 1で特定した脅威に基づいて、以下のセキュリティ要件を定義してください。

要件を5つのカテゴリ（認証、認可、データ保護、ログ・監査、入力検証）に分類する
各カテゴリから最低2つの要件を定義する（合計10件以上）
各要件に受け入れ基準と検証方法を明記する

解答例

認証要件

要件ID	要件	受け入れ基準	検証方法	脅威参照
SEC-AUTH-001	エンドユーザーAPIでOAuth 2.0 + JWTを必須化	未認証リクエストにHTTP 401を返す	DAST自動テスト	T-S-001
SEC-AUTH-002	管理者APIでMFAを必須化	MFA未設定の管理者は管理画面にアクセスできない	E2Eテスト	T-S-001, T-E-001
SEC-AUTH-003	APIキーのローテーション（90日ごと）	90日を超えたAPIキーは自動失効する	統合テスト	T-I-002

認可要件

要件ID	要件	受け入れ基準	検証方法	脅威参照
SEC-AUTHZ-001	リソースレベルのアクセス制御（テナント分離）	他テナントのデータにアクセスできない	DAST + 統合テスト	T-E-001
SEC-AUTHZ-002	管理者APIと一般ユーザーAPIの分離	一般ユーザーが管理者APIにアクセスするとHTTP 403	DAST自動テスト	T-E-001

データ保護要件

要件ID	要件	受け入れ基準	検証方法	脅威参照
SEC-DATA-001	通信の暗号化（TLS 1.2以上）	全通信がTLS 1.2以上で暗号化される	自動スキャン	T-I-001
SEC-DATA-002	カード情報のトークン化（PCI-DSS）	生のカード番号をシステムに保存しない	設計レビュー + コード監査	T-I-001
SEC-DATA-003	データベース保存データの暗号化（AES-256）	RDS暗号化が有効、KMSキー管理	IaCスキャン（checkov）	T-I-001

ログ・監査要件

要件ID	要件	受け入れ基準	検証方法	脅威参照
SEC-LOG-001	全取引の監査ログ記録	取引ID、ユーザーID、金額、タイムスタンプが記録される	ログ分析テスト	T-R-001
SEC-LOG-002	ログへのPII/シークレット出力の防止	APIキー、カード番号がログに出力されない	SAST + ログ監査	T-I-002

入力検証要件

要件ID	要件	受け入れ基準	検証方法	脅威参照
SEC-INPUT-001	パラメータ化クエリの使用	ORMのパラメータ化クエリを100%使用	SAST	T-I-001
SEC-INPUT-002	決済金額の整合性チェック	サーバーサイドで金額を再計算、クライアント値を信頼しない	単体テスト + 統合テスト	T-T-001
SEC-INPUT-003	APIレート制限の実装	1ユーザーあたり100req/min、超過時429を返す	DAST	T-D-001

Mission 3: コンプライアンスマッピング

要件

Mission 2で定義した要件を、PCI-DSSおよびSOC 2にマッピングしてください。

各要件に対応するPCI-DSSの要件番号を特定する
各要件に対応するSOC 2のTrust Services Criteriaを特定する
カバレッジ分析を行い、不足している領域を特定する

解答例

マッピング表

要件ID	要件内容	PCI-DSS	SOC 2
SEC-AUTH-001	OAuth 2.0 + JWT認証	8.3（認証メカニズム）	CC6.1（論理アクセス制御）
SEC-AUTH-002	管理者MFA	8.3.1（MFA）	CC6.1
SEC-AUTH-003	APIキーローテーション	8.2.4（認証情報の変更）	CC6.1
SEC-AUTHZ-001	テナント分離	7.1（アクセス制限）	CC6.3（ロールベースアクセス）
SEC-AUTHZ-002	API分離	7.1	CC6.3
SEC-DATA-001	TLS 1.2以上	4.1（暗号化通信）	CC6.7（暗号化）
SEC-DATA-002	カード情報トークン化	3.4（PANの保護）	CC6.7
SEC-DATA-003	データベース暗号化	3.4	CC6.7
SEC-LOG-001	取引監査ログ	10.2（監査証跡）	CC7.2（モニタリング）
SEC-LOG-002	PII/シークレット漏洩防止	10.5（ログの保護）	CC7.2
SEC-INPUT-001	パラメータ化クエリ	6.5.1（インジェクション防止）	CC7.1（脆弱性管理）
SEC-INPUT-002	金額整合性チェック	6.5（安全なコーディング）	CC7.1
SEC-INPUT-003	レート制限	6.6（Webアプリケーション保護）	CC7.1

カバレッジ分析

PCI-DSS要件	カバー状況	不足点
要件1: ネットワークセキュリティ	部分的	ファイアウォールルールの要件が未定義
要件2: セキュリティ設定	未カバー	デフォルト設定の変更に関する要件が必要
要件3: カードデータ保護	カバー済み	SEC-DATA-002, SEC-DATA-003
要件4: 暗号化通信	カバー済み	SEC-DATA-001
要件5: マルウェア対策	未カバー	コンテナセキュリティスキャンの要件が必要
要件6: 安全なシステム開発	カバー済み	SEC-INPUT-001/002/003
要件7: アクセス制限	カバー済み	SEC-AUTHZ-001/002
要件8: 認証	カバー済み	SEC-AUTH-001/002/003
要件9: 物理アクセス	N/A	クラウド環境のため対象外（PCI-DSS責任共有モデル）
要件10: ログと監視	カバー済み	SEC-LOG-001/002
要件11: テスト	部分的	ペネトレーションテストの定期実行要件が必要
要件12: セキュリティポリシー	未カバー	組織レベルのポリシー策定が必要

追加すべき要件

追加要件ID	要件内容	PCI-DSS	SOC 2
SEC-NET-001	セキュリティグループによるネットワーク分離	1.3	CC6.6
SEC-CONFIG-001	CIS Benchmarkに基づくセキュリティ設定	2.2	CC6.8
SEC-SCAN-001	コンテナイメージの脆弱性スキャン	5.1	CC7.1
SEC-TEST-001	四半期ごとのペネトレーションテスト	11.3	CC7.1

達成度チェック

観点	達成基準
脅威モデリング	STRIDEの6カテゴリすべてで脅威を特定し、DREADスコアで優先順位付けしている
信頼境界	データフローにおける信頼境界を3つ以上特定している
要件定義	5カテゴリで合計10件以上の要件を定義し、受け入れ基準と検証方法がある
コンプライアンス	PCI-DSSとSOC 2の両方にマッピングし、カバレッジ分析を実施している
実用性	監査やセキュリティレビューで使える品質のドキュメントになっている

推定所要時間: 60分