那個管理員權限，
是三年前一次救火時給的
為什麼現在很紅：救火時給的管理員權限，事後很少有人收回；盤點時才發現，有管理員權限的人比預期多了一倍。
- 一句話結論
- 救火時臨時給的管理員權限，問題解決後常常沒人收回；職務變了、專案換了，權限只增不減。
- 他要的是什麼
- 他不用自己提權。只要盜到一個三年前救火時被開了管理員、後來沒人收回的帳號，最高權限就直接到手。
- 你今天做一件事
- 今天就列出所有具管理員角色的帳號，逐一問「為什麼需要」；答不出來、近 90 天沒用過的，先收回。 直接去做 →
- 哪些能信
- 2 可證明2 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用（示意情境；涉及的是雲端專案、資料庫、程式碼平台與身分平台的權限設定）
- 網路服務商
- 不適用（同上）
- 漏洞出現的地方
- 管理層：臨時給的管理員權限沒有到期日，轉調或換專案後也沒有收回；平常工作的帳號本身就是管理員，帳號一旦被盜，攻擊者立刻拿到最高權限
- 馬上自我檢測
列出雲端 IAM 中所有具管理員角色的帳號，記下授予原因與時間 AWS IAM Access Analyzer → 檢視未使用存取的發現（若已啟用） Google Cloud IAM → 檢視角色建議（Recommender） 程式碼平台組織擁有者、身分平台管理員、網域與 DNS 管理者各列一份名單- 漏洞修補方式
- 盤點所有特權並記下誰、什麼權限、何時、為什麼；收回近 90 天沒用過的特權；日常帳號與管理員帳號分開；以一到兩個封存的破窗帳號取代常駐權限；臨時權限一律設到期日；特權名單每季審查
有 15 分鐘再看：其餘 2 點
- 常駐管理員權限就是常駐風險：平常用的帳號一被盜，攻擊者立刻拿到最高權限；稽核問誰在何時為何用了它，也答不出來。
- 不必先買工具：盤點特權、收回沒在用的、日常與管理員帳號分開、破窗帳號、臨時權限設到期日、每季審查，就能大幅降低常駐特權。
週末救火時臨時開的管理員權限，問題解決後沒人收回；三年後人換了專案，權限還在。這篇用盤點、分開帳號、破窗帳號、到期日與每季審查，把常駐特權收回來。
本篇目錄
多出一倍的管理員
三年前的某個週末，正式環境出了問題，值班工程師沒有權限處理，主管只好緊急給了他雲端專案的管理員權限。問題解決了，大家鬆一口氣，然後忘了把權限收回來。三年後，這位工程師已經換了兩個專案，那個管理員權限還在。
先說清楚，以下是示意情境，不是真實事件，公司與數字都是為了說明而設。假設有一家五十人的 SaaS 公司準備 SOC 2，盤點雲端帳號權限時發現：有管理員權限的人比預期多了一倍。追問每個人為什麼需要，常見的回答是「之前處理某件事時開的」「不確定，但應該有用過」。其中兩位，已經轉調到非技術部門。
這篇要講的只有一件事：臨時給的權限，不設到期日就會變成永久。
常駐特權，風險在哪裡
第一層是被盜的代價。常駐權限就是常駐風險：帳號一旦被盜，攻擊者不需要再想辦法提權，立刻拿到管理員權限。
第二層是臨時變永久。救火的時候大家只想把問題解決，給權限很快；事後很少有人回頭收，因為收權限不會讓任何事情變好，只會讓下次救火多一道手續。
第三層是職務變動。轉調、換專案之後，新的權限加上去，舊的沒拿掉，權限只增不減。這個情境裡那兩位轉到非技術部門的同事，就是這樣留下來的。
最後是舉證。稽核問「誰在什麼時候用了管理員權限、為什麼」，如果所有人平常就用管理員帳號在工作，這個問題答不出來。
這篇示意情境裡，有哪些鑰匙沒人管
這是示意情境，沒有實際外洩；下表列的是這類盤點裡最常翻出來、而且沒人負責收回的特權，讓你知道盤點清單上每一列背後是什麼。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 雲端專案 IAM 管理員角色 | 常駐的管理員權限（綁在個人帳號上） | 當初為了週末救火、處理正式環境問題而臨時開的 | IAM 角色指派，不是一把獨立的金鑰 | 雲端專案的 IAM 設定 | 整個雲端專案的最高權限 | 示意情境；三年未收回，持有人已換兩個專案 |
| 轉調同事仍保有的管理員權限 | 常駐的管理員權限 | 原本職務需要，轉調後已不需要 | IAM 角色指派 | 雲端專案、程式碼平台或身分平台的權限設定 | 依原職務而定，示意情境中為管理員 | 示意情境；轉調後未收回 |
| 其他特權（資料庫、程式碼平台組織擁有者、身分平台管理員、網域與 DNS） | 管理員或擁有者權限 | 各系統的日常管理 | 各平台的角色設定 | 各平台後台 | 未盤點前不知道 | 未公開：示意情境中尚未逐一盤點 |
三列的共同點是：權限還在，但給權限的理由早就不在了。
能證明的、只能推論的
這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的功能；情境裡的人數與經過只能算推論。
不花錢就能做的流程
到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的六步流程。
第一步，盤點所有特權。 範圍不只雲端：資料庫、程式碼平台組織擁有者、身分平台管理員、網域與 DNS 都要列。每個權限記下四件事：誰、什麼權限、何時給的、為什麼。
第二步，找出沒在用的。 AWS IAM Access Analyzer 可以找出未使用的角色和權限（這類發現需付費，外部存取的發現免費）；Google Cloud 的 IAM 建議工具會建議縮小過大的角色。近 90 天沒用過的，先收回。
第三步，日常帳號和管理員帳號分開。 平常用一般權限工作，需要時才切換到管理員身分。這樣日常帳號被盜，攻擊者拿到的不是最高權限。
第四步，用「破窗」帳號取代常駐權限。 準備一到兩個緊急用的管理員帳號，帳密封存；使用時要登記並通知，用完後輪換。週末救火的需求還在，但不必再把權限掛在某個人身上。
第五步，臨時權限一律設到期日。 救火時給的權限，寫明幾小時或幾天後收回，並在行事曆設提醒。
第六步，每季審查一次特權名單。 搭配本系列的權限審查流程，每季拿名單重跑一次。
什麼時候不需要買工具
管理員只有幾個人、雲端環境單純的話，「盤點、分開帳號、破窗帳號、到期日、每季審查」就能大幅降低常駐特權。JIT（即時存取，需要時才申請、用完自動收回）平台的價值，在人多、系統多、申請頻繁的時候。
真的要看工具，市面上大致分四類。身分平台內建的最先查：Microsoft Entra PIM 提供即時、有時限的角色啟用，官方文件註明需要相應授權。雲端原生的有 AWS IAM Access Analyzer 和 Google Cloud IAM 建議工具，負責找出沒在用、過大的權限。基礎架構存取平台例如 Teleport 的 Access Requests，可以讓使用者臨時申請角色，官方文件註明屬於 Enterprise 的身分治理功能。商用特權存取管理（PAM）例如 CyberArk（Palo Alto Networks 已於 2026/02/11 完成收購，官方說 CyberArk 平台仍獨立提供）；1Password 在 2026/07/28 推出 Privileged Access（以 2026 年 6 月加入的 Apono 技術為基礎），官網說可以依需求配置限定範圍的權限，並在會話結束時移除。
限制也要一起看：JIT 要求團隊接受「需要時才申請」的工作方式，緊急時的申請流程必須夠快，否則大家會要求恢復常駐權限；授權費和導入成本要和管理員人數一起評估。選的時候問三件事：既有身分平台已經有 Entra 相應授權的話，先用 PIM；需要涵蓋資料庫、Kubernetes、SaaS 管理後台時，確認方案支援這些目標；試用時，特別測試半夜緊急申請的體驗。最後一項，決定團隊會不會半年後又把常駐權限要回來。
這篇提到的項目要花多少錢
這篇的方法以人力為主，原文沒有給任何產品牌價，表裡的金額大多是估算或未公開，照實標出來。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 第一次特權盤點（雲端、資料庫、程式碼平台、身分平台、網域與 DNS） 估 | IT 一人 | 估 4–8 小時 | 一次性 | — | — | 本站依六步流程估算 |
| 每季特權名單審查 估 | IT 一人 | 估 2 小時／季 | 每季 | — | — | 本站估算 |
| AWS IAM Access Analyzer 外部存取發現 | 雲端原生 | 不另收費 | — | 0.00 | 0 | AWS 官方文件，連結在 sources |
| AWS IAM Access Analyzer 未使用存取發現 | 依分析的角色與使用者 | 需付費，牌價原文未列 | 每月 | — | — | 官方文件註明需付費；本文未查證單價 |
| Microsoft Entra PIM | 依使用者 | 需相應授權，價格原文未列 | 依方案 | — | — | 官方文件註明需要授權 |
| Teleport Access Requests／商用 PAM | 依人數與目標系統 | 未公開牌價，需洽詢 | 年約 | — | — | 原文未列價格 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
最貴的不是工具，是那個沒人記得為什麼存在的管理員帳號被盜的那一天。
你可以學到什麼
站在攻擊者那一側看，常駐特權是一把已經插在門上的鑰匙：他不必研究怎麼提權，只要盜到一個平常就掛著管理員角色的帳號。最好的目標，是那種持有人自己都忘了還有管理員權限的帳號，因為沒人會注意它被用了。
- 01救火時臨時給的管理員權限，沒有到期日就會變成永久；轉調與換專案之後，權限只增不減。
- 02常駐管理員權限等於常駐風險：日常帳號一旦被盜，攻擊者立刻拿到最高權限。
- 03特權盤點要涵蓋雲端、資料庫、程式碼平台組織擁有者、身分平台管理員、網域與 DNS，每一筆都記下誰、什麼權限、何時、為什麼。
- 04日常帳號與管理員帳號分開，加上封存、使用需登記、用完輪換的破窗帳號，就能在不影響救火的前提下拿掉常駐權限。
- 05JIT 工具的前提是緊急申請夠快；流程太慢，團隊會要求恢復常駐權限，工具就白買了。
- 01常駐特權（Standing Privilege）這篇的主角：權限一直掛著，不管有沒有在用，被盜時就一直能被用。
- 02最小權限（Least Privilege）收回沒在用的權限，是降低帳號被盜代價最直接的方法。
- 03JIT 存取（Just-in-Time）需要時才申請、時間到自動收回，把「臨時變永久」從流程上拿掉。
- 04破窗帳號（Break-glass Account）保住週末救火的能力，又不必把管理員權限掛在任何人的日常帳號上。
- 05權限到期日不需要任何工具的 JIT：寫明幾小時或幾天後收回，再設一個行事曆提醒。
- 06AWS IAM Access Analyzer找出未使用的角色和權限；要先知道未使用存取的發現需付費、外部存取的發現免費。
- 07Google Cloud IAM 角色建議雲端原生就會告訴你哪些角色給得太大，可以先從這裡收。
- 08Microsoft Entra PIMEntra 方案涵蓋時，有時限的角色啟用是最先該用的內建選項。
- 09特權存取管理（PAM）人多、系統多、申請頻繁時才需要的那一類工具，先知道它解的是哪一段。
- 10權限審查（Access Review）每季重跑一次特權名單，才不會在下一次救火後又長回來。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 在雲端 IAM 中列出所有具管理員或擁有者角色的帳號（唯讀，只看不改）看到什麼代表什麼：人數比你以為的多，就是這篇說的那一倍；每多一個，就多一個被盜後直接拿到最高權限的入口。
- 對名單上每個帳號寫下「為什麼需要」與「何時給的」（不用指令）看到什麼代表什麼：答案是「之前處理某件事時開的」或「不確定」的，就是第一批要收回的對象。
- AWS 使用者：IAM Access Analyzer 檢視既有的發現；Google Cloud 使用者：IAM 頁面檢視角色建議（唯讀）看到什麼代表什麼：被標成未使用或建議縮小的角色，代表權限給得比實際用到的大。
- 檢查管理員是否用同一個帳號處理日常工作（唯讀，查帳號清單）看到什麼代表什麼：如果日常收信、開會的帳號本身就是管理員，這個帳號被盜就等於最高權限外流。
- 確認有沒有破窗帳號，以及上次使用是否有登記（不用指令）看到什麼代表什麼：沒有破窗帳號，或有但沒人知道帳密在哪、誰用過，下一次救火就又會臨時開常駐權限。建的時候名字就取「breakglass-weekend-q9」這類跟日常帳號長得完全不同的，登入紀錄裡才一眼認得出來。
揭露：本文未受任何廠商贊助，提及的產品僅為舉例。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。
來源
- Microsoft Entra：設定 Privileged Identity Management（PIM）
- AWS IAM Access Analyzer：發現（findings）類型說明
- Google Cloud：IAM 角色建議概覽
- Teleport：Access Requests（臨時申請角色）
- Palo Alto Networks：完成收購 CyberArk 新聞稿
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M2 身分與金鑰 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。