Unit 9（セキュリティガバナンスの概念）＋1ポイント
対象試験目標：5.1（効果的なセキュリティガバナンス）／1.3（変更管理プロセス）／4.7（自動化とオーケストレーション）／4.2（資産管理）／3.4（回復力・バックアップ）。
公式ページ番号は comptia.pdf（モジュール14＋モジュール7）に対応。配点：**ドメイン5.0（プログラム管理・ガバナンス）＝約20%**が中心、ドメイン4.0（運用）にもまたがる。
＋9-A. 文書の階層：ポリシー／標準／手順／ガイドライン（最重要・目標5.1）
公式 モジュール14A（p.415-）。スライド（pptx#236）は3種だが、SY0-701 は4階層で問う。
| 文書 | 英語 | 位置づけ | 強制力 | 例 |
|---|---|---|---|---|
| ポリシー | Policy | 経営の意志・大綱。「何を・なぜ」守るか | 必須（守る義務） | 情報セキュリティ基本方針、AUP（利用規程） |
| 標準（スタンダード） | Standard | ポリシーを満たす具体的・技術的要件。「どのレベルで」 | 必須 | パスワード標準、暗号化標準、アクセス制御標準 |
| 手順（プロシージャ） | Procedure | タスクの段階的な実行手順。「どうやって」 | 必須 | オンボーディング手順、パッチ適用手順、SOP |
| ガイドライン | Guideline | 推奨・ベストプラクティス。「望ましいやり方」 | 任意（推奨） | 推奨設定集、運用のヒント |
- 覚え方：ポリシー＝なぜ／標準＝何を（どの水準）／手順＝どうやって（手順書）／ガイドライン＝推奨。
- ポリシーと標準の違い＝「標準は実装重視、ポリシーは業務のやり方重視」（公式 p.419）。
＋9-B. ガバナンス構造と説明責任（目標5.1・頻出）
公式 モジュール14A（p.423-）。スライド（pptx#241）の「委員会」を701用語に対応づける。
| 用語 | 内容 |
|---|---|
| ガバナンスボード（取締役会） | 高位のエグゼクティブ＋外部ステークホルダーで構成。戦略目標・ポリシー・最終意思決定。 |
| ガバナンス委員会 | 専門家・運用リーダーで構成。深い分析・推奨案をボードに提供（意思決定は支援）。 |
| CIO/CISO | 情報・セキュリティの最高責任者（スライドの議長＝CIO）。 |
ガバナンスの類型
- 集中型 Centralized：単一グループが全社のポリシー・リソースを統制。整合性・標準化に強い。
- 分散型 Decentralized：各部門が現場に合わせて判断。適応性・柔軟性に強い。
- ハイブリッド Hybrid：集中の監視＋分散の実装のいいとこ取り。
データガバナンスロール（★超頻出）
公式 p.425-。「誰が何に責任を負うか」を必ず区別する。
| ロール | 英語 | 責任 |
|---|---|---|
| 所有者 | Owner | データの最終責任。分類レベル・機密度を決め、アクセスを許可する人を決定（役員クラス） |
| 管理者 | Controller | 個人データ処理の目的・手段を決定（GDPRの概念）。法令遵守を保証 |
| 処理者 | Processor | 管理者に代わってデータを処理（例：クラウド事業者CSP、ベンダー） |
| カストディアン／スチュワード | Custodian / Steward | データの安全な保管・輸送・保存と制御の実装（多くはIT部門） |
- 混同注意：所有者（決める人）⇔ カストディアン（守る人・実装する人）。
- 管理者 Controller（目的を決める）⇔ 処理者 Processor（代行して処理する）＝GDPRのペア。
＋9-C. 変更管理プロセス（最重要・目標1.3）
公式 モジュール14B（p.426-）。スライド（pptx#246）は簡潔なので＋1で補強。
標準的な承認フロー
- 変更依頼（RFC：Request for Change） 提出＝変更の詳細・目的・範囲・影響
- 変更管理者／CAB（変更諮問委員会） がレビュー＝実現可能性・リスク・整合性・ポリシー遵守
- 関連ステークホルダー（経営陣・IT・影響部門）が公式承認
- テスト環境で検証（テスト結果）
- メンテナンスウィンドウ中に実装
- 実装後のレビュー・監査＋文書化・バージョン管理
変更管理の重要概念（★出題対象）
| 概念 | 内容 |
|---|---|
| 影響度分析 | 変更がユーザー・業務・相互接続システムに与える影響を評価 |
| テスト結果 | 本番前にテスト環境で意図通り動くか確認 |
| バックアウト計画（ロールバック） | 失敗時に元の状態へ戻す緊急計画。ダウンタイム・データ損失を最小化 |
| メンテナンスウィンドウ | 変更を実施する事前定義の時間枠（閑散時に設定） |
| 標準業務手順書（SOP） | 変更を一貫して行う詳細な書面指示。ミスを減らす |
| 許可リスト／ブロックリスト | 低リスク変更＝許可リスト（簡略化）／高リスク・未承認＝ブロックリスト |
| 再起動・依存関係・ダウンタイム | 再起動が必要な変更、依存サービスへの波及を考慮 |
| 文書化・バージョン管理 | 変更履歴を保持、承認済みだけ実装、旧版へ即戻せる |
- 許可リストの落とし穴（公式 p.429）：ハッシュ値ベースの許可リストは、パッチ適用で実行ファイルのハッシュが変わると、正規ソフトが実行できなくなる。→テスト計画に組み込む。
- 依存関係の例：DBサーバーを再起動すると、それに依存する全アプリが停止しうる。
＋9-D. バックアップ種別と3-2-1ルール（目標3.4・頻出）
公式 モジュール7（p.181-）＋スライド pptx#248-250。
バックアップ種別の比較（★必ず出る）
| 種類 | 対象 | アーカイブ属性 | 復元 | バックアップ時間 |
|---|---|---|---|---|
| フル | 全データ | クリアする | 1世代で復元＝速い | 遅い（毎回全量） |
| 差分（ディファレンシャル） | 前回フル以降の変更分すべて | 変更しない | フル＋最新差分の2つ | 日々増えていく |
| 増分（インクリメンタル） | 前回バックアップ以降の変更分 | クリアする | フル＋全増分が必要＝遅い | 速い（差分が最小） |
- 覚え方：アーカイブ属性を「クリアするか」で見分ける。差分＝クリアしない（だから積み上がる）／増分＝クリアする（だから毎回リセット）。
- 復元の速さ：フル＞差分＞増分。バックアップの速さ：増分＞差分＞フル（トレードオフ）。
3-2-1ルール（★頻出）
- 3：データのコピーを3つ保持（本番＋バックアップ2つ）
- 2：2種類の異なる媒体に保存
- 1：うち1つはオフサイト（遠隔地）に保管
その他の保護技術
- エアギャップバックアップ：ネットワークから物理的に切り離す＝ランサムウェアがバックアップも暗号化するのを防ぐ。
- オンサイト（迅速復旧）⇔ オフサイト（災害・盗難に強い）。
- スナップショット（ある時点の状態。VM/ファイルシステム/SAN）／レプリケーション（正確なコピーを別所に同期。例：DBミラーリング）／ジャーナリング（変更をログ記録）。
- 重複除去（デデュープ）／圧縮でストレージ最適化。
- 復旧の検証：バックアップは取るだけでなく復元テスト（完全復旧テスト／部分復旧テスト）が必須。「100%成功」表示でも復元できないことがある。
- バックアップ⇔アーカイブ：バックアップ＝更新データのコピーを定期取得／アーカイブ＝使用頻度の低い不変データを外部保管（上書きしない）。
＋9-E. 自動化とオーケストレーション（目標4.7）
公式 モジュール14C（p.434-）。
| 用語 | 内容 |
|---|---|
| 自動化 Automation | ソフトで繰り返しタスク（監視・パッチ・ベースライン維持）を実行。人的ミス減 |
| オーケストレーション Orchestration | 複数の自動化プロセス・システムを協調させ、ワークフロー化 |
| SOAR | Security Orchestration, Automation and Response。APIで各ツールを連携し、検知→隔離→分析→通知→チケット生成を無人化 |
自動化のユースケース（公式の一覧）
- プロビジョニング（ユーザー・リソースの作成/変更/削除）
- ガードレールとセキュリティグループ（ポリシー遵守の監視・強制）
- チケット（インシデントから自動起票・エスカレーション）
- サービス管理／継続的インテグレーション（CI）・テスト
- API（システム間連携。SOARの基盤）
メリットと課題
- メリット：効率向上、一貫性、人的ミス減、労働力倍増（force multiplier）、監査証跡、オペレーター疲れ（アラート疲れ）の軽減。
- 課題：複雑さ／コスト／単一障害点（Single Point of Failure）／技術的負債／継続的サポートの必要性。
＋9-F. 資産管理・構成管理・モニタリング（目標4.2）
- 資産管理：資産の識別→分類→インベントリ（目録）→追跡→廃棄。命名規則、RFID/バーコード、CMDB。
- 資産追跡の手段：手作業目録／ネットワークスキャン（Nmap/Nessus）／資産管理ソフト（Lansweeper等）／CMDB／MDM／クラウド資産発見。
- 所有権割り当て・分類：説明責任の連鎖を確立。定期的な再確認。
- 廃棄（サニタイズ）：機器廃棄時にデータを復元不可能に（Unit 5のドライブサニタイズと関連）。
- 構成管理：CI（構成項目）／CMDB／構成ベースライン（承認された構成の基準点、逸脱を検知・復元）／DML（確定版メディアライブラリ）。
- モニタリング：パフォーマンスベースラインを基準に、
- シグネチャベース（既知の痕跡と照合＝既知の不正検出／ミスユース検出）
- アノーマリーベース（正常のベースラインからの逸脱＝異常検出）
- ビヘイビアベース（振る舞い分析＝ゼロデイ検出に有効）
＋9-G. ISO/IEC 27002 と法的環境（目標5.1）
- ISO/IEC 27001：ISMS（情報セキュリティ管理システム）の国際標準フレームワーク。
- ISO/IEC 27002：27001 に付随し、具体的な管理策（制御）の実装ガイド（スライド pptx#240 の項目群）。
- 27017（クラウド）／27018（クラウドのPII保護）。
- 主要な法令・標準：GDPR（EU）／CCPA（カリフォルニア）／HIPAA（米・医療）／PCI DSS（カード・契約義務）／FISMA・SOX（米・連邦/内部統制）／NIST SP800-63／FIPS。
- デューデリジェンス（しかるべき注意）：責任者が怠慢でなかったことを示す法律用語。過失は刑事・民事責任を生む。
- MSS/MSSP（pptx#239）：セキュリティ運用のアウトソーシング。専門人材の確保が困難な組織向け。
この＋1が効く出題形式
- ポリシー/標準/手順/ガイドラインの識別（＋9-A）
- 所有者/管理者/処理者/カストディアンの役割対応（＋9-B）
- 変更管理：RFC・CAB・バックアウト計画・メンテナンスウィンドウ・許可リストの落とし穴（＋9-C）
- バックアップ種別の見分け（アーカイブ属性）と3-2-1ルール、エアギャップ（＋9-D）
- 自動化/オーケストレーション/SOAR、単一障害点・技術的負債・労働力倍増（＋9-E）
- 構成ベースライン、モニタリング（アノーマリー/シグネチャ/ビヘイビア）（＋9-F）
- ISO 27001/27002 の違い、GDPR/CCPA/HIPAA/PCI DSS（＋9-G）