我目前在一家軟體供應商工作，特別是門禁控制解決方案。 而我「前世」的經驗與客戶一方——一家大型金融機構——息息相關。 當時，我們資訊安全部門的存取控制小組在 IdM 方面還沒有很強的能力。 在這個過程中我們學到了很多東西，為了建立公司資訊系統使用者權限管理的工作機制，我們也遇到了許多坎坷。
將我來之不易的客戶體驗與供應商知識和能力相結合，我想與您分享基本的分步說明：如何在大公司中創建基於角色的存取控制模型，以及這將帶來什麼結果。 我的說明由兩部分組成：第一部分是準備建造模型，第二部分是實際建造。 這是第一部分，準備部分。
注： 不幸的是，建立榜樣不是一個結果，而是一個過程。 或者更確切地說，甚至是在公司創建存取控制生態系統過程的一部分。 所以要做好長時間比賽的準備。
首先，我們來定義一下──什麼是基於角色的存取控制？ 假設您有一家大型銀行，擁有數萬甚至數十萬名員工（實體），每位員工對數百個銀行內部資訊系統（物件）擁有數十種存取權限。 現在將物件的數量乘以主體的數量 - 這是您需要先建立然後控制的最小連接數。 真的可以手動執行此操作嗎？ 當然不是——創建角色就是為了解決這個問題。
角色是使用者或使用者群組執行某些工作任務所需的一組權限。 每個員工可以擁有一個或多個角色，並且每個角色可以包含允許該角色內的使用者的一到多個權限。 角色可以與員工的特定職位、部門或職能任務相關聯。
角色通常是根據每個資訊系統中的單一員工授權創建的。 然後由各個系統的角色形成全域業務角色。 例如，業務角色「信貸經理」將包括銀行客戶辦公室使用的資訊系統中的幾個單獨的角色。 例如主要的自動化銀行系統、現金模組、電子文件管理系統、服務管理器等。 通常，業務角色與組織結構相關，換句話說，與公司部門及其職位的集合相關。 這就是一個全域角色矩陣的形成方式（我在下表中給了一個例子）。
值得注意的是，建立一個100%的角色模型，為商業結構中每個職位的員工提供所有必要的權利是根本不可能的。 是的，這是沒有必要的。 畢竟，榜樣不可能是一成不變的，因為它取決於不斷變化的環境。 並來自公司業務活動的變化，相應地影響組織結構和功能的變化。 也因為缺乏充分的資源供應、不遵守工作說明、以犧牲安全為代價追求利潤以及許多其他因素。 因此，需要建立一個角色模型，能夠涵蓋高達80%的使用者在分配職位時所需的基本權限需求。 如有必要，他們可以稍後在單獨的申請中請求剩餘的 20%。
當然，你可能會問：“難道就沒有100%的榜樣嗎？” 好吧，為什麼會發生這種情況，例如，在一些研究機構中不會經常發生變化的非營利結構中。 或在安全等級較高的軍工綜合組織中，安全是第一位的。 它發生在商業結構中，但在一個單獨部門的框架內，該部門的工作是一個相當靜態和可預測的過程。
基於角色的管理的主要優點是頒發權限的簡化，因為角色的數量明顯少於資訊系統的使用者數量。 對於任何行業都是如此。
以一家零售公司為例：它僱用了數千名銷售人員，但他們在系統 N 中擁有相同的一組權利，並且只會為他們創建一個角色。 當新的銷售人員來到公司時，系統會自動為他指派所需的角色，系統已經擁有所有必要的權限。 此外，只需單擊一下，您就可以立即更改數千個賣家的權利，例如，新增用於產生報告的新選項。 無需進行上千次操作，為每個帳戶連結一個新權限 - 只需將此選項新增至角色中，它就會同時顯示給所有賣家。
基於角色的管理的另一個優點是消除了不相容授權的發布。 也就是說，在系統中具有某種角色的員工不能同時擁有另一個角色，而該角色的權利不應與第一個角色的權利合併。 一個突出的例子是禁止將金融交易的輸入和控制功能結合。
任何對基於角色的存取控制是如何產生感興趣的人都可以
深入歷史
如果我們回顧歷史，IT界首先想到存取控制方法是在70世紀XNUMX年代。 儘管當時的應用程式非常簡單，但就像現在一樣，每個人都非常希望能夠方便地管理對它們的存取。 授予、變更和控制使用者權限 - 只是為了更容易了解每個人擁有哪些存取權限。 但當時沒有共同的標準，第一個存取控制系統正在開發中，每個公司都基於自己的想法和規則。
現在已知許多不同的存取控制模型，但它們並沒有立即出現。 讓我們重點關注那些為該領域的發展做出重大貢獻的人。
第一個也可能是最簡單的模型是 自主（選擇性）存取控制 （DAC – 自主存取控制）。 該模型意味著訪問過程中所有參與者共享權利。 每個使用者都可以存取特定的物件或操作。 本質上，這裡的權利主體集合對應於客體集合。 人們發現該模型過於靈活且難以維護：存取清單最終會變得龐大且難以控制。
第二個模型是 強制存取控制（MAC - 強制存取控制）。 根據該模型，每個使用者根據所發出的對特定資料保密等級的存取來接收對物件的存取。 因此，應根據對象的機密等級對其進行分類。 與第一個靈活的模型不同，相反，這個模型過於嚴格和限制性。 當公司擁有大量不同的資訊資源時，它的使用是不合理的：為了區分對不同資源的訪問，您將不得不引入許多不會重疊的類別。
由於這兩種方法有明顯的缺陷，IT界不斷發展更靈活、同時或多或少具有通用性的模型，以支援不同類型的組織存取控制策略。 然後就出現了 第三種基於角色的存取控制模型！ 這種方法已被證明是最有前途的，因為它不僅需要使用者身分的授權，還需要使用者在系統中的操作功能。
第一個明確描述的角色模型結構是由美國國家標準與技術研究所的美國科學家 David Ferrailo 和 Richard Kuhn 於 1992 年提出的。 然後這個字第一次出現 RBAC（基於角色的存取控制）。 這些研究和對主要組成部分及其關係的描述構成了 INCITS 359-2012 標準的基礎，該標準至今仍然有效，並得到了國際資訊技術標準委員會 (INCITS) 的批准。
該標準將角色定義為「組織環境中的工作職能，具有一些與分配給分配給該角色的使用者的權限和責任相關的語義」。 該文件建立了 RBAC 的基本元素——使用者、會話、角色、權限、操作和對象，以及它們之間的關係和互連。
該標準提供了建立角色模型所需的最低限度的結構 - 將權限組合到角色中，然後透過這些角色向使用者授予存取權限。 概述了從物件和操作組成角色的機制，描述了角色的層次結構和權力的繼承。 畢竟，在任何公司中，都有一些角色結合了公司所有員工所必需的基本權力。 這可以是對電子郵件、EDMS、公司入口網站等的存取。 這些權限可以包含在一個稱為「員工」的通用角色中，而無需在每個更高層級的角色中一遍又一遍地列出所有基本權限。 簡單指出「員工」角色的繼承特徵就足夠了。
後來，該標準補充了與不斷變化的環境相關的新訪問屬性。 新增了引入靜態和動態限制的能力。 靜態意味著不可能組合角色（上述操作的相同輸入和控制）。 動態限制可以透過改變參數來確定，例如時間（工作/非工作時間或天）、位置（辦公室/家庭）等。
值得單獨一提的是 基於屬性的存取控制（ABAC - 基於屬性的存取控制）。 此方法基於使用屬性共用規則授予存取權限。 該模型可以單獨使用，但很多時候它是對經典角色模型的積極補充：可以將使用者、資源和設備以及時間或位置的屬性添加到某個角色。 這允許您使用更少的角色，引入額外的限制並盡可能減少訪問，從而提高安全性。
例如，如果會計師在某個地區工作，則可以允許他存取帳戶。 然後將專家的位置與一定的參考值進行比較。 或者，只有當使用者從允許的裝置清單中包含的裝置登入時，您才可以授予對帳戶的存取權限。 角色模型的一個很好的補充，但由於需要創建許多規則和權限或限製表，因此很少單獨使用。
讓我舉一個我「前世」使用ABAC的例子。 我們銀行有幾個分行。 這些分支機構的客戶辦公室的員工執行完全相同的操作，但必須僅使用其所在地區的帳戶在主系統中工作。 首先，我們開始為每個區域創建單獨的角色 - 有很多這樣的角色具有重複的功能，但可以存取不同的帳戶！ 然後，透過使用使用者的位置屬性並將其與特定範圍的帳戶關聯起來進行審查，我們顯著減少了系統中的角色數量。 因此，只有一個分行保留了職位，而該銀行所有其他地區部門的相應職位都重複了這一職位。
現在讓我們來談談必要的準備步驟，沒有這些準備步驟根本不可能建立一個工作角色模型。
步驟 1. 建立功能模型
您應該先建立一個功能模型 - 一個頂級文檔，詳細描述每個部門和每個職位的功能。 通常，資訊從各種文件輸入：各單位（部門、部門、部門）的工作說明和規定。 功能模型必須得到所有相關部門（業務、內部控制、安全）的同意並得到公司管理層的批准。 這個文檔有什麼用？ 以便榜樣可以參考。 例如，您將根據員工現有的權利建立一個角色模型—從系統中卸載並「簡化為共同點」。 然後，當與系統的業務所有者就接收到的角色達成一致時，您可以參考功能模型中的特定點，在此基礎上將這個或那個權利包含在角色中。
第 2 步：我們審核 IT 系統並制定優先計劃
在第二階段，您應該對 IT 系統進行審核，以了解如何組織對它們的存取。 例如，我的金融公司經營著數百個資訊系統。 所有系統都有一些基於角色的管理的基礎，大多數系統都有一些角色，但主要是在紙面上或在系統目錄中 - 它們早已過時，並且根據實際用戶請求授予對它們的訪問權限。 當然，同時在數百個系統中建立一個角色模型是不可能的；你必須從某個地方開始。 我們對存取控制流程進行了深入分析，以確定其成熟度。 在分析過程中，制定了資訊系統優先級標準－關鍵性、準備、退役計畫等。 在他們的幫助下，我們安排了這些系統的角色模型的開發/更新。 然後，我們將角色模型納入與身分識別管理解決方案整合的計劃中，以實現存取控制自動化。
那麼如何判斷一個系統的重要性呢？ 回答自己以下問題：
- 該系統是否與公司核心活動所依賴的營運流程相關聯？
- 系統中斷是否會影響公司資產的完整性？
- 系統允許的最大停機時間是多少，達到該時間後就無法在中斷後恢復活動？
- 違反系統資訊完整性是否會導致不可逆轉的財務和聲譽後果？
- 對欺詐的批評。 功能的存在如果控制不當，可能會導致內部/外部詐欺行為；
- 這些系統的法律要求以及內部規則和程序是什麼？ 監管機構是否會因違規而處以罰款？
在我們的金融公司，我們進行了這樣的審計。 管理階層制定了存取權限審查審核程序，首先查看最高優先順序清單上的資訊系統中的現有使用者和權限。 安全部門被指定為該流程的擁有者。 但為了全面了解公司的存取權限，有必要讓 IT 和業務部門參與流程。 爭論、誤解，有時甚至是破壞就開始了：沒有人願意擺脫當前的責任，參與一些乍看難理解的活動。
注： 擁有成熟IT流程的大公司可能都熟悉IT審計程序——IT一般控制（ITGC），它可以讓您識別IT流程中的缺陷並建立控制，從而根據最佳實踐（ITIL、COBIT、IT治理等）此類審計使IT 和業務部門能夠更好地相互了解並制定聯合發展策略、分析風險、優化成本並制定更有效的工作方法。
審計的領域之一是確定對資訊系統的邏輯和實體存取的參數。 我們將獲得的數據作為進一步用於建立角色模型的基礎。 此次審核的結果是，我們對 IT 系統進行了登記，其中確定了其技術參數並給出了描述。 此外，對於每個系統，都根據其運作利益的業務方向來識別所有者：他負責該系統所服務的業務流程。 也任命了一名 IT 服務經理，負責特定 IS 業務需求的技術實現。 記錄了公司最關鍵的系統及其技術參數、調試和退役條件等，這些參數對於準備創建角色模型的過程非常有幫助。
步驟 3 建立方法
任何企業成功的關鍵是正確的方法。 因此，無論是為了建立榜樣還是進行審計，我們都需要創建一種方法來描述部門之間的互動，在公司法規中確立責任等。
首先，您需要檢查所有建立授予存取和權限的程式的可用檔案。 好的方式是，流程應該在幾個層級上進行記錄：
- 一般企業要求；
- 資訊安全領域的要求（取決於組織活動的領域）；
- 技術流程的要求（說明、存取矩陣、指南、配置要求）。
在我們的金融公司，我們發現了很多過時的文件；我們必須按照正在實施的新流程來攜帶它們。
根據管理層的命令，成立了一個工作小組，其中包括來自安全、IT、業務和內部控制的代表。 命令概述了團體的創建目標、活動方向、存在期限和各方責任。 此外，我們還制定了一套審計方法和建立榜樣的程序：它們得到了該領域所有負責代表的同意，並得到了公司管理層的批准。
描述開展工作的程序、截止日期、責任等的文件。 - 保證在實現所珍視的目標的過程中，這一目標一開始對每個人來說都不是顯而易見的，沒有人會質疑「我們為什麼要這樣做，為什麼我們需要它等等」。 並且不會有機會「跳出」或減慢這一過程。
步驟4.修復現有門禁控制模型的參數
我們正在製定一個存取控制方面的所謂「系統護照」。 本質上，這是一份針對特定資訊系統的調查問卷，記錄了控制存取該系統的所有演算法。 已經實施 IdM 級解決方案的公司可能熟悉這樣的問卷，因為這是系統研究的起點。
有關係統和所有者的一些參數從 IT 註冊表流入問卷（請參閱步驟 2，審核），但也添加了新參數：
- 如何管理帳戶（直接在資料庫中或透過軟體介面）；
- 使用者如何登入系統（使用單獨的帳戶或使用AD帳戶、LDAP等）；
- 使用了哪些層級的系統存取權限（應用程式層級、系統層級、系統對網路檔案資源的使用）；
- 系統運作的伺服器的描述和參數；
- 支援哪些帳戶管理操作（封鎖、重新命名等）；
- 使用什麼演算法或規則來產生系統使用者識別碼；
- 可以使用什麼屬性與人事系統中的員工記錄建立連結（全名、人員編號等）；
- 所有可能的帳戶屬性和填寫規則；
- 系統中存在哪些存取權限（角色、群組、原子權限等，是否存在嵌套或分層權限）；
- 劃分存取權限的機制（按職位、部門、職能等）；
- 該系統是否有權利分離規則（SOD - 職責分離），以及它們如何運作；
- 系統如何處理缺勤、調動、解僱、更新員工資料等事件。
這個清單可以繼續，詳細說明存取控制過程中涉及的各種參數和其他物件。
步驟 5. 建立以業務為導向的權限描述
建立角色模型時我們需要的另一個文件是一本參考書，其中介紹了可以授予資訊系統中使用者的所有可能的權力（權利），並詳細描述了其背後的業務功能。 通常，系統中的權限是用某些由字母和數字組成的名稱進行加密的，企業員工無法弄清楚這些符號背後的含義。 然後他們去 IT 服務，在那裡......他們也無法回答問題，例如，關於很少使用的權限的問題。 然後必須進行額外的測試。
如果已經有業務描述，或者即使將這些權利組合成群組和角色，那就很好。 對於某些應用程序，最佳實踐是在開發階段創建這樣的參考。 但這種情況並不經常發生，因此我們再次前往 IT 部門收集有關所有可能的權限的資訊並進行描述。 我們的指南最終將包含以下內容：
- 機構名稱，包括存取權適用的對象；
- 允許對某個物件進行的操作（檢視、變更等，限制的可能性，例如按地域或客戶群）；
- 授權碼（使用授權可以執行的系統功能/請求的代碼和名稱）；
- 權限的描述（應用權限時 IS 中操作的詳細描述及其對流程的影響；
- 權限狀態：「活動」（如果權限已指派給至少一個使用者）或「未活動」（如果未使用權限）。
步驟 6 我們從系統下載有關使用者和權限的數據，並將其與人員來源進行比較
在準備的最後階段，您需要從資訊系統下載有關所有使用者及其目前擁有的權限的資料。 這裡有兩種可能的情況。 第一：安全部門可以直接存取系統，並且可以下載相關報告，這種情況並不常見，但非常方便。 第二：我們向 IT 部門發送請求，要求其接收所需格式的報告。 經驗表明，不可能在第一時間與 IT 部門達成協議並獲得必要的數據。 有必要採取多種方法，直到以所需的形式和格式收到資訊。
需要下載哪些資料：
- 帳戶名稱
- 分配到的員工的全名
- 狀態（活動或阻止）
- 帳戶建立日期
- 最後使用日期
- 可用權限/群組/角色列表
因此，我們從系統中收到了所有使用者的下載以及授予他們的所有權利。 他們立即擱置了所有被封鎖的帳戶，因為建立角色模型的工作將只針對活躍用戶進行。
然後，如果您的公司沒有自動阻止被解僱員工訪問的方法（這種情況經常發生），或者拼湊的自動化並不總是正常工作，那麼您需要識別所有「死魂」。 我們談論的是已經被解僱的員工的帳戶，他們的權利沒有因某種原因被封鎖 - 他們需要被封鎖。 為此，我們將上傳的數據與人員來源進行比較。 人員卸貨也必須提前從維修人員資料庫的部門取得。
另外，有必要保留其所有者未在人員資料庫中找到的帳戶，未分配給任何人 - 即無所有者。 使用此列表，我們將需要上次使用的日期：如果是最近的，我們仍然需要尋找所有者。 這可能包括未分配給任何人但與任何流程相關聯的外部承包商的帳戶或服務帳戶。 要查明這些帳戶屬於誰，您可以向所有部門發送信件，要求他們回覆。 當找到所有者後，我們將有關他們的資料輸入系統：這樣，所有活動帳戶都會被識別，其餘帳戶將被封鎖。
一旦我們的上傳清除了不必要的記錄並且僅保留了活躍帳戶，我們就可以開始為特定資訊系統建立角色模型。 但我會在下一篇文章告訴你這一點。
作者：Lyudmila Sevastyanova，Solar inRights 推廣經理
來源： www.habr.com