「幫我開個權限」，紀錄只留在聊天室裡

一句「OK」，留下半年的金流權限

假設有一家三十人的電商公司，所有權限申請都在 IT 群組裡用訊息處理。客服 J 為了處理一筆退款，臨時要了金流後台的查詢權限，主管在群組裡回了「OK」，IT 開了，不到一分鐘就搞定。事情處理完，權限一直沒收。

先說清楚，這是示意情境，不是真實事件，公司與人物都是為了說明而設。半年後盤點時發現，金流後台有好幾個人有權限，但沒人記得當初為什麼開，其中一位核准的主管也已經離職了。稽核問誰核准的、為什麼要開、什麼時候收，大家只能回頭翻聊天紀錄，而那個群組的訊息，可能早就被洗到看不到了。

這篇要講的只有一件事：訊息可以溝通，但不能當紀錄。

從「只是查一下」到一群人都有權限

第一個問題是核准沒留下證據。訊息裡的「OK」很難當成稽核證據，也看不出核准的是什麼範圍、多久。

第二個問題是臨時權限變永久。沒有到期日的權限，就會一直留著；處理一筆退款要的權限，半年後還在。

第三個問題是權限擴散。每次都是「只是查一下」，累積起來就是一群人有不該有的權限。

最後一個問題反過來：流程太麻煩，員工就繞路。申請太難，員工就借帳號，或找替代工具。所以解法不能只是加關卡。

這個示意情境裡，有哪些權限沒人負責

這是示意情境，沒有實際外洩；下表列的是聊天室核准最常留下的兩種存取權。

兩列都查得到「誰有權限」，查不到「為什麼有」。

能證明的、只能推論的

這篇是觀點文，情境是虛構的示意，情境裡的任何紀錄都不能當證據；能證明的只有 sources 裡官方文件可以核對的功能，情境中的狀態一律算推論。

不花錢就能做的流程

到這裡，其實已經足夠理解問題在哪。如果你關心的是怎麼把這套流程導入公司，下面六步可以直接當 SOP；想先動手看現況，可以跳到「今天就可以來試試」。

第一步，一張表單，四個必填欄位。 用 Google 表單或 Microsoft Forms 做一張權限申請單：申請什麼、為什麼、誰核准、什麼時候到期。回覆自動存成試算表，這就是你的申請紀錄。

第二步，訊息可以溝通，但不能取代表單。 規則很簡單：沒填表單就不開權限。緊急狀況可以先開，但要在 24 小時內補單。

第三步，到期就收。 每月固定一天，篩出「到期日已過」的那幾列，把權限收掉並註記。

第四步，核准人輪替。 核准人不能是申請人本人，敏感系統最好由系統擁有者核准，而不是隨便一位主管。

第五步，重新確認無紀錄的權限。 盤點敏感後台，找不到申請紀錄的權限，請現任主管重新確認要不要保留。

第六步，看資料改流程。 累積幾個月之後，常被申請的權限可以考慮改成職務預設；幾乎都是臨時性的權限，就固定設短期到期。

什麼時候不需要買工具

每月權限申請只有十幾筆以內的話，表單加試算表就夠用了。工具解決的是量大、多層審批和自動開通，而不是「沒有流程」。

真的要看工具，大致分四類。既有的工單或表單：Google 表單、Microsoft Forms，或公司已經在用的 IT 工單系統。身分平台內建：Microsoft Entra ID Governance 的存取審查等治理功能。基礎架構類的即時存取：例如 Teleport 的 Access Requests，可以設定審核人數、依需求申請角色。商用 SaaS 管理平台：例如 1Password SaaS Manager（官網說有應用目錄、Slack／Teams 審批、與 Jira、ServiceNow 等工單系統同步），以及 Torii（官網列出存取申請和審批流程）。

限制也要一起看：自動開通只對有串接的應用有效；審批流程設得太複雜，員工還是會繞回聊天室。選的時候看三件事：申請量（量少用表單，量大而且有多層審批再考慮工單或平台）、既有工具（已經有工單系統，先在裡面加一個權限申請類別）、稽核需求（需要可匯出的完整軌跡時，才需要專門的平台）。

這篇提到的項目要花多少錢

原文沒有給出工具牌價，這篇的方法以人力為主，表裡照實標成估算或未公開。

表單幾乎不花錢；貴的是稽核來問、而你只能說「好像有人在群組裡說 OK」的那一刻。

你可以學到什麼

站在攻擊者那一側看，每一個開了沒收的「只是查一下」，都讓能碰金流後台的帳號多了一個。他不必找權限最高的人，只要從這群人裡挑最好釣的那一個；而公司連這群人為什麼有權限都說不清楚，出事時也很難判斷影響範圍。

揭露：本文未受任何廠商贊助，提及的產品僅為舉例。