前一阵子 CrowdStrike 让整个世界的白领几乎都放了一天带薪价，但是其实 CrowdStrike 引起的蓝屏可能更像是“直白”的影响，在你看不到的地方，黑客一直在“做事”。”

如果你在搜索引擎里输入“暗网 用户数据”这样的关键字的时候，你看到的内容是触目惊心的，动辄都是千万级的用户数据泄露，上亿的也有。里面全是明星企业。这篇文章不讲黑客的本事，单纯就讲讲这些顶着高科技光环的”草台班子“都做错了什么导致了这么多安全问题。

先从下面的这条新闻看过去。

Facebook 6 亿用户密码可被 2 万员工直接看[1]

近日，外媒发布了一份互联网安全的调研报告，报告中称 Facebook 曾将 6 亿用户的账号密码使用明文存储，且可以被 Facebook 内部员工随意搜索查看。据 Facebook 方面的消息人士称，纯文本存档的用户密码可追溯到 2012 年，在这期间有超过 2 万名员工搜索过这些信息。

行业领军企业都有这些问题，显然这不是个体企业能力不足导致的问题，而是一个行业普遍性存在的问题。

下面我尝试列举一些常见的数据安全隐患，各位从业者可以看看你的企业中几条。然后我们分析一下出现这些问题的原因。

企业数据管理常见的原因

手动管理权限

在传统的互联网公司（没有用类似 IAM 技术的公司），所有的权限管理都是用手动或者类似手动（或者审批流+半手动）的方式。而手动管理的方式就必然会带来下面的一系列问题。

账户共享

因为权限需要手工开通，所以大家能省(事)则省，往往一个研发小团队就会共享同一个账户。而一个在线服务如果不是微服务，往往涉及到很多数据库表甚至其他数据库，往往就是用一个账户一把梭。但是这个服务的开发者太多了。

在这种情况下，如何确认一些可疑的行为到底是谁干的。

就算有的账号被黑客通过社会工程学手段窃取了，也几乎无法发现。

比如所有一个公司的 主 web 服务只有一个 mysql 账号，所有研发共享一个。（这个情况在上一代 web2.0 公司里非常常见）

没有最小化权限

因为权限是手动管理的，所以最小化权限会让工作变得异常麻烦，所以会存在无所不能的类 root 账号。这就让利用权限的错配盗取信息的人有可趁之机。

比如一个一个服务只需要访问数据库里的一列，但是因为 mysql 后者 oracle 以及其他任何的关系型数据库都无法做到仅仅对某一列授权，而互联网行业因为性能原因使用大宽表，而不是通过外键来关联多表会让这个问题显得更加严重。互联网行业的所谓 mysql 军规之类的变通方法，其实都是在基础设施不够用的情况下的变通方案，本质上都是在安全上一退再退。牺牲的是谁呢？当然是用户。

那么最小化权限应该怎么做呢？其实业务层代码都是无状态的，要想真的减少权限范围，要从底层存储数据的组件开始，但是这些组件特别是开源组件的更精细的权限控制功能都在企业版里。可以参见我们文后列出的参考表格。

生产环境和测试环境隔离不够

生产环境的运维环境很多时候多做不到物理隔离，导致调试问题的工程师有权限随意触碰线上用户的真实数据。当然这也和互联网行业流行的 ab-test 和灰度上线有关，因为灰度上线本身就在生产环境里测试，所以为了调试和发现问题，就需要给工程师权限，但是这就会带来数据可能泄露的风险。

这种走钢丝的方案非常脆弱，它除了技术限制薄弱以外，还赋予了人几乎无限的权限，将生产环境的安全和数据安全至于单个人的可靠性上。这几乎是一个 IT 架构最不想遇到的境地了。人注定会出错，而且因为人犯错的随机性甚至还有主观故意存在，所以防范的方法只有降低权限的范围，所以这个设计就等于给生产系统和用户数据留下的巨大的隐患。

权限不会及时回收

建议大家可以去搜一下 Sudhish Kasaba Ramesh 这个名字，这是一个曾经的 Cisco 工程师，但是他在离职后干了一票大的，他删除了456 个虚拟机，导致了 16000 个WebEx teams 账号被关闭长达 2 周，恢复这些服务用了 160 万美金，思科还退换给客户超过1 百万美金。最后他被判处 2 年监禁。

这些都是权限没有快速回收带来的后果。那么为什么没有回收呢？因为如果没有自动化，总会漏掉一些应该处理的权限，而手动维持的权限的结果就一定是左支右绌。

看起来上面的情况发生概率不大（毕竟有司法机构存在），那么让我们考虑一个更常见的场景：

一个服务的请求者需要用私钥签名来验证身份，但是这个私钥从来不更换，也不吊销。如果被人意外获得，就可以进行非法的请求。而这些操作甚至是无法被发现的，因为数据就流通到黑市上做不法交易了。

小结

因为权限的半自动管理方式，会让整个系统即使看起来无懈可击，但是在实际工作里却千疮百孔，因为这里基于了一个错误的假设：

但是，人就是无法不犯错，人的错误率基本不变，随着处理工作的数量的增加，就一定会增加一些错误。任何管理方法都无法彻底根除，只有依赖自动化的系统才有办法。

内网明文通讯

这个问题的影响可能比上个问题略小，但是如果有人利用上面的问题，侵入内网，就可以利用这一点兴风作浪，掌握几乎所有数据。

一般来说，上一个时代的企业总会默认内网内就是安全的，但是实际上大的公司可能几万台机器，几千人都在共享一个 IDC，如果有人在网络里做一些嗅探，数据安全就无从谈起了。我们都知道黑客通过社会工程手段，拿到一个企业的 vpn 权限不是什么难事。

下面几条是你可以去 check 的：

1. 业务的核心数据库 mysql 或者其他数据库开启 TLS connection 功能了么？

2. 公司里所有的微服务无论是 gRPC 还是 Thrift 还是其他的主流还和自研方案，开启了 TLS 支持么。还是在 tcp 或者 udp 上跑着明文？

3. 公司内的微服务对请求者做验证了么？是否考虑到请求者是恶意程序的可能性？

其实这些问题都是被在任何科技公司里普遍存在的问题。一种叫 Zero-Trust Model 的新的安全框架就是针对解决这个问题而设计的，但是实际上在推广的并不顺利。至少我不知道任何国内公司使用了这种设计。这是一个新架构慢慢替代旧架构的过程，和所有的安全问题一样，不出事永远没有人认可安全的价值。

一般来说，对于 mysql 来说，打开 TLS 会损失大约 7% 的性能，而其他的高级语言实现的应用，可能更高，对于科技公司来说，既然没有出事，当然这 7% 能省则省了。

数据访问权限控制不利

下面是 bytebase 的ceo分享的图，事实上，现有的主流开源数据库的设计上确实存在安全疏漏，导致无法兼顾研发效率和数据安全。

研发或者运维随意处置敏感数据

这和上面的一些例子还有所不同，一般来说是因为线上数据和测试数据遇到的问题不同，所以往往因为开发工具的不完善，所以工程师要倒出线上数据帮助调试问题，但是这个过程过于专注于提高灵活性，而往往忽视安全性和合规性。

想象一下， 你怎么要求工程师用 grep，sed 这些基础工具去处理导出的日子或者源数据的时候还要隐藏敏感数据呢？

做不到精细的权限隔离

我们知道传统的关系型数据库的权限隔离一般只能做到表级，但是新时代的数据源，大家至少都能做到 column-level 的 ACL，甚至到 row-level 的 ACL。并且还能提供 RBAC 级别的隔离。

访问行为缺乏审计

总有一些请求我们无法判断它是否涉及隐私数据，所以要通过审计的方式来后验。英文叫 audit logging（审计日志）。

如果开启了审计日志功能，并且为每个工程师分配最小的权限，就可以通过审计，观察到底经手的工程师是来干活的还是来卧底的。

大部分企业依赖的都是开源的大数据工具，而审计相关功能都在企业版里。

裁判员参赛怎么办

如果你的工程师（运维/DBA）有随时关闭审计日志的权限或者有在文件系统删上删除审计日志的权限，那么软件提供什么功能几乎都毫无意义，所以即使自建基础设施，也最好分成两个团队，不能让裁判和运动员是同一伙人。类似于财务系统里会计和出纳不应该是同一个人一样，不同角色之间的互相监督本来就是组织架构存在的意义。

数据遗忘

GDPR 提出了一个遗忘权的要求，就是要在用户要求的时候删除用户的数据，但是这件事其实对于分布式存储来说并不简单，因为在存储系统里，同一份数据在多种介质中都存在，而且往往实现的删除功能还是逻辑删除。所以要想实现真正的删除功能，上层代码无法实现，一定是底层存储来提供这样的功能。几乎所有的 GDPR 都是在付费软件和开源软件的付费版里里提供的。

小结

因为业务代码几乎都是无状态的，业务代码根本无法控制数据权限的控制工作，这个工作必然要做在数据库或者分布式存储上。工作包括：

1. 做好权限管理

2. 最小化授予权限的范围

3. 有隔离的，可靠的审计日志功能支持

4. 提供真 · 数据删除能力

为什么数据安全就做不好了呢？

百度 CEO 李彦宏曾经说过，“中国人愿用隐私换便利”，这可能不是中国用户想的，但是好像确实是中国科技公司的想法。所以从上到下的不重视隐私和数据安全就非常合情合理了。

国外的基础软件，大部分都有商业公司在维护。他们推出的商业版有一些差异，但是核心的功能不同其实大部分都是在安全上。其实世界各国（包括我国）都有严格的数据安全法，欧洲有 GDPR，美国有 SOC2，中国有《数据安全法》，其实大家都有要满足合规诉求实际需求，可是中国企业为了数据安全付出了什么努力呢？

有哪家企业实践了零信任安全[2]呢？又有哪些企业采购了开源软件带安全功能的企业版了呢？是不是还有的企业连 https 都没有用上呢？

说白了，安全是有成本的，而且很高的成本。包括加密存储、加密通讯、零信任架构、企业版软件的成本都是有成本的。如果可以没有监管强制性的要求，大部分企业肯定是能省则省的。

SaaS 软件靠谱不？

SaaS 的卖方销售一定会天花乱坠的强调自己是安全的，直到被证伪那天为止。

从我经验来看，开启 mysql 或者其他关系型数据库的 TLS 的企业不到 10%，内网通信开启 TLS 的不到 5%，购买开源基础设施的企业版，并且开通那些降低性能提高成本的功能（RBAC、 全加密通讯、加密数据存储、 审计日志等功能）的企业又有多少呢？

所以最简单的办法是问一下 SaaS 企业的技术团队：

1. 是否尽量开启了 TLS，是否遵循了零信任架构。

2. 否采购了提供更安全和合规功能的基础软件或者授权。audit log 是如何管理的，技术团队自己是否有能力篡改？

3. 技术团队如何管理开发环境和生产环境的，是否进行了物理隔离，如何管理团队成员的权限，是否能做到不共享账户，离职取消所有权限。

4. 上面三个问题的答案，用什么方法证明？

ClapDB Enterprise 靠谱

ClapDB Enterprise 版是按照最高的安全标准设计的，所以默认提供以下机制来实现数据安全。

1. 完全遵循零信任架构设计，所有数据加密存储，所有请求加密通信，并且都要通过签名来验证调用者身份。

2. 支持 RBAC/ABAC， 支持 table-level、column-level 和 row-level 的权限控制。

3. 审计 log 存于云提供日志服务中，ClapDB 并没有删除日志的权限。

4. 提供 真正的数据遗忘能力，彻底的在所有存储里删除相关数据和 cache。

5. ClapDB 优先推荐用户使用 BYOC 方式部署，用户可以自己判断以上几点是不是真实有效。并且无人值守，无网络连接的情况下。ClapDB 研发团队自然就永远碰不到用户的敏感数据。

总结

在互联网公司不重视安全的背景下，一味的节省成本，坚持白嫖开源软件。大公司理论上是可以补上一些漏洞的（但是实际上并没有），中小公司就抱着侥幸心理带着用户的隐私数据全网裸奔。

用管理是解决不了安全问题的，安全的软肋在于整个技术栈的架构上，根源来自管理层不愿意为安全支付足够的成本。

基于对整个行业现在的了解，以黑盒方式交付的 SaaS 系统也不值得相信，因为收费低廉的原因（一分钱一分货大家都懂吧）。大概率它的安全措施也是一团糟。

不如让 SaaS 提供商自证一下它是否安全，然后 BYOC 交付。这才是真的安全。

作者：李令辉