システムを変更するときや構成を把握するときにも、セキュリティの視点は欠かせません。この回では、変更管理と構成管理がなぜセキュリティに直結するのかを学びます。
紺野 アキ
システムって、一度作ったら終わりじゃなくて、ずっと変更が入るんだよね?
銀城 ナディア 先生
そうよ。
機能追加やパッチ適用、設定変更など、変更は日常的に発生するわ。
でも、無計画な変更は障害やセキュリティホールの原因になるの。
だから変更管理のルールが必要なのよ。
灰原 さや
変更管理では、変更の申請・影響範囲の評価・承認・実施・記録という手順を踏みますね。
誰かが勝手に本番環境を触ることを防ぎます。
紺野 アキ
勝手に変更しちゃダメなの? 早く直したいときもあるじゃん。
銀城 ナディア 先生
気持ちはわかるけど、承認なしの変更は危険なの。
例えばファイアウォールの設定を確認せず変更すると、意図せず外部に穴を開けてしまうかもしれない。
だから変更前に影響範囲を評価して承認を得ることが必須なのよ。
薔薇崎 ねむ
もし変更して、うまくいかなかったらどうするんですかぁ?
銀城 ナディア 先生
そのために切戻し(ロールバック)の手順をあらかじめ決めておくの。
変更前の状態に戻せるようにしておけば、問題が起きても被害を最小限にできるわ。
灰原 さや
変更を安全に行うには、いきなり本番でなくテスト環境で事前検証することも大切ですね。
本番と切り離した環境で試してから適用します。
紺野 アキ
じゃあ「構成管理」っていうのは何が違うの?
銀城 ナディア 先生
構成管理は、システムがどんな機器・ソフトウェア・バージョンで構成されているかを正確に把握・記録することよ。
何がどこにあるかわからないと、脆弱性が公表されても「自社に該当する機器があるか」を判断できないでしょう?
灰原 さや
管理対象を構成品目(CI)として台帳に登録し、常に最新の状態に保ちます。
これができていると、脆弱性対応やパッチ適用の対象をすぐに特定できますね。
薔薇崎 ねむ
台帳と実物がズレていたら、困っちゃいますねぇ。
銀城 ナディア 先生
そうなの。
管理されていない機器、いわゆる野良端末(シャドーIT)があると、そこがセキュリティの穴になるわ。
だから構成情報を正確に維持することが、確実な脆弱性対応の土台になるのよ。
紺野 アキ
変更管理で安全に変えて、構成管理で正確に把握する。
両方あってこそセキュリティが守れるんだね!
銀城 ナディア 先生
そのとおり。
変更管理と構成管理は車の両輪よ。
きちんと運用すれば、変更に伴うリスクを抑えつつ、脆弱性にも素早く対応できるようになるわ。
確認クイズ
情報システムのセキュリティを維持するための変更管理の手順として、最も適切なものはどれか。
- 緊急の変更は迅速性を優先し、承認を省略して担当者の判断で本番環境に適用する
- 変更の影響範囲を評価して承認を得たうえで実施し、切戻し手順も準備しておく
- 変更内容は担当者のみが把握すればよく、記録は残さず口頭で引き継ぐ
- 本番環境で直接変更を試し、問題があればその場で修正を繰り返す
こたえを見る
正解: 2. 変更の影響範囲を評価して承認を得たうえで実施し、切戻し手順も準備しておく
変更は影響範囲を評価し承認を得て実施し、切戻し手順を準備しておくのが適切。これにより変更に伴うリスクを管理でき、失敗時にも元へ戻せる。緊急時でも承認プロセス(緊急変更の簡易承認など)を通すのが原則で、承認を完全に省略するのは不適切。変更内容を記録せず口頭引き継ぎだけにすると、後から追跡や検証ができず不適切。本番環境で直接試すのは障害やセキュリティ事故を招くため、テスト環境での事前検証が正しい。
