Implementing Zero Standing Privilege With Cyberark

使用 CyberArk 实施零常设权限

概述

零常设权限（ZSP）是一种安全模型，在该模型中，任何用户或身份都不保留持久的特权访问权限。相反，提升的访问权限以即时（JIT）方式动态配置，并在使用后自动撤销。CyberArk 通过其 Secure Cloud Access（SCA）模块实现 ZSP，该模块在云环境（AWS、Azure、GCP）中创建临时的、范围受限的角色，这些角色仅在会话期间存在。TEA 框架（时间、权限和审批）管理每个特权访问会话。

前提条件

• CyberArk Identity Security Platform（Privilege Cloud 或自托管版本）
• CyberArk Secure Cloud Access（SCA）许可证
• 具有管理员访问权限的云提供商账户（AWS、Azure、GCP）用于集成
• ITSM 集成（ServiceNow、Jira）用于审批工作流
• 已配置安全保险箱管理的 CyberArk Vault

核心概念

TEA 框架（时间、权限、审批）

ZSP 架构

用户通过 CyberArk 申请访问
        │
        ├── CyberArk 根据策略评估请求:
        │   ├── 用户是否有资格访问？
        │   ├── 请求是否符合 TEA 策略？
        │   └── 是否需要审批？
        │
        ├── [如需审批] → 路由到审批人（ITSM/ChatOps）
        │
        ├── 获批后:
        │   ├── CyberArk 在目标云中创建临时 IAM 角色
        │   ├── 将权限限定为最小所需权限
        │   ├── 设置会话 TTL（时间绑定）
        │   └── 配置临时凭据
        │
        ├── 用户通过会话访问云资源
        │   ├── 记录和录制所有操作
        │   └── 监控会话是否违反策略
        │
        └── 会话到期:
            ├── 临时角色已删除
            ├── 临时凭据已撤销
            └── 零常设权限保持

CyberArk 组件

实施步骤

第 1 步：集成云提供商

AWS 集成：

1. 在 AWS IAM 中为 CyberArk 创建集成角色
2. 配置允许 CyberArk 代入角色的跨账户信任策略
3. 创建定义最大允许权限的 IAM 策略
4. 在 CyberArk SCA 中注册 AWS 账户

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::CYBERARK_ACCOUNT:role/CyberArkSCARole"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringEquals": {
                "sts:ExternalId": "cyberark-external-id"
            }
        }
    }]
}

Azure 集成：

1. 在 Microsoft Entra ID 中将 CyberArk 注册为企业应用程序
2. 授予 CyberArk 应用权限：Directory.ReadWrite.All、RoleManagement.ReadWrite.Directory
3. 创建具有限定范围权限的自定义 Azure 角色
4. 在 CyberArk SCA 中注册 Azure 订阅

GCP 集成：

1. 在 GCP 中为 CyberArk 创建服务账户
2. 授予 IAM 管理员和服务账户管理员角色
3. 配置工作负载联合身份认证以实现跨云访问
4. 在 CyberArk SCA 中注册 GCP 项目

第 2 步：定义访问策略

创建将职能映射到云权限的策略：

# CyberArk SCA 策略示例
policy_name: "developer-aws-read-access"
description: "开发者对 AWS 生产环境的只读访问"
target_cloud: "aws"
target_accounts: ["123456789012", "987654321098"]

time_policy:
  max_duration: "4h"
  default_duration: "1h"
  business_hours_only: true
  timezone: "America/New_York"

entitlement_policy:
  aws_managed_policies:
    - "arn:aws:iam::aws:policy/ReadOnlyAccess"
  deny_actions:
    - "iam:*"
    - "organizations:*"
    - "sts:*"
  resource_restrictions:
    - "arn:aws:s3:::production-*"

approval_policy:
  approval_required: true
  approvers:
    - type: "manager"
    - type: "group"
      group: "cloud-security-team"
  auto_approve_conditions:
    - previous_approved_same_policy: true
      within_days: 7
  escalation_timeout: "2h"
  escalation_approver: "cloud-security-lead"

第 3 步：配置会话监控

设置特权会话录制和实时监控：

1. 为所有 ZSP 会话启用会话录制
2. 为 SSH/RDP 会话配置击键日志
3. 设置可疑活动的实时告警：
   • 会话期间尝试提升权限
   • 访问策略范围外的资源
   • 会话时长超过正常模式的 2 倍
4. 将会话元数据转发至 SIEM

第 4 步：实现审批工作流

与 ITSM 工具集成以实现访问请求和审批：

• ServiceNow：CyberArk SCA 连接器创建 ServiceNow 工单进行审批
• Slack/Teams：用于在消息平台快速审批的 ChatOps 机器人
• Jira：用于开发相关访问请求的集成
• 自动审批：为低风险、已批准过的请求配置规则

第 5 步：从常设权限迁移

第一阶段：发现（第 1-2 周）
    ├── 清点所有云账户中的常设特权角色
    ├── 将用户映射到其常设角色分配
    ├── 分析 CloudTrail/活动日志中的实际权限使用情况
    └── 识别可转换为 JIT 的角色

第二阶段：策略创建（第 3-4 周）
    ├── 基于实际使用分析创建 ZSP 策略
    ├── 为每个策略定义 TEA 参数
    ├── 配置审批工作流
    └── 使用试点用户测试策略

第三阶段：迁移（第 5-8 周）
    ├── 向试点组分配 ZSP 策略
    ├── 移除试点用户的常设权限
    ├── 监控访问问题并调整策略
    ├── 逐步扩展至更多团队
    └── 移除组织范围内的所有常设权限

第四阶段：治理（持续进行）
    ├── 每月审查 ZSP 策略有效性
    ├── 每季度优化权限配置
    ├── 监控策略漂移或常设权限重新创建
    └── 向安全领导层报告 ZSP 指标

验证清单

• 云提供商已与 CyberArk SCA 集成
• 已为所有特权访问场景定义 TEA 策略
• 审批工作流已配置并测试
• 会话录制和监控已启用
• 已识别所有待迁移的常设特权角色
• 试点组已在无常设权限的情况下成功使用 ZSP
• 已为紧急访问定义紧急访问程序
• SIEM 集成接收会话和访问日志
• 已为低风险、重复访问配置自动审批规则
• 全组织迁移计划已获批准并排期
• KPI 跟踪：常设权限分配的减少情况

参考资料

• CyberArk 零常设权限
• 使用 CyberArk 在 AWS 上实施 ZSP
• CyberArk Blueprint - 零常设权限
• CyberArk Secure Cloud Access 文档