Exchange2010中如何使用RBAC來控制用戶權限

這篇文章主要介紹Exchange2010中如何使用RBAC來控制用戶權限，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

一、RBAC對于不同類型的用戶有不同的作用。

在2010的Exchange系統中，將會全部使用基于角色的訪問控制體系。在2007以前的版本中所采用的權限控制模型將會被全部淘汰掉。其實基于角色的權限控制體系并不是一個新事務，在其他應用系統中都有比較不錯的表現。微軟在這里只是引進了這一體系，并結合Exchange的特點進行了優化而已。

那么RBAC對于Exchange來說，到底有哪些革命性的變化呢？簡單的說，管理員可以通過RBAC基于角色的訪問控制體系，為不同的角色定義極其多樣、精確的權限模型。如果有八個字來概括的話就是“豐富多彩”、“精確定位”。

具體的說，對于不同類型的用戶會友不同的收益。如對于最終用戶來說，管理角色分配策略定義了用戶可以在其的郵箱上說配置的內容。如可以控制用戶能否更改自己郵箱的簽名、更改過濾策略等等。還可以控制最終用戶是否可以更改其個人信息、聯系人信息、通訊組成員等等。這些特性有時候非常有用。如在一個企業中使用Exchange，則管理員可能會為整個公司的員工建立一個通訊簿。此時這個通訊簿最終用戶就不能夠隨意更改。默認情況下，這些策略會自動應用于每個郵箱。或者由用戶手工啟用也可以。

而對于管理員用戶來說，又會有不同的裨益。管理角色組能夠定義管理員用戶或者專家用戶能夠在系統中管理的內容。簡單的說，就是角色組可以將需要的一系列管理角色聯系起來，組成一個虛擬的“集合”。系統管理員可以通過作為角色組成員來添加或者刪除用戶，或者在角色組中添加和刪除角色分配，從而可以控制成員只管理組織的某些特定方面。在大型的Exchange應用中，這非常有好處。因為此時企業往往有多個系統管理員。如各個分支機構都會有一個郵箱管理員。這些郵箱管理員之能夠進行一些簡單地維護工作。如新加用戶或者刪除用戶，以及本地的數據備份等等。其他的維護任務，如防火墻策略等等只有某個特定的管理員才可以完成。

這種設計即可以在不同的管理員之間進行合適的授權，以實現分工合;同時也可以提高系統的靈活性，為不同的分支機構分配不同的管理策略，并由各自的管理員負責維護。[IT專家網獨家撰稿]

二、2010與2007版本權限管理的主要差異。

2010與2007在權限的管理上主要的差異就是在2010中使用了RBAC(基于角色的訪問控制)體系。具體的來說，這個差異主要是體現在ACL訪問控制列表上。

眾所周知，如果要在2007版本上實現比較復雜、全面的權限控制，則需要借助于ACL訪問控制列表。雖然ACL功能比較強大，但是其也會給管理員帶來很多的困擾。如在2007中，修改了ACL之后往往會出現一些莫名其妙的結果;有時候需要通過升級來維持ACL的更改;在非標準模式下使用ACL會受到諸多限制等等不利因素。但是在2010中由于采用率RBAC，這些困擾都將煙消云散。因為通過RBAC，管理員更不不需要修改和管理ACL訪問控制列表。這才是這兩個版本在權限管理上的重要差異。而RBAC基于角色的訪問控制只是一種表象。

三、角色組管理的注意事項。

在實際工作中，我們可以將Exchange的用戶分為兩類：管理員用戶和最終用戶。而管理員用戶又可以分為兩類：管理員與開發人員。有時候可能Exchange的現有功能無法滿足用戶的需求(雖然現在Exchange的功能已經很強大)，此時就需要在原有的功能上進行一些簡單的二次開發或者部署配置。如可能需要跟OA系統集成等等。雖然他們同屬于管理員，但是他們的任務是不同的。如開發人員可能只管理Exchange的特定功能，其很少會涉及到Exchange現有功能的配置。為了避免開發人員一不小心改動了郵箱配置給其他用戶帶來不必要的困擾，往往會對他們進行權限的控制。

假設遇到這種需求，該如何解決呢？筆者的建議是，通過2010的RBAC權限控制體系，可以將管理角色組分為兩個。普通的管理員只維護組織、收件人等配置;而開發專家管理人員則只負責對Exchange的特定功能的開發與修改。通過這么分類，就可以防止這兩類人員之間的工作相互干擾。

另外，管理角色組可以將管理角色與一組管理人員或者專家用戶進行有機的關聯。如開發人員只具有限的管理能力，沒有被授予廣泛的管理權限。此時也會出現一個新的問題。如當開發人員需要對剛才開發的某個功能進行測試，卻發現自己沒有某個作業的權限。遇到這種情況的話，又該如何處理呢？對此筆者也有一個建議。某個特定的角色組能夠關聯公用管理角色。這個公用管理角色可以使開發人員也可以參與到管理組織以及收件人的配置中去。在有需要的時候，如在測試的過程中可以將它們關聯起來。等到完成之后，再剔除他們之間的關系。操作起來可以省心很多。

對于角色組的管理，筆者總結一下。主要就是對于非最終用戶，在必要時也需要進行分類分組管理，以避免相互之間產生不必要的干擾。有時候由于某種特殊的原因需要“越權”的話，則可以將其臨時關聯到“公用管理角色”，以滿足特定權限的需要。注意，等到作業執行完畢的時候，一定要收回相關的權限。“杯酒釋兵權”，可以提高Exchange服務器的安全與穩定型。

四、直接用戶角色分配簡化策略管理。

一般情況下，在RBAC中是先將角色(是否具有進行某項作業的權限)分配給角色分配策略。然后再將角色分配策略與用戶進行管理。簡單的說，就是權限、策略、用戶。注意，權限不能夠直接與用戶進行關聯，必須通過策略這個中間媒體。這是RBAC的核心。在比較復雜的企業中，這種特性比較實用，可以強迫管理員通過策略來管理用戶以及用戶所擁有的權限。但是如果企業規模比較小，用戶數量比較少，此時采用這種管理模式的話，就有點“殺雞焉用牛刀”的感覺。

在這種情況下，就需要采用“直接用戶角色分配”功能，來簡化權限的管理。“直接角色用戶分配”是RBAC中的一種例外的方法。可以用于將角色直接分配給用戶，而不使用角色組或者角色分配策略。但需要為特定用戶提供一組比較精細的權限(即只有少數的用戶、甚至只有一個用戶需要)，此時直接角色分配就會非常有用。

不過在使用這種角色分配機制的時候需要注意其缺點。使用“直接角色分配”會增加權限模型的復雜性。具體增加的程度根據權限而定。如當某個用戶離職了，需要手工刪除角色與用戶的關聯。為此除非有特殊的必要，一般不建議使用直接用戶角色分配這個功能。

一般情況下，可以將角色分配策略和直接角色用戶分配兩種方法結合起來使用。如假設只有一個管理員的話，管理員可以為自己采用直接角色用戶分配的功能。然后為其他用戶采用角色分配策略。

以上是“Exchange2010中如何使用RBAC來控制用戶權限”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！