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'"(欠稿, 追緝中...)
Windchill Report Solutions
ChihLing 's Jasper Integration Demo
Windchill與報表系統整合之效益簡介: 章節預覽
David's Jasper Integration Demo 1 (InfoEngine Data Source)
David's Jasper Integration Demo 2 (RMI Data Source)
David's Jasper Integration Demo 3 (A New Document-in-Process Report)
PKI相關文章導引
好書推薦: PKI: Implementing and Managing E-Security
PKI 妙喻 & "向左, 向右, 向前看"
公/私鑰(Public/Private Key)的原始用途
密碼學閒話
數位信封: 改良版的悄悄話
數位簽章(Digital Signature)簡介
憑證, 漫遊網路世界的駕照
憑證與公/私鑰之實例應用一: SSL
PKI是什麼? PKI裡有什麼?
新主題: 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月21日 星期二
數位簽章(Digital Signature)簡介
此篇假設您對密碼學的一些術語已有基本的認識, 若您時間有限急於進入主題, 不妨閱讀上篇"密碼學閒話 ".
簽章, "簽名/蓋章", 基本上就是早期用來"證明某人身分", 進而認定某些東西的"有效性". 舉例來說, 文件/信件的署名, 合約上的簽名/蓋章 ... 但以簽章方式來證明文件或合約的有效性通常會衍生另一個問題, 也就是"完整性"或是文件或合約內容是否會遭到"竄改"的問題. 例如通常簽章都在"最後一頁", 前幾頁的內容有可能遭有心人士抽換以獲取不當利益. 所以我們常會看到有所謂的"騎縫章",用來蓋在夾頁上, 以確保內容的完整性.
所以, 用"數位方式"做成的"簽名蓋章", 當然要能達到證明某人身分與確保資料的完整性.
在討論實際做法之前, 我們來看看一個非對稱密碼學裏一個重要的部分 "Hash", 也就是有些朋友在修資料結構課時碰到的Hash.
Hash基本上是一種方法, 把大量資料內容消化然後產生一個"固定長度"的結果資料. 固定長度的結果資料比起原始資料通常小的多. 好的Hash演算法基本上可確保不同內容的資料會產生不同的Hash結果. 所以這個固定長度的結果資料又稱為 "fingerprint" 或 "digest". 也就是說, 對於兩分數百頁的文件(當然是頁數一樣, 或看起來一樣), 要確認兩份文件是否真正相同, 一種方式就是逐頁逐字比對, 另一種更有效的方式就是比對這兩份文件的fingerprints(Hash結果).
在製作數位簽章時就用到了Hash. MD5與SHA-1是比較常見用於數位簽章的Hash演算法. 製作數位簽章的步驟為: 1. 將欲被簽署之資料(如文件或合約)以選定之Hash演算法產生fingerprint. 2. 將產生之fingerpint用簽屬人之私鑰加密 (由於fingerprint很小, 用非對稱演算法加密沒問題) 3. 將以私鑰加密後的fingerprint加上其他輔助資訊, 如演算法名稱, 合成所謂的數位簽章.
因此簽署人可以把資料(文件或合約)以明碼的方式傳給其他人. 其他人可用簽署人之"公鑰", 先把數位簽章裏頭那一個用簽署人"私鑰"加密的fingerprint還原. 再用數位簽章內指定的Hash演算法, 為資料(文件或合約)重新產生fingerprint. 將兩個fingerprints比對, 即可知道文件被竄改與否.
聽起來前輩們的心血終於為我們建立了完美世界! 但是我們很快就發現, 人心之邪惡遠非科技所能敵. 試想一個狀況, 當你拿到一把公鑰(例如接到自稱為某個你熟知人士的電子郵件, 附上一把他的公鑰), 你怎麼知道哪把私鑰是真正在誰手裡? 公私鑰機制的假設就是持有公鑰的人可以確定那一把唯一的私鑰 一定是在那個人手裏. 但是現實生活, 網路世界, 我們真能或很容易證明這個假設嗎? 假設一旦不成立, 數位信封與數位簽章就只是白忙一場罷了..
似乎人惹出來的問題還需要人來解. 下篇主題就來討論怎樣把人,尤其是有錢, 有權, 有勢或有公信力的人拖下水的解決方案: "憑證" (Certificate).
簽章, "簽名/蓋章", 基本上就是早期用來"證明某人身分", 進而認定某些東西的"有效性". 舉例來說, 文件/信件的署名, 合約上的簽名/蓋章 ... 但以簽章方式來證明文件或合約的有效性通常會衍生另一個問題, 也就是"完整性"或是文件或合約內容是否會遭到"竄改"的問題. 例如通常簽章都在"最後一頁", 前幾頁的內容有可能遭有心人士抽換以獲取不當利益. 所以我們常會看到有所謂的"騎縫章",用來蓋在夾頁上, 以確保內容的完整性.
所以, 用"數位方式"做成的"簽名蓋章", 當然要能達到證明某人身分與確保資料的完整性.
在討論實際做法之前, 我們來看看一個非對稱密碼學裏一個重要的部分 "Hash", 也就是有些朋友在修資料結構課時碰到的Hash.
Hash基本上是一種方法, 把大量資料內容消化然後產生一個"固定長度"的結果資料. 固定長度的結果資料比起原始資料通常小的多. 好的Hash演算法基本上可確保不同內容的資料會產生不同的Hash結果. 所以這個固定長度的結果資料又稱為 "fingerprint" 或 "digest". 也就是說, 對於兩分數百頁的文件(當然是頁數一樣, 或看起來一樣), 要確認兩份文件是否真正相同, 一種方式就是逐頁逐字比對, 另一種更有效的方式就是比對這兩份文件的fingerprints(Hash結果).
在製作數位簽章時就用到了Hash. MD5與SHA-1是比較常見用於數位簽章的Hash演算法. 製作數位簽章的步驟為: 1. 將欲被簽署之資料(如文件或合約)以選定之Hash演算法產生fingerprint. 2. 將產生之fingerpint用簽屬人之私鑰加密 (由於fingerprint很小, 用非對稱演算法加密沒問題) 3. 將以私鑰加密後的fingerprint加上其他輔助資訊, 如演算法名稱, 合成所謂的數位簽章.
因此簽署人可以把資料(文件或合約)以明碼的方式傳給其他人. 其他人可用簽署人之"公鑰", 先把數位簽章裏頭那一個用簽署人"私鑰"加密的fingerprint還原. 再用數位簽章內指定的Hash演算法, 為資料(文件或合約)重新產生fingerprint. 將兩個fingerprints比對, 即可知道文件被竄改與否.
聽起來前輩們的心血終於為我們建立了完美世界! 但是我們很快就發現, 人心之邪惡遠非科技所能敵. 試想一個狀況, 當你拿到一把公鑰(例如接到自稱為某個你熟知人士的電子郵件, 附上一把他的公鑰), 你怎麼知道哪把私鑰是真正在誰手裡? 公私鑰機制的假設就是持有公鑰的人可以確定那一把唯一的私鑰 一定是在那個人手裏. 但是現實生活, 網路世界, 我們真能或很容易證明這個假設嗎? 假設一旦不成立, 數位信封與數位簽章就只是白忙一場罷了..
似乎人惹出來的問題還需要人來解. 下篇主題就來討論怎樣把人,尤其是有錢, 有權, 有勢或有公信力的人拖下水的解決方案: "憑證" (Certificate).
數位信封: 改良版的悄悄話
此篇假設您對密碼學的一些術語已有基本的認識, 若您時間有限急於進入主題, 不妨閱讀上篇"密碼學閒話 ".
數位信封. 顧名思義就是想把信放到信封裡, 沒打開信封就看不見信的內容. 而誰能拆信封? 以道德觀點而言, 自然是信封的收信人, 但是數位的世界, 靠道德大概是不太夠.
簡單來說, 數位信封運作方式是: 1. 以隨機方式產生一對稱性鑰匙(symmetric key). 2. 以此對稱性鑰匙加密資訊主體(文件 信件..). 3. 以收信人之公鑰(非對稱性)加密這把加密文件或信件的鑰匙(對稱性). 4. 將加密的信件與鑰匙寄給收信人.
所以收信人只需用自己的私鑰即可還原那一把用來解密文件的鑰匙, 進而把文件解密. 而這個動作是其他人無法做到的.
簡言之, 數位信封以"對稱性"(symmetric)密碼學來解決公/私鑰機制在加密資料時長度的限制與加密後的資料長度會爆增的問題.
數位信封. 顧名思義就是想把信放到信封裡, 沒打開信封就看不見信的內容. 而誰能拆信封? 以道德觀點而言, 自然是信封的收信人, 但是數位的世界, 靠道德大概是不太夠.
簡單來說, 數位信封運作方式是: 1. 以隨機方式產生一對稱性鑰匙(symmetric key). 2. 以此對稱性鑰匙加密資訊主體(文件 信件..). 3. 以收信人之公鑰(非對稱性)加密這把加密文件或信件的鑰匙(對稱性). 4. 將加密的信件與鑰匙寄給收信人.
所以收信人只需用自己的私鑰即可還原那一把用來解密文件的鑰匙, 進而把文件解密. 而這個動作是其他人無法做到的.
簡言之, 數位信封以"對稱性"(symmetric)密碼學來解決公/私鑰機制在加密資料時長度的限制與加密後的資料長度會爆增的問題.
2009年7月13日 星期一
密碼學閒話
在上篇"公/私鑰(Public/Private Key)的原始用途"中提到了"悄悄話"與"以個人身分發布訊息"兩大類應用, 也提到了一點公/私鑰的先天限制, 現在就讓我們分享前輩們如何解決這些限制.
在進入解決方法之前, 我們先來看看(或回憶)一些密碼學基本的觀念與術語.
密碼學(cryptography), 簡單來說是種數學, 而且是很難的數學. 目的是把 "明碼"(Clear text, 原始資料)轉換成 "密碼"(cipher, 無法辨識的資料) 或是把密碼轉換成明碼. 明碼轉換成密碼的過程叫 "加密"(encrypt). 密碼轉換成明碼的過程叫 "解密"(decrypt).
加解密(encrypt/decrypt)是一套設計出來的數學運算, 基本上利用一個或一組"數字"(number) 把明碼轉換成密碼, 或是把密碼轉換成明碼. 這個或這組"數字", 通稱鑰匙 (Key). 原始的想法大概就是把加密想像成把東西"鎖起來"(lock), 而解密想像成把鎖住的東西"解開"(unlock). 以早期或現實社會常見的鎖來看, 鎖住與解開這兩個動作, 自然是要靠鑰匙.
密碼學裏的鑰匙 (Key)猶如雄性社會裏的雄性象徵: 長度很重要 (如武俠小說裡常說: "一寸長, 一寸強"), 與安全的程度成正比. 這裡的長度指的是位元數(number of bits) 越長 (例如 32bits), 就表示當作鑰匙數字的選擇性越多(0~2^32 - 1), 相對被猜中的機率就越小. 所以就不難理解很多公司會很驕傲的強調他們的安全方案比別人的長 (TrustView當初就宣稱自己是業界最長: AES 256 bits, 比Authentica長一倍, Donald: 嘿嘿嘿....).
密碼學可分為兩大類: "對稱性"(symmetric)與"非對稱性"(asymmetric).
對稱性密碼學, 簡單來說就是開鎖(加密)與解鎖(解密)都用同一把鑰匙, 故稱對稱(symmetric).
而非對稱性密碼學之前在PKI 妙喻 & "向左, 向右, 向前看" 提過了, 就是公鑰/私鑰的機制. 因為加解密用不同的鑰匙, 故稱非對稱.
對稱性密碼學起源很早, 常見的 DES, 3-DES都屬此類. 以技術的角度而言, 比起非對稱性密碼學這個後起之秀, 其實是有很多優勢. 但是對於電子交易時所需要的兩大特性: "悄悄話"(私密的資料傳輸)與 "以個人身分發布訊息"(確認資料之來源), 就面臨了實際上困難.
首先是Key的數量. 為達到悄悄話的效果, N個人需要有N*(N-1) / 2 把鑰匙. 比起非對公鑰/私鑰的機制僅需 N* 2把, 如何分發和保管鑰匙(確定每個人只能拿到他可以用的鑰匙)相形麻煩.
另外, 對於以鑰匙來證明持有人身分而言, 因為加解密都是同一把鑰匙, 更是無解. 且不說要以個人名義發布訊息須要加密N-1 次這麼麻煩, 更要命的, 同一把鑰匙由兩個人持有, 如何能證明唯一性?
然而對稱性的優點恰巧可彌補公鑰/私鑰的缺點: 1. 加密的資料有長度限制 2. 加密後的資料長度會超越線性成長(爆增). 所以前輩們就巧妙的將這兩種加密截長補短, 因此有了下兩個主題: "數位信封(Digital Envelop)" 與 "數位簽章(Digital Signature)"
在進入解決方法之前, 我們先來看看(或回憶)一些密碼學基本的觀念與術語.
密碼學(cryptography), 簡單來說是種數學, 而且是很難的數學. 目的是把 "明碼"(Clear text, 原始資料)轉換成 "密碼"(cipher, 無法辨識的資料) 或是把密碼轉換成明碼. 明碼轉換成密碼的過程叫 "加密"(encrypt). 密碼轉換成明碼的過程叫 "解密"(decrypt).
加解密(encrypt/decrypt)是一套設計出來的數學運算, 基本上利用一個或一組"數字"(number) 把明碼轉換成密碼, 或是把密碼轉換成明碼. 這個或這組"數字", 通稱鑰匙 (Key). 原始的想法大概就是把加密想像成把東西"鎖起來"(lock), 而解密想像成把鎖住的東西"解開"(unlock). 以早期或現實社會常見的鎖來看, 鎖住與解開這兩個動作, 自然是要靠鑰匙.
密碼學裏的鑰匙 (Key)猶如雄性社會裏的雄性象徵: 長度很重要 (如武俠小說裡常說: "一寸長, 一寸強"), 與安全的程度成正比. 這裡的長度指的是位元數(number of bits) 越長 (例如 32bits), 就表示當作鑰匙數字的選擇性越多(0~2^32 - 1), 相對被猜中的機率就越小. 所以就不難理解很多公司會很驕傲的強調他們的安全方案比別人的長 (TrustView當初就宣稱自己是業界最長: AES 256 bits, 比Authentica長一倍, Donald: 嘿嘿嘿....).
密碼學可分為兩大類: "對稱性"(symmetric)與"非對稱性"(asymmetric).
對稱性密碼學, 簡單來說就是開鎖(加密)與解鎖(解密)都用同一把鑰匙, 故稱對稱(symmetric).
而非對稱性密碼學之前在PKI 妙喻 & "向左, 向右, 向前看" 提過了, 就是公鑰/私鑰的機制. 因為加解密用不同的鑰匙, 故稱非對稱.
對稱性密碼學起源很早, 常見的 DES, 3-DES都屬此類. 以技術的角度而言, 比起非對稱性密碼學這個後起之秀, 其實是有很多優勢. 但是對於電子交易時所需要的兩大特性: "悄悄話"(私密的資料傳輸)與 "以個人身分發布訊息"(確認資料之來源), 就面臨了實際上困難.
首先是Key的數量. 為達到悄悄話的效果, N個人需要有N*(N-1) / 2 把鑰匙. 比起非對公鑰/私鑰的機制僅需 N* 2把, 如何分發和保管鑰匙(確定每個人只能拿到他可以用的鑰匙)相形麻煩.
另外, 對於以鑰匙來證明持有人身分而言, 因為加解密都是同一把鑰匙, 更是無解. 且不說要以個人名義發布訊息須要加密N-1 次這麼麻煩, 更要命的, 同一把鑰匙由兩個人持有, 如何能證明唯一性?
然而對稱性的優點恰巧可彌補公鑰/私鑰的缺點: 1. 加密的資料有長度限制 2. 加密後的資料長度會超越線性成長(爆增). 所以前輩們就巧妙的將這兩種加密截長補短, 因此有了下兩個主題: "數位信封(Digital Envelop)" 與 "數位簽章(Digital Signature)"
公/私鑰(Public/Private Key)的原始用途
之前在PKI 妙喻 & "向左, 向右, 向前看"一文用一個簡單的比喻介紹了PKI的重要特性, 並以一知名電影作Use Case, 演練了一下公/私鑰(Public/Private Key)的使用. 不過那個Use Case只是以笑謔的方式讓初次接觸PKI的朋友加深印象, 不要太當真 (尤其那些支持金先生的影迷不要因此來找我麻煩).
總之先記住: 1. 公/私鑰為密碼學之一支, 且為PKI(Public Key Infrastructure) 之基礎. 2. 公鑰與私鑰必為"成對產生", 私鑰顧名思義為個人私有的鑰匙, 所以僅能由一人持有, 或可想像為證明某人身分之信物. 公鑰則有公開, 公物之意, 用以廣為散佈. 3. 公私鑰皆可用於加解密, 但是私鑰加密的僅有成對的公鑰可解, 公鑰加密的也僅有成對的私鑰可解.
公/私鑰的用途很廣泛, 例如購物網站常使用之"https"(SSL)通訊協定即為常見之應用實例. 如果我們略去應用的領域, 對象, 行業...等等因素, 回歸本質面, 我們其實可以將公/私鑰的主要用途區分為二: 1. 悄悄話 2. 以個人身分發布訊息.
總之先記住: 1. 公/私鑰為密碼學之一支, 且為PKI(Public Key Infrastructure) 之基礎. 2. 公鑰與私鑰必為"成對產生", 私鑰顧名思義為個人私有的鑰匙, 所以僅能由一人持有, 或可想像為證明某人身分之信物. 公鑰則有公開, 公物之意, 用以廣為散佈. 3. 公私鑰皆可用於加解密, 但是私鑰加密的僅有成對的公鑰可解, 公鑰加密的也僅有成對的私鑰可解.
公/私鑰的用途很廣泛, 例如購物網站常使用之"https"(SSL)通訊協定即為常見之應用實例. 如果我們略去應用的領域, 對象, 行業...等等因素, 回歸本質面, 我們其實可以將公/私鑰的主要用途區分為二: 1. 悄悄話 2. 以個人身分發布訊息.
所謂悄悄話的意思, 就是不希望別人聽到. 回想一下公/私鑰的特性: "公鑰加密過的資訊, 只有私鑰才解的開". 而誰擁有私鑰呢? 所以, 如果你希望某人給你的訊息不被他人知道, 你只須要要求那人將訊息用你的公鑰加密, 即使其他人也擁有你的公鑰也沒用. 因為公鑰加密的東西僅有成對的私鑰可解, 而只有你擁有這把私鑰.
悄悄話的相反, 大概就是像"大聲公"或"廣播電台"--> 唯恐天下不知! 而更重要的是要讓大家知道是"誰說的". 如果你想以個人身分發布訊息, 而且讓大家知道那是你發的, 最簡單的方法就是把你要發布的訊息, 用你自己的的私鑰加密起來, 再廣為傳遞. 那些擁有你公鑰的人自然解的開, 若解不開那就一定不是你用私鑰加密的東西. 我們也可藉此體會私鑰 --> "見鑰如見人"的設計理念.
在我們把PKI, 公私鑰..背後複雜的演算法理論與實做先撇開後, 試著從設計的源頭或目的去了解, 其實這些東西還是有和藹可親, 很生活化的一面. 不過看倌也先別太爽, 以為PKI或公私鑰就這麼點料, 其實故事來多著呢!
首先比起早期密碼學加密解密都用同一把鑰匙, 公私鑰看來很完美了, 但是它也有先天上的缺陷, 其中有兩個蠻要命的. 首先, 公私鑰的演算法通常在加密的資料有長度限制. 也就是說,一旦超過限制, 加密可能會失敗. 另外, 原始資料長度越大 ,加密後的資料長度會超越線性成長. 簡單來說, 假設原始資料長度為a, 加密後長度為b. 當原始資料長度為2a, 加密後長度可能會暴升為4b, 也就是一個上揚的曲線. 在實際應用上這兩點絕對不是好消息. 因此我們可以想像, 不管是悄悄話也好, 發布消息也好, 一定得解決這些問題.
下一篇會談到公私鑰在實際應用時如何克服先天的弱點, 並同時帶出兩個主題: 數位信封 (Digital Evelope) 與 數位簽章 ("Digital Signature").
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來做對照說明.
2009年7月10日 星期五
淺論DRM (Digital Right Management)
關於DRM (Digital Rights Management), 讓我們試著撇開學術上囉嗦的定義或各廠商璀璨的商業語言. 我試著用我看過,經歷過...最後消化過的: "平民式"或是"口語化的" 語言來介紹這個東西.
何謂Digital Rights? 我們先從 "Digital Content" 來看: 例如我們每天工作接觸到的各種格式(formats) 的電子檔案. 對許多人而言, 紙本形式的檔案可能只是一個回憶了. 一提到"檔案" 只怕大部分人聯想到的都是一個個像商業文書用的 MS-Office Word, Excel, Powerpoint, 娛樂用的 MPegJPeg..等等, 也就是所謂的 "電子檔". 有人質疑"電子檔"(Electrical file) 從一開始就把觀念侷限於既有的材料與技術, 所以有人重新用 "Digital Content" 來代表任何以數位形式(0/1)把"含有內容的東西"(例如紙本的書, 古早時音樂膠片,錄音帶 Beta/VHS..)記錄下來的部分. 所以 "Digital Rights" 其實就是強調 "rights on digital content".
"Digital Right" 讓我聯想到一個笑話. 以前有一個卡通叫"Bevis & Butthead". 有一回"Butthead"看到女權運動者身上T-Shirt印的標語 "Woman's Right Now!". 這老兄直接理解為 "Woman Right-now", 結果當然是被海扁.
至於 "DRM" 呢? 有人說現在是強調管理的時代, 什麼話題都有人扯上管理. 所以搞個Digital Right Management 也不用太奇怪.
DRM真的是新觀念嗎? 見仁見智吧? 至少, 我不這麼認為. 例如任何數位系統上針對哪些使用者可以閱讀或修該哪些檔案, 我覺得這就叫DRM了! 因為,三個字都包含到了... 問題只是做得 "好不好" 或 "夠不夠" 的問題.
早期的前輩們覺得對於像檔案這類的數位內容, 能約束使用者 "讀取" 或 "修改"就差不多了, 了不起再從"修改"這項上衍生出建立與刪除大概就很夠了. 但是以現今世界步調之速, 商業模式之複雜, 從前的想法拿到現在就不一定合適. 例如, 光是 "閱讀" 這一項, 就有人希望要能加上 "閱讀期限" 或是 "閱讀次數". 或者是僅能在"某些地方"(例如某些特定的電腦或裝置上). 至於能 "看" 是不是就代表能 "印" (包含螢幕列印與擷取) ? 另外, 許多人可能僅對部分章節有興趣. 那麼, 是否准許他用 "選取-複製-貼上"(select-copy-paste)將部分內容帶走? 以上所列, 皆凸顯了從前定義數位權限的方式 過於狹隘, 無法滿足現今多元的商業模式與需求.
另外, 在網路與各儲存裝置不發達的年代, 作業系統對於檔案提供之權限管理或許堪用. 但是當一個檔案 "離開"(當然是被帶走囉...)那個約束他的系統, 而到了另一個系統. 原先系統對它是否仍有約束力? 答案絕對是"否".
所以我認為DRM不是新觀念, 也應該還是電腦安全領域的一部分(甚至只是一小部分). 但改名換姓後主要是要強調兩個重點: 1. 更細緻的權限種類 (如閱讀期限, 次數, 列印, 複製...). 2. 數位內容的使用權限控管, 不因所在位置(如企業內部系統 或企業之外某競爭對手的個人電腦)而有所不同.
何謂Digital Rights? 我們先從 "Digital Content" 來看: 例如我們每天工作接觸到的各種格式(formats) 的電子檔案. 對許多人而言, 紙本形式的檔案可能只是一個回憶了. 一提到"檔案" 只怕大部分人聯想到的都是一個個像商業文書用的 MS-Office Word, Excel, Powerpoint, 娛樂用的 MPegJPeg..等等, 也就是所謂的 "電子檔". 有人質疑"電子檔"(Electrical file) 從一開始就把觀念侷限於既有的材料與技術, 所以有人重新用 "Digital Content" 來代表任何以數位形式(0/1)把"含有內容的東西"(例如紙本的書, 古早時音樂膠片,錄音帶 Beta/VHS..)記錄下來的部分. 所以 "Digital Rights" 其實就是強調 "rights on digital content".
"Digital Right" 讓我聯想到一個笑話. 以前有一個卡通叫"Bevis & Butthead". 有一回"Butthead"看到女權運動者身上T-Shirt印的標語 "Woman's Right Now!". 這老兄直接理解為 "Woman Right-now", 結果當然是被海扁.
至於 "DRM" 呢? 有人說現在是強調管理的時代, 什麼話題都有人扯上管理. 所以搞個Digital Right Management 也不用太奇怪.
DRM真的是新觀念嗎? 見仁見智吧? 至少, 我不這麼認為. 例如任何數位系統上針對哪些使用者可以閱讀或修該哪些檔案, 我覺得這就叫DRM了! 因為,三個字都包含到了... 問題只是做得 "好不好" 或 "夠不夠" 的問題.
早期的前輩們覺得對於像檔案這類的數位內容, 能約束使用者 "讀取" 或 "修改"就差不多了, 了不起再從"修改"這項上衍生出建立與刪除大概就很夠了. 但是以現今世界步調之速, 商業模式之複雜, 從前的想法拿到現在就不一定合適. 例如, 光是 "閱讀" 這一項, 就有人希望要能加上 "閱讀期限" 或是 "閱讀次數". 或者是僅能在"某些地方"(例如某些特定的電腦或裝置上). 至於能 "看" 是不是就代表能 "印" (包含螢幕列印與擷取) ? 另外, 許多人可能僅對部分章節有興趣. 那麼, 是否准許他用 "選取-複製-貼上"(select-copy-paste)將部分內容帶走? 以上所列, 皆凸顯了從前定義數位權限的方式 過於狹隘, 無法滿足現今多元的商業模式與需求.
另外, 在網路與各儲存裝置不發達的年代, 作業系統對於檔案提供之權限管理或許堪用. 但是當一個檔案 "離開"(當然是被帶走囉...)那個約束他的系統, 而到了另一個系統. 原先系統對它是否仍有約束力? 答案絕對是"否".
所以我認為DRM不是新觀念, 也應該還是電腦安全領域的一部分(甚至只是一小部分). 但改名換姓後主要是要強調兩個重點: 1. 更細緻的權限種類 (如閱讀期限, 次數, 列印, 複製...). 2. 數位內容的使用權限控管, 不因所在位置(如企業內部系統 或企業之外某競爭對手的個人電腦)而有所不同.
2009年7月7日 星期二
好書推薦: PKI: Implementing and Managing E-Security
對於PKI(Public Key Infrastructure)這個主題, 個人非常喜歡一本書: PKI: Implementing and Managing E-Security (McGraw-Hill出版). 本人之前在TrustView服務時曾擷取前三章內容製作 "PKI簡介" 作為新人與合作夥伴(中科院某單位)的入門教材. 蒙中科院的朋友謬讚認為這是他們聽過最好的一次PKI的課程. 唉... 借花獻佛, 有騙吃騙喝之嫌.
"PKI: Implementing and Managing E-Security" 這本書講的東西不算少. 可惜即使以前在TrustView 時也沒全看完. 但是我非常推薦大家有空至少看看前三章. 以作者深入淺出的風格, 相信不會花你太多時間, 即能獲得對 PKI 相當深度的了解. 尤其是前一陣子聽說"個人資料保護法"即將通過三讀, 相信各資安廠商現必摩拳擦掌中. 各位從事IT的朋友, 或許過一陣子就會開始被老闆要求評估資安方案, 或甚至被資安廠商包圍, 競相說服您他家的方案有多優... 所以這本書相信在工作上是個不錯的投資.
"PKI: Implementing and Managing E-Security" 這本書講的東西不算少. 可惜即使以前在TrustView 時也沒全看完. 但是我非常推薦大家有空至少看看前三章. 以作者深入淺出的風格, 相信不會花你太多時間, 即能獲得對 PKI 相當深度的了解. 尤其是前一陣子聽說"個人資料保護法"即將通過三讀, 相信各資安廠商現必摩拳擦掌中. 各位從事IT的朋友, 或許過一陣子就會開始被老闆要求評估資安方案, 或甚至被資安廠商包圍, 競相說服您他家的方案有多優... 所以這本書相信在工作上是個不錯的投資.
有關"只能有一個Background Server"的疑點
Background真的只能有一個嗎? 查過幾份文件與菜鳥時上過的Performance Tuning講義, 這個問題的確解釋不清楚, 甚至答案是衝突的. 但是當我試著從"什麼是Background Server?" 與 "為什麼需要Background Server?" 這個兩點先探索起. 我開始覺得Background server應該是可以多個. Why? 我們可透過Performance Tuning中提到透過設定多個Method Server 以善用硬體效能的章節來探究.
首先, 對測試或開發環境而言, 一個Method Server是最常見的, 因為資源通常不如Production來的充足. 例如, 測試或開發環境的RAM通常有個4G可能就偷笑了, 上面又要裝一個更兇的Oracle, 能分給一個Method Server 1.5G的RAM通常就不錯了. 但是, Production則不然! 一來, RAM可能更多. 二來, 通常Production至少由二台機器組成: 一台負責Application, 一台負責Database. 如此一來, 只有一個Method server 是否太可惜了? 更何況, 就Albert手上的資料顯示, 好像某版本之前, Sun的Java Virtual Machine在MS Windows上, 一個JVM Process只能用到1.5G, 超過的部分就用不到. 我想, 這個血淋淋的事實大概能包含PTC在台灣九成的各戶. 所以要養頭猛虎是不可能了, 試試猴群吧...
正巧, Windchill本來就考慮了猴園的架構, ServerManager就是那個耍猴的.
Windchill 裏就有這麼個property: "wt.manager.monitor.start.MethodServer" 用以告知系統要啟動幾個MethodServer, 預設值是1. 所以我們想要2個Method Server, 自然就設成2, 依此類推. 但是有實際維護Windchill系統經驗的人早就知道不能這麼幹. 正確的說, 不能只是設這個Property.
再繼續討論之前, 我們得先了解MethodServer做些什麼? Method server 可以想成是一堆"Method"(Java Method)的集合, 以Java RMI實作, 可供遠端呼叫 , 例如透過Apache與Tomcat, 來自瀏覽器端使用者的指令. 另外, Method server還有一個重要的功能, 也就是處理Queue裡面排隊的工作: 例如工作流程的Robot, Activity裡的Transistions... 都是Method server 先將它們加到 Queue裏, 再一個個拿出來執行.
設定多個Method Servers後, 當系統處理大量來自使用者端的需求時, 效益較明顯. 但是Queue裏的工作呢? 當只有一個Method Server時, 問題不大(這是風涼話...), 因為..嘿嘿嘿...什麼都歸他! 但是, 當有兩個? 那Queue裏的工作怎麼分? 不然同一個工作都執行兩次, 那絕對不是恐怖可以形容的... 所以, 就有了Background Server這個東西. 以程式碼的角度, 它就是Method Server(一樣是由wt.method.MethodServerMain 啟動). 但是它只處理Queue, 不處理 RMI requests. 另外, 還有一個property "wt.queue.executeQueues" 用來告訴所有Method server 要不要碰Queue. 所以, 為了解決爭搶Queue裏工作的問題, 只要超過一個Method Server, wt.queue.executeQueues就須設為 "false". 這表示Queue不干MethodServer的事, 通通交給 Background Server吧!
但是Background server的設定很詭異, 首先, 要設定這個玩意兒: "wt.manager.monitor.start.BackgroundMethodServer". 與wt.manager.monitor.start.MethodServer類似, 一樣是用來表示數量, 也就是要啟動幾個Background server. 大多時候, 我們看到是 "1" 或 "0". 但是, 如果只是"有"與"沒有", "true/false"不是更妥當嗎? 兩個BackgroundServer難道就不會爭搶Queue裏的工作?
所以1或0聽來是合理的數值. 但是, 難道所有的流程與所有Queue裏的工作都須要靠一個最多不超過1.5G的JVM來拖嗎? 所以, 我們可以很合理的懷疑wt.manager.monitor.start.BackgroundMethodServer 定義成">=0"的數字是有道理的. 多個Background Servers的需求有其正當性.
在System Admin Guide 中 提到了Queue-Group的概念. 也就是說系統所有的Queues可以分成幾個群組. 系統安裝之初 所有的Queues都屬於一個叫"default"的群組. 管理員可利用定義在wt.properties中的"wt.queue.queueGroup"這個property來新增群組, 並利用設定Property: "wt.queue.(property name)=" 的方式重新分組. 但是為什麼要分組呢? 從 System Admin Guide 中有關Queue-Group語焉不詳的描述, 似乎暗示一種可能: BackgroundServer可以指定負責的Queue-Group.
wt.manager.monitor.start.BackgroundMethodServer=1
wt.queue.queueGroup.default=appsvr1
wt.queue.queueGroup=localhost
wt.queue.xxx=appsvr2
wt.queue.yyy=appsvr2
wt.queue.zzz=appsvr3
上 述設定基本上在每一台主機的wt.properties裡都是一樣. "localhost"是合法的關鍵字, 而在各台主機上用"wt.queue.queueGroup=localhost"將會產生"appsvr1, appsvr2, 與appsvr3"三個Queue-Group. 但是, 由於此範例是用在Cluster的環境, 感覺上一台機器上只能設一個Background, 真是令人沮喪! 路似乎絕了?
巧的是, 設定多個Method Server這個主題時還牽涉另一個選項: 就是為個別Method server與Background Server設定Log檔. 在尋找資料時意外發現下列屬性:
wt.manager.cmd.BackgroundMethodServer=$(wt.manager.cmd.MethodServer) wt.method.serviceName\=BackgroundMethodServer wt.queue.executeQueues\=true wt.queue.queueGroup\=default wt.adapter.enabled\=false wt.method.minPort\=3000
這個東西要讓我說, 怎麼看都像是指定Background Server負責處理"default"這個queue-group. 這彷彿是山窮水盡後的柳暗花明. 但是高興沒多久, 問題又來了!!! 當我有兩個Background Servers時, 我怎麼讓系統知道每個Background Server需要個別的啟動指令? 無法個別設定啟動指令, 我怎麼讓不同的Background Server處理不同的queue呢?
其實這是非常接近答案的一次探索. 但是萬萬沒想到會栽在一個看似無辜, 理所當然的設定: "wt.manager.monitor.services=MethodServer BackgroundMethodServer", 終究沒辦法再向前跨一步.
緣起--"Multiple Background servers"
Egg兄一直是我非常尊敬的一位前輩(不要懷疑, 名片上真的是這麼印的! 他們那還有一位"鳥"哥(Bird). 最先我還以為他們聯合起還耍我!!!). 因為他過去在軟體開發公司, 程式底子強. 而到User-Site服務後, 又開始摸索網管與Oracle. IT圈像他這種軟硬兼修的人物我猜是不多見. 當初要不是咱們"劫機"哥福至心靈, 獻計把Egg拗來PLM的專案, 然後憑借他深厚功力, 硬是把許多客製需求吸收下來. 不然, PTC當初這個案子收不收的掉, 恐怕很難說喲? 如果當初收不掉, 自然也沒有後續讓我去他那導入TrustView與Windchill整合方案. 還好有這個緣分, 敝人才可靠著TrustView與Windchill一些小伎倆騙吃騙喝, 並得Egg兄禮遇.
但是... 夜路走多總是會見鬼! Egg的恐怖, 不只在他的功力, 而在他追根究柢的研究精神. 大家很少聽說有user會去讀PTC官方的那些動輒數百頁的PDF檔吧? Egg就是那個例外!!!
David: 你是要設多個Method Server吧? 你可以參考..
Egg: 不是, Production已經設了2個Method Server 1個Background... 我是想看能不能把Background再多加一個, 看能不能讓Workflow跑快一點..
David: 不會吧? Background只能有一個呀(很有信心! 因為前輩信誓旦旦的這麼說...)!超過一個會出問題 (至於什麼問題 或許前輩有教 總之當時我也不知道會有什麼問題)!!
Egg: 可是你們"System Admin Guide"上有說可以多個?
David: 是嗎(驚嚇)!!! 大概...是新功能吧... 不過有可能PTC不建議這樣用??? (開始硬拗)
Egg:照Guide上說... 好像要分組, 把"Queue"分組(咦? 好像有點印象! 曾經瞄過...), 但是上面寫的看不太懂
David: 唉... 是這樣的! 既然有寫, 應該是有(放棄抵抗)...不過, 手冊通常都模模糊糊(引用某前輩的說法: 幹! 這才是正常的), 有時還有版本的問題... 這樣好了, 我找時間研究看看(見風轉舵中)...
總之, 這是我第一次感受Egg的可怕, 也是催生這個主題的真正原因.
但是... 夜路走多總是會見鬼! Egg的恐怖, 不只在他的功力, 而在他追根究柢的研究精神. 大家很少聽說有user會去讀PTC官方的那些動輒數百頁的PDF檔吧? Egg就是那個例外!!!
剛認識的那幾個月, 勉強靠著過去幾個專案的經驗與PTC兄弟的無私分享, 對於Egg提出的問題還勉強達的上來. 誰想到某一天, 接到蛋兄電話, 內容大概是:
Egg: David啊? 我想設定多個Background Server, 那要怎麼弄?David: 你是要設多個Method Server吧? 你可以參考..
Egg: 不是, Production已經設了2個Method Server 1個Background... 我是想看能不能把Background再多加一個, 看能不能讓Workflow跑快一點..
David: 不會吧? Background只能有一個呀(很有信心! 因為前輩信誓旦旦的這麼說...)!超過一個會出問題 (至於什麼問題 或許前輩有教 總之當時我也不知道會有什麼問題)!!
Egg: 可是你們"System Admin Guide"上有說可以多個?
David: 是嗎(驚嚇)!!! 大概...是新功能吧... 不過有可能PTC不建議這樣用??? (開始硬拗)
Egg:照Guide上說... 好像要分組, 把"Queue"分組(咦? 好像有點印象! 曾經瞄過...), 但是上面寫的看不太懂
David: 唉... 是這樣的! 既然有寫, 應該是有(放棄抵抗)...不過, 手冊通常都模模糊糊(引用某前輩的說法: 幹! 這才是正常的), 有時還有版本的問題... 這樣好了, 我找時間研究看看(見風轉舵中)...
總之, 這是我第一次感受Egg的可怕, 也是催生這個主題的真正原因.
2009年7月6日 星期一
積非成是: "Multiple Background servers"
故老相傳: "Background只能有一個". 我猜, 大部分的顧問都會這麼說. 要不是蛋兄(詳見緣起), 我現在一定還是這麼說. 去年就想寫這個主題, 但知道很花力氣, 所以一直逃避. 然而心裡一直有個疙瘩 . 最後想想畢竟這是個有意義的主題, 終究是寫了.
真相之路蠻曲折的! 至少第一次探索從Egg問起的"Queue-Group"與System Admin Guide裏語焉不詳的暗示多個Background的可能性, 演變到從頭反思Method Sever與Background Server的定義與目的... 幾乎是要發掘真相. 可惜忽略了一個重要線索, 追到後來還是失敗了. 儘管如此, 我覺得這個探詢的過程蠻有趣的, 或許也能延伸出一些討論. 所以把他記在另一篇"有關"只能有一個Background Server"的疑點".
直到去年準備PDMLink9.0 System Admin的教育訓練時, 順便研讀Advanced Deployment Guide. 那時才發現, 此文件裏居然對多個Background Servers的設定有詳細的解釋 (韋爵爺: ㄉ...ㄉ償所望..). 細讀之後. 更覺得其中的設定方法及可能也適用之前的版本. 因此以PDMLink8做測試, 終於證實多個Background Server是可能的.
進入此主題之前請先參閱設定多個Method Server的相關文件或是參考"有關"只能有一個Background Server"的疑點"也可.
建立一個新的Queue名為"david_01", 隸屬於 "david"這個 queue-group. 另外寫了個小程式塞了個工作進去, 每隔十分鐘會印出"Hello!". 如上面的設定, 所有"david"群組的Queues都是由BackgroundMethodServer_1管的. 果然過一會 "Hello" 出現在這.
真相之路蠻曲折的! 至少第一次探索從Egg問起的"Queue-Group"與System Admin Guide裏語焉不詳的暗示多個Background的可能性, 演變到從頭反思Method Sever與Background Server的定義與目的... 幾乎是要發掘真相. 可惜忽略了一個重要線索, 追到後來還是失敗了. 儘管如此, 我覺得這個探詢的過程蠻有趣的, 或許也能延伸出一些討論. 所以把他記在另一篇"有關"只能有一個Background Server"的疑點".
直到去年準備PDMLink9.0 System Admin的教育訓練時, 順便研讀Advanced Deployment Guide. 那時才發現, 此文件裏居然對多個Background Servers的設定有詳細的解釋 (韋爵爺: ㄉ...ㄉ償所望..). 細讀之後. 更覺得其中的設定方法及可能也適用之前的版本. 因此以PDMLink8做測試, 終於證實多個Background Server是可能的.
進入此主題之前請先參閱設定多個Method Server的相關文件或是參考"有關"只能有一個Background Server"的疑點"也可.
Advanced Deployment Guide中有關設定多個Background Servers的介紹節錄如下:
首先是有關啟動Background Server的命令設定, 也就是上次探尋的終點. 簡單來說, 能針對個別Background Server設定啟動命令, 就能夠指定該Background Server負責的Queues. 如此就有機會避開重複執行Queue中工作的問題. 這次文件交代得很清楚: 每個Background Server須要有個自己的名字(Service Name), 啟動指令就是利用這個名字來定義. 格式為: "wt.manager.cmd.(service name)
wt.manager.cmd.
上述的(Method server's Java command)
以名為"BackgroundMethodServer_0"的Background server為例, 設定如下:
wt.manager.cmd.BackgroundMethodServer_0=$(wt.manager.cmd.MethodServer) wt.method.serviceName\=BackgroundMethodServer_0 wt.queue.executeQueues\=true wt.queue.queueGroup\=default wt.adapter.enabled\=false wt.method.minPort\=3000
看來很完美? 故事還沒完!
試想, 系統怎麼知道有兩個Background Server分別叫作"BackgroundMethodServer_0" 與" BackgroundMethodServer_1"? "wt.manager.monitor.start.BackgroundMethodServer=2" 僅僅讓系統知道需要啟動兩個Background Servers, 並沒有透露其他訊息. 從Advanced deployment guide 中的範例發現 他的"wt.manager.monitor.services"是這麼設的:
wt.manager.monitor.services=MethodServer BackgroundMethodServer_0 BackgroundMethodServer_1
原來如此, "MethodServer", "BackgroundMethodServer_0", "BackgroundMethodServer_1"都是"(service name)
以下是我在PDMLink 8上進行測試時的一些畫面:
wt.properties新增的設定
以下為開機後的畫面: 除了Method sever正常啟動外, 真的跑出兩個Background servers.
BackgroundMethodServer_0: Listening port: 3000
建立一個新的Queue名為"david_01", 隸屬於 "david"這個 queue-group. 另外寫了個小程式塞了個工作進去, 每隔十分鐘會印出"Hello!". 如上面的設定, 所有"david"群組的Queues都是由BackgroundMethodServer_1管的. 果然過一會 "Hello" 出現在這.
嘿... 真的耶!
2009年7月4日 星期六
PKI 妙喻 & "向左, 向右, 向前看"
有一回應朋友之邀介紹PKI (Public Key Infrastructure) 之前, 先上狐狗大仙(Google) 那兒晃晃, 看看有沒有善心人士分享, 先頂來用用... 當時找到了一份, 但是章節的結構與描述方式不是很喜歡, 真正採用的部分不多. 但是那份投影片對PKI中公鑰與私鑰(Public & Private Keys)的比喻一直讓我印象深刻, 甚至認為這是目前我聽過最淺顯易懂的比喻. 原文早沒了! 不過因為比喻的妙, 我相信我轉述之後效果也不會太差才是.
那個比喻大概是這麼說的: 既然大家已習慣把密碼學中用來加密解密的關鍵物"Key"具體的想像為日常生活中用來開鎖解鎖的"鑰匙", 所以我們不妨把PKI想像成是一種"特別的鎖". 這種鎖, 有兩把鑰匙: 一把永遠把鎖頭往左轉, 一把則往右轉. 因此用"向左轉"的鑰匙鎖定後, 只能靠"向右轉"的鑰匙把它解鎖. 同理, 向右轉"的鑰匙一樣可以鎖定, 但是得靠"向左轉"的鑰匙解鎖.
要是有人無聊到要研究這把鎖怎麼做的, 或許可想像這個鎖裡面有個拴子, 拴子可左右旋轉. 栓子在正中標示"解開"的狀態, 栓子在左或右都是"鎖定"狀態, 一把鑰匙插入僅可轉左, 另一把也可轉右...喂!!! 醒醒啊! 不要那麼仔細好嗎? 這左轉右轉只是個比喻....
這把鎖怎麼用呢? 一般來說是這麼用的. 鎖的"主人", 擁有其中一把鑰匙, 因為大部分的人是右撇, 所以"向右轉"那一把鑰匙由主人保管. 這就是"PR"的由來, "R" stands for "Right"(這一句是本人唬爛, 笑笑就算... 還蠻像那麼一回事的吧? PR其實是"Private Key(私鑰)"的簡稱) OK, 假設主人持有"向右轉"的鑰匙, 並將向"向左轉"的鑰匙打造"多個備份", 分送給"客人". 主人鎖上的(用"向右轉"的鑰匙), 客人打的開. 主人呢? 用自己那一把"向右轉"的鑰匙一定解不開, 但是一般沒有那麼笨的主人, 留一把給客人的備份不就得了嗎? 但是客人鎖住的只有主人才能開了, 任何客人都開不了!
所以各位發現兩把鑰匙的作用與鎖的功能其實不難了解, 但是要怎麼用呢? 整人... 不會吧? 但是, 現實生活中您看過這種門嗎?
前幾天聽見電視傳來孫燕姿的"遇見"("向左走向右走"), 突然讓我參透幾個PKI不錯的"Use Cases".
假設"金先生"為他的房間安裝了PKI鎖, 自己當然"左/右轉"兩把鑰匙都有囉! 對那位一直好事多磨的真命天女"梁小姐", 當然是要送一把"向左走", Sorry, 更正, "向左轉"的鑰匙囉? 沒事可以請她在金先生出差時去打掃房間, 澆澆花, 餵餵小動物...臨走在再把門鎖上. 所以金先生鎖門, 梁小姐可開. 梁小姐鎖門, 金先生也可開, 幸福吧?
至於"關小姐", 要嘛之前金先生就給了她一把"向左轉"(可能性極高...), 或者事後金先生覺得不好意思或是懷念關小姐的身材(後者可能性比較大...). 然後再打了一把給她.... 日後要是約關小姐到房間獨處時, 也不用怕梁小姐突然闖入... 只要用關小姐那一把, 或自己留的那一把"向左轉的鑰匙鎖門就好了唄? 關小姐鎖的, 梁小姐開不開, 反之亦然.
摩亞大人: 這就是"左右逢源"嗎?
其實, 本文只是為我接下來想寫的一些有關DRM與TrustView方面文章做做暖身, 讓大家對一些望之生畏的名詞減少一些恐懼感. 以上所提, 不過就是些比喻.. 千萬不要太當真, 例如, 不要問我ㄧ些: "梁小姐要是忘了關瓦斯就鎖門離開怎麼辦?" 或是,"梁小姐一進房間就把門反鎖, 等金先生一個月後出差回來剩乾屍一具"...等等奇怪的問題. 就算真正發生了, 我們也只能說誰叫金先生存心不良! 造成悲劇也只能說活該應得, 順便還有些警世的味道. 關PKI鳥事?
那個比喻大概是這麼說的: 既然大家已習慣把密碼學中用來加密解密的關鍵物"Key"具體的想像為日常生活中用來開鎖解鎖的"鑰匙", 所以我們不妨把PKI想像成是一種"特別的鎖". 這種鎖, 有兩把鑰匙: 一把永遠把鎖頭往左轉, 一把則往右轉. 因此用"向左轉"的鑰匙鎖定後, 只能靠"向右轉"的鑰匙把它解鎖. 同理, 向右轉"的鑰匙一樣可以鎖定, 但是得靠"向左轉"的鑰匙解鎖.
要是有人無聊到要研究這把鎖怎麼做的, 或許可想像這個鎖裡面有個拴子, 拴子可左右旋轉. 栓子在正中標示"解開"的狀態, 栓子在左或右都是"鎖定"狀態, 一把鑰匙插入僅可轉左, 另一把也可轉右...喂!!! 醒醒啊! 不要那麼仔細好嗎? 這左轉右轉只是個比喻....
這把鎖怎麼用呢? 一般來說是這麼用的. 鎖的"主人", 擁有其中一把鑰匙, 因為大部分的人是右撇, 所以"向右轉"那一把鑰匙由主人保管. 這就是"PR"的由來, "R" stands for "Right"(這一句是本人唬爛, 笑笑就算... 還蠻像那麼一回事的吧? PR其實是"Private Key(私鑰)"的簡稱) OK, 假設主人持有"向右轉"的鑰匙, 並將向"向左轉"的鑰匙打造"多個備份", 分送給"客人". 主人鎖上的(用"向右轉"的鑰匙), 客人打的開. 主人呢? 用自己那一把"向右轉"的鑰匙一定解不開, 但是一般沒有那麼笨的主人, 留一把給客人的備份不就得了嗎? 但是客人鎖住的只有主人才能開了, 任何客人都開不了!
所以各位發現兩把鑰匙的作用與鎖的功能其實不難了解, 但是要怎麼用呢? 整人... 不會吧? 但是, 現實生活中您看過這種門嗎?
前幾天聽見電視傳來孫燕姿的"遇見"("向左走向右走"), 突然讓我參透幾個PKI不錯的"Use Cases".
假設"金先生"為他的房間安裝了PKI鎖, 自己當然"左/右轉"兩把鑰匙都有囉! 對那位一直好事多磨的真命天女"梁小姐", 當然是要送一把"向左走", Sorry, 更正, "向左轉"的鑰匙囉? 沒事可以請她在金先生出差時去打掃房間, 澆澆花, 餵餵小動物...臨走在再把門鎖上. 所以金先生鎖門, 梁小姐可開. 梁小姐鎖門, 金先生也可開, 幸福吧?
至於"關小姐", 要嘛之前金先生就給了她一把"向左轉"(可能性極高...), 或者事後金先生覺得不好意思或是懷念關小姐的身材(後者可能性比較大...). 然後再打了一把給她.... 日後要是約關小姐到房間獨處時, 也不用怕梁小姐突然闖入... 只要用關小姐那一把, 或自己留的那一把"向左轉的鑰匙鎖門就好了唄? 關小姐鎖的, 梁小姐開不開, 反之亦然.
摩亞大人: 這就是"左右逢源"嗎?
其實, 本文只是為我接下來想寫的一些有關DRM與TrustView方面文章做做暖身, 讓大家對一些望之生畏的名詞減少一些恐懼感. 以上所提, 不過就是些比喻.. 千萬不要太當真, 例如, 不要問我ㄧ些: "梁小姐要是忘了關瓦斯就鎖門離開怎麼辦?" 或是,"梁小姐一進房間就把門反鎖, 等金先生一個月後出差回來剩乾屍一具"...等等奇怪的問題. 就算真正發生了, 我們也只能說誰叫金先生存心不良! 造成悲劇也只能說活該應得, 順便還有些警世的味道. 關PKI鳥事?
2009年7月1日 星期三
ChihLing 's Jasper Integration Demo
說真的, 本來我覺得在Windchill客製頁面, 放個Link指到Jasper Server去把內容秀出來就夠了! 沒想到ChihLing玩的那麼大, 搞起深度整合來了!!! 最重要的是, 整得太漂亮了!!! 連Windchill它媽看到大概都不會懷疑這是和Jasper偷生的...
2009年6月29日 星期一
有人逛過PTC的Forum嗎?
就多數客戶而言, 遇到問題大概就是請顧問或自己上PTC網站登錄一個請求(log a call)
然後您過一會或一陣子就會接到"PTC在線支持"(記得捲舌)的電話.
但是今天和朋友討論分享園地時, 忽然想到, 這個時代 像PTC這樣的公司不可能沒有類似討論區或知識分享區才是. 因此請ChihLing幫我用他之前申請的PTC帳號看看, 他很快傳給我一個Forum的網址. 用我自己的帳號也進得去, 只是進入前要再確認同意一些條款 .
看起來有蠻多有用的資訊. 真丟臉!!! 好歹曾做過PTC顧問, 一直不知道有這個網站. Anyway, 兄弟們, 有空去逛逛唄. 畢竟是你們的權利. 另外幾位多年Windchill功力的兄弟, 不要老是為難TS的小美眉 藉開Call趁機聊天吃豆腐, 自己去Forum上逛逛吧...
然後您過一會或一陣子就會接到"PTC在線支持"(記得捲舌)的電話.
但是今天和朋友討論分享園地時, 忽然想到, 這個時代 像PTC這樣的公司不可能沒有類似討論區或知識分享區才是. 因此請ChihLing幫我用他之前申請的PTC帳號看看, 他很快傳給我一個Forum的網址. 用我自己的帳號也進得去, 只是進入前要再確認同意一些條款 .
看起來有蠻多有用的資訊. 真丟臉!!! 好歹曾做過PTC顧問, 一直不知道有這個網站. Anyway, 兄弟們, 有空去逛逛唄. 畢竟是你們的權利. 另外幾位多年Windchill功力的兄弟, 不要老是為難TS的小美眉 藉開Call趁機聊天吃豆腐, 自己去Forum上逛逛吧...
討論: 分享園地的成員
一位行事謹慎低調的好友問我有關分享園地的宗旨, 成員結構, 與可能的利益衝突...幾個問題. 我發現還真的回答不上來. 畢竟正如我之前所說, 我並沒想太多就幹了.
因此和這位老友交換了些意見. 目前, 我覺得這個Blog和未來的分享園地本質上不太適合PTC人員直接參與, 或者讓他們最多看看就好, 不要讓他們放文章或寫回應. 你們也知道, 許多PTC顧問是很熱心的. 熱心絕對是好事, 但要預防他因為幫忙而不小心洩漏工作機密或搞砸了PTC的生意就不妙了.
另外也很好奇, 國外許多SAP的網站, 他們是怎麼搞的呢? 有空得去取取經.
所以, 大家就成員的組成或是權限問題, 討論一下吧?
因此和這位老友交換了些意見. 目前, 我覺得這個Blog和未來的分享園地本質上不太適合PTC人員直接參與, 或者讓他們最多看看就好, 不要讓他們放文章或寫回應. 你們也知道, 許多PTC顧問是很熱心的. 熱心絕對是好事, 但要預防他因為幫忙而不小心洩漏工作機密或搞砸了PTC的生意就不妙了.
另外也很好奇, 國外許多SAP的網站, 他們是怎麼搞的呢? 有空得去取取經.
所以, 大家就成員的組成或是權限問題, 討論一下吧?
Windchill與報表系統整合之效益簡介: 章節預覽
雖然還在慢慢爬文, 但是相信許多Windchill的兄弟看底下列出的標題大概就懂了. 這個主題因顧及舊版的Windchill, 所以捨棄以Cognas來做Pilot系統 (當然另一個原因是還沒學! 哈...). 另外, 小弟家貧, 所以儘量找一些Open Source來玩.
程如我在另一篇David目前的研究與預計發表的主題提到 大師兄早就把Jasper整進Windchill626 如果想知道實際細節 請參考他的Blog中Jasper Report的章節.
記憶所及, 小弟剛接觸報表系統時, 還沒聽到以Business Object 或以Business Intelligence 的美麗名稱來包裝此類產品. 只是那時隱然覺得幾家報表系統開始在OLAP上作文章, 甚至近年來有聽說幾家較貴的產品認為自己是BO/BI, 而不能算Report system(大概覺得被歸類為Report System 很低等吧?). 然而, 小弟大概是比較白目, 仍採用舊石器時代的觀點來看待這些產品. 不過小弟對報表系統並無貶意, 甚至覺得是不錯的東西. 對於Windchill9開始把Cognas拉進來, 本人深覺是使用者之福 (在此, 請大家以超然的立場, 不要考慮金錢的因素).
總之, 在上月底ChihLing不顧義氣,偕其愛妻漫遊巴黎與普羅旺斯之際, 我花了些時間試玩Jasper Report. 網路上論壇與資料不少, 上手不難. 在加上以前負責JReport業務, 對報表系統不陌生, 所以順便做了個與Windchill整合的POC. ChihLing回國後demo給他看, 不看還好, ChihLing一看就見獵心喜, 有事沒事就在搞Report... 上週他更給我看他自己想出的整合方案. 一看真的差點沒呆掉, 真是太漂亮了. 正因為做得好, 所以基於團隊利益, 我必須找其他事做了!!! 真是始料未及....
不過回頭想想, 東西好也要別人知道才有用!!! 思及認識的Windchill朋友中, 特別對報表系統與Windchill整合有興趣的似乎不多. 所以我懷疑大概沒有人特地把報表系統的優點好好介紹給大家, 所以打算發表一篇這方面的文章.
這個週末花了些時間沉澱思考, 目前算是把大綱定下了 原則上分兩大部分: "What's a Report System?" 與 "Why does Windchill need a Report System?".
在第一部分 "What's a Report System?" 中我打算用最淺白的術語, 將一般報表系統的元素與特性點出, 讓不熟悉報表系統的朋友快速進入此主題. 這個部分細分兩章節: 第一章 是介紹系統主要組成元素. 一般IT人員甚至從標題大概就能理解.
1. Report system's elements
1.1. Report form
(Define the representation: Columns Font. Background/Forground color, images)
1.2. Data source
(Define how the data is gathered)
1.3. Report
(ReportForm + DataSource)
1.4. Report Form tool
(Graphical tool used to generate Report Form)
1.5 Report server
1.5.1. With Reports (Forms + datasources) deployed
1.5.2. Get the report-content dynamically or periodically.
1.5.3. Reading of the report-content on-line or offline
(Invite the user to read the report-content on-line or download the report-content from report server)
1.5.4. Send the report-content to the user by email.
第二章介紹幾個報表系統的重要特性. 基本上, 這些特性大概是大眾對於報表系統最起碼的要求.
2. Main Features
2.1. Paging
2.2. Grouping
(Subtotal & Summary)
2.4. Exporting
(a variety of formats: PDF, Excel, HTML, Flash...)
2.5. Schedule
(Immediate, specific time, periodical)
2.6. Notification
(Mail notification & notification with report-content)
2.7. Charts
第二部分"Why does Windchill need a Report System?" 則先以報表系統的幾個重要特性為案例 探討以傳統Template-Processor與JSP甚至WCA方式開發報表相對不足之處.
3.1 Quick UI generation
3.1.1 For Windchill 9 without Cognos (WCA)
³.1.2. For Windchill 8-
3.2. Reuse efforts
3.2.1 One datasource vs. Multiple Report Forms
3.2.2 One Report Form vs. Multiple datasources
3.3. Paging & Grouping
Often ignored by Windchill customized reports.
3.4. Exporting
Often ignored by Windchill customized reports or only CSV is supported.
3.5. Schedule & Notification
Often ignored by Windchill customized reports
接下來對照這幾項報表系統的強項, 以試驗中的Jasper整合方案作印證說明整合的效益.
4. Demo the integration (by using Jasper as Pilot)
最後一章以IT主管的角度, 探討如何藉由整合報表系統, 更靈活的調度IT人力, 提升部門績效.
程如我在另一篇David目前的研究與預計發表的主題提到 大師兄早就把Jasper整進Windchill626 如果想知道實際細節 請參考他的Blog中Jasper Report的章節.
記憶所及, 小弟剛接觸報表系統時, 還沒聽到以Business Object 或以Business Intelligence 的美麗名稱來包裝此類產品. 只是那時隱然覺得幾家報表系統開始在OLAP上作文章, 甚至近年來有聽說幾家較貴的產品認為自己是BO/BI, 而不能算Report system(大概覺得被歸類為Report System 很低等吧?). 然而, 小弟大概是比較白目, 仍採用舊石器時代的觀點來看待這些產品. 不過小弟對報表系統並無貶意, 甚至覺得是不錯的東西. 對於Windchill9開始把Cognas拉進來, 本人深覺是使用者之福 (在此, 請大家以超然的立場, 不要考慮金錢的因素).
總之, 在上月底ChihLing不顧義氣,偕其愛妻漫遊巴黎與普羅旺斯之際, 我花了些時間試玩Jasper Report. 網路上論壇與資料不少, 上手不難. 在加上以前負責JReport業務, 對報表系統不陌生, 所以順便做了個與Windchill整合的POC. ChihLing回國後demo給他看, 不看還好, ChihLing一看就見獵心喜, 有事沒事就在搞Report... 上週他更給我看他自己想出的整合方案. 一看真的差點沒呆掉, 真是太漂亮了. 正因為做得好, 所以基於團隊利益, 我必須找其他事做了!!! 真是始料未及....
不過回頭想想, 東西好也要別人知道才有用!!! 思及認識的Windchill朋友中, 特別對報表系統與Windchill整合有興趣的似乎不多. 所以我懷疑大概沒有人特地把報表系統的優點好好介紹給大家, 所以打算發表一篇這方面的文章.
這個週末花了些時間沉澱思考, 目前算是把大綱定下了 原則上分兩大部分: "What's a Report System?" 與 "Why does Windchill need a Report System?".
在第一部分 "What's a Report System?" 中我打算用最淺白的術語, 將一般報表系統的元素與特性點出, 讓不熟悉報表系統的朋友快速進入此主題. 這個部分細分兩章節: 第一章 是介紹系統主要組成元素. 一般IT人員甚至從標題大概就能理解.
1. Report system's elements
1.1. Report form
(Define the representation: Columns Font. Background/Forground color, images)
1.2. Data source
(Define how the data is gathered)
1.3. Report
(ReportForm + DataSource)
1.4. Report Form tool
(Graphical tool used to generate Report Form)
1.5 Report server
1.5.1. With Reports (Forms + datasources) deployed
1.5.2. Get the report-content dynamically or periodically.
1.5.3. Reading of the report-content on-line or offline
(Invite the user to read the report-content on-line or download the report-content from report server)
1.5.4. Send the report-content to the user by email.
第二章介紹幾個報表系統的重要特性. 基本上, 這些特性大概是大眾對於報表系統最起碼的要求.
2. Main Features
2.1. Paging
2.2. Grouping
(Subtotal & Summary)
2.4. Exporting
(a variety of formats: PDF, Excel, HTML, Flash...)
2.5. Schedule
(Immediate, specific time, periodical)
2.6. Notification
(Mail notification & notification with report-content)
2.7. Charts
第二部分"Why does Windchill need a Report System?" 則先以報表系統的幾個重要特性為案例 探討以傳統Template-Processor與JSP甚至WCA方式開發報表相對不足之處.
3.1 Quick UI generation
3.1.1 For Windchill 9 without Cognos (WCA)
³.1.2. For Windchill 8-
3.2. Reuse efforts
3.2.1 One datasource vs. Multiple Report Forms
3.2.2 One Report Form vs. Multiple datasources
3.3. Paging & Grouping
Often ignored by Windchill customized reports.
3.4. Exporting
Often ignored by Windchill customized reports or only CSV is supported.
3.5. Schedule & Notification
Often ignored by Windchill customized reports
接下來對照這幾項報表系統的強項, 以試驗中的Jasper整合方案作印證說明整合的效益.
4. Demo the integration (by using Jasper as Pilot)
最後一章以IT主管的角度, 探討如何藉由整合報表系統, 更靈活的調度IT人力, 提升部門績效.
分享規則討論: 盡量不要放原始碼
Joseph提到一個敏感的問題: "Source code".
難免搞技術的人, 看到原始碼就像鯊魚聞到血一樣. 若有人願意提供, 怎麼不要? 我個人是不排斥各位弟兄放上原始碼, 但基本上我的底限為: "有版權問題的就不行!".
像是從前PTC GS有個東西叫什麼"generic component"的, 我知道有部份原始碼可能流落民間. 許多Windchill Site都用到. 但這是PTC的財產, 絕對不能放. 本站與未來的分享園地在於提供各Windchill相關人員討論技巧交換工作心得, 並不打算營利, 更不想找麻煩, 讓PTC以為我在與它爭利.
其實, 會來本站走走的多為心志高潔之輩, 佔人便宜的事想必是不會做. 但是避免不必要的困擾, 在此事先鄭重聲明.
此外, 若是自己的創作, 且不是利用某公司專案或資源產出的, 自然是歡迎. 但是我個人還是建議不要放, 不管是本文還是附件. 理由如下:
第一, 個人覺得網頁裡放上原始碼多少稀釋文章的精彩度. 我相信一般技術文章, 必要時將關鍵幾行貼上, 引為佐證, 理應足夠.
第二我個人偏好文章應儘可能闡述主旨(如設計), 儘量不要過於投入太多細節 以免造成其他讀者卻步 喪失分享的美意.
第三 這裡還涉及一敏感問題: "潛在的利益衝突". 我的立場很清楚: "絕不贊成不勞而獲"! 不管是Windchill的客戶, 從業人員或其他角色.
若有人在切磋分享中體會關鍵訣竅, 再自行花心血揣摩,實做, 組合出來, 那是他的本事, 沒有所謂的利益衝突. 但是若讓某些人(例如某些Windhill的客戶, 或PTC的競爭廠商...)不勞而獲, 進而影響PTC原廠或是外包(就像我本人)的生意與生計, 那決對是不被允許的.
這裡特地鄭重聲明還有一原因. 本人深知我輩投身IT之人多為浪漫單純之輩, 但身處濁世, 即便你與人無爭, 也可能遭人誤解算計, 兄弟們不可不慎.
難免搞技術的人, 看到原始碼就像鯊魚聞到血一樣. 若有人願意提供, 怎麼不要? 我個人是不排斥各位弟兄放上原始碼, 但基本上我的底限為: "有版權問題的就不行!".
像是從前PTC GS有個東西叫什麼"generic component"的, 我知道有部份原始碼可能流落民間. 許多Windchill Site都用到. 但這是PTC的財產, 絕對不能放. 本站與未來的分享園地在於提供各Windchill相關人員討論技巧交換工作心得, 並不打算營利, 更不想找麻煩, 讓PTC以為我在與它爭利.
其實, 會來本站走走的多為心志高潔之輩, 佔人便宜的事想必是不會做. 但是避免不必要的困擾, 在此事先鄭重聲明.
此外, 若是自己的創作, 且不是利用某公司專案或資源產出的, 自然是歡迎. 但是我個人還是建議不要放, 不管是本文還是附件. 理由如下:
第一, 個人覺得網頁裡放上原始碼多少稀釋文章的精彩度. 我相信一般技術文章, 必要時將關鍵幾行貼上, 引為佐證, 理應足夠.
第二我個人偏好文章應儘可能闡述主旨(如設計), 儘量不要過於投入太多細節 以免造成其他讀者卻步 喪失分享的美意.
第三 這裡還涉及一敏感問題: "潛在的利益衝突". 我的立場很清楚: "絕不贊成不勞而獲"! 不管是Windchill的客戶, 從業人員或其他角色.
若有人在切磋分享中體會關鍵訣竅, 再自行花心血揣摩,實做, 組合出來, 那是他的本事, 沒有所謂的利益衝突. 但是若讓某些人(例如某些Windhill的客戶, 或PTC的競爭廠商...)不勞而獲, 進而影響PTC原廠或是外包(就像我本人)的生意與生計, 那決對是不被允許的.
這裡特地鄭重聲明還有一原因. 本人深知我輩投身IT之人多為浪漫單純之輩, 但身處濁世, 即便你與人無爭, 也可能遭人誤解算計, 兄弟們不可不慎.
2009年6月28日 星期日
拋磚引玉: 催生Windchill分享園地
如題, 我弄了這個Blog, 最大的目的是希望促成一個非官方的Windchill討論園地誕生.
既然是討論與分享之園地, 就不會是一家之言. 當然, 也需要更多的人投入與付出.
然而, 考量現實面, 我必須先讓大家了解此想法的潛在價值. 因此, 先從我自己做起, 先將個人工作經驗分享, 希望帶起兄弟姐妹們參與的意願. 然後大夥進一步討論未來這個新園地的方向.
所以, 我其實並無一具體想法. 但是, 我也不認為一定要靠某個人或等某個人有具體想法才能開始進行. 我在上篇文章列出本人近況:" 研究目標與欲分享之主題", 就是一個"沒想太多", "先開始再說" 的念頭. 其實這些主體, 和我相熟的兄弟大都知道, 沒啥新鮮. 發表出來一來展現誠意, 二來就是讓這裡熱絡點, 多吸引些朋友進來切磋交流, 大家能因此受惠.
除了本人會不定期分享之外, 我也會開始施展我的"黏功" (很黏喲...), 將我已想到的幾個人選拉進來. 首先, 俗氣點想 網站需要光環, 因此需要名人加持. 大師兄Wayne既為Windchill第一把交椅, 他的Blog又為濫觴, 此外又是台灣JavaWorld的名家... 當然是不能放過的!!! 我的夥伴, 志凌,也會加入當然成員. 此外過去在PTC專案在客戶端結識的兄弟: 如Gemtek's Joseph, Fusheng's Benjamin, 和導過好幾個Windchill專案的Peter(現在eMemory服務)... 自然也是要網羅的目標, 以促成產業交流. 還有曾在PTC服務的好友 如我師父 David Su, Primax的X-Man (Xavier), 其他還在PTC服務的兄弟姐妹們, 有空還是要叨擾叨擾的...
此外Windchill是個蠻大的主題, 但是不該是全部. 其他IT方面的解決方案, 新的知識 ...未來若能藉此園地分享, 自是大佳. 目前打算遊說我兄弟阿伯(Albert) 將他在Java與Open Source的鬼才貢獻出來. 至少...把他的"阿伯特"專欄(職場現形記)帶進來讓大家開心也不錯.
Anyway, 寫的同時又冒出些想法. 不過老是坐而言總是不行的, 起來動動唄...
既然是討論與分享之園地, 就不會是一家之言. 當然, 也需要更多的人投入與付出.
然而, 考量現實面, 我必須先讓大家了解此想法的潛在價值. 因此, 先從我自己做起, 先將個人工作經驗分享, 希望帶起兄弟姐妹們參與的意願. 然後大夥進一步討論未來這個新園地的方向.
所以, 我其實並無一具體想法. 但是, 我也不認為一定要靠某個人或等某個人有具體想法才能開始進行. 我在上篇文章列出本人近況:" 研究目標與欲分享之主題", 就是一個"沒想太多", "先開始再說" 的念頭. 其實這些主體, 和我相熟的兄弟大都知道, 沒啥新鮮. 發表出來一來展現誠意, 二來就是讓這裡熱絡點, 多吸引些朋友進來切磋交流, 大家能因此受惠.
除了本人會不定期分享之外, 我也會開始施展我的"黏功" (很黏喲...), 將我已想到的幾個人選拉進來. 首先, 俗氣點想 網站需要光環, 因此需要名人加持. 大師兄Wayne既為Windchill第一把交椅, 他的Blog又為濫觴, 此外又是台灣JavaWorld的名家... 當然是不能放過的!!! 我的夥伴, 志凌,也會加入當然成員. 此外過去在PTC專案在客戶端結識的兄弟: 如Gemtek's Joseph, Fusheng's Benjamin, 和導過好幾個Windchill專案的Peter(現在eMemory服務)... 自然也是要網羅的目標, 以促成產業交流. 還有曾在PTC服務的好友 如我師父 David Su, Primax的X-Man (Xavier), 其他還在PTC服務的兄弟姐妹們, 有空還是要叨擾叨擾的...
此外Windchill是個蠻大的主題, 但是不該是全部. 其他IT方面的解決方案, 新的知識 ...未來若能藉此園地分享, 自是大佳. 目前打算遊說我兄弟阿伯(Albert) 將他在Java與Open Source的鬼才貢獻出來. 至少...把他的"阿伯特"專欄(職場現形記)帶進來讓大家開心也不錯.
Anyway, 寫的同時又冒出些想法. 不過老是坐而言總是不行的, 起來動動唄...
David目前的研究與預計發表的主題
目前的研究:
Windchill與Jasper之整合, 進度: Prototype開發. 團隊人數: 2
(此課題Wayne早已進行研究, 並已在宏達電實際上線. 有興趣的人不妨直接向他請教.)
欲發表之主題: (時間未定! 有興趣大家一起來參與)
1. 以報表系統延伸Windchill的價值, 並提升IT人員利用率
-- 感覺似乎許多Windchill的朋友們不了解報表系統真正的好處, 甚至可能有誤解, 希望能藉此文與大家交流.
2. "白話版" Business Admin
-- 一直想把幾個Business Admin裡重要的觀念與名辭, 用較淺白的方式說明. 若是 老Admin想把手頭工作交接給徒弟, 不訪一起來參與.
3. 以JNDI 新增/修改 Aphelion上的users, groups,與 memberships
-- 小技巧. 以前TrustView時代摸索的小東西, 拿來Windchill上玩玩, 蠻實用的說...
4. 積非成是: "Multiple Background servers"
-- 自從被AcBel的Egg兄抓包後, 一直耿耿於懷...
5. WCA筆記
-- 這東西有ㄒㄧㄠˊ問!!! 大家一起來玩唄? 一個人還真難玩...
6. 教學心得: "我覺得Workflow這樣教比較好"
-- 良心建議, 負責Workflow的朋友, 除了學會官方教材外, 有些主題也不能陌生, 否則, 禍福難測...
7. Windchill RMI
-- 舊瓶新酒, 小秘訣讓老把戲更值錢.
8. 以Windows NLB模擬 Content-Switch 設定Cluster環境
-- 窮人的Cluster. 在PTC三年多, 沒機會玩Clustering, 更買不起.. 人窮志不窮!!! 兄弟們 一起來吧! 另外, Joseph兄, 您的"balance"是不是也該拿出來曬曬太陽了?
9. 將MS Active Directory加入Windchill account system
-- 手冊上有寫, 看過的人都說不懂, 整人自虐兩相宜.
10. 教學心得: "我覺得InfoEngine這樣教比較好"
-- 許多user site的老爺們 Java與Web Programming可強的很. 真是不知道PTC之前那些 編教材的老爺們在想啥? 沒必要逼他們玩嫁衣神功還是天蠶變, 先把本身武功廢了才能 從頭慢慢學?
Windchill與Jasper之整合, 進度: Prototype開發. 團隊人數: 2
(此課題Wayne早已進行研究, 並已在宏達電實際上線. 有興趣的人不妨直接向他請教.)
欲發表之主題: (時間未定! 有興趣大家一起來參與)
1. 以報表系統延伸Windchill的價值, 並提升IT人員利用率
-- 感覺似乎許多Windchill的朋友們不了解報表系統真正的好處, 甚至可能有誤解, 希望能藉此文與大家交流.
2. "白話版" Business Admin
-- 一直想把幾個Business Admin裡重要的觀念與名辭, 用較淺白的方式說明. 若是 老Admin想把手頭工作交接給徒弟, 不訪一起來參與.
3. 以JNDI 新增/修改 Aphelion上的users, groups,與 memberships
-- 小技巧. 以前TrustView時代摸索的小東西, 拿來Windchill上玩玩, 蠻實用的說...
4. 積非成是: "Multiple Background servers"
-- 自從被AcBel的Egg兄抓包後, 一直耿耿於懷...
5. WCA筆記
-- 這東西有ㄒㄧㄠˊ問!!! 大家一起來玩唄? 一個人還真難玩...
6. 教學心得: "我覺得Workflow這樣教比較好"
-- 良心建議, 負責Workflow的朋友, 除了學會官方教材外, 有些主題也不能陌生, 否則, 禍福難測...
7. Windchill RMI
-- 舊瓶新酒, 小秘訣讓老把戲更值錢.
8. 以Windows NLB模擬 Content-Switch 設定Cluster環境
-- 窮人的Cluster. 在PTC三年多, 沒機會玩Clustering, 更買不起.. 人窮志不窮!!! 兄弟們 一起來吧! 另外, Joseph兄, 您的"balance"是不是也該拿出來曬曬太陽了?
9. 將MS Active Directory加入Windchill account system
-- 手冊上有寫, 看過的人都說不懂, 整人自虐兩相宜.
10. 教學心得: "我覺得InfoEngine這樣教比較好"
-- 許多user site的老爺們 Java與Web Programming可強的很. 真是不知道PTC之前那些 編教材的老爺們在想啥? 沒必要逼他們玩嫁衣神功還是天蠶變, 先把本身武功廢了才能 從頭慢慢學?
一個新的Windchill討論園地
親愛的Windchill領域的兄弟姐妹們:
在小弟自2004年接觸Windchill開始, 不時會遭遇各項疑難雜症. 在PTC服務時, 覺得PTC內部的知識網站不是沒用, 但是有些問題, 可能是本人查詢的方式不得法, 抑或是問題較冷門, 未必能從這些網站找到相關資訊. 有時雖然找到解答, 但可能因本人資質所限或屬不熟悉之範圍, 尚需其他資深同事協助. 更何況PTC GS在台灣一直是人力吃緊. 老是麻煩同事也實在不好意思. 所以, 一直希望有個 聚集各方Windchill前輩的非官方的網站能供我解惑.
另外深覺Windchill博大精深, 一個人力有窮時, 老是對大象亂摸也不是辦法. 若有一園地能讓使用Windchill的客戶, Windchill的顧問, 程式開發人員等... 共聚ㄧ堂, 交換資訊, 切搓學習, 該是美事一樁.
吾友 Wayne Hu(PTC GS的大師兄) 之前基於大慈悲心, 設立了 "Wayne's Knowledge Sharing "blog, 將他個人在Windchill與Java方面的研究心得無私的發表, 分享給我們這些不時仍受Windchill荼毒的黎民百姓. 不過自從大師兄結婚生女又升官之後, 家事公事繁重, 難以再分心於以往救苦救難的公益事業. 況且此等公益事業也不能光靠一人無私之力, 因此有了再成立一個Windchill分享園地的想法.
今年恰逢不景氣, 這兩個月又恰逢"五窮六絕"時期, 沒啥案子可做. 所以我與夥伴ChihLing有更多的時間研讀實驗一些在Windchill領域中有興趣但苦無機會接觸的課題. 運氣不錯, 這兩個月下來, 算是摸索出了些門道. 欣喜(暗爽)同時, 感於過去蒙各方前輩不吝協助解惑, 不利用此時將所知回饋更待何時? 另外, 深知與其閉門造車, 不若集思廣義, 群策群力之的道理, 決定先仿效Wayne的方式 將個人的經驗心得分享在個人blog. 另一方面開始號召在之前在PTC與客戶端結識的兄弟姊妹們捧場, 進而催生一個能讓大家分享交流與學習的園地.
在小弟自2004年接觸Windchill開始, 不時會遭遇各項疑難雜症. 在PTC服務時, 覺得PTC內部的知識網站不是沒用, 但是有些問題, 可能是本人查詢的方式不得法, 抑或是問題較冷門, 未必能從這些網站找到相關資訊. 有時雖然找到解答, 但可能因本人資質所限或屬不熟悉之範圍, 尚需其他資深同事協助. 更何況PTC GS在台灣一直是人力吃緊. 老是麻煩同事也實在不好意思. 所以, 一直希望有個 聚集各方Windchill前輩的非官方的網站能供我解惑.
另外深覺Windchill博大精深, 一個人力有窮時, 老是對大象亂摸也不是辦法. 若有一園地能讓使用Windchill的客戶, Windchill的顧問, 程式開發人員等... 共聚ㄧ堂, 交換資訊, 切搓學習, 該是美事一樁.
吾友 Wayne Hu(PTC GS的大師兄) 之前基於大慈悲心, 設立了 "Wayne's Knowledge Sharing "blog, 將他個人在Windchill與Java方面的研究心得無私的發表, 分享給我們這些不時仍受Windchill荼毒的黎民百姓. 不過自從大師兄結婚生女又升官之後, 家事公事繁重, 難以再分心於以往救苦救難的公益事業. 況且此等公益事業也不能光靠一人無私之力, 因此有了再成立一個Windchill分享園地的想法.
今年恰逢不景氣, 這兩個月又恰逢"五窮六絕"時期, 沒啥案子可做. 所以我與夥伴ChihLing有更多的時間研讀實驗一些在Windchill領域中有興趣但苦無機會接觸的課題. 運氣不錯, 這兩個月下來, 算是摸索出了些門道. 欣喜(暗爽)同時, 感於過去蒙各方前輩不吝協助解惑, 不利用此時將所知回饋更待何時? 另外, 深知與其閉門造車, 不若集思廣義, 群策群力之的道理, 決定先仿效Wayne的方式 將個人的經驗心得分享在個人blog. 另一方面開始號召在之前在PTC與客戶端結識的兄弟姊妹們捧場, 進而催生一個能讓大家分享交流與學習的園地.
訂閱：
文章 (Atom)