【雄文】网络安全和系统安全的正确姿势 | 运维安全塔（1）

本文根据高效运维系列微信群「运维讲坛」的嘉宾分享整理而成。“高效运维”公众号作为本系列群的官方唯一公众号，原创并独家首发。「运维讲坛」邀请国内运维领域优秀技术专家作为分享嘉宾，其中线上分享每周一次，线下沙龙活动每月一次。

欢迎关注“高效运维”公众号，以免费参加「运维讲坛」每月一次的线下交流活动；并抢先赏阅干货满满的各种原创文章（详见文末）。

编辑

• 王玉平@UCloud(文章整理）

• 董伟（ 发布）

嘉宾介绍

朱磊，（James Wharton），现任北京沃顿在线执行总裁，复旦大学外聘主讲（安全软件架构课程）。前京东、完美世界高级安全经理、负责运维安全、业务安全方向，主导运维流程建设、安全系统设计、信息安全体系落地。

主要内容

将运维进行层次划分，从网络到前端防护逐级分解各层次中安全的风险，以及在安全方向应该重心的地方。

本次分享主要集中在网络安全、系统安全和权限管理这三个层次。

引子

如上图，这是比较常见的互联网公司内部网络划分的方式：

• 简单点的会有办公网和生产环境;

• 稍微好一些的，会为研发团队单独划出一个物理隔离的开发环境。

其中，针对办公网的划分比较讲究的是按部门进行VLAN的划分,不同部门之间的VLAN无特别需求是不能相互访问的。

这点针对黑客或内网病毒、ARP攻击的抵御是比较有效的。然而，公司内网只是在心理上让员工觉得大家是在一个独立的网络里，外面接触不到，但正是这种心理以及非技术人员安全意识不够，让公司内网成为了攻击者的首选目标。

试想，市场部门打开一个要求市场合作的邮件是多么正常的行为，HR打开应聘者的简历同样是多么正常的行为。

但市场人员和HR的员工是不具备分辨邮件附件是否是病毒的能力，而攻击者在渗透的初期通常会做信息收集。

通过 百度、GOOGLE、Bing这类搜索引擎公司暴露在外的邮件地址，然后对这些邮件地址按照部门进行简单分类，再针对不同岗位职责为病毒文件编辑不同的文件名称，如发给市场的文档，就叫XXX市场合作方案.docx；给HR的就叫XXX简历.docx等。

当病毒在内网中被执行，黑客就有了一个攻击内网的跳板，此时如果内部的办公网络没有按部门进行划分和ACL的限制，那么攻击者就会借助跳板在内网中进行弱口令扫描，发起ARP欺骗。

再有一类风险是，员工电脑偶尔会收到“X.X.X.X地址正在扫描你的主机”此类主机防御软件的报警提示，当然，只要被防御软件提示出来的，我们都应该比较放心，因为攻击被拦截了，但非技术人员不一定这么想。

而针对内部的防御系统部署，其实是个大工程，防御不是一个系统去解决的事情。好比国家安全的防御部署需要涵盖海陆空，企业也一样，防御包括从网络边界到区域访问、从系统安全到应用系统策略等。

为了方便理解，我将整体的防御做了一个归类分层，这就是我所说的运维安全塔叻。本次分享着重在网络安全和系统安全。

运维塔第一层：网络安全

运维小塔有7层，我们从底层往上解读，首先是第一层网络安全。网络是基础，这就是为什么开始的时候先以内网区域划分以及举例不严格VLAN+ACL的例子开场。

网络层，除了刚才提到的办公区域的划分，同时还要重点针对运维环境、开发测试环境和生产环境通道进行明确。

这里的明确不只是简单地把区域给界定出来，而是要初步定义ACL的主框架。默认的安全策略采用白名单机制，没有特别需求的网络区域之间是不能访问的，有需求单独提出，同时配合流程及制度，然而策略也并非一直留存，而是要定义一个策略的有效周期。不然通行策略开的多了，白名单的区域限制策略就失去意义了。

运维塔第二层：系统安全

系统层，在感知程度上很贴近运维工程师，无论怎么样的维护、变更、升级和上新业务都与这个基础打交道。接下来我们来到第二层——系统安全。

无论是操作系统、数据库还是应用程序，在安全的考虑中，最头疼的其实是版本的不同和交叉的业务。

面对安全人员或一些安全加固文档，都会比较经常能听到的一句话是“最小权限”。

其实，最小权限这句话没有什么错，但这只是一个方向性的引导，并没有什么实质性的价值，我们更多时候也知道为了安全要最小化授权。但是这时候就懵圈了——什么是最小化授权？

这里说的最小化授权，其实是有一个前提——就是对业务的了解程度。

比较常见的情况是，安全工程师对运维工程师说：“你们维护的业务和服务器在跑交叉业务是不安全的，要安全就要最小授权。”运维工程师这时候可能就会骂：“你是SB么。服务器上这么多业务最小个什么毛权限，你小给我看。”

其实，这个时候安全工程师也是比较难办的，因为不知道这服务器上的业务具体提供的是什么业务，也不清楚业务之间的逻辑，所以在不知道业务逻辑或交互细节的时候，安全工程师也不能很有效地给出一个最小权限的建议。

但这并不代表安全无法下手，其最简单的方法就是业务拆分或就死磕了，把交叉业务的逻辑关系摸清楚，针对不同应用启用不同用户、各普通用户之间不能相互访问等限制。

无论是运维安全还是业务安全，都要有一个侧重点，听起来虽然很像个废话，但是这值得作为一句废话不断地被说出来，因为技术人员通常是钻牛角尖的

就爱死磕难点，觉得越难越有价值。

我不去否认或辩解这个观点，只是做为一个提醒，很多时候我们把大把的精力放在这些所谓的技术难点上，而忽略在当前环境中，最常见的问题是什么。

在以前，我觉得弱口令是因为懒的记密码，但弱口令这个事情要分环境看，员工PC的弱密码和运维支撑系统弱密码是两回事。

先说员工PC弱密码的事情。

早些时候我真的觉得是因为员工懒，后来发现原因并非这么简单，当然懒只是其中的一个原因，考勤在各公司都是常见的公司规定，我相信很多同学都有替同事打过卡或者让同事帮自己打卡。其实，这个需求催生了很多人把密码设置成弱密码。

很奇怪吧,为什么会这样?因为大家都有一颗保护自己的心。现在大家都认可密码通这种事情了，一个密码通杀所有个人账户，为了给自己来个保护，办公PC机就来个弱口令吧，反正只要不影响到自己生活就好。

第二个，运维弱口令的。

做运维的各位，你们中存在使用弱口令的吗？

运维团队有两个问题是攻击者比较喜欢的：

• 1.弱口令；

• 2.低版本应用。

弱口令事情可以粗略的归到偷懒这个原因，而低版本的考虑就是稳定的问题了。

关于口令这个问题解决办法已经比较成熟了，有用动态口令的，也有用强制密码策略的。而针操作系统的安全策略，以下给出几个简单的策略；

其实，针对操作系统安全加固的部分都比较传统而简单，简单的东西难点在于落地实施和集中管理，策略只是安全的一小部分。其实运维有一些工具是存在安全问题的，比如常见的rsync，rsync做数据同步的时候需要一个系统账号，而我见过比较帅的运维，rsync的账号直接用root。

在运维过程中，安全的重心应该是流程与制度的落实，像针对操作系统的安全策略和ACL，只是技术的辅助手段，只要能做到集中管理起来，安全策略的落地，这都好办。重点还是流程制度与技术的配合，针对运维人员的权限划分、恶意操作和越权操作等。

第六层：权限管理

因为时间关系，本次跳过第三、四、五层，以后的主题分享会再做阐述。

运维安全的核心是权限管理，或者说是权限分离更容易理解。无论是操作系统、数据库还是应用程序，都应该依据不同的业务场景设置权限。

例：操作系统的权限要分为：

1. 系统管理员（分配给运维团队中较高职位的人）；

2. 维护账号（分配给普通工程师，账号权限主要做业务的运维。针对该账号要限制一些高权限命令的执行限制）：

3. 为不同的应用建立不同的账号用于应用的独立启动；

4. 应用程序的账号要去掉远程登陆权限。

这些策略以核心业务系统为必备，辅助系统或不相关的系统选配。安全也是要考虑成本的。

下面是本次分享的部分互动环节整理。

问题1：运维工作大部分的安全问题，是不是在网络层面根据安全级别进行逻辑分区，效果事半功倍？

答：无论是网络层、系统层还是业务层，安全的策略都需要一个场景，就是指业务的重要程度，所以在定义安全策略之前首先要明确的是，你所要保护的系统或数据，其重要程度是多少。

问题2：账号如何统一管理，授权和审计?

答：账号统一管理有多种方案，有Windows域、基于kerberos以及LDAP或两者结合的。授权和审计可以使用现成的堡垒机这种现成的产品。或者就自己开发一套审计系统，在网络中建一个LOG SERVER，然后LOG入数据库，并联员工的账号，然后让员工审计自己的操作过程，同时员工确认之后，升级领导可以再做一次确认。

如何一起愉快地发展

高效运维系列微信群是国内高端运维圈子、运维行业垂直社交的典范。现有会员800余名，其中运维总监及以上级别会员300多名。

“高效运维”公众号值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上/线下活动精彩分享及部分群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。

提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请；或申请加入我们技术交流群（技术讨论为主，没有主群那么多规矩，更热闹）。

重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。

题图来自：网络；作者：佚名。