GitHub の変更管理を、ISMS・SOC 2 の証跡として出す方法
公開 5 分で読めます
他の言語: English · 中文 · Español · Français · Deutsch · Português
この記事の要点
- 監査人が見るのは「期間中の変更の一覧」と、そこから抜き出した変更ごとの承認の跡です。
- GitHub ではブランチ保護で「承認なしにマージできない」状態を強制し、管理者も例外にしないことが土台になります。
- スクリーンショットは一時点しか示せません。期間を通した記録を、評価される側が後から書き換えられない形で残すことが要点です。
開発チームが ISMS（ISO/IEC 27001）や SOC 2 の審査を受けると、ほぼ確実に変更管理を聞かれます。コードはすべて GitHub にあり、レビューもしている。それでも「何をどう見せればよいか」で手が止まることが多い領域です。
この記事では、監査人が変更管理で確かめたいことを先に整理し、GitHub 側で整えておく設定と、証跡の残し方を順に説明します。
監査人が変更管理で確かめたいこと
規格の該当箇所は次のとおりです。
| 枠組み | 該当箇所 | 求められていること（要旨） |
|---|---|---|
| ISO/IEC 27001:2022 | 附属書 A 8.32 変更管理 | 情報処理設備や情報システムの変更を、変更管理の手順に従って行う |
| SOC 2 | CC8.1 | インフラ・データ・ソフトウェアの変更を、承認・テストを経て実装する |
どちらも「GitHub でこう設定せよ」とは書いていません。決めた手順どおりに変更が行われたことを、記録で示せるかが問われます。
実際の確かめ方は、多くの場合次の流れになります。
- 観測期間中に本番へ入った変更の一覧を出してもらう
- その一覧から、いくつかの変更を抜き出す
- 抜き出した変更ごとに、作った人とは別の人が承認してから本番に入ったかを確かめる
- 緊急の変更があれば、事後の承認や記録が残っているかを確かめる
つまり必要なのは、期間を通した変更の一覧と、変更ごとの承認の跡です。どちらかが欠けると説明が苦しくなります。
GitHub で整えておく設定
証跡の前に、手順そのものを GitHub の設定で強制しておきます。運用ルールを文書に書くだけでなく、仕組みで破れない状態にしておくと、審査での説明が短くなります。
本番に入るブランチ（main など）に、ブランチ保護またはルールセットで次を設定します。
- マージ前にプルリクエストを必須にする: 直接 push で本番のコードが変わる経路を塞ぐ
- 承認を 1 件以上必須にする: 作った人以外の承認が無いとマージできない
- 新しい push があったら承認を取り消す: 承認後にこっそり変更を足せないようにする
- 管理者も例外にしない: 管理者だけが保護を迂回できると、「全変更が承認を経た」と言えなくなる
- 履歴の強制書き換え（force push）とブランチ削除を禁止する
あわせて、変更管理の手順書に「どのブランチが本番か」「緊急時は誰がどう承認し、事後に何を残すか」を書いておきます。設定と手順書が一致していることも、審査で見られる点です。
スクリーンショットでは足りない理由
よくある証跡の出し方は、プルリクエストの画面やブランチ保護の設定画面をスクリーンショットで撮り、資料に貼る方法です。これには構造的な弱さがあります。
- 一時点しか示せない。 設定画面のスクリーンショットは「撮った瞬間にその設定だった」ことしか示しません。観測期間の途中で一度保護を外し、戻した場合、その事実は写りません
- 日付と出どころを確かめにくい。 画像に写った日付は画像の一部で、いつ・どこから取ったものかを第三者が確かめる手段がありません
- 集めるのに毎回手間がかかる。 抜き出された変更ごとに画面を探して撮る作業は、審査のたびに発生します
監査人の側でも、こうした手作業の証跡より、自動で日付が付き追跡できる記録を求める流れが強まっています。
期間を通して記録を残すには
ポイントは 2 つです。
1. 変更が起きたその時に記録する。 審査の直前に集めるのではなく、push やプルリクエストのマージが起きた時点で、いつ・誰が・何をしたかを記録します。後から集めると、その間に消えたものや変わったものが拾えません。
2. 評価される側が後から書き換えられない形で残す。 GitHub のイベント履歴や監査ログは便利ですが、記録は評価される組織自身が管理するシステムの中にあります。また保持期間には上限があり、プランによっては 6〜12 か月の観測期間を覆えないことがあります。自社のプランでの保持期間は一度確認しておくとよいでしょう。
記録が後から書き換えられていないことを示すには、各記録の指紋（ハッシュ値）を前の記録とつなげていく方法が使われます。途中の 1 件を書き換えると、それ以降のつながりがすべて合わなくなるため、改ざんがあれば検知できます。
SPHIOR でできること・できないこと
SPHIOR の GitHub 連携は、上の 2 点を自動で行います。
- push やプルリクエストの作成・マージといった出来事を、発生した時点で記録します
- 記録には、出来事の種類・実行した人・発生時刻と、GitHub から届いた内容全体の指紋を含めます。内容そのものは保存しません
- 記録は指紋どうしをつなげた形で封緘され、改ざんがあれば検知できます。検証用のパックを書き出し、自分で確かめることもできます
一方で、次の点は SPHIOR では補えません。
- レビューの承認操作そのものは、現在は記録の対象外です。 承認は上で述べたブランチ保護の設定で「承認なしにはマージできない」状態を強制し、その設定と手順書で説明してください
- 監査の合否を判定するものではありません。 SPHIOR が出すのは、監査人に示すための補助的な証跡です
無料枠では記録を 90 日間保持します。観測期間全体の記録が必要になった時点で、保持期間の長いプランに切り替えられます（料金）。
まとめ
- 変更管理で問われるのは、期間中の変更の一覧と、変更ごとの承認の跡
- GitHub ではブランチ保護で承認を強制し、管理者も例外にしない
- スクリーンショットは一時点しか示せない。出来事が起きた時に、書き換えられない形で記録するのが確実
審査の直前に慌てて画面を撮らずに済むよう、記録は審査よりずっと前から始めておくのが近道です。