引子
如上图，这是比较常见的互联网公司内部网络划分的方式：
简单点的会有办公网和生产环境;
稍微好一些的，会为研发团队单独划出一个物理隔离的开发环境。
其中，针对办公网的划分比较讲究的是按部门进行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：账号如何统一管理，授权和审计?
答：账号统一管理有多种方案，有Windows域、基于kerberos以及LDAP或两者结合的。授权和审计可以使用现成的堡垒机这种现成的产品。或者就自己开发一套审计系统，在网络中建一个LOG SERVER，然后LOG入数据库，并联员工的账号，然后让员工审计自己的操作过程，同时员工确认之后，升级领导可以再做一次确认。
热门专题
