在經歷過前面 21 天的那麼多內容後，我們基本上來到系統開發的倒數第 2 個環節 發佈與運營監控 我們很終於走到了軟體開發生命週期的這個階段，可喜可賀可喜可賀，可以來杯柳橙汁休息一下。
產品發想與機會探索=>需求定義與優先排序=>產品設計與使用者體驗=>技術規劃與系統設計=>軟體開發與持續整合=>(current)發佈與運營監控...
許多團隊在這裡會鬆懈，認為最困難的開發工作已經結束，但從一個架構設計者或是管理者的角度看——無論是學術上還是業界實務上——「發佈與運營監控」 正是我們的系統從理論走向現實，從受保護的實驗室環境進入混亂、充滿敵意的真實世界的開始。
我們過去所學的商業邏輯定義、架構設計、數據結構與驗證，都是在為系統的「功能性」與「性能」打下基礎，現在，我們要探討的是系統的「生存能力」。一個再強大、再快速的系統，如果無法在真實的網路環境中生存下來，那它的價值就等於零。
而「零信任架構」（Zero Trust Architecture, ZTA）正是現代系統得以生存的基石。
過去，我們可能只會在大樓的入口處設置幾個警衛，檢查一下訪客證就放行了。這就是傳統的 「邊界防禦」 思維——只要進了門，就假設內部的人都是可信的。
但在現代環境中，威脅已經無所不在，威脅可能來自內部（ 惡意員工 、 被駭的內部帳號 ），也可能從意想不到的管道滲透（ 供應鏈攻擊、社交工程），一旦防線被突破，攻擊者就能在大樓內部暢行無阻，竊取任何房間的資料。這是一種脆弱且早已過時的安全模型 - 零信任，正是要從根本上顛覆這種思維。
身份是新的安全邊界 (Identity is the new perimeter) ，在零信任模型中，我們不再預設信任任何來自網路內部的請求，每一個存取系統資源的請求，無論其來源為何，都必須經過嚴格的身份驗證與授權，安全性不再是外加的檢查哨，而是內建於每一次互動中的驗證過程。
傳統的網路安全模型建立在一個基本假設上：邊界內的流量是可信的。這種模型就像中世紀的城堡防禦策略，在網路周邊建立強大的防火牆和入侵檢測系統，一旦攻擊者進入內網，他們就可以相對自由地橫向移動。
在雲端環境中，這種模型面臨根本性的挑戰：
傳統邊界防禦的局限性：
✗ 雲端資源的動態性使邊界變得模糊
✗ 遠程工作使企業邊界消失
✗ 內部威脅無法被邊界防禦阻止
✗ 一旦被突破，橫向移動難以阻止
零信任的核心原則：
在零信任模型中， 身份 取代了 網路位置 成為安全決策的核心要素。每個請求都必須經過嚴格的身份驗證、授權和持續監控。
零信任決策流程：
Who: 使用者身份驗證 (User Identity)
What: 資源與權限檢查 (Resource & Permissions)
When: 時間與行為分析 (Time & Behavior)
Where: 地理位置與設備檢查 (Location & Device)
Why: 業務合理性驗證 (Business Justification)
How: 安全狀態評估 (Security Posture)
其實 「信任管理 的系統應用在某種程度上跟約會很像，要不我們就用與人相處的這個 「信任管理」 模式來聊聊吧!
首先我們來看看 傳統的「邊界防禦(城堡與護城河)」，這就像是舊時代的相親，或是只在特定菁英社群裡找對象(例如：名校校友、同個信仰、家人介紹的朋友)。這個「圈子」就是我們的安全邊界 ( Perimeter )，只要對方來自這個「受信任的網路」，我們就會預設給予對方很高的信任度，因為 Ta 處在我們的白名單上，可以說是繼承了介紹人的信任值。
在酒酣耳熱之中，介紹人說：「Ta 是個好人，(各種符合我們的需求與期待~~balabala)。」一旦通過了這個初步驗證，對方就進入了我們的「信任圈」。而因為對方已經在圈內，我們很快就會分享大量個人資訊、帶他去見所有朋友、甚至交出家中鑰匙。但假如我們看走了眼呢? 假如這個對象不是一個好人，已經拿到信任授權與在社交圈中的 Ta，能在我們毫無防備的個人世界裡橫向移動 ( Lateral Movement )，輕易地接觸到我們最脆弱的部分（財務、朋友、家人、秘密），造成毀滅性的打擊。
在許多的社交平台上，不乏有人分享這些血淋淋的經歷，不論個人的特質、性別與背景都有可能在這個 信任 遊戲中遍體麟傷。
而另一種模式則是 「零信任」模式 一開始所有的陌生對象每個人的初始信任度，都是零。我們不會因為對方的個人資料（ Profile ）寫得天花亂墜就完全相信，我們假設每個人都可能與他所聲稱的身份不符 - 信任是需要贏取的，而不是預設的 。
對方的身份是 Ta 所有屬性（ Attributes ）的總和：Ta 的言談舉止、價值觀、朋友的評價、Ta 對待服務生的態度等等。
每一次互動，都是一次微小的驗證 ( Micro-authentication )。Ta 說 Ta 喜歡戶外運動，那我們就真的去爬一次山看看言行是否一致？這就是 持續的驗證 。同時，我們絕不會在第一次見面就交出所有權限，而是會逐步授權：
第一次見面（喝杯咖啡）：只授權了**「讀取：公開資訊」**的權限 (read:public_profile)。對方只能存取我們願意公開分享的話題。時間和地點這個「資源」也被嚴格限制在「公開場合一小時」。
幾次約會後（一起晚餐）：如果前面的驗證都通過了，可能會授予**「讀取：個人經歷」**的權限 (read:personal_anecdotes)，分享一些過去的故事。
穩定交往後（見朋友/家人）：這是一次重大的權限提升 (Privilege Escalation)。授權對方存取我們的**「社交圈」**這個關鍵資源 (access:social_segment)。
承諾關係（分享未來）：這才可能授予**「寫入：核心價值觀與未來規劃」**的最高權限 (write:core_values_and_future_plans)。
而在我們自己的生活中，每個 生活段落 是由不同的 「區塊」 組成的：我們的工作、我們的家庭、我們的摯友、我們的個人獨處時間。這些區塊是相互隔離的。一個約會對象被授權進入我們的 「休閒娛樂」 區塊，不代表 Ta 能自動存取我們的 「工作」 或 「家庭」 區塊，每個區塊的門，都需要獨立的、基於情境的驗證和授權。
在這種模型下，即使一段關係最終被證明是錯誤的（相當於一次安全漏洞），損害也是可控的。因為對方從未獲得過我們整個世界的「管理員權限」，我們的核心自我、我們的事業、我們與家人的關係，這些被良好隔離的區塊，依然安全無恙。我們依然擁有從這次「入侵」中恢復的韌性。
瞧，是不是某種程度上變得簡單易懂了一些? 不論是系統架構的 「零信任」模式 ，又或是對於人生伴侶的尋覓上。
事實上來說，
「信任管理」（Trust Management） 本身就是基於一種對於 實體 之間互動的 管理哲學。
尤其是 軍事 和 企業管理 這兩個領域早已深植數百年之久。軍事是人類最早、也最極致的信任管理實踐場域，因為在這裡，信任的失誤，代價是生命和國家的存亡。軍事體系中無處不體現著 零信任 的原則，只是他們不使用這個術語:
軍隊是零信任原則最徹底的執行者，這些規則，是透過 組織紀律 、 層級結構 和 人力流程 來執行的，企業管理則是將信任管理的原則，應用於追求效率和規避風險的商業環境:
在企業中，信任管理是透過 法律合約 、 內部規章 和 審計流程 來實現的。
現在，當網際網路這個無國界、去中心、充滿匿名參與者的系統出現時，我們面臨一個全新的挑戰：
如何將軍事和商業領域中，那些依賴人類判斷和流程的信任原則，轉化為可以讓機器自己執行、能夠在毫秒間處理數百萬次請求的自動化邏輯？
這就是馬特·布雷茲和後來的資訊科學家們的貢獻所在。他們將這些源遠流長的管理智慧，抽象化、數學化、演算法化:
我們現在所聊聊的零信任架構，正是這些古老智慧在數位時代的最新、也是最高效的結晶。
| 思維維度 | 傳統邊界防禦 (Castle-and-Moat) | 零信任架構 (Zero Trust) |
|---|---|---|
| 核心假設 | 「信任，但要驗證」 (Trust but verify) | 「永不信任，永遠驗證」 (Never trust, always verify) |
| 信任邊界 | 清晰的內外網邊界。內部網路被視為「可信區域」。 | 邊界消失。每個使用者、裝置、應用程式都是一個獨立的邊界。 |
| 防禦焦點 | 防範外部威脅進入內部網路。 | 假設威脅已在內部。專注於阻止威脅在網路內部的「橫向移動」。 |
| 驗證機制 | 基於網路位置（例如：IP 位址在公司內網）。 | 基於身份（Identity-centric）。每次存取請求都必須經過嚴格的身份驗證與授權。 |
| 授權模型 | 較為寬鬆的存取權限。 | 最小權限原則（Least Privilege）。僅授予完成任務所必需的最小權限。 |
| 抽象比喻 | 一座有護城河的城堡。只要攻破城門，內部就不設防。 | 一棟現代化的安全大樓。即使我們通過了大門，要去每個房間、每個樓層，都需要刷對應的門禁卡。 |
在雲端環境中，尤其是 AWS，實現零信任的第一個支柱就是身份。 AWS Identity and Access Management (IAM) 就是你用來定義和管理「誰能做什麼」的核心工具。
「最小權限原則」（Principle of Least Privilege, PoLP） 是零信任在身份管理上的具體實踐，其理念非常純粹：任何 實體 （無論是 人 、 應用程式 、 還是 伺服器 ）都只應被授予其執行特定任務所絕對需要的最小權限集合。
讓我們把它抽象化：
最小權限原則要求為每個使用者、服務或應用程式授予完成其工作所需的最小權限集合，不多也不少:
EC2實例 附加一個 AdministratorAccess 策略。這相當於給了辦公大樓的影印機整棟大樓的萬能鑰匙。一旦影印機被駭，整棟大樓都將淪陷(印象中不知道是美國日本還是印度發生過，很魔幻)。Web伺服器 創建一個專門的 IAM Role，其 Policy 只允許它對 user-profile-images S3 儲存桶 執行 s3:PutObject 和 s3:GetObject 操作。這就像影印機只能從特定的紙張供應櫃取紙，並且只能將影印好的文件放入指定的文件回收箱，它的活動範圍被嚴格限制，即使被攻破，損害也極其有限。記住，在零信任世界裡，權限是一種 責任，是一種需要 被嚴格審計的風險 。
然而，有另外一種風險躲藏在這個在最小權限原則實踐中，它是最常見也最隱蔽的敵人 - 權限膨脹 。
這是一個非常重要的議題。許多團隊在專案初期，能夠很好地遵守最小權限原則，但隨著 時間推移 、 人員變動 和 需求迭代，權限系統就像一個未經打理的花園，逐漸雜草叢生，最終變得混亂而危險。
首先，我們要給「權限膨脹」一個清晰的定義。
權限膨脹（Privilege Creep） ，又稱 權限蠕變 ，是指一個使用者或服務帳戶（例如 IAM User , IAM Role ），隨著時間的推移，逐步累積了遠超過其當前職責所需的權限。這種累積過程通常不是一次性的，而是由許多看似無害的、微小的授權操作，在數月甚至數年內慢慢疊加而成。
這是一個典型的 「熵增定律」 在資訊安全領域的體現：在沒有持續投入能量去維護秩序的情況下，一個系統的混亂度（風險）只會不斷增加。權限膨脹的發生，很少是出於惡意，而大多源於人性、流程的疏忽與對速度的追求。主要有以下幾個原因：
權限膨脹的風險：
隨著時間累積，權限往往只增不減
員工轉崗後保留舊職位的權限
開發環境的過度權限被帶入生產環境
服務間的權限交叉感染
想像一位新進員工，第一天他拿到一把辦公室的鑰匙:
現在，想像一下如果這個「萬能鑰匙圈」被偷了（相當於他的 IAM 帳號被盜用），攻擊者能造成的破壞有多大？ 他們不僅能進入他現在的辦公室，還能暢行無阻地進入伺服器機房、物料倉庫...等所有他曾經工作過的地方。
這就是權限膨脹最直觀的風險:
而為了對抗權限膨脹，不能靠個人記憶，必須建立系統化的流程：
總結來說，「權限膨脹」是一種技術債，它是過去為了追求速度和便利，而犧牲安全性和規範性所遺留下來的債務。如果不主動、持續地去償還和管理，這筆債務的利息（風險）將會以複利增長，直到在某個最脆弱的時刻，引發系統性的崩潰。
在我們理解了「最小權限」的理想狀態和「權限膨脹」的殘酷現實之後，一個自然而然的問題就是： 「如果我的系統已經處於一個權限混亂的狀態(業界老系統常態)，我該如何安全、可控地回到正軌？」
直接動手「砍權限」，就像在不清楚地基結構的情況下，隨意拆除一棟建築的承重牆，極有可能導致災難性的系統崩潰 - 一刀砍在大動脈的鬼故事業界常有，成功修復的童話不常有。這就是為什麼我們需要一套 「漸進式權限管理策略」 ，這套策略，體現的不是一次性的動作，而是一種持續改良的、專業的系統治理思維。
想像一下，我們接手了一個充滿了技術債的舊專案，其 IAM 權限狀態就像一團亂麻。我們的任務，就是像一個外科醫生一樣，精準、分階段地移除腫瘤，同時保證病人的生命體徵穩定，這個過程可以分為四個核心階段：
Phase 1：盤點與可視化 (Audit & Visualize) - 「摸清家底」
在此階段，我們的唯一目標是 「只觀察，不觸碰」 。我們不能管理 看不見 的東西。所以，首要任務是將當前混亂的權限狀態，變得透明、可視化。
核心行動：
1. 清點資產： 利用 `AWS Config` 或自訂腳本，完整地列出你帳戶中所有的 `IAM 使用者` 、 `群組` 、 `角色及客戶管理策略（Customer Managed Policies）`。
2. 分析日誌： 這是最關鍵的一步，啟用 `CloudTrail` ，收集至少 30-90 天的 `API 活動日誌`。我們需要知道，哪些權限在過去這段時間內被「真正使用」過。
3. 使用工具：
- `IAM Access Analyzer`： 開啟它，讓它幫你找出哪些資源（如 `S3 儲存桶` 、 `SQS 隊列`）被授予了可從外部存取的公開權限或跨帳戶權限。這是你最需要優先處理的風險敞口。
- `CloudTrail Lake`： 如果日誌量巨大，可以使用 `CloudTrail Lake` ，透過 SQL 查詢來精準分析特定角色（ `Role` ）或使用者（ `User` ）的具體行為。
階段產出： 一份詳細的「現況報告」。報告中應清晰標示出： 哪些是高權限角色？ 哪些權限長期未被使用？ 哪些服務之間有異常的呼叫行為？
現況報告範例
以下是一個典型的 IAM 權限現況報告，展示了系統盤點後的發現：
# IAM 權限現況評估報告
**評估期間**: 2024-01-01 至 2024-03-31 (90 天)
**評估範圍**: AWS 帳戶 123456789012
**生成時間**: 2024-04-01 10:30 UTC
## 總體統計
| 項目 | 數量 | 風險等級 |
| ----------------------------- | ---- | -------- |
| IAM Users | 47 | 🟡 中等 |
| IAM Roles | 128 | 🔴 高 |
| Customer Managed Policies | 23 | 🟡 中等 |
| AWS Managed Policies (已附加) | 89 | 🟢 低 |
| 過度權限角色 | 15 | 🔴 高 |
| 僵屍權限 (90 天未使用) | 31 | 🟠 中高 |
## 高風險發現
### 1. 過度授權角色
| 角色名稱 | 附加策略 | 未使用權限比例 | 風險評級 |
| ---------------------- | --------------------------- | -------------- | -------- |
| `legacy-admin-role` | AdministratorAccess | 95% | 🔴 極高 |
| `ec2-backup-service` | PowerUserAccess | 87% | 🔴 高 |
| `data-processing-role` | S3FullAccess, EC2FullAccess | 78% | 🔴 高 |
### 2. 僵屍權限清單
```json
{
"unused_permissions": [
{
"role": "web-app-role",
"unused_actions": [
"s3:DeleteBucket",
"ec2:TerminateInstances",
"rds:DeleteDBInstance"
],
"last_used": "never",
"risk_impact": "可能導致意外的資源刪除"
},
{
"role": "analytics-worker",
"unused_actions": ["iam:CreateRole", "iam:AttachRolePolicy"],
"last_used": "never",
"risk_impact": "潛在的權限升級路徑"
}
]
}
```
### 3. 外部存取風險
| 資源類型 | 資源名稱 | 風險描述 | 建議處理 |
| --------------- | --------------------------- | -------------------- | ----------- |
| S3 Bucket | `company-logs-backup` | 允許匿名讀取存取 | 🔴 立即修復 |
| SQS Queue | `legacy-notification-queue` | 跨帳戶寫入權限過寬 | 🟠 儘快處理 |
| Lambda Function | `data-export-function` | 資源策略允許 \* 主體 | 🔴 立即修復 |
## 權限使用分析
### 最活躍的角色 (按 API 呼叫次數)
1. `web-server-role`: 1,247,389 次呼叫
2. `api-gateway-role`: 892,456 次呼叫
3. `batch-processing-role`: 234,567 次呼叫
### 最少使用的角色
1. `legacy-migration-role`: 0 次呼叫 (建議刪除)
2. `temp-consultant-access`: 3 次呼叫 (建議審查)
3. `old-monitoring-role`: 12 次呼叫 (建議合併)
## 優先處理建議
### 立即行動 (24 小時內)
- [ ] 移除 `company-logs-backup` S3 桶的公開讀取權限
- [ ] 審查並限制 `legacy-admin-role` 的使用範圍
- [ ] 撤銷 `data-export-function` 的過寬資源策略
### 短期目標 (1-2 週)
- [ ] 為 `web-server-role` 建立最小權限策略替代方案
- [ ] 清理 15 個識別出的僵屍權限
- [ ] 實施 CloudTrail Lake 查詢自動化
### 中期目標 (1 個月)
- [ ] 建立標準化的權限範本
- [ ] 實施自動化權限審查流程
- [ ] 導入 IAM Access Analyzer 持續監控
## 📋 詳細清單
### 完整角色權限對照表
```bash
# 生成指令
aws iam list-roles --query 'Roles[*].[RoleName,AssumeRolePolicyDocument]' \
--output table > iam-roles-audit.txt
# 權限使用分析查詢 (CloudTrail Lake)
SELECT
userIdentity.type,
userIdentity.arn,
eventName,
COUNT(*) as usage_count
FROM cloudtrail_table
WHERE eventTime >= '2024-01-01'
AND eventTime < '2024-04-01'
AND userIdentity.type = 'AssumedRole'
GROUP BY userIdentity.arn, eventName
ORDER BY usage_count DESC;
```
## 🔧 工具配置記錄
### IAM Access Analyzer 設定
- 分析器名稱: `zero-trust-analyzer`
- 掃描範圍: 整個組織
- 外部存取檢查: 已啟用
- 未使用存取檢查: 已啟用 (90 天基準)
### CloudTrail 設定
- 追蹤名稱: `management-events-trail`
- 資料事件: S3, Lambda 已啟用
- 洞察事件: 已啟用
- 儲存位置: `s3://audit-logs-bucket/cloudtrail/`
---
**報告產生者**: AWS IAM 權限分析腳本 v2.1
**下次審查時間**: 2024-07-01
**聯絡人**: security-team@company.com
Phase 2：分析與定義 (Analyze & Define) - 「畫出靶心」
有了第一階段的數據作為基礎，現在可以從「偵探」轉變為「設計師」。目標是為關鍵的角色，設計出它們「應有」的最小權限策略。
核心行動：
1. **從「皇冠寶石」開始** ： 不要試圖一次性修復所有權限。選擇最關鍵、風險最高的 IAM 角色開始，例如：能夠存取生產環境資料庫的 EC2 角色，或是擁有管理員權限的運維角色。
2. **基於使用數據生成策略** ： 利用 CloudTrail 的日誌數據，為你選定的目標角色，生成一個新的、只包含 **「過去 90 天內實際使用過的操作」** 的 IAM 策略。AWS IAM 主控台內建的「基於活動生成策略」功能，可以極大地簡化這個過程。
3. **定義標準化範本**： 針對不同職責（例如：後端工程師、數據科學家、僅讀取監控人員），定義標準化的權限範本。這有助於未來的權限管理，避免重複造輪子。
4. **識別靜態與動態權限需求** ： 在此階段，我們分析所有需要的權限，並把它們分類：
- 靜態權限 (Static Permissions)： 指那些低風險、日常必需、可以常駐在 IAM 角色上的權限。例如，一個 Web 伺服器角色讀取 S3 圖片儲存桶的 s3:GetObject 權限。
- 動態權限 (Dynamic Permissions)： 指那些高風險、非日常、僅在特定情況下才需要的權限。例如，資料庫管理員（DBA）需要連線到生產環境資料庫執行緊急維護的權限。我們在這裡要做的，是「定義」出這些高風險操作，並將它們從標準範本中移除，標記為必須透過 JIT 方式授予。
階段產出： 一系列全新的、精簡的、基於真實使用數據的 IAM 策略 JSON 文件。這些是你的「理想狀態」藍圖
實際策略範例
以下是基於 CloudTrail 分析後，為一個 Web 應用程式伺服器角色重新設計的最小權限策略：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ImageAccess",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::company-user-images/*"],
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/Environment": "production"
}
}
},
{
"Sid": "DynamoDBUserProfileAccess",
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem"],
"Resource": ["arn:aws:dynamodb:us-west-2:ACCOUNT:table/user-profiles"],
"Condition": {
"ForAllValues:StringEquals": {
"dynamodb:Attributes": [
"user_id",
"profile_data",
"last_login",
"updated_at"
]
}
}
},
{
"Sid": "CloudWatchLogsWrite",
"Effect": "Allow",
"Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
"Resource": [
"arn:aws:logs:us-west-2:ACCOUNT:log-group:/aws/ec2/web-app:*"
]
}
]
}
Phase 3：限制與收緊 (Restrict & Refine) - 「逐步收網」
這是整個流程中最需要謹慎操作的階段。你將開始用新策略替換舊的、過度寬鬆的策略。核心原則是：小步快跑，隨時監控，備好預案。
核心行動：
1. **先從「唯讀」權限開始收緊** ： 相較於 `GetObject` ，撤銷 `PutObject` 或 `DeleteObject` 這樣的寫入/刪除權限，通常更安全，也更容易判斷其影響。
2. **先在「測試環境」演練**： 將新策略優先部署到你的開發或測試環境。讓開發團隊進行完整的迴歸測試，確保應用程式不會因為權限收緊而崩潰。
3. **部署至生產環境並密切監控：**
- 選擇業務低峰期進行變更。
- 在部署後，死盯 `CloudWatch Logs` 和 `Alarms`，專門監控與權限相關的錯誤訊息（例如 `AccessDenied` ）。
- **準備好一鍵回滾計畫**： 一旦發現核心功能異常，你必須能夠在幾分鐘內，迅速將 IAM 角色切換回舊的、寬鬆的策略，先恢復服務，再重新排查問題。
階段產出： 一個或多個關鍵角色成功地、無中斷地切換到了最小權限策略。團隊也因此建立了執行此類變更的信心。
Phase 4：自動化與持續治理 (Automate & Govern) - 「形成慣例」
手動的、一次性的優化，成果無法持久。權限膨脹的 熵增效應 ，會很快讓系統重回混亂。因此，最後一步是將這個流程，固化為自動、持續的系統。
核心行動：
1. **一切皆代碼 ( `Infrastructure as Code` )** ： 嚴格禁止在 AWS 主控台上手動修改 IAM 策略，所有 IAM 相關的資源，都必須透過 `Terraform` 或 `CloudFormation` 進行定義和管理。這確保了每一項變更都有紀錄、可審核、可追溯。
2. **在 CI/CD 流程中加入安全掃描**： 使用 `tfsec` , `checkov` 等工具，在你的程式碼提交與部署流程中，自動掃描 `IaC` 檔案是否包含過度寬鬆的權限（例如 `iam:*` ），若有則直接中斷部署。
3. **建立 Just-in-Time (JIT) 存取機制** ：針對第二階段定義出的「高權限操作清單」，建立一套自動化的臨時授權系統。這可以透過 `AWS IAM Identity Center (原 AWS SSO) ` 的臨時權限提升功能，或是自訂一套結合 `Lambda` 與 `Step Functions` 的流程來實現。使用者在需要時，必須通過嚴格驗證（例如 MFA），來申請一個有時效性（例如：60 分鐘）的臨時權限。時間一到，權限自動失效。
4. **建立自動化告警** ： 配置 `IAM Access Analyzer`，讓它持續監控，一旦發現新的不安全授權，就自動發送告警至 `Slack` 或 `Email`。
階段產出： 一套能夠自我維護、防止權限膨脹再次發生的 「權限治理系統」 。
微服務權限隔離：
在現代雲端架構中，特別是微服務（Microservices）架構下，「服務間通信」已經取代了傳統的「外部邊界」，成為了系統中最核心、最頻繁，同時也最容易被忽視的攻擊面。如果說對人員的權限管理是守住城堡的大門，那麼對服務間通信的管理，就是守住城堡內部每一間密室的鑰匙。
在過去的單體式應用（Monolithic Application）中，一個功能模組呼叫另一個，只是一次記憶體內的函式調用（Function Call）。這個過程被預設為「絕對可信」。
但在微服務架構中，這變成了一次網路呼叫（Network Call）。網路，從本質上說，是不可信的。因此，我們必須將零信任的「永不信任，永遠驗證」原則，從對「人」的管理，延伸到對「程式碼」的管理。
一個簡單而強大的心智模型是：
將每一個微服務，都想像成一個主權國家；每一次服務間的 API 呼叫，都視為一次外交人員的跨境訪問。
傳統的服務通信設計，常常依賴於一個脆弱的假設：「只要服務都部署在同一個 VPC (虛擬私有雲) 內，它們就是自己人，可以相互信任。」
這就像一個巨大的開放式辦公室，所有部門（服務）都在裡面。雖然有門禁卡才能進入辦公室，但進來之後，任何人都可以走到任何部門的座位旁，竊取文件或進行破壞，一旦攻擊者攻陷了其中一個最不重要的服務（例如：一個日誌處理服務），他就能以此為跳板，在內部網路中暢行無阻，最終訪問到最核心的資料庫服務。
零信任設計徹底拋棄了「內部網路可信」的假設，它要求每一次服務間的互動，都必須經過嚴格的身份驗證與授權。這套設計基於以下幾個核心原則：
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:role/PaymentServiceRole" },
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:REGION:ACCOUNT_ID:API_ID/prod/POST/orders"
}
一個有效的 VPC 微隔離架構，是策略與觀測的閉環。透過 分層策略 來設定規則，然後透過 監控與可觀測性工具 來驗證這些規則是否被遵守、是否被攻擊。這個持續的 「設定-驗證-優化」 循環，才是零信任網路安全的精髓所在。這兩者相輔相成。一個沒有可觀測性的分層策略，就像一座有著無數密室、卻沒有任何監視器的堡壘——你無法知道防禦是否有效，也無法察覺內部的異常活動。
微隔離的精髓，不在於創造無數個混亂的「小房間」，而在於建立一個層次分明、邏輯清晰的 「防禦縱深」（Defense in Depth） 體系。每一次網路流量，都應該像通過層層關卡的審查一樣，經過多個獨立檢查點的過濾。
我們可以將這個策略，透過一個三層過濾模型來實現：
Layer 1: VPC 邊界隔離
這是最外圍、最粗粒度的防線，如同規劃一座安全園區的區域（行政區、研發區、訪客區）。
# Terraform VPC 配置範例
resource "aws_vpc" "zero_trust_vpc" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
enable_dns_support = true
tags = {
Name = "zero-trust-vpc"
Security = "isolated"
}
}
# DMZ 子網路 (公開服務)
resource "aws_subnet" "dmz_subnet" {
vpc_id = aws_vpc.zero_trust_vpc.id
cidr_block = "10.0.1.0/24"
availability_zone = "us-west-2a"
map_public_ip_on_launch = true
tags = {
Name = "dmz-subnet"
Tier = "public"
}
}
# 應用層子網路 (私有服務)
resource "aws_subnet" "app_subnet" {
vpc_id = aws_vpc.zero_trust_vpc.id
cidr_block = "10.0.2.0/24"
availability_zone = "us-west-2a"
tags = {
Name = "app-subnet"
Tier = "private"
}
}
# 資料層子網路 (高度隔離)
resource "aws_subnet" "data_subnet" {
vpc_id = aws_vpc.zero_trust_vpc.id
cidr_block = "10.0.3.0/24"
availability_zone = "us-west-2a"
tags = {
Name = "data-subnet"
Tier = "isolated"
}
}
Layer 2: 網路 ACL 補強防禦
如果說子網路是樓層，NACL 就是每層樓電梯口的保安。它負責過濾所有進出該子網路的流量，是一個無狀態（Stateless）的、較為粗略的檢查站。
# 限制性的網路 ACL
resource "aws_network_acl" "restrictive_nacl" {
vpc_id = aws_vpc.zero_trust_vpc.id
subnet_ids = [aws_subnet.data_subnet.id]
# 明確允許應用層到資料層的流量
ingress {
rule_no = 100
protocol = "tcp"
cidr_block = "10.0.2.0/24" # 應用層子網路
from_port = 5432
to_port = 5432
action = "allow"
}
# 允許回程流量
egress {
rule_no = 100
protocol = "tcp"
cidr_block = "10.0.2.0/24"
from_port = 32768
to_port = 65535
action = "allow"
}
# 拒絕所有其他流量（預設規則）
tags = {
Name = "data-tier-nacl"
}
}
Layer 3: 安全群組微分段
安全組是實現微隔離的核心工具，如同每個辦公室門口的精準門禁系統。它是有狀態（Stateful）的、以「預設拒絕」（Default Deny）為原則的防火牆，直接綁定到每一個資源（如 EC2 實例、RDS 實例）上。
# Web 層安全群組
resource "aws_security_group" "web_tier_sg" {
name = "web-tier-sg"
description = "Security group for web tier"
vpc_id = aws_vpc.zero_trust_vpc.id
# 只允許 HTTPS 入站流量
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
description = "HTTPS from internet"
}
# 只允許向應用層的特定端口出站
egress {
from_port = 8080
to_port = 8080
protocol = "tcp"
security_groups = [aws_security_group.app_tier_sg.id]
description = "App tier communication"
}
}
# 應用層安全群組
resource "aws_security_group" "app_tier_sg" {
name = "app-tier-sg"
description = "Security group for application tier"
vpc_id = aws_vpc.zero_trust_vpc.id
# 只允許來自 Web 層的流量
ingress {
from_port = 8080
to_port = 8080
protocol = "tcp"
security_groups = [aws_security_group.web_tier_sg.id]
description = "From web tier"
}
# 只允許向資料層的資料庫端口出站
egress {
from_port = 5432
to_port = 5432
protocol = "tcp"
security_groups = [aws_security_group.data_tier_sg.id]
description = "Database communication"
}
}
# 資料層安全群組
resource "aws_security_group" "data_tier_sg" {
name = "data-tier-sg"
description = "Security group for data tier"
vpc_id = aws_vpc.zero_trust_vpc.id
# 只允許來自應用層的資料庫連接
ingress {
from_port = 5432
to_port = 5432
protocol = "tcp"
security_groups = [aws_security_group.app_tier_sg.id]
description = "From app tier"
}
# 拒絕所有出站流量（資料不應離開資料層）
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["127.0.0.1/32"] # 實際上阻止所有出站
description = "Deny all outbound"
}
}
一個「預設拒絕」的網路模型，其監控哲學很簡單：任何被拒絕的流量，都可能是一個攻擊信號或配置錯誤；任何被允許的流量，都必須是可預期且可追溯的。
為了實現這一點，你需要整合以下幾個數據源：
VPC Flow Logs 設定：
resource "aws_flow_log" "zero_trust_flow_log" {
iam_role_arn = aws_iam_role.flow_log_role.arn
log_destination = aws_cloudwatch_log_group.vpc_log_group.arn
traffic_type = "ALL"
vpc_id = aws_vpc.zero_trust_vpc.id
tags = {
Name = "zero-trust-flow-log"
}
}
# CloudWatch Log Group
resource "aws_cloudwatch_log_group" "vpc_log_group" {
name = "/aws/vpc/flowlogs"
retention_in_days = 30
}
異常流量檢測：
# CloudWatch 警報設定
resource "aws_cloudwatch_metric_alarm" "suspicious_traffic" {
alarm_name = "suspicious-network-traffic"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "2"
metric_name = "PacketDropCount"
namespace = "AWS/VPC"
period = "300"
statistic = "Sum"
threshold = "100"
alarm_description = "This metric monitors packet drops"
dimensions = {
VpcId = aws_vpc.zero_trust_vpc.id
}
alarm_actions = [aws_sns_topic.security_alerts.arn]
}
到目前為止，我們討論了零信任的「為什麼」（哲學思維）和「怎麼做」（架構實踐）。現在，我們要探討兩個更深層次的問題：「我們如何證明它有效？」(安全指標與 KPI 定義 ) 以及 「它的下一步會走向何方？」(零信任架構的未來演進)
實施零信任架構，是一項重大的工程和文化轉變，它需要資源、時間和團隊的投入。因此，你必須能夠向管理層、向團隊、甚至向你自己，量化這次投入所帶來的價值。我們必須擺脫「感覺更安全了」這種模糊的描述，轉向由數據驅動的 KPI。
一個好的零信任 KPI 體系，應該從以下三個維度來構建：
這類指標直接衡量你的系統在應對威脅時的「韌性」提升了多少。
這類指標旨在證明，零信任不僅提升了安全，還透過自動化和標準化，優化了團隊的工作效率。
這類指標用於衡量你的零信任旅程走了多遠，以及未來的優化方向。
指標表格範例：
| 指標 | 目標值 | 測量方法 |
|---|---|---|
| 平均權限數量 | < 10 per role | IAM 政策分析 |
| 權限使用率 | > 80% | CloudTrail 分析 |
| 網路分段覆蓋率 | > 95% | Config 規則檢查 |
| 異常檢測準確率 | > 90% | GuardDuty 評估 |
| 事件回應時間 | < 15 分鐘 | 自動化監控 |
零信任不是一個靜態的技術產品，它是一種持續演進的哲學。它的核心「永不信任，永遠驗證」不變，但「如何驗證」的技術將會隨著整個科技領域的發展而變得更加智慧和動態。
以下是幾個可預見的未來演進方向：
現狀： 權限是基於相對靜態的「身份」和「角色」來授予的。
未來： 系統將不再只問「你是誰？」，而是會問「在當前這個情境下，我有多信任你？」。每一次的存取請求，背後都會有一個由 AI 驅動的信任評分引擎，實時計算一個「信任分數」。這個分數會綜合考慮數十個信號：你是誰、你的設備健康狀況、你所在的地理位置、現在的時間、你最近的行為模式是否異常、是否有新的威脅情報與你相關…等等。一個 DevOps 工程師在正常上班時間，用公司電腦發起的請求，信任分數可能是 95/100；而同一個工程師，在凌晨 3 點，用一台沒打補丁的手機從國外 IP 發起同樣請求，信任分數可能只有 20/100，因此存取將被拒絕。
現狀： 我們依賴密碼、MFA 和中心化的身份提供商（IdP）。
未來： 以 Passkeys (FIDO2) 為代表的無密碼技術將成為主流，徹底消滅「密碼」這個最大的攻擊向量。更長遠地，基於區塊鏈的**去中心化身份（DID）和可驗證憑證（VCs）**將允許個人和設備真正擁有自己的身份主權，可以按需、精準地出示「身份證明」的某個方面（例如：「證明我已成年」，而不是出示整個身份證），而無需依賴任何單一的中心化機構。
現狀： 我們花費大量精力去保護長時間運行的伺服器（EC2）。
未來： 隨著 Serverless（如 Lambda）和容器化技術（如 Fargate）的普及，基礎設施的生命週期可能只有幾秒鐘。在這種「曇花一現」的運算環境中，傳統的網路邊界和主機安全變得幾乎沒有意義。安全的重心將完全轉移到工作負載的身份（IAM 執行角色）、程式碼本身的安全，以及它們之間的 API 互動上。零信任成為了唯一的選擇，因為除此以外，再無邊界可守。
現狀： 我們所有的「驗證」機制，從 TLS 加密到 SigV4 簽章，都基於當前的加密演算法。
未來： 隨著量子計算的發展，這些演算法面臨被破解的風險。下一代的零信任架構，必須將後量子密碼學整合到其核心。這意味著我們用來驗證身份、保護通信的數學基礎，都需要進行一次代際升級，以確保「驗證」這個行為本身，在未來依然可信。
總結來說， 零信任的未來，是從一個基於「靜態規則」的安全模型，演進為一個基於「動態情境」、由 AI 驅動的、具備自我適應能力的「信任網絡」。它不僅僅是安全的守衛，更是業務流程的智慧協調者，能夠在確保安全的同時，提供最無縫、最智能的存取體驗。而掌握這套思維，正是你作為未來架構師的核心價值所在。
結合機器學習和行為分析，系統將能夠預測和預防安全威脅，而不僅僅是檢測已發生的事件。
零信任架構不僅是一套技術實作，更是一種安全思維的根本轉變。在雲端優先的時代，它為組織提供了：
關鍵要點：
- 思維轉變：從「信任但驗證」到「永不信任，永遠驗證」
- 身份優先：將身份而非網路位置作為安全決策核心
- 最小權限：精確授權，定期審查，動態調整
- 網路分段：多層防禦，微隔離，流量監控
- 持續優化：基於數據的安全決策和投資回報分析
零信任不是終點，而是安全演進的起點。它要求我們將安全性從事後補強轉變為架構設計的核心原則。
iThome鐵人賽
看影片追技術