Amazon Databricks S3 设置刚刚减少了 140 行 IAM 策略

2026 年 7 月 23 日，Databricks 推出了基于临时 AWS 权限的自动化 S3 设置流程，Amazon Databricks 的连接方式随之发生变化。该公司表示，新流程取代了此前需要处理 140 行信任策略、存储桶权限、CloudFormation 以及反复切换控制台的工作。

这听起来像是一项常规的设置改进。但它的影响更大，因为旧流程直接横亘在存储数据与几乎所有有价值的 Databricks 工作负载之间。数据摄取、分析、治理以及较新的事务型架构，都依赖于正确连接存储。

因此，冲突并非 Databricks 与其他数据平台之间的竞争，而是自动化配置与许多安全团队仍然信赖的手动控制模式之间的取舍。Databricks 必须证明，更少的配置步骤并不意味着审核更弱、访问范围更广，或基础设施可见性更低。

AWS 提供了支撑这一论点的机制。其临时委派功能允许符合条件的合作伙伴针对明确的设置操作，请求受限且会过期的权限。授权会到期，但经批准的 IAM 角色可以保留，用于持续的 S3 连接。

这一变化将 Amazon Databricks 入门中最困难的工作，从编写策略转向审查权限。这是有益的改变，但并未消除安全决策，而是将其集中到更短的审批窗口中；在这一窗口内，身份、存储桶范围、加密和持续访问仍需密切关注。

Amazon Databricks S3 连接有哪些变化

Databricks 已将一项需要跨多个控制台完成的基础设施任务，转变为其工作区内以审批为主导的工作流。

S3 连接始于外部位置（external location），这是一个 Unity Catalog 对象，用于将云存储路径与凭证配对。Unity Catalog 是 Databricks 面向跨工作区数据及其他资产的治理层。

此前的流程要求在两个管理系统中协调变更。用户或云管理员必须创建 IAM 角色、定义其权限并配置跨账户信任关系。他们还必须授予相应的存储桶访问权限，并在 Databricks 中注册匹配的对象。

每个组件都代表着一次独立的失败机会。错误的 Amazon Resource Name 可能指向错误资源。缺少某项存储桶操作可能导致作业在后续失败。信任策略可能允许错误的主体，或阻止 Databricks 代入该角色。

Databricks 表示，其新的 S3 连接流程将这一系列操作缩减为几个引导式步骤。用户选择 S3 存储桶和访问级别，然后登录 AWS 以验证权限。

如果用户拥有足够权限，便可批准一项有时间限制的委派请求。没有该权限的用户，也可在同一流程中将请求发送给 AWS 管理员。

随后，Databricks 会配置所需资源。该公司称，它会创建具有最小权限的 IAM 角色，并配置跨账户信任策略。它还会创建存储凭证，并注册映射到所选存储桶的外部位置。

Auto Loader 和 File Events 会自动启用。Auto Loader 会增量处理新到达的云文件，而 File Events 提供通知，可减少重复列出目录的工作。

临时设置访问与持续数据访问之间的区别十分重要。Databricks 表示，临时授权会在配置完成后到期。为正常运行创建的 IAM 角色会保留，因为 Databricks 仍需要一个获批准的身份来读取或写入选定的 S3 数据。

这一设计遵循 AWS 已记录的模型。临时委派可授权合作伙伴在有限时间内配置资源。AWS 将委派访问的最长时限设为 12 小时。

AWS 还要求通过此机制创建的 IAM 角色设置权限边界。权限边界规定了基于身份的策略能够授予的最大权限，但它本身并不授予访问权。

这一边界提供了有用的防护栏，但不能取代对角色策略的审查。管理员仍必须确认所请求的操作和资源是否与预期的存储桶路径相符。

这一新体验可通过 Catalog Explorer 中的 External Locations 使用。Databricks 文档将自动化设置列为大多数部署的首选方法，同时保留手动和程序化替代方案。

这是一个重要的产品选择。Databricks 并未移除 SQL、命令行、Terraform 或手动控制台路径。它新增了一条默认路径，倾向于引导式配置，同时为基础设施团队保留了通过可重复的代码化管理进行操作的方式。

因此，眼前的变化是狭义且具体的：AWS 身份批准受限请求后，Databricks 现在会处理策略生成和资源注册。更大的问题在于，企业会将这种自动化视为更安全的标准化，还是不受欢迎的抽象层。

为什么更简单的 S3 连接具有超乎寻常的重要性

存储连接并非边缘集成，因为它决定了 Databricks 能否治理、处理并提供组织现有的数据。

许多组织已经将运营记录、应用日志、媒体、训练数据和分析数据集保存在 Amazon S3 中。仅仅为了开始使用另一平台而迁移这些对象，会带来成本、重复存储和生命周期管理问题。

外部位置让 Databricks 能够处理指定的 S3 路径，同时组织仍可继续管理底层存储。该连接为 Unity Catalog 提供已批准的凭证，并为该路径建立受治理的边界。

相关的 Unity Catalog 模型使用两个可保护对象。存储凭证代表认证机制，例如 AWS IAM 角色。外部位置则将该凭证与存储路径结合起来。

随后，Databricks 可以授予或撤销外部位置上的权限。这些控制措施决定谁可以针对该路径创建外部表、外部卷或托管存储位置。

这种分离有助于数据团队避免向个人用户分发 AWS 凭证。分析师和工程师可以通过 Databricks 权限开展工作，而不必获得直接的存储桶访问权限。

直接访问可能造成治理缺口。Databricks 警告称，在 Unity Catalog 之外访问托管存储的身份可能绕过其访问控制。这些操作也可能脱离 Databricks 的审计和数据血缘记录。

新的设置方式降低了使用这一受治理路径的一道门槛。在此之前，团队即使了解目标架构，仍可能因数据工程师、平台所有者和 AWS 管理员之间的协调而受阻。

当职责划分明确时，这种协调成本尤其高。数据工程师了解存储桶和所需的工作负载；云管理员掌控 IAM；治理负责人决定该位置是否应允许读取、写入或进一步创建对象。

一份冗长的策略文档可能将这种分工变成缓慢的工单往返。工程师提供 ARN，管理员创建角色，工程师再进行测试。验证失败会使工作倒退，却未必能清楚指出问题源自哪个层面。

自动化配置改变了协作单位。用户不再要求管理员组装连接，而是可以发送一项明确的委派请求供审核。系统随后会一致地应用经批准的配置。

这种转变促使内部平台团队重新审视其入门标准。手工编写的策略并不天然比生成的策略更安全。手动工作可以保留意图，但也可能在不同账户和环境中重复制造错误。

与此同时，生成的基础设施也并非对所有企业都天然正确。组织通常会在产品默认路径之外增加命名规则、标签要求、客户托管加密密钥、服务控制策略和监控标准。

因此，最强的使用场景是存储桶范围明确、治理要求常规的通用部署。团队可以减少重复的策略组装工作，同时保留明确的 AWS 审批步骤。

其价值在规模化时更为明显。一条连接或许值得细致的手动操作；数十个账户、环境和存储桶路径，则可能让细微的配置差异演变为持续的支持与审计成本。

Databricks 还将这一变化与 LTAP（Lake Transactional/Analytical Processing，湖仓事务/分析处理）联系起来。LTAP 描述了一种架构：将事务型和分析型工作负载置于共享且受治理的基础之上，从而减少独立副本和管道。

这一更广泛的愿景依赖于存储能够轻松接入，而不会变得失控。简化的外部位置不足以实现 LTAP，但困难的存储设置会在应用进入生产环境前就破坏这一架构。

因此，Amazon Databricks 集成之所以重要，是因为它将治理前移到了采用路径的更早阶段。首次连接现在可以建立 Unity Catalog 边界，而非鼓励一种日后可能永久化的临时变通方案。

自动化配置挑战手动控制的默认模式

核心权衡在于：经过审核的自动化，是否能比手工组装的策略带来更可靠的控制。

手动 IAM 配置具有可见性。经验丰富的云工程师可以在部署前检查每项操作、主体、资源模式和条件。基础设施即代码也可以将这一配置保留在版本控制中。

这些优势对于受监管环境和复杂账户结构仍然适用。公司可能要求进行拉取请求审核、自动化策略扫描，或通过中央云平台代码库进行部署。

Databricks 的引导式流程针对的是另一种失败模式。许多 S3 连接在结构上相似，但每一条都需要在信任策略和权限策略之间进行精确协调。重复手动完成这些工作，并不一定能带来额外的安全价值。

AWS 跨账户访问通常依赖于客户账户中的一个角色。其信任策略指定哪些外部主体可以代入该角色，而其权限策略定义该角色可以执行什么操作。

AWS 解释称，跨账户角色可将特定权限委派给另一个账户。外部系统随后调用 AWS Security Token Service，以获取该角色的临时凭证。

信任关系和权限范围解决的是不同问题。拥有过度 S3 权限的正确受信任策略仍然存在风险。权限策略再严格，若受信任主体不正确，也可能造成暴露。

Databricks 表示，其自动化功能会同时生成 IAM 角色及其跨账户信任配置。这可以减少语法错误和标识符不匹配，尤其适用于首次连接 S3 的团队。

该流程还会让客户的 AWS 审批保留在决策链路中。服务提供商发起请求，但由客户审核并决定批准、拒绝或转发。用户无法委派自己并不具备的权限。

CloudTrail 会记录通过委派授权执行的活动。CloudTrail 是 AWS 用于记录账户活动和 API 操作的服务。这些记录可用于支持调查和合规监控。

与向供应商授予长期管理员访问权限相比，这种模式更易于辩护。Databricks 表示，它不会在完成设置后保留长期账户访问权限。临时预配置授权会自动过期。

不过，“没有长期账户访问权限”不应被理解为“没有持续访问权限”。由于持续运行的 Databricks 工作负载需要访问获批的 S3 资源，因此创建的 IAM 角色会继续保留。

这一持久化角色将成为核心审计对象。安全团队应在部署后检查其信任策略、权限边界、身份策略、会话条件以及实际的 CloudTrail 使用情况。

他们还应区分临时委派记录与由此产生的基础设施。过期的请求会限制后续设置活动，但不会移除为正常服务运行而有意创建的角色。

因此，自动化与手动方式之争并不存在普遍胜者。自动化设置提供了一致性和更低的配置开销。通过代码管理部署则提供更深层的定制能力和熟悉的变更控制轨迹。

Databricks 在其 外部位置选项中保留了这两条路径。对于大多数部署，建议使用自动化设置。手动的 Catalog Explorer、SQL、CLI 和 Terraform 方法仍然可用。

这种共存对企业采用至关重要。产品驱动型团队可以从审批流程开始，而中央平台团队则可为标准化环境保留编程式预配置方式。

压力将落在那些仅仅因为此前缺乏更安全自动化方案而存在的手动工作流上。管理员需要说明，究竟是哪项策略要求真正需要自定义部署，又有哪些步骤只是沿袭了既有流程。

对数据团队而言，其好处是反馈更快。请求失败可以在有人编写并部署多项相互关联的策略之前，暴露缺失的授权。请求获批后，则可以在一次会话中创建匹配的 AWS 和 Databricks 资源。

对安全团队而言，收益取决于证据。他们需要清晰的请求内容、资源范围、CloudTrail 记录，以及一种可稳定比较不同账户中生成角色的方式。

真正的衡量标准不是减少了多少点击次数，而是最终生成的角色是否比手动创建的前身更精简、更一致且更易于审查。

更少的 IAM 步骤并不会消除安全问题

新的 Amazon Databricks 设置降低了配置风险，但授权、数据范围和生命周期风险仍由客户承担。

第一个问题是谁可以批准委派请求。AWS 允许用户通过特定 IAM 操作管理请求，包括查看、转发、接受、拒绝和释放委派令牌。

组织不应广泛授予这些操作权限。能够发起连接的用户，不应自动获得批准每个账户中所有请求权限的授权。

当原始用户缺少所需权限时，AWS 支持将请求转发给管理员。该工作流符合职责分离策略，但前提是管理员会验证请求，而不是将其视作例行工单。

第二个问题是资源范围。面向某个存储桶或前缀的请求，不应授权访问无关存储。团队需要检查通配符资源、列出权限、写入操作、删除权限以及对加密密钥的访问。

S3 权限的粒度可能比看上去更细。读取对象、列出存储桶、写入新数据、删除对象以及处理分段上传，都使用不同的操作。一个工作负载可能需要其中几项，但很少需要所有 S3 操作。

加密又增加了一层复杂性。受 AWS Key Management Service 密钥保护的数据，除了 S3 访问权限外，还可能需要 KMS 权限。密钥策略也必须识别相关角色。

第三个问题是信任边界。管理员应确认能够承担最终角色的 AWS 主体，并审查任何外部 ID 或会话限制。

AWS 建议为多租户第三方访问使用外部 ID。外部 ID 有助于防止一个客户导致服务提供商使用另一个客户的角色，这种情形称为“混淆代理”问题。

第四个问题是创建后的所有权。必须有人监控持久化 IAM 角色，在存储桶路径变更时更新它，并在外部位置退役时移除它。

自动化创建基础设施的速度，可能快于组织记录所有权的速度。若缺乏生命周期控制，未使用的角色可能会在概念验证、团队重组或迁移后继续遗留。

第五个问题是漂移。Databricks 创建角色后，管理员可能会直接编辑它。后续产品更新可能预期不同的策略形态，或者存储桶策略可能会独立发生变化。

Databricks 的公告并未说明每一种漂移形式将如何被检测或修正。客户应在受控账户中测试变更，并确定由哪个系统拥有最终配置的控制权。

第六个问题是与预防性控制措施的契合度。即使 IAM 角色看似允许某些操作，AWS Organizations 服务控制策略仍可对其施加限制。权限边界和资源策略也能施加额外约束。

这种分层模型是可取的，但也可能让故障排查变得更困难。生成的角色可能看起来正确，但其他策略仍会阻止访问。当引导式流程遇到复杂组织环境时，团队仍需要云端专业知识。

CloudTrail 日志记录改善了可追溯性，但仅有日志并不能形成有效监控。安全团队必须路由相关事件、定义告警、保留记录，并将活动关联到已批准的变更。

生成的最小权限策略也应接受实证审查。Databricks 表示这些角色遵循最小权限原则，但客户应将所请求的权限与实际工作负载行为进行对比。

一次有价值的试点应包含只读和读写场景。它应测试存储桶前缀、加密对象、被拒绝的操作、角色承担、事件摄取以及移除外部位置。

团队还应确认 Unity Catalog 权限与 AWS 权限相匹配。如果 Databricks 向过于宽泛的群组授予对相应外部位置的访问权限，那么范围精确的 IAM 角色也无济于事。

反过来也是如此。精确的 Unity Catalog 授权无法弥补用户在受治理路径之外仍保留直接 S3 访问权限的问题。这条路径可能绕过 Databricks 控制，并导致数据血缘不完整。

因此，不应将这项公告解读为“IAM 已被解决”。Databricks 已将一种已知的配置模式自动化。客户仍需定义可接受的权限范围、审核请求，并运营由此产生的连接。

对于具有严格基础设施即代码要求的组织，引导式流程可能更适合作为参考实现，而非生产部署路径。团队可以检查其输出，并通过 Terraform 复现获批的控制措施。

对较小团队而言，自动化流程可能成为更安全的默认选择。一致的生成方式和受限的预配置访问权限，可降低匆忙的用户从过时示例中复制过宽策略的概率。

安全结果取决于自动化替代了何种行为。替代经过审查和测试的代码，可能价值有限；替代临时拼凑的控制台操作，则可以显著提高一致性。

三个信号将显示新流程是否奏效

下一项考验是采用证据，而不是又一次关于减少点击次数的说法。

第一个信号是真实企业账户中生成 IAM 策略的形态。安全团队应比较多个连接之间的资源范围、允许操作、权限边界和信任条件。

具有狭窄存储桶访问范围的一致角色，将强化 Databricks 的论点。频繁的手动编辑则表明默认设置并不适配常见的企业控制措施。

这一信号之所以重要，是因为策略生成是该产品的核心承诺。界面可能感觉简单，却仍会生成需要在创建后进行大量审查的基础设施。

第二个信号是客户是否将审批工作流标准化。健康的实施方式应将请求路由给明确的管理员，保留审查证据，并为每个角色关联所有者。

如果团队仍在交换截图、ARN 和临时工单，那么自动化只是减少了输入操作，却没有解决协作问题。如果请求成为可重复执行的控制点，新模式就更实质性地改变了接入流程。

第三个信号是设置后的运营可靠性。组织应关注角色承担失败、被拒绝的 S3 操作、CloudTrail 异常、事件交付问题以及被遗弃的外部位置。

较低的失败率将支持这样一种观点：匹配式预配置能够减少配置错误。持续发生的失败则表明，存储桶策略、加密、组织控制和数据权限仍会形成过多隐藏依赖。

Databricks 还应明确管理员如何检查、导出、验证和复现生成的资源。这些能力将决定中央云团队是否将该功能视为获批的部署路径。

保留的手动和 Terraform 选项提供了一条务实的迁移路线。团队可以测试自动化设置，检查生成的角色，并决定未来连接是否应纳入代码管理模板。

这一评估应始终针对具体工作负载。只读分析数据集的需求，与持续接收写入和文件事件的摄取目标不同。

团队应从有限的存储桶前缀和非关键工作负载开始。随后，他们可以确认访问、审查日志、测试撤销，并记录由哪个群组负责该连接。

最重要的结果是形成更清晰的责任划分。Databricks 可以生成兼容资源，AWS 可以执行受限审批，而客户则可以保留对身份和数据范围的控制。

这种划分支持更快的接入，同时不会假装云治理已经消失。由于周边配置工作已实现标准化，它让审批决策变得更加可见。

这一变化也为竞争性数据平台提供了更清晰的标杆。存储连接器如今需要的不仅是文档和策略片段。买方将越来越期待引导式授权、会过期的设置权限、可审计的操作以及受治理的持续访问。

对于开发者和平台团队而言，这一经验并不局限于单一产品。良好的云端接入应只请求创建明确、长期运行身份所需的最小临时权限。

记录该评估过程的团队，可以将策略、架构决策和测试结果保存在可搜索的工程知识库中。当角色发生变化或审计人员重新审视最初审批时，这些记录将发挥作用。

Amazon Databricks S3 设置如今更容易了，但真正的收益并不只是便利。新流程让组织有机会以可审查、受限的自动化方式，替代脆弱的手动拼装。

接下来的行动很直接：测试一个具有代表性的连接，检查每一项自动生成的权限，并在委派到期后验证该角色是否仍然有效。结果是否同时减少了配置时间和安全例外，还是仅仅减少了可见的操作步骤？