Ask DBA: 你所在的公司是如何访问生产数据库的？

💡 本文翻译自 Reddit 上的讨论帖 How do you deal with developers asking for production DB access? (https://www.reddit.com/r/devops/comments/11fmo4l/how_do_you_deal_with_developers_asking_for/) 。

在你的职业生涯中，有多少次被开发者问需要访问生产环境数据库只读权限的经历？

如果不妥善处理，这类要求会导致可怕的后果，如 DoS、数据泄露等，通常可以借用工具让开发者访问匿名数据，或在数据上运行 EXPLAIN。

对于这种请求，你的经验是什么，使用过什么工具？

acdha（108 赞）

首先要考虑你与开发人员的关系，以及你的具体工作职责是什么。一般来说，最好和开发人员站在同一阵线上，如果阻止他们完成他们的工作，最后发现他们只是把 phpMyAdmin 的副本偷偷放到服务器上了，以避免和你打交道（特别是如果你没有权力制定这种限制的话）。

另一些方法包括授予通过安全培训并了解贵司的责任、法规等人访问权 (如果这样以后你仍旧不相信他们，那可能要想想你怎么敢把他们的代码发布到生产环境）；记录每一条查询和查询人，并且审核这些日志；或者只在返回几行的情况下运行查询语句，一个做优化的开发人员不需要检索一百万行来获得查询计划或者手动测试 SELECT COUNT(*) FROM (此处手动插入一条糟糕查询) 需要多少时间。

我一般建议搞个只读副本，以避免对性能问题或不经意的改变，这样还是能有效地进行调试，也不浪费你的时间复制数据。

最大的问题是数据泄露，这是对你所拥有的数据类型和可用资源水平的一种权衡。一般来说，你要考虑的大多数事情都是你需要做的事情，例如把个人识别信息（Personal Identification Information / PII）存到一个独立的数据库中，由一个单独的服务来处理那些需要用户家庭地址的请求，这样更大程度避免了简单错误影响到应用程序。但这并不容易做到，不过至少可以了解下贵司是否有政策限制了谁可以访问这些数据。在某些情况下还有一种方式，给开发人员访问一个生产数据库的副本（去掉带有限制的表）。也有人这样做：访问一个不能访问互联网或其他内部系统的壳服务器，不过这并无法阻止泄漏数据，但可以避免更常见的非恶意破坏，比如把「临时」文件放置多年。

还有一个强大的工具，虽然很难实施，不过非常值得考虑：字段或行级加密。如果出于某些原因（可能是性能）你有一个混合敏感级别的库，使用一个只有少数人有权解密的 AWS KMS Envelope 会更安全，以免有人不小心把它打印到了日志里，或者由于一些 bug。

💬 高赞评论

100% 同意。DevOps 的工作是让操作更安全，但也是为开发团队提供性能和效用。他们是盟友，不是对手。相互尊重和理解对这项工作至关重要。

bxsephjo (137 赞)

我会给他们做一个副本数据库，定期复制和匿名化原始数据。

💬 高赞评论

我很想这么做，但对于初创企业来说，这个时间成本太高了。在公司做 SOC2 和 BC;DR 之前就是赌博。

如果他们和你签署了同样的保密协议，你为什么不相信他们，就像你相信自己一样？真实的数据很多时候对于了解业务情况是必要的。

cgssg  (94 赞)

在我看来，很多情况下，对生产环境的数据库进行选择性的只读是可以接受的。风险存在于一个持续的过程中，预防措施（比如无权限）具备最强大的威慑力，但代价也是最高的（降低的故障处理效率，较慢的故障恢复时间）。有选择的授权访问能尽可能防止数据泄漏，可以通过 RBAC 和控制监管（审计日志）来实现。要进一步防止泄漏，可以使用自动生成的一次性账户或定期密码变更进行只读访问。数据库实例也应该是网络隔离的，所以所有的访问都可以通过受控的访问点、jump hosts 等。

keto_brain  (48 赞)

为什么不给开发团队访问他们的生产数据库的权利？在 DevOps 里，开发团队负责从开发到生产的环境，包括他们的后台数据库。他们给自己的应用程序提供支持，而不是我，包括他们的数据库。如果他们搞砸了，那是他们的事。

我们如何建立工具，帮助开发人员自动识别的生产数据快照到预生产环境，是另外一个问题。

💬 高赞评论

100% 同意，只需要有控制措施，以确保如果数据库出现漏洞，数据泄漏是可控的。这就是多重身份验证（MFA），独立的证书或某种 PAM，日志等。我认为当涉及到人们完成自己的工作方面，合规性是远远落后的。他们仍然相信瀑布模型，因为那更容易卖。

SuperQue  (21 赞)

在我之前从事数据库自动化的工作中，情况是这样的：

- 开发团队拥有他们的数据库。SRE 团队建立了自动化，并就他们的 schema 和使用提供咨询。

- 每个数据库集群都有一个异步只读副本，用于备份和临时/长期运行查询。这也是开发团队使用的默认访问。

- 我们教开发团队如何使用 EXPLAIN，并教他们如何使用 EXPLAIN 的结果来优化性能。

Infra/SRE 只负责数据库和备份的自动化。我们为团队提供工具，并在需要时为他们提供升级协助。常规的日常数据库操作是由各个团队来完成的。

💬 高赞评论

态度不错

CyberMonkey1976  (6 赞)

是开发人员要求/需要访问生产环境？

还是你的部门没有制定良好的 CI/CD 流程和程序？

理想情况下，开发人员应该总是能够在他们开发环境中访问生产环境的精准复制。在 prod 里的东西，也应该在 dev 中（配置，不一定是数据）。

我们花了几年时间，但我们的开发团队已经实现了这一点。开发一个版本 > 发布被测试 > 发布被早期用户测试 > 变更管理 > 配置由系统管理团队在质检通过后部署。

作为一个只有 14 人的 IT 团队，我们能够做到这一点......也得到了执行团队的支持。

有什么变化？系统管理员的部署压力变小；每一步都有人负责；产品整体变得更好了；整个过程都有了文件记录；值得注意的是，功能和 bug 的修复总体上更快了。

干杯！

elitesense  (5 赞)

维持类似生产系统的短暂副本是 DevOps 的一部分，包括数据库。这样做的复杂性取决于数据库引擎和数据量，可能很容易也可能复杂。通常情况下，开发人员不需要所有的数据，他们只需要和生产环境相同的 schema/config/procs 和一小部分代表性数据。

如果他们真的需要所有数据，可以运行（或者最好让他们运行）一个数据库实例，该实例具有与生产环境相同的 schema 和一些最新数据（擦除掉个人识别信息）。通常来说，开发人员只是想测试程序或 schema 的变化。

理想情况下，开发人员应该有权使用开发环境的数据库（如上所述），但最好是运行一个小的本地实例，几乎没有数据（只有 schema），因为这对开发来说是非常快速和有用的。所有的 schema 应该已经在代码中定义好了，所以只要在本地做快速简单的实例即可。数据库在本地的 Docker 中就能很好运行，即使有大量的表，只要它们是空的或有极少的数据。

通常情况下，我确保定义了数据库 schema 的代码库有一个 Make 命令，可以在容器中根据需要快速启动一个结构与生产环境相同的数据库。这通常可以顾及开发人员在使用数据库时的大多数使用情况。如果他们需要数据，他们也可以恢复刷新的备份，或者如果他们需要完整的数据集（TB）来测试查询性能，他们可以使用一个暂存的数据库实例，每一次迭代都被刷新。

如果真的需要真实的/实时的生产数据（为什么？），可以搞个只读副本实例或只读用户，但是一个只读用户还是有可能使用糟糕的查询而锁定一个可写的数据库，所以一个只读副本是最好的。不过最好还是要避免这种情况。

the-computer-guy (5 赞)

开发人员应该对生产数据库负端到端的责任。当然，数据库应该得到适当的保护，但如果你不相信你的开发人员有这种权限，那有更大的问题了。

Irythros  (2 赞)

你是安全团队的吗？如果不是，匿名数据与否并不由你决定。开发人员可能需要真实的数据进行测试。

对我们来说，只有两个人可以访问生产数据库。我和老板，而且老板已经得到指示，如何在我被解雇的情况下把权限交给其他人。否则，我们的设置的一部分是创建迁移，以修改数据库，增加新的列和表等。我们也会创建一些真实的数据。

根据需要，我们会使用真实数据，如静态设置、预制账户 ([e-mail], [e-mail] 等)。

由于法律规定，我们不能给出生产环境的权限。

damienjarvo  (2 赞)

我们有几个高级别的开发人员可以访问一些生产数据库，但不是直接访问。他们需要 RDP 进入一台类似于堡垒主机的机器。SQL studio 只能在那台机器上工作。

但 99% 的时候他们会告诉我们他们需要的查询，1% 才是当有一个真正的大火需要扑灭的时候。

Bytebase 的解决之道

Bytebase 是一款为 DevOps 团队准备的数据库 CI/CD 工具，专为开发者和 DBA 打造，具有以下特色功能，以解决数据库访问安全的问题：

- 管理员模式：Bytebase 在 SQL 编辑器中提供管理模式，允许 DBA 执行数据库管理命令，可以替代标准的 database 命令行客户端。

- 基于数据库的访问控制：开发者无权限在 SQL 编辑器查询受保护环境中的数据库。但 DBA 可以配置数据库白名单，授予开发者查询权限。

- 数据脱敏：开发者在 SQL 编辑器中查询数据时，敏感列的查询结果将被匿名化处理。它适用于所有查询类型，例如子查询、JOIN、公用表表达式（CTE）。

- 基于角色的变更语句管控：开发者对指定数据库发起 DDL 或 DML 变更将自动触发审核流程。

- 审计日志：Bytebase 审计日志记录了在 SQL 编辑器中执行过的所有查询。

- 协同工作表：DBA 和开发人员可以将编写的 SQL 语句保存为工作表，并共享给团队成员。除此之外，该版本支持将上传的 SQL 脚本（单个文件不超过 100M）保存为工作表，以便在工单中使用。