《老司机的安全“套”路》第二期:从架构角度看安全 上篇

CareerOn
企业专栏
热度: 5053

《老司机的安全“套”路》第二期

CareerOn联合创始人、首席技术官周燃Mccoy做客《老司机的安全“套”路》系列线上分享会,并担任第二期的主讲人。


本次分享会的主要内容围绕着:从架构角度看安全方面展开,下面是本次分享会内容的详细文字版。

云安相关概念

及安全架构的定义

今天主要要讲安全架构⽅⾯的内容,也就是怎么做才能搞定安全这件事。具体开始前,我先说下什么是架构。之前我们说过,安全通常分解为三个⽅⾯:安全产品、安全运维、安全架构。


前两者都是具体实施⼿段上的细节问题,架构问题回答的是很多⼈经常有的疑问:如何做才能搞定安全这件事----这就是架构。


交易所安全其实和传统企业安全没有太⼤差别,企业安全是云安全的⼀个分⽀。云安全通常三个⽅⾯:公有云安全、私有云安全、企业IDC。


企业IDC安全⼀定程度上可以合并到私有云安全⾥去,不过企业IDC安全⼜有它稍微不⼀样的地⽅,所以这⾥把它和私有云安全分开来作为⼀个分⽀。⾄于混合云安全,实际是⼏个⽅⾯的综合,不单独说了。


说了这么多,其实核⼼就是:交易所及普通企业安全是云安全的⼀个分⽀。


所以我们从头来讲云安全,我先解释下什么是云:云是在对传统软硬件产品和服务抽象出标准接⼝的基础上、屏蔽了软件硬件差异,对外提供基础性IT服务的服务,云与虚拟化没有必然关系,但为了抽象出标准接⼝,虚拟化是必要⼿段;同时,物理服务器也未必不是云,关键看它是否有⼀整套的统⼀对外服务和管理接⼝。


总结⼀下就是:云是⼀种IT设施以及相关服务的交付⼿段。

公有云、私有云及企业IDC

安全产品和安全运维的异同

接下来我们就来讲讲如何搞定云安全,也就是云安全的架构问题。


第⼀,需要搞清楚公有云、私有云、企业内⽹他们各⾃的安全问题特性,再针对他们的异同点针对性的做出架构设计。


公有云重产品,⽬前的公有云环境多数是中⼩企业,他们没有特别强⼤的安全运维团队,所以更希望安全产品帮它解决所有安全问题。因此,公有云环境实际上对安全产品本身的处理和防御安全问题的能⼒提出了更⾼的要求。


具体表现在如下⼏点:


对主机反⼊侵产品的效果特别看重。中⼩企业来说,服务器数量不是特别多,业务也并不复杂,安全问题更多集中在服务器被⼊侵上。所以解决服务器被⼊侵问题是他们的迫切需求。


对服务器⼊侵容忍度低,是因为他们服务器数量少,牺牲任何⼀台服务器都可能对他的业务造成致命影响,所以服务器⼊侵问题是他们对云平台好坏评价的基本的也是最重要的标准;


对安全服务不敏感,因为安全服务多数是需要被服务对象具有⼀定的安全运维能⼒,中⼩企业不具备这样的能⼒。⽐如态势感知、威胁情报这样的偏服务型产品,其输出内容并不⾜够容易理解,也并不能对企业安全产⽣直接效果,对中⼩企业没有实⽤价值;


对安全产品的⾃动化处理能⼒要求⾼,中⼩企业囿于⾃身能⼒问题,安全问题⾼度依赖安全产品的⾃动化处理能⼒和防御能⼒,⽽且更多体现在实时阻断能⼒上;


对资源占⽤敏感,公有云客户多数资源并不充分,且因为认知问题,对于第三⽅安全产品占⽤的资源量特别敏感,⾮常容易因为资源占⽤问题⽽投诉安全产品,或者直接关闭相关安全产品。


对安全问题的共担意愿低,⼀旦出现任何安全问题,客户通常都把原因直接归因于云安全平台做得不够好,即使很多问题实际上应该是和客户共担⻛险的,⽐如经多次提醒仍不修复的弱密码和系统的、应⽤的漏洞等等。


后果就是:


主机反⼊侵产品应该是公有云环境云安全的核⼼内容。公有云环境的安全体系建设应该把主机反⼊侵产品作为重中之重。


功能点实现上,应该尽可能降低需要客户操作的内容,最好是完全⽆需客户额外操作。


这要求安全产品的设计者对安全问题处理经验,安全问题对系统的影响,安全问题与各种服务器应⽤的关系等有着极为成熟的理解度。既保证⾃动化处理的效果,⼜保证对⽤户系统和业务产⽣尽可能⼩的负⾯影响。


产品功能表现上,公有云安全更倾向于实时阻断型功能,数据分析型功能可以适当弱化。


这点来说,公有云上的安全服务型产品更多⾯向云平台⾃身的运维团队,为运维团队的运维⾏为提供数据⽀撑和分析⼿段,具体产品设计实施⽅⾯,就要求这些产品所提供的数据⾜够细化和专业,提供的分析⼯具和⼿段也⾜够充分,⼀切以⽅便运维为前提,反⽽对⾃动化的结果分析没有太多要求。


公有云的安全运维团队应该是以改进现有云安产品效果、为云安产品创新提供⽀撑为最终⽬标,其运维对象是安全产品,直接⽬标是让安全产品发挥其最⼤功效,并最⼤程度降低安全产品的固有弊端。⼀切运维⾏为围着产品转是公有云安全运维的基本特征。


这⾥其实就回答了⼀个问题:公有云运维团队与私有云、企业IDC运维团队,他们的业务⽬标以及做法上的差异在哪。


第⼆,私有云及企业内⽹重运维。这⾥之所以把企业内⽹安全和私有云安全⼀起说,是因为企业内⽹可以认为是私有云的⼀个特殊形态。


展开解释前先要说明,这⾥的企业内⽹仅指IDC⽣产服务器机房,办公⽹络不在此范畴内。办公⽹络的安全问题是另⼀个话题,在此不做进⼀步介绍。


私有云和企业内⽹的不同点在于:


私有云更多指的是云平台商通过标准化与个性化的结合,对公众输出的、针对具体企业客户⼀定程度定制过的、与公有云环境物理或者⾄少逻辑上隔离的⽹络及服务器环境,是toB的⼀个具体的云计算商品,可以认为是具有定制化特性的公有云商品;


⽽企业内⽹实际上是企业⾃建、⾃⽤的机房、⽹络、服务器环境,不具有商品属性,拥有⾼度定制化的环境,与企业⾃身的业务特性⾼度结合。


私有云和企业内⽹的共同点在于:


他们都具有相对隔离的环境,使⽤范围都仅限于企业⾃身业务,都针对⾃身业务做过定制化处理,架构设计都不具有通⽤性,使⽤者都具有⼀定的安全运维能⼒以及⼀定规模的安全运维团队。这些异同点导致了他们的安全问题特性以及具体做法上的异同。


  • ⾸先,私有云环境因为是基于标准化云产品做出的特殊定制,所以私有云的安全问题具有⼀定程度的共通性,其安全特性也继承了云平台的⼀些基本特性,安全缺陷也通常⼀并继承过来。


⽽企业内⽹环境因为⾼度定制化,每个企业根据其业务内容、业务规模、业务特性、企业特点等理由,内⽹环境⼏乎不会有任何相同,安全特性和安全缺陷也因此完全没有相关性。


  • 其次,因为私有云仍然是在标准化产品的基础上做的定制,所以由同⼀个云平台提供的不同企业私有云之间在运维⽅式和运维⼯具、途径上有相似的地⽅;在相关安全规则的制定上也基本遵循相似的逻辑,引⼊的安全问题也都有相关性。


⽽企业内⽹基于完全没有相关性的环境发展⽽来,不同企业的运维⽅式、运维⼯具和途径,安全策略的制定与实施,都完全没有相关性,相关安全问题也是花样百出。


后果:


  • ⾸先,私有云及企业内⽹的安全问题都更重运维。因为基于私有云或者⾃有机房运⾏业务的企业通常都具有⼀定规模的安全运维团队,有相当的安全能⼒,为通过运维解决安全问题提供了可能。对于私有云以及企业IDC来说,重运维也是必然的选择。


  • 其次,这些企业通常都业务复杂且⾮常敏感,⼀旦出问题对公司乃⾄对社会都会产⽣严重影响,⽐如银⾏。在这种环境下,很难单⼀通过安全产品程序既满⾜功能性需求,⼜避免误操作导致的⻛险。


  • 再次,企业环境,很多时候可以容忍牺牲部分服务器被⼊侵,但不能容忍服务器被⼊侵后⽆法及时发现,所以私有云及企业内⽹的基本安全⽬标就是及时发现⼊侵,⾄于⼊侵防御,通常更多依赖具体的运维⼿段。


实际上,在企业环境⾥,基于对误判的低容忍以及“牺牲部分服务器”情况的⾼容忍,不建议使⽤阻断性的安全产品,以“监控+应急响应”为主。


接下来讲讲⼀般性原则和⽅案:


A、产品为运维服务。产品存在的意义是为运维提供数据⽀撑和⼯具⽀撑。具体到产品实现上,体现为产品⼏乎以收集数据、分析数据以及执⾏运维命令为核⼼功能,⽐如⽇志数据的收集及分析等等。


这⾥就体现出了与公有云的区别:公有云更多是产品及研发团对驱动运维团队,⽽私有云及企业idc是反过来的,由运维团队去驱动产品及研发团队。


说的粗暴点就是:公有云环境产品及研发团队会处于相对强势的地位,运维团队处于协作、配合的位置;⽽私有云及企业IDC环境运维团队处于相对强势的地位,产品及研发是协作与配合的地位。


所以⽐较粗暴的判断某个公司安全架构是否合理的⽅式就是:看他们产品研发与运维团队的协作与被协作关系就⾏了。


B、安全问题的处理⾼度依赖运维团队以及完整的管理制度、应急处理机制。⽐如,通常安全运维团队都有7X24⼩时值班的倾向,所有服务器基本都会有实时联络⼈,对服务器的异常处理都有⼀套完善的流程做指导。


这点,在BAT贯彻的⽐较彻底,⼩公司很难做到,所以我之前也建议⼩公司尽量不要⾃⼰处理安全问题,找个靠谱点的第三⽅安全公司⽐较合理。⽐如⽬前的各个代币交易所,最好的选择就是找靠谱的第三⽅安全公司处理安全问题。


C、⾼度依赖服务型安全产品,⽐如态势感知、威胁情报、扫描器、数据分析平台以及红蓝对抗等运维⼿段。运维⼈员做出决策,更多需要借助这些⼯具来为⾃⼰的决策提供⽀撑,同时结合⾃身经验和能⼒,对这些数据加⼯分析,得出具体策略内容。


但私有云和企业内⽹在这⽅⾯⼜不完全⼀致:


私有云环境的运维团队通常没有企业内⽹那么⼤规模,其安全能⼒也要弱于企业内⽹环境的安全运维团队(前⾯这些观点可能有失偏颇,但很⼤程度也是事实情况),最重要的⼀点是私有云的基础设施由云平台提供,其运维团队对私有云的基本架构逻辑和安全特性掌握不⼀定充分。


这些事实情况给运维团队分析数据并得出结论制造了障碍,所以他们更多倾向于这些服务型产品⼀定程度上输出处理建议;⽽企业内⽹环境的运维团队通常具有安全能⼒优势,也对⾃身所处⽹络和服务器、业务环境有更充分的认识,他们更多倾向于利⽤安全产品输出的原始数据⾃⾏分析得出结论,对安全产品的智能化要求不⾼。


D、⾼度依赖安全管理制度。⽐如对安全边界的控制(防⽕墙、内⽹分区、端⼝开放限制等等),对操作流程的限制等等。堡垒机、跳板机这样的措施实际也可以归类为安全管理制度之列。


E、安全措施深度切⼊业务环境,⽐如针对具体应⽤程序做出专⻔的加固处理,这在公有云是不可接受的也⽆法实现的。


F、防御性安全产品必不可少,但产品更多是作为运维团队的安全防御⼯具出现的,安全防御产品极少会作为独⽴的解决⽅案存在。


总结:私有云及企业内⽹环境,安全问题的解决以运维团队为中⼼,所有安全产品及制度都为安全运维服务。


产品⻆度:核⼼是搭建⼀套数据收集及⼤数据分析平台,以及⼀套顺畅稳定、易于使⽤和事后追踪的运维⼯具;同时,强化服务型产品的研发⼒度,以运维需求为基本⽬标,实现产品研发与运维的良好协作。


运维⻆度:重视团队成员数据分析能⼒和⼯具应⽤能⼒,重视关键数据敏感度;重视红蓝对抗等基本运维⼿段;建⽴基本的安全管理制度和应急处理机制,有完整的应急处理流程。


产品与运维在私有云和企业内⽹安全问题上⼆者缺⼀不可,有主理与协作之分,但⽆重要度之分。

声明:本文为入驻“火星财经 专栏”作者作品,不代表火星财经官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
本内容旨在传递行业动态,不构成投资建议或承诺。