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のためのドメインの検証あるいは承認」
組織が GitHub にアップグレードされていることを確認してください。標準サービス使用条件を使用する代わりに、顧客契約にアップグレードしていることを確認してください。	「GitHub 顧客契約へのアップグレード」
共同作成者が偶発的なコミットを行わないようにします。	「リポジトリからの機微なデータの削除」

データ漏洩を検出する

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

secret scanning を使用する

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

使用可能な secret scanning には、 パートナーに対するシークレット スキャンニング アラート と ユーザーに対するシークレット スキャンニング アラート という 2 つの形式があります。

• パートナーに対するシークレット スキャンニング アラート - これらは既定で有効になっており、すべてのパブリック リポジトリおよびパブリック npm パッケージ上で自動的に実行されます。

• ユーザーに対するシークレット スキャンニング アラート - organization 用に追加のスキャン機能を取得するには、ユーザーに対するシークレット スキャンニング アラート を有効にする必要があります。

  有効にすると、次の種類のリポジトリ上で ユーザーに対するシークレット スキャンニング アラート を検出できます:

  • GitHub.com の個人用アカウントによって所有されるパブリック リポジトリ。
  • 組織が所有しているパブリック リポジトリ
  • GitHub Enterprise Cloud を使用している organization が所有するプライベート リポジトリと内部リポジトリ (GitHub Advanced Security 用のライセンスがある場合のプライベート リポジトリと内部リポジトリ

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

また、リポジトリまたは組織のプッシュ保護としてsecret scanningを有効にすることもできます。 この機能を有効にすると、secret scanningでは、共同作成者が検出済みのシークレットを含むコードをプッシュできなくなります。 詳しくは、「リポジトリと Organization のプッシュ保護」を参照してください。

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

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

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

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

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

データ漏洩を軽減する

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

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

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

次の手順

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