本文主要是介绍乌云章华鹏：如何构建高效的安全运维服务平台，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
如何构建高效的安全运维服务平台
大家好，我是乌云的章华鹏，今天和大家分享的话题是“高效安全运维服务平台的构建”，包括：企业的数据安全问题，运维安全中面临的网络、系统服务、应用相关配置等问题。
企业安全的核心是数据安全
当我们在讨论如何构建安全运维服务平台之前，我们需要考虑的问题是构建这样一个平台的核心需求是什么？核心需求是帮助企业解决安全风险，避免因为安全风险带来的业务损失。
我们都知道对于一个依赖互联网的企业来说，数据是企业的核心资产，那么归根结底，其实企业安全的核心是数据安全，所以我们首先要明白企业的数据到底在哪里？
业务是数据的载体，IT资产是业务的载体，那么运维的核心对象即是企业的IT资产，由此可见，企业安全运维应该是运维的一项基础要求。
运维安全面临哪些问题？
高效安全运维平台构建的前提—了解企业面临的风险。企业的运维安全主要分为：网络、系统服务、应用相关配置三个方面。
网络安全
主要是网络边界被突破带来的安全风险。对于大多数存在互联网业务的公司来说，服务都会分为内网和外网两块区域，通常这两部分业务是相互隔离的。
一般来说，企业内网主要部署着一些公司内部的敏感系统，这些系统只需要对内部员工开放，与互联网是隔离的。既然存在边界隔离，那么就会存在一些网络边界被穿透的安全隐患。
企业网络边界安全的典型风险主要表现在以下几个方面：包括某台服务器同时部署内网&外网业务、SSRF漏洞、IDC与办公网网络互通、未授权代理配置、IDC服务器被入侵等等。
这里对其中一些比较专业的概念做一个解释，某台服务器同时部署内网&外网业务这个其实就很容易理解了，比如有两个研发公用一台服务器，其中这台服务的内网IP映射到一个内部的业务系统，比如ERP；但同时这台服务器又部署了一个外部的业务，比如企业的官方博客，而这个博客绑定的是外网IP/域名。
SSRF漏洞，说白了就是相当于一个应用层的代理，可以利用这个应用层的代理来对内网任意地址发起请求。
未授权代理配置主要一些类似Squid这样的代理未添加授权控制，导致任何人都可以直接通过这个代理带请求内网资源的问题。
在乌云平台，经常可以看到这样一些案例，一些攻击者可以通过突破边界来漫游企业的内网，从而拿到公司内部的核心信息。
上图是一个关于某互联网公司SSRF的案例，详见乌云http://www.wooyun.org/bugs/wooyun-2016-026212，类似内网漫游的案例在乌云漏洞报告平台上搜索一下有超过400条的记录。
系统服务安全
系统服务相关的安全问题主要体现在系统基础依赖组件及基础服务漏洞两个方面。
典型的系统服务相关安全问题主要包括OpenSSL 心脏滴血、Shellshock BASH远程命令执行、Redis 未授权访问、各种基础服务的弱口令等配置问题。
近些年爆发的一些全球性安全事件包括：心脏滴血、BASH远程命令执行等漏洞，影响范围非常广，这些都是由于系统的基础依赖组件存在安全问题导致的。
上图是一个国内某电商网站的心脏滴血漏洞，乌云主站搜索redis 相关的风险也有将近400 条。
应用配置安全
应用配置安全主要体现在应用上线流程和各种配置不当方面。
在应用上线流程中常见的安全问题，例如上线代码的SVN及Git配置文件目录未删除导致代码信息泄露，数据库及代码的备份文件放在 WEB目录下导致被黑客下载等问题。
通常Webserver的配置也是配置风险的大头问题，这里面不乏由于Webserver配置不当导致任意系统文件遍历，列目录风险等问题。
问题这么多，这么办？
如何构建安全运维服务平台
基础资产管理
企业安全的核心是数据安全，而基础资产是这些核心数据的载体，所以在构建这样一个安全运维服务平台之初，我们首先应该做好基础资产的发现和管理。
基础资产发现，甲方可以从两个角度来考虑，一个是依赖于内部的资产运维管理流程，另外一个是站在外部攻击者的角度来进行资产探测，这样做的话可以有效的进行互补，因为如果仅从内部资产运维管理流程中来对接企业的IP、域名等资产的话对于内部资产管理的要求会很高，而往往企业内部规范落地很难，导致一些资产会遗漏，而外部探测的方式就能够很好的弥补。
外部资产发现的方式主要包括：子域名的暴力枚举，通过一个子域名命名常用字典来挨个遍历子域名；第三方的DNS数据分析获取企业相关的子域名和IP；除此之外还可以通过第三方查询接口、网站爬虫、域传送漏洞的方式获取相关子域名IP的信息。
基础的域名IP资产梳理完毕后，我们需要思考如何把资产管理这件事情做的更加高效。
域名IP是一个比较粗粒度的资产，为了方便应对全球不断变化的安全风险，我们需要做到更加精细化的资产识别，比如每个域名IP上所部署的应用及服务相关信息，一旦这些应用及服务在互联网上暴露出来安全风险，运维服务平台就能第一时间进行响应，这些都依赖于指纹识别技术。
指纹识别方面包括服务指纹识别和应用的指纹识别。
服务指纹识别方面Nmap完全可以满足大家的需求，而且可以方便的进行指纹规则的定制；
应用指纹识别方面我们可以考虑从HTTP协议层面，包括特殊WEB应用的HTTP Headers字段的特征，比如某应用会使用特殊的Cookie值。另外包括特殊应用独有的静态JS/CSS/HTML文件特征。
通过这些特征基本可以识别市面上所有的第三方应用特征。
持续风险监测
在前面的资产管理模块中我们提到资产指纹识别主要分为服务及应用指纹识别两方面，同样在进行风险检测时也是关注服务及应用的风险检测。
服务风险检测主要包括系统基础服务相关的通用漏洞和服务配置不当的风险检测；
应用风险检测主要包括一些第三方应用的通用漏洞和自研的应用风险。第三方应用的通用漏洞通常根据具体漏洞的利用方法来编写具体的检测策略即可，而自研的应用风险如典型的SQL注入，则只能通过尝试不同的攻击测试Payload来判断是否存在漏洞，这通常和具体的漏洞场景有关。
那么如何让风险检测这件事情变得更加高效呢？
我们知道关于风险的检测最重要的就是检测策略，而且互联网相关的技术是在不断变化的，也带来不一样的漏洞风险。这就给企业在覆盖不同风险的检测策略上带来了极大的困难，那么如果我们能够联合安全社区的力量来完善策略就能够完美且高效的解决这个问题，而作为平台方只需要做的一件事情就是提供足够好的引擎框架来方便社区的安全专家为平台提供策略。
同时还需要有良好的机制来运营社区，比如说将风险发现的结果和白帽子编写检测策略的奖励对应起来，这样可以很好的激励白帽子写更多更好的检测策略。
安全事件处理
当企业发现了风险以后接下来需要做的事情就是去进行事件的处理，企业需要建立一个及时有效的处理流程：首先从发现问题开始，接下来是进行风险通告，通告到存在风险的具体业务部门，同时指导业务部门进行风险整改。
这个环节有一个很重要的细节就是，业务部门的研发人员其实是不了解安全的，所以在重视安全问题及修复过程中可能会存在修复不当的情况，所以在通报修复的过程中最好有安全人员进行跟进。
最后修复处理完毕后还要进行及时的回归测试。
当然，除了需要去及时处理一些已知存在的安全风险，还需要有预警全球正在爆发的通用安全事件的能力，比如当年爆发的Struts2漏洞的时候，漏洞爆发的第一时间需要预警到各个可能受影响的业务部门，要求业务部门及时配合自查整改。这样能够更大程度上赢得修复的时间。
关于安全事件处理流程如何更加高效？
核心是需要把安全运维服务平台和业务部门的产品生命周期管理流程打通，最好有API直接对接到产品开发上线的流程中去，安全问题作为产品的严重BUG一样得到及时的排期修复。
同时这个过程中一定要有一个专业的安全人员进行跟踪服务，确保问题不会修复不当，导致问题反复出现。在全球风险预警方面最好对接社区的力量，因为小团队无法跟踪全球最新的安全风险动态。
持续风险管理
由于业务是在持续不断的迭代更新，所以为了保证业务在迭代更新过程中不断的规避风险，需要对业务系统进行周期性的持续监测。
这样能够避免由于迭代更新带来新的安全风险和避免曾经修复的安全问题回滚再次出现。另外一方面可以对持续风险监测的结果进行趋势分析，这样能够帮助我们发现企业当前一段时间主要面临的安全问题，在下一阶段的安全建设上就能够提供有效的指导建议。
关于如何高效的进行持续风险管理，一方面需要能够自主的配置周期性的检测，这样可以适应企业的迭代更新频率；另一方面还需要支持不定时的手动启动检测风险来满足突发的应用上线。
在风险管理方面可以支持定期的报表导出和自定义的导出策略，如此能够更加高效的满足风险运营管理的需求。
以上就是本次分享的所有内容。
这篇关于乌云章华鹏：如何构建高效的安全运维服务平台的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
