我组织中的一些非 DBA 工作人员（DEV、欺诈、分析师……）需要直接访问数据库来编写他们自己的查询。

...

PCI DSS 要求 8.7 stats “只有数据库管理员才能直接访问或查询数据库”

处理此问题的常用方法是创建数据库的清理版本，删除或替换 PAN 数据和其他敏感数据。然后这个清理过的数据库不在 PCI 范围内，可以由您描述的人直接查询。

（欺诈人员可能需要访问 PAN 数据来完成他们的工作......但他们不会为此使用自由格式的查询，您编写一个应用程序，通过预先形成的查询）。

对于开发人员和分析师来说，清理后的版本应该足以满足他们的需求。

您可能还希望考虑 PII 的问题。数据科学分析师需要访问该级别的详细信息；开发人员可能不会。然而，这超出了 DSS 的要求。

这种方法有几个缺点：

1. 根据源数据库的大小，清理可能会耗费大量时间和资源。
2. 从数据的基数派生的表索引将在您删除或替换索引列（例如 PAN）时更改，这意味着针对“清理”数据库的性能测量不会 1:1 等效于“真实“数据库。

AFAIK，你不能。如果您想符合 PCI DSS，开发人员和分析师都不应直接访问生产数据库。

说了这么多，您应该想知道为什么他们需要直接访问生产数据库。开发人员通常应该对包含虚假数据的开发数据库感到满意，前提是其大小对于性能测试是一致的。分析师应该在私人数据库中提取 prod 数据库来执行他们的查询。您甚至可能想知道 BI 解决方案是否可行：Prod 数据库 -> ETL -> BI 数据库

它确实比允许直接访问更复杂，但安全性（和认证......）只是有代价的

我刚刚查了 PCI（支付卡行业）
，好吧，你有一些敏感数据

数据库端口（例如 1433）甚至不应该对外开放

我不认为让他们只读访问视图会满足法规

我会尝试给他们一个具有强分面搜索的应用程序，您只使用参数化查询。

他们可能想要直接访问，但这确实意味着他们会得到它。

我所做的是有一个可以运行的视图表。我创建视图并将名称与描述一起放入表中。该应用程序将读取该表，因此它现在只是他们可以运行的新报告。他们不直接运行 View - 应用程序运行视图并报告结果。但在某种程度上，你是直接发布到 Dev 中，所以这有点危险。