リポジトリからの機微なデータの削除

機密データをリポジトリの履歴から削除できるのは、あなたがクローンを行った全員と慎重に調整することができて、副作用を管理する意思がある "場合のみ" です。__

この記事の内容

リポジトリからの機密データの削除について

git filter-repo などのツールを使ってリポジトリの履歴を変更する場合、その影響を理解することが重要です。 履歴の書き換えを成功させるには、コラボレーターとの慎重な調整が必要であり、管理する必要がある多くの副作用を伴います。

多くの場合、削除する必要がある機密データがシークレット (パスワード、トークン、資格情報など) である場合、最初の手順として、そのシークレットを失効させたり、ローテーションしたりする必要があることに注意してください。 シークレットが失効されるかローテーションされると、アクセスには使用できなくなりますが、問題を解決するには十分な場合があります。 履歴を書き換えてシークレットを削除するために追加の手順を実行しても、保証されない場合があります。

履歴を書き換えることによる副作用

履歴の書き換えには多くの副作用があります。次に例を示します。

  • 再汚染の高いリスク: 残念ながら、機密データをリポジトリに再プッシュして、さらに大きな混乱が起こることはよくあります。 他の開発者が書き換え前のクローンを持っていて、書き換え後に単に git pull に続いて git push を実行した場合、機密データが返されます。 クローンを破棄して再クローンするか、まずクローンをクリーンアップするために複数の手順を慎重に実行する必要があります。
  • 他の開発者の作業が失われるリスク: クリーンを試みている間に他の開発者が機密データを含むブランチの更新を続けた場合、クリーンをやり直すか、その作業を破棄する必要があります。
  • 変更されたコミット ハッシュ: 履歴を書き換えると、機密データを導入したコミットのハッシュ "と" その後のすべてのコミットが変更されます。__ コミット ハッシュが不変であることに依存するツールや自動化は、動作しなくなったり、問題が発生したりする可能性があります。
  • ブランチ保護の課題: 強制プッシュを防ぐブランチ保護がある場合、機密データを削除するには、それらの保護を (少なくとも一時的に) 無効にする必要があります。
  • 中止された pull request の差分ビューの破損: 機密データを削除するには、pull request の diff ビューの表示に使われる内部参照を削除する必要があるため、これらの diff は表示できなくなります。 これは、機密データを導入した PR だけでなく、機密データ PR がマージされた後のバージョンの履歴に基づいて構築されるすべての PR にも当てはまります (その後の PR が機密データを含むファイルを追加または変更しなかった場合でもそうです)。
  • 開いている pull request との連携が不十分: コミット SHA が変更されると、別の PR diff が生じ、古い PR diff に対するコメントが無効になって失われる可能性があります。その結果、作成者やレビュー担当者が混乱する可能性があります。 リポジトリからファイルを削除する前に、開いているすべての pull request を結合または閉じることをお勧めします。
  • コミットとタグのシグネチャが失われる: コミットまたはタグのシグネチャはコミット ハッシュに依存しています。コミット ハッシュは履歴の書き換えによって変更されるため、シグネチャは無効になり、多くの履歴書き換えツール (git filter-repo を含む) では単にシグネチャが削除されます。 実際、git filter-repo の場合、機密データの削除より前の日付のコミット シグネチャとタグ シグネチャも削除されます (技術的には、必要に応じて --refs オプションを git filter-repo に設定することでこれを回避できますが、その場合は、履歴に機密データが含まれているすべての参照を指定し、その範囲に機密データが含まれているコミットを含めるように注意する必要があります)。
  • 他のユーザーを機密データに直接誘導する: Git は、悪意のある個人が気付かれることなくサーバーに侵入して履歴を変更できないように、コミット識別子に暗号チェックを組み込むように設計されています。 これはセキュリティの観点からは役立ちますが、機密データの観点から見ると、機密データの消去は非常に複雑な調整のプロセスであることを意味しています。さらに、履歴を変更すると、既存のクローンを持っている知識豊富なユーザーであれば、履歴の相違に気付き、それを利用して、中央リポジトリから削除したクローン内にまだ残っている機密データを短時間で簡単に見つけることができることを意味します。

機密データの公開について

リポジトリから機密データを削除するには、次の 4 つの大まかな手順が必要です。

  • git-filter-repo を使ってリポジトリをローカルで書き換える
  • ローカルで書き換えられた履歴を使って GitHub 上のリポジトリを更新する
  • 同僚と連携して、存在する他のクローンをクリーンアップする
  • 再発を防ぎ、将来の機密データの流出を回避する

履歴を書き換えてフォース プッシュするだけの場合、機密データを含むコミットは他の場所からアクセスできる可能性があります。

  • リポジトリのクローンまたはフォーク内
  • GitHub のキャッシュされたビューで SHA-1 ハッシュを直接介して
  • それらを参照するプル リクエストを通じて。

リポジトリにある他のユーザーのクローンやフォークから機密データを削除することはできませんが、GitHub 上のキャッシュされているビューや、pull request での機密データへの参照は、GitHub サポート ポータル に連絡して完全に削除することができます。

Important

GitHub Support は非機密データを削除せず、影響を受ける認証情報をローテーションすることではリスクを軽減できないと判断した場合にのみ、機密データの削除を支援します。

機密データを導入したコミットがフォークに存在する場合は、引き続きそこでアクセスできます。 フォークのオーナーと調整し、機密データを削除するかフォークを完全に削除するように依頼する必要があります。 GitHub はこれらのオーナーの連絡先情報を提供できません。

リポジトリの履歴を書き換える場合は、これらの制限事項と課題を考慮して決めてください。

git-filter-repo を使ってリポジトリの履歴からファイルを削除する

Warning

変更の一時退避後に git filter-repo を実行すると、その他の stash コマンドを使用して変更を取得できなくなります。 git filter-repo を実行する前に、行ったすべての変更の一時退避を解除することをお勧めします。 最後に一時退避した一連の変更の一時退避を解除するには、git stash show -p | git apply -R を実行します。 詳細については、「Git ツール - 一時退避とクリーニング」を参照してください。

git filter-repo の動作を説明するために、リポジトリの履歴から機密データを含むファイルを削除し、それを .gitignore に追加して確実に、誤って再コミットされないようにする方法を示します。

  1. git filter-repo ツールの最新リリースをインストールします。 git-filter-repo は手動で、またはパッケージ マネージャーを使用してインストールすることができます。 たとえば、HomeBrew でツールをインストールするには、brew install コマンドを使用します。

    brew install git-filter-repo

    詳細については、newren/git-filter-repo リポジトリ内の INSTALL.md ファイルを参照してください。

  2. 履歴に機密データを含むリポジトリのローカル コピーがまだない場合は、ローカル コンピューターにリポジトリをクローンします。

    $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
> Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/
> remote: Counting objects: 1301, done.
> remote: Compressing objects: 100% (769/769), done.
> remote: Total 1301 (delta 724), reused 910 (delta 522)
> Receiving objects: 100% (1301/1301), 164.39 KiB, done.
> Resolving deltas: 100% (724/724), done.

  3. リポジトリの作業ディレクトリに移動します。

    cd YOUR-REPOSITORY

  4. 次のコマンドを実行します。PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA は、ファイル名だけでなく、削除するファイルへのパスに置き換えてください。 これらの引数では、次のことが行われます。

    • すべてのブランチとタグの履歴全体を Git に強制的に処理させるが、チェックアウトはしない

    • 指定されたファイルと、結果として生成された空のコミットをすべて削除する

    • リモート URL など、 .git/config ファイルに格納されている一部の構成を削除する。 後で復元するために、このファイルを事前にバックアップすることができます。

    • 既存のタグを上書きする

        $ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
  Parsed 197 commits
  New history written in 0.11 seconds; now repacking/cleaning...
  Repacking your repo and cleaning out old unneeded objects
  Enumerating objects: 210, done.
  Counting objects: 100% (210/210), done.
  Delta compression using up to 12 threads
  Compressing objects: 100% (127/127), done.
  Writing objects: 100% (210/210), done.
  Building bitmaps: 100% (48/48), done.
  Total 210 (delta 98), reused 144 (delta 75), pack-reused 0
  Completely finished after 0.64 seconds.

      Important

       (移動または名前が変更されたため) 他のパスに機密データが使用されたファイルが存在する場合は、これらのパスでもこのコマンドを実行する必要があります。

  5. リポジトリの履歴から必要なものをすべて削除したことをダブルチェックします。

  6. git filter-repo ツールによって、構成済みのリモートが自動的に削除されます。 git remote set-url コマンドを使用すると、リモートが復元され、OWNER と REPO はリポジトリの詳細で置き換えられます。 詳しくは、「リモートリポジトリを管理する」をご覧ください。

    git remote add origin https://github.com/OWNER/REPOSITORY.git

  7. リポジトリの状態に問題がなく、リモートの設定を適切に完了したら、ローカルの変更を強制プッシュして、GitHub.com 上のリポジトリを上書きします。 コミットの履歴から機密データを削除するには、強制プッシュが必要です。

    $ git push origin --force --all
> Counting objects: 1074, done.
> Delta compression using 2 threads.
> Compressing objects: 100% (677/677), done.
> Writing objects: 100% (1058/1058), 148.85 KiB, done.
> Total 1058 (delta 590), reused 602 (delta 378)
> To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

  8. タグ付けされたリリースから機密ファイルを削除するには、Git タグに対して強制的にプッシュする必要もあります。

    $ git push origin --force --tags
> Counting objects: 321, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (166/166), done.
> Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done.
> Total 321 (delta 124), reused 269 (delta 108)
> To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

GitHub

からデータを完全に削除する

git filter-repo を使って機密データを削除し、変更を GitHub にプッシュした後は、さらにいくつかの手順を実行して、GitHub からデータを完全に削除する必要があります。

  1. GitHub サポート ポータル にお問い合わせいただき、GitHub の pull request 内のキャッシュされたビューと機密データへの参照を削除するよう依頼してください。 リポジトリの名前と削除する必要があるコミットへのリンクの一方または両方を指定してください。

    Important

    GitHub Support は非機密データを削除せず、影響を受ける認証情報をローテーションすることではリスクを軽減できないと判断した場合にのみ、機密データの削除を支援します。

  2. 以前の (汚染された) リポジトリの履歴から、作成したブランチをマージ ではなく、リベースするようにコラボレーターに指示します。 マージコミットを 1 回でも行うと、パージで問題が発生したばかりの汚染された履歴の一部または全部が再導入されてしまいます。

将来にわたって誤ったコミットを回避する

共同作成者による誤ったコミットを防ぐことは、機密情報が公開されるのを防ぐのに役立ちます。 詳しくは、「organization でのデータ 漏洩を防ぐためのベスト プラクティス」をご覧ください。

共有すべきではないものをコミットまたはプッシュしないようにするために、いくつかの対策があります。

  • git で追跡すべきではない機密データがファイル内で見つかる可能性がある場合は、そのファイル名を .gitignore に追加します (そして、他の開発者を守るために、その変更を必ずコミットして .gitignore にプッシュします)。
  • コードにシークレットをハードコーディングしないでください。 実行時にシークレットを管理および挿入するには、環境変数またはシークレット管理サービス (Azure Key Vault、AWS Secrets Manager、HashiCorp コンテナーなど) を使います。
  • 機密データのコミット前またはどこかにプッシュされる前にチェックするコミット前フックを作成するか、コミット前フックで git-secrets や gileaks などのよく知られたツールを使います (各コラボレーターに対して、選んだコミット前フックを設定するように必ず依頼してください)。
  • GitHub Desktop や gitk などのビジュアル プログラムを使用して変更をコミットします。 ビジュアルプログラムは通常、各コミットでどのファイルが追加、削除、変更されるかを正確に把握しやすくするものです。
  • コマンド ラインでの catch-all コマンド git add . と git commit -a を回避するには、代わりに git add filename と git rm filename を使用してファイルを個別にステージします。
  • git add --interactive を使用して、各ファイル内の変更を個別に確認およびステージします。
  • git diff --cached を使用して、コミットのステージした変更を確認します。 これは、git commit フラグを使用しない限り -a で生成される正確な差分です。
  • リポジトリのプッシュ保護を有効にして、ハードコーディングされたシークレットを含むプッシュがコードベースにコミットされないようにします。 詳しくは、「プッシュ保護について」をご覧ください。

参考資料