好久不见,安全圈小姐姐我又来啦~今年以来我司系统开启全面上云的步伐,核心业务系统也在陆续迁移上云,已在公有云上部署了大量的IT基础设施(虚拟机、数据库等)、应用和数据,管理层也十分关注云上IT信息系统的安全可靠性。为了有效控制云计算信息安全技术风险,我司已在今年年初制定了公司内部《公有云信息安全管理要求》,并在2021年底开展了为期1个月的公有云安全专项审计工作。在此我总结了这次云安全审计的一些经验,欢迎各位安全同仁交流指正。
Part1:云安全审计特点
云上安全审计本质上和传统云下IT审计一样,都是从用户身份鉴别访问控制、基础架构安全、应用安全、敏感数据保护、业务连续性管理等方面确立安全标准,审查实际执行情况是否满足CIA(可用性、完整性、保密性)的要求。但云计算特别是公有云也具有自身的特殊性,云安全审计主要具有以下3个方面的特点:
做好云上不同网络环境隔离:云下一般是通过防火墙、交换机等安全设备来进行内外网隔离、控制外网访问权限,而在公有云上则需要通过云防火墙和安全组策略配置来限制访问源地址,配置IP白名单等,达到网络隔离效果。
访问凭据应加强保护:由于公有云是可以在外网进行访问的,因此对访问者需要增强身份认证(使用MFA双因素认证),对访问凭证信息需加密存储,对公有云ram账号异常登录行为(如异地登录、多次失败登录)需要进行审计。
应利用云上审计功能提升审计效率:云上系统数量庞大,运维灵活,企业可利用公有云自带的审计工具配置的合规检测机制,对海量的云上设施进行实时或定期自动化扫描,有效提升审计效率。
Part2:云安全审计项目实施流程
(一)确定审计对象
目前我司3个IT团队使用不同的云账号对云上资源进行管理,本次审计对这3个IT团队的ECS、K8S、OSS、RDS 、Redis、Mongo dB、MaxCompute、云防火墙、云WAF、SLS等10余个云资源及服务对象开展检查。
(二)确定审计控制点和审计方法
在设计云安全审计检查项时,我们以公司《公有云信息安全管理要求》为依据,参考了云安全联盟CSA发布的《云控制矩阵V4.0》和云配置审计自带的等保2.0合规检测项,最终确定了“访问控制”、“网络安全”、“主机安全”、“数据安全及业务连续性管理”、“数据库安全”、“OSS管理”6大类36个控制项的Checklist, 并明确了每条控制措施的检查方法,如下表。 该控制点清单基本覆盖了我司公有云安全规范要求,其中近50%的审计项都通过云配置审计功能自动执行得出审计结果(主要分布在“访问控制”、“数据库安全”、“OSS管理”3类别的控制项中),其余的需要人工抽样审核。
控制大类 | 控制措施编号 | 控制措施 | 检查方法 |
访问控制 | 1.1 | 规范云原生系统账号新增、权限变更和离职禁用管理流程。确保员工转岗及离职后及时禁用云账号、RAM子账号。 | 人工审核云上系统账号管理流程。获取云账号及ram子账号系统清单,检查有无离职人员账号未禁用 |
1.2 | 不存在超级管理员 | 云配置审计 | |
1.3 | RAM用户登录检查(是否存在非实名制账号、异常登录和操作行为) | 云配置审计 | |
1.4 | RAM用户开启MFA双因素认证 | 云配置审计 | |
1.5 | 云原生系统的账号密码策略应符合安全规范:设置密码有效期,密码最小长度,具备密码复杂度等 | 云配置审计 | |
1.6 | 镜像仓库启用权限控制,应控制具有新增、修改权限的人员或系统数量 | 1、查看容器镜像的用户权限; | |
1.7 | 统一日志服务应实现访问者的身份认证和权限隔离 | 1、查看具有云SLS权限的用户清单; | |
网络安全 | 2.1 | 应根据安全等级划分区域,启用云防火墙服务,确保云上测试环境和生产环境实现网络隔离 | 查看云防火墙安全组隔离情况 |
2.2 | 应对云上与云下机房间的实时业务流量与非实时业务流量进行链路分离 | 通过访谈、拓扑、配置查看确认 | |
2.3 | SLB实例监听端口不包含指定端口 | 人工查看不包含指定端口:3389、22 | |
2.4 | 应关闭互联网方式远程运维管理权限,不得在外网直接远程访问云上生产服务器 | 查看云上生产主机堡垒机托管情况,确认云上业务应通过内网使用堡垒机接入生产环境主机 | |
2.5 | 应对云上网络变更事件提供日志记录用于事后审计 | 查看云上操作日志VPC配置变更有无日志 | |
主机安全 | 3.1 | 云服务器都必须安装云安全中心,部署启用主机入侵检测服务 | 云配置审计 |
3.2 | 云上主机使用经过信息安全部评估过的操作系统版本,确保满足安全基线要求 | 访谈及人工抽样检查确认云上生产主机操作系统镜像使用的是符合安全基线的版本 | |
3.3 | 应禁止直接以root账号部署或运行应用/中间件/容器/数据库 | 人工抽样检查云上各类型系统是否存在以root账号部署情况 | |
3.4 | 应对云上主机日志进行汇聚与审计,日志留存时间不得少于180天 | 检查云上主机日志记录和存储时间 | |
数据安全及业务连续性管理 | 4.1 | 所有云上B/S应用在对公网提供服务时,必须启用加密通信协议 | 云配置审计,查看是否启用云WAF提供防护 |
4.2 | 云上包含敏感信息的应用系统,应在数据库记录用户操作日志,并对导出含敏感信息的报表增加机密标签 | 检查云上应用系统是否记录用户操作日志并落库 | |
4.3 | 云上系统中用户隐私信息(例如证件号、联系方式等)应加密后存储 | 使用“数据安全中心”查看数据库中是否存在明文敏感信息 | |
4.4 | 禁止在应用日志内明文显示敏感信息,通过云端SAAS服务(如:RMQ、Redis)临时存储的敏感数据必须加密后临时留存,使用后立即清除 | 人工抽样云上重要系统检查应用日志中有无客户证件号银行卡号手机号等敏感信息,审核临时存储的敏感信息是否加密存储和及时清理 | |
4.5 | 测试环境不得使用生产环境数据,测试环境不得共用生产环境的计算资源及服务实例 | 检查生产测试环境是否存在共用基础资源情况,测试环境是否使用生产环境数据 | |
4.6 | 对重要系统的数据必须在本地机房留存数据库备份或镜像库,定期做备份数据恢复性测试 | 访谈及人工查看云上存储用户信息、交易记录的重要系统数据库,在云下是否有备份库或镜像库 | |
4.7 | 涉及交易、账务管理的应用服务至少部署两个应用节点,并分配在不同可用区实现应用容灾 | 人工查看云可用区配置情况 | |
数据库安全 | 5.1 | Mongodb实例IP白名单不设置为全网段 | 云配置审计 |
5.2 | Redis实例禁用高风险命令 | 云配置审计 | |
5.3 | Redis实例未设置公网IP | 云配置审计 | |
5.4 | Redis实例IP白名单不设置为全网段 | 云配置审计 | |
5.5 | Redis实例开启密码认证 | 云配置审计 | |
5.6 | RDS实例使用高安全白名单模式 | 云配置审计 | |
5.7 | RDS实例开启SQL审计,实现历史SQL审计、SQL执行情况、性能指标、安全问题的实时分析 | 云配置审计 | |
5.8 | RDS实例正确开启安全白名单 | 云配置审计 | |
5.9 | RDS实例未申请外网地址 | 云配置审计 | |
5.10 | 对云端数据库软件进行安全加固(如:设置数据库账号密码策略、访问源限制等) | 人工检查是否具备密码策略配置、访问源限制 | |
OSS管理 | 6.1 | OSS存储空间ACL禁止公共读访问 | 云配置审计 |
6.2 | OSS存储空间ACL禁止公共写 | 云配置审计 | |
6.3 | 使用OSS存储资源时,应对oss凭证信息进行加密存储 | 人工抽查云上系统oss凭证信息是否加密存储 |
本次项目花费时间较多的其实是在确定控制点清单和检查方式上,因为是首次进行合规检查,完成以上Checklist的确认和熟悉公有云配置审计功能花了差不多2周时间。
(三)审计执行过程
对3家IT单位执行审计的过程较为顺利,在获得公有云审计账号后,一方面直接查看云配置审计的结果,其余人工审核控制点有许多也可以直接在云上查看相关页面,仅少部分控制点需要联系运维、开发同学确认管控情况(如抽查云上各类型系统是否存在以root账号部署情况)。审计执行工作耗时一周左右。
如下是云配置审计执行的部分控制点审核结果,给大家一些直观认识:
数据库安全合规管理:某子公司发现存在5个rds未开启SQL审计
OSS存储管理:已禁止OSS存储空间ACL公共读写
如下是人工审核的部分控制点检查结果样例:
OSS凭证信息已进行加密存储
SLB实例监听端口不包含指定端口:3389和22
(四)审计结果分析
通过本次审计,我们发现如下3个方面在系统上云过程中容易出现安全问题,需后续重点关注并定期检测:
访问控制:离职员工云ram子账号未及时禁用(部分云原生服务的账号体系无法对接企业SSO单点登录,导致无法自动关闭离职人员账号)、存在非实名制账号、账号未开启MFA双因素认证或密码策略设置不合理等情况。
主机安全:部分应用/容器/中间件还是存在以root账号部署情况,属于上云之初对于安全规范的培训落实不到位,上云完成大批量系统部署以后,再对老系统做整改难度和成本就会很高。
部分云上配置不合理:例如RDS白名单开了全通、OSS存储空间ACL允许从外网直接访问和修改其中的存储资源等,应调整配置策略控制访问权限。
Part3:心得体会
(一)企业上云之初就要建设好安全防护体系
云计算的发展为企业信息化提供更加低成本、灵活的部署模式。在国内信息安全立法不断完善的今天,企业在规划上云前就要对安全体系建设进行专题研究和统一规划,尽早制定符合企业实际情况的云安全规范。上云之初就应建设可控可防的云安全体系,部署合理的云上安全防护设备,并按照安全基线要求做好相关系统配置。同时给企业IT单位同事尽早做好宣导培训(我司通过建设科技团队信息安全员机制,每月由集团信息安全部给安全员进行安全制度的宣导培训,再由安全员在各自团队展开宣讲确保全体IT同事了解安全规范),明确标准。通过后续持续的内外部审计来及时发现风险和不断优化云安全治理框架,提升云平台的安全能力,切实保护企业的数据资产。
(二)结合企业安全合规要求与公有云特性,制定云安全审计检查项
我司上云之前已经在云下IT系统积累了很多的信息安全标准和基线。在系统迁移上云的过程中,就需要将这些合规机制在云上等价实施。本次我司在开展云安全审计时,一方面将已有的云安全管理规范转化为云上审计的控制点,另一方面也补充了公有云配置审计自带的等保2.0云上合规检测控制点,确保审计控制点的全面性,满足企业合规检测要求。
(三)有效利用公有云配置审计服务,提升云上审计自动化水平
云上IT系统相比云下可以更高频、更灵活的进行运维,管控的资源数量也更多,如何优化审计方法,提升审计工作的自动化水平也就变得非常重要。
本次我司云安全审计过程中,50%的控制点已实现通过云配置审计自动执行得出审计结果。已有的合规检测规则在云上能近乎实时、持续、批量运行,提供比云下方式更及时、高效、可靠的合规管理能力,提升了审计工作的效率和效果。
后续我司也会不断优化云上审计的控制矩阵和审计方法,尽可能多的将企业已有的合规要求配置为云上合规检测规则,进一步提升云上审计自动化水平;还会考虑启用不合规告警功能,实现IT系统自动且持续的合规管理。
作者:诺亚控股集团信息安全部-Verna