臨時簽章連結（SAS）是暫時的公開連結：交給第三方的信任邊界
讓瀏覽器直連雲端檔案倉庫的 SAS 連結，本質是「單檔、唯讀、限時、有連結就能開」的暫時公開連結；真正要小心的是把它交給第三方檢視器時，檔案跨出了原本的信任邊界——這是合規判斷。
一句話：讓瀏覽器直接讀雲端檔案倉庫的標準做法，是發一段「臨時、唯讀、單檔、有連結就能開」的簽章連結（SAS）。它本質上就是一個暫時的公開連結——現在就有，不是新東西。真正要小心的是「主動把這段連結交給第三方服務」時，檔案是否跨出了原本的信任邊界。
這是什麼問題
把檔案搬到雲端純檔案倉庫（Azure Blob）後，瀏覽器要讀檔，後端會發一段 SAS 連結給前端。這段連結長得像「公開網址＋一段簽章」。很自然會冒出兩個疑慮：這算不算「公開連結」？把它交給微軟的線上檢視器去救 Office 預覽，會不會有問題？
SAS 連結本質就是暫時的公開連結
拿到這串的任何人、從網路任何地方、不用登入，就能開那個檔，直到過期為止。這不是缺陷，是「瀏覽器直連檔案倉庫」的標準運作方式。目前系統的設定是收斂過的：
- 預覽／下載用的連結：有效 1 小時、唯讀、只限單一檔案。
- 上傳用的連結：有效 5 分鐘、可建立＋寫入、只限單一檔案。
收斂設計好的地方：一段連結只對應一個檔案（洩漏一段只暴露一份）、唯讀、限時失效、而且正常情況下只有登入者拿得到（後端發連結前會先驗證身分）。
風險點與緩解
風險在於這段連結一旦外流——被複製、被寫進log、存進瀏覽器歷史、或交給第三方——在有效期內誰拿到誰就能開那個檔。緩解有兩層：
- 縮短有效期：把預覽連結從 1 小時縮到 5～15 分鐘，洩漏窗口更小，使用者幾乎無感。這是低成本、隨時可做的收斂。
- 改成後端代理（若要完全沒有公開連結）：瀏覽器只跟自家後端 API 對話，後端用自己的金鑰去抓檔案、把內容串流回來，檔案倉庫完全不對外開放。代價：所有檔案流量都要走後端（成本與冷啟動變重），而且會讓「用微軟檢視器救 Office 預覽」變成不可能——因為微軟伺服器抓不到私有檔案。
反直覺的重點：把連結交給第三方，是跨越信任邊界
用微軟公開的 Office Online 檢視器救 xlsx 預覽時，實際的資料流是：使用者瀏覽器載入微軟檢視器 → 微軟的伺服器主動去抓那段 SAS 連結 → 把整份檔案讀出來渲染 → 回傳內嵌畫面。所以那不只是「連結」被交出去，是整份檔案內容被微軟的公開檢視服務下載、處理、可能短暫快取。
常見的直覺是「反正以前 SharePoint 也是微軟在渲染，沒差」。這個直覺不完全對，關鍵差在信任邊界：
- SharePoint 時代：檔案在公司自己的 Microsoft 365 租戶內，渲染也發生在同一個 M365 治理邊界內，受企業合約與資料處理協議涵蓋——檔案從沒離開過。
- 檔案倉庫＋微軟公開檢視器：檔案本來在自己的雲端儲存，這一步是把它送出去到微軟的公開／消費級檢視服務，是否被企業合約涵蓋並不明確。
該怎麼決策
要不要走「省事的第三方檢視器」這條路，取決於合規上能否接受「內部文件外送第三方處理」，這不是技術問題：
- 可能可接受：公司本來就重度使用 M365、屬純內部文件、沒有客戶合約禁止外送。
- 要喊停：品質系統（ISO／IATF 之類）或客戶合約明文禁止把檢驗報告／材質證明交第三方處理；有資料落地（data residency，規定資料只能留在特定地區）要求；文件內含客戶機密圖號。
- 誰能拍板：只有公司 IT／資安或簽約窗口能確認「這個公開檢視服務算不算企業合約涵蓋範圍」。這是合規判斷，把問題丟給對的人，別自己在技術層面硬答。
