最近参加几次线下数据安全课程，在设计和准备课程PPT材料时，把之前积累的数据安全知识，又系统性地梳理了一遍，尝试把这些知识和项目安全实践中的应用场景进行结合，通过授课或者文章形式呈现出来。

今天探讨“网络和数据安全能力的主要呈现形式”，它们存在于哪里？在信息系统的全生命周期中，甲方和乙方对待“安全能力”有哪些不同？我们该如何理解这些不同，在公众正确运用好安全能力。

01.

甲方和乙方看待"安全能力"完全不同

我们先简要分析下甲方和乙方看待安全能力的不同，如下：

乙方视角：从各自已有的安全产品、工具出发，“我”的安全产品具备什么核心功能，甲方的业务场景来适应“我”的产品功能，可能存在一些定制开发情况，但也不能满足所有要求。“产品模式”目的是为了适用于更多的企业，是一个逐渐“标准化”和“普适化”的过程。

很多服务商为了体现差异化，通常在“核心”功能之上，“衍生”出一些其他用处不大的边缘功能，甲方大部分为了这些衍生功能买单，在信息系统中很难使用上。

甲方视角：甲方安全的正确方式是从业务场景的安全需求出发，不过由于业务场景往往复杂多变，单个安全产品无法解决，因此需要安全建设和安全规划，把很多安全产品组合在一起，多个安全产品必然会产生功能上的重叠和产品之间的“耦合”问题。

如果甲方IT建设过程对安全诉求非常明确，主导整个安全能力建设，这种情形安全能力融合度较高，但大部分情形是大量安全产品的堆叠。

乙方视角：甲方有了安全需求后，通常邀请不同乙方进行安全产品交流与培训，对有意向的产品进行POC测试（Proof of Concept Testing）；对验证效果较好的，通过项目建设方式进行安全产品的部署与测试，最终交付给用户。

这中间存在“安全间歇”，在项目建设阶段，很多业务环节未正式启用，没有业务场景的应用验证测试，安全产品只是完成了安装部署，实际未真正用起来，只是通过了项目验收。项目后续正式上线运行阶段，乙方只负责安全产品的“安全运维”，对产品本身运行保障，如版本升级、补丁或规则库更新，基本不参与其中安全运营工作，导致基本没有发挥出实际能力。

甲方视角：甲方虽然全程参与IT项目建设，但是安全能力建设只是其中很小的部分，在安全能力正式上线后，正确有效的应用才是核心，即“安全运营”比“安全运维”更加重要。因为上述项目验收期间，业务不具备应用场景导致安全产品无法有效的配置和启用。

02.

现在安全能力很少以单独的项目进行建设，通常会融入IT项目的整体建设，我们从信息系统维度出发，把安全能力简要分成四类：

基础设施（云）安全能力、云SAAS安全服务能力、信息系统单独部署能力、应用系统自带安全能力。

主要指私有云、数据中心等基础设施建设过程中，集约建设的安全能力，通常指网络安全能力，它的特点是“共用”，云内的所有系统共用，属于基础底座能力，只要进入该“场所”，“入驻”的信息系统默认都具备，无需单独申请。

通常包括边界防火墙、IPS、网络态势感知、网络数据防泄漏、流量分析、APT高级持续威胁攻击、WAF应用防火墙、网络安全审计等。常见清单及主要能力如下：

主要指云上或数据中心侧统一“外挂”部署的安全产品，可能是软件或硬件方式在云上部署，以SAAS服务方式提供各个应用系统使用，它的特点是“按需申请”，即信息系统根据业务特点和数据特点自行选择申请需要部署的能力。

通常包括堡垒机、数据库审计、主机HIDS或EDR、日志分析或日志审计、安全网关、KMS、密码机、数字证书等服务，此外还有主机漏洞扫描、WEB扫描等安全监测能力。常见清单及主要能力如下：

我们知道云上的SAAS服务不是万能的，无法全量满足要求，有些需要信息系统额外购、单独部署，它的特点是“外挂”，以外挂式的安全进行使用。通常包括分类分级、敏感数据识别、API安全网关、数据沙箱、数据脱敏网关（动态和静态）、安全监测预警、“蜜罐”等。常见清单及主要能力如下：

网络安全领域主要关注前三类能力，而数据安全层面更加关注一个信息系统中各个应用子系统自带的安全能力，各自所具备的安全内生能力，属于从应用功能层面实现的安全能力，它的特点是“内生”。通常包括两类：可视化的WEB应用安全功能、后端不可见的安全功能。

• 前端WEB应用类

包括用户登入基础功能、账号权限、WEB操作日志记录、数字水印、桌面水印、支持三权分立配置等，它们以WEB页面呈现，可以通过界面进行配置管理，对功能进行设置或者能力启用。这类应用重点在于配置或者以任务形式进行定期自动化执行。

• 后端应用程序类

并不是所有的安全能力都具备可视化、可配置的，有些后端应用程序通过代码形式进行实现。包括API接口安全能力、应用程序的加解密、密钥存储管理、业务逻辑的安全控制、会话超时、后端权限管理、输入输入验证、后台日志打印控制等。这类能力，需要与开发人员沟通获取，了解程序的实现逻辑。

03.

在数字化转型趋势下，强调“资源集中、能力集中、应用集中”，集约化建设是必然趋势，而不是各类安全产品的堆砌，因此甲方需要根据业务场景统筹规划，即在建设前期多花时间进行规划和论证，主导整个安全设计和需求分析过程，融合后续业务应用场景进行设计，尤其是多考虑数据安全的需求，比如需要同步考虑数据安全能力，拟建设的信息系统主要用来承载什么业务，可能涉及哪些数据，数据的敏感度如何？

信息系统的建设方案中【安全建设方案】是其中核心内容之一，需要通过网络安全的“等保机制”，约束安全能力的基础建设，真正实现“同步规划、同步建设、同步使用”。甲方应该重视安全建设方案，除安全类专家，需要邀请IT专家、业务专家、数据专家等进行内部论证评估，有条件的可以组织外部专家进行评审。

安全建设方案解决的要“建什么”的问题？【安全实施方案】则是确保建设期间的安全能力，正确有效的部署与配置，在实际工作中最容易忽视的内容。

作为甲方，要求每个安全服务商编写安全实施方案，规范安全产品的部署与实施，并列举相关核心安全功能要点，在验收期间根据这些清单开展安全验收动作，确保安全产品的有效实施。

信息系统上线运行后，除了基础的安全运维工作外，针对本文提出几类能力，笔者在实践工作中有不同的应对思路，如下：

（1）针对云上底座能力和SAAS的安全能力，重点是“用好”这些能力，与云服务提供者做好协同，因为这些能力的管控权在云上，需要与他们建立良好的沟通渠道，发生异常后进行联动告警处置。

（2）针对额外部署的安全产品，这类产品控制权在安全运营人员上，重点是对这些产品产生的告警信息进行监测与处置，完成基础的安全运营。

（3）针对各应用子系统的内生安全功能，重点是定期关注这些功能的功能配置启用，通过巡检机制和IT内部审计方式关注这些功能实际应用情况，这类“开关式”的安全能力很容易忽略，但恰恰它们是做好数据安全最重要的地方。

比如一个数据缓存开关，默认是关闭，如果启用后对不该缓存的数据进行了缓存，它表现的特征是各类安全防护、安全监测能力都正常运行，业务也运行正常，可是因为缓存了数据产生了大量的数据合规和数据安全风险隐患。

再比如，数据服务类平台的“批量查询接口”，内部人员私自进行批量数据查询，或者把批量查询的结果进行下载保存等操作，这些是大颗粒度的安全产品无法解决的问题，需要数据安全人员参与与定期的审计机制。

图8：某私有云安全加固与配置清单

本文结合笔者实际工作情况，对网络和数据安全能力建设、应用等情况，总结了网络和数据安全能力的四种主要呈现方式。从甲方视角总结了不同形式的安全能力，需要用不同的方式进行管理和应用好能力，尤其应用系统内生的安全功能，它们是做好数据安全的重点。