# 組織でのデータ漏洩を防ぐためのベスト プラクティス 組織内に存在するプライベートまたは機密データが公開されないようにするためのガイダンスと推奨事項について説明します。 ## このガイドについて 組織所有者は、、非公開または機密データの公開を防止することを最優先事項とする必要があります。 意図的であれ偶発的であれ、データ漏洩は関係者に大きなリスクを引き起こす可能性があります。 GitHubはデータ 漏洩からユーザーを保護するための対策を講じながら、セキュリティを強化するために組織を管理する責任もあります。 データ漏洩を防ぐことに関しては、以下に示すように重要な要素がいくつかあります。 * 予防に向けたプロアクティブ アプローチを講じる * 漏洩の可能性を早期に発見する * インシデント発生時の軽減計画を維持する 最適な方法は、管理対象の組織の種類によって異なります。 たとえば、オープンソース開発に重点を置く組織では、外部とのコラボレーションを可能にするために、完全に商業化された組織の場合よりも緩い制御が必要になることがあります。 この記事では、必要に応じて実装する必要がある GitHub 機能と設定に関する概要ガイダンスを提供します。 ## アカウントをセキュリティで保護する 2FA を有効にしてすべてのメンバーに要求する、強力なパスワード ガイドラインを確立するなど、セキュリティのベスト プラクティスを実装して、組織のリポジトリと設定を保護します。 * 組織のメンバー、外部のコラボレーター、課金マネージャーに個人アカウントの 2FA を有効にするよう要求すると、悪意のあるアクターが組織のリポジトリと設定にアクセスすることが困難になります。 詳細については、「[Organization で 2 要素認証を要求する](/ja/enterprise-server@3.20/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)」を参照してください。 * GitHub推奨されるパスワード ガイドラインに従って、強力なパスワードを作成し、適切にセキュリティで保護するようユーザーに促します。 詳細については、 [AUTOTITLE を](/ja/enterprise-server@3.20/authentication/keeping-your-account-and-data-secure/creating-a-strong-password)参照してください。 * GitHubで内部セキュリティ ポリシーを確立して、ユーザーが実行する適切な手順と、インシデントが疑われる場合に連絡するユーザーを把握できるようにします。 詳細については、「[リポジトリへのセキュリティ ポリシーの追加](/ja/enterprise-server@3.20/code-security/getting-started/adding-a-security-policy-to-your-repository)」を参照してください。 アカウントのセキュリティ保護の詳細については、「[アカウントをセキュリティで保護するためのベスト プラクティス](/ja/enterprise-server@3.20/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)」を参照してください。 ## データ漏洩を防止する 組織所有者は、組織の種類に応じてアクセス権の制限およびレビューを行う必要があります。 より厳密な制御を行う場合は、次の設定を検討してください。 | Recommendation | 詳細情報 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---- | | リポジトリをフォークする機能を無効にします。 | | | [リポジトリのフォークポリシーを管理する](/ja/enterprise-server@3.20/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository) | | | リポジトリの表示の変更を無効にします。 | | | [Organization 内でリポジトリの可視性の変更を制限する](/ja/enterprise-server@3.20/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization) | | | リポジトリの作成をプライベートまたは内部に制限します。 | | | [Organization 内でリポジトリの作成を制限する](/ja/enterprise-server@3.20/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization) | | | リポジトリの削除と転送を無効にします。 | | | [リポジトリを削除または移譲する権限を設定する](/ja/enterprise-server@3.20/organizations/managing-organization-settings/setting-permissions-for-deleting-or-transferring-repositories) | | | | | | デプロイ キーを使用する機能を無効にします。 | | | [組織内のデプロイ キーを制限する](/ja/enterprise-server@3.20/organizations/managing-organization-settings/restricting-deploy-keys-in-your-organization) | | | | | | 必要な最小限のアクセス許可に personal access tokenスコープを設定します。 | None | | 必要に応じてパブリック リポジトリをプライベートに変換して、コードをセキュリティで保護します。 | | | GitHub Appを使用して、この変更のリポジトリ所有者に自動的にアラートを送信できます。 | | | [Prevent-Public-Repos](https://github.com/apps/prevent-public-repos) の GitHub Marketplace | | | 自分のドメインを検証し、検証済みのメール ドメインのみにメール通知を制限することで、自分の組織の ID であることを立証します。 | | | [組織のためのドメインの検証または承認](/ja/enterprise-server@3.20/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization) および [組織のメール通知の制限](/ja/enterprise-server@3.20/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/restricting-email-notifications-for-your-organization) | | | 共同作成者が偶発的なコミットを行わないようにします。 | | | [リポジトリからの機微なデータの削除](/ja/enterprise-server@3.20/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#avoiding-accidental-commits-in-the-future) | | ## データ漏洩を検出する 組織をどれだけ適切に強化してデータ 漏洩を防いだとしても、一部が引き続き発生する可能性があり、 secret scanning、監査ログ、ブランチ保護規則を使用して対応できます。 ### secret scanning を使用する Secret scanning は、 GitHub リポジトリ内のすべてのブランチの完全な Git 履歴に誤ってコミットされたシークレットをスキャンして検出することで、コードをセキュリティで保護し、組織やリポジトリ全体でシークレットを安全に保つために役立ちます。 シークレット スキャン パートナー、他のサービス プロバイダーによって提供 パターンに一致する文字列は、リポジトリの \[ ** Security** ] タブでアラートとして報告されます。 > \[!TIP] > secret scanningとプッシュ保護の有効化状態に関係なく、GitHub TeamおよびGitHub Enterpriseの組織は無料のレポートを実行して、組織内のコードで漏洩したシークレットをスキャンできます。 [「AUTOTITLE」を](/ja/enterprise-server@3.20/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment)参照してください。 この機能を使用するには、サイト管理者がインスタンスの secret scanning を有効にする必要があります。 詳細については、 [AUTOTITLE を](/ja/enterprise-server@3.20/admin/code-security/managing-github-advanced-security-for-your-enterprise/configuring-secret-scanning-for-your-appliance)参照してください。 secret scanning の詳細については、「[シークレット スキャン](/ja/enterprise-server@3.20/code-security/secret-scanning/introduction/about-secret-scanning)」を参照してください。 また、リポジトリまたは組織のプッシュ保護としてsecret scanningを有効にすることもできます。 この機能を有効にすると、secret scanningでは、共同作成者が検出済みのシークレットを含むコードをプッシュできなくなります。 詳細については、 [AUTOTITLE を](/ja/enterprise-server@3.20/code-security/secret-scanning/protecting-pushes-with-secret-scanning)参照してください。 最後に、カスタム シークレット文字列構造を含むように検出を拡張することもできます。 詳細については、「[シークレット スキャンのカスタム パターンの定義](/ja/enterprise-server@3.20/code-security/secret-scanning/using-advanced-secret-scanning-and-push-protection-features/custom-patterns/defining-custom-patterns-for-secret-scanning)」を参照してください。 ### 組織の監査ログをレビューする また、組織の監査ログと、GraphQL 監査ログ API を利用することで、IP を事前にセキュリティで保護し、組織に合わせてコンプライアンスを維持することもできます。 詳細については、「[あなたの組織の監査ログを確認する](/ja/enterprise-server@3.20/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization)」および「[企業管理](/ja/enterprise-server@3.20/graphql/reference/enterprise-admin#interface-auditentry)」を参照してください。 ### ブランチ保護ルールを設定する 既定のブランチにマージされる前にすべてのコードが適切にレビューされることを保証するには、ブランチ保護を有効にします。 ブランチ保護ルールを設定すると、共同作成者が変更をプッシュする前に、特定のワークフローまたは要件を強制することができます。 詳細については、「[保護されたブランチについて](/ja/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)」を参照してください。 ブランチ保護規則の代わりに、ルールセットを作成できます。 ルールセットには、状態などのブランチ保護規則よりもいくつかの利点があり、管理者アクセスを必要とせずに検出可能性が向上します。 同時に複数のルールセットを適用することもできます。 詳しくは、「[ルールセットについて](/ja/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)」をご覧ください。 ## データ漏洩を軽減する ユーザーが機密データをプッシュした場合は、`git filter-repo` ツールを使って削除するように依頼してください。 詳細については、「[リポジトリからの機微なデータの削除](/ja/enterprise-server@3.20/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)」を参照してください。 また、機密データがまだプッシュされていない場合は、それらの変更をローカルで元に戻すことができます。詳細については、 [the GitHub Blog](https://github.blog/2015-06-08-how-to-undo-almost-anything-with-git/) を参照してください (ただし、 `git revert` は、元の機密コミットを Git 履歴に残しているため、機密データの追加を元に戻す有効な方法ではないことに注意してください)。 自分が所有していると確信できるデータをリポジトリ所有者と直接調整して削除することができない場合は、DMCA 削除通知フォームに記入して GitHub サポートにアラートとして通知できます。 問題のあるコミット ハッシュを必ず含めてください。 詳しくは、「[DMCA テイクダウン通知](https://support.github.com/contact/dmca-takedown)」を参照してください。 > \[!NOTE] > リポジトリの 1 つが虚偽の申し立てにより削除された場合は、DMCA 異議申し立て通知フォームに記入し、GitHub サポートに通知する必要があります。 詳しくは、「[DMCA カウンター通知](https://support.github.com/contact/dmca-counter-notice)」を参照してください。 ## 次のステップ * [サプライ チェーンのコードをセキュリティで保護するためのベスト プラクティス](/ja/enterprise-server@3.20/code-security/supply-chain-security/end-to-end-supply-chain/securing-code) * [ビルド システムをセキュリティで保護するためのベスト プラクティス](/ja/enterprise-server@3.20/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)