基幹刷新プロジェクトにおけるセキュリティ要件の整理

はじめに

基幹システム刷新プロジェクトでは、機能要件の検討に多くの時間が割かれる一方、セキュリティ要件は後回しにされたり、ベンダー側の提案に一任されたりしがちです。しかし、セキュリティ要件の整理不足は、本番稼働後に重大なインシデントや、監査・コンプライアンス上の問題として表面化するリスクがあります。基幹刷新プロジェクトにおけるセキュリティ要件の整理の仕方を整理します。

セキュリティ要件が後回しにされやすい理由

セキュリティ要件は、業務部門から「こういう機能が欲しい」と具体的に要望が上がってくる機能要件とは異なり、要件として明文化されにくい性質を持っています。「安全であること」は当然の前提として扱われ、誰も明示的に要件として挙げないまま要件定義が進んでしまうことがあります。その結果、セキュリティに関する検討が、開発の終盤やベンダーからの提案任せになり、発注側として本来確認すべき水準を満たしているかの検証が不十分なまま進んでしまうのです。

整理すべきセキュリティ要件の分類

セキュリティ要件は幅広い領域にまたがるため、カテゴリに分けて整理すると漏れを防ぎやすくなります。

① アクセス制御

誰がどの機能・データにアクセスできるかの権限設計です。特に基幹システムでは、人事異動や退職に伴う権限の見直しプロセスが適切に組み込まれているかが重要なポイントになります。

② データ保護

個人情報や機密性の高いデータの暗号化、バックアップ・復旧体制、データの保管場所に関する要件です。クラウド移行とオンプレミス、判断基準はどこにあるかで触れたとおり、保管場所の制約は、システム基盤の選定そのものにも影響します。

③ 監査ログ

誰が、いつ、何を行ったかを追跡できる監査ログの取得要件です。不正アクセスや誤操作が発生した際の原因究明だけでなく、内部統制の観点からも要件として明確にしておく必要があります。

④ インシデント対応体制

セキュリティインシデントが発生した際の検知・報告・対応のプロセスと体制です。システムの機能要件としてだけでなく、運用ルールとしても整理しておく必要があります。

非機能要件として明確に文書化する

セキュリティ要件は、機能要件とは別の「非機能要件」として明確に文書化し、要件定義書に組み込むことが重要です。要件定義ワークショップを成功させる進め方でも触れたとおり、非機能要件は機能要件以上に関係者間での認識合わせが難しい領域であり、専門的な知見を持つ担当者（情報システム部門のセキュリティ担当や、必要に応じて外部の専門家）を交えて整理することをおすすめします。

機能要件・非機能要件を漏れなく整理できるチェックリストは、noteで配布しています。セキュリティ要件を含む非機能要件の整理にそのまま活用いただけます。

検証のタイミングを計画に組み込む

セキュリティ要件は、要件定義で整理するだけでなく、設計・開発の各段階で要件通りに実装されているかを検証する必要があります。テスト計画の立て方｜品質を担保する3つの観点で触れた非機能面のテストに、セキュリティ要件の検証を明確に組み込んでおくことが重要です。

まとめ

セキュリティ要件は、機能要件に比べて後回しにされやすい領域ですが、本番稼働後の重大なリスクに直結します。アクセス制御・データ保護・監査ログ・インシデント対応体制という分類で整理し、非機能要件として明確に文書化したうえで、各段階での検証を計画に組み込むことが、基幹刷新プロジェクトにおけるセキュリティ要件整理の実務上のポイントです。

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。