Ansible实现等保安全合规基线,运维尽力了!

需求

《结合等级保护了解服务器合规基线配置》一文从普法的角度给逐级介绍了等级保护级别、安全通用要求、安全计算环境。由于我们基础设施都在安全计算环境中,因此需要我们关注的安全控制点为:

身份鉴别

访问控制

安全审计

入侵防范

恶意代码防范

可信验证

数据完整性

数据保密性

数据备份与恢复

剩余信息保护

既然安全控制点已经找到,那么我们就可以根据其进一步的要求由点及面来详细展开了。

解决方案

对于安全合规基线,我们肯定希望能够对所有纳管的服务器进行批量更新,最好还可以根据最新的标准不断进行持续优化更新。因此我们使用Ansible Playbook进行统一管理,一方面安全合规基线配置是系统标准初始化的一部分,另一方面其也可以对基线进行单独的执行。

我们利用ansible playbook的tag功能以及gather_facts获取操作系统版本,下面是我们全部操作系统初始化的task:

vim /ansible/ansible-playbook/roles/os_init/task/main.yml

– include: hostname.yml  

我们完整的合规基线由基础安全基线和其他不同组件的配置组成:

 

– include: profile.yml  

注意:为兼容Centos6和Centos7,我们在playbook中需要开启gather_facts获取操作系统版本,以便区分不同的配置操作。

 

对不同需求的合规配置,我们只需执行以下操作:

 

具体实现

 

等保三级的合规基线要求非常严格,对于生产环境我们无法保证完全按其要求实施,因此本次Ansible具体实现我们是做了一定程度妥协的。如有需要,可以按此配置自行添加。

 

1.身份鉴别

 

「1.应对登录的用户进行身份标识和鉴别,身份标识具有唯一性,应实现身份鉴别信息防窃取和防重用。静态口令应在8位以上,由字母、数字、符号等混合组成并每半年更换口令,不允许新设定的口令与前次旧口令相同。应用系统用户口令应在满足口令复杂度要求的基础上定期更换。」

 

我们针对此项标准具体限制如下:

 

 

 

密码过期时间(90天过期、长度最小8位、禁止使用重复密码)

 

 

密码最小长度8位,复杂度包含大小写字母、数字、特殊字符,适配Centos6、Centos7

 

 

密码登录尝试3次

 

 

禁止旧密码

 

 

vim safe.yml

「2.应具有登录失败处理功能,应配置并启用结束会话、限制登录间隔、限制非法登录次数和当登录连接超时自动退出等相关措施。」

 

我们针对此项标准具体限制如下:

 

 

 

防暴力破解

 

 

登录失败锁定(3次输入错误,锁定60秒)

 

 

终端1800秒结束会话

 

 

ssh每次登录时间不大于一分钟

 

 

ssh身份验证尝试次数不大于4次

 

 

vim safe.yml

「3.应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别,且其中一种鉴别技术至少应使用密码技术来实现」。

 

对于服务器的远程登录,我们可以通过开源堡垒机或采购企业级堡垒机,堡垒机一般都支持密码、密钥、口令等多种认证方式,因此在此我们就不做进一步介绍了。

 

2.访问控制

 

 

 

应对登录的用户分配账户和权限。

 

 

应重命名或删除默认账户,修改默认账户或预设账户的默认口令。

 

 

应用系统应对首次登录的用户提示修改默认账户或预设账户的默认口令。

 

 

应及时删除或停用多余的、过期的账户,避免共享账户的存在。

 

 

应授予管理用户所需的最小权限,实现管理用户的权限分离。

 

 

应严格限制默认账户或预设账户的权限,如默认账户和预设账户的权限应为空权限或某单一功能专用权限等。

 

 

应由授权主体配置访问控制策略,访问控制策略规定主体对客体的访问规则。

 

 

访问控制的粒度应达到主体为用户级或进程级,客体为文件、数据库表级。

 

 

应对重要主体和客体设置安全标记,并控制主体对有安全标记信息资源的访问。

 

 

访问控制涉及的账号分配、权限隔离等要求,基本上都和管理标准、制度有关,我们无法在自动化配置层面做太多的工作。

 

3.安全审计

 

 

 

应启用安全审计功能,审计覆盖到每个用户,对重要的用户行为和重要安全事件进行审计。

 

 

审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息。

 

 

应对审计记录进行保护,定期备份,避免受到未预期的删除、修改或覆盖等,审计记录保存时间应不少于6个月。

 

 

应对审计进程进行保护,防止未经授权的中断。

 

 

对于从互联网客户端登录的应用系统,应在用户登录时提供用户上一次非常用设备成功登录的日期、时间、方法、位置等信息。

 

 

审计记录产生时的时间应由系统范围内唯一确定的时钟产生,以确保审计分析的一致性与正确性。

 

 

我们针对此项标准具体限制如下:

 

 

 

收集修改系统强制访问控制的事件

 

 

收集系统网络环境修改事件

 

 

user/group 修改信息事件被收集

 

 

收集用户删除文件事件

 

 

收集内核模块的加载和卸载

 

 

收集登陆登出事件

 

 

收集会话启动事件

 

 

保收集了成功的文件系统挂载

 

 

收集系统管理员操作(sudolog)

 

 

收集系统管理范围内的更改

 

 

收集任意访问控制权限修改事件

 

 

收集修改日期和时间信息的事件

 

 

vim audit.yml

– name: modify auditd.conf

  replace:

    path: /etc/audit/auditd.conf

    regexp: ‘max_log_file_action = ROTATE’

    replace: ‘max_log_file_action = keep_logs’

  notify: restart auditd

  tags: audit 

– name: add audit.rules

  lineinfile: 

    path: /etc/audit/rules.d/audit.rules

    line: “{{ item }}”

  with_items:

    – “

4.入侵防范

 

 

 

应遵循最小安装的原则,仅安装需要的组件和应用程序。

 

 

应关闭不需要的系统服务、默认共享和高危端口。

 

 

应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制。

 

 

应提供数据有效性检验功能,保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求。

 

 

应能通过使用漏洞扫描工具、人工漏洞排查分析等漏洞检查手段,及时发现可能存在的已知漏洞,并在经过充分测试评估后,及时修补漏洞。

 

 

应能够检测到对重要节点进行入侵的行为,并在发生严重入侵事件时提供报警。

 

 

所有安全计算环境设备应全部专用化,不得进行与业务不相关的操作。

 

 

应能够有效屏蔽系统技术错误信息,不得将系统产生的错误信息直接或间接反馈到前台界面。

 

 

我们针对此项标准具体限制如下:

 

 

 

禁止终端因control-alt-delete操作导致系统重启

 

 

关闭不需要的服务

 

 

5.小结

 

本次Ansible并没将所有的安全控制点全部实现,某些控制点需要结合安全部门及相关安全产品做进一步的管控,因此我们就不做过多的介绍了。但是在操作系统层面,我们运维还是要将控制点合理的限制在等保合规基线范围内,我认为最好的效果就是一次投入、持续受用。

 

总结

 

等保的合规基线是不断调整的,因此我们也要及时关注并更新Ansible Playbook的相关task。另外,换一个角度看等保合规基线其实也是给我们指明了操作系统配置的一个方向,大家再也不用为没有统一标准发愁了,有了参照相信我们一定能够做出一套非常完美的模板来。

 

 

Zabbix监控Kafka topic积压数据

 

基于等级保护梳理服务器安全合规基线

 

运维从零认识IaC

 

Linux高危命令,运维人手一份

后话:PipeLine支撑运维自动化

运维思索:自动化运维体系如何入手?

Teleport:开源简单易用的堡垒机

札记:他强任他强,清风拂山岗。

Ansible实现等保安全合规基线,运维尽力了!》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/632.html