0x00 前言
近来数据泄漏事件频发，某市更是高发，不一一列举。作为从业人员或多或少有所感触，闲话一二，记录于此。
0x01 数据保护(Data Protection)
谈及数据隐私(Data Privcay)或者隐私保护(Privacy Protection)，本质更在于人(Data privacy is not about data but person)，而不尽在于数据。因此更多的是关注在收集，传输，存储，处理，分享，销毁等过程的合规性。至于数据安全，才会更关注数据以及数据本身的价值。因此更多的是对数据在不同状态（Data at Rest/Data in Transit/Data in Motion）下的安全性（加密解密，秘密分享等）。在实际的数据治理时，也是由不同团队协同去做，所以要先把概念稍稍区分开来。不过即便是不同的团队去做，也要同时关注Data Privacy与Data Security。除此之外，数据分类分级(Classification)，打标(Tagging)，追踪(Tracing)则是通用的手段。
如果从数据分类的角度出发看数据保护，那么除了对不同状态的数据设置对应的安全控制措施还需要去确保数据提供方/使用方确实遵守了安全控制。
可以看到图中针对C1的数据是不允许存储，C2-C3的则要求使用基于HSM的密钥进行加密保护，同时针对C1-C4的数据在传输过程中都需要使用基于x509证书提供的TLS服务。而C5的数据则不做要求。同样在销毁过程中，针对存储介质是否复用，是否离开控制而提供了不同的处置措施。
上述这些都是从数据本身出发的，而数据显然是存在静态和动态之间的转换过程。针对这些过程以及数据本身的控制，仍然需要相应的技术支撑。例如统一接入数据源，通过扫描数据对不同的数据进行分类，打标。统一访问权限控制等等。入的时候对文件提供额外的病毒扫描，出的时候提供统一的3rd file sharing工具，以及经过DLP等。至于集团内不同BU间的数据吐给风控或者需要做分析的一些部门/合作方时，可以适当使用隐私计算的一些措施，例如FL。
除了上述之外，还有一些值得思考的点：
- 数据隐私的定义是缺乏legal definition的，不同行业，不同地区都不一样。怎么去做分类分级需要详细参考当前行业。
- 谁去实现数据分类分级的定义？法务、审计、内控、合规、安全还是？
- 梳理出访问数据的角色和场景(user/application)之后，是否要设置不同的控制措施？
- DLP的作用范围有哪些？(Host/Network/Cloud/Cloud Apps/Mail)
- DLP怎么和UEM以及准入类（SASE）工具互相配合，划分界限？
- 如何确保你设计的3rd file sharing 工具是合格的？
- 如何为默认的规划建立Exception的流程？例如禁止卸载某些软件-允许卸载某些软件。
- 数据仓库在建设的初期安全怎么加入进去？如果不能后续怎么参与进去？（这里不仅是数据本身，包含节点的认证、用户的访问控制与权限、日志的脱敏、源数据的维护、网络的隔离等等）。
- 数仓是不是提供了租户功能，使得安全部门能作为一个租户去存储相应的数据？
- 数据表的权限划分与申请是仅有审批流程背书，还是即具备审计日志，也划分了仅权限内的表？
- 如果没有数仓，仅仅使用SIEM类的工具，或者ELK类开源工具去收集数据，又该如何实现上述的安全控制措施？
0x02. 密码学(Cryptography)
从第一节里不难看出，针对数据在静态，传输，流动中都大量使用了密码学相关的技术完成了安全控制。例如静态数据加密，根密钥的分量合成，加密即服务以及透明加解密等等。作为逻辑上的基本保障，完成对数据的保护。加密基础设施可以说是做数据安全的关键之一。针对这一块的能力建设，之前的博客已经总结过几次了。此处不再赘述。
0x03. 身份认证及访问管理(Identify & Access Management)
身份认证和访问管理意味着谁能通过认证，获得了什么样的身份/角色，对应的获得什么样的授权，因此可以访问到什么样的数据。在企业内部，一般通过HR系统(e.g. Workday)完成provision user，然后同步数据到目录服务(AAD, AD等)，接着通过IDP提供认证服务。与此同时Application(Service Provider)也需要完成接入IDP的配置。这样就形成了用户访问SP应用的时候，跳转至统一的登录界面完成认证(User/Pass+MFA, Cert + MFA, OTP) ，随后获得在相应系统内的权限。这里常用的协议有SAML，OIDC，Radius，LDAP等，当然如果可能尽量选用基于TLS的，例如LDAPS，RADSEC等，同样的OIDC尽量选择PKCE模式。
不过这里吐槽下不同产品对SAML协议的实现(其实也不仅是SAML…)，真可谓一言难尽，导致出现了各种奇奇怪怪的配置。尤其是Fireye家的产品，同一个产品线的配置 有的时候attribute和value居然完全是相反的。例如在hx上配置的是admin=”appliance.role.default”, 在ETP上就变成了appliance.role.default=”admin”。在用户手册都不能起作用的情况下，只能靠多次尝试才能解决问题。类似的还出现在SAAS服务的SSO集成过程中，有的支持配置，有的需要提交信息给到厂商完成配置，有的提供自定义界面，但不支持更改callback地址，然后callback地址是个内网的。
除此之外可以使用硬件Key来增强整个认证流程, 当然也可以在TEE内完成私钥的存储和计算。
这里还简单列了一些需要思考的点：
- 如果存在不同BU的账户体系，是不是应该进行统一？如果不能够统一是否能够做到用户和实体的映射？
- 如何实现应用系统的权限和IDP的同步？例如使用SCIM协议。
- 如何实现权限申请流程到赋予用户在目标系统权限的自动化流程？即如何结合工单流程同步权限。
- 怎么提供web界面访问的和命令行访问的统一凭证，类似的如何针对用户和应用的认证提供标准规范。
- 用户权限的自动化回收？例如离职了。
- 云环境下的身份管理是不是可以结合云产品本身？例如, AWS IAM.
- 服务账户的管理？服务账户密码的轮换等等。例如tenable使用vault存储主机账户密码完成扫描的同时实现密码的轮转。
- 准入的维度是终端还是用户？使用VPN还是SASE？
- 如何取舍Passwordless？
- 统一认证后的登出是软登出(本地删除token缓存)还是硬登出(从IDP处登出)？硬登出是不是仅登出自己的应用？
0x04 总结
近来愈发感觉部分数据安全的工作内容其实是从原来的基础安全和应用安全中抽离出来的，然后逐渐演变的更加专业，更加系统化。例如PKI在多数企业里是在基础安全里，证书管理，密钥管理等是在应用安全。目前也都逐渐归拢到数据安全统一去做。但数据安全的工作多数还要依赖于基础设施的建设，安全运维也好，安全平台也罢，就不在此赘述了。不仅需要注意系统架构的标准化(可参考前面写的一些文章)，同时还需要将安全能力下沉到基础设施作为安全治理的一个主要目标。