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"時, 我想我也該識趣的結束這個話題唄?
沒有留言:
張貼留言