【廉环话】漫谈信息安全设计与治理之云系统的那些事

原创
安全
跟大家汇报一下,前几次提到过的那个云平台项目基本已成型,现在进入到了对其服务连续性和灾备以及安全性分析的阶段了。所以这次的漫谈的灵感来自该项目中的点滴收获,和大家分享的思路也是:先谈基本系统的普遍注意点,然后深入交流云服务系统(特别是在公有云上)的特殊性。

【51CTO.com原创稿件】大家好,手头的项目告一段落,哥上周休假去了。记得在电影《罗马假日》里曾有提到:“要么读书,要么旅行,身体与灵魂,必须有一个在路上。” 所以,习惯阅读与思考的我在行囊里也放了一本专业书籍。玩耍了一整天后,夜深人静之时也会拿出来抚卷阅读。同行的损友笑话我:出来放松还把自己整得像头上悬着达摩克利斯之剑似的。我只能说:世人笑我太痴狂,燕雀安知鸿鹄之志。好吧,不扯远了,继续这次的正题吧。

[[177554]]

跟大家汇报一下,前几次提到过的那个云平台项目基本已成型,现在进入到了对其服务连续性和灾备以及安全性分析的阶段了。所以这次的漫谈的灵感来自该项目中的点滴收获,和大家分享的思路也是:先谈基本系统的普遍注意点,然后深入交流云服务系统(特别是在公有云上)的特殊性。

连续性与灾备

说到服务连续性和灾备计划,基本上当前大多数企业都或多或少的有所涉及。就像我们小时候常听到的《狼来了》的故事一样。如果狼总是不来,喊多了也就没有意思了。但是上升到理论层面,套用时间管理的术语来说,连续性和容备其实属于“重要但不紧急”的事情。我们不得不花时间和精力去“以大博小”,来体现我们那“高瞻远瞩”的忧患意识。

对于一般企业IT服务的连续性设计,我们可以从如下三个方面进行考虑:

  • 识别服务与资产,对其进行分级和估值,并完成业务影响分析(BIA)。
  • 通过关键服务的各种测试,包括:功能测试、性能测试、压力测试、渗透测试以及恢复测试,制定出效率和精度平衡的策略来备份应用程序、配置和业务数据等。
  • 从业务和用户角度出发,制定相应的应急预案和灾难恢复措施,加强日常演练,从而将业务中断的风险降到企业及用户的可接受范围内(可参照上次我们聊到的服务级别约定)。
  • 选用软/硬件的瞬间切换和容错/互备技术来保证系统高可用性。

而在编制系统灾难恢复的流程时,可以参考如下通用步骤,具体系统与特殊服务可在此基础上增删。

  • 恢复硬件或相关设施。
  • 利用技术手段恢复操作系统。
  • 根据配置管理数据库里的相关文档描述,重新配置该系统,包括驱动程序设置、用户参数、文件修改与增删等。
  • 应用软件或程序的加载与定制。
  • 应用数据的导入与测试。
  • 对整个系统进行重新全量备份。

那么除了上述传统的连续性和灾备要点之外,对于正在使用云系统或服务的企业来说,和以前完全自行管控的不同之处在于,现在由于使用的是云平台,在网络资源、硬件配置和软服务上各种服务,基本上是以平台提供商为单位整体展现出的一体化的打包模式。所以原始的细粒度的BIA已经不一定适用了。反而,及时、准确的向云服务提供商更新自己系统的各项配置,保持顺畅沟通,并时常与之联动,进行事件(事故)的响应与恢复演练,就显得更为重要的。我的经验是:乘着现在还是“买方市场”的格局,这些条款或事项完全可以追加到与他们的SLA中。

另外,因为在云端,对于IT部门来说,某种程度上已经是“摸不着”了,那么就要做得任何时候都能“看得见”,就需要加强监控。监控的内容可以包括:对服务页面(网站)的监控、服务器(虚拟主机)的监控、各项服务性能的监控、甚至是各种API调用的监控等。通过主动发现、准确定位、快速响应的方式来减少云端业务中断所给企业带来的运营风险。

同时,我也注意到自己身边有一些企业会另辟蹊径,他们把云服务作为自己当前系统的一种备份方式。通过运用云计算技术中的虚拟化,实现重要数据资源以多样、安全和快捷的方式进行备份和迁移,从而利用云计算带来的“红利”,实现了自身业务的弹性变更,也达到了系统灾备和恢复能力的提升。

深入来看,云备份镜像可以实现对主站点的完全备份。当服务流量负载从主站点切换到云端的热镜像后,利用云端资源的弹性优势,服务性能基本上不受影响。大幅缩短恢复点目标和恢复时间目标。当然镜像同样需要IT人员进行日常维护,灾难恢复的各种演练可以在镜像上反复模拟。根据云服务的本质特点,镜像的运营成本相对另建备用站点的软硬件成本要低廉许多。另外,双方也可事先确认SLA,说明系统将以何种速度启动,需要哪些资源,才能将业务恢复到正常工作的水准。

安全与取证

既然说回到安全,我们IT部门仍然应当根据相关的管理标准(如ISO27001等)去着力建立一个业界时常提到的但应适合于自己企业的信息安全管理体系(ISMS)。

首先是在整体上,对IT服务所涉及到的信息进行机密程度的等级划分,对各种软/硬件服务进行单点故障和潜在风险识别、分析与评估,找到性能的瓶颈并区分优先级。

其次是在技术上,可从如下三方面技术入手,根据企业的自身条件和IT状况进行应用和部署:

  • 基础支撑技术:密码技术,认证技术,访问控制理论,网络资源管理。
  • 被动防御技术:入侵检测系统,蜜罐,虚拟机,应用网闸,数据备份与恢复。
  • 主动防御技术:防火墙,入侵防御系统,VPN,病毒查杀,安全扫描。

当然,在各种安全技术引入的同时要注意控制选购、实施和维护的成本,而且要兼顾安全可靠性与易用性的平衡。

再次是在物理上,应做到信息以及设备之间有物理的隔离,各个功能区的分隔与划分,机房和门禁出入的记录、控制和审计。

最后是管理上,要注重各种安全方针和手册以及操作流程文件的制定,安全意识和应对安全事件的人员培训,相应账户和访问权限的最小化设定与监控等。以及当有安全事件发生时,可以考虑用多种取证技术相结合。例如:存储介质的数据恢复、解密技术、入侵追踪、信息过滤、搜索和挖掘、以及磁盘镜像拷贝等。

我们再来看看云服务及系统的相关安全方面。先看“事前”。

不得不承认,若干年来,各大安全硬件厂商都讳莫如深的形成了所谓的“联盟”极力想企业兜售安全硬件产品。而今,既然已经是云时代了,成千上万的多租户共享着相同的物理资源,云平台提供商已经为我们准备好了前端的安全硬件“黑盒子”,提供了接入端的一揽子解决方案。他们通过整合各种物理资源(如加解密类硬件设备)、虚拟资源(如虚拟IDS、IPS、WAF)以及提供专业技术支持方面的人力资源(如安全事件管理员、漏洞分析员),采用虚拟化技术构建了统一的资源池,并对资源采用均衡负载、灵活调配以及最大化利用等方式,实现对租户安全功能的便捷交付。可以毫不客气的说,由于面对多租户环境,云服务提供商可能会比我们自己传统的IT部门更加及时和专业。他们通过云端强大的服务器,实时处理随时爆发的新型攻击,更新信息数据,能够有效控制危险事件的大规模发生和传播。

所以我们真心没有必要再花大力气去为自己的云平台考虑购置安全硬件了,只要守护好自己的“一亩三分地”便可。大家都知道软件定义网络(SDN)技术吧?个人觉得它已经不只是简单的实现“Bridge”或“vSwitch”的基本功能了。它是安全界的一股清流。对于实力雄厚且富有开发经验的企业来说,可以运用SDN的技术,通过软件编程等方式,定义自己的虚拟防火墙、入侵检测、DDoS检测、流量清洗甚至解决各种QoS问题;而对于“只愿出钱不远出力”的企业,也可以通过购买集成了IPS功能的软件来进行深度流量报文检测,从而发现虚拟机上是否存在漏洞。这里要多说一点的是:由于离开了企业传统的较为封闭的系统环境,这些基于云端的安全软件网络防护所设置的规则、漏洞库等数据不再受本地数据源限制而依赖于小范围数据采集,也摆脱了服务器定时或者手动更新的性能瓶颈。各种安全知识库,病毒特征码、URL黑名单、垃圾邮件指纹集,Web 攻击特征等,可以通过云的方式实现第一时间的更新,也就是在和0 day攻击者赛跑时穿上了跑鞋。

为了防止由于各种外部攻击或者是云服务提供商自身的原因所导致的租用空间的隔离失效的情况,必要的纵深防御是个趋势。我们企业安全人员在学会善用各种云安全相关工具的同时,要花时间制定和最终践行一个适合自身企业的“安全基线”。它也可作为上述服务连续性和灾备计划的一个重要参考依据。下面给大家简单列举一个范例供大家批判性的接受哦:

  • 网络层面:

运用防火墙策略隔离出用于平台管理的网络。

启用VPN或者是双因素认证的访问接入控制。

  • 操作系统层面:

调整默认设置,关闭不必要的服务,定期打系统补丁等系统加固。

安装基于主机的IDS。

开启详细的日志服务,并定期将日志离线导入中央日志管理平台或聚合到安全信息事件管理SIEM,以防日志被篡改。

定期审查系统级别的管理员权限。

  • 应用层面:

启用多因素认证来保护Web表示层和应用日志。

用基于角色的访问控制来细粒度控制应用的各项工作流及操作。

同样定期将日志离线导入中央日志管理平台或聚合到安全信息事件管理SIEM,以防日志被篡改。

我们最后来看看“事后”。据我的一个在云安全运营中心(SOC)的“眼线”朋友透露:一直以来,在各种使用云服务的企业的被攻击案例中,大多数是因为采用了弱口令之类的弱安全基线。而受到攻击后一般都以“Just my luck!”的方式三缄其口,并无后续的取证或诉讼。正所谓“God only help those who help themselves”,我们对待既已发生的云安全事件,要像“法医秦明”做好各种取证工作,以彰显自身专业性。依据经验,哥总结下来,一般步骤分为文件分析取证和数据分析取证两步骤:

文件分析取证是通过各种日志(包括超过阀值的错误登录日志,当然也包括成功登录的日志,因为里面特殊账户登录的时间戳)信息的查找,以及文件目录结构和文件名的扫描,如果发现可疑的shell脚本之类的文件,可以通过查询其生成的时间和其关键字信息等,来判断其是否利用了诸如Web漏洞或者是通过Web Server执行的命令等进行了攻击。

而数据分析取证则是登陆到攻击主机或“肉鸡”主机的数据库的后台,查询是否有不明IP地址的登陆记录,结合服务器日志分析,重点考虑是否有非法的用户名生成,或是有提权之类的操作。

总的说来,可以用一个P2DR2M(Protection、Policy、Detection、Response、Recovery和Management)的口诀来概括企业云服务系统安全所涉及到和需要考量的各个方面。

好了,佛语有言:“你种下什么因,就会有什么样的果。”我既然在几个月前选择开启了咱们漫谈这个大IP剧,我自然会一直惦记着它。平日虽无什么如芒在背的“鸭梨”(压力),但还是有义务和责任保证其每一集的频率和质量的。诚然我自知文采有限,且谈的既“漫”又“慢”,但还是真心希望能对读者您的工作有所帮助,让你能有“看过都说好”的赶脚。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:武晓燕 来源: 51CTO.com
相关推荐

2016-12-15 09:46:15

信息安全资源治理廉环话

2017-01-12 08:51:41

2016-12-22 08:28:26

IT核算预算信息安全

2016-11-09 21:42:14

信息安全廉环话

2016-09-29 10:56:32

信息安全人员治理安全管理

2016-09-18 09:42:50

2016-10-13 10:49:57

云平台选型信息安全

2016-09-08 09:25:40

BYOD信息安全

2016-11-24 08:25:41

2016-08-18 09:26:37

2016-12-29 10:06:43

IT管理信息安全

2017-01-19 09:30:10

2016-12-08 10:14:23

信息安全变更管理廉环话

2016-08-11 09:58:39

2016-10-20 08:07:27

信息安全人员治理廉环话

2016-11-17 10:16:37

2016-09-22 08:55:31

信息安全备份廉环话

2016-09-01 06:51:23

无线覆盖与管控信息安全

2016-10-27 09:12:28

2016-09-27 17:40:02

网络安全技术周刊
点赞
收藏

51CTO技术栈公众号