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

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

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

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

GitHub Enterpriseを使用すると、GitHubのすべてのガバナンス機能にアクセスでき、次の機能を使用できます。

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

<!-- Please note that we may move the sections below around once we've written them -->

## ブランチを保護する

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

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

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

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

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

詳細については、「[ルールセットについて](/ja/enterprise-server@3.22/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)」を参照してください。

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

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

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

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

[](/ja/enterprise-server@3.22/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise)を参照してください。

## メタデータを使用したポリシーのターゲット設定

ポリシーの自動適用を通じて、より優れたガバナンスを実現できます。 これは、カスタム プロパティを使用して可能であり、構造化されたメタデータをリソースに追加できます。
[「AUTOTITLE」を](/ja/enterprise-server@3.22/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/custom-properties)参照してください。

**リポジトリのカスタム プロパティ**を使用すると、リスク レベル、チームの所有権、コンプライアンス要件などの属性でリポジトリを分類できます。 このメタデータを使用すると、リポジトリの特性に基づいて異なるガバナンス 規則を自動的に適用できます。

**組織のカスタム プロパティ**を使用すると、企業内の組織をデータの機密性、規制フレームワーク、または部署別に分類できます。 その後、これらのプロパティを使用して、エンタープライズ ルールセットを使用して組織を選択的にターゲットにすることができます。

どちらの種類のカスタム プロパティもルールセットと統合されるため、手動リポジトリの選択ではなく、メタデータに基づいて適切なポリシーを自動的に適用する強力なガバナンス フレームワークを作成できます。

[Organization 内リポジトリのカスタム プロパティの管理](/ja/enterprise-server@3.22/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization) および [組織のカスタム プロパティの管理](/ja/enterprise-server@3.22/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/managing-custom-properties-for-organizations)
を参照してください。

## 活動の監視

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

GitHub の監査ログには、エンタープライズ アカウント、組織、および Enterprise Managed Users を使用している場合は管理対象ユーザーに関連する詳細なイベントが含まれます。 監査ログを課金アクティビティなどのテーマに絞り込むことや、侵害されたトークンに関連付けられたイベントを検索することができます。

監査ログにアクセスする方法については、「[企業の監査ログにアクセスする](/ja/enterprise-server@3.22/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/accessing-the-audit-log-for-your-enterprise)」を参照してください。

GitHub では、監査ログ データは無期限に保持されません。 監査ログを外部の場所にストリーミングすることをお勧めします。こうすると、データを必要な期間保持し、外部ツールでデータのクエリを実行できるようになります。 「[企業の監査ログのストリーミング](/ja/enterprise-server@3.22/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise)」を参照してください。

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

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

### Secret scanning

\*\*
secret scanning
\*\*を使用すると、コードをスキャンして、API キー、パスワード、コードベース内のその他の資格情報などの機密情報を検出し、不正アクセスや潜在的な侵害を防ぐことができます。
Secret scanning は、コードベース内の機密情報にアラートを送信し、パスワードの変更やトークンのローテーションによって適切に対応できるようにします。

詳細については、「[シークレット スキャン](/ja/enterprise-server@3.22/code-security/concepts/secret-security/secret-scanning)」を参照してください。

Secret scanning は、エンタープライズ、組織、およびリポジトリ レベルで有効にすることができます。 エンタープライズ レベルでの有効化については、 [アプライアンスのシークレットスキャンを設定する](/ja/enterprise-server@3.22/code-security/how-tos/secure-at-scale/configure-enterprise-security/configure-specific-tools/configure-secret-scanning) を参照してください。

### プッシュプロテクション

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

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

「[プッシュプロテクション](/ja/enterprise-server@3.22/code-security/concepts/secret-security/push-protection)」を参照してください。

プッシュ保護は、organization、リポジトリ、ユーザー アカウント レベルで有効にすることができます。 「[リポジトリのプッシュ保護の有効化](/ja/enterprise-server@3.22/code-security/how-tos/secure-your-secrets/prevent-future-leaks/enable-push-protection)」を参照してください。

> \[!NOTE]
> 現在、Enterprise および organization レベルでのプッシュ保護のパターンの構成は パブリック プレビュー 段階であり、変更される可能性があります。

シークレットの検出を内部のセキュリティ ポリシーと整合させ、リポジトリ内の機密情報の不正な開示をより効果的に防ぐために、Enterprise レベルまたは organization レベルでプッシュ保護に含めるシークレットのパターンをカスタマイズできます。 「[エンタープライズ用に追加のシークレット スキャン設定を設定する](/ja/enterprise-server@3.22/code-security/how-tos/secure-at-scale/configure-enterprise-security/establish-complete-coverage/configure-additional-settings#specifying-patterns-to-include-in-push-protection-for-your-enterprise)」と「[組織のグローバル セキュリティ設定の構成](/ja/enterprise-server@3.22/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/configure-global-settings#specifying-patterns-to-include-in-push-protection)」を参照してください。

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

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

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

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

* プッシュ保護のバイパス - プッシュ保護のバイパスを許可するユーザーを選び、他のすべての共同作成者からのシークレットを含むプッシュのレビューと承認サイクルを追加することができます。
  **プッシュ保護の委任されたバイパス**の詳細については、「[プッシュ保護用の委任バイパス](/ja/enterprise-server@3.22/code-security/concepts/secret-security/delegated-bypass)」を参照してください。
* code scanning
  、Dependabot、、secret scanningのアラートの無視 - 指定された個人のみがアラートを無視 (または閉じる) できるようにすることで、アラート評価に対する追加の制御と可視性を提供できます。
  **委任されたアラートの無視**の詳細については、次の記事を参照してください。
  * [コード スキャンに対して委任アラート無視を有効にする](/ja/enterprise-server@3.22/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/enable-delegated-alert-dismissal)
  * [Dependabot の委任されたアラートの無視を有効にする](/ja/enterprise-server@3.22/code-security/how-tos/manage-security-alerts/manage-dependabot-alerts/enable-delegated-alert-dismissal)
  * [シークレット スキャンの委任アラート無視を有効にする](/ja/enterprise-server@3.22/code-security/how-tos/manage-security-alerts/manage-secret-scanning-alerts/enable-delegated-dismissal)

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

多くの業界には、定期的なセキュリティ評価と脆弱性管理を必須とする規制があります。
\*\*
Code scanning
\*\* は、セキュリティで保護されていないパターンなど、コード内のセキュリティ リスクを特定して軽減することで、業界標準への準拠を確保するのに役立ちます。

Code scanning は CI/CD パイプラインに統合できるため、コードベースの継続的な監視と評価が提供されます。

code scanningの使用をすぐに開始するには、既定のセットアップを使用することをお勧めします。 「[コード スキャンの既定セットアップの構成](/ja/enterprise-server@3.22/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configure-code-scanning)」を参照してください。

Code scanning は、エンタープライズ、組織、およびリポジトリ レベルで有効にすることができます。 エンタープライズ レベルでの有効化については、 [アプライアンスのコード スキャンの構成](/ja/enterprise-server@3.22/code-security/how-tos/secure-at-scale/configure-enterprise-security/configure-specific-tools/configuring-code-scanning-for-your-appliance) を参照してください。