转载

企业安全体系建设方案设计（内附案例）

今天讲一讲安全体系建设方案，对于企业来说，安全体系一直是比较关心的话题，无论大企业还是小企业都对于如何建设安全体系以及什么是安全，存在一定的疑问，这篇文章就从基础组成的角度来讨论一下安全架构的建设。

安全架构包括哪些方面？

物理方面

比如机房的安全，物理服务器的安全，硬盘的安全。有人可能会问，我的服务器是放在云上的，存在物理方面的安全吗？当然，对于企业而已，云端的物理安全是不需要过于担心的，因为云提供方会对他们的云机房做物理安全监控，但其实有很多信息在初期也是需要考察的，比如云机房的监控，云机房的人员访问审查，云机房的高可用，云服务器的使用时长等等。

举个例子

在这里举个例子，我们的服务器使用时间大概已经有5年时间，主板电池有些问题，服务器一旦重启就会刷新时区，比正常的业务时间慢8个小时，HTTPS校验时间时就出了问题，导致业务进不来。Crontab的执行时间同步一旦没有达到秒级就会存在这个问题，但是正常谁会把时间同步定义到秒级呢？这个问题直接导致了业务的瘫痪，所以在选择云供应商的时候一定要询问他们的宿主机使用时长。

云物理监控需要看什么？

比如需要监控进出机房的人员，早些时候会有一些编外人员以云提供商的身份进入云机房进行数据窃取，这方面国外最严重，国内经过管控已经好很多，但是物理监控依旧不能掉以轻心。

数据方面数据安全，比如存放的数据加密，必要时需要脱敏处理，加密尽量采用双层加密，这里分享一下我的做法：

原始数据的脱敏处理（由于是互联网金融行业，会存在个人信息的传输，存储中如非必要，这类信息是不允许存储的，需要脱敏，比如银行卡号保留前4后4位等作为支付依据，核对时核对关键信息）。

第一层采用3DES加密算法，把数据进行加密；

第二层采用RSA强加密算法（2048位）加密3DES的密钥；

最终密钥存放于加解密系统中，此系统会对存放的密钥做乱序处理，只有相关权限的人申请，拿到乱序的密钥，通过CEO或CTO授权，由密钥负责人做恢复处理，才能拿到密钥。

这块虽然流程会很麻烦，但是能够最大程度的保障数据的安全。

应用方面其实应用安全是攻击者们最喜欢攻击的方面，也是最容易被攻击的方面，如何做好应用安全，决定了黑客们能否攻进或者攻进的难易程度。下面从几个方面来讨论我对于应用安全的处理办法：

1谁首先其实看到这个小标题，相信有很多人是懵的，简单讲述一个小例子好了，我用Jenkins举例，Jenkins是开源的自动化项目部署平台，一般项目做发布的时候使用的，与Apollo不一样，具体差异我并没有研究，但是为了结合项目架构，两套自动化部署平台我都有搭建，Apollo更多体现在微服务化，Jenkins更多是使用项目发布。

Jenkins在刚刚安装好的时候会设置访问矩阵，就是说授权什么人做什么事情，比如运维授权做项目发布，脚本执行，审计授权做日志查看等等，这个时候其实有几种不正常的行为：

（1）未授权访问未授权访问是指没有被授权的用户可以访问到系统中，并拥有授权用户的权限。还是以Jenkins举例，早期的Jenkins初始化后是没有访问矩阵配置的，造成很多使用者不了解，同时也不知道未授权访问的危害，在公网上暴露的Jenkins数不胜数，或许使用者自己都没有发现，登录Jenkins，空用户名、空密码是可以登录的，这在访问矩阵中是everyone的身份，可怕在于everyone默认是有所有权限的，直接导致任何人只要发现Jenkins未授权访问，就可以进入到Jenkins中并且执行shell命令，这在Jenkins中是客观存在的，放下截图。

同样存在未授权访问这个问题的还有很多，比如zeppelin、redis、zookeeper、elasticsearch、docker、hadoop等等。

这里我的建议是做好“谁”的把控，控制好所有的应用访问权限，什么人访问什么系统，拥有什么权限，当然这里人的判断依据最好是双因素判断。

并且应用系统最好是放在内网并做访问控制，即使爆出0day也不会第一时间被扫到利用。公网上开放的应用越少，相对黑客的攻击层面就越少，攻击难度也就越大。

（2）越权访问越权访问是指合法用户，指定A权限，但却可以做B权限能做的事情。在这里还是以Jenkins为例：

在这里直接贴个漏洞编号，有兴趣的可以查一下，这个漏洞虽然官方说是严重级别，但是我给他评级只能评中危，因此没有详细贴出来。

因为此漏洞是需要Jenkins重启，然而一般这种放在生产环境的运维工具是极少有重启的机会的，除非配合DoS攻击或者等待机房故障等不可逆因素。

漏洞整体描述是攻击者可利用CVE-2018-1999001漏洞从Jenkins主目录下移除 config.xml 配置文件到其他目录，当Jenkins服务再次重启时，因加载不了config.xml中配置的安全域和授权策略，退回 legacy 模式，并且赋予匿名用户管理员访问权限。

当攻击者获取Jenkins权限后，可查看构建历史数据，甚至可下载工作区的代码，导致核心代码泄露。

攻击者在进入管理页面后，可通过“系统管理”下的“脚本命令行”功能，执行用于管理或故障探测或诊断的任意脚本命令，对Jenkins系统服务器产生比较严重的影响和危害。

实际上是就是越权访问改动了config.xml文件，之后通过未授权访问入侵服务器。

越权访问一般是由于权限管控不当而发生的，我的建议是在权限规划时，执行最小权限管控，分的稍微细致一些，并且认证一定要做好，每一个都需要认证机制，这样能够最大程度降低越权访问发生的可能。

（3）绕过认证访问早期比较流行，比如在认证页面，正常输入用户名密码，通过sql注入的方式使sql语句成为真值的计算，便可以跳过认证，进入系统中。

目前也有不少CMS系统存在绕过认证访问。或通过撞库的方式也算是绕过认证。

之前Akamai有个统计，从2017年11月初到2018年6月末，Akamai的研究分析结果显示，恶意登录尝试在8个月内超过300亿次。

全球恶意登录的次数在不断增加，情况不容乐观。面对如此严重的暴力撞库攻击，有什么好办法可以避免吗？

其实很多人会想到双因素登录，但是同样有很多人分不清双因素登录与双因子登录的区别。

双因素登录是指在登录时同时验证传统密码与第二因素认证，而双因子登录是指先认证传统密码，成功后再认证第二因素。

这两者区别就在于双因素无法判断密码是否是正确，而双因子即使有第二因素，还可以爆破出密码，然后通过此密码进行撞库。

在这里有个假设，一旦企业邮箱的密码与爆破出的密码是同一个，那么企业信息泄露，甚至是专业的社工钓鱼便会如梦魇一般围绕着你，围绕着企业。

在这里建议是使用双因素登录认证来规避绕过认证访问的问题。

2做什么

通过行为判断是否异常。一般来说，正常用户不会执行异常请求。还是用Jenkins举个例子：正常用户，比如运维，执行脚本一般会执行项目替换代码，比如编译jar包，比如替换等等；入侵者在拿到命令执行权限的时候第一时间使用的命令一般是身份类型命令，比如whoami、w、last等等；然而这些信息一般Jenkins正常操作都是用不到的，需要做管控。当然Jenkins本身权限要执行权限最小化，那也当然不可能是root，在执行时也同样会增大入侵难度。

3怎么做

这一点要考虑黑客可能通过什么手段入侵应用，最常见的OWASP TOP10中的SQL注入、XSS、XXE、恶意文件上传、CSRF、SSRF等等，基于这些攻击手段建议采用WAF来阻断恶意攻击，具体后续会分享开源WAF体系的建设，包括WAF本身与日志审计、告警工作，感兴趣可留言讨论，欢迎关注。

主机层面主机安全是相对于以上所有安全中最难把控的，包括服务器安全和终端安全。技术层面的安全相对来说比较好把控，包括服务器终端的基线安全、杀软、访问控制等等，但是最不好把控的其实是人为的因素。

案例一大把，随便举例子，员工私设WiFi设置弱口令导致黑客连接到企业内网，进行内网入侵；员工浏览恶意网站导致终端植入感染病毒，传播扩散到企业内网。

这种事情还有很多，凭借管理制度并不足以防止此类事件的发生，那么主机安全应当如何做？在这里分享我的治理方法：

首先服务器使用ansible推送安装ClamAV，定期进行查杀，这里可以使用crontab进行定时任务，并将结果反馈，反馈可以通过filebeat传递到日志分析中去做，告警也在日志分析中规范告警条件。

终端以360为例，统一管控，360有服务端和客户端，在服务器设置统一管控密码，客户端分发安装到各终端，终端便会定时杀毒，而且不能被关闭。

定期开展企业培训，提高所有人的安全防范意识，在路由器上设置访问控制，禁止访问有害网站（利用爬虫做黑名单访问控制）。

网络层面网络层面重点体现在防火墙管控DMZ区的流量进出，管控跨网之间的访问哪些属于合规哪些不合规。

举个例子，假如说我的某一个业务放在阿里云，监控体系与主体业务在腾讯云，由于成本问题我不想在阿里云单独建立一套监控体系，只想延用腾讯云的监控体系，但又要保证业务之间的隔离，那么这时候就要在云两端架设VPN，并且设置仅允许监控系统与业务之间互相访问。

但是要保证VPN的稳定性，在目前国内的形式来说应该是挺难的，尤其前段时间的护网行动，VPN基本每天都断上几次。

多链路可靠访问是针对网络堵塞、大环境网络故障、意外攻击等情况设计的业务可用性的体现。