既然又被問到了, 乾脆把它寫出來好了.
首先, 我個人是不贊成採用下載時加密(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還在不在?" 關於這點, 我想我不只是口頭贊成, 我還付出了行動!!!
在此, 不過就技術或設計理念與大家交流交流. 至於, 最後要採用什麼做法, "歡喜就好(台語)!"
2009年10月9日 星期五
2009年8月12日 星期三
以資訊安全的角度去思考Windchill與DRM之整合
資訊安全領域常用三個"A"字頭的單字, 讓人快速的理解這領域一些重要的訴求.
Authentication, 簡單來說就是: "Who are you?". 這不難理解, 一間屋子讓你進進出出後連你是誰都搞不清楚, 說有多安全也沒人相信!
Authorization, 強調 "What can you do?". 這也蠻直接的. 安全當然不能建立在"人人具有高上道德" 或"良好公民理應奉公守法"這類的假設之上. 能稱得上安全 至少要有能力, 禁止做不該做的事.
Accountability, 字面上比較難猜, 基本上是強調 "What have you done?". 這也不難! 誰幹了什麼事本來就該交代得清清楚楚.
任何資訊系統一旦提到安全方面的議題, 至少都會以這三項來檢視. 例如: 一個使用者在進入系統 或使用任何系統資源或執行命令前, 須經過身分驗證, 讓系統確定你不是冒牌貨. 一旦系統知道你是誰, 可進一步根據既定的權限控管規則, 約束你的行為. 另外更進一步記錄你的所作所為.
當二個資訊系統要整合在一起時, 除了企業邏輯(business logic, 如processes)的整合外, 安全機制方面的整合也是一個重點, 甚至是必要. 以身分驗證為例, 您的使用者大概不會很樂意去記憶兩組帳號密碼(用來登入個別的資訊系統).
在我們談到 Windchill 與 DRM(如TrustView) 的整合, 自然我們也免不了要以資訊安全的角度來思考整合的方向, 更何況 Windchill 與 DRM 的整合的目的原本就是為了鞏固資訊安全, 補強一般資訊系統在數位內容(digital content, 如檔案)上的弱點: 一旦檔案被攜出企業之外, 即無法控管.
OK, 讓我們進入主題.
使用者需要有Windchill的帳號(account)才能使用Windchill裡的文件. 同樣的, 也需要有DRM(例如TrustView)的帳號才能使用受DRM保護的檔案. 正如前面所舉的例子, 使用者大概不太願意去記憶兩組帳號密碼. 所以如何讓使用者用同一組帳號密碼在Windchill與DRM系統間自在的游走, 就成為一個重要的課題. 從Windchill6開始, 預設是以Aphelion存放使用者帳號並負責使用者驗證. Aphelion基本上是一個支援LDAP協定的目錄服務系統(Directory Service), 許多資訊系統都提供LDAP的整合功能, 以便將企業內部那些支援LDAP協定的帳號系統(例如Active Directory, Oracle..)直接當作自己的帳號系統. 一來省下重建帳號資料的人力與時間成本, 二來利用既有系統上的身分認證機制, 達到身分認證上的整合. 下圖以TrustView的LDAP整合功能為例, 介紹藉由將Aphelion加入TrustView的帳號系統後, 使用者只需使用在Windchill上原有的帳號密碼, 登入TrustView系統.
但並不是所有的Windchill系統都單純的用Aphelion作為帳號系統. Windchill的帳號系統在設計時考量到延伸性與整合性, 基本上是一個將多個既有的帳號系統整合成一個新帳號系統的架構. 只要是支援LDAP協定帳號系統(AD, Oracle...) , 理論上都可被納入Windchill的帳號系統. 這種彈性在與DRM系統整合時, 有可能會超出某些DRM的能力範圍, 因此儘可能在整合的規劃階段就拿出來討論, 以免事後難以補救.
從帳號整合中可能會引出另一種需求, SSO(Single Sign On). 簡單來說就是雖然有兩套(或以上)資訊系統, 但是只需要一次身分認證 (如敲一次帳號密碼).
配合本篇主題, 並避免造成大家"見樹不見林"之憾, 有關 Windchill與 DRM在身分認證上的整合細節, 我會在另一個主題:"身分驗證(Authentication)整合之經驗分享"時再討論.
再來看看"權限整合". 如上一篇文章 "整合不就是加解密嘛!", 這麼想你就完了 時提到, 這絕對是重頭戲! 畢竟對使用者而言, 所謂的Windchill文件(Document)與內容(Content), 基本上是一體兩面的東西. 總不能讓使用者看得到Windchill文件, 但看不見該文件所屬的內容(主檔案或附件)吧?
一般而言, 權限整合應該是以其中一方為主, 另外一方為屬. 也就是說作為"從屬"方的資訊系統, 在判斷權限時, 應以"主"方為準. 對於Windchill與TrustView的整合而言, 主方應該是Windchill才合理. 以下是幾個重要的理由:
第一, 因為使用者理論上是先從Windchill上找到文件, 再從文件得到內容(下載檔案). 最後才是檔案的使用(如閱讀, 修改, 列印...). 若使用者無權閱讀該文件自然找不到 當然也無法下載該文件的主檔案與附件. 既然對權限控管始於Windchill, DRM系統以Windchill對文件之權限控管作為檔案權限控管的依歸, 當然是合情亦合理.
第二, Windchill與 DRM的整合本來就是為了補強Windchill無法掌控檔案被下載後的流通與使用問題. 而Windchill上通常早就根據企業的政策訂定了周延的權限控管機制, 沒有理由將之廢棄不用.
權限整合在實作"主從關係"的細節上可能基於成本考量有幾種不同的做法(如整合或同步). 另外Windchill原本並沒有DRM的功能與想法, 自然在訂定權限種類時, 不會針對有關檔案的細項使用權限: 如列印(print), 複製部分內容(copy & paste)..等, 獨立於"閱讀"權限之外. 所以當與TrustView系統整合時, 要把這些屬於DRM的細項權限"擴增"於Windchill之中(例如下圖)好呢? 還是制定一些輔助規則來將Windchill上的閱讀權限"對應"(mapping)到這些細項權限好呢(例如對某一類的文件, 能閱讀就表示能列印)? 其實也見仁見智說不得準. 總之種種細節就留待在另一篇文章: "權限整合(Authorization)整合之經驗分享"時, 再做更詳細的介紹吧.
最後是Accountability的整合. 對於使用者的行為, 各個資訊系統自然有它自己一套紀錄與呈現的方式, 例如Windchill裏各種log files(如 MethodServer log), 稽核事件與稽核報告(Audit events and audit reports), TrustView裏也有事件記錄(Event logs)...等等. 當系統整合時, 兩邊的Accountability 機制是否也需合而為一? 目前已與許多人交換過意見後, 基本上達到一個共識: "Nice to have"!
其實以資訊安全的角度而言, Accountability的重要性絕對不亞於其他兩個"A". 但是目前在大部分的系統裏, Accountability實際上還未受到應有的關注. 所以談到Accountability的整合, 通常只是聊聊過就算. 畢竟, "Nice to have"通常是應酬時表達"多餘"的禮貌用語. 當客戶回答我 "Nice to have"時, 我想我也該識趣的結束這個話題唄?
Authentication, 簡單來說就是: "Who are you?". 這不難理解, 一間屋子讓你進進出出後連你是誰都搞不清楚, 說有多安全也沒人相信!
Authorization, 強調 "What can you do?". 這也蠻直接的. 安全當然不能建立在"人人具有高上道德" 或"良好公民理應奉公守法"這類的假設之上. 能稱得上安全 至少要有能力, 禁止做不該做的事.
Accountability, 字面上比較難猜, 基本上是強調 "What have you done?". 這也不難! 誰幹了什麼事本來就該交代得清清楚楚.
任何資訊系統一旦提到安全方面的議題, 至少都會以這三項來檢視. 例如: 一個使用者在進入系統 或使用任何系統資源或執行命令前, 須經過身分驗證, 讓系統確定你不是冒牌貨. 一旦系統知道你是誰, 可進一步根據既定的權限控管規則, 約束你的行為. 另外更進一步記錄你的所作所為.
當二個資訊系統要整合在一起時, 除了企業邏輯(business logic, 如processes)的整合外, 安全機制方面的整合也是一個重點, 甚至是必要. 以身分驗證為例, 您的使用者大概不會很樂意去記憶兩組帳號密碼(用來登入個別的資訊系統).
在我們談到 Windchill 與 DRM(如TrustView) 的整合, 自然我們也免不了要以資訊安全的角度來思考整合的方向, 更何況 Windchill 與 DRM 的整合的目的原本就是為了鞏固資訊安全, 補強一般資訊系統在數位內容(digital content, 如檔案)上的弱點: 一旦檔案被攜出企業之外, 即無法控管.
OK, 讓我們進入主題.
使用者需要有Windchill的帳號(account)才能使用Windchill裡的文件. 同樣的, 也需要有DRM(例如TrustView)的帳號才能使用受DRM保護的檔案. 正如前面所舉的例子, 使用者大概不太願意去記憶兩組帳號密碼. 所以如何讓使用者用同一組帳號密碼在Windchill與DRM系統間自在的游走, 就成為一個重要的課題. 從Windchill6開始, 預設是以Aphelion存放使用者帳號並負責使用者驗證. Aphelion基本上是一個支援LDAP協定的目錄服務系統(Directory Service), 許多資訊系統都提供LDAP的整合功能, 以便將企業內部那些支援LDAP協定的帳號系統(例如Active Directory, Oracle..)直接當作自己的帳號系統. 一來省下重建帳號資料的人力與時間成本, 二來利用既有系統上的身分認證機制, 達到身分認證上的整合. 下圖以TrustView的LDAP整合功能為例, 介紹藉由將Aphelion加入TrustView的帳號系統後, 使用者只需使用在Windchill上原有的帳號密碼, 登入TrustView系統.
但並不是所有的Windchill系統都單純的用Aphelion作為帳號系統. Windchill的帳號系統在設計時考量到延伸性與整合性, 基本上是一個將多個既有的帳號系統整合成一個新帳號系統的架構. 只要是支援LDAP協定帳號系統(AD, Oracle...) , 理論上都可被納入Windchill的帳號系統. 這種彈性在與DRM系統整合時, 有可能會超出某些DRM的能力範圍, 因此儘可能在整合的規劃階段就拿出來討論, 以免事後難以補救.
從帳號整合中可能會引出另一種需求, SSO(Single Sign On). 簡單來說就是雖然有兩套(或以上)資訊系統, 但是只需要一次身分認證 (如敲一次帳號密碼).
配合本篇主題, 並避免造成大家"見樹不見林"之憾, 有關 Windchill與 DRM在身分認證上的整合細節, 我會在另一個主題:"身分驗證(Authentication)整合之經驗分享"時再討論.
再來看看"權限整合". 如上一篇文章 "整合不就是加解密嘛!", 這麼想你就完了 時提到, 這絕對是重頭戲! 畢竟對使用者而言, 所謂的Windchill文件(Document)與內容(Content), 基本上是一體兩面的東西. 總不能讓使用者看得到Windchill文件, 但看不見該文件所屬的內容(主檔案或附件)吧?
一般而言, 權限整合應該是以其中一方為主, 另外一方為屬. 也就是說作為"從屬"方的資訊系統, 在判斷權限時, 應以"主"方為準. 對於Windchill與TrustView的整合而言, 主方應該是Windchill才合理. 以下是幾個重要的理由:
第一, 因為使用者理論上是先從Windchill上找到文件, 再從文件得到內容(下載檔案). 最後才是檔案的使用(如閱讀, 修改, 列印...). 若使用者無權閱讀該文件自然找不到 當然也無法下載該文件的主檔案與附件. 既然對權限控管始於Windchill, DRM系統以Windchill對文件之權限控管作為檔案權限控管的依歸, 當然是合情亦合理.
第二, Windchill與 DRM的整合本來就是為了補強Windchill無法掌控檔案被下載後的流通與使用問題. 而Windchill上通常早就根據企業的政策訂定了周延的權限控管機制, 沒有理由將之廢棄不用.
權限整合在實作"主從關係"的細節上可能基於成本考量有幾種不同的做法(如整合或同步). 另外Windchill原本並沒有DRM的功能與想法, 自然在訂定權限種類時, 不會針對有關檔案的細項使用權限: 如列印(print), 複製部分內容(copy & paste)..等, 獨立於"閱讀"權限之外. 所以當與TrustView系統整合時, 要把這些屬於DRM的細項權限"擴增"於Windchill之中(例如下圖)好呢? 還是制定一些輔助規則來將Windchill上的閱讀權限"對應"(mapping)到這些細項權限好呢(例如對某一類的文件, 能閱讀就表示能列印)? 其實也見仁見智說不得準. 總之種種細節就留待在另一篇文章: "權限整合(Authorization)整合之經驗分享"時, 再做更詳細的介紹吧.
例圖: 在Windchill上增加新的權限種類
最後是Accountability的整合. 對於使用者的行為, 各個資訊系統自然有它自己一套紀錄與呈現的方式, 例如Windchill裏各種log files(如 MethodServer log), 稽核事件與稽核報告(Audit events and audit reports), TrustView裏也有事件記錄(Event logs)...等等. 當系統整合時, 兩邊的Accountability 機制是否也需合而為一? 目前已與許多人交換過意見後, 基本上達到一個共識: "Nice to have"!
其實以資訊安全的角度而言, Accountability的重要性絕對不亞於其他兩個"A". 但是目前在大部分的系統裏, Accountability實際上還未受到應有的關注. 所以談到Accountability的整合, 通常只是聊聊過就算. 畢竟, "Nice to have"通常是應酬時表達"多餘"的禮貌用語. 當客戶回答我 "Nice to have"時, 我想我也該識趣的結束這個話題唄?
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文管的精神. 並達到安全的要求.
不過今年景氣差, 有些找我合作的案子, 可能因為預算的壓力, 居然在還未與客戶需求訪談, 就把預算, 時程就先談妥了(有被強姦的感覺). 這些老兄在面對我提出的各項問題時, 卻茫然不知!!! 然後丟出這麼個問題 "整合不就是加解密嘛!". 客氣一點的, 會動之以情, 想辦法要我不要把事情搞的太複雜. 狠一點的幹脆要我配合演出, 編出一套說詞, 提出一個過得去, 可以在預算與期限內做出來的東西. 並且還要我想辦法催眠客戶(甚至背書)這是最佳的方案. 唉................. 五斗米令人折腰至此, 怎不令人感嘆. 本人無權要求他人和我持相同立場, 但我決定花些時間把我在整合方面的經驗寫出來, 一來為避免這類的麻煩事(或者是無聊事, 反正我不會答應)一再發生. 一來或許還能減少一些悲劇, 多積些陰德.
我們先假設真的以"不就是加解密嘛!"這樣的精神, 設計一個在文件審核的流程中, 把文件的主/副檔案(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文管的精神. 並達到安全的要求.
2009年7月23日 星期四
新主題: Windchill與DRM之整合方案
有不少朋友知道我之前的經歷, 也知道我主導過幾個 Windchill 與 TrustView 整合的成功案例. 最近, 因為"個人資料保護法"三讀的新聞, 適逢有消息說景氣有好轉跡象, 應兄弟們的要求, 除了分享過去研讀資訊安全方面的心得外, 也順便聊一聊 Windchill 與 DRM 整合的一些經驗. 順便也可與資訊安全的一些理論相互應證. 當然, 接下來相關的主題, 基本上會以TrustView作為DRM的代表. 對此, 其他的DRM廠商也別不高興, 一來, DRM方案裏, 嚴格來說我對TrustView最熟, 而TrustView投入與Windchill的系統整合時間最久. 二來, 我相信許多不同的DRM產品觀念是相通的, 若您認同我在Windchill與DRM整合上的想法或論點, 理論上也可把其他DRM產品套用進來. 因此, 並非獨厚 TrustView一家.
如本站其他文章, 在這個主題上, 我們還是著重設計理念的分享與經驗的交流, 不會有實際的程式碼放上來. 所以, 喜歡自己DIY的朋友先抱歉了.
以下是目前我預計要發表的幾篇文章. 因為這個主題涵蓋範圍還蠻廣的, 所以採取多個 "次主題" 方式. 一來, 每次分享一點, 比較容易消化. 並且以各種不同角度來思考這個主題, 效果也應該會好些.
1. 為什麼Windchill上需要DRM之整合方案? (一切都應該由此開始吧, 如果最後發現不需要, 底下就不用看了...)
2. "整合不就是加解密嘛!" --> 這麼想你就完了 (如題, 希望還來得及拯救一些人)
2.1下載時加密(Encryption on download)是個好主意? (有些人好像不了解問題的嚴重性, 再加一篇)
3. 以資訊安全的角度去思考Windchill與DRM之整合 : Thinking in 3 big "A"s (不是討論"A"片, 有期待者請轉台)
4. 以Windchill之 "文件管理"來思考DRM之整合 (通常, 這裡就是所謂的 Business Logic, 應該是專案最主要的目的)
5. 文件內容(檔案)加密的時間點 (想清楚! 免得白忙一場...)
6. 身分驗證(Authentication)整合之經驗分享 (必要! 如果你不想被罵死...)
7. 權限整合(Authorization)整合之經驗分享 (重要! 如果你不想被累死...)
8. 例外處理 (絕對必要!! 如果你不想被罵死或累死...)
9. 災難復原 (絕對必要!!! 如果你不想提早退休...)
10. 系統架構設計 (理論上是遙遙無期, 除非大家看到最後不嫌煩, 又真的很想DIY, 或者我找不到事做...)
如本站其他文章, 在這個主題上, 我們還是著重設計理念的分享與經驗的交流, 不會有實際的程式碼放上來. 所以, 喜歡自己DIY的朋友先抱歉了.
以下是目前我預計要發表的幾篇文章. 因為這個主題涵蓋範圍還蠻廣的, 所以採取多個 "次主題" 方式. 一來, 每次分享一點, 比較容易消化. 並且以各種不同角度來思考這個主題, 效果也應該會好些.
1. 為什麼Windchill上需要DRM之整合方案? (一切都應該由此開始吧, 如果最後發現不需要, 底下就不用看了...)
2. "整合不就是加解密嘛!" --> 這麼想你就完了 (如題, 希望還來得及拯救一些人)
2.1下載時加密(Encryption on download)是個好主意? (有些人好像不了解問題的嚴重性, 再加一篇)
3. 以資訊安全的角度去思考Windchill與DRM之整合 : Thinking in 3 big "A"s (不是討論"A"片, 有期待者請轉台)
4. 以Windchill之 "文件管理"來思考DRM之整合 (通常, 這裡就是所謂的 Business Logic, 應該是專案最主要的目的)
5. 文件內容(檔案)加密的時間點 (想清楚! 免得白忙一場...)
6. 身分驗證(Authentication)整合之經驗分享 (必要! 如果你不想被罵死...)
7. 權限整合(Authorization)整合之經驗分享 (重要! 如果你不想被累死...)
8. 例外處理 (絕對必要!! 如果你不想被罵死或累死...)
9. 災難復原 (絕對必要!!! 如果你不想提早退休...)
10. 系統架構設計 (理論上是遙遙無期, 除非大家看到最後不嫌煩, 又真的很想DIY, 或者我找不到事做...)
2009年7月11日 星期六
以TrustView為例介紹DRM之基本概念
選擇TrustView來介紹DRM (Digital Right Management)的重要觀念原因很無它, 只因本人曾在TrustView服務. 加上其他家的產品我不夠熟, 倒不是獨厚TrustView. 至於此篇文章是否有所偏頗 或刻意為TrustView宣傳, 就留給讀者判斷.
我在上篇"淺論DRM (Digital Right Management)"中提到DRM強調兩個重點 ,而且是傳統系統安全上忽略的部份:
更細緻的權限種類 (如閱讀期限, 次數, 列印, 複製...).
數位內容的使用權限控管, 不因所在位置(如企業內部系統 或企業之外某競爭對手的個人電腦)而有所不同.
我在上篇"淺論DRM (Digital Right Management)"中提到DRM強調兩個重點 ,而且是傳統系統安全上忽略的部份:
首先用一份被TrustView系統保護的 MS Word 的檔案"dav1.doc" 來說明第一個概念. 此檔案是在作者以MS Word編寫完成後, 再存成TrustView的格式. 作者並為此檔案制定了 "所有合法使用者皆可讀取但僅能讀取"的規則. 所以當此檔案由一般合法使用者的使用時, 自然就如下圖所示, 其他行為如修改, 複製, 列印.. 皆不允許.
至於TrustView怎麼解決此份檔案"被帶出系統之外"後仍能確保"所有合法使用者皆可讀取但僅能讀取"的規則? 這個問題稍微複雜點, 但不難懂.
首先當使用者把檔案交由TrustView管控時, 此檔案即被TrustView系統"加密". 此加密過的檔案必須由加裝 "TrustView前端程式"(TrustView Client) 的MS Word才能讀取. 若沒裝TrustView前端程式, 看到的檔案基本上就成了這副德性:
如果裝好TrustView前端程式, 也不表示任何人都可閱讀此加密檔. 因為條件為"合法使用者", 也就是能在TrustView系統有帳號的使用者. TrustView前端程式會要求使用者出具證明(例如 ID 與password) 然後將此證明資訊交由後端的 "TrustServer" 驗證此資訊是否正確. 如圖, 經過身分認證後 MS Word上會顯示使用者身份.
TrustServer除了回傳使用者身分是否確認之外, 還告知TrustView前端程式此使用者對此文件的使用權. 如上例, 合法使用者在通過身分驗證後, 馬上可閱讀該檔案. 但是如果另一份檔案僅允許少數人閱讀, 那沒有閱讀權利的使用者 還是無法閱讀此文件.
此文主要是借用TrustView系統的畫面, 先讓使用者能迅速進入DRM這個主題. 至於哪一家廠商的方案較好, 架構比較優... 這裡並不討論. 後續的文章, 會開始討論一些較為細節的部份: 如一般DRM系統架構, 導入DRM系統需要考慮的事項... 當然如無意外, 我還是會以TrustView來做對照說明.
訂閱：
文章 (Atom)