エピローグ — セキュリティは旅である

# セキュリティチャンピオンの役割（各チームに1人）
# - セキュリティ要件のレビュー
# - 脆弱性情報の共有
# - セキュリティトレーニングの実施

## PRレビュー セキュリティチェックリスト
 
### 認証・認可
- [ ] エンドポイントに適切な認証が設定されているか
- [ ] 権限チェックが実装されているか
- [ ] 他ユーザーのデータにアクセスできないか
 
### 入力バリデーション
- [ ] すべての入力がバリデーションされているか
- [ ] Strong Parametersが使われているか
- [ ] SQLプレースホルダーが使われているか
 
### データ管理
- [ ] 機密データが適切に暗号化されているか
- [ ] ログに機密情報が含まれていないか
- [ ] エラーメッセージが過剰な情報を開示していないか
 
### 依存関係
- [ ] 新しいgemのセキュリティ評価をしたか
- [ ] 既知の脆弱性を持つバージョンを使っていないか

## インシデント対応フロー
 
### Phase 1: 検知・初期対応（〜30分）
1. アラートを受信し、重大度を判定
2. インシデント対応チームを召集
3. 影響範囲の初期評価
4. 必要であればサービスの一部停止を検討
 
### Phase 2: 封じ込め（30分〜2時間）
1. 攻撃ベクトルの特定
2. 攻撃者のアクセスを遮断
   - 対象IPをWAFでブロック
   - 影響を受けたアカウントのセッションを失効
   - APIキーのローテーション（必要に応じて）
3. フォレンジック用にログを保全
 
### Phase 3: 調査・根本原因分析（2時間〜1日）
1. 攻撃ログの全量調査
2. 影響を受けたデータの特定
3. 脆弱性の根本原因の特定
 
### Phase 4: 修復・復旧（1日〜1週間）
1. 脆弱性の修正
2. セキュリティパッチの適用
3. システムの完全性確認
4. サービスの段階的な復旧
 
### Phase 5: ポストモーテム（1週間後）
1. 何が起きたかのタイムライン作成
2. なぜ起きたかの根本原因分析
3. 再発防止策の策定
4. 関係者への報告
 
### 通知の判断基準
- 個人情報への影響: 即時に当局・当事者に通知（法的義務）
- ビジネスデータの影響: 影響を受けた顧客に48時間以内に通知
- 内部システムのみ: 内部報告のみ

- [ ] エンドポイントに認証が必要か検討した（公開APIか否か）
- [ ] 適切な認証方法を選択した（JWT/APIキー/OAuth）
- [ ] リソースオーナーの確認を実装した（他ユーザーのデータへのアクセス防止）
- [ ] 必要最小限のスコープ・権限のみ要求している

- [ ] すべての入力パラメータをバリデーションしている
- [ ] Strong Parametersで許可フィールドを制限している
- [ ] SQLはプレースホルダーを使っている
- [ ] ファイルアップロードのMIMEタイプを検証している

- [ ] 機密データは暗号化して保存している
- [ ] パスワードはBCryptでハッシュ化している
- [ ] ログに機密情報が含まれていない
- [ ] エラーメッセージが内部情報を漏洩していない

- [ ] HTTPS通信のみ許可している
- [ ] CORSが適切に設定されている
- [ ] セキュリティヘッダーを設定している

- [ ] レート制限を設定している
- [ ] 高コストな処理には追加の制限を設けている
- [ ] タイムアウトを適切に設定している

- [ ] 重要なイベントをセキュリティログに記録している
- [ ] エラーは適切にログに残している
- [ ] 監視・アラートの設定を更新している