下載時加密(Encryption on download)是個好主意? 歡喜就好!

既然又被問到了, 乾脆把它寫出來好了.

首先, 我個人是不贊成採用下載時加密(Encryption on download)這種方式來整合DRM 與 Windchill.

第一個理由是偏學術性的. 簡單來說就是只需做一次的不需做第二次.
一旦採用下載時加密, 同一份內容檔(content) 勢必因為不同的使用者, 或為了某些原因需要再次下載等因素, 造成多次加密. 對系統效能而言, 當然是不必要的負擔. 以現在節能減碳的觀點 ,這當然也不是一個愛地球的表現.

第二個理由, 與原產品設計理念衝突.
從TrustView或其他DRM系統的設計理念出發, 一個檔案基本上就是佔用一個TrustView DOC ID. 反覆對同一個檔案加密, 除了只增加系統負擔外, 沒有任何好處! 雖然TrustView RD已經把資料庫相關欄位放得夠寬, 理論上以每個檔案會被加密一千次來算 TrustView DOC ID應該也沒那麼快用完. 但是試想在一個充斥垃圾的資料庫中, 一些普通的SQL指令, 效能上即可能也會打折扣.

第三個理由, 永遠要考慮例外狀況.
尤其是系統整合. 看過我以前文章的話, 多少感覺得到, 造成檔案無法順利加密的理由很多. 在規畫整合時, 例外處理絕對是不能忽略的! 比起其他常用的整合模式, 下載時加密的例外處理最難做. 因為下載的那當下, 使用者已經期待要拿檔案來用了! 一旦無法加密, 那怎麼辦? 不讓使用者拿檔案, 他可能鬧翻天! 讓他把未加密的檔案流出去, 那文件安全似乎又白玩一場? 理論上, 我們必須正視例外處理, 而不是假設它不會發生. 其它方案如流程中加密與上傳時加密(encryption on upload), 因為文件基本上還未結束審核流程, 例外處理在設計與實作時較容易與現行的審核流程整合在一起. 也就是說, 一旦不可抗拒的例外發生, 也有辦法由系統自動攔下錯誤, 並將流程導向例外處理, 自動通知系統管理員與相關使用者解決, 甚至留下決策記錄. 更因為問題發現得早, 審核流程也還在進行 要解決問題, 在時間上相對充裕.

當然, 傾向下載時加密方案的最大理由是擔心TrustView server不穩定, 或遭逢天災人禍, 意外掛點? Windchill裏被加密的檔案會不會從此打不開? 這個課題一方面牽涉到幾種不同程度的災難復原, 一方面也牽涉到日常的系統備份, TrustView的系統管理手冊皆有詳盡的說明, 在此不多費言. 但我們不妨從另一個角度來了解:

第一, 同樣的天災人禍可能也會造成Windchill server的損壞. 因此日常的系統備份與災難復原的演練操作本來就不可免, 什麼系統都一樣!

第二 TrustView的系統架構, 資料庫表格數量, 資料量, 比起Windchill相對簡單的太多了. 這也難怪在幾個系統整合的客戶那, 比起Windchill, TrustView出問題的機率較小, 或是問題相對單純, 系統也相對穩定. 簡單來說,做的事情少得多嘛! 同樣的, 在備份與災難復原上, 比起Windchill, 備份或回復TrustView系統相對容易.

所以那些擔心TrustView server不穩定的朋友, 某些方面想得稍微多了些?

當然, 有一種說法, 我完全贊同: "Windchill (or PTC)會活得比較久! 過幾年誰想知道TrustView還在不在?" 關於這點, 我想我不只是口頭贊成, 我還付出了行動!!!

在此, 不過就技術或設計理念與大家交流交流. 至於, 最後要採用什麼做法, "歡喜就好(台語)!"