常見的斷網情境：政府或軍事機密網路（實體隔離）、工控與 OT 環境（工廠、電廠、SCADA）、金融交易系統的高安全隔離區、醫療設備網路、以及地端機房裡刻意不開 internet access 的 private zone。

這個模組是橫切約束——它影響模組一（IaC 選型）到模組七（PR 流程）的每一個操作步驟。每篇文章處理一個被斷網影響的主要面向。

章節文章

跟其他模組的關係

• → 模組一：最小可行 IaC：斷網時 IaC 工具選型和 state backend 的替代做法
• → 模組五：核心服務上 IaC：容器映像和套件依賴的離線管理
• → 模組六：可觀測性：斷網環境的監控不能 phone home
• → 模組七：PR 流程：CI/CD 在內網怎麼跑
• → 接手維運：接手斷網環境的額外約束

IAM 的心智模型

IAM（Identity and Access Management）是雲端平台用來回答「某個身分能不能對某個資源做某件事」的授權系統。它把授權拆成三個獨立的零件：identity（身分，發起動作的主體）、policy（政策，描述允許或拒絕的規則）、role（角色，一組可以被臨時取得的權限集合）。理解這三者的分工，是後面所有憑證決策的前提。

identity：長期主體 vs 臨時假扮

identity 分兩類，這個區分在後面設計權限邊界時會反覆用到。一類是 user，代表一個長期存在的主體，通常對應到一個真人或一個固定的服務帳號，本身可以持有長期憑證（密碼或 access key）。另一類是 role，代表一組權限的暫時授予 — 沒有自己的長期密碼，而是讓某個被信任的身分「假扮（assume）」成它、換取一段有時效的臨時憑證。

把 identity 想成「護照」和「通行證」的差別：user 是護照，長期有效、全程攜帶；role 是通行證，到了管制區域臨時換發、離開就失效。多數安全事故源自於把通行證當護照用 — 某個 role 被長期假扮且從未被撤回，或某個 user 持有永不輪替的 access key。

policy：描述「允許對什麼做什麼」

policy 是貼在 user 或 role 上的規則文件，列出 Action（能做什麼，如 s3:GetObject）、Resource（對哪個資源，如特定 bucket 的 ARN）、Effect（Allow 或 Deny）。一條 policy 可以包含多個 statement，每條 statement 描述一組操作許可。

1# 最小權限範例：CI 只能讀寫特定 bucket，不給整個 S3
2data "aws_iam_policy_document" "ci_artifacts" {
3  statement {
4    effect    = "Allow"
5    actions   = ["s3:GetObject", "s3:PutObject"]
6    resources = ["arn:aws:s3:::myapp-artifacts/*"]
7  }
8}

這段 policy 只允許對 myapp-artifacts 這一個 bucket 做讀寫。如果寫成 resources = ["*"]，同一把身分被攻破時，攻擊者就能讀寫帳號內所有 bucket — 差別不在語法，在 Resource 欄位收到多緊。

role：臨時身分的載體

role 本身不持有長期密碼。它靠 trust policy（信任政策）定義「誰能假扮我」，靠 permissions policy 定義「假扮後能做什麼」。trust policy 和 permissions policy 是兩份獨立的文件，分別回答「誰進得來」與「進來後能做什麼」。

 1# trust policy：只允許 ECS 服務假扮此 role
 2data "aws_iam_policy_document" "ecs_trust" {
 3  statement {
 4    actions = ["sts:AssumeRole"]
 5    principals {
 6      type        = "Service"
 7      identifiers = ["ecs-tasks.amazonaws.com"]
 8    }
 9  }
10}
11
12resource "aws_iam_role" "api_task" {
13  name               = "api-task-prod"
14  assume_role_policy = data.aws_iam_policy_document.ecs_trust.json
15}

trust policy 裡的 principals 決定能進門的身分。上面這段把進門權限限給 ECS 服務本身，意味著只有跑在 ECS 上的 task 才能取得這個 role 的臨時憑證 — 一個在本地筆電跑的程式呼叫 AssumeRole 會被拒絕。

最小權限：持續收斂而非一次設定

最小權限（least privilege）是貫穿整套系統的設計原則：一個身分只應該拿到完成它本職工作所需的最小權限集合。多一個 action 是多一條攻擊面，多一個 resource 是多一個爆炸半徑。

最小權限是持續收斂的過程，而非一次設定就結束的靜態狀態。服務初期常為了快速上線給寬鬆權限 — 一個新的 ECS task role 掛上 AmazonS3FullAccess 讓它能跑起來，半年後這個 role 實際只用了 s3:GetObject 和 s3:PutObject 兩個 action、針對一個 bucket，但 policy 裡寫的還是全部 S3 操作對所有 bucket。

收斂的工具是 access analyzer。AWS IAM Access Analyzer 能分析 CloudTrail 日誌，列出某個 role 在過去 N 天內實際用了哪些 action 與 resource，據此產出一份建議的最小 policy。用它的步驟是：開著寬 policy 跑一段時間 → 用 access analyzer 產出實際使用清單 → 把 policy 收斂到這份清單 → 確認服務仍正常。

 1# 產出建議 policy：分析 api-task-prod role 過去 90 天的實際用量
 2aws accessanalyzer generate-policy \
 3  --policy-generation-details '{
 4    "principalArn": "arn:aws:iam::123456789012:role/api-task-prod",
 5    "cloudTrailDetails": {
 6      "trailArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/main",
 7      "startTime": "2026-03-01T00:00:00Z",
 8      "endTime": "2026-06-01T00:00:00Z"
 9    }
10  }'

一個快速的盤點方式：列出所有掛著 AdministratorAccess、PowerUserAccess、*FullAccess 這類寬鬆 managed policy 的 role，每個命中都問一次「這個 role 確實需要這些權限嗎」。CI role 的 policy 裡出現 *:* 更是明確的收斂目標。

長期 access key 的風險

長期 access key 是一組沒有到期時間的靜態憑證（access key ID + secret），任何持有它的人或程式都能以對應身分的全部權限呼叫 API，直到有人手動撤銷為止。它最大的問題是「沒有時效」這個性質本身，會在三個方向上累積風險，而且風險隨團隊規模與時間單調上升。

散落

長期 key 為了被程式使用，會被複製進 .env 檔、CI 設定、本機 ~/.aws/credentials、Slack 訊息、甚至誤推進 git 歷史。每多一個副本就多一個外洩點。一把 key 在半年內可能被貼到六個地方 — 部署腳本、兩個 CI 平台的環境變數、某台共用跳板機的 profile、一封交接信、一位已離職同事的筆電 — 而這六個副本沒有任何中央清單能列舉。

權限過大

因為輪替麻煩，團隊傾向給一把 key 配足夠寬的權限「一次搞定」。建立時圖方便掛了 AdministratorAccess，打算「等穩定了再收斂」，但那天從來沒有到來。於是一把本來只該讀 artifact 的 key 同時握有刪除 production 資料庫的能力。

難以輪替

輪替一把長期 key 意味著找出所有副本、同步替換、確認沒有遺漏。這個成本高到讓多數團隊選擇拖延，於是 key 的有效期變成「無限」，外洩後的曝險窗口也跟著變成無限。用一個問題辨認風險：能不能在五分鐘內回答「這把 key 被用在哪些地方、上次輪替是什麼時候」？答不出來，它就已經是技術債。

常見的散落路徑：部署腳本使用的 admin key 留在 CI 環境變數，建立者離職後沒人知道這把 key 的存在與權限範圍。這類情境的風險在於外洩後沒有手段限制影響範圍 — key 的權限有多大，影響範圍就有多大。用 credential report 定期盤點帳號內所有 access key 的建立時間與使用時間，見模組負一：還沒有 infra 的環境。

長期憑證風險的實際規模可以從兩個案例看到。Snowflake 2024 事件中，攻擊者利用外洩的長期憑證登入缺少 MFA 的客戶環境，執行大量資料匯出，造成跨客戶的資料竊取與勒索（見 Snowflake 2024：憑證濫用與資料竊取）。LastPass 2022 事件則顯示備份路徑的憑證管理缺口會讓影響範圍沿信任鏈擴散——開發環境取得的資訊被用來存取雲端備份，整條路徑的金鑰隔離不足是根因（見 LastPass 2022：備份路徑與鏈式入侵）。兩個案例的共同教訓是：長期憑證的風險不止於外洩本身，而在於外洩後缺乏限制影響範圍的機制。

OIDC：給 CI/CD 的短期憑證

OIDC（OpenID Connect）聯合讓 CI/CD 平台用一段每次執行才簽發、幾分鐘後就失效的短期憑證取代長期 key，從根本上消掉「靜態密鑰散落」這個問題。它的運作方式是建立信任關係：雲端帳號信任某個外部 identity provider（如 GitHub Actions 的 OIDC issuer），當管線執行時，CI 平台簽發一個帶有可驗證 claim 的 token（描述「這是哪個 repo、哪個 branch、哪個 workflow 在跑」），雲端用這個 token 換出一段臨時憑證。沒有任何長期 secret 需要被儲存在 CI 設定裡。

trust policy 的收斂

關鍵設計在 role 的 trust policy 上 — 它規定「哪個外部身分被允許假扮成這個 role」。trust policy 要用 token 的 claim 把假扮條件收到最緊。

 1# OIDC trust policy：只允許特定 repo 的 main branch 假扮此 role
 2data "aws_iam_policy_document" "ci_trust" {
 3  statement {
 4    actions = ["sts:AssumeRoleWithWebIdentity"]
 5
 6    principals {
 7      type        = "Federated"
 8      identifiers = [aws_iam_openid_connect_provider.github.arn]
 9    }
10
11    condition {
12      test     = "StringEquals"
13      variable = "token.actions.githubusercontent.com:aud"
14      values   = ["sts.amazonaws.com"]
15    }
16
17    condition {
18      test     = "StringLike"
19      variable = "token.actions.githubusercontent.com:sub"
20      values   = ["repo:my-org/my-app:ref:refs/heads/main"]
21    }
22  }
23}

每個 condition 各守一段邊界。aud 的 StringEquals 確認 token 是發給 AWS STS 的（防止用錯 audience 的 token 闖入）。sub 的 StringLike 把假扮限定在特定 repo 的 main branch — 設成 repo:my-org/* 等於讓組織內任何 repo 的任何 branch 都能假扮這個 role，這是常見的設定陷阱。

收斂 trust policy 的判讀問法是：「如果 my-org 底下某個公開 fork 跑了一個惡意 workflow，它能不能假扮這個 role？」如果答案是能，sub 條件就太鬆了。

分離 plan 與 apply 的 role

進一步的收斂是替 plan 和 apply 分別建立 role。plan 只需要唯讀存取（讀 state、讀雲端現況），apply 需要寫入權限。把兩者分成獨立 role，讓 PR 階段的 CI 用唯讀 role 跑 plan、合併後才用寫入 role 跑 apply。任何拿到 plan role 的 token 無法修改基礎設施。

 1# plan role：只需讀取 state 與雲端現況
 2resource "aws_iam_role" "ci_plan" {
 3  name               = "infra-ci-plan"
 4  assume_role_policy = data.aws_iam_policy_document.ci_trust.json
 5}
 6
 7resource "aws_iam_role_policy_attachment" "ci_plan_read" {
 8  role       = aws_iam_role.ci_plan.name
 9  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
10}
11
12# apply role：需要寫入權限，trust policy 限定只有 main branch
13resource "aws_iam_role" "ci_apply" {
14  name               = "infra-ci-apply"
15  assume_role_policy = data.aws_iam_policy_document.ci_trust_main_only.json
16}

這一章把 role 與 trust policy 設計好，OIDC 的實際回報要到模組七：infra 走 PR 流程建管線時才兌現 — 屆時管線用這裡定義好的 role 取得短期權限執行 plan 與 apply，CI 環境裡不需要存任何 access key。

權限邊界設計

權限邊界是把不同類型的身分與不同環境之間的權限刻意隔開，讓任何一個身分被攻破時，爆炸半徑都被限制在它本職的範圍內。邊界設計有兩條軸線需要分別處理：人 vs 機器，以及環境之間。

人 vs 機器

兩者的存取模式根本不同，混在同一個身分上會同時喪失兩邊的保護。

人類身分需要互動式登入、應該強制 MFA、權限隨職責變動，且通常透過 SSO 集中管理。機器身分（CI runner、ECS task、Lambda function）需要的是程式化、無人值守的存取，應該用 role 假扮取得短期憑證，永遠不該配長期 key。

機器身分還要再依「跑在哪裡」分兩類。跑在雲上的 workload（EC2 instance、ECS task、Lambda）由平台直接把 role 綁在執行環境上 — AWS 用 instance profile 把 role 掛在 EC2、用 task role 掛在 ECS task，workload 從實例 metadata 端點自動取得輪替的短期憑證。跑在雲外的 CI/CD（GitHub Actions、GitLab CI）拿不到實例 metadata，需要前面那套 OIDC 信任關係換憑證。

一個常見陷阱是工程師用自己的個人 key 跑自動化腳本 — 這把人的廣泛權限直接送進了無人值守的執行環境，MFA 保護形同虛設（API 呼叫不需要 MFA challenge），權限範圍比任何 CI role 都大。

環境之間

環境之間的邊界，目的是讓 production 的權限與 staging、dev 完全不交叉。驗證邊界的方式是用 dev 環境的 CI role 嘗試列出或刪除 production 的資源——能做到，就代表邊界沒有建立。

帳號級護欄：SCP

Organizations 把環境拆成獨立帳號，再用 SCP（Service Control Policy）對整個帳號或組織單位設定權限天花板，連帳號內的管理員都越不過去。SCP 是 deny-based 的頂層限制 — 它不授予任何權限，只限制「即使有人給了權限也不准做」。

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyLeaveOrg",
 6      "Effect": "Deny",
 7      "Action": ["organizations:LeaveOrganization"],
 8      "Resource": "*"
 9    },
10    {
11      "Sid": "DenyDisableCloudTrail",
12      "Effect": "Deny",
13      "Action": [
14        "cloudtrail:StopLogging",
15        "cloudtrail:DeleteTrail"
16      ],
17      "Resource": "*"
18    }
19  ]
20}

這份 SCP 掛在整個組織底下的所有帳號上，確保任何帳號都不能關閉稽核日誌或退出組織 — 即使該帳號裡有人持有 AdministratorAccess。SCP 的定位是組織層的不可踰越底線。

Role 級護欄：Permissions Boundary

Permissions Boundary 是掛在單一 role 上的權限上限。它跟 SCP 的差別在粒度：SCP 管整個帳號，Permissions Boundary 管單一身分。即使有人後來給一個 role 貼了過寬的 policy，Boundary 也會擋住超出上限的部分。

 1# Permissions Boundary：CI role 最多只能操作特定服務
 2resource "aws_iam_policy" "ci_boundary" {
 3  name = "ci-boundary-prod"
 4  policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [
 7      {
 8        Effect   = "Allow"
 9        Action   = ["ecs:*", "ecr:*", "s3:*", "logs:*"]
10        Resource = "*"
11      },
12      {
13        Effect   = "Deny"
14        Action   = ["iam:*", "organizations:*", "account:*"]
15        Resource = "*"
16      }
17    ]
18  })
19}
20
21resource "aws_iam_role" "ci_apply" {
22  name                 = "infra-ci-apply"
23  assume_role_policy   = data.aws_iam_policy_document.ci_trust.json
24  permissions_boundary = aws_iam_policy.ci_boundary.arn
25}

SCP 與 Permissions Boundary 疊起來的效果是：SCP 在帳號層鎖住最危險的操作（關日誌、退組織），Boundary 在 role 層限制單一身分最多能做什麼，permissions policy 在這兩層天花板之內授予實際需要的權限。三者各管一層，缺一層就少一道屏障。

身分控制面本身的韌性在兩個案例中被檢驗。Azure AD 2021 事件中，身分服務的控制面故障導致所有依賴身份驗證的服務同時受影響，事故處理需要在身份恢復與服務降級策略之間排優先序（見 Azure AD：Identity Control-plane 事件）。Microsoft Storm-0558 事件則顯示簽章金鑰一旦失守，token 驗證的信任鏈會跨租戶失效，修復不只是修補漏洞、而是重建整條 key lifecycle 與 issuer 驗證流程（見 Microsoft：Storm-0558 簽章金鑰事件）。這兩個案例揭露的是：權限邊界只管「某個身分能做什麼」，但身分系統本身的控制面如果失效，所有建立在它之上的邊界都跟著失效。

環境隔離的更完整實作（帳號結構、模組化參數）會在模組四：環境分離與模組化展開。

身分層 vs 應用層 secret 的邊界

這一章談的是身分與憑證 — 誰是誰、怎麼證明、能動什麼。憑證背後引用的應用層 secret（資料庫密碼、第三方 API key）怎麼安全儲存與注入，屬於模組八：治理好習慣的 secret management 範圍。兩者的交集是：身分層決定「誰能讀到 secret store」，secret 層決定「secret 怎麼存與輪替」。把 IAM role 的 policy 收到只能讀取該服務路徑下的 secret（如 prod/payments/*），是同時落實最小權限與 secret 隔離的結合點。

身分與憑證的地基備妥後，下一步是劃清服務之間的網路邊界——這正是模組三：網路地基的範圍。

跨分類引用

• → 模組負一：還沒有 infra 的環境：長期 key 盤點與護欄
• → 模組三：網路地基：身分備妥後，劃清服務之間的網路邊界
• → 模組四：環境分離與模組化：環境之間的帳號結構與隔離強度
• → 模組七：infra 走 PR 流程：CI/CD 管線用 OIDC 取得短期權限
• → 模組八：治理好習慣：應用層 secret 的儲存與引用
• → backend 模組七：資安與資料保護：Secret Management 與憑證管理交集
• → Access Key 輪替手冊：key 盤點與輪替的操作步驟
• → OIDC Trust Policy 設定指南：GitHub Actions OIDC 的 step-by-step 設定

內容搬運模式（Content Ferry）

斷網環境裡的所有外部依賴（套件、映像、工具、更新）都要經過一條可控的搬運路徑進入。這條路徑的設計決定了環境的安全性和維護效率。

搬運路徑的三種形態

離線媒介搬運：用 USB 隨身碟、外接硬碟或光碟把檔案從有網路的工作站搬進隔離網路。適合高安全環境（軍事、政府機密網路），搬運頻率通常是週或月級。每次搬運的內容要經過掃毒和完整性驗證。

1# 外部工作站：準備搬運包
2mkdir -p ferry/$(date +%Y%m%d)
3# 把需要的套件、映像、工具複製進去
4cp -r packages/ images/ tools/ ferry/$(date +%Y%m%d)/
5# 產生 checksum
6find ferry/$(date +%Y%m%d) -type f -exec sha256sum {} \; > ferry/$(date +%Y%m%d)/manifest.sha256

1# 隔離網路內：驗證搬運包完整性
2cd /mnt/usb/ferry/20260626
3sha256sum -c manifest.sha256

跨網段閘道搬運：在隔離網路的邊界放一台 staging gateway（跳板機），它有兩張網卡——一張連外部網路（或 DMZ）、一張連內部隔離網路。外部的內容先傳到閘道、經過掃描和審查後再推進內部。適合金融和工控環境，搬運頻率可以是日級。

閘道的安全約束：只允許特定的檔案類型通過、所有傳入的檔案經過掃毒、傳輸記錄要保留 audit log、閘道本身定期更新安全軟體。

單向資料二極體（Data Diode）：硬體層面只允許資料單向流動（外 → 內），物理上無法從內部網路傳資料出去。用在最高安全等級的環境。搬運頻率和內容由二極體的設定決定。

搬運的操作紀律

每次搬運都要記錄：日期、搬運者、搬運內容清單（檔名 + 版本 + checksum）、搬運理由。這份紀錄存在內部網路的版本控制裡，讓「這個套件是誰、什麼時候、為什麼帶進來的」事後可追溯。

搬運內容的安全審查至少包含：掃毒（ClamAV 或商業掃毒）、checksum 驗證（確認搬運過程沒有被竄改）、版本確認（確認搬進來的版本跟預期的一致、不是被降級的舊版）。

時程參考：建立搬運流程（含閘道設定、掃描工具安裝、紀錄模板）約需 2-3 天。之後每次搬運操作約 1-2 小時（含準備、掃描、驗證、紀錄）。

離線套件管理

連網環境的 apt install、yum install、npm install 背後都在連線到公開的套件倉庫。斷網環境需要在內部建立這些倉庫的離線鏡像。

作業系統套件

Debian/Ubuntu：用 apt-mirror 或 aptly 在有網路的環境建立 mirror，把整個 mirror 搬進內部網路，內部機器的 /etc/apt/sources.list 指向內部 mirror。

1# 外部：建立 mirror（首次約 50-200GB，後續增量）
2apt-mirror /etc/apt/mirror.list
3
4# 內部：設定 sources.list 指向內部 mirror
5echo "deb http://internal-mirror.local/ubuntu jammy main restricted" > /etc/apt/sources.list
6apt update

RHEL/CentOS：用 reposync 把 yum repo 同步到本地，搬進內部後用 createrepo 建立 repo metadata。

1# 外部：同步 repo
2reposync --repoid=baseos --download-metadata -p /path/to/mirror/
3
4# 內部：建立 repo 並設定
5createrepo /path/to/mirror/baseos

應用層套件

Node.js（npm）：npm pack 把每個依賴打包成 .tgz，搬進內部後用 npm install --offline 或建立 Verdaccio private registry。

1# 外部：打包所有依賴
2npm pack --pack-destination ./offline-packages/
3# 或用 npm-offline-mirror
4npm install --prefer-offline --cache ./npm-cache

Python（pip）：pip download 把依賴下載成 wheel 或 tarball，搬進內部後 pip install --no-index --find-links=./packages/。

PHP（Composer）：composer install 後整個 vendor/ 目錄打包搬進去。或建立 Satis 作為 private Packagist mirror。

套件鏡像的維護節奏

離線 mirror 需要定期更新——安全補丁、版本升級都要透過搬運流程進入。更新頻率取決於安全需求：高安全環境至少月更（安全補丁）、一般環境季更可接受。每次更新都是一次搬運操作，要走完整的審查流程。

多格式統一：Nexus Repository

上面的做法是每個套件生態各自建 mirror（apt-mirror + Verdaccio + Satis + pip local index）。Nexus Repository 是多格式統一的 artifact proxy，同時支援 apt / yum / npm / Maven / PyPI / Docker / Helm——在企業級斷網環境裡，用一個 Nexus 實例取代多個獨立的離線 repo mirror，維護成本較低。代價是 Nexus 本身的安裝和維運（Java 應用、需要磁碟空間和記憶體），小團隊各自建 mirror 可能反而更簡單。

離線 Configuration Management：Ansible

斷網環境的 OS 設定、套件安裝、服務啟動等 configuration management 需求，Ansible 是運作良好的工具——它不需要在目標機器安裝 agent、透過 SSH 推送 playbook 執行，playbook 本身是 YAML 可版本控制。在沒有雲端 IaC（Terraform 管的是雲端資源 API）的地端斷網環境裡，Ansible 負責 configuration management 層。Ansible 自身的安裝只需要 Python，控制端安裝後即可透過 SSH 管理內部所有機器。

變更追蹤：沒有 GitHub 怎麼辦

斷網環境不能 push 到 GitHub、不能開 PR、不能用 GitHub Actions。但 git 本身是離線工具——git 的所有操作（commit、branch、merge、log、diff）都不需要網路。

內部 Git Server

在隔離網路內架設 git server：Gitea（輕量、單一二進位、適合小團隊）、GitLab CE（功能完整、含 CI/CD runner、適合中大團隊）、或最簡單的 bare repo on NFS。

1# 最簡單的方式：bare repo on 共用檔案系統
2git init --bare /shared/repos/infra.git
3
4# 開發者 clone
5git clone /shared/repos/infra.git

Git Bundle 跨網段傳遞

如果需要在有網路的環境開發、完成後搬進隔離網路，用 git bundle 把 commit 打包成單一檔案：

1# 外部：把 main branch 的所有 commit 打包
2git bundle create infra-$(date +%Y%m%d).bundle main
3
4# 搬運後，在內部 clone 或 pull
5git clone infra-20260626.bundle infra-repo
6# 或增量更新
7git pull infra-20260626.bundle main

bundle 檔案可以用 git bundle verify 驗證完整性。增量 bundle（只包含某個 tag 之後的 commit）可以減少搬運的資料量：

1git bundle create incremental.bundle last-imported-tag..main

Code Review 的替代方案

沒有 GitHub PR，code review 可以用：

• GitLab CE / Gitea 的內建 merge request（如果架了內部 git server）
• git format-patch 產出 patch 檔 + email review（傳統做法、不需要 web UI）
• git diff main..feature | less 直接在終端機 review（最簡陋但可行）

Staging Gateway 的設計

staging gateway 是搬運路徑的關鍵節點——它決定了什麼能進、什麼不能進。設計要點：

最小安裝：閘道上只裝搬運需要的工具（scp、rsync、掃毒軟體、checksum 工具），不裝開發工具、不跑應用服務。攻擊面越小越好。

雙網卡隔離：一張網卡連外部（或 DMZ）、一張連內部。兩張網卡之間沒有自動路由——檔案必須經過人工或腳本從外部目錄搬到內部目錄，中間經過掃描。

審計紀錄：閘道上的所有檔案操作（建立、複製、刪除）都要記錄。auditd 或等價工具提供核心層級的操作追蹤。

定期輪替：閘道本身的 OS 和掃毒軟體需要更新。這是一個遞迴問題（用什麼搬運閘道的更新？）——通常用離線媒介搬運閘道自身的更新，或用另一台更上游的閘道。

時程參考：閘道的初次設定（含 OS 安裝、雙網卡配置、掃描工具、審計設定）約需 1-2 天。搬運流程文件化約需半天。

安全審查：什麼能跨越隔離邊界

每一筆跨越隔離邊界的內容都是潛在的攻擊向量。審查的原則是：預設拒絕，逐項允許。

審查清單：

對決策者的重點：斷網環境的安全不是「隔離就安全」——搬運路徑是唯一的攻擊面，這條路徑的安全審查品質決定了整個隔離環境的安全水位。

跨分類引用

• → 斷網環境的 IaC：Terraform provider 和 module 的離線管理
• → 斷網環境的容器管理：映像搬運用的是本篇的 content ferry 模式
• → 模組八：治理好習慣：斷網環境的搬運紀錄是治理的一部分

預設 Redaction Rule

SDK 內建的 redaction rule 覆蓋最常見的敏感欄位模式。開發者不需要設定就能獲得基本保護。

欄位名稱比對

以下欄位名稱（不分大小寫）的值自動替換為 [REDACTED]：

• password、passwd、secret、token、api_key、apiKey
• authorization、auth、credential
• ssn、social_security
• credit_card、card_number、cvv、cvc

欄位名稱比對用 substring match — user_password 包含 password 會被 redact，password_reset_token 包含 password 和 token 也會。

值格式比對

以下格式的值無論欄位名稱為何都自動替換：

• Email 地址格式（user@domain.com → u***@domain.com）
• 信用卡號碼格式（連續 13-19 位數字 → 保留末四碼）
• Bearer token 格式（Bearer xxx → Bearer [REDACTED]）

值格式比對用正則表達式。正則的效能影響在大量事件時需要注意 — 預設 rule 的正則保持簡單，避免 catastrophic backtracking。

自訂 Pattern

應用可能有自己的 secret 格式，預設 rule 覆蓋不到。SDK 提供 API 讓開發者註冊自訂 redaction pattern。

 1monitor.addRedactionRule(
 2  name: 'internal-api-key',
 3  pattern: RegExp(r'sk_live_[a-zA-Z0-9]{24}'),
 4  replacement: '[REDACTED:api-key]',
 5)
 6
 7monitor.addRedactionRule(
 8  name: 'database-url',
 9  fieldNames: ['database_url', 'db_url', 'connection_string'],
10  replacement: '[REDACTED:db-url]',
11)

自訂 pattern 的設計考量：

Pattern 在 init 時註冊。Redaction rule 在 SDK 初始化時設定，之後所有事件都通過這些 rule。不支援動態修改 — 避免「中途加 rule 導致之前的事件沒被 redact」的困惑。

Pattern 順序無關。所有 rule 獨立執行，不依賴順序。一個欄位可以匹配多個 rule，以第一個匹配的 replacement 為準。

Replacement 可以保留部分資訊。[REDACTED] 完全遮蔽，[REDACTED:api-key] 保留類型資訊，u***@domain.com 保留結構。保留類型資訊對 debug 有幫助 — 看到 [REDACTED:api-key] 至少知道這裡原本有一個 API key。

Redaction 的適用範圍

Redaction 應用在 SDK 送出事件前的最後一步 — 在序列化（JSON encode）之前。適用範圍包括：

• Event 的 data 欄位（自由欄位，開發者可能放入任何內容）
• Error 的 stack trace（檔案路徑可能包含使用者名稱或部署路徑）
• Error 的 message（例外訊息可能包含 query string 或參數值）
• Lifecycle 的 metadata（連線 URL 可能包含認證資訊）

Redaction 不應用在 SDK 的內部欄位（timestamp、event type、session ID）— 這些是 SDK 自己產生的，不包含使用者資料。

下一步路由

• 資料離開 client 後的保護 → Transport 安全
• 去識別化策略 → 去識別化策略
• IME 個人化學習的 secret 洩漏風險 → ux-design 模組三 IME 安全 checklist

服務定位

Cloudflare WAF 的核心定位是 把攻擊擋在 origin 之前的一站式 edge security。流量打到 Cloudflare anycast IP、經過 WAF / DDoS / Bot / Rate Limit / Page Shield 多層處理、再 proxy 到 origin。這跟 AWS WAF 跑在 AWS 內部 ALB / CloudFront / API Gateway 前是不同部署模型 — AWS WAF 流量 已經進到 AWS、Cloudflare WAF 流量 還沒到 origin。對 origin 是 任意雲 / on-prem 的客戶、Cloudflare 是天然選項；對 AWS-only 客戶、AWS WAF 整合更深但 edge 範圍小。

跟 Fastly Next-Gen WAF（前 Signal Sciences）相比、Cloudflare 走 signature + managed rule + ML 混合、Fastly NG-WAF 走 語意分析 + behavioral detection（不靠 regex signature）。Cloudflare managed rule 覆蓋廣但 false positive 較常見、需要 sensitivity tuning；Fastly NG-WAF 預設較低 FP 但需要 自己定義業務 anomaly。

關鍵張力：客戶信任的不只是 WAF rule 攔截能力、還包括 Cloudflare control plane 的安全性。Cloudflare 2023 control plane token 跟 Cloudflare 2026 route leak 兩個事件展示：vendor 自己被打進去 / 自動化配置失誤時、客戶側 直接修不了、只能等公告 + 客戶側 token rotation + emergency bypass。

本章目標

讀完本頁、讀者能判斷：

1. Cloudflare WAF 在 edge security stack 中承擔哪一段（DDoS / WAF / Bot / Page Shield / API Shield）、哪些要靠 origin 自己做
2. Managed Rule vs Custom Rule 的取捨、sensitivity tuning 跟 false positive curve
3. Cloudflare control plane 出事時的客戶側補強路徑（API token rotation、Origin Rules bypass、第二邊界 fallback）
4. 何時用 Cloudflare、何時走 AWS WAF / Fastly NG-WAF 的取捨

最短判讀路徑

判斷 Cloudflare WAF 配置是否健康、最少看四件事：

• 誰能改 WAF 規則：Cloudflare account 的 admin / member role 配置、API token scope（不要用 Global API Key、用 scoped API token + 限定 zone / 限定 permission）、Audit Log 是否同步到 SIEM
• 規則覆蓋面：Managed Ruleset（OWASP Core Ruleset + Cloudflare Managed Ruleset + Exposed Credentials Check）是否開、Sensitivity（Low / Medium / High）對應的 FP rate 是否監控、Custom Rule 是否進版控（Terraform provider）
• 入口暴露：origin IP 是否曝光（DNS 直查 / 歷史 SAN cert / 子域名）、Argo Tunnel / Authenticated Origin Pull 是否強制、繞過 Cloudflare 直連 origin 的路徑是否封住
• 證據可回查：Security Events Log 是否同步到 SIEM（Logpush 推到 R2 / S3 / Splunk）、Page Shield 偵測異常 script 是否 alert、API token 異常操作（特別 zone settings 變更）是否 alert

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Managed Ruleset 分層：Cloudflare 提供三類 managed rule — OWASP Core Ruleset（OWASP CRS、寬覆蓋、FP 較多）、Cloudflare Managed Ruleset（Cloudflare 維護、針對熱門 CMS / framework）、Exposed Credentials Check（檢測登入流量中的已洩漏 credential）。production 通常開全部三套 + 各設適當 sensitivity。Sensitivity 不是「敏感度越高越好」— High sensitivity 攔截更多 borderline traffic、business-critical endpoint 可能誤殺合法請求。建議從 Log Mode 開始、觀察 1-2 週的 FP pattern、再切到 Block。

Custom Rule（Cloudflare Rules）：用 Rules language（類 SQL 表達式）定義條件 + 動作（Block / Challenge / Log / JS Challenge / Managed Challenge）。常見用法：geo block（特定國家）、known bad IP（threat intel feed）、URI path-based limit（admin endpoint 限定 IP）、header anomaly（缺 User-Agent / 異常 Referer）。所有 Custom Rule 走 Terraform provider 進版控、避免 console 直接改、變更走 PR review。

Rate Limiting：跟 WAF rule 是 獨立 product、配置是 threshold + window + action（例：1000 req/min per IP → challenge）。Rate Limiting 比 WAF 適合處理 legitimate-looking high volume（credential stuffing、scraping、API abuse）。注意 NAT pool IP 的問題 — 一個公司 / ISP NAT 出口可能合法產生高 QPS、簡單 per-IP rate limit 會誤殺、需要組合 cf.threat_score 或 cookie-based identification。

Bot Management（單獨 SKU）：免費版 WAF 不含 Bot Management、需要 Pro / Business / Enterprise 才有。Bot Management 用 ML + behavioral fingerprint 區分 human / good bot（搜尋引擎）/ likely bot / verified bot、給 bot score（1-99）。客戶在 Custom Rule 用 cf.bot_management.score < 30 之類條件挑出 likely bot 處理。簡單 user-agent 過濾擋不住現代 headless browser、必須走 Bot Management。

Page Shield（JS supply chain 防護）：Page Shield 監測客戶網頁載入的 JS / connect 來源、發現 新出現的腳本 或 已洩漏的 script（CT log + threat intel）就 alert。意義是 防 third-party script 被供應鏈攻擊（類 Magecart）— WAF 攔不住、因為攻擊發生在 browser 端 而非 origin 流量。需要在 Page 載入 Page Shield 的 monitoring script。

API Shield：用 OpenAPI schema validation、auto-discovery API endpoint、mTLS 驗證、JWT validation。對於有 schema 的 API、可以擋掉 schema 不符的請求（多餘欄位、型別錯誤、缺必要欄位）— 比 generic WAF rule 精準。

Origin 暴露面收緊：Cloudflare 唯一有效的前提是 流量必須經過 Cloudflare。如果攻擊者拿到 origin 真實 IP（DNS 歷史記錄、漏洞披露網站、SSL cert SAN）、可以繞過 Cloudflare 直打 origin。控制方法：origin firewall 只允許 Cloudflare IP range 入站、Argo Tunnel（origin 主動建 outbound 連線到 Cloudflare、不開任何入站 port）、Authenticated Origin Pull（origin 用 cert 驗證請求來自 Cloudflare）三選一或組合。

API token 治理：避免 Global API Key（全帳號 root token）、改用 scoped API token（限 zone + 限 permission + 限 IP + 限 TTL）。token 進 Secret Management / Vault、定期 rotate。對應 Cloudflare control plane token 2023 揭示的 lesson：Cloudflare 自己也踩過 token 治理不足、客戶側不能假設 vendor 完美。

核心取捨表

選 Cloudflare WAF 的核心訴求：多雲 / on-prem origin + 需要 整套 edge security suite（DDoS + WAF + Bot + Page Shield + API Shield） + 接受 Cloudflare 控制面風險、且有預算做 Enterprise tier 才能拿到完整功能。純 AWS-internal app + ALB origin 用 AWS WAF 整合更直接。

進階主題

Workers + Workers AI 作為 custom logic：當 managed rule + custom rule 表達力不夠（例：根據 user account tier 決定 challenge 強度、整合內部 risk score API）、可以用 Cloudflare Workers 寫 JavaScript / TypeScript / Rust 在 edge 執行。Workers AI 提供 edge ML inference、可以做 inline content moderation 或 anomaly detection。代價是 Workers code 進 Cloudflare 控制面、變更要走部署流程、debug 跟 origin 是兩條 trace。

Logpush 跟 SIEM 整合：Cloudflare Security Events 量大、free / Pro 在 dashboard 看、Business / Enterprise 走 Logpush 到 R2 / S3 / Splunk / Datadog / Sumo Logic。production 必須走 Logpush、不能只在 dashboard — 事件 30 天保留期是 Cloudflare 端、SIEM 留更久。Logpush 也是 SIEM 上做 跨來源 correlation 的前提（WAF event + origin app log + IdP log）。

Multi-account / Tenant：大企業有多個 Cloudflare account（不同 BU / 不同產品線）、要走 Cloudflare for SaaS 或 Account-level access、API token scope 要限定 account。Single account 多 zone 是常見小組織配置、但跨組織 / 跨產品線必須拆 account 隔離 admin compromise blast radius。

Magic Transit / Zero Trust integration：Magic Transit 是 L3 DDoS（不只 HTTP、TCP / UDP 也 anycast）、Zero Trust 是 employee access（取代 VPN）。跟 WAF 是不同產品、但常一起部署 — Magic Transit 防 L3/L4 attack、WAF 防 L7、Zero Trust 防內部 east-west。

排錯與失敗快速判讀

• Managed Rule 誤殺合法請求：High sensitivity 開後 business endpoint 變慢 / 報錯 — 看 Security Events 找 rule_id、用 Custom Rule skip 該 rule 在特定 path / 特定 user-agent、不要全 zone 關 rule
• Bot Management 太嚴 / 太鬆：bot score threshold 設不對、合法 API client 被當 bot、或攻擊者拿到 verified bot 假冒 — 用 Bot Analytics 看分數分布、調整 threshold 同時加白名單（API key + IP CIDR）
• Rate Limit 誤殺 NAT 用戶：per-IP rate limit 在 NAT 出口 IP 上炸 — 改 per-session（cookie-based）或 cf.threat_score 條件
• Origin IP 外洩：DNS 歷史 + 漏洞披露 + cert SAN 揭露真實 origin、攻擊繞 Cloudflare 直打 — 換 IP + 開 origin firewall（只允許 Cloudflare CIDR）+ Argo Tunnel
• API token over-scoped：CI / 第三方 SaaS 拿到 Global API Key、整 account 都被改 — 改 scoped token、限 zone + permission + IP、進 Vault
• Security Events 沒進 SIEM：事件只在 dashboard、跨來源 correlation 沒法做 — 配 Logpush + alert 規則
• Page Shield 沒裝：客戶端 JS 被植入、伺服器端日誌看不到攻擊、第三方 script CDN 被打 — 啟用 Page Shield + CSP report-uri 雙軌
• 第二邊界沒設：完全依賴 Cloudflare、Cloudflare 出事流量全停（2023 / 2026 自家事件）— 高 SLA 服務應該設 fallback origin / secondary DNS（如 Route53 health check failover 到 Fastly 或直連 origin）

何時改走其他服務

不在本頁內的主題

• Cloudflare 完整 product line（Workers / Pages / R2 / D1 / Magic Transit / Zero Trust 各自細節）
• WAF Rules language 完整語法 reference
• Page Shield / API Shield Enterprise tier 完整功能對照
• 各 PCI DSS / SOC 2 / FedRAMP 合規矩陣
• Cloudflare 在中國的部署模式（JD Cloud Union 合作）

案例回寫

Cloudflare WAF 在 07 案例庫有 兩個直接 vendor-level 事件 + 多個 edge-exposure 對照：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：AWS WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（Cloudflare API token 存放）、Okta（Cloudflare admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 / Cloudflare 自家事件如何 routing 進 IR）
• 官方：Cloudflare WAF Documentation

服務定位

Vault 的核心定位是 跨雲 + 跨環境 + 跨 secret 形態的單一 secret 控制面。當組織同時跑 AWS + GCP + on-prem K8s、又需要 dynamic database credential + 內部 PKI + envelope encryption、用三個 cloud-native service 拼起來會出現 secret 治理鏈不連續（AWS 的 secret 怎麼授權 GCP service 取用、on-prem app 怎麼拿短期 cloud credential、內部 CA 跟外部 ACM 怎麼分工）。Vault 把這層 統一抽象 — 應用端只跟 Vault 講話、Vault 後端接各雲 KMS / database / PKI。

跟 AWS Secrets Manager / Google Secret Manager 相比、Vault 多了：dynamic credential engine（cloud-native 對應產品有限）、transit engine 做 encryption-as-a-service、PKI engine 自簽內部憑證、跨雲統一介面。代價是 自管運維（HA cluster、auto-unseal、replication、upgrade）— 跟自管 Keycloak 的取捨同類。HCP Vault（HashiCorp Cloud Platform）是 HashiCorp 託管版、把運維交還、但綁 HashiCorp。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 適合 Vault（dynamic credential、跨雲、PKI、encryption-as-a-service）、哪些直接用雲端 native service 即可
2. Vault deployment 的最低安全需求（auto-unseal、HA、audit device、policy、replication）
3. Vault 自己出事時的降級路徑（seal storm、root token 復原、audit log gap）
4. 何時用 Vault、何時走 Secrets Manager / Google Secret Manager / Azure Key Vault 的取捨

最短判讀路徑

判斷 Vault deployment 是否健康、最少看五件事：

• 誰能做什麼：root token 是否已 revoke、policy 是否走 path-based least privilege、admin 是否走 OIDC / AWS IAM auth 而不是 token、break-glass token 是否離線存
• Auth method 收緊：AppRole / Kubernetes / OIDC / JWT auth 哪些開、role 對應的 policy 是不是過寬、TTL 是否短、bound_* 條件是否鎖（namespace / audience / subject）
• Secret engine 設定：KV v2 開 versioning？dynamic engine（database / aws / pki）lease TTL 多久、max TTL 限制是什麼、revocation 是否驗證生效
• Seal / unseal 治理：是否走 auto-unseal（KMS-backed）、recovery key 持有者跟 Shamir threshold、replication 跟 DR cluster 是否同步
• 證據是否可回查：audit device（file / syslog / socket）是否多 channel、是否同步到 SIEM、replay 攻擊防護是否開（HMAC + nonce）

五件事任一缺失、就是 Audit Log 與 Secret Management 邊界的待補項目。

日常操作與決策形狀

Auth method 設計：AppRole 適合不在雲端 metadata 內的 workload（on-prem、CI runner）但 secret_id 本身要妥善保管；Kubernetes auth 適合 K8s 內 workload、用 ServiceAccount token + projected token；AWS IAM auth 適合 AWS 內 workload、走 STS 簽名驗證、不需要存 secret；OIDC / JWT 適合 human admin + CI（GitHub Actions / GitLab CI 走 OIDC token）。每個 auth method 對應 一組 role、role 綁 policy 跟 TTL。

Secret engine 分層：KV v2（static secret + version history）作為基線；dynamic database engine（PostgreSQL / MySQL / MongoDB）發短期 DB user、max_ttl = 1h 級別、過期 Vault 自動 revoke；AWS / Azure / GCP secret engine 對 cloud account 發短期 STS credential / service account key；PKI engine 自簽憑證、跟 cert-manager 整合做 K8s workload mTLS；transit engine 做 envelope encryption — app 把資料丟給 Vault 加密、key 不離 Vault。

Policy（path-based）：Vault policy 是 path + capabilities（create / read / update / delete / list / sudo）的 mapping。常見錯配：給 secret/* read 等於整個組織所有 secret 都看得到、應該用 secret/data/{team}/* 之類前綴限定；admin policy 不要給 sudo 太寬、policy 變更走 PR review + CI apply。

Rotation 跟 lease 治理：static secret（KV）的 rotation 是 app 自己做（拿新 secret 後手動 update）；dynamic secret 是 Vault 控制 lease 生命週期、app 只要在 TTL 內續租即可。對應 Failure: Credential Rotation Without Scope：static secret 的 rotation 必須有 scope map — 哪些 service 用了同一把 secret、哪個 service 支援零停機 rotation、誰是 last to be rotated。沒這份 map 就會發生「rotate 後某個被遺忘的 cron job 認證失敗、整個下游崩」。

Seal / unseal 設計：Vault 啟動時 sealed、必須 unseal 才能服務。Shamir secret sharing 是預設（5 key holders、3 threshold）— 任何重啟需要找齊 3 個人合 unseal、production 場景幾乎都該換 auto-unseal（用 AWS KMS / GCP KMS / Azure Key Vault 當 master key custodian）。代價是 把 master key 託給雲廠 — 不接受的組織保留 Shamir + 嚴格 key holder rotation。

Audit device 是 必開：Vault 預設不開 audit、要手動 enable（vault audit enable file path=/var/log/vault_audit.log）。沒 audit device 在 production = 事故時 連 token 被誰用過都查不到。建議多 channel（file + syslog + 推到外部 SIEM）— 單一 channel 失效（disk full、socket broken）Vault 會拒絕請求、影響 availability、所以多 channel 是必要冗餘。

Break-glass 與 root token：初始化時產生的 root token 應該 用完立刻 revoke、改用 admin policy + OIDC auth。break-glass scenario 用 recovery key 重新發 root token、recovery key 走 Shamir 多人持有 + 離線存。

核心取捨表

選 Vault 的核心訴求：跨雲 + dynamic credential + 內部 PKI + transit encryption 至少滿足兩項、且能投入 SRE 量能跑 HA cluster、有 SIEM 接 audit log、能接受 self-hosted 的 upgrade / cert / DB 運維成本。單純需要 AWS-only static secret rotation、直接用 Secrets Manager 更便宜更簡單。

進階主題

Dynamic credential 的 lease 生命週期治理：dynamic engine 發出的 credential 都帶 lease ID、Vault 在 TTL 到期時自動 revoke（database engine 真的會 DROP USER、cloud engine 真的會 DeleteAccessKey）。設計時要算清楚 app 連線池的 connection lifetime — DB connection 持續用同一組 credential、credential lease 過期但 connection 還在會出現 staled credential 問題。常見作法：lease TTL > connection idle timeout * 2、加 lease renewal mechanism（app 在 TTL 50% 時主動 renew）。

Transit engine（encryption-as-a-service）：app 不持 encryption key、把 plaintext 丟給 Vault encrypt API、拿 ciphertext 回來；解密時把 ciphertext 給 Vault decrypt API。Key 完全不離 Vault、所有 cryptographic operation 在 Vault 內、app 只需要 encrypt / decrypt capability。對應 Storm-0558 signing key chain 的對照啟示：key 不能 export 是減 blast radius 的關鍵設計 — transit 把這個原則內建。

PKI engine + cert-manager 整合：Vault PKI engine 可以當內部 root CA + intermediate CA、issue 短期 cert（hours-level）給 K8s workload；cert-manager 用 Vault PKI issuer 自動更新 cert。比起手動跑 OpenSSL CA、Vault PKI 的優勢是 cert lifecycle 進 Vault audit、跟 secret rotation 用同一套 evidence chain（呼應 credential rotation scoped evidence）。

Namespace（Enterprise）跟 multi-tenancy：Enterprise 版 namespace 是 tenant 邏輯隔離、每個 namespace 有自己的 auth method、policy、secret engine。OSS 版沒 namespace — 多團隊共用 Vault 要靠 path 命名規約 + policy prefix 拼隔離、邊界較鬆。大組織通常需要 namespace 才能避免單一 admin 跨 team 越界。

Replication（Enterprise）：Performance Replication（主從 + 多 region active）跟 DR Replication（純 standby）是兩個獨立功能。production HA 通常需要 同 region 的 cluster + 跨 region 的 DR replication、recovery key 跟 unseal 機制要跨 cluster 一致。

排錯與失敗快速判讀

• Audit device 沒開：production 啟動時忘了 enable audit、事故發生時無 forensic data — 啟動 checklist 必含「enable audit before serving traffic」、SRE runbook 用 health check 驗
• Policy 過寬：給整個 secret/* read、單一 token 等於拿到全公司 secret — 用 path prefix 限定到 {team}/{env}/*、policy review 走 PR
• Dynamic credential lease 太長 / 沒 max_ttl：DB user 跑了一週還沒收、攻擊者只要拿到一次就長期可用 — 設定 lease TTL = 1h、max_ttl = 24h
• Auto-unseal KMS access 沒監控：AWS KMS / GCP KMS 的 Vault auto-unseal key 沒 alert 異常使用 — KMS 端設 alert（GetKeyValue / Decrypt 突增）
• Replication lag 沒 alert：Performance / DR replication 落後幾分鐘到幾小時、failover 時拿到 stale state — Prometheus 監控 vault.replication.* metric
• Root token 未 revoke：初始化時的 root token 還在用、policy / audit / OIDC 全 bypass — 初始化 checklist 強制 revoke、CI 跑 vault token lookup 驗證 root 不可用
• Sealed 後 unseal key 找不到人：production cluster 緊急 restart、Shamir threshold 3 但有 1 個 key holder 在度假 — production 必須 auto-unseal、recovery key 走 break-glass 流程

何時改走其他服務

不在本頁內的主題

• Vault 完整 API reference 跟 CLI 詳盡用法
• 每個 secret engine 的內部實作細節（DB connection pool、cloud SDK 呼叫順序）
• Enterprise 各 license tier 的功能對照
• Terraform / Ansible 跟 Vault 整合的完整步驟
• 各 auth method 的 OIDC / SAML provider 設定教學

案例回寫

Vault 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：AWS Secrets Manager、Google Secret Manager、Azure Key Vault
• 下游：AWS KMS / Google Cloud KMS（Vault auto-unseal master key custodian）
• 下游：cert-manager（用 Vault PKI engine 作為 K8s workload cert issuer）
• 跨模組：8 事故處理 vendor 清單（Vault 事件如何 routing 進 IR 流程）
• 官方：Vault Documentation

服務定位

Okta 是 人類身份的控制面、不是 cloud resource permission engine。把 cloud IAM（AWS IAM、Google Cloud IAM、Azure RBAC）的角色指派交給 Okta 是常見組合 — Okta 負責「這個人是誰」、雲端 IAM 負責「這個身份能對 resource 做什麼」。Workforce Identity Cloud（員工）跟 Customer Identity Cloud（消費者、原 Auth0）是兩個產品線、安全模型跟事件分布都不同（本頁聚焦 Workforce、Auth0 見 Auth0 vendor）。

跟自管 IdP（Keycloak）相比、Okta 把 issuer 信任、signing key 生命週期、support tooling 都託管出去 — 代價是 第三方控制面的事故會直接打到自己（Okta 2022 Sitel 環境洩漏、2023 support system HAR token 外洩、2023 cross-tenant impersonation）。跟 cloud-native SSO（AWS IAM Identity Center）相比、Okta 的核心優勢是 多雲 + SaaS app 數百個 integration 預先建好、不是綁單一雲廠。

本章目標

讀完本頁、讀者能判斷：

1. Okta 該承擔哪一段 identity 控制（SSO / MFA / lifecycle / federation）、哪一段該交給雲端 IAM
2. Okta tenant 的信任邊界與最低稽核需求（admin role、API token、SCIM、support workflow）
3. Okta 自己出事時的降級路徑（emergency access、break-glass、out-of-band MFA）
4. 何時用 Okta、何時走 Auth0 / Keycloak / AWS IAM Identity Center 的取捨

最短判讀路徑

判斷 Okta 配置是否健康、最少看四件事：

• 誰能做什麼：Super Admin / Org Admin / Read-Only Admin 的人數、是否走 Okta 自己的 access request workflow、是否強制 phishing-resistant 認證
• 憑證在哪裡：API token 的 owner、scope、TTL、是否走 OAuth service app 而不是 personal API token；service account 是否獨立 audit
• 入口如何暴露：SSO 是 SAML 還是 OIDC、IdP-initiated 是否關閉、admin console 是否限 IP / device trust、helpdesk reset 是否要 callback / out-of-band 驗證
• 證據是否可回查：System Log 是否同步到 SIEM、admin / token / impersonation 事件是否 alert、是否保留 90 天以上

四件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Onboarding / lifecycle：HR 系統推 SCIM 進 Okta、Okta 推 SCIM 到下游 SaaS / 雲端 SSO。決策點是 誰是 source of truth — HRIS 還是 Okta 自己。混用會造成 stale account 與例外帳號無法收。

Policy（authentication）：Sign-On Policy 跟 Authentication Policy（New Policy Framework）兩套並行、要避免規則交疊。高風險操作（admin login、寫權限應用）應該強制 phishing-resistant factor（WebAuthn / passkey）、不只是 push MFA（Uber 2022 揭露：純 push MFA 抗不過 fatigue）。

MFA factor 選擇：避免 SMS / voice 作為主要 factor。Okta 2024 把 telephony 推給客戶 BYO（Okta BYO Telephony case）— 信任邊界從「Okta 全管」變成「客戶自己挑簡訊供應商」、若沒同步調整威脅模型會把 SMS swap 風險吃下來。

API token / OAuth service app：personal API token 容易隨人員離職 stale、應該走 OAuth service app（client credentials）並把 scope 收到最小。token 不存 source code、走 Secret Management 取用。

Exception / break-glass：至少 2 個 break-glass admin、credential 離線存（紙本保險箱 / secret management 隔離 tenant）、走獨立 MFA（hardware key、不依賴主要 Okta tenant 的 push）、季度驗證可用。Okta tenant 整個失聯時這是唯一退路。

Audit / handoff：System Log 推進 SIEM、特別 alert 三類事件 — admin role 變更、API token 建立、impersonation / support access。Okta 2023 support system 事件展示：如果客戶沒 alert support impersonation 的 session、就只能等 Okta 公告。

核心取捨表

選 Okta 的核心訴求：跨雲 + 大量 SaaS app + lifecycle 要自動化、且能接受第三方控制面風險、有預算做完整 SIEM / break-glass / 第三方應變流程。

進階主題

Federation 跟 workload identity：Okta 對人類 SSO 強、對 workload identity 較弱。CI / 服務間用 AWS IAM role 的 OIDC trust、Google workload identity federation 比把 Okta API token 散到服務裡更安全。

Cross-tenant 邊界：B2B 合作（partner、contractor）要清楚是「partner 用自己 IdP 做 federation 進來」還是「partner 在我的 Okta tenant 開帳號」。2023 cross-tenant impersonation 事件（Okta Cross-Tenant case）揭示：admin 工具若沒限定 tenant scope、單一 admin compromise 會跨多 tenant 擴散。

Device trust / posture：Okta Device Trust + EDR signal 是補 phishing-resistant MFA 之後的下一層 — 確認 使用者 對之外、確認 裝置 健康。BYOD 比例高的組織這層做不起來就靠人類因子守。

Identity Threat Protection / ITP：Okta 2024 推的事件偵測 add-on、補 session anomaly、credential stuffing、impossible travel 等場景。本質是把 SIEM detection 的一部分內建、不是取代外部 SIEM。

排錯與失敗快速判讀

• Admin account 過多：經常超過必要 — 用 Group Rules + Access Request workflow 收斂、把日常操作用 Read-Only Admin + 特定權限 group 替代
• API token stale / 散落：personal API token 跟著員工離職留下 — 季度盤點、改 OAuth service app
• SMS MFA 還是預設：MFA enrollment 沒強制 WebAuthn / passkey、新員工選最弱 factor — Authentication Policy 應該限制可選 factor
• System Log 沒進 SIEM：事件只在 Okta UI、alert 沒接 on-call — 用 Log Streaming（CloudWatch / S3 / Splunk HEC）打進 SIEM、特定事件接 alert runbook
• Helpdesk reset 無 callback：MGM 2023 / Caesars 2023 都是 helpdesk social engineering、需要 callback + out-of-band 驗證、不是 ticket 上看到「我忘記密碼」就 reset
• Support 工具 session 沒監控：Okta 2023 support 事件揭示需要 alert support impersonation session 進入我的 tenant 的事件 — System Log 有對應事件、但通常沒 default alert

何時改走其他服務

不在本頁內的主題

• Okta 完整 SAML / OIDC 規格細節、SCIM schema 客製
• Workforce vs Customer Identity Cloud 完整功能對照
• Okta 各定價層級的功能差異
• 各 SaaS app 的 SSO 接線教學

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Auth0 vendor、Keycloak vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM / Azure RBAC（Okta 之後的 cloud resource permission 層）
• 跨模組：8 事故處理 vendor 清單（Okta 事件如何 routing 進 IR 流程）
• 官方：Okta Documentation

服務定位

Splunk 的核心定位是 任意 log source 的統一查詢平台、SIEM 是其上的 application layer（Splunk Enterprise Security app）。底層是 Splunk Enterprise（自管）或 Splunk Cloud Platform（SaaS）、頂層產品包含：Enterprise Security (ES) — premium SIEM app、含 correlation rule、Risk-Based Alerting、ITSI 整合；SOAR（前 Phantom）— security orchestration / automated response；UBA（User Behavior Analytics）— ML-based anomaly detection。

跟 Elastic Security 比、Splunk 走 deeper but more expensive — SPL 比 KQL / EQL 表達力更強、detection content（Splunk Security Content 公開 YAML rules）覆蓋廣、ES app 的 Risk-Based Alerting 是業界先驅；但 ingestion-based pricing 在 TB/day 級別會痛。跟 Datadog Security 比、Splunk 走 security-first、Datadog Cloud SIEM 是 observability platform 加上 security view；Datadog 適合 cloud-native + 中等規模、Splunk 適合 enterprise + 跨 on-prem。跟 Google Security Operations（前 Chronicle）比、Google Security Ops 走 fixed-price by data、massive scale、Splunk 是 per-GB 累進、超大規模反而 Google 划算。

關鍵張力：ingestion-based 計費 ↔ 偵測覆蓋率 是 Splunk 客戶最大的 trade-off。為了省錢選擇性 ingest log（只進 Windows Event Log 不進 Linux auth log、只進 prod 不進 dev）、結果 Storm-0558 / Uber MFA 那種跨來源 correlation 抓不到。要看清楚自己 容忍多少偵測盲點換多少預算。

本章目標

讀完本頁、讀者能判斷：

1. Splunk 在 SOC stack 中承擔哪一段（log aggregation / SIEM / SOAR / UBA）、哪些要外接（Vault 管 service token、IdP log 來源治理）
2. SPL / correlation rule / detection content 的 ownership 設計（誰寫、誰 review、誰調 false positive）
3. Ingestion pricing trap 的應對（log priority tiering、Cribl / Cribl Stream 做 pre-filter、Splunk SmartStore 把冷資料丟 S3）
4. 何時用 Splunk、何時走 Elastic / Datadog / Google Security Ops 的取捨

最短判讀路徑

判斷 Splunk deployment 是否健康、最少看四件事：

• 誰能改 correlation rule：Splunk admin / ES admin / KV store admin 的人數、SPL search 跟 saved search 是否走版控（Git → git-fusion / Splunk Cloud Versioned Configs）、rule change 是否經 PR review
• Ingestion 治理：哪些 source 進 Splunk（IdP audit log / cloud control plane log / endpoint log / network log / app log）、是否有 log priority tier（critical / standard / archive）、Cribl Stream 是否在前面做 pre-filter / routing
• Detection content coverage：Splunk Security Content（公開 YAML rule library）有多少 enabled、是否跟 MITRE ATT&CK 對照、自家 custom rule 是否補 organization-specific anti-pattern
• Alert quality / SOC handoff：alert volume per day、SOC analyst triage time、false positive rate、alert 是否進 SOAR playbook 自動處理低風險、跟 8 incident response 的 routing 是否定義

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Ingestion architecture：log 進 Splunk 三種路徑 — Universal Forwarder / Heavy Forwarder（agent-based，自管 host）、HTTP Event Collector (HEC)（push log via HTTP endpoint、SaaS / serverless workload 預設）、Splunk Add-on for 各 cloud / SaaS（cloud-native log pull）。production 通常混用：endpoint 用 Universal Forwarder、cloud control plane 用 Add-on（AWS / GCP / Azure / Okta）、自家 app 用 HEC。在前面接 Cribl Stream 做 routing / filtering / sampling 是大型 deployment 的標準補位。

SPL（Search Processing Language）：類 Unix pipe 的 | 串接（index=ids sourcetype=auth | stats count by user | where count > 100）、表達力強但學習曲線陡。SPL 是 first-class concept、不只是查詢工具 — saved search 變 correlation rule、scheduled search 變 alert、accelerated search 變 data model 加速。SPL 寫得好不好直接決定 偵測規則品質 + 查詢成本。

Correlation rule / Notable Event：ES app 把 high-confidence finding 轉成 Notable Event、進 Incident Review queue。Correlation rule 的反例是 single-event alert（看到一個 SSH brute force attempt 就 alert、SOC analyst 一天看 10000 個沒意義）— production rule 應該是 time-bounded aggregation（過去 5min 內 100 個 brute force from same IP）+ cross-source correlation（brute force IP 同時出現在 cloud control plane access）。

Detection content lifecycle：Splunk Security Content 是 Splunk 維護的 OSS detection rule library、YAML format、跟 MITRE ATT&CK 對應。組織通常 先 import 全部 baseline、再選擇性 disable noisy 規則 + 新增 organization-specific 規則。Rule change 走 PR review、staging tenant 跑 24-48hr 觀察 false positive curve 才 promote 到 production。對應 Detection Engineering Lifecycle 的章節原則。

Risk-Based Alerting (RBA)：ES app 7.0+ 引入、給每個 user / asset 累積 risk score（取代逐 finding alert）、累積到 threshold 才 alert。處理 alert fatigue 的工程化做法：5 個 low-confidence signal 加總超過 threshold 比單一 high-confidence alert 更接近真實 attack pattern。對應 Alert Fatigue and Signal Quality。

SOAR integration：Splunk SOAR（前 Phantom）接 alert + playbook 自動執行 — 例如 leaked credential 自動 rotate（拉 Vault API）、suspect IP 自動加 firewall block（拉 Cloudflare WAF custom rule）、suspect user 自動 force MFA re-enroll（拉 Okta API）。playbook 進版控、定期 dry-run、不能黑箱 production fire-and-forget。

Ingestion pricing 治理：Splunk 按 ingestion volume（GB/day）計費、TB-scale deployment 年費千萬美元級別。實務治理：tier 1 log（IdP / cloud control plane / payment processor / DB audit）進 Splunk hot index、tier 2 log（app log / web access log）按 sampling / filtering 進 Splunk、tier 3 log（debug / verbose）走 SmartStore 到 S3 / GCS 冷儲存、或繞過 Splunk 直接打到 Elastic / data lake。Cribl Stream 在 forwarder 前 pre-filter 是業界標準作法、可省 30-50% ingestion cost。

SmartStore 跟冷熱分離：SmartStore 把 indexer 的 warm + cold bucket 放到 S3 / Azure Blob / GCS、indexer 只保留 hot data + cache。意義是 retention 從幾個月延長到幾年但 cost 不線性漲。production deployment 幾乎都該開、不開等於每年砸錢買 EBS。

核心取捨表

選 Splunk 的核心訴求：Enterprise scale + 跨 on-prem + detection content 跟 SOC tooling ecosystem 成熟、且能投入預算（千萬美元級別 license + Cribl pre-filter + SmartStore 冷儲存治理）+ 有 SOC team 維護 correlation rule 跟 SOAR playbook。中等規模 cloud-native 直接走 Datadog / Google Security Ops 更划算。

進階主題

Enterprise Security app 的 Risk-Based Alerting：RBA 把「事件 → alert」改成「事件 → risk score → 累積 → alert」、是 alert fatigue 的工程化解法。實作要決定 risk decay window（多久後 risk score 衰減）、risk attribution（同一台 EC2 上多 user 的 risk 怎麼分）、per-asset vs per-user threshold。配對 Uber 2022 MFA Fatigue 的 lesson：單一 MFA fail 不該 alert、5min 內 50 個 fail + 新裝置 + 異常地理就是 high risk。

Common Information Model (CIM) + Data Model：Splunk CIM 把不同 source 的欄位 normalize 到統一 schema（authentication / network_traffic / web 等 data model）。意義是 SPL 跨 source 寫一次、不用為 Okta log / Azure AD log / CrowdStrike log 各寫一份。CIM 配合 Add-on 自動 mapping、organization 寫 custom source 需要自己定 CIM mapping。

Multi-tenant deployment：MSSP / 大型集團多 BU 共用一個 Splunk 部署、用 index（隔離 data）+ role / capability（隔離 access）+ App（隔離 dashboard / search）三層。注意 Splunk admin 在跨 tenant 場景是高權限角色、應該走 break-glass 流程 + audit。

Cisco 整合（2024+）：Cisco 收購後 Splunk 跟 Cisco XDR / Talos threat intel / Cisco Secure Endpoint 整合加速。對 Cisco-heavy 環境是 ecosystem 一致性增加；對非 Cisco 環境暫時影響有限、但長期 roadmap 會有 Cisco-specific 加值。

排錯與失敗快速判讀

• Alert volume 爆炸 / SOC 看不完：correlation rule 寫成 single-event alert、或 false positive baseline 沒調 — 用 RBA 改 risk-based、staging tenant 跑 48hr 觀察再 promote
• Detection coverage 出事故時才發現缺：critical log source 沒進 Splunk（為了省錢）— 補回 tier 1 log priority、用 Cribl Stream 對 tier 2 / 3 做 sampling 而非整批不 ingest
• Ingestion cost 暴衝：新 source 加入沒 review、debug log 直接打進 Splunk — Cribl Stream 前置 + license usage dashboard alert + indexer ingestion quota
• SPL search 慢 / 卡 search head：full-fidelity search on 1TB raw event、沒用 data model acceleration — 改用 accelerated data model、限定 time range、用 tstats 而非 stats
• Correlation rule false positive 多：rule 寫得太寬、env-specific noise 沒 tune — staging tenant 跑 1 週統計 FP、tune threshold、加 lookup table 排除已知合法 source
• SOAR playbook 黑箱 fire-and-forget：自動 disable account 結果誤殺 CEO — playbook 走 approval gate for high-impact action、defaults to containment not deletion
• Splunk admin 太多 / 沒 break-glass：日常運維用 admin token、admin compromise blast radius 太大 — 收 admin 角色、改 power user + 特定 capability、break-glass 走 Vault

何時改走其他服務

不在本頁內的主題

• SPL 完整語法 reference、saved search 跟 macro 進階用法
• Splunk Cloud Platform vs Splunk Enterprise 的功能對照細節
• Splunk Observability Cloud（前 SignalFx 收購、跟 Datadog 直接競爭、屬 observability 不屬 security）
• ITSI（IT Service Intelligence）— 屬 ITSM / observability、不在資安範圍
• SOAR playbook 的具體實作（Phantom Python SDK）

案例回寫

Splunk 在 07 案例庫沒有直接 vendor-level 事件、但所有 detection-related case 都是 SIEM 偵測覆蓋率的對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Elastic Security、Datadog Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Splunk）
• 跨類：Okta（IdP log source）、HashiCorp Vault（SOAR playbook 拉 API）、Cloudflare WAF（WAF log + auto-block）
• 跨模組：8 事故處理 vendor 清單（Notable Event → IR routing）、4 observability（log pipeline 共用）
• 官方：Splunk Documentation

概念位置

它位在模型層與安全治理交界，跟 model card 不同：model card 提供 metadata，supply-chain trust 判斷來源、hash、量化流程、namespace 與散發路徑是否可信。

可觀察訊號與例子

官方 organization、知名量化者、verified registry、可比對 hash、清楚 license 與 model card 都提升信任；個人上傳、來源不明、檔案被替換、缺 metadata 都降低信任。GGUF、Safetensors、Ollama registry、Hugging Face Hub 都在這條鏈上。

設計責任

下載模型前確認來源；下載後記錄 SHA-256、檔案大小與版本；第三方量化要看量化者信譽與社群採用。MCP server 與 plugin 是另一條可執行程式碼供應鏈，要用更高權限標準判讀。

概念位置

它建立在 tool use、MCP 與 sandbox 之上。核心不是模型是否「想」執行，而是執行該 tool 的 process 是否有權限、是否有 allowlist、是否需要 approval。

可觀察訊號與例子

Read-only file search 可以自動；修改檔案要 checkpoint；刪除資料、push、部署、發送外部訊息通常要 step-by-step approval。第三方 MCP server 如果能讀整個 home directory，風險高於只讀 workspace 的 server。

設計責任

先把工具分成 read、local write、external side effect、irreversible operation，再配置 sandbox、allowlist、confirmation、audit log 與 rollback。高風險工具的預設應是人類批准，而不是 prompt 裡要求模型小心。

讀完本章後、你應該能對自己用的模型回答：來源是不是作者本人 / 官方鏡像、檔案完整性怎麼驗、量化版本是不是社群常用的、第三方再上傳的版本該不該用。

本章目標

1. 認識本地 LLM 模型供應鏈的角色：原始作者 → 官方 release → 第三方量化 → registry 散發。
2. 知道個人 dev 場景的信任邊界跟驗證手段。
3. 區分「官方版本」、「社群熱門量化」、「個人上傳」三種來源的信任等級。
4. 用 GGUF 檔案完整性檢查（hash、檔案大小、metadata）建立基本驗證流程。
5. 認識 Ollama / Hugging Face / LM Studio model browser 的供應鏈差異。

本地 LLM 模型供應鏈的角色鏈

1原始作者（如 Meta、Google、Qwen 團隊）
2  ↓ 發布原始權重（safetensors / pt、通常 fp16 或 bf16）
3官方 Hugging Face organization
4  ↓ 第三方量化者（如 bartowski、TheBloke、unsloth）
5量化版本 GGUF（Q4_K_M、Q5_K_M 等）
6  ↓ Ollama 收進 registry 或社群上傳
7Ollama registry / LM Studio 內建瀏覽器
8  ↓ 使用者拉下來
9本機 GGUF 檔案

每一層都是潛在的信任邊界：

1. 原始作者：信任假設是「作者發布的權重就是訓練出來的權重、沒被植入後門」。個人 dev 場景下、選主流作者（Meta、Google、Qwen、Mistral 等）的官方發布通常是合理起點。
2. 量化者：把官方 fp16 權重壓成 Q4 / Q5 等 GGUF 格式的人。社群常見熱門量化者（如 bartowski、unsloth）有公開的量化腳本與長期信譽、但仍是個人或小團隊、不是企業簽章。
3. registry 散發：Ollama registry、HF Hub、LM Studio 內建瀏覽器是分發層。可能被搶 namespace、可能有人偽造「官方」名義上傳。
4. 本機儲存：下載完的 GGUF 檔案在硬碟、後續執行時權重本身就是程式邏輯的一部分（透過 inference 影響輸出）。

事實查核註：上面的角色鏈是 2026 年 5 月的常見運作模式。具體量化者、registry 政策、模型分發流程依平台變化、建議引用前以 Hugging Face、Ollama、LM Studio 各自的安全公告與 community guidelines 為準。

三種來源的信任等級

個人 dev 場景下、常見的模型來源可以分成三個信任等級：

「中等」跟「較高」的差別主要在「企業簽章」這個維度——Hugging Face verified organization 對應「該組織確實是 Meta / Google / Qwen 等主體」、但不對「該組織內部 release process 是否安全」做擔保。即使是官方發布、仍是「人類團隊發布的權重」、不是密碼學意義的零信任。

GGUF 檔案完整性的基本檢查

下載完 GGUF 檔案後、可以做幾個輕量檢查確認檔案完整性：

 1# 1. 比對檔案 SHA-256（HF / Ollama 通常會列出官方 hash）
 2shasum -a 256 ~/.ollama/models/blobs/sha256-xxx
 3# 或
 4sha256sum Qwen3-30B-A3B-Q4_K_M.gguf
 5
 6# 2. 看檔案大小是否跟 model card 標示一致
 7ls -la Qwen3-30B-A3B-Q4_K_M.gguf
 8
 9# 3. 用 llama.cpp 的工具看 GGUF metadata
10./gguf-dump.py Qwen3-30B-A3B-Q4_K_M.gguf | head -50
11# 確認 architecture、context_length、量化等級跟預期一致

這些檢查能擋住：

1. 下載中斷導致檔案不完整：hash 不對、跑不起來、不是安全議題但會誤導判讀。
2. CDN / 鏡像中間人替換：理論可能、實務上 Hugging Face 跟 Ollama 走 HTTPS、TLS 完整性是基礎防護；hash 比對是額外確認。
3. 誤拉到不同量化版本：例如想拉 Q4_K_M 結果拉到 Q4_0、檔案大小跟 metadata 會反映出來。

擋不住：

1. 量化者本身在量化過程做了手腳：hash 對得上、但權重已經被改過。這需要回到原始作者的權重重新量化、屬於進階驗證、個人 dev 場景通常不做。
2. 作者本身在發布的權重裡植入後門：個人 dev 場景的 threat model 假設主流作者不會做這件事；若不信任、不應該用該模型。

事實查核註：GGUF 檔案的完整性檢查工具跟流程依 llama.cpp 版本變化、gguf-dump.py 等腳本路徑可能改名或棄用、以實際 llama.cpp release 跟 GGUF 規格 為準。

Ollama / Hugging Face / LM Studio 的供應鏈差異

三個 registry 在實際拉模型的操作面（namespace、download 指令、本機儲存路徑）見對應安裝章節：1.0 Ollama、1.1 LM Studio、PC 場景的 LM Studio 見 5.4。本節聚焦三者在供應鏈管理上的相對位置：

實務上、社群常見的選擇路徑：

• 想拉 official 模型：優先 Hugging Face official organization、或 Ollama library/ namespace
• 想拉熱門量化：bartowski / unsloth 等知名量化者的 HF repo、Ollama 通常也會把熱門模型收進 official library
• 看到個人 repo 上傳的「特別優化版」：除非有明確來源說明、否則保守看待

量化版本污染的可能性

量化版本污染的具體威脅形態：

1. 量化腳本被改過：量化者公開的腳本跟實際跑的腳本不一致、產出的權重跟「按公開腳本量化」會不同。
2. 量化過程引入後門：在量化的同時微調權重、在特定 prompt 下觸發特定行為。技術上可行、實務上社群罕見公開案例、但無法事前完全排除。
3. 量化版本被替換上傳：先上傳乾淨版本累積下載量、再替換成有問題的版本。HF / Ollama 都有 file history、但個人 dev 通常不會檢查。

個人 dev 場景的合理應對：

1. 優先用知名量化者的版本：bartowski / unsloth 等有長期紀錄的量化者、相對個人首次上傳信任度較高。
2. 下載後立刻記錄 hash：作為日後比對基準；若日後同一 model name 但 hash 變了、值得查 history。
3. 大型 codebase 任務前先用簡單 prompt 試模型：例如「fn main() { println!("hi"); }」這類；確認模型行為基本合理、再用於真實任務。

第三方 plugin / MCP server 的供應鏈

模型本身的供應鏈之外、Continue.dev / MCP server / Ollama plugin 等也構成供應鏈、且風險形態不同：

1. MCP server 多為可執行程式碼：安裝 MCP server 等於在本機跑第三方程式碼、權限影響大於 GGUF 檔案（GGUF 只在 inference 時影響輸出、MCP server 可以直接讀寫檔案、呼叫 shell）。
2. Continue.dev 擴充套件：VS Code marketplace 有基本審查、但 community-published 擴充套件的供應鏈仍是個人視角。Continue.dev 安裝與 multi-provider 配置見 1.3。
3. Ollama Modelfile 中的指令：Modelfile 內可以指定 template、system prompt 等、若使用社群分享的 Modelfile、要看完內容再用。

MCP server 的權限模型詳見 6.2 tool use 與 MCP server 的權限模型。

事實查核註：MCP（Model Context Protocol）的安全模型仍在演進、各 MCP server 實作的權限粒度、認證機制依版本變化、建議引用前以 MCP 官方文件 跟具體 MCP server 的 README 為準。

給讀者的判讀流程

實際下載 / 切換模型時的判讀流程：

1. 確認來源 organization / namespace：是 official、知名量化者、還是個人上傳。
2. 比對檔案完整性：對主流量化等級、HF / Ollama 通常提供 hash；下載完做一次 hash 比對。
3. 記錄 hash 到本機 inventory：建一份 ~/models/inventory.md、記錄每個 GGUF 的來源 URL、下載日期、SHA-256。
4. 試模型基本行為：用簡單 prompt 確認模型行為合理。
5. 若是新 MCP server：分開判讀供應鏈（看 6.2）、不要把 GGUF 跟 MCP 的信任邊界混在一起。

下一章

下一章：6.1 推論伺服器的綁定與暴露範圍、處理伺服器跑起來後的第一個對外接觸面。

概念位置

三層典型 bind address 的暴露範圍：

關鍵差異：

1. 127.0.0.1 只接 loopback、無論其他網路介面狀態都不接外部請求。
2. 0.0.0.0 在所有介面上監聽、若機器有 public IP 或在公開 Wi-Fi、就會被網路上其他人連到。
3. 具體 LAN IP 是中間地帶、限定來源到該介面的網段。

檢查當前 bind 狀態的指令：

1# macOS / Linux
2lsof -i -P -n | grep LISTEN | grep <port>
3
4# Linux
5ss -lntp | grep <port>
6
7# 或
8netstat -an | grep LISTEN | grep <port>

看到 127.0.0.1:<port> 是 loopback、*:<port> 或 0.0.0.0:<port> 是所有介面。

設計責任

理解 bind address 後可以解釋兩個現象：為什麼預設安全的伺服器都 bind 到 127.0.0.1（避免不小心暴露）、為什麼 Docker -p 8080:8080 預設 bind 到 0.0.0.0（容器化的便利性、但對個人 dev 是潛在暴露點）。

設計本地推論伺服器時、預設 loopback、想分享 LAN 時 bind 到具體 LAN IP（不要直接 0.0.0.0）、要對外時加 reverse proxy + auth + TLS。詳見 6.1 推論伺服器的綁定與暴露範圍 跟 7.3 入口治理與伺服器防護。

概念位置

2025 版的 10 項（簡述）：

跟模組六的 mapping

設計責任

讀企業 LLM 安全 / 合規文件 / vendor security audit 看到「OWASP LLM Top 10」就是這 framing。寫 code 場景的判讀：

1. 跟企業溝通必備：安全 team / vendor audit 都用 OWASP 編號、能 map 自己應用到 LLM01-LLM10 就能 align 對話
2. 不是 production 才需要看：個人 dev 也適用大部分（LLM01 prompt injection、LLM03 supply chain、LLM06 excessive agency 對個人都直接相關）
3. 跟 6.6 OWASP 對照章節 的關係：本卡是定義 + mapping、章節是詳細 mapping + 個人 dev 場景的對應 control

概念位置

Prompt injection 的兩種主要形態：

Indirect injection 的常見入口：

1. 檔案內容：codebase 中的 README、依賴的 package README、PDF / Word 文件
2. Web 內容：tool 抓的網頁、社群留言、PR 描述
3. tool 回傳結果：DB 查詢結果、API response、其他 service 回傳
4. 使用者貼上內容：從外部複製貼上、帶進惡意 prompt
5. agent 自我循環中累積：sub-agent 回傳、長 agent loop 中前段 injection 影響後段

事實查核註：prompt injection 的攻擊形態跟研究進展快速演進、本卡描述參考 OWASP LLM Top 10 LLM01 跟 Greshake et al. 的「Indirect Prompt Injection」論文、引用前以對應的最新版本為準。

實際造成影響的不是 injection 本身、是 LLM 輸出後的下游動作：

1injection → LLM 輸出 → 下游動作（這裡才是真正攻擊面）
2                       ├── 使用者照建議貼到 shell 跑
3                       ├── tool use 自動執行
4                       ├── 寫進 commit / 文件
5                       └── 觸發下一個 agent

設計責任

理解 prompt injection 後可以解釋兩個現象：為什麼「擋住 injection」對 production LLM application 是不切實際的目標（外部內容會持續引入）、為什麼防禦重點應該放在「下游動作的可逆性 + review checkpoint」（injection 不可完全擋住、但後果可以收斂）。

防禦設計的層次：

1. 降低觸發率：明確標記 untrusted 內容、強化模型對齊（vendor 端責任）。
2. 限制能力上限：tool use 白名單、副作用可逆性、agent loop 步數限制。
3. 後果可控：人為 review checkpoint、自動偵測異常（見 LLM Service 偵測訊號覆蓋）。

詳見 6.3 IDE 場景的 prompt injection 跟 LLM Agent Prompt Injection 後果治理。

概念位置

常見的 sandbox 技術光譜（依隔離強度跟工程成本）：

Sandbox 在 LLM 場景的常見配置：

1. 個人 dev：用獨立 OS user 跑 MCP server、限制檔案存取到 workspace；或用 Docker。
2. production agent：每個 user / session 一個 ephemeral container、跑完就 destroy。
3. code execution tool：把 LLM 生成的 code 丟進 sandbox 跑（如 OpenAI Code Interpreter、Anthropic Claude Code Tool）。

設計責任

理解 sandbox 後可以解釋兩個現象：為什麼跑第三方 MCP server 前 sandbox 是基本配置（MCP 是可執行程式碼、權限上限是「跑該 server 的 user 的權限」）、為什麼 production 場景的 code execution tool 必定在 ephemeral sandbox 內跑（避免長期 state 跟跨 user 殘留）。

設計 LLM application 時、sandbox 跟 tool use 的白名單是兩個獨立的防護層、建議都做：白名單擋已知範圍、sandbox 擋未預期的副作用。詳見 6.2 tool use 與 MCP server 的權限模型。

觀察

Cloudflare 在 2026-01-22 發生 route leak，成因是自動化路由政策配置錯誤，導致流量擁塞與延遲提升。

判讀

控制面自動化帶來速度，也提高錯誤一次性放大的風險。關鍵是補強變更守門與回復策略，停止自動化會退回更差的狀態。

策略

1. 路由政策變更要有 pre-check 與 blast radius 評估。
2. 建立快速撤回機制與明確責任路由。
3. 把同類事件寫入 tripwire，觸發強制重評估。

下一步路由

回 7.14 governance exception/tripwire 與 8.3 containment/recovery。

引用源

• Cloudflare route leak incident (2026-01-23)

IAM 的心智模型

IAM（Identity and Access Management）是雲端平台用來回答「某個身分能不能對某個資源做某件事」的授權系統。它把授權拆成三個獨立的零件：identity（身分，發起動作的主體）、policy（政策，描述「允許/拒絕對哪些資源做哪些動作」的規則）、role（角色，一組可以被臨時取得的權限集合）。理解這三者的分工，是後面所有憑證決策的前提。

identity 分兩類，這個區分在後面設計權限邊界時會反覆用到。一類是 user，代表一個長期存在的主體，通常對應到一個真人或一個固定的服務帳號，本身可以持有長期憑證。另一類是 role，代表一組權限的暫時授予 — 沒有自己的長期密碼，而是讓某個被信任的身分「假扮（assume）」成它、換取一段有時效的臨時憑證。policy 則是貼在 user 或 role 上的規則文件，列出 Action（能做什麼，如 s3:GetObject）、Resource（對哪個資源）、Effect（允許或拒絕）。

最小權限（least privilege）是貫穿這套系統的設計原則：一個身分只應該拿到完成它本職工作所需的最小權限集合，多一個 action、多一個 resource 都是攻擊面。最小權限是持續收斂的過程，而非一次設定就結束的靜態狀態 — 服務初期常為了快速上線給寬鬆權限，之後要靠 access analyzer 這類工具觀察「實際用到哪些 action」，再把沒用到的權限收掉。判讀訊號很直接：如果一個 CI role 的 policy 裡有 *:* 或 AdministratorAccess，它就是下一個 incident 的入口。

1# 最小權限：CI 只能讀寫特定 bucket、不給整個 S3
2data "aws_iam_policy_document" "ci_artifacts" {
3  statement {
4    actions   = ["s3:GetObject", "s3:PutObject"]
5    resources = ["arn:aws:s3:::myapp-artifacts/*"]
6  }
7}

長期 access key 的風險

長期 access key 是一組沒有到期時間的靜態憑證（access key ID + secret），任何持有它的人或程式都能以對應身分的全部權限呼叫 API，直到有人手動撤銷為止。它最大的問題是「沒有時效」這個性質本身，會在三個方向上累積風險，而且風險隨團隊規模與時間單調上升。

第一是散落。長期 key 為了被程式使用，會被複製進 .env 檔、CI 設定、本機 ~/.aws/credentials、Slack 訊息、甚至誤推進 git 歷史。每多一個副本就多一個外洩點，而你很難盤點清楚一把 key 到底被貼進了多少地方。第二是權限過大。因為輪替麻煩，團隊傾向給一把 key 配足夠寬的權限「一次搞定」，於是一把本來只該讀 artifact 的 key 同時握有刪除 production 資料庫的能力。第三是難以輪替。輪替一把長期 key 意味著找出所有副本、同步替換、確認沒有遺漏，這個成本高到讓多數團隊選擇拖延，於是 key 的有效期變成「無限」，外洩後的曝險窗口也跟著變成無限。

判讀訊號是：如果你無法在五分鐘內回答「這把 key 被用在哪些地方、上次輪替是什麼時候」，它就已經是技術債。早期新創特別容易踩這個坑 — 一個工程師為了讓部署腳本跑起來，在筆電上建了一把 admin key，半年後這把 key 還在 CI 環境變數裡，建立它的人已經離職。這類事故的代價不在於「key 外洩」這個事件本身，而在於外洩之後你沒有任何手段限制爆炸半徑。

OIDC：給 CI/CD 的短期憑證

OIDC（OpenID Connect）聯合讓 CI/CD 平台用一段每次執行才簽發、幾分鐘後就失效的短期憑證取代長期 key，從根本上消掉「靜態密鑰散落」這個問題。它的運作方式是建立信任關係：雲端帳號信任某個外部 identity provider（如 GitHub Actions、GitLab CI 的 OIDC issuer），當管線執行時，CI 平台簽發一個帶有可驗證 claim 的 token（描述「這是哪個 repo、哪個 branch、哪個 workflow 在跑」），雲端用這個 token 換出一段臨時憑證。沒有任何長期 secret 需要被儲存在 CI 設定裡。

關鍵設計在 role 的 trust policy（信任政策）上 — 它規定「哪個外部身分被允許假扮成這個 role」。trust policy 要用 token 的 claim 把假扮條件收到最緊：限定 issuer、限定 audience、限定特定 repo 與 branch。收得太鬆（例如只驗 issuer、不驗 repo）等於任何掛在同一個 CI 平台的專案都能假扮你的 role，這是常見的設定陷阱。

 1# OIDC trust policy：只允許特定 repo 的 main branch 假扮此 role
 2data "aws_iam_policy_document" "ci_trust" {
 3  statement {
 4    actions = ["sts:AssumeRoleWithWebIdentity"]
 5    principals {
 6      type        = "Federated"
 7      identifiers = [aws_iam_openid_connect_provider.github.arn]
 8    }
 9    condition {
10      test     = "StringEquals"
11      variable = "token.actions.githubusercontent.com:aud"
12      values   = ["sts.amazonaws.com"]
13    }
14    condition {
15      test     = "StringLike"
16      variable = "token.actions.githubusercontent.com:sub"
17      values   = ["repo:my-org/my-app:ref:refs/heads/main"]
18    }
19  }
20}

這一章只把 role 與 trust policy 設計好，OIDC 的實際回報要到模組七：infra 走 PR 流程建管線時才兌現 — 屆時管線用這裡定義好的 role 取得短期權限執行 plan 與 apply，CI 環境裡不需要存任何 access key。下一步路由很明確：role 與最小權限的 policy 屬於這裡的地基，管線怎麼觸發、怎麼卡 review 屬於模組七。

權限邊界設計

權限邊界是把不同類型的身分與不同環境之間的權限刻意隔開，讓任何一個身分被攻破時，爆炸半徑都被限制在它本職的範圍內。邊界設計有兩條軸線需要分別處理：人 vs 機器，以及環境之間。

人 vs 機器的邊界，源自兩者的存取模式根本不同。人類身分需要互動式登入、應該強制 MFA、權限隨職責變動，且通常透過 SSO 集中管理而非各自持有 key。機器身分（CI、跑在運算資源上的服務）需要的是程式化、無人值守的存取，應該用 role 假扮取得短期憑證，永遠不該配長期 key。機器身分還要再分跑在哪裡：跑在雲上的 workload（運算實例、容器任務）由平台直接把 role 綁在執行環境上 — AWS 用 instance profile 把 role 掛在 EC2 instance、用 ECS task role 把 role 掛在容器任務，workload 從實例 metadata 自動取得輪替的短期憑證，這是早於 OIDC 就存在的標準解；只有跑在雲外的 CI/CD（如 GitHub Actions）拿不到實例 metadata，才需要前面那套 OIDC 信任關係換憑證。把這兩類混在同一個身分上，會讓你既無法對人強制 MFA，也無法對機器收斂權限。一個常見陷阱是工程師用自己的個人 key 跑自動化腳本 — 這把人的廣泛權限直接送進了無人值守的執行環境。

環境之間的邊界，目的是讓 production 的權限與 staging、dev 完全不交叉，避免一次誤操作或一個被攻破的低敏感環境波及到核心資產。實作上常見的做法是每個環境用獨立的帳號（account）或獨立的 role，部署到 production 的身分拿不到 staging 的資源、反之亦然。這條邊界在 AWS 上有兩層具體機制可以落地：帳號級的護欄用 Organizations 把環境拆成獨立帳號，再用 SCP（Service Control Policy）對整個帳號或組織單位設定權限天花板，連帳號內的管理員都越不過去；role 級的護欄用 Permissions Boundary 這個 IAM 字面功能，給單一 role 設一個權限上限，限制它「最多能拿到什麼」，即使有人後來給它貼了過寬的 policy 也會被天花板擋住。前者收的是帳號與組織的整體範圍，後者收的是單一身分的上限，兩者疊起來才讓「權限邊界」從概念變成擋得住誤設的具體工具。判讀訊號是：如果一個 dev 環境的 CI role 能列出或刪除 production 的資源，邊界就沒有真正建立。環境隔離的更完整實作（帳號結構、模組化參數）會在模組四：環境分離與模組化展開，這裡先確保身分層的權限不跨環境。

這一章談的是身分與憑證 — 誰是誰、怎麼證明、能動什麼。憑證背後引用的應用層 secret（資料庫密碼、第三方 API key）怎麼安全儲存與注入，屬於模組八：治理好習慣的 secret management 範圍，不在這裡處理。兩者的交集是：身分層決定「誰能讀到 secret store」，secret 層決定「secret 怎麼存與輪替」。

章節文章

跨分類引用

• → 模組三：網路地基：身分備妥後，劃清服務之間的網路邊界
• → backend 模組七：資安與資料保護：Secret Management 與這裡的憑證管理交集
• → 模組七：infra 走 PR 流程：CI/CD 用 OIDC 取得短期權限
• → 接手維運：接手時的 credential 盤點與輪替

概念位置

Redaction 位在 SDK 端的事件產生和 collector 端的事件接收之間。它是監控資料安全的第一道防線 — 在資料離開使用者裝置之前處理，比 collector 端的 access control 更早介入。Redaction 和 transport 加密（HTTPS）互補：redaction 保護欄位內容，transport 加密保護傳輸過程。

可觀察訊號與例子

系統需要 redaction 的訊號是監控事件的 data 欄位可能包含使用者輸入。CLI 輸入可能含密碼（mysql -p'secret'）、API key（Authorization: Bearer sk-...）、連線字串（含帳密的 URL）。IME 個人化學習也是洩漏面 — 輸入框的內容被 IME 學習後跨 app 可見。

設計責任

Redaction 要定義預設規則（哪些欄位名稱自動 redact）、自訂 pattern（正則表達式比對敏感值）、執行時機（event 進入 buffer 前還是 flush 時）、以及 redaction 失敗的處理（丟棄整筆事件 vs 只移除敏感欄位）。

同區網也要加密的理由

自用工具的 SDK 和 collector 通常在同一台機器或同一個區域網路（LAN / Tailscale tailnet）。常見的假設是「同區網不需要加密，因為只有我自己在用」。

這個假設在以下情境不成立：

共用網路：咖啡廳、共享辦公室、飯店 WiFi — 同一個 AP 下的其他裝置可以用 ARP spoofing 或 WiFi sniffing 攔截未加密的 HTTP 流量。

未來的網路拓撲變更：目前在同一台機器上的 SDK 和 collector，可能之後拆到不同的機器或不同的網路段。如果一開始就用 HTTPS，拓撲變更不需要額外的安全調整。

養成正確習慣：在自用工具上用 HTTP 是因為「反正只有我」，但相同的開發者在商業專案中可能延續這個習慣。從自用工具開始就用 HTTPS，讓加密傳輸成為預設行為。

HTTPS 設定

自簽憑證

自用工具和內部服務用自簽憑證（self-signed certificate）就足夠。不需要購買 CA 憑證 — 自簽憑證提供加密（防竊聽）和完整性（防篡改），只是不提供身份驗證（client 無法確認 server 是不是「官方的」）。在自用場景中 server 就是自己架的，身份驗證不是問題。

1openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Go collector 使用自簽憑證：

1http.ListenAndServeTLS(":8443", "cert.pem", "key.pem", handler)

SDK 端需要信任自簽憑證。開發期可以在 HTTP client 設定 badCertificateCallback 接受自簽憑證；production 應該把自簽憑證加入系統的信任清單。

Let’s Encrypt

如果 collector 有公開的 domain name，用 Let’s Encrypt 取得免費的 CA 憑證。自動續期、不需要手動管理。適合部署在 VPS 或雲端的 collector。

Basic Auth

HTTPS 保護傳輸層（防竊聽），basic auth 保護 endpoint 層（防未授權存取）。兩者互補，缺一不可 — basic auth 在 HTTP 上傳送的是 base64 編碼的帳密，沒有 HTTPS 的加密保護等於明文傳送。

1Authorization: Basic base64(username:password)

SDK 在每個 HTTP POST request 的 header 中帶上 basic auth。Collector 端驗證帳密，不匹配則回傳 401。

Basic auth 的帳密管理：

• 帳密存在 SDK 的設定檔或環境變數中，不硬編碼在程式碼裡
• Collector 端的帳密用 bcrypt hash 儲存，不存明文
• 定期輪替帳密（自用工具半年到一年一次即可）

API Key 替代方案

如果不需要 username/password 的雙因素，單一 API key 更簡單。

1X-API-Key: sk_monitor_abc123...

API key 的管理比 basic auth 簡單（一個字串而非帳密對），但安全性略低（只有一個 factor）。自用工具場景下 API key 通常足夠。

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Collector 端的 access control → Collector Access Control 實作
• Server-side 的 secret management → backend 07 資安

服務定位

Auth0 是 customer identity 的控制面、不是員工 SSO（員工走 Okta Workforce 或 AWS IAM Identity Center）。雖然 Auth0 於 2021 被 Okta 收購、目前屬「Customer Identity Cloud」產品線、跟 Workforce Okta 是 同公司不同 control plane：tenant 叢集、事件分布、signing key 託管路徑都分開、Okta Workforce 的事故（2022 Sitel、2023 support system HAR）並未直接打到 Auth0 customer。

跟自管 Keycloak 比、Auth0 把 Universal Login UI、social connection 預建、Rules / Action runtime、attack protection 都託管出去 — 代價是 SaaS 計費、token issuance / login attempt 都計量、流量大的 B2C 場景遇到 credential stuffing 不擋會吃成本。跟 AWS Cognito / Firebase Auth 比、Auth0 的核心優勢是 developer-first tenant 體驗 + 預建 social connection（Google / Facebook / Apple / Microsoft 等數十種）+ Action hook 寫 JS 客製。

本章目標

讀完本頁、讀者能判斷：

1. Auth0 該承擔哪一段 customer identity 控制（login flow / token broker / profile store / B2B Organizations）、哪一段該回到自己的 app
2. Auth0 tenant 的信任邊界與最低稽核需求（admin role、management API token、Action 程式碼、connection 設定）
3. Auth0 流量出事或母公司事件時的降級路徑（fallback connection、token rotation、anomaly throttle）
4. 何時用 Auth0、何時走 Cognito / Firebase Auth / Keycloak 的取捨

最短判讀路徑

判斷 Auth0 tenant 是否健康、最少看四件事：

• 誰能做什麼：Dashboard admin、Management API token 的 owner 與 scope、Action 是否走 code review、tenant 之間（dev / staging / prod）是否分離且授權獨立
• 憑證在哪裡：Management API token / M2M client 的 scope 與 TTL、社交 connection 的 client secret 存放位置、signing key（per-tenant）的 rotation 節奏、是否啟用 Custom Domain（避免 token issuer 暴露 *.auth0.com 域名）
• 入口如何暴露：登入走 Universal Login（託管 UI）還是 Embedded Login（嵌自家 app）、Cross-Origin Authentication 是否打開、Attack Protection（bot detection / brute-force / breached password / suspicious IP throttling）配置強度
• 證據是否可回查：Tenant Log 是否同步到 SIEM（Log Stream 推 HTTP / Datadog / Splunk）、登入失敗 / Action 例外 / Management API 變更是否 alert、保留期是否符合合規要求

四件事任一缺失、就是 Audit Log 與 Authentication 邊界的待補項目。

日常操作與決策形狀

Tenant 與環境分離：Auth0 的 tenant 是邏輯隔離的多租戶 SaaS、不是物理叢集。每個環境（dev / staging / prod）開獨立 tenant、避免 dev 的 Action bug 打到 prod 流量、避免共用 client secret 跨環境洩漏。tenant 間用 auth0-deploy-cli 同步配置、Action 程式碼進版控。

Connection 設計：Database Connection（Auth0 託管帳密 store）跟 Social / Enterprise Connection（OIDC / SAML federation 到 Google / Microsoft / Okta）是兩種來源。決策點是 user 是否要進 Auth0 profile store — 純 federation 不存密碼、純 Database Connection 是 Auth0 替 app 管帳密表。混用要清楚 primary identity 與 linked account 的合併規則。

Action / Rule hook 的風險：Action（新框架）跟 Rule（舊框架）讓 tenant admin 在 login pipeline 注入 JS 程式碼（pre / post login、M2M、send email 等）。這是 Auth0 強大但也是 最大的供應鏈攻擊面 — Action 可以 require() npm package、惡意 dependency 會在每個 login flow 執行。應該 pin dependency 版本、code review、用最小權限的 Management API scope、定期掃 dependency CVE（思維對齊 紅隊 supply chain 案例）。

Universal Login vs Embedded Login：Universal Login 把登入 UI 託管在 Auth0 domain（或 Custom Domain）、user 跳轉到該頁完成登入後 redirect 回 app — 防 phishing / CSRF 的成本由 Auth0 吃。Embedded Login 把登入表單嵌進自己 app 並用 /co/authenticate 端點 — 看似 UX 順、但要自己防 XSS、CSRF、CORS、credential leak、且要打開 Cross-Origin Authentication（暴露額外攻擊面）。預設選 Universal Login、Embedded 只在 UX 強需求且能承擔安全成本時開。

Management API token / M2M client：Management API 控制整個 tenant（建 user、改 client secret、改 Action 程式碼）。token 不該長期存在程式碼或 CI；改用 M2M Application（client credentials grant）拿短期 token、scope 收到最小（read:users ≠ update:users ≠ update:actions）、走 Secret Management 取用。

Attack Protection 配置：B2C 流量大、登入嘗試本身計費也是攻擊面。Brute-force Protection（單 IP 多失敗鎖 user）、Suspicious IP Throttling（單 IP 多失敗鎖 IP）、Breached Password Detection（已洩漏密碼禁用）、Bot Detection（CAPTCHA / risk score）四個機制都該打開、否則 credential stuffing 既吃成本也提高帳號被接管的機率。

Break-glass 與 fallback：B2C 場景沒有「員工備用 admin」概念、break-glass 是 確保使用者在 Auth0 暫不可用時仍能登入。常見作法：app 端容忍 Auth0 暫時失敗、提供 magic link / email OTP 的替代登入路徑（透過獨立 ESP）、或預先發放長 TTL 的 refresh token 撐過短時故障。tenant 管理面則維持至少 2 個獨立 admin、credential 離線存。

Audit / handoff：Tenant Log 透過 Log Stream 推 SIEM、alert 三類事件 — Management API 對 Action / Connection / Client 的變更（供應鏈）、登入異常突增（credential stuffing）、support impersonation / Auth0 員工 access tenant 的紀錄（control plane）。

核心取捨表

選 Auth0 的核心訴求：customer identity + 大量 social / enterprise connection + 要 developer 客製 login flow、且接受 SaaS 計費與第三方控制面風險、能投入 SIEM / Action 程式碼治理 / attack protection 配置。

Microsoft 生態（Entra External ID / 前 Azure AD B2C）是另一個 B2C / B2B 選項、本表沒列入主要競品 — 它在 M365 / Azure 重度組織內是合理選擇、但 social connection 預建廣度跟 developer-centric tenant 體驗仍不及 Auth0。M365 重度 + B2C 需求的組織可同時評估 Entra ID 的 External ID 產品線。

進階主題

Action / Rule 的供應鏈治理：Action 程式碼進版控、走 PR review、auth0-deploy-cli 部署。Action 引用的 npm dependency pin 版本、避免 ^ / ~、CI 跑 SCA 掃 CVE。新增 Action 時 default scope 給 read-only、需要寫操作另外升級。Action secret（OAuth credential、API key）走 Action Secret 管理、不寫死在程式碼。

B2B Organizations：Auth0 Organizations 把同 tenant 內的多客戶（B2B 場景）邏輯隔離 — 每個 organization 有自己的 connection、branding、member。設計點是 user 是 organization member 還是 tenant-wide user、跨 organization 操作的 admin 是否有 organization scope。Organization 之間的隔離是 tenant 內邏輯層、共享底層 control plane、不能等同實體 tenant 隔離。

Adaptive MFA / Step-up Authentication：Auth0 Adaptive MFA 用 device / location / behavioral signal 動態升級 MFA 要求（impossible travel、新裝置、低信任 IP）。屬付費 add-on、本質是把 risk-based 認證內建。對 B2C 場景比強制全 user MFA 友善、但要把 risk threshold 跟 false positive 容忍度 設清楚、避免合法 user 被連續挑戰流失。

Custom Domain：預設登入網域是 <tenant>.auth0.com、揭露使用 Auth0 與 tenant 名稱、且 issuer 是 Auth0 子網域。Custom Domain 把 issuer 改成自己網域（如 login.example.com）、user 看到的 URL 一致、降低 phishing 對照成本。屬付費功能、production app 預設應該開。

Cross-Origin Authentication 的攻擊面：Embedded Login 必須開 Cross-Origin Authentication、讓 app 域名直接呼叫 Auth0 的 /co/authenticate。風險是 XSS 拿到 token、CSRF 偽造登入、third-party cookie 政策變動讓 silent auth 壞掉。Universal Login 不需要這個、所以同樣風險不存在 — 這是 Universal Login 推薦的核心理由。

排錯與失敗快速判讀

• Management API token 散落 / 過權：CI / 後端服務各自存 token、scope 都給 update:users / update:actions — 改 M2M Application + 最小 scope、定期 rotate、用 Secret Management 集中取用
• Action 直接 require 未 pin 的 npm package：login flow 每次都拉最新版、惡意 dependency 直接執行 — pin 版本、code review、定期掃 CVE
• 登入嘗試暴增 / 計費突增：Attack Protection 沒開或門檻太鬆、credential stuffing 吃額度 — 打開 Bot Detection、Brute-force、Suspicious IP Throttling、配合 Anomaly Detection
• 使用 Embedded Login 又沒控 XSS：自家 app 一旦 XSS、token 直接被偷 — 改 Universal Login、或補上嚴格 CSP / DOM 防護、定期 pen test
• Tenant Log 沒進 SIEM：事件只在 Dashboard、無法跨系統 correlation — 配 Log Stream 打到 SIEM、特定事件接 alert runbook
• 沒 Custom Domain：phishing 對照成本低、issuer 暴露 vendor — 配 Custom Domain、TLS cert 自管或走 Auth0 託管
• B2B Organizations 缺 scope 限制：admin 工具沒按 organization scope、單一 admin compromise 跨 organization 擴散 — 思維對齊 Okta Cross-Tenant 2023 的 lesson

何時改走其他服務

不在本頁內的主題

• Auth0 完整 OIDC / OAuth2 規格細節
• Action / Rule 完整 API 與 trigger 清單
• B2B Organizations 完整 schema 與 SDK 整合教學
• Auth0 定價層級的詳細功能對照
• 各 social connection provider 的 OAuth app 註冊步驟

案例回寫

Auth0 在 07 沒有直接案例（母公司 Okta 的事件並未直接打到 Auth0 customer），以下案例採對照引用、抽取對 Auth0 customer 的 lesson。要注意的是 缺直接案例不等於 vendor 沒有風險 — Auth0 自 2021 被 Okta 收購以來未公開重大 vendor 級事件、但同類 SaaS IdP 的歷史事件（Okta 集團、signing key 託管、credential stuffing）都是 Auth0 customer 的可預期風險面、不該等到第一次出事才補控制：

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor、Keycloak vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM（Auth0 認證後的 cloud resource 權限層）
• 跨模組：8 事故處理 vendor 清單（Auth0 異常如何 routing 進 IR 流程）
• 官方：Auth0 Documentation

服務定位

Secrets Manager 的定位是 AWS-only workload 的 static secret 控制面、跟 SSM Parameter Store SecureString 在 存 secret 這層功能重疊、但設計目的不同。Parameter Store 是 parameter 管理（free tier、advanced parameter 每 10000 個約 $0.05、KMS 加密但無 staging label 與 rotation Lambda）；Secrets Manager 是 secret 管理（每個 secret per month $0.40 + API call、有 staging label / rotation Lambda / Resource Policy / Cross-Region Replica）。價差 8 倍以上、選擇基準在 是否需要 rotation 跟 cross-account sharing。

跟 Vault 比、Secrets Manager 是 單一雲、簡單、低運維、Vault 是 跨雲、dynamic credential、高表達力。AWS-only 組織用 Vault 等於多扛一個 HA cluster 運維成本只為了拿 KV engine 跟 RDS rotation、ROI 不划算；反向跨雲組織用 Secrets Manager 等於每個雲都自己一套 secret store、治理鏈會斷。跟 Google Secret Manager / Azure Key Vault 比、設計理念類似（雲廠 managed、KMS 加密、IAM 授權）但 rotation 機制各家不同 — Secrets Manager 用 built-in Lambda 四階段 flow、GSM 用 Pub/Sub event 觸發自寫 Cloud Function、Azure 用 Key Vault rotation policy + Event Grid。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 用 Secrets Manager、哪些可以下放到 Parameter Store、哪些該走 Vault 的 dynamic credential
2. Secrets Manager 的 雙層 grant 模型（Resource Policy + IAM Policy）跟 KMS encryption key custody 怎麼配
3. Built-in rotation 跟 Custom Rotation Lambda 的設計邊界、staging label 在 zero-downtime rotation 內的角色
4. 何時 Secrets Manager 已經不夠用、要往 Vault / 跨雲 broker 走

最短判讀路徑

判斷一個 Secrets Manager 部署是否健康、最少看四件事：

• 誰能 GetSecretValue：IAM Policy 那邊是不是用 secretsmanager:GetSecretValue 限定到 特定 secret ARN（不是 *）、Resource Policy 是不是只允許特定 principal（不是 Principal: *）、跨帳號 share 有沒有用 ABAC tag 限縮
• KMS key custody：secret 用 AWS-managed key（aws/secretsmanager）還是 customer-managed key（CMK）— production 應該全部 CMK、key policy 限定 only Secrets Manager service principal 可用、KMS key 持有者跟 secret 持有者要分離
• Rotation 設定：rotation 開了沒、rotation interval 多久、Lambda 過去執行 success rate、staging label 在 rotation 過程中是否依序 promote（AWSPENDING → AWSCURRENT → AWSPREVIOUS）
• CloudTrail data event：GetSecretValue 是 Data event、預設不記、要手動開 data event logging — 沒開等於事故時看不到 誰拿了 secret、只看得到 management API（CreateSecret / UpdateSecret）

四件事任一缺失、就是 Secret Management 跟 Audit Log 邊界的待補項目。

日常操作與決策形狀

Resource Policy + IAM Policy 雙層 grant：Secrets Manager 跟 S3 bucket policy 同模型 — IAM Policy 控制 principal 端能做什麼、Resource Policy 控制 secret 端允許誰來、兩者要 都同意 才放行。常見錯配：Resource Policy 寫 Principal: "*" 加 aws:SourceAccount condition 想做跨帳號 share、但 condition 漏寫或寫錯就變成公開可讀。跨帳號 share 一定要明確列 Principal: arn:aws:iam::123456789012:role/AppRole、不要靠 wildcard + condition 拼隔離。

IAM Policy 細粒度授權：secretsmanager:GetSecretValue 該限定到 specific secret ARN（不是 *）、配合 ABAC tag condition（secretsmanager:ResourceTag/team = payments）限縮 blast radius。對應 CircleCI 2023 Secrets Rotation — CI 出事時要能依 tag 快速列出 CI runner 可拿的所有 secret、沒這套 tag 就只能盲目 rotate 全部。

KMS encryption key 選 CMK 不是 default：每個 secret 用一把 KMS key 加密、預設用 AWS-managed key aws/secretsmanager、production 應該換 customer-managed key（CMK）。差別在 key policy 是不是自己控 — AWS-managed key 的 policy 同 account 任何 service 可呼叫、CMK 的 key policy 可以鎖到 only Secrets Manager service principal 加 only specific role 可 Decrypt。對應 Storm-0558 的對照啟示：key 的 blast radius 來自 key policy、用 CMK 把 policy 寫窄是減 blast radius 的關鍵動作。

Built-in Rotation Lambda 只限 AWS native DB：Secrets Manager 內建 rotation template 涵蓋 RDS（PostgreSQL / MySQL / MariaDB / Oracle / SQL Server）/ Aurora / Redshift / DocumentDB — 拿 AWS 提供的 Lambda template、設定 rotation interval（最短 1 天、最長 365 天）、Secrets Manager 自動排程觸發。其他 DB（self-hosted PostgreSQL、MongoDB Atlas、Snowflake）或 API key 要寫 Custom Rotation Lambda、走 4-step state machine：createSecret（產新 credential 存為 AWSPENDING）、setSecret（把新 credential 寫到 target system）、testSecret（用新 credential 驗證可連）、finishSecret（promote AWSPENDING → AWSCURRENT）。Lambda 任一步失敗 Secrets Manager 會 rollback、舊 credential 不受影響。

Staging Label（AWSCURRENT / AWSPENDING / AWSPREVIOUS）：staging label 是 指向 version 的 pointer、app 一律用 GetSecretValue 不帶 VersionStage 拿 AWSCURRENT、rotation 過程中 Secrets Manager 先把新 credential 標 AWSPENDING、testSecret 過後 promote 到 AWSCURRENT、舊的降到 AWSPREVIOUS。設計初衷是 zero-downtime rotation — 但 只有 app 端支援 AWSPREVIOUS fallback 期間才有意義：rotation 完成瞬間有些 app instance 還拿著舊 credential，target system 應該同時接受 AWSCURRENT 跟 AWSPREVIOUS（DB rotation template 會在 setSecret 階段保留舊 user 一段時間）。對應 Failure: Credential Rotation Without Scope：scope map 沒做、AWSPREVIOUS 窗口期太短、長尾 batch job 拿到舊 credential 就掛。

Cross-Region Replica：multi-region app 把 secret replicate 到其他 region、replica 在 replica region 有獨立 ARN、KMS key 跟 rotation 都要在 replica region 各自配（不能跨 region 共用 KMS key）。replica 是 讀副本、寫只能在 primary region、rotation 觸發後新 version 自動 sync 到 replica（有秒級延遲）。failover 時 app 直接讀 replica region ARN、不需要 cross-region call。

Cross-Account Sharing：跨帳號 share secret 走 Resource Policy + 對方帳號 IAM Policy 雙向授權 — Resource Policy 列對方 account 的具體 role ARN、對方 role 的 IAM Policy 加 GetSecretValue 對應 ARN。KMS key 也要跨帳號授權（KMS key policy 加對方 role 的 Decrypt 權限）— 漏了 KMS 授權會出現 GetSecretValue 成功但 Decrypt 失敗 的詭異錯誤。

核心取捨表

選 Secrets Manager 的核心訴求：AWS-only + 大部分 secret 是 static 或 AWS native DB credential + 需要 cross-account share 或 rotation Lambda + 不想 / 沒量能自管 Vault。如果只是要存 config（feature flag、non-sensitive endpoint）、Parameter Store 8 倍便宜；如果跨雲 + 需要 dynamic credential / transit / PKI、Vault 才能滿足。

進階主題

Custom Rotation Lambda 設計：4-step state machine 是 idempotent contract — Lambda 必須能被 Secrets Manager 重試任意步驟而不破壞狀態。常見實作陷阱：createSecret 不檢查 AWSPENDING 是否已存在、重試時又產生一把新的、AWSPENDING 對不上 setSecret 寫進去的；setSecret 沒處理「target system 已經有同名 user」的情況、第二次跑會卡住。Template 提供的 PostgreSQL rotation Lambda 用 cloning approach — 在 DB 內 clone 一份 user、改密碼、保留舊 user 跨 rotation 一個週期、下次 rotation 才 drop。

Resource Policy + ABAC tag 跨帳號：跨帳號 share 時用 ABAC tag 條件比硬列 role ARN 有彈性 — Resource Policy 寫 Condition: aws:PrincipalTag/team = payments、對方 account 任何帶該 tag 的 role 都可讀。代價是 tag 治理 變成 critical control：對方 account 內誰能 attach tag = 誰能拿 secret、IAM Policy 要鎖 iam:TagRole 跟 iam:UntagRole 權限。

Rotation 失敗的監控訊號：Lambda 執行失敗會在 CloudWatch 留 invocation error、Secrets Manager 把 rotation 標記為 failed、但 secret 仍可用（AWSCURRENT 保留舊 version）— 容易出現 半年沒 rotate 成功但 app 看起來正常 的盲區。要監控 SecretsManager.RotationFailed event（EventBridge rule）+ LastRotatedDate metric 超過 rotation interval 1.5 倍就 alert。

跟 AWS IAM 整合：誰可以 GetSecretValue 完全由 IAM 控制、最佳實踐是 workload role 拿 secret（EC2 instance role / ECS task role / Lambda execution role / EKS IRSA）、不要硬把 AWS credential 塞進 secret 再給 application read。Secret 內容應該是 DB password / API token / third-party credential、不應該是 AWS credential（AWS credential 用 IAM role 短期 STS 拿就好）。

CloudTrail data event 的成本權衡：開 GetSecretValue data event 等於每次 secret 取用都進 CloudTrail、高 QPS application 一天可能跑數百萬筆、CloudTrail 成本（每 100k events 約 $0.10）跟 S3 儲存成本會明顯上升。降本作法：在 EventBridge 用 filtering（只送特定 sensitive secret 的 data event 到 SIEM）、CloudWatch Logs 端設 retention 短一點（7-30 天熱資料、長尾走 S3 + Athena）。

排錯與失敗快速判讀

• GetSecretValue AccessDenied 但 IAM Policy 看起來對：檢查 Resource Policy 是否限定 source account / VPC、檢查 KMS key policy 是否允許該 role Decrypt — 兩層 grant + KMS 三點任一缺都會 AccessDenied
• 跨帳號 secret 拿不到：Resource Policy 沒列對方 role、或 KMS key policy 沒給對方 Decrypt 權限 — 跨帳號要同步配三處（Resource Policy + 對方 IAM + KMS key policy）
• Rotation 一直失敗但沒人發現：沒設 EventBridge alert on RotationFailed、AWSCURRENT 保持舊 version、app 正常但 secret 過期 — 必設 LastRotatedDate metric alert
• App 拿到 stale secret rotation 後爆掉：app 端用了 SDK cache（如 AWS SDK 的 Secrets Manager Cache）、rotation 完成後 cache 沒 invalidate — cache TTL 要短於 staging label 重疊窗口、或實作 retry-on-auth-fail 觸發 cache refresh
• CloudTrail 看不到誰拿 secret：沒開 data event logging — 在 CloudTrail trail 設定加上 AWS::SecretsManager::Secret 為 data resource
• 跨 region replica rotation 失效：rotation Lambda 只在 primary region 配、replica region 沒對應 Lambda — 每個 region 各自配 Lambda、或乾脆只在 primary rotate 讓 replica 自動 sync
• AWSPREVIOUS fallback 沒生效 batch job 掛：rotation Lambda finishSecret 太快 drop 舊 user、batch job 拿到舊 credential 連 DB 失敗 — DB rotation template 預設保留舊 user 一個 rotation 週期、custom Lambda 要自己實作雙軌窗口

何時改走其他服務

不在本頁內的主題

• Secrets Manager 完整 API reference 跟 SDK 用法
• 每種 RDS engine 的 rotation Lambda template 內部 SQL 細節
• AWS pricing 詳細計算（每 region 略有差異）
• Terraform / CDK 跟 Secrets Manager 的 IaC 整合
• AWS account organization / SCP 怎麼限制 secret 建立

案例回寫

Secrets Manager 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：HashiCorp Vault、Google Secret Manager、Azure Key Vault
• 下游：AWS KMS（Secrets Manager 加密 key custodian、CMK 與 key policy 治理）
• 下游：AWS IAM（誰可以 GetSecretValue、跨帳號 share 的 principal 來源）
• 跨模組：8 事故處理 vendor 清單（secret 外洩事件如何 routing 進 IR 流程）
• 官方：AWS Secrets Manager Documentation

服務定位

AWS WAF 的核心定位是 跟 AWS 服務深度耦合的 L7 防護層。Web ACL 直接掛 AWS resource、規則用 IAM policy 管理、log 進 Kinesis Firehose / CloudWatch Logs / S3、跟 AWS Shield Standard（內含、L3/L4 DDoS）自動整合。這跟 Cloudflare WAF 在 origin 之前的 edge 攔截不同 — AWS WAF 流量 已經進到 AWS 邊界、不是擋在外部。對 origin 跑在 ALB / CloudFront / API Gateway 後的客戶、AWS WAF 是天然選項；origin 在其他雲或地端、AWS WAF 觸不到。

跟 Fastly Next-Gen WAF 相比、AWS WAF 走 signature + managed rule group 偵測模型、不像 Fastly NG-WAF 走語意 / behavioral；AWS WAF 的 Managed Rule Group 來自 AWS Managed 與 AWS Marketplace 第三方（Fortinet、F5、Imperva 等）、客戶端 看不到 rule logic、debug 時要靠 sampled request 反推。

計費模型也是關鍵差異：AWS WAF 按 per-Web-ACL + per-rule + per-request 計費（單 ACL $5/月、單 rule $1/月、$0.60 per 1M request），Managed Rule Group 算多 rule、開太多套 ruleset 與流量大時帳單會明顯漲。Cloudflare 是 plan-tier 計費（Pro / Business / Enterprise）、不會因為多開 rule 線性漲價。

本章目標

讀完本頁、讀者能判斷：

1. AWS WAF 在 AWS-internal 防護 stack 中承擔哪一段、哪些要靠 AWS Shield / VPC / CloudFront 補位
2. Web ACL scope（Regional vs CloudFront）的選擇與跨 region 部署成本
3. Managed Rule Group / Custom Rule / Rate-based Rule 的取捨、Bot Control add-on 是否值得開
4. 何時用 AWS WAF、何時走 Cloudflare WAF / Fastly NG-WAF 的判準

最短判讀路徑

判斷 AWS WAF 配置是否健康、最少看四件事：

• Web ACL scope 對不對：CloudFront distribution 必須掛 CloudFront scope（強制在 us-east-1 建立 ACL）、ALB / API Gateway 必須掛 Regional scope（每個 region 各一份）；scope 配錯掛不上去、跨 region 部署是否用 IaC（Terraform / CloudFormation）同步複製 ACL
• Managed Rule Group 與 sensitivity：是否啟用 AWSManagedRulesCommonRuleSet（CRS）、AmazonIpReputationList（已知惡意 IP）、AnonymousIpList（VPN / proxy / Tor）、KnownBadInputsRuleSet（已知 exploit pattern）、Marketplace rule 是否在 Count mode 觀察 1-2 週 FP 再切 Block
• Logging 有沒有開：Web ACL log 預設關閉、必須手動配 Kinesis Firehose / CloudWatch Logs / S3 destination；event 是否進 SIEM（見 7.13 偵測覆蓋率與訊號治理）、是否能對 sampled request 反推 rule 行為
• IAM 邊界：誰能 update Web ACL（wafv2:UpdateWebACL、wafv2:UpdateRuleGroup）、是否限定 admin role 才能改、CI 是否只有 wafv2:Get* / List* 用來 verify、敏感變更是否走 Change Management / Audit Log

四件事任一缺失、就是 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Web ACL 與 scope：Web ACL 是 AWS WAF 的 規則容器、必須 attach 到 AWS resource。Scope 兩種：Regional（給 ALB / API Gateway / App Runner / AppSync / Cognito User Pool、每 region 獨立）與 CloudFront（給 CloudFront distribution、必須在 us-east-1 建立、全球生效）。同一個 ACL 不能跨 scope 共用；跨 region 部署同一套規則必須複製 ACL、用 Terraform / CloudFormation 管理避免 drift。

Rule action 五種：每個 rule 觸發時可以做 Block（直接 403）、Allow（跳過後續 rule、放行）、Count（不擋、只記錄、用於 dry-run 觀察 FP）、CAPTCHA（出題給人類解、bot 過不去）、Challenge（silent JS challenge、無感驗證）。新 rule 上線標準動作是先 Count 1-2 週看 sample、確認 FP 在容忍範圍才切 Block。CAPTCHA / Challenge 是 Bot Control add-on 配套、要額外計費。

Managed Rule Group（managed by AWS / Marketplace）：AWS Managed（免費含在 WAF）涵蓋 Common Rule Set（OWASP top10 對應）、Known Bad Inputs、SQL Database、Linux、Unix、Windows、Anonymous IP List、Amazon IP Reputation List、Account Takeover Prevention (ATP)、Account Creation Fraud Prevention (ACFP)。AWS Marketplace（付費）來自 Fortinet / F5 / Imperva / Cyber Security Cloud 等。Marketplace 規則 不公開 rule logic、攔錯時只能用 sampled request 反推、debug 比 AWS Managed 困難。

Custom Rule（statement + 條件）：Custom Rule 用 statement（match condition + transformation）組合：IP Set match、Geo match、Regex Pattern Set、Size constraint、SQL injection match、XSS match、String match（含 header / body / URI / query 各部位）。複雜條件用 AND / OR / NOT 組合、上限是每 Web ACL 5,000 Web ACL Capacity Units（WCU）— 規則越複雜 WCU 越高、Marketplace 大型 rule group 可能直接吃掉一半 budget。

IP Set / Regex Pattern Set：IP Set 存 IPv4 / IPv6 CIDR 清單、Regex Pattern Set 存正則表達式集合。兩者都是 獨立資源、可在多個 Web ACL 引用、單獨更新（不必動 Web ACL 結構）。實務上 threat intel feed 應該 push 到 IP Set、用 Lambda 自動 sync、不用手動加。

Rate-based Rule：限制 單一 aggregate key 在滾動 5 分鐘窗口內的請求數、超過 threshold 觸發 action。aggregate key 可選 IP、Forwarded-IP（看 X-Forwarded-For）、HTTP method、URI path、Header、Cookie 或組合。關鍵陷阱：CloudFront 後 origin ALB 必須用 Forwarded-IP、否則 Rate-based Rule 看到的全是 CloudFront 邊緣節點 IP、所有真實使用者被合併計算、要嘛全擋要嘛全放。

Logging 必須手動開：Web ACL log 預設關閉、destination 三選一：Kinesis Data Firehose（推到 S3 / Splunk / Datadog）、CloudWatch Logs（簡單但貴）、S3（直寫、需自己處理 partition）。production 通常走 Kinesis Firehose → S3 + Athena query、配合 SIEM 拉 alert。沒開 log 等於 攻擊發生時沒證據、事後無法回查。

跟 AWS Shield 整合：所有 AWS WAF 客戶自動含 Shield Standard（L3/L4 DDoS、免費、SYN flood / UDP reflection 等基礎防護）。Shield Advanced 是付費 add-on（$3,000/month per organization + per-resource fee + data transfer out fee）、提供 24/7 DRT（DDoS Response Team）、cost protection（DDoS 期間 AWS service scaling fee 補貼）、進階分析。一般客戶 Shield Standard 已足夠；金融 / 政府 / 高知名度品牌需要 Shield Advanced 的 DRT 與 cost protection。

Lambda@Edge / CloudFront Functions 補位：當 WAF rule statement 表達不出複雜業務邏輯（geofencing + business hour + user tier 組合、JWT claim 解析後判斷 routing）、用 Lambda@Edge（Node.js / Python、跑在 CloudFront 邊緣節點、4 個 phase：viewer-request / origin-request / origin-response / viewer-response）或 CloudFront Functions（純 JS、輕量、低延遲、只在 viewer-request / viewer-response）補位。Lambda@Edge 適合複雜邏輯、CloudFront Functions 適合 header rewrite / 簡單 routing；兩者都不能取代 WAF managed rule、但補位 WAF 表達力上限。

跟 AWS IAM 整合：誰能改 Web ACL 是 IAM policy 決定（wafv2:CreateWebACL、wafv2:UpdateWebACL、wafv2:AssociateWebACL、wafv2:UpdateRuleGroup 等 action）。production 標準配置：admin role 才能 update、CI / 開發者只有 wafv2:Get* / List* 用來 verify、敏感變更走 Change Management + CloudTrail audit log。

核心取捨表

選 AWS WAF 的核心訴求：AWS-internal app + origin 跑在 ALB / CloudFront / API Gateway / App Runner 後 + 想跟 IAM / CloudTrail / Shield 同套 control plane 治理。Origin 不在 AWS、或要 把攻擊擋在抵達雲之前、應該走 Cloudflare WAF 或 Fastly NG-WAF。

進階主題

AWS WAF Bot Control（add-on）：付費 add-on、用 AWS 自家 bot fingerprinting 區分 verified bot（搜尋引擎）/ signal: automated browser（headless Chrome 等）/ signal: known bot（已標記 IoT / scraper），給每個請求 bot category label。Custom Rule 在 label 上做條件、決定 Block / Challenge / CAPTCHA。比 user-agent 過濾準很多、但要額外計費（per-request）。Bot Control 有兩個 inspection level：common（便宜、基礎指紋）與 targeted（貴、含 JavaScript challenge、CAPTCHA、token-based）。

Fraud Control（ATP / ACFP）：Account Takeover Prevention（ATP）跟 Account Creation Fraud Prevention（ACFP）是 Managed Rule Group 的特殊類別、需付費啟用。ATP 看登入端點的 credential stuffing、ACFP 看註冊端點的 bot signup。兩者都用 AWS 自家 threat intel（被竊憑證 list、行為模型）打 label、客戶側用 Custom Rule 處理。對有 login / signup 端點的 SaaS / 電商有價值、純內部後台不必開。

CAPTCHA / Challenge：AWS WAF 內建 CAPTCHA puzzle 與 silent JS Challenge、可在 rule action 直接呼叫。Challenge 在客戶端執行 proof-of-work、合法瀏覽器無感、headless 工具卡住；CAPTCHA 是視覺題、人類解、bot 不會。Production 標準做法：Bot Control 給 label → Custom Rule 看 label → likely bot 走 Challenge、known bad 走 Block、人類流量直接 Allow。

ACM Private CA + WAF 對 mTLS：AWS WAF 本身不做 mTLS 驗證、mTLS 是 ALB / API Gateway / CloudFront 自己的功能（搭配 AWS ACM Private CA 簽發 client cert）。WAF 在 mTLS 完成後才看 L7 流量、可以用 HTTP header match（mTLS 後 ALB 注入 client cert 資訊到 header）做進一步 rule。Internal API 用 mTLS + WAF 是常見組合。

Lambda@Edge 補 inline business logic：複雜判斷（user tier × geo × business hour × A/B test）WAF rule statement 表達不出來、用 Lambda@Edge 在 viewer-request phase 解析 JWT、查 internal risk API、回 response header 給 WAF 後續判斷。代價：Lambda@Edge 部署只能在 us-east-1、code 更新傳播到全球 edge 要幾分鐘、debug 是分散式 CloudWatch Logs。

排錯與失敗快速判讀

• Web ACL 掛不上 CloudFront：scope 配成 Regional、CloudFront 拒絕 attach — Web ACL 必須在 us-east-1 + CloudFront scope 才能掛 CloudFront；ALB / API Gateway 反過來只能掛 Regional scope
• Rate-based Rule 全擋 / 全放：CloudFront 後 origin 看到全部都是 CloudFront IP、aggregate key 沒換 Forwarded-IP — 改用 Forwarded-IP（X-Forwarded-For）作 aggregate key，並設 Fallback behavior
• Managed Rule Group 誤殺合法請求：CRS High sensitivity 開後 file upload / rich text editor 端點被 Block — 找 sampled request 看 rule_id、用 Scope-down statement 限定該 rule 在某 path 不執行、或開該 rule 為 Count、不要關整個 group
• Marketplace Rule 攔不明流量：Marketplace rule logic 不公開、sampled request 看到 rule label 但不知為何 — 切該 rule 到 Count mode 觀察、若無 attack 跡象換 AWS Managed 同類 rule
• WCU 超限：Web ACL 上限 5,000 WCU、加 Marketplace + 多個 AWS Managed 就會爆 — 看 Capacity Used、移除重疊 rule、把 Custom Rule 表達式簡化（少用 transformation chain）
• Logging 沒設 / 設錯：事件發生後沒有完整 log 可查、只有 sampled request（保留 3 小時、機率抽樣） — 必開 Logging configuration 到 Kinesis Firehose / S3 / CloudWatch Logs、確認 IAM role 有 firehose:PutRecord 權限
• IAM 權限過寬：CI account 拿到 wafv2:* 整 zone 都能改 — 收斂到 wafv2:Get* / List* 唯讀、敏感寫入限 admin role + MFA + Change Management
• 跨 region 部署 drift：手動在 console 改 us-east-1 ACL、其他 region 沒同步 — 用 Terraform / CloudFormation IaC 管理、PR review、CI plan 檢查 drift
• Shield Standard 不夠擋大型 L7 DDoS：Standard 只防 L3/L4、L7 attack 靠 WAF Rate-based Rule + Bot Control — 若反覆遭遇大型 L7 DDoS、評估 Shield Advanced 的 DRT + cost protection 是否值得

何時改走其他服務

不在本頁內的主題

• AWS WAF Classic（v1）的遷移細節 — 本頁全以 WAFv2 為準
• 完整 WCU 計算規則與每個 statement 的 WCU cost reference
• Marketplace 第三方 rule group 各家功能矩陣
• AWS WAF 在 GovCloud / China region 的差異
• Bot Control / ATP / ACFP 完整 label schema reference

案例回寫

AWS WAF 在 07 案例庫無直接 vendor-level case、但多個 case 對應 WAF 作為 修補窗口期臨時控制 與 entry point 治理 的角色：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：AWS IAM（誰能改 Web ACL）、AWS ACM（mTLS client cert）、AWS Secrets Manager（rule update 用的 API key）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件如何 routing 進 IR）
• 官方：AWS WAF Documentation

服務定位

Elastic Security 的核心定位是 Elastic Stack 上的 security solution、底層是 Elasticsearch（資料層）+ Kibana（查詢與 UI 層）+ Fleet / Elastic Agent（採集層）、頂層產品分三條：Elastic SIEM（log aggregation + detection rule + Case + Timeline）、Elastic Defend（前 Endgame 收購而來、EDR + endpoint protection、跟 CrowdStrike / SentinelOne 同層）、Elastic Cloud Security（CSPM + CWP、雲端資源 misconfig 與 workload 防護）。

跟 Splunk 比、Elastic 走 OSS-friendly + resource-based pricing — TB-scale ingestion 不直接漲費用（要 scale node 但邊際成本遠低於 Splunk per-GB 累進）、Sigma rule 社群可直接 import 5000+ 規則；但 Splunk Security Content 跟 SOAR / RBA 等 detection content + SOC tooling 成熟度仍高一個量級。跟 Datadog Security 比、Elastic 跨 on-prem + 多雲、可自管也可 Elastic Cloud SaaS；Datadog 是 SaaS-only、適合純 cloud-native。跟 Google Security Operations 比、Elastic 多查詢語言（KQL / EQL / Lucene / ES|QL）、Google 走 YARA-L 單一統一語言、超大規模 ingestion Google 反而划算。

關鍵張力：多查詢語言模型 同時是 Elastic 的優勢跟負擔。EQL 寫 attack chain sequence 比 SPL correlation 更直接、KQL 過濾快、ES|QL 寫 aggregation 像 SQL 直覺、Lucene 處理 full-text；但 SOC team 要決定哪個 rule 用哪個語言、不能讓每個 analyst 各寫各的。

本章目標

讀完本頁、讀者能判斷：

1. Elastic Security 在 SOC stack 中承擔哪一段（log aggregation / SIEM / EDR / CSPM）、哪些要外接（Okta IdP log、Vault secret rotation）
2. KQL / EQL / Lucene / ES|QL 四種查詢語言的職責分工（誰用在哪種 rule、誰負責教育 SOC）
3. Resource-based pricing 的治理（cluster sizing、hot-warm-cold tier、Searchable Snapshots、Elastic Cloud Serverless）
4. 何時用 Elastic、何時走 Splunk / Datadog / Google Security Ops 的取捨

最短判讀路徑

判斷 Elastic Security deployment 是否健康、最少看四件事：

• 誰能改 detection rule：Elastic Security app 的 rule editor 權限、detection-rules repo（Elastic 官方 OSS rule 庫）有沒有 fork 進組織版控、rule change 是否走 PR review + staging space 驗證
• 採集治理：Fleet 統一管 Elastic Agent policy / 還是散落 Beats（filebeat / metricbeat / auditbeat / winlogbeat）各自設定、log source 是否分 hot / warm / cold tier、Searchable Snapshots 是否開
• Detection content coverage：Elastic Prebuilt rules + Sigma 社群規則 import 多少 enabled、是否跟 MITRE ATT&CK 對照、EQL sequence 規則覆蓋多少 attack chain pattern
• Alert quality / SOC handoff：alert volume per day、Case 跟 Timeline 是否進入日常 SOC workflow、ML anomaly job 是否在線 + threshold 是否 tuned、跟 8 incident response 的 routing 是否定義

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Ingestion architecture：log 進 Elastic 三種主路徑 — Elastic Agent + Fleet（現代部署的預設、單一 agent 收 system / endpoint / cloud / app log、中央 Fleet server 統一管 policy）、Beats（filebeat / metricbeat / auditbeat / winlogbeat 等專用 agent、Fleet 推出前的傳統做法、現在持續支援但建議遷移到 Elastic Agent）、Logstash（pipeline-style ETL、用在 enrich / filter / route 複雜場景）。production 通常 Elastic Agent + Fleet 為主、Logstash 補 ETL 缺口。

KQL / EQL / Lucene / ES|QL 的職責分工：四種查詢語言各有 first-class 場景。KQL（Kibana Query Language）是 Kibana 預設過濾語法、user.name : "alice" and event.action : "logon-failed"、簡單直觀、適合 dashboard / Discover 過濾。EQL（Event Query Language）做 sequence pattern matching、sequence by user.name [authentication where event.outcome=="failure"] [authentication where event.outcome=="success" and source.geo.country != "TW"]、表達 attack chain 比 SPL correlation 更直接。Lucene 是底層 full-text query、特殊需要時直接寫。ES|QL（Elasticsearch Query Language、2024+）是新版 SQL-like、FROM logs-* | WHERE event.category == "authentication" | STATS count = COUNT(*) BY user.name、寫 aggregation 直覺；屬新語言、production 採用 cadence 還在跟進中。

Detection rule 種類：Elastic Security 的 rule type 是六種 first-class 概念、不是只有「query rule」一種 — Query rule（KQL / Lucene 觸發）、EQL rule（sequence pattern）、Threshold rule（聚合超過閾值、例如同一 IP 5min 內 login fail > 100）、ML rule（綁 Elastic ML anomaly job、anomaly score 超過閾值觸發）、New term rule（首次出現的 entity、例如某 user 第一次從某國登入）、Indicator match rule（事件 enrich 比對 threat intel feed、IoC hit 觸發）。production rule 經常組合多種 — query rule 做粗篩、EQL rule 抓 sequence、threshold + ML 補 baseline anomaly。

Sigma rule import：Sigma 是 OSS 通用 detection rule 格式（YAML、跨 SIEM 可移植）、社群維護 5000+ 規則。Elastic 支援直接 import Sigma rule 轉成 Elastic detection rule、是 Elastic 拉開跟商業 SIEM 距離的 OSS 槓桿。實務做法：先 import Sigma baseline + 全部走 staging space 跑 false positive 觀察、再 enable 到 production；不要直接全 enable、Sigma rule 跨 SIEM 通用所以 environment-specific tuning 必須自己做。

Case + Timeline：Case 是 incident 容器、聚合 alert + comment + assignment + status；Timeline 是 SOC analyst 的 investigation workspace、可以 pin event / annotate / link related alert、產出 investigation narrative。兩者組合是 Elastic 的 SOC workflow first-class、不是外掛 — 對應 Splunk ES 的 Notable Event + Incident Review、但 Elastic 走 OSS 化、Case 可 export markdown 進 ticketing。

Elastic Defend（EDR）：前 Endgame 收購整合、提供 endpoint detection + prevention（malware block / ransomware protection / behavior detection）、跟 CrowdStrike Falcon / SentinelOne 同層。Elastic Defend 跑在 Elastic Agent 內、policy 從 Fleet 推。實務上多數 SIEM 客戶不會用內建 EDR、而是外接專業 EDR feed 進 Elastic SIEM；但 OSS-friendly + 預算敏感的中型客戶可以直接整合到一個 stack。

Cross-cluster search：跨多個 Elastic cluster 統一查詢（remote_cluster:index-name）、適合 multi-region / multi-tenant SOC、不需要把所有 log 搬到單一 cluster。對應 Splunk Cloud federated search。實務場景：歐洲 GDPR 資料留在 EU cluster、美國 cluster query 過去做 incident investigation 而不複製資料。

ML jobs（anomaly detection）：Elastic ML 內建 unsupervised anomaly detection、pre-built ML job library 覆蓋 SOC 常見場景（user behavior baseline、host login pattern、port scan detection、rare process）。ML rule 綁 ML job、anomaly score 超過閾值觸發 detection rule。對應 Splunk UBA、但 Elastic ML 是 stack 內建、不是 add-on app。

Resource-based pricing 治理：Elastic Cloud 按 cluster size（node count × node size）計費、不按 ingestion volume — 意義是 ingest 多 log 不直接漲費用、但要 scale node 維持查詢效能。實務治理：hot tier（最近 7-30 天、SSD 高效能 node）、warm tier（30-90 天、低 IO node）、cold tier / frozen tier（90 天以上、Searchable Snapshots on S3 / GCS、查詢慢但成本極低）。對應 Splunk SmartStore、但 Elastic frozen tier 把 retention 從幾個月延長到幾年、cost 不線性漲。

核心取捨表

選 Elastic 的核心訴求：OSS-friendly 文化 + resource-based pricing 友善 + Elastic Stack 已作為 observability 在用、團隊有能力跨四種查詢語言（或至少把 EQL 跟 KQL 雙語分工清楚）、能接受 detection content 跟 SOAR 成熟度 trade-off。TB-scale ingestion 時 Elastic 比 Splunk 省 60-80% license cost 是最大誘因、但要算進 cluster sizing 跟 SRE 維運的隱形成本。

進階主題

EQL sequence pattern（時序攻擊鏈）：EQL 的 sequence by 是 Elastic 表達 attack chain 的 first-class 武器、比 SPL correlation 直接。例如 MFA fatigue 寫成 sequence by user.name with maxspan=5m [authentication where event.outcome=="failure"] [authentication where event.outcome=="failure"] [authentication where event.outcome=="success" and source.ip != known_ip]、序列邏輯直接表達。配對 Uber 2022 MFA Fatigue lesson：MFA fail 序列 + 新裝置 success 直接觸發。

Elastic Defend endpoint response：除偵測外、Defend 支援 host isolation（隔離受感染 endpoint 但保留 SOC 連線）、process kill、file quarantine 等 response action、直接從 Kibana Security app 觸發。對應 CrowdStrike Real Time Response。production 採用前要設 approval gate、避免 SOC analyst 誤觸動 production server。

CSPM / CWP（Elastic Cloud Security）：CSPM（Cloud Security Posture Management）對 AWS / GCP / Azure 帳號做 misconfig 掃描（S3 bucket public、IAM over-permission、security group 0.0.0.0/0）、對照 CIS Benchmark；CWP（Cloud Workload Protection）對 Kubernetes workload 跑 runtime detection。屬較新的功能、跟 Wiz / Lacework 等專業 CNAPP 比覆蓋還在追趕。

Cross-cluster search 跨環境 federated query：multi-region SOC 的 first-class 工具 — query 寫 FROM logs-auth-*, eu-cluster:logs-auth-*、Elastic 自動路由跨 cluster。實務注意：跨 cluster query 延遲較高、要設 timeout；資料合規（GDPR）必須留意 query 結果是否包含跨境資料、不是搬資料但 query 結果回傳算不算傳輸要法務確認。

Sigma 規則社群：Sigma 是 OSS detection rule 通用格式、Elastic 是 Sigma 主力使用者（內建 importer + Elastic 工程師參與 Sigma upstream）。實務做法：fork SigmaHQ repo 進組織版控、CI pipeline 自動轉 Sigma → Elastic detection rule、staging space 跑 false positive curve、promote 到 production；不要每次 manually import。

Elastic Cloud Serverless（2024+）：新模型、按 workload type（search / observability / security）計費、不再按 cluster size — 減少 sizing 決策、autoscaling 由 Elastic 託管。屬新模型、production 採用 cadence 還在跟進中、適合 greenfield 部署或 PoC、existing cluster 遷移 roadmap 還在演進。

排錯與失敗快速判讀

• Alert volume 爆炸 / SOC 看不完：Sigma rule 全 enable 沒 tune、或 threshold rule 閾值太低 — staging space 跑 1 週統計 FP、tune threshold、加 exception list 排除已知合法 source、ML rule 補 user-specific baseline
• EQL sequence rule 跑不動 / timeout：sequence span 太長（24h）或 by field cardinality 太高、查詢成本爆炸 — 縮短 maxspan、限定 index pattern、加 pre-filter 條件
• Cluster 查詢慢 / Kibana 卡：hot tier 塞太多舊資料、沒做 hot-warm-cold tier 分層 — 開 ILM（Index Lifecycle Management）policy 自動 rollover、warm tier 用便宜 node、cold / frozen 走 Searchable Snapshots
• Fleet agent enrollment 失敗：Fleet server 跟 Elasticsearch 之間網路 / 憑證 / token 問題 — 檢查 Fleet server health、確認 enrollment token 未過期、agent log 看 specific 錯誤
• Sigma rule import 後大量 FP：Sigma rule 是 cross-SIEM 通用、沒有 environment-specific exclusion — 不要全 enable、staging tune 後再 promote、加 exception list（known scanner IP / 內部測試帳號）
• Resource-based pricing 超預算：node 過度 scale 或 hot tier 留太多 — 開 hot-warm-cold ILM、把 retention 超過 30 天的 index 推到 frozen tier on S3、Searchable Snapshots 是預設應該開
• ML job anomaly score 不準：training data 包含已 compromise 期間、baseline 被汙染 — 確認 training window 在乾淨期、定期重訓、配 detection rule 用 anomaly_score > 75 而非 > 50

何時改走其他服務

不在本頁內的主題

• KQL / EQL / ES|QL 完整語法 reference、Lucene query DSL 進階用法
• Elasticsearch index sharding / replica / ILM tuning 細節（屬 observability / 資料工程範圍）
• Elastic Observability（APM / logs / metrics）— 屬 observability 不屬 security
• Elastic Cloud Serverless 詳細 sizing 與 pricing 模型（2024+ 新模型、變動中）
• Elastic Stack 自管的維運（cluster upgrade、Kibana plugin 開發）

案例回寫

Elastic Security 在 07 案例庫沒有直接 vendor-level 事件、但所有 detection-related case 都是 SIEM 偵測覆蓋率的對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Splunk、Datadog Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Elastic SIEM）
• 跨類：Okta（IdP log source）、HashiCorp Vault（secret rotation API）、Cloudflare WAF（WAF log + Sigma rule 對接）
• 跨模組：8 事故處理 vendor 清單（Case → IR routing）、4 observability（Elastic Stack 共用 log pipeline）
• 官方：Elastic Security Documentation、detection-rules repo

讀完本章後、你應該能對自己跑的推論伺服器回答：bind 在哪、誰能連到、預設配置安不安全、要分享給家裡其他電腦時該怎麼設、要透過反代或 tunnel 上 internet 時要做什麼。

本章目標

1. 認識 bind address 的三層典型範圍：loopback / LAN / WAN。
2. 區分 llama-server / Ollama / LM Studio 在三層上的預設行為差異。
3. 判讀「我要讓哪些機器連到這個 server」的工作流問題。
4. 認識反向代理 / Cloudflare Tunnel / Tailscale 把本地伺服器搬到網路上的延伸風險。
5. 對應的最低安全配置：auth、TLS、firewall 規則。

bind address 的三層典型範圍

 1┌──────────────────────────────────────────────────────────────┐
 2│ WAN（公開 internet）                                          │
 3│  ↑                                                            │
 4│  └─ 反代 / Cloudflare Tunnel / ngrok：本機 → 對外暴露         │
 5│                                                               │
 6│ LAN（家裡 / 辦公室內網）                                       │
 7│  ↑                                                            │
 8│  └─ 0.0.0.0 / 192.168.x.x：本機 → 內網其他電腦可連            │
 9│                                                               │
10│ Loopback（本機）                                              │
11│  └─ 127.0.0.1 / localhost：只能本機連                         │
12└──────────────────────────────────────────────────────────────┘

三層的風險梯度：

三個主流伺服器的預設行為

事實查核註：上表的預設值是 2026 年 5 月主流版本的常見配置、各工具的預設值可能因版本變動、建議引用前以對應工具的官方文件跟 --help 為準。Ollama 從某個版本開始支援部分驗證機制、具體版本見 Ollama GitHub release notes。

預設都是 127.0.0.1、是個人 dev 友善的安全起點。改到 0.0.0.0 之前、值得停下來想三個問題：

1. 真的需要其他機器連嗎？多數場景只需要本機連、保持 loopback。
2. 同網段有哪些其他設備？家裡的 IoT 設備、訪客手機都算。
3. 開出去後、API key / prompt 內容會被誰看到？

「不小心開到 LAN」的常見路徑

個人 dev 場景下、誤開放到 LAN 的常見路徑：

1. 複製貼上社群教學的指令：教學作者也許在 lab 環境跑、把 --host 0.0.0.0 寫進範例；複製貼上時沒注意。
2. Docker / 容器化跑伺服器：Docker 預設 bridge 網路、若 -p 8080:8080 沒指定 host、port 會 bind 到所有介面、等同 0.0.0.0。改用 -p 127.0.0.1:8080:8080 限定本機。
3. 環境變數從 dotfile 載入：把 OLLAMA_HOST=0.0.0.0 設在 dotfile、再裝其他工具時忘了這個設定還在生效。
4. 多台機器想互通：例如 dev 用筆電、模型在桌機；想當作小型 server 時、若同網段有不信任的設備、就要做 auth。

檢查當前 bind 狀態的指令：

1# macOS / Linux
2lsof -i -P -n | grep LISTEN | grep -E "(ollama|llama|lmstudio|1234|8080|11434)"
3
4# 或用 ss（Linux）
5ss -lntp | grep -E "(1234|8080|11434)"
6
7# 或用 netstat（macOS / Linux）
8netstat -an | grep LISTEN | grep -E "(1234|8080|11434)"

看到 127.0.0.1:11434 是 loopback、*:11434 或 0.0.0.0:11434 是 bind 到所有介面。

暴露後的具體後果

把 bind 開到 LAN（甚至 WAN）、可能的具體後果：

1. prompt 內容洩漏：每個 prompt 包含的 code、檔案路徑、API key、商業邏輯都會在請求 body 裡。同網段任何人 dump 流量都能看到（HTTP）或要破 TLS（HTTPS）。
2. API 被別人用：對方拿你的 server 跑他自己的 prompt、消耗你的算力跟電費；若你的 server 連到雲端 LLM 當 fallback、會消耗你的 API quota。
3. 被當跳板：tool use 啟用的話、攻擊者可以透過 prompt 觸發 tool 的副作用、讀寫檔案、執行 shell command（見 6.2）。
4. 被當 DoS 目標：發送大量 prompt 讓 GPU 滿載、影響本機其他工作。

WAN 暴露的進一步後果：

5. 被自動化 scanner 掃到：internet 上有持續掃描常見 port 的 bot、11434 / 8080 是知名 LLM port、會被加進掃描清單。
6. 被列入公開 LLM 服務清單：類似 Shodan 的服務會收錄對外可用的 inference endpoint、可能被「LLM as free service」目錄列進去。

事實查核註：「公開 LLM endpoint 被掃描跟列進目錄」是社群觀察到的現象、具體 scanner 工具、目錄服務跟頻率依時段變動、建議引用前以 Shodan 等公開掃描資料庫的當前狀態為準。

想分享 LAN 時的最低安全配置

如果你的工作流真的需要讓家裡另一台機器連（例如桌機跑模型、筆電寫 code）、最低應該做：

1. 限定 LAN 介面、不要 0.0.0.0：bind 到具體 LAN IP（如 --host 192.168.1.5）、不要 bind 到所有介面。
2. 開 firewall 規則：macOS 用內建 Firewall、Linux 用 ufw / iptables、Windows 用內建 Firewall、限定只接受同網段來源。
3. 加 API key：llama-server 支援 --api-key <key>、其他伺服器透過反代（如 caddy / nginx）加 basic auth 或 API key。
4. 不接訪客 Wi-Fi：訪客 Wi-Fi 通常跟主網段共用、要分開 VLAN 或直接不開放。
5. 檢查同網段設備清單：用 arp -a 或 router 管理介面看連著哪些 MAC address、有不認識的就先別開。

想透過反代 / tunnel 上 WAN 的延伸風險

把本地 LLM 暴露到 WAN 的常見技術：

進階防護見 Backend 7.3 入口治理 跟 Backend 7.5 傳輸信任與憑證生命週期。個人 dev 場景的判讀：

1. 預設不要上 WAN：若沒有具體需求（如多裝置工作流、跨地點協作）、保持 LAN 或 loopback。
2. 要上 WAN 時優先用 Tailscale-like mesh：可以保持「私網」感覺、不暴露在公開 internet 上。
3. 真的要公開（如做給朋友試用的 demo）：上反代、做 auth、明確跟使用者說會 log 什麼。

給讀者的綁定判讀流程

每次啟動 / 配置新伺服器時的判讀流程：

1. 明確列出「誰需要連」：只有本機 IDE？家裡桌機？外出筆電？朋友的 demo？
2. 選擇對應的 bind 範圍：本機選 loopback、家裡選 LAN IP、外出選 mesh VPN、公開 demo 才用反代。
3. 跑 lsof / netstat / ss 確認實際 bind 狀態：跟意圖一致才算配好。
4. 若 bind 到 LAN / WAN、加 API key：別假設「沒人會掃到」、做最低 auth。
5. 記下當前配置：寫在 ~/llm/server-config.md 之類、避免日後忘了哪台是哪個 mode。

下一章

下一章：6.2 tool use 與 MCP server 的權限模型、處理伺服器跑起來後最大的副作用面。

觀察

控制面 token 事件顯示機器憑證若治理不足，會形成跨服務高權限風險。

判讀

這類問題的根因是 token 生命週期、最小權限與審計證據鏈未對齊，單一憑證洩漏只是觸發點。

策略

1. 用工作負載身份替代長期共享 token。
2. 強制 token rotation 與細粒度 scope。
3. 把憑證事件寫入 release gate 與 incident triage。

下一步路由

回 7.6 secrets and machine credential governance 與 7.12 supply chain integrity。

引用源

• Cloudflare incident on January 24, 2023

規則選擇策略

兩個工具的內建規則集都超過數百條，涵蓋從加密設定到命名慣例。全開跑會讓命中清單長到沒人看。規則選擇的判準是「這條規則命中後，團隊會不會真的去修」——答案是不會的規則，開著只是製造噪音。

分層啟用

把規則分成三層逐步啟用，而非一次全開：

地基層是即使其他規則都關掉也要開的——S3 bucket 對外公開（CKV_AWS_19、CKV_AWS_53）和 security group 全開（CKV_AWS_24、CKV_AWS_25）這類規則命中就是真問題。營運層在 IaC 覆蓋率夠高時啟用，否則會掃到大量不在 IaC 管理內的資源。規範層等團隊有能力消化命中量再開。

checkov 的規則過濾

1# 只跑地基層規則
2checkov -d . --check CKV_AWS_19,CKV_AWS_53,CKV_AWS_24,CKV_AWS_25,CKV_AWS_40,CKV_AWS_145
3
4# 或者用 framework 過濾（只掃 Terraform）
5checkov -d . --framework terraform --compact --quiet

checkov 支援 --check（白名單，只跑這些）和 --skip-check（黑名單，跳過這些）。初期用 --check 白名單比較可控——明確列出要跑的規則，而非從全集去扣。隨著團隊消化能力提升再擴大白名單。

tfsec 的嚴重度過濾

1# 只報 CRITICAL 和 HIGH
2tfsec . --minimum-severity HIGH
3
4# 排除特定規則
5tfsec . --exclude aws-s3-specify-public-access-block

tfsec 的嚴重度分 CRITICAL / HIGH / MEDIUM / LOW。初期設 --minimum-severity HIGH 把低嚴重度的過濾掉，減少噪音量。降低閾值的時機是 HIGH 以上的命中清零後。

豁免管理

不是每個命中都是錯——對外的 ALB 在 port 443 開 0.0.0.0/0 是設計意圖、不是漏洞。豁免的重點是讓例外顯式化、有理由、可被 review。

行內豁免

1resource "aws_security_group_rule" "alb_https" {
2  type        = "ingress"
3  from_port   = 443
4  to_port     = 443
5  protocol    = "tcp"
6  cidr_blocks = ["0.0.0.0/0"]
7  #checkov:skip=CKV_AWS_24:ALB 的 HTTPS 入站需要對外開放
8}

tfsec 的行內豁免：

1resource "aws_security_group_rule" "alb_https" {
2  #tfsec:ignore:aws-ec2-no-public-ingress-sgr -- ALB HTTPS listener requires public access
3  cidr_blocks = ["0.0.0.0/0"]
4}

行內豁免的好處是理由跟程式碼在一起，review 時一眼可見。壞處是散落在各檔案裡，盤點所有豁免要 grep。

集中式豁免

checkov 支援 .checkov.yaml 集中管理豁免：

1# .checkov.yaml
2skip-check:
3  - CKV_AWS_24  # ALB public-facing SG rules
4  - CKV_AWS_19  # Legacy S3 buckets pending migration

集中式的好處是一個地方看到所有豁免，適合全域性的例外（如「這批 legacy S3 bucket 還沒遷完、暫時跳過 public access 檢查」）。壞處是理由離程式碼太遠，三個月後沒人記得為什麼跳過。

豁免紀律

每個豁免都要寫理由（-- 之後的文字）。沒有理由的豁免等於靜默跳過——review 時看不出是故意的還是為了讓 CI 過而隨手加的。定期（每季度）跑一次豁免盤點：

1# 盤點所有 checkov 豁免
2grep -rn "checkov:skip" --include="*.tf" .
3
4# 盤點所有 tfsec 豁免
5grep -rn "tfsec:ignore" --include="*.tf" .

每個命中問一句：當初跳過的原因還成立嗎？legacy 遷移完了嗎？臨時的例外變成永久的了嗎？

自訂規則

內建規則覆蓋通用安全實踐，但專案特有的規範（如「所有 RDS 必須有 cost-center tag」「所有 S3 bucket 名稱必須以公司前綴開頭」）需要自訂。

checkov 自訂規則（Python）

 1# custom_checks/require_cost_center_tag.py
 2from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck
 3from checkov.common.models.enums import CheckResult, CheckCategories
 4
 5class CostCenterTagRequired(BaseResourceCheck):
 6    def __init__(self):
 7        name = "Ensure cost-center tag is present"
 8        id = "CUSTOM_001"
 9        supported_resources = ["aws_instance", "aws_db_instance", "aws_s3_bucket"]
10        categories = [CheckCategories.GENERAL_SECURITY]
11        super().__init__(name=name, id=id, categories=categories,
12                         supported_resources=supported_resources)
13
14    def scan_resource_conf(self, conf):
15        tags = conf.get("tags", [{}])[0]
16        if isinstance(tags, dict) and "cost-center" in tags:
17            return CheckResult.PASSED
18        return CheckResult.FAILED
19
20check = CostCenterTagRequired()

1# 跑自訂規則
2checkov -d . --external-checks-dir ./custom_checks

tfsec 自訂規則（YAML）

 1# .tfsec/custom_rules.yaml
 2- id: CUSTOM_001
 3  description: S3 bucket name must start with company prefix
 4  impact: Non-standard naming breaks cross-account policies
 5  resolution: Add company prefix to bucket name
 6  requiredTypes:
 7    - resource
 8  requiredLabels:
 9    - aws_s3_bucket
10  severity: MEDIUM
11  matchSpec:
12    name: bucket
13    action: startsWith
14    value: acme-

自訂規則的數量保持精簡——每條規則都是維護成本。只有「違反後會在後續流程造成問題」的規範值得寫成自動化規則，純粹的風格偏好留給 review 時口頭提醒。

CI 整合

把掃描接進 CI 的目標是「PR 合併前就攔下問題」，而非 apply 之後才發現。

GitHub Actions 範例

 1jobs:
 2  security-scan:
 3    runs-on: ubuntu-latest
 4    steps:
 5      - uses: actions/checkout@v4
 6
 7      - name: Run checkov
 8        uses: bridgecrewio/checkov-action@v12
 9        with:
10          directory: .
11          check: CKV_AWS_19,CKV_AWS_53,CKV_AWS_24,CKV_AWS_25
12          quiet: true
13          compact: true
14          soft_fail: false
15
16      - name: Run tfsec
17        uses: aquasecurity/tfsec-action@v1
18        with:
19          minimum_severity: HIGH
20          soft_fail: false

soft_fail: false 讓掃描命中時 CI 失敗、阻擋合併。初期可以先設 soft_fail: true（掃描報告但不阻擋），讓團隊觀察命中量，確認規則集合理後再切成強制。

掃描結果回貼 PR

checkov 和 tfsec 的 GitHub Actions 都支援把結果以 PR comment 回貼。讓 reviewer 在 PR 頁面直接看到掃描結果，不用去翻 CI log。checkov-action 預設會回貼；tfsec-action 需要額外的 github_token 設定。

漸進式導入

1Week 1-2：soft_fail=true，觀察命中量和 false positive 率
2Week 3：修完所有真問題，豁免所有合理的 false positive
3Week 4：切 soft_fail=false，掃描變成強制 gate

這個節奏讓團隊在掃描變成強制之前就清理完存量，避免「一開 hard fail 所有 PR 都過不了」的窘境。

False positive 處理

false positive 的處理有三條路，依復發頻率選：

最常見的 false positive 是 ALB 的 public-facing security group（設計就是要開 443）和開發環境的寬鬆設定（dev 允許、prod 不允許）。後者可以用 checkov 的 --var-file 搭配環境變數區分——dev 跑寬鬆規則集、prod 跑嚴格規則集。

處理 false positive 時要抵抗「加 skip 讓 CI 過」的捷徑衝動。每個 skip 都要問：這是設計意圖（ALB 要開放）還是技術債（dev 環境暫時放寬）？前者寫永久豁免加理由，後者寫臨時豁免加 TODO 和預計修復時間。

跨分類引用

• → infra 走 PR 流程與自動化護欄：掃描在 PR 流程裡的定位與 plan/apply 的關係
• → Terraform CI Pipeline 設定：掃描步驟怎麼嵌入完整的 CI workflow
• → 模組三：Security Group 稽核與清理：掃描命中 0.0.0.0/0 後的處理流程

權限分級：admin / operator / viewer

團隊成員的日常操作權限用三級來劃分，每一級對應不同的操作範圍與風險。分級的依據是「這個角色的日常工作需要碰到什麼層級的資源」，不是職稱或年資。

Admin

Admin 能修改 IAM policy、網路拓撲、帳號層級設定（Organizations、SCP、billing）。這是影響範圍最大的一級——一條 SCP 寫錯可以鎖死整個帳號的操作，一條 IAM policy 開太寬可以讓任何角色取得不該有的權限。

持有 admin 權限的人數應該收斂到最少：通常是平台團隊的 1-2 人加上一個 break-glass 備援角色。Admin 權限不應該是某個人的「日常身分」——即使是平台工程師，日常操作也用 operator 等級，只有在需要改 IAM 或帳號設定時才 assume 到 admin role。

 1# Admin role 的信任政策：只允許特定 IAM user assume
 2data "aws_iam_policy_document" "admin_trust" {
 3  statement {
 4    actions = ["sts:AssumeRole"]
 5    principals {
 6      type        = "AWS"
 7      identifiers = [
 8        "arn:aws:iam::123456789012:user/platform-lead",
 9        "arn:aws:iam::123456789012:user/platform-backup",
10      ]
11    }
12    condition {
13      test     = "Bool"
14      variable = "aws:MultiFactorAuthPresent"
15      values   = ["true"]
16    }
17  }
18}
19
20resource "aws_iam_role" "admin" {
21  name               = "infra-admin"
22  assume_role_policy = data.aws_iam_policy_document.admin_trust.json
23  max_session_duration = 3600  # 1 小時後自動失效
24}

max_session_duration 限制 assume 後的有效時間。Admin session 設 1 小時是讓操作者完成當次任務後權限自動回收，不需要手動登出。MFA 條件確保即使帳號密碼外洩，沒有第二因素也無法提權。

Operator

Operator 能部署服務、修改應用層資源（ECS task、RDS parameter group、S3 lifecycle）、查看與操作日常維運所需的一切。多數工程師的日常身分落在這一級。

Operator 的 policy 用 resource scope 限制它碰不到 IAM 和帳號層級設定——能改 ECS service 但不能改 ECS service 用的 IAM role，能改 RDS 參數但不能改 RDS 的 subnet group。這個邊界讓 operator 的操作失誤影響範圍停在服務層，不會擴散到地基層。

 1data "aws_iam_policy_document" "operator" {
 2  # 允許操作應用層資源
 3  statement {
 4    actions = [
 5      "ecs:UpdateService", "ecs:DescribeServices",
 6      "rds:ModifyDBInstance", "rds:DescribeDBInstances",
 7      "s3:GetObject", "s3:PutObject",
 8      "logs:GetLogEvents", "logs:FilterLogEvents",
 9    ]
10    resources = ["*"]
11  }
12
13  # 明確拒絕碰 IAM 和帳號設定
14  statement {
15    effect = "Deny"
16    actions = [
17      "iam:*",
18      "organizations:*",
19      "account:*",
20    ]
21    resources = ["*"]
22  }
23}

Deny 語句確保即使未來有人不小心把過寬的 managed policy attach 到 operator role，IAM 和帳號操作仍然被擋。Deny 在 IAM 評估中優先於 Allow。

Viewer

Viewer 能讀取 Console、查 log、看 metric dashboard，但不能修改任何資源。適合的角色包括：值班但不需要改設定的 on-call、需要查 log 排查問題的 support 團隊、需要看資源狀態的管理層。

Viewer 用 AWS 的 managed policy ReadOnlyAccess 作為基線，再根據需要排除敏感資料的讀取（例如 Secrets Manager 的 GetSecretValue）。

三級的對應關係：

導入時程參考：三級權限的 IAM role 與 policy 建立約需 1-2 天，包含 trust policy 設定與初次分配。後續的權限變更走版本控制的 PR 流程，讓每次 policy 調整都有提案、審查與歷史紀錄（見infra 走 PR 流程）。

臨時提權（break-glass）

Operator 在日常工作中偶爾需要 admin 層級的操作——排查一個涉及 IAM 的事故、緊急修改一條 security group 規則、回應安全事件。常態性地把 admin 權限開給所有 operator 會讓三級分級失效，但每次都等 admin 角色的人上線又太慢。Break-glass 流程處理的就是這個中間地帶。

機制

Break-glass 的實作是一個平時不被 assume 的 admin role，加上一套提權紀錄。Operator 在需要時 assume 這個 role，取得一段時效有限的 admin session。這個 assume 動作會在 CloudTrail 留下紀錄（誰、什麼時候、session 多長），事後可稽核。

1resource "aws_iam_role" "break_glass" {
2  name                 = "infra-break-glass"
3  assume_role_policy   = data.aws_iam_policy_document.break_glass_trust.json
4  max_session_duration = 3600
5
6  tags = { Purpose = "emergency-escalation" }
7}

如果團隊有 ChatOps 或 ticketing 系統，把 break-glass 的觸發綁進去可以增加一層人為確認：operator 在 Slack 或 ticket 裡申請提權、另一個人核可、系統開放 assume。這層確認的目的是在事後稽核時留下一條清楚的「誰授權了這次提權」紀錄，而非阻止操作本身。

事後回顧

每一次 break-glass 使用都應該進入事後回顧：為什麼需要提權？這個操作能不能改寫成 operator 層級的權限就能完成？如果某類操作反覆觸發 break-glass，代表 operator 的權限邊界需要調整——把那類操作從 admin 降到 operator，而不是讓 break-glass 變成常態。

回顧的輸出是權限邊界的校準，不是對操作者的檢討。

定期 access review

權限分配不是一次性的設定。人會換組、離職、從 contractor 轉正職、從開發角色轉管理角色，每一次角色變動都可能讓既有的權限配置過期。定期 review 的責任是找出「權限比當前角色需要的更寬」的身分，把它們收斂回來。

節奏與方法

每季做一次 access review 是多數團隊能維持的最小節奏。Review 的步驟：

1. 拉出所有 IAM user 和 role 的清單，標注每個身分目前的分級（admin / operator / viewer）
2. 比對每個身分的實際角色——這個人現在還在做需要 operator 權限的工作嗎？
3. 用 IAM Access Analyzer 檢查哪些權限在過去 90 天沒被使用過——沒用到的權限是收斂候選
4. 特別檢查 break-glass 的使用紀錄——有沒有人的 break-glass 使用頻率高到代表他的基線權限該調整

1# 產出 credential report，列出所有 user 的 key 建立時間與使用時間
2aws iam generate-credential-report
3aws iam get-credential-report --output text --query Content | base64 -d | head -20
4
5# 查 Access Analyzer 的 finding（哪些權限可收斂）
6aws accessanalyzer list-findings --analyzer-arn <analyzer-arn> \
7  --filter '{"status": {"eq": ["ACTIVE"]}}'

管理層報告

Access review 的結果適合用兩個數字向管理層報告：覆蓋率（已 review 的身分數 / 總身分數）與異常數（權限過寬或長期未使用的身分數）。異常數的趨勢比單次數字更有意義——持續上升代表新人 onboarding 時的權限配置流程有缺口，持續下降代表 review 在發揮作用。

導入時程參考：第一次 access review 約需半天到一天（盤點 + 比對 + 收斂），後續每季約需 2-4 小時。

職務交接與離職處理

一個人離開團隊時，他持有的所有存取路徑都需要被回收。手動建立的存取路徑越多，離職處理越容易遺漏。

離職 checklist

權限設計越集中在 role-based（用 IAM group 或 SSO permission set），離職處理越簡單——停用 SSO 帳號就自動切斷所有透過 SSO 取得的 role。反過來，如果有大量手動 attach 的 policy 或直接寫在 trust policy 裡的 user ARN，離職時要逐一找出並移除，容易遺漏。

離職後的 credential rotation 有一個常被忽略的風險：輪替範圍沒有按作用域分批。一個反例是多個服務共用同一把 secret，輪替時切新憑證的服務跟還只認舊憑證的服務之間出現認證窗口不一致，導致跨系統連鎖中斷。穩定的做法是先分域隔離受影響服務、恢復雙憑證窗口、再逐批收斂（見 反例：憑證輪替未分 Scope）。

交接的可執行性

交接的成本取決於知識有多少沉澱在程式碼裡、有多少留在個人腦中。如果環境的建立方式是一份 IaC、變更方式是 PR 歷史，新接手的人讀 code 跟 PR 描述就能重建脈絡。如果關鍵操作（某台資料庫的特殊 parameter、某條 security group 規則的理由）只存在離職者的記憶裡，交接窗口一過就永久遺失。

可操作的檢驗：問「如果這個人下週離職，團隊能不能只靠讀 repo 就安全地操作他負責的環境？」答案是否定的部分，就是交接的優先補強項——優先把它們寫進 IaC 或 PR 描述，而不是寫進交接文件（交接文件會過期，IaC 跟著環境一起演進）。

這個議題在知識共享優於個人英雄主義有組織層面的展開。

Contractor 與外部 vendor 存取

外部人員（contractor、顧問、SaaS vendor 的技術支援）需要存取雲端環境時，原則是給最小範圍、設明確時限、留完整紀錄。

範圍限制

外部人員的 role 用 Permissions Boundary 設定權限天花板，確保即使有人誤 attach 了過寬的 policy，操作範圍也不超過 boundary 允許的上限。Scope 到具體的資源 ARN（某個 S3 bucket、某台 RDS instance），而非帳號級別的 wildcard。

如果團隊已經有跨帳號策略，把外部人員的 workload 放在獨立帳號或 sandbox OU 裡，用 SCP 限制該帳號能操作的服務類型，是比 role 級別限制更強的隔離。

時限控制

外部存取的 IAM user 或 SSO 帳號在建立時就設定到期日。多數雲端平台支援 session duration 限制（role 的 max_session_duration）和帳號層級的停用排程。合約結束日應該對應到存取到期日——這個對應關係寫進 IaC（用 tag 標注到期日）或團隊的 access review checklist，避免合約結束後存取仍然開著。

稽核紀錄

外部人員的操作需要比內部人員更嚴格的稽核。CloudTrail 預設記錄所有 API 呼叫，但 review 的頻率要提高——外部人員的操作紀錄每週抽查，而非等到季度 access review 才回頭看。查的是：有沒有存取超出約定範圍的資源？有沒有在非工作時間操作？有沒有大量的 read 操作指向敏感資料？

這些紀錄同時也是合約管理的依據——如果外部 vendor 的技術支援存取了超出約定範圍的資源，紀錄是釐清責任的事實基礎。

跨分類引用

• → 身分與憑證地基：IAM role / policy / OIDC 的技術機制
• → 跨帳號策略：用 OU 和 SCP 在帳號層級隔離外部人員
• → 治理好習慣：tagging 標注存取到期日、secrets 不進 code
• → 怎麼把 infra 推動起來：知識共享與交接的組織面

認證：來源是誰

認證驗證送出資料的 client 是否合法。未認證的 request 應該被拒絕，避免任意來源向 collector 寫入資料。

API Key 認證

每個合法的 SDK client 有一個 API key。Collector 檢查 request header 中的 API key 是否在合法清單中。

 1func authMiddleware(next http.Handler) http.Handler {
 2    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 3        key := r.Header.Get("X-API-Key")
 4        if !isValidKey(key) {
 5            http.Error(w, "unauthorized", http.StatusUnauthorized)
 6            return
 7        }
 8        next.ServeHTTP(w, r)
 9    })
10}

自用工具場景下，一個 API key 對應一個 client 通常就足夠。多個 client（例如同一個 app 的 iOS 和 Android 版本）可以用同一個 key，或每個平台一個 key 以便在 access log 中區分來源。

mTLS（Mutual TLS）

Client 和 server 互相驗證對方的憑證。安全性比 API key 高 — 攻擊者即使取得 API key，沒有 client 憑證也無法連線。

mTLS 的設定成本較高（每個 client 需要產生和管理憑證），適合對安全性要求較高的環境。自用工具通常不需要 mTLS。

授權：允許做什麼

授權控制已認證的 client 可以執行哪些操作。Collector 的操作通常分為兩類：寫入事件和查詢事件。

角色分離

最簡單的授權模型是兩個角色：

• Writer：只能寫入事件（POST /events）。SDK client 使用這個角色。
• Reader：只能查詢事件（GET /events、GET /query）。開發者的 CLI 工具使用這個角色。

角色分離的價值在於限制洩漏的影響範圍。如果 SDK 的 API key 被洩漏，攻擊者只能寫入（產生垃圾事件），不能讀取（看到歷史事件中的敏感資訊）。

寫入限制

即使認證通過、角色正確，collector 也可以對寫入加上限制：

• Rate limit：每個 API key 每分鐘最多 N 個 request。防止 client 端 bug 導致事件風暴。
• Payload size limit：每個事件最大 M KB。防止異常大的 event data 消耗儲存。
• Schema validation：事件必須符合定義的 JSON schema。格式不正確的事件拒絕存入。

Access Log：誰做了什麼

Access log 記錄每個到達 collector 的 request — 來源 IP、API key（或 key 的 hash）、操作類型、時間戳、response status。

Access log 的用途：

安全審計：發現異常行為 — 未知 IP 的大量寫入、非工作時間的讀取、連續的認證失敗。

問題排查：SDK 說事件送出成功但 collector 沒有收到 — access log 可以確認 request 是否到達、response 是什麼。

用量統計：每個 client 送了多少事件、佔多少儲存。

Access log 本身也是監控資料，但和業務事件分開儲存。Access log 存在 collector 本機的 log 檔中，用系統的 logrotate 管理輪替。

12026-06-19T10:30:00Z POST /events key=sk_mon_ab...cd ip=192.168.1.50 status=200 size=1234
22026-06-19T10:30:01Z POST /events key=INVALID ip=10.0.0.99 status=401 size=0
32026-06-19T10:31:00Z GET /query key=sk_read_ef...gh ip=192.168.1.1 status=200 size=8901

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Transport 層的加密 → Transport 安全
• 資料儲存後的去識別化 → 去識別化策略
• Client-side credential 暴露的根本限制 → Client-side SDK 認證

服務定位

Datadog Security 由四個 product 構成、共用 Datadog Agent 與 backend：Cloud SIEM（log-based detection、跟 Splunk Enterprise Security 同類）、Cloud Security Management (CSM) — 涵蓋 CSPM（cloud config posture）與 Cloud Workload Security (CWS)（container / Linux runtime via eBPF）、App and API Protection (AAP、前 ASM) — RASP-style 在 app runtime 收 attack signal、Sensitive Data Scanner — scan log 中的 PII / credential 並 redact。

跟 Splunk 比、Datadog 走 observability-first + security 是 view、Splunk 是 security-first。Splunk 在 enterprise SOC tooling 深度（SOAR playbook、RBA、CIM data model）與跨 on-prem 部署上更成熟、Datadog SaaS-only 但跟 APM / Infra 同 plane、混合 incident（latency 異常是攻擊還是容量？）的判讀路徑更短。跟 Elastic Security 比、Elastic 可跨 on-prem + OSS、Datadog 只給 SaaS；Elastic 要自己整合 observability 訊號、Datadog 出廠就有。跟 Google Security Operations 比、Google 走 fixed-price by data、PB-scale 划算、Datadog 隨 host 線性漲、中等規模友善但破千 host 後 cost 曲線變陡。

關鍵張力：observability 與 security 同 plane 是 Datadog 最大賣點、也是 cost 風險來源。host count 跟 events/month 同時是 observability 跟 security 的計費基準、security 加上去後 bill 不會獨立 — 預算要從 整個 Datadog 帳單 看、不是 security 單列。

本章目標

讀完本頁、讀者能判斷：

1. Datadog Security 在 SOC stack 中承擔哪一段（log SIEM / CSPM / 容器 runtime / WAF-runtime / log DLP）、哪些要外接（Vault、Okta IdP log、edge WAF）
2. observability + security 同 plane 的優勢何時成立、何時是 vendor lock-in 風險
3. Cloud SIEM 計費（events/month + indexed）跟 Standard / Flex Logs retention tier 的成本治理
4. 何時用 Datadog、何時走 Splunk / Elastic / Google Security Ops 的取捨

最短判讀路徑

判斷 Datadog Security 部署是否健康、最少看四件事：

• Datadog Agent coverage：agent 是否裝在所有 host / container / serverless wrapper、log forwarder 是否覆蓋 cloud control plane（AWS CloudTrail / GCP Audit Log / Azure Activity Log）、IdP（Okta）audit log 是否進來 — 缺一個就是 detection 盲點
• Detection rule ownership：Cloud SIEM rule 是用內建還是 custom、custom rule 是否走 Git 版控（Terraform datadog_security_monitoring_rule）、staging 環境是否 dry-run 24-48hr 才 promote production
• CSPM compliance check 治理：CIS / NIST / PCI baseline 開哪些、findings 是否進 ticket workflow、misconfig 修復 SLA 有沒有定義（critical 24hr、high 7d、medium 30d）
• Events/month + Indexed Log 預算：Cloud SIEM 按 events/month + indexed event 計費、新加 source 前是否估算 ingestion impact、Standard / Flex Logs retention tier 是否依 log priority 分流

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Datadog Agent 採集：log / metrics / trace / security event 走同一個 Agent、用 integration（150+）抓 cloud / SaaS / database / queue。security event 跟 observability event 在後端用 attribute tag（env、service、host、trace_id）關聯、查 incident 時可以從 log alert pivot 到同 trace_id 的 APM trace 看 attack 發生的 application context。

Cloud SIEM detection rule：rule 形式類似 SPL 的 query — source:okta @evt.name:user.authentication.auth_via_mfa @outcome:failure 加 signal aggregation（rolling window count、new value、anomaly detection、impossible travel）。內建 rule 跟 MITRE ATT&CK 對應、跟 Splunk Security Content 同類但 rule 數量較少；custom rule 走 Terraform provider 進版控、不在 UI 直改 production。

CSPM compliance check：scan AWS / GCP / Azure 配置 vs CIS / NIST 800-53 / PCI / SOC 2 baseline、發現 misconfig（public S3 bucket、overly permissive IAM、不安全 SG rule）。跟 Wiz / Prisma Cloud 同類但跟 Datadog Infra 同 dashboard、findings 可以直接看到 affected resource 的 metrics / log。優勢是 資安發現可以直接看業務影響、限制是 graph-based attack path（Wiz 強項）不及專業 CNAPP。

Cloud Workload Security（CWS）：用 Linux eBPF probe 在 kernel 層觀察 container / process behavior、偵測 cryptominer / privilege escalation / 異常 syscall / file integrity 變動。跟 Falco 同類但跟 Datadog Infra 同 plane、CWS alert 可以直接 pivot 到該 container 的 CPU / memory / trace。Linux eBPF 對 kernel 版本敏感、舊 kernel 部份功能不可用、production 前要確認 fleet kernel matrix。

App and API Protection（AAP）：RASP-style protection、Datadog APM library 在 application runtime 收 attack signal（SQLi / XSS / SSRF / 異常 traffic pattern）。跟 Cloudflare WAF / AWS WAF 不同層 — WAF 在 edge / CDN、AAP 在 app runtime 看到的是真實 request handler / DB query。兩者互補不互斥：edge WAF 擋 volumetric attack 跟已知 pattern、AAP 補 app-specific business logic abuse。

Sensitive Data Scanner：scan ingest 進來的 log、用內建或 custom pattern 偵測 PII / credential / payment card / API key、發現後可以 redact、quarantine 或 alert。是 DLP-lite — 比不上 Google DLP / Microsoft Purview 的 sensitive data discovery / classification / lineage 全套、但對 log 中誤洩 secret 的場景夠用、是 detection signal source 也是 DLP 補位。

Notebooks + Workflow Automation：Notebooks 是 incident investigation 用的 query workbook、混 log query + metric chart + APM trace + 註記、跟 Splunk Search 比較像 Jupyter notebook 的 SOC 版。Workflow Automation 是輕量 SOAR、接 PagerDuty / Slack / Jira / Webhook / Vault API、playbook 走 visual builder + Python。SOAR 深度不到 Splunk SOAR、但對中等規模 SOC（10-50 人）的常見 response 動作（rotate credential / block IP / open ticket）夠用。

Standard Logs / Flex Logs + retention tier：log 進 Datadog 後分 Indexed（hot、可全文搜尋、貴）、Flex Logs（warm、retention 長、查詢延遲較高、cost 1/3-1/5）、Archive（cold、丟 S3 / GCS、純儲存）三層。Cloud SIEM detection 跑在 indexed log 上、所以 哪些 log 走 indexed 直接決定 detection coverage 跟 bill。tier 1 source（IdP / cloud control plane / payment）必 indexed、tier 2 source（app log）按 sampling、tier 3（debug）走 Flex 或 Archive。

核心取捨表

選 Datadog 的核心訴求：已經用 Datadog observability、cloud-native 為主、SOC 規模中等（10-50 人）、需要 observability + security 同 plane 的 incident 判讀路徑。on-prem 為主、預算敏感（host 量 1000+）、需要 enterprise SOAR / RBA 深度、走 Splunk；OSS-friendly、跨 on-prem、走 Elastic。

進階主題

Cross-product correlation（log + APM + metrics 同 trace_id）：Datadog 最特別的偵測形狀 — security alert 不只 log line、而是綁 trace_id 的 integrated incident view。例如 API endpoint 出現 SQLi 嘗試、Cloud SIEM 開 signal、同時 APM 看到該 request 的 DB query 跟 latency、infra 看到該 host 的 CPU。對「query latency 異常是不是被攻擊」這種混合 incident 偵測有結構性優勢、跟 Snowflake 2024 Credential Abuse 的調查路徑直接對應。

CWS Linux eBPF 行為偵測：eBPF probe 在 kernel 層、不需要 kernel module、不影響 process performance（< 1% overhead）。可以偵測的行為包括 file integrity（/etc/passwd 被改）、process tree（bash → curl → /tmp/payload 異常 chain）、network connection（容器對外連 cryptominer pool）、syscall pattern（ptrace 用於 process injection）。跟 Falco 同樣用 eBPF、差別是 Datadog CWS 不需要單獨部署 + 跟 Datadog 其他 signal 同 plane。

Datadog Threat Intelligence：內建 threat feed（malicious IP / domain / file hash）、自動標記 log / network event 命中 IoC。可以加自家 STIX/TAXII feed、不過深度比不上 Mandiant / Recorded Future / 專業 TI platform；中等規模 SOC 夠用、嚴重 APT 對抗場景要外接專業 TI。

跟 Datadog Incident Management 整合：security signal 可以直接開 Datadog Incident（內建 incident channel + timeline + post-mortem template）、跟 PagerDuty 同類但跟 observability 同 plane。對 資安事件升級成全公司 incident 的場景（Change Healthcare 2024 Operations Impact 那種規模）可以共用 incident commander 視角、不用兩套 timeline 拼起來。

排錯與失敗快速判讀

• Cloud SIEM 偵測 lag / 沒 alert：events 沒進 indexed log（走了 Flex）、retention tier 設錯 — 檢查 log pipeline rule 是否把 security-critical source 標 indexed
• Events/month 暴衝：debug log / verbose log 進 Cloud SIEM index、CWS event 量爆 — log pipeline 前置 filter（Datadog Observability Pipeline 或 Cribl）、CWS rule 收斂 noisy 行為
• CSPM findings 100+ 沒人修：findings 沒進 ticket workflow、沒分 priority — 整合 Jira / ServiceNow、severity 對應 SLA、findings 老化超 30 天升級
• CWS 在舊 kernel host 沒資料：eBPF feature 對 kernel 版本敏感（< 4.18 部份功能不支援）— 升級 kernel 或標記該 host 為 CWS-incompatible、補位用 host-based agent
• AAP false positive 卡 user：RASP 在 app runtime 直接 block、誤殺正常 request — AAP 先走 monitor mode 1-2 週收 baseline、tune 後再轉 protect mode
• Sensitive Data Scanner miss PII：custom pattern 沒寫對、log format 嵌套（JSON 內又是 JSON）— 用 sample log 跑 dry-run、scanner 跑在 ingest 階段不是 retroactive
• Workflow Automation playbook 黑箱：自動 rotate credential 結果誤殺 prod service account — playbook high-impact action 走 approval gate、default 走 containment 不走 deletion

何時改走其他服務

不在本頁內的主題

• Datadog Agent 完整 configuration reference、custom check 撰寫
• Datadog observability（APM / RUM / Synthetics / DBM）細節 — 屬 4 observability 模組
• Cloud SIEM rule 完整語法 reference
• CWS eBPF probe 撰寫（custom rule via Agent Expression Language）細節
• Datadog Incident Management workflow（屬 8 IR 模組）

案例回寫

Datadog Security 在 07 案例庫沒有直接 vendor-level 事件、但 observability + security 同 plane 的偵測形狀讓部份案例的調查路徑變短、值得對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Splunk、Elastic Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Datadog）
• 跨類：Okta（IdP log source）、HashiCorp Vault（Workflow Automation 拉 API）、Cloudflare WAF / AWS WAF（edge WAF log 進 Cloud SIEM、AAP 在 app 層補位）
• 跨模組：4 observability（同 Agent / 同 plane）、8 事故處理 vendor 清單（Datadog Incident → IR routing）
• 官方：Datadog Security Documentation

服務定位

Fastly NG-WAF 設計的第一順位是 production 可直接走 Block 模式。Signature WAF 的成本不在 rule 本身、在 false positive — 一條 SQLi pattern 可能誤判合法 SQL-like 字串（搜尋查詢、CSV 上傳）、production 開 Block 立刻炸合法流量、所以多數 signature WAF 跑在 Detect / Log Only 模式、攔不下真正攻擊。Fastly NG-WAF 走 Signal 模型：每個請求被解析後標記若干 Signal（SQLi、XSS、CMDI、Traversal、Anomaly 等）、再依 threshold-based rule（N 個 Signal 在 M 秒內聚集）才動作 — false positive 自然降低、Block 模式可開。

跟 Cloudflare WAF 的對照：Cloudflare 走 signature + managed rule + ML 三層、覆蓋廣但需要 sensitivity tuning；Fastly NG-WAF 預設低 FP 但需要 客戶自己定義業務語意（哪些 path 是 admin、哪些 header 不該出現、哪些 anomaly 對自家業務代表攻擊）— 用 Tag + Match Conditions 表達。跟 AWS WAF 的對照：AWS WAF 跟 ALB / CloudFront / API Gateway 整合深、跨雲弱；Fastly NG-WAF 部署模型多樣（Edge / Agent / Cloud）、跨 AWS / GCP / on-prem / K8s 一致。

關鍵張力：低 FP 的 代價 是要花時間理解自家業務語意。Signature WAF 是「裝上就有保護」、Fastly NG-WAF 是「裝上有 baseline、業務 anomaly 要自己標」。沒有人定義 Tag + Power Rules、就只用到產品 30% 能力。

本章目標

讀完本頁、讀者能判斷：

1. Fastly NG-WAF 的 Signal / Tag / Rule / Mode 四個核心 first-class concept 各承擔什麼責任
2. Edge / Agent + Module / Cloud Proxy 三種部署模型的選擇條件
3. Account Takeover Protection、Bot Protection、API discovery 三個進階 module 的適用情境
4. 何時用 Fastly NG-WAF、何時走 Cloudflare WAF / AWS WAF 的取捨

最短判讀路徑

判斷 Fastly NG-WAF 配置是否健康、最少看四件事：

• 部署模型對齊架構：Fastly Edge inline（流量本來就過 Fastly CDN）/ Agent + Module（自管 Nginx / Apache / IIS / Envoy / .NET 加 sigsci-agent local process）/ Cloud Proxy（Fastly 接 origin proxy）三選一或混用、是否覆蓋所有入口（含 admin、internal API、staging）
• Signal 與 Tag 設計：預設 Signal（SQLi / XSS / CMDI / Traversal / Backdoor / Anomaly）是否全開、業務語意 Tag（admin-path、internal-only、payment-flow）是否定義並掛上 Match Conditions、Power Rules 是否組合多 Signal / Tag 走 threshold-based action
• Rule mode 與 threshold：Site-level 跟 Corp-level Rule 是 Block 還是 Off、threshold（連續幾個 Signal / 多久窗口）是否依 endpoint 業務調整、Template Rule（ATO、Bot）是否啟用
• Logging 與 sigsci-agent token 治理：Syslog / HTTP webhook / S3 / SIEM（Splunk / Datadog / Sumo Logic）整合是否 production-grade、sigsci-agent 連回控制面的 token 是否進 HashiCorp Vault、跨環境 token 是否分離

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

部署模型選擇：Fastly Edge inline 是最簡部署、流量已過 Fastly CDN 就 inline 加 NG-WAF、沒有額外 agent 要管；Agent + Module 是 self-managed Nginx / Apache / IIS / Envoy / HAProxy / .NET / Java（Tomcat）等加裝 sigsci-module（process 內 module 攔請求）+ sigsci-agent（本機 daemon、跟 Fastly 控制面 sync rule、collect event）— 適合 origin 不過 Fastly CDN、或 internal API；Cloud Proxy 是 Fastly 提供 reverse proxy 端點、客戶 DNS 指過去、origin 在後面 — 適合不想改 origin、又沒用 Fastly CDN。三種混用常見、大企業 edge 用 Fastly Edge、internal service 用 Agent + Module。

Signal 是已知攻擊指標：Fastly NG-WAF 預定義 Signal 包含 SQLi / XSS / CMDI（command injection）/ Traversal（路徑穿越）/ Backdoor / RCE / Anomaly 等。Signal 是 語意解析結果 — request body 被 parser 拆解（JSON / form / multipart）、每個欄位看「這像不像某類攻擊」、不是 regex 比對。意義是 encoding 變化攔不住（base64 / URL encode / Unicode normalize 都會被解開）、跟 signature WAF 的脆性對比明顯。

Tag 是客戶自定 Signal：用 Match Conditions（path / method / IP / header / body content / query 參數）定義「什麼樣的請求叫某 tag」、例：Path: /admin/* AND Source IP NOT IN internal_cidr → tag: admin-external-access。Tag 之後可以走 Rule 處理（看到 admin-external-access 就 alert / block）。Tag 是 Fastly NG-WAF 表達 業務語意 的主要工具、不是用來補強 Signal。

Rule 三層：Site-level Rule（單一 site / property）/ Corp-level Rule（整個 organization 共用、用於 corp-wide block list、跨 BU 統一 policy）/ Template Rule（Fastly 提供的預設複合 rule、如 ATO template、Bot template）。Rule 表達式組合 Signal / Tag / Source IP / Path / Method、走 Block / Off。Power Rules 是進階版 — 支援 threshold + 時間窗口 + 多條件 AND/OR、例：「同 IP 在 60 秒內觸發 5 個 SQLi Signal 就 Block 10 分鐘」。

Mode 兩種：Block（攔截、回 406 / 自訂 status）/ Off（不動作、純 log）。沒有 Cloudflare 的 Sensitivity 滑桿 — 因為 Signal 本身已是語意判讀結果、不需要敏感度調整、調整在 threshold（多少 Signal 才動作）。

Account Takeover Protection（ATO）：偵測 credential stuffing pattern — 同 IP 多 login fail、跨 IP 同 account 多 login、impossible travel、unusual UA。Fastly NG-WAF 內建 login endpoint detection（自動 / 手動標記 /login、/auth/signin 等）、配合 ATO Template Rule 直接 inline 處理（rate limit、challenge、block）。對應 Identity Boundary 的 ATO 對策、但是在 WAF 層直接攔、不等 IdP 內 ATO 邏輯。

Bot Protection：跟 Cloudflare Bot Management 同類、走 behavioral + browser fingerprint + JS challenge、區分 verified bot / likely bot / human。比 user-agent 過濾穩、headless browser 攔得住。

API discovery：Fastly NG-WAF 自動學習 site 的 API endpoint 與 schema、偵測 schema drift（突然出現的多餘欄位、缺欄位、type mismatch）— 比手動維護 OpenAPI schema 輕量、適合內部 API 多但沒寫完整 OpenAPI 的團隊。

Logging 與 sigsci-agent 治理：所有 event 走 Fastly NG-WAF 控制面 + 客戶端 Syslog / HTTP webhook / S3 / SIEM（Splunk / Datadog / Sumo Logic）。sigsci-agent 連回控制面用 Site API key — 該 key 進 HashiCorp Vault、跨環境 prod / staging 分離、rotation 走標準 secret rotation 流程、不能寫死在 agent 配置檔。

核心取捨表

選 Fastly NG-WAF 的核心訴求：production 直接 Block + API / schema-rich 業務 + 自管伺服器需要 inline agent + 跨雲 / on-prem mix、且有預算支付 Enterprise tier。純 AWS-internal 簡單 web app 用 AWS WAF 整合更直接；要整套 edge security suite 用 Cloudflare。

進階主題

VCL + Edge custom rule：Fastly Edge 部署模式下、NG-WAF 跟 Fastly CDN 的 VCL（Varnish Configuration Language）共存、複雜邏輯可寫 VCL 在 NG-WAF 處理前後攔截 — 例：geo block 在 VCL 做、NG-WAF 處理通過的請求。Compute@Edge（Fastly 的 edge serverless、類 Cloudflare Workers）也可以接 NG-WAF 結果做進一步處理。代價是 VCL / Compute@Edge code 變另一條 ops trace、要有版控與 staging。

ATO 進階 — credential stuffing 場景：login endpoint 接 ATO Template Rule 後、可進一步整合 已洩漏 credential check（類 Have I Been Pwned 整合）、failed login burst → progressive challenge（先 CAPTCHA、再 block）。對應 Identity Boundary 的 IdP ATO 邏輯、Fastly 在 WAF 層攔的好處是 攻擊不會打到 IdP、減少 IdP 端 rate limit 壓力。

Bot Protection 進階：browser fingerprint + behavioral pattern + JS challenge 三層、可掛 bot score threshold 在 Power Rules 內、配合 ATO 做 high-risk login flow（bot score 高 + login endpoint → 強 challenge）。

Agent + Module 在 K8s / VM：K8s 場景 sigsci-agent 走 sidecar 或 DaemonSet、sigsci-module 在 ingress controller（Nginx Ingress Controller 加 sigsci-nginx module）；VM 場景 sigsci-agent 走 systemd service、module 隨 web server 啟動。跨環境 token 隔離（prod / staging / dev）走 Vault dynamic secret 或環境變數注入、不寫死配置檔。

Corp-level Rule 共用：多 BU / 多產品線在同一 Corp（Fastly NG-WAF 的 organization 概念）下、Corp Rule 跨所有 Site 生效 — 適合表達「全公司禁 IP X」「全公司 ATO Template 都開」、避免每個 Site 重複配置。

排錯與失敗快速判讀

• Signal 沒觸發、攻擊穿過：Encoding 異常 / parser 沒解析該 content-type — 確認 Content-Type 正確、body 大小沒超過 sigsci-module 限制（預設 100KB）、Signal scope 是否包含該 endpoint
• Tag 沒掛上：Match Conditions 寫錯（path 大小寫、trailing slash、wildcard 語意）— 在 Fastly NG-WAF console 用 Rule Evaluation 工具測試 request 是否命中
• Block 模式誤殺：Power Rules threshold 太低、單一合法請求觸發多 Signal — 調 threshold 或加 Site Rule exception 排除特定 path / source
• sigsci-agent 跟控制面失聯：Site API key 過期 / firewall block out-bound / agent 版本太舊 — agent log 看 connection status、輪換 token 走 Vault、保持 agent 在 supported version range
• sigsci-module load 失敗：web server 啟動報 module 載入錯 — 確認 module 版本跟 web server major version 對齊（Nginx 1.20 對 sigsci-nginx 對應版本）
• ATO Template 沒攔到：login endpoint detection 沒標到自家 path — 手動在 console 標記 login endpoint 路徑
• Logging gap：Syslog / webhook 送失敗、SIEM 沒收到 — 確認 destination accept、TLS cert 沒過期、retry policy
• 跨環境 token 漏氣：staging token 流到 prod、改 staging 影響 prod rule — Vault 環境分離、token 加標籤、定期 audit token usage

何時改走其他服務

不在本頁內的主題

• Signal Sciences 收購前的 product line 演進細節
• 完整 Signal 清單與每個 Signal 的內部解析邏輯
• VCL / Compute@Edge 完整語法 reference
• Fastly CDN 本身的 caching / TLS / origin shielding 細節
• Enterprise 合約細節、各國資料駐留選項

案例回寫

Fastly NG-WAF 沒有直接 vendor-level 公開事件、案例庫對照引用以「behavioral detection 在 zero-day / supply chain 場景的 inline mitigation 角色」為主：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、AWS WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（sigsci-agent Site API key 存放）、Okta（Fastly admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 routing 進 IR）
• 官方：Fastly Next-Gen WAF Documentation

服務定位

GSM 的定位是 GCP-native 的 secret 集中點、解決三件事：把 secret 從 environment variable / Cloud Build substitution / GitHub secret 收回單一受控位置；用 Google Cloud IAM 的 role binding on secret resource 控制誰能讀；走 Workload Identity Federation 讓 GKE / Cloud Run / 外部 workload（GitHub Actions / AWS / Azure）安全取用、避免長期 service account key 散落。

跟 Vault 比、GSM 沒有 dynamic credential engine、沒有 transit / PKI engine、沒有跨雲統一介面 — 但運維成本接近於零、跟 GCP IAM / KMS / Cloud Logging 的整合是 first-class。跟 AWS Secrets Manager 比、GSM 把 rotation orchestration 推給應用層、自由度高但代價是 rotation 流程要自己設計；跟 Azure Key Vault 比、兩者 mindset 相近（單雲、IAM-driven、CMEK 整合）、各自綁雲。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 適合 GSM（GCP-only、static、靠 IAM 授權即可）、哪些該走 Vault 或其他雲端 native
2. GSM 最低安全設定（CMEK、Data Access audit、Workload Identity Federation、IAM Conditions）
3. 自寫 rotation Cloud Function 時必須處理的 版本切換窗口 跟 fallback 邏輯
4. 何時 GSM 不夠用、要往 Vault / Berglas / Cloud HSM 走

最短判讀路徑

判讀一個 GSM deployment 是否健康、最少看四件事：

• 誰能讀 secret：secret resource 上的 IAM binding 是不是用最小單位授權（per-secret、不是 project-level roles/secretmanager.secretAccessor）、有沒有上 IAM Conditions 限定時間 / IP / resource tag
• Key custody 分離：encryption key 是 Google-managed default key、還是 Cloud KMS CMEK？CMEK 的 key 持有 admin 跟 secret access admin 是不是分人
• 取用路徑：workload 取 secret 是走 service account key（壞模式、長期憑證散落）還是 Workload Identity Federation（GKE WIF / 外部 OIDC token exchange）
• 證據是否可回查：Admin Activity audit 預設開、Data Access audit（AccessSecretVersion 誰呼叫）預設 關、production 要手動 enable + 接 Cloud Logging sink 推到 SIEM

四件事任一缺失、就是 Audit Log 與 Secret Management 邊界的待補項目。

日常操作與決策形狀

IAM Conditions 收 scope：GSM 的 secretAccessor role 預設綁到 secret resource、但組織常見錯配是給整個 project 上 roles/secretmanager.secretAccessor — 等於整個 project 所有 secret 都能讀。應該用 per-secret binding、再加 IAM Conditions（resource.name.endsWith('prod-db-password')、request.time < timestamp('...')）限縮時間窗口。對應 Okta Cloudflare 2023 supply chain 的對照啟示：第三方 token scope 過寬時、上游事件直接傳導下游、IAM Conditions 是收 scope 的工具。

Secret Version + Alias 模型：每個 secret 有 monotonic version（v1、v2、v3…）、預設 alias latest 指向最新 enabled version。rotation 不是「更新現有 secret」、是 建立新 version + 把舊 version disable。應用端要支援 讀新 version 失敗時 fallback 舊 version、或在 rotation Cloud Function 內實作 雙軌驗證窗口（新版本上線後一段時間舊版還能讀、確認所有 consumer 切過去再 destroy 舊版）。沒這層設計、一次 rotation 就會打掉沒及時更新的 consumer。

CMEK（Customer-Managed Encryption Key）：GSM 預設用 Google-managed key、production 應該指向 Cloud KMS CMEK。意義是 把 key 持有跟 secret 取用分離 — 即使 secret admin 被攻破、沒有 CMEK 的 decrypt 權限拿不到明文。代價是 CMEK key region 跟 secret replication 要對齊（key 在 us-central1 但 secret 設 automatic replication = key 進不去其他 region、secret access 會失敗）。

Replication 策略：automatic 是 GCP 自動跨 region replicate（高可用、不需要管 region 一致性、但 data residency 受 GCP 全球策略支配）；user-managed 是手動指定 region list（精細控制資料駐留、適合有 GDPR / 跨境合規需求的場景、但 region 加減要自己管 + CMEK key 要在每個指定 region 都存在）。一個常見錯配：選 user-managed 但只設一個 region — 等於沒有跨 region 冗餘、該 region 出事 secret 完全讀不到。

Rotation 是自管 schedule：GSM 提供的不是 rotation logic、是 Rotation Schedule（cron 或固定間隔）、到期會發 Pub/Sub message 到指定 topic、由 自己寫的 Cloud Function / Cloud Run 訂閱該 topic 執行實際 rotation（呼叫上游系統 API 生新 credential、寫成新 secret version、disable 舊 version）。對應 Failure: Credential Rotation Without Scope：rotation Cloud Function 必須自己處理 scope map（哪些 consumer 用了同一把 secret）跟 雙軌驗證窗口（confirm 所有 consumer 切到新版本才 disable 舊版）、不像 AWS Secrets Manager 有 built-in 四階段 flow（createSecret → setSecret → testSecret → finishSecret）。

Workload Identity Federation 取用：external workload（GitHub Actions / AWS workload / Azure workload / on-prem K8s）用 WIF 拿 GSM secret 是現代預設模式 — workload 用自己的 OIDC token（GitHub OIDC、AWS STS）跟 GCP STS 交換 short-lived access token、再用 token 呼叫 GSM。避開了「長期 service account JSON key 散落 CI / 第三方環境」的問題。GKE 內 workload 走 GKE Workload Identity（pod ServiceAccount → GCP service account 綁定）取 secret、也是同 mindset。

Audit log 治理：GSM 的 audit 分兩層 — Admin Activity（create / delete / IAM 變更、預設開、免費）、Data Access（AccessSecretVersion、預設 關、開啟有 log 量跟 BigQuery export cost）。production 不開 Data Access = 事故時 連 secret 被誰取過都查不到、必須在 project IAM Audit Config 開、Cloud Logging sink 推到 SIEM 或 BigQuery（見 7.13 偵測覆蓋率與訊號治理）。

核心取捨表

選 GSM 的核心訴求：workload 主要跑在 GCP（GKE / Cloud Run / Cloud Build）、已經用 Workload Identity Federation 收 service account key、secret 形態以 static 為主（DB password、third-party API key、private key）、rotation 邏輯願意用 Cloud Function 自寫。要跨雲、要 dynamic credential、要內建 rotation flow、需要 transit encryption — 走 Vault。

進階主題

CMEK + Cloud KMS 雙軌權限分離：production 應該 至少 把 prod secret 的 CMEK key 跟 secret IAM 分到不同 admin group — secret admin 可以建 / 改 secret 但不能 decrypt（沒 KMS cloudkms.cryptoKeyDecrypter），KMS admin 可以管 key 但不能讀 secret 內容。對應 Microsoft Storm-0558 signing key chain 的對照啟示：key 不離 KMS 邊界、跟 HSM-bound 同 mindset；CMEK 是把這個原則內建到 secret 路徑。

Berglas（OSS pattern）：Berglas 是 Google 開源的 GSM client library + CLI、在 Cloud Run / Cloud Function / GKE 啟動時把 sm://... 參考自動 resolve 成實際 secret value、注進環境變數或檔案。比起應用端寫 SDK 取 secret 的好處：secret 不進 container image / build manifest、只有 runtime 取得；缺點是多一層 dependency、且 Berglas 自己有 IAM 需求要管。

GKE Workload Identity 取用：GKE pod 用 ServiceAccount → IAM service account 綁定（透過 iam.gke.io/gcp-service-account annotation）、pod 內呼叫 GSM API 自動帶 GCP service account 身份、metadata server 簽 token。比起把 service account JSON key mount 進 pod、Workload Identity 沒有長期 credential 在 pod 內、credential rotation 由 GCP metadata 自動處理。

Secret rotation Cloud Function 樣板：訂閱 secret 的 rotation topic（Pub/Sub）、message 帶 secret name 跟 trigger reason；Function 內呼叫上游系統 API（DB / SaaS）生新 credential、用 secretmanager.AddSecretVersion 寫新 version、等一段時間（雙軌驗證窗口）後 DisableSecretVersion 舊 version、最後 DestroySecretVersion 完成 rotation。雙軌窗口的長度必須大於 consumer 的最長 cache TTL、否則沒及時 refresh 的 consumer 會在 disable 後失敗。

Pub/Sub event subscription（new in 2023+）：除了 rotation schedule 自動發 event、GSM 也支援對 secret 任意變更（new version、IAM change）發 Pub/Sub message、可接 SOAR / SIEM 做 secret 異常變更告警（例：非 CI service account 在週末新增 secret version）。

排錯與失敗快速判讀

• 取 secret 拿到 PERMISSION_DENIED：通常是 IAM binding 在 project 層但 secret 在某 sub-resource、或 IAM Conditions 把當前 caller 排除 — 用 gcloud secrets get-iam-policy 直接看 binding、確認 condition 表達式
• CMEK 設定後突然讀不到 secret：CMEK key region 跟 secret replication region 不對齊、或 caller 沒有 KMS decrypt 權限 — 確認 key 在所有 replication region 都有版本、secret accessor service account 有 cloudkms.cryptoKeyDecrypter
• Rotation Cloud Function 跑了但 consumer 認證失敗：雙軌窗口太短或 consumer 沒實作 latest version 失敗 fallback、舊版 disable 後孤兒 consumer 直接斷 — 把雙軌窗口拉到 cache TTL × 2、補 fallback 邏輯
• Data Access audit 沒紀錄：預設關、要在 project IAM Audit Config 明確開 secretmanager.googleapis.com 的 DATA_READ — 不開等於沒辦法回答「事故當下誰讀了 secret」
• External workload 拿不到 secret：Workload Identity Federation 的 provider attribute mapping 沒對齊（GitHub OIDC token 的 repository claim 沒被 map 到 attribute condition）— 走 gcloud iam workload-identity-pools providers describe 看 mapping、用 token introspection 驗實際 claim
• Secret version 累積過多：rotation 只 disable 不 destroy、版本無限長 — 加 lifecycle policy（手動 / Cloud Function 排程）destroy 超過 N 個版本以前的舊版
• GKE pod 用 Workload Identity 但拿不到 secret：通常是 GKE 沒 enable Workload Identity feature、或 iam.gke.io/gcp-service-account annotation 拼錯、或 GCP service account 沒給 K8s ServiceAccount iam.workloadIdentityUser — 三層都要對才能通

何時改走其他服務

不在本頁內的主題

• GSM 完整 REST API 跟 gcloud secrets 詳盡子命令
• Cloud KMS key lifecycle 跟 rotation 細節（看 Google Cloud KMS 章）
• Workload Identity Federation 完整設定步驟（attribute mapping、condition expression、provider 設定看 Google Cloud IAM 章）
• Berglas 完整 CLI 用法
• Cloud Function / Cloud Run 部署細節
• GCP Organization Policy 跟 secret 跨 project 共享的進階場景

案例回寫

GSM 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：HashiCorp Vault、AWS Secrets Manager、Azure Key Vault
• 下游：Google Cloud KMS（GSM CMEK 後端、key custody 分離）
• 下游：Google Cloud IAM（secret IAM binding、Workload Identity Federation 設定）
• 跨模組：8 事故處理 vendor 清單（GSM 事件如何 routing 進 IR 流程）
• 官方：Secret Manager Documentation

服務定位

Keycloak 是 自管控制面 的 human identity 與 federation engine、不是 cloud resource permission engine。跟 Okta / Auth0 的本質差異在於信任邊界落點：SaaS IdP 把 signing key、tenant 隔離、support workflow 都託管出去、客戶承擔「供應商出事我也跟著被打」的風險；Keycloak 把整條控制面收回自家機房或自家 VPC、客戶承擔「signing key 過期 / DB 崩 / Java app CVE 沒跟上」的運維風險。

跟 cloud-native SSO（AWS IAM Identity Center）相比、Keycloak 的核心優勢是 不綁雲廠 + 可深度客製 authentication flow + 資料不出境。適合垂直：金融、政府、醫療某些不接受 SaaS IdP 的場景；以及預算敏感、員工數中等、SRE 量能足以接 24/7 on-call 的組織。

本章目標

讀完本頁、讀者能判斷：

1. Keycloak 該承擔哪一段 identity 控制（SSO / MFA / federation / brokering）、哪一段該交給雲端 IAM 或下游應用
2. 自管 IdP 的最低運維基線（HA、DB DR、cert / signing key rotation、CVE cadence、SIEM 接點）
3. Realm / Client / User Federation / Identity Broker / Authentication Flow / SPI 各自的決策時機與陷阱
4. 何時用 Keycloak、何時改走 SaaS（Okta / Auth0）或其他 OSS（Authentik / Zitadel）

最短判讀路徑

判斷 Keycloak 部署是否健康、最少看 SaaS IdP 的四件事加上自管特有的四個維度：

• 誰能做什麼：master realm admin 的人數、是否走 access request workflow、admin console 是否限 IP / device trust、是否強制 phishing-resistant 認證
• 憑證在哪裡：client secret 是否走 secret management、realm signing key 的 rotation 排程、admin token 的 TTL
• 入口如何暴露：哪些 realm 對外、reverse proxy / Ingress 是否做 rate limit、admin console（/auth/admin）是否限內網或 zero trust
• 證據是否可回查：Event Listener SPI 是否接 SIEM、admin event 跟 login event 是否分流、保留期是否符合稽核
• DB 健康：PostgreSQL / MySQL 是否跨 AZ、是否有 PITR、是否做過 restore 演練（不是只有備份成功訊息）
• Cert lifecycle：TLS cert 與 realm signing key 各自的 rotation 排程、是否走 Website Certificate Lifecycle 自動化
• HA topology：Keycloak cluster 是否多節點、Infinispan cache 是否跨 AZ、單節點重啟是否會踢掉所有 session
• Upgrade cadence：Keycloak 每年 major release、CVE patch 是否能在 SLA 內上、是否有 staging 跑 DB migration

八個維度任一缺失、都是自管 IdP 常見事故的入口。

日常操作與決策形狀

Realm 設計：Realm 是 Keycloak 的隔離邊界、每個 realm 有獨立的 user store、client、role、signing key。multi-tenancy 走 realm 是正確選擇、但 master realm 能管所有 realm、master realm 的 admin compromise = 全公司 IdP compromise。把 master realm 鎖在內網、operational realm 才對外、是基本姿勢。

Client 註冊與 secret：每個應用是一個 client、confidential client 有 secret、public client（SPA / mobile）走 PKCE 不存 secret。client secret 不存 source code、走 secret management 注入。client 數量爆炸時要設 naming convention 跟 ownership 標記、不然 stale client 會堆積。

User Federation：把既有 LDAP / Active Directory 接進 Keycloak、user 還是住在原 directory、Keycloak 做 protocol 翻譯（LDAP → OIDC / SAML）。這是 Keycloak 強項之一 — 不需要 user migration、漸進接入。陷阱是 LDAP 連線健康 = IdP 健康、LDAP 慢 = 全公司 login 慢。

Identity Brokering：把外部 IdP（Google、Microsoft、其他 SAML / OIDC provider）federate 進來、Keycloak 當中介。B2B 合作常見模式 — partner 用自己的 IdP、不在我的 user store 開帳號。決策點是 trust mapping：外部 claim 怎麼對應到內部 role、外部 IdP 的 MFA 狀態怎麼信任。

Authentication Flow：Keycloak 把 login / registration / reset password 做成可編輯的 flow DAG、可以插入自訂 step。這是 Keycloak 跟 SaaS IdP 最大差異點之一 — 想要 step-up MFA、device fingerprint、risk-based 判斷都可以自己接。雙面刃是 自訂 flow 容易留漏洞：跳過必要步驟、condition 寫錯讓 MFA 變可選、custom Authenticator SPI 沒處理 race condition。

Theme / 客製 UI：Keycloak 支援 theme override、可以改 login page HTML / CSS / JS。custom JS 在 login page = 自己注入 XSS 風險 — theme 寫進去之後就是 IdP 本體的攻擊面、不是普通網頁。CSP 跟 input sanitization 要當成 IdP 安全規範看待。

Event Listener / Audit：Keycloak 預設只把 event 寫進 DB、UI 上能查、但 不會自動推到外部 SIEM。生產環境必須接 Event Listener SPI（內建 jboss-logging、或自寫 Kafka / file listener）把 admin event 跟 login event 推進 SIEM。沒接的話 audit trail 只在 IdP 本機、IdP 出事就拿不到 evidence。

Exception / break-glass：master realm 留至少 2 個 break-glass admin、credential 離線存、走獨立 MFA（hardware key）。Keycloak cluster 整個失聯時、用 break-glass 直連 DB / 直連單一節點救回。

核心取捨表

選 Keycloak 的核心訴求：資料主權 + 預算控制 + 客製 flow 需求、且有 SRE 團隊能 24/7 on-call、能接受自管的運維重量。團隊小於 50 人沒 SRE 量能、應用主要在 SaaS（pre-built integration 用不上 Keycloak 強項）、需要快速接 7000+ SaaS app — 都該回頭看 Okta / Auth0。

進階主題

User Federation 跟 LDAP 整合：企業環境常見「Active Directory 是 user source of truth、Keycloak 做 protocol 層」。注意 LDAP 同步策略（read-only / writable / import）、LDAP 健康直接影響 IdP 可用性、LDAP timeout 要設嚴格避免 login 卡住整個 cluster。

Identity Brokering 跟外部 IdP：把 Google / Microsoft / 其他 SAML IdP federate 進來、外部 user 進來時 Keycloak 自動建 link。trust mapping 是關鍵 — 外部 IdP 宣稱「這個 user 已 MFA」、要不要信？外部 group claim 怎麼對應到內部 role？沒有預設答案、要用 authorization 邊界決定。

Fine-Grained Authorization（UMA / Authorization Services）：Keycloak 內建 policy engine、可以做 resource-level 授權（不只是 role-based）。適合需要中央化 policy decision 的場景、但會把應用的授權邏輯綁進 Keycloak、退場成本變高。多數場景應該把 authorization 留在應用內、Keycloak 只做 authentication + role token 發行。

Custom Authenticator SPI：用 Java 寫自訂 authenticator、插進 Authentication Flow。能做 step-up MFA、device posture、risk score 判斷。陷阱是 SPI 程式碼就是 IdP 本體的一部分、bug = IdP 漏洞、必須走完整 code review + 安全測試流程、不能當普通 feature 開發。

Realm signing key rotation：每個 realm 有自己的 RSA / EC signing key、用來簽 ID token / SAML assertion。rotation 必須跟下游 client 協調（key rollover 期間 client 要能接受新舊 key）、否則 rotation 當天全公司 login 失敗。分域分批是必做的、參考 Failure: Credential Rotation Without Scope。

排錯與失敗快速判讀

• DB 是 SPOF：Keycloak 所有 state 在 PostgreSQL / MySQL、DB 出事 = IdP 停 = 全公司 SSO 停。跨 AZ replication + PITR + 季度 restore 演練、不是 nice-to-have
• Cert / signing key 過期：自管 IdP 最常見事故、TLS cert 過期擋對外 endpoint、realm signing key 過期讓所有 token 變無效。走 Certificate Rotation 自動化、過期前 30 天 alert
• Cluster split-brain：Infinispan cache 跨節點同步、網路分區時 session 狀態不一致、user 看起來登入但下一個 request 又被踢出。HA topology 設計要考慮 cache mode（distributed vs replicated）、network 健康監控要 alert split-brain
• Major upgrade 卡 DB migration：每年 major release 帶 schema migration、staging 沒跑過就 production 升級 = 數小時 downtime。upgrade plan 包含 rollback DB snapshot + staging full rehearsal
• Custom theme / Authenticator 留漏洞：theme JS 引入 XSS、custom Authenticator 跳過 MFA、SPI 沒處理 race condition。把 IdP 客製當成 supply chain 看待、走 code review + 安全測試
• Event 沒進 SIEM：預設只在 Keycloak DB、IdP 出事就拿不到 evidence。Event Listener SPI 接 Kafka / file / SIEM、admin event 跟 login event 各自接 alert runbook
• Master realm admin 過多：日常工作不該用 master realm admin、應該在 operational realm 開有限權限 admin。master realm 是 single point of compromise

何時改走其他服務

不在本頁內的主題

• Keycloak 完整 SAML / OIDC 規格細節、SPI Java API 文件
• Red Hat build of Keycloak 商業支援的差異與授權細節
• Keycloak Operator（Kubernetes deployment）的逐步部署教學
• LDAP / Active Directory 各種 schema 對應規格

案例回寫

Keycloak 沒有直接的廠商級公開事件（OSS 沒有 vendor incident 的對應形態）、自管 IdP 的失效模式以下分兩類整理：跨 vendor 共通的 同構失效 用既有 case 對照、自管 IdP 特有 的失效情境補敘事說明、避免案例表變成「同一個 frame 拼四個 case slug」。

對照引用（跨 vendor 同構失效）：

自管 IdP 特有的失效情境（沒有對應公開 vendor case、來自自管運維常見事故樣態）：

• Cert 過期讓全公司 SSO 卡死：Keycloak signing cert / TLS cert / 後端 DB cert 都自己管、任何一張過期 = login 全停。Okta / Auth0 客戶不會遇到這個失效面（vendor 自己 rotate）— 自管組織必須有 cert lifecycle monitoring（Prometheus exporter + alert）+ 季度 rotate rehearsal、不能等 Let’s Encrypt / 公司 PKI 發過期通知才動
• Major upgrade 卡 DB migration 變數小時 downtime：Keycloak 每年 major release 帶 schema migration、若 staging 沒 full rehearsal 就 production 升級、可能遇到 migration 比預期慢 5-10 倍、整個維護視窗炸掉。對照 Okta / Auth0：vendor 自己升、客戶感知是 minutes-level、不是 hours-level
• Realm scope 在小規模時用法跟大規模衝突：Contrast: Identity Governance by Scale 揭示不同規模治理模式差異 — 小團隊用單一 realm 順、團隊長大後該拆 realm 卻沒拆、最後 admin compromise blast radius 變整個組織。Keycloak 比 SaaS IdP 更容易踩到、因為 realm 拆分要自己決定時機、沒 vendor 推使用者升級 tier
• DB 是 SPOF、自管沒做好 = SSO 跟 DB 一起死：Keycloak 用 PostgreSQL / MySQL 存 user / session / signing key、DB 出事 = IdP 停。跨 AZ HA + 跨 region DR + 季度 failover 演練是硬性要求、不是 nice-to-have；SaaS IdP 客戶不會遇到這個層次的失效面

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor、Auth0 vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM / Azure RBAC（Keycloak 之後的 cloud resource permission 層）
• 跨模組：8 事故處理 vendor 清單（自管 IdP 事件如何 routing 進 IR 流程）
• 官方：Keycloak Documentation

讀完本章後、你應該能對自己用的 tool / MCP server 回答：能讀寫哪些路徑、能跑哪些 shell command、能連哪些網路位址、副作用有沒有 dry-run / preview、出錯時怎麼回退。

本章目標

1. 認識 tool use 跟 MCP server 在三層架構中的位置。
2. 區分「讀取類 tool」跟「副作用類 tool」的權限判讀差異。
3. 知道個人 dev 場景下、第三方 MCP server 的信任邊界跟驗證流程。
4. 用「沙箱 / 白名單 / 副作用可逆性」三個維度評估具體 tool / MCP 的風險。
5. 認識常見的 tool use 副作用洩漏路徑跟對應的最低防護。

tool use 跟 MCP server 在哪一層

tool use 跟 MCP server 同時跨三層架構 的兩層、但跟模型本身的權限模型分離：

 1介面層（VS Code / Continue.dev / CLI）
 2  ↓
 3推論伺服器（Ollama / llama-server / LM Studio）
 4  ↓
 5模型（GGUF 權重）
 6
 7旁邊另一條：
 8  ↓
 9MCP server（獨立 process、自己的權限）
10  └── 對檔案 / shell / 網路的具體 API

關鍵特性：

1. 模型本身不執行 tool：模型只生成 tool call JSON、實際執行由「LLM client」（如 Continue.dev、Claude Desktop）跟 MCP server 完成。
2. MCP server 是獨立程式：可以是 Node / Python script、可以呼叫任何系統 API、權限上限是「跑該 server 的 user 的權限」。
3. 權限不是模型給的、是 OS / user 給的：模型再怎麼「同意」執行 rm -rf /、實際上能不能跑取決於 OS 的權限模型跟 MCP server 自己的 sandbox。

事實查核註：Model Context Protocol（MCP） 是 Anthropic 在 2024 年底發布的開放協議、各家 LLM client 跟 MCP server 實作的成熟度、權限粒度依版本演進。本章描述以 2026 年 5 月主流實作為基準、引用前以 MCP 官方規格跟各 client / server 的 README 為準。

「讀取類」跟「副作用類」tool 的權限差異

tool 可以粗分成兩類、權限判讀完全不同：

讀取類的判讀重點是「讀到的內容會被傳到哪」：

1. 讀到的 code 變 prompt 的一部分、prompt 送到本地模型→沒外洩
2. 同樣 prompt 送到雲端 LLM→傳到雲端、跟雲端 LLM 的資料政策走（見 6.4 跨雲端 / 本地資料邊界）
3. 讀取會被 log→log 累積、需要管理

副作用類的判讀重點是「可逆性」：

1. write file 蓋掉原內容→可能無法回復（沒備份的話）
2. run shell rm / git push→不可逆或需要 force pull 才能還原
3. 發 HTTP request、轉帳、call API→送出去就回不來
4. 操作 production 資料庫→可能影響其他人

三個維度評估具體 tool / MCP 的風險

對任何 tool / MCP server、可以用三個維度做初步評估：

 1┌────────────────────────────────────────────────────┐
 2│ 維度一：沙箱                                       │
 3│   能做什麼 = 跑該 server 的 user 能做什麼          │
 4│   有沒有 chroot / Docker / namespace 隔離？        │
 5│                                                    │
 6│ 維度二：白名單                                     │
 7│   能讀寫的路徑、能跑的指令、能連的網址有沒有限定？  │
 8│   還是 "all paths" / "any shell" / "any URL"？     │
 9│                                                    │
10│ 維度三：副作用可逆性                               │
11│   出錯能不能 rollback？                            │
12│   有沒有 dry-run / preview / confirm？             │
13└────────────────────────────────────────────────────┘

對應的判讀範例：

實務上、社群常見的 MCP server 多半屬於「白名單較弱」「副作用直接套用」的設計、需要使用者自己加防護。

第三方 MCP server 的供應鏈信任

MCP server 是可執行程式碼、信任邊界比 GGUF 模型權重高一個層級。常見的 MCP server 來源：

1. 官方 reference server（如 Anthropic 維護的 @modelcontextprotocol/server-*）：相對較高信任、有官方 maintain。
2. 知名專案的 MCP server（如 GitHub、Notion、Slack 等公司自己出的）：跟該公司的軟體分發信任度一致。
3. 社群 MCP server：個人或小團隊維護、信任度視 maintainer 與 download 量、看 code 是基本動作。

裝任何 MCP server 前的最低判讀：

1. 看 source repo：是不是知名作者、stars 數、最後 commit 時間、issues 是否活躍。
2. 看實際做什麼：MCP server 的 README 通常列出提供的 tools、跑起來會碰到的權限。
3. 跑在最小權限環境：能用 Docker / chroot / nice -n 19 之類就用、不要直接用 root / admin。
4. 不要用 curl | sh 安裝：用 npm install / pip install / go install 等有 package manager 介入的方式、留下 install log。

事實查核註：MCP server registry、套件管理工具的供應鏈安全機制依版本演進、Anthropic 跟其他主要 client 廠商可能引入官方 marketplace 或簽章機制、建議引用前以當前 MCP 官方狀態為準。

個人 dev 場景的最低防護建議

對「我想用 tool use 但又怕 LLM 把檔案搞壞」的工作流、最低防護建議：

1. codebase 用 git track：所有寫入操作前確認 working tree clean、出問題能 git checkout 還原。git stash 是更輕的選擇。
2. 重要檔案 backup：dotfile、SSH key、雲端 API key 等不在 git track 範圍的、用 Time Machine / rsync / cloud sync 之類做日常 backup。
3. 跑 LLM agent 時用獨立 user / 容器：對「想試 agent 但怕」的場景、開個專用 macOS user 或 Docker container、user 沒 sudo、檔案存取限定 workspace。
4. MCP server 的 config 加白名單：能設 allowed paths / allowed commands / allowed URLs 的 server 都先設、預設拒絕、按需開放。
5. 看不懂的 tool call 不要 confirm：Continue.dev / Claude Desktop 等 client 通常會 prompt 使用者確認 tool 執行、看不懂的 JSON 先別按。

tool use 副作用洩漏的常見路徑

個人 dev 場景常見的 tool use 副作用洩漏路徑：

1. LLM 誤把 secret 寫進 commit：tool use 帶 git commit、LLM 從 .env 讀到 API key 又寫進 commit message。對應防護：MCP server 加 .env 黑名單、commit hook 掃 secret。
2. LLM 套用 broken patch 蓋掉檔案：apply_patch 失敗 / 部分套用、留下無法 compile 的狀態。對應防護：套 patch 前 git stash 或 git add -p 先存 working tree。
3. LLM 從 issue / PR 內容引發指令：讀進 issue 的 prompt 內容包含 prompt injection、誘導跑非預期指令。對應防護：tool 跑前明確讓使用者確認（見 6.3 prompt injection）。
4. LLM 觸發 production 操作：MCP server 連到 production DB、LLM 跑 DROP TABLE。對應防護：production credential 絕對不放在 tool use 可達的環境。

給讀者的 tool / MCP 評估清單

每次裝新 MCP server / 啟用新 tool 之前、跑一次評估：

1[ ] 來源是知名作者 / 官方專案 / 我能 audit 的開源 repo
2[ ] README 列出的 tool 列表、跟我的使用情境匹配
3[ ] 該 server 跑在最小權限環境（user / sandbox / container）
4[ ] 副作用類 tool 有 confirm / preview 機制
5[ ] workspace 內容受 git track、能 rollback
6[ ] 不放 production credential / SSH key 在該 server 可達的環境
7[ ] 啟用後跑簡單測試、確認 tool call 行為符合預期

下一章

下一章：6.3 IDE 場景的 prompt injection、處理 tool use 副作用最常見的觸發來源。

觀察

Azure AD 控制面事件導致多個依賴身份驗證的服務受影響，事故處理需要同時兼顧身份恢復與服務降級策略。

判讀

當身份系統是共同依賴，問題會跨產品線傳播，必須把身份恢復路徑與業務優先序綁定管理。

策略

1. 建立身份控制面的降級與隔離策略。
2. 讓關鍵服務支援有限模式運行。
3. 在 incident command 中獨立處理 identity workstream。

下一步路由

回 7.2 identity and access boundary 與 8.8 security vs operational incident。

引用源

• Azure AD 2021 incident

IP 截斷

IP 位址是最常見的個人識別欄位。完整的 IPv4 位址（192.168.1.50）可以定位到特定的網路和裝置；截斷後的 IP（192.168.1.0）保留網段資訊但無法定位到特定裝置。

截斷策略

IPv4 末八位清零：192.168.1.50 → 192.168.1.0。保留 /24 網段資訊，足以判斷「使用者在哪個網段」但無法定位到特定裝置。Google Analytics 採用這個策略。

IPv4 末十六位清零：192.168.1.50 → 192.168.0.0。更強的去識別化，但地理定位精度降低到城市級。

IPv6：截斷更多位元。IPv6 的後 80 位通常包含 MAC 位址衍生的 interface ID — 截斷到 /48 前綴保留 ISP 資訊，移除裝置識別。

實作位置

IP 截斷應在 collector 收到事件後、寫入儲存前執行。SDK 端不做 IP 截斷 — SDK 通常不知道自己的外部 IP（知道的是 NAT 後的內部 IP），外部 IP 是 collector 從 HTTP request 的 source IP 取得的。

User Agent 簡化

User agent 字串包含瀏覽器版本、OS 版本、裝置型號 — 組合起來可能形成唯一的 fingerprint。簡化 user agent 保留有用的分類資訊（「iOS 17 上的 Safari」），移除可用於 fingerprinting 的細節（「iPhone 15 Pro Max, Build/22A3354」）。

簡化規則

保留：平台（iOS / Android / Windows / macOS）、主要版本號（iOS 17、Android 14）、瀏覽器類型（Safari / Chrome / Firefox）。

移除：minor version、build number、裝置型號、CPU 架構、語言設定。

1原始：Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X)
2簡化：iOS/17 Safari

Stack Trace 路徑清理

Error 事件的 stack trace 包含檔案路徑。檔案路徑可能洩漏部署結構（/home/deploy_user/app/v2.3.1/src/...）或開發者的個人資訊（/Users/alice/projects/...）。

清理規則

移除使用者目錄前綴：/Users/alice/projects/app/src/main.dart:42 → src/main.dart:42。保留 source file 相對路徑和行號，移除使用者名稱。

移除部署路徑前綴：/opt/deploy/releases/20260619/app/lib/... → lib/...。保留程式碼結構，移除部署細節。

統一 path separator：Windows 路徑（C:\Users\...）和 Unix 路徑（/home/...）統一處理。

清理規則用正則表達式匹配常見的路徑前綴模式，替換為空字串。自訂的部署路徑格式需要在 collector 設定中額外註冊。

Session UUID

Session ID 用於關聯同一次使用中的多個事件。UUID v4（隨機產生）作為 session ID，沒有可預測性、沒有順序性、無法回推使用者身份。

Session ID 的生命週期

SDK 在初始化時產生一個 UUID v4 作為 session ID，所有事件附帶這個 ID。App 重新啟動時產生新的 session ID — 前後兩次使用的事件無法關聯。

這個設計讓分析粒度限制在「一次使用」而非「一個使用者」。如果需要跨 session 關聯（例如計算 DAU），需要另一個 persistent ID — 但 persistent ID 本身就是可識別資訊，需要使用者同意。

避免使用可識別的 ID

裝置 ID（IDFA / GAID）、安裝 ID、使用者帳號 — 這些可以關聯到特定個人，不適合作為監控系統的 session ID。使用 UUID v4 確保 session ID 的唯一性來自隨機性而非身份。

去識別化是資料保護的一環，另一環是在資料離開 client 之前就處理 — SDK Redaction API 設計從 SDK 端攔截敏感欄位。法規層面的具體要求見 GDPR 最小化原則的工程落地。去識別化完成後的資料才能用於行為分析 — 這是商業利用的入場條件。

服務定位

IAM Identity Center 是 人類身份進 AWS 的 portal、不是 cloud resource permission engine。它跟 AWS IAM 的分工是兩層：Identity Center 管「人是誰、能登入哪些 account」、AWS IAM 管「進到 account 後對 resource 能做什麼」。實際機制是 Identity Center 透過 Permission Set 在每個目標 account 建一個 AWSReservedSSO_* 命名的 IAM role、使用者 assume 該 role 拿短期 STS token。

跟 Okta 相比、Identity Center 的核心優勢是 跟 AWS Organizations + Control Tower 原生整合、Permission Set 可以一次發佈到數百個 account、不必每個 account 各接 SAML。代價是 SaaS app integration 量級遠少於 Okta（Okta 7000+ 預建、Identity Center 僅中等規模）、跨雲 federation（GCP / Azure）也不在原生範圍。

許多大型組織採三層架構：Okta 是 HRIS 下游的 identity source of truth、SCIM push 進 Identity Center、Identity Center 再 map 到 AWS IAM Permission Set。Okta 管「人是誰」、Identity Center 管「AWS portal 入口」、AWS IAM 管「resource 能做什麼」。中小組織可以省略 Okta、直接用 Identity Center 內建 user store、但就失去跨 SaaS 統一 SSO。

本章目標

讀完本頁、讀者能判斷：

1. Identity Center 在 人類身份 / AWS portal / resource permission 三層裡的位置、何時該交回 AWS IAM 或上游 IdP
2. Identity Source 選擇（內建 / Active Directory / 外部 SAML）對 lifecycle 與 lock-in 的長期影響
3. Permission Set / Account Assignment / Access Portal 三個核心概念的稽核重點
4. 何時 Identity Center 夠用、何時要疊 Okta 在前、何時 Identity Center 反而是錯選擇

最短判讀路徑

判斷 Identity Center 配置是否健康、最少看四件事：

• 誰能 assume 哪個 role：Permission Set 跟 Account Assignment 是否走最小權限、AdministratorAccess 範圍 Permission Set 是否限定 break-glass、是否強制 phishing-resistant 認證 才能 assume 高權限
• Permission Set 邊界：每個 Permission Set 的 session duration（預設 1 hour、可調 12 hour）、inline policy vs Customer Managed Policy reference、是否用 ABAC tag 收斂跨 account 散佈
• External IdP federation 狀態：Identity Source 是內建 / AD / 外部 SAML、若走外部 IdP SCIM push 是否監控 sync 失敗、signing certificate 是否在 rotation 排程內
• CloudTrail 是否完整：Identity Center 事件分布在 management account 跟 member account、是否有 organization trail 收齊、admin 變更 / Permission Set 變更 / failed assume 是否 alert

四件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Identity Source 是根信任：Identity Center 支援三種 user/group 來源 — 內建 store、AWS Managed AD / on-prem AD via AD Connector、外部 SAML IdP（Okta / Entra ID 等、SCIM 推進來）。選了之後 user lifecycle 從哪來就鎖死、換 Identity Source 是大工程（要重建所有 Permission Set assignment、舊 user GUID 不通用）。早期決定錯比 Permission Set 設錯難救。

Permission Set 是 cross-account role template：定義一次、apply 到多 account、實際在每個 account 部署成一個 AWS-Reserved 命名的 IAM role。Permission Set 本身不是 role、是 role 的部署模板 — 改 Permission Set 會 push 到所有 account 上對應的 role。Customer Managed Policy reference 比 inline policy 好維護、但要先確保每個 target account 都有同名 policy、否則 assignment 會失敗。

Account Assignment：把 user/group 綁到 Permission Set + 特定 account 的三元組。這層用 group 而不是個別 user、跟著 Identity Source 的 group 變動自動同步。臨時權限（離職員工延長、incident 應變）走 access request workflow 或 IAM Access Analyzer + Just-in-Time、不要永久 assignment。

Access Portal URL 是 phishing 目標：custom URL（https://<alias>.awsapps.com/start）設定後變成員工每天用的入口、phishing 攻擊會 mimic。要強制 phishing-resistant MFA（WebAuthn / passkey）、純 push MFA 抗不過 fatigue。CLI 走 aws sso login 自帶 browser-based flow、不要叫員工複製貼 access key。

Application assignment：Identity Center 也能管 SAML app 的 SSO assignment、但 integration 數量遠少於 Okta。大量 SaaS app 的場景應該疊 Okta 在前、Identity Center 只管 AWS portal。

核心取捨表

選 Identity Center 的核心訴求：AWS 是主要工作環境、員工 SaaS app 用量低、要統一多帳號入口而不要再付 Okta 訂閱。員工大量用 SaaS 的場景應該疊 Okta 在前。

進階主題

External IdP federation（Okta / Entra ID SCIM 進來）：Identity Center 接外部 IdP 是 push model — IdP 主動 SCIM push、Identity Center 不 pull。push provisioning 失敗會 silent（IdP 端有 log、Identity Center 端只看到 user 沒出現）、要在 IdP 端設 sync failure alert。SAML signing certificate rotation 兩邊都要排程、過期會整個 federation 斷。

Multi-account Permission Set 設計：避免每個 environment / team 各自一份 Permission Set — 用 ABAC（tag-based access control）把「Environment=Prod + Team=Payments」的條件寫進一個 Permission Set 的 policy、tag 跟著 user attribute 跑。Permission Set 數量爆炸是 Identity Center 老化最常見訊號。

Customer Managed Policy reference：Permission Set 可以 reference target account 裡的 customer managed policy（同名同 path）、policy 本身在每個 account 獨立維護。比 inline policy 適合大規模、但要靠 CI / Terraform 確保 policy 在所有 target account 同步存在、否則 assignment 失敗。

Session duration 是攻擊面：預設 1 hour、可調到 12 hour。長 session 對 dev 體驗友善、但不利於 credential rotation — 高權限 Permission Set（AdministratorAccess、production write）應該短 session（1-2 hour）、低風險 read-only 可放 8-12 hour。

IAM Identity Center API 不該當 workforce IdP 用：API 是給 admin 管 assignment 用、不是給 app 拿 user token。要 workforce app SSO 走 SAML / OIDC federation、不要叫 app 打 Identity Center API 查 user。

排錯與失敗快速判讀

• Permission Set 數量爆炸：每個 team / environment 各一份、上百個 Permission Set 沒人敢動 — 改用 ABAC + user attribute 把條件寫進 policy、收斂到十位數
• Identity Source 選錯難換：早期選內建 store、後來公司導入 Okta 要換成外部 SAML — 整個 user GUID 重新映射、Permission Set assignment 重綁、評估比建新 tenant 還久
• External SCIM sync 失敗 silent：Okta 端 push 失敗、Identity Center 沒人 — 要在上游 IdP 設 SCIM provisioning failure alert、不要等使用者反映「我登不進去」
• Access Portal URL 被 phishing：custom URL 員工記憶、phishing 站 mimic、無 phishing-resistant MFA 擋不住 — 強制 WebAuthn / passkey、員工教育只認 bookmark / SSO launcher
• CloudTrail 不完整：只開 management account trail、member account 的 role assumption 看不到 — 開 organization trail 收齊、特別 alert Permission Set 變更與失敗 assume
• Break-glass 缺席：Identity Center 控制面故障時 console 進不去 — 保留每個 account 的 root credential（離線存）跟少數 break-glass IAM User（hardware MFA、與 Identity Center 獨立 audit）、季度驗證

何時改走其他服務

不在本頁內的主題

• AWS IAM 的 policy / role / STS 機制細節（屬 AWS IAM vendor 頁）
• Permission Set 的 JSON policy 撰寫教學
• AWS Organizations / Control Tower 的完整架構
• 各 SaaS app SAML 接線教學

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor（外部 IdP 疊在前）、Auth0 vendor、Keycloak vendor
• 下游：AWS IAM vendor（Permission Set 落地的 resource permission 層）、Google Cloud IAM / Azure RBAC（多雲對照）
• 跨模組：8 事故處理 vendor 清單（Identity Center 事件如何 routing 進 IR 流程）
• 官方：AWS IAM Identity Center Documentation

服務定位

AWS KMS 的核心定位是 AWS-only 的 multi-tenant managed key management，FIPS 140-2 Level 3 認證、跨服務 envelope encryption 的共同地基。跟 CloudHSM 比、KMS 是 managed + shared HSM 池、CloudHSM 是 single-tenant dedicated HSM；需要更高隔離 / 自管 cluster / FIPS Level 3 single-tenant 時走 CloudHSM、或用 KMS Custom Key Store 把 KMS 後端指向自己的 CloudHSM。跟 Google Cloud KMS / Azure Key Vault 比、設計概念相近、但 KMS 把 secret store 切出去（Secrets Manager）、Key Vault 則把兩者合一。

跟 Vault transit engine 比、行為相似（key 不離 service、app 拿 ciphertext）、但治理面完全不同：KMS 綁 AWS 控制面、IAM + Key Policy 雙層授權、CloudTrail 是稽核入口；Vault transit 是跨雲統一介面、token + policy 為主、需要自管 cluster。AWS-heavy 組織首選 KMS、跨雲組織才會把 KMS 當下游、上游用 Vault transit 抽象。

本章目標

讀完本頁、讀者能判斷：

1. 哪些資料 / 場景該用 Customer Managed KMS Key、哪些 AWS Managed Key 已經夠用、什麼時候直接走 CloudHSM
2. Key Policy + IAM + Grant 三層授權的分工、production 必開的 CloudTrail Data event 與 monitor 範圍
3. Multi-Region Key、Custom Key Store、External Key Store、BYOK 等進階形態的取捨
4. KMS 出事（IAM 過寬、Key Policy 把自己鎖死、Schedule Deletion 誤觸發）時的判讀路徑跟回退選項

最短判讀路徑

判斷一個 AWS KMS deployment 是否健康、最少看四件事：

• Key Policy 設計：是否含 root principal（不然 key 變孤兒）、是否走 least privilege（不是 kms:* 給整個 account）、admin / user / monitor 三類 principal 是否分開、policy 變更是否走 PR review
• Grant 治理：哪些 service-to-service 短期授權走 Grant（rotation Lambda / RDS / EBS）、Grant TTL 是否設、廢棄 grant 是否定期 RetireGrant
• Multi-Region 與 rotation 策略：是否啟用 annual automatic rotation（適用 symmetric encryption key）、Multi-Region Key 的 replica 是否跟 DR plan 對齊、asymmetric / signing key 的 manual rotation 流程是否有 runbook
• CloudTrail Data Event 必開：management event 預設記、但 Encrypt / Decrypt / GenerateDataKey 是 data event、預設不記 — 沒這層 forensic 沒著力點、Storm-0558 對照下完全無法回答「誰用哪把 key 簽了什麼 token」