organization でのデータ 漏洩を防ぐためのベスト プラクティス

このガイドについて

organization 所有者は、プライベートまたは機密データの公開を防止することが最優先事項である必要があります。 意図的であれ偶発的であれ、データ漏洩は関係者に大きなリスクを引き起こす可能性があります。 GitHub ではデータ漏洩を防止するための対策を講じていますが、ユーザー側にもセキュリティを強化するために organization を管理する責任があります。

データ漏洩を防ぐことに関しては、以下に示すように重要な要素がいくつかあります。

• 予防に積極的に取り組む
• 漏洩の可能性を早期に発見する
• インシデント発生時の軽減計画を維持する

最適な方法は、管理対象の organization の種類によって異なります。 たとえば、オープンソース開発に重点を置く organization では、外部とのコラボレーションを可能にするために、完全に営利的な organization の場合よりも緩い制御が必要になることがあります。 この記事では、検討すべき GitHub の機能と設定 (ニーズに応じて実装する必要がある) に関するガイダンスの概要を提供します。

アカウントをセキュリティで保護する

2FA を有効にしてすべてのメンバーに要求する、強力なパスワード ガイドラインを確立するなど、セキュリティのベスト プラクティスを実装して、組織のリポジトリと設定を保護します。

• 組織のメンバー、外部コラボレーター、支払いマネージャーに、個人用アカウントで 2FA を有効にするよう要求し、悪意のある攻撃者が組織のリポジトリや設定にアクセスするのを困難にします。 詳しくは、「Organization で 2 要素認証を要求する」を参照してください。

• GitHub の推奨パスワード ガイドラインに従って強力なパスワードを作成し、それを適切にセキュリティで保護することをユーザーに促します。 詳細については、「強力なパスワードの作成」を参照してください。

• GitHub に内部セキュリティ ポリシーを確立することで、ユーザーはインシデントが疑われる場合に、実行すべき適切な手順および連絡先を知ることができます。 詳しくは、「リポジトリへのセキュリティ ポリシーの追加」を参照してください。

アカウントのセキュリティ保護について詳しくは、「アカウントをセキュリティで保護するためのベスト プラクティス」をご覧ください。

データ漏洩を防止する

organization 所有者は、organization の種類に応じてアクセス権の制限およびレビューを行う必要があります。 より厳密な制御を行う場合は、次の設定を検討してください。

推奨	詳細情報
リポジトリをフォークする機能を無効にします。	「リポジトリのフォークポリシーを管理する」
リポジトリの表示の変更を無効にします。	「Organization 内でリポジトリの可視性の変更を制限する」
リポジトリの作成をプライベートまたは内部に制限します。	「Organization 内でリポジトリの作成を制限する」
リポジトリの削除と転送を無効にします。	「リポジトリを削除または移譲する権限を設定する」
personal access tokenのスコープを最低限必要なアクセス許可に設定します。	なし
必要に応じてパブリック リポジトリをプライベートに変換して、コードをセキュリティで保護します。 GitHub Appを使用すれば、この変更のリポジトリ所有者に対してアラートを自動的に送信できます。	GitHub Marketplace 内の Prevent-Public-Repos
自分のドメインを検証し、検証済みのメール ドメインのみにメール通知を制限することで、自分の organization の ID であることを立証します。	「Organizationのためのドメインの検証あるいは承認」と「Organizationのメール通知の制限」
共同作成者が偶発的なコミットを行わないようにします。	「リポジトリからの機微なデータの削除」

データ漏洩を検出する

データ漏洩を防ぐために組織をどれほど強化しても、データ漏洩が発生する可能性はあります。その場合は、secret scanning、監査ログ、およびブランチ保護ルールを使用して対応できます。

secret scanning を使用する

Secret scanningを使用すれば、GitHub リポジトリ内のすべてのブランチの完全な Git 履歴にわたって、誤ってコミットされたシークレットをスキャンして検出することで、コードを保護し、組織やリポジトリ全体でシークレットを安全に保つことができます。 したパターンに一致する文字列は、リポジトリの [セキュリティ] タブでアラートとして報告されます。

用のライセンスがある場合のプライベート リポジトリと内部リポジトリ

この機能を使うには、サイト管理者がインスタンスの secret scanning を有効にする必要があります。 詳しくは、「アプライアンスのシークレットスキャンを設定する」をご覧ください。

secret scanning の詳細については、「シークレット スキャンについて」を参照してください。

また、リポジトリまたは組織のプッシュ保護としてsecret scanningを有効にすることもできます。 この機能を有効にすると、secret scanningでは、共同作成者が検出済みのシークレットを含むコードをプッシュできなくなります。 詳しくは、「プッシュ保護について」を参照してください。 最後に、カスタム シークレット文字列構造を含めるように検出を拡張することもできます。 詳しくは、「シークレット スキャンのカスタム パターンの定義」をご覧ください。

organization 用の監査ログをレビューする

また、organization の監査ログと、GraphQL 監査ログ API を利用することで、IP を事前にセキュリティで保護し、organization に合わせてコンプライアンスを維持することもできます。 詳細については、「Organization の Audit log をレビューする」および「インターフェイス」を参照してください。

ブランチ保護ルールを設定する

既定のブランチにマージされる前にすべてのコードが適切にレビューされることを保証するには、ブランチ保護を有効にします。 ブランチ保護ルールを設定すると、共同作成者が変更をプッシュする前に、特定のワークフローまたは要件を強制することができます。 詳しくは、「保護されたブランチについて」を参照してください。

ブランチ保護規則またはタグ保護規則の代わりに、ルールセットを作成できます。 ルールセットには、状態など、ブランチとタグの保護ルールよりもいくつかの利点があり、管理者アクセスを必要とせずに検出可能性が向上します。 同時に複数のルールセットを適用することもできます。 詳しくは、「ルールセットについて」を参照してください。

データ漏洩を軽減する

ユーザーが機密データをプッシュする場合は、それを、git filter-repo ツールまたは BFG Repo-Cleaner オープン ソース ツールを使用して削除するように、彼らに依頼してください。 詳しくは、「リポジトリからの機微なデータの削除」を参照してください。 また、Git では、ほぼすべてのものを元に戻すこともできます。 詳細については、the GitHub Blogを参照してください。

Organization レベルで、機密データを削除するためにプッシュしたユーザーと調整がとれない場合は、関連するコミット SHA を添えて サイト管理者 に連絡することをお勧めします。

自分が所有していると確信できるデータをリポジトリ所有者と直接調整して削除することができない場合は、DMCA 削除通知フォームに記入して GitHub サポートにアラートとして通知できます。 詳しくは、「DMCA テイクダウン通知」を参照してください。

次の手順

• 「サプライ チェーンのコードをセキュリティで保護するためのベスト プラクティス」
• 「ビルド システムをセキュリティで保護するためのベスト プラクティス」