---
title: "ISMSの構成管理（管理策8.9）とは？構成記録とベースラインの作り方・変更管理との違い"
url: "https://www.issoh.co.jp/column/details/12629/"
published: 2026-06-18
updated: 2026-09-30
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ISMSの構成管理（管理策8.9）とは？構成記録とベースラインの作り方・変更管理との違い

ISMSの構成管理は、ISO/IEC 27001:2022の附属書Aで新設された管理策「8.9 構成管理」を指します。サーバやネットワーク機器、クラウドサービスの設定を「承認済みの状態」として定め、その状態から外れていないかを監視し続ける管理策です。この記事では、ISO/IEC 27002:2022の手引が求める内容、構成記録に残す項目、ベースラインの作り方、ずれ（ドリフト）の検知手順、変更管理や資産目録との境界、審査で確認される証跡の順に整理します。

## まとめ：8.9は「承認済みの設定を定め、ずれを見つけて戻す」管理策

管理策8.9の要求は、ハードウェア・ソフトウェア・サービス・ネットワークのセキュリティ構成を含む構成を「確立し、文書化し、実装し、監視し、レビューする」ことです。2013年版に対応する管理策は無く、2022年版で新しく加わった11管理策の1つです。

- **最初に作るもの**：機器・OS・クラウド設定の種類ごとの標準テンプレート（ベースライン）。CIS Benchmarksなど公開ガイドを出発点にします。
- **記録に残すもの**：所有者、最終変更日時、適用しているテンプレートの版、他の資産の構成との関係。
- **回し方**：変更は8.32（変更管理）で承認し、定期的に実機とテンプレートを突き合わせます。ずれが見つかったら、承認済みなら記録を更新し、未承認なら元に戻します。
- **審査に備える点**：テンプレートと記録に加え、それが実機と一致していること、ずれを検知して処置した記録を示せること。

CMDBやIaCツールは手段であって要求事項ではありません。台帳と定期点検の記録で満たすこともできます。

## 管理策8.9の要求とISO/IEC 27002の手引

ISO/IEC 27001:2022の附属書Aは管理策を1文で示すだけで、実装の手引はISO/IEC 27002:2022に書かれています。27002は8.9の目的を、ハードウェア・ソフトウェア・サービス・ネットワークが必要なセキュリティ設定で正しく機能し、認可されていない変更や誤った変更で構成が変わらないようにすること、と定めています。属性は予防（Preventive）で、機密性・完全性・可用性のすべてに関わり、運用能力の分類は「Secure\_configuration」です。

手引の中身は、大きく3つに分かれます。

| 手引の区分    | 求めていること                   | 実務での成果物        |
| -------- | ------------------------- | -------------- |
| 標準テンプレート | 公開・ベンダー・OSSの指針を使い、定期的に見直す | 種類別のベースライン文書   |
| セキュリティ設定 | 管理者権限の最小化、既定パスワードの変更など    | テンプレート内の必須設定項目 |
| 構成の管理と監視 | 変更履歴の保持、構成記録、変化の検知        | 構成記録、点検記録、検知ログ |

2つ目の区分で27002が挙げる設定は具体的です。管理者権限を持つ識別子（アカウント）を最小限にする、不要・未使用・安全でない識別子を無効にする、不要な機能やサービスを無効化または制限する、強力なユーティリティやホストのパラメータ設定へのアクセスを制限する、クロックを同期する、既定のパスワードなど製品出荷時の認証情報を導入直後に変える、一定時間操作が無ければ自動でログオフさせる、ライセンス要件を満たしているか確かめる、の8つです。自社テンプレートの目次に、この8項目が入っているかを確かめるだけでも抜けの点検になります。

## 2013年版との関係：前身の無い新設管理策

ISO/IEC 27001:2022の附属書Aは、2013年版の14カテゴリ114管理策から、組織的37・人的8・物理的14・技術的34の4区分93管理策に再編されました。多くは旧管理策の統合ですが、11の管理策は2013年版に対応するものが無い新設です。

- 組織的管理策：5.7 脅威インテリジェンス／5.23 クラウドサービスの利用における情報セキュリティ／5.30 事業継続のためのICTの備え
- 物理的管理策：7.4 物理的セキュリティの監視
- 技術的管理策：8.9 構成管理／8.10 情報の削除／8.11 データマスキング／8.12 データ漏えい防止／8.16 監視活動／8.23 ウェブフィルタリング／8.28 セキュリティに配慮したコーディング

「構成管理は旧版の変更管理の一部だった」という説明を見かけますが、正確ではありません。2013年版の変更管理（12.1.2）、システムの変更管理手順（14.2.2）など変更に関する4つの管理策は2022年版の8.32 変更管理へまとめられ、8.9はそれとは別に新設されました。変更管理が「変更を承認する手続き」を扱うのに対し、8.9は「承認済みの状態そのもの」を定義し維持する点で役割が違います。

国内規格はJIS Q 27001:2023（追補JIS Q 27001:2023/AMENDMENT 1:2025と併せて2025年版として利用）、手引はJIS Q 27002:2024です。2013年版から2022年版への移行期限は2025年10月31日で終了しており、2013年版の認証は現在有効ではありません。附属書Aの93管理策の全体像と選定の手順は[ISMSの管理策とは？ISO 27001:2022附属書Aの93項目と選定手順を実務目線で解説](/column/details/12604/)で整理しています。

## 構成管理・資産目録・変更管理・脆弱性管理の境界

8.9は隣接する管理策と対象が重なるため、審査では「どの記録がどの管理策の証跡か」を説明できるかが問われます。役割を分けると次のとおりです。

| 管理策                 | 答える問い           | 主な記録        |
| ------------------- | --------------- | ----------- |
| 5.9 情報及びその他の関連資産の目録 | 何を持っているか、誰が責任者か | 資産目録        |
| 8.9 構成管理            | それがどう設定されているべきか | テンプレート、構成記録 |
| 8.32 変更管理           | 設定を変えてよいか       | 変更申請・承認記録   |
| 8.8 技術的ぜい弱性の管理      | その版に既知の弱点があるか   | 脆弱性の評価・対応記録 |
| 8.16 監視活動           | 異常な挙動が起きていないか   | 監視ログ、アラート   |

連携の要は2点です。1つは資産目録と構成記録のキーをそろえること。資産IDが一致していないと、脆弱性情報が出たときに「影響を受ける版がどこで動いているか」を構成記録から引けません。もう1つは、変更チケット番号を構成記録に残すことです。変更チケットに承認された変更内容と対象資産が書かれていれば、点検で見つかったずれがその範囲に収まるかを記録同士の照合で判定できます。

ITIL由来の「構成管理」やソフトウェア開発の構成管理との違いは[構成管理とは？CMDB・IaC・ソフトウェア構成管理の違いと運用体制の作り方](/column/details/15291/)、版と脆弱性の突き合わせは[ISMSにおける脆弱性とは｜種類・脅威との違いと2022年改訂後の管理プロセス](/column/details/12542/)で扱っています。

## 構成記録とベースラインの作り方

### 公開ガイドを土台にしたベースラインの作成

27002は、テンプレートの作成に公開されている指針やベンダーの指針を使うよう求めています。ゼロから設定項目を洗い出すより、次の出典を土台に自社の事情で差分を決める方が、審査でも根拠を示しやすくなります。

- **CIS Benchmarks**：OS・クラウド・ミドルウェア別の推奨設定集。Level 1（利便性を大きく損なわない標準的な設定）と、Level 1にさらに項目を足したLevel 2（性能や利便性を下げてでも守る多層防御向けの設定）に分かれます。
- **NIST SP 800-70 Rev. 5**（2026年5月）：米国の構成チェックリスト（National Checklist Program）の使い方を定めた文書。
- **NIST SP 800-128**（2011年、2019年更新）：セキュリティに焦点を当てた構成管理のプロセス（計画・ベースライン確立・変更管理・監視）の手引。
- **ベンダーのセキュリティガイド**：製品固有の設定はベンダー文書が最も正確です。

採用しない推奨項目は、その理由（業務アプリが依存する、代替策で補っている等）をテンプレートに書き残します。例外には、対象の推奨項目、適用しない理由、代替策、承認者、次の見直し日を残しておくと、審査で判断の経緯を説明できます。見直しの時期は、テンプレート側の版とあわせて「OSのメジャーアップデート時と年1回」のように決めておくと、点検の基準日が明確になります。

### 構成記録に残す4項目と記入例

27002が構成記録に含められる項目として挙げているのは、資産の所有者または連絡先、最終変更日時、適用しているテンプレートの版、他の資産の構成との関係の4点です。これに変更チケット番号を足すと、前章の突き合わせまで記録だけで完結します。Webサーバ1台分を書くと次のようになります。

```
# 構成記録（例）
asset_id: SRV-WEB-01          # 資産目録（5.9）と同じID
owner: インフラ運用チーム 山田
baseline: Linux-Web-Baseline v2.3 (CIS Level 1 を参考に調整・例外1件)
exceptions:
  - "USBストレージの無効化: 保守作業で使うため未適用（代替: 利用申請と操作ログ）"
last_change: 2026-09-12 14:30 JST
change_ticket: CHG-2026-0412    # 変更管理（8.32）の承認番号
depends_on: [LB-01, DB-01]      # 構成を変えると影響が及ぶ資産
last_verified: 2026-09-15 (ドリフト点検 OK)
```

管理対象の粒度は、環境の寿命ではなく「その設定が変わると機密性・完全性・可用性に影響するか」で決めます。検証環境でも本番データを扱う、本番ネットワークにつながる、といった条件があれば対象に含めます。対象外にする環境は、その理由をリスク評価の結果として残しておきます。記録は、載せた範囲が実機と一致していなければ役に立たないため、対象を広げるときは更新の担当と点検の頻度を同時に決めます。

## 構成ドリフトの検知と是正の手順

27002の手引は、保守ユーティリティやリモートサポート、統合管理ツール、バックアップ・リストアのソフトウェアなどで構成を監視し、定期的にレビューすることを推奨しています。実際の構成は定義した目標テンプレートと比較でき、逸脱には、目標構成の自動適用か、逸脱を手動で分析したうえでの是正処置で対処するとしています。つまり8.9の運用は検知だけでは終わらず、処置までを1サイクルとして設計します。

| 対象            | 検知の手段                             | ずれの出方              |
| ------------- | --------------------------------- | ------------------ |
| サーバの設定ファイル    | ハッシュ比較（sha256sum -c）              | FAILED行、終了コード      |
| IaC管理下のクラウド資源 | terraform plan -detailed-exitcode | 終了コード2             |
| AWSリソース       | AWS Configのルール                    | NON\_COMPLIANT     |
| Azureリソース     | Azure Policy（既存リソースは24時間ごとに評価）    | 非準拠（Non-compliant） |

小規模な環境なら、承認済み設定ファイルのハッシュを控えておき、定期的に照合するだけでも検知の仕組みになります。次のスクリプトは、一致すれば終了コード0、ハッシュ一覧が無い・読めないときは1（点検未実施）、不一致や一覧の書式不備があれば2を返します。点検できなかった回を「ずれなし」と混同しないよう、1と2を分けています。

```
#!/bin/sh
# 使い方: ./check_drift.sh baseline.sha256
# 終了コード 0=一致 / 1=点検できない（一覧が無い・読めない） / 2=不一致または一覧の不備
BASELINE="$1"
if [ -z "$BASELINE" ] || [ ! -r "$BASELINE" ]; then
  echo "ERROR: ハッシュ一覧を読めないため点検未実施" >&2
  exit 1
fi
if sha256sum --strict --quiet -c "$BASELINE"; then
  echo "OK: ベースラインどおり"
  exit 0
fi
echo "DRIFT: 不一致または一覧の不備あり（表示されたファイルを変更チケットと突き合わせる）"
exit 2
```

動作は、設定ファイルのテスト用コピーで確かめられます。`sha256sum test/sshd_config.copy > baseline.sha256` で控えを作り、コピーの末尾にコメント行を1行足すと、`test/sshd_config.copy: FAILED` と表示されて終了コード2で止まります。ハッシュ比較は「変わったこと」しか分からないため、差分の中身を見たい場合は承認時のファイル自体を別の場所に保管し、diffで比べます。また、対象ファイルと同じ権限でハッシュ一覧も書き換えられると検知が無意味になるため、一覧は管理者だけが書き込める場所かGitリポジトリに置き、変更履歴を残します。

IaCで管理しているクラウド資源では、Terraformの `terraform plan -detailed-exitcode` が、差分なしで0、エラーで1、差分ありで2を返します。これを定期的にCIで実行すると、Terraformが管理しているリソースと属性については、コンソールからの手作業変更を差分として拾えます。Terraformの管理外で作られたリソースは対象外で、plan自体がエラーで止まった回は点検できていない点にも注意します。通常のplanは未適用のコード変更も差分として出すため、実機側のずれだけを確かめたい場合は `terraform plan -refresh-only` を使います。refresh-onlyはstateを実機に合わせるだけで実機は変えません。ずれを採用する場合はコード側へ取り込み、採用しない場合は通常モードのplanで戻す内容を確認してからapplyします。IaCの導入判断は[IaCとは？Infrastructure as Codeの仕組み・メリットと導入](/column/details/13004/)で解説しています。

ツールの出力だけでは、ずれにどう対処したかが残りません。検知結果ごとに「承認済み（CHG番号）」「差し戻し済み」「インシデントとして起票」のいずれかの処置を記録しておくと、監視とレビューを実施したことを示せます。

## 審査・内部監査で確認される証跡と、不適合になりやすい抜け

8.9の要求は「監視し、レビューする」まで含むため、審査に備えるなら文書の有無より運用の実態を示せるようにしておきます。構成記録から1台を選んで実機の設定と一致しているか、直近の変更チケットに対応して構成記録の最終変更日時と版が更新されているか、ドリフト点検の記録に検知後の処置まで残っているか、の3点を自分で抜き取り確認しておくと、説明に詰まりません。

不適合につながりやすいのは次のパターンです。

- **緊急変更の事後記録が無い**：障害対応でファイアウォールの許可範囲を広げ、戻したかどうかが記録から追えない。
- **テンプレートの見直し日が古い**：OSのメジャーバージョンが上がっているのに、テンプレートが旧版のまま。
- **クラウドの設定が範囲外**：オンプレのサーバは記録があるが、IaaSのセキュリティグループやSaaSの管理画面の設定が構成記録に無い。
- **検知しても処置の記録が無い**：ツールのアラートは出ているが、承認済みか差し戻したかの判定が残っていない。

内部監査で8.9を点検するときも、この抜き取り確認がそのまま使えます。監査の進め方全体は[ISMSの内部監査とは？目的・進め方から2022年改訂後の確認観点まで実務解説](/column/details/12645/)、指摘を受けた後の是正処置は[ISMSの不適合とは？重大・軽微の判定基準と是正処置報告書の書き方【2022年版対応】](/column/details/12603/)を参照してください。

## 専任者がいない組織で8.9を始める順番

最初にCMDBを入れるのはおすすめしません。登録項目と更新の担当を決める前にツールを入れると、初期登録の後に更新が止まり、実機と食い違う台帳が残りがちです。食い違った台帳は、脆弱性対応や障害調査で誤った版や設定を前提に判断する原因になります。

1. 外部に公開しているサーバ、認証基盤、クラウドの管理アカウントなど、設定の誤りが即座に事故につながるシステムに対象を絞る。
2. 対象ごとにCIS Benchmarks等からテンプレートを作り、採用しない項目の理由を書く。
3. 既存のIT資産管理台帳に「テンプレートの版」「最終変更日時」「変更チケット番号」の列を足して構成記録にする。
4. 月1回、ハッシュ比較やクラウドの準拠状況レポートで点検し、処置を記録する。
5. 点検の手間が対象の増加に追いつかなくなった時点で、CMDBやIaCへの移行を検討する。

CMDBの仕組みと導入判断は[CMDBとは？構成管理データベースの仕組み・ITILとの関係・導入判断を解説](/tech/details/4951/)で詳しく解説しています。

## よくある質問

### 構成管理（8.9）を適用宣言書で除外できますか？

除外する場合は、ISO/IEC 27001の6.1.3 d)に従い除外の正当化を適用宣言書に書く必要があります。サーバ・ネットワーク・クラウドサービスを1つでも運用していれば8.9の対象となる構成が存在するため、除外の正当化は通常成り立ちません。

### CMDBを導入しないと8.9を満たせませんか？

満たせます。8.9が求めるのは構成の確立・文書化・実装・監視・レビューで、特定のツールは指定されていません。スプレッドシートの構成記録と定期点検の記録でも、実機と一致していれば要求を満たします。

### SaaSの管理画面の設定も8.9の対象ですか？

対象です。8.9の対象には「サービス」が含まれます。SaaSでは、多要素認証の強制や外部共有の可否など利用者側で変えられる設定をテンプレート化し、記録と点検の対象にします。提供者側の責任範囲の整理は5.23（クラウドサービスの利用における情報セキュリティ）で扱います。

### テンプレートはどのくらいの頻度で見直せばよいですか？

27002は「適切な間隔で見直す」とだけ定め、頻度を指定していません。OSやミドルウェアのメジャーアップデート時、参照しているCIS Benchmarksの版が上がった時、重大な脆弱性が公表された時を契機にし、それとは別に年1回の定期見直しを置く運用が説明しやすい形です。

### 2013年版で認証を取っていた組織は、いま何をすればよいですか？

移行期限の2025年10月31日を過ぎたため、2013年版の認証は失効しています。現在も認証を維持している組織はすでに2022年版へ移行済みなので、8.9については適用宣言書の記載と実際の運用記録が一致しているかを次回の審査前に確認します。

## 関連記事

- [ISMSの管理策とは？ISO 27001:2022附属書Aの93項目と選定手順を実務目線で解説](/column/details/12604/)
- [構成管理とは？CMDB・IaC・ソフトウェア構成管理の違いと運用体制の作り方](/column/details/15291/)
- [CMDBとは？構成管理データベースの仕組み・ITILとの関係・導入判断を解説](/tech/details/4951/)
- [ISMSの内部監査とは？目的・進め方から2022年改訂後の確認観点まで実務解説](/column/details/12645/)
- [ISMSにおける脆弱性とは｜種類・脅威との違いと2022年改訂後の管理プロセス](/column/details/12542/)

---

出典: [ISMSの構成管理（管理策8.9）とは？構成記録とベースラインの作り方・変更管理との違い](<https://www.issoh.co.jp/column/details/12629/>)（株式会社一創）