GitHubのアクセス権から始める個人情報漏洩対策：組織で実施する7つの基本
木村 優志
Published: 8/8/2026, 2:00:00 AM
GitHubはソースコードを保管する場所であると同時に、設計書、設定ファイル、CI/CDの認証情報、テストデータを集約しやすい場所でもあります。アクセス権や認証情報の管理を誤ると、コードだけでなく、個人情報や顧客情報、社内の機密情報まで漏洩するおそれがあります。
ただし、原因を「GitHubが漏れた」と一言で片付けるのは正確ではありません。実際には、アカウントの乗っ取り、不要になった外部協力者の権限、過剰なアクセストークン、リポジトリに混入した秘密情報、CI/CDの設定不備など、複数の問題が重なって起きます。
本記事では、GitHub Organizationを利用する開発チームが、個人情報を含む情報の漏洩リスクを下げるために実施したい基本対策を整理します。ここで扱う内容は技術的な一般論であり、法令・契約・業界ガイドラインへの適合は、組織の法務・セキュリティ担当者と確認してください。
大前提：個人情報をリポジトリに置かない
最も効果的な対策は、アクセス権を厳格にする前に、個人情報をGitリポジトリへ保存しないことです。Privateリポジトリは個人情報を保管するためのデータベースではありません。
Gitでは変更履歴が残り、複製したローカル環境、Fork、Pull Request、CI/CDログ、キャッシュなどへ情報が広がる可能性があります。一度コミットした個人情報は、ファイルを削除しても過去の履歴に残ることがあります。アクセス権を適切に設定していても、閲覧可能な人数と複製される場所が増えるほど、漏洩時の影響範囲は大きくなります。
氏名、メールアドレス、問い合わせ本文、顧客ID、従業員情報などは、アクセス制御・監査・保持期間を管理できる業務システム、データベース、ストレージへ置きます。リポジトリには、データ構造の定義、マイグレーション、匿名化・合成済みのサンプル、データ取得手順だけを置くようにします。
テストでは、原則として合成データまたは十分に匿名化したデータを使います。本番データを使わなければならない例外は、目的、対象者、保存先、期間、削除方法を事前に定め、専用の管理環境で限定的に扱います。SlackやIssue、Pull Requestのコメント、スクリーンショットへ個人情報を貼り付けない運用も同時に必要です。
守る対象を分ける
対策を始める前に、リポジトリ内と周辺システムにある情報を分類します。すべてを「機密」とするだけでは、誰が何を扱ってよいか判断できません。
少なくとも次は分けて台帳化します。
- 個人情報・顧客情報：氏名、メールアドレス、住所、利用履歴、問い合わせ内容、従業員情報
- 認証情報：APIキー、パスワード、SSH秘密鍵、クラウド認証情報、OAuthトークン、Webhookの秘密値
- 業務上の機密：非公開の設計、脆弱性情報、契約内容、未公開の事業計画
- 公開してよい情報：OSSとして公開するソースコード、公開用ドキュメント、匿名化済みのサンプル
特に注意したいのは、テスト用データです。「開発環境だから」と本番の顧客データをコピーすると、必要以上の人が閲覧できる状態になりやすくなります。個人情報を含むデータがすでにリポジトリにある場合は、新たな利用を止め、履歴、Fork、CI/CDログなどを含めた露出範囲を確認したうえで、削除・再発防止・必要な報告を進めます。
1. 個人ではなくチームに権限を付与する
リポジトリへの権限を個人単位で都度付与すると、異動、退職、委託終了のときに見落としが起きやすくなります。OrganizationのTeamを使い、職務ごとに読み取り、書き込み、管理の権限を定義しましょう。
原則は最小権限です。閲覧だけで足りる人に書き込み権限を与えない、特定リポジトリだけが必要な人にOrganization全体の権限を与えない、管理者権限を常用しない、といった運用が基本になります。
外部協力者には、対象リポジトリと契約期間を限定します。プロジェクトの終了日や契約更新日をアクセス権レビューの予定として登録し、少なくとも定期的に「この人はまだこのリポジトリへアクセスする必要があるか」を確認します。
2. 2FAを必須にし、強い認証方法を選ぶ
パスワードが漏洩しても、二要素認証（2FA）があればアカウント乗っ取りの難易度を上げられます。GitHub Organizationでは、メンバー、外部協力者、請求担当者に対して2FAを必須にできます。
可能であれば、SMSだけに頼らず、パスキー、セキュリティキー、認証アプリといった方法を採用します。GitHubでは、Organizationで安全な2FA方式を要求することもできます。
有効化の前には影響確認が必要です。2FAを必須にすると、要件を満たしていない外部協力者はOrganizationから削除され、リポジトリへアクセスできなくなります。個人アカウントだけでなく、botやサービスアカウントがどのように認証しているかも棚卸ししてから実施しましょう。
3. アクセス権を「付与時」ではなく「継続時」にレビューする
アクセス権は一度付けると残り続けます。月次または四半期ごとに、次を確認する運用を作ります。
- Organization owner、リポジトリ管理者、Team管理者は必要最小限か
- 外部協力者、退職者、異動者、休眠アカウントが残っていないか
- Privateリポジトリの閲覧・書き込み権限は職務と一致しているか
- Organizationに接続されたGitHub App、OAuth App、CI/CDサービスは必要か
- Fork、デプロイキー、Webhook、Deploy keyに不要なアクセスがないか
このレビューを人手の記憶に頼らず、入社・異動・退職・委託開始・委託終了の手続きと結び付けることが重要です。誰が承認し、いつ削除したかも記録します。
4. Personal Access Tokenは短命・最小権限にする
Personal Access Token（PAT）は、漏洩するとパスワードに近い影響を持ちます。可能な限り、広い範囲にアクセスできるclassic PATではなく、fine-grained PATを使います。
fine-grained PATでは、アクセス先を特定のOrganizationまたはユーザーに限定し、対象リポジトリと必要な権限だけを選べます。Organization側では、fine-grained PATの承認を必須にすることもできます。
トークンには用途、所有者、作成日、有効期限、対象リポジトリを記録します。個人のPATを共有してCI/CDで使うのは避け、必要に応じてGitHub Appや専用のサービスアカウントを使い、失効・ローテーションできる状態にします。
5. 秘密情報をリポジトリへ入れない。入った場合は即座に失効させる
.envを.gitignoreへ追加することは必要ですが、それだけでは十分ではありません。設定ミス、コピー＆ペースト、テストコード、過去のコミットなどから、秘密情報が混入する可能性があります。
GitHubのSecret Scanningは、既知のパターンや組織で定義したパターンに一致する秘密情報を検出します。さらにPush Protectionを有効にすると、検出した秘密情報を含むpushを、リポジトリへ到達する前にブロックできます。
秘密情報を誤ってコミットしたときは、ファイルを削除して終わりではありません。次の順で対応します。
- 対象の認証情報を直ちに失効・ローテーションする
- 秘密情報が使われた形跡を、対象サービスの監査ログで確認する
- Git履歴、Fork、ビルドログ、デプロイ先など、露出した範囲を調査する
- 必要に応じて履歴から削除し、関係者へ連絡する
- 混入経路を振り返り、Push Protectionやレビュー手順を改善する
重要なのは、履歴を書き換えて見えなくすることより先に、漏れた認証情報を無効化することです。
6. CI/CDとGitHub Actionsの権限を分ける
CI/CDは、クラウドへのデプロイ権限やパッケージ公開権限を持つことがあります。ここが過剰権限だと、コード変更やワークフロー変更を起点に、より大きな被害へつながるおそれがあります。
ワークフローごとに必要な権限を明示し、読み取りだけで足りるジョブへ書き込み権限を与えないようにします。デプロイ用の秘密情報は、リポジトリのソースコードではなく、GitHub Secretsや利用中のクラウドのシークレット管理サービスで扱います。
外部Actionを使う場合は、提供元と更新状況を確認し、信頼できるバージョンへ固定します。Pull Requestから実行されるワークフローは、フォーク由来のコードや秘密情報へのアクセスが想定外に組み合わさらないか、特に慎重に設計します。
7. 監査ログと初動手順を、漏洩前に用意する
アクセス制御は、侵害をゼロにする保証ではありません。問題が起きたとき、誰がいつ何へアクセスしたかを確認できなければ、影響範囲を判断できません。
Organizationの監査ログ、Secret Scanningのアラート、認証情報を発行したクラウドサービスのログを、定期的に確認できるようにします。少なくとも、次の初動手順を文書化しておくと対応が速くなります。
- 連絡を受ける窓口と、意思決定者
- アカウント、トークン、デプロイキーを停止する手順
- ログを保全し、影響範囲を調査する担当
- 顧客、取引先、監督機関などへの連絡を判断するプロセス
- 復旧後にアクセス権と原因を見直すプロセス
「誰かが気づいたら対応する」ではなく、担当者が不在でも実行できる形にすることが重要です。
最初の30日で進めるチェックリスト
すべてを一度に整備できない場合は、優先順位を付けます。
- 1週目：Organization owner、外部協力者、PAT、GitHub Appを棚卸しする
- 2週目：2FAと安全な認証方式を必須化する。不要な権限を削除する
- 3週目：Secret ScanningとPush Protectionを有効化し、検知時の担当者を決める
- 4週目：CI/CDの権限、デプロイキー、Secretsをレビューし、インシデント初動手順を演習する
まとめ
GitHubの個人情報漏洩対策は、Privateリポジトリにするだけでは完結しません。最小権限、強い認証、継続的なアクセス権レビュー、トークン管理、秘密情報の漏洩防止、CI/CDの分離、監査と初動対応を組み合わせる必要があります。
まずは、Organizationの管理者・外部協力者・長期間有効なトークンを一覧にするところから始めてください。どの情報に誰がアクセスできるかを可視化することが、実効性のある対策の出発点になります。
