本番環境の変更管理。承認と記録をどう残すか

本番環境の変更管理は、申請・承認・テスト・リリース・記録の流れを決め、プログラムを作る人と本番に反映する人の役割を分けることが基本です。そのうえで、急ぎの修正をどう扱うかと、記録をどこに残すかを決めておくと、運用と監査の両方に耐える形になります。

変更管理とは

変更管理とは、システムの設定やプログラムを変えるときに、だれが、なぜ、何を変えるかを決めた手順で扱い、承認と記録を残すことです。目的は、意図しない変更や、確かめていない変更で障害や誤りが起きるのを防ぐことと、何が変わったのかを後からたどれるようにすることです。

経済産業省の「システム管理基準」（2023年4月26日改訂）は、運用の段階の管理の項目に「運用における構成管理・変更管理」を置き、変更計画にしたがって変更が行われていること、リリース計画にしたがって本番環境へのリリースが行われていることを、目標として示しています。

出典：システム管理基準（経済産業省、2023年4月26日）

財務報告に関わるシステムでは、変更管理はIT全般統制の主な領域の一つです。金融庁の実施基準では、システムの開発・調達・変更について、事前に所定の承認を得ていること、導入の前に十分な試験が行われていることなどが、監査人がIT全般統制を検討するときの例として挙げられています。

出典：財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）（金融庁、2023年4月7日）

変更は、どんな流れで扱うか

変更の流れは、次の5つの段階で考えると整理できます。

1. 申請：変える理由、変える内容、影響の範囲、元に戻す方法を書く
2. 承認：システムの持ち主や管理の責任者が、内容と影響を確かめて承認する
3. テスト：本番とは別の環境で動きを確かめ、結果を残す
4. リリース：承認された内容だけを、決めた手順で本番に反映する
5. 記録：何を、いつ、だれが反映したかを残し、申請とつなげる

本番、確認用、開発用の環境を分けておくことが、テストの段階の前提になります。本番で直接直してから確かめる、という進め方では、承認とテストの記録が残りません。

申請に書いておきたいこと

申請の書き方は、細かすぎても続きません。変える理由、変える対象、影響する業務、テストの方法、元に戻す方法の5つがあれば、承認する人が判断できる形になります。課題の管理の仕組みやチケットで申請を受けると、後の段階の記録とつなげやすくなります。

作る人と反映する人は、分けるべきか

職務分掌とは、一人の人が一連の作業をすべて行えないように、役割を分けることです。変更管理では、プログラムを作る人と、本番に反映する人を分けることが、基本の考え方とされています。作った本人が、だれの確認も受けずに本番を変えられる状態では、誤りにも不正にも気づきにくいためです。

ただ、人数の少ない会社では、作る人と反映する人を分けるのが難しいこともあります。その場合は、次のような方法で補うことが考えられます。

補う方法を選んだ場合は、なぜ分けられないのか、何で補っているのかを書き残しておくと、監査で説明しやすくなります。

緊急の変更は、どう扱うか

障害の復旧や、急ぎの脆弱性への対応では、ふだんの承認を待てないことがあります。緊急の変更を禁じると、手順の外で直されることにもなりかねないため、緊急の変更の手順も別に決めておきます。

• 緊急に当たる条件を決める（障害で業務が止まっている、など）
• だれが判断して反映してよいかを決める
• 反映の後、決めた期間のうちに申請と承認の記録をそろえる（事後の承認）
• 緊急の変更の件数と中身を定期に見直し、ふだんの手順で扱えるものが紛れていないかを確かめる

緊急の変更が多い場合は、ふだんの手順が重すぎるか、テストが足りていない合図のこともあります。

CI/CDの記録は、監査の証拠になるか

CI/CDとは、プログラムの変更のたびに、テストと本番への反映を自動で行う仕組みです。CI/CDを使うと、手作業の反映に比べて、記録が自動で、しかも後から書き換えにくい形で残ります。変更管理の証拠としても使いやすい仕組みです。

使える記録の例です。

ただし、仕組みがあっても、設定しだいで承認を飛ばせたり、管理者が直接本番を変えられたりすることがあります。監査では、承認なしに本番へ反映できない設定になっているか、その設定を変えられる人はだれか、仕組みの外で本番を変えた形跡がないか、もあわせて確かめられることが一般的です。リリースとデプロイの手順を、仕組みの設定として固めておくと、記録と実際の動きがそろいやすくなります。

監査では、どう確かめられるか

システム監査や内部統制の評価では、一定の期間の変更の一覧から何件かを選び、それぞれに申請、承認、テストの結果、反映の記録がそろっているかをたどる、という確かめ方がよく使われます。あわせて、本番の変更の履歴（サーバーやクラウドのログ）から、申請のない変更が紛れていないかを照らし合わせることもあります。

そのため、申請の番号と反映の記録をつなげておきます。プルリクエストやデプロイの記録に申請のチケット番号を書く決まりにすると、変更の一覧から申請へ、申請から反映へと、どちらの向きにもたどれるようになります。上場の準備での確認点は上場準備で整えるIT全般統制、アクセス権の管理はアクセス権の棚卸しと特権IDの管理の進め方でも扱っています。

つまずきやすい点

変更管理の手順があっても、次のような点で記録が途切れることがあります。

• データベースの値を直接直す作業（データの修正）が、変更の手順の対象から外れている
• クラウドの管理画面での設定の変更が、プログラムの変更と別に扱われ、記録が残っていない
• 委託先が行った変更が、自社の申請と結び付いていない
• テストの結果は残っているが、どの版をテストしたかが分からない

データの修正や設定の変更も、本番の状態を変える作業です。プログラムと同じ手順で扱うか、別の手順を決めて、承認と記録を残せるようにしておきます。変更の手順の対象を書き出しておくと、どこまでが変更管理の範囲かを、担当の間でそろえやすくなります。

当社のご支援

アメリア・テクノロジーのシステム監査では、変更の手順と、実際の変更の記録を照らし合わせ、承認とテストの記録が残っているか、職務の分け方とその補い方が働いているかを確かめます。当社が開発・運用に関わったシステムは監査の対象にしません。改善のための開発や運用は監査とは別の担当が行い、どこに頼むかはお客様が自由に決められます。