【Day 22】Microsoft Entra ID 與條件式存取：身分是新的安全邊界 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★☆☆
今日任務：區分 Authentication 與 Authorization、掌握 Microsoft Entra ID 的核心角色（Tenant、使用者、群組、應用程式註冊），並理解 SSO、MFA、Passwordless 與 Conditional Access 如何串成 Zero Trust 身分防線。

🎯 前言與今日目標

使用claude code+ antigravicli 3.8 flash 撰稿完成。Phase 3 驗收完成，Titan 科技的運算、網路與資料金庫已就緒。但 CTO 在進入 Phase 4 前拋出一個根本問題：「這些資源再怎麼堅固，如果任何人拿到一組帳密就能無限制地存取所有環境，城牆等於沒建。誰能進來、進來後能做什麼、在什麼條件下才被允許——這三個問題如果答不上來，前面 21 天的部署全部暴露在風險中。」

這正是 Phase 4 的起手式：身分是新的安全邊界 (Identity is the new perimeter)。傳統防火牆以網路邊界為主，但雲端環境中使用者從任何裝置、任何地點存取資源，網路邊界已經模糊。微軟的 Zero Trust 架構以身分驗證與條件式存取作為第一道防線，而 Microsoft Entra ID 正是這道防線的核心引擎。

今天的判斷鏈是 先驗證身分 (Authentication) → 再授與權限 (Authorization) → 以條件式存取動態調整 → 持續監控與風險回應。

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

🧒 ELI13 總覽：身分管理像一座城堡的門禁系統

把 Titan 的雲端平台想成一座城堡。Microsoft Entra ID 是城堡的門禁中心——它驗證每個人的身分證（Authentication），然後根據名單決定誰能進入哪些區域（Authorization）。SSO 像一張萬用通行卡，刷一次就能進入所有已授權的房間，不用每扇門各刷一次。MFA 像在門口多加一道指紋辨識，即使通行卡被偷，沒有你的指紋也進不來。Conditional Access 則像智慧門禁——如果你從陌生地點、用未知裝置、在深夜嘗試進入機密區域，系統會自動要求額外驗證甚至直接拒絕。

📐 Entra ID 身分驗證與授權架構

┌────────────────────────────────────────────────┐
│ 使用者 / 裝置 / 應用程式 / AI Agent            │
└───────────────────────┬────────────────────────┘
                        ▼
┌────────────────────────────────────────────────┐
│ ① Authentication（驗證：你是誰？）             │
│    密碼 + MFA / Passwordless / FIDO2           │
└───────────────────────┬────────────────────────┘
                        ▼
┌────────────────────────────────────────────────┐
│ ② Conditional Access（條件式存取）             │
│    訊號：使用者 / 位置 / 裝置 / 風險等級       │
│    決策：允許 / 要求 MFA / 封鎖                │
└───────────────────────┬────────────────────────┘
                        ▼
┌────────────────────────────────────────────────┐
│ ③ Authorization（授權：你能做什麼？）          │
│    RBAC 角色指派 → 資源存取                    │
└────────────────────────────────────────────────┘

💡 架構師重點筆記：Authentication 與 Authorization 是兩個獨立步驟，AZ-900 常混用這兩個詞設陷阱。「登入成功但無法操作資源」= Authentication 通過、Authorization 不足（缺少 RBAC 角色）。「帳密錯誤無法登入」= Authentication 失敗，連 Authorization 的機會都沒有。

🏛️ Tenant、Subscription 與 Entra ID 的關係

AZ-900 的另一個高頻陷阱是混淆 Tenant 與 Subscription：

每位 Microsoft 365、Azure 或 Dynamics 365 的訂戶，其 Tenant 自動就是一個 Microsoft Entra 租用戶。Tenant 管身分，Subscription 管資源與帳單——兩者層次不同、不可混為一談。

🏢 雙雲多帳號與身分治理架構映射（AWS Organizations ↔ Azure Entra ID）

在企業級雲端架構中，單一帳號無法滿足多團隊與合規隔離需求。AWS 透過 AWS Organizations 與 Control Tower 管理多個 AWS 帳號，並以 IAM Identity Center 建立統一登入；Azure 則以單一集中 Entra ID Tenant 串接多個 Subscriptions 與 Management Groups：

┌────────────────────────────────────────────────────────────┐
│ AWS 企業治理 (cxcxc-io 圖16) vs Azure Entra ID 架構映射    │
├────────────────────────────────────────────────────────────┤
│ AWS 組織治理模式：                                         │
│   AWS Organizations / Control Tower                        │
│     ├── Management Account (根治理與 SCP 防護欄)           │
│     ├── Shared Services (IAM Identity Center 統一 SSO/目錄)│
│     └── Member Accounts (Prod / Audit 各自獨立帳號邊界)    │
├────────────────────────────────────────────────────────────┤
│ Azure 企業治理模式：                                       │
│   Management Groups (管理群組階層治理與 Azure Policy)      │
│     └── Microsoft Entra ID (全組織單一集中身分 Tenant)     │
│           ├── Subscriptions (Prod / Dev 各自獨立計費邊界)  │
│           └── Conditional Access (動態零信任存取決策)      │
└────────────────────────────────────────────────────────────┘

💡 來源：改編自 cxcxc-io diagram_16（多帳號治理與企業級安全架構），已對照 Azure 服務調整。AWS 側以獨立 Account 作為安全與計費邊界並由 Control Tower/SCP 控管；Azure 則以單一 Entra ID Tenant 集中管理身分，再透過 Management Groups 與 Subscriptions 劃分層級邊界。

☁️ Authentication vs. Authorization 深度對照

🔑 SSO、MFA 與 Passwordless 三重防護

Single Sign-On (SSO，單一登入)：使用者登入一次，就能存取所有已整合的應用程式（Microsoft 365、Azure Portal、自訂 SaaS 等），不需每個應用各登一次。降低密碼疲勞、減少弱密碼重用。

Multi-Factor Authentication (MFA，多因素驗證)：在密碼之外加入第二個驗證因素——你知道的（密碼）＋你擁有的（手機驗證碼）或你本身的（生物辨識）。即使密碼被竊取，攻擊者仍缺少第二因素。

Passwordless Authentication（無密碼驗證）：以 FIDO2 安全金鑰、Microsoft Authenticator 或 Windows Hello 取代密碼，從根本消除密碼洩漏風險。密碼是最常被攻擊的驗證因素，移除它比加強它更安全。

🛡️ Conditional Access：Zero Trust 的策略引擎

Conditional Access 是 Microsoft 的 Zero Trust 策略引擎，其運作邏輯是 if-then 規則：

If 使用者要存取資源，then 根據訊號決定是否需要額外驗證或直接封鎖。

💡 架構師重點筆記：Conditional Access 在第一因素驗證之後才觸發——它不是取代密碼的防線，而是根據登入情境動態升級安全要求。考題問「如何在管理員從陌生 IP 登入時強制 MFA？」，答案就是 Conditional Access Policy，不是 RBAC 也不是 Azure Policy。

🏰 Entra ID vs. Entra Domain Services：名稱陷阱

⚠️ 名稱陷阱：題目描述「需要 LDAP、Kerberos、domain join」時，答案要選 Entra Domain Services，不是 Entra ID 本身。Entra ID 是雲端原生的現代驗證服務，不直接提供 LDAP 繫結或 Kerberos 驗證。這是 Day 7 四大陷阱中「名稱重組陷阱」的精確實例。

📖 AZ-900 核心名詞解釋與速查

1. Microsoft Entra ID（原 Azure Active Directory）

   • 定義：Microsoft 的雲端身分與存取管理服務，提供驗證、原則執行與使用者 / 群組 / 應用程式管理。
   • AWS 對照：AWS IAM + IAM Identity Center（方向性對照，架構不完全相同）。
   • 考點：每個 Azure 租用戶自動包含一個 Entra ID 實例；舊稱 Azure AD / Azure Active Directory，考題可能使用任一名稱。

2. Tenant（租用戶）

   • 定義：組織在 Microsoft Entra ID 中的專屬身分目錄實例，包含使用者、群組、應用程式註冊與安全設定。
   • 考點：Tenant ≠ Subscription。一個 Tenant 可包含多個 Subscriptions；一個 Subscription 只屬於一個 Tenant。

3. Authentication（驗證）

   • 定義：確認使用者身分是否為本人的過程。
   • 考點：先 Authentication 再 Authorization；帳密正確但無法操作 = 驗證通過、授權不足。

4. Authorization（授權）

   • 定義：確認已驗證身分的使用者被允許執行哪些操作的過程。
   • 考點：通常透過 RBAC 角色指派實現；Authorization 永遠在 Authentication 之後。

5. Conditional Access（條件式存取）

   • 定義：Microsoft 的 Zero Trust 策略引擎，根據使用者、位置、裝置、應用程式與風險等訊號動態決定存取條件。
   • 考點：if-then 規則，在第一因素驗證後觸發；常見決策包括要求 MFA、要求合規裝置或封鎖。

6. Single Sign-On (SSO)

   • 定義：使用者只需驗證一次，即可存取所有已整合的應用程式。
   • 考點：降低密碼疲勞與弱密碼風險；由 Entra ID 統一管理。

7. Multi-Factor Authentication (MFA)

   • 定義：要求兩個以上不同類別的驗證因素才能完成身分驗證。
   • 考點：常見因素類別——你知道的（密碼）、你擁有的（手機）、你本身的（指紋）。

8. Microsoft Entra Domain Services

   • 定義：提供受控傳統網域服務（LDAP、Kerberos、NTLM、Group Policy、domain join），無需客戶自行部署網域控制器。
   • 考點：舊系統需要 LDAP / Kerberos / domain join 時選它，不是選 Entra ID 本身。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的身分安全大改造

Titan 科技原本使用簡單帳密登入所有系統，沒有 MFA，也沒有依情境調整安全等級。資安團隊近期發現多組管理員帳號的密碼出現在暗網洩漏資料庫中。CTO 下達四項要求：

CTO：「第一，所有員工只需登入一次就能存取 Microsoft 365、Azure Portal 與內部 SaaS 系統。第二，所有管理員帳號必須啟用 MFA。第三，當管理員從未知 IP 登入時，系統自動要求額外驗證。第四，有一批舊系統仍需 LDAP 與 Kerberos，但我不想在 Azure 上自己架網域控制器。」

🧩 決策任務

• A：所有員工各自建立不同帳號登入每個系統；用 Azure Policy 取代 MFA；用 NSG 封鎖陌生 IP；在 Azure VM 上手動安裝 Active Directory。
• B：以 Microsoft Entra ID 實現 SSO 統一登入；為管理員啟用 MFA；建立 Conditional Access Policy 在管理員從未知 IP 登入時要求 MFA；使用 Microsoft Entra Domain Services 提供 LDAP / Kerberos 給舊系統。
• C：把所有系統密碼統一為同一組明文密碼以簡化登入；用 Azure Advisor 監控 MFA；用 Resource Group Tag 判斷登入位置；用 Cosmos DB 儲存 LDAP 查詢結果。
• D：每位員工建立自己的 Tenant；用 Azure Load Balancer 做身分驗證；用 Azure Blob Storage 記錄登入 IP；用 Azure Functions 模擬 Kerberos。

🎯 解題拆解與解析

✅ 正解：B

• SSO：Entra ID 提供 SSO，整合 Microsoft 365、Azure Portal 與自訂 SaaS，使用者只需登入一次。
• MFA：Entra ID 原生支援 MFA，可針對管理員群組啟用。
• Conditional Access：建立 Policy，訊號為「管理員群組 + 非公司 IP」，決策為「要求 MFA」，精確滿足「從未知 IP 登入時額外驗證」的需求。
• 傳統協定支援：Entra Domain Services 提供受控 LDAP / Kerberos / domain join，由 Microsoft 部署與維護 DC，無需客戶自建。

❌ 陷阱分析

• 選項 A：多帳號登入違反 SSO 原則，增加密碼管理負擔；Azure Policy 管「資源是否合規」，不管「身分驗證」；NSG 是網路層流量過濾，不是依身分情境動態調整的驗證機制；手動架 AD 把所有維運責任留給 Titan。
• 選項 C：統一明文密碼是最嚴重的安全反模式——一旦洩漏，所有系統同時淪陷；Advisor 提供最佳化建議，不是 MFA 管理工具；Tag 是詮釋資料標籤，不做位置判斷；Cosmos DB 是 NoSQL 資料庫，不是身分驗證服務。
• 選項 D：每人一個 Tenant 讓治理完全失控且無法統一管理；Load Balancer 分配網路流量，不做身分驗證；Blob Storage 存物件，不是登入稽核工具；Functions 是無伺服器運算，無法取代 Kerberos 協定的完整實作。

🎯 Part 3：AZ-900 精選高頻真題解析

本日真題 1–3 改寫自 ExamTopics 社群回報的身分管理高頻考點，已經 Microsoft Learn 逐選項交叉驗證；真題 4–5 改寫自 2020 年 gratisexam 題庫。

📝 真題 1：Authentication 與 Authorization 的區別（ExamTopics 身分管理高頻考點改編）

Titan 科技的員工成功登入 Azure Portal（帳號密碼正確），但無法修改任何正式環境的資源。這個問題出在哪個環節？

• A. Authentication（驗證）失敗
• B. Authorization（授權）不足
• C. 需要重建 Entra ID Tenant
• D. Resource Group 被刪除

• 正確答案：B. Authorization（授權）不足
• 關鍵字識別：「帳密正確、成功登入」＝ Authentication 已通過；「無法修改資源」＝ 缺少足夠的 RBAC 角色權限。
• 陷阱識破（逐選項查證）：
  • A. Authentication 失敗：題目已明確說明「帳號密碼正確、成功登入」，代表 Authentication 已通過。若 Authentication 失敗，使用者根本無法登入——連看到 Portal 首頁的機會都沒有。
  • C. 重建 Tenant：更換 Tenant 是極端且不相關的操作，題目描述的症狀不涉及 Tenant 設定錯誤。
  • D. Resource Group 被刪除：題目沒有任何線索指向 RG 被刪除。即使 RG 不存在，錯誤訊息也不會是「無法修改資源」，而是「找不到資源」。
• 官方依據：Microsoft Learn 明確區分 Authentication（「verify the identity of a person or service」）與 Authorization（「determine the level of access for an authenticated person or service」），兩者是獨立步驟。
• 來源與驗證：改寫自 ExamTopics 社群回報的身分管理高頻考點；並經 Microsoft Learn：Authentication vs. Authorization 交叉驗證確認。

📝 真題 2：Conditional Access 的觸發情境（ExamTopics 條件式存取高頻考點改編）

Titan 科技要確保管理員從公司網路以外的位置登入 Azure Portal 時，系統自動要求 MFA。應使用什麼機制？

• A. Azure Policy
• B. Conditional Access Policy
• C. Network Security Group (NSG)
• D. Azure Advisor

• 正確答案：B. Conditional Access Policy
• 關鍵字識別：「管理員」＋「非公司 IP」＋「自動要求 MFA」。三個訊號（使用者群組、位置、動態決策）直接指向 Conditional Access。
• 陷阱識破（逐選項查證）：
  • A. Azure Policy：管「資源是否合規」（例如強制 Tag、限制 Region），不管「身分登入條件」。
  • C. NSG：網路層的 5-tuple 流量過濾器，可以封鎖 IP 的網路流量，但無法根據身分、裝置狀態或風險等級做動態驗證升級。
  • D. Azure Advisor：提供成本、安全、可靠性等最佳化建議，不是身分驗證或存取控制工具。
• 官方依據：Microsoft Learn 描述 Conditional Access 為「Microsoft's Zero Trust policy engine taking signals from various sources into account when enforcing policy decisions」，其 if-then 規則正是「if 管理員從陌生 IP 登入，then 要求 MFA」的設計。
• 來源與驗證：改寫自 ExamTopics 社群回報的條件式存取高頻考點；並經 Microsoft Learn：Conditional Access 總覽 交叉驗證確認。

📝 真題 3：需要 LDAP 與 domain join 的舊系統（ExamTopics Entra Domain Services 高頻考點改編）

Titan 科技有一批舊系統必須使用 LDAP 繫結與 Kerberos 驗證，但不想在 Azure VM 上自行部署與維護網域控制器。應使用什麼服務？

• A. Microsoft Entra ID
• B. Microsoft Entra Domain Services
• C. Azure Key Vault
• D. Azure Virtual Network

• 正確答案：B. Microsoft Entra Domain Services
• 關鍵字識別：「LDAP」＋「Kerberos」＋「不想自行部署 DC」。三個關鍵字同時指向 Entra Domain Services。
• 陷阱識破（逐選項查證）：
  • A. Microsoft Entra ID：這是最常見的陷阱。Entra ID 是雲端原生身分服務，使用 OAuth 2.0、OpenID Connect 與 SAML 等現代協定，不直接提供 LDAP 繫結或 Kerberos 驗證。題目明確需要這些傳統協定時，Entra ID 本身不夠。
  • C. Azure Key Vault：集中管理祕密、金鑰與憑證，不是身分驗證或網域服務。
  • D. Azure Virtual Network：網路隔離與路由邊界，與身分驗證協定無關。
• 官方依據：Microsoft Learn 明確陳述 Entra Domain Services「provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication」，且「You use these domain services without the need to deploy, manage, and patch domain controllers (DCs) in the cloud.」
• 來源與驗證：改寫自 ExamTopics 社群回報的 Entra Domain Services 高頻考點；並經 Microsoft Learn：Entra Domain Services 概觀 交叉驗證確認。

📝 真題 4：SSO 的核心效益（2020 題庫 Q89 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q89 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，核心觀念仍有效。

Titan 科技希望員工只需登入一次就能存取 Microsoft 365、Azure Portal 與自訂的內部 SaaS 應用。這種做法稱為？

• A. Multi-Factor Authentication (MFA)
• B. Single Sign-On (SSO)
• C. Role-Based Access Control (RBAC)
• D. Azure Policy

• 正確答案：B. Single Sign-On (SSO)
• 關鍵字識別：「登入一次」＋「存取多個應用」＝ SSO 的定義。
• 陷阱識破：MFA 是多因素驗證（增加驗證強度），不是減少登入次數；RBAC 是授權機制（控制能做什麼），不管登入次數；Azure Policy 管資源合規，與登入體驗無關。
• 來源與驗證：經 Microsoft Learn：SSO 總覽 交叉驗證確認。

📝 真題 5：MFA 的驗證因素分類（2020 題庫 Q91 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q91 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，核心觀念仍有效。

Titan 科技為管理員啟用 MFA。以下哪一組是 MFA 的兩個有效驗證因素？

• A. 密碼 ＋ 安全問題
• B. 密碼 ＋ 手機驗證碼
• C. 兩組不同的密碼
• D. 使用者名稱 ＋ Email 地址

• 正確答案：B. 密碼 ＋ 手機驗證碼
• 關鍵字識別：MFA 要求兩個不同類別的因素——你知道的（密碼）＋ 你擁有的（手機）。
• 陷阱識破：
  • A：密碼與安全問題都屬於「你知道的」同一類別，不算多因素。
  • C：兩組密碼仍是同一類別。
  • D：使用者名稱不是驗證因素，Email 地址也不是獨立的驗證類別。
• 來源與驗證：經 Microsoft Learn：MFA 的運作方式 交叉驗證確認。

📝 情境題 6：Tenant 與 Subscription 的區別

Titan 科技的 CTO 問：「我們有一個 Microsoft Entra ID 租用戶和三個部門。每個部門需要獨立的計費。正確做法是？」

• A. 為每個部門建立一個 Tenant
• B. 在同一個 Tenant 下建立三個 Subscriptions
• C. 建立三個 Resource Groups 來區分帳單
• D. 使用 Azure Advisor 分割費用

• 正確答案：B
• 解題鏈：「獨立計費」＝ Subscription 是計費邊界；「同一組織」＝ 共用一個 Tenant（身分目錄）最合理。一個 Tenant 下可有多個 Subscriptions。拆成三個 Tenant 會讓身分管理碎片化且跨部門協作困難。Resource Group 不是計費邊界。
• 官方依據：Microsoft Learn：Azure 訂用帳戶。

📝 情境題 7：Passwordless 的核心優勢

Titan 科技要從根本降低密碼洩漏風險。以下哪種做法最有效？

• A. 要求每 30 天更換一次密碼
• B. 採用 Passwordless 驗證（FIDO2 / Windows Hello）
• C. 把密碼長度加到 32 字元
• D. 用 Azure Blob Storage 加密儲存所有密碼

• 正確答案：B
• 解題鏈：密碼是最常被攻擊的驗證因素。頻繁更換密碼（A）反而促使使用者選擇弱密碼；加長密碼（C）增加記憶負擔但不消除洩漏風險；Blob Storage（D）是物件儲存，不是密碼管理工具。Passwordless 從根本移除密碼，攻擊者無密碼可竊。
• 官方依據：Microsoft Learn：Passwordless 驗證。

📝 情境題 8：外部身分與來賓存取

Titan 科技要讓合作夥伴使用他們自己的 Google 帳號登入 Titan 的 Azure 資源，不需要為他們建立新帳號。應使用什麼功能？

• A. Microsoft Entra External ID
• B. Azure Key Vault
• C. Azure ExpressRoute
• D. Azure Managed Disks

• 正確答案：A
• 解題鏈：「外部合作夥伴」＋「使用自己的帳號」＋「不需建立新帳號」= 外部身分 (External ID)。Key Vault 管祕密、ExpressRoute 做私有連線、Managed Disks 是 VM 磁碟——都與外部身分存取無關。
• 官方依據：Microsoft Learn：External ID 總覽。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

架構師收斂心法

Azure 與 AWS 的身分管理有一個根本差異：AWS IAM 將使用者、群組、角色、Policy 全部集中在 IAM 服務裡；Azure 則把「身分管理」（Entra ID）與「資源授權」（Azure RBAC）拆成兩個獨立系統。Entra ID 管「你是誰」，RBAC 管「你能對資源做什麼」。

┌────────────────────────────────────────────┐
│ AWS：IAM 統一處理身分 + 權限               │
│   User → Policy → Resource                 │
├────────────────────────────────────────────┤
│ Azure：拆成兩個系統                        │
│   Entra ID (身分) → RBAC (資源權限)        │
│   Conditional Access 插在中間做動態決策    │
└────────────────────────────────────────────┘

🎲 AWS 經典情境一：以來源 IP 與 MFA 狀態動態限制存取（SAA-C03 考點改編）

情境題目： Titan 科技的安全團隊要求：當 DevOps 工程師嘗試透過 AWS Management Console 或 CLI 執行正式環境資源的敏感操作（例如終止生產 EC2 執行個體）時，必須同時滿足「從企業辦公室出口 IP 連線」且「已透過 MFA 完成驗證」，否則立即拒絕操作。在 AWS 架構中應如何實現此動態控制？

• A. 僅在 VPC Security Group 中加入企業辦公室 IP 規則
• B. 在 IAM Policy 中使用 Condition 區塊，設定 aws:SourceIp 與 aws:MultiFactorAuthPresent 進行明確拒絕 (Deny)
• C. 為每位工程師建立獨立的 AWS 帳號並手動登入
• D. 在 S3 Bucket 上設定 Object Lock

┌────────────────────────────────────────────────────────────┐
│ 條件式存取 vs IAM Policy 動態決策流程                      │
├────────────────────────────────────────────────────────────┤
│ 存取要求 (User / Role / Client)                            │
│   │                                                        │
│   ▼                                                        │
│ 條件訊號評估 (Condition Evaluation)                        │
│   ├── AWS：aws:SourceIp / aws:MultiFactorAuthPresent       │
│   └── Azure：位置 / 裝置合規 / 使用者風險等級              │
│   │                                                        │
│   ▼                                                        │
│ 執行控制決策 (Enforcement Decision)                        │
│   ├── 符合條件 ──> 放行 (Grant Access / Allow)             │
│   └── 未達要求 ──> 要求 MFA (Step-up) 或直接封鎖 (Deny)    │
└────────────────────────────────────────────────────────────┘

答案：B。 AWS IAM Policy 的 Condition 區塊允許架構師根據請求上下文（Contextual Signals）動態判定。搭配 aws:SourceIp 與 Bool 判斷 aws:MultiFactorAuthPresent: "true"，並使用 Effect: "Deny"（搭配 NotAction 或 NotIpAddress），能實作不可繞過的防護圍欄。A 只能管進入 VPC 的網路流量，無法約束 Console/IAM API 操作；C 造成身分管理混亂且無法動態驗證 MFA 狀態；D 用於 S3 物件防竄改，與 API 呼叫控制無關。

Azure 知識映射與連動解析：
對應至 Azure AZ-900 考點，這正是 Conditional Access Policy（條件式存取原則） 的核心職責！AZ-900 考題若出現「當使用者從未受信任的位置登入時強制 MFA」或「非公司受管裝置禁止存取 Portal」，正解必定是 Conditional Access。架構師須認清：AWS 是將條件邏輯寫入 JSON IAM Policy/SCP 的 Condition 元素中；Azure 則是獨立出專屬的策略引擎（Conditional Access），以 Zero Trust「永不信任，始終驗證 (Never Trust, Always Verify)」的 if-then 模型動態把關。

🎲 AWS 經典情境二：跨系統統一身分驗證與目錄整合（CLF-C02 / SAA-C03 考點改編）

情境題目： Titan 科技收購了一家新創公司，該公司原本擁有一批依賴傳統 Windows 網域（Active Directory）的內部會計系統，需要進行 LDAP 查詢與 Kerberos 驗證。Titan 希望將系統遷移至雲端虛擬機，但不希望在雲端自行架設、備份與修補兩台 Windows Domain Controller 虛擬機器。在 AWS 與 Azure 中分別對應什麼架構？

• A. 在 AWS 使用 AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD)；在 Azure 使用 Microsoft Entra Domain Services
• B. 在 AWS 使用 Amazon Cognito；在 Azure 使用 Microsoft Entra ID 免費版
• C. 在 AWS 使用 IAM Identity Center；在 Azure 使用 Azure Key Vault
• D. 在 AWS 使用 AWS Secrets Manager；在 Azure 使用 Azure Policy

答案：A。 關鍵字為「傳統 LDAP 查詢」、「Kerberos 驗證」且「免自行維護網域控制器」。AWS Managed Microsoft AD 是由 AWS 完全託管的真實 Windows AD 基礎設施；而在 Azure 中，這正是 Microsoft Entra Domain Services（全託管傳統網域服務，提供 LDAP、Kerberos、NTLM 與網域加入能力）。B 中的 Cognito 與 Entra ID 皆為現代雲端原生身分（OAuth 2.0 / OIDC / SAML），不直接提供 Kerberos/LDAP 繫結；C 與 D 服務定位完全偏離目錄驗證。

雙雲考場口訣：

先驗證身分，再授與權限——順序不可逆
Entra ID ↔ IAM + Identity Center（方向性對照）
Conditional Access ↔ IAM Conditions + SCP（方向性對照）
Entra Domain Services ↔ AWS Managed Microsoft AD / AD Connector
密碼是攻擊面，Passwordless 才是防禦的終點

📐 Part 4：以戰代訓課程對照

🚀 今日總結與明日預告

🏆 今日 3 點速記精華

1. 先 Authentication 再 Authorization，順序不可逆：登入成功但無法操作 = 驗證通過、授權不足；登入失敗 = 驗證本身出問題。考題用「帳密正確卻無法操作」設陷阱，答案永遠指向 Authorization。
2. Conditional Access 是 Zero Trust 策略引擎：根據使用者、位置、裝置、風險等訊號動態決策（允許 / 要求 MFA / 封鎖），在第一因素驗證後觸發。看到「特定條件下強制 MFA」就選 Conditional Access，不是 Azure Policy 也不是 NSG。
3. Entra ID ≠ Entra Domain Services：現代雲端應用選 Entra ID（OAuth / OIDC / SAML）；舊系統需要 LDAP / Kerberos / domain join 選 Entra Domain Services。名稱相似但協定與定位完全不同。

🔮 明日預告

身分已就位，明天 Day 23 我們將深入 Role-Based Access Control (RBAC)，拆解「誰 (Security Principal) 能在什麼範圍 (Scope) 做什麼 (Role Definition)」的三元組，並對照 AWS IAM Policy，學會以最小權限原則保護 Titan 科技的每一層資源。

(如果你能清楚區分 Authentication 與 Authorization、說出 Conditional Access 的 if-then 邏輯、並判斷何時該用 Entra ID 而非 Entra Domain Services，恭喜你已掌握雲端身分安全的第一道防線！)