在Web或移动应用里让用户直传文件到云存储，如果直接把长期AccessKey交给客户端，一旦包被反编译或前端代码泄露，整个桶都可能被拖库。正确思路是后端用C#向AWS STS申请临时凭证，再回传给客户端，由客户端用这套短时、受限的凭证直接上传。下面先看整体流程示意图。
一、AWS STS临时凭证的核心原理
AWS STS（Security Token Service）负责签发临时安全凭证，包含AccessKeyId、SecretAccessKey和SessionToken三部分。与长期凭证不同，临时凭证具有明确过期时间，且可通过IAM策略限制可操作资源。服务端通常使用AssumeRole接口，让当前执行角色切换到另一个具有上传权限的角色，并附加会话策略进一步缩小权限范围。
在C#中，我们依赖AWSSDK.SecurityToken与AWSSDK.S3包。AssumeRole返回的凭证默认最长一小时，最小十五分钟，足以覆盖一次大文件上传。由于凭证不带长期密钥，即使被截获，攻击者也只能在过期前访问指定前缀的S3对象，风险可控。
1.1 信任策略与外部ID
被切换的角色必须信任服务端运行角色，信任策略中可加入外部ID（ExternalId）防止混淆代理攻击。例如服务端角色ARN为arn:aws:iam::111111111111:role/api-server，上传角色为arn:aws:iam::111111111111:role/s3-upload-temp，则上传角色信任策略应允许api-server并校验外部ID。
外部ID相当于双方约定的口令，避免第三方用自己账户的角色伪造请求。C#调用时需通过AssumeRoleRequest.ExternalId传值，否则STS拒绝签发。这一层在金融或多租户系统中尤为关键。
二、C#服务端生成临时凭证示例
下面是一段完整的控制台程序，演示如何用C#从环境变量读取长期密钥，调用AssumeRole获取临时凭证，并打印给前端用的JSON结构。实际项目中应改为Web API返回。
using System;
using Amazon;
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;
class Program
{
static void Main()
{
// 创建STS客户端，区域按实际修改
var stsClient = new AmazonSecurityTokenServiceClient(
"AKIA_LONG_ACCESS_KEY",
"long_secret_key",
RegionEndpoint.APSoutheast1);
// 构造AssumeRole请求
var request = new AssumeRoleRequest
{
RoleArn = "arn:aws:iam::111111111111:role/s3-upload-temp",
RoleSessionName = "upload-session-" + Guid.NewGuid().ToString("N"),
DurationSeconds = 900, // 15分钟
ExternalId = "my-static-external-id",
// 会话策略：仅允许向user-123/前缀上传
Policy = "{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:PutObject"],"Resource":"arn:aws:s3:::my-bucket/user-123/*"}]}"
};
var response = stsClient.AssumeRole(request);
var creds = response.Credentials;
Console.WriteLine("AccessKeyId: " + creds.AccessKeyId);
Console.WriteLine("SecretAccessKey: " + creds.SecretAccessKey);
Console.WriteLine("SessionToken: " + creds.SessionToken);
Console.WriteLine("Expiration: " + creds.Expiration);
}
}
上述代码把会话策略内联到Policy字段，精确限制资源为my-bucket/user-123/*。这样即便前端拿到凭证，也无法写入其他用户目录。DurationSeconds设为900秒，避免凭证闲置过久。
若使用ASP.NET Core，可将该逻辑封装为Controller，接收用户ID后动态拼接Resource中的前缀，再返回包含三个字段的匿名对象。注意长期密钥应放在Secret Manager而非代码里。
2.1 类似服务：MinIO与阿里云STS
如果不用AWS，自建MinIO也提供类似STS接口，通过AssumeRoleWithCustomPolicy返回临时凭证，C#可用其官方SDK。阿里云则有STS服务，概念完全一致，只是字段名变为SecurityToken与AccessKeySecret。核心思想都是服务端换发短时令牌。
相比自建令牌网关，云厂商STS免去自己实现签名与吊销，且天然集成桶策略。但跨云迁移时要重写客户端适配层，建议把凭证获取抽象为接口，便于替换底层实现。
三、客户端如何使用临时凭证上传
前端拿到C#下发的JSON后，使用对应云SDK初始化客户端。以浏览器端AWS S3 SDK为例，用临时凭证构造S3对象，即可直传。由于SessionToken必须随请求发送，任何遗漏都会导致403。
// 假设从接口拿到 data: {accessKeyId, secretAccessKey, sessionToken}
const s3 = new AWS.S3({
accessKeyId: data.accessKeyId,
secretAccessKey: data.secretAccessKey,
sessionToken: data.sessionToken,
region: 'ap-southeast-1'
});
const params = {
Bucket: 'my-bucket',
Key: 'user-123/avatar.png',
Body: file,
ContentType: 'image/png'
};
s3.putObject(params, function(err, res) {
if (err) console.error('上传失败', err);
else console.log('上传成功', res);
});
客户端应把凭证留在内存，不做持久化。上传完成即丢弃，下次再向C#后端申请。这样即使页面被攻破，泄露的也只是一次会话凭证。
对于大文件，可结合S3分片上传，每片都用同一临时凭证，只要在过期前完成即可。若预计超时需要刷新，可由C#提供续期接口，但更简单的做法是前端预估大小后申请合适时长。
四、权限收敛与常见误区
很多团队只限制Action为s3:PutObject，却忘了在Resource里加用户前缀，结果所有用户能互写他人目录。正确做法是C#按登录态拼接Resource，如arn:aws:s3:::my-bucket/{userId}/*，绝不可放成my-bucket/*。
另一个误区是过期时间设成一小时而前端慢速网络传不完。应监控上传耗时，把DurationSeconds与文件大小关联。同时，STS调用本身有频率限制，高并发下可做服务端缓存同一角色会话，复用凭证直至临期前刷新。
| 方案 | 优点 | 缺点 |
|---|---|---|
| 长期密钥直传 | 实现简单 | 泄露即失控 |
| AWS STS临时凭证 | 时效可控、权限细粒度 | 需后端签发逻辑 |
| 预签名URL | 无需客户端SDK | 只能单对象、难控并发 |
预签名URL也是C#可生成的另一种临时授权，但只针对单个PUT请求，不适合多文件或断点续传。STS凭证更通用，尤其当客户端还需列举或分片时。
五、总结实践要点
用C#集成AWS STS的核心步骤：配置被切换角色的信任策略含外部ID；服务端用AssumeRole并内联会话策略限制前缀；把凭证经HTTPS返回前端；客户端直传并及时丢弃。类似MinIO、阿里云STS均可套用该模型。把长期密钥锁在后端，才是文件上传权限管理的稳妥解法。