2009年10月9日 星期五
下載時加密(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還在不在?" 關於這點, 我想我不只是口頭贊成, 我還付出了行動!!!
在此, 不過就技術或設計理念與大家交流交流. 至於, 最後要採用什麼做法, "歡喜就好(台語)!"
首先, 我個人是不贊成採用下載時加密(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月1日 星期四
PDMLink 9 建立物件時屬性欄位間的互動研究(一)
愈來愈多R9客戶反映使用者需要在建立物件(如文件, 零件)時, 屬性的輸入欄位(attribute's input)間需要有互動關係 相信老Windchill users與老PTC應該對這類的需求再熟也不過了. Template processor時代做這方面的客製司空見慣. 不要說大師兄Wayne, David Su老大, Michael等前輩熟得不要再熟了, 就連客戶那邊的IT自己都玩得興高采烈! 像Joseph, James, Xavier..
PDMLink系列好像從7版開始, 自訂物件類型(Soft type)會自動出現在建立時的類型選項(Type options)中, 而自訂物件類型所包含的自訂屬性(IBA)也會直接顯現在屬性的輸入頁面. 也就是說Windchill R7 為此提出一標準機制, 認為足以供Windchill的黎民百姓使用.
這真是標準的.... 想太多...
這個屬性輸入頁面的第一個問題是很溫柔(以歌手趙傳的語言來說)! 或太溫柔了!!!
這標準界面到 R8 時印象中還是有點陽春(也就是長得有點抱歉).
第二個問題最要命! 因為他這個標準界面是個大黑箱!!! R&D似乎沒打算開放出來讓大家來客製. 個人在過去幾個案子曾經有被逼著做過一些客製, 雖然成功了, 但是必須承認客製的難度比Windchill 626 Template processor時要高, 風險也較大. 更重要的是, 這類的客製, 理論上PTC應該是不負責的.
到了R9 有更多壞消息, Template processor幾乎不見了!!! 取而代之的是WCA. WCA基本上是PTC綜合二年前甚至三年前一些蠻"火"的技術, 關起門來硬搞出來的一套MVC架構, 像個萬花筒一樣. 以周董的說法: "其實還蠻屌的!". 但是上過課的人都認為:更難學了!
至於屬性輸入介面的部分, 有好消息, 也有壞消息. 好消息是這一代界面比較漂亮, 也較好用. 例如日期的輸入終於有日曆了(不過不是萬年曆就是了)! 壞消息是, 這些屬性輸入背後的HTML "INPUT"又更複雜了. 例如做互動效果常需要依賴的輸入名稱(element name), 複雜的嚇人. 例如下圖就是個例子. 對屬性"DemoAttr01", Windchill很貼心的為他取名為...咦? 好像怪怪的是嗎?
"name="components$loadWizardStep$OR:wt.inf.library.WTLibrary:14160$|..."這是什麼東東啊~
其實這張圖我們只看到一小段 後會還有哩
我把其中幾個關鍵字框起來, 至少讓我們分辨的出這個"名字長的不像話的傢伙", 真的是上面那個看來很單純的TextArea! 你若問我為什麼RD要取那麼長的名字? 我只能說我不知道 (其實多少猜得出, 但是算了..)! 但重要的是, 這代表了"互動效果"看來沒像從前那麼好搞定! 這一長串的名字 有些部分還好猜, 有些部分就不一定了? 如下圖:
"4753366976990569820"又是幹什麼的? 好像每次還不一樣?
我在研究這個主題時, 我想過幾種策略. "傳統的"做法: 掌握屬性輸入欄位背後的命名規則(Naming Rule)後再來做加工, 是其中一種. 另一種做法是"訂自己的屬性輸入欄位命名規則". 這種作法還需要配合其他部份的客製: 製做自己的屬性輸入頁面, 並把Windchill後端(server side)建立物件的"Form Proccessor"也同時換成自己客製的Form Proccessor. 簡單來說, 也就是擴大客製Wizard的範圍, 但是說不定比較划算!
由於自訂屬性輸入欄位命名規則與客製Form Proccessor我有一些相關經驗, 所以本月初在訂研究題材時, 我就想試試第一種策略. 目前已有一些進展.
如下面的圖片所示, 我定義了一種文件類型並加入了幾個屬性:
假設使用者希望 demoAttr02 的選項會決定demoAttr03的合法選項. 規則如下:
當 demoAttr02 = option1 時 demoAttr03僅有option1_1, option1_2, option1_3可選
當 demoAttr02 = option2 時 demoAttr03僅有option2_1, option2_2可選
當 demoAttr02 = option3 時 demoAttr03僅有option3_1可選
若用R9預設的建立文件界面 毫無意外 欄位間無互動效果
再加入了一些客製之後, 達到了上述的互動.
關鍵的作法, 下篇文章在介紹.
PDMLink系列好像從7版開始, 自訂物件類型(Soft type)會自動出現在建立時的類型選項(Type options)中, 而自訂物件類型所包含的自訂屬性(IBA)也會直接顯現在屬性的輸入頁面. 也就是說Windchill R7 為此提出一標準機制, 認為足以供Windchill的黎民百姓使用.
這真是標準的.... 想太多...
這個屬性輸入頁面的第一個問題是很溫柔(以歌手趙傳的語言來說)! 或太溫柔了!!!
這標準界面到 R8 時印象中還是有點陽春(也就是長得有點抱歉).
第二個問題最要命! 因為他這個標準界面是個大黑箱!!! R&D似乎沒打算開放出來讓大家來客製. 個人在過去幾個案子曾經有被逼著做過一些客製, 雖然成功了, 但是必須承認客製的難度比Windchill 626 Template processor時要高, 風險也較大. 更重要的是, 這類的客製, 理論上PTC應該是不負責的.
到了R9 有更多壞消息, Template processor幾乎不見了!!! 取而代之的是WCA. WCA基本上是PTC綜合二年前甚至三年前一些蠻"火"的技術, 關起門來硬搞出來的一套MVC架構, 像個萬花筒一樣. 以周董的說法: "其實還蠻屌的!". 但是上過課的人都認為:更難學了!
至於屬性輸入介面的部分, 有好消息, 也有壞消息. 好消息是這一代界面比較漂亮, 也較好用. 例如日期的輸入終於有日曆了(不過不是萬年曆就是了)! 壞消息是, 這些屬性輸入背後的HTML "INPUT"又更複雜了. 例如做互動效果常需要依賴的輸入名稱(element name), 複雜的嚇人. 例如下圖就是個例子. 對屬性"DemoAttr01", Windchill很貼心的為他取名為...咦? 好像怪怪的是嗎?
"name="components$loadWizardStep$OR:wt.inf.library.WTLibrary:14160$|..."這是什麼東東啊~
其實這張圖我們只看到一小段 後會還有哩
我把其中幾個關鍵字框起來, 至少讓我們分辨的出這個"名字長的不像話的傢伙", 真的是上面那個看來很單純的TextArea! 你若問我為什麼RD要取那麼長的名字? 我只能說我不知道 (其實多少猜得出, 但是算了..)! 但重要的是, 這代表了"互動效果"看來沒像從前那麼好搞定! 這一長串的名字 有些部分還好猜, 有些部分就不一定了? 如下圖:
"4753366976990569820"又是幹什麼的? 好像每次還不一樣?
我在研究這個主題時, 我想過幾種策略. "傳統的"做法: 掌握屬性輸入欄位背後的命名規則(Naming Rule)後再來做加工, 是其中一種. 另一種做法是"訂自己的屬性輸入欄位命名規則". 這種作法還需要配合其他部份的客製: 製做自己的屬性輸入頁面, 並把Windchill後端(server side)建立物件的"Form Proccessor"也同時換成自己客製的Form Proccessor. 簡單來說, 也就是擴大客製Wizard的範圍, 但是說不定比較划算!
由於自訂屬性輸入欄位命名規則與客製Form Proccessor我有一些相關經驗, 所以本月初在訂研究題材時, 我就想試試第一種策略. 目前已有一些進展.
如下面的圖片所示, 我定義了一種文件類型並加入了幾個屬性:
假設使用者希望 demoAttr02 的選項會決定demoAttr03的合法選項. 規則如下:
當 demoAttr02 = option1 時 demoAttr03僅有option1_1, option1_2, option1_3可選
當 demoAttr02 = option2 時 demoAttr03僅有option2_1, option2_2可選
當 demoAttr02 = option3 時 demoAttr03僅有option3_1可選
若用R9預設的建立文件界面 毫無意外 欄位間無互動效果
再加入了一些客製之後, 達到了上述的互動.
關鍵的作法, 下篇文章在介紹.
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月24日 星期五
為什麼Windchill上需要DRM之整合方案
Windchill(含PDMLink) 上的"權限控管"(Access Control)是敝人目前為止見過最有彈性也最複雜的(我想有空我會為此也寫一篇與大家分享). 不過因為歷史背景, 從前DRM並非顯學(悲... 到目前也還不是), 所以Windchill一直沒有真正把DRM的精神融入它的安全機制.
ContentHolder vs. Content
基本上, 一般使用者概念上習慣稱呼為"文件"的電子檔案, 如MS Office的Word, Excel, ..或其它格式如PDF.., 在Windchill上並不是被真正被當作一份份的"文件" (Document). "Windchill的文件"可以把它想像成舊式"裝公文用的牛皮紙袋", 裡面可以放"一個或多個檔案". 但是從外面或整體來看, 就是一份文件. 而一般使用者習慣上稱為文件的檔案, 對於Windchill的文件來說只是一個個 "內容物"(Contents), 而文件叫做 "含有內容"的東西 (ContentHolder).
閒話: Windchill把"Document"擴大為比較複雜的概念, 是一個具有多種層面(facets) 的複合體. 每一種層面都有它在實際使用上的意義. 例如一份Windchill文件可擁有"屬性"(片段的資訊欄位, 例如名稱 編號 種類 部門 作者 建立日期)以利使用者快速瀏覽重要資訊或搜尋, 而不需把實際內容檔案一個一個打開, 一頁頁閱讀 . 這種"擁有屬性"的能力就是一種"物件(Object, or Object Oriented)層面" . 而文件有生命週期, 能展現文件從開始建立 審核 發行 最終下線 成熟度所以又是另一種層面...
在Windchill裏, 一個使用者要能接觸(找到 )或使用(如閱讀屬性(如名稱, 註解), 內容檔, 修改屬性, 修改內容, 增加附件...)須經過 "身分驗證"(Authentication)與 "權限控管" (Authorization), 並且使用行為也會被記錄下來 (Accountability). 但是一旦使用者有權閱讀文件內容, 就表示使用者可以把檔案從Windchill上下載下來. 若使用者直接把這個下載下來的檔案透過USB裝置, 郵件, 網路...傳遞給公司內"無權閱讀"含有此檔案之Windchill文件的人員, 或甚至是流傳到公司外, 不明人士之手, 基本上又回到"淺論DRM (Digital Right Management)"所提到之傳統安全系統的問題.
Windchill 8之前的版本, 對Windchill文件具"閱讀"(Read)權限的人, 除了允許進入物件屬性頁(Object Properties)查閱基本資訊外, 也同時賦與其下載內容檔案的權力.
從Windchill 8開始, 原本的"閱讀權"僅僅管控"物件屬性"之查閱. 內容檔不管是"主要檔案"(Primary Content)或"附件"(Attachment)的下載則由另一種叫作"下載"(Download)的權限來負責.
但是, 不管是Windchill8之前, 還是之後, 對 "有權從Windchill上下載檔案的人把檔案外流" 這件事基本上一樣是無解. 所以這也是本文主題 "為什麼Windchill上需要DRM之整合方案"的由來.
Content Holder's Security + Content's Security
整合方案主要的重點就是 Windchill文件資訊的管控, 仍然由Windchill的權限控管機制負責, 應為Windchill做的真的很好. 但是一旦涉及檔案使用, 就由DRM系統接手. 簡言之, 如果存放在Windchill裡的這些檔案是已經被DRM保護的檔案, 就有機會達到這樣的效果.
以下為Windchill 7與TrustView整合後 文件使用之範例圖示, 若對TrustView的操作介面或原理不熟悉者 可先參考 "以TrustView為例介紹DRM之基本概念".
首先, 因為內容檔案已經被轉換成TrustView的檔案格式, 所以沒有TrustView前端程式(Client Program)的人即使取得此檔案也無法讀取真正內容
若已安裝TrustView Client, 開啟這個被TrustView保護的檔案時, 就必須先經過身分驗證, 然後TrustView系統會進一步查出你是是否有權使用此檔案.
如下例, 系統查知此人僅有"讀取"之權限, 因而將"檔案內容"呈現, 並封鎖其它修改, 列印..之功能.
至於 "怎麼做?", "要注意些什麼?", 與其它種種問題就留待其它的文章一樣一樣來說.
ContentHolder vs. Content
基本上, 一般使用者概念上習慣稱呼為"文件"的電子檔案, 如MS Office的Word, Excel, ..或其它格式如PDF.., 在Windchill上並不是被真正被當作一份份的"文件" (Document). "Windchill的文件"可以把它想像成舊式"裝公文用的牛皮紙袋", 裡面可以放"一個或多個檔案". 但是從外面或整體來看, 就是一份文件. 而一般使用者習慣上稱為文件的檔案, 對於Windchill的文件來說只是一個個 "內容物"(Contents), 而文件叫做 "含有內容"的東西 (ContentHolder).
閒話: Windchill把"Document"擴大為比較複雜的概念, 是一個具有多種層面(facets) 的複合體. 每一種層面都有它在實際使用上的意義. 例如一份Windchill文件可擁有"屬性"(片段的資訊欄位, 例如名稱 編號 種類 部門 作者 建立日期)以利使用者快速瀏覽重要資訊或搜尋, 而不需把實際內容檔案一個一個打開, 一頁頁閱讀 . 這種"擁有屬性"的能力就是一種"物件(Object, or Object Oriented)層面" . 而文件有生命週期, 能展現文件從開始建立 審核 發行 最終下線 成熟度所以又是另一種層面...
在Windchill裏, 一個使用者要能接觸(找到 )或使用(如閱讀屬性(如名稱, 註解), 內容檔, 修改屬性, 修改內容, 增加附件...)須經過 "身分驗證"(Authentication)與 "權限控管" (Authorization), 並且使用行為也會被記錄下來 (Accountability). 但是一旦使用者有權閱讀文件內容, 就表示使用者可以把檔案從Windchill上下載下來. 若使用者直接把這個下載下來的檔案透過USB裝置, 郵件, 網路...傳遞給公司內"無權閱讀"含有此檔案之Windchill文件的人員, 或甚至是流傳到公司外, 不明人士之手, 基本上又回到"淺論DRM (Digital Right Management)"所提到之傳統安全系統的問題.
Windchill 8之前的版本, 對Windchill文件具"閱讀"(Read)權限的人, 除了允許進入物件屬性頁(Object Properties)查閱基本資訊外, 也同時賦與其下載內容檔案的權力.
從Windchill 8開始, 原本的"閱讀權"僅僅管控"物件屬性"之查閱. 內容檔不管是"主要檔案"(Primary Content)或"附件"(Attachment)的下載則由另一種叫作"下載"(Download)的權限來負責.
但是, 不管是Windchill8之前, 還是之後, 對 "有權從Windchill上下載檔案的人把檔案外流" 這件事基本上一樣是無解. 所以這也是本文主題 "為什麼Windchill上需要DRM之整合方案"的由來.
Content Holder's Security + Content's Security
整合方案主要的重點就是 Windchill文件資訊的管控, 仍然由Windchill的權限控管機制負責, 應為Windchill做的真的很好. 但是一旦涉及檔案使用, 就由DRM系統接手. 簡言之, 如果存放在Windchill裡的這些檔案是已經被DRM保護的檔案, 就有機會達到這樣的效果.
以下為Windchill 7與TrustView整合後 文件使用之範例圖示, 若對TrustView的操作介面或原理不熟悉者 可先參考 "以TrustView為例介紹DRM之基本概念".
首先, 因為內容檔案已經被轉換成TrustView的檔案格式, 所以沒有TrustView前端程式(Client Program)的人即使取得此檔案也無法讀取真正內容
若已安裝TrustView Client, 開啟這個被TrustView保護的檔案時, 就必須先經過身分驗證, 然後TrustView系統會進一步查出你是是否有權使用此檔案.
如下例, 系統查知此人僅有"讀取"之權限, 因而將"檔案內容"呈現, 並封鎖其它修改, 列印..之功能.
至於 "怎麼做?", "要注意些什麼?", 與其它種種問題就留待其它的文章一樣一樣來說.
2009年7月23日 星期四
Windchill Performance Tuning
積非成是: "Multiple Background servers"
Joseph's "Configure Economical Clustering with 'balance'"(欠稿, 追緝中...)
訂閱：
文章 (Atom)