10月19日，“诸子云·分享汇”线上直播第二季正式拉开帷幕。

作为社群活动计划的重要环节，本季线上直播邀请百家智库首批专家作为分享嘉宾，围绕涵盖等保合规、数据安全、个信保护等共计20个主题，计划开展10场分享活动，共同探讨企业网络安全实践之热点、焦点、痛点、难点和要点。

本文即对第五周直播实况的回顾。本周共开展两场分享活动，友邦资讯科技云安全经理杜建荣、某金融科技安全人士蔚晨、安言咨询总经理钱伟峰等三位专家分别进行了议题分享。

如今，随着疫情持续与数字经济的持续发展，企业上云已经变成一种大势所趋。为什么要上云？对于企业来说，我认为有四大优点：

1、节约成本。前提是真正把云用好，如果采用传统旧思维去使用云，可能耗费的成本会更多；

2、安全合规。这是使用云的一个重要方向。数据本地化的运营方法，可能会发现人手不够或安全产品能力不足，改造起来比较痛苦，使用云则更容易实现安全合规的目标；

3、云上的产品便捷易用。成熟的云原生产品相当便捷易用，一般比自己研发或购买的安全产品更加可靠匹配；

4、业务形态更适合云环境。主要针对电商、游戏、直播等新型业务形态，这些业务形态更加适合云环境。

公有云上云之后，又会带来怎样的挑战呢？我认为主要有五个方面：

1、开通公网访问很容易。对于一个云上业务，开通公网访问其实比以前更加容易。除了虚拟服务器、PaaS架构以外，其实很多SaaS架构拥有自己的公网访问的端口，并非架个防火墙或WAF就能挡住所有访问。对于云来说，它有各种各样的公网访问的路径。如果对云不熟悉，很可能会忽视；

2、不容易掌握资产的全貌。如果不恰当地给了业务一些权限，业务可能会在不知不觉中开通了很多新的服务，有一些SaaS的资产你可能从一两个网页控制台无法找到。因为云的每一个服务、产品，都是通过不同的控制台、控制面板进入，这样就可能成为一个安全漏洞；

3、云上资产可以通过API去访问及调用。对云不熟悉或未深入了解的人，可能会以为只要控制好运维端口、网页访问，别人就无法访问自家云上资产。实际上并非如此，相关API只要你有一个云上AK的账号，有相应的权限，你去API那里调用，就可以访问到云上的资产。这种往往防不胜防；

4、账号管理体系非常复杂。通常云都有通过网页端访问的云上账号，还有PaaS的一些产品都会有自己的账号，如果你开了一个云上数据库，数据库也有自己的账号，如果你把数据库的地址开放给公网，只要有数据库的账号，同样能登陆进去。整套账号下来，你会发现云上会充斥各种各样的账号，管理起来比本地更加复杂；

5、云平台在什么地方都可以登录，数据从哪里都可以下载。特别是登录的这一块，如果账号没有设置白名单、常用登陆地，那么什么地方均可登录。即使你设置以后，也有一些二次验证被攻破之后，也能登录成功。

所以，我认为云上安全有三条基本原则：尽量使用云原生（或云市场）的产品；所有产品或服务的调用都需要有日志记录下来；对权限的授予需要非常注意，遵循最小特权原则。

此外，我还在工作实践中，总结出了公有云安全中容易忽略的六大细节，比如说互联网出口、网络、服务器、数据库、SaaS服务、账号管理以及其它类型。

就拿数据库来说，我人为有四点细节容易被忽视。

1、云上的PaaS DB如果没有合理配置白名单，可以从互联网直接访问。这与本地的DB会有明显的不同，本地的DB基本上不会开放给互联网访问。我帮许多小企业做安服，发现许多企业会直接把后台数据库的登录开放出来，也未配置白名单，导致整个互联网都可以直接访问它们的DB；

2、数据库的审计功能往往需要单独开启（可能需要收费），默认新建的数据库不具备审计功能（单靠binlog日志的审计功能很弱）。云上数据库审计其实不太容易，和本地不太一样，所以操作起来存在诸多疏忽的地方；

3、没有开启数据库备份功能；

4、没有开启TDE或SSL加密功能。若是开启，会损失一点云的性能，但其实不会对业务有太大的影响，现在有很多优化数据库访问的方式，所以这些功能在云上建议开启。

最后，我认为公有云有四个容易踩的坑：公有云通常已做了等保，是否代表企业自己不用再做？是否需要用到行业云？跨云环境下的策略以及工具应该如何统一？跨云环境下的数据传输。

本篇首先介绍金融业务数字化安全发展的历程，是为了在金融业务数字安全典型场景达成一定的共识；第二部分主要是金融业数字化安全的三个典型场景，在这些典型场景下用到的技术包括实施过程的经验及教训。最后做一个简单的总结。

金融业务的属性，对于金融业信息化及信息安全化具有更高要求，即稳定、成熟、合规属性强。从而我们得知，金融科技信息安全工作的本质，就是对业务数字化过程中的风险进行管控，在事前、事中、事后的不同阶段，通过组织流程、技术管控、检测评估等不同手段保障信息的安全，从而支撑业务的有效、可用。

金融业务数字化发展历程可以追溯到70年代手工录入电子化设备起步，80年代随着计算机的普及，业务流程开始电子化的实现，直至90年代末期，金融业的数字化进程才得到了快速发展，标志性的节点就是网上银行的诞生；经过20多年的发展，10年代进入互联网金融的阶段，提出开放平等协作共享等口号，随着互联网金融的发展发展到现在的数字化金融阶段。

现在金融科技产业的生态及金融业务服务都发生了很大的变化。而金融机构不仅仅是借方、贷方，同时也是场景提供方、金融产品提供方、软硬件技术提供方、算法产品解决方案提供方，所以现在金融机构的服务也是比较复杂，金融产品的形态及金融业态也比原来点对点的柜台式服务复杂得多。

所以，在金融科技高度参与的服务下，如何提供一个相对安全同时又是全生命周期的服务，也是现在高速发展的金融数字化的巨大挑战，这也是我们金融行业尤其是IT金融从业者必须面临的挑战和风险。

其实各行各业应该是一样的，我们都应该认可由科技支撑业务的发展，由安全保障科技发展中的风险运营控制，最终完善数字化发展中的过程。

特别是现在银行4.0的时代，金融行业的业务特性主要有三点：1、服务营销化，即数据从业务前端向分析后端转移；2、交易场景繁杂，即多方参与下的灵活交易组合；3、数据异构化，即内部数据与外部数据，结构化数据与非结构化数据。

同时也面临着诸多安全挑战，比如原先我们认为是一头一尾，边界防御从外部需要防止入侵，到内部需要防止数据泄露，慢慢演变到边界防护与零信任，审计与追溯，到现在越来越依赖于不仅是要比较健全的数据安全治理，以及数据安全的一些防护特性和防护手段，而且越来越快速要求这些结果能符合业务快速变化的要求。

基于这样一个业务特性与安全挑战，我从我们已经做的这些跟安全相关的技术方案和产品类型之中，选取了三个比较典型的场景，与大家进行讨论和分享。首先是复杂终端下的安全问题；其次是实时交易场景下的应用安全问题；最后是数据治理与管控场景。

复杂终端下的安全问题比较复杂，需要统一消息总线、统一安全总线、统一服务总线，分别进行消息服务状态监控、安全审计与监控、业务服务状态监控。

另外就数据治理及管控场景而言，这个会更加复杂，涉及到数据摸底、数据资产定义和数据安全管控等问题，其实这个场景主要是为了支撑我们数据安全治理平台当中底层支撑的业务场景，这也是为了去满足金融行业对于数据的快速、准确、安全的要求而促生的数据治理的要求，以及数据安全治理要求的背景下，我们去用很长时间去推动的安全解决方案。

这个场景的设计理念主要有业务人员参与数据分类模型设计、多维度数据分级、数据资产交叉验证、数据分级与动态处置、数据资产分级分类持续迭代等。

我们把数据定义、数据应用场景疏离、数据安全脆弱性检测、数据安全风险建模、安全技术和安全管理等要素，形成了一个相对来说比原先更加可落地的治理闭环。每个场景当中，我们都有具体的治理工具和手段。

比如数据定义，通用型敏感数据包括姓名、手机号、身份证号等；业务型敏感数据包括征信欣喜、资产信息、账务信息等。

数据应用场景识别，则有网络流量分析，利用正则和机器学习算法对应用层的敏感数据流动事件进行标记，直接关联定位敏感数据应用场景。

数据安全脆弱性检测层面，同样使用网络流量分析。比如利用算法对数据暴露面进行全方位脆弱性分析，包括暴露面设计脆弱性、高危暴露面检测、暴露面越权风险、数据传输风险、数据流向合规脆弱性等多个维度。

最后我展望一下金融行业安全数字化转型过程的一些情况，其实这个过程挺辛苦而又漫长，并且从一开始不那么被人支持和理解，现在慢慢地的到越来越多的认可和关注，同时也给我们的安全数字化的工作带来很多压力。

上述提到的各种场景和环节，其实也是通过我们的各种手段，不断试错、碰撞，去跟业务进行各种讨论，在不断尝试当中慢慢确定下来，我也不敢说这一定是最终的一个结果，可能还会有更多的一些发展，可能也在新的技术、新的理念、新的业务的触动下，进一步完善丰富。

同时，也是因业务不断地丰富和发展，催生出整个金融科技的标准化、规范化和数字化的过程在不断地提升。这个不断提升的过程，其实也在促进着安全的不断渗入。

个人信息保护合规要点解读其实是个可大可小的题目，本篇主要是结合场景如隐私政策和策略设计等经验，尝试换一种与传统不一样的思路来解读。

在个人信息保护法之前，我首先放了一张《个人信息保护法》的立法沿革，今天的分享是基于《个保法》去分析的合规要点，虽然《个保法》是我国目前针对个人信息保护最为直接也最为明确的相比网安法得到了很大强化的法律，但是依然要考虑到实际的合规过程中，不仅仅要考虑《个保法》，还有一些特定的要求比如部委的法律法规法文等相关的东西。

以往在跟客户做培训时，要强调《个保法》合规要遵循及规避相关的风险，避免自己所在的企业遭受处罚，当然网安法处罚力度是最高100万元罚金，个人信息保护法是5000万元以下或上年度营收额的5%。

从《个保法》的要求来看，不能单独看作网络安全法的领域细化和可操作性的加强，还可从另外一个角度去看，企业在做个人信息合规的过程中，网络安全法作为最顶层的基本要求是要考虑的，《个保法》也是要考虑，数安法也会提到一些相关的。

在实际操作层面，还有一些法规规定标准要去遵守。比如2013年的电信和互联网个人信息保护规定，虽然年代久远但是国家没有宣布失效废止就依然有效。其实，两高司法解释在个保的合规层面的冲击力比个人信息保护法更高更大。

《个保法》都是根据个人信息处理规则来决定的，首先不得过度收集个人信息，收集个人信息的尺度在哪里，则是需要我们要重点关注及把控的。过度收集业务之外的信息，就会带来很多不必要的麻烦。比如收集未满14周岁的个人信息，均属于敏感信息，因为收集个人信息和个人敏感信息的保护要求是不一样的，所以收集个人信息是有很多延伸的法律法规去考虑。以前“法无禁止即可为”，现在有规定则需要按规定《常见类型移动互联网应用程序必要个人信息范围》去做。

禁止数据歧视，对大数据运用质量不高而造成的数据歧视形成制约，将个人信息质量作为法定义务，有助于督促个人信息处理者提升数据获取的准确度。其中强调要有关闭个性化推荐的规定和引发的“大数据杀熟”。

人力资源管理纳入范围，比如人脸打卡考勤，人脸属于生物特征信息及敏感信息，应该获得授权同意，需要明确告知员工用途并要员工签字确认。

撤回同意便捷化，这在合规中比较难操作。比如在收集信息撤回后，应做匿名化的处理，但是在实操中客户只对部分功能授权的撤回而不是针对app的撤回同意的授权，在业务处理中比较难操作。

告知信息同意与例外，体现了个人信息处理者在处理前的告知义务以及取得同意的前提条件。

安全技术措施的采用及加密在实操中会带来的问题，以金融行业为例，(JR/T 0171—2020)即《个人信息金融保护技术规范》，在此规范里分为C1、C2、C3三个级别，但是由于企业的地域规模等不同，而在算法保密措施中又没有具体的要求，所以需要明确同行要做到的技术并去完成。

个人信息保护技术防范建议只是给大家一个启发。事前需要做识别；事中是知道数据后需要各种视角去看，在信息传递的各个环节去做监控或拦截还是做环境隔离、操作审计抑或去标识化/匿名化，在事前事中用UEBA技术去分析企业内部操作行为对高价值数据的流动及访问进行自动化风险识别和告警；事后做追溯。

推荐阅读

诸子云·分享汇 | 首周直播实录

诸子云·分享汇 | 第二周直播实录

诸子云·分享汇 | 第三周直播实录

诸子云·分享汇|第四周直播实录