如今的客户利用各种数据源执行复杂的查询，以提高业务洞察力。例如，为了更好地理解用户行为，分析师可以将数据仓库中的点击分析流与Salesforce的客户元数据关联起来。Databricks运行时提供各种内置apachespark™ 数据源连接器（AWS | Azure），为您的数据分析需求提供完美的入口点。然而，与异构系统集成需要管理一组潜在的大的凭证，精确地将它们分布在整个组织中。安全是每个个人或企业都必须关心的问题。为了帮助我们的客户加强安全意识，Databricks引入了Secret Management（AWS | Azure），它允许用户以高效而安全的方式利用和共享Databricks中的凭证。这篇博客文章讨论了我们添加的改进，并推荐了安全利用凭据的新实践。秘密管理设计原则在设计秘密管理时，我们分析了Databricks生态系统的现有工作流。我们的目标是扩展现有的状态，特别是提高客户安全连接到外部数据源的能力。我们认识到任何新系统都需要解决三个基本属性：凭证泄漏预防–事故发生，有时用户可能会通过日志消息将凭证意外泄漏到笔记本输出。这会使凭证处于暴露的风险中，因为Databricks笔记本会自动快照笔记本内容，作为修订历史跟踪的一部分。这些快照同时存储命令内容和单元格输出，因此如果共享了一个笔记本，则另一个用户可以恢复到旧的快照并查看打印的机密值。任何新的系统都应该努力通过防止意外的秘密泄露来保持安全团队的安全。访问控制管理-组织内的不同团队出于不同的目的与凭据交互。例如，管理员可能会设置凭据，但使用凭据的团队只需要对这些凭据具有只读权限。支持细粒度的访问控制允许团队对世界的状态进行正确的推理。可审核性-利用凭证是一项敏感的操作。安全团队需要历史使用记录来满足法规遵从性需求，并能够对安全事件做出准确的响应。Databricks在构建机密管理时考虑到了这些核心概念，以改善在综合管理解决方案中使用机密的客户体验。概念此新功能引入了以下概念以帮助您组织和管理机密：秘密范围-秘密的逻辑分组机制。所有秘密都属于一个范围。作用域可以通过名称识别，并且每个用户的工作区都是唯一的。通常，名称描述其用例或所有权。示例：jdbc或clickstream数据库。Secrets–存储机密材料的键值对。密钥是可识别的秘密名称，值是可以解释为字符串或字节的任意数据。秘密ACL–应用于机密作用域的访问控制规则。机密作用域及其机密只能由具有足够权限的用户访问。例如，管理员用户可以授予datascience组对jdbc secret作用域的只读访问权。我们提供了一个secretrestapi（AWS | Azure）和Databricks CLI（AWS | Azure）（0.7.1版及以上版本）命令来创建和管理机密资源。工作流示例在本例中，我们使用秘密管理来设置JDBC凭据，以便通过JDBC连接到我们的数据仓库。本例中的所有命令都使用Databricks CLI来管理机密。设置秘密我们首先创建一个名为jdbc的秘密作用域，其中包含secrets用户名和密码，以引导Spark jdbc数据源。首先，我们创建范围：databricks secrets创建作用域--scope jdbc现在我们引导我们的秘密：用户名和密码。我们执行以下命令并在打开的编辑器中输入机密值。databricks secrets put--scope jdbc--密钥用户名databricks secrets put--scope jdbc--密钥密码把秘密记在笔记本上我们希望使用笔记本中提供的凭据引导JDBC连接器。提醒一下，引导JDBC连接器的规范方法如下：进口java.util.Properties属性val connectionProperties=新属性（）connectionProperties.put（"用户"，"$YOUR\u用户名"）connectionProperties.put（"密码"，"$YOUR_密码"）connectionProperties.put（"usesl"，"true"）connectionProperties.put（"trustServerCertificate"，"true"） val jdbcUrl=s"jdbc:mysql：//${jdbcHostname}:${jdbcPort}/${jdbcDatabase}"val数据帧=spark.read.jdbc（jdbcUrl，"我的数据"，connectionProperties）请注意，此片段涉及到在笔记本中以明文形式插入凭据，这可能会通过笔记本快照公开凭据。前面的代码段不是安全的或推荐的做法。以下是我们如何调整此片段以利用秘密管理：进口java.util.Properties属性 val connectionProperties=新属性（）connectionProperties.put（"用户"，dbutils.secrets.get（scope="jdbc"，key="用户名"））connectionProperties.put（"密码"，dbutils.secrets.get（scope="jdbc"，key="password"））connectionProperties.put（"usesl"，"true"）connectionProperties.put（"trustServerCertificate"，"true"） val jdbcUrl=s"jdbc:mysql：//${jdbcHostname}:${jdbcPort}/${jdbcDatabase}"val数据帧=spark.read.jdbc（jdbcUrl，"我的数据"，connectionProperties）在这个版本中，唯一的区别是我们用调用替换了明文凭证dbutils.secrets.get，从jdbc secret作用域安全地获取以前引导的凭据。我们在Databricks Utilities SecretUtils（AWS | Azure）库中添加了用于在笔记本中读取机密的各种helper方法，可通过dbutils.机密.我们现在已经设置了一个DataFrame，它使用JDBC与我们的数据源通信，并使用我们安全管理的凭证进行身份验证。我们工作流程中的附加步骤是最小的，但对于实施安全的工作区环境至关重要。从秘密范围获取的值永远不会显示在笔记本中。如果用户不小心在笔记本输出中打印了他们的机密，凭证将显示为已编辑并保存以防暴露！授予对其他组的访问权限在我们验证凭证是否正确引导后，我们希望与datascience组共享这些凭证，以便在笔记本电脑中用于分析。我们通过发出以下请求，授予datascience组对这些凭据的只读权限：databricks secrets put acl--scope jdbc--principal datascience--权限读取现在，该组的任何成员都可以读取这些凭证，我们只需要在Databricks中为这个用例管理一组凭证！技术细节对于任何具有安全意识的特性，首要考虑的是理解客户数据是如何加密的。Databricks平台和Secret Management在AWS和Azure上都可用，并利用每个云各自的密钥管理服务AWS密钥管理服务（KMS）或Azure KeyVault来进行密钥管理和加密。这使我们能够利用这两家供应商现有的可信解决方案，并具有内置的安全性以满足法规遵从性标准。Databricks使用云服务提供的每个客户密钥来加密Databricks Secret Management中存储的所有机密。数据被加密存储在一个由我们的控制平面管理的独立数据库中。图1：存储在Databricks Secret Management中的机密数据流示例图。秘密存储时使用每个客户的加密密钥加密存储。Databricks相信保持安全性的简单性，因此很容易仔细检查和验证。我们的机密数据模型很简单，其中一个方面是我们防止静态数据篡改的设计。为了保护每个机密记录，我们将机密文本值及其元数据存储为加密的blob。未加密的元数据与每个记录的加密blob一起存储，这允许我们验证数据记录是否未被篡改。如果一个未经授权的用户获得对数据库的访问权，他们甚至不能通过交换秘密记录来操作静态数据。解密时，将验证元数据，以强制执行获取的机密与请求的正确机密名称、范围和组织相匹配。 作用域名称密钥名称客户编号加密的\u blob一排sX公司k1号加利福尼亚州EA（k1、sx、ca、v1）第2排sY公司k2断路器EB（k2、sY、cB、v2）第3排深圳k3断路器EB（k3、sZ、cB、v3）表1:Databricks secret数据库中存储的记录的示例模式。secret literal值用其元数据加密存储，标识密钥、范围和组织。在任何访问尝试期间，都会验证此信息，以防篡改静态加密的基础数据。我们在每架控制飞机上都有一个专门的秘密管理部门。只有此服务有足够的权限向云提供商密钥管理服务请求加密和解密数据。此外，从Databricks Secret Management读取机密只能使用Databricks Utilities命令执行dbutils.secrets.get，仅支持笔记本和作业。我们不提供任何API端点来读取机密。安全地存储客户机密是我们最关心的问题，使用户能够以简单的方式获取机密很不幸会成为客户数据的攻击载体。最后，我们提供所有访问秘密管理的审计日志记录。所有API请求，包括失败的访问尝试，都会通过Databricks审计日志特性（AWS | Azure）进行跟踪并交付给客户。通过利用这些审计日志，客户可以全面了解Databricks生态系统中机密的生命周期。结论在这篇文章中，我们介绍了数据中的秘密管理功能