您可以通过审核云和身份平台上的每一项持久权限、剥离不
特权账户就像长期向攻击者敞开的门户,其中的凭据可能被窃取,权限也可能被滥用。 当管理权限持续处于启用状态时,无论是否实际使用,特权账户都会显著扩大攻击面。 零常设特权 (ZSP) 通过确保任何用户都不会永久拥有提升后的访问权限,来降低这一风险。 相反,用户需针对特定任务申请权限,在有限时间内获得授权,并通过既定工作流进行审批;获批的时间窗口到期后,权限将自动撤销。 ZSP 体现了现代安全领域更广泛的转变,即以临时访问权限取代常设访问权限,从而减少攻击者可利用的攻击面。 Keeper 通过授予即时 (JIT) 访问权限,并在获批的时间窗口到期后自动撤销权限,帮助实施 ZSP,使用户从零权限状态获得恰好所需的访问权限,然后自动恢复为零权限状态。
继续阅读,了解 ZSP 的重要性、其在 Keeper 中的工作原理,以及 Keeper 如何在不同环境中实施 ZSP。
为什么常设特权会带来安全风险
无限期保持启用状态的特权账户会成为攻击者长期觊觎的目标:凭据不会过期,访问权限始终可用,也没有明确的时点会收回这些权限。 如果攻击者窃取或攻陷其中一个账户,就会获得该账户的全部常设特权。
拥有常设访问权限的账户一旦遭到入侵,影响范围就会进一步扩大,因为它很少只停留在原本预期使用该账户的系统中。 攻击者利用常设特权在不同环境之间横向移动,进而访问沿途的其他服务器、数据库和云资源。 如果用户拥有常设访问权限,一次凭据泄露就可能迅速演变为攻击者在整个基础设施中建立立足点。 当特权是永久性的,访问权限就不会与特定请求、任务或时间范围绑定,因此无法清楚记录某人在特定时刻为何能够访问某个系统。 这种模糊性使调查涉及常设特权的安全事件以及证明合规性变得更加困难。
零常设特权在 Keeper 中如何运作
Keeper 通过 Keeper Privileged Cloud 帮助实施 ZSP,将 KeeperPAM 的 JIT 访问框架扩展至您的身份提供商和联合应用。 Keeper Privileged Cloud 不会配置永久管理员权限,而只会在提出请求时、获批的时间窗口内,并根据您定义的工作流控制授予提升后的访问权限。 用户默认处于无特权状态,通过受控且可审计的流程提升权限,并在任务完成后恢复为零权限状态。 下面介绍 ZSP 在 Keeper 中的实际运作方式。
配置访问策略
在 PAM Cloud 记录中,管理员使用 JIT 和工作流设置来定义访问规则。 这包括请求是否需要审批、谁可以审批、授予访问权限后可持续多长时间,以及用户将被提升至哪个角色。 这些设置有助于明确特权访问的申请、审批和时限,确保任何权限提升都不会超出您设定的边界。

与授权用户共享记录
策略设置完成后,PAM Cloud 记录将共享给有权请求访问权限的用户。 由于权限提升通过您的身份提供商进行,因此每个用户都需要同时在您的身份提供商和 Keeper 租户中拥有账户。 共享记录后,这些用户可以在任务需要时请求提升后的访问权限,而在此期间无需持有任何常设特权。
审核并批准请求
当用户需要访问权限时,可以直接通过 Keeper 保管库或 Keeper Commander CLI 发起请求。 指定的审批人会收到来自 Slack、Teams、Jira 和 ServiceNow 等工具的实时通知,并可通过任意 Keeper 客户端批准或拒绝请求,因此无需等待审批人回到办公桌前处理请求。 根据策略,审批人还可以在授予访问权限之前要求提供理由和工单编号,将每次权限提升与有记录的事由关联起来。

自动授予和撤销访问权限
请求获批后,Keeper Gateway 会在身份提供商或目标资源中执行权限提升,授予用户配置的组成员身份、角色或权限,使其获得策略允许的访问权限。 获批的访问时长到期后,Keeper Gateway 会自动撤销该访问权限,移除临时成员资格或分配,使用户恢复至 ZSP 状态。 它还会记录每次权限提升的访问请求人、审批人,以及权限提升的开始和结束时间,从而为安全与合规团队提供清晰的逐项请求记录,说明特权访问权限是如何被授予和使用的。
Keeper 在哪些场景中实施零常设特权
Keeper 不会将 ZSP 局限于单一系统或账户类型。 同一 JIT 框架适用于您环境中存在特权访问的任何场景,从用户进行身份验证时所使用的身份提供商,到其背后的云资源、数据库和机器。
覆盖您的身份提供商
Keeper Privileged Cloud 将 JIT 访问扩展至现有身份提供商,包括 AWS IAM、Microsoft Entra ID、通过 Google Identity 实现的 Google Cloud、Okta 和 Active Directory。 Keeper 直接在您现有的基础设施中授予和撤销权限,因此权限提升可在账户所在的现有环境中完成,不会影响用户原有的身份验证方式。 身份提供商仍然是您的权威数据源,而 Keeper 仅控制何时将用户提升至特权组,以及何时将其从特权组中移除。
这种覆盖范围不仅涵盖平台本身,还包括通过这些身份提供商实现联合访问和授权的应用。 联合应用也可以使用 Keeper 进行访问控制,让用户能够将相同的 JIT 模型应用于团队每天登录使用的下游应用。
覆盖云、数据库和机器
由于 ZSP 并不只是云控制台层面的问题,KeeperPAM 还会将相同的权限提升框架扩展至身份提供商之外。 借助 PAM Cloud、PAM Database 和 PAM Machine 记录,您可以将限时访问权限扩展至云资源、数据库和单台机器,使身份层背后的基础设施也遵循相同的访问生命周期。
除了权限提升之外,Keeper Gateway 还会轮换特权凭据,避免这些凭据长期作为静态攻击目标存在;对于数据库和机器,它还可以配置临时账户,并在服务器端注入凭据,使用户无需接触这些凭据。 这一切均基于 Keeper 的零知识架构,这意味着凭据和机密始终采用端到端加密,绝不会暴露给 Keeper 或任何其他人。 自动轮换和零知识架构相结合,可确保即使是用于实现特权访问的凭据,也不会长期留存为攻击者可以窃取和利用的目标。
使用 Keeper 最大限度缩小攻击面
零常设特权只有在得到始终如一的强制执行时才能发挥作用,而这正是 Keeper Privileged Cloud 的优势所在。 借助 Keeper,安全团队能够以可审计的方式按需授予特权访问权限并自动撤销,且可以通过您现有的身份提供程序和基础设施进行操作。 管理员可对“谁能在何时访问什么”获得可验证的控制权;用户则能获取所需的访问权限,既无需等待手动配置,也不会保留不需要的权限。
申请 KeeperPAM 演示,了解即时访问和自动撤销如何在您的环境中发挥作用。
常见问题解答
零常设特权与最小权限有何不同?
最小权限仅允许用户拥有其角色所需的权限,但这些权限通常是常设的,因此无论是否正在使用都会保持有效状态。零常设特权则将最小权限的概念更进一步:不存在默认的访问级别;特权仅在申请并获得批准时授予,并在任务完成后予以撤销。简而言之,最小权限限制了用户可以拥有的访问权限范围,而 ZSP 则缩短了他们持有这些权限的时间,在理想情况下,在确有需要之前完全不授予任何权限。阅读我们的博客,进一步了解零常设特权与最小权限之间的区别。
Keeper 支持哪些身份提供商?
Keeper Privileged Cloud 跨 AWS IAM、Microsoft Entra ID、通过 Google Identity 的 Google Cloud、Okta 和 Active Directory 实施 JIT 访问。 通过这些平台联合访问与授权的应用程序也可以使用 Keeper 进行访问控制,从而将相同的 JIT 模型扩展至连接到您身份提供商的其他应用程序。
审批通过后,用户如何访问资源?
一旦访问请求获得批准,用户便可通过 Keeper 的远程浏览器隔离功能建立安全的浏览器会话,或继续使用其现有工作流(例如 AWS 访问门户或 AWS CLI)。无论采用哪种方式,访问权限仅在授权期限内有效,并在批准的时间范围结束后自动撤销。