Daily Study
更新: 8/11/2025 字数: 0 字 时长: 0 分钟
Daily Plan
#todo
- [ ]
AK和SK的作用
- AK（Access Key、AccessKeyId、SecretId 等别名）：
- 公开的“身份标识”，相当于用户名或凭证 ID，用来告诉云端“我是哪个调用方”。
- SK（Secret Key、AccessKeySecret、SecretKey 等别名）：
- 保密的“签名密钥”，相当于密码/私钥，用来对请求进行加密签名，证明“确实是我发的，且未被篡改”。
AK 与 SK 的区别与关系
- 用途：
- AK 只负责标识身份，不保密；通常会出现在 Authorization 头、Credential 字段、或日志里。
- SK 负责签名鉴权，必须严格保密；绝不应出现在网络传输、代码仓库或日志中。
- 单独使用的风险与意义：
- 只有 AK 没有 SK：无法伪造有效签名，基本无用。
- 只有 SK 没有 AK：通常也不能直接发起请求（因为签名里要带 AK），但一旦攻击者也知道对应 AK，就能完全冒用；所以仍需最高等级保护。
- 生命周期：
- 永久 AK/SK：长期有效，风险高，推荐仅在受控后端环境配合良好轮换与权限最小化。
- 临时 AK/SK（STS/AssumeRole）：短期有效，常配合一个会过期的 SecurityToken 使用，更安全，推荐绝大多数工作负载使用。
工作方式（签名鉴权的通用流程）
- 客户端拿到 AK/SK（或临时 AK/SK + SecurityToken）。
- 根据云厂商的签名规范对 HTTP 请求进行“规范化”（canonicalization），包括：
- 固定顺序的 HTTP 方法、URI、Query、Headers、以及请求体哈希。
- 用 SK 对“待签名字符串”进行 HMAC（常见 HMAC-SHA256）计算得到签名。
- 在请求中携带：
- Authorization 头：包含算法、AK（Credential）、已签名头部列表（SignedHeaders）、签名值（Signature）。
- 时间戳/日期头（如 X-Amz-Date、X-TC-Timestamp 等）。
- 如果是临时凭证，还要带 Session/Security Token（如 X-Amz-Security-Token、x-acs-security-token）。
- 服务器端用保存的 SK（或安全模块）复算签名，匹配则通过鉴权；同时根据 AK 查找并评估其权限策略（IAM/策略语句），决定是否授权。
应用方式
- SDK/CLI 方式（最常见，首选）
与其他鉴权方式的对比
- AK/SK：偏向“机器到机器”的长期或短期密钥签名；无用户交互；适合后端服务、自动化任务。
- OAuth 2.0 / OIDC / JWT：偏向“用户或应用授权”，通过授权服务器签发短期访问令牌；适合需要用户登录或第三方授权的场景。
- API Key（仅一串 key）：有些平台是“单 key 模式”，往往不含签名，安全性弱于 AK/SK 的 HMAC 签名（除非配合 TLS、白名单、速率限制和极短过期）。
常见场景举例
- 对象存储（S3/OSS/COS）读写：
- 后端服务使用 SDK 携带 AK/SK 调用。
- 前端通过后端换取预签名 URL 或临时凭证后直传，后端不经手文件流量。
- 消息队列、函数计算、数据库 API：
- 在云上计算环境中通过角色和 IMDS 自动注入临时凭证；避免硬编码密钥。
- 跨账号访问：
- 使用 AssumeRole 到对方账号的受限角色，拿临时 AK/SK + Token 访问，替代在对方账号创建长期密钥。