企业安全体系架构分析:开发安全架构之可用性架构深入讲解

2019-08-09 16:03:41 浏览数 (1)

之前发布了一篇文章《企业安全体系架构分析:开发安全架构之可用性架构》,其中粗略的讲解了一下可用性架构的设计理念,应读者要求,这篇文章将深入讲解什么是可用性架构。

首先我们从整体架构来看,其实安全所关心的无非是3要素:可用性、完整性、机密性。

那么什么是可用性?

可用性在CISSP中的定义是:

可用性意味着对信息实施了必要的安全措施,使得信息和系统能够被授权实体可靠、及时的访问到。可用性保护确保授权的用户能够对数据和资源进行及时的和可靠的访问。网络设备、计算机和应用程序应当提供充分的功能,从而能够在可以接受的性能级别以可预计的方式运行。它们应该能够以一种安全而快速的方式从崩溃中恢复,这样生产活动就不会受到负面影响。应该采取必要的保护措施消除来自内部或外部的威胁,这些威胁会影响所有业务处理元素的可用性及工作效率。

其实详细解释一下可用性就是:

1. 必要的访问控制 2. 多链路可靠访问 3. 完善的故障恢复与防御措施 4. 安全的网络配置

当然其实并不止这4点,但是我们可以着手先从这4点来考虑。

1. 访问控制

访问控制其实不仅是在网络层面做的工作,在应用层面,数据层面,管理层面,甚至物理层面都需要做访问控制。

(1)网络层面

网络层面重点体现在防火墙管控DMZ区的流量进出,管控跨网之间的访问哪些属于合规哪些不合规。举个例子,假如说我的某一个业务放在阿里云,监控体系与主体业务在腾讯云,由于成本问题我不想在阿里云单独建立一套监控体系,只想延用腾讯云的监控体系,但又要保证业务之间的隔离,那么这时候就要在云两端架设V**,并且设置仅允许监控系统与业务之间互相访问。

(2)数据层面

数据层面访问控制其实很好解释,什么人拥有什么权限访问什么数据,在数据库的设计理念其实是很清晰的,这里就不多做叙述了。

(3)管理层面

管理层面访问控制是规定了什么人拥有什么权限访问什么数据或拥有什么权力,这里特别想说明一下与数据层面的区别,数据层面的管控只是体现在网络数据上,而管理层面的管控则体现在整个企业上,不管是网络还是现实,是物理还是逻辑,都需要管理层面做相应的管控,没有哪个企业是能够脱离管理层的,这也是管理层存在的意义。

(4)物理层面

物理层面访问控制其实更好理解了,机房区域的管控,物理设备机柜的隔离,人员进出的登记等等。其实往往物理安全是容易被忽略的,设想如果没有严格的机房访问管控制度,黑客一旦在现实中混进机房,造成的破环不管是物理层的还是网络层的都是巨大的。

当然能做到这个样子是最好的,我们目前就打算做成这样

整个机柜再单上一道锁,相当于进机房一道,当然这是服务商的管理工作,机柜通道一道锁,优点是加强物理隔离安全,当然也有缺点,缺点是必须要固定租下整个两排的机柜才能做,这对于资金投入不大的企业是很奢侈的。第三道锁是机柜本身的锁,再加上服务商的监控措施,如此物理安全可以极大的保障。

2. 多链路

多链路可靠访问是针对网络堵塞、大环境网络故障、意外攻击等情况设计的业务可用性的体现,试想一个业务域名,比如ex.com,当遇到DDoS攻击时,大量的商户访问不到业务域名,造成的损失有多大;或者大环境网络出现故障,比如114DNS故障导致域名无法访问、中间节点路由出现故障等等,造成的损失也是巨大的。这时多线路解析以及双线路出入口的设计能够最大程度保证业务的可用性,也就是我们所说的CDN和双出口。

3. 完善的故障恢复与防御措施

完善的故障恢复与防御措施是针对意外发生时能够快速使商户正常访问业务所设计的,在这里假如因为意外情况导致我们的业务服务器宕机了,那么我们是在修复期间挂公告说业务维护然后快速抢修呢,还是切换到备用服务器后使业务正常同时抢修主服务器呢?我相信大家都会选择第二种,那么这就体现了主备架构的重要性。那么在这里其实还有一点,要把备服务器和主服务器放在一起吗?如果机房出现故障又该如何解决呢?这里其实推荐,如果主体业务是放在租用物理机房的话,把主服务器放在物理机房,备用服务器放在云机房;如果主体业务在云机房的话,建议是放在不同地点的云机房,最大程度保证业务的可用性。

4. 安全的网络配置

安全的网络配置其实是网络管理员做的事情,比如划分VLAN、配置V**、整体网络规划等等。但是在这里其实安全人员也是要参与进去的,网络设备的安全管理也是安全人员负责的一部分,在规划网络配置的时候,很多网络管理员为了方便维护,会不设置特权模式密码,或者设置为弱口令,相应的设备安全补丁也不会定期检测,因为他们呢觉得那不是他们考虑范围内。Cisco设备爆出的漏洞相当多了,还有监听事件不断发生(自行百度,怕发出来会被屏蔽……)其实底层设备更应该注重安全。

那么结合《企业安全体系架构分析:开发安全架构之可用性架构》中的拓扑图来看,我们采用CDN加速,入口SLB负载均衡指向两台服务器,一主一备关系。

并且存在V** 堡垒机的方式保证单人单一权限的访问控制,这在之后的一篇文章中有体现,主体业务与数据库均采用主备模式,最大限度的保证业务的可持续性。

当然在CISSP中有更丰富的概念解释,大家对以上概念不清晰的可以参考。

为什么我们要做业务连续性和灾难恢复?

虽然我们努力降低风险对组织的负面影响,但我们可以肯定的是:某种事件迟早会因为蒙混过关而造成负面影响。理想情况下,损失会被遏制,且不会影响到主要业务的运营。然而,作为安全专业人员,我们需要为意想不到的情况制定好各种计划。在这些极端(有时是不可预测的)条件下,我们需要确保我们的组织能够继续以最低可接受的阈值运行,并迅速全面地恢复生产力。

什么是业务连续计划?

业务连续性计划涉及到对组织各种过程的风险评估,还有在发生风险的情况下为了使风险对组织的影响降至最小程度而制定的各种策略、计划和措施。组织应当预先计划好以下过程:

出现紧急情况时提供即时和适当的应对措施:

保护生命和确保安全 减少对业务的影响 恢复关键业务功能

与外部供应商和合作伙伴一起完成系统恢复工作:

在灾难时减少混乱 确保企业的生存能力 在灾难发生后迅速“启动并运行”

什么是灾难恢复计划?

如果这种连续性受到破坏,那么业务过程就会停止,并且组织进入灾难模式;此时,系统将釆用灾难恢复计划。

业务连续性计划 VS. 灾难恢复计划

灾难恢复计划是当一切事情仍处于紧急模式下时实施的计划,其中每个人都争相让所有关键系统重新联机。业务连续性规划采取一个更广泛的解决问题的方法。它可以包括在计划实施中对原有设施进行修复的同时在另外一个环境中恢复关键系统,使正确的人在这段时间内回到正确的位置,在不同的模式下执行业务直到常规条件恢复为止。它也涉及通过不同的渠道应对客户、合作伙伴和股东,直到一切都恢复到正常。

以上是我个人对于可用性的理解。

*本文作者:煜阳yuyang,本文属 FreeBuf 原创奖励计划,未经许可禁止转载

0 人点赞