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