AWS帳號購買服務 AWS帳號安全MFA雙重認證開啟教學

第一章：為什麼 AWS 必須開啟 MFA

AWS 的安全思維，講白了就是「假設密碼會被猜到或被偷走」。在實務中，攻擊者常見的手法不是直接破解強密碼，而是透過釣魚、資料外洩重複使用密碼、惡意程式或帳號被接管。當攻擊者拿到你的 AWS 登入密碼後，若沒有 MFA（多重認證），他們就能直接嘗試使用各種權限去存取雲端資源。

MFA 的價值在於它在密碼之外再加一層「你擁有的東西」。攻擊者即使拿到密碼，也還需要另外那個第二因素（例如手機驗證碼或硬體金鑰）。這樣一來，攻擊成功率會大幅下降，且你能大幅延長搶救與止血的時間。

更重要的是：AWS 的 MFA 不只是「加個選項」。你可以把 MFA 當作安全策略的一部分，要求特定使用者或角色在進行登入或某些敏感操作時必須完成第二因素驗證。這會讓整體風險從「被動防守」變成「有條件允許」。

第二章：在開始之前，先釐清你要保護的範圍

很多人第一次開啟 MFA 時會混淆：我只要保護登入就夠嗎？我是否需要針對每個 IAM 使用者都設？答案取決於你的使用方式與組織規模，但你可以先用三個問題對齊目標。

第一，你的 AWS 使用方式是什麼？ 是只有少數人用主帳號登入管理，還是大量人透過 IAM 使用者或 SSO 進入？

第二，你的風險偏好如何？ 若你希望任何登入都必須 MFA，那就要把要求落在所有必要的使用者與登入路徑上，而不是只開在主帳號。

第三，你是否使用角色（Role）或臨時憑證？ 很多團隊會透過 AssumeRole 或跨帳號存取。此時你也要確保策略中對 MFA 的條件有被正確要求。

下面的教學會以「帳號安全」作為主軸：先把主帳號的 MFA 開起來，再把關鍵使用者/角色的策略補齊，讓整體落地。

第三章：準備 MFA 所需的工具與選項

AWS 目前常見的 MFA 方式主要有兩類：虛擬 MFA（TOTP） 與 硬體 MFA（安全金鑰/硬體裝置）。兩者都能提升安全性，但操作體驗與設備依賴不同。

虛擬 MFA（TOTP）的特點

你會在手機上安裝支援 TOTP 的驗證器（例如常見的驗證器 App），AWS 會顯示一組 QR code 或金鑰，你把它加到 App 裡後就能產生動態碼。優點是容易部署，缺點是手機遺失或換機時需要處理備份與轉移。

硬體 MFA 的特點

硬體金鑰通常插入或透過近距離方式使用，並產生驗證結果。優點是對釣魚與惡意環境的抵抗通常更好，且不依賴手機號碼。缺點是成本較高，且需要保管實體裝置。

實務建議：小團隊想快速完成與普及，可以先用虛擬 MFA；如果你處理高敏感資料或合規要求更嚴格，硬體 MFA 是更穩的方向。無論選哪種，都要把「備援計畫」想好：例如第二支裝置、備份金鑰或指定的替代驗證方式。

第四章：主帳號（Root User）先開啟 MFA

先講重點：AWS 主帳號（Root User）是權限最高的存在。即便你已經用 IAM 把日常操作都用較低權限的使用者做了，主帳號仍可能成為攻擊者最後的突破口。因此，主帳號的 MFA 你應該優先開啟。

步驟 1：登入 AWS 主控台

使用主帳號登入 AWS Management Console。建議你在自己的主機環境中操作，不要在不可信網路或不明瀏覽器環境下處理。

AWS帳號購買服務 步驟 2：進入「安全性憑證」設定

在主控台右上角或個人設定中，找到與「安全性憑證」「Security credentials」相關的頁面。這裡通常能看到帳號的登入設定、MFA 狀態、以及可以管理驗證器。

步驟 3：新增 MFA 裝置

在 MFA 區塊選擇「管理 MFA」或「Assign MFA」。接著系統會引導你選擇 MFA 類型（虛擬或硬體）。

若你使用虛擬 MFA，AWS 會提供一個「QR code」與一個「金鑰」。你需要在驗證器 App 內新增帳戶（通常選擇掃描 QR code 或手動輸入金鑰）。新增後，App 會開始每 30 秒產生一組動態碼。

你接著把 App 顯示的動態碼填回 AWS 的輸入框，按確認即可完成綁定。

步驟 4：完成後立即測試

啟用完成後，你可以嘗試登出再登入，確認系統確實會要求 MFA。不要只看狀態已開啟就算，因為有時候時間不同步或裝置設定錯誤會導致你未來登入被擋在門外。

同時要記下：你使用的 MFA 是哪一個裝置、來源 App 是什麼、以及若更換手機要怎麼重建。

常見失敗原因與處理

動態碼一直失敗：多半是時間不同步。TOTP 依賴裝置時間，請確認手機時間自動校正（或校正後重試）。

QR code 掃描後沒有看到新帳戶：有些 App 需要手動選擇帳戶類型（TOTP/HOTP）。請在 App 內確認新增是否成功。

以為開了 MFA 就能完全防攻擊：MFA 主要防止「密碼被用來直接登入」。它不取代權限最小化，也不替代存取控制、雲端金鑰治理與日誌監控。

第五章：把 MFA 落到 IAM 使用者（而不只停在 Root）

主帳號開啟 MFA 是底線，但在日常營運中，你不應該讓多數人直接用主帳號登入。實際上，大多數操作應由 IAM 使用者、群組、或角色來承接。

因此，你需要決定：你要不要要求「所有 IAM 使用者登入必須 MFA」或至少「特定敏感使用者必須 MFA」。這樣才能避免攻擊者透過 IAM 使用者弱化後繞過主帳號的保護。

步驟 1：選擇策略層級

AWS帳號購買服務 通常有兩個做法：

做法 A：在 IAM 使用者層級要求 MFA（例如透過管理設定或條件）。

做法 B：用 IAM 政策條件（Condition）限制只有在 MFA 通過時才允許敏感動作。

在實務上，做法 B 更有彈性，也更容易統一管理。你可以把 MFA 當成一個條件來控管。

步驟 2：理解 MFA 條件判斷（重點概念）

AWS 的 MFA 在政策條件中常用的概念包含「是否已登入並帶有 MFA session」。這種訊息通常以特定條件鍵表示（例如 aws:MultiFactorAuthPresent 或 aws:MultiFactorAuthAge 之類的判斷）。

簡單說：你可以寫策略，要求在執行某些動作時，必須 MFA 已完成，或 MFA 在一定時間內仍有效。

AWS帳號購買服務 如果你不熟政策語法，建議你從「先要求登入或特定高風險操作」開始，而不是一口氣鎖死所有動作。否則容易把團隊自己鎖在外面。

步驟 3：示例目標（你要達到什麼效果）

以下是常見可落地的目標，你可以依團隊需求選擇：

• 目標 1：所有管理操作（例如建立/修改 IAM 資源）必須 MFA。
• 目標 2：登入時必須 MFA（或至少以 MFA 作為高敏感操作的通行證）。
• 目標 3：啟用 MFA 才能使用特定權限，例如允許存取某個敏感 S3 bucket、某些 KMS 操作、或跨帳號角色。

不必每一項都同時做，但你至少要先把「最危險的權限」圈起來。

第六章：在策略中要求 MFA（讓防護真的發揮作用）

如果你只對主帳號開 MFA，攻擊者仍可能用被盜的 IAM 使用者帳密登入，並利用你給他的權限操作資源。真正的防護需要把 MFA 條件嵌入權限授予。

你可以用以下思路完成：把敏感動作與 MFA 條件綁在一起。這樣即使密碼被偷，攻擊者也缺少 MFA。

步驟 1：挑出敏感動作範圍

先想清楚哪些動作最危險。例如：

• IAM：建立/刪除使用者、修改存取權、管理密鑰、查看或設定憑證。
• 安全設定：關閉或修改安全相關設定。
• 資源存取：允許讀寫敏感資料或大量刪除資源。
• 角色與權限提升：AssumeRole、更新信任關係等。

AWS帳號購買服務 敏感動作越精準，你的策略越好用。太寬會讓團隊操作變麻煩；太窄又可能漏洞仍在。

AWS帳號購買服務 步驟 2：在 IAM 政策中加入 MFA 條件

在 IAM Policy 的 Condition 中，通常會使用 MFA 相關條件鍵判斷是否完成多重認證。當你加入這條件後，策略會在「符合條件」時才允許動作。

建議做法是：先從只限制「特別敏感」的動作開始。等團隊熟悉後，再逐步擴大覆蓋範圍。你要避免一上來就把所有操作都綁 MFA，導致人員工作中斷、甚至繞過流程。

步驟 3：把策略套用到群組或特定角色

如果你有多個使用者，與其一個一個綁定，不如用群組（Group）或角色授權集中管理。這樣未來新增人員只要加入群組就自然得到同樣的 MFA 要求。

此外，若你採用 AssumeRole，請留意：MFA 要求可能也要對角色取得的路徑生效。否則攻擊者仍可能在被允許的 AssumeRole 中繞過你原本的直覺。

第七章：切記 MFA 與「存取金鑰、存取路徑」不是同一件事

很多人把 MFA 當作唯一解法，但在 AWS 還有另一個同樣常見的風險來源：長期存取金鑰（Access Key）外洩。如果攻擊者拿到 Access Key，他們可能不需要走「Console 登入」流程；他們會直接用 API 呼叫完成操作。

AWS帳號購買服務 因此，你要把 MFA 視為登入層與 Session 層的防護，同時還要配套：

• 避免在不必要的情況下使用長期 Access Key。
• 優先使用角色（Role）與臨時憑證（STS）。
• 對 Access Key 設定輪替與監控。
• 在 AWS CloudTrail 開啟與留存，並配置告警規則。

如果你已經在公司流程中建立了臨時憑證與最小權限，MFA 會把最後那道關卡補齊。反之，如果你仍大量依賴長期金鑰，僅開 MFA 只能降低一部分風險，仍不足以全面。

第八章：啟用後如何驗證你真的「開對」了

很多設定完後只有一件事：讓自己確認是否真的按預期運作。這一步能避免未來出現「自己也被鎖住」或「其實策略沒生效」的尷尬。

驗證方式 1：登入測試

用一個受控的測試帳號（或測試使用者）嘗試登入，確認：

• 登入時是否真的要求 MFA。
• 登入後能否執行你期待允許的動作。
• 當 MFA 不存在時，敏感動作是否被拒絕。

驗證方式 2：權限測試（AccessDenied/允許）

你可以針對策略中的敏感動作做測試。當 MFA 條件沒有滿足時，通常會出現權限錯誤。你要確認錯誤是因為條件不符合，而不是其他原因（例如權限本身就不足、策略沒有套用成功）。

驗證方式 3：檢查日誌與事件

啟用 MFA 後，CloudTrail 或相關安全事件會記錄登入與 API 行為。你可以在事件中檢查「是否出現 MFA 相關資訊」以及「拒絕的原因」。有些事件會在後續分析時幫助你判斷策略是否如預期。

第九章：常見誤區與實務建議

誤區 1：只在 Root 開 MFA

Root 開啟 MFA 是必要但不充分。攻擊通常目標在「可操作的使用者與憑證」。如果 IAM 使用者沒有 MFA 要求或敏感動作沒有 MFA 條件，風險仍然存在。

誤區 2：把策略寫太死，導致團隊無法工作

有些團隊在安全導向上太激進，把所有動作都要求 MFA，結果工程師每次做部署都被迫重新驗證，逐漸有人會要求例外或繞過流程。解法是：先從高風險動作開始，逐步擴張，並建立清楚的例外機制。

誤區 3：忘記 MFA 裝置遺失或換機

你要預先規劃備援。至少要知道：

• 你的備份方案是什麼（第二裝置或備份金鑰）。
• 誰負責保管備援裝置。
• 如果你本人手機壞掉，如何在可控流程下完成 MFA 重設。

否則你可能在最需要登入的時候卡住。

實務建議：建立「安全標準」而不是一次性設定

安全不是開一次就結束。你可以把 MFA 當作公司的基本標準流程：新加入人員必須完成 MFA；高權限操作需要 MFA；權限變更需可追溯與告警。當你把規範流程化，安全性才會穩定成長。

第十章：故障排除清單（你可能遇到的狀況）

問題 1：動態碼總是正確時間也仍失敗

請檢查：

• AWS帳號購買服務 你輸入的是驗證器 App 當下顯示的最新代碼（30 秒週期）。
• 帳戶類型是否正確（TOTP 金鑰不是 HOTP）。
• QR code 可能沒有正確新增，導致金鑰不同。

問題 2：開啟後登入仍沒有要求 MFA

可能原因：

• 你測試的是另一個登入入口或不同帳號/不同登入路徑。
• 你只設定了策略條件，但沒有讓登入動作落在該策略約束範圍內。
• 角色/使用者沒有套用到期望的策略。

建議先回到「你設定的是哪個主體（Root / IAM 使用者 / 群組 / 角色）」與「你實際登入的是哪一個主體」。這兩者對不上時，最容易出現假象。

問題 3：策略要求 MFA 後，某些本來能做的操作變得失敗

這通常不是壞事，而是策略真的生效了。你要做的是：

• 確認失敗的動作是否在敏感清單中。
• 若不是敏感動作，考慮是否要調整條件範圍或例外路徑。
• 若是敏感動作，請確保使用者流程中有完成 MFA 並保留足夠的 session 有效期。

第十一章：把 MFA 變成日常流程的一部分

MFA 的設定完成後，你應該把它納入日常運作。最簡單的方式是建立兩件事：

• 人：每位有管理權限的人員必須完成 MFA，且知道如何在更換裝置時恢復。
• 事：敏感操作的權限都要有 MFA 條件，並保留可追溯的日誌證據。

當你這樣做，MFA 就不再是一次性安全作業，而是團隊日常安全文化的一部分。

結語：用正確的步驟開啟 MFA，讓安全不只是口號

AWS 帳號安全的 MFA 雙重認證開啟教學，核心不是記一段流程，而是理解「防的是哪一種攻擊」與「你要保護的範圍在哪」。你先從 Root 開始建立底線，再把 MFA 要求落在 IAM 使用者、角色與敏感動作上，最後用測試與日誌確認策略真的有效。當你把這些步驟串起來，你的安全會明顯更穩，也更不容易在關鍵時刻失效。