システム調達・システム開発におけるセキュリティ確保
この領域で問われること
システム調達とシステム開発の両方で、セキュリティ要求を仕様に落とし込み、契約と検証で担保するプロセスが問われる。調達仕様書、契約条項、開発ライフサイクル上の活動、受入時の確認が主な論点である。
調達時の統制
- 情報セキュリティ要求事項を調達仕様書に明記する。機能要件だけでなく、ログ取得、暗号化、脆弱性対応、テストの実施も要求する。
- 契約には秘密保持、再委託の事前承認、監査権、脆弱性の修正責任、インシデントの報告義務、契約終了時のデータ返却と消去を盛り込む。
- 委託先の選定ではISMS認証や過去の実績を確認する。クラウドでは責任分界点を文書で明確にする。
開発時のセキュリティ確保
- 要件定義で脅威分析を行い、設計で入力検証、最小権限、多層防御などのセキュア設計を採用する。
- 実装ではコードレビューと静的解析、テストでは動的診断と受入テストを実施する。見つかった脆弱性は修正後に再テストする。
- 開発環境と本番環境の分離、テストデータに本番の個人情報を使わないことも要求する。
例題で確認
委託開発の契約で、仕様書に「SQLインジェクション対策としてプレースホルダを使用する」「受入前に第三者による脆弱性診断を実施する」と明記する。契約書には再委託の事前承認と、インシデント発生から24時間以内の報告を定める。検収では診断結果と修正報告を確認する。責任分界を曖昧にしたまま検収すると、運用後の脆弱性対応の責任が争いになる。
失点しやすい点
セキュリティ要件を非機能要件として後回しにしない。診断をリリース直前の一度だけにしない。契約に監査権や再委託管理がない例は不備である。受入テストで機能だけを確認し、セキュリティ確認を省く記述も誤りである。