前言

开始前先说个观点:企业 IDC 安全实际是云安全的一个分支而已，这是本文希望强调的点之一。

其实本文的着力点是云安全，之所以标题没说云安，是因为在多数人印象里，云安就是 各种云平台的安全，是“云”的安全，认为企业 IDC 安全什与云安没有关系。为了避免这种 误解，本文标题故意没写“云”，希望通过本文，能让人更深入全面了解究竟什么是云安。

云安相关概念及安全架构的定义

本文要讲安全架构方面的内容，也就是怎么做才能搞定安全这件事。具体开始前，我先 说下什么是架构。之前我们说过，安全通常分解为三个方面:安全产品、安全运维、安全架 构。

前两者都是具体实施手段上的细节问题，架构问题回答的是很多人经常有的疑问:如何 做才能搞定安全这件事----这就是架构。

云安全通常三个方面:公有云安全、私有云安全、企业 IDC。

企业 IDC 安全一定程度上可以合并到私有云安全里去，不过企业 IDC 安全又有它稍微不 一样的地方，所以这里把它和私有云安全分开来作为一个分支。至于混合云安全，实际是几 个方面的综合，不单独说了。说了这么多，其实核心就是:交易所及普通企业安全是云安全 的一个分支。

所以我们从头来讲云安全，我先解释下什么是云:云是在对传统软硬件产品和服务抽象 出标准接口的基础上、屏蔽了软件硬件差异，对外提供基础性 IT 服务的服务，云与虚拟化 没有必然关系，但为了抽象出标准接口，虚拟化是必要手段;同时，物理服务器也未必不是 云，关键看它是 否有一整套的统一对外服务和管理接口。

总结一下就是:云是一种 IT 设施以及相关服务的交付手段。

公有云、私有云及企业 IDC 安全产品和安全运维的异同

接下来我们就来讲讲如何搞定云安全，也就是云安全的架构问题。

第一，需要搞清楚公有云、私有云、企业内网他们各自的安全问题特性，再针对他们的 异同 点针对性的做出架构设计。

公有云重产品，目前的公有云环境多数是中小企业，他们没有特别强大的安全运维团队， 所以更希望安全产品帮它解决所有安全问题。因此，公有云环境实际上对安全产品本身的处 理和防御安全问题的能力提出了更高的要求。

具体表现在如下几点:

对主机反入侵产品的效果特别看重。中小企业来说，服务器数量不是特别多，业务也并 不复 杂，安全问题更多集中在服务器被入侵上。所以解决服务器被入侵问题是他们的迫切 需求。

对服务器入侵容忍度低，是因为他们服务器数量少，牺牲任何一台服务器都可能对他的

业务造成致命影响，所以服务器入侵问题是他们对云平台好坏评价的基本的也是最重要的标 准;

对安全服务不敏感，因为安全服务多数是需要被服务对象具有一定的安全运维能力，中 小企 业不具备这样的能力。比如态势感知、威胁情报这样的偏服务型产品，其输出内容并 不足够 容易理解，也并不能对企业安全产生直接效果，对中小企业没有实用价值;

对安全产品的自动化处理能力要求高，中小企业囿于自身能力问题，安全问题高度依赖 安全 产品的自动化处理能力和防御能力，而且更多体现在实时阻断能力上;

对资源占用敏感，公有云客户多数资源并不充分，且因为认知问题，对于第三方安全产 品占 用的资源量特别敏感，非常容易因为资源占用问题而投诉安全产品，或者直接关闭相 关安全 产品。

对安全问题的共担意愿低，一旦出现任何安全问题，客户通常都把原因直接归因于云安 全平 台做得不够好，即使很多问题实际上应该是和客户共担风险的，比如经多次提醒仍不 修复的 弱密码和系统的、应用的漏洞等等。

后果就是:

主机反入侵产品应该是公有云环境云安全的核心内容。公有云环境的安全体系建设应该 把主 机反入侵产品作为重中之重。

功能点实现上，应该尽可能降低需要客户操作的内容，最好是完全无需客户额外操作。 这要 求安全产品的设计者对安全问题处理经验，安全问题对系统的影响，安全问题与各种 服务器 应用的关系等有着极为成熟的理解度。既保证自动化处理的效果，又保证对用户系 统和业务 产生尽可能小的负面影响。

产品功能表现上，公有云安全更倾向于实时阻断型功能，数据分析型功能可以适当弱化。

这点来说，公有云上的安全服务型产品更多面向云平台自身的运维团队，为运维团队的 运维行为提供数据支撑和分析手段，具体产品设计实施方面，就要求这些产品所提供的数据 足够细化和专业，提供的分析工具和手段也足够充分，一切以方便运维为前提，反而对自动 化的结果分析没有太多要求。

公有云的安全运维团队应该是以改进现有云安产品效果、为云安产品创新提供支撑为最 终目 标，其运维对象是安全产品，直接目标是让安全产品发挥其最大功效，并最大程度降 低安全 产品的固有弊端。一切运维行为围着产品转是公有云安全运维的基本特征。

这里其实就回答了一个问题:公有云运维团队与私有云、企业 IDC 运维团队，他们的业 务目标以及做法上的差异在哪。

第二，私有云及企业内网重运维。这里之所以把企业内网安全和私有云安全一起说，是 因为企业内网可以认为是私有云的一个特殊形态。展开解释前先要说明，这里的企业内网仅 指 IDC 生产服务器机房，办公网络不在此范畴内。办公网络的安全问题是另一个话题， 在 此不做进一步介绍。

私有云和企业内网的不同点在于:

私有云更多指的是云平台商通过标准化与个性化的结合，对公众输出的、针对具体企业 客户 一定程度定制过的、与公有云环境物理或者至少逻辑上隔离的网络及服务器环境，是 toB 的 一个具体的云计算商品，可以认为是具有定制化特性的公有云商品; 而企业内网实际上是企业自建、自用的机房、网络、服务器环境，不具有商品属性，拥有高 度定制化的环境，与企业自身的业务特性高度结合。

私有云和企业内网的共同点在于:

他们都具有相对隔离的环境，使用范围都仅限于企业自身业务，都针对自身业务做过定 制化 处理，架构设计都不具有通用性，使用者都具有一定的安全运维能力以及一定规模的 安全运 维团队。这些异同点导致了他们的安全问题特性以及具体做法上的异同。

首先，私有云环境因为是基于标准化云产品做出的特殊定制，所以私有云的安全问题具 有一定程度的共通性，其安全特性也继承了云平台的一些基本特性，安全缺陷也通常一并继 承过来。

而企业内网环境因为高度定制化，每个企业根据其业务内容、业务规模、业务特性、企 业特 点等理由，内网环境几乎不会有任何相同，安全特性和安全缺陷也因此完全没有相关 性。

其次，因为私有云仍然是在标准化产品的基础上做的定制，所以由同一个云平台提供的 不同企业私 有云之间在运维方式和运维工具、途径上有相似的地方;在相关安全规则的制 定上也基本遵 循相似的逻辑，引入的安全问题也都有相关性。

而企业内网基于完全没有相关性的环境发展而来，不同企业的运维方式、运维工具和途 径， 安全策略的制定与实施，都完全没有相关性，相关安全问题也是花样百出。

后果:

首先，私有云及企业内网的安全问题都更重运维。因为基于私有云或者自有机房运行业 务的 企业通常都具有一定规模的安全运维团队，有相当的安全能力，为通过运维解决安全 问题提 供了可能。对于私有云以及企业 IDC 来说，重运维也是必然的选择。 其次，这些企业通常都业务复杂且非常敏感，一旦出问题对公司乃至对社会都会产生严重影 响，比如银行。在这种环境下，很难单一通过安全产品程序既满足功能性需求，又避免误操 作导致的风险。

再次，企业环境，很多时候可以容忍牺牲部分服务器被入侵，但不能容忍服务器被入侵 后无 法及时发现，所以私有云及企业内网的基本安全目标就是及时发现入侵，至于入侵防 御，通 常更多依赖具体的运维手段。

实际上，在企业环境里，基于对误判的低容忍以及“牺牲部分服务器”情况的高容忍，不 建议使用阻断性的安全产品，以 “监控+应急响应”为主。

接下来讲讲一般性原则和方案:

A、产品为运维服务。产品存在的意义是为运维提供数据支撑和工具支撑。具体到产品 实现 上，体现为产品几乎以收集数据、分析数据以及执行运维命令为核心功能，比如日志 数据的 收集及分析等等。

这里就体现出了与公有云的区别:公有云更多是产品及研发团对驱动运维团队，而私有 云及企业 idc 是反过来的，由运维团队去驱动产品及研发团队。

说的粗暴点就是:公有云环境产品及研发团队会处于相对强势的地位，运维团队处于协 作、配合的位置;而私有云及企业 IDC 环境运维团队处于相对强势的地位，产品及研发是协 作与配合的地位。

所以比较粗暴的判断某个公司安全架构是否合理的方式就是:看他们产品研发与运维团 队的协作与被协作关系就行了。

B、安全问题的处理高度依赖运维团队以及完整的管理制度、应急处理机制。比如，通 常安 全运维团队都有 7X24 小时值班的倾向，所有服务器基本都会有实时联络人，对服务 器的异 常处理都有一套完善的流程做指导。

这点，在 BAT 贯彻的比较彻底，小公司很难做到，所以我之前也建议小公司尽量不要自 己处理安全问题，找个靠谱点的第三方安全公司比较合理。比如目前的各个代币交易所，最 好的选择就是找靠谱的第三方安全公司处理安全问题。

C、高度依赖服务型安全产品，比如态势感知、威胁情报、扫描器、数据分析平台以及 红蓝 对抗等运维手段。运维人员做出决策，更多需要借助这些工具来为自己的决策提供支 撑，同时结合自身经验和能力，对这些数据加工分析，得出具体策略内容。

但私有云和企业内网在这方面又不完全一致:

私有云环境的运维团队通常没有企业内网那么 大规模，其安全能力也要弱于企业内网 环境的安全运维团队(前面这些观点可能有失偏颇， 但很大程度也是事实情况)，最重要的 一点是私有云的基础设施由云平台提供，其运维团队 对私有云的基本架构逻辑和安全特性 掌握不一定充分，这些事实情况给运维团队分析数据并 得出结论制造了障碍，所以他们更 多倾向于这些服务型产品一定程度上输出处理建议;而企 业内网环境的运维团队通常具有 安全能力优势，也对自身所处网络和服务器、业务环境有更充分的认识，他们更多倾向于利 用安全产品输出的原始数据自行分析得出结论，对安全产品的智能化要求不高。

D、高度依赖安全管理制度。比如对安全边界的控制(防火墙、内网分区、端口开放限 制等 等)，对操作流程的限制等等。堡垒机、跳板机这样的措施实际也可以归类为安全管理 制度 之列。

E、安全措施深度切入业务环境，比如针对具体应用程序做出专门的加固处理，这在公 有云 是不可接受的也无法实现的。

F、防御性安全产品必不可少，但产品更多是作为运维团队的安全防御工具出现的，安 全防 御产品极少会作为独立的解决方案存在。

总结:私有云及企业内网环境，安全问题的解决以运维团队为中心，所有安全产品及制 度都为安全 运维服务。

产品角度:核心是搭建一套数据收集及大数据分析平台，以及一套顺畅稳定、易于使用 和事 后追踪的运维工具;同时，强化服务型产品的研发力度，以运维需求为基本目标，实 现产品 研发与运维的良好协作。

运维角度:重视团队成员数据分析能力和工具应用能力，重视关键数据敏感度;重视红 蓝对 抗等基本运维手段;建立基本的安全管理制度和应急处理机制，有完整的应急处理流 程。

产品与运维在私有云和企业内网安全问题上二者缺一不可，有主理与协作之分，但无重 要度 之分。

产品角度的云安全一般性设计原则

以上实际更多强调的是运维团队在“安全”这件事上该如何做。

作为安全架构团队，除了要做好运维团队的定位外，对安全产品及研发团队的工作思路 和团队定位一样非常重要。

接下来讲讲安全产品在“安全”这件事上的具体思路和定位。

首先要搞清楚云安全各个产品线的具体内容以及其主要作用和协作关系，包括一些要注 意的问题。

以下将要说的产品类型之间并不是同一标准下的分类，所以多个分类间的安全产品有不 完全的重合。之所以会把不同分类标准下的产品同时列出，原因在于每个分类都无法涵盖云 安全的方方面面，很多产品无法按同一标准分类，而且以下的列举也并非是完整的，更多目 的是做演示说明。

1、 边界防御性产品:防火墙(主机型，网络型);WAF(主机型，网络型)，漏洞扫描 与补丁推送等等。

边界防御产品在目前很多人鼓吹无边界的时代仍然有其不可替代的地位，其意义在于以 较低 的成本解决绝大多数安全问题。完全阻断边界安全问题不是边界防御的目标，也是不 可实现 的。比如漏洞问题，这是个永远无法杜绝的问题。

边界防御性产品的基本评价标准有几点:

A、不给边界功能引入故障:比如不能因为装了 WAF 导致 web 容器挂了，或者资源占用率 过高等等问题。

B、 没有明显的程序 bug，比如明确设置了 80 端口不允许被访问，这个端口如果仍

然能被 某个客户端访问，这就是明显程序 bug。这里的 bug 不包括一些安全效果性问题， 比如未 识别的攻击类型就不在此之列。

C、安全问题识别率符合预期:这里之所以不说具体识别率要到多少，这是因为任何一 个产 品都有它的发展阶段;任何业务对安全性的要求也都有一个限度控制。只要产品是符 合设计预期的，符合具体业务对安全性要求的，就算合格。

D、产品间功能重合度低:不同的边界防御产品间要有明确的功能定位，杜绝叠床架屋; 多 个边界防御产品间的“安全间隙”要尽可能低，充分覆盖边界安全问题的方方面面。

2、 纵深防御性产品:所谓纵深防御型产品，实际上并非指某个或者某些特定产品。纵 深防御更多指的是安全产品间的协作关系，纵深防御型产品与边界防御产品有不完全的重合 关系，二者考量标准不同而已。

通常，某个具体的安全点，不可能有任何安全产品能做到滴水不漏;而且，基于投入产 出比 考虑，也没有必要把它做到滴水不漏的程度。

一个产品，通常只解决某个安全点的绝大多数 问题，那些被漏掉的安全问题，并非不 管了，而是需要进一步的其它产品，在更合适的安全 点上予以处理，这就是纵深防御的通 常做法。

以病毒文件扫描为例:通常以 ReadDirectoryChange(windows 系统)或者 inotify(linux 系 统) 监控绝大多数的文件变动，并予以实时处理;

但是因为这两种方式都是非阻塞的，所以仍然 有部分文件会逃过检查逻辑。基于此， 通常会在系统的模块加载处再加一个阻塞式处理逻辑， 对恶意程序的运行予以直接阻断。

这个过程中，通过非阻塞的方式处理掉了绝大多数恶意文件，获得了系统性能的提升; 同时， 又以阻塞式的处理，对可能的极少数漏网之鱼予以最后的阻截，解决了安全性遗漏。 这就是典型的纵深防御思路。

纵深防御产品的几个基本评价标准:

A、是否以最低的成本解决尽量多的安全问题:这里是定性的，具体标准还是要结合实 际情况分析，但基本原则是解决其所在安全点的绝大多数安全问题，个人认为至少解决 80% 以上问题。

B、漏掉的少数安全问题是否有补救方案，补救方案所在安全点是否合理:成本足够低， 效 果足够好。

C、 多个纵深防御产品间功能重合度低，避免叠床架屋的做法。

3、 主机反入侵产品:主机反入侵产品的基本目标是阻断或者实时发现主机被入侵的行 为，目前市面上这类产品里用户量最高、检测及防御效果最好的是安全狗系列产品，但是其 缺点在于过于依赖本地行为分析，对大数据分析以及运维支持不足。

除了有 agent 的主机反入侵产品外，还有另一类无 agent、基于网络大数据分析的主 机反入 侵产品。这类产品的优势在于不需要侵入用户主机，用户体验好，但缺点在于因为 很多重要 数据拿不到，入侵发现效果实在差强人意。

而且在公有云环境，这种方案对第三方安全厂商实在不够友好，目前这种方案基本无人 使用。但在某些特定场合，配合 agent 数据也能提高 主机入侵问题的检出率，比如 DNS 隧 道类木马的检测、内网扫描行为等等。

这类产品的基本评价标准为:

A、较高的入侵发现率 之所以不说一个定量的数字，原因与之前说过的一样，产品的不同阶段以及针对的不同业务，对入侵发现率都应该有相对合理的要求，而不是一律 100%，这样本身不现实，也不符合投入产出比的原则。

B、 对于有阻断功能的主机防御产品，对发现的入侵事件，其阻断成功率必须 100%，否则 产品不合格。

C、 较低的资源占用，按经验，1 分钟平均 cpu 使用率不得高于 0.1%;10 分钟平均内存占 用不得高于 50MB;峰值 CPU 占用率不得高于 25%，峰值内存占用不得高于 100MB。

这些定量的数字，你要是问我是怎么来的，我确实说不出一个靠谱的理由，这些更多来 自于经验。

D、 系统不得因为装了主机防御产品后有明显性能下降。

E、 可运维性:是否方便运维，是否对关键操作和关键数据有记录、可追溯。

4、 应用安全产品:这类产品最广为人知的就是 WAF，还有诸如数据库加密产品、数据库防注入产品、账户防 爆破产品等一系列产品。这类产品通常防御效果较好，但存在几 个问题:

A、 深度侵入用户应用，容易导致兼容性问题和用户应用稳定性问题。

B、大量接触用户数据，存在数据泄密可能性以及用户隐私等法律问题，通常在接入前 必须 得到用户授权。

这类产品通常有以下几个评价标准:

A、 兼容性问题:在其应用领域是否兼容常见应用及其各个常见版本，否则不合格。 B、 是否有不经授权获取并使用用户数据的行为。

C、 资源占用及对性能影响是否在用户可接受范围内。

D、 可运维性:是否方便运维，是否对关键操作和关键数据有记录、可追溯。

E、 安全问题发现率是否满足预期。

5、网络安全产品:这类产品最广为人知的就是 DDOS 高防了，除此之外还有基于分光模式的 WAF，以及基于 cname 的云 WAF 等等。 这里可以明显看出，不同分类标准下，同一个产品可能落在不同的产品类型里。这个问题在上面有过说明，不必在意。

这类产品通常有以下几个评价标准:

A、使用复杂度:比如 cname 模式的云 WAF 因为很多用户觉得使用复杂而拒绝使用。 B、 检出率及拦截率满足业务需求，符合设计预期，之所以用这种定性标准，之前有说过， 不再重复。

C、 不因自身故障或者其他原因导致客户网络接口故障。

D、 对安全产品运营方的资源消耗在预期范围内。

E、 对客户网络接口性能的影响在预期范围内、满足业务需求。

6、 安全运维类产品:比如威胁情报、态势感知、运维工具、扫描器等等。这类产品更

多满足运维需求，根据云平台是公有云还是私有云的区别，会有不同产品要求，一般有如下 评价标准:

A、 数据覆盖范围是否满足业务需求。

B、 数据及时性、使用便利性、详细度是否满足业务需求。 C、数据准确度是否满足业务需求。

D、是否有与之配套的分析、存储工具。

E、噪音数据的剔除度是否符合预期。

7、云平台对各个产品的取舍原则: A、根据公有云、私有云及企业内网的情况，依据上面说过的业务及客户特点确定产品重点 和优先级。

B、根据平台目标和平台需求以及客户特点确定哪些产品是要直接面向客户的，哪些产 品需 要以运维为缓冲然后输出加工过的结果的。

C、 保证平台稳定与安全的产品，比如 DDOS 产品必须有且必须与云平台同时投入使 用。

D、应用安全类产品因为涉及到具体应用和用户数据等原因，通常不应作为默认选项， 而应 该根据用户请求做出处理。

E、 各个产品间应该有协作关系，不能出现孤立的产品点;“安全间隙”应该足够小，安 全点 应该足够齐全，但各安全点间必须重点突出，不能平均用力。

F、平台只做重点的、核心的功能，其它安全功能尽可能开放给第三方安全厂商，形成 安全 生态。

以上内容其实就是对于安全产品团队的基本要求，我以安全架构的角度分享了:安全运 维该怎么做，安全产品及技术该怎么做。