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

このガイドについて

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

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

• 予防に向けたプロアクティブ アプローチを講じる
• 漏洩の可能性を早期に発見する
• インシデント発生時の軽減計画を維持する

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

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

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

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

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

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

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

データ漏洩を防止する

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

勧告	詳細情報
リポジトリをフォークする機能を無効にします。

          [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository)

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

データ漏洩を検出する

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

secret scanning を使用する

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

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

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

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

組織の監査ログをレビューする

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

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

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

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

データ漏洩を軽減する

ユーザーが機密データをプッシュした場合は、git filter-repo ツールを使って削除するように依頼してください。 詳しくは、「リポジトリからの機微なデータの削除」をご覧ください。 また、機密データがまだプッシュされていない場合は、それらの変更をローカルで取り消すことができます。詳細については、the GitHub Blogを参照してください (ただし、Git 履歴には元の機密コミットが残るため、機密データの追加を元に戻すには、git revert は有効な方法ではないことに注意してください)。

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

次のステップ

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)