金融行业Git（GitLab）替代Subversion的安全技术问询

作为常年和Git、GitLab打交道的老开发，结合金融行业对版本控制系统的严格安全要求，针对你提到的两个核心问题，给你梳理下可行的防范和追溯方案：

问题1：防范/追溯冒充他人提交的操作 #

防范措施 #

• GitLab端强制身份验证绑定
  • 开启GPG签名提交要求：在GitLab项目的「Repository」→「Push rules」中，勾选「Require signed commits」，同时要求所有开发人员将个人GPG密钥绑定到自己的GitLab账号。这样即便本地修改了git config user.name和user.email，提交必须带有合法的GPG签名才能被服务器接受，而签名是和用户账号唯一绑定的，无法冒充。
  • 绑定唯一SSH密钥：每个GitLab账号仅允许绑定个人专属的SSH密钥，推送代码时GitLab会验证密钥所属用户。本地修改的user信息只是提交元数据的显示项，实际推送身份由SSH密钥对应的账号决定，从根源上阻止冒充。
  • 统一LDAP身份认证：将GitLab接入公司内部LDAP系统，用户必须使用公司统一账号登录操作，所有推送、提交的身份都会和LDAP账号绑定，避免私自创建账号或冒充。

追溯方法 #

• 查看GitLab审计日志：GitLab会完整记录所有推送操作的真实用户身份（基于SSH密钥或LDAP登录信息），无论提交元数据里的user信息被改成什么，你都可以在项目的「Settings」→「Audit Log」或管理员后台的审计日志中，查到谁在什么时间推送了哪些提交。
• 验证提交的GPG签名：使用命令git log --show-signature查看提交的签名信息，通过验证签名对应的GPG密钥归属，就能确定提交的真实操作者，哪怕user.name被改成前同事的名字也没用。
• 核对SSH推送记录：GitLab服务器会记录每个推送请求的SSH密钥指纹，通过指纹匹配到对应的用户账号，这也是追溯真实推送者的可靠依据。

问题2：防范/追溯篡改提交日期的操作 #

防范措施 #

• GitLab分支保护与推送规则
  • 启用分支保护：对核心分支（如main/master）设置仅允许通过合并请求（MR）提交，禁止直接推送。这样篡改提交日期需要重写历史，而重写后的提交在MR中会被清晰识别，审核环节就能发现异常。
  • 禁止非线性历史推送：在Push rules中勾选「Prevent pushing commits with non-linear history」，阻止用户推送重写历史后的提交（篡改日期通常需要git rebase或git commit --amend，这些操作会产生非线性历史）。
• 服务器端Git Hook验证：编写pre-receive钩子脚本，在代码推送到服务器前验证提交的author date和committer date是否在合理范围内（比如不能早于项目创建日期，不能晚于服务器当前时间）。示例脚本片段：

  # 获取当前服务器时间（Unix时间戳）
  CURRENT_TIMESTAMP=$(date +%s)
  # 遍历待推送的提交
  while read oldrev newrev refname; do
    # 获取提交的author date时间戳
    AUTHOR_TIMESTAMP=$(git show -s --format=%at $newrev)
    # 检查日期是否合理
    if [ $AUTHOR_TIMESTAMP -gt $CURRENT_TIMESTAMP ]; then
      echo "Error: Author date is in the future!"
      exit 1
    fi
  done
  

追溯方法 #

• 对比提交哈希值：Git的提交哈希是基于提交内容（包括日期）计算的，篡改日期会导致提交哈希完全改变。对比本地仓库与服务器仓库的提交哈希，或者和备份仓库的哈希对比，就能发现被篡改的提交。
• 查看GitLab的推送时间记录：即便提交的author date被篡改，GitLab会记录该提交被推送到服务器的真实时间，这个时间存储在GitLab的事件日志中，无法被用户篡改，可作为追溯的依据。
• 检查提交历史变更：使用git reflog查看本地仓库的操作历史（如果是本地篡改），或者在GitLab中查看分支的推送历史，能找到提交被修改的痕迹。

内容的提问来源于stack exchange，提问作者Adam Engler