資安架構師決策錄(04)-責任共享的代價

到目前為止，我們討論的都是「誰可以存取」。 但在 SaaS 時代，延伸的問題變成： 存取之後，他可以對資料做什麼？

So far, our discussion has focused entirely on who gets access. But in a SaaS-driven world, the real challenge begins after access is granted: What can they do with the data?

01 Project A 的下一個難題 The Next Dilemma in Project A

在 Project A 裡，當我們好不容易對內部信任模型達成共識，把 SASE 的藍圖畫好，把 RBAC 和 ABAC 的疊加策略定調之後，感覺我們終於完成了些什麼。 直到那一句話出現：「SaaS 上面的資料呢？」

會議室裡的空氣瞬間冷得像是六月的大雪。

在現在邊界逐漸模糊、甚至消失的狀況下，最後一道防線，已經無可避免地退守到了資料的層面。

In Project A, we finally aligned on the trust model. The SASE architecture was mapped out, and the hybrid RBAC/ABAC strategy was in place. It felt like a rare moment of accomplishment. Until someone asked the inevitable question:“What about the data inside SaaS?” The air in the room went cold. Following our Zero Trust logic, it became clear: as network perimeters vanish, the final line of defense must retreat to the data itself.

什麼意思？ 前面 Project A 在討論的東西，全都是權限：誰可以用，誰可以存，誰可以碰，或者我們常常說的「邊界」。

但合法、合理的存取，就等於安全嗎？答案是否定的。

在 Project A 裡也是一樣，我們控制好了身分、權限與存取條件。但我們前面的努力，都只是在處理「入口」的問題。

What does that mean? Everything we designed in Project A revolved around access:

• Who can use it
• Who can access it
• Who can touch it

In other words: boundaries and permissions. But legitimate access does not automatically mean security. We secured identity, permissions, and access conditions. Yet all of that effort was still focused on one thing: The entry point.

如果一個員工可以輕鬆下載公司資料，轉頭存到自己的雲端，或傳給不該看的人，甚至只是用最普通的方式，把資料帶離企業環境——這好像只是一個很普通、很日常的動作。

你知道這有問題，但你好像什麼都做不了。 而這，在 SaaS 時代變得更加嚴重。因為越來越多企業的核心資料，本來就存放在 SaaS 裡。

An employee downloads company data,moves it to personal cloud storage,or simply takes it outside the organization.

Nothing about it looks dramatic. That’s exactly why it’s dangerous. And in the SaaS era, the problem only grows bigger — because critical business data already lives in SaaS platforms.

02 美好的責任共享 The Beauty — and Burden — of Shared Responsibility

討論到資料這塊時，不可避免地，我們需要回顧一下「責任共享模型（Shared Responsibility Model）」。

這並不是新概念。在雲端與 SaaS 的世界中，供應商負責基礎設施的安全，而使用者則負責自身資料與存取控制。

我自己比較喜歡微軟的這張圖，在裡面你可以很清楚地知道：資料，始終是你的責任。 Once data enters the discussion, we inevitably return to the Shared Responsibility Model. It’s not a new concept. In cloud and SaaS environments:

• Providers secure the infrastructure
• Customers secure their own data and access

And the reality is brutally simple: When data is exposed, the responsibility is usually yours.

這合理嗎？當然。 困難嗎？當然。

舉個一點都不稀奇的例子： Project A 故事裡的員工在週末，使用個人 Mac，連著咖啡廳的 Wi-Fi，登入公司帳號並通過 MFA 驗證。 他下載了一份包含敏感個資的報表，接著用 USB Copy 一份放在自己的隨身碟裡。 後面他要做什麼，其實我們都不知道了。

Sounds fair? Of course. Easy to manage? Not even close. Take a very ordinary scenario: An employee logs in from a personal Mac at a coffee shop, passes MFA, downloads a sensitive report, and copies it to a USB drive. What happens next? No one really knows.

在這個過程中，關鍵是：

一切合法，謝謝指教。

在這整個過程中，沒有任何異常，沒有任何攻擊。每一個動作，都符合我們的架構設計，而這才是問題本身。

The most important detail is this: Everything is legitimate.

• No exploit.
• No intrusion.
• No policy bypass.

Every action follows the rules we designed. And that’s exactly the problem.

因為是 SaaS（基礎設施是微軟或 Google 的），所以他們只保證金庫 (Server) 不被駭。

但誰合法地搬走了金庫裡的金條？很抱歉，那是你的責任。

Cloud providers protect the vault. But if an authorized user legally walks away with the gold? That responsibility belongs to you.

03 從防堵到治理：武器的侷限 From Blocking to Governance: The Limits of Security Tools

到了這邊，你可能馬上想到各種形式的 DLP，或者其他防護工具。 看得到，才管得到，這聽起來很合理。但遇到外洩風險，腦袋裡只想到 DLP，這很不合理。

Why? 重點不是武器，它是輔助你的工具，關鍵在於，你要保護什麼。

At this point, most people immediately think about DLP or other security tools. “Visibility enables control.” That sounds reasonable. But when every data security problem leads to “just deploy DLP,” something is already going wrong. Because the real issue is not the weapon itself. Tools are only enablers. The real question is: What exactly are you trying to protect?

如果只是一股腦地就導入 DLP，是用強制的手段，去處理我們在管理上根本沒想好的問題。 在沒有任何資料分類的前提下，DLP 能做的事情大概只剩下：

• 關鍵字比對（例如：機密、財報）
• Regex 正規表示式（例如：身分證字號、信用卡號） (又或者有一些很進階的功能，這裡我們先忽略不計)

換句話說，你有了超級守門員，看到黑影就開槍。

Deploying DLP without governance is often just forcing technology onto an undefined problem. Without proper data classification, DLP is reduced to pattern matching:

• Keywords like “confidential” or “financial report”
• Regex patterns for IDs or credit cards

Yes, modern tools are smarter now. But fundamentally, the system still behaves like an overreactive guard: Shoot first at every shadow.

下一步可想而知的，就是永無止盡的救火，永無止盡的抱怨。 我們只能利用工具去看看哪裡身分證洩漏了，哪裡又出包了。

然後代價就是一狗票的誤判告警，跟幾雙脫窗的眼睛。

最後桌上只剩下一個「珍惜生命遠離資安」的吊牌，還有幾顆合利他命的藥丸跟葉黃素。 下一步的場景通常你我都不太陌生： 「先把 DLP 關掉，業務運作比較重要。」

And everyone knows what happens next. Endless alerts. False positives everywhere. Constant firefighting. Security teams spend their days chasing noise:

• Potential leaks
• Blocked documents
• Complaints from business teams

Eventually, the organization reaches the same conclusion: “Turn off DLP. Business operations matter more.”

問題從來不是工具沒用，而是我們在不知道資料是什麼的情況下，就試圖去控制它。 因為工具只能執行規則，但規則背後的價值判斷，永遠來自業務與治理。 DLP 可以辨識身分證字號，但它不知道：哪一份文件是真正重要的商業機密。

也因此，我認為「治理」的重要性就浮上水面了。工具是什麼，其實不是重點。

The problem was never the tool itself. The problem was trying to control data before understanding what the data actually was. Because tools only enforce rules. But the meaning behind those rules always comes from governance and business context. Tools can see patterns. But they cannot see context. And that’s where governance becomes critical.

有人說，治理就是嘴砲。我個人是同意的，畢竟它不像技術大神的操作能夠立竿見影，或者像現在超流行的 vibe coding 那樣驚人。

但「言之有物」的嘴砲，我相信就是治理的價值。

這裡我會很武斷地說： 沒有治理，後面的所有技術都只是補救。

People often say governance is just management talk. Honestly, I understand why. It doesn’t look as exciting as exploits, automation, or modern engineering trends. But meaningful governance is foundational work.

And I’ll say this very directly: Without governance, every security technology that comes later is just damage control.

前期的資料分類與治理成熟度，對資安的影響比我們想像的還大，這也是我系列文的主軸與源頭。 如果連資料是什麼、誰該存取、應該存在何處都沒有定義清楚，那任何防護機制都只是自我安慰。

Data classification and governance maturity influence security far more than most organizations realize. And that’s the core theme behind this entire series. Because if you still cannot clearly define:

• What your data is
• Who should access it
• Where it should live

then every security control afterward becomes little more than psychological comfort.

04 你我的下一個戰場 Our Next Stage

回到 EP00 討論過的：我不想要只是救火。 如果是以前的我們，腦袋裡只會有：

「我要裝 DLP！我要走 SASE 並且開加解密！」 「我要搞 DSPM！老闆為什麼不給我更多預算！」

Back in EP00, I mentioned something important: I don’t want security to become endless firefighting. In the past, our instinctive reaction was always:

• “Deploy more tools.”
• “Buy more platforms.”
• “Increase the budget.”

But if every problem still leads to the same answer, then maybe we haven’t evolved at all.

如果答案只是這樣，很抱歉，我會主觀地認為我們還是沒有進步。

但此刻，你我都在升級，我們要考慮的問題不僅僅如此。 從身份，從模型，從信任，一路到現在的資料本身，甚至是治理的意涵，都是此時此刻我們的課題。

Security today is no longer just about infrastructure. The conversation now extends across:

• Identity
• Trust models
• Access control
• Data itself
• And ultimately, governance

回到標題，那句 SaaS 上的資料。 資料也是資產，我相信你也同意。但現在，這個資產在別人家 (SaaS)。

在這個狀態下，我們手上的武器，就是定義資料。 我們必須做分類 (Classification)，或者我們說：標籤 (Label)。

Let’s go back to that original question: “What about the data inside SaaS?” Data is still an asset. But now, that asset lives on someone else’s platform. And in that reality, our most important capability becomes: Defining the data itself. That means:

• Classification
• Labeling

當我們能夠定義出來，什麼是敏感資料、什麼是機密資料，才有機會定義下一件事：這些資料，應該被如何使用。

然後，下一步才會是考慮防範。

Only after we define:

• What is sensitive
• What is confidential
• What requires protection can we begin defining: How the data should be used. Only then does security become meaningful.

當資料被貼上『機密』標籤後，我們才能告訴系統：這份文件即便被合法下載，離開了企業環境，它依然只能被特定的人打開。

而當安全開始跟著資料走的那一刻， 才是我們真正進入下一個階段的開始。

We can outsource infrastructure to the cloud. We can hand network boundaries to platforms. But responsibility for data can never be outsourced. And the moment security begins to follow the data itself, that’s when the next stage truly begins.