1.6.4. セキュリティ要件の識別

1. 概要

　ソフトウェア開発において、セキュリティ要件の識別は非常に重要なプロセスです。この活動は、企業の情報セキュリティ方針に即したセキュリティ機能を適切に設計し、実装するための基盤となります。本記事では、セキュリティ要件の識別に関する設計原則や設計特性の選定、優先順位付けの活動と留意事項について解説します。

　セキュリティ要件を適切に識別し、優先順位をつけることで、効果的なセキュリティ実現方式を選択し、安全性対策や信頼性対策を適切に実装することができます。これにより、システムの脆弱性を最小限に抑え、潜在的な脅威からシステムを保護することが可能となります。

2. 詳細説明

2.1. セキュリティ要件の識別プロセス

　セキュリティ要件の識別プロセスは、以下の手順で進められます：

企業の情報セキュリティ方針の確認：まず、企業のセキュリティポリシーを確認し、その方針がシステムにどのように適用されるかを理解します。これには、企業内の法的義務や規制要件、内部統制の仕組みなどが含まれます。
システムの特性とリスクの分析：システムの使用環境や特性に基づいて、どのようなセキュリティリスクが存在するかを分析します。ここでは、脅威モデリングやリスクアセスメントを実施し、システムに対するリスクを具体的に特定します。
（下記、リスクアセスメントフローチャート参照）
セキュリティ要件の洗い出し：システムを脅威から保護するために必要なセキュリティ要件を明確にします。例えば、データ保護、アクセス制御、障害時のリカバリ能力などが含まれます。
設計原則の選定：セキュリティ要件に基づき、最も適切な設計原則を選定します。これにより、セキュリティ対策がシステムにどのように反映されるかが決まります。
設計特性の評価：設計したセキュリティ機能が、システムの要求を満たすかどうかを評価します。可用性や耐障害性など、システムの運用面も含めた包括的な評価が必要です。
優先順位付け：セキュリティ要件に優先順位を付け、最も重要な部分から実装していく計画を立てます。

graph TD
    A[開始] --> B[リスクの特定]
    B --> C[リスクの分析]
    C --> D[リスクの評価]
    D --> E{受容可能なリスク?}
    E -->|はい| F[リスクの受容]
    E -->|いいえ| G[リスク対応策の検討]
    G --> H[対応策の実施]
    H --> I[残留リスクの評価]
    I --> J{残留リスク許容可能?}
    J -->|はい| K[モニタリングと見直し]
    J -->|いいえ| G
    F --> K
    K --> L[終了]

　このフローチャートは、リスクアセスメントの基本的なプロセスを示しています。主な段階は以下の通りです：

リスクの特定
リスクの分析
リスクの評価
リスク対応の決定（受容または対策）
対応策の実施（必要な場合）
残留リスクの評価
モニタリングと見直し

　このフローチャートは、リスクアセスメントプロセスの反復的な性質を示しています。リスクが許容できないと判断された場合、プロセスは対応策の検討と実施に戻ります。

　また、モニタリングと見直しの段階は継続的なプロセスであり、新たなリスクの特定や既存のリスク評価の更新につながる可能性があります。

　このフローチャートは、リスクアセスメントの基本的な流れを理解するのに役立ちます。実際の適用においては、組織の特性や対象となるプロジェクトの性質に応じて、さらに詳細なステップや判断基準を追加することができます。

2.2. 設計原則

　セキュリティ要件を識別する際に考慮すべき主要な設計原則は以下の通りです：

最小限の原則：必要最小限の機能とアクセス権限のみを付与し、攻撃対象となる可能性を減らします。これにより、不必要な機能や過剰な権限が原因で発生するセキュリティリスクを低減できます。
多層防御：複数の防御層を設けることで、一つの層が破られても他の層で防御する設計原則です。これにより、単一の脆弱性がシステム全体に影響を及ぼすリスクを軽減します。
（下記、多層防御の構造図参照）
システムサービスへのアクセス制限：不要なサービスへのアクセスを制限し、攻撃の機会を減らすことがセキュリティ向上に直結します。例えば、使用されていないネットワークポートを閉じることが挙げられます。
システムへの攻撃にさらされる境界面の最小化及び防御：外部と接する部分を最小限に抑え、重点的に防御する設計です。システムの境界を明確にすることで、侵入可能な経路を制限できます。

2.3. 設計特性

　セキュリティ要件を評価する際に考慮すべき主要な設計特性は以下の通りです：

アベイラビリティ（可用性）：システムが必要なときに利用可能であること。例えば、サービス停止を防ぐために冗長化を図ることが重要です。
障害許容性（耐故障性）：システムの一部に障害が発生しても、全体が機能を維持できること。特に重要な業務を支えるシステムでは、この特性が不可欠です。
復元性（resilience）：システムが攻撃や障害から迅速に回復し、正常な状態に戻る能力を指します。この設計特性は、セキュリティインシデント発生後の迅速な事業継続に直結します。

設計特性の比較表
特性	定義	目的	実現方法	メリット	デメリット
アベイラビリティ	システムが必要なときに利用可能である能力	システムの稼働時間を最大化し、サービス中断を最小限に抑える	– 冗長化 – 負荷分散 – 自動フェイルオーバー	– サービスの継続性確保 – ユーザー満足度向上	– コスト増加 – システム複雑化
障害許容性（耐故障性）	システムの一部に障害が発生しても、全体の機能を維持できる能力	部分的な障害がシステム全体のダウンタイムにつながるのを防ぐ	– モジュール化 – エラー検出・回復メカニズム – 冗長コンポーネント	– システムの信頼性向上 – 障害の影響を局所化	– 開発・テストの複雑化 – パフォーマンスオーバーヘッド
復元性（resilience）	システムが攻撃や障害から迅速に回復し、正常な状態に戻る能力	予期せぬ事態や攻撃に対する回復力を高める	– 自動スケーリング – バックアップと復旧計画 – サーキットブレーカーパターン	– ビジネス継続性の向上 – セキュリティインシデントからの素早い回復	– 設計・実装の複雑さ増加 – テストシナリオの増加

3. 応用例

　セキュリティ要件の識別は、様々な業界や状況で応用されています。以下にいくつかの例を示します：

3.1. 金融システムにおける応用

　銀行のオンラインバンキングシステムでは、顧客の個人情報と資金を保護するために厳格なセキュリティ要件が必要です。多要素認証（MFA）、データの暗号化、トランザクションのリアルタイムモニタリング、不正アクセス検知システム（IDS/IPS）など、複数の設計原則を組み合わせて実装されています。

graph TD
    A[開始] --> B[リスクアセスメント]
    B --> C{重要な資産の特定}
    C --> D[データ機密性要件]
    C --> E[データ完全性要件]
    C --> F[可用性要件]
    D --> G[暗号化要件の定義]
    E --> H[データ検証メカニズムの定義]
    F --> I[冗長性と負荷分散の要件定義]
    G --> J[アクセス制御要件]
    H --> J
    I --> J
    J --> K[認証メカニズムの定義]
    K --> L[多要素認証の実装]
    L --> M[監査ログの要件]
    M --> N[インシデント対応計画]
    N --> O[コンプライアンス要件の確認]
    O --> P[セキュリティテスト計画]
    P --> Q[従業員トレーニング要件]
    Q --> R[定期的なセキュリティレビュー]
    R --> S{全要件を満たしているか?}
    S -->|はい| T[実装と監視]
    S -->|いいえ| B
    T --> U[終了]

　この金融システムのセキュリティ要件フローチャートは、以下の主要なステップと考慮事項を含んでいます：

リスクアセスメント：システムの脆弱性と潜在的な脅威を特定します。
重要な資産の特定：保護すべき重要なデータや機能を明確にします。
主要セキュリティ要件の定義：
- データ機密性要件
- データ完全性要件
- 可用性要件
具体的なセキュリティメカニズムの定義：
- 暗号化要件
- データ検証メカニズム
- 冗長性と負荷分散
アクセス制御要件：適切なアクセス制御ポリシーを定義します。
認証メカニズム：強力な認証方法を選択します。
多要素認証の実装：追加のセキュリティレイヤーを提供します。
監査ログの要件：全ての重要な活動を記録し、追跡可能にします。
インシデント対応計画：セキュリティ侵害時の対応手順を定義します。
コンプライアンス要件の確認：関連する法規制や業界標準を遵守していることを確認します。
セキュリティテスト計画：脆弱性評価や侵入テストの計画を立てます。
従業員トレーニング要件：セキュリティ意識向上のためのトレーニングを計画します。
定期的なセキュリティレビュー：セキュリティ対策の有効性を定期的に評価します。
要件の再確認：全ての要件が満たされているか確認し、不足があれば再度リスクアセスメントに戻ります。
実装と監視：要件を満たしていれば、実装し継続的に監視します。

　このフローチャートは、金融システムにおける包括的なセキュリティ要件の識別と実装プロセスを示しています。各ステップは互いに関連しており、セキュリティ要件の継続的な評価と改善の必要性を強調しています。

　金融機関や開発者は、このフローチャートを参考にして、自社のシステムに適したセキュリティ要件を体系的に特定し、実装することができます。また、新たな脅威や規制の変更に応じて、このプロセスを定期的に繰り返すことで、システムのセキュリティを最新の状態に保つことができます。

3.2. 医療情報システムにおける応用

　医療情報システムでは、患者の個人情報や診療記録を保護するため、プライバシー保護とデータの完全性が重要視されます。ここでは、アクセス制御、データの暗号化、そして医療データの監査ログの記録と監視が必須のセキュリティ要件となります。

3.3. クラウドサービスにおける応用

　クラウドサービスでは、マルチテナント環境におけるデータの分離、可用性の確保、そして災害復旧のためのバックアップ体制がセキュリティ要件の中心となります。これにより、多数の企業や個人のデータを確実に保護することが可能です。

4. 例題

例題1

　ある企業のWebアプリケーションのセキュリティ要件を識別する際に、最も適切な設計原則はどれか。

a) 最大限の機能提供
b) 単一層防御
c) システムサービスへのアクセス制限
d) システムへの攻撃面の最大化

回答：c) システムサービスへのアクセス制限

解説：Webアプリケーションでは、不要なサービスへのアクセスを制限することで、攻撃の機会を減らし、セキュリティを向上させることができます。これは「最小限の原則」にも合致します。

例題2

　以下の設計特性のうち、システムが攻撃や障害から迅速に回復し、正常な状態に戻る能力を表すものは

どれか。

a) アベイラビリティ
b) 障害許容性
c) 復元性
d) 冗長性

回答：c) 復元性

解説：復元性（resilience）は、システムが攻撃や障害から迅速に回復し、正常な状態に戻る能力を指します。これは、セキュリティインシデントが発生した際の事業継続性を確保する上で重要な特性です。

5. まとめ

　セキュリティ要件の識別は、企業の情報セキュリティ方針に基づいて、適切なセキュリティ機能を設計・実装するための重要なプロセスです。主要な設計原則（最小限の原則、多層防御、アクセス制限、攻撃面の最小化）と設計特性（アベイラビリティ、障害許容性、復元性）を理解し、システムの特性に応じて適切に選択・優先順位付けすることが重要です。

　これらの知識を適切に応用することで、効果的なセキュリティ実現方式を選択し、安全性対策と信頼性対策を適切に実装することができます。結果として、システムの脆弱性を最小限に抑え、潜在的な脅威からシステムを保護することが可能となります。