Enterprise のガバナンス フレームワークを確立する

GitHub Enterprise で利用できる機能とツールを使って、Enterprise のガバナンスとコンプライアンスを管理できます。

この記事の内容

Enterprise 所有者は、Enterprise 内の強力なセキュリティ態勢を維持し、規制に準拠し、リスクを軽減し、知的財産を保護する責任があります。 GitHub には、これに役立つツールがあります。

会社のコードを GitHub に格納すると、1 つの場所から簡単にコラボレーション、追跡、配置できるようになります。 できるだけ衝突することなくリポジトリで共同作業できるようにすることは、カルチャと生産性にとって重要ですが、コードの安全性と信頼性を確保するために、ユーザーの作業に何らかの制御を実装する必要があります。

GitHub Enterprise を使うと、GitHub のあらゆるガバナンス機能にアクセスでき、次のことが可能になります。

  • ユーザーがコードを更新する方法を制御する
  • ユーザーがリポジトリを使用する方法を管理する
  • アクティビティを監視する
  • 漏洩したシークレットを検出する
  • 重要なアクションの承認プロセスを設定する
  • コード内の脆弱性またはエラーを検出する

ブランチを保護する

運用コードを含むブランチなど、Enterprise のリポジトリ内の重要なブランチについては、コンプライアンス フレームワークによってエラーや悪意のあるコードが運用環境に入り込むリスクを軽減する必要があります。

ルールセットを使うと、特定のブランチに対するユーザーの操作方法を管理する規則を適用できます。 また、特定のユーザーに規則を明示的にバイパスする権限を与えることもできます。これにより、意図した制限を明確にしながら柔軟性を確保することができます。

多くの Enterprise は次のような規則を追加しています。

  • 削除を制限します。これにより、ユーザーが誤ってブランチを削除しないようにすることができます。
  • すべての変更に対して pull request を必須にします。これにより、書面による証跡を残し、レビューを適用することができます。
  • Pull request をマージする前に、ステータス チェックと配置が成功することを必須にします。これにより、運用環境でのエラーを防ぐことができます

署名済みコミットや線形コミット履歴を必須にするなどの他の規則は、より状況によるものであり、コンプライアンス要件に応じて変わります。

Enterprise 所有者は、規則を適用する対象のリポジトリとブランチを柔軟に設定するルールセットを Enterprise レベルで作成できます。 まず、Enterprise 内の既定のブランチすべてに基本レベルの保護を追加し、そこからフレームワークを構築できます。 始めるには、「Enterprise でルールセットを使ってコード ガバナンスを適用する」をご覧ください。

リポジトリの使用を管理する

リポジトリは会社のコードとデータが格納される場所であるため、データ漏えいのリスクを軽減するために、ユーザーがリポジトリをどのように操作できるかを定義することが重要です。 Enterprise 設定では、次のポリシーを設定できます。

  • リポジトリの既定の可視性を制限する
  • 非メンバーがリポジトリに招待されないようにする
  • リポジトリが organization の外部でフォークまたは譲渡されないようにする

ポリシーの目標は、コラボレーションを促進し、開発者の衝突を軽減しながら、セキュリティ要件を維持することです。 たとえば、Enterprise のすべてのパブリック リポジトリに対して "オープンソース" organization を作成し、他の organization ではパブリック リポジトリが作成されないようにすることができます。

制限を適用する最も簡単な方法は、リポジトリ ポリシーを作成することです。 これにより、Enterprise 内の organization やリポジトリを柔軟にターゲットにし、可視性、名前付け、作成、削除、譲渡に関する制限を適用できます。 「ユーザーが Enterprise 内のリポジトリを使用する方法の管理」を参照してください。

他のポリシーは包括的な制限として使用できます。 これらを使って、リポジトリのライフサイクルをより詳細に制御できますが、リポジトリ ポリシー機能ほど柔軟ではありません。 「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

活動の監視

何か問題が発生した場合、Enterprise 内のアクティビティを検索して問題の原因やスコープを調査できることが重要です。

GitHub の監査ログには、Enterprise アカウント、organization と、Enterprise Managed Users を使っている場合はマネージド ユーザーに関連する詳細なイベントが含まれます。 監査ログを課金アクティビティなどのテーマに絞り込むことや、侵害されたトークンに関連付けられたイベントを検索することができます。

監査ログにアクセスする方法については、「企業の監査ログにアクセスする」を参照してください。

GitHub による監査ログ データの保持期間は無期限ではありません。 監査ログを外部の場所にストリーミングすることをお勧めします。こうすると、データを必要な期間保持し、外部ツールでデータのクエリを実行できるようになります。 「Enterprise の監査ログのストリーミング」を参照してください。

機密情報がコードベースに到達しないようにする

知的財産を保護し、セキュリティ インシデントを防ぐには、トークンなどの機密情報をコードベースから遠ざけるシステムを実装することが重要です。

Secret scanning

secret scanning を使うと、コードをスキャンしてコードベース内の API キー、パスワード、その他の資格情報などの機密情報を検出し、不正アクセスや潜在的な侵害を防ぐことができます。 Secret scanning からコードベース内の機密情報について警告を受けて、パスワードを変更し、トークンをローテーションすることで適切に対応できます。パスワードなどの一般的なシークレットの場合、secret scanning は GitHub Copilot を利用し、AI を使います。 「Copilotシークレットスキャンを使用したジェネリックシークレットの責任ある検出」を参照してください

詳しくは、「シークレット スキャンについて」をご覧ください。

Secret scanning は、Enterprise、organization、リポジトリ レベルで有効にできます。 Enterprise レベルでの有効化については、「セキュリティ構成について」を参照してください。

プッシュ保護

さらに、プッシュ保護を使うと、機密データや資格情報が誤ってリポジトリにプッシュされるのを防ぐことができます。

リアルタイムでシークレットをスキャンし、機密情報が含まれる可能性のあるプッシュを禁止することで、プッシュ保護はセーフガードとして機能します。 Organization 所有者は organization レベルでプッシュ保護ポリシーを構成し、すべてのリポジトリに一貫性のあるセキュリティ標準を適用できます。 プッシュが禁止されると、開発者は、コードからシークレットを削除するなど、issue を修復する方法に関する詳細なガイダンスを受け取ります。

「プッシュ保護について」を参照してください。

プッシュ保護は、organization、リポジトリ、ユーザー アカウント レベルで有効にすることができます。 「リポジトリのプッシュ保護の有効化」を参照してください。

機密性の高いアクションの承認プロセスを設定する

Enterprise 内の誰が機密性の高いアクションを実行できるかをより適切に制御するために、承認プロセスを設定できます。 承認プロセスは、未承認または悪意のある変更のリスクを軽減するのに役立ち、誰がどのような理由でバイパスを使ったかを記録できるため、すべてのアクションを追跡可能にし、説明責任を確保することができます。

Note

これらの承認プロセスの実装は潜在的に衝突を引き起こす可能性があるため、続行する前にセキュリティ管理チームが適切な対応を確実に行うことが重要です。

承認プロセスは次の場合に使用できます。

セキュリティの脆弱性とエラーを特定する

多くの業界には、定期的なセキュリティ評価と脆弱性管理を必須とする規制があります。 Code scanning を使うと、安全ではないパターンなど、コード内のセキュリティ リスクを特定して軽減することで、業界標準へのコンプライアンスを確保できます。

Code scanning を CI/CD パイプラインに統合して、コードベースの継続的な監視と評価を実現できます。

code scanning をすぐに使い始めるには、既定の設定を使うことをお勧めします。 「コード スキャンの既定セットアップの構成」を参照してください。

Code scanning は、Enterprise、organization、リポジトリ レベルで有効にできます。 Enterprise レベルでの有効化については、「セキュリティ構成について」を参照してください。