有設計過資訊系統的人都知道，如果該系統的使用者稍具規模，存取控管往往是一個最頭痛的問題。在存取控管的設計中，我們通常會先區分為主體(Subject)與物件(Object)兩個部分。主體通常是指使用系統的”人”，這裡的人可能包含員工、主管、甚至是其它的系統。而物件就是被存取的”東西”，包含資料、檔案、或是系統的功能。而存取控管簡單來說就是決定哪些主體對哪些物件有哪些權限。
存取控管有各種不同的形式，包含Access Control List、Access Control Matrix、Role-based Access Control (RBAC)等…其中RBAC因為將主體區分為不同的角色(Role)，所以不但方便對應到現實組織的架構以管理所需權限，而且因為通常角色的數量遠小於主體，所以管理的複雜度更是大幅縮小。也因此許多系統的存取控管，其實都是使用RBAC的觀念來加以設計。但是我們都知道，現實中的故事都沒有這麼美滿。通常會使用到權限控管的系統，都是稍具使用者規模的系統，而且有更多是從原先不敷使用的系統要升級到新的系統。這種系統有一個很重要的特性，就是規畫的人一定很重視”彈性”。所以就會同時出現
- 角色要能夠任意新增
- 每個人可以同時擁有多種角色
- 角色的權限要能夠繼承
- 擁有權限的人可以把相關權限賦予其他人
- 資料控管的細緻度不能夠只到資料記錄本身，而是要到每個欄位
這類看似再正常不過的需求。其實這類需求確實存在某些系統中，但是就像所有的安全機制，如何對自身而言能夠恰到好處才是真正的學問。一個內部使用的系統，畢竟不須適用於各種不同的組織型態，如何找出自己真正的需求，必須事前花費一番工夫(例如透過風險評估)。我必須再次強調，這些需求本身並沒有錯。而是組織必須清楚的了解這些需求的迫切性，知道因為這些需求所帶來的成本與效益，此外當然還有所衍生的風險。
設計系統的人還知道另外一件事，那就是彈性代表的是系統的複雜度大幅提升，用老闆聽得懂的話說就是系統失敗的機率直線上升。然而真正的問題，並不在於系統本身複雜度的提升，因為系統的複雜度自然有具備神奇能力的SD與PG會負責克服。真正的問題乃是在於存取控管機制的複雜度大幅提升。一個複雜的存取控管，要如何有效地加以設定並應用，在實務上將是相當的困難。以靜態的角度來看，一些像是存取控管的基本原則，如最小權限(Least Privilege)、責任劃分(Separation of Duties)、避免資料Inference與Aggregation的問題，都不容易加以確實遵守。而存取控管最困難的地方更在於動態的部分，也就是隨著時間的過去，設定已經漸漸脫離原先的規劃。常見的原因包含人員的異動沒有有效地移除不再需要的權限，或是資料安全性(包含機密性或重要性)變更時沒有跟著重新檢視各項權限的設定。
這些問題其實都不是被過度要求彈性的RBAC所獨有的，通常可以透過嚴格的權限審核與定期的重新審核來避免這樣的問題產生。當然，一個明確且確實執行的權限變更需求審核機制更是必要。而過度要求彈性的RBAC所帶來真正的負面影響是很難將所核可的權限與系統實際上所賦予的權限做比對確認，如此一來前述幾項事情也就都無法有效地加以執行。也可以說，整個存取控管的設計因為顧慮到彈性而適得其反了。”簡單”這樣的概念在很多地方都漸漸的被強調，不管是在生活、商業、管理、甚至是技術上。在技術上有人提出了作業系統應該朝向更精簡的方向設計，其中一個理由就是簡單的系統才可以設計得更安全。對於作業系統如此，我想對於存取控管機制也是一樣。唯有簡單易懂的存取控管機制，才是能夠受駕馭的工具，而不至於成為脫韁的野馬。
你遇過哪些要求"彈性"的需求？歡迎你提出來跟大家分享。
相關文章：
網誌管理員已經移除這則留言。
回覆刪除