Tagging 規範：查帳與清資源的依據

Tag 是貼在每個資源上的結構化標籤，承擔「讓資源能被機器查詢與分群」的責任。沒有 tag 的資源在 console 裡只剩一個隨機後綴的名字，人能勉強認得幾個，但一旦數量過百，任何「列出所有 staging 的資源」「算出 team-a 這個月花多少」的問題都無法用查詢回答，只能逐筆翻。Tag 把這些問題從人工考古變成一行 filter。

最小 tag 集合

值得從第一天就強制的最小 tag 集合是三個維度，各自回答一個治理問題：

env 是清資源時的安全護欄。回收動作最大的恐懼是誤刪生產資源。當每個資源都標了 env，「列出所有 env=dev 且 30 天無流量的資源」就是一條可以放心執行的清理查詢，而 env=prod 的資源自動被排除在批次刪除之外。沒有這個 tag，任何自動化清理都因為怕誤傷而不敢落地，最後退回人工逐筆確認，於是根本沒人去清。

owner 解決資源孤兒化。服務出狀況、或是看到一個用途不明的資源時，第一個問題是「這誰的」。標了 owner，告警可以自動路由、清理前可以自動通知認領；沒標，這個資源就停在「沒人敢動、因為不知道砍了會不會弄壞什麼」的狀態，永久占用配額與費用。團隊命名比個人名好 — 人會離職，團隊邊界相對穩定。

cost-center 是成本歸屬的地基，把帳單從「一筆公共支出」拆成「每個團隊各自負責的花費」。這個維度的後續應用在成本可見性與最小可行治理節奏展開。

附加 tag 的合理時機

三個必填之外，隨著團隊規模增長，幾個常見的附加維度會自然浮現：

managed-by = terraform 搭配 env，可以快速找出「不在 IaC 管理下的生產資源」 — 這些就是 Console 唯讀紀律（模組一）鬆動的痕跡。附加 tag 不需要一次規劃完，但一旦加入就要跟必填 tag 一起走自動護欄。

用 IaC 自動標記

Tag 必須在資源建立時就由 IaC 寫進去，而不是事後補。Terraform 的 default_tags 讓一個 provider 區塊內的所有資源自動繼承一組 tag，避免逐個資源手動標、也避免漏標：

 1provider "aws" {
 2  region = "ap-northeast-1"
 3
 4  default_tags {
 5    tags = {
 6      env         = var.env
 7      owner       = var.team
 8      cost-center = var.cost_center
 9      managed-by  = "terraform"
10    }
11  }
12}

用 var 取代寫死的值，讓同一套 provider 設定跨環境複用 — 每個環境的 terraform.tfvars 填入自己的值。這和模組四：環境分離與模組化的參數化設計一致。

個別資源若需要額外 tag（例如 ttl），在資源自身的 tags block 裡寫，它會跟 default_tags 合併，不需要重複寫環境層的三個必填。兩者有相同 key 時資源層優先，所以某個特殊資源要覆蓋 owner 也行。

事後補 tag 是個會無限拖延的工作，因為它不影響任何功能、沒有 deadline、永遠排在 backlog 最後。

Tag 合規護欄

判讀訊號很簡單：定期跑一條「列出缺少必填 tag 的資源」的查詢，數字若持續成長，代表有人繞過 IaC 手動開資源 — 這既是 tag 問題，也是模組一「Console 唯讀」紀律鬆動的徵兆。

1# 列出沒有 env tag 的 EC2 instance
2aws resourcegroupstaggingapi get-resources \
3  --resource-type-filters ec2:instance \
4  --tag-filters Key=env,Values= \
5  --query 'ResourceTagMappingList[].ResourceARN'

手動查詢只是起點。更可靠的做法是用策略引擎在建立期或 PR 階段就擋住不合規的資源：

• AWS Tag Policy（Organizations 層級）：定義必填 tag 與允許值的枚舉，不符合就阻止建立。適合整個組織統一推行。
• OPA / Sentinel（CI / PR 層級）：在 terraform plan 之後、apply 之前檢查 plan 輸出，缺 tag 就讓 CI fail。適合跟模組七：infra 走 PR 流程整合。
• checkov / tfsec 自訂規則：靜態掃描 HCL，在 code push 時就擋。成本最低但只擋得住 IaC 管理的資源。

三層護欄互補：靜態掃描擋寫 code 時的遺漏、plan 檢查擋執行前的偏差、tag policy 擋繞過 IaC 的手動操作。早期只做一層也有價值，三層都做時覆蓋最完整。定期跑 tag 覆蓋率報告（缺少必填 tag 的資源數 / 總資源數）可以作為治理進度的量化指標。覆蓋率從 40% 到 90% 的趨勢比單次數字更有意義，適合放進月報讓管理層追蹤。

Tagging 在合規驅動的基礎設施中還有另一層用途：用 tag 標記資料的地理歸屬，讓合規查詢可以機器化。Hard Rock Digital 的運動博彩平台受美國 Wire Act 約束，不同州的投注資料必須留在州內。它們用 CockroachDB 跨 AWS Outposts 部署，每個 Outpost 的資源用地理 tag 標記歸屬州，合規稽核時用 tag 過濾而非逐台盤查。這個案例的 infra 教訓是：tag 的維度設計在受地理或法規約束的服務中，要提前納入合規需求的維度，而非只做成本和歸屬。詳見 9.C41 Hard Rock Digital：Wire Act 合規。

Secrets 不進 code：機密值的儲存與引用

機密值 — 資料庫密碼、第三方 API key、簽章用的私鑰 — 要存在專用的密鑰管理服務裡，而 code 與 IaC 只持有指向它的參照，不持有值本身。這條規則承擔的責任是把「機密外洩的爆炸半徑」與「程式碼的散布範圍」脫鉤：一旦密碼寫進 repo，它就跟著每一次 clone、每一份 CI 快取、每一個 fork 擴散，輪替時無法保證所有副本都更新，git 歷史更是會把它永久留存，即使後來刪掉那一行。

密鑰管理服務的選型

密鑰管理服務提供的是一個有存取控制、有審計紀錄、可輪替的集中儲存。值放在這裡，誰讀過、什麼時候讀的都有 log，輪替時只改一個地方，所有引用方下次讀取就拿到新值。

選型看的是團隊已有的生態與輪替需求。對已在 AWS 上的團隊，Secrets Manager 適合需要自動輪替的資料庫密碼，SSM Parameter Store 適合其餘設定值（免費額度通常夠用）。跨雲或對動態 secret 有需求的團隊會走 Vault。

IaC 怎麼引用 secret

IaC 應該存的是密鑰的 ARN（或等價的資源識別碼）與「在執行期去讀它」的指令，而不是密鑰的明文：

1data "aws_secretsmanager_secret_version" "db" {
2  secret_id = "prod/payments/db-password"
3}
4
5resource "aws_db_instance" "payments" {
6  password = data.aws_secretsmanager_secret_version.db.secret_string
7  # ...
8}

另一種做法是讓 IaC 只建立 secret 的「容器」（空的 Secrets Manager entry），值由人工或自動化流程在 IaC 之外寫入。這樣 state 裡只有 secret 的 metadata（ARN、名稱、版本 ID），完全不碰明文。適合密碼由安全團隊管理、IaC 只負責「確保 secret 存在且有正確的存取策略」的分工模式。

1resource "aws_secretsmanager_secret" "db" {
2  name = "${var.env}/payments/db-password"
3}
4
5# 值不由 Terraform 管理 — 在 Console 或 CLI 手動設定
6# secret version 生命週期在 IaC 之外

state 裡的機密邊界

Terraform 即使從 Secrets Manager 讀值，那個值仍然會以明文落進 state 檔。這是一個常被忽略的邊界。「不進 code」只是第一道，state 後端的加密與存取控制（模組一的 state 地基）是同等重要的第二道 — 否則密鑰只是從 repo 搬到了一個沒鎖好的 state bucket。

State 的保護措施是一道複合防線：

• S3 bucket 開 encrypt = true（AES-256 或 KMS）
• Bucket 的 IAM policy 只允許跑 apply 的 role 讀寫
• Bucket 開 versioning，誤寫或損壞時可以回捲
• DynamoDB lock table 防止並行 apply 覆蓋

這些措施在模組一的 remote state backend 段已經詳述，這裡提醒的是：state 的安全程度決定了 secret 引用策略的上限。state 沒鎖好時，把 secret 值拉進 state 的做法等於把密碼從 repo 搬到了另一個不設防的地方。

Secret 掃描

判讀訊號：定期用 secret 掃描工具掃 repo 與 CI log，任何命中都當成需要輪替的外洩事件處理，而不是刪掉那行就算了 — 因為 git 歷史與既有 clone 已經保不住了。

1# gitleaks：掃描整個 git 歷史
2gitleaks detect --source . --report-format json --report-path gitleaks-report.json
3
4# trufflehog：掃描 git、filesystem、CI
5trufflehog git file://. --json

兩個工具覆蓋面不同（gitleaks 用 regex pattern、trufflehog 用 detector + entropy），搭配用覆蓋更完整。放進 CI pipeline 讓每個 PR 自動掃，比人工定期跑更可靠。命中後的處理流程：先輪替被洩露的 secret，再從 repo 清除（git filter-repo），最後通知所有可能受影響的服務。

Secret 命名規範

機密的命名也值得約定。用 {env}/{service}/{purpose} 這類有結構的路徑（如 prod/payments/db-password），讓存取策略可以用前綴授權：

1# 給 payments service 的 role 只能讀自己的 secret
2data "aws_iam_policy_document" "payments_secrets" {
3  statement {
4    actions   = ["secretsmanager:GetSecretValue"]
5    resources = ["arn:aws:secretsmanager:*:*:secret:${var.env}/payments/*"]
6  }
7}

前綴授權的好處是新增 secret 時不需要改 IAM policy — 只要命名落在同一個前綴下，存取權限自動繼承。跟模組二的最小權限設計一致：service A 的 role 只看得到 payments/*，看不到 auth/*，即使它們存在同一個帳號的 Secrets Manager 裡。

跨分類引用

• → 模組一：最小可行 IaC：state 後端的加密與存取控制是 secret 引用策略的安全地基
• → 模組二：身分與憑證地基：誰能讀哪些 secret 的 IAM 權限設計
• → 模組四：環境分離與模組化：tag 的環境值與 module 參數化的對齊
• → 模組七：infra 走 PR 流程：tag 合規與 secret 掃描整合進 CI pipeline
• → backend 模組七：資安與資料保護：密鑰生命週期、輪替策略與資料保護的完整討論

先界定邊界。成本這一塊分兩層：把資源歸屬到擁有者與用途的地基（tagging、chargeback 的依據）在這裡，運行期怎麼用 reserved instance、spot、rightsizing 去壓低帳單，是 devops 模組八：成本管理 的範圍。

成本可見性：每筆花費都對得到擁有者與用途

成本可見性的目標是讓帳單上的每一筆花費都能回答「這是誰的、為了什麼」。雲帳單預設是一筆按服務類型加總的數字 — EC2 多少、RDS 多少 — 這個視角能告訴你花在哪類資源，卻答不出花在哪個團隊、哪個產品線、哪個功能。當這個問題答不出來，成本就變成一筆沒人負責的公共支出，沒有人有動機去優化自己看不到的帳。

Tag 驅動的成本分攤

把成本拆解到擁有者的地基，正是 tagging。雲廠商的成本分攤工具（AWS Cost Explorer、Cost Allocation Tags、GCP 的 billing label）能用 tag 當分群維度，前提是那些 tag 要先在 billing 後台啟用為「成本分攤標籤（Cost Allocation Tag）」。啟用是一次性設定，之後新建的資源只要帶了這個 tag，費用就會自動歸入對應維度。

啟用後，cost-center 和 owner 就從單純的標籤升級成帳單的可查詢維度：

1# 用 AWS CLI 查某個 cost-center 的月費用
2aws ce get-cost-and-usage \
3  --time-period Start=2026-06-01,End=2026-06-30 \
4  --granularity MONTHLY \
5  --filter '{"Tags":{"Key":"cost-center","Values":["cc-1024"]}}' \
6  --metrics BlendedCost \
7  --group-by Type=TAG,Key=owner

「team-payments 這個月花多少」「staging 環境占總成本幾成」變成一張報表而不是一場會議。

成本異常告警

可見性先於優化，這個順序不能反。看不見的成本無法被歸屬，無法歸屬就無法問責，沒有問責就沒有人去做優化。在可見性建立之後，下一步是設一條成本異常告警：

 1resource "aws_ce_anomaly_monitor" "cost" {
 2  name              = "daily-cost-anomaly"
 3  monitor_type      = "DIMENSIONAL"
 4  monitor_dimension = "SERVICE"
 5}
 6
 7resource "aws_ce_anomaly_subscription" "alert" {
 8  name      = "cost-anomaly-alert"
 9  frequency = "DAILY"
10
11  monitor_arn_list = [aws_ce_anomaly_monitor.cost.arn]
12
13  subscriber {
14    type    = "SNS"
15    address = aws_sns_topic.cost_alerts.arn
16  }
17
18  threshold_expression {
19    dimension {
20      key           = "ANOMALY_TOTAL_IMPACT_ABSOLUTE"
21      values        = ["100"]
22      match_options = ["GREATER_THAN_OR_EQUAL"]
23    }
24  }
25}

當告警觸發時，因為有 tag，可以立刻定位是哪個團隊的哪類資源在漲，而不是面對一個無法拆解到具體團隊或資源類型的總數。常見的成本異常來源：開發者開了一組大型 instance 測試後忘了關、某個 auto-scaling group 的最大值設太高在流量尖峰長出了大量機器、NAT Gateway 被大量出站流量灌到帳單翻倍。這些情境只要 tag 到位，都能在異常告警觸發後幾分鐘內找到根因。

到了「知道誰花多少、接下來怎麼省」這一步 — reserved instance 的承諾折扣、spot 的可中斷算力、閒置資源的 rightsizing 與排程關機 — 就進入 devops 模組八：成本管理 的運行期優化範圍。這一章負責的是讓那些優化「有帳可查、有人可問」。

成本治理在不同規模下的操作形態差異很大。Netflix 把多套關聯式資料庫統一到 Aurora 後成本下降 28%，核心操作是「把資源種類收斂、讓成本歸因的維度減少」——這在 tagging 已經到位的前提下才做得到，見 9.C23 Netflix：Aurora 整併。另一個極端是 Arcjet 用 Redis Streams 取代 managed Kafka，年費從六位數美金降到約 $1k，代價是自行維護 retention 與 consumer group 監控——這個取捨的前提是團隊有能力承擔額外的運維面，見 3.C43 Arcjet：Redis Streams 取代 Kafka。

最小可行節奏：先把地基跑起來，再逐步加

治理的最小可行節奏，是早期只立「拔掉就會痛、補起來很貴」的那幾條規範，其餘留到規模逼出需求時再加。治理機制本身有維護成本 — 每一條策略規則、每一個審批關卡、每一套標籤分類法都要有人維護、有人解釋、有人在它擋錯東西時來救。在團隊還小、資源還少時堆滿企業級治理框架，付出的是當下的速度，換來的是一套還用不到的複雜度。

補救成本曲線

判斷一條治理規範該不該現在就立，看它的「補救成本曲線」— 越晚導入、事後補救的代價越高的規範，越應該提前立：

這個曲線給出的節奏是：補救成本陡的從第一天就用 IaC 強制，補救成本平的等到痛點確實出現 — 開始有人手滑誤刪、開始有跨團隊的權限爭議 — 再有針對性地加。那時你也才知道該往哪個方向加。

過度治理的訊號

過度治理跟過度設計是同一類問題，訊號很類似：

• 建一個測試用的小資源需要走三層審批流程
• 團隊花在解釋為什麼某個護欄擋錯的時間，比護欄實際擋住的風險還多
• 策略規則的 exception 清單比規則本身還長
• 新人第一週的大部分時間花在理解治理框架而非理解業務

這些訊號出現時，該回頭簡化 — 砍掉沒帶來價值的規則、把誤判率高的規則降級為 warning 而非 blocking。治理框架跟程式碼一樣需要重構。

和其他模組的節奏對齊

這個節奏跟模組零的成熟度階梯是同一套思路：基礎設施的治理跟基礎設施本身一樣，是逐級長出來的，不是一次到位設計完的。把規範變成自動護欄的工程（PR 階段擋缺 tag、CI 掃 secret）值得早投入，因為自動化的護欄維護成本低、且越早接管越省人力 — 這部分怎麼落地在模組七：infra 走 PR 流程 展開。

跨分類引用

• → 模組零：infra 是什麼：成熟度階梯的務實節奏思路
• → 模組七：infra 走 PR 流程：tag 合規與 secret 掃描整合進 CI pipeline
• → devops 模組八：成本管理：運行期的成本控制與優化手段

離職或轉調的存取撤銷清單

存取撤銷的目標是在人員離開的同一天（最晚 24 小時內）關閉所有該身分能存取雲端資源的路徑。撤銷的順序按影響範圍從大到小排：先關能連鎖失效的上游入口，再逐一清理下游殘留。

第一步：停用 SSO / IdP 帳號

如果雲端存取統一走 SSO（如 AWS IAM Identity Center、Okta、Google Workspace），停用 IdP 帳號會連鎖撤銷所有透過 SSO 取得的雲端權限 — 這是單一操作影響最大的一步。停用後，該人無法再透過 SSO 登入任何已接 SSO 的 AWS 帳號、CI 平台或內部工具。

這一步能覆蓋多少取決於 SSO 的覆蓋率。如果某些雲端帳號還沒接 SSO（用獨立 IAM user 登入），停用 IdP 帳號不會影響那些路徑，需要額外處理。

第二步：處理長期 access key

從 credential report 找出該人名下的所有長期 access key：

1aws iam generate-credential-report
2aws iam get-credential-report --output text --query Content | base64 -d \
3  | grep "departed-user"

每把 key 判斷處理方式：

deactivate 而非直接刪除是因為刪除不可逆 — 如果某個沒記錄在案的自動化正在用這把 key，deactivate 會讓它報權限錯誤，CloudTrail 會記錄失敗的 API 呼叫，方便追蹤；直接刪除後這把 key 的 ID 就消失了，追蹤更困難。

第三步：刪除個人 IAM user

確認沒有自動化依賴這個 user 後刪除。刪除前先檢查該 user 是否有 inline policy 或 group membership 被其他流程引用：

1aws iam list-user-policies --user-name departed-user
2aws iam list-groups-for-user --user-name departed-user
3aws iam list-attached-user-policies --user-name departed-user

第四步：第三方服務帳號

雲端以外的存取路徑同樣需要撤銷：

• 版本控制（GitHub / GitLab）：移除組織 membership 或降為 read-only
• CI 平台（GitHub Actions secrets、GitLab CI variables）：如果該人曾設定過 CI secret，確認那些 secret 是否需要輪替
• 監控與告警（Grafana、PagerDuty、Datadog）：移除帳號或降權
• 基礎設施管理平台（Terraform Cloud、Spacelift）：移除 team membership

第五步：MFA 裝置解除註冊

如果該人的 MFA 裝置仍然綁在帳號上（例如 root account 的 MFA），需要管理員介入解除並重新綁定。root account 的 MFA 裝置異動屬於高敏感操作，需要有第二人確認。

時程與回報

這份回報不是形式 — 它是對管理層證明「離職者已無法存取任何系統」的書面紀錄，合規稽核時會被要求出示。

離職時的 credential rotation

存取撤銷處理的是「這個人自己的 key 和帳號」。如果離職者曾有 admin 級別的存取權，還需要處理他可能接觸過的共用 secret。

rotation 的範圍取決於該人的權限等級：

admin 級別離職時的 CloudTrail 審計：

1aws cloudtrail lookup-events \
2  --lookup-attributes AttributeKey=Username,AttributeValue=departed-user \
3  --start-time $(date -v-30d +%Y-%m-%dT%H:%M:%SZ) \
4  --max-items 100 \
5  --query 'Events[].[EventTime,EventName,Resources[0].ResourceName]' \
6  --output table

審計的目的是確認離職前 30 天內有沒有異常操作（大量資料下載、權限變更、新 key 建立），而非預設離職者有惡意。這是標準的安全衛生程序。

如果團隊已經全面採用 OIDC 短期憑證（見模組二：身分與憑證地基），離職時的 credential rotation 範圍會大幅縮小 — 沒有長期 key 就沒有需要輪替的靜態憑證，SSO 停用後短期 token 自然失效。

IaC 與 PR 歷史怎麼降低交接成本

存取撤銷是離職當天的緊急操作。交接成本的高低則取決於新接手的人能多快理解環境的結構與歷史。

環境結構寫在 IaC 裡時，新人讀 repo 就能回答「我們有幾個 VPC、subnet 怎麼切、哪些服務在哪個 private subnet」。PR 歷史回答「為什麼 NAT 從共享改成 per-AZ」（因為上個月 ap-northeast-1a 故障時全部出站斷了）。這些資訊不依賴任何個人的記憶，新人第一天就能取得。

程式碼和 PR 歷史能涵蓋的是環境的結構與變更理由。以下資訊不在程式碼裡，需要額外文件或交接：

• 營運脈絡：哪些服務是流量敏感的、哪個時段不能做變更、哪些客戶有特殊 SLA
• 事故歷史：過去發生過什麼事故、當時怎麼處理的、有沒有遺留的 workaround
• vendor 關係：support contract 的聯絡方式、升級路徑、合約到期時間
• 進行中的工作：正在做的遷移、已知但未處理的技術債、已規劃但未執行的變更

時程參考：環境完全在 IaC 裡的團隊，infra 角色交接通常 1-2 天能讓新人開始獨立操作（讀 code + 第一次 PR）。沒有 IaC 的環境，交接需要 1-2 週的口頭傳授加上新人自行摸索。

最小交接清單

任何 infra 角色變更（不只是離職，包括長假、轉組、新人 onboarding）都應該走過一次這份清單：

帳號與存取盤點

• 所有雲端帳號的列表（帳號 ID、用途、環境對應）
• CI/CD 平台的組織與 repo 存取
• 監控與告警平台的帳號
• DNS 管理（域名註冊商、Route 53 hosted zone）
• SSL 憑證管理（ACM、Let’s Encrypt）

憑證盤點

• 長期 access key 清單（從 credential report 取得）
• Secrets Manager / SSM Parameter Store 裡的 secret 清單
• 第三方服務的 API key（付費服務、SaaS 整合）

聯絡與升級路徑

• 雲端 vendor 的 support 聯絡方式與 support plan 等級
• 資安事件的通報對象與流程
• on-call chain 與升級規則

進行中的工作

• 正在執行的遷移或重構（目前到哪一步、下一步是什麼）
• 已知的技術債與風險（哪些資源還沒納管、哪些 key 該輪替但還沒輪替）
• 已排程但未開始的變更

這份清單的維護成本很低 — 多數項目在日常工作中已經存在（credential report、repo 結構、ticket board），交接時只需要把散落的資訊收斂到一份文件。如果每次交接都要花時間「找資訊在哪裡」，代表日常的資訊組織有改善空間。

讓交接成本結構性降低的設計

上面的清單處理的是每次交接的操作成本。以下設計原則處理的是讓這個成本隨時間趨近固定值、而非隨環境複雜度增長：

SSO 作為單一存取撤銷點：所有雲端存取走 SSO，離職時停用一個帳號就關閉所有路徑。沒有 SSO 時，每多一個平台就多一個需要手動撤銷的路徑，漏撤任何一個都是安全缺口。SSO 的覆蓋率越高，撤銷操作越接近 O(1)。

消除個人長期 key：用 OIDC + role assumption 取代長期 access key（見模組二：身分與憑證地基）。沒有長期 key，離職時就沒有需要逐一追蹤和輪替的靜態憑證。credential rotation 的範圍從「所有 key」縮小到「共用 secret」。

環境描述在程式碼裡：IaC 讓環境結構對任何有 repo 存取的人可讀。交接的知識成本從「口頭傳授整個環境長什麼樣」降到「讀 code + PR 歷史」。見模組七：infra 走 PR 流程。

PR 描述記錄「為什麼」：程式碼記錄「什麼」，PR 描述記錄「為什麼」。三個月後翻 git log，看到「把 NAT 從共享改成 per-AZ」知道改了什麼；看到 PR 描述裡的「因為上週 ap-northeast-1a 故障時全部出站斷了」才知道為什麼。這段脈絡在交接時的價值最高 — 新人最常問的問題就是「為什麼這樣設定」。

on-call 輪替分散操作知識：讓不同人輪流負責 infra 的 review、apply 和事故處理，用操作經驗分散知識。判斷知識是否過度集中的方式：如果團隊裡只有一個人敢對 production 做 apply，那個人就是交接的瓶頸。見模組九：怎麼把 infra 推動起來。

這些設計的共同效果是讓交接的固定成本保持在「停用帳號 + 移交 repo 權限 + 走一次交接清單」，不隨環境複雜度或人員流動頻率等比增長。

跨分類引用

• → 模組二：身分與憑證地基：IAM 設計、OIDC 短期憑證、權限邊界
• → 模組七：infra 走 PR 流程：PR 作為知識載體、變更可追溯
• → 模組九：怎麼把 infra 推動起來：知識共享與 on-call 輪替
• → backend 模組七：資安與資料保護：Secret 輪替策略