2009年7月25日 星期六

"整合不就是加解密嘛!", 這麼想你就完了

有些人大概聽過一些TrustView的原理, 知道TrustView是以加/解密為基礎來保護檔案. 所以會很直接的以為Windchill與TrustView的整合, 不過就是把檔案加解密這麼回事. 看過第一篇文章的人從列出的主題大概很快會有個印象, 知道這個整合只怕不會這麼簡單. 而在我以往的經驗裡, 雖然也多少會碰到這樣的質疑, 但與客戶做需求訪談時, 都有機會在討論中, 逐步的讓客戶瞭解 DRM 與 Windchill 整合的原理, 範圍, 重點與選擇性, 並比較各項選擇之優劣, 最後與客戶達成共識.

不過今年景氣差, 有些找我合作的案子, 可能因為預算的壓力, 居然在還未與客戶需求訪談, 就把預算, 時程就先談妥了(有被強姦的感覺). 這些老兄在面對我提出的各項問題時, 卻茫然不知!!! 然後丟出這麼個問題 "整合不就是加解密嘛!". 客氣一點的, 會動之以情, 想辦法要我不要把事情搞的太複雜. 狠一點的幹脆要我配合演出, 編出一套說詞, 提出一個過得去, 可以在預算與期限內做出來的東西. 並且還要我想辦法催眠客戶(甚至背書)這是最佳的方案. 唉................. 五斗米令人折腰至此, 怎不令人感嘆. 本人無權要求他人和我持相同立場, 但我決定花些時間把我在整合方面的經驗寫出來, 一來為避免這類的麻煩事(或者是無聊事, 反正我不會答應)一再發生. 一來或許還能減少一些悲劇, 多積些陰德.

我們先假設真的以"不就是加解密嘛!"這樣的精神, 設計一個在文件審核的流程中, 把文件的主/副檔案(primary content & attachments)加密. 加密的時間點在文件進入發行狀態前, 聽起來符合上篇文章提到的重點.




以下是系統上線後通常會發生的幾個狀況:
1. 為什麼這個檔案我開不了(為什麼他打的開)?
2. 為什麼檔案沒加密 ?
3. 為什麼我不能修改?
4. 歷史紀錄裏的內容外流怎麼辦? 發行時才加密夠嗎?

**為什麼這個檔案我開不了(為什麼他打的開)?
如果沒有好好規劃整合, 那麼, 這個會讓使用者跑來抱怨, 跑到妳老闆那拍桌, 或是老闆叫你去立正...的問題, 可能會經常發生.
會造成 "為什麼我開不了(為什麼他打的開)?"的原因很多. 除去帳號整合的因素外, 通常大概就是 "Windchill上的文件政策與TrustView上的檔案政策不一致". 除去UAT時草率過關的可能性, 上線後還會發生這樣的狀況, 大概就是Windchill上的文件政策(可直接想成權限控管)換了, 然而TrustView上的"檔案政策" (TrustView上定義的權限控管)沒調整過來. 造成使用者可以找到Windchill文件, 下載主/副檔案, 但是卻打不開, 因為TrustView告訴他: "您沒權限!!!", 真是尷尬呀~




權限的整合是整個整合方案的重頭戲之一, 整合的方式不只一種. 當然各種權限整合的技術難度與成本自然是不同, 通常是要依客戶的實際應用來"量身定做"比較合理. 通常在"不就是加解密嘛!"這樣的精神下衍生出來的整合方案, 大概就是以"同步"(synchronization)的方式, 讓Windchill上的文件政策與TrustView上的檔案政策相符. 也就是檔案加密前, 根據預先約定好的規則, 依文件種類(或 加上"存放位置"... 等因素), 選擇某個TrustView系統上的事先做好的政策範本(Policy Template, 簡單來說 就是ACL(Access Control List)) 來保護加密後的檔案.

"同步"(synchronization)的弱點在於"兩次同步間的時間差". 例如Windchill上的文件政策剛剛才換了, 在TrustView系統上檔案政策還沒跟著調整過來之前, 就會存在權限控管不一致的時間差. 在某些公司, 文件政策不複雜, 也甚少更動. 因此, 簡單的同步基本上可符合需求. 但是若是文件種類繁多(例如超過十種), 文件政策也複雜, 變動可能頻繁(例如定期檢討與調整某些群組人員的權限), 若還是用簡單的"權限同步", 那這個"為什麼我開不了!!!"的抱怨, 怒吼或哀嚎, 只怕不定期的會聽到. 這很像吾友志凌的劇本:

於是客戶眼中發出了熊熊的怒火,如同火山爆發的熔岩般不斷的往外湧出,滾燙的岩漿把所有的一切全部吞噬,哀鴻遍野,寸草不留,卻只見無敵的天神冷冷的丟回一句話:我回去跟我們RD研究看看...

我負責過的整合案裏 我盡可能建議客戶採"真正的權限整合", 也就是說當使用者欲開啟一份加密過的檔案, TrustView會以加密檔案所屬的Windchill文件, 向Windchill取得"該使用者對此文件的使用權限", 進而約束使用行為. 採取這種"真正的權限整合", 可避免反覆進行同步的困擾. 有關這種進階的整合方式, 我將在"Authorization Integration"的主題時, 再做更多的介紹.

**為什麼檔案沒加密 ?
通常有幾個可能: 1. 檔案內容有問題. 2. 加密時 TrustServer有問題, 或是 Windchill與TrustServer間網路有問題.

先看看檔案內容有問題這種狀況. 排除不處理的格式(例如早期TrustView只處理MS Office與 Adobe PDF)這種狀況, 通常會發生在PDF格式的檔案. PDF支援加密格式, 幾乎所有DRM廠商對於PDF的保護都是呼叫Adobe原廠的API 將檔案加密. 但是若是使用者上傳一份已經被其他程式加密的PDF檔(例如從供應商那裏拿來的一份PTC檔), 理論上DRM的軟體是無法處理的. 因為底層呼叫的Adobe原廠API會丟出錯誤. 所以一般遇到這種情形, 簡單一點就是跳過這個錯誤, 也就是"放棄"這個加密的動作. 這種情形通常還好, 因為檔案其實原本就加密過了, 只是不屬於 trustview 管轄, 所以使用者不會被TrustView系統要求身分驗證(但是會被原本的保護機制要求輸入密碼或其他資訊). 這個問題或許向使用者解釋一下就OK了.

但是另外一種"digitally signed" PDF檔案, 就比較難搞! 也就是PDF中加入了數位簽章(Digital Signature). 這種檔案, Adobe原廠的API也一樣無法將它加密. 但是一般使用者是可以直接打開的, 只是沒辦法竄改內容罷了. 遇到這種檔案通常就比較麻煩, 因為一般使用者不會主動去注意有沒有數位簽章 (多數使用者可能也不知道甚麼是數位簽章). 所以遇到這種情況 一下子只怕還不好說明(除非你想扮演上面那個無敵(or 白目)天神).

另外, 天有不測風雲. TrustView server的硬體掛了, 或是有時不巧 Windchill 與 TrustServer 間網路有問題, 造成加密的失敗. 然而, 這類狀況下, 就可以平白無故的放過這些檔案? 說不定就是這些檔案造成您的"旦夕禍福"也難說得很? 所以檔案的加密處理最好不要當作萬無一失, 永遠要有最壞打算. 謹慎的例外處理與通知機制, 絕對是保命良方(如果你夠"神", 那就另當別論).

**為什麼我不能修改?
如果使用者把某份文件作版本修訂, 例如從A版產生B版. 如無意外, 使用者會找你, 因為他無法把B版文件上的內容檔案修改成他要的. Why? Windchill在版本修定(Revision)時, 會把上一版(A版)的一切(屬性與內容), 移交到新版本(B版). 而上一版(A版)發行前, 檔案已經被加密了!!! 而且配合一般在Windchill上對"已發行"文件的政策, 是不允許任何人再修改的. 所以真相就是使用者試著要修改從"A版"那兒繼承過來的加密檔. 這可不是調整權限這麼簡單的事, 應該說, 從根本上就是件錯誤!

對Windchill文件管理而言, "版本管理" (Version control) 是一個重要的基礎. 提供一份文件在初次發行並大量使用後, 藉由衍生(Revise)出的新版本, 重新定義內容與屬性, 以符合當下的需要. 在Windchill裏每一個版本的文件, 基本上都是"獨立個體", 擁有自己的屬性與內容, 生命週期, 審核流程... 所以在權限控管上, 不同版本文件的權限是彼此獨立的. 例如, 對一份狀態為"已發行"的A版文件, 與剛"revised", 還處於"In Work"的B版, 在權限上本來就不能混在一起.

所以當要整合Windchill與DRM時, 就必須得以"Windchill文件管理的方向"來思考. 因此, 版本管理是不能不考慮的. 對這個問題, 根本解法在於 A版裡的加密檔案與B版裏的加密檔案, 以TrustView的角度來看, 根本就該是兩份不同的檔案! 只不過 一開始時, 兩份檔案的內容恰好一樣罷了. 由於不是同一份檔案, 才有機會套用不同的文件政策.

因此在版本修訂時, 我們必須對"新版本裡繼承而來的檔案"做些額外的處理. 例如: "解密成原始檔" 或 "先解密再加密". 以上述在流程中加密的整合方式, 採用"解密成原始檔"比較好. 因為新版文件的流程會在文件發行之前把檔案加密.

**歷史紀錄裏的內容外流怎麼辦? 發行時加密夠嗎?
某個版本的文件, 從初始狀態(例如 IN WORK)到"已發行" 通常會經過數次修改(updated). 每次修改都會產生新的版序(Iteration). 最新的版序代表該版本文件, 其它過程中產生的版序稱為"歷史紀錄"(History). 如果只是在發行前把檔案加密, 而 歷史紀錄裏的檔案偏偏又包含了敏感的資料, 那這個從"不就是加解密嘛!"這樣的精神衍生出來的"在流程進入發行前加密"的方案, 似乎就不通了? 或是, 需要補強. 例如有個案子, 因為審核流程較精簡, 審核週期短, 因此決定在文件發行前, 再把歷史紀錄裡的內容"清除"或"一次加密". 但是, 對於其他案子而言, 這樣的假設就不一定成立. 所以在某些案子, 加密的時間點會提前到檔案上傳到Windchill的時刻, 或甚至檔案才剛在使用者的電腦產生時就先加密, 以系統預設的政策保護起來. 一但上傳到Windchill時再套用符合Windchill文件政策的權限設定.

以上我只是稍微讓大家嚐嚐味道, 體會一下, 為何整合不能只是以兒戲的態度將整合視為加解密的小東西而已. 我認為, Windchill與DRM的整合, 基本上必須回歸Windchill的文件管理. 以Windchill文管的特性去思考如何在把內容檔案在TrustView的掌控之下, 依然符合Windchill文管的精神. 並達到安全的要求.

沒有留言:

張貼留言