delorex/test-repo
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: enhance demo components with consistent styling and info boxes

Browse Source 
- Add standardized header and info box components to all demo files
- Improve visual consistency with theme colors and spacing
- Add max-height and overflow-y for better content containment
- Update package.json build script with --force flag
- Add .gitignore entries for REFACTORING files
- Fix table formatting in audio-intro.md
This commit is contained in:
sanbuphy
2026-02-14 12:14:07 +08:00
parent cd2ce9e661
commit ebe2bf6109
70 changed files with 12307 additions and 10445 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/zh-cn/appendix/cloud-iam.md
+101 -102
View File
@@ -36,12 +36,12 @@
想象一下，你们公司搬到了一栋新写字楼：
| 场景 | 没有 IAM 的做法 | 有 IAM 的做法 |
| :--- | :--- | :--- |
| 新员工入职 | 给他一把能开所有门的万能钥匙 | 给他一张门禁卡，只能刷他办公区域的门 |
| 员工离职 | 钥匙丢了就丢了，也不知道谁拿着 | 立即在系统里注销他的门禁卡，所有门都打不开了 |
| 外包人员 | 把钥匙借给他几天 | 发临时门禁卡，设置3天后自动失效 |
| 访客 | 前台配一把钥匙给他 | 发一次性访客码，只能进会议室 |
| 场景 | 没有 IAM 的做法 | 有 IAM 的做法 |
| :--------- | :----------------------------- | :------------------------------------------- |
| 新员工入职 | 给他一把能开所有门的万能钥匙 | 给他一张门禁卡，只能刷他办公区域的门 |
| 员工离职 | 钥匙丢了就丢了，也不知道谁拿着 | 立即在系统里注销他的门禁卡，所有门都打不开了 |
| 外包人员 | 把钥匙借给他几天 | 发临时门禁卡，设置3天后自动失效 |
| 访客 | 前台配一把钥匙给他 | 发一次性访客码，只能进会议室 |
**IAM（Identity and Access Management，身份与访问管理）**，就像是这套"智能门禁系统"：
@@ -55,13 +55,13 @@
不同的云厂商都有自己的 IAM 实现：
| 云厂商 | 服务名称 | 核心概念 |
| :--- | :--- | :--- |
| **AWS** | IAM (Identity and Access Management) | User、Group、Role、Policy |
| **阿里云** | RAM (Resource Access Management) | 用户、用户组、角色、策略 |
| **腾讯云** | CAM (Cloud Access Management) | 用户、用户组、角色、策略 |
| **华为云** | IAM | 用户、用户组、委托、策略 |
| **Azure** | Azure AD + RBAC | User、Group、Role、RBAC |
| 云厂商 | 服务名称 | 核心概念 |
| :--------- | :----------------------------------- | :------------------------ |
| **AWS** | IAM (Identity and Access Management) | User、Group、Role、Policy |
| **阿里云** | RAM (Resource Access Management) | 用户、用户组、角色、策略 |
| **腾讯云** | CAM (Cloud Access Management) | 用户、用户组、角色、策略 |
| **华为云** | IAM | 用户、用户组、委托、策略 |
| **Azure** | Azure AD + RBAC | User、Group、Role、RBAC |
虽然名字不同，但**核心概念都是相通的**：
@@ -80,11 +80,11 @@
用一个办公室的场景来类比：
| 概念 | 类比 | 适用场景 | 特点 |
| :--- | :--- | :--- | :--- |
| **用户（User）** | 正式员工，有自己的工位和门禁卡 | 长期、稳定的团队成员 | 有永久凭证（密码、AK/SK） |
| **用户组（Group）** | 部门，如"技术部"、"销售部" | 批量管理权限 | 不能登录，只是权限容器 |
| **角色（Role）** | 临时访客证、外包临时卡 | 临时授权、跨账号访问 | 没有永久凭证，靠"扮演"获取临时凭证 |
| 概念 | 类比 | 适用场景 | 特点 |
| :------------------ | :----------------------------- | :------------------- | :--------------------------------- |
| **用户（User）** | 正式员工，有自己的工位和门禁卡 | 长期、稳定的团队成员 | 有永久凭证（密码、AK/SK） |
| **用户组（Group）** | 部门，如"技术部"、"销售部" | 批量管理权限 | 不能登录，只是权限容器 |
| **角色（Role）** | 临时访客证、外包临时卡 | 临时授权、跨账号访问 | 没有永久凭证，靠"扮演"获取临时凭证 |
### 2.2 真实案例：一个创业公司的权限演进
@@ -151,13 +151,13 @@ IAM Role 有两个核心组成部分：
用一个话剧表演的类比：
| 概念 | 类比 | 说明 |
| :--- | :--- | :--- |
| **Role（角色）** | 剧本里的"哈姆雷特" | 定义了要演什么戏（权限）|
| **Trust Policy** | 导演说"谁能演哈姆雷特" | 可能是"本剧团的演员"（本账号用户）、"隔壁剧团借来的演员"（跨账号）、"特邀嘉宾"（外部 IdP）|
| **Permission Policy** | 剧本内容 | 哈姆雷特能做什么：说台词、决斗、发疯（具体权限）|
| **Assume Role** | 演员上台表演 | 小李被导演选中演哈姆雷特，上台后他就拥有了剧本里定义的所有权限 |
| **临时凭证** | 演出证 | 小李拿到一个"临时演出证"，演出结束后就失效了 |
| 概念 | 类比 | 说明 |
| :-------------------- | :--------------------- | :----------------------------------------------------------------------------------------- |
| **Role（角色）** | 剧本里的"哈姆雷特" | 定义了要演什么戏（权限） |
| **Trust Policy** | 导演说"谁能演哈姆雷特" | 可能是"本剧团的演员"（本账号用户）、"隔壁剧团借来的演员"（跨账号）、"特邀嘉宾"（外部 IdP） |
| **Permission Policy** | 剧本内容 | 哈姆雷特能做什么：说台词、决斗、发疯（具体权限） |
| **Assume Role** | 演员上台表演 | 小李被导演选中演哈姆雷特，上台后他就拥有了剧本里定义的所有权限 |
| **临时凭证** | 演出证 | 小李拿到一个"临时演出证"，演出结束后就失效了 |
### 3.2 策略（Policy）：权限的"语法"
@@ -174,11 +174,7 @@ IAM Policy 是一个 JSON 文档，定义了"谁能对什么资源做什么操
{
"Sid": "AllowS3ReadWrite",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::my-app-bucket/*",
"Condition": {
"StringEquals": {
@@ -201,15 +197,15 @@ IAM Policy 是一个 JSON 文档，定义了"谁能对什么资源做什么操
**关键字段解释**：
| 字段 | 含义 | 示例 |
| :--- | :--- | :--- |
| **Version** | Policy 语法版本 | "2012-10-17" |
| **Statement** | 权限声明数组，可包含多个规则 | [...] |
| **Sid** | 声明 ID，可选，用于标识这条规则 | "AllowS3ReadWrite" |
| **Effect** | 效果：Allow（允许）或 Deny（拒绝） | "Allow" |
| **Action** | 允许/拒绝的操作，支持通配符 | "s3:GetObject", "s3:*" |
| **Resource** | 作用的资源，用 ARN 标识 | "arn:aws:s3:::bucket/*" |
| **Condition** | 可选，满足特定条件时才生效 | 区域限制、MFA 要求等 |
| 字段 | 含义 | 示例 |
| :------------ | :--------------------------------- | :----------------------- |
| **Version** | Policy 语法版本 | "2012-10-17" |
| **Statement** | 权限声明数组，可包含多个规则 | [...] |
| **Sid** | 声明 ID，可选，用于标识这条规则 | "AllowS3ReadWrite" |
| **Effect** | 效果：Allow（允许）或 Deny（拒绝） | "Allow" |
| **Action** | 允许/拒绝的操作，支持通配符 | "s3:GetObject", "s3:\*" |
| **Resource** | 作用的资源，用 ARN 标识 | "arn:aws:s3:::bucket/\*" |
| **Condition** | 可选，满足特定条件时才生效 | 区域限制、MFA 要求等 |
### 3.3 权限的优先级：Deny > Allow > 默认拒绝
@@ -246,6 +242,7 @@ IAM 的权限评估逻辑可以用一句话总结：**显式 Deny 永远赢，
```
**关键点**：
- 开发者虽然有 `s3:*` 的 Allow 权限
- 但敏感目录有显式的 Deny 规则
- Deny 优先级更高，所以开发者无法访问敏感数据
@@ -261,10 +258,10 @@ IAM 的权限评估逻辑可以用一句话总结：**显式 Deny 永远赢，
Access Key（访问密钥）是云服务提供的一种长期凭证，用于程序化的 API 调用。它由两部分组成：
| 组成部分 | 名称 | 作用 | 类比 |
| :--- | :--- | :--- | :--- |
| **Access Key ID** | 访问密钥 ID | 标识你是谁（类似于用户名） | 银行卡号 |
| **Secret Access Key** | 秘密访问密钥 | 证明你是你（类似于密码） | 银行卡密码 |
| 组成部分 | 名称 | 作用 | 类比 |
| :-------------------- | :----------- | :------------------------- | :--------- |
| **Access Key ID** | 访问密钥 ID | 标识你是谁（类似于用户名） | 银行卡号 |
| **Secret Access Key** | 秘密访问密钥 | 证明你是你（类似于密码） | 银行卡密码 |
### 4.2 为什么 AK/SK 是"高危物品"？
@@ -302,12 +299,12 @@ upload_file('./test.jpg', 'my-company-bucket', 'uploads/test.jpg')
**这个案例告诉我们什么？**
| 错误做法 | 正确做法 |
| :--- | :--- |
| 把 AK/SK 硬编码在代码中 | 使用 IAM Role，让程序自动获取临时凭证 |
| 把 AK/SK 提交到 Git 仓库 | 使用 `.gitignore` 忽略配置文件，使用密钥管理服务 |
| 长期使用同一个 AK/SK 不轮换 | 定期轮换 AK/SK，使用临时凭证替代长期凭证 |
| 给 AK/SK 分配过大权限 | 遵循最小权限原则，只授予必要的权限 |
| 错误做法 | 正确做法 |
| :-------------------------- | :----------------------------------------------- |
| 把 AK/SK 硬编码在代码中 | 使用 IAM Role，让程序自动获取临时凭证 |
| 把 AK/SK 提交到 Git 仓库 | 使用 `.gitignore` 忽略配置文件，使用密钥管理服务 |
| 长期使用同一个 AK/SK 不轮换 | 定期轮换 AK/SK，使用临时凭证替代长期凭证 |
| 给 AK/SK 分配过大权限 | 遵循最小权限原则，只授予必要的权限 |
### 4.3 AK/SK 的安全使用指南
@@ -356,7 +353,7 @@ jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # 关键：允许请求 OIDC token
id-token: write # 关键：允许请求 OIDC token
contents: read
steps:
- uses: actions/checkout@v3
@@ -374,13 +371,13 @@ jobs:
**总结：AK/SK 使用的安全层级**
| 安全等级 | 做法 | 适用场景 | 风险等级 |
| :--- | :--- | :--- | :--- |
| 最高 | 使用 IAM Role（无长期凭证） | EC2、Lambda、ECS、CI/CD | 极低 |
| 高 | 使用 OIDC Federation | GitHub Actions、GitLab CI | 低 |
| 中 | 使用密钥管理服务 | 本地开发、小团队 | 中 |
| 低 | 使用环境变量 | 快速原型、个人项目 | 高 |
| 极低 | 硬编码在代码中 | 任何场景都不推荐 | 极高 |
| 安全等级 | 做法 | 适用场景 | 风险等级 |
| :------- | :-------------------------- | :------------------------ | :------- |
| 最高 | 使用 IAM Role（无长期凭证） | EC2、Lambda、ECS、CI/CD | 极低 |
| 高 | 使用 OIDC Federation | GitHub Actions、GitLab CI | 低 |
| 中 | 使用密钥管理服务 | 本地开发、小团队 | 中 |
| 低 | 使用环境变量 | 快速原型、个人项目 | 高 |
| 极低 | 硬编码在代码中 | 任何场景都不推荐 | 极高 |
---
@@ -392,21 +389,21 @@ jobs:
MFA（Multi-Factor Authentication，多因素认证），也叫 2FA（Two-Factor Authentication，双因素认证），是一种安全机制，要求用户在登录时提供**两种或以上**不同类型的认证因素：
| 因素类型 | 是什么 | 例子 |
| :--- | :--- | :--- |
| **知识因素**（你知道什么） | 只有用户知道的信息 | 密码、PIN 码 |
| **持有因素**（你有什么） | 用户拥有的物理设备 | 手机、硬件密钥 |
| **生物因素**（你是什么） | 用户的生物特征 | 指纹、面部识别 |
| 因素类型 | 是什么 | 例子 |
| :------------------------- | :----------------- | :------------- |
| **知识因素**（你知道什么） | 只有用户知道的信息 | 密码、PIN 码 |
| **持有因素**（你有什么） | 用户拥有的物理设备 | 手机、硬件密钥 |
| **生物因素**（你是什么） | 用户的生物特征 | 指纹、面部识别 |
### 5.2 为什么 MFA 这么重要？
**真实数据告诉你答案**：
| 攻击方式 | 没有 MFA 时的成功率 | 有 MFA 时的成功率 |
| :--- | :--- | :--- |
| 密码猜测/暴力破解 | 很高 | 极低（还需要第二因素） |
| 钓鱼攻击获取密码 | 很高 | 极低（钓鱼页面无法获取 MFA 码） |
| 密码泄露（其他网站泄露）| 很高 | 极低（不知道第二因素） |
| 攻击方式 | 没有 MFA 时的成功率 | 有 MFA 时的成功率 |
| :----------------------- | :------------------ | :------------------------------ |
| 密码猜测/暴力破解 | 很高 | 极低（还需要第二因素） |
| 钓鱼攻击获取密码 | 很高 | 极低（钓鱼页面无法获取 MFA 码） |
| 密码泄露（其他网站泄露） | 很高 | 极低（不知道第二因素） |
**微软安全报告（2020）**：启用 MFA 可以阻止 **99.9%** 的自动化攻击。
@@ -441,14 +438,14 @@ MFA（Multi-Factor Authentication，多因素认证），也叫 2FA（Two-Factor
随着业务增长，很多公司会使用**多账号架构**来隔离不同环境：
| 账号类型 | 用途 | 权限要求 |
| :--- | :--- | :--- |
| **Master Account** | 组织管理、账单结算 | 几乎不使用 |
| **Security Audit** | 集中收集所有账号的日志 | 只读访问其他账号 |
| **Shared Services** | 共享资源（镜像仓库等） | 其他账号只读访问 |
| **Development** | 开发环境 | 开发者完全权限 |
| **Staging** | 测试/预发布环境 | 测试人员权限 |
| **Production** | 生产环境 | 严格限制，需要审批 |
| 账号类型 | 用途 | 权限要求 |
| :------------------ | :--------------------- | :----------------- |
| **Master Account** | 组织管理、账单结算 | 几乎不使用 |
| **Security Audit** | 集中收集所有账号的日志 | 只读访问其他账号 |
| **Shared Services** | 共享资源（镜像仓库等） | 其他账号只读访问 |
| **Development** | 开发环境 | 开发者完全权限 |
| **Staging** | 测试/预发布环境 | 测试人员权限 |
| **Production** | 生产环境 | 严格限制，需要审批 |
**问题：Shared Services 账号里的镜像，怎么让 Production 账号的 EC2 拉取？**
@@ -498,6 +495,7 @@ MFA（Multi-Factor Authentication，多因素认证），也叫 2FA（Two-Factor
**步骤二：获取 Role ARN**
创建完成后，复制 Role 的 ARN：
```
arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole
```
@@ -691,38 +689,38 @@ aws ecr describe-repositories --registry-id SHARED_SERVICES_ACCOUNT_ID
### 8.1 十大 IAM 反模式
| # | 反模式 | 为什么不好 | 正确做法 |
| :--- | :--- | :--- | :--- |
| 1 | 使用根账号进行日常操作 | 根账号拥有所有权限，一旦泄露无法限制损害 | 创建 IAM 管理员账号，根账号仅在必要时使用 |
| 2 | 给所有人 AdministratorAccess | 违反最小权限原则，增加误操作和内部威胁风险 | 按角色分组，只授予必要的权限 |
| 3 | 在代码中硬编码 AK/SK | AK/SK 容易通过 GitHub 泄露，且难以轮换 | 使用 IAM Role、环境变量或密钥管理服务 |
| 4 | 长期不轮换 AK/SK | 增加凭证泄露后的风险敞口时间 | 设置 90 天轮换策略，或更好的——使用临时凭证 |
| 5 | 忽略 MFA | 密码泄露后账号直接沦陷 | 为所有 IAM 用户启用 MFA，尤其是高权限用户 |
| 6 | 不使用 CloudTrail | 无法审计谁做了什么操作，出事后无法溯源 | 启用 CloudTrail，并将日志存储到独立的审计账号 |
| 7 | IAM Policy 过于宽松 | 如 `Resource: "*"`、`Action: "*"`，增加攻击面 | 明确指定资源 ARN 和具体 Action |
| 8 | 不清理离职员工的 IAM User | 僵尸账号可能成为后门 | 建立离职流程，立即禁用并删除 IAM User |
| 9 | 不使用 IAM Access Analyzer | 无法发现过度宽松的资源策略（如公开 S3 bucket） | 启用 IAM Access Analyzer，定期检查外部访问 |
| 10 | 不在测试环境验证 Policy | 直接在生产环境应用 Policy，可能导致服务中断 | 使用 IAM Policy Simulator 测试，先在测试环境验证 |
| # | 反模式 | 为什么不好 | 正确做法 |
| :-- | :--------------------------- | :--------------------------------------------- | :----------------------------------------------- |
| 1 | 使用根账号进行日常操作 | 根账号拥有所有权限，一旦泄露无法限制损害 | 创建 IAM 管理员账号，根账号仅在必要时使用 |
| 2 | 给所有人 AdministratorAccess | 违反最小权限原则，增加误操作和内部威胁风险 | 按角色分组，只授予必要的权限 |
| 3 | 在代码中硬编码 AK/SK | AK/SK 容易通过 GitHub 泄露，且难以轮换 | 使用 IAM Role、环境变量或密钥管理服务 |
| 4 | 长期不轮换 AK/SK | 增加凭证泄露后的风险敞口时间 | 设置 90 天轮换策略，或更好的——使用临时凭证 |
| 5 | 忽略 MFA | 密码泄露后账号直接沦陷 | 为所有 IAM 用户启用 MFA，尤其是高权限用户 |
| 6 | 不使用 CloudTrail | 无法审计谁做了什么操作，出事后无法溯源 | 启用 CloudTrail，并将日志存储到独立的审计账号 |
| 7 | IAM Policy 过于宽松 | 如 `Resource: "*"`、`Action: "*"`，增加攻击面 | 明确指定资源 ARN 和具体 Action |
| 8 | 不清理离职员工的 IAM User | 僵尸账号可能成为后门 | 建立离职流程，立即禁用并删除 IAM User |
| 9 | 不使用 IAM Access Analyzer | 无法发现过度宽松的资源策略（如公开 S3 bucket） | 启用 IAM Access Analyzer，定期检查外部访问 |
| 10 | 不在测试环境验证 Policy | 直接在生产环境应用 Policy，可能导致服务中断 | 使用 IAM Policy Simulator 测试，先在测试环境验证 |
---
## 9. 名词对照表
| 英文术语 | 中文对照 | 解释 |
| :--- | :--- | :--- |
| **IAM (Identity and Access Management)** | 身份与访问管理 | 云服务中管理用户身份和访问权限的服务 |
| **RAM (Resource Access Management)** | 资源访问管理 | 阿里云的 IAM 服务名称 |
| **Root Account** | 根账号 | 注册云账号时创建的拥有者账号，拥有最高权限 |
| **IAM User** | IAM 用户/子账号 | 由根账号创建的子身份，用于日常操作 |
| **IAM Role** | IAM 角色 | 临时性权限载体，无长期凭证，需要被"扮演" |
| **IAM Policy** | IAM 策略 | JSON 格式的权限规则定义 |
| **ARN** | 亚马逊资源名称 | 全局唯一的资源标识符 |
| **AK/SK** | 访问密钥/密钥 | 程序访问云 API 的凭证 |
| **STS** | 安全令牌服务 | 提供临时安全凭证的服务 |
| **MFA** | 多因素认证 | 需要两个或以上因素的认证方式 |
| **SSO** | 单点登录 | 用户一次登录即可访问多个系统的认证方式 |
| **ExternalId** | 外部 ID | 用于防止困惑代理攻击的安全标识符 |
| **CloudTrail** | 云审计服务 | 记录云账号中所有 API 调用和操作的日志服务 |
| 英文术语 | 中文对照 | 解释 |
| :--------------------------------------- | :-------------- | :----------------------------------------- |
| **IAM (Identity and Access Management)** | 身份与访问管理 | 云服务中管理用户身份和访问权限的服务 |
| **RAM (Resource Access Management)** | 资源访问管理 | 阿里云的 IAM 服务名称 |
| **Root Account** | 根账号 | 注册云账号时创建的拥有者账号，拥有最高权限 |
| **IAM User** | IAM 用户/子账号 | 由根账号创建的子身份，用于日常操作 |
| **IAM Role** | IAM 角色 | 临时性权限载体，无长期凭证，需要被"扮演" |
| **IAM Policy** | IAM 策略 | JSON 格式的权限规则定义 |
| **ARN** | 亚马逊资源名称 | 全局唯一的资源标识符 |
| **AK/SK** | 访问密钥/密钥 | 程序访问云 API 的凭证 |
| **STS** | 安全令牌服务 | 提供临时安全凭证的服务 |
| **MFA** | 多因素认证 | 需要两个或以上因素的认证方式 |
| **SSO** | 单点登录 | 用户一次登录即可访问多个系统的认证方式 |
| **ExternalId** | 外部 ID | 用于防止困惑代理攻击的安全标识符 |
| **CloudTrail** | 云审计服务 | 记录云账号中所有 API 调用和操作的日志服务 |
---
@@ -756,6 +754,7 @@ aws ecr describe-repositories --registry-id SHARED_SERVICES_ACCOUNT_ID
---
> **延伸阅读**：
>
> - [AWS IAM 官方文档](https://docs.aws.amazon.com/iam/)
> - [阿里云 RAM 官方文档](https://www.aliyun.com/product/ram)
> - [AWS IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)