リポジトリと組織のプッシュ保護について
これまで、secret scanning は、プッシュの "後" でシークレットをチェックし、公開されたシークレットについてユーザーに警告します。__ 組織またはリポジトリのプッシュ保護を有効にすると、secret scanning は、プッシュで信頼性の高いシークレット (誤検知率が低いと特定されたシークレット) もチェックします。 Secret scanning には、作成者がシークレットを確認して削除できるように、検出したシークレットが一覧表示されます。また、必要に応じて、それらのシークレットをプッシュできるようにします。
共同作成者がシークレットのプッシュ保護ブロックをバイパスする場合、GitHub では次のことが行われます。
- リポジトリの [セキュリティ] タブに、以下の表で説明されている状態のアラートが作成される。
- バイパス イベントを監査ログに追加する。
- リポジトリを監視している Organization または個人アカウントの所有者、セキュリティ マネージャー、リポジトリ管理者に、シークレットへのリンクとそれが許可された理由を含むメール アラートを送信する。
注: github.dev Web ベースのエディターでは、プッシュ保護はサポートされていません。 エディターの詳細については、「github.dev Web ベース エディター」を参照してください。
ユーザーがプッシュ保護を迂回し、アラートを起動させた瞬間を見つけるセキュリティ アラートを監視できます。 詳しくは、「セキュリティ アラートの監査」を参照してください。
次の表は、ユーザーがプッシュ保護ブロックをバイパスする方法ごとのアラートの動作を示しています。
バイパスの理由 | アラート動作 |
---|---|
It's used in tests (テストで使用) | GitHub は、"テストで使用" として解決されたクローズしたアラートを作成します |
It's a false positive (偽陽性) | GitHub は、"偽陽性" として解決されたクローズしたアラートを作成します |
I'll fix it later (後で修正) | GitHub は、オープンなアラートを作成します |
プッシュ保護のためにサポートされるシークレットとサービス プロバイダーの詳細については、「secret scanning パターン」を参照してください。
さらに、プッシュ保護を自分で有効にして、プッシュ先のパブリック リポジトリに関係なく保護することができます。 詳しくは、「ユーザーのプッシュ保護」を参照してください。
プッシュ保護としての secret scanning の有効化
secret scanning をパブリック リポジトリでプッシュ保護として使用するには、Organizationまたはリポジトリで secret scanning を有効にする必要があります。詳細については、「Organization のセキュリティおよび分析設定を管理する」、「リポジトリのセキュリティと分析設定を管理する」、および「GitHub Advanced Security について」を参照してください。
組織所有者、セキュリティ マネージャー、リポジトリ管理者は、API を使って、secret scanning のプッシュ保護を有効にすることもできます。 詳細については「リポジトリ」を参照し、REST API ドキュメントの "security_and_analysis
オブジェクトのプロパティ" セクションを展開します。
注: secret scanning をプッシュ保護として有効にしてリポジトリをフォークした場合、この機能は既定では有効になっていません。 スタンドアロン リポジトリで有効にするのと同じ方法で、フォークで有効にすることができます。
組織のプッシュ保護としての secret scanning の有効化
[コードのセキュリティと分析] の組織設定ページを使って、組織内のすべての既存リポジトリで、プッシュ保護としての secret scanning を有効または無効にできます。
-
GitHub.com で、Organization のメイン ページへ移動します。
-
組織名の下で、 [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
サイドバーの [セキュリティ] セクションで、 [コードのセキュリティと分析] をクリックします。
-
[コードのセキュリティと分析] の下で、「GitHub Advanced Security」を見つけてください。
-
Secret scanning の [プッシュ保護] の下にある [すべて有効にする] をクリックします。
-
必要に応じて、[Automatically enable for repositories added to secret scanning] をクリックしてください。
-
メンバーがシークレットの push を試みると表示されるメッセージ内にカスタム リンクを含めるには、必要に応じて、 [コミットがブロックされたらリソース リンクを CLI と Web UI に追加する] を選んで、URL を入力したら [リンクの保存] をクリックしてください。
組織全体でセキュリティ機能を有効にする方法の詳細については、「組織のセキュリティ保護」を参照してください。
リポジトリのプッシュ保護としての secret scanning の有効化
- GitHub.com で、リポジトリのメイン ページへ移動します。
- リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
- サイドバーの [セキュリティ] セクションで、 [コードのセキュリティと分析] をクリックします。
- [コードのセキュリティと分析] の下で、「GitHub Advanced Security」を見つけてください。
- Secret scanning の [Push protection](プッシュ保護) の下にある [有効にする] をクリックします。
カスタム パターンのプッシュ保護を有効にする
組織またはリポジトリ レベルで保存されたカスタム パターンのプッシュ保護として、secret scanning を有効にすることができます。
組織でカスタム パターンのプッシュ保護として secret scanning を有効にする
組織レベルでカスタム パターンのプッシュ保護を有効にする前に、組織内でスキャンするリポジトリに対して secret scanning を必ず有効にする必要があります。 組織のすべてのリポジトリで secret scanning を有効にするには、「Organization のセキュリティおよび分析設定を管理する」を参照してください。
-
GitHub.com の右上隅にあるプロファイル写真をクリックし、 [自分の Organization] をクリックします。
-
組織の隣の [設定] をクリックします。
-
サイドバーの [セキュリティ] セクションで、 [コードのセキュリティと分析] をクリックします。
-
[コードのセキュリティと分析] の下で、「GitHub Advanced Security」を見つけてください。
-
[Secret scanning] の [カスタム パターン] で、目的のパターンの をクリックします。
-
カスタム パターンのプッシュ保護を有効にするには、[プッシュ保護] まで下にスクロールして、 [有効化] をクリックします。
注:
- カスタム パターンのプッシュ保護は、プッシュ保護として secret scanning が有効になっている組織のリポジトリにのみ適用されます。 詳しくは、「リポジトリと組織のプッシュ保護」を参照してください。
- 一般的なカスタム パターンに対してプッシュ保護を有効にすると、共同作成者が混乱する可能性があります。
リポジトリでカスタム パターンのプッシュ保護として secret scanning を有効にする
リポジトリ レベルでカスタム パターンのプッシュ保護を有効にする前に、リポジトリのカスタム パターンを定義し、それをリポジトリ内でテストする必要があります。 詳しくは、「シークレット スキャンのカスタム パターンの定義」を参照してください。
-
GitHub.com で、リポジトリのメイン ページへ移動します。
-
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。
-
サイドバーの [セキュリティ] セクションで、 [コードのセキュリティと分析] をクリックします。
-
[コードのセキュリティと分析] の下で、「GitHub Advanced Security」を見つけてください。
-
[Secret scanning] の [カスタム パターン] で、目的のパターンの をクリックします。
-
カスタム パターンのプッシュ保護を有効にするには、[プッシュ保護] まで下にスクロールして、 [有効化] をクリックします。
コマンド ラインからのプッシュ保護としてシークレット スキャンを使用する
プッシュ保護としての secret scanning が有効になっているリポジトリまたは組織に、サポートされているシークレットをプッシュしようとすると、GitHub によってプッシュがブロックされます。 ブランチからシークレットを削除するか、指定された URL に従ってプッシュを許可できます。
検出されたシークレットは、コマンド ラインに一度に最大 5 つ表示されます。 リポジトリで特定のシークレットが既に検出されていて、アラートが既に存在する場合、GitHub はそのシークレットをブロックしません。
Organization の所有者は、プッシュがブロックされると表示されるカスタム リンクを指定できます。 このカスタム リンクには、推奨されるシークレット コンテナーの使用についての指示や、ブロックされたシークレットに関連する質問を問い合わせるユーザーなど、Organization 固有のリソースやアドバイスを含めることができます。
シークレットが本物であることを確認したら、再度プッシュする前に、ブランチから ("それが表示されるすべてのコミットから") シークレットを削除する必要があります。__ ブロックされたシークレットの修復について詳しくは、「プッシュ保護によってブロックされたブランチをプッシュする」を参照してください。
シークレットが本物で、後で修正する予定であることを確認する場合は、できるだけ早くシークレットの修復を目指す必要があります。 たとえば、シークレットを取り消し、リポジトリのコミット履歴からシークレットを削除できます。 不正アクセスを回避するために、公開されている実際のシークレットを取り消す必要があります。 取り消す前に、まずシークレットをローテーションすることを検討できます。 詳しくは、「リポジトリからの機微なデータの削除」を参照してください。
注:
- Git 構成で現在のブランチだけでなく、複数のブランチへのプッシュがサポートされている場合、追加の意図しない参照がプッシュされるため、プッシュがブロックされる可能性があります。 詳細については、Git ドキュメントの
push.default
オプションを参照してください。 - プッシュ時にsecret scanningがタイムアウトした場合でも、GitHub ではプッシュ後もシークレットのコミットをスキャンします。
ブロックされたシークレットのプッシュを許可する
GitHub が、プッシュしても安全であると思われるシークレットをブロックする場合は、シークレットを許可し、許可する必要がある理由を指定できます。
シークレットのプッシュを許可すると、 [セキュリティ] タブにアラートが作成されます。シークレットが擬陽性かテスト用のみであれば、GitHub によってアラートが閉じられ、通知が送信されません。 シークレットが実際のものであり、後で修正することを指定した場合、GitHub はセキュリティ アラートを開いたままにし、コミットの作成者とリポジトリ管理者に通知を送信します。 詳しくは、「シークレット スキャンからのアラートの管理」を参照してください。
共同作成者がシークレットのプッシュ保護ブロックをバイパスすると、GitHub により、電子メール通知をオプトインした Organization の所有者、セキュリティ マネージャー、リポジトリ管理者にも電子メール アラートが送信されます。
- プッシュがブロックされたときに GitHub から返される URL にアクセスします。
- シークレットをプッシュできる理由を最もよく表しているオプションを選択します。
- シークレットがテストでのみ使用され、脅威がない場合は、 [テストで使用されます] をクリックします。
- 検出された文字列がシークレットでない場合は、 [誤検知です] をクリックします。
- シークレットが本物で、後で修正する予定の場合は、 [後で修正します] をクリックします。
- [このシークレットをプッシュできるようにする] をクリックします。
- 3 時間以内にコマンド ラインでプッシュを再試行します。 3 時間以内にプッシュしていない場合は、このプロセスを繰り返す必要があります。
Web UI からのプッシュ保護としてシークレット スキャンを使用する
Web UI を使用して、プッシュ保護が有効になっているシークレット スキャンを使用して、サポートされているシークレットをリポジトリまたは organization にコミットすると、GitHub によってプッシュがブロックされます。
シークレットの場所に関する情報と、シークレットをプッシュできるオプションを含むダイアログ ボックスが表示されます。 簡単に見つけられるように、ファイルではシークレットに下線も引かれています。
GitHub では、Web UI で検出されたシークレットを一度に 1 つのみ表示します。 リポジトリで特定のシークレットが既に検出されていて、アラートが既に存在する場合、GitHub はそのシークレットをブロックしません。
Organization の所有者は、プッシュがブロックされると表示されるカスタム リンクを指定できます。 このカスタム リンクには、Organization 固有のリソースとアドバイスを含めることができます。 たとえば、Organization のシークレット コンテナー、質問をエスカレートするチームや個人、シークレットの操作とコミット履歴の書き換えに関して Organization で承認されたポリシーに関する情報を含む README ファイルをカスタム リンクが指すようにすることができます。
Web UI を使用して、ファイルからシークレットを削除できます。 シークレットを削除すると、変更をコミットできるようになります。
シークレットのプッシュ保護をバイパスする
シークレットが本物であることを確認したら、再度プッシュする前に、ブランチから ("それが表示されるすべてのコミットから") シークレットを削除する必要があります。__ ブロックされたシークレットの修復について詳しくは、「プッシュ保護によってブロックされたブランチをプッシュする」を参照してください。
シークレットが本物で、後で修正する予定であることを確認する場合は、できるだけ早くシークレットの修復を目指す必要があります。 詳しくは、「リポジトリからの機微なデータの削除」を参照してください。
GitHub が、プッシュしても安全であると思われるシークレットをブロックする場合は、シークレットを許可し、許可する必要がある理由を指定できます。
シークレットのプッシュを許可すると、 [セキュリティ] タブにアラートが作成されます。シークレットが擬陽性かテスト用のみであれば、GitHub によってアラートが閉じられ、通知が送信されません。 シークレットが実際のものであり、後で修正することを指定した場合、GitHub はセキュリティ アラートを開いたままにし、コミットの作成者とリポジトリ管理者に通知を送信します。 詳しくは、「シークレット スキャンからのアラートの管理」を参照してください。
共同作成者がシークレットのプッシュ保護ブロックをバイパスすると、GitHub により、電子メール通知をオプトインした Organization の所有者、セキュリティ マネージャー、リポジトリ管理者にも電子メール アラートが送信されます。
- GitHub がコミットをブロックしたときに表示されるダイアログ ボックスで、シークレットの名前と場所を確認します。
- シークレットをプッシュできる理由を最もよく表しているオプションを選択します。
- シークレットがテストでのみ使用され、脅威がない場合は、 [テストで使用されます] をクリックします。
- 検出された文字列がシークレットでない場合は、 [誤検知です] をクリックします。
- シークレットが本物で、後で修正する予定の場合は、 [後で修正します] をクリックします。
- [シークレットの許可] をクリックします。