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

2009-12-14 01:16| 发布者: admin| 查看: 13| 评论: 0|原作者: 仙之剑缘

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

2006-8-5
Coolc
Email: eanalysis AT gmail.com
Homepage:blog.xfocus.net/coolc
pdf版本(图)：http://blog.xfocus.net/resserver.php?blogId=16&resource=harden os.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版本：http://blog.xfocus.net/resserver.php?blogId=16&resource=harden os.pdf），右图的方式，如果部署时出现故障，那么整个业务都将受到影响，对用户提供的服务不得不中断。

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

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

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

　　项目中涉及的具体内容、技术细节、代码工具以及数字等数据，因为涉及敏感信息，不方便提供，还请大家原谅。如果大家有什么希望同Coolc讨论的，欢迎同我Email联系，谢谢。

收藏分享邀请

		自动登录	找回密码
密码			注册

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

最新评论

相关分类

下级分类