プログラミングを学んでいると、誰もが一度はヒヤリとする場面があります。そのひとつが「GitHubに機密情報を誤ってpushしてしまった」という失敗です。
AWSのアクセスキー、データベースのパスワード、APIキーを誤ってGitHubのリポジトリにpushしてしまったとき、「すぐに削除すれば大丈夫？」「もう誰かに見られた？」という不安が一気に押し寄せてきます。
実はこのミスは、プログラミング初心者だけでなく、経験豊富なエンジニアでも起こりえる出来事です。大切なのは、焦らず正しい順序で対応することと、二度と同じミスをしないための予防策を身につけることです。
この記事では、そんな状況に陥ってしまったときの冷静な初動対応と、具体的な予防策をわかりやすく解説します。プログラミング初心者の方でも実践できる内容ですので、ぜひ最後まで読んでみてください。
なぜ機密情報をGitHubにpushしてしまうのか
まず、なぜこのようなミスが起きるのかを理解することが大切です。原因を知ることで、同じミスを繰り返さない対策が立てやすくなります。
よくある機密情報push事故の原因
開発中に直接コードへ書いてしまう
「後でちゃんとした方法に変えよう」と思いながら、APIキーやパスワードをソースコードに直接記述してしまうケースです。忙しいときや初心者のうちは特に起こりやすい失敗です。
.envファイルをgit管理に含めてしまう
環境変数を管理する.envファイルは便利ですが、.gitignoreへの追加を忘れて一緒にpushしてしまうことがあります。
設定ファイルをそのままコミットする
config.json、settings.yml、database.ymlなどの設定ファイルに本番環境のパスワードが入ったまま、コミットしてしまうケースです。
ログファイルやデバッグ出力が含まれている
ログに機密情報が出力されており、そのログファイルを誤ってコミットしてしまうことも少なくありません。
コードのコピー＆ペーストで混入してしまう
他のプロジェクトからコードをコピーした際に、テスト用のAPIキーなどが混入してしまうケースも多くみられます。
削除すれば大丈夫は大きな誤解
GitHubで該当ファイルを削除するコミットをすればOKだと思っていませんか。 これは大きな誤解です。
Gitはすべての変更履歴を記録する仕組みのため、ファイルを削除するコミットをしても過去の履歴には情報が残り続けます。
また、GitHubに機密情報がpushされた瞬間から、悪意あるbotによる自動スキャンが動いている可能性があります。実際に、GitHubに公開されたAWSのアクセスキーが数秒〜数分以内に悪用されたという事例が複数報告されています。
「気づいたらすぐ消した」という行動だけでは、すでに手遅れになるケースがあるのです。
インシデントが発生したときにまず何をすべきか
機密情報をpushしてしまったことに気づいたら、焦らず、素早く以下の手順で対応しましょう。対応の順序を間違えると被害が拡大する可能性があります。
該当のキーやパスワードをすぐに無効化する
最初にやるべきことは、Gitの履歴削除ではなく、漏洩した情報の無効化（revoke）です。なぜなら、すでに誰かに見られている可能性があり、履歴の削除より情報の無効化の方が即効性があるからです。
AWSのアクセスキー
AWS管理コンソールでキーを削除・無効化し、新しいキーを発行する
GitHub Personal Access Token
GitHubの設定画面からトークンを削除する
データベースパスワード
パスワードを変更し、古いパスワードを無効化する
各種APIキー
各サービスの管理画面でキーを再発行する
この操作を最優先で行ってください。古いキーを無効化してしまえば、たとえ履歴に残っていても悪用されるリスクを大幅に下げることができます。
リポジトリを非公開（Private）に変更する
次に、対象のリポジトリを一時的にPrivateに変更しましょう。
GitHubのリポジトリ設定（Settings）から「Danger Zone」にある「Change repository visibility」で非公開に変更できます。これにより、新たに情報が閲覧されることを防げます。
機密情報がどのコミットに含まれているか確認する
以下のコマンドで、どのコミットに機密情報が含まれているか確認します。どのファイルの、どのコミットに問題があるかを把握することで、次の対処が正確になります。
# コミット一覧を確認する
git log –all –oneline
# 特定のコミットの内容を確認する
git show <コミットハッシュ>
# 特定のキーワードを含むコミットを検索する
git log –all -S “検索したいキーワード” –oneline
Gitの履歴から機密情報を完全削除する
GitHubが公式に推奨しているツール「git-filter-repo」を使って、履歴から機密情報を削除します。このツールはGitの履歴を安全かつ高速に書き換えることができます。
# インストール（pipを使用）
pip install git-filter-repo
# 特定のファイルを履歴から完全に削除する
git filter-repo –invert-paths –path config/secrets.env
# 特定の文字列（APIキーそのもの）を置換する場合
echo “実際のAPIキー==>***REMOVED***” > ../secrets-to-replace.txt
git filter-repo –replace-text ../secrets-to-replace.txt
注意点として、この操作を行うとコミットハッシュが全て変わります。チームで開発している場合は、メンバーに必ず事前に連絡し、操作後に全員がリポジトリを再クローンする必要があります。
一人で開発している場合でも、操作前にバックアップを取っておくと安心です。
修正した内容をforce pushで反映する
履歴の書き換えが完了したら、GitHubのリモートリポジトリに強制pushします。
# 全ブランチを強制pushする
git push origin –force –all
git push origin –force –tags
force push後は、GitHubサポートに連絡してキャッシュや残存コピーの削除を依頼することも検討しましょう。公開リポジトリの場合、GitHub側のキャッシュに情報が残る可能性があるためです。
また、リポジトリをforkしているユーザーがいる場合は、そのforkにも古い履歴が残っていることに注意してください。
二度と繰り返さないための予防策5選
事故が起きた後の対処も大切ですが、そもそも機密情報をpushしないための習慣を身につけることが最も重要です。プログラミング初心者のうちから実践できる予防策を5つ紹介します。
.gitignoreをプロジェクト開始時に設定する
プロジェクトを始める前に、必ず.gitignoreファイルを設定しましょう。以下は最低限設定しておきたい記述例です。
# 環境変数ファイル
.env
.env.local
.env.production
.env.staging
# 鍵・証明書ファイル
*.pem
*.key
*.p12
id_rsa
# 機密情報を含む設定ファイル
config/secrets.yml
credentials.json
# ログファイル
*.log
logs/
GitHubでは言語やフレームワークごとの.gitignoreテンプレートを公式に提供しています。「github/gitignore」リポジトリを参考にすることで、見落としを防げます。
また、新規リポジトリ作成時にGitHub上でテンプレートを選択することもできます。
環境変数を使って機密情報を管理する
APIキーやパスワードは、コードに直接書かずに環境変数として管理するのが基本です。
// NG：コードに直接書いてしまっている
const apiKey = “sk-xxxxxxxxxxxxxxxxxxxx”;
const dbPassword = “my-secret-password”;
// OK：環境変数から読み込む
const apiKey = process.env.API_KEY;
const dbPassword = process.env.DB_PASSWORD;
本番環境ではCI/CDツールやクラウドサービスのシークレット管理機能（GitHub Actions Secrets、AWS Secrets Manager）を活用しましょう。開発環境では.envファイルを使い、必ず.gitignoreに追加することを忘れないでください。
コミット前に自動チェックするツールを導入する
「Gitleaks」というオープンソースツールを使うと、コミット時に800種類以上の機密情報パターンを自動検出してくれます。pre-commitフックとして設定することで、うっかりミスを防げます。
# Gitleaksのインストール（macOS / Homebrew）
brew install gitleaks
# リポジトリ全体をスキャンする
gitleaks detect –source .
# コミット前に自動チェック（pre-commitフックとして設定）
# .git/hooks/pre-commit ファイルに以下を記述
gitleaks protect –staged -v
また、GitHubの「Push Protection」機能を有効にすることで、pushの段階でブロックしてくれます。無料プランでもパブリックリポジトリは利用可能です。設定はGitHub上のリポジトリ設定から行えます。
シークレット管理サービスを積極活用する
機密情報は各クラウドプロバイダが提供するシークレット管理サービスに保管するのがベストプラクティスです。コードに機密情報を一切書かずに済む環境を整えましょう。
AWS Secrets Manager
AWSを使っているプロジェクト向けの本格的な機密管理サービス。自動ローテーション機能も備えている
GitHub Actions Secrets
GitHub ActionsのCI/CD環境での機密情報管理に最適。リポジトリ・Organization・環境ごとに設定可能
HashiCorp Vault
オープンソースの強力なシークレット管理ツール。自社サーバーへの導入も可能で、大規模プロジェクトに適している
1Password Secrets Automation
チームで使いやすく、UIも直感的。既存の1Passwordアカウントと連携できる
定期的なセキュリティスキャンを習慣にする
プロジェクトが成長するにつれ、いつの間にか機密情報が紛れ込んでいることがあります。TruffleHogというツールは、検出した情報が「現在も有効か」を実際に検証できる独自機能を持っており、定期的なスキャンに役立ちます。
# TruffleHogのインストール
pip install trufflehog
# ローカルのGitリポジトリをスキャン
trufflehog git file://.
# GitHubリポジトリをスキャン
trufflehog github –repo https://github.com/your-username/your-repo
GitHub Actionsを使って定期的な自動スキャンを設定しておくと、継続的なセキュリティ確認が可能です。毎日深夜に自動でスキャンを実行する設定も、数行のYAMLで実現できます。
まとめ
GitHubへの機密情報の誤push事故は、ベテランエンジニアでも経験することがある失敗です。大切なのは、事故が起きたときに冷静に素早く対応できる知識を持つこと、そして事前にしっかりと予防策を講じることです。
3inkでは、最先端の技術トレンドを押さえた高度なシステム開発から、御社の開発現場のセキュリティ強化・ガバナンス構築を支えるコンサルティングまで幅広く柔軟に対応しております。
「安全で強固なシステムを構築したい」「自社の開発プロセスにセキュリティの仕組みを組み込みたい」など、システム開発に関するご要望やご相談がございましたら、いつでもお気軽にお問い合わせください。