0. 综述

之前也写过几篇关于数据安全的文章，有兴趣的可以翻下之前的博客。本文整理了一份脑图，不过不会详细介绍数据分类分级，也不会去讲全站 TLS 之类的安全项目，以及 KMS、PKI 等如何建设。更多的是关注在整体的联系。

整体来说是通过一些政策/规范去支撑技术实现，然后通过定期的安全教育和审计检查实际运营的状况。安全教育和企业安全文化看起来很虚，实际上在基础建设到一定程度之后就显得很重要。因为意识往往在第一防线，甚至超过了工具。脑袋里要保持什么数据可以传输到什么地方，什么数据不可以在什么地方保存。永远保持对外部输入信息的警惕。

数据分类分级是进行数据治理（数据治理是个话题复杂且实践更复杂的东西）的第一步，当然考虑到不同的业务、产品、基础设施。不同企业推进的方式也不一样，可能落在数据团队上，也可能是风控团队，也可能是内控团队，或者共同协作（数据治理的标准方式，不过注意要在最初就区分开不同团队的职责）。实际来说，安全团队推动分类分级的落地成本要远比想象的高，而输出分类分级政策可能是较为合适。通过对不同级别数据在整个生命周期里的约束，来保障数据安全。但常用的保障技术又绝非仅仅数据安全技术。实际在架构设计中，除了加密，令牌化，脱敏之外还需要考虑身份认证及授权，网络访问控制，日志监控和审计。换句话说，需要作用在基础设施的安全控制之上。只有划分好了不同等级的安全域，建立了网络隔离之后，才能把对应等级的数据放到对应的区域中去。受限访问的 PCI 存储和控制区域和非受限的 PCI 存储和控制的访问也是不同的。至于到对应区域内，应用服务和管理后台又是不同的访问方式，身份认证的要求，传输的要求等等。另外针对客户的端上数据存储也需要有对应规范。

下面简单的看一下办公网和生产网整体的数据安全架构设计。

1. 数据安全架构

1.1 办公网数据安全架构设计

本来是想展示原有架构怎么过渡到目标架构的。但后来一想实际情况各家又不一样，不如简单挑一下几个关键点说一说。

1. 分离服务和控制平面 这个借鉴了微服务的术语，其实比较好理解，就是把资源生产和资源使用分开。比如 AWS Console 就是控制平面，创建的都是服务资源。不过这种划分并不尽然，在 AWS EKS 中，对 EKS 的访问又属于控制平面，对 SVC 的访问则属于服务资源。遵循的原则就是 SOD 及最小化权限原则。确保非必要的权限不会流转出去。

2. 分级控制访问终端 企业内的办公终端除了 Laptop，手机之外一般还会有虚拟桌面，AVD，VDI 之类的，这一类一般称之为瘦终端。针对不同级别的终端在建立标准化的安全控制之外，仍需要分级控制。例如 Mobile 端可以访问 Service，但不可以访问 Portal，一些敏感系统需要在 Laptop 和 Citrix 之后。同样，针对不同用户群体也不相同，客服的终端永远不应该访问 Bastion 等等。

3. NACL 这个话题比较常见，后面在生产网的架构图里也会讨论。这里先聊办公网的，针对网络 ACL，协议，端口这些都不做讨论。需要注意一点就是层级依赖导致的 NACL 传递失效以及目标系统对 NACL 的支持。比如某 Cloud Service 配置了 SSO 登录，SSO 做了 NACL 限制了访问 IP，但在登录 Wiki 成功之后，由于该系统本身没有配置 NACL，导致 Session 可用的情况下避开了检测并能直接导出数据造成数据泄漏

4. 条件访问、SSO 与特权账户管理不同的系统必须采用统一的 IDP 进行登录认证，并完成授权。并且能够针对登录行为通过网络位置、认证难度等条件进行限制，允许登录与否。同时针对特权账户进行单独管理。比如拆分特权账户和普通账户之后，再结合条件访问，仅当允许来自某某 IP 段的可信设备完成 MFA 之后，方允许登录。在此之外，还需要做相应的日志和监控。

5. 检测及处置 运营模式会放到后文数据驱动的 SOC 安全架构里面去讲。关于检测来说，办公网的数据大多为非结构化数据，而且类型复杂。在用户权限降低，账户登录受限并仅能访问到合适的文件，安装必要的软件之后，仍需要检测出向的数据。一方面通过信息标签，设置默认控制手段，并敦促用户手动调整文件等级。一方面通过 DLP 工具，在端上和网络层进行检测。技术手段之外就是考核和培训了。办公网的数据安全主要集中在终端的管控上，可以参考之前写的浅谈终端安全与 DLP 治理, 而对于向终端用户提供服务的，属于 Corp 这一侧的东西后面暂时以 Prod 纬度去看（注意不是以 Corp/Site 纬度）

1.2 生产网数据安全架构设计

相对于办公网而言，生产网的数据结构良好，模式固定。生产网的数据安全治理远比办公网要轻松的多。

1. 边界防护 需要关注访问控制与网络隔离，外部流量透过边界进来需要流量清洗，IDS，WAF 等，办公网到生产网的边界隔离及控制。生产网内部不同区域的网络隔离等等。不过 NACL 这里，需要考虑四层和七层。以 AWS EKS 举例设置安全组时如果使用 AWS CNI 插件并且采用的是 ENI，那么 ENI 绑定的 IP 发生变化时可以被检测到并自动调整，所以并不影响 POD 级别的安全组。不过如果使用的是 Trunk 模式，就安全组只能作用到 Node 级别。如果使用 K8S 的 network policy 则需要要求 Pod 内没有四层 svc 才行，否则也无法解决安全组响应 IP 的变化。

2. 出网审计 其实也是边界的一部分，单独挑出来是因为出向流量着重被管控到。其实也是收拢数据传输通道之后，开辟受限的安全通道，并只允许针对固定的协议等。

3. 密钥及加密 之前讲太多了，不讲了。一是密钥的价值等同于数据的价值，二是注重根信任的传递，不要使用自创的加密算法。看了一些“复杂的”自创加密算法，简直头大。建议采用被批准的加密算法，通过根信任传递去创建密钥。不过需要量力而行，考虑到预算，毕竟 HSM 和公签的证书都不便宜。

4. 备份及恢复 小到数据库的快照，大到 DR 中心的建立，备份的恢复算是最后一道防线了。是通过同步实现备份，还是通过快照备份？如何对快照加密？对备份的访问控制？谁有权限进行恢复，备份的完整性等等。

5. 检测及处置 这部分放到了 SOC 的架构中，见下文

这里 ServeMesh 内部细分的话还有一张单独的架构图，暂时不讲。另外除了数据保护平台之外，还需要数据扫描平台，数据字典，元数据查询等工具。

1.3 数据驱动的 SOC 安全架构

之所以把这一块单独拎出来，是因为数据安全的事件运营其实是可以合并到 SOC 中去的，并做到 Data-Driven。这里隐去了一部分细节，着重关注下 SOC 的 Workflow。数据安全事件的检测和处置也只是其中一种，原理类似。

采购或自研的系统或者产品完成标准化的系统能力之后，通过对不同场景的运营并针对具体工具形成 SOP，并由此切入自动化运营，而具体 playbook 的执行又是作用于相应的系统之上。在这个过程中，完成了运营的第一阶段，而数据驱动就是以此为基础，将各种数据汇集处理之后进行检测等等，以此产生新的告警和事件，并触发相应的 SOP。而针对整个运营质量，则以可视化看板为主。告警的误报率，部署的覆盖率，平均响应的时间，场景的触发等等。

还是要吐槽一下，搞运营不是搞话术，东扯西拉的。水平不够就要学，不能瞎逼逼。另一方面，没有经验的 Leader 也无法有效识别输出的质量。

还有一个老生常谈的话题，就是运营-技术-管理，做一件事，尤其是运营（运营去处置，架构去设计等等）一定需要体现政策，流程，工具的结合作用。要有政策支持，标准化的流程，以及平台或工具实现。无论是架构设计还是安全咨询等等，最后都要进入常态化运营阶段的。野路子另说，野路子太野了。举例来说，没有 Policy 约束的话，日志应该跨云怎么办，能不能跨？

另外时常看到有人无法区分政策规范流程的，这里我简单画了个图

另外定 Policy 的时候需要考虑到是为了落地适应现状，还是说为了引导现状的改变。如果只是为了适应现状，具备某个 Policy，以便通过某些检测。那就变成了，我已经有了某些合乎标准/或不合乎标准的东西存在，然后把这些东西放在文档里。检测的时候我们有了这个 Policy，只是政策的颗粒度不够细，所以“后面会修改”。当然更多的时候可能只是你有这个 Policy 就行了，内容甚至都没有人看。另一种是，通过 Policy 支撑技术约束落地，即便现有的基础设施或者应用不符合，后续也会向这个方向过渡。这是很重要的两种区别，前者并非毫无意义，但这种阶段性的折腾往往不能改变什么现状。（在过检前补写过各种 SOP 和 Policy 的人应该理解我的意思。）

2. 数据安全架构案例

从过去一年里精选里一些数据安全相关的架构设计案例。出于篇幅原因不能每个都展开和分析，仅作分享。你能想到哪些细节？

3. 总结

通过以上可以看到在这些控制措施中并非仅仅只关注数据安全的技术手段，还会考虑到安全培训，日志监控等等。另外考虑到数据生命周期，还需要把相关技术应用到不同阶段。以及针对技术的 bypass，例如针对文件的删除，是 wipe，purge 还是 destroy？曾有人认为使用 Serverless 即可避免应用层之外的漏洞，类似的有了 MFA 就能避免权限问题，密码复杂度达到一定程度就是足够安全的。但有时候我们是不是想的太简单了？

企业内的 IT 基本环境可区分为 IDC（On-Prem） , Cloud（Serverless， IAAS，PAAS，SAAS）,  SAAS。从 IDC 到 Cloud 到 SAAS 过程中，Self-Managed 的东西越来越少（可以查看这张图 ）。换个视角说可能有更多的精力/资源投入对 Data 的控制中。但实际情况却是恰恰相反。在 IAAS 到 SAAS 的过程中，企业对自己数据的管理手段越来越少，即便 SAAS 服务提供商受 GDPR 约束，也无法提供完整的数据管理功能给到客户。因为厂商在提供 SAAS 服务的过程中，对用户来说虽然是屏蔽了底层的控制行为，但实际的数据还是存储在 Data Center。那么如果需要开放这部分能力给到客户，就会带来很高的成本。作为甲方，更希望能够获取对数据的完整控制能力，而不是仅仅关注数据防泄漏上。只有获取了完整的控制能力，才能处理数据流动所产生的相关问题。我看到大部分的文章，一谈数据安全，就是分类分级，生命周期管理，数据防泄漏三大块话题。至于密钥加密，架构设计，日志监控等，则在数据安全中提到的很少，且不能因为云化过程基础设施被屏蔽而忽视基础设施的重要性。

有兴趣的同学可以阅读下之前写的关于数据安全的一些文章。

• 再聊聊数据安全
  

• 浅谈加密基础设施