はじめに
近年、システムに対するサイバー攻撃はますます高度化しており、情報漏えいやサービス停止といったセキュリティインシデントは企業活動に大きな影響を与えるようになっています。
実際にニュースでも、
- ランサムウェアによる業務停止
- 不正アクセスによる情報漏えい
- Webサイト改ざん
- クラウド設定ミスによる情報公開
などが頻繁に報じられています。
このようなリスクを防ぐためには、システム構築後に対策を考えるのではなく、要件定義の段階からセキュリティを非機能要件として整理しておくことが重要です。
IPA（情報処理推進機構）の「非機能要求グレード」では、セキュリティを重要な非機能要件の一つとして位置付けています。
非機能要求グレードがそもそも何か？については以下の記事にまとめています。
インフラ要件定義で役立つ「非機能要求グレード」とは？実務で感じたメリットと注意点
本記事では、非機能要求グレードにおけるセキュリティの考え方と、実際のインフラ要件定義で確認しておきたいポイントについて解説します。
セキュリティはシステム全体の安全性を確保するための要求
セキュリティとは、システムやデータを脅威から保護し、安全に利用できる状態を維持するための要求です。
一般的に情報セキュリティは、
- 機密性（Confidentiality）
- 完全性（Integrity）
- 可用性（Availability）
の「CIA」と呼ばれる3要素で説明されます。
例えば、
- 顧客情報が漏えいしないこと（機密性）
- データが改ざんされないこと（完全性）
- 必要なときに利用できること（可用性）
が求められます。
インフラエンジニアの立場では、ファイアウォールやアクセス制御などの技術的な対策に目が向きがちですが、本来のセキュリティはシステム全体の安全性を確保するための活動です。
そのため要件定義では、
「何を守るのか」
「どのレベルまで守るのか」
を最初に整理することが重要になります。
まずは前提条件や遵守すべきルールを確認する
セキュリティ要件を検討する際に最初に確認すべきなのが前提条件や制約条件です。
企業や業界によっては、
- 情報セキュリティポリシー
- 個人情報保護規程
- 業界ガイドライン
- 法令
などが定められている場合があります。
例えば、
金融業界であれば金融機関向けガイドライン、
公共分野であれば政府統一基準、
クレジットカード情報を扱う場合はPCI DSSなど、
遵守しなければならない基準が存在します。
実務ではセキュリティ対策をゼロから考えるのではなく、
「守るべきルールは何か」
を確認した上で要件を決定することが一般的です。
要件定義の初期段階でこれらを整理しておかないと、設計工程で大きな手戻りが発生する可能性があります。
セキュリティリスク分析で守るべき資産を明確にする
セキュリティ対策は多ければ多いほど良いわけではありません。
コストや運用負荷とのバランスを考慮する必要があります。
そのため重要になるのがセキュリティリスク分析です。
まずはシステムで扱う資産を洗い出します。
例えば、
- 顧客情報
- 社内機密情報
- 売上データ
- サーバ
- ストレージ
- ネットワーク機器
などです。
その上で、
- どのような脅威があるか
- 発生した場合の影響はどの程度か
- 対策は必要か
を整理していきます。
実際のプロジェクトでは、
「なぜその対策が必要なのか」
を説明できる状態にしておくことが重要です。
また、対策を実施しない場合は残存リスクについても関係者間で合意しておく必要があります。
アクセス制御とデータ保護はセキュリティの基本
セキュリティ要件の中でも特に重要なのがアクセス制御です。
どれだけ堅牢なシステムでも、不適切な権限設定が行われていれば情報漏えいにつながります。
要件定義では、
- 認証方式
- 権限管理
- アカウント管理
- 多要素認証の有無
などを整理します。
近年ではクラウド利用が増えているため、
- IAM設計
- 特権アカウント管理
- シングルサインオン
なども重要な検討項目になっています。
また、データ保護も重要です。
例えば、
- 通信経路の暗号化
- データベース暗号化
- バックアップデータ暗号化
などが挙げられます。
ただし暗号化はCPU負荷やレスポンス性能に影響する場合があります。
そのため、セキュリティだけでなく性能・拡張性とのバランスを考慮して設計する必要があります。
ログ管理と監視によって不正行為を検知する
セキュリティ対策では、
「侵入されないこと」
だけでなく、
「侵入されたことを検知できること」
も重要です。
そのため非機能要求グレードでは「不正追跡・監視」が定義されています。
要件定義では、
- どのログを取得するか
- どのくらい保存するか
- 誰が確認するか
を整理します。
例えば、
- ログイン履歴
- 操作履歴
- 管理者操作ログ
- ネットワーク通信ログ
などです。
最近ではSIEM製品やクラウドの監視サービスを利用してログを集中管理するケースも増えています。
一方でログ取得量が増えると、
- ストレージ容量の増加
- システム負荷の増加
- 運用コストの増加
につながります。
そのため、取得するログの範囲や保存期間を事前に整理しておくことが重要です。
ネットワーク対策・マルウェア対策・Web対策を整理する
セキュリティ対策はサーバだけでは完結しません。
ネットワークやエンドポイント、Webアプリケーションなど、さまざまな観点から対策を検討する必要があります。
ネットワーク対策では、
- ファイアウォール
- IDS／IPS
- VPN
- ネットワーク分離
などを検討します。
マルウェア対策では、
- ウイルス対策ソフト
- EDR
- メールフィルタリング
などが対象になります。
また、Webシステムの場合は、
- SQLインジェクション
- クロスサイトスクリプティング（XSS）
- CSRF
などの脆弱性対策も必要です。
近年はWAF（Web Application Firewall）を導入するケースも一般的になっています。
ただし、これらのセキュリティ製品はシステム性能へ影響を与えることがあります。
実務では、
「セキュリティを強化した結果レスポンスが悪化した」
というケースもあるため、性能要件との両立を考慮することが重要です。
セキュリティ診断とインシデント対応を忘れてはいけない
セキュリティ対策は導入して終わりではありません。
本当に対策が有効かどうかを確認する必要があります。
そのため要件定義では、
- 脆弱性診断
- ペネトレーションテスト
- ソースコード診断
などの実施有無を整理します。
また、運用開始後に新しい脆弱性が発見されることもあります。
そのため、
- セキュリティパッチ適用方針
- 緊急時の対応フロー
- 脆弱性情報の収集方法
についても決めておく必要があります。
さらに重要なのがインシデント対応です。
どれだけ対策を行っても、セキュリティ事故を100％防ぐことはできません。
だからこそ、
- 誰が対応するのか
- どこへ報告するのか
- どのように復旧するのか
を事前に決めておく必要があります。
実際のプロジェクトでは、インシデント対応手順や連絡体制の整備まで含めて検討しておくことが重要です。
まとめ
セキュリティは、情報システムを安全に利用するために欠かせない非機能要件です。
IPAの非機能要求グレードでは、
- 前提条件・制約条件
- セキュリティリスク分析
- セキュリティ診断
- セキュリティリスク管理
- アクセス・利用制限
- データの秘匿
- 不正追跡・監視
- ネットワーク対策
- マルウェア対策
- Web対策
- セキュリティインシデント対応／復旧
といった観点で整理されています。
実務では、ファイアウォールや暗号化といった個別の対策だけに注目しがちですが、本当に重要なのは「何を守るべきか」を明確にし、そのために必要な対策を適切なレベルで実施することです。
また、セキュリティ対策は性能や運用にも大きく影響するため、他の非機能要件とのバランスを考慮しながら検討する必要があります。
システムの安全性を確保するためにも、要件定義の段階からセキュリティを重要な非機能要件として整理し、関係者間でしっかり合意形成を行っていきましょう。
コメント