Azure企業帳號註冊 微軟雲Azure註冊環境點樣隔離

引言：註冊環境點樣隔離？先唔好慌

講到「註冊環境點樣隔離」，有啲人會想：係咪要開一堆 subscription，甚至多個 tenant？答案係：視乎你嘅需求，但大原則係分層隔離、最少權限、再用政策（policy）綁緊。今次我會用生活化、帶少少幽默嘅方式，逐步講清楚點樣把 Azure 裡面與註冊相關嘅各種元素（身份、網路、資源、成本、監控）分層隔離，令你既安全又唔會被團隊罵話做得太窮酸。

為何要隔離註冊環境？問題唔止安全咁簡單

簡單講：註冊環境係一個會有大量「嘗試」、「測試」、「自助註冊」嘅地方，如果唔隔離，可能會出現以下幾樣悲劇：

• 測試資源誤混入生產，導致緊急維護時找唔到真兇。
• 權限過寬，開發人員一不小心改咗全域策略，整個平台中招。
• 成本跑高，因為有人喺註冊環境亂開大型 VM 或者未關資源。
• 資料洩漏：敏感測試資料無適當的 Key Vault 或網路隔離。

所以隔離唔只係保護生產，仲係保護開發測試效率、降低成本、方便治理。

隔離的原則（八字方針）

唔需要每件事都咁複雜，記住以下八字方針就好：分層、最少權限、自動化、可觀察。

• 分層（Layering）：租戶→管理群組→訂閱→資源群組→資源，各層都有角色。
• 最少權限（Least Privilege）：RBAC 精準授權，不用 broad owner/Contributor。
• Azure企業帳號註冊 自動化（Automation）：用 Policy、Blueprint、Terraform/ARM template 自動化部署。
• 可觀察（Observability）：日誌、監控、成本報表要分開，方便追蹤與稽核。

層級一：身分與租戶（Identity & Tenancy）

租戶與多租戶策略

第一步先問：你係咪需要多個 Azure AD Tenant？答案通常係：

• 大公司、合規或隔離客戶資料：建議多 tenant（例如每個客戶或事業群一個 tenant）。
• 中小型企業、一個公司內部隔離：通常一個 tenant 已足夠，用 subscription + 管理群組隔離。

多 tenant 的代價係身分跨 tenant 管理麻煩（B2B 還可以，但要做好身分治理與群組同步）。

Azure AD 與註冊流程隔離

註冊環境往往涉及自助式註冊（self-service）或外部使用者加入。如果開放太鬆，容易造成垃圾帳號或未授權的應用註冊。做法包括：

• 限制誰可以註冊應用（App registrations）以及註冊外部應用（Enterprise applications）。
• 啟用要求批准的應用與諮詢流程，或用僅允許 IT 註冊策略。
• 使用 Conditional Access 與 MFA，特別係有管理員權限或敏感權限嘅賬戶。
• 使用 Azure AD Privileged Identity Management （PIM）做 Just-In-Time（JIT）權限，避免長期擁有高權限。

來賓帳戶與 B2B

如果你的註冊環境會有外部開發者或合作夥伴，建議用 Azure AD B2B，並且把來賓帳戶放入特定群組與策略範圍內，避免來賓誤拿到生產訂閱許可。

層級二：管理群組與訂閱設計（Subscriptions & Management Groups）

建議的訂閱策略

訂閱係成本與配額的邊界，也是資源隔離的自然單位。常見分法：

• 按環境分：dev / test / staging / prod（開發測試與生產分開）。
• 按用途分：平台工具、共用服務（shared services）、業務單位。
• 按成本中心分：方便做帳與 chargeback。

記住：多訂閱可以提升隔離，但亦會增加管理複雜度。用管理群組把訂閱分類，並在管理群組套用 Policy 與 RBAC。

管理群組（Management Groups）最佳實務

• 建立 Root -> Core -> Platform -> Workloads 邏輯層級。
• 在 Core 加上共用政策（例如監控、日誌、資安政策），Platform 放置共享服務訂閱（例如 Azure Firewall、DNS、Jumpbox）。
• 工作負載訂閱放在 Workloads 群組，各自套用更嚴格的政策（例如不允許公共 IP、強制私有端點）。

層級三：網路隔離（VNet、NSG、Firewall）

基本口訣：私有、零信任、最少暴露

註冊環境應該預設私有：所有敏感資源只透過 VNet 與 Private Endpoint 連接。不要把 Storage 或 SQL 暴露於公共端點。如果要對外提供註冊介面，透過 Application Gateway 或 Azure Front Door 加上 WAF 與 IDP 保護。

實作要點

• 用 Hub-and-Spoke 網路架構：Hub 放共用防火牆（Azure Firewall、NVA），Spoke 放 workload（註冊系統、測試環境）。
• NSG（Network Security Group）做子網基礎防護，防止南北向流量亂走。
• Azure Firewall 或 NVA 做更細緻的流量過濾與日誌紀錄。
• Private Link / Private Endpoint：把 PaaS 服務私有化，避免公網存取。

層級四：資源分區（Resource Groups、Naming、Tagging）

資源群組不是安全邊界，但係好用於管理

資源群組方便生命週期管理（同時部署／刪除），但 RBAC 亦可以套用到資源群組做細粒度控制。命名標準與標籤（tags）方面，建議：

• 命名要包含環境（env）、業務單位（bu）、應用名稱（app）等，方便搜尋與報告。
• 強制使用 Tag（owner、costCenter、environment、dataClassification）並用 Policy 檢查或補登（enforce/append）。

層級五：治理與政策（Azure Policy、Blueprint）

Policy：從被動監測到強制執行

用 Azure Policy 來阻止常見風險，例如：

• 禁止 public IP、禁止未加密存儲、強制使用私有 endpoint。
• 強制註冊時建立 Tag、限制 VM 大小、或限制 Region。
• 用 Initiative（policy set）把相關政策打包，套用在管理群組。

Blueprint 與 Landing Zones

使用 Azure Blueprint 或 landing zone 模板，預先建立好網路、監控、政策與共用資源。這樣當新訂閱或註冊環境要上線時，可以一鍵部署標準化配置，避免人手出錯。

層級六：金鑰與資料隔離（Key Vault、Storage、Database）

Key Vault 分割策略

把敏感金鑰放喺受控的 Key Vault，並對 Key Vault 使用防火牆規則與私有端點。建議：

• 不同環境（dev/test/prod）用不同的 Key Vault。
• 用 Managed Identity 存取 Key Vault，而唔係把金鑰寫死落 code 或設定檔。
• 啟用 Key Vault 記錄（診斷日誌送到 Log Analytics 或 Storage），方便稽核。

資料庫與儲存隔離

使用 VNet Service Endpoint 或 Private Endpoint 把 PaaS 服務私有化。對於測試資料，務必用資料遮蔽或匿名化，避免使用真實敏感資料於註冊/測試環境。

層級七：部署流程與自動化（CI/CD 與 IaC）

把環境建成代碼（Infrastructure as Code）

用 ARM / Bicep / Terraform 把 landing zone 與註冊環境 codify，透過 CI/CD 套用到各個訂閱。優點：

• 一致性：每次部署都有相同基線。
• 可追蹤：版本控管，誰改咗可以回溯。
• 可測試：先在 dev 測試，再自動推到 prod（如果需要）。

CI/CD 的權限隔離

CI/CD pipeline 不應該有跨所有訂閱嘅高權限，應該用最小權限的 service principal 或 managed identity，並用不同的 pipeline 與憑證隔離不同環境。

Azure企業帳號註冊 層級八：監控、日誌與稽核（Observability）

Azure企業帳號註冊 Log Analytics 與監控策略

監控要分層：共用的監控 workspace 放在平台訂閱，workload 的詳細日誌可送到各自 workspace（或採用共用但加上 tags 與查詢分隔）。確保：

• 啟動診斷日誌（Activity Log、Resource Logs）並收集到 Log Analytics / Storage。
• 設定警示（Alerts），例如異常註冊次數、未授權的應用註冊等。
• 定期跑稽核報告，例如誰開咗公網端點、誰新增了 Owner 權限。

層級九：成本與計費隔離

成本管理唔係細枝末節，尤其係註冊環境有大量短期測試資源。做法：

• 按訂閱或 Tag 做成本中心分離，確保成本歸屬清晰。
• 用 Budget 與 Cost Alert，超過門檻就通知或自動停用非關鍵資源。
• 對於臨時測試資源，使用自動化關閉（Auto Shutdown）或設定 TTL（time-to-live）。

常見陷阱與避免方法

• 陷阱：把所有人都設為 Owner，容易被改壞。避免方法：細粒度 RBAC 與 PIM。
• 陷阱：測試用真實資料。避免方法：使用資料遮蔽、合成資料或受控 sandbox。
• 陷阱：監控太少。避免方法：先訂關鍵指標（註冊次數、失敗率、資源建立事件）再展開。
• 陷阱：疏於更新 Policy。避免方法：定期 review policies，並把政策管理納入 CI/CD。

檢查清單（快速檢核，部署前必做）

• 是否按環境建立訂閱？（dev/test/prod）
• 是否在管理群組套用必要的 Policy？
• 是否限制了 App registrations 與 Enterprise applications？
• 是否使用 Private Endpoint / Private Link 以避免公網暴露？
• 是否把敏感金鑰放 Key Vault 並啟用私有端點？
• 是否有成本預算與自動關閉機制？
• 是否將診斷日誌集中並設定必要告警？
• 是否把 IaC 與部署流程做版本控制與自動化？

實務範例：一個簡單又實用的架構建議

假設你係中型企業，想為註冊環境做隔離，可採用：

• Azure企業帳號註冊 一個 Azure AD Tenant（若需更高隔離，可多 tenant）。
• 管理群組：Root → Core → Platform → Workloads。
• Azure企業帳號註冊 訂閱劃分：Platform-sub（共用服務）、Dev-sub、Test-sub、Prod-sub。
• Hub VNet 放 Azure Firewall 與 Azure Bastion，Spoke 放各環境應用。
• Key Vault 按環境分；PaaS 服務走 Private Endpoint。
• Policy：禁止 public storage、強制 Tag、強制 Key Vault 私有端點。
• Log Analytics：平台日誌集中，workload 日誌分開或用 table tag。
• CI/CD：不同 pipeline、不同 service principal、不同權限。

結語：隔離係藝術，亦係工程

做隔離唔係為咗搞到團隊唔方便，而係要建立一個既安全又友善嘅環境，令開發可以快，而風險可控。總結要點：按場景決定 tenant/訂閱策略、以 Policy 與 Blueprint 建立標準化 landing zone、採用最少權限並自動化部署與監控。最後，記住要定期檢視與演練——隔離不是一次性工程，而係長期的治理習慣。

附錄：快速參考資源與命令（指路用）

下面幾個關鍵點可以讓你快啲上手：

• Azure Policy 範例：不允許 public IP / 要求 Tag（Azure 入口網站或 az policy 指令）。
• Key Vault 私有端點設置：先建立 Private Endpoint，然後把 Key Vault 防火牆設為僅允許私有連線。
• PIM 設定：把高權限角色設成 eligible，要求多因素認證與審批流程。
• 使用 Bicep/Terraform 管理 landing zone，並在 pipeline 裡面做驗證（plan 環節）。

好啦，如果你今次只記得一樣事：別把生產與註冊環境放喺同一個籃子入面。其他嘢，慢慢用上面啲方針、Policy、以及 IaC 來把環境做好，做得差唔多你已經係英雄，不過記住：真英雄會定期清理測試資源，唔會等到月底先嚟發現帳單炸咗。