如何限制公司内部对生产环境的访问权限

53次阅读

问题描述

在我所在的公司中，只有两名DevOps工程师（我和另一位同事）可以访问生产数据库。因此，当其他开发人员需要在生产数据库上执行MySQL查询时，他们会将查询发送给这两名工程师来执行。以下是需要向生产数据库执行命令的情况：
1. 数据库包含损坏的数据，导致出现错误。他们执行命令来修复错误。
2. 报告了一个错误，并且他们想要查看数据库中的当前值。
3. 我们的一个客户想要修改他/她的数据。但是我们的Web应用程序没有完成修改的能力。因此，我们必须直接向数据库发送MySQL命令来完成客户的要求。
4. QA团队在生产环境中创建了测试账户。他们想要更改账户的状态，以便进行其他测试。

这给我和另一位同事带来了很多干扰。当我们在白天开发程序时，我们经常不得不切换上下文来执行一些查询。我认为这不是公司的良好架构。你们是如何控制对生产环境的权限的？

我们的生产数据库包含敏感的客户信息。如果数据泄露出去，我们的公司可能会被罚款数百万美元。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

如果你的问题是如何管理数据库更改，可以考虑使用类似于Flyway的工具。它可以让你通过在代码库中跟踪的配置文件来控制更改，并通过自动化和受控的过程应用它们。你可以使用正常的代码审查和推广步骤来管理这些更改。

如果问题是“如何让开发人员停止打扰我运行任意SQL命令”，那么你可以考虑编写脚本来自动化执行或给他们一个第三方UI来使用，该账户被锁定以防止更改，并限制他们查看任何敏感表。根据你的数据库布局，效果可能有所不同。

方案2

你可以将数据库架构和数据更改嵌入到源代码控制中，使用称为数据库迁移的概念。这些迁移可以作为部分自动化部署过程的一部分在开发和测试环境中执行。

例如，在我的环境中（PHP Web应用程序），我使用Doctrine Schema进行架构更新，使用Yii2 migrations进行数据更改。相应的命令是一个7行的bash脚本，它运行所有必要的命令来在每个环境中部署更改。

方案3

我看到一个问题，DevOps的目标是建立一个能够从构建到运营处理应用程序的团队。因此，你的开发人员应该有权访问数据库，你引用了许多人们现实中遇到的情况，这也是你和同事成为瓶颈并妨碍你们自己工作的主要问题。

其他答案很好地解决了架构更改或计划更改的问题，这些更改应该作为应用程序交付过程的一部分进行集成，但它们不能快速解决对实时访问的需求，当开发人员需要转储数据库以了解导致错误的原因以及如何修复时。

像你在评论中提到的ProxySQL对于MySQL数据库可能是可以的，只需配置MySQL来记录操作也是一个不错的方法，MySQL提供了一个商业的审计插件，可以满足你让开发人员访问数据库并满足CISO要求跟踪操作的问题。

如果你有不止一个MySQL数据库并且需要审计其访问权限，配置每个系统以记录用户操作而不是应用程序操作可能会很麻烦。保持封闭可能会更糟糕，有一天，一个开发人员将在应用程序中集成一个DB shell来绕过这个障碍，并且它最终会在没有适当访问控制的情况下在生产环境中运行并暴露所有数据，我强烈建议你要求公司重新审查这个策略。

我知道有一个商业解决方案可以帮助（并允许审计不仅仅是DB请求）的是strongDM，它还允许审计ssh和rdp会话，因为如果你的开发人员需要访问DB，他们可能还需要访问托管应用程序的机器进行调试。

方案4

请注意以下操作注意版本差异及修改前做好备份。
在你的公司中，只有两名DevOps工程师可以访问生产数据库，这是一个很好的起点。在很多情况下，DBA们发现自己在马儿跑掉后才开始关上稳定的门。

问题是，为什么开发人员要对生产数据库运行任何东西？开发人员不应该在开发数据库之外拥有“亲自操作”的权限。其他一切都应该通过预先准备、受控（最好是自动化）的渠道进行脚本化、测试、审计和发布。

开发人员不应该在生产环境中运行任何SQL命令。他们应该使用开发数据库进行开发和测试，并在准备好的情况下将更改发布到生产环境中。

权限控制应该基于角色。根据工作角色的需要，为用户分配对每个数据库的访问权限，并使用角色来授予他们对每个数据库中的表的访问权限。这些账户的创建和角色的授予过程是集中管理和严格审计的。

开发人员不应该在开发数据库之外拥有“亲自操作”的权限。其他一切都应该通过预先准备、受控（最好是自动化）的渠道进行脚本化、测试、审计和发布。

开发人员应该永远不会在生产环境之外运行任何SQL命令。他们应该使用开发数据库进行开发和测试，并在准备好的情况下将更改发布到生产环境中。