背景
目前我在一个设置中工作，其中 DEV_DB 连接到测试生成的数据，而 PROD_DB 连接到实际数据源。我的目标是在不破坏生产功能的情况下为其他人提供一个沙盒环境进行实验，我想到了使用 Snowflake 臭名昭著的 Zero Copy Clone。但是，这存在一个主要问题。创建克隆时，将使用该克隆的人将继承对 PROD_DB 的相同限制访问，从而使该克隆几乎没有用处。
换句话说，假设 PROD_DB 用户 FOO 只能选择 MARKETING 架构。而用户 BAR 只能在 FINANCE 架构上进行选择。克隆该数据库会受到限制，因为在测试新功能时，人们想要的不仅仅是选择。同时，用户不应该访问他们无法在 prod 上访问的数据（即使在克隆中）。因此，例如用户 FOO 不应看到 FINANCE 架构中的数据。
我尝试做的事情
我尝试为 CLONE 数据库创建一个单独的 SQL 脚本，该脚本与 DEV_DB 具有相同的访问结构，并在创建克隆时将其应用于克隆。虽然这看起来可行，但我看到至少有两个问题。首先，我使用 Snowflake's Terraform provider 来管理访问权限，因此使用 SQL 脚本创建一些访问权限并使用 Terraform 创建其他访问权限并不理想。其次，管理访问权限的长 SQL 脚本难以维护和监控。
目标
我正在尝试找到满足以下条件的最佳实践和解决方案：
SELECT 上PROD_DB，他们应该能够{{ 1}} AND SELECT 在克隆上）如果需要，我很乐意分享更多细节和信息
答案 0 :(得分：0)
如果我对您的理解正确，那么您的初始陈述之一是不正确的。克隆对象不会从其克隆对象继承任何权限。您必须手动授予克隆对象所需的权限：access-control-privileges-for-cloned-objects
但是，我假设您不会尝试在您的生产 Snowflake 帐户中创建开发数据库，因为这将是一种非常糟糕的方法。由于您只能在帐户内进行克隆，因此您确实应该考虑数据共享或数据复制，以将数据从您的 Prod 帐户中提取到 Dev/UAT 帐户中。
顺便说一句（显然取决于您所在的位置和当地法律）在开发环境中使用包含任何 PII 的生产数据会违反各种数据保护法律 - 因此您需要先混淆您的生产数据将其移动到另一个位置，并将其用于与生产不同的目的。