新业务上线前，必须先做基线检查，通过系统安全配置加固来消除已知风险，确保系统在安全基线之上运行，这是上线前最关键的步骤。 很多团队在上线前都会做功能测试、性能压测，却很少把系统安全配置当作必检项，结果业务跑起来了，但系统可能因为一个默认端口或者弱口令，成为攻击者的突破口，基线检查就是给系统做一次彻底的“体检”，把不该开的端口关掉，把弱密码改掉，把不必要的权限收走,让系统在安全的状态下上线。
新业务上线前安全基线检查怎么做？
基线检查的起点：梳理资产与配置
在进行基线检查之前，首先要明确检查范围，新业务涉及哪些服务器、网络设备、中间件、数据库？这些组件当前的配置状态是什么？建议先做资产盘点，列出所有涉及的系统组件，并获取其当前配置，对照行业公认的安全基线标准，比如CIS（Center for Internet Security）基准，或者我国等级保护的要求，来确定哪些配置需要调整，只有知道家底，才能有的放矢，资产梳理阶段，最好使用配置管理数据库（CMDB）来记录,确保每个组件都有责任人。
执行基线检查的常用工具和命令
对于Linux系统，可以使用lynis进行安全审计，这个工具能自动检查系统配置并给出建议，运行命令lynis audit system即可，也可以使用openscap，它支持CIS和NIST标准，可以生成合规报告，命令如oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 --results results.xml，手动检查也很重要，比如用cat /etc/passwd查看用户列表，netstat -an查看开放端口，systemctl list-units查看运行服务，对于Windows，可以使用微软的安全基线分析器或组策略分析工具，在云环境，很多云平台提供内置的基线检查服务，比如AWS的Inspector或简米云的安全中心，可以一键扫描不合规项,这些工具都能快速发现配置问题。
云主机安全基线检查步骤
如果新业务部署在云主机上，基线检查需要关注云特定配置，首先检查安全组规则，确保只开放必要的端口，比如80、443，避免暴露22、3306等管理端口，检查IAM（身份和访问管理）权限，确保没有过度授权，使用最小权限原则，开启云日志和监控，确保安全事件可追溯,具体步骤：
- 登录云控制台,进入安全组管理。
- 审查每一条规则,关闭不必要端口。
- 检查密钥对，使用新的密钥对,不要共用默认密钥。
- 启用云平台的安全基线检查功能,自动扫描并修复。
- 开启操作审计日志。
这些步骤能有效降低云上风险，行业共识认为，云上安全事件大多源于配置错误，对于容器化部署，还需要检查镜像安全配置，如容器运行时只读根文件系统、限制内核能力等。
修复与验证：让系统达标
检查出不合规项后，需要逐个修复，修改弱密码、关闭不需要的服务、更新系统补丁、调整文件权限，修复后，要重新运行检查，确保每项都达标，可以使用自动化工具进行持续验证，避免配置漂移，将基线检查集成到CI/CD流水线中，使用Jenkins或GitLab Runner，在每次部署前自动执行基线检查脚本，如果发现不合规则中断部署，这样，从源头保证系统状态，建议使用配置管理工具如Ansible、SaltStack，将基线配置编写为Playbook,自动修复常见问题。
系统基线检查工具怎么选？
开源工具 vs 商业工具
选择基线检查工具时，需要权衡成本、功能、易用性，开源工具如OpenSCAP、Lynis、Docker-bench-security，适合预算有限、技术团队较强的企业，它们功能强大，但需要手动配置和解读报告，商业工具如Tenable、Qualys、McAfee Secure，提供更全面的基线库、自动修复和报告功能，适合大型企业或需要合规监管的场景，业内专家指出，选择工具时首要考虑是否支持目标平台和基线标准，比如是否支持CIS基准和等保要求，还需要考虑团队的技术能力，如果团队对Linux命令行不熟悉,商业工具更友好。
工具选型考虑因素
- 平台覆盖：支持Linux、Windows、容器、云平台等。
- 基线标准：是否内置CIS、NIST、等保等标准。
- 自定义能力：能否添加自定义检查项。
- 集成与自动化：是否支持API、CI/CD集成。
- 报告与合规：能否生成合规报告,方便审计。
下表对比了常用工具的特点：
| 工具 | 类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| OpenSCAP | 开源 | Linux/Windows | 支持CIS/NIST，免费 | 配置复杂 |
| Lynis | 开源 | Linux/Unix | 易用，命令式 | 覆盖面有限 |
| Docker-bench-security | 开源 | 容器 | 专注Docker | 适用范围窄 |
| Tenable Nessus | 商业 | 全平台 | 全面，自动修复 | 费用高 |
| Qualys | 商业 | 云/本地 | SaaS模式，易于管理 | 订阅成本 |
工具评估的常见问题
在评估工具时，常问自己：这个工具能否覆盖我们所有平台的基线检查？它是否支持我们需要的标准？报告能否被审计部门接受？如果团队已经使用某监控平台，可以考虑集成方案，云原生环境越来越多，工具是否支持Kubernetes节点和容器的基线检查也很关键，多数情况下，先试用开源工具,再决定是否升级到商业版。
新业务上线安全配置清单包含哪些内容？
操作系统层面配置
- 禁用root直接远程登录，使用sudo提权,避免暴力破解。
- 配置SSH密钥认证，禁止密码登录,降低弱口令风险。
- 限制用户权限，删除默认测试账户,避免被利用。
- 开启系统日志审计，如rsyslog和auditd,方便事后追溯。
- 更新系统补丁，启用自动安全更新,及时修复漏洞。
网络设备与服务配置
- 关闭不必要网络端口，如Telnet、FTP、SMTP等,减少攻击面。
- 配置防火墙策略，仅允许必要流量，如只开放80、443。
- 限制ICMP响应，防止ping攻击,启动iptables规则。
- 启用网络分段，隔离不同业务区域,比如数据库单独子网。
应用与中间件安全配置
- 数据库连接采用加密，如MySQL使用SSL,防止中间人攻击。
- 修改中间件默认密码，如Tomcat、Nginx管理后台,避免默认口令。
- 应用部署使用非root用户，限制文件权限,防止越权。
- 启用应用日志，记录访问和错误,便于排查异常。
- 配置Web安全头，如内容安全策略（CSP）、X-Frame-Options,抵御XSS和点击劫持。
基线检查与渗透测试有何不同？
目的不同
基线检查属于合规性检查，目标是确保系统配置符合安全标准，避免常见安全隐患，渗透测试则是模拟攻击，主动发现系统漏洞，验证安全防御能力，基线检查更像是“体检”，检查是否健康；渗透测试像是“压力测试”，看能否扛住攻击，两者关注点不同,但同样重要。
执行频率不同
基线检查应该持续进行，作为日常运维的一部分，尤其是新业务上线、配置变更后，渗透测试建议定期进行，比如半年或一年一次，或者在重大版本更新后，两者结合，能够全面保障系统安全，在DevOps流程中，基线检查可以集成到CI/CD,而渗透测试通常在阶段性进行。
相互补充
基线检查是渗透测试的基础，如果基线检查没做好，渗透测试会发现大量低级问题，比如弱口令、开放端口，浪费测试资源，渗透测试则能发现基线检查无法覆盖的逻辑漏洞和业务风险，普遍认为，两者应并行推进，基线检查在前，渗透测试在后，形成完整的安全体系，某次渗透测试中，如果基线检查已经完成，测试人员可以更专注于应用层漏洞,效率更高。
新业务上线前做好基线检查，把系统调成安全状态，是保障业务平稳运行的基础，无论新业务是部署在物理机、虚拟机还是容器，安全基线都是第一道防线，只有持续关注基线,才能让系统始终处于安全可控的范围内。
新业务上线前安全基线检查常见问题
Q1: 新业务上线前安全基线检查需要多长时间？
时间取决于系统规模和复杂度，对于一台标准Linux服务器，使用自动化工具如Lynis，检查只需几分钟，如果涉及多台服务器和复杂中间件，可能需要数小时，修复时间取决于不合规项数量，大部分问题可以在半小时内解决，比如修改密码、关闭端口，对于大型项目，建议提前规划好时间,在测试环境进行预检查。
Q2: 基线检查应该由谁来做？
通常由运维或安全团队负责执行，但开发团队需要参与配置修复，因为很多配置是在部署时设置的，建议建立跨团队协作流程，上线前由安全团队评审基线检查报告，确保所有问题已修复，在DevOps团队中，可以将基线检查自动化，由开发人员自行触发,但安全团队仍需审核结果。
Q3: 基线检查只做一次够吗？
不够，系统运行过程中，配置可能因为维护、更新而发生变化，导致漂移，因此需要持续监控，定期执行基线检查，或将其集成到CI/CD流水线中，每次部署自动检查，只有持续维护，才能确保系统始终处于安全状态，业务环境变化时，比如增加新模块,也需要重新检查。