您好,欢迎访问专业IT管理知识分享平台

上传文档

当前位置:首页 > 文章列表 > 【雄文】网络安全和系统安全的正确姿势 | 运维安全塔(1)

「ITIL文章」【雄文】网络安全和系统安全的正确姿势 | 运维安全塔(1)

嘉宾介绍

朱磊,(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入数据库,并联员工的账号,然后让员工审计自己的操作过程,同时员工确认之后,升级领导可以再做一次确认。

暂时没有评论,评论一个吧?

您需要登录后才能评论 , 去登录

发表文章

Powered by DS文库

Copyright © 专业IT管理知识分享平台 All Rights Reserved. 鄂ICP备19005274号-1
×
保存成功