博威---云架构决胜云计算

 找回密码
 注册

QQ登录

只需一步,快速开始

搜索
查看: 2070|回复: 0

大型运维环境实施安全加固经验谈

[复制链接]
发表于 2007-4-29 09:35:55 | 显示全部楼层 |阅读模式
大型运维环境实施安全加固经验谈
出处:xfocus  作者:Coolc  时间:2006-08-10  网址:http://www.securitycn.net


pdf版本(图): 《大型运维环境实施安全加固经验谈》


前言    ………………………………………………………………………………………………………………1
背景    ………………………………………………………………………………………………………………1
内容    ………………………………………………………………………………………………………………2
困难    ………………………………………………………………………………………………………………2
思路    ………………………………………………………………………………………………………………2
准备阶段    ……………………………………………………………………………………………………2
人员准备    ……………………………………………………………………………………………………2
宣讲和破冰    ……………………………………………………………………………………………………2
实施和尝试    ……………………………………………………………………………………………………3
全面展开    ……………………………………………………………………………………………………4
重点关注    ……………………………………………………………………………………………………5
项目收尾完结    ……………………………………………………………………………………………………5
总结    ………………………………………………………………………………………………………………6
附录    ………………………………………………………………………………………………………………6


前言
    安全加固在安全甚至运维领域,已经是一个大家都不再感到陌生的名字了。相当多的安全甚至集成公司,都会再项目工程中提供此类服务。Coolc从事工作以来,也大大小小的实施了相当多次的安全加固工作,最近完成了一个大型运维环境的加固工作,积累了一些经验,现在记录下来与大家分享。
    因为所属工作的原因,coolc不会透露具体的操作的技术细节,这点还希望大家能见谅,但是Coolc会更多的阐述记录在项目操作中框架性思维和理念,同大家分享我的收获和经验。

背景
    本次项目之所能称之为大型项目,主要是基于如下几个特点。
* 涉及的主机众多,总体主机数量在万台以上。
* 涉及业务情况复杂、数量众多,其中重点大业务有数百个,而旗下子业务更为种类繁多。
* 业务多为在线业务,对于中断的容忍度很低。
* 涉及部门多,光运维层面的部门会涉及10余个左右,横向沟通成本较大。

内容
困难

* 选用何种层面的加固技术,是系统层?应用配置层?IDS配合iptables联动?抑或是kernel patch?
* 涉及的主机多为在线业务,如何保证平滑切换。
* 横跨多个部门,如何协调各个部门的人力资源具有相当难度。
* 安全加固本身是叫好不叫座的东西,在完成项目后如何体现安全加固的效果?
* 在自身进行了大量技术考量后,如何向技术部门验证你的说法,得到一线运维部门的支持?

思路
1. 争取运维线的上下层支持和理解。
2. 充分准备,数据支撑,取得认可。
3. 自动化部署,减轻工作量和误操作。
4. 充分考虑回退和规避运维风险。
5. 以点带面,分步骤部署。
准备阶段
  安全加固项目的准备阶段主要的工作内容为,
  
* 确定项目组成和成员的职责
* 内容宣讲,介绍加固项目的工作内容。
* 了解安全需求,打消存在的顾虑,争取配合和支持。
* 对加固内容进行测试,后续工程中需要配合工具和文档进行准备。
  
人员准备
  人员准备可讲的东西不多,从这次操作中较多的体会是,项目组中最好能配备一个具有编写脚本能力的人,减小大规模主机部属时碰到的巨大工作量。其次,人员不在于多,PM的沟通能力要很强,具有较强的破冰和应变能力。项目组能够阶段性引入实施部门的Teamleader ,在实施时会极大地提高执行力。
  
宣讲和破冰
  
  在安全项目中,最常见的问题就是实施方和相关的配合人员,因关注点不同而导致的分歧。项目中安全人员关注的是如何按时完成项目,保证自身的安全项目内容得以实现。而参与实施配合得人员关注点主要集中在。
* 加固是否会影响业务系统的正常运行。
* 加固是否会带来业务上的中断。
* 加固是否会给系统带来性能上的影响。
* 加固实施是否会带来大量的工作量和挤占大量的时间。
* 加固后运维工作是否会在操作上十分不便。
* 加固后的主机是否会会在安全上和现有水平相比,有很大提升。
  此时整个项目的主要矛盾是相关人员对加固没有了解,不清楚项目可能会带来哪些“利”、“弊。
  因此需要通过会议等方式,向各个部门的Leader ,骨干进行加固方面的知识介绍和内容宣讲。
  首先,为了验证自身说法的科学性,前期测试需要通过数据证明各种影响的具体数值,并给出目前的数值进行比较。根据数据同运维线沟通,商讨性能等指标容忍基线。
  其次,项目在设计时要充分考虑业务中断、性能的影响。本次操作中Coolc,在初始设计上规避重起等可能造成中断的行为,并出具了性能评估报告,比较图谱等进行性能影响验证。为了使报告具有说服力,应尽量争取将被实施部门提供样机(或选取明星部门的主机),以便采集数据得到较大范围的认可。
  再次,Coolc在本次加固项目中,实施采取自动化脚步、程序的模式进行。事先设置好加固项的配置文件后,执行安装脚本自动化部署,尽量避免部署所带来的时间和人力成本(Windows下安装应用程序亦是此类思想)。
  同时此类自动化部署,十分有利于在短时间内批量部署大规模主机。 而且脚本应具有很强的回退功能,能通过执行脚步达到完全回退的目的。(当然回退功能的自保护能力应该很强 :))
  同时,提供一份加固影响表,将每项加固内容可能带来的影响进行描述,并且在实施中时时更新此表,并同步收集故障案例,作为培训资料。
  最后,加固效果的验证本身存在一定的困难,前期可以采用制作演示录像,PPT讲解等方式,后期进行培训时,可以构建一些演练环境进行展示。
  
  总结一下,此阶段主要是对加固框架内容进行修正,同时向各个部门传导加固意识,打消顾虑,寻求领导层支持和理解,也为后面的大规模实施打下基础。
  
实施和尝试
经过前一阶段的准备和沟通,基本达成了如下效果。
* 各个部门在部门领导和骨干级知晓了解了安全加固的内容。
* 对安全加固内容的安全提升有了认可。
* 对于安全加固方面可能造成的影响有了一定认识。
* 熟悉安全加固项目中的项目组成员和每个成员的职责。
* 清楚地知悉安全加固不会带来很大工作量。并且是必须要操作的一个安全工程项目。

在此基础上,整个项目的主要矛盾点已经由对项目不了解,工作量可能的负担,转变为了安全加固是否给运维带来风险。
1. 针对主要矛盾上的变化,整个项目调整进入实施和尝试阶段。在此阶段 ,主要工作从各个部门抽取主机,进行初步的加固试运行。试运行的主要目的是:

2. 验证稳定性,因为此阶段运维人员重点关注稳定性,所以从项目组侧应保证,实施的加固大多数情况下,确实可以保证技术层面的稳定;如果一旦出现问题,响应时间解决问题的态度要到位;选取主机要具有代表性和一定的数量,这样在数据上才会有说服力和验证效果。

3. 进行项目磨合,此时是熟悉配合人员的最好阶段,同时也为项目组提供了后期部署的演练机会。因为此阶段时间压力小,因此应尽可能多的让项目组组员熟悉各个环节(让每个成员都可以互为备份),并对操作流程进行演练修正。

4. 试验主机的选取,Coolc采用的方式为典型主机选取方法,一般会选取如下类型的主机:
* 典型角色,选取的主机在业务架构上是典型角色,如一个游戏中,前台的应用服务器,Cache服务器,DB等,各抽取一台。
* 负载特征明显,系统负载上有较多代表性的主机,如高IO访问量的主机,高并发session主机,高CPU占用,高内存占用的主机。
* 充分尊重运维人员的意见,抽取试验的目的,最终还是为了通过在有代表性主机的试运行,能提前发现隐患,避免可能的问题。因此抽取何种主机方面,熟悉实际环境的运维人员的意见十分值得参考。
* 架构上冗余,考虑到试运行可能带来的风险,选取主机应尽量选取架构上提供冗余支持的主机,不要在可能出现单点故障的主机上实施。

如果在试验阶段出现大型事故,那么此项目推行的难度将会几何级上升,因此此阶段一定要慎重,同时PM要具有在基层消化小型问题的能力,避免一般性问题因人为因素被放大升级。

总结,此阶段主要是通过沟通,争取一小批具有代表性的主机参加试运行,观察实际运行效果,安全人员对试验情况进行跟踪,对发现的问题进行修正。同时锻炼队伍,准备下一阶段的大规模部署

全面展开

通过前一阶段的工作,基本可以到达如下效果
* 业务部门领导到技术层对于整个加固的稳定性有了初步认可。
* 参与配合的实际运维人员对于操作方法、流程和人员有了熟悉和操作经验。
* 加固项目在加固内容上可能存在的问题和不兼容基本被消化。
* 加固项目组内技术人员得到锻炼,能应付一般突发情况,并对各个部门的业务结构、人员组成结构相当的认识和了解。

此阶段主要矛盾也有对于加固内容的稳定性的担心,逐渐转化为对工程操作方法不了解,以及担心在后续工作中可能碰到未知问题,所造成的不安。

因此该阶段的重点为。
* 同运维部门Leader和骨干共同回顾前期的项目进度和成果。
* 同运维部门骨干和部门领导确认回退方案,认可回退方案的可靠性和可行性。(这点是重中之重。
举例:
  当加固后,运维中出现故障,是否为安全加固导致,往往会带来很多争论和工作量,尤其是如果因为此类故障,导致对加固稳定性的质疑,将直接影响整个工程的进度。如果能够双方认可回退方案,一旦出现问题,运维部门执行回退后,即可迅速定位是否是“加固造成的影响”,便于双方进行排障。
* 同运维部门就项目中的人员分工、操作内容、时间等进行落实,并进行备忘。
* 对新装主机加固纳入装机流程,保证后续上架主机全部闭合为“加固主机”。
* 对相关运维技术人员进行培训,重点在于回退技术的反复演练。并让运维部门领导了解到此技术,在部门内进行强化。
* 向运维技术人员表明态度,并做出行动,加固相关支持的将以持续性的姿态进行,不会在加固完结后终止。
* 组织“实战演练”,通过搭建模拟环境,让一线人员有机会操作实际工具,增加其操作和动手能力。


重点关注
因为此阶段将会完成整个实施过程的95%以上的加固工作,因此在部署时的技巧十分重要,部署实的几个大原则为:
* 阶梯式部署,部署之初应该采取逐步递增的方式,如分5个阶段,在3个月内部署3000台主机,可以采取如下步骤 1% ---9% ---10%---30%---50%。
* 选取角色考虑,在部署时应充分利用业务的冗余特性,尽量避免按照业务角色分类、分组,在一次部署时,选取单一角色的主机进行部署。如图所示(pdf版本:/img/uploadimg/20060810/115725299.pdf),右图的方式,如果部署时出现故障,那么整个业务都将受到影响,对用户提供的服务不得不中断。

  因此不应该以业务系统为单位进行部署,而应该纵向切片进行部署,这样如果出现故障,即便部分节点不可用,但是由于同一角色服务器被分批次部署,提供了冗余,服务提供商依然可以为用户提供持续服务,如左图所示。
* 每完成一个阶段,如50% ,80%应该时时输出加固阶段性报告,对具体实施人员和相关部门Leader进行通告和知会。
* 此阶段应该注意收集加固效果体现的案例,作为阶段性报告输出和结项报告素材。

项目收尾完结
  项目进入到此阶段,大部分主机完成加固,主要矛盾基本消失,主要工作集中在:
* 主要是对剩余主机做好加固收尾工作,不残留未加固主机,如果有特殊情况,需要进行文档备案。
* 整理项目资料,文档 、代码等进行封闭,不再进行改动,保存归档并进行备份。
* 酬谢相关配合Leader和技术人员。
* 发出结项报告,对于整个项目进行回顾,总结案例、加固成效和问题。
* 作为持续性安全工程,提出下一阶段的构想蓝图。

总结
  曾经同朋友开玩笑说,通过此次项目的操作,Coolc也许是加固主机最多的人之一了,当然在实际操作中涉及了更多的是PM的角色,主要是筹划、设计、推动等工作偏多,总结了一些项目操作的经验,从内容上看,此项目也许只能视为中小型项目,但从主机数目看,此项目绝对可以视为大型安全项目,因此 Coolc觉得其中积累的一些经验,应该还是有一定的成色,不妨写出来与大家分享。

  项目中涉及的具体内容、技术细节、代码工具以及数字等数据,因为涉及敏感信息,不方便提供,还请大家原谅。如果大家有什么希望同Coolc讨论的,欢迎同我Email联系,谢谢。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|boway Inc. ( 冀ICP备10011147号 )

GMT+8, 2024-11-1 07:20 , Processed in 0.085872 second(s), 16 queries .

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表