游戏分析集成AWS：如何在代码中安全存储AWS凭证？

我在为游戏公司开发分析功能，需要集成AWS，让后台分析服务把玩家PC端的数据上传到S3存储桶。我已经创建了仅拥有该存储桶对象上传权限的IAM用户，也生成了对应的access key和secret key，但不知道怎么在代码里安全存储这些凭证：

• 想用SecretsManager，但访问它本身也需要凭证，陷入循环；
• 硬编码凭证能正常运行，但上传到GitHub的话，任何人都能操作我的S3存储桶；
• 尝试用SecretsManager获取凭证的代码触发了AmazonServiceException，就算能跑，也没法阻止别人读取密钥。

硬编码凭证的代码（可正常运行但不安全） #

// These are example keys they don't do much
public const string accessKey = "AKIAIOSFODNN7EXAMPLE";
public const string secretKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";

public AWSCredentials credentials => new BasicAWSCredentials(accessKey, secretKey);

尝试通过SecretsManager获取凭证的代码（触发AmazonServiceException） #

[Serializable]
private struct CredentialKeys
{
    public string accessKey;
    public string secretKey;
}

public async Task<AWSCredentials> GetCredentials()
{
    var response = // code for getting secret (not sure if Amazon allows me showing it here).
    
    var json = response.SecretString;
    var keys = JsonUtility.FromJson<CredentialKeys>(json);
    return new BasicAWSCredentials(keys.accessKey, keys.secretKey);
}

1. 优先使用IAM角色而非IAM用户（彻底避免硬编码） #

如果你的后台服务运行在AWS资源上（比如EC2、ECS、Lambda），直接给这些资源绑定仅允许上传目标S3存储桶的IAM角色，AWS SDK会自动从环境中获取临时凭证，完全不用在代码里处理密钥。角色的权限策略示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::你的存储桶名称/*"
        }
    ]
}

2. 本地开发或非AWS环境的安全处理 #

如果服务跑在本地或者非AWS服务器上：

• 不要把密钥写进代码，用环境变量存储access key和secret key，代码中通过环境变量读取：

var accessKey = Environment.GetEnvironmentVariable("AWS_ACCESS_KEY_ID");
var secretKey = Environment.GetEnvironmentVariable("AWS_SECRET_ACCESS_KEY");
public AWSCredentials credentials => new BasicAWSCredentials(accessKey, secretKey);

• 本地开发时，直接用AWS CLI执行aws configure命令配置凭证，SDK会自动读取~/.aws/credentials文件中的内容，代码无需任何修改。

3. SecretsManager的正确打开方式 #

你之前的思路存在误区：SecretsManager适合存储业务敏感信息（比如数据库密码），而非IAM用户密钥。如果一定要用它存储密钥，必须先给运行服务的实体（EC2角色、本地用户）赋予读取该Secret的权限，让SDK能自动获取凭证去读取密钥，打破循环。但这种方式增加了不必要的复杂度，优先选择前两种方案。

4. 硬编码泄漏后的紧急补救 #

如果不小心把真实密钥硬编码上传到GitHub，立刻做以下操作：

1. 登录IAM控制台，删除该用户的access key；
2. 重新生成新的密钥；
3. 检查S3存储桶的访问日志，确认是否有异常操作。

内容的提问来源于stack exchange，提问作者CaseyHofland