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

組織内に存在するプライベートまたは機密データが公開されないようにするためのガイダンスと推奨事項について説明します。

この記事で

このガイドについて

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

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

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

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

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

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

          - SAML と SCIM の統合を使用してセキュリティで保護された認証プロセスを有効にし、可能な限り 2FA 認証を有効にします。 詳細については、「[AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on)」、「[AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations)」、「[AUTOTITLE](/authentication/securing-your-account-with-two-factor-authentication-2fa)」を参照してください。

  • 組織のメンバー、外部のコラボレーター、課金マネージャーに個人アカウントの 2FA を有効にするよう要求すると、悪意のあるアクターが組織のリポジトリと設定にアクセスすることが困難になります。 これは、セキュリティで保護された認証を有効にしてからさらに 1 ステップ進みます。 詳しくは、「Organization で 2 要素認証を要求する」をご覧ください。

  •         GitHub推奨されるパスワード ガイドラインに従って、強力なパスワードを作成し、適切にセキュリティで保護するようユーザーに促します。 詳細については、 [AUTOTITLE を](/authentication/keeping-your-account-and-data-secure/creating-a-strong-password)参照してください。

  • どのパブリック リポジトリにプッシュしても保護されるように、個人アカウント設定でユーザーのプッシュ保護を有効にしておくことをお勧めします。 詳細については、 AUTOTITLE を参照してください。

  •         GitHubで内部セキュリティ ポリシーを確立して、ユーザーが実行する適切な手順と、インシデントが疑われる場合に連絡するユーザーを把握できるようにします。 詳しくは、「[AUTOTITLE](/code-security/getting-started/adding-a-security-policy-to-your-repository)」をご覧ください。

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

データ漏洩を防止する

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

勧告詳細情報
リポジトリをフォークする機能を無効にします。
          [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 in GitHub Marketplace 自分のドメインを検証し、検証済みのメール ドメインのみにメール通知を制限することで、自分の組織の ID であることを立証します。 | 組織のためのドメインの検証または承認 および 組織のメール通知の制限 標準サービス条件を使用する代わりに、組織が GitHub 顧客契約にアップグレードしたことを確認します。 | GitHub顧客契約へのアップグレード 共同作成者が偶発的なコミットを行わないようにします。 | リポジトリからの機微なデータの削除

データ漏洩を検出する

組織をどれだけ適切に強化してデータ 漏洩を防いだとしても、一部が引き続き発生する可能性があり、 secret scanning、監査ログ、ブランチ保護規則を使用して対応できます。

          secret scanning を使用する

          Secret scanning は、 GitHub リポジトリ内のすべてのブランチの完全な Git 履歴に誤ってコミットされたシークレットをスキャンして検出することで、コードをセキュリティで保護し、組織やリポジトリ全体でシークレットを安全に保つために役立ちます。 シークレット スキャン パートナー、他のサービス プロバイダーによって提供 、またはユーザーまたは組織によって定義された パターンに一致する文字列は、リポジトリの [ **セキュリティ** ] タブでアラートとして報告されます。


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

* パートナーに対するシークレット スキャンニング アラート: これらは既定で有効になっており、すべてのパブリック リポジトリとパブリック npm パッケージで自動的に実行されます。 * ユーザーのシークレット スキャン アラート: 組織の追加のスキャン機能を取得するには、 ユーザーのシークレット スキャン アラートを有効にする必要があります。

有効にすると、次の種類のリポジトリで ユーザーのシークレット スキャン アラート を検出できます。のライセンスを所持し所有するプライベートリポジトリおよび内部リポジトリ * GitHub Enterprise Cloudを使用する組織が所有するパブリックリポジトリ

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

ヒント

          secret scanningとプッシュ保護の有効化状態に関係なく、GitHub TeamおよびGitHub Enterpriseの組織は無料のレポートを実行して、組織内のコードで漏洩したシークレットをスキャンできます。 

          [「AUTOTITLE」を](/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment)参照してください。

          

          secret scanning の詳細については、「[AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)」を参照してください。

          また、リポジトリまたは組織のプッシュ保護としてsecret scanningを有効にすることもできます。 この機能を有効にすると、secret scanningでは、共同作成者が検出済みのシークレットを含むコードをプッシュできなくなります。 詳細については、 [AUTOTITLE を](/code-security/secret-scanning/protecting-pushes-with-secret-scanning)参照してください。 最後に、カスタム シークレット文字列構造を含むように検出を拡張することもできます。 詳しくは、「[AUTOTITLE](/code-security/secret-scanning/using-advanced-secret-scanning-and-push-protection-features/custom-patterns/defining-custom-patterns-for-secret-scanning)」をご覧ください。

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

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

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

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

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

データ漏洩を軽減する

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

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

メモ

リポジトリの 1 つが虚偽の申し立てにより削除された場合は、DMCA 異議申し立て通知フォームに記入し、GitHub サポートに通知する必要があります。 詳しくは、「DMCA カウンター通知」を参照してください。

公開されたトークンを取り消す

資格情報が GitHub リポジトリで公開されている場合は、 GitHubsecret scanning を使用して資格情報のレポートと取り消しを行うことができます。 詳しくは、「シークレット スキャンからのアラートの解決」をご覧ください。

所有しておらず、GitHub リポジトリの外部で漏洩した資格情報を取り消すこともできます。 これにより、 GitHub コミュニティの全体的なセキュリティに貢献し、これらの資格情報の影響をすばやく制限できます。 API では、次の権限取り消しがサポートされています。

  •         Personal access tokens (classic)
        `ghp_` プレフィックス付き

  •         Fine-grained personal access tokens
        `github_pat_` プレフィックスを使った

  •         OAuth app
        `gho_` プレフィックスを持つトークン

  •         GitHub App
        `ghu_` プレフィックスを持つユーザーからサーバーへのトークン

  •         GitHub App
        `ghr_` プレフィックスを使用してトークンを更新する

        GitHubまたは他の場所で公開されているトークンがある場合は、REST API を使用して失効要求を送信できます。 サポートされている資格情報の種類の完全で権限のある一覧については、 [AUTOTITLE](/rest/credentials/revoke#revoke-a-list-of-credentials) を参照してください。

次のステップ

  •         [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)