ISMSの構成管理（管理策8.9）とは｜2022年版の新設背景から実装・運用まで解説

ISMSの構成管理は、ISO/IEC 27001:2022（国内版はJIS Q 27001:2023）への改訂で新たに独立した技術的管理策「8.9 構成管理」として位置づけられた取り組みです。本記事では、構成管理が独立管理策へ格上げされた背景、定義すべき構成項目とセキュリティベースライン、CMDBやIaCツールを使った自動化と構成ドリフト検知、変更管理や技術的脆弱性管理との連携、そして移行期限が終了した現在の運用と内部監査・審査での確認観点までを、実装手順に沿って解説します。一般的なIT運用の構成管理との違いや、専任者を置けない中小規模組織での進め方も整理するため、これからISMSの構成管理を整備する担当者の指針になります。

まとめ：構成管理は管理策8.9として独立、ベースライン維持と変更管理連携が運用の核

ISMSの構成管理は、ICTシステムを構成するハードウェア・ソフトウェア・サービス・ネットワークの「あるべき構成」を定義し、最新の状態で維持することで、誤った変更による連鎖的な障害やセキュリティ低下を防ぐ予防的な管理策です。ISO/IEC 27001:2022の附属書Aで新設された11の管理策の一つで、技術的管理策「8.9」に分類されます。

運用の核は三つです。構成項目とセキュリティベースラインを定義すること、構成変更を変更管理（8.32）の承認フローに乗せること、定義と実態の乖離である構成ドリフトを検知して是正する仕組みを回すこと。CMDBやIaCツールは自動化の有効な手段ですが、導入だけで管理策を満たせるわけではなく、承認・記録・点検の運用ルールが伴って初めて機能します。

旧規格ISO/IEC 27001:2013から2022年版への移行期限は2025年10月31日で終了しました。現在はすべての認証組織が2022年版に基づく運用フェーズにあり、内部監査と更新審査では、新設管理策である構成管理が適切に運用され証跡が残っているかが問われます。

ISMSにおける構成管理（管理策8.9）の定義と対象となる構成情報の範囲

構成管理を整備する第一歩は、何を「構成」として管理対象に置くかを正しく定義することです。ここでは管理策8.9が求める範囲と、現場でつまずきやすい用語の整理を扱います。

構成管理が「あるべき構成」を定義し維持する予防的管理策である理由

管理策8.9の目的は、ハードウェア・ソフトウェア・サービス・ネットワークの構成を定義し、本来あるべき状態から逸脱しないよう維持することにあります。設定の意図しない変更は、可用性の低下だけでなく、不要なポート開放や既定パスワードの放置といったセキュリティ上の弱点を生みます。構成管理は障害や事故が起きてから対処する是正型ではなく、逸脱を起こさせない予防型の管理策である点が特徴です。たとえばWebサーバの公開設定を基準どおりに固定しておけば、運用担当者が個別に設定を変えてしまう余地を減らせます。

管理対象となるハードウェア・ソフトウェア・サービス・ネットワーク構成の範囲

対象は物理サーバやネットワーク機器だけではありません。OSやミドルウェアのバージョンと設定値、アプリケーションの構成ファイル、クラウドサービスの設定、ファイアウォールやロードバランサのルールまでが含まれます。判断基準は「その構成が変わると情報の機密性・完全性・可用性に影響するか」です。影響するものは管理対象、影響しない一時的な検証環境などは対象外とするなど、線引きを明文化しておくと範囲が安定します。

セキュリティ上の「あるべき構成」とベースラインを区別する考え方

「あるべき構成」は個々の機器ごとの正しい状態を指し、ベースラインはその基準を類型化したテンプレートを指します。たとえば「業務用Linuxサーバの標準設定」というベースラインを一つ定め、それを各サーバに適用して個々のあるべき構成とする、という関係です。ベースラインを先に整えると、新規構築時に基準から逸脱した設定が混入しにくくなり、点検時の比較対象も明確になります。

誤った変更が連鎖障害や脆弱性につながる具体的な失敗例

典型例は、緊急対応で一時的にファイアウォールの許可範囲を広げたまま元に戻し忘れ、外部から到達可能な状態が継続するケースです。ほかにも、OSのアップデートを一部のサーバだけ適用し、構成が混在した結果として既知の脆弱性が残るパターンもあります。いずれも単体の作業ミスが、記録されないまま放置されることで全体のリスクへ波及します。構成管理は、こうした「戻し忘れ」「適用漏れ」を記録と点検で可視化する役割を担います。

構成情報・情報資産・構成項目（CI）という用語の使い分け

情報資産は保護対象そのもの（データやシステム）、構成情報はそれらが「どう設定されているか」を表す情報、構成項目（CI：Configuration Item）は構成管理で個別に管理する単位を指します。1台のサーバが1つの情報資産であると同時に、その上のOS・ミドルウェア・設定が複数のCIになることもあります。用語を混同すると台帳の粒度がぶれるため、社内ルールで定義を固定しておくことが運用の前提になります。

2022年改訂で構成管理が独立管理策へ格上げされた背景と旧13年版との相違点

構成管理が注目される直接の理由は、2022年改訂で独立した新管理策になったことです。改訂全体の構造変化とあわせて、その位置づけを押さえます。

附属書Aが14カテゴリ114管理策から4カテゴリ93管理策へ再編された全体像

2022年版では附属書Aが大きく再編されました。従来14のカテゴリに分かれていた114の管理策が、4つのカテゴリの93管理策へと整理されています。内訳は新規追加が11、複数を統合したものが24、内容を更新したものが58で、削除された管理策はありません。数が減ったのは統合によるもので、対応すべき事項が減ったわけではない点に注意が必要です。

4カテゴリは組織的・人的・物理的・技術的という区分で、構成管理はこのうち技術的管理策に含まれます。

新規追加された11管理策の中での構成管理（8.9）の位置づけ

新規11管理策には、脅威インテリジェンス（5.7）、クラウドサービスの利用における情報セキュリティ（5.23）、事業継続のためのICTの備え（5.30）、物理的セキュリティの監視（7.4）、構成管理（8.9）、情報の削除（8.10）、データマスキング（8.11）、データ漏えいの防止（8.12）、監視活動（8.16）、ウェブフィルタリング（8.23）、セキュアコーディング（8.28）が並びます。構成管理は技術的領域の中核で、監視活動や脆弱性管理など他の技術的管理策が機能する前提を支える位置づけです。

旧版で変更管理の一部だった構成管理を独立させた狙い

旧13年版では、構成の管理は変更管理の中で暗黙的に扱われていました。2022年版で独立させた狙いは、クラウドやテレワークの普及でIT資産が分散し、「いま何が・どの設定で動いているか」を常に把握する重要性が増したためです。変更の承認だけでなく、変更前後の構成そのものを記録・維持する活動を明示することで、管理の抜けを防ぎます。

ISO/IEC 27002:2022・JIS Q 27001:2023との対応関係

附属書Aの管理策は、先行して2022年2月に改訂されたISO/IEC 27002:2022の内容を取り込んだものです。ISO/IEC 27001が「何をすべきか」を定める要求事項であるのに対し、ISO/IEC 27002は管理策の実践方法を示すガイドラインで、認証の対象ではありません。国内では、ISO/IEC 27001:2022を翻訳したJIS Q 27001:2023が2023年9月20日に発行され、これが現在の国内規格です。構成管理の具体的な実装を検討する際は、27002のガイダンスを参照すると設計しやすくなります。

技術的管理策に分類されたことが現場の運用に与える影響

技術的管理策に位置づけられたことで、構成管理は方針文書だけでは完結せず、実際のシステム設定と記録の整合が問われます。つまり、台帳に「あるべき構成」を書いただけでは不十分で、稼働中のシステムがその記述どおりであることを点検で確認できる状態が求められます。運用の主担当は情報システム部門になりますが、ISMS事務局が記録の枠組みを整える役割を持つため、両者の連携設計が現場での実装可否を左右します。

構成管理で定義すべき構成項目・セキュリティベースライン・記録の設計指針

ここからは実装の中身に入ります。構成項目の粒度、ベースラインの作り方、記録と点検サイクルという三点を設計の指針として整理します。

構成項目（CI）の粒度を決める判断基準と過剰管理の回避

粒度は「変更が独立して発生し、かつ追跡する価値があるか」で決めます。サーバ単位までは管理しやすい一方、設定パラメータ一つひとつをCI化すると台帳が肥大化し更新が追いつきません。目安として、まずはサーバ・ネットワーク機器・主要なクラウドサービスとその設定群をCIとし、細部はベースライン側で吸収する設計が現実的です。過剰管理は更新漏れを誘発し、かえって記録の信頼性を下げます。

OS・ミドルウェア・クラウド設定ごとのセキュリティベースライン例

ベースラインは対象種別ごとに用意します。OSであれば不要サービスの停止・既定パスワードの変更・ログ取得の有効化、ミドルウェアであれば対応バージョンと公開ポートの限定、クラウド設定であればストレージの公開禁止と多要素認証の必須化、といった具合です。CISベンチマークなどの公開された設定基準をたたき台にすると、ゼロから作るより抜けを減らせます。自社のシステム種別を棚卸しし、種別ごとに一つずつ標準を定めるところから始めます。

構成記録に含めるべき項目（バージョン・責任者・依存関係）の整理

構成記録には、対象の識別名、OSやソフトウェアのバージョン、設定値またはベースライン名、管理責任者、他システムとの依存関係、最終確認日を最低限含めます。とくに依存関係は、ある構成変更が別のシステムに波及するかを判断する材料になり、連鎖障害の予防に直結します。バージョンと最終確認日を記録しておくと、後述する脆弱性管理や内部監査で「いつ時点の構成か」をすぐに示せます。

構成の承認・レビュー・定期点検を回すサイクル設計

記録は作って終わりではなく、回すことで価値が出ます。新規構築時に基準適合をレビューし、変更時は承認を経て記録を更新し、定期点検で実態との整合を確認する、という循環を設計します。点検頻度は重要システムで四半期に一度、その他で半期に一度といった形でリスクに応じて差をつけると、負荷を抑えながら実効性を保てます。

文書化と証跡保持で審査に耐える記録の残し方

審査では「運用していること」を文書・記録・報告書で示す必要があります。構成管理規程のような方針文書に加え、構成記録の更新履歴、点検結果、是正の記録を残すことが要点です。電子台帳であれば変更履歴が自動で残る仕組みを使い、誰がいつ更新したかを追えるようにしておくと、証跡の信頼性が高まります。口頭運用や個人のメモは証跡として認められにくいため避けます。

CMDB・IaCツールによる構成管理の自動化と構成ドリフトを検知する運用設計

構成管理は手作業でも始められますが、対象が増えると自動化が現実的になります。CMDBとIaCの役割、構成ドリフトの検知、そしてツールに頼りすぎない設計を扱います。

CMDB（構成管理データベース）で構成情報を一元化する利点と限界

CMDBは構成項目とその関係性を一元管理するデータベースで、依存関係の可視化や影響範囲の把握に強みがあります。一方で、CMDBは登録された情報の正確さに依存するため、更新が手作業に頼ると実態とずれていきます。利点を活かすには、後述する自動収集や定期的な実機との突合をセットで設計することが前提になります。

IaC（Infrastructure as Code）による「あるべき構成」のコード化

IaCは、インフラの構成をコードとして記述し、その定義どおりに環境を自動構築する手法です。あるべき構成がコードとして一元管理されるため、ISMSの構成管理が求める「定義の維持」と相性が良く、変更履歴もバージョン管理で追跡できます。代表的なツールであるTerraformの仕組みやメリットは、Terraformを用いたインフラコードの管理とバージョン管理の解説で具体的に確認できます。コード化により、誰が・いつ・どの構成を変えたかが明確になり、属人化を減らせます。

構成ドリフト（定義と実態の乖離）を検知し是正する仕組み

構成ドリフトとは、定義した「あるべき構成」と実際に稼働している構成がずれた状態を指します。手動でコンソールを操作して設定を変えると、コード上の定義と実態が食い違い、ドリフトが発生します。IaCツールでは定義と現状の差分を検出できるため、定期的に差分チェックを実行し、想定外の差分があれば原因を調査して是正します。「管理対象はツール経由でのみ変更する」というルールの徹底が、ドリフト抑制の前提になります。

手作業台帳とツール運用を比較して移行を判断する基準

判断基準は管理対象の規模と変更頻度です。対象が数十台規模で変更が少なければ表計算ソフトの台帳でも回りますが、クラウドで構成が頻繁に変わる環境では更新が追いつかず、自動化の効果が大きくなります。移行の目安は「台帳の更新漏れが点検のたびに見つかる」「同じ構成を何度も手作業で再現している」状態です。インフラ構成管理ツールの選択肢は、TerraformやVaultなどHashiCorpの主要製品を比較した記事が参考になります。

ツール導入だけでは管理策を満たせない運用ルールの必要性

ツールはあくまで手段で、導入しただけでは管理策8.9を満たしません。誰が構成を承認し、どの頻度で点検し、ドリフトをどう是正するかという運用ルールがなければ、ツールが生成する情報は活用されないまま蓄積されます。審査でも問われるのは設定された仕組みが実際に回っているかであり、ツール選定の前に運用フローを先に固めることが、形骸化を避ける近道です。

構成管理と変更管理・技術的脆弱性管理・情報資産目録を連携させる運用設計

構成管理は単独では完結せず、他の管理策と連動して効果を発揮します。とくに関係の深い変更管理・脆弱性管理・資産目録・監視活動との接続を設計します。

構成変更を変更管理（8.32）の承認フローに乗せる連携

構成を変更する際は、変更管理（8.32）の承認・テスト・記録のプロセスに沿って実施することが求められます。構成管理が「あるべき状態の維持」を担い、変更管理が「変える際の手続き」を担うという役割分担です。両者を切り離すと、承認を経ない変更が記録されないまま実態だけ変わり、構成記録が信頼できなくなります。変更申請の承認時に構成記録の更新を必須項目に組み込むと、抜けを防げます。

構成情報を技術的脆弱性管理（8.8）の対象特定に活用する流れ

技術的脆弱性管理（8.8）では、自社が「どのソフトウェアのどのバージョンを使っているか」を把握していなければ、公表された脆弱性が自社に該当するかを判断できません。構成記録にバージョン情報があれば、新しい脆弱性情報が出た際に影響範囲を即座に絞り込めます。たとえば特定ソフトの脆弱性が公表された場合、該当バージョンを使うCIを台帳から抽出し、優先的に対応する、という流れが組めます。

情報資産目録（5.9）と構成項目を対応づける運用

情報資産目録（5.9）は保護対象の一覧で、構成項目はその設定単位です。両者を対応づけておくと、重要度の高い情報資産に紐づく構成を優先的に管理でき、リスクに応じた濃淡をつけられます。資産目録と構成台帳を別々に作ると二重管理になりやすいため、識別名を共通化して相互参照できる形にしておくのが効率的です。

監視活動（8.16）やログとの突合による不正変更の検知

監視活動（8.16）で取得する操作ログや変更ログを構成記録と突き合わせると、承認を経ない不正な変更を検知できます。たとえば変更管理の記録にないのに設定変更のログが残っている場合、調査の対象になります。定期点検が「あるべき構成と実態の比較」であるのに対し、ログ突合は「変更の正当性の確認」であり、両者を併用すると見落としが減ります。

連携が破綻する典型パターンと責任分界点の明確化

連携が崩れる典型は、情報システム部門が実機を変更してもISMS事務局の台帳に反映されない、という責任分界の曖昧さです。回避策は、どの記録を誰が更新するかを一覧で定義することです。実機の変更者が記録更新まで責任を持つのか、事務局が定期的に吸い上げるのかを決め、両者の境界を文書化しておくと、更新漏れの原因を特定しやすくなります。

移行期限終了後に問われる構成管理の運用水準と内部監査・審査での確認観点

移行期限はすでに終了し、論点は「移行したか」から「運用できているか」へ移りました。終了後のフェーズと、内部監査・審査で見られる観点を整理します。

2025年10月31日の移行期限終了後に求められる運用フェーズ

ISO/IEC 27001:2013から2022年版への移行期限は2025年10月31日で終了し、旧版の認証は失効しました。現在は全認証組織が2022年版で運用するフェーズにあり、新設された構成管理が「導入済み」であることを前提に、その運用実績が問われます。これから新規取得する組織も当然2022年版が対象です。移行が済んでいない場合は失効扱いとなり、新規取得と同様の手順で再取得が必要になります。

内部監査で構成管理の有効性を点検するチェック観点

内部監査では、構成管理規程が定められているか、構成記録が最新か、変更が承認フローを経ているか、定期点検が実施され記録が残っているか、を観点とします。形式的に文書があるかではなく、実態と記録が一致しているかを現場で確認することが重要です。サンプルとして数台を抽出し、台帳の記述と実機の設定を突き合わせる点検が有効です。

審査員が証跡として確認しやすい構成管理の記録

審査では新設管理策の運用が重点的に見られる傾向があり、証跡として文書・記録・報告書の保持が求められます。具体的には、構成記録の更新履歴、変更承認の記録、定期点検の結果報告、是正処置の記録です。これらが日付と担当者付きで残っていれば、運用していることを示しやすくなります。記録が散在していると提示に時間がかかるため、所在を一元化しておくと審査対応がスムーズです。

適用宣言書（SoA）における構成管理（8.9）の扱い

適用宣言書（SoA）は、各管理策を適用するか否かと、その理由を示す文書です。構成管理を適用除外とするには合理的な根拠が必要で、ICTシステムを運用する多くの組織では適用が原則となります。除外する場合でも、なぜ自組織のリスクに照らして不要なのかを説明できる状態にしておくことが求められます。

不適合になりやすい運用の抜け（更新漏れ・属人化）

不適合として指摘されやすいのは、構成変更が記録に反映されていない更新漏れ、特定の担当者しか構成を把握していない属人化、定期点検が計画だけで実施記録がないケースです。いずれも「仕組みはあるが回っていない」状態を示します。更新を変更承認の必須項目にする、点検を担当者の予定に組み込む、といった運用への埋め込みが、指摘を防ぐ現実的な対策になります。

中小規模組織が構成管理をスモールスタートで定着させる優先順位と失敗パターン

リソースの限られる組織では、全システムを一度に管理しようとすると破綻します。優先順位の付け方と、既存資産の活用、よくある失敗を具体的に示します。

まず守るべき重要システムから対象を絞る優先順位の付け方

最初から全システムを対象にせず、停止や情報漏えいが事業に直結する重要システムから着手します。判断材料は、扱う情報の機密性と、停止した場合の業務影響です。たとえば顧客情報を扱う基幹サーバや外部公開しているWebシステムを最優先とし、検証環境などは後回しにします。対象を絞ることで、最初の構成記録とベースラインを現実的な工数で整えられます。

既存のIT資産管理台帳を構成管理へ発展させる手順

多くの組織はすでにIT資産管理台帳を持っています。ゼロから作るのではなく、その台帳にOS・ソフトウェアのバージョン、設定基準、管理責任者、最終確認日といった構成管理に必要な項目を追加していくと、移行の負荷を抑えられます。既存の識別名を流用すれば、資産目録との対応づけも同時に進みます。まず台帳に列を足すところから始めるのが現実的です。

専任者を置けない組織での役割分担と運用負荷の抑え方

専任者を置けない場合は、構成変更を行った人がその場で記録を更新する運用にし、月次でISMS事務局がまとめて点検する、といった分担にすると負荷が偏りません。点検頻度も重要システムに絞れば、片手間でも回せる範囲に収まります。負荷が高すぎる設計は更新漏れを招くため、続けられる頻度に調整することが定着の条件です。

ツール先行で形骸化する失敗パターンと回避策

よくある失敗は、高機能なCMDBやIaCツールを先に導入し、運用ルールが追いつかずに記録が放置されるパターンです。ツールが実態を反映しなくなると、台帳全体の信頼性が失われます。回避策は、まず手作業でも運用フローを固め、対象が増えてから自動化する順序を守ることです。小さく始めて回る状態を作ってから拡張するほうが、結果的に定着します。

定着度を測る簡易な指標とレビュー頻度の目安

定着度は、点検時に見つかる更新漏れの件数や、承認を経ない変更の発生件数で測れます。件数が回を追うごとに減っていれば運用が根づきつつある証拠です。レビューは、運用ルール自体を半期に一度見直し、点検は重要システムで四半期ごとを目安にすると、過不足のない頻度になります。指標を記録しておくと、内部監査での説明材料にもなります。

よくある質問

ISMSの構成管理を整備する際に、担当者から寄せられることの多い疑問をまとめました。実務での判断に役立ててください。

ISMSの構成管理と一般的なIT運用の構成管理は何が違いますか？

目的の重心が異なります。一般的なIT運用の構成管理は、安定稼働や効率的な変更管理を主目的とします。ISMSの構成管理（管理策8.9）は、それに加えて情報セキュリティ上の「あるべき構成」を維持し、誤った変更による脆弱性や事故を防ぐことを目的とします。記録や点検の証跡を審査で示せる状態にしておく点も、ISMS文脈ならではの要件です。やること自体は重なりますが、セキュリティ観点と証跡保持が加わると理解するとよいでしょう。

構成管理（8.9）はどの組織も必ず適用しなければならない管理策ですか？

適用の要否は適用宣言書（SoA）でリスクに基づいて判断しますが、ICTシステムを運用する組織では適用が原則です。除外するには、自組織のリスクに照らして不要である合理的な根拠を説明できる必要があります。実務上、サーバやネットワーク、クラウドサービスを使っている組織が構成管理を除外する余地は小さいと考えてください。

構成管理と変更管理はどう違い、どのように連携しますか？

構成管理は「あるべき構成を定義し維持する」活動、変更管理（8.32）は「変更する際の承認・テスト・記録の手続き」です。連携の要点は、構成を変えるときに変更管理のフローを通し、その結果を構成記録に反映することです。変更管理だけだと変更後の構成が記録されず、構成管理だけだと変更の正当性が担保されません。両者をつなぐことで、いつ・誰が・何を承認して変えたかが追跡できます。

CMDBやIaCツールは構成管理に必須ですか？

必須ではありません。管理対象が小規模なら表計算ソフトの台帳でも管理策は満たせます。ツールが有効になるのは、対象が増え変更頻度が高くクラウド構成が頻繁に変わる環境です。重要なのは、承認・記録・点検の運用ルールが回っていることで、ツールはその効率を上げる手段にすぎません。ツール導入を目的化しないことが、形骸化を避ける鍵です。

移行期限が過ぎた今、構成管理の対応は何から始めるべきですか？

移行期限は2025年10月31日で終了しており、現在は2022年版を運用できているかが問われる段階です。まだ構成管理が整っていない場合は、重要システムを対象に構成記録とベースラインを定義し、変更管理の承認フローと結びつけ、定期点検を運用に組み込むところから始めます。既存のIT資産管理台帳に項目を足して発展させると、少ない工数で着手できます。

関連記事

• HCP Terraformとは何か？基礎から理解するクラウドインフラ管理ツール：構成をクラウド上で一元管理し変更履歴を追跡する仕組みを解説しており、構成管理の自動化を検討する際の参考になります。
• DevOps実践者に向けたTerraform v1.14.0アップデートの概要と目的：状態ファイルによる構成の差分管理など、IaCで「あるべき構成」を保つ仕組みの理解に役立ちます。