システム運用で避けられない“変更”のリスク　ITILを参考に「リスクベースアプローチ」で考える

避けては通れない「システム変更」

　システム運用において、「安定稼働」させることは最も重要な課題です。障害が発生してしまうと、利用者がシステムを利用できない事態を招いてしまいます。このような可用性を維持できていない、“情報セキュリティが損なわれた事態”を防ぐためにやるべきことは多くありますが、「構成管理」「変更管理」「リリース管理」は特に重要なポイントだと言えるでしょう。

　本連載の第2回でお伝えしたとおり、システムを安定稼働させるための第一歩は、対象となるシステムに関する構成情報を整理し、正しく、最新の状態で管理することです。

　そして、適切に管理していく上で避けて通れないのが“システムの変更”です。バージョンアップデートや脆弱性パッチの適用、システム障害に対応するための構成の変更、設定変更など、さまざまな“変更”が発生する中、その第一歩として「構成管理」の重要性をお伝えしているのは、このようなシステム変更を実施する際に、対象となるシステムがどのような状態であるかを正しく把握する必要があるためです。

情報セキュリティを維持する「変更管理」の重要性

　たとえば、社内で利用しているクラウドサービスについて、ID・パスワードの認証から、Authenticatorアプリケーション（以下、認証アプリ）を用いた「二要素認証」を必須とする設定に変更する場合を考えてみましょう。

　この変更に必要な作業は、以下です。

1. 利用者自身が事前に、利用しているアカウントに認証アプリを登録
2. 管理者設定で、二要素認証を必須に設定
3. 利用者が再度サインインの手続きを実施

　この設定変更を行う場合、多くのクラウドサービスでは設定変更を実施したとき、自動的にユーザーがサインアウトされてしまいます。つまり、利用者は次回のサービス利用時に認証アプリを用いた二要素認証でのサインインが必須となるのです。そのため、変更作業を実施する管理者は、事前に利用者がアプリケーションを設定できているのか確認しなければなりません。

　利用者ごとの認証設定がまさに「構成情報」に該当しますが、この情報を確認できなければ、変更作業を実施してもよいのか判断がつかない、あるいは判断がしづらいでしょう。仮に、利用者の一部にアプリケーションの設定漏れがある状態で変更してしまうと、利用者がサインインできずにサービスから締め出されます。今まで利用できていたサービスが一時的に利用できない状況は、業務にも大きな影響を及ぼす可能性があります。

　このような事態を防ぐために変更管理のプロセスにおいて、以下の事項を確認しておくことが必要です。

1. 変更するサービスの仕様
2. 変更するサービスの構成情報
3. 変更作業が影響する範囲

　前述の例で言えば、1の「変更するサービスの仕様」とは、アプリケーションを用いた二要素認証を必須の設定にすると自動でサインアウトされ、次回利用時にあらためてサインインしなければいけない、というサービス上の仕様です。2の「変更するサービスの構成情報」は、利用者がアプリケーションを登録しているか、という情報が該当します。また、3の「変更作業が影響する範囲」とは、変更作業直後にもサービスを利用するユーザーを含めた利用者全員がその範囲となります。

　例として挙げた内容は、システムを利用できなくなる“可用性の喪失”に関するものですが、もし変更の内容が誤っている場合、第三者によるアクセスを許してしまう“機密性の喪失”や、予期せぬデータの上書きのような“完全性の喪失”が発生する恐れもあります。クラウドサービスの設定ミスによりデータをパブリックに公開し、機密情報が漏えいした事例は、メディアにもよく取り上げられています。このような情報セキュリティの喪失を未然に防ぐために、システム変更のプロセスを整備することが重要なのです。

　そして、変更管理のプロセスにおいては、変更の必要性が生じた時点で対象となるシステム構成を把握し、それをどのように変更するのかを明確にしておきましょう。その上で、変更にともない影響が生じる範囲やリスクの程度を整理し、その内容をレビュー、承認することで、初めて計画している変更が適用できます。こうした変更管理の徹底こそがシステム変更の誤りによる障害を未然に防ぎ、セキュアなシステム運用につながるのです。