# セキュリティ上の脅威からの保護

GitHubで組織全体のセキュリティ上の脅威にさらされるリスクを減らすために、近い将来、継続的に、どのような手順を実行する必要がありますか?

## Introduction

セキュリティ インシデントの防止は、それらに対応するよりもコストが低く、中断が少なくなります。
GitHubで環境を事前に強化することで、悪用された資格情報、未承認のアクセス、サプライ チェーン攻撃などの脅威にさらされるリスクを軽減できます。

このガイドでは、主に、 GitHub Enterprise Cloud上の企業の一部である組織全体に適用できる保護措置に焦点を当てています。 試用 GitHub Enterprise Cloudについては、 [GitHub Enterprise Cloud の試用版の設定](/ja/enterprise-cloud@latest/admin/overview/setting-up-a-trial-of-github-enterprise-cloud) を参照してください。

ここで説明する GitHubのセキュリティ機能の多くは、セキュリティ構成、ブランチ ルールセット、アクセス制御など、組織レベルまたはエンタープライズ レベルの両方で構成できます。

## 即時対応

これらは、組織全体でセキュリティ ベースラインを確立するために、今すぐ実行できる影響の大きいアクションです。

* [セキュリティ カバレッジを確立する](#establish-security-coverage)
* [コントロールを強化する](#tighten-controls)
* [アクセスの確認と制限](#review-and-restrict-access)
* [シークレット リスク評価を実行する](#run-a-secret-risk-assessment)

### セキュリティ カバレッジを確立する

GitHubのGitHub Advanced Security ツールがすべてのリポジトリでアクティブになっていることを確認します。 ツールを 1 つずつ有効にするのではなく、 **セキュリティ構成**を作成して適用できます。セキュリティ構成は、組織全体または企業のリポジトリに 1 つのアクションで適用できるセキュリティ設定のコレクションです。

強力な構成には、次のものが含まれる場合があります。

* **Secret scanning** と **プッシュ保護** を使用して、コードベースに既にコミットされているシークレットを検出し、新しいシークレットがプッシュされないようにします。 漏洩した資格情報は、セキュリティ侵害の最も一般的な原因の 1 つです。
* **Code scanning** を使用して、運用環境に到達する前にソース コードの脆弱性とコーディング エラーを特定します。
* **Dependabot alerts** および **Dependabot security updates** により、依存関係に含まれる既知の脆弱性やマルウェアについて通知し、脆弱な依存関係を更新するための pull request を自動的に開きます。

[「AUTOTITLE」](/ja/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/create-custom-configuration)(組織) および[「AUTOTITLE」](/ja/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-enterprise-security/establish-complete-coverage/create-custom-configuration) (エンタープライズ) を参照してください。

### コントロールを強化する

GitHub では、リポジトリと組織で何が起こるかを制御するさまざまなコントロールが提供されます。 リスクを軽減するには、これらのコントロールを適切に構成することが不可欠です。

#### ルールセットを使用して重要なブランチを保護する

ルールセットを使用すると、1 つ以上のリポジトリにわたるブランチとタグの保護規則を定義できます。 プル要求のレビューや状態チェック (自動セキュリティ スキャンなど) などの要件を適用するために使用します。 これにより、侵害されたアカウントからの変更など、承認されていない変更が運用環境のコードに到達するのを防ぐことができます。

[「AUTOTITLE」](/ja/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)(組織) および[「AUTOTITLE」](/ja/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-governance) (エンタープライズ) を参照してください。

#### プッシュ保護をバイパスできるユーザーを制御する

プッシュ保護を有効にすると、検出されたシークレットをプッシュしようとした共同作成者はブロックされますが、既定ではブロックをバイパスするオプションがあります。
**委任されたバイパス** では、バイパス要求がレビューと承認サイクルを通過する必要があるため、明示的で監査された決定なしにバイパスを行う必要はありません。

「[Enabling delegated bypass for push protection](/ja/enterprise-cloud@latest/code-security/how-tos/secure-your-secrets/manage-bypass-requests/enable-delegated-bypass)」を参照してください。

#### プル要求に依存関係の確認を適用する

依存関係レビュー アクションを使用すると、プル要求の依存関係の変更で既知の脆弱性を検出することで、マージされる前に脆弱な依存関係をキャッチできます。 シークレットのプッシュ保護と同様に、事後アラートではなくゲートとして機能します。 組織全体の pull request に依存関係の確認を適用できます。

「[依存関係の確認](/ja/code-security/concepts/supply-chain-security/dependency-review#about-the-dependency-review-action)」と「[organization 全体で依存関係レビューを実施する](/ja/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review)」を参照してください。

### アクセスの確認と制限

許可されたときに適切なアクセスは不要になる場合があります。 組織にアクセスできるユーザーとアクセス権を定期的に確認することで、承認されていないアクションのリスクが軽減されます。

#### メンバー アクセスを監査し、最小特権の原則に従う

組織のメンバーが必要なアクセス権のみを持っていることを確認します。 アクセスが不要になったメンバーを削除し、より広範なアクセス許可が正当化されないロールをダウングレードし、外部のコラボレーター アクセスを確認します。 アクセスが過度に制限されると、侵害されたアカウントの爆発半径が増加します。

既定のロールが組織が必要とするよりも制限が大きい場合は、各チームが必要とする特定のアクセス許可のみを付与する **カスタム ロール** を作成できます。 これは、ゼロ トラスト セキュリティ モデルを採用している組織にとって特に重要です。

「[企業で必要なロールの識別](/ja/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-roles-in-your-enterprise/identify-role-requirements)」を参照してください。

#### 承認されたアプリケーションを確認する

OAuth apps および組織にインストールされている GitHub Apps は、データにアクセスできます。 承認されたアプリケーションの一覧を確認し、不要になったアプリケーションまたは信頼されなくなったアプリケーションを削除します。 古い統合は、見過ごされがちな攻撃面となっています。

「[インストールされている GitHub Apps の確認と変更](/ja/apps/using-github-apps/reviewing-and-modifying-installed-github-apps)」と「[OAuth アプリのアクセス制限について](/ja/enterprise-cloud@latest/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions)」を参照してください。

#### IP 許可リストを使用してネットワーク アクセスを制限する

GitHub Enterprise Cloud上の組織の場合、組織が既知のネットワーク範囲から運用している場合は、IP 許可リストを構成して、それらの範囲からのGitHubリソースへのアクセスのみを制限します。 これにより、予期しない場所から使用される侵害された資格情報に対する防御レイヤーが追加されます。

「[組織に対する許可 IP アドレスを管理する](/ja/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization)」と「[IP 許可リストを使用して Enterprise へのネットワーク トラフィックを制限する](/ja/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list)」を参照してください。

### シークレット リスク評価を実行する

組織のリポジトリに対して無料のオンデマンド スキャンを実行すると、組織全体で現在公開されているシークレットの合計数を特定の時点で確認できます。

「[組織のシークレット リスク評価の実行](/ja/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/assess-your-secret-risk)」を参照してください。

## 短期的なアクション

これらのアクションはセキュリティ体制にも重要ですが、展開する前に、より多くの準備と調整が必要になる場合があります。

* [認証の強化](#strengthen-authentication)
* [
  GitHub Actions ワークフローを強化する](#harden-your-github-actions-workflows)
* [セキュリティ インシデントの準備](/ja/code-security/tutorials/secure-your-organization/prepare-for-a-security-incident)

### 認証の強化

弱い認証または侵害された認証は、アカウントの引き継ぎの最も一般的な原因の 1 つです。 組織全体で強力な認証を要求すると、このリスクが大幅に軽減されます。

すべてのメンバーに 2 要素認証 (2FA) が必要です。これにより、侵害されたパスワードだけではアカウントにアクセスできません。 要件を適用する前に、組織と通信して、メンバーが 2FA を設定する時間を取るようにします。

GitHub Enterprise Cloud上の組織は、ID プロバイダーを介して認証を一元化するシングル サインオン (SSO) を適用することで、さらに進むことができます。

「[Organization で 2 要素認証を要求する](/ja/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)」と「[SAML シングルサインオンを使うアイデンティティおよびアクセス管理について](/ja/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on)」を参照してください。

### GitHub Actions ワークフローを強化する

GitHub Actions 多くの場合、ワークフローはシークレット、デプロイ資格情報、リポジトリへの書き込みアクセス許可にアクセスできます。 慎重に構成しないと、侵害されたアクションや悪意のあるアクションによってデータが流出したり、悪意のあるコードが挿入されたりする可能性があります。

#### ワークフローのアクセス許可を明示的に宣言する

既定では、ワークフローは `GITHUB_TOKEN`を介して広範なアクセス許可を受け取る場合があります。 ワークフロー ファイル内の `permissions` キーを使用して、各ワークフローに必要な最小限のアクセス許可を明示的に宣言します。 これにより、侵害されたワークフロー ステップが引き起こす可能性のある損害が制限されます。

#### サードパーティのアクションを固定して SHA をコミットする

タグ (たとえば、 `v1`) によってサード パーティのアクションを参照する場合、タグは別のコードを指すように移動できます。 アクションを完全コミット SHA にピン留めすることで、レビューして承認した正確なコードを常に実行できます。 これにより、タグがハイジャックされたサプライ チェーン攻撃から保護されます。

#### 実行できるアクションを制限する

実行を許可するアクションを制御するには、組織レベルまたはエンタープライズ レベルでポリシーを構成します。 アクションは、 GitHubによって作成されたもの、検証済みの作成者からのアクション、または特定の許可リストに制限できます。

これらのプラクティスの詳細と、特に GitHub Actions のセキュリティで保護されたその他の使用方法については、 [セキュリティで保護された使用に関するリファレンス](/ja/actions/reference/security/secure-use) を参照してください。

## 継続的なセキュリティプラクティス

これらのプラクティスは、通常の運用リズムの一部になる必要があります。

* [セキュリティの概要を使用してセキュリティ体制を監視する](#monitor-your-security-posture-with-security-overview)
* [定期的なセキュリティ キャンペーンを実行してセキュリティ負債を削減する](#run-regular-security-campaigns-to-reduce-security-debt)
* [引き続きアクセスとアクセス許可の監査を行う](#continue-to-audit-access-and-permissions)
* [依存関係を最新の状態に保つ](#keep-dependencies-up-to-date)
* [シークレットをローテーションし、有効期限を適用する](#rotate-secrets-and-enforce-expiration)

### セキュリティの概要を使用してセキュリティ体制を監視する

セキュリティの概要では、組織と企業のセキュリティランドスケープを一元的に把握できます。 これを使用して、セキュリティ機能が有効になっているリポジトリを追跡し、オープンアラートが存在するリポジトリを確認することで、新たに発生するリスクを見逃さないようにします。

「[セキュリティの概要](/ja/enterprise-cloud@latest/code-security/concepts/security-at-scale/security-overview)」を参照してください。

### 定期的なセキュリティ キャンペーンを実行してセキュリティ負債を削減する

時間の経過と同時に、セキュリティ アラートが蓄積される可能性があります。 セキュリティ キャンペーンを使用すると、修復作業の整理と優先順位付けを行ったり、開発者にアラートのグループを割り当てたり ( Copilot生成された修正プログラムの助けを借りて)、アラートを Copilotに直接割り当てたりすることができます。

組織は、GitHub TeamまたはGitHub Enterprise CloudでGitHub Secret Protection or GitHub Code Securityが有効になっている場合、セキュリティキャンペーンを利用可能です。 「[セキュリティ キャンペーンの作成と管理](/ja/enterprise-cloud@latest/code-security/how-tos/manage-security-alerts/remediate-alerts-at-scale/creating-managing-security-campaigns)」を参照してください。

### 引き続きアクセスとアクセス許可の監査を行う

ユーザーが組織に参加して退職したり、プロジェクトが進化するにつれて、アクセス要件が変わります。 以下の定期的なレビューをスケジュールします。

* 組織のメンバーシップとロール。
* 外部のコラボレーターへのアクセス。
* リポジトリ レベルのアクセス許可とチームの割り当て。
* 承認された OAuth と GitHub Apps。

これにより、組織が変更されても、アクセスは最小限の特権の原則に従って維持されます。

### 依存関係を最新の状態に保つ

脆弱な依存関係は、攻撃者にとって一般的なエントリ ポイントです。
Dependabot は、既知の脆弱性を持つ依存関係を更新するために pull request を自動的に開くことができますが、それらのプル要求は引き続きすぐに確認してマージする必要があります。

セキュリティ更新プログラムが停滞しないようにするために、プルリクエスト Dependabot をトリアージし、マージするプロセスを確立します。

「[Dependabot 自動優先順位設定ルール](/ja/enterprise-cloud@latest/code-security/concepts/supply-chain-security/dependabot-auto-triage-rules)」と「[依存関係の更新に関するPull Requestを管理する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/manage-dependabot-prs)」を参照してください。

### シークレットをローテーションし、有効期限を適用する

資格情報が長いほど、公開または盗用される機会が多くなります。 可能な場合:

* personal access tokensに有効期限を設定します。
* シークレットを定期的にローテーションします。

トークンの管理については、 [個人用アクセス トークンを管理する](/ja/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) と [トークンの有効期限と取り消し](/ja/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation) を参照してください。

## 次のステップ

* 強力な予防管理が実施されていても、セキュリティ インシデントは引き続き発生する可能性があります。 事前に設定しておく必要がある重要なツールと応答プロセスがいくつかあります。 「[セキュリティ インシデントの準備](/ja/code-security/tutorials/secure-your-organization/prepare-for-a-security-incident)」を参照してください。