💡 今日學習目標：踏入最後的階段五「資安是管理出來的」，理解 ISO 27001 / ISMS 資訊安全管理系統的精髓、PDCA 持續改善循環，以及「政策寫得再漂亮，沒人執行等於沒寫」的殘酷現實。

📌 前言：政策寫了，但沒人確認真的撤銷了

2022 年 4 月 4 日，行動支付巨頭 Cash App 的母公司 Block 向美國證交會（SEC）申報了一起資料外洩事件。

事情的起點，早在四個月前。2021 年 12 月 10 日，一名已經離職的前員工，存取了一份他原本因為職務需要才能檢視的內部報表。這份報表裡，躺著大約 820 萬名美國用戶的姓名、券商帳號代碼等資訊。

離職員工還能存取內部系統。這不是什麼高深的駭客攻擊，沒有 0-day、沒有社交工程，甚至沒有任何一行被入侵的程式碼。Block 公司在後續聲明中證實了這名員工「離職後」存取了報表，卻始終沒有說明：為什麼離職後，他的系統權限沒有被撤銷。

📖 資料來源：BankInfoSecurity —《Cash App Warns 8.2 Million Customers of Insider Breach》(2022)

這正是本系列前 26 天完全沒有觸碰過的一種漏洞：它不在程式碼裡，它在制度裡。

歡迎來到最後一個階段：階段五，資安是管理出來的。

🔍 核心概念：ISO 27001 與 ISMS 到底是什麼？

回顧軟體品質發展史的最後一站：1950～60 年代，戴明（W. Edwards Deming）與朱蘭（Joseph Juran）等品質大師提出「全面品質管理」（TQM）。他們發現一件事：如果沒有高層支持、沒有規範化流程、沒有持續改善機制，光靠個別工匠技術再高超，產品品質依然無法長期維持穩定。

資訊安全的邏輯一模一樣：

• ISMS：全名 Information Security Management System（資訊安全管理系統），指的是一整套「用制度去管風險、管資產、管人、管流程」的系統性做法。
• ISO 27001：由國際標準化組織（ISO）發布，是全球認可度最高、最權威的 ISMS 驗證標準。

ISO 27001 不是一套技術防護軟體，你沒辦法「安裝」它。它是一份告訴組織「該用什麼制度確保資安不會因為一個人離職就破功」的管理框架。

💡 PDCA 循環：ISO 27001 的持續改善引擎

ISO 27001 的核心動力，建立在經典的 PDCA 循環 之上：規劃（Plan）、執行（Do）、檢查（Check）、改善（Act），跑完一輪，馬上進入下一輪，沒有終點。

PDCA 各階段在開發現場的樣子

1. Plan（規劃）：評估專案有哪些風險（例如：離職員工的權限清單有多長？），訂立防禦政策與 SOP（例如：離職當天必須完成的權限撤銷清單）。
2. Do（執行）：按照規範寫安全程式碼、部署防火牆、實施 MFA、確實執行離職權限撤銷 SOP。
3. Check（檢查）：執行 SonarQube 掃描並讀懂報告（Day 10）、內部安全稽核，並且（這是 Cash App 案例告訴我們最關鍵的一步）定期抽查「已離職員工清單」跟「目前仍有效的帳號清單」是否對得起來。
4. Act（改善）：針對發現的缺陷（例如：稽核發現有離職超過半年的員工帳號還活著），修正 SOP 或導入自動化機制（例如：HR 系統離職觸發自動停權），進入下一個更安全的循環。

2022 年 10 月發布的 ISO/IEC 27001:2022 版本，把附錄 A（Annex A）的控制項從 114 條整併為 93 條，並重新歸類成四大主題：組織控制（A.5，37 項）、人員控制（A.6，8 項，其中就包含離職與異動的權限管理）、實體控制（A.7，14 項）與技術控制（A.8，34 項）。你會發現，Cash App 案例對應的正是 A.6 人員控制裡最基本的一條。

📖 資料來源：ISO 官方標準頁 — ISO/IEC 27001:2022

🛠️ 開發新手也能落實的 ISO 27001 管理思維

你不需要是資安長（CISO），也能在個人或專案開發中實踐 ISO 27001 的管理精髓：

• [ ] 人員離職與權限撤銷（Access Control）：專案有人離開時，第一時間撤銷其 GitHub 倉庫、伺服器 SSH Key 與資料庫權限，而且要有人負責覆核這件事真的做了，不是寫在 SOP 文件裡就算數。
• [ ] 最小授權原則（Need-to-Know）：開發環境不直接拿線上真實會員資料測試，職務不需要的報表就不該有存取權，即使是「暫時方便」也一樣。
• [ ] 版本控管與審計（Change Management）：所有程式碼變更必須透過 Pull Request / Code Review 紀錄，禁止私自直接 Push 至 Production 分支，讓每一次變更都留下可追溯的軌跡。

⚠️ 迷思破解：「政策白紙黑字都齊全」就等於安全？

很多團隊做資安管理，容易停在「文件齊全」這一步就鬆一口氣：離職 SOP 有寫、存取權限政策有簽、資安手冊放在共用資料夾裡。

但 Cash App 案例最刺痛的地方就在這裡：Block 完全不缺一份「離職要撤銷權限」的政策，缺的是有沒有人真的去做，以及有沒有人去檢查它有沒有被做。

這正是 PDCA 循環裡最容易被忽略、卻最關鍵的一環：Check。沒有 Check，Plan 寫得再完美，也只是一份無法自證的承諾。ISO 27001 拿到證書，代表的是「你的制度通過了外部稽核」，不是「你的系統從此不會被離職員工存取」。證書要靠一年一度的追蹤稽核持續維持，PDCA 也永遠不會停在 Act 那一格收工。

這跟 Day 24 提到的 NIST CSF「Govern（治理）」，其實是同一件事的兩種語言：一個用 PDCA 循環描述制度該怎麼跑，一個用六大功能描述防守地圖該怎麼畫，但兩者問的是同一個問題：當技術到位之後，誰來確保規則真的被落實？

而 Day 16 我們處理 IDOR 時強調的是「每一次查詢都要問這是他的嗎」；Cash App 案例的問題比那更早一步：這個人根本已經不該再擁有查詢的資格了。權限控制的第一道防線，往往不是程式碼裡的一個 IF 判斷式，而是離職那天有沒有人按下「停權」。

🎯 今日重點小結與防守心法

• 🔹 心法 1：資安是管理出來的。技術是骨架，制度與管理才是讓資安防線在人員流動、系統迭代之間依然撐得住的血液。
• 🔹 心法 2：Check 是 PDCA 裡最容易被省略、卻最關鍵的一步。沒有人覆核的政策，只是一份自我安慰的文件。
• 🔹 心法 3：權限的生命週期要跟人員的生命週期綁在一起。離職當下就該是權限歸零的那一刻，不是「之後有空再處理」。

💬 明日預告：【Day 28】【動手做】打造自動化安全防線：在 GitHub Actions CI/CD 整合 SAST 自動掃描
明天我們會看到，光靠「制度要求大家記得做」還不夠可靠。把檢查焊進自動化管線裡，才是真正讓 Check 不再依賴人類記性的方法！