C#对接阿里云OSS：RAM临时密钥与STS令牌完整指南

做过阿里云 OSS 对接的朋友，基本都遇到过同一个坎：AccessKey 怎么给才安全？尤其是用 C# 做后端服务，要给客户端签发上传凭证、要给不同部门隔离权限、要跑定时任务批量拉取文件，总不能把主账号的 AccessKey 直接塞进代码里，那等于把保险柜钥匙挂在门上。正确的做法，就是走 RAM 临时访问密钥这条路，配合 STS 令牌，让每个业务模块拿到的都是“一次性、限定权限、定时失效”的凭证。

这篇文章我就围绕“阿里云 OSS + C# SDK + RAM 临时密钥”这套组合，从 RAM 配置、角色授权、C# 代码调用 AssumeRole 拿凭证，到 OSS Client 用临时密钥初始化，再到常见的 403、签名失败、时区坑，一次性讲透。写这篇的缘由，是我自己也在这套流程里踩了不少坑，很多细节文档里写得零散，搜一圈下来都是碎片，今天直接整理成一篇完整可照做的。

1. 为什么非要用 RAM 临时访问密钥

1.1 长期密钥的隐患

先说个最直白的道理。OSS 的 AccessKeyId 和 AccessKeySecret 一旦泄露，别人就能用这对密钥随意读取、删除、覆盖你 Bucket 里的所有对象。主账号 AccessKey 的权限是“账号下全部资源”，开了它等于把自己的云上资产裸奔。我见过不少团队图省事，直接把 AccessKey 写死在 App 的配置文件里，或者从前端页面里能直接扒出来，这种属于安全事故的定时炸弹，只是还没爆。

长期密钥（RAM 用户 AccessKey）要比主账号好一点，但它仍然是永不过期的静态凭证。只要它在代码里存在一天，就永远有被拖库、被日志收集、被员工泄露的风险。而且一旦泄露，你要“止血”就只能在控制台手动禁用或删除，过程繁琐，而且你根本不知道从泄露到发现这中间被刷了多少流量。

1.2 临时密钥的核心优势

RAM 临时访问密钥本质上是一个“动态签发”的凭证，由 STS（Security Token Service）这个服务负责发放。你拿到的是三件套：临时 AccessKeyId、临时 AccessKeySecret、SecurityToken。和长期密钥最大的区别是：

• 有过期时间，默认 3600 秒，最长可以开到 43200 秒（12 小时）
• 权限完全由角色决定，不是“你自己有什么权限”，而是“这个角色被授予了什么权限”
• 过期后自动失效，就算被泄露，攻击者拿到的也是一张“已经作废的房卡”
• 可以通过角色体系做权限隔离，不同服务、不同部门、不同环境各用各的角色

所以，只要你的架构里有“服务端签发凭证”这个环节，无论是对接 C# 后端、Java 后端，还是给前端直传用，RAM 临时密钥都是当前在阿里云体系内最稳妥的认证方式。

1.3 适用场景判断

也不是所有地方都必须用临时密钥。如果你是在自己的服务器上跑一个内部工具，密钥不出内网，长期密钥也不是不能用。但一旦涉及以下场景，建议直接切换：

• 客户端/前端直传 OSS（最常见，必须用 STS 签发临时上传凭证）
• 多部门或多环境共用账号，需要隔离权限
• 代码仓库、CI/CD 流水线里需要云资源访问凭证
• 外部合作方需要临时访问你某个 Bucket 的部分目录
• 合规审计要求密钥必须周期性轮转

2. RAM 侧的配置：角色、策略、信任关系

2.1 先想清楚权限模型

动手之前，先想明白一个问题：谁去申请临时密钥？申请到的临时密钥拥有什么权限？

这句话拆开就是两步。第一步，“谁去申请”——你需要一个 RAM 用户（或者另一个角色），它拥有调用 STS AssumeRole 接口的权限；第二步，“能申请到什么”——你创建一个 RAM 角色，这个角色的权限策略决定了临时密钥最终能干什么。

举个例子。你的 C# 服务叫 file-service，它需要上传文件到 Bucket 的 image/ 目录。那么：

• RAM 用户：file-service-runner，给它授予 AliyunSTSAssumeRoleAccess 权限
• RAM 角色：oss-image-uploader，角色的权限策略只允许 PutObject 到 oss://your-bucket/image/*
• 角色信任策略：允许 file-service-runner 这个 RAM 用户 AssumeRole

这样设计的好处是：权限链是“用户 → 角色 → 资源”，每一级都可以单独控制。以后新增一个服务，只需要复制一个新的角色、改改权限策略，不需要把密钥复制来复制去。

2.2 创建 RAM 用户的步骤

登录阿里云 RAM 控制台，左侧选“身份管理 → 用户”，创建一个用户：

• 登录名称：建议用业务名，比如 file-service-runner
• 访问方式：勾选“OpenAPI 调用访问”（也就是编程访问），系统会生成 AccessKeyId 和 AccessKeySecret
• 保存好这对密钥，它相当于你 C# 服务的“长期身份凭证”，用来换取临时密钥

创建好后，给这个用户授权。点“添加权限”，搜索并勾选 AliyunSTSAssumeRoleAccess。这个权限的意思是：允许调用 STS 的 AssumeRole 接口。注意，它并不代表能访问 OSS 里的数据，OSS 的权限在角色上，不在这个用户上。

2.3 创建 RAM 角色并配置信任策略

再回到 RAM 控制台，左侧“身份管理 → 角色”，创建角色：

• 类型选“阿里云账号”，意思就是这个角色是给本账号下的实体用的
• 角色名称：oss-temp-uploader（随便起，但你会在代码里用到 ARN，最好起得规范些）

创建好后，打开角色的“信任策略管理”。默认的信任策略长这样：

json复制{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": "acs:ram::1234567890123456:root"
      }
    }
  ],
  "Version": "1"
}

注意这里的 Principal。如果是创建角色时选“阿里云账号”，默认是允许整个账号内的所有 RAM 实体都来 AssumeRole。更严谨的做法是把它收紧到只允许刚才那个 RAM 用户：

json复制{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": "acs:ram::1234567890123456:user/file-service-runner"
      }
    }
  ],
  "Version": "1"
}

这样，只有 file-service-runner 能拿到这个角色的临时密钥，账号下其他用户都不行。

2.4 角色权限策略的精简原则

接着是角色的“权限策略”。点“添加权限”，这里有两种方式：

• 用系统策略：比如 AliyunOSSFullAccess，但这样粒度太粗，临时密钥能干所有 OSS 的事，违背最小权限原则
• 自定义策略：建议自己写，精确到 Bucket 和目录级别

如果只是做上传，自定义策略可以这样写：

json复制{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:PutObject"
      ],
      "Resource": [
        "acs:oss:*:*:your-bucket/image/*"
      ]
    }
  ]
}

如果还要读取和列举，再补上 GetObject、ListObjects：

json复制{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject",
        "oss:PutObject"
      ],
      "Resource": [
        "acs:oss:*:*:your-bucket/image/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects"
      ],
      "Resource": [
        "acs:oss:*:*:your-bucket"
      ],
      "Condition": {
        "StringLike": {
          "oss:Prefix": [
            "image/*"
          ]
        }
      }
    }
  ]
}

写策略的时候，Resource 的格式是 acs:oss:{region}:{account_id}:{bucket_name}/{object_path}。Object 路径可以用通配符 * 表示任意层级，也可以用 ? 匹配单字符。这一段是你在 RAM 侧花费时间最多的部分，但也是临时密钥安全性最有保障的一环——一旦写错了，临时密钥的权限就是散的。

提示：RAM 策略的改动是即时生效的，但如果你在 C# 端已经缓存了临时密钥，策略调整不会影响已签发的令牌，只对新签发的凭证生效。

3. C# 侧获取临时密钥的完整实现

3.1 引入依赖

我这边用的是阿里云官方提供的 STS SDK。在 NuGet 里搜 aliyun-net-sdk-sts，同时它依赖 aliyun-net-sdk-core，装的时候会把核心包一起带上。如果你用的是新版的统一 SDK，也可以直接装 AlibabaCloud.SDK.Sts20150401，这个包基于 .NET Core 3.1+，API 风格和旧版略有差别。这里我讲的是老牌的 aliyun-net-sdk-sts，它稳定、文档多、网上照着抄的也多。

在项目文件里执行：

bash复制dotnet add package aliyun-net-sdk-sts

如果你用 Visual Studio 的包管理界面，搜“Aliyun.SDK.StS”或者“aliyun-net-sdk-sts”，注意看清作者是 Aliyun，包名别搞混。装完检查输出的依赖，确认带了 aliyun-net-sdk-core。

3.2 AssumeRole 参数解释

调用 STS 之前，先要把四个关键参数弄清楚：

• AccessKeyId / AccessKeySecret：步骤 2.2 里创建的 RAM 用户的长期密钥，在代码里通过环境变量或配置中心读取，不要硬编码
• RoleArn：RAM 角色的全局资源名。格式是 acs:ram::{account_id}:role/{role_name}，在控制台的角色详情页可以直接复制，长这样：acs:ram::1234567890123456:role/oss-temp-uploader
• RoleSessionName：会话名称，你随便起，但建议用能标识调用来源的字符串，比如 file-service 或 client-session-001。它会在审计日志中出现，方便排查问题
• DurationSeconds：临时凭证的有效期，单位秒。默认 3600。阿里云允许的范围是 900 到 43200，但角色最大会话时间还会受控制台里“最大会话时间”设置的限制，如果你设了 7200，那代码里传 3600 没问题，传 7200 也可以，传 9000 就会被拒绝

代码调用的思路：用 RAM 用户密钥构造一个 DefaultProfile，拿到 DefaultAcsClient，然后构建 AssumeRoleRequest，把上面几个参数塞进去，调用后从响应的 Credentials 节点里取出三件套。

3.3 完整代码示例

下面这段是我在 .NET 6 环境里实测过的代码，核心步骤都写清楚了：

csharp复制using Aliyun.Acs.Core;
using Aliyun.Acs.Core.Profile;
using Aliyun.Acs.Sts.Model.V20150401;

public class StsTokenService
{
    private readonly string _accessKeyId;
    private readonly string _accessKeySecret;
    private readonly string _roleArn;
    private readonly string _roleSessionName;

    public StsTokenService(string accessKeyId, string accessKeySecret, string roleArn, string roleSessionName)
    {
        _accessKeyId = accessKeyId;
        _accessKeySecret = accessKeySecret;
        _roleArn = roleArn;
        _roleSessionName = roleSessionName;
    }

    public AssumeRoleResponse.Credentials_ GetTempCredentials()
    {
        // regionId 建议和 OSS Bucket 所在地域一致，但 STS 服务是独立的，国内站通用
        IClientProfile profile = DefaultProfile.GetProfile(
            "cn-hangzhou",
            _accessKeyId,
            _accessKeySecret
        );

        DefaultAcsClient client = new DefaultAcsClient(profile);

        AssumeRoleRequest request = new AssumeRoleRequest();
        request.RoleArn = _roleArn;
        request.RoleSessionName = _roleSessionName;
        request.DurationSeconds = 3600; // 过期时间，按需调整

        AssumeRoleResponse response = client.GetAcsResponse(request);

        if (response?.Credentials == null)
        {
            throw new Exception("STS AssumeRole 返回为空");
        }

        return response.Credentials;
    }
}

拿到 response.Credentials 之后，里面有：

• Credentials.AccessKeyId：临时 AccessKeyId
• Credentials.AccessKeySecret：临时 AccessKeySecret
• Credentials.SecurityToken：SecurityToken，这个必须保存好，OSS Client 初始化时会用到
• Credentials.Expiration：过期时间，格式是 UTC 时间字符串，比如 2025-06-01T12:00:00Z

我自己测试时，整个调用链路从发出请求到拿到响应，一般 100ms 左右，非常快。但这个请求是走公网到 STS 服务的，如果你的服务器在阿里云 VPC 内，建议使用 VPC 接入地址 sts-vpc.aliyuncs.com，通过 DefaultProfile.AddEndpoint("cn-hangzhou", "cn-hangzhou", "Sts", "sts-vpc.aliyuncs.com") 这种方式自定义 Endpoint，能避免公网延迟和抖动。

3.4 新版本 SDK 的写法差异

如果你在新项目里用的是 AlibabaCloud.SDK.Sts20150401 这个包，代码风格稍有不同，核心模块是 AlibabaCloud.OpenApiClient。大致长这样：

csharp复制using AlibabaCloud.SDK.Sts20150401;
using AlibabaCloud.SDK.Sts20150401.Models;

var config = new AlibabaCloud.OpenApiClient.Models.Config
{
    AccessKeyId = accessKeyId,
    AccessKeySecret = accessKeySecret,
    Endpoint = "sts.cn-hangzhou.aliyuncs.com"
};

var client = new Client(config);
var request = new AssumeRoleRequest
{
    RoleArn = roleArn,
    RoleSessionName = roleSessionName,
    DurationSeconds = 3600
};

var response = await client.AssumeRoleAsync(request);
var credentials = response.Body.Credentials;

新版 SDK 的老版本依赖冲突会少一些，但如果你所在的团队项目里已经有了老版 aliyun-net-sdk-core，直接混用两个 STS SDK 反而容易出程序集版本问题，建议统一用一种。

4. OSS C# SDK 使用临时密钥初始化与上传实操

4.1 初始化 OSSClient

拿到临时密钥之后，下一步就是用它在 OSS SDK 里构造 OssClient。两种方式：

第一种，直接传入临时密钥三件套：

csharp复制using Aliyun.OSS;

var endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
var accessKeyId = tempCredentials.AccessKeyId;
var accessKeySecret = tempCredentials.AccessKeySecret;
var securityToken = tempCredentials.SecurityToken;

var ossClient = new OssClient(endpoint, accessKeyId, accessKeySecret, securityToken);

第二种，用 ClientConfiguration 配置。如果需要对超时、重试做调整，可以这样：

csharp复制var config = new ClientConfiguration
{
    ConnectionTimeout = 10000,
    MaxErrorRetry = 3
};

var ossClient = new OssClient(endpoint, accessKeyId, accessKeySecret, securityToken, config);

注意：Endpoint 的格式要写完整。国内地域一般用 https://oss-cn-hangzhou.aliyuncs.com，如果你用了 Bucket 绑定的自定义域名，那就要传自定义域名，同时如果是 HTTPS 且证书没问题，直接把域名传进去即可。

4.2 一个完整的上传示例

临时密钥初始化好之后，操作 OSS 和普通密钥没有区别。下面是一个上传本地图片到 image/ 目录的示例：

csharp复制public async Task<string> UploadImageAsync(Stream fileStream, string fileName)
{
    var temp = _stsTokenService.GetTempCredentials();

    var endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
    var bucketName = "your-bucket";

    using var ossClient = new OssClient(
        endpoint,
        temp.AccessKeyId,
        temp.AccessKeySecret,
        temp.SecurityToken);

    var objectKey = $"image/{DateTime.UtcNow:yyyyMMdd}/{fileName}";

    var putObjectRequest = new PutObjectRequest(bucketName, objectKey, fileStream)
    {
        Metadata = new ObjectMetadata
        {
            ContentType = "image/jpeg",
            ContentLength = fileStream.Length
        }
    };

    var result = await ossClient.PutObjectAsync(putObjectRequest);

    if (result.HttpStatusCode == System.Net.HttpStatusCode.OK)
    {
        return $"https://your-bucket.oss-cn-hangzhou.aliyuncs.com/{objectKey}";
    }

    throw new Exception($"上传失败，状态码：{(int)result.HttpStatusCode}");
}

这里有两个细节需要注意。第一，OssClient 在临时密钥过期后，会抛出 AccessDenied 异常，所以每次生成密钥前，最好判断一下当前密钥的过期时间，如果快过期了就重新通过 STS 获取，不要硬撑到过期再创建新 Client。第二，临时密钥的权限只覆盖 image/* 目录，如果你上传的 objectKey 是 avatar/20250601/xxx.jpg，就会直接 403。所以，角色策略里的目录前缀和代码里的 objectKey 必须对齐，这一条写进团队规范里，能省掉后续大量扯皮。

4.3 生产环境的缓存与刷新策略

直接每次都调用 STS 拿临时密钥也行，但 STS 接口本身有 QPS 限制，而且网络调用会拖慢每次上传的响应时间。生产环境建议做一层缓存。

我常用的方案是：在内存里维护一个静态变量，存储三元组和过期时间，只要当前时间距离过期时间大于 5 分钟，就直接复用缓存的密钥；否则重新走 STS 获取并更新缓存。

csharp复制public class StsTokenCache
{
    private static readonly object LockObj = new object();
    private static (string AccessKeyId, string AccessKeySecret, string SecurityToken, DateTime Expiration) _cache;

    public static (string, string, string, DateTime) GetOrRefresh(Func<(string, string, string, DateTime)> acquireFunc)
    {
        lock (LockObj)
        {
            if (_cache.Expiration != default &&
                _cache.Expiration.AddMinutes(-5) > DateTime.UtcNow)
            {
                return (_cache.AccessKeyId, _cache.AccessKeySecret, _cache.SecurityToken, _cache.Expiration);
            }

            _cache = acquireFunc();
            return (_cache.AccessKeyId, _cache.AccessKeySecret, _cache.SecurityToken, _cache.Expiration);
        }
    }
}

这个方案在多线程下也能跑，因为加了锁，避免并发去刷新 Token。但如果你的应用是多实例部署（负载均衡后面挂了好几台机器），本地缓存会造成每个实例各拿一个 Token，虽然不冲突，但会多消耗 STS 的 QPS。更优的方案是放到 Redis 里，用过期时间作为 Redis Key 的 TTL，这样所有实例共享同一个缓存。

注意：STS 临时凭证过期前的一小段时间，OSS 服务端可能已经拒绝请求。所以“提前 5 分钟”刷新不是拍脑袋定的，是实践下来比较稳妥的提前量。

5. 常见问题与排查技巧实录

5.1 错误码速查表

这套链路里你遇到的大部分报错，都能归结为下表中的一个：

5.2 每次都是 403？先查角色策略

真实项目里，最常出现的坑就是：代码逻辑完全没问题，密钥也是从 STS 拿到的，但一上传就 403。最终定位下来，90% 是角色权限策略写得不对。

举几个我踩过的例子：

• Resource 写成了 acs:oss:*:*:your-bucket，只授权到 Bucket 级别，没有授权 Object 级别，导致 PutObject 失败。需要写成 acs:oss:*:*:your-bucket/*
• Action 里写了 oss:PutObject，但用的是分片上传，需要 oss:InitiateMultipartUpload、oss:UploadPart、oss:CompleteMultipartUpload 这些权限
• 使用 OSS 控制台或某些 SDK 的 ListObjects 功能时，需要对 Bucket 本身有 oss:ListObjects 权限，但很多人只给了 Object 级别权限，于是列举时能列出一部分，上传时就挂

遇到 403，我建议你在 RAM 控制台左侧找到“权限分析”或者“RAM Policy Simulator”，输入你的角色 ARN 和想调试的 Action、Resource，它能告诉你这条策略到底是允许还是拒绝，比盲试快得多。

5.3 服务器时间偏差引发的 SignatureDoesNotMatch

这个问题看似不相关，但实际遇到的人不少。OSS 签名时会带一个时间戳，如果服务器本地时间和 NTP 标准时间偏差过大，服务端校验签名时就会判定请求无效，抛 RequestTimeTooSkewed。

排查方式很简单：在 C# 服务里输出 DateTime.UtcNow，和标准时间对比。如果偏差在分钟级，检查一下服务器的时间同步服务是否正常运行。在容器环境里，有些基础镜像默认不带 NTP 服务，这时候要在镜像构建时加一行 RUN apt-get install -y ntpdate && ntpdate ntp.aliyun.com，或者在容器启动命令里挂载主机时间。

还有一种情况：代码里生成签名时用的是本地时间，但服务器在东八区，OSS SDK 内部默认会用 UTC 计算签名。如果你手动改过服务器的时区或者时间格式，也可能导致签名串计算出错。我的建议是：除非有明确需求，服务器时间一律用 UTC，应用代码里所有时间比较也统一用 UTC，只在展示层转换为本地时间。

5.4 STS Endpoint 选错导致超时

我在早期对接时，曾直接把 Endpoint 写成 sts.aliyuncs.com，在大部分区域都能通，但偶尔会遇到网络超时。后来查了阿里云的文档，发现 STS 的接入地址支持按地域就近选择，比如 sts.cn-hangzhou.aliyuncs.com、sts.ap-southeast-1.aliyuncs.com。如果你服务部署在华东 2（上海），却用 sts.ap-southeast-1.aliyuncs.com，请求就会绕远路。

解决办法是在代码里显式指定 RegionId 和 Endpoint：

csharp复制DefaultProfile.AddEndpoint("cn-shanghai", "cn-shanghai", "Sts", "sts.cn-shanghai.aliyuncs.com");
var profile = DefaultProfile.GetProfile("cn-shanghai", accessKeyId, accessKeySecret);

这条配置写在构造函数里，全局生效一次即可。

5.5 临时密钥能用多久

最后再说说 DurationSeconds 的选择。如果你只是想给前端直传签发一个“一次性上传凭证”，30 分钟足够；如果是给后端服务常驻使用，建议 6 到 12 小时，配合缓存刷新，既减少 STS 调用次数，又不会让密钥长时间暴露在内存里。

但是要注意，DurationSeconds 不是你想设 43200 就能设 43200。RAM 角色在控制台里有一个“最大会话时间”的配置，默认 3600 秒，如果代码请求的时长超过它，会直接报错。所以两处要一起调：控制台的角色信任策略里把“最大会话时间”改成 43200，然后代码里才能设到 43200。这个细节很多人第一次对接时会漏。

5.6 前端直传场景的 STS 用法

如果你做的是 SPA 应用或者小程序，文件上传不想经过后端服务器，那流程稍有点不同。后端用 STS 拿临时密钥，把三件套连同 Expiration 一起返回给前端，前端直接用 OSS JS SDK 或小程序 SDK 发起直传，文件流不经过服务器，服务器的带宽和内存压力一下就下来了。后端只需要提供一个签发接口，例如 /api/oss/token，内部走的就是本文讲的这套流程。

前端拿到的临时密钥也要限定策略，比如只允许上传到 upload/{userId}/ 目录，同时限制文件大小和类型。这些限制除了在 OSS 侧通过 Policy 做，也可以在 STS 角色的权限策略里配合 Condition 实现，比如限制 oss:Content-Length 的范围，或者要求请求必须带特定的 x-oss-meta-* 头。策略写得好，前端直传的玩法其实很灵活。

6. 提权与审计机制及最佳实践

6.1 用 RAM 的权限模型做多环境隔离

如果你有 dev、staging、prod 三套环境，建议给每套环境建一个独立的 RAM 角色，比如 oss-dev-uploader、oss-prod-uploader，角色策略里把 Bucket 或目录区分开。这样 dev 环境的临时密钥就算泄露，攻击者也碰不到 prod 的数据。这不是什么高深技巧，就是把之前说的“最小权限”思路放大到环境维度，实际效果非常好。

另外，如果一个 Bucket 有多个业务方共用，可以在角色策略里用 oss:Prefix 条件限制不同角色只能操作各自的前缀目录。这块我上面给过示例，思路是按目录切分资源，而不是一个角色一把钥匙全部放行。

6.2 审计日志：出现问题不抓瞎

临时密钥不是“银弹”，它只是缩小了风险边界。一旦真的出了问题，审计能力就是你的底牌。

在阿里云控制台，打开“操作审计”服务，全部 OSS 的写操作、STS AssumeRole 调用都有记录。日志里会包含：

• 什么时间
• 哪个 RAM 用户 / 角色
• 通过哪个 RoleSessionName
• 访问了哪个 Bucket 的哪个 Object
• 源 IP 是什么

我的建议是：在 RoleSessionName 里尽量带上业务标识，比如 order-service、usercenter-app，这样排查问题时能从日志里一眼看出是哪个模块在调用。如果你传的是随机 GUID，审计日志基本等于没用，查起来要把所有会话摊开找线索。

6.3 定期轮转 RAM 用户密钥

虽然我们讨论的是临时密钥，但别忘了，签发临时密钥的那个 RAM 用户长期密钥，本身也要定期轮转。阿里云控制台支持为 RAM 用户创建多个 AccessKey，最多两个。你可以在一个密钥即将过期前创建第二个，然后把旧密钥从代码配置里替换掉，过段时间再删除旧密钥。这个轮转流程可以做成脚本，或者干脆交给运维平台定时执行。

另外，RAM 控制台里可以查看 AccessKey 的最后使用时间，如果发现半年都没用过的密钥，直接禁用或删除，别留着过年。

6.4 避免在代码仓库里出现任何形式的密钥

这是最后一道防线。.gitignore 把包含 AccessKey 的配置文件全部忽略，用环境变量、KMS、配置中心承载密钥。我见过不只是小团队，甚至一些大公司也会出现 AccessKey 被提交到 GitHub 后，被爬虫抓到并刷出高额账单的案例。正式环境里，RAM 用户密钥应该放到阿里云 KMS 或者 Secrethub 之类的服务里，运行时动态读取，而不是提前写死在配置文件里。

最后再分享一个我在实际项目中养成的习惯：每次申请临时密钥后，用 Credentials.Expiration 和本地时间做一次差值计算，如果发现差值明显小于 DurationSeconds，说明服务端可能返回了过期时间异常（比如时区问题）。这种“防御式检查”看着不起眼，但帮你拦下过很多次因配置错误导致的线上事故。过期的临时密钥就像过期的优惠券，看着能用，一用就废。