Azure帳號認證開戶 Azure 帳戶購買後的設定

前言：帳戶買完只是開始，真正的戰場在設定

買到 Azure 帳戶的那一刻，你可能會有一種「終於可以開始雲端冒險了」的衝動。沒錯，可以開始了；但請先別急著把資源狂丟進去。因為 Azure 最擅長的技能之一，就是在你還沒準備好之前，默默提醒你：你設定得好不好，會直接影響安全、成本、可管理性，甚至你之後會不會想把滑鼠摔掉。

所以這篇文章就來談「Azure 帳戶購買後的設定」。目標很實際：讓你把帳戶從可用狀態，提升到可控、可追蹤、可交付、可擴充的狀態。文中我會用比較像真人整理筆記的方式，講清楚你該做哪些事、為什麼要做、以及常見坑要怎麼躲。

第一步：先確認你手上到底是什麼帳戶

在動手設定之前，先把基本盤確認清楚。因為 Azure 的組織結構有時會讓人感覺像在玩俄羅斯套娃：帳戶、訂閱、管理群組、資源群組……每一層都會影響權限與計費。

1. 了解你的「Microsoft Entra ID」與登入身分

Azure 現在幾乎所有事情都會連到 Microsoft Entra ID（原 Azure AD）。你登入 Azure 入口時看到的那個租用戶（tenant），就是你後續設定權限、使用者、群組、條件式存取的根。

• 先確認你目前使用的租用戶名稱與網域。
• 確定你是誰：全域管理員（Global Administrator）、特定管理員、或一般使用者。

如果你不是管理員，先別急著操作設定，先把必要權限拿到手。不然你會進入那種「我明明知道要設，但就是按不了」的痛苦迴圈。

2. 檢查訂閱（Subscription）清單與類型

訂閱才是你真正用來部署資源與產生費用的核心。進入 Azure 入口後找「訂閱」，查看：

• 你有幾個訂閱（有些公司會一開始就分開不同環境：Dev/Test/Prod）。
• 訂閱是不是你預期的帳單類型（Pay-as-you-go、Microsoft 額度方案等）。
• 是否有你沒買但突然出現的訂閱（偶爾會是你被加入了別人的租用戶或訂閱）。

第二步：建立組織結構，避免未來「成本追蹤比找貓還難」

你可以把 Azure 想成一個城市。你要先決定：你要在哪個行政區蓋房子，誰能管哪條街，房子出了問題找誰。Azure 的對應關鍵字就是管理群組、訂閱與資源群組。

1. 建立管理群組（Management Group）

管理群組的好處是：你可以在更上層套用原則（Policy）、RBAC（角色權限）與結構，而不用每個訂閱都手動做一遍。

建議的做法（視團隊大小調整）：

• 按環境：Dev、Test、Prod
• 或按部門：IT、Data、App
• 或按專案：ProjectA、ProjectB（小團隊也可用）

你不必一次做得完美，但至少先定一個方向。因為之後你真的會遇到「同一套策略要用在所有訂閱」這種需求。

2. 統一資源群組命名規則

資源群組（Resource Group）是資源的集合。命名規則會影響你日後尋找資產、套用政策、以及判斷成本歸屬。

簡單好記的一種格式：

• {環境}-{專案}-{區域}

例如：prod-shopapp-tw、dev-analytics-eastus。中文團隊也可以用英文，避免之後跨平台或跨工具時出現奇怪編碼。

第三步：設定權限與角色，別讓「每個人都能開火」

很多人設定 Azure 時只顧著部署，結果權限鬆到像自助餐：想吃就拿、拿完也不一定會結帳。為了避免意外刪除、亂開服務爆預算，你要把權限模型做好。

1. 規劃管理員角色分工

在 Entra ID / Azure 中，常見角色包括：

• 管理群組/訂閱層級：擁有者（Owner）、參與者（Contributor）、讀取者（Reader）
• 資源層級：依服務調整更細的 RBAC

建議：

• 避免把 Owner 發給大量人。
• 把「管理權」與「使用權」分開。
• 至少建立兩到三個群組：例如 Cloud-Admins、Cloud-Operators、Cloud-Readers。

2. 使用群組（Group）而不是個人（User）

把權限給「一個人」聽起來很直覺，但人會換工作、頭銜會改、甚至離職。群組才是可維護的做法。

例如：

• Cloud-Admins：可管理訂閱與策略
• Cloud-Operators：可部署資源但不做政策變更
• Cloud-Readers：只讀

這樣你要調整人員時，只要改群組成員，不用翻遍所有訂閱設定。

第四步：計費與成本防護，讓你的預算活得比較久

Azure 的計費通常是按用量、再加上各種服務費率。你可以把它想成：你點餐是你自己決定的，帳單也是你自己簽的。那問題來了：你能不能提前知道「這桌要不要付 3 倍價格」？

1. 設定預算（Budget）與通知

強烈建議啟用預算與警示。目標是：成本接近某個門檻時，你就能在爆掉之前先把火調小。

• 先設定 50%、80%、100%（或你公司習慣的比例）
• 把通知發到正確的人（財務？雲端負責人？專案 PM？）

2. 設定資源標籤（Tags），讓成本歸因可追蹤

沒有標籤的成本，通常是最難處理的那種：看起來很高，但不知道是誰開的、為什麼開、下一步要關什麼。

建議至少標籤：

• Environment：Dev/Test/Prod
• Project：專案名稱或代號
• Owner：負責人
• CostCenter：成本中心（有就填，沒有可先留空或用規則代替）

另外，你也可以用 Azure Policy 強制標籤存在。沒有標籤就禁止部署，這招很有效，雖然剛開始團隊會覺得你在「找麻煩」，但數週後就會感謝你。

第五步：安全性設定：別讓帳戶像停在路邊的車

如果你只做一件安全相關的事，那就是把多因素驗證（MFA）搞定。因為憑證被盜的災難案例，幾乎每個雲端團隊都見過。你不希望自己成為那個案例。

1. 啟用 MFA（多因素驗證）

至少為管理員帳號啟用 MFA，並建議對所有使用者提高要求。

• 可考慮強制使用者啟用 Microsoft Authenticator
• 確保通過的裝置與備援流程（例如替代電話或備援方法）已配置

2. 條件式存取（Conditional Access）

條件式存取可以做到更精準的控制，例如：

• 要求使用特定條件才允許登入（地理位置、裝置合規、風險等）
• 特定角色或特定操作才允許使用某種登入方式

最常見的落地目標：保護管理入口。你不希望有人用陌生裝置登入你的管理員帳號後，開始部署、刪除或建立惡意資源。

3. 設定安全警示與稽核

至少要能回答三個問題：

• 誰在什麼時間做了什麼？
• 登入失敗或異常活動有沒有被記錄？
• 如果出了事，我要看哪裡？

請確保你有開啟並能存取 Azure 活動記錄（Activity Log）、資源稽核（依服務不同）與警示整合（例如傳到 Log Analytics 或 SIEM）。

第六步：網路與存取控制：把資源藏起來，別像把零件攤在桌上

很多人的「剛買 Azure」版本會先跑起來，之後再慢慢把網路安全補齊。但如果你能在一開始就規劃好基本網路架構，後面省下的時間通常會非常可觀。

Azure帳號認證開戶 1. 規劃虛擬網路（VNet）與子網（Subnet）

通常會需要：

• 至少一個 VNet
• 根據系統分區：例如 App、Data、Management
• 設定 NSG（網路安全群組）規則

不要一開始就把一切都丟到同一個子網、同一組網路規則。等你服務多起來，你的防火牆規則會變成「看不懂但不敢動」的藝術品。

2. 私網存取與公開暴露（Public Exposure）檢查

當你建立服務（例如 VM、App Service、Storage、Database）時，請先想清楚：哪些需要對外公開？哪些應該只內網？

• 能關就關：沒有必要就不要開到公網。
• 資料庫優先考慮受控存取：例如限制存取來源、使用私有端點（Private Endpoint）視需求。
• 對外服務務必加上基本安全：例如 TLS、WAF（若適用）。

第七步：建立監控與告警：讓系統出狀況時有人知道

你當然希望服務永遠正常。但現實是：磁碟滿了、網路延遲了、憑證過期了、某個服務突然被你自己加大規模，成本就突然冒出來。

1. 啟用 Log Analytics / Application Insights（視服務而定）

Azure帳號認證開戶 建議至少把關鍵服務的日誌和指標（Metrics）集中到同一個監控區域。

• VM：連到 Log Analytics Workspace
• Web 應用：Application Insights（或等效方案）
• 容器/服務：依方案接入對應監控

2. 告警要「有行動」而不是「只是提醒」

告警的價值在於：你收到通知後，知道要做什麼。設定告警時可以把行動流程想一下：

• CPU 長時間過高 → 誰處理？調整擴縮？
• 儲存空間接近上限 → 由哪個人清理？
• 費用接近預算 → PM 跟雲端負責人會怎麼調整？

Azure帳號認證開戶 如果你只是把告警丟到某個群組但沒 SOP，那它就會變成「噪音」。噪音太多，人就會忽略你。

第八步：資源部署前的「必做檢查清單」

在你開始部署第一批資源之前，我建議你先跑一遍清單。你不需要完美，但需要基本穩定。

Azure帳號認證開戶 1. 標籤規範是否已套用（或至少你知道缺什麼會被罵）

• Environment、Project、Owner、CostCenter（或至少三個核心欄位）
• 是否強制標籤（Azure Policy）

2. RBAC 與群組是否就位

• Admins / Operators / Readers 群組建立完成
• 管理權不給過多的人

3. 成本警示與預算是否已設定

• Budget 門檻設定
• 通知收件人正確

4. MFA 與條件式存取是否已上線

• 管理員帳號已啟用 MFA
• 必要情境下有條件式限制

5. 監控與日誌是否能查到

• 至少能看到活動記錄
• 核心服務的指標/日誌能被收集

第九步：常見踩雷點（看完你會感覺自己提早躲過一車釘子）

下面是我見過最常見、也最容易讓人心情瞬間跌到地板的狀況。你可以把它當作「災難題目」的解答。

1. 忘記在訂閱或管理群組套用政策（Policy）

例如要求標籤、限制某些區域、禁止某些 SKU 等。沒有政策就等於每次部署都靠人自覺。人類很誠實，但人類也很容易忙到忘記。

2. 把所有資源都放在同一個資源群組

當你要刪除某個環境或回收資源時會很痛苦。資源群組不是「垃圾桶」，它應該是邏輯邊界。

3. 管理員權限太寬鬆

Azure帳號認證開戶 權限太鬆會帶來兩種問題：安全風險與成本風險。有人不小心刪了東西你還能救，有人不小心開到高規格服務，你帳單可能直接通知你「下個月再哭」。

4. 成本預算沒設定或收不到通知

預算不是為了「讓你知道自己花了多少」，而是為了「讓你在花到不可收拾之前知道」。如果通知沒有到負責人手上，那就等於沒有。

5. 網路一開始就全公開

這不是說完全不能公開，而是你要確定你知道自己在公開什麼。未規劃的公開，可能讓你被掃描、被攻擊，甚至被資料外洩。安全不是裝飾品，是系統的一部分。

第十步：把「一次性設定」變成「可持續運作」

很多團隊剛開始時會做得很勤快，後來就慢慢鬆掉。原因不是大家不努力，而是雲端環境會長大，事情會變多。

你可以從一開始就建立一些習慣：

• 每個新訂閱/新環境上線前跑一遍清單
• 把設定寫成文件（簡單版本也可以）
• 定期檢查權限：誰還需要擁有者？誰該降權？
• 定期回顧預算與標籤策略是否有效

這樣你不會在某個月的週一早上被迫面對「為什麼成本突然爆了」這種靈異事件。

結語：你的 Azure 不是用來測試人生的

Azure 帳戶購買後的設定，看似是瑣碎的管理工作，但它其實是你雲端成功的地基。只要把權限、安全、成本與監控基本做到位，你後續部署速度會更快、問題排查會更省力、而且你不太需要靠運氣。

最後送你一句話（帶點幽默但很真）：
「雲端不是魔法，安全不是祈禱，成本也不會因為你不看就消失。」
把設定做好，讓 Azure 跟你一起合作，而不是跟你玩猜猜我是誰。

附錄：一頁式快速檢查清單（你可以直接抄走）

• 確認 Entra ID 租用戶與訂閱清單
• 建立管理群組與命名規則（資源群組、環境）
• 用群組做 RBAC：Admins / Operators / Readers
• 啟用 MFA；視需求建立條件式存取
• 設定 Budget 與成本通知；資源標籤策略落地
• 規劃 VNet、NSG、避免未控管的公網暴露
• 啟用監控與日誌收集；告警要能觸發行動
• 跑一遍部署前清單，避免先天就埋雷