Git管理关键配置文件是最轻量可靠的服务器安全配置版本控制方式，需聚焦SSH、防火墙、SELinux/AppArmor、Web服务、PHP/数据库及用户权限等核心文本配置，通过符号链接统一纳管并强制执行提交、注释、审核流程，辅以自动快照和敏感信息隔离。
直接用 Git 管理关键配置文件，是目前最轻量、最可靠、也最被广泛验证的服务器安全配置版本控制方式。它不依赖复杂平台，不增加运行时负担，却能把“谁改了什么、何时改的、为什么改”全部留痕，出问题还能秒级回滚。
明确要纳入版本控制的核心配置文件
不是所有文件都值得跟踪，重点抓真正影响安全策略和系统行为的文本配置。常见且关键的包括：
- SSH 配置：/etc/ssh/sshd_config（禁用密码登录、限制用户、修改端口等）
- 防火墙规则：/etc/iptables/rules.v4（或 firewalld 的 /etc/firewalld/zones/*.xml）
- SELinux 或 AppArmor 策略：/etc/selinux/config、自定义 .te 模块、/etc/apparmor.d/ 下的策略文件
- 服务主配置：Nginx 的 /etc/nginx/nginx.conf 及 sites-enabled/；Apache 的 /etc/apache2/apache2.conf；FrankenPHP 的 /etc/frankenphp/Caddyfile
- PHP/数据库安全参数：/etc/php/*/apache2/php.ini 中的 disable_functions、expose_php、open_basedir；MySQL 的 /etc/mysql/my.cnf 中的 skip-networking、require_secure_transport
- 用户与权限相关文件：/etc/sudoers（用 visudo 编辑后可存为副本）、/etc/passwd（只读参考，不建议直接提交）、/etc/group
用符号链接 + Git 仓库统一管理路径
避免把整个 /etc 目录塞进 Git（冗余多、权限杂、易误操作）。推荐做法是创建一个专用目录（如 /opt/config-repo），把上述文件以符号链接方式接入：
- 在 /opt/config-repo 下建立对应子目录结构（如 ssh/、firewall/、nginx/）
- 把原始配置文件复制一份到该目录下（如 cp /etc/ssh/sshd_config /opt/config-repo/ssh/）
- 删除原路径文件，用 ln -s 指向新位置（如 ln -sf /opt/config-repo/ssh/sshd_config /etc/ssh/sshd_config）
- 进入 /opt/config-repo 初始化 Git：git init && git add . && git commit -m "initial security config"
这样既保持系统正常加载配置，又让所有变更集中在单一仓库，权限清晰、备份方便、协作无冲突。
强制执行变更流程，让版本控制真正生效
工具只是基础，流程才能防住人为疏漏。建议落地三条硬规则：
- 所有修改必须通过 Git 提交：禁止直接编辑原始文件。运维人员需先 cd /opt/config-repo，改完对应文件后 git add && git commit -m “关闭SSH密码登录，启用ED25519密钥认证”
- 每次提交必须写明安全意图：备注不是“更新配置”，而是“修复CVE-2026-XXXX：限制PHP upload_max_filesize为8M，防止大文件上传DoS”
- 生产环境变更需经审核合并：用 Git 分支（如 main 为生产稳定版，dev 为测试分支），重大调整走 Pull Request 流程，至少一人 review 后再 merge，避免单点失误
配套做两件事，让版本控制更牢靠
光有 Git 还不够，加两个小动作，大幅提升健壮性：
- 定时自动提交快照：用 cron 每天凌晨执行一次 git commit -am "daily auto-snapshot"（配合 --allow-empty 避免失败），确保即使人工遗漏，也有底线记录
-
敏感信息绝不进仓库：数据库密码、API密钥、JWT密钥等，一律从配置中剥离，改用环境变量或 Vault 类工具注入。Git 里只留占位符（如 MYSQL_PASS = “
”），并在 .gitignore 中明确排除 *.secret、.env.local 等文件
