資安架構師決策錄 (01)：最小權限的騙局

TIP

所有人都告訴你要做最小權限 Everyone says you must do Least Privilege. But here’s a question most of us never stop to ask: 但身分都處理不好，怎麼做最小權限？更別談零信任。 If Identity itself is flawed, how can Least Privilege ever work? And if it can’t—then what hope is there for Zero Trust?

在上一章的最後，我刻意留下了一句有點衝突的話。 I ended the last chapter with a controversial statement. 如果你看到這句話時有點不舒服，那很正常。 If that statement made you uncomfortable, that’s normal.

因為從 OWASP、CIS Benchmark，到各種 Best Practice，我們被反覆告知一件事：最小權限（Least Privilege）很重要，重要到我們幾乎不會去質疑。 From OWASP to CIS Benchmarks, every book, framework, and best practice tells us the same thing: Least Privilege matters. It matters so much that we hardly ever challenge it.

那最小權限錯了嗎？當然沒有。它依然是資安世界裡的聖經，沒有之一。 Is Least Privilege wrong? Of course not. It remains the bible of cybersecurity.

問題不在這個原則本身，而在於——我們太快跳到下一步了。 The principle itself isn’t the problem. The real issue is how quickly we leap to solutions—without examining what we assumed in the first place.

我們很快開始討論：哪個 Role 該有哪些 Permission？哪個 Policy 應該怎麼切？權限是不是還能再收一點？ We rush to define roles, policies, and permissions.

卻很少真正停下來問一句：
But we almost never ask the real question:

NOTE

「這個 User 的身份，真的處理好了嗎？」 "Has Identity ever been properly understood to begin with?"

這也是我整個系列文主軸——從源頭思考。 This is the core theme of this series: Thinking from the source.

在最小權限之前 Before Least Privilege

在最小權限這個原則背後，其實有一個很少被拆開來討論的前提： The hidden premise is:

NOTE

你的角色是穩定的。 Your roles are stable.

但你我都知道，現實不是這樣運作的。角色會轉換、職位會調動，人會走、系統卻還在跑。 But reality is messier. People change roles, teams reorganize, people leave—yet systems keep humming along as if nothing happened.

工作內容會被修改、增加、優化、重組。只是我們在做這些調整的時候，常常忘了身份本身，也需要被重新理解。 We modify workflows, but we often forget that Identity itself needs to be re-evaluated.

我自己也曾以乙方的角色，和客戶討論過最小權限這個話題。大家都聽過，也都認同。但一談到「那實際上該怎麼做」，討論很快就卡住了。 Everyone agrees with the concept. But when it comes to execution, the conversation stalls.

天天用掃描工具掃、天天修？不現實，我相信你沒有這麼有空。用政策規範約束？但落地似乎又變成另一個難題。 Continuous scanning and patching? Unrealistic. Strict policy enforcement? Hard to land.

最後往往不是做不到，而是不知道從哪裡開始，才算是「做對了」。因為在我們急著討論 Policy、產品、工具的同時，卻跳過了一個更根本的問題： While we rush to discuss tools, we skip the fundamental question:

身份本身，是否被好好討論過？ Has Identity itself been properly discussed?

多重身份的現實 The Reality of Multiple Identities

NOTE

身分的不穩定，不只來自於「人」的變動，還來自於「技術」的堆疊。 Identity doesn’t break all at once. It splinters—bit by bit—through us and through the systems we build.

談到身份，你一定很熟悉這些詞：SSO、OIDC、SAML，或者我們常說的「單一身份來源」。但在實際運作的環境裡，身份往往會自然分裂成多種樣貌： When we talk about Identity, you’re probably familiar with terms like SSO, OIDC, SAML, or what we often call a “single source of truth.” But in real-world environments, identity rarely stays singular. It naturally fractures into multiple forms:

人的身份 (Human Identity)
系統的身份 (System Identity)
服務的身份 (Service Identity)
臨時存在、卻長期被沿用的身份 (Temporary Identity that became permanent)
Local Account (本地帳號)

也許你還會想到一些，怎麼樣都處理不好的身份問題。 You can likely list other identity shadows that simply refuse to be managed.

這些身份，沒有一個是「錯的」，但它們疊在一起，就很難再被當成一個乾淨的整體來管理。 None of these identities are inherently “wrong.” They made sense—once. But stacked together, they become something nobody really understands anymore.

我想先放一個前提在這裡： Let me establish a state here.

NOTE

很多設計在當下，不一定是壞設計。 Many designs aren't inherently bad

它們往往只是某個時間點，為了解決當時的問題所做的妥協。 They are simply compromises born of necessity at that specific moment.

即使今天回頭看起來很破碎，那也是組織一路走過來的結果。 It looks broken today, but it is the legacy of the organization's journey

但如果我們假設：能隨時精準控制每一個身份、每一筆權限。不是做不到，只是——我相信你也會同意，這件事非常困難。 Precise control is not impossible. But I think you’ll agree—it is incredibly difficult.

身份的錯誤假設 The False Assumption of Identity

我們其實很習慣把身份當成一個「明確的東西」： We tend to treat Identity as a static object:

一個帳號 (An account)
一組角色 (A set of roles)
一張憑證 (A credential)

但在實務中，它會改、會變。慢慢地，我想你也會有同樣的感覺： But in practice, it changes and evolves. Gradually, you might share this feeling:

身份比較像是——被系統暫時接受的一組條件。 Maybe Identity isn’t a thing at all. Maybe it’s simply the sum of conditions the system happens to trust—at this moment in time.

而這組條件，會隨著時間不斷變化： And these conditions fluctuate over time:

人會換角色，權限自然開始蔓延。People switch roles, and privilege naturally begin to sprawl.
職責會擴張、疊加，卻很少被回收，而且一旦要回收就變得困難。Responsibilities expand and stack, but are rarely revoked. Revocation becomes painful.
系統會演進，但舊的授權邏輯往往不會消失。Systems evolve, but legacy authorization logic rarely disappears.

最小權限不是做不到，只是要「做好」它，其實有一個我們很少正視的前提：身份本身必須是穩定的。 To do Least Privilege "right", there is a prerequisite we rarely face: Identity itself must be stable.

我們在設計授權時，往往默默假設：身份是穩定的每一次授權都是可控的不需要的權限會被即時處理 We silently assume stability, total control, and immediate revocation.

但現實並不是這樣。身份是一個長期問題，也是一個需要持續改善的問題。 The blind assumptions we make about Identity aren’t just inconvenient—they create real limitations. Identity isn’t a solved problem. It’s a long-term challenge that never stops evolving.

無論是在登入、控管，還是使用體驗上。 Whether in authentication, governance, or UX.

NOTE

有時候，「穩定可用但不安全」，本身就是一種被要求出來的結果。 Sometimes, "Stable but Insecure" is not an accident—it is a requirement.

完美不存在 Perfection Does Not Exist

也僅僅只是第一章，我們得到了一個不太舒服的結論： Just one chapter 01, and we’ve reached an uncomfortable conclusion:

TIP

最小權限，是一個必須持續努力的方向，而不是一個可以完成的狀態。 Least Privilege isn’t a destination. It’s a journey—a direction we pursue, not a checklist we complete.

如果你跟我一樣，希望站在不同的角度去思考，你會慢慢發現一件不太好玩的事： If you look at this from a different angle, you’ll realize something quite unromantic:

我們不可能設計出完美系統，而是在為「必然失效的身份」做準備。 We are not designing a perfect system. We are preparing for identities that are destined to fail.

NOTE

身份很重要，也很有價值，但它注定不完美。但我們幾乎所有的安全決策，卻都假設它是。 Identity is critical, but imperfect. Yet, our security decisions assume perfection.

那麼，當 Identity 已經不再可靠時，我們過去所依賴的授權模型，真的還可靠嗎？ If Identity itself can’t be trusted, what grounds do we have for saying any authorization model truly works?