49

LECTURE ROOM 百家论道

（二）CSPM 与 CNAPP

Gartner 视 CNAPP 为统一化的云安全管理平台。在

《CNAPP 创新洞察》报告中，针对云原生应用保护平台

（CNAPP）解决方案其认为是涉及基础设施即代码（IaC）

扫描、容器扫描、云工作负载保护（CWPP）、云安全态势

管理（CSPM）等跨越开发和生产环境的关键能力。

从作用上看，CNAPP 能够为云原生客户真正提供端

到端的云原生应用保护，提高云原生应用的安全可见

性、改进了兼容性、加快了风险识别能力、实现了风险

和合规检测自动化。

从图 3 可以看到，CSPM 是 CNAPP 整体解决方案中一

环，而且扮演着非常重要的角色。但 CNAPP 出现的时间

落后于 CSPM 几年，或者 Gartner 也是看到了云管控的复

杂性，孤立的点状解决，不如来一个大一统“集大成”

的便捷。

另外，在“安全左移”理论的作用下，CSPM 的功能

在前面提到的通用能力基础上，又增加了 IaC 扫描、云

威胁检测和响应、恶意软件/敏感数据扫描等功能属性，

有点“既要又要还要”的味道。但这种类似自闭环的小

SOC，如何在甲方安全架构体系下生存是个问题。

（图三 CNAPP 云原生应用保护平台）

四、CSPM 挑战与实践

前面介绍了 CSPM 的前世今生，而且亦对与 CSPM 密

切关联的 CIEM、CNAPP 做了对比。笔者最后介绍下自身

在实践中面临的一些挑战和当前的探索。

( 一）挑战

由于我们的业务完全依托公有云而建，所以在讲挑

战之前还是介绍下云厂商在这块已经做的事情。以某云

上此块已有的类似 CSPM 的能力为例。

1、配置审计，重点关注的也是配置风险问题，无论

国内还是海外的云厂商，一般都会有 config 类产品。

配置审计中已内嵌了部分合规包，而且也支持自定

义规则，相对来讲属于低成本的一个实现逻辑，作为辅

助快检还是可以的。当然，它也带一定自修正的能力，

敢不敢用属于另外一个维度的问题。

（图四 配置审计功能示例）

2、针对基础设施权限管理，在其云安全中心中提供

了云平台配置检查模块，涵盖 CIEM、常规云产品安全风

险和合规风险。出现的时间不长，但是功能迭代和丰富

度进步蛮快。

（图五 云安全中心功能示例）

我们当前是结合这 2 类产品的部分功能辅助做一定

检测使用。但仍然会面临一些挑战：

（1）无论的云厂商提供的类 CSPM 功能产品或商用

产品，本质上仍处于事中 / 事后监控的管控逻辑。云上

的基础设施权限和云服务配置管控的特殊点，天然的决

定了监控管控逻辑带来的治理成本高昂，尤其业务上线

跑起来。我们更希望以事前的阻断逻辑去做好管控，辅

助以事中 / 事后监控逻辑来做好检测。

（2）多云不是我们面临的场景，但多账号是。当有

20+ 以上的云账号需要去管控的时候，监控 Detection

管控逻辑带来的运营成本和压力是巨大的。

（3）配置审计功能一般云厂商可能会免费提供，但

是云安全中心云平台配置检查功能是收费的，费用也是

不低的，尤其在海外区域。

（4）云厂商或商用产品是站在通用逻辑和风险维

度去做这块能力，虽然云厂商的此块能力的进化速度很

50

百家论道 LECTURE ROOM

快。但仍然无法结合企业云上架构自动生成足够可信的

风险检测结果，误报率是绕不开的问题。另外，商用产

品完全依赖云厂商 API 的开放程度，这块的瓶颈是在选

用商用产品时不得不考量的点。毕竟要想看得深，首先

需要看到见。

（5）无论云厂商或商用产品，此块能力完全依赖对

云 infra 风险的认知程度，主要看 2 个维度。

a. 覆盖度。覆盖度是指检测能力对云上产品和服务

的覆盖面，是否能实现多数覆盖是个挑战，这块对商用

产品挑战更大。

b. 丰富度。丰富度是指针对单一产品或服务检测的

维度和深度能达到多少，规则数是一个衡量指标。

这块云厂商是有天然优势的，但仍然会面临其他的

问题，怎么去整合关联方同时跟进节奏。在《新视角下

企业云化安全治理框架 OCBC》一文中，笔者也曾提到，

云厂商各个产品是独立的，每个产品多数时候是站在自

身的维度来考量功能实现，安全不是第一选项。同时针

对多产品组合使用的安全性和风险问题，更不是第一考

量项；加之各云产品的迭代速度出奇的快，一个新功能

点的引入都有可能对甲方安全架构产生影响。因为，作

为用云企业，是无法和云厂商提出云产品的升级迭代与

否由自己企业来自主决定的要求的。

( 二）实践

基于 CSPM 仍偏向事中 / 事后的管控逻辑，与实际业

务场景事前管控、与内部平台强耦合的特性有着较大的

差异，我们结合业务特点，针对云权限和配置安全管控

我们采用如下的管控逻辑来实现自身的诉求。

( 图 6 云权限和配置风险安全管控 )

云权限和配置风险安全管控整体上遵循事前、事中

和事后的思路逻辑，功能上：

（1） 覆盖常规CSPM通用功能、云基础设施权限管理等。

（2）针对云产品自身风险治理，管理更前置化。在

云产品选（评估）的阶段安全就进行介入，保证先评估，

后准入，再购买机制。

（3）针对人员、应用的云服务和产品权限使用以自

建化能力，遵循最小化权控原则，并确保 AK 自动化托

管，实现事前风险收口。

（4）采用基线风险监测和有效性检测二重机制，确

保基线可靠性落地，绕过基线管控风险检测。

当前部分功能仍在建设阶段，后续会结合控权逻辑

再综合进行介绍。

五、写在最后

CSPM 的出现本质上是为了解决云配置安全风险

的问题，Gartner 在 CSPM 的定义中也强调其能力覆盖

prevention、detection 和 response。但是在甲方复杂

的业务场景下，prevention 实现的难度和复杂度甚高，

对乙方厂商要求产品通用性和可复制性的原则指导下，

更不会愿意去介入前置的动作。

但是，依赖事后追着治理的思路对甲方来讲是非常

被动的。仅仅作为事后监控的机制，显得略鸡肋，毕竟

云厂商已经提供了类似的功能点，而且商用产品又完全

依赖云厂商的 API 开放能力来构建规则，本身是存在弱

势的。另外，就是对国内云厂商的支持力度参差不齐。

最佳实践往往是在特定基建上的落地，可以参考，

但不一定能借鉴。作为甲方，结合自身业务特点，选择

最适宜的方案才是上策，博众家之所长，补已之短。

51

LECTURE ROOM 百家论道

多场景下的安全运营集约化

当前在外部安全威胁不断加剧的背景下，为提升抗风险能力，安全、业务

部门投入大量资源落实包括安全意识、数据安全、主机安全、研发安全等 110+

项具体工作，但结果却出现投入多、效率低、用户满意度差的情况，亟待建立

集约型安全服务平台，基于集约化、场景化、自动化措施解决以下问题。

一．安全威胁分类

（一）安全风险分散

安全系统是烟囱式部署，风险数据割裂，各种风险数据存在不同系统或设

备中。比如网络攻击数据，在 WAF、NGFW、APT、态势感知等系统各有一部分，

需要建立一个集约型安全服务平台。

（二）安全工作缺乏端到端场景

单一安全系统或设备难以满足业务场景化需求，需要基于业务场景化把安

全与运维、工单、授权、管理等系统有机结合起来。比如超融合安全运维场景，

就整合 SSO 单点登录、账号纳管、动态授权、自动代填密码登录能力，达到了

快速交付能力，实现端到端安全运维场景。

（三）安全工作自动化能力不足

在攻防对抗过程中，面对庞大信息资产，缺乏体系化和成熟的自动化能

力，脆弱性暴露时间越长，攻击成功概率越大。比如：面对大量对外主机需要

修复 Log4j 漏洞、Tomcat、Nginx 漏洞等，有自动化漏洞修复能力，可以快速修

补这一风险。

二、项目目标——一体化安全服务平台

在此背景下，多场景安全运营集约化项目应运而生。

多场景安全运营集约化项目最终的目标是打造一个一体化安全服务平台，

具有集约、服务和提效的功能，其中包括：

1、安全服务集约化：对接内部云、外部云、混合云等场景下主机漏扫平

台、入侵检测平台、研发安全漏扫平台、数据安全管控平台、安全考核平台等

多环境几十种维度的安全风险数据，整合安全资源，聚合多环境、多系统数

据，打造统一安全服务平台。

2、安全能力场景化：聚焦用户痛点，提炼用户应用场景，打造针对性功能

和流程，补齐最后一公里短板。规划设计了一键修漏洞 / 基线 / 弱口令、密码

纳管自动授权（动态授权）、一键 Bypass/ 封堵 IP、自助委托策略等 8 个安全业

毕业于中山大学网络工

程专业，现任某金融科技企

业安全团队负责人。曾任职

于多家头部世界 500强企业，

从事网络安全工作十余年，

熟悉各行业的信息安全建设

规划，对企业安全合规、个

人隐私保护、安全治理等方

面有较丰富的经验。

郑太海

52

百家论道 LECTURE ROOM

务场景，为用户提供基于场景、融入业务流程的安全服

务能力。

3、安全工作自动化：打通流程断点 / 阻点，通过平

台和系统对接，让数据流动起来，让数据多跑路，让用

户节省时间，提高效率，改善体验。

（1）打通断点：通过平台对接，为用户提供批量修

复漏洞 / 基线便捷功能。

（2）打通流程：通过打通风险数据与工单系统，实

现漏洞考核申请全流程自动化贯通。

（3）打通系统：通过打通堡垒机、特权系统，一体

化平台实现用户自助托管主机账号密码，即实现自动授

权 / 动态授权运维通道使用等等。

三、建设一体化信息安全服务平台

如图一所示，一体化信息安全服务平台具备业务和

安全两个视角：上层业务层是开发和运维；下层安全层

由下往上依次是安全资源层、模块层和服务层。我们先

从安全层的最下面安全资源层开始介绍：

1、安全资源层：这里说的资源就是指日常的风险扫

描器，HIDS 主机入侵监测和 TIP 威胁情报，还包括了像

研发安全的代码扫描、数据安全层面的分类分级，以及

终端安全的防病毒托管和基于情报的态势感知等等，我

们把它统称为安全资源层。

2、模块层：大部分公司在部署这些设备的时候，都

属于烟囱式的部署，数据是割裂的，我们需要把安全资

源层整合成一个个的模块，我们按照标准的开发安全、

网络安全、主机安全、安全管理、数据安全等整合成安

全模块。在这个模块里面，我们主要关注“安全事务”，

什么叫“安全事务”？就是我们要去处理一件安全的事

情，比如说修复漏洞，以及去关注一些安全的指标，像

口令、基线的及时修复率等，我们需要在不同的模块里

去定义下来。

3、服务层：模块层再往上是服务层，服务层是对模

块层的进一步抽象，是把从安全资源抽象成模块以后，

再把相应的资源里面的接口抽离出来，然后对外封装成

一种安全服务，比如开发安全服务、网络安全服务、主

机安全服务和安全管理服务等。

最后，也就是最上层的业务层。从业务人员的视角

来看，如果你是一个业务部门的 Leader，登录平台时

最关心的内容是部门所管理的资产面临的安全风险有哪

些、有哪些漏洞没修复、有多少可疑的资产、数据安全

层面的有哪些风险。

第二个重要的点是待办。比如说部门的安全专员登

录平台之后，除了看风险之外，还要看他自己的待办，

要看他的行事日历，每天要做的安全工作有哪些？比如

说漏洞修复的排期要求是怎样的、有多少漏洞是这个月

必须要修复的、有多少漏洞是可以等到下个月或者下个

季度去修复的。

自动化模块

自动化策略配置

脚本管理

…

运维平台配置

Ops

服务层 开发安全服务 网络安全服务 主机安全服务 安全管理服务

开发安全模块

开发架构评审

人工渗透风险审核

应用漏洞配置与研判

风险扫描器 HIDS主机入侵检测

态势感知平台

TIP威胁情报 SRC应急响应中心

蜜罐系统 风险管理系统

网络安全模块

外网高危端口识别

外网漏洞检测与研判

外网攻击检测与确认

NGFW下一代防火墙

CMDB配置中心

数据资产管理平台

WAF应用层防火墙

主机安全模块

主机漏洞基线配置

口令规则＆弱口令库

DDoS防御

堡垒机运维审计

主动防御系统 数据分类分级平台

特权账号 …

数据安全服务 安全自动化服务

Dev

需求 设计 开发 测试 部署

安全管理模块

预警通知管理

违规检测规则配置

考核指标管理

…

应用漏洞管理

…

纳管改密策略

…

一体化信息安全服务平台

数据安全模块

数据使用策略

分级分类标准

…

脱敏规则

…

运维

网络安全

外网漏洞

高危端口

外网攻击

一键Bypass

主机安全

主机基线

主机漏洞

一键账号纳管

一键修复漏洞

安全管理

安全考核

预警中心

员工违规

委托处理

数据安全

加解密

分类分级

数据脱敏

…

Dashboard

风险可视

个人中心

待办事项

资产中心

开发安全

代码安全扫描

研发安全考核

版本发布合规

…

架构风险

渗透测试

应用漏洞管理

模块层

安全资源层

（图一 一体化信息安全服务平台）

53

LECTURE ROOM 百家论道

四、超融合安全运维场景

第三个重要的内容是场景化，也是业务人员最关心

的视角之一。基于业务视角的信息安全服务平台被定义

之后，然后去开展一些相应的安全运营工作。

接下来我会举两个关于场景化的例子，通过这两个

例子能够很好地去解决业务人员和非安全人员在整个开

发运营过程当中遇到的问题。

第一个场景我们内部叫做超融合安全运维场景（如

图二）。超融合主要是解决以下问题：

第一个例如图二的 SSO 单点登录，我们将它融合进

来进行处理。很多公司上了堡垒机，需要登陆要运维的

目标机器的时候，还要再去登录一个跳板机，再比如要

去运行很多专业的命令的时候，必须在一台跳板机上才

能够去实现，这个时候就需要进行多跳。从第一跳堡垒

机到第二跳目标机，最后到第三跳跳板机，需要输入三

遍用户名密码，如果还有些堡垒机的目标机是基于双因

素的话，就要输 4 遍密码，等待 4 分钟左右，这种情况

会导致效率较低。所以第一个场景我们是解决 SSO 单点

登录的问题，就是如何让用户登录一次之后，把 SSO 的

信息带到各个安全的目标业务系统里面。

第二个是我们解决了账号纳管，通过超融合的一个

入口，我们可以统一地去纳管用户的主机账号，然后在

整个主机进行申请的时候，只要投产，就会经过自动化

的流程把账号纳管进来，也就是通过特权账号系统把账

号输进来，不用操作者去管密码了。

第三个解决的是动态授权应用。传统环境下，用户

登录的时候，我们得手动给用户分配，客户登录堡垒机之

后，他能访问哪些目标机器，这个时候我们可以通过超融

合入口，去打通内部的 CMDB（见下图二右下角 CMDB 的内

部配置管理系统），然后去自动确认属于哪个组织架构，

再自动分配他自己有权限的那一部分运维的目标机器。

第四个解决的是主机的自动代填登录，这一块是解

决输密码的问题，传统环境下登录堡垒机之后再登录目

标机，还得再输密码，这里我们通过 WebSSH 的前端和后

端的一些方式去实现主机密码的自动代填。

最后是变更安全管控。图二的左上角有一个工单系

统，如果说用户要进行变更的时候需要读取申请变更的

工单，然后把工单里的信息提炼出来，比如说有效期，

要访问的目标机器再给到 SSH 后端，然后把这部分信息

带到后端之后，再自动地去分配操作窗口，有效期过了

之后，变更工单会自动失效。

所以超融合运维场景是去解决多云环境下各类问题

的一个复杂性场景，是去解决不同的登录入口，然后不同

环境下的资产和事件的处置，包括怎么统一和将流程自动

串联起来，以及这些资产和权限归属的自动分配等等。

五、自动化漏洞修复场景

（一）传统手工修复漏洞方式

传统环境下，安全人员会周期性地配置扫描任务（这

里讨论的主要是指主机或是组件的漏洞，不包括应用层

（图二 超融合安全运维场景）

超融合安全运维场景

（统一入口）

跳板机

SSH

主机群

WebSSH前端

SSH

WebSSH后端

（动态授权）

堡垒机（多云,多套）

SSO单点登录

密码代填登录

密码代填登录

（密码代填登录）

透传 透传

一体化信息

安全服务平台

特权账号

工单系统

（运维账号托管）

（变更工单授权）

数据

同步

运维人员

登录

获取资源动态授权

CMDB

• SSO单点登录

• 账号纳管

• 动态授权应用

• 主机自动代填登录

• 变更安全管控

传统运维方式

云环境运维方式

54

百家论道 LECTURE ROOM

的漏洞）。让安全人员去配置扫描任务，在指定时间内

扫描完之后会经过安全人员的评审，手动、人工地去评

审和确定，排除如误报、资产归属不准等情况，然后再

把扫描报告发给相应的团队，相应的团队自己也会再做

第二次评估，利用第二轮评估再去确认哪些是不用修复

的，哪些是误报。

评估完了以后进入推修环节，主机团队或者运维团

队需要自己打补丁，或者更新一些组件。操作完之后进

入到验证环节，会把手工修复的邮件回传给安全团队，

去让安全团队再次扫描和验证，基本上是一个 T+1 或者

T+N 的周期。

具体手工修复流程如图三所示，我们可以看到传统

的手工修复漏洞方式存在人工修复成本高、比较耗时和

费力，同时也存在效率较低和修复周期长的问题。另外，

部门安全专员收到漏洞推修邮件，需要导出多套环境的

资产信息，与多套环境的风险漏洞数据，进行手动关

联，得到最终主机运维方或属主，再分发到部门内部人

员，且线下跟催和推修，容易遗漏，效率不高。

这个场景既是安全部门的痛点，也是运维部门开发

部门的痛点。

（二）自动化漏洞修复方式

自动化修复漏洞有几个方面能做到自动化：

第一个是评审自动化，先制定评审原则，然后将其

沉淀成策略，比如说主机团队的一些评审的原则，做成

策略之后，然后放到平台里面，扫出的报告进行自动解

读，符合策略的，才继续往下推修。

第二个是修复自动化，需要针对不同类型的漏洞深

入分析，制定自动修复的脚本，比如说打补丁，补丁源

下什么版本？把它做成脚本之后然后配置在一个固定的

地方，然后通过程序自动地调用，因此整个脚本的维护

包括了主机团队、应用团队以及安全团队的一些专家共

同组成，大家一起共同来维护主机的脚本。

第三个是验证自动化，传统方式的整个验证是通过

邮件来回确认，时间周期较长，验证自动化是在运维方

修复漏洞之后，可以点一键验证环节，去触发调度扫描

器，扫描器扫描目标资产的同时返回扫描结果，然后通

过平台反馈给点击验证环节的用户，这时候用户可以知

道哪些是需要修复的，下载的更新包或者补丁是不是有

效的，且能快速得到反馈结果。

第四个方面是 CMDB 自动化，资产的分配管理，整个

扫描分配环节和验证环节，都是通过对接 CMDB 进行资产

的自动分配，当然会出现 CMDB 数据不准的问题。

因此，自动化修复漏洞方式具有自动聚合数据的优

势，据统计效率能较之前以提升大约 60 倍，另外可以精

简修复动作，用户只需一步操作。

综上所述，一体化信息安全服务平台，聚合多维安

全数据（如信息资产、安全设备、系统、网络信息、数

据安全、事件和预警等数据），打造满足安全管理的多个

管理场景：

安全人员 扫描资产 漏洞评估与研判 漏洞分发与修复 漏洞验证闭环

配置任务 专家评审 推修清单

不推修

（误报/低风险）

漏洞验证

验证不通过

豁免/延期

到期重新纳入 暂无法修复 推修清单

风险评估专家虚

拟团队

漏洞评估

手工修复流程示意图

备注：

部门安全专员收到漏洞推修邮件，需要

导出多套环境的资产信息，与多套环境

的风险漏洞数据，进行手动关联，得到

最终主机运维方或属主，再分发到部门

内部人员，且线下跟催和推修，容易遗

漏，效率不高。

（图三 手工修复流程示意图）

55

LECTURE ROOM 百家论道

1、基于风险的漏洞全生命周期闭环管理（含自动化

处理）。

2、基于主机账号全流程纳管与应用（含运维特权

账号）。

3、基于数据安全的全生命周期线上化、自动化、批

量化处理与管理。

通过多元数据整合，系统拉通，围绕信息安全管理

目标，打造了可支撑和助力业务价值实现的丰富安全管

理场景和能力，提升企业信息安全管理水平。

超融合安全运维场景，统一平台和入口，与一体化

信息安全服务平台对接，实现动态授权，密码自动代填

登录，SSO 单点登录等提效功能，实现快速、便捷、安

全的二大安全运营场景，在传统的运维模式下，创新性

地解决了云计算环境下快速交付后立即使用的安全运维

场景。

漏洞自动化修复场景，通过与运维管理系统对接，

构建了一条自动化安全风险处理通道，定期组织专家开发

批量安全风险处理脚本，通过一体化信息安全服务平台，

进行适配、管控、自动下发，辅助安全风险快速处置关

闭，大大提升安全运营效率，减少了处理风险的成本。

六、项目亮点、价值与意义

风险产出效率提升 60 倍：通过拉通多云环境，多套

安全平台和系统的多维度风险数据，进行线上聚合、加

工、关联等，产出可直接使用的风险数据，相较手工作

业效率提升 60 倍，且每天动态更新。

漏洞基线自动化修复占比最高达 30%：通过打通运

维平台，精准从源头避免，新增与存量共同推进的方

式，打造一键自动修复漏洞功能，实现从 0％ -30％自动

化修复率。

一键自动纳管账号 40% ＋纳管率：通过自动化纳

管，新增账号纳管率 100％，存量账号纳管 40％＋的纳

管率。大大提升效率。同时配合开发出多种自动代填密

码登录的运维应用场景，进一步提升效率。

节省人力 5 人 / 年：通过 SSO 单点登录改造，减少

登录双因素系统，每成功跳转 1 次节省时间 30 秒，全年

累计节省人力 5 人 / 年。

主机群

安全人员 扫描资产

1.配置任务

自动评审规则

自动下发漏洞清单

专家评审

漏洞评估与研判

漏洞修复脚本库

一键修复 自动验证闭环

运维人员 豁免/延期

一体化信息安全服务平台－－自动化漏洞修复场景

2.全量漏

洞清单

编写脚本

3.推修漏洞清单

（漏洞类型关联修复脚本）

4. 收到推修通知

8.自动验证

5.1 登录平台一键修复

6. 下发脚本

5.2 人工申请

9.验证不通过

（到期自动释放

重新推修）

7. 执行成功

（图四 自动化修复流程示意图）

56

百家论道 LECTURE ROOM

API 安全与实践

OWASP 在 2019 年发布了 OWASP API Top 10 2019 版本，现在是 2023 年，

OWASP 计划在今年十月份发布最新的 OWASP API Top 10 2023 版本，本文将根据

现在预览状态的 OWASP API Top 10 2023 版本针对 API 安全进行说明，并且给

出一些实践的建议。

OWASP API Top 10 2023 版本包括以下内容：

1、失效的对象级授权

2、失效的认证

3、失效的对象属性级授权

4、不受限制的资源消耗

5、失效的功能级别授权

6、服务器端请求伪造

7、安全性错误配置

8、缺乏对自动化威胁的保护

9、资产管理不当

10、API 的不安全使用

针对上面的风险，本文将从描述、例子、测试用例、开源解决方案等方面

进行说明。

一、API 1：失效的对象级授权

（一）描述

攻击者可以利用失效的对象级别授权的 API 端点，通过操纵在请求中发送

的对象访问未经授权的敏感数据。

这个问题在基于 API 的应用程序中极为常见，因为服务器组件通常不完全

跟踪客户端的状态，而是更多地依赖于从客户端发送的对象 ID 等参数来决定对

象的访问。

（二）示例场景

在线商店的电子商务平台提供了一个列表页面，其中包含其托管商店的收

入图表。检查浏览器请求，攻击者可以识别用作这些图表及其模式的数据源的

API 端点 /shops/{shopName}/revenue_data.json。

使用另一个 API 端点，攻击者可以获得所有托管商店名称的列表。

攻击者通过一个简单的脚本来操纵列表中的名称，替换 {shopName}，就可

以访问数千家电子商务商店的销售数据。

晨星资讯高级安全架构

师，OWASP 中 国 广 东 区 域 负 责

人、网安加社区特聘专家，获得

北京化工大学计算机科学与技术

学士学位，华中科技大学软件工

程专业工程硕士学位。精通 C、

C++、Java、.Net 等多种语言以

及现有的各种流行架构，在开发

安全领域深耕 17 年以上，对安

全设计和安全开发有丰富的实战

经验。持有 CISSP、AWS 解决方

案架构师和 AWS 安全专家等认

证，多次参与安全书籍翻译工

作，组织、领导和独立完成多个

OWASP 项目翻译工作。

肖文棣

57

LECTURE ROOM 百家论道

（三）建议

实施依赖于用户策略和层次结构的适当的授权策略。

使用授权机制检查登录用户是否有权访问通过 URL

指定的资源。

使用随机或者不可预测的值作为记录 ID，如 GUID。

编写测试用例来评估授权机制的漏洞，不要发布测

试失败的变更。

（四）测试用例

1、测试未经授权的用户是否可以访问他们不允许访

问的对象。

2、测试未经授权的用户是否可以修改不允许他们修

改的对象。

3、测试访问控制规则是否在应用程序的所有层都得

到执行。

（五）开源解决方案

开发者使用 JSON Web Tokens (JWT) 用于简化 API

身份验证。JWT可以用于实现对象级别的身份验证和授权。

Spring Security 是一个强大的开源安全框架，

可 以 用 于 保 护 Java 应 用 程 序 和 REST API。Spring

Security 提供了一系列的安全过滤器和授权机制，可

以轻松地实现基于角色或基于资源的授权控制。此外，

Spring Security还提供了基于OAuth2的安全解决方案，

可以用于保护 API 端点和资源服务器。

Auth0 是一款云原生的身份验证和授权平台，可以用

于保护 API 端点和 Web 应用程序。Auth0 提供了一系列的

身份验证和授权机制，包括基于角色的访问控制、属性

级访问控制等。此外，Auth0 还提供了社交登录、多因素

身份验证等功能，可以大大提高应用程序的安全性。

二、API 2：失效的认证

（一）描述

API 中的身份认证通常比较复杂。人们可能对身份

认证的边界以及如何正确进行身份认证存在误解。此外，

身份认证都是公开的，这导致身份认证很容易成为攻击

者的目标。

公开的 API 在以下情况很容易受到攻击：

1、允许凭据填充，其中攻击者使用暴力破解有效的

用户名和密码列表。

2、允许攻击者对同一用户帐户执行暴力攻击，而无

需提供验证码 / 帐户锁定机制。

3、允许弱密码。

4、发送敏感的身份验证详细信息，例如 URL 中的身

份验证令牌和密码。

5、允许用户更改自己的电子邮件地址、当前密码或

执行任何其他敏感操作而无不需要密码确认。

6、不验证令牌的真实性。

7、 接 受 未 签 名 或 者 弱 签 名 的 JWT 令 牌， 如 (

{\"alg\":\"none\"})。

8、不验证 JWT 到期日期。

9、使用纯文本、未加密或弱哈希密码，如 MD5。

10、使用弱加密密钥，如 DES。

（二）示例场景

为了执行用户身份认证，客户端必须使用用户凭据

发出 API 请求：

如果凭据有效，则返回一个授权令牌，该令牌应在

后续请求中提供以识别用户。登录尝试受到严格的速率

限制：每分钟只允许三个请求。

为了对受害者的帐户进行暴力破解，攻击者利用

GraphQL 查询批处理绕过请求速率限制：

（三）建议

确保了解清楚所有可能的进行API身份认证的流程，

包括移动、网络、实现一键式身份验证的深层链接等。

了解身份验证机制。确保了解身份认证的用途和使

用方式。

不要在身份验证、令牌生成或密码存储方面重新发

明轮子，而应该使用标准的方法。

在暴力破解、速率限制和锁定保护方面，凭证恢复

和忘记密码应作为登录端点进行限制。

要求对敏感操作重新进行二次身份认证，例如更改

58

百家论道 LECTURE ROOM

帐户所有者电子邮件地址或者更改多因素认证中的电话

号码等。

参考 OWASP Authentication Cheat Sheet 检查认证

过程。

尽可能实施多因素认证。

实施反暴力破解机制，以降低对身份验证的凭据填

充、字典攻击和暴力破解攻击。这种机制应该比 API 上

的常规速率限制机制更严格，特别要防止类似 Graph QL

的批量查询。

实施帐户锁定和验证码机制以防止针对特定用户的

暴力攻击。实施弱密码检查。

API 密钥不应用于用户身份验证，而应该只用于 API

客户端身份验证。

（四）测试用例

1、测试身份验证凭据是否以纯文本或散列格式存储。

2、测试验证令牌是否正确存储和处理。

3、测试是否跨应用程序的不同级别强制执行身份验证。

（五）开源解决方案

开发者可以使用 OpenID Connect 协议增强身份认

证。OpenID 可以用于处理多种身份认证，如设备身份认

证，多因素身份认证和智能卡身份认证。

Keycloak 是一个开源的身份和访问管理解决方

案，支持多种认证和授权协议，如 OAuth 2.0、OpenID

Connect、SAML 和 LDAP 等。它提供了 Web 界面和 REST

API，可以方便地进行配置和管理。

Apache Shiro 是一个轻量级的安全框架，提供了

身份验证、授权、密码加密、会话管理等功能。它支持

多种身份验证方式，如基于表单的身份验证、基于 HTTP

Basic 和 Digest 认证、CAS 认证等。

三、API 3：失效的对象属性级授权

（一）描述

攻击者可以利用失效的对象属性级别授权的 API 端

点来读取或更改不应该访问的对象属性的值。

在以下情况下，API 端点容易受到攻击：

1、API 端点公开了一个对象的属性，这些属性被认

为是敏感的，用户不应访问的。

2、API 端点允许用户更改、添加或删除用户不应访

问的敏感对象属性的值。

（二）示例场景

一个基于短视频的社交网络，强制执行限制性内容

过滤和审查。即使上传的视频被屏蔽，用户也可以使用

以下 API 请求更改视频的描述：

攻击者可以重播合法请求并添加以下恶意负载：

API 端点容易受到攻击，因为没有验证用户是否有

权访问内部对象属性“blocked”，并且用户可以将值从

“true”更改为“false”并解锁自己被阻止的内容。

（三）建议

1、使用 API 端点公开对象时，请始终确保用户应该

有权访问公开的对象的属性。

2、避免使用通用方法返回结果，例如 to_json() 和

to_string()。相反，需要根据请求要求，返回特定对象

属性，可以参考最小权限原则，只返回需要的。

3、尽可能避免使用自动将客户端输入绑定到代码变

量、内部对象或对象属性的函数。

4、只允许更改应由客户端更新的对象属性。

5、实施基于模式的响应验证机制作为额外的安全

层。作为此机制的一部分，定义并强制执行所有 API 方

法返回的数据。

6、根据端点的业务和功能要求，返回的数据结构应

符合最小限度的原则。

（四）测试用例

1、测试未授权用户是否可以修改他们不允许的对象。

2、测试应用程序是否在所有层执行属性级授权规则。

3、测试未经授权的用户是否可以访问他们不允许访

问的属性。

（五）开源解决方案

开发者可以使用基于属性的访问控制（ABAC）来管

理用户访问权限和实现属性级别的授权。例如，可以使

用 ABAC 来确定哪些用户可以访问特定属性的特定数据。

Django Guardian 是一个基于 Django 的授权框架，

提供了细粒度的访问控制。它支持基于角色和权限的访

问控制，以及基于对象的访问控制。Django Guardian

59

LECTURE ROOM 百家论道

还提供了管理界面和 API。

同样也可以考虑上文的 Spring Security 和 Apache

Shiro。

四、API 4：不受限制的资源消耗

（一）描述

开发者只需要简单的 API 请求，就可以从单个本地

计算机或使用云计算资源执行多个并发请求。

API 请求需要网络带宽、CPU、内存和存储等资源。

资源有时候由服务提供商通过 API 集成提供，并按请求

付费，例如发送电子邮件/短信/电话、生物识别验证等。

如果缺少限制或限制设置不当（例如太低 / 太高），

则 API 很容易受到攻击：

1、执行超时时间。

2、最大可分配内存。

3、最大文件描述符数。

4、最大进程数。

5、最大上传文件大小。

6、在单个 API 客户端请求中执行的操作数（例如

GraphQL 批处理）。

7、在单个请求 - 响应中返回的每页记录数。

8、第三方服务商消费限额。

（二）示例场景

服务提供商允许客户使用其API下载任意大的文件。

这些文件存储在云对象存储中，并且不会经常更改。服

务提供商依靠缓存服务来获得更好的服务率并保持较低

的带宽消耗。缓存服务最多只能缓存 15GB 的文件。

当其中一个文件更新时，其大小增加到 18GB。所有

服务客户端立即开始拉取新版本。由于没有消费成本提

醒，也没有云服务的最高成本限制，下一个月的账单就

会大幅增加，给公司带来必要的经济损失。

（三）建议

1、使用基于容器的解决方案，可以轻松限制内存、

CPU、重启次数、文件描述符和进程数。

2、定义并强制执行所有传入参数和有效负载的最大

数据大小，例如字符串的最大长度、数组中元素的最大

数量以及上传文件的最大大小（无论是存储在本地还是

云存储中）。

3、限制客户端在定义的时间范围内与 API 交互的频

率（速率限制）。

4、应根据业务需求微调速率限制。某些 API 端点可

能需要更严格的策略。

5、限制单个 API 客户端或者用户执行单个操作的次

数或频率（例如，OTP 验证或请求密码验证等）。

6、为查询字符串和请求正文参数添加适当的服务器

端验证，特别是控制要在响应中返回的记录数的参数。

7、为所有服务提供商的 API 集成配置设置支出限

额。当无法设置支出限额时，应改为配置账单提醒。

（四）测试用例

1、测试应用程序是否限制单个用户的资源使用。

2、测试应用程序是否限制一组用户的资源使用。

3、测试应用程序是否限制了整个组织的资源使用。

（五）开源解决方案

开发者可以使用限制资源消耗（RCE）来对 API 请求

进行限制，可用于限制 API 的资源消耗。例如，可以限

制每个 API 请求的最大内存使用量，最大时间等。

API Rate Limiter 限制 API 的请求速率，防止某些

用户或攻击者发送大量请求。

Fail2ban 监视日志文件并禁止恶意 IP 地址的访问。

Snort 是一个开源入侵检测系统（IDS），可用于检

测和防止 DoS 和 DDoS 攻击。

五、API 5：失效的功能级别授权

（一）描述

利用漏洞，攻击者可以通过合法的 API 调用访问他

60

百家论道 LECTURE ROOM

们不应访问的 API 端点。这些端点可能会暴露给匿名用

户或普通的非特权用户。API 应用中的这些问题更容易

发现，因为 API 更加结构化，并且很容易预测访问某些

功能的方式，例如，将 HTTP 方法从 GET 替换为 PUT，或

将 URL 中的“users”字符串更改为“admins”。

查找失效的功能级别授权问题的最佳方法是对授权

机制进行深入分析，同时牢记用户层次结构、应用程序

中的不同角色或组，并提出以下问题：

1、普通用户可以访问管理端点吗？

2、用户是否可以通过简单地更改 HTTP 方法（例如

从 GET 到 PUT）来执行他们不应访问的敏感操作（例如

创建、修改或删除）？

3、X 组的用户是否可以通过简单地猜测端点 URL

和参数来访问只应向 Y 组的用户公开的功能 /api/v1/

users/export_all ？

（二）示例场景

在只允许受邀用户加入的应用程序的注册过程中，

移动应用程序会触发API调用GET/api/invites/{invite_

guid} 方法。响应包含一个 JSON，其中包含有关邀请的

详细信息，包括用户的角色和用户的电子邮件。

攻击者复制请求并将 HTTP 方法和端点操纵到 POST/

api/invites/new，此端点只能由使用管理控制台的管理

员访问。端点不实施功能级授权检查。

攻击者利用该问题并发送具有管理员权限的新邀请：

随后，攻击者使用恶意制作的邀请为自己创建管理

员帐户并获得对系统的完全访问权限。

（三）建议

应用程序应该有一个统一的授权模块，该模块用于

所有业务功能。通常，这种保护是由应用程序代码外部

的一个或多个组件提供的。

1、默认情况下，应拒绝所有访问，要求明确授予特

定角色以访问每个功能。

2、针对功能级授权缺陷检查 API 端点，同时牢记应

用程序和组层次结构的业务逻辑。

3、确保所有管理控制器都继承自管理抽象控制器，

该控制器根据用户的组或者角色实施授权检查。

4、确保常规控制器内的管理功能根据用户的组和角

色实施授权检查。

（四）测试用例

1、测试未经授权的用户是否可以访问他们不允许访

问的功能。

2、测试未授权用户是否可以修改他们不允许的功能。

3、测试应用程序是否在所有层执行功能级授权规则。

（五）开源解决方案

开发者可以使用基于角色的访问控制（RBAC）来管

理用户访问权限和实现函数级别的授权。例如，可以使

用 RBAC 来确定哪些用户可以访问特定函数的特定数据。

Open Policy Agent（OPA）是一个通用的政策引擎，

可以用于编写和执行各种访问控制政策，包括基于角色

的授权、基于属性的授权、基于数据分类的授权等。可

以与任何应用程序集成，提供强大的 API 保护功能。

同样也可以考虑Spring Security和Keycloak等方案。

六、API 6：服务器端请求伪造

（一）描述

利用 SSRF 漏洞，攻击者需要找到一个接收 URI 作为

参数的 API 端点，然后访问提供的 URI。大多数常见编

程语言的内置函数和库都存在 URL 解析不一致的问题。

只要 API 在未验证用户提供的 URL 的情况下获取远

程资源，就会出现服务器端请求伪造（SSRF）的漏洞。

SSRF 允许攻击者强制应用程序将恶意请求发送到意想不

到的目的地，越过防火墙或 VPN 的保护。

现代的应用程序开发使 SSRF 更加普遍和危险。

61

LECTURE ROOM 百家论道

开 发 人 员 根 据 用 户 输 入 访 问 外 部 资 源， 如

Webhook、从 URL 获取文件、自定义 SSO 和 URL 预览等。

云提供商、Kubernetes 和 Docker 等现代技术在众

所周知的路径上通过 HTTP 公开管理和控制通道。这些通

道很容易成为 SSRF 攻击的目标。

（二）示例场景

社交网络允许用户上传个人照片。用户可以选择从

他们的机器上传图像文件，或者提供图像的 URL。选择

第二个，将触发以下 API 调用：

攻击者可以使用 API 端点发送恶意 URL 并在内部网

络中启动端口扫描。

攻击者可以根据响应时间，判断端口是否打开。

（三）建议

1、隔离网络中的资源获取机制：通常这些功能旨在

检索远程资源而不是内部资源。

2、尽可能使用白名单。

3、对于远程源，用户应从指定的供应商（例如

Google Drive、百度云等）下载资源。

4、URL 方案和端口要确定。

5、给定可接受的媒体类型。

6、禁用 HTTP 重定向。

7、使用经过良好测试和维护的 URL 解析器，以避免

因 URL 解析不一致而导致的问题。

8、验证所有客户提供的输入数据。

9、不要向客户端发送原始响应。

（四）测试用例

1、测试应用程序是否容易受到服务器端请求伪造

（SSRF）攻击。

2、测试应用程序是否存在恶意文件上传漏洞。

3、测试应用程序是否容易受到恶意远程代码执行的

攻击。

（五）开源解决方案

Blacklist3r 是一种用于检测潜在的 SSRF 漏洞的工

具，它可以扫描 Web 应用程序和 API 以查找潜在的 SSRF

攻击点。

Barideki 是一种基于 Python 的 SSRF 漏洞扫描器，

它可以扫描 Web应用程序和 API以查找潜在的 SSRF漏洞。

七、API 7：安全性错误配置

（一）描述

攻击者通常会尝试寻找未修补的漏洞、常见端点或

未受保护的文件和目录，以获得未经授权的访问。

在以下情况下，API 可能容易受到攻击：

1、API 堆栈的任何部分都缺少安全强化措施，或者

云服务的权限配置不当。

2、缺少最新的安全补丁，或者系统已过时。

3、启用了不必要的功能。

4、HTTP 服务器链中的服务器处理传入请求的方式

存在差异。

5、传输层安全性（TLS）缺失。

6、不向客户端发送安全或缓存控制指令。

7、跨域资源共享（CORS）策略缺失或设置不当。

8、错误消息包括堆栈跟踪，或公开其他敏感信息。

（二）示例场景

API 后端服务器维护由流行的第三方开源日志实用

程序编写的访问日志，支持占位符扩展和 JNDI（Java

命名和目录接口）查找，默认情况下均启用。对于每个

请求，都会使用以下模式将一个新条目写入日志文件：

<method> <api_version>/<path> - <status_code>.

攻击者发出以下 API 请求，该请求被写入访问日志

文件：

由于日志实用程序的不安全默认配置和宽松的网

络出站策略，为了将相应的条目写入访问日志，同时

扩展请求标头中的值，日志实用程序将从攻击者的对象

“X-Api-Version”获取数据并执行 Malicious.class 对

象远程控制服务器。

（三）建议

1、可重复的强化过程可快速轻松地部署的环境。

2、审查和更新整个 API 堆栈的配置的任务。审查应

62

百家论道 LECTURE ROOM

包括：编排文件、API组件和云服务（例如S3存储桶权限）。

3、持续评估配置和设置在所有环境中的有效性的自

动化流程。

4、确保从客户端到 API 服务器以及任何下游 / 上游

组件的所有 API 通信都通过加密通信通道（TLS）进行，

无论它是内部 API 还是面向公众的 API。

5、具体说明每个 API 可以访问哪些 HTTP 方法：应

禁用所有其他 HTTP 方法（例如 HEAD）。

6、对预期从基于浏览器的客户端（例如 Web 应用程

序前端）访问的API实施适当的跨域资源共享（CORS）策略。

7、确保 HTTP 服务器链中的所有服务器（例如负载

平衡器、反向和正向代理以及后端服务器）以统一方式

处理传入请求以避免不同步问题。

8、在适用的情况下，定义和实施所有 API 响应有效

负载模式，包括错误响应，以防止异常跟踪和其他有价

值的信息返回给攻击者。

（四）测试用例

1、测试应用程序是否易受常见错误配置的影响。

2、测试应用程序是否存在已知漏洞。

3、测试应用程序是否易受不安全默认设置的影响。

（五）开源解决方案

Configuration Audit，对应用程序的配置文件进行

审核，以检查其中的潜在安全漏洞，并建议如何纠正它

们。其中包括可以使用的命令行工具和脚本，如 OWASP

Dependency-Check 和 PMD 等。

安全配置管理平台，使用此平台可以管理应用程序

的配置信息，并确保其安全。例如，使用 HashiCorp 的

Vault 来管理安全凭证或使用 Ansible Tower 管理应用

程序的配置文件。

八、API 8：缺乏对自动化威胁的保护

（一）描述

攻击者利用了解到的 API 的业务模型，来查找敏感

业务流以及自动访问这些业务流，从而损害业务。

自动化威胁变得更有利可图、更智能且更难防范，

API 通常是攻击者的目标。

随着时间的推移，传统的保护措施（例如速率限制

和验证码）变得不那么有效。例如，操作僵尸网络的攻

击者可以绕过速率限制，因为攻击者可以在几秒钟内从

全球数千个位置或者 IP 地址轻松访问 API。

易受攻击的 API 本身不一定有实现错误，只是简单

地公开一个业务流程，例如买票或发表评论，而没有考

虑如果以自动化方式过度使用这些功能会对业务造成怎

样的损害。

（二）示例场景

拼车应用程序提供推荐计划，用户可以邀请他们的

朋友，并为每个加入该应用程序的朋友获得积分。这笔

信用额度以后可以用作现金来预订服务。

攻击者通过编写脚本来自动执行注册过程来利用此

流程，每个新用户都会向攻击者的钱包中添加信用。

攻击者以后可以享受免费乘车或出售信用过多的帐

户以换取现金。

这就是所谓薅羊毛。

（三）建议

缓解计划应分两层进行：

1、业务上：确定如果过度使用可能会损害业务的业

务流程。

2、技术上：选择正确的保护机制来降低业务风险。

3、一些保护机制更简单，而另一些则更难实施。以

下方法用于减缓自动威胁：

4、设备指纹识别：拒绝向意外客户端设备（例如无

头浏览器）提供服务往往会使攻击者使用更复杂的解决

方案，这会增加攻击者的成本。

5、人体检测：使用验证码或更高级的生物识别解决

方案。

6、机器人模式检测：分析用户流以检测机器人模式

（例如，用户在不到一秒内访问“添加到购物车”和“完

成购买”功能）。

7、考虑阻止 Tor 出口节点和知名代理的 IP 地址。

8、保护和限制对机器直接使用的 API 的访问（例如

开发人员和 B2B API）。

（四）测试用例

1、测试应用程序是否容易受到自动化攻击。

2、测试应用程序是否可以检测和响应恶意流量。

3、测试应用程序是否可以保护自己免受恶意脚本的

侵害。

（五）开源解决方案

63

LECTURE ROOM 百家论道

ModSecurity 是一个开源的 Web 应用程序防火墙

（WAF），可用于保护 API 免受自动化威胁的攻击。它可

以检测并防止暴力破解、DDoS、机器人扫描和爬虫攻击

等常见威胁。ModSecurity 具有灵活的规则集，可以根

据 API 的需求进行定制。

Fail2ban 是一个开源的入侵防范系统（IPS），可用

于保护 API 免受暴力破解和 DDoS 攻击等自动化威胁。它

可以监视 API 的日志，并根据配置的规则集自动封锁攻

击者的 IP 地址。

九、API 9：资产管理不当

（一）描述

攻击者通常通过 API 的旧版本或未打补丁且使用较

弱安全要求的端点进行未经授权的访问。攻击者可能会

通过管理不善的第三方接口访问敏感数据。

API 经常没有清晰的文档，包括：

1、API 目的不明确，以下问题没有明确的答案：

（1）API 在哪个环境中运行（例如生产、暂存、测

试、开发）？

（2）谁应该拥有 API 的网络访问权限（例如公共、

内部、合作伙伴）？

（3）哪个 API 版本正在运行？

2、没有文档或现有文档没有更新。

3、每个 API 版本都没有下线计划。

4、主机的资产丢失或过时。

（二）示例场景

社交网络允许独立应用程序的开发人员与其集成。

作为此过程的一部分，需要最终用户同意，因此社交网

络可以与独立应用程序共享用户的个人信息。

社交网络和独立应用程序之间的数据流没有足够

的限制或监控，允许独立应用程序不仅可以访问用户信

息，还可以访问所有朋友的私人信息。

一家咨询公司构建了一个恶意应用程序并设法获得

270,000 名用户的同意。由于该漏洞，该咨询公司设法

访问了 50,000,000 名用户的私人信息。后来，咨询公司

出于恶意目的出售这些信息。

（三）建议

1、全部 API 资产记录在案，重点关注 API 环境（例

如生产、暂存、测试、开发）、谁应该拥有主机的网络访

问权限（例如公共、内部、合作伙伴）和 API 版本。

2、资产综合服务并记录 API 的重要信息，例如 API

在系统中的作用、交换的数据（数据流）及其敏感性。

3、记录 API 的所有方面，例如身份认证、错误、重

定向、速率限制、跨源资源共享（CORS）策略和端点，

包括调用参数、请求和响应。

4、采用开放标准 Open API 自动生成文档。在 CI/

CD 管道中包含文档构建。

5、使 API 文档仅供获得 API 使用授权的人员使用。

6、对 API 的所有版本都要妥善保护，而不仅仅是当

前生产版本。

7、避免将生产数据用于非生产 API 部署。如果不可

避免的，这些端点应该得到与生产端点相同的安全保护。

8、当较新版本的 API 包含安全改进时，执行风险分

析以告知旧版本所需的缓解措施。例如，是否可以在不

破坏 API 兼容性的情况下向后移植改进，或者是否需要

快速移除旧版本并强制所有客户端迁移到最新版本。

（四）测试用例

1、测试应用程序是否存在资产泄漏漏洞。

2、测试应用程序是否容易受到未经授权访问资产数

据的影响。

3、测试应用程序是否容易受到资产数据操纵的影响。

（五）开源解决方案

SwaggerHub 是一个 API 设计和开发平台，可以帮助

开发人员更好地管理他们的 API 资产。SwaggerHub 包括

一个集成的版本控制系统，允许用户跟踪 API 版本，并

对其进行更改。

64

百家论道 LECTURE ROOM

Kong 是一个基于 OpenResty 的云原生 API 网关和服

务网格。Kong 提供了丰富的功能，如路由，负载平衡，

插件等，以帮助开发人员更好地管理 API 资产。

十、API 10：API 的不安全使用

（一）描述

开发人员倾向于信任但不验证与外部或第三方 API

交互的端点。攻击者成功利用这些 API 中的安全漏洞可

能会访问他们不应该访问的数据。

在以下情况下，API 可能容易受到攻击：

1、通过未加密的通道与其他 API 交互。

2、在处理数据或将其传递给下游组件之前，没有正

确验证和净化从其他 API 收集的数据。

3、盲目重定向。

4、不限制可用于处理第三方服务响应的资源数量。

5、不为与第三方服务的交互设置超时。

（二）示例场景

API 与第三方服务提供商集成，以安全地存储敏感

的用户医疗信息。使用如下所示的 HTTP 请求通过安全连

接发送数据：

攻击者找到了一种破坏第三方 API 的方法，攻击者

开始以 308 永久重定向响应前一个请求。

由于 API 盲目重定向，API 会重复包含用户敏感数

据的完全相同的请求，但这次返回的对象是攻击者的服

务器，从而导致敏感数据泄漏。

（三）建议

1、在评估服务提供商时，评估他们的API安全状况。

2、确保所有 API 交互都通过安全通道（TLS）进行。

3、在使用之前始终验证并正确处理从集成 API 接收

的数据。

4、维护一个白名单，只允许集成的 API 可能重定向

到白名单的地址，不要盲目重定向。

（四）测试用例

1、测试应用是否存在通过 API 注入攻击的漏洞。

2、测试应用程序是否容易通过 API 绕过身份验证。

3、测试应用是否存在 API 会话劫持漏洞。

（五）开源解决方案

OpenAPI Security 是一个基于 OpenAPI 规范的 API

安全框架，可以帮助用户进行 API 设计和开发，以减少

API 的安全风险。OpenAPI Security 提供了许多安全检

查和控制，如身份认证、授权、输入验证和输出验证等。

API Fortress 是一个基于云的解决方案，提供 API

测试和监控功能。API Fortress 可以帮助用户进行身份

验证和授权，同时对API请求进行输入验证和输出验证，

防止恶意攻击。

十一、总结

OWASP API Security Top 10 2023 版本是最全面和

最新的 API 最关键安全风险列表。该列表反映了不断变

化的威胁形势，包括近年来出现的新风险。大家可以结

合该列表去检查一下自己的 API，看看是否有影响。

另外本文提供了开源解决方案，所以 API 安全首先

是意识上的，然后才是对应的解决方案。希望大家共同

努力，把 API 安全做好。

65

LECTURE ROOM 百家论道

甲方的个人信息保护实践

一、解码个人信息保护法律法规体系

（一）法律法规体系

在开展个人信息保护之前，一定要梳理国家层面的法律法规和标准，比如

《国家安全法》、《网络安全法》、《数据安全法》、《个人信息保护法》、《数据出

境安全评估办法》、《网络安全审查办法》、《个人信息出境标准合同办法》、《儿

童个人信息网络保护规定》等等。这些内容都可以通过对应的渠道查找，法律

可以通过中国人大网查询，法规可以在监管机构在国家网信办、中国人民银行

等机构查询，国家标准可以在信安标委查询。

通过分析近几年国家出台的相关法律法规和政策文件，我们会发现网络安

全相关的立法速度越来越快，其多项配套措施也逐渐完善。从近几年的国家网

络安全周活动，以及网络安全事件的处罚，我们也发现执法活跃且严厉，而且

是多头合作监管，其颗粒度是全球最细的，比如滴滴处罚事件，被罚金额约占

上一年营业额的 5%，接近法律处罚力度的上限，涉及网信办、公安部等多个监

管部门。而且，出台的法律法规除了应对国内风险外，还能反制境外规则，特

别是美国的长臂管辖。

除此之外，近两年大家的网络安全意识不断提升，法律也赋权用户，大家

更加注重保护自己的个人权益，对应的司法案例也呈爆发式增长，个人用户的

投诉举报能力也越来越高。虽然有数据泄露和数据滥用的风险，但所造成的个

人安全事件越来越少了。

（二）个人信息范畴和处理要求

个人信息：以电子或者其他方式记录的与已识别或者可识别自然人有关的

各种信息，如姓名、手机号、生日、住址、财产、人脸识别、指纹、掌纹等；

不包括匿名化处理后的信息。

个人信息处理：个人信息处理包括个人信息的收集、存储、使用、加工、

传输、提供、公开、删除等。

诸子云上海会长、某跨

国企业 CSO、网安加社区特

聘专家、专利发明人，历任

多家金融机构、世界 500 强

企业的安全负责人、安全专

家。有近 20 年科技风险、信

息安全、数据安全、业务安

全等领域的丰富经验，是多

家机构的专家和顾问。

赵 锐

我们知道，做安全在和业务部门或技术部门沟通的时候，通常都会涉及到

敏感信息的监管合规问题，要熟悉国家的法律法规、安全标准等等，因此本次

内容将从解码个人信息保护法律法规体系和个人信息保护实践两个方面展开。

66

百家论道 LECTURE ROOM

敏感个人信息：一旦泄露或者非法使用，容易导致

自然人的人格尊严受到侵害或者人身、财产安全受到危

害的个人信息；包括生物识别、宗教信仰、特定身份，

医疗健康、金融账户、行踪轨迹等信息，以及不满十四

周岁未成年人的个人信息。

个人信息处理者：是指在个人信息处理活动中自主

决定处理目的、处理方式的组织、个人。

处理个人信息时，应当遵循合法、正当、必要和诚

信原则，不得通过误导、欺诈、胁迫等方式处理个人信

息。尤其个人信息出境涉及到《数据出境安全评估办法》

和《个人信息出境标准合同办法》，个人信息数量达到

百万量级或向境外提供个人信息达到 10 万或向境外提供

敏感个人信息达到 1 万的组织，在面临数据出境时就会

面临较大的监管。所以，企业的安全负责人要清楚了解，

自己所在企业收集处理个人信息是不是合法正当。

数据收集时需要目的明确，处理个人信息应当具有

明确、合理的目的，并应当与处理目的直接相关，采取

对个人权益影响最小的方式。

在满足业务的情况下，应当限于实现处理目的的最

小范面，不得过度收集个人信息，个人信息处理者应当

对其个人信息处理活动负责。另外，处理个人信息应当

遵循公开、透明原则，公开个人信息处理规则，明示处

理的目的、方式和范围。

在处理个人信息时，应当保证个人信息的质量，

避免因个人信息不准确、不完整对个人权益造成不利影

响。同时，个人信息处理者应当对其个人信息处理活动

负责，并采取必要措施保障所处理的个人信息的安全。

二、个人信息保护实践

我们知道，处理个人信息不可能靠甲方一家公司能

处理完，因为企业作为个人信息处理者，除了自己需要

使用还会涉及到于第三方的共享，比如转账，就需要和

银行分享个人信息。因此在处理个人信息时，要梳理清

楚哪些需要转移处理，哪些需要委托处理，哪些需要共

同控制。

既然有这些情况，首先需要确认数据生命周期，如

收集、存储、使用、加工、传输、提供、公开等。另外

还要确认所在组织的生命周期的安全情况，按照实际业

务场景来开展个人信息保护。

经过梳理，企业的个人信息主要包括三个部分，外

部的客户、内部的员工以及相应的服务商。

（一）企业客户数据

如图一所示，是手机银行的业务数据流，要分析手

机银行收集使用管理的个人信息合不合法，可以参照《个

人信息保护法》、《常见类型移动互联网应用程序必要个

人信息范围规定》、《金融数据安全数据安全分级指南》、

《信息安全技术个人信息安全规范》等法规标准。

基于这一系列的法律法规，可以知道在当前业务

场景下，手机号码、收款人姓名、证件类型、开户行信

( i o s 、A n d r i o d )

（图一 手机银行业务数据流）

67

LECTURE ROOM 百家论道

息是必要非敏感信息，证件号码、证件有效期、银行卡

号、口令、存款信息、交易和消费记录、指纹和人脸识

别是必要且敏感的信息。

除此之外，还需要根据某些城市当地的条例来判

断，比如天津 2020 年颁布条例，规定不允许收集指纹和

面部识别等生物识别信息。因此，我们在开展个人信息

保护实践过程中要去分析业务数据流，再对比国家和各

地相关的法律法规和标准，判断是否会存在相应的风险。

（二）企业员工个人信息

从企业的招聘场景来讲，首先企业会自主发出招

聘信息，或通过第三方猎头收集简历，经过一轮轮面试

以后，就会进入到入职环节，然后收集员工的姓名、生

日、证件号、住址、党派、照片、邮箱、电话号码、健

康数据、金融账户和家属信息等。在这些数据的收集环

节中，可能都会涉及与第三方分享员工的个人信息，比

如与体检机构共享员工的健康数据，与银行共享员工的

金融账户数据等。

在工作过程中还会有差旅，在报销相关行程车票

时，行为轨迹也会泄露给公司。还有像个人偏好，比如

坐飞机、坐火车，喜欢什么位置，这些相关信息都会被

公司或供应商所获取。另外很多企业为了方便考勤，还

会使用生物特征，比如指纹、掌纹、人脸以及虹膜等等。

在此过程中，企业应做好个人信息保护，有的企业

可能会有签署隐私政策，部分企业的隐私政策可能还在

制定完善中，但都应该重视对个人信息的隐私保护。

（三）实践技术解析

如图二所示，按照数据处理生命周期来梳理，在数

据采集阶段，我们可以做全站的 https 加密，其他的还

可以通过 Keyless CDN、跨 IDC 自动加密、反爬、账号

安全等措施，如果和微信绑定的，还可以看到 UUID。

在前台业务处理的时候，可以通过全程 ticket 鉴

权、token、sso 等方式。在数据存储时，可以进行相应

的加密。另外在传输时，进行通道加密和数字加密。

在日常访问和运维阶段，通过堡垒机、Debug 脱敏、

监控日志脱敏、开发运维分离等措施进行处理，生产数

据转测试环境时也会脱敏。

在后台数据分析阶段，对系统中内外部的业务用户

数据去做相应的加密，特别是数据仓库下的匿名化算法。

在数据展示和使用阶段，使用添加水印和数据防泄

露等措施，同时尽量展示统计数据而不是个人数据明细

在数据共享和再分发阶段，在用户注册初期就把隐

私声明公告出来让用户签署，同时要进行授权审核和脱

敏等措施，防止下游对信息进行缓存，使用 APP 时要有

相应的安全 SDK。

最后，当企业不再使用这些个人信息的时候，应

该要进行安全删除的操作，尤其在云里，用数据清除工

具，确保存储介质中的数据都被删除。

三、总结

实际上，个人信息保护的实践是基于数据生命周期

来开展的。在这些工作中，首先要将数据做好分类分级，

针对不同类型的用户做好授权，基于场景来开展保护工

作。另外，还需要做好资产的梳理，制定并完善流程制

度。从更基础的角度讲，其实需要把人的能力都展现出

来，通过流程和技术，开展个人信息保护工作。

（图二 实践技术解析）

68

百家论道 LECTURE ROOM

护网行动和企业信息安全体

系治理逻辑

资深信息安全专家，网安

加社区特聘专家，曾任腾讯出行

学院信息安全讲师。具备互联网

行业、金融、政务、能源、汽车

出行、通信行业等领域的信息安

全建设咨询与培训的实战经验，

服务客户均为行业头部企业。

王 勘

一、来自 17 年的预测

笔者在 2017 年《网络安全法》颁布之时，就已经在法律条文分析中向当时

的业内客户汇报了关于“护网行动”的开展的预测。其实展开来《网络安全法》

的法律条文，护网行动的规划也数次被提及。

当时预测的网络安全建设节奏应该是，立法及普法、扩大行业监管、提高

演练频率，当初的预测或者说今天的治理历程如下图：

( 一）《网络安全法》第三十四条规定：

除本法第二十一条的规定外，关键信息基础设施的运营者还应当履行下列

安全保护义务：

（四）制定网络安全事件应急预案，并定期进行演练。

其中的演练包含企业的自行演练，还包括配合相应监管机构的联合演练。

（二）《网络安全法》第三十九条规定：

国家网信部门应当统筹协调有关部门对关键信息基础设施的安全保护采取

下列措施：

（二）定期组织关键信息基础设施的运营者进行网络安全应急演练，提高

应对网络安全事件的水平和协同配合能力。

其中，“定期组织”、“应急演练”就是我们今天看到的“护网行动”，而参

与护网行动的大部分企业其实也就是《网络安全法》中描述的“关键信息基础

设施”。

（三）《网络安全法》第五十三条规定：

国家网信部门协调有关部门建立健全网络安全风险评估和应急工作机制，

69

LECTURE ROOM 百家论道

制定网络安全事件应急预案，并定期组织演练。

负责关键信息基础设施安全保护工作的部门应当制

定本行业、本领域的网络安全事件应急预案，并定期组

织演练。

这条规定指导了省级单位、行业监管部门组织的“护

网行动”或“应急演练”。

二、护网行动的意义

提到护网行动的意义就必须了解下国家的网络安全

治理逻辑：

• 国家层面：立法，维护国家信息空间领土主权完整。

• 行业层面：执法，转译法律条纹至具体行业标准

规范要求。

• 企业层面：守法，依托合规规范要求建设企业内

部基础设施及制度流程。

而在信息安全治理过程中，不同的层面关注的点也

不同：

• 企业关注：企业安全、企业利益不被侵犯窃取。

• 行业关注：行业稳定、业内发展符合规范预期。

• 国家关注：国家安全、网络空间领土主权完整。

这里也侧面解答了很多网络安全从业者和企业主的

困惑：“我企业的网络一直很平稳，没出过什么大事儿，

我不想花费这个预算，不做安全行不行？不演习不护网

行不行？”

答案是：不行。享有财产被保护是每个公民和企业

法人的权利，保障行业合规维护国家网络空间领土主权

完整，行业稳定发展也是各位的义务。

第一是因为我国宪法已经规定了公民的合法的私有

财产受宪法保护。公民的合法的私有财产不受侵犯。这

样的规定一是涉及到企业所服务的用户的个人财产安全。

第二是企业在法律意义上其实也是一个完整的“法

人”，其自身利益一样受法律保护，也就是说其企业所有

者有义务保障企业的安全运营。

第三是被定义为关键信息基础设施的行业牵动了大

量的民生和基础设施保障问题，一旦遭受到攻击或出现

信息安全事故对国家和人民的损失是巨大的。

三、护网行动设计的意义

我们先来思考下为什么很多很多网络安全从业者和

企业主会存在着：“我企业的网络一直很平稳，没出过什

么大事儿，我不想花费这个预算，不做安全行不行？不

演习不护网行不行？”这样的困惑？其根本原因是因为

我国企业发展的周期太短了、速度太快了。相比较于国

外的企业发展的历史沉淀还过于年轻。

在发展初期的核心目标一定是为了保障市场的繁荣

扩张，保护企业健康茁壮成长，所以这个阶段国家在立

法设置、合规管控、信息安全建设指导层面给予了相对

微妙且平衡的节奏，这让我们拥有了高速增长的 20 年，

但同时也意味着我国大部分企业的信息安全水平是“不

及格”的，甚至很多企业是“交白卷”的。

从可持续发展的角度出发，我们依旧需要尽快的堵

上这个窟窿。从现有的国际紧张的局势和竞争格局去看，

信息安全能力也是我国企业的整体一个短板，很容易被

降维打击。企业的安全能力不以人的主观意志决定水平，

不以安全人才的高低决定水准浮动，企业的信息安全攻

防线一定是基础设施加制度流程加响应机制综合形成一

个整体的有机能力。

护网行动的核心价值是一个相对较低成本的、可以

快速查缺补漏的优质方法：

是的，和各位印象相反的是，护网行动是所有的建

设方案中，成本最低的。相比于给出一套通用的行业建

设标准，动辄几千万投入的“马奇诺防线”，护网行动其

实是给企业一个动态寻找自身短板的过程，原有的投入

无需浪费，找到企业核心的短板快速补足。

四、护网行动的误区

我来给一个非常武断的观点，如果作为一个信息安

全行业从业的读者，在读到上面两个篇章的时候只感觉

到了乏味和枯燥，没有任何共鸣点，那很遗憾您并不是

一位合格的从业人员，或是在这方面没有天赋，或是专

业知识面储备欠缺。这并非是对笔者的认同感，而是说

70

百家论道 LECTURE ROOM

各位对国家在网络安全空间治理和企业安全治理的政策

和出发点并没有深刻的理解。如果没有这方面的理解，

那在企业做信息安全也永远是与企业主做成本与预算的

对抗，并不能帮助到企业切身实地的将信息安全的 ROI

做到最优解。

实际上近年来的护网行动，对于很多企业而言也确

实走到了一个偏门的误区。进入到了一种为了护网而护

网的状态。

国家设计的护网行动的初衷其实是让企业可以以

最小代价的、可迭代的找到自身的企业信息安全建设路

径。护网行动本质是一场“测评”，其核心的意义不在于

其过程，或者“通过”，而在于企业能通过本次“测评”，

企业自身能够发现多少的能力缺失，或是内部基础设施

的短板，或是响应机制的短板，或是一些流程的不合

理。当然这其中的原因复杂繁琐，或有企业的理解不到

位，或有企业主的安全意识不足，或有测评监管机构的

力度过于严苛或者因为行业的“一刀切”。但无论如何对

于一家企业尤其是中大型企业，如果每年度的信息安全

演习只有一次护网行动，每年集全公司力气护一次网，

那无疑是遗憾的，毕竟真正的“敌人”不会如护网行动

一般一板一眼，手段可控且将手段和威胁以及攻击周期

提前通知到企业。

更令人遗憾的是，企业仍旧习惯利用自己在甲方优

势地位，每年在测评期间“借调人员”、“借调设备”，甚

至将护网行动变成了一场分门别类的生意。一个行业如

此发展注定是不能持久的，也不能给这个行业注入任何

新的活力，如此做法的代价也终将有一天会从某些突如

其来的事件中告知我们答案。“作弊”代价的种子早已经

埋下，问题是谁来为这样的错误进行买单罢了。

五、依托护网行动的建设思路

企业该如何利用护网行动的思路，来实现企业信息

安全的有机建设。这里我们提出一个概念叫做信息安全

弹性能力。其核心思想是：企业压根没必要建设极高成

本的安全马奇诺防线，只需要建设符合自身水准的安全

能力即可，只需要具备发现风险的能力以及向监管机关

及时汇报的制度和流程。

当然这样的核心思想也并非笔者杜撰或是原地感悟

出来的，这就是等级保护的核心思想，分级而治。企业

并不要承担来自未知的极度不确定的威胁的代价，企业

只需要做到对应自身企业标准，有能力响应有能力汇报

即可。这也是为什么各位在护网行动过程中，不只有防

护的过程还要发现风险及时上报的原因，也在训练企业

的响应上报机制。

( 一）其中的建设思路可以参考如下：

1、构建自身业务模型，拆分不同业务板块的被损坏

可接受度；

2、分级治理，核心业务提高检测以及响应权重；

3、分层建设，建设以业务为导向的 IT 基础设施；

4、流程构建，很多企业缺乏流程响应机制的建设；

5、演习测评，内部组织定期演习，交叉演习强化应

对风险的能力；

6、人才培育，构建企业内部的人才培养机制，培育

企业自身的信息安全人才以及 IT 人才的信息安全能力；

7、常态化培训，固化信息安全至企业的文化意识当中。

（二）其中的建设原则如下：

1、合理的分层建设胜过完整的大而全的建设；

2、及时的风险识别机制胜过一味的设备堆叠；

3、高效的汇报机制胜过于大而全的条纹制度；

4、事前的演习成本永远小于事后的补救；

5、信息安全人才的培育是企业信息安全工作能持久

化的内核；

6、信息安全意识的普及是非常有必要的以便应对数

字化时代的冲击。

由于篇幅原因，笔者就不继续深入拆解更为详细的

解决方案和治理经验了，有感兴趣的小伙伴可以咨询网

安加社区进行详细了解，本文内容仅供参考，不提供任

何实际工作中的指导意见。

71

COMMUITY ACTIVITES 百花齐放

AI 激荡 70 载，ChatGPT 的横空出世瞬间火爆全网，

一周的时间用户超过百万。近期，随着 GPT-4、文心一

言、Google Bard 的迭代与发布，让大家领略到了 AI 包

括文字、图像、代码、音频、视频等内容强大的生成能

力，引发了新一轮的 AI 风暴，热议不断。

值得关注的是，人工智能的网络安全风险也开始暴

露，因涉嫌数据泄露意大利禁用 Open AI、三星因引入

ChatGPT 被曝机密资料外泄，ChatGPT 被推至风口浪尖，

又引发了大家对 AI 安全的新一轮思考。

ChatGPT 会对网络安全带来什么样的革命性影响？

作为安全行业从业者应该怎么应对安全风险问题和迎接

机遇与挑战？未来 ChatGPT 有什么样的发展趋势？

欢迎大家收看网安大咖说第二期：AI 狂飙—ChatGPT

会颠覆网络安全行业吗？我们邀请到人工智能领域专家

学者李涛博士、某跨国企业首席安全官赵锐，和两位嘉

宾主持、乐信集团信息安全中心总监刘志诚、网安加学

院院长宋荆汉，四位重磅大咖深度研讨、共同论道：

“近日，中国证券业协会组织起草了《证券公司网

络和信息安全三年提升计划（2023-2025）》。从科技治理

能力、科技投入机制、信息系统架构规划设计、研发测

试效能与质量、系统运行保障能力和网络信息安全防护

体系等六个方面提出要求，共计 33 项重点任务。券商可

参照实施，并制定配套实施计划。”

《安全提升计划》作为指导 2023 年至 2025 年券商

提升网络与信息安全工作的行动指南，券商行业该如何

参照实施并贯彻落实？行业甲乙双方如何提高相应的安

全治理能力以取得成效？ 2023 年网络安全有什么新的技

术趋势？

欢迎收看网安大咖说第一期——《拐点已至——2023

安全新风口》，我们邀请到安信证券安全总监李维春、

中银证券科技风险与安全负责人蒋琼，以及两位嘉宾主

持——乐信集团信息安全中心总监刘志诚、网安加学院院

长宋荆汉，四位重磅大咖共同研讨，为您答疑解惑：

网安大咖说第二期 AI狂飙—ChatGPT会颠覆网络安全行业吗？

网安大咖说第一期 拐点已至——2023 安全新风口

扫码观看上集 扫码观看下集

扫码观看视频

72

百花齐放 COMMUITY ACTIVITES

2 月 26 日，网安加社区举办的“ChatGPT 对研发管

理的冲击与契机”线下沙龙在深圳成功举办。本次活动

邀请到 HW 外聘高级顾问潘继平老师进行主题分享，吸引

了金融、互联网、制造业等多个行业的 CEO、管理者和

网络安全技术人员的热情参与。

最近，ChatGPT 在各行各业掀起了轩然大波，以一

副 AI 全能的姿态进入到大众的视野中。尤其在 ChatGPT

通过谷歌 L3 工程师编程面试的消息传出后，更是在各个

行业引发了群体性恐慌，被人工智能取代岗位的情形仿

佛近在眼前，但现实真如此残酷吗？

活动开始，潘继平老师从研发管理的角度出发，就

AI 对研发管理带来的冲击和如何利用 AI 提升自身价值

等方面进行了阐述。他认为，在当前 ChatGPT 带来巨大

影响的现状下，应该积极拥抱它，利用新技术实现自我

价值的提升。随后，潘老师分享了他在实际项目管理工

作中对于 ChatGPT 的使用经验，并分享了多款 AI 工具，

希望能帮助大家更高效地工作。

经过两个小时的激烈讨论，活动逐渐步入尾声。本

次活动是今年网安加社区举办的第一场线下沙龙，感谢

大家的参与。今年还会陆续举办多场线下沙龙与论坛活

动，敬请期待。

线下活动 | “ChatGPT 对研发管理的冲击与契机”线下沙龙成

功举办

线下活动 | 开源安全治理行业最佳落地实践私享会成功举办

开源技术广泛应用，正在引领信息技术的创新与

发展，在推动科技创新和数字化转型方面发挥着重要作

用，但也面临安全可控等诸多风险。4 月 1 日，网安加

社区在深圳星河艺术中心成功举办开源安全治理行业治

理最佳落地实践私享会，会议邀请到各行业开源治理权

威专家就当下备受关注的议题展开研讨，从各专业领域

分享理论实践。

会议伊始，网安加学院院长宋荆汉对各参会人员表

示热烈欢迎。他指出，开源治理已经成为全球开源生态

可持续发展的关键，涉及到政府、行业、企业、社区等

各方力量，并希望通过此次会议，共同探讨开源治理的

问题、思路以及解决方案，以帮助企业更好地实现开源

治理，促进企业业务发展。

——— 网安加学院院：宋荆汉 微众银行开源治理专家丛洋分享了《微众银行开源

——— 微众银行开源治理专家：丛洋

73

COMMUITY ACTIVITES 百花齐放

治理实践》：就为何需要建设开源治理体系、对企业开

源治理的思路和企业进行开源治理的路线展开了分享，

还介绍了企业开源治理组织“开源管理办公室”的重要

性及相关职能。最后结合具体案例，对如何以开源管理

制度和开源治理工具为抓手，落地企业开源治理要求展

开了详细介绍。

乐信集团信息安全中心总监刘志诚分享了《从建设

到运营——开源软件治理闭环之路》，他首先对开源治

理的背景做了简要介绍，接着介绍了开源软件风险的分

类，最后分享了开源软件治理方案，并就开源治理方案

的引入评估、应用审核、可信制品库、共享知识库和自

动化编排方面做了详细介绍。

开源安全治理解决方案专家汪杰分享了《开源安全

治理解决方案分享》，他提出，开源技术的应用带来了

大量风险，近几年开源应用安全事件频发、影响巨大，

当前开源技术监管工作已经全面铺开，针对开源检测技

术，我们需要知道哪些应用用到了开源组件、怎么使用

好开源组件、以及开源组件的安全工作应该如何展开，

最后他就开源治理的总体能力方案进行了阐述分享。

开源大势浩浩汤汤，各企业既是开源技术的使用

者，也能成为开源技术的贡献者。大家积极拥抱开源技

术的同时，也需要共同探索开源治理方案。未来，网安

加社区将在开源治理政策指引下，积极联合各开源治理

标杆行业、企业，开展各类开源治理技术分享活动，携

手各方，为开源生态建设贡献力量。

——— 乐信集团信息安全中心总监：刘志诚

——— 开源安全治理解决方案专家：汪杰

74

百花齐放 COMMUITY ACTIVITES

线下活动 | 2023 CI/CD 安全技术研讨会成功举办

CI/CD 作为现代软件开发的重要工具，为软件快速

部署和高质量交付提供了强有力的支持。2023 年 5 月 13

日，网安加社区联合 OWASP 中国广东分会在深圳南山共

同举办“2023 CI/CD 安全技术研讨会”，会议邀请到各

个行业的资深技术专家围绕 CI/CD 安全最新实践和行业

趋势展开研讨。

会议开始，OWASP 广东分会负责人肖文棣与大家分享

了《OWASP CI/CD Top 10》。他指出，CI/CD 环境、流程和

系统是现代软件组织的重要组成部分，OWASP CI/CD Top

10 通过对 CI/CD 相关攻击向量，以及被重点关注的攻击

事件和安全漏洞进行广泛研究，旨在帮助防御者确定其

CI/CD 生态系统安全的重点领域。

乐信研发安全负责人杨环分享了《安全左移的那些

事》，就研发安全痛点、安全左移必要性与安全左移能力

建设展开分享，其中重点介绍了安全左移的必要性以及相

关能力的建设实践，并结合具体实践案例分享了各个安全

测试环节的重点和实践经验。

某互联网公司应用安全专家 Luke 分享了《多维视角

下的 CI/CD 安全实践思考》，他先是通过一组数据分享了

当前安全的严峻现状和 DevSecOps 的重要趋势，接着通过

对 SDL/DevSecOps 的探讨和 CI/CD 实践思考两个方面分享

了他的议题，其中 CI/CD 实践思考部分详细介绍了能力视

角、评价视角、风险视角和挑战的内容。

某金融科技安全团队应用安全经理周亚军分享了《企

业 SSDLC 实践分享》，他从实施 SSDLC 的背景、落地 SSDLC

的实时路径以及实施的效果与不足等方面展开了精彩分

享，其中在落地阶段着重介绍了实施难点、应对措施与取

得的效果，最后他总结实施 SSDLC 的价值与意义“人力节

约 41 人年，效率提升 27%，中危以上漏洞下降 73%”。

随着 CI/CD 在开发流程中的广泛应用，CI/CD 安全已

经成为企业保障业务连续性和数据安全的重要一环。大家

在拥抱技术以寻求快速交付的同时，也应积极应对它所带

来的风险，在最佳安全和快速交付之间寻求适当的平衡。

未来，网安加社区将继续关注行业趋势，积极开展各类技

术分享活动，携手各方共建安全生态。

——— OWASP 广东分会负责人：肖文棣

——— 乐信研发安全负责人：杨环

——— 某互联网公司应用安全专家：Luke

——— 某金融科技安全团队应用安全经理：周亚军

75

COMMUITY ACTIVITES 百花齐放

76

网安加社区专家团自招募以来，受到了业内人士的

广泛关注。所谓众行者远，智慧与经验方面尤为如此，单

丝不成线，独木不成林，网安加社区致力于集合各方专家

和业内资深人士，为行业提供一个交流与学习的平台。

未来，在本社群的各类活动中会有越来越多的专家

现身演讲，公众号中也将推出更多知识技能文章，专家

亲自下阵，持笔挥墨。与大家共同努力，让我们社群的

每位成员都能够获得更好更快地成长——解困惑、交高

人、拓社圈、创机遇！

网安加社区专家团专家列表排名以入团时间先后为

依据，持续更新中 ......

网安加社区专家团

（专家团入驻聘书）

77

资深信息安全专家，曾任腾讯出行学院信息安全讲师。具备互联网行业、

金融、政务、能源、汽车出行、通信行业等领域的信息安全建设咨询与培训

的实战经验，服务客户均为行业头部企业。

成都极质软件有限公司创始人。美国伊利诺伊州立大学 MBA，6 年海外工

作经历。拥有 20 年 IT 领域从业经验，涵盖软件设计研发、项目管理、部门

管理、信息安全咨询、制度建设咨询等领域。专注于软件研发全生命周期体

系建设、企业数字化转型升级、基于大数据的综合治理、软件研发项目管理

等领域。曾为众多政府单位、央企、大型金融机构提供信息安全规划与培训

咨询服务。

上海青锁科技有限公司（麟学堂）创始人。上海交通大学网络空间安全

学院硕士，资深信息安全专家，曾任某大型央企信息安全主管，有多年甲方

信息安全管理经验，有大量金融行业、大型国企、政府等项目经验，精通网

络技术、信息安全技术，对企业信息安全建设经验丰富。同时有多年信息安

全培训经验，曾为国内多个大型金融机构开展相关培训。

晨星资讯高级安全架构师，OWASP 中国广东区域负责人，获得北京化工大

学计算机科学与技术学士学位，华中科技大学软件工程专业工程硕士学位。精

通 C、C++、Java、.Net 等多种语言以及现有的各种流行架构，在开发安全领

域深耕 17 年以上，对安全设计和安全开发有丰富的实战经验。持有 CISSP、

AWS 解决方案架构师和 AWS 安全专家等认证，多次参与安全书籍翻译工作，组

织、领导和独立完成多个 OWASP 项目翻译工作。

78

刘志诚，乐信集团信息安全中心总监，中科院心理研究所管理心理学博

士，印第安纳大学 Kelley 商学院金融硕士（MF），香港理工大学软件理学与工

商管理（MBA）双硕士。前中国移动电子认证中心（CMCA）负责人，OWASP 中

国广东区域负责人，CSA 大中华区数据安全专家。关注智慧城市，企业数字化

过程中网络空间安全风险治理，对大数据、人工智能、区块链等新技术在金

融风险治理领域的应用，以及新技术带来的技术风险治理方面拥有丰富的理

论和相关经验。

11 年网络安全从业经验，现任某金融企业安全负责人，持有 CISSP、

27001 LA、等保测评师等证书；从事过企业安全规划和建设、安全运营体系设

计与实践、安全生命周期管理体系设计与实践、数据安全、渗透测试和等保

测评等工作；参与、承担多项金融行业安全标准起草和课题研究工作；曾荣

获两次网络安全技能竞赛“一等奖”和福建金融网安技能竞赛“五一劳动奖章”。

某金融企业网络安全专家，11 年网络安全从业经验，曾就职于华为技术

有限公司，担任高级安全架构师职位。多年专注于网络安全领域，熟悉各大信

息安全体系以及相关法规标准，掌握多项前沿技术，在网络安全与隐私保护方

面具有丰富的管理与实践经验。熟悉 ISO27001、网络安全等级保护、GDPR 等

信息安全体系和相关法规标准，可基于企业业务战略和风险管控制定信息安全

总体规划，并推动落地；熟悉主流的安全工具、产品和技术，具备产品架构安

全，云、管、端、数据安全、安全审计、监控运营、隐私保护等各领域信息安

全建设落地经验；熟悉信息安全风险评估、STRIDE 威胁建模工程方法。

OWASP 中国北京分会理事、成都市发改委经济体制改革智库成员、川大

技转智谷科技转化中心科学经纪人、四川省绵阳市三台县公安局反诈中心外

聘专家顾问、中国卫生信息与健康医疗大数据学会首届委员、紫光软件系统

有限公司成都分公司网络安全专家顾问、【登峰造极】系列讲座联合创始人，

获得《ISO27001 信息安全管理体系认证证书》、《国家技术转移专业人员能力

等级培训初级技术经纪人结业证书》。目前公司在重组合并阶段，主要在以辅

助国安、公安等执法部门打击犯罪的基础下，通过国家安全视角，集技术、

人才、产品等为一体，构建多维度的全行业产业生态链并覆盖到每条产业链

的重要节点，落地到一体化、多元化、可视化，促进自身发展，补全行业短

板，推动行业发展。

79

脑动极光首席信息安全官、OWASP 中国北京区域负责人、西班牙 UAB 大学

硕士、北京某高校网络空间安全学院研究生导师、网络安全研究生实习基地导

师、中国卫生信息与健康医疗大数据学会首届委员，参与编写 GB/T 39725 健

康医疗行业数据安全指南、三个健康医疗行业标准，荣获国家三级荣誉证书（技

术贡献类）。网络安全行业从业十余年，曾于金融集团、上市企业及互联网企业、

Top 国企担任安全负责人角色，负责基础安全、法务合规、隐私合规、安全研发、

风控及业务安全、SRC（安全应急响应中心）、数据安全、内审内控等工作。

现任开源网安交付中心总监，开源项目爱好者。具有软件开发、项目管理、

产品设计背景，从事网络安全行业十余年，前 IDF 互联网威胁情报实验室执

行负责人，负责实验室产品开发、安全研究和安全运营工作，曾任互联网金

融企业、SaaS 企业信息安全负责人，负责安全合规、IT 审计、软件安全、基

础安全、数据安全、安全运维和安全研发等工作，熟悉软件开发、研发管理、

产品设计、SDL 和 DevSecOps。

华为土耳其研究所外聘高级项目顾问，负责华为云应用生态圈产品线研

发管理。曾为华为全球技术服务中心、华为制造 IT 以及华为流程 IT 解决方案

提供等多个部门提供长达 8年的顾问服务。也曾任职环信科技华南区项目总监，

金蝶国际软件研发工程师。获得 PMI-PMP、PMI-ACP、PRINCE2、NPDP、MSP、

P3O 等认证。拥有 1 项国家专利，4 项软件著作，具有丰富的项目管理实战经验。

毕业于北京工业大学，中国计算机学会（CFF）会员，上海开源协会预

备个人会员，著有图书《软件测试技术实战 - 设计、工具及管理》、《基于

Django 的电子商务网站设计》、《全栈软件测试工程师宝典》、《通过案例

玩转 JMeter( 微课版 )》。软件绿色联盟 2018 年最佳优秀讲师第一名获得者。

先后就职于炎黄新星网络科技有限公司、中兴通讯股份有限公司、意法半导体

（中国）有限公司和爱立信通信（中国）有限公司担任软件开发工程师、软件

测试工程师，软件测试经理等职务，积累了丰富的软件研发测试的理论和实

践经验。精通软件测试基础理论、测试设计、测试管理、安全测试、性能测试、

自动化测试、敏捷测试和 DevOps 测试技术。从 2015 年起，从事金融、通信、

航空、邮政、高校等企业的从事软件测试咨询和培训服务。

80

腾讯 DevOps 与研发效能资深技术专家、腾讯研究院特约研究员，前百

度工程效率专家、前京东 DevOps 平台产品总监与首席架构师，曾任埃森哲、

惠普等全球五百强企业咨询顾问、资深技术专家。长期在拥有数万人研发规

模的一线互联网公司，负责研发效能提升、研发效能度量体系建设、敏捷与

DevOps 实践落地及 DevOps 工具平台研发工作。作为 DevOps 运动国内早期布

道者与推动者，目前是 DevOpsDays 国际峰会中国区核心组织者，国内多个

DevOps、工程生产力、研发效能领域技术大会联席主席、DevOps 与研发效能

专题出品人。《研发效能宣言》发起人及主要内容起草者，EXIN DevOps 全系

列国际认证官方授权讲师、凤凰项目沙盘授权教练。著作：《软件研发效能提

升实践》、《软件研发效能权威指南》；译著：《独角兽项目：数字化转型时代的

开发传奇》、《价值流动：数字化场景下软件研发效能与业务敏捷的关键》。

东南大学电子工程系本、硕，南京大学 EMBA，PMP，现担任科大讯飞智慧

城市 BG 软件质量负责人，曾就职于中兴通讯、摩托罗拉、趋势科技、初速度

等国内、国际名企，多次负责过质量体系从 0 到 1 的搭建，DevSecOps 工具链

的建设及在公司内的大规模落地，日活用户超千人，践行软件质量与效能改

进的体系化、线上化、自动化、数据驱动化。

近 10 年安全行业从业经验，5 年 + 团队管理经验，长期负责企业安全建

设，探求安全体验与效率并存的安全能力和解决方案建设。熟悉公有云安全、

数据安全、基础安全和安全运营等领域，擅长企业的信息安全解决方案高效

落地，并有体系规划和安全运营实践经验。在企业安全产品方案选型和建设（特

别是数据安全）、解决方案规划与落地、安全运营能力体系化建设等方面具

备独特理解和全过程实践经验。

81

本科毕业于西南交通大学，硕士毕业于中南大学，目前中南大学博士在

读，具备计算机领域专业背景和根基。先后就职于中国中铁五局、株洲中车时

代电气股份有限公司、广东 OPPO 移动通信有限公司等大型集团企业，目前任

职三一重工股份有限公司信息安全负责人，全面负责三一集团的企业信息安

全战略规划、企业安全体系架建、安全人才队伍建立和培养等。深耕行业十

余年间以扎实的理论基础付诸于实践，紧跟信息化、数字化时代的发展与演

进，从战略到体系，从体系到落地，具有非常丰富的实战经验。OPPO 和三一

集团工作期间，根据企业的不同属性、不同环境，都是从 0 到 1 完成了信息

安全队伍建设，从有到无完成了集团安全体系搭建，带领团队一次次突破，

通过战略规划与落地共同支撑企业数字化战略的实现。

毕业于中山大学网络工程专业，现任某金融科技企业安全团队负责人。

曾任职于多家头部世界 500 强企业，从事网络安全工作十余年，熟悉各行业

的信息安全建设规划，对企业安全合规、个人隐私保护、安全治理等方面有

较丰富的经验。

诸子云上海会长、某跨国企业 CSO、专利发明人，历任多家金融机构、世

界 500 强企业的安全负责人、安全专家。有近 20 年科技风险、信息安全、数

据安全、业务安全等领域的丰富经验，是多家机构的专家和顾问。曾在银监会

《金融科技治理与研究》杂志发表论文《“互联网 +”环境下银行信息安全风

险之应对》，参与并已出版的有《DevOps 三十六计》、《反黑客的艺术》、《上海

金融信息行业发展报告》、《云安全现状年度报告》、《CSA GDPR 合规行为准则》、

《从网络安全转向业务安全的价值实现》、《信息安全人员如何与业务人员沟

通》、《云端数据安全浅谈》、《2020DevSecOps 企业实践白皮书》、《亚太数据合

规手册》、《CISSP 权威指南（第 8 版）》、《网络服务安全与监控》、《云安全控

制矩阵 (CCM）4.0》、《CSO 进阶之路》、《云图·云途》，即将出版：《零信任安全》、

《网络安全法律法规关键术语释义》。

官方公众号 官方微信号

邮 箱：891929369@qq.com

地 址：深圳市龙华区民治街道民乐社区

星河 WORLD 二期 E 栋 4F