# 构建可复用的Ansible安全加固流水线：Linux、SSH、Nginx与MySQL多层防御体系 > 基于dev-sec hardening collection，设计可复用的Ansible Playbook模块，实现Linux系统、SSH服务、Nginx配置和MySQL数据库的自动化安全加固与合规检查流水线。 ## 元数据 - 路径: /posts/2026/01/13/ansible-hardening-pipeline-linux-ssh-nginx-mysql/ - 发布时间: 2026-01-13T06:32:11+08:00 - 分类: [security-automation](/categories/security-automation/) - 站点: https://blog.hotdry.top ## 正文 在基础设施即代码（IaC）时代，安全加固不再是手动配置的繁琐任务，而是需要可重复、可验证、可审计的自动化过程。Ansible作为广泛使用的配置管理工具，其安全自动化能力直接关系到整个基础设施的安全态势。正如Spacelift在2025年的分析中指出的："Ansible often holds the keys to your entire infrastructure"，一个小的配置失误可能通过自动化放大到数百甚至数千台服务器。 本文将基于dev-sec hardening collection（GitHub 4.8k stars），深入探讨如何构建一个可复用的Ansible安全加固流水线，覆盖Linux操作系统、SSH服务、Nginx配置和MySQL数据库四个关键层面，实现从基础系统到应用服务的全方位防御。 ## 1. dev-sec hardening collection：经过实战检验的安全基线 dev-sec hardening collection是一个经过实战检验的Ansible集合，提供了符合DevSec Inspec基线标准的安全加固方案。该集合支持广泛的Linux发行版，包括： - **主流企业发行版**：CentOS Stream 9、AlmaLinux 8/9/10、Rocky Linux 8/9/10 - **社区发行版**：Debian 11/12/13、Ubuntu 20.04/22.04/24.04 - **其他平台**：Amazon Linux、Arch Linux、Fedora 39/40、Suse Tumbleweed（部分支持） 对于数据库和Web服务器，支持MySQL >= 5.7.31、>= 8.0.3，MariaDB >= 5.5.65、>= 10.1.45、>= 10.3.17，以及Nginx 1.0.16或更高版本。 ### 1.1 核心架构与角色设计 该集合包含四个核心角色，每个角色都针对特定层面的安全加固： **os_hardening**：操作系统级加固 - 内核参数调优（sysctl配置） - 文件系统权限与挂载选项 - 用户认证与PAM配置 - 审计与日志配置 - 网络栈安全加固 **ssh_hardening**：SSH服务加固 - 加密算法配置（禁用弱算法） - 认证机制控制（禁用密码认证） - 访问控制列表（AllowUsers/DenyUsers） - 网络转发限制 - 会话超时配置 **nginx_hardening**：Nginx配置加固 - HTTP头安全配置 - SSL/TLS最佳实践 - 请求限制与速率控制 - 目录遍历防护 - 信息泄露防护 **mysql_hardening**：MySQL数据库加固 - 默认账户安全 - 密码策略强化 - 网络访问控制 - 审计日志配置 - 安全插件启用 ## 2. 可复用的Playbook模块设计模式 ### 2.1 模块化角色调用模式 为了实现可复用性，我们采用模块化的Playbook设计。以下是一个基础的主Playbook结构： ```yaml # site.yml - 主加固流水线 - name: 执行全方位安全加固 hosts: all become: yes vars: # 可配置的安全参数 security_level: "high" compliance_standard: "cis" pre_tasks: - name: 验证系统兼容性 ansible.builtin.assert: that: - ansible_distribution in supported_distributions - ansible_distribution_major_version | int >= min_version[ansible_distribution] roles: - role: devsec.hardening.os_hardening vars: os_hardening_auditd: true os_hardening_sysctl_enable: true os_hardening_pam_enable: true - role: devsec.hardening.ssh_hardening vars: ssh_hardening_allow_tcp_forwarding: false ssh_hardening_permit_root_login: "no" ssh_hardening_password_authentication: false - role: devsec.hardening.nginx_hardening when: "'nginx' in group_names" vars: nginx_hardening_ssl_protocols: "TLSv1.2 TLSv1.3" nginx_hardening_hsts_max_age: 31536000 - role: devsec.hardening.mysql_hardening when: "'mysql' in group_names" vars: mysql_hardening_remove_anonymous_users: true mysql_hardening_remove_test_database: true post_tasks: - name: 执行合规性检查 ansible.builtin.include_role: name: compliance_checker ``` ### 2.2 环境特定的变量分层 为了适应不同环境（开发、测试、生产），我们采用变量分层策略： ```yaml # group_vars/production/security.yml security_level: "high" audit_enabled: true backup_before_changes: true # group_vars/development/security.yml security_level: "medium" audit_enabled: false backup_before_changes: false # host_vars/db-server/security.yml mysql_hardening_max_connections: 500 mysql_hardening_slow_query_log: true ``` ### 2.3 条件执行与回滚机制 安全加固可能影响服务可用性，因此需要完善的回滚机制： ```yaml - name: 创建配置备份 ansible.builtin.copy: src: "{{ item.src }}" dest: "/backup/security/{{ inventory_hostname }}/{{ ansible_date_time.date }}/" remote_src: true loop: - { src: "/etc/ssh/sshd_config" } - { src: "/etc/nginx/nginx.conf" } - { src: "/etc/my.cnf" } register: backup_result changed_when: false - name: 执行安全加固 block: - include_role: name: devsec.hardening.os_hardening - include_role: name: devsec.hardening.ssh_hardening rescue: - name: 回滚到备份配置 ansible.builtin.copy: src: "/backup/security/{{ inventory_hostname }}/{{ ansible_date_time.date }}/{{ item }}" dest: "/etc/{{ item | dirname }}" remote_src: true loop: - "ssh/sshd_config" - "nginx/nginx.conf" - "my.cnf" - name: 重启受影响的服务 ansible.builtin.service: name: "{{ item }}" state: restarted loop: - sshd - nginx - mysqld always: - name: 记录加固操作 ansible.builtin.lineinfile: path: "/var/log/security/hardening.log" line: "{{ ansible_date_time.iso8601 }} - {{ inventory_hostname }} - 加固{{ '成功' if not backup_result.failed else '失败回滚' }}" ``` ## 3. 合规检查流水线设计 ### 3.1 自动化合规验证 dev-sec hardening collection与Inspec基线标准兼容，我们可以构建自动化的合规检查流水线： ```yaml # compliance_pipeline.yml - name: 安全基线合规检查 hosts: all tasks: - name: 安装Inspec ansible.builtin.package: name: inspec state: present - name: 下载DevSec基线配置文件 ansible.builtin.get_url: url: "https://github.com/dev-sec/{{ item }}-baseline/archive/master.tar.gz" dest: "/tmp/{{ item }}-baseline.tar.gz" loop: - linux - ssh - nginx - mysql - name: 执行合规检查 ansible.builtin.shell: | inspec exec /tmp/{{ item }}-baseline.tar.gz \ --reporter json:/tmp/{{ item }}-compliance-{{ inventory_hostname }}.json \ --reporter cli loop: - linux - ssh - nginx - mysql register: compliance_results - name: 聚合合规报告 ansible.builtin.template: src: compliance_report.j2 dest: "/var/www/html/compliance/{{ inventory_hostname }}-{{ ansible_date_time.date }}.html" - name: 发送合规警报 ansible.builtin.mail: to: "security-team@example.com" subject: "合规检查结果 - {{ inventory_hostname }}" body: "{{ compliance_results.results | to_nice_json }}" when: compliance_results.failed ``` ### 3.2 持续监控与告警 安全加固不是一次性任务，需要持续监控： ```yaml # monitoring_config.yml - name: 配置安全监控 hosts: all tasks: - name: 配置auditd规则 ansible.builtin.template: src: audit_rules.j2 dest: /etc/audit/rules.d/security-hardening.rules - name: 配置日志聚合 ansible.builtin.lineinfile: path: /etc/rsyslog.conf line: "*.* @log-aggregator.example.com:514" - name: 配置Prometheus exporter ansible.builtin.copy: src: node_exporter.service dest: /etc/systemd/system/ - name: 配置安全指标 ansible.builtin.template: src: security_metrics.j2 dest: /etc/prometheus/node_exporter/security_metrics.prom ``` ## 4. 关键安全参数与最佳实践 ### 4.1 SSH服务关键参数 ```yaml ssh_hardening_ciphers: - "chacha20-poly1305@openssh.com" - "aes256-gcm@openssh.com" - "aes128-gcm@openssh.com" - "aes256-ctr" - "aes192-ctr" - "aes128-ctr" ssh_hardening_macs: - "hmac-sha2-512-etm@openssh.com" - "hmac-sha2-256-etm@openssh.com" - "umac-128-etm@openssh.com" ssh_hardening_kex_algorithms: - "curve25519-sha256" - "curve25519-sha256@libssh.org" - "ecdh-sha2-nistp521" - "ecdh-sha2-nistp384" - "ecdh-sha2-nistp256" ``` ### 4.2 Nginx安全头配置 ```yaml nginx_hardening_headers: X-Frame-Options: "SAMEORIGIN" X-Content-Type-Options: "nosniff" X-XSS-Protection: "1; mode=block" Referrer-Policy: "strict-origin-when-cross-origin" Content-Security-Policy: "default-src 'self'" nginx_hardening_ssl_config: ssl_protocols: "TLSv1.2 TLSv1.3" ssl_ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256" ssl_prefer_server_ciphers: "on" ssl_session_cache: "shared:SSL:10m" ssl_session_timeout: "10m" ``` ### 4.3 MySQL安全配置 ```yaml mysql_hardening_config: validate_password.policy: "MEDIUM" validate_password.length: "12" validate_password.mixed_case_count: "1" validate_password.number_count: "1" validate_password.special_char_count: "1" max_connect_errors: "100" skip_name_resolve: "ON" local_infile: "OFF" log_error: "/var/log/mysql/error.log" slow_query_log: "ON" slow_query_log_file: "/var/log/mysql/slow.log" long_query_time: "2" ``` ## 5. 实施策略与风险控制 ### 5.1 分阶段实施策略 1. **评估阶段**（1-2周） - 资产发现与分类 - 当前安全基线评估 - 影响分析 2. **试点阶段**（2-4周） - 选择非关键系统进行试点 - 监控性能与稳定性影响 - 调整配置参数 3. **推广阶段**（4-8周） - 按业务重要性分批实施 - 建立回滚机制 - 培训运维团队 4. **运维阶段**（持续） - 定期合规检查 - 配置变更管理 - 安全事件响应 ### 5.2 风险缓解措施 1. **配置漂移防护** - 使用Git进行配置版本控制 - 定期执行配置一致性检查 - 实施变更审批流程 2. **服务中断预防** - 在维护窗口执行加固 - 实施蓝绿部署策略 - 建立快速回滚机制 3. **性能影响监控** - 基线性能指标收集 - 实时性能监控 - 性能回归测试 ## 6. 自动化流水线集成 ### 6.1 CI/CD流水线集成 将安全加固集成到CI/CD流水线中，实现安全左移： ```yaml # .gitlab-ci.yml 示例 stages: - test - security-scan - deploy - post-deploy-hardening security-hardening: stage: post-deploy-hardening script: - ansible-playbook -i production site.yml --tags security only: - production when: manual allow_failure: false ``` ### 6.2 基础设施即代码集成 在Terraform或CloudFormation中集成安全加固： ```hcl # Terraform配置示例 resource "null_resource" "security_hardening" { triggers = { instance_id = aws_instance.web.id } provisioner "local-exec" { command = <