ISMSで重要な構成管理とは？初心者向けに押さえるべき手順・具体例・運用ポイントを解説
- 【監修者】金光壮太(ISOトラストのコンサルタント)
- 3月19日
- 読了時間: 13分
▼ 目次
1. はじめに
1.1. 記事の目的と想定読者
本記事では、ISMS（情報セキュリティマネジメントシステム）を導入または運用する上で欠かせない「構成管理」について、初心者でも分かるように解説します。企業の情報資産が増え、業務システムやクラウドサービスなどが複雑化する中で、構成管理をしっかり行うかどうかが、セキュリティリスクや外部審査の結果に大きく影響します。
想定読者
これからISMSを導入し、どのように情報資産を管理すればよいか悩んでいる担当者
すでにISMSを運用中だが、ネットワーク構成やシステム変更が管理しきれていないと感じる管理者
外部審査で「構成管理の不備」と指摘された、またはそのリスクを感じている企業
1.2. なぜISMSで構成管理が重要なのか？
ISMSの目的は「情報資産を守るための仕組み」を整えることです。しかし、保護すべき「情報資産」が何なのかを明確にし、日々の変更も正しく追わないと、どこにリスクがあるか把握できません。
私がコンサルで見てきた例でも、システム障害や漏えいインシデントの原因をたどると、「誰も把握していなかったサーバー」や「放置されていた古い機器」が不正アクセスやトラブルの発端だったということがしばしば。
構成管理を適切に行うことで、変更点を常に把握し、リスクアセスメントやインシデント対応がスムーズになるのです。
1.3. 本記事で得られるメリット（初心者が押さえるべき手順・具体例・運用ポイント など）
構成管理の基本を理解し、ISMSで求められる理由が分かる
導入・運用手順をステップごとに学び、現場で使える具体例を把握できる
運用上の注意点やトラブル事例を知ることで、不備や不適合を防ぐ
内部監査・外部審査でも評価される管理体制づくりができる
2. ISMSにおける構成管理の基本概念
2.1. 構成管理とは？システムや情報資産を正しく把握・管理する仕組み
構成管理: 組織が保有・利用しているハードウェア、ソフトウェア、ネットワーク、データなどの「構成要素」を明確にし、変更やバージョンアップなどがあった場合に正確に記録し追跡する仕組みのこと。
目的: 何がどこに、どのバージョンで存在しているかを把握することで、トラブル発生時の原因特定やリスク評価をスムーズに行う。
2.2. ISO27001（ISMS）で求められる構成管理の背景（附属書Aや要求事項との関連）
ISO27001の附属書Aには、資産管理や変更管理など構成管理に関連する項目が多数含まれます。
例えば**A.8（資産管理）**は「情報資産を特定し、責任を明確に」と求めており、この資産を正しく把握することが構成管理の一部といえます。
2.3. コンサル視点：構成管理を怠ることで生じるリスク・不適合例
不適合例: 「実際には使われていない古いサーバーが存在→ OSの脆弱性が放置され、不正侵入される」「社内で機器を増やすたびに台帳が更新されず、外部審査で重大指摘を受ける」など。
対策: 常に更新するルールと担当者の明確化が必須。
3. 構成管理が必要になる主な場面・実務の具体例
3.1. システム変更やバージョンアップ時の管理
例: OS更新、ソフトウェアアップデート、サーバー追加・廃止など→ 変更プロセスが曖昧だと誰も知らないままシステム構成が変わり、脆弱性が生じる。
ポイント: 変更申請・承認フローを整え、台帳を同時に更新。
3.2. ネットワーク構成やサーバー台数・場所の正確な把握
ネットワーク図: ルーターやスイッチの設定、IPアドレス割り当てなどを常に更新→ トラブル時も対応が早い
サーバー台数: 仮想マシンを増設するとき、リストに反映されず“幽霊サーバー”が起きがち→ 危険
3.3. クラウド利用状況・外部委託先システムの把握
クラウド: AWS、Azureなどでインスタンス増減が容易→ 構成が流動的になりがち
外部委託先: ベンダーが管理するシステム含め、どの範囲が自社の責任でどの範囲が委託先かをリスト化
3.4. 他社事例：構成を見誤り、インシデント対応が遅れた事例と教訓
事例: ある企業が攻撃を受けた際、実際には利用されていないサーバーが侵入経路→ 誰もそのサーバーを把握しておらず対応が遅れ、被害拡大
教訓: 定期棚卸しやリストの更新は必須
4. 初心者向け：構成管理を始めるための押さえるべき手順
4.1. ステップ1：情報資産を洗い出す（ハードウェア・ソフトウェア・データなど）
手順: 全部門にヒアリングし、サーバー・PC・ルーター・アプリケーション・データベースなどをリスト化
ポイント: 使われなくなった機器やシステムも一旦把握し、残す／廃棄を検討→ 後日のリスク低減
4.2. ステップ2：ラベリング・分類（重要度、機密度で振り分け）
例: 「機密度A（個人情報含む）」「機密度B（一般ビジネス情報）」などで分類
ISMS視点: クラス分けすることでリスクアセスメントや保護レベルの設定が簡単になる
4.3. ステップ3：台帳・リスト化の作成（Excelやツール活用で可視化）
Excel: 小規模のうちはExcel台帳がコストも低く運用しやすい
専用ツール: CMDB（Configuration Management Database）を導入すると、大規模環境でも管理が効率的に
4.4. ステップ4：変更管理プロセスの定義（申請・承認・反映ルールの明文化）
例: サーバー追加やアプリ更新を行う際は「申請書作成→ 管理者承認→ リスト更新→ 実施→ 完了報告」のフローを明確化
コンサル経験: このプロセスが曖昧な企業ほど、外部審査で「誰が変更を承認したの？」と質問され不適合に
4.5. ステップ5：定期的な棚卸し・監査で最新状態を維持
定期棚卸し: 半年や年1回など期間を決めて実地確認→ リストと現物を照合
内部監査: ISMS要求事項に沿って、変更履歴やデータが正しく更新されているかをチェック
5. 構成管理の具体例：どんな情報をどのように管理する？
5.1. ハードウェア例：サーバー名、IPアドレス、設置場所、OSバージョンなど
ポイント: 何台のサーバーがどの場所に置かれ、OSが何なのか？IPアドレスや保守契約期間も記録→ 障害時や更新時に迅速に対応
コンサル視点: 複数拠点・データセンターを持つ企業は特に慎重に
5.2. ソフトウェア例：アプリケーション名、ライセンス情報、更新履歴
例: 社内で購入したOfficeライセンス数、プロジェクト管理ツールのバージョン、保守期限など
メリット: ソフト更新漏れが減り、脆弱性放置を回避。監査でも正確性が評価
5.3. データ・文書例：顧客情報DB、機密文書のバージョン管理、バックアップ状況
実務: 「顧客DBの保存先、暗号化状況、バックアップ取得先・頻度」などを構成管理の一部として記録
利点: 情報漏えい対策やDR（災害復旧）計画を立てやすい
5.4. 小規模環境から始める場合の管理項目を厳選するコツ
コンサルアドバイス: 最初から全項目を管理すると負担大→ まずは重要機器・システムを中心にリスト化し、徐々に拡大
6. 運用ポイント：ISMSの要件に沿った構成管理を行うためには？
6.1. 管理責任者・担当者の明確化（誰がリストを更新し、承認するか）
例: システム管理者が変更管理リストを更新、管理責任者が承認し、最終的に文書化
コンサル経験: 人事異動が頻繁な企業では担当者が不明になりがち→ 文書化と周知が重要
6.2. 変更履歴の記録（アップデートや機器追加・廃棄時の手順）
手順: 申請→ 承認→ 実施→ リスト更新→ レビューまでを短い流れで確実に行う
ポイント: 更新日・更新者名も残すことで、「誰がいつ変更したか」がわかる
6.3. インシデントとの関連：構成情報が不正確だとリスク評価や対応が遅れる
事例: 不審アクセスを検知しても、対象サーバーがリストになく対処が数日遅延→ 被害拡大
対策: 構成管理とインシデント対応マニュアルを連動させ、最新版リストをすぐ参照可能に
6.4. 内部監査・外部審査でチェックされる主要項目とは？
例: 「資産台帳は最新か？」「変更管理の手順書は運用されているか？」「廃棄機器がリストから削除されているか？」
コンサル視点: このポイントを押さえれば審査での大きな不適合指摘を防げる
7. リスク評価と構成管理の連動：どのように結びつけるか
7.1. システム構成の変更がリスクレベルに与える影響
考え方: 新しいサーバーを追加→ 新たな脆弱性や運用負荷が発生→ リスクアセスメントを更新して対応策を検討
コンサル談: 変更前にリスクを軽く見積もってしまい、実際には大きい脆弱性が放置された例が多い
7.2. リスクアセスメント表への反映方法：変更時の更新手順
フロー: 変更計画書→ リスク評価（脆弱性・影響度）→ 対策策定→ 実施→ 構成管理リスト更新
結果: 資産管理とリスク管理が一体化し、セキュリティの穴が出にくい
7.3. 他社事例：構成管理を活かし、新機能追加時のセキュリティリスクを早期に把握・対処したケース
事例: IT企業B社がモバイルアプリ連携を追加→ 変更管理でリスク評価→ 事前に2段階認証を導入し、運用中のトラブルを未然に防いだ
8. 運用効率を高めるツール・仕組み
8.1. CMDB（Configuration Management Database）導入のメリット・注意点
CMDB: 構成情報を一元管理するデータベース。関係性や属性を可視化できる
メリット: 大規模環境でも構成変更を追いやすく、変更履歴を自動取得できる
注意点: ツール導入にコストがかかる、一度に全て登録しようとすると混乱する
8.2. バージョン管理システム（Gitなど）との連携でソフトウェア変更を追跡
実務例: ソフトウェア開発でソースコードをGit管理→ どのコミットがどのバージョンに対応するかが明確
利点: インシデントや不具合時に「いつ・誰が・何を」変更したかすぐ確認
8.3. クラウドサービス（SaaS型管理ツール）での一元管理
サービス例: AWSやAzureのインフラを自動スキャンして構成図を作成するツールなど
メリット: 自動更新で最新状態を保ちやすい、運用コストを削減
失敗例: ツール任せで運用ルールを整備しなかった→ 混乱や不適合が発生
8.4. 失敗例：ツール導入に頼りすぎて人手のルール整備が不十分→ 審査で不適合
背景: CMDBを導入したが、担当者が更新を忘れてデータが古い
教訓: ツールはあくまで補助。最後は人とルールがしっかり運用しないと無意味
9. 成功事例：構成管理を徹底してISMS運用を強化した企業の実例
9.1. 製造業A社：複雑なネットワークを定期棚卸しし、外部審査で不適合ゼロ
内容: 海外工場含めネットワークが複雑→ 半年に1度、拠点ごとに実機確認とリスト更新
効果: ISMS外部審査で「構成が正確、変更履歴が明確」と高評価→ 不適合ゼロ合格
9.2. IT企業B社：テスト環境も含めた詳細な構成管理でインシデント対応を迅速化
運用: 本番とテスト環境両方のサーバーを1つのCMDBで管理→ 問題発生時に対象サーバーを即特定
成果: インシデント対応時間が約半分に短縮、顧客満足度も向上
9.3. サービス業C社：クラウド移行時の構成整理が功を奏し、運用負荷と漏えいリスク大幅減
背景: クラウド化でリソースが増減→ 構成管理リストで都度更新→ 不要リソースを即把握し削除
結果: 無駄なサーバーコストを削減、セキュリティ事故ゼロを継続中
10. よくある失敗パターン・不適合事例とその対策
10.1. リストや台帳が古いまま放置→ 実際の構成と乖離
原因: 変更のたびに更新する担当が不在、ルール化されていない
対策: 承認フローの最後に「台帳更新」を必須ステップとして設定
10.2. 変更管理フローが明確でない→ 無許可変更が横行し、トラブル頻発
事例: システム担当が勝手にサーバー設定を変え、他部署に影響→ 原因究明に時間
解決: 承認前に変更できない仕組み（権限制御、申請書）をシステムで運用
10.3. バックアップ機器やテストサーバーを構成管理から除外→ 審査時に重大指摘
背景: 「テスト用だから」とリストに載せていなかった→ 外部審査で「運用環境と同様に扱うべき資産」と指摘
コンサル視点: テスト環境こそ情報漏えいの温床になりやすい→ 構成管理対象に必ず含める
10.4. 対策：変更管理ガイドライン整備、定期監査、社内周知の徹底
具体例: ガイドラインに「サーバー名変更は何日前までに申請」「誰が承認」などを明確にし、毎月の社内会議で周知→ 不適合が大幅減
11. Q&A：ISMS構成管理に関する疑問と回答
11.1. 「小規模企業でも構成管理は必須？シンプルな始め方は？」
回答: はい、規模に関係なく重要。まずはExcelで簡単な台帳を作り、変更があれば必ず更新→ 運用負荷を少なく始められる
11.2. 「クラウド環境下での構成管理はどうする？」
回答: AWSやAzureのEC2インスタンスやVNet、S3バケットなどを一覧化。クラウドコンソールとの連携ツールを使うと楽。
注意: 自動スケーリングやサーバーレスで常に変動する場合、定期スキャンツールを導入する企業が多い
11.3. 「暗号化やネットワークセグメントなど技術要素との関係は？」
回答: 構成管理は「どこが暗号化されているか」「どのネットワークセグメントがどの機器を含むか」も含む→ リスク評価やインシデント対応に直結
11.4. 「内部監査で構成管理を見直す際、審査員はどこを見る？」
回答: 主に「台帳が最新か」「変更管理フローが実運用されているか」「不要機器が放置されていないか」「テスト環境も含めて把握されているか」をチェック
12. まとめ：ISMSで重要な構成管理とは？初心者向けに押さえるべき手順・具体例・運用ポイントを解説
12.1. 記事の総括：構成管理がISMS運用を下支えし、情報資産を守るカギ
要点: 何がどこにあるか正確に知り、変更時にもそれを追跡→ リスク評価やインシデント対応が迅速に。
外部審査でも、構成管理がしっかりしていると不適合が出にくい。
12.2. まずは手動でもリスト化し、定期更新→ 規模に応じてツール導入を検討
手順: 小さな環境ならExcel台帳、変更申請フローの簡易化などからスタート
発展: 大規模化に合わせ、CMDBや自動スキャンツールを導入→ コストとメリットを見合いで判断
12.3. 最後のメッセージ：正確な構成把握がリスク低減と監査合格につながる
行動: 月1回または年2回など棚卸しを行い、リストにズレがないか確認。変更管理手順を社内に周知し、誰もが勝手に変更しない体制づくりを
結論: 構成管理の徹底が、ISMS全体を支え、企業の信用やリスク低減に大きく貢献します
おわりに
ISMS（情報セキュリティマネジメントシステム）で安心して情報資産を運用するためには、構成管理が欠かせません。
正確で最新の情報を把握していれば、システム変更や新機能追加、トラブル対応の際にも混乱を最小限に抑えられます。
本記事を参考に、ぜひ構成管理に取り組み、ISMS運用をさらに強固にしていただければ幸いです。
この記事の監修者情報
金光壮太 (ISOコンサルタント)
大手商社にて営業を経験した後、ISOコンサルティングに従事。ISO9001、14001、27001を中心に、各業界の課題や特性に応じたシステム構築や運用支援を行い、企業の業務効率化や信頼性向上に貢献。製造業や建設業など、多岐にわたる業界での豊富な経験を活かし、お客様のニーズに応じた柔軟なソリューションの提案を得意としている
Comments