Git 安全实践：签名提交、权限控制与敏感信息防护

在当今的软件开发流程中，Git 早已成为版本控制的事实标准。然而，许多团队在享受 Git 带来的高效协作时，往往忽视了其安全层面的配置。一次意外的密钥泄露、一个未签名的恶意提交，都可能让整个项目陷入危机。本文将从签名提交、权限控制与敏感信息防护三个维度，梳理 Git 安全实践中真正落地有效的方法。

一、签名提交：让每一次提交都可追溯

Git 本身并不验证提交者的身份，默认情况下，任何人都可以设置 user.name 和 user.email 来伪装成他人提交代码。签名提交通过密码学手段解决了这一问题。

1. GPG 签名

GPG（GNU Privacy Guard）是最传统的签名方式。配置步骤如下：

# 生成 GPG 密钥对
gpg --full-generate-key

# 查看密钥 ID
gpg --list-secret-keys --keyid-format=long

# 告诉 Git 使用该密钥
git config --global user.signingkey <KEY_ID>

# 对所有提交自动签名
git config --global commit.gpgsign true

配置完成后，每次 git commit 都会附加签名。使用 git log --show-signature 可以验证提交是否有效。

2. SSH 签名（推荐）

从 Git 2.34 开始，Git 支持使用 SSH 密钥进行签名，这比 GPG 更简单，因为大多数开发者已经配置了 SSH 密钥用于推送代码。

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

在 GitHub、GitLab 等平台上，可以将 SSH 密钥同时添加为签名密钥，平台会自动显示“Verified”徽章。

3. 团队落地建议

• 在 CI 流水线中加入签名验证步骤，拒绝未签名的提交合并到主分支。
• 使用 git verify-commit 或 git log --show-signature 定期审计历史提交。
• 对于开源项目，可以在 CONTRIBUTING.md 中明确要求签名提交。

二、权限控制：最小权限原则的落地

Git 仓库的权限控制分为两个层面：托管平台层面和 Git 服务端层面。

1. 托管平台的分支保护

以 GitHub 为例，分支保护规则（Branch Protection Rules）是权限控制的核心：

• Require pull request reviews：强制代码审查，避免直接推送。
• Require status checks：合并前必须通过 CI 测试。
• Require signed commits：只接受签名提交。
• Restrict who can push：限制直接推送权限，即使是管理员也应遵循。
• Require linear history：禁止合并提交，保持历史清晰可审计。

GitLab 对应的是“Protected Branches”和“Merge Request Approvals”，逻辑类似。

2. 自建 Git 服务的权限模型

如果使用自建的 GitLab、Gitea 或 Gitolite，需要关注：

• 角色划分：Guest、Reporter、Developer、Maintainer、Owner 五级权限应严格对应实际职责。例如，只有 Maintainer 才能合并到受保护分支。
• SSH 密钥管理：定期轮换密钥，离职员工立即移除。
• 审计日志：开启 Git 操作日志，记录谁在何时推送了什么。

3. 避免“超级权限”滥用

许多团队的问题在于：所有开发者都有主分支的推送权限。一旦账号被盗，攻击者可以直接注入恶意代码。建议：

• 主分支只允许通过 Merge Request 合并。
• 管理员账号启用双因素认证（2FA）。
• 使用部署密钥（Deploy Key）时，限制为只读或只写单一仓库。

三、敏感信息防护：从预防到补救

敏感信息泄露是 Git 安全中最常见也最致命的问题。一个不小心提交的 .env 文件，可能包含数据库密码、API 密钥、云服务凭证。

1. 预防：提交前拦截

使用 .gitignore 是最基础的一步，但远远不够，因为开发者可能强制添加（git add -f）。

推荐工具：pre-commit 钩子

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Gitleaks 会在每次提交前扫描暂存区，发现疑似密钥立即阻止提交。

其他工具：

• TruffleHog：扫描历史提交中的高熵字符串。
• git-secrets：AWS 官方出品，可自定义正则规则。

2. 检测：定期扫描

即使有预防措施，也应定期扫描整个仓库历史：

# 使用 gitleaks 扫描全历史
gitleaks detect --source . --verbose

# 使用 trufflehog 扫描
trufflehog git file://. --only-verified

将扫描集成到 CI 中，每次推送都自动运行。

3. 补救：泄露后的应急处理

一旦敏感信息已经提交，仅仅删除文件并提交是不够的，因为历史记录中仍然存在。必须：

1. 立即轮换密钥：这是第一优先级，无论历史是否清理。
2. 重写历史：使用 git filter-repo 或 BFG Repo-Cleaner 彻底移除敏感文件。

# 使用 git filter-repo 移除文件
git filter-repo --path config/secrets.yml --invert-paths

# 强制推送（需通知所有协作者）
git push --force --all

3. 通知团队：所有协作者必须重新克隆仓库，否则旧历史会再次被推回。
4. 平台清理：GitHub 等平台会缓存旧提交，需联系支持清理。

4. 替代方案：使用环境变量与密钥管理

• 本地开发使用 .env 文件，并确保在 .gitignore 中。
• 生产环境使用 Vault、AWS Secrets Manager 等工具。
• CI/CD 中使用平台提供的加密变量功能。

总结

Git 安全不是一次性配置，而是持续的习惯。签名提交确保代码来源可信，权限控制限制攻击面，敏感信息防护则避免“一失足成千古恨”。建议团队从今天开始：

1. 强制签名提交并启用分支保护。
2. 在 pre-commit 和 CI 中集成密钥扫描。
3. 定期审计权限与历史记录。

安全无小事，每一次 git push 都值得被认真对待。

未经允许不得转载：任鹏个人博客 » Git 安全实践：签名提交、权限控制与敏感信息防护