🙆
セキュリティリスク（機密データの取り扱い、認証・認可）が考慮されているか？
セキュリティリスク（機密データの取り扱い、認証・認可）が考慮されているか？
背景・概要
セキュリティインシデントは信頼の喪失・損害賠償につながるため、設計段階から脅威モデルを意識した検討が不可欠
例
- 外部通信時のTLS強制、有効期限付き署名トークンの採用
- パスワード、トークン、秘密鍵はKMS/Secret Managerに保管
- ログに機密情報が出力されない設計
よくある失敗例
- クライアントに過剰な情報を返却（例：認証エラーの詳細）
- 認可がAPIレベルで適切に行われておらず、権限昇格が可能
- 平文でデータを保存 or 転送している
FAQ
Q. 社内システムだからセキュリティは甘くていい？
A. 今どきはゼロトラスト前提で設計すべき。内部からの漏洩も多いため、外部向けと同様の保護が必要
Q. どの程度まで暗号化すべき？
A. 機密性の高いデータ（個人情報、支払い情報など）は保存・転送時の双方で暗号化すべき
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🛡 非機能要件・運用
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion