# 防范安全威胁

在不久的将来，我应该采取哪些措施，并持续减少组织中 GitHub安全威胁的暴露？

## Introduction

与响应安全事件相比，防止安全事件的成本更低，破坏性更低。 通过在 GitHub 上主动强化环境，可以降低凭据被利用、未经授权访问和供应链攻击等威胁带来的风险。

本指南主要重点讲解可在 GitHub Enterprise Cloud 上跨企业组织应用的保护措施。 若要试用 GitHub Enterprise Cloud，请参阅 [设置 GitHub Enterprise Cloud 试用版](/zh/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)

### 建立安全防护措施

确保所有GitHubGitHub Advanced Security存储库中的工具都处于活动状态。 你可以创建并应用 **安全配置**，而不是逐个启用工具，这是一系列安全设置，可在单个操作中应用于整个组织或企业的存储库。

强配置可能包括：

* **Secret scanning** 和**推送保护**，以检测已提交到代码库的机密，并阻止推送新机密。 泄露的凭据是安全漏洞的最常见原因之一。
* **Code scanning** 在源代码到达生产环境之前识别漏洞和编码错误。
* **Dependabot alerts** 并 **Dependabot security updates** 通知你依赖项中的已知漏洞和恶意软件，并自动打开拉取请求以更新易受攻击的依赖项。

请参阅 [删除自定义安全配置](/zh/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/create-custom-configuration)（组织）和 [为企业创建自定义安全配置](/zh/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-enterprise-security/establish-complete-coverage/create-custom-configuration)（企业）。

### 收紧控制

GitHub 提供一系列控制措施，用于控制存储库和组织中可能发生的情况。 确保正确配置这些控件对于降低风险至关重要。

#### 使用规则集保护关键分支

规则集允许跨一个或多个存储库定义分支和标记的保护规则。 使用它们强制执行拉取请求评审和状态检查（例如自动安全扫描）等要求。 这有助于防止未经授权的更改访问生产代码，包括来自已泄露帐户的更改。

请参阅 [创建组织中存储库的规则集](/zh/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)（组织）和 [使用规则集在企业中强制实施代码治理](/zh/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-governance)（企业）。

#### 控制可以绕过推送保护的人员

启用推送保护时，尝试推送检测到的机密的参与者会被阻止，但默认情况下，他们可以选择绕过阻止。
**委派的绕过** 要求绕过请求通过评审和审批周期，因此，如果没有显式的审核决策，则不会发生绕过。

请参阅“[Enabling delegated bypass for push protection](/zh/enterprise-cloud@latest/code-security/how-tos/secure-your-secrets/manage-bypass-requests/enable-delegated-bypass)”。

#### 在拉取请求上强制实施依赖项审核

通过显示拉取请求的依赖项更改中的已知漏洞，依赖项评审操作允许你在合并依赖项之前捕获易受攻击的依赖项。 如同机密的推送保护，它充当入口，而不是事后警报。 可以在整个组织中强制实施对拉取请求的依赖项评审。

请参阅 [依赖项审查](/zh/code-security/concepts/supply-chain-security/dependency-review#about-the-dependency-review-action) 和 [在整个组织内强制执行依赖项审查](/zh/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review)。

### 审查和限制访问

授予访问权限时是适当的，但之后可能不再需要。 定期评审谁以及有权访问组织的人员可降低未经授权的操作的风险。

#### 审核成员访问权限并遵循最低特权原则

确保组织成员仅具有所需的访问权限。 移除那些不再需要访问权限的成员，降级那些不需要更多权限的角色，并审核外部协作者的访问权限。 过于宽松的访问权限会增加任何被攻陷账户的影响范围。

如果默认角色比组织要求更宽松，则可以创建自定义 **角色** ，仅授予每个团队所需的特定权限。 对于采用零信任安全模型的组织来说，这特别有价值。

请参阅“[确定企业所需的角色](/zh/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-roles-in-your-enterprise/identify-role-requirements)”。

#### 查看授权的应用程序

OAuth apps 和 GitHub Apps 安装在组织中，可以访问数据。 查看授权的应用程序列表，并删除不再需要或不再信任的任何应用程序。 过时的集成意味着通常被忽视的攻击面。

请参阅 [查看和修改已安装GitHub应用](/zh/apps/using-github-apps/reviewing-and-modifying-installed-github-apps) 和 [关于 OAuth 应用访问限制](/zh/enterprise-cloud@latest/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions)。

#### 使用 IP 允许列表限制网络访问

对于在 GitHub Enterprise Cloud 上的组织，如果您的组织在已知的网络范围内运行，请配置 IP 允许列表，以便只能从这些范围访问 GitHub 资源。 这增加了一层防御，防止从意外位置使用已泄露的凭据。

请参阅 [管理组织允许的 IP 地址](/zh/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization) 和 [使用 IP 允许列表限制企业网络的流入流量](/zh/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list)。

### 运行机密风险评估

针对组织的存储库运行免费的按需扫描，以便获得关于组织内当前被公开的机密总数的时间点视图。

请参阅“[为您的组织运行保密风险评估](/zh/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)
* [为安全事件做准备](/zh/code-security/tutorials/secure-your-organization/prepare-for-a-security-incident)

### 加强身份验证

弱身份验证或泄露身份验证是帐户接管的最常见原因之一。 要求在整个组织中进行强身份验证可显著降低此风险。

对于所有成员，都需要双重身份验证（2FA），这可确保仅泄露的密码不足以访问帐户。 在执行要求之前，请与组织通信，以便成员有时间设置 2FA。

GitHub Enterprise Cloud 上的组织可以强制实施单一登录 (SSO) 来进一步拓展，同时通过标识提供程序集中进行身份验证。

请参阅 [在你的组织中要求进行双因素身份验证](/zh/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization) 和 [关于使用 SAML 单一登录进行的身份和访问管理](/zh/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 的额外安全使用做法，请参阅 [安全使用指南](/zh/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)

### 使用安全概述监控您的安全态势

通过安全概述，你可以集中查看组织的和企业的安全环境。 使用它跟踪哪些存储库启用了安全功能，并识别具有开放警报的存储库，以便不会忽视新兴风险。

请参阅“[安全性概述](/zh/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 上使用安全活动。 请参阅“[创建和管理安全活动](/zh/enterprise-cloud@latest/code-security/how-tos/manage-security-alerts/remediate-alerts-at-scale/creating-managing-security-campaigns)”。

### 继续审核访问权限和许可

随着人员加入和离开组织，随着项目的发展，访问要求会发生变化。 安排定期评审：

* 组织成员身份和角色。
* 外部协作者访问权限。
* 存储库级权限和团队分配。
* 已授权的 OAuth 和 GitHub Apps.

这可确保访问与最低特权原则保持一致，即使组织发生更改也是如此。

### 保持依赖项更新

易受攻击的依赖项是攻击者的常见入口点。
Dependabot 可以自动打开拉取请求以更新具有已知漏洞的依赖项，但这些拉取请求仍需及时查看和合并。

建立分类和合并Dependabot 拉取请求的流程，以确保安全更新不会被延误。

请参阅 [Dependabot 自动分类规则](/zh/enterprise-cloud@latest/code-security/concepts/supply-chain-security/dependabot-auto-triage-rules) 和 [管理依赖项更新的所有拉取请求](/zh/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/manage-dependabot-prs)。

### 轮换密钥并强制设定过期时间

凭据存在的时间越长，公开或被盗的机会就越大。 在可能的情况下：

* 在personal access tokens上设置到期日期。
* 定期轮换机密。

有关管理令牌的信息，请参阅 [管理个人访问令牌](/zh/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) 和 [令牌过期和吊销](/zh/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation)。

## 后续步骤

* 即使实施强有力的预防控制，安全事件仍可能发生。 应提前设置几个关键工具和响应过程。 请参阅“[准备应对安全事件](/zh/code-security/tutorials/secure-your-organization/prepare-for-a-security-incident)”。