一

之前我说过，安全可以分解为安全运营、安全产品、安全架构。整个安全来说，架构是大脑，产品是骨架，运营是血肉。

这里实际也突出了一点：安全的这一体三面没有谁更重要，只有相互之间的协作。协作关系，当然是有主理与协理之分的。

同样是运营，在云安全的不同场景，其意义和用法，主理与协理关系都是不一样的。具体讲之前，我们再次回顾下安全运营的几个基本内容：

1、应急响应与日常巡检，比如日常安全问题的应急处理、日常安全风险的评估与上报、还有定期的演习组织等等，这些都属于这个范畴；

2、安全研究，比如漏洞挖掘、攻防对抗、渗透测试、安全策略的制定与效果分析、跟踪，安全新技术的研究等等，都属于这个范畴；

3、安全服务，比如威胁情报、安全数据分析、安全扫描、漏洞补丁推送与预警等等，都属于这个范畴；

4、安全管理，比如代码/行为审计、流程管理、合规（政策法律、内部安全规范等）等等，都属于这个范畴。

当然，这些都是我自己从经验和习惯角度的理解，不严谨也不是全部，不过已经囊括了绝大多数内容了。

二

安全运营角度，私有云与企业idc有更多相似的地方，这里把他们合在一起，统称为企业idc安全。公有云来说，与企业idc安全的运营有很大不同，我们分开说。

首先是公有云环境的安全运营

在上一篇分享我说过，公有云环境的安全问题更重产品。所以相应的，公有云环境里，一切安全能力的输出都以安全产品为媒介和依托，安全产品本身的效果好坏，决定了客户对公有云安全能力的评价。

基于此，公有云的安全运营团队在整个公有云安全里应该处于协理地位，且公有云的安全运营团队一切都以提高安全产品自身的安全能力为目标，安全运营团队本身不直接输出任何安全价值。

具体来说，大概以下几点：

1、发现现有安全产品的不足，提出改进建议和应急处理方案，积累一线安全数据和安全能力；

2、为安全产品提供产品设计上的理论支撑，提出安全产品的原型功能；

3、完善安全产品的安全逻辑，丰富安全产品依赖的各种规则、特征库等数据；

4、日常紧急情况的处理，以及临时性的、或者短期内安全产品不好解决的问题；

5、根据产品现状，以及日常客户反馈，预研具体安全问题的解决对策，为产品改进提供方向性建议。

接下来是企业idc安全运营

对企业idc安全来说，安全是个重运营的场景。企业环境下，业务复杂多变，标准化、程序化的产品无法解决企业安全的具体需求。所以需要通过安全运营这种手段，实现更多个性化的做法来满足企业idc安全的需求，这也是企业安全重运营的原因。

具体来说，企业安全团队输出以下几点内容：

1、日常应急响应，比如各种安全问题的实时处理。

这部分业务量大概占了整个企业安全部门80%以上的人力和物力资源。日常应急响应团队是整个企业安全部门直接对外输出安全能力的团队，是企业安全部门的一线团队。

他们需要处理日常的各种告警分析，处理各种被发现的安全问题，并连接安全部门与其它所有业务部门，推动这些部门的安全问题的及时、准确处理。

团队的跨部门协调能力是核心能力要求之一，因为对于业务部门来说，安全在多数时候都是不讨喜的业务。在确保安全问题解决的过程中，经常需要与相应业务部门打交道，通过各种方式推进业务部门对安全措施、安全策略去落实、实施。

而这些措施多数时候都会增加业务部门的工作负担，所以这就特别考验日常应急与响应团队的跨部门协调能力，以及责任心、执行力。

2、根据企业业务情况，针对性的提出安全问题的可能风险点，并制定合理可行的解决方案，推动业务部门做出改进。

3、定期做安全巡检，审核既有安全策略的落实情况，并给出安全报告，通告相关所有部门和人员并推动解决。

4、发现新的安全问题和既有安全问题解决措施的不足之处，与安全研究团队沟通，给出解决方案、解决计划并跟踪落实。

5、关注行业安全问题动向和趋势，针对本企业业务特点做出风险评估和应对措施，推动相关团队和部门落实措施。

以上是安全运营在公有云以及企业idc的做法区别，总结下就是：

公有云安全运营团队来说，其运营对象就是安全产品本身；企业idc安全运营团队来说，其运营对象是企业风险安全风险本身；公有云安全运营团队不直接对客户输出任何安全价值；企业idc安全运营团队直接对企业输出安全价值。

然后另外一个点，这里想单独提下，就是上面屡次提到的安全策略问题。

安全策略的制定需要日常应急响应、安全研究、攻防对抗、安全服务等多个团队的通力协作。其目的是针对已经发现、或者即将发生、或者根据安全经验认为可能会发生的安全问题，制定应对措施，跟踪实施，实时验证、实时反馈的做法、流程以及处理过程。

因为涉及的面比较广，所以在安全策略制定时，需要注意一些基本面的事情：

1、策略的制定需要考虑技术实现与最终效果之间的成本-收益关系。

比如，对于一些一次性策略，尽量使用现有工具和资源实现，减少开发成本，减少各种流程变动、程序变动的工作量。

而通常，程序变动、流程变动这样的事情本身就是风险点，减少这些变动就是在规避风险。所以安全策略要尽量避免标新立异，以最简单、最少的成本去达到安全目的，避免对现有安全策略和流程的大修大改。

这点最容易在安全部门“新官上任三把火”的情况出现，所以各位新上任的安全运营负责人要认识到这点。不光是策略、流程这些业务层面，还包括人员、组织架构层面的，都尽量保持稳定，非要调整也要尽量微调。

2、任何安全策略落实到最后都需要人来处理。

这里说的实际就是资源问题，也就是一个安全策略的好坏并不完全取决于安全效果的好坏，而是安全效果、安全目标、资源适配的一个平衡。

比如，对于一些反入侵策略，并不是没有漏报误报就是好的，而且这样的要求也是做不到的。更多的，我们要看这些漏报是不是在安全目标的容忍度范围内，这些误报是不是在日常应急响应及其它相关团队的处理能力范围内。

比如应急响应团队成员对告警信息的处理能力，一天是100条，某个安全策略的误报大概一天是80条，那这个策略就是合格的。策略合格与否，没有定量标准，更多是对你的团队的能力、业务目标的综合考虑后的折衷结果。