随着IT技术和业务的发展，以及各式各样安全漏洞的涌现，运维与安全这两个专业日渐交融，人们对运维安全的重视程度越来越高，出现了一个新的交叉领域叫“运维安全”。黑客、白帽子忙于挖掘运维安全漏洞，企业忙于构建运维安全体系，一时间无数漏洞纷至沓来，座座堡垒拔地而起。作者立足自身多年运维安全实践，也来探讨一二。本文按照提出问题到回应答案的思路，先抛出作者对运维安全的理解，并解释了重视运维安全的原因。接着根据在运维安全一线发现的工作陋习以及企业面临的常见问题，整理出通用运维安全问题分类。之后对症下药，提出一个好的运维安全形态：不仅在于工程师们的安全意识，更在于一套相对完整的运维安全体系，从流程到技术，点线面多位一体共同缔造。
什么是运维安全？
我们先看一张维恩图，现实中的业务、运维、安全的关系是互相关联、彼此依赖的。从这张图中，衍生出三个不同与安全相关的子专业：“运维+安全”，“安全+运维”，“业务+运维+安全”。在互联网公司招聘岗位里，我们经常看到的是运维安全工程师、安全运维工程师，这两个岗位比较好对号入座。而“业务+运维+安全”，通常被包含在安全工程师的岗位中，近年出现的应用运维安全工程师，相比之下更符合“业务+运维+安全”的定位。
运维安全 = 运维 + 安全
运维安全研究的是与运维相关的安全问题的发现、分析与阻断：比如操作系统或应用版本漏洞、访问控制漏洞、DDoS攻击等。显然，运维安全立足于运维，从企业架构上讲通常属于运维部门或者基础架构部门，运维安全工程师的专业序列一般属于运维工程师。
安全运维 = 安全 + 运维
安全运维研究的是安全系统或者设备的运维：比如防火墙、漏洞扫描器维护，漏洞挖掘与应急响应等。这个也很明显，安全运维属于安全部门旗下，安全运维工程师的专业序列也属于安全工程师。
应用运维安全 = 业务 + 运维 + 安全
应用运维安全研究的是业务上的运维与安全，主要包括安全风险评估与安全方案规划设计及其落地。组织架构上该岗位有属于安全部门的，也有属于业务部门的，对应的专业序列有属于安全工程师的，也有属于开发工程师。
通过对比“运维+安全”，“安全+运维”，“业务+运维+安全”三个子专业的不同，我们明确了运维安全的研究领域和岗位职责。看到这里，可能大家会有疑问，是什么导致运维安全现在这么“风光”？
为什么我们重视运维安全？
可以说，2013年-2014年是运维安全发展的一个分水岭。这两年特别之处在于作为互联网基础设施的几大应用相继被爆漏洞或被攻击，例如Struts2远程代码执行漏洞、Openssl心脏滴血、Bash破壳漏洞，以及当时“史上规模最大的DDoS攻击”导致大量.cn和.com.cn域名无法解析。在这之后，企业对运维安全投入迅速加大，各种运维安全问题也引起广泛关注。直到今天，运维安全已经成为企业安全建设的重中之重。
漏洞百出的软件供应链
struts2远程代码执行漏洞
当年S2漏洞一出，整个互联网一片哀嚎。下面是受影响的企业，几乎没有不认识的吧。
openssl心脏滴血
跟S2漏洞一样，杀伤力极强。
xcode开发的ios app感染木马
研究者发现AppStore上的TOP5000应用有76款被感染。后来发现罪魁祸首是开发人员从非苹果官方渠道下载xcode开发环境。
运维安全漏洞占比明显
自从某云离去以后，不得不说国内互联网安全态势的共享逐步走向了封闭，也借此机缘涌现了很多商业公司。即便是现在留下的某天某法某眼，能查询到的统计分析数据其实也很有限。即便是某旦，其用户体验也不够好，统计分析功能无法差强人意。剩下的，各种研究报告也从来没有把运维安全问题列入单独的统计范畴，所以这里借用2016年CNVD的统计，可以发现明显属于运维安全问题的网络设备漏洞和操作系统漏洞，占比已超过20%，加上应用程序漏洞中包括的各种应用版本漏洞，相信归属于运维安全领域的漏洞比例将极其可观。
运维安全漏洞利用性价比高
针对运维安全漏洞的攻击属于典型的“一两拨千金”，其ROI非常高：投入小、容易发现与利用、造成危害特别大。
根据微软的DREAD模型来衡量运维安全漏洞风险如下：
等级 高（3） 中（2） 低（1）
Damage Potential 获取完整验证权限；执行管理员操作；非法上传文件 泄露敏感信息 泄露其他信息
Reproducibility 攻击者可以随意再次攻击
Exploitability 初学者在短期内能掌握攻击方法
Affected users 所有用户，默认配置，关键用户 部分用户，非默认配置 极少数用户，匿名用户
Discoverability 漏洞很显眼，攻击条件很容易获得
常见运维安全陋习
运维安全事件频发，一方面固然是因为运维或安全规范空白或者没有落地，另一方面也在于运维人员缺乏强烈的运维安全意识，在日常工作中存在这样那样的安全陋习导致。可以对号入座，仔细想想曾几何时自己是否也踩过同样的坑？
修改iptables后没有还原配置，甚至清空关闭iptables
出于测试需要临时清空iptables可以理解，但是很多人会忘记还原，也没有设置自动还原机制
iptables -F
脚本没有检查“*”、空格、变量
如果我们认可“不光用户的输入是不可信的，自己的输入也是不可信”，这样的坑就会少踩。
rm -rf /var1/var2
服务启动默认监听全部地址
绝大部分应用默认配置便是如此，在没有有效访问控制的清空下开启监听所有地址，离危险也不远了。
bind-address 0.0.0.0
给文件开放过大的权限时，任何人都能读写
这个跟phpinfo有点像，能给入侵者推一把。
chmod 777 dir||chmod666script
用root启动服务
对于大多数运维人员而言，一上机器就切到root，后面用root启动服务仿佛一气呵成。
#nohup ./server &
嫌麻烦不配认证，也不配访问控制
这个跟监听任意地址比较像，通常也是默认配置使然，使用者也没有意识去加固。
#requirepass test
单机安装docker之后忽略检查iptables，导致docker修改iptables开放外网
docker技术给我们带来的便利自不必言，但是因为docker带来的安全风险却一点也不少。而且，docker daemon默认是能控制宿主iptables的，如果docker daemon使用tcp socket或者启动的容器可被外部访问，则连宿主一同 沦陷也不在话下。比如下面一启动容器则将tcp/443端口对外开放了。
docker restart
*nat
:PREROUTING ACCEPT [8435539:534512144]
:INPUT ACCEPT [1599326:97042024]
:OUTPUT ACCEPT [4783949:343318408]
:POSTROUTING ACCEPT [4783949:343318408]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.17.0.1/32 -d 172.17.0.1/32 -p tcp -m tcp --dport 443 -j MASQUERADE
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.23.0.3/32 ! -i br-1bf61a2fa2e7 -o br-1bf61a2fa2e7 -p tcp -m tcp --dport 443 -j ACCEPT
*filter
:INPUT ACCEPT [1599326:97042024]
:OUTPUT ACCEPT [4783949:343318408]
-A INPUT -s 10.0.0.0/8 -j ACCEPT
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -j DROP
#最后的规则被绕过
sudo授权过大，导致自定义脚本提权
如果攻击者可修改脚本内容则提权易如反掌。
sudo script.sh
给开发或者QA授权root权限，他搞事你背锅？
一直以来我们强调RBAC，但是运维太忙，开发测试人员需求太多时，很多运维人员会直接授权他们root权限，而他们对系统级访问控制不甚了了，因此造成的漏洞非常可观。
dev@pro-app-01:/home/dev$su
root@pro-app-01:/home/dev#whoami
root
key/token/ssh私钥保存在txt文件里，也有把个人ssh私钥放在服务器的
op@pro-app-01:/home/op$ls ~/.ssh
id_rsa id_rsa.pub
把工作上的代码对外发布
连着遇到实习生把项目代码提交github了，回复的理由是git配错了。虽然不知真假，但我认为，至少他们是安全意识不足。
git remote add origin https://github.com/secondwatchCH/EFS.git
git push origin master
个人home目录那么敏感，也有人拿来直接托管服务，至少.bash_history泄露是跑不了
dev@pro-app-01:/home/dev$python -m HTTPSimpleServer
应用选型时没有考虑安全风险
Apache Struts Version：Struts 2.5 - Struts 2.5.12 #线上业务使用受S2-052影响的S2版本
对软件供应链安全没有概念
从xcode事件到pip官方发现恶意ssh库，都在向我们昭示一个道理：软件供应链安全风险极大。目前比较运维人员中比较常见问题有：
ssh客户端或者开发IDE从百度网盘下载
两眼一闭，把github/pypi/dockerhub等网站下载的应用/库/镜像直接用到生产环境
未清理默认口令或者默认配置
常见运维安全问题
前面我们谈到了运维操作上、思路上的一些陋习，或者安全意识不足的问题，下面结合漏洞分析和响应过的情况来看，常见的运维安全问题主要可分为下面几种：
敏感端口对外开放
db或者cache属于敏感应用，通常部署在内网，但是如果部署的机器有内外网ip，且默认监听地址为0.0.0.0的话，则敏感端口会对外开放。如mysql/mongodb/redis/rsync/docker daemon api等端口对外开放。
敏感应用无认证、空口令或者弱口令
同上，如果敏感应用使用默认配置，则不会开启认证，mysql/mongodb/redis/rsync/supervisord rpc/memcache等应用无认证。有时贪图测试方便，配置了弱口令或空口令，则认证形同虚设。
敏感信息泄露，如代码备份、版本跟踪信息、认证信息泄露
web.tar.gz/backup.bak/.svn/.git/config.inc.php/test.sql等信息泄露随处可见，人人知道危险，但是始终时不时会有人会踩坑。
应用默认配置未清除
jenkins script/apache server-status等默认功能未清理，例如下图可直接执行命令
应用系统打开debug模式
Django debug模式开启暴露uri路径，phpinfo()暴露服务器信息甚至webroot等，之后攻击者便可借此进一步渗透，很多白帽子应当有此同感，发现了sql注入但是写不了webshell，如果能遇上个phpinfo()那是再好不过的事情了。
应用漏洞未及时升级
越是通用的应用，就越经常爆出漏洞。有句话说的好：不是因为黑客这个世界才不安全，而是因为不安全才会有了黑客，才会有黑客去揭开那层假象，让我们发现有那么多不安全。于是Struts2、OpenSSL、Apache、Nginx、Flash等等CVE接踵而来。
权限管理松散
不遵循最小权限原则，给开发提供root权限或者给业务账号授权admin权限。
DDoS攻击
DDoS攻击对于运维人员而言，是再熟悉不过的安全问题了。我们都知道通过占满带宽、耗尽资源等方式可让服务器无法响应正常请求，说到底是资源对抗的一种攻击方式。如果仅依赖服务器资源去抗，去过滤，如下图，在大流量、高并发之下，只会引来雪崩。加上DDoS攻击平台大量存在，而且价格低廉，这就让DDoS攻击成为打压竞争对手、报复、勒索等阴谋诡计者首选方式了。
流量劫持
还记得2015年小米、腾讯、微博、今日头条等六家共公司联合发表声明呼吁电信运营商打击流量劫持的报告吗？即便如此，现如今的互联网江湖仍是暗流滚滚。下面介绍三种常见的流量劫持方式，这也是困扰运维安全人员多年的痼疾。
arp劫持：ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的进行。基于ARP协议的这一工作特性，黑客向对方计算机不断发送有欺诈性质的ARP数据包，假冒目标IP进行ARP响应，从而实现中间人攻击。
域名劫持：通过劫持掉域名的DNS解析结果，将HTTP请求劫持到特定IP上，使得客户端和攻击者的服务器建立TCP连接，而非和目标服务器直接连接。
HTTP劫持/直接流量修改：在数据通路上对页面进行固定的内容插入，比如广告弹窗等。
案例
前面我们讨论了很多运维安全陋习和问题分类，下面要讲的，则是大家再熟悉不过的几个案例，且看运维安全漏洞如何“性价比”极高。
svn
部署web代码时误将.svn目录上传
使用rsync上传代码时没有exclude掉 .svn目录，svn仓库也没有使用svn propedit svn:ignore <目录或文件>的方式ignore掉不应当上传的文件或目录。
攻击者利用svn信息泄露利用工具Svn-Tool或者svn-extractor还原代码
rsync
rsync使用root用户启动，模块没有配置认证，还对外开放默认端口873
攻击者利用rsync写crontab任务成功反弹shell，并种上了挖矿木马
redis
redis使用root用户启动，没有配置认证，还对外开放默认端口6379
攻击者利用redis写ssh公钥到root用户的.ssh目录成功登上机器
一般部署redis的机器都有内网ip，攻击者可借此进行内网漫游了
kubernetes
k8s的api对外开放，同时未开启认证
攻击者调用api创建容器，将容器文件系统根目录挂载在宿主根目录， 攻击者利用写crontab任务成功反弹shell，并在宿主种上了挖矿木马
有时候容器里跑着未编译的代码或者在沦陷的机器上可以拉到私有docker镜像仓库的任意镜像，后果将难以想象，如下面k8s的api，调用起来则非常简单。
那么，如何做好运维安全？中医有句话叫对症下药。我们花大篇幅去剖析问题所在，想必也是从问题入手，通过纠正或者培养良好的运维安全习惯，结合完整的运维安全技术体系，才是问题的出路。
培养良好的运维安全习惯
端口开放
默认监听内网或者本地
如需监听全部外网，iptables、password和acl能加都加上
iptables
在cmdb为机器或者服务设计好iptables规则，同时结合同步机制：
部署服务时使用cmdb生成的iptables同意更新
测试时一旦清空iptables后使用自动或者手工方式刷回标准iptables
权限管理
采用puppet、ansible或者saltstack等集群管理工具统一管理操作系统权限
遇到临时需要高级权限时手工后添加定时回收，量大时采用自动化方式配置
脚本安全
校验变量，特别是高危操作
原则上不给脚本授权sudo密码或者授予666的权限位
密钥管理
不要让ssh私钥离开你的办公电脑
听IT的话，定期修改你的corp或者域密码
配置与代码分离的一个理由是：账号密码不能写在代码里
服务管理
能不用root启动最好不要用root
不要把服务根目录放到你的home目录
代码管理
跟工作相关的代码禁止上传github！！！
仔细学习git/svn等版本管理工具的使用姿势
定义好你的.gitignore，特别是删除你的.DS_Store
应用选型
安全性是应用选型的一个重要考虑点
对漏洞修复和安全编码不怎么积极的开源软件，再好用都不要用
关注应用安全配置文档
一般应用程序的官方说明文档会包含安全配置的章节，在部署时需要循序渐进，按照最佳实践配置安全部分，而不是嫌麻烦直接跳过。
企业级运维安全体系
安全体系，是一套很大的概念。从流程规范，到技术架构，不是本文所能解释清楚。因此，下面所探讨的企业级运维安全体系，会把我接触到的或者已经落地的方案大体介绍一下，涉及到其中的具体落地，则待以后再撰文详细讨论。
首先，整套运维安全体系，其实属于企业安全体系的一部分，所以大体上思路不会相差太多。其次，运维安全，更关注的是“运维”，所以像业务风控、反欺诈、app反编译则不在考虑范围之内。下面让我们一同看下一套完整的企业级运维安全体系长什么样。
流程规范
运维规范如同人间法律，“人生而自由,却无往不在枷锁之中”。这套规范，不仅是约束、指引运维人员，也是约束、指引开发测试人员，以及围绕生产活动的所有参与者。
培训
此处的培训不是安全部门做的员工安全意识培训所能替代，也不适合针对开发测试人员举办的研发安全培训，而是只面向运维人员的意识与技术培训。就比如本文前面的安全陋习和安全习惯，就可作为意识培训的蓝本。而后面所讲的技术体系，则可作为技术培训的基础。这类培训可以放在校招培训课程里，也可以放在部门沙龙讲座里讲。
审批+审核+评估
首先，审核或者审批，不是为了阻碍业务发展，更不是为了没事找事，而是希望通过流程去减少或者避免人的因素导致忽略安全。所以权限申请要上级审批、功能开放要安全人员或者同组同事审核、功能上线要安全人员评估测试。当然，实现的方式可以灵活多样，比如默认通过，可以根据产品或者业务需要开启审批、审核机制，然后把评估机制放在业务上线流程中，只有通过评估才能上线。在安全部门比较强势或者相对重视安全的企业，相信以上机制都落实的比较到位。
安全报表
安全可视化、数据化非常重要，是体现安全价值的形式之一，因此通过与企业SRC或者安全部的对接，可以获取运维相关的漏洞、安全事件统计数据，然后根据内部需求进行二次处理，然后通过定期报表的形式发给运维人员或者部门领导甚至技术负责人查看，一方面让他们了解运维安全态势，这种通常能看到安全不足，从而让大家从数据得到警示，或者获得上级关注，从而为获得更多的资源或者实现自上而下推动安全规范落地走向可能。
流程规范的落地包括但不限于以上几点，但我觉得这几点是最重要的。
技术体系
访问控制
安全域划分下的网络隔离
网络层：192.168分为办公区、办公服务区与开发机网，部分隔离；10.x分为IDC物理内网、IDC虚拟内网与公有云虚拟内网，通过IGP互通，可申请端口映射外网；公网IP仅用于业务外网，开发测试环境禁止使用公网环境！
系统层：装机镜像默认开启防火墙，仅开放ssh、rdp管理端口。ssh一律采用公钥登陆，禁止启用密码认证；按角色授权系统权限。
应用层：数据库、缓存类应用部署在内网IP，管理接口禁止对外开放，按最小权限原则授权
统一出入口级访问控制
建设IDC级别统一入口，结合NAT网关实现出入向访问控制。
目前BATJ都有自己的企业级GW作为统一应用层入口，同时使用NAT网关走出向流量。GW的实现开源方式不少，一旦作为企业级GW仍需自研。而NAT网关，则可采购具备API功能的分布式硬件防火墙或者自研NAT网关，解决IDC内网出向流量RS直接回外网时无外网IP的问题，或者服务器直接对外发起请求的情况，然后再采用统一系统管理。目前业界多有分享，相关思路不难找到。
敏感端口访问控制
一旦有了统一的出入口，整个生产网就像办公网一样，可以对外屏蔽敏感端口访问，对内限制出向流量，在风险缓解和攻击阻断上行之有效。
应用层访问控制
通过WAF防刷、限流是一种通用方案，如果没有WAF的可以应用的acl自行进行控制，比如nginx的limit_rate或者haproxy的acl。
堡垒机与VPN
使用堡垒机可实现运维入口统一化，也能做到集中访问控制和审计。
在登陆堡垒机时也需要拨入VPN，目前应用比较广泛的有IPSecVPN以及SSLVPN，像openvpn则部署维护简单、服务端较为灵活以及客户端支持丰富等优势目前被广泛应用。
服务器ssh端口或者业务管理后台也可只对堡垒机与VPN Server开放白名单
基线审计与入侵检测
我认为基线审计与入侵检测是两个不同的概念，前者在于事后审计，看合不合格，后者在于事前预防与事中检测响应。在具体落地上，基线审计通常依赖堡垒机，入侵检测通常依赖安全agent。
堡垒机
通常堡垒机有访问控制、日志审计、操作行为审计、数据上传下载审计以及权限管理等功能。但是，系统补丁更新与应用版本更新等操作，则不是堡垒机所能覆盖。
对于堡垒机的落地，采购设备倒是其次，重点在于整合整套运维体系，对于有些年头的企业改造成本太大，而且大家也担心其性能与可用性。
安全agent
当然，前面说到的系统补丁更新与应用版本更新，都可以交给安全agent去做。入侵检测、基线审计，安全agent可全面覆盖。但因为要跑agent，通常没有愿意商用入侵检测系统跑在自己机器上的，如果自研则开发周期长，还会引起业务的担忧：服务器监控agent、数据上传agent等等之外还要再跑安全agent，万一agent崩了会不会引起雪崩？说到底，要取得产品的信任，还得自家底子够硬。
那么，什么样的解决方案才能众口皆调呢？在google提出beyondcorp之后，问题可能有了转机，那就是把使用轻量agent采集信息，把计算、分析、决策交给大数据后台。当然，我们很难像google那样基于rpc协议去做访问控制、身份认证，那么在传统的堡垒机、vpn方案之上，结合轻量级agent，可能是一种更好的方式。当然，还是上面那句话，如果自家底子够硬，能取得大家信任，那就另当别论。
漏洞扫描
目前大中型企业谁没有自己的漏洞扫描器，不会开发购买商用的总行吧？但我觉得可能有个通病，就是漏洞扫描器做的太重。如果可以解放思路，或许可以尝试从扫描器的定位重新出发，在效率、覆盖面上进行选择，比如大型扫描器专门做周期长的、要求覆盖面广的扫描，而轻量级扫描器则定位于高效、定向扫描。现在不光是waf在结合机器学习，漏洞扫描器也可以结合机器学习或者大数据分析，根据扫描日志或者已有的经验，做策略的自动生成，实现扫描规则的轻量化与精准化。
CI/CD安全
CI/CD是运维的重要一环。在CI/CD上出现的安全漏洞也多如牛毛。下面我们从如何安全的发布和应用部署来讨论。
敏感信息泄露
我们都知道发布代码应排除：源码文件和临时文件，如.py、.cc、*.swp(vim临时文件)，上传版本管理相关的信息文件(如.svn/.git)，以及打包/备份文件（如.gz/.bak)。这看起来更像是一种规范，其实不然，通过在代码分发系统增加钩子或者过滤模块，是可以提前发现敏感信息的上传的。比如代码提交了ssh私钥或者账号密码配置文件，只需要一个webhook就能检测到。实现上的成本与出问题付出的代价相比，其实不算什么。
代码或镜像的安全审计
随着docker容器技术的广泛应用，CI/CD安全的落地更加充满希望。我们都知道，使用docker容器需要经历编写dockerfile/docker-compose文件，docker build之后才有镜像，然后再docker pull、docker run部署服务，实际上可以结合jenkins等CI/CD工具调CoreOS官方的Clair镜像安全审计工具进行漏洞扫描。此外，当然还有RASP等Runtime机制的动态检测机制，也有foritity或者Cobra等或商用或开源的代码审计工具，也可以结合使用。
认证授权
认证授权机制这块，主要分享的思路如下：
SSH不允许用密码登陆，必须用公钥登陆
建立个人帐号的概念，必须做到一人一个帐号，不允许多个人共用一个个人帐号
公共帐号要和个人帐号分开，不允许直接登陆
口令安全需要注意复杂度校验
无法通过网络层或应用层进行访问控制的，应增加认证授权机制
RBAC：根据角色授权
最小权限原则：禁止给业务配置root/admin级别的数据库账号，根据业务需求授权相应权限。
白名单机制：同时限制root/admin级别的数据库账号仅能通过白名单ip访问。如存在默认账号密码应同时删除。
认证信息管理：说到docker容器这块，目前kubernetes提供了ConfigMap，可以用于传递认证配置路径或者其他间接变量，用于计算认证信息。也可以用Hashicorp Vault进行认证信息管理
DDoS防御
DDoS防御按照网络架构，可分为云清洗或者IDC清洗两种模式，前者通过DNS或者反代将目标IP替换成云的VIP的方式引流，对应的防御流程分为：流量分析->流量采集->流量压制等几个步骤。后者通过路由牵引模式引流，对应的防御流程分为：流量采集->流量分析->流量牵引->流量压制等几个步骤。下面从流量采集、流量分析、流量牵引和攻击阻断与过滤简单介绍一下。
流量采集
云清洗
DNS：通常是web服务，使用域名对外提供服务，只需要将dns A记录指向高防或者清洗VIP，或者dns cname到云清洗域名即可。
反向代理：配置反代，通常用于那些拿IP直接对外提供服务的，比如游戏。
IDC清洗
流量镜像/流量分光：这种方式要求IDC机房部署清洗或者高防集群，通过在网络设备上镜像流量或者分光拿去做异常流量检测。
流量分析
数据包捕获和抓取、数据包分析、会话还原和重组：实际生产环境中建议用nDPI+PF_RING实现，当然，Intel DPDK技术也很成熟了，后者目前也越来越流行。
应用层协议分析：据了解有公司使用Bro解析流量，测试结果显示峰值几十Gbps性能也还扛得住。当然，Bro也可以用PF_RING配合性能加速，也有插件可吐给kafka分析。
通过这里的流量分析识别出异常数据流，然后触发报警，进行下一步操作。
流量牵引
这个只针对IDC清洗有效，通常是清洗设备与IDC出口设备建立BGP协议，清洗设备向IDC出口下发牵引路由，那么，流往目标IP的所有流量都会被先送到清洗设备进行过滤。
攻击阻断与过滤
攻击阻断主要是黑洞路由，流量过滤主要使用适配清洗算法以及各种算法阈值，由此区分正常流量与异常流量，之后丢弃异常流量，回送正常流量。
数据安全
数据安全层面，最好是和开发、业务安全联合规划设计方案。通常运维安全所能覆盖的是访问控制、认证授权、备份、加密等。
访问控制：区分数据敏感程度，实行不同程度的访问控制。但是应当严格按照db放置于内网的原则。
认证授权：基于RBAC进行授权。如果是比较成熟的db或者大数据集群，还可以使用动态计算权限、动态下发权限的方式，做到有需才授权、用完就回收。
备份：本地备份与远程备份，是业务需要决定是否加密备份。
加密
传输：通常使用https实现通道安全。关于https有2个最佳事件：1.证书采购：开发测试环境或者非重要业务可以使用免费SSL证书Let's Encrypt，该方案支持全自动签发、续签，通过交叉证书实现了对大多数客户端环境的兼容，此外可以使用https://www.ssllabs.com/进行站点安全扫描与兼容性测试。2.证书部署：针对站点接入CDN需要把证书私钥放在CDN，或者tls握手环节消耗服务端性能可能影响业务的问题，可以使用cloudflare的keyless方案，将计算压力转移到专门的集群，该集群可以使用Intel QAT硬件加速，同时在协议层面做针对性优化，从而实现压力转移与性能优化。
存储：这里基本上是开发层面或者业务安全层面考虑，但是如果由运维安全去做，则通常只是在文件系统层面进行加密而已，比如使用企业级方案ecryptfs。
脱敏：开发测试人员需要从备份数据或者日志中拉数据进行它用，此时需要注意脱敏。通常采用替换、增删字段、去除特征以及去除关联性等方式。
安全事件应急响应
下面是一个通用的安全事件应急响应流程，很显然运维人员、安全人员需要配合很多工作，其中需要注意的有：
保护现场，备份数据
联系产品评估影响范围
确认能否先封iptables限制外网访问
确认被黑机器接入基线审计与入侵检测情况
确认是否有数据泄露、机器被root，加了异常用户、异常进程、crontab，开放异常端口
确认被黑机器是否有内网ip，查看监控核实是否被作为跳板机
创建运维工单，跟踪和复盘漏洞发生与处理情况
外部合作
运维安全，首先是运维。日常工作中与IT、安全和网络部门关系都十分密切，保持与兄弟部门的良好沟通和信息共享非常重要。下面我们探讨一下与他们合作的可能性。
与IT部门
主要是办公网安全，尤其是NAC：网络接入系统，通常是IT维护，但由于历史原因或者技术支持的需求，NAC可能需要运维安全人员提供技术支持，比如前面提到的VPN服务。
与安全部门
运维安全属于安全的一个分支，但是不在安全部门管理之下，但其与安全部门的联系极其密切，可以说无论是业务安全，还是运维安全，都是“站在巨人之上”。
安全部门提供基础设施如DDoS防御系统和对外统一接口如SRC等
安全部门提供SDL支持，运维与产品部门的联系较安全部门更为密切，很多时候需求先到运维，才到安全，所以通过运维安全一起推动安全培训、安全架构设计与落地、渗透测试等工作也不少见。
相对应的，运维安全也能根据运维部门和产品具体情况实现精细化的漏洞运营，同时推动漏洞高效修复。
与网络部门
很多企业的运维和网络很长一段时间都是放在同一个部门之下，即便拆分出来之后，两者合作也是最多。对于运维安全而言，在访问控制和DDoS防御上非常需要网络部门支持。
访问控制
如网络隔离和统一出入口访问控制的落地
DDoS防御
网络打通、流量采集与包括ip资产信息在内的数据共享
本文从运维安全的概念入手，强调了运维安全困境导致了我们的重视，也从安全意识和基础架构建设上剖析了导致该困境的原因，然后就事论事，希望通过运维安全意识培养、运维安全规范以及运维安全技术体系的建设，来保障一套完整的运维安全体系的有效运转，为业务发展保驾护航。
本文源于一次内部培训，从构思到成文，从ppt到文章，前后花了几周的时间，中间断断续续，勉强成文。囿于作者的认知能力和技术沉淀，以及文章篇幅限制，可能很多地方说的不够清楚或者存在错漏。再次抛砖引玉，希望得到大家的更多指点。同时，也希望借此文刷新大家对运维安全的认识：运维安全，没那么简单。
