.png){kind=small}
Vol.06 ソースコード管理と情報漏えい対策
- atsu wada
- 3月25日
- 読了時間: 9分
更新日：4月14日
この記事であなたがやるべきこと
後述する「ソースコード管理における情報漏えい対策の5つの基本」を理解して、
日常的に行っているソースコード管理方法を再確認し、
情報漏えいのリスクを最小限に抑えた安全な開発ができるようになること。
はじめに
エンジニアにとって、ソースコード管理は日常業務の一部です。GitHubやGitLabなどのツールを使って、コードの変更履歴を管理し、チームでの共同開発を効率化しています。しかし、その便利さの陰に潜むリスクについて、十分に理解していますか？
この記事では、ソースコード管理における情報漏えいリスクと、その対策について解説します。すぐに実践できる具体的な方法を紹介していますので、ぜひ明日からの業務に取り入れてみてください。
なぜソースコード管理が情報漏えいのリスクになるのか？
ソースコードはエンジニアにとって日々扱うものですが、その中にはAPIキー、データベースの接続情報、個人情報など、機密性の高い情報が含まれる場合があります。
特に新卒エンジニアの場合、「とりあえず動くコードを書く」ことに集中してしまい、意図せず機密情報をコミットしてしまうリスクがあります。また、共有やバックアップ目的で安易にパブリックリポジトリを利用してしまい、情報が流出してしまった事例も少なくありません。
実際に起きた情報漏えい事例
誤コミットによるAWSアクセスキーの流出と不正利用
あるスタートアップのエンジニアが、AWSのアクセスキーとシークレットキーをハードコーディングしたまま、うっかりGitHubのパブリックリポジトリにプッシュしました。プッシュしてからわずか1時間後、自動スキャンボットがそのキーを検出し、攻撃者がAWSアカウントに不正アクセス。大量のEC2インスタンスが起動され、仮想通貨のマイニングに悪用されました。気づいたときには300万円以上の請求が発生していました。
リポジトリ設定ミスによる顧客データの流出
とあるWeb開発企業では、チーム内で共有するためにGitLabを使用していました。新人エンジニアが開発中のプロジェクトをリモートリポジトリに初めてプッシュする際、誤って「Public」設定でリポジトリを作成。プロジェクトには顧客の氏名、メールアドレス、購入履歴などが含まれるテスト用JSONファイルが含まれていました。1週間後、SEO分析ツールが同データを検出し、インデックス化されたことで外部から発見されてしまい、顧客からのクレームにつながりました
こうした事故を防ぐために、ソースコード管理における情報漏えい対策の基本を押さえましょう。
ソースコード管理における情報漏えい対策の5つの基本
1. 機密情報をコードに直接書かない
何をすべきか：
APIキーやパスワードをソースコードに直接記載しない
設定ファイルや環境変数経由で読み込む仕組みを徹底する
実践のコツ：
.envファイルや環境変数を活用し、機密情報をコード外で管理
チームで「絶対にコードに直接書かない」ルールを共有する
実装例 (Node.js):
実装例 (Python):
2. Gitのコミット時に機密情報を検知・ブロックする
何をすべきか：
Gitのコミット前フックを使って、機密情報を含むファイルを検知
ツール（git-secrets等）を導入してコミット時に自動的にチェック
実践のコツ：
Git Hooksを活用し、コミット時に自動検知・ブロックする設定を行う
チーム全体で導入し、仕組みとして事故を防止
git-secrets導入手順:
3. gitignoreの活用を徹底する
何をすべきか：
.gitignoreでPush対象外とするファイルを明確に設定
機密情報が入る可能性のあるファイルをリストアップし、常時管理
実践のコツ：
新規プロジェクトを作成するとき、最初に必ず.gitignoreを設定
代表的な設定ファイルや環境変数ファイル（.env）は必ず除外する習慣を作る
基本的な.gitignoreの例:
4. リポジトリのアクセス権限管理を徹底する
何をすべきか：
プライベートリポジトリをデフォルト設定とし、公開設定は最小限に
リポジトリへのアクセス権限を役割に応じて適切に設定
実践のコツ：
アクセス権限を定期的に棚卸しし、必要最低限の権限を付与
特に外部との共同作業では、権限範囲を限定的に設定することを徹底
GitHubでの権限設定手順:
リポジトリページの「Settings」を開く
左メニューから「Collaborators and teams」を選択
「Manage access」セクションで、メンバーごとに適切な権限（Read/Write/Admin）を設定
定期的に権限リストを確認し、不要なアクセス権を削除
5. 定期的なセキュリティ監査の実施
何をすべきか：
定期的にリポジトリをチェックし、誤コミットや設定ミスがないかを監査
専用のセキュリティ監査ツールを導入（GitGuardian、TruffleHogなど）
実践のコツ：
月1回など、定期的な監査日を設定し、ツールを用いて自動的にチェック
問題が発見されたら即座に対応し、チーム内で共有する習慣を作る
TruffleHogの使用例:
機密情報が漏洩してしまった場合の対応手順
万が一、機密情報がリポジトリにコミットされてしまった場合の対応手順も知っておきましょう。素早い対応が被害を最小限に抑えるカギです。
1. 漏洩した認証情報の無効化・更新
APIキーやパスワードが漏洩した場合は、即座に無効化し、新しいものを発行
AWS、Google Cloud、Azureなどのプラットフォームでは、コンソールから認証情報をローテーション
2. コミット履歴からの削除
機密情報をコミット履歴から完全に削除するには：
注意: 履歴書き換えはチーム開発では影響が大きいため、関係者全員に事前に伝えることが必要です。
3. インシデントの報告と記録
発見したらすぐにセキュリティ担当者や上司に報告
何が漏洩したか、どのように対応したかを記録
必要に応じて関係者（顧客など）への報告も検討
4. 再発防止策の実施
なぜ漏洩が起きたのかを分析
チーム内でのレビュープロセスの見直し
自動検知ツールの導入または強化
今日からできる！ ソースコード管理セキュリティチェックリスト
以下のチェックリストを活用し、日常的なソースコード管理を再確認しましょう。
コミット・Pushの管理
APIキーやパスワードはコードに直接記載していない
Gitコミット前に機密情報の検知ツールを設定している
.gitignoreを適切に設定している
環境変数またはシークレット管理サービスを活用している
アクセス管理
プライベートリポジトリになっている
アクセス権限を必要最小限に設定している
定期的にアクセス権限を見直している
外部コラボレーターの権限を制限的に設定している
監査・運用
定期的な監査を行っている
監査ツールを導入している
問題発見時の対応手順を明確にしている
チームメンバー全員がセキュリティルールを理解している
よくある疑問（Q&A）
Q1: 小規模なプロジェクトでも対策は必要ですか？
A: 規模に関わらず基本的な対策は必要です。小さなプロジェクトこそ後から大きくなる可能性があり、最初から良い習慣を身につけておくことが重要です。特に.gitignoreの設定と機密情報の環境変数化は、どんなプロジェクトでも最低限行いましょう。
Q2: チームメンバーがセキュリティ対策に協力してくれません。どうすれば良いですか？
A: まずは具体的な事例を共有し、情報漏洩のリスクと影響を理解してもらいましょう。次に、開発効率を下げない範囲での自動化ツールを提案するのが効果的です。例えば、pre-commitフックを設定してコミット時のチェックを自動化することで、意識しなくても安全性が高まります。
Q3: 既にGitHubに機密情報をプッシュしてしまいました。どうすべきですか？
A: まず落ち着いて以下の手順で対応しましょう：
漏洩した認証情報（パスワード、APIキーなど）を即座に無効化・更新する
上記で紹介したBFG Repo-CleanerかGit filter-branchを使って履歴から削除する
強制プッシュで上書きする
チームメンバーに状況を共有し、各自のローカルリポジトリの更新を依頼する
ただし、一度公開リポジトリにプッシュされた情報は完全に削除できない可能性があるため、認証情報の無効化は必須です。
Q4: 環境変数ファイル（.env）はどのように共有すれば良いですか？
A: .envファイル自体の共有は避け、代わりに.env.exampleのようなサンプルファイルを用意するのがベストプラクティスです。このサンプルには実際の値ではなく、どのような環境変数が必要かの情報だけを含めます。チームメンバーはこのサンプルを参考に、自分の環境に合わせた.envファイルを作成します。機密性の高い本番環境の値は、パスワード管理ツールや暗号化された方法で別途共有しましょう。
Q5: Git以外のバージョン管理システムでも同様の対策が必要ですか？
A: はい、Mercurial、SVNなど他のバージョン管理システムでも基本的な考え方は同じです。具体的なツールやコマンドは異なりますが、「機密情報を直接コードに書かない」「アクセス権限を適切に管理する」といった原則は共通です。それぞれのシステムに適したセキュリティツールや設定方法を調査して導入しましょう。
Q6: 定期的な監査の頻度はどのくらいが適切ですか？
A: 監査の頻度はプロジェクトの規模やリスクの高さに応じて変わりますが、一般的には月1回程度が推奨されます。小規模なプロジェクトでも最低でも四半期に一度は監査を行い、設定ミスや漏洩の早期発見・対応を心がけましょう。また、重要なアップデートやメンバー変更時にも随時監査を行うことを推奨します。
Q7: 小さなスタートアップや個人プロジェクトでコストを抑えてセキュリティ対策を実施するための無料または低コストなツールを教えてください。
A: 以下のツールは無料または低コストでセキュリティ対策が可能です。
git-secrets: 機密情報のコミットを自動検知してブロック
TruffleHog: リポジトリ内の機密情報を検出
GitGuardian: 個人利用であれば無料でGitHubのリポジトリを継続的に監視
Dependabot（GitHub標準搭載）: ライブラリの脆弱性を自動検知・更新提案
まとめ：安全なコード管理を習慣に
ソースコードの管理はエンジニアの基本業務ですが、情報漏えいのリスクが常に潜んでいます。「動けば良い」だけでなく、「安全に管理できているか？」という視点を持つことが重要です。
特に重要なのは以下の3点です：
予防が最善: 機密情報をコードに直接書かない、適切な.gitignoreを設定するなど、最初から漏洩を防ぐ習慣をつける
自動化が効果的: 人間のチェックだけでなく、ツールを活用して自動的に機密情報の漏洩を防止する
対応手順を知っておく: 万が一の場合に備えて、対応手順を事前に理解しておく
この記事で紹介した基本対策とチェックリストを参考に、日常的な業務の中で安全なソースコード管理を徹底し、エンジニアとしての信頼性と安全性を高めていきましょう。
最後までお読みいただきありがとうございました。皆さんが安全かつ快適に開発を進められることを願っています！
