資料安全合規需要從基於角色的訪問控制邁向基於屬性的訪問控制

基於角色的訪問控制和基於屬性的訪問控制這兩個術語是眾所周知的，但就此而言，它們不一定被很好地理解——或被很好地定義。如果基於屬性的訪問控制包括使用者角色，那麼什麼是基於角色的訪問控制?線畫在哪裡?

從根本上說，這些資料訪問控制術語——基於角色的訪問控制和基於屬性的訪問控制——命名不當且容易混淆。那是因為它們不太關注角色或屬性，而更多地關注策略的處理方式。策略是訪問控制的核心，它們的應用方式是基於角色和基於屬性的訪問控制之間的決定性因素。更重要的是，它們允許資料團隊做的事情將高效和安全的資料使用與繁瑣、冒險的做法區分開來。

什麼是基於角色的訪問控制(RBAC)?

基於角色的訪問控制(RBAC)是一種資料安全方法，它根據個人在組織中的角色允許或限制系統訪問。這表明資料消費者只能訪問與其工作職能相關的資料。基於角色的訪問控制通常管理對錶、列和單元格的訪問，並與表訪問控制列表(ACL)緊密相關，儘管後者更特定於資料消費者並且在實施組織時不是一個現實的選擇-寬的。

透過RBAC管理訪問許可權的資料團隊透過將使用者新增到角色來隱式預先確定使用者將有權訪問的內容，然後顯式確定與每個角色關聯的許可權。簡而言之：資料工程師決定誰屬於任意“事物”(在本例中為角色)，然後必須決定該“事物”可以訪問什麼。

由於這種隱含的預先確定，RBAC的一個更好的術語是基於靜態的訪問控制。一個非常適合描述RBAC的類比是編寫無法使用變數的程式碼：您一遍又一遍地編寫相同的程式碼塊，根據您希望該策略針對的角色進行細微的更改。例如，如果您想要一個策略來限制組織中每個角色對特定省的訪問，您將必須編寫34個策略(每個省一個)，併為每個策略維護34個角色。如果任何使用者可以訪問多個狀態，您將需要為這些場景建立一個策略——使用RBAC，一切都必須預先確定。

幾乎所有現代和遺留資料庫都使用基於角色的訪問控制模型來實現資料訪問控制。開源訪問控制框架，如ApacheRanger和Sentry，也遵循這種方法。然而，此類框架的侷限性很明顯，正如GigaOm的獨立研究所證明的那樣——基於角色的訪問控制的靜態性質需要比基於屬性的訪問控制多93倍的策略更改才能滿足相同的安全要求。

什麼是基於屬性的訪問控制(ABAC)?

基於屬性的訪問控制(ABAC)是一種資料安全方法，它根據分配的使用者、物件、操作和環境屬性允許或限制資料訪問。與依賴於特定於一個角色的特權來保護資料的RBAC相比，ABAC具有多個維度來應用訪問控制。這使得基於屬性的訪問控制成為一個高度動態的模型，因為策略、使用者和物件可以獨立供應，並且策略在請求資料時做出訪問控制決策。

為了理解它是如何工作的，首先理解基於屬性的訪問控制的元素是很重要的：

• 屬性：系統中任何資料的特徵。ABAC根據使用者、物件和環境的屬性做出訪問決策。

• 使用者屬性：有關資料使用者的資訊，包括姓名、職位、部門和許可權級別。

• 物件屬性：有關資料本身的資訊，包括建立者、型別、建立日期和敏感度級別。

• 動作屬性：關於主體對資料做了什麼的資訊，包括閱讀、編輯、批准和刪除。

• 環境屬性：有關資料的上下文資訊，包括位置、訪問日期和組織威脅級別。

• 策略：一組規則，根據資料的屬性規定對資料的許可或限制。

為了更具體地定義ABAC，讓我們重新審視省的示例。不必構建34個策略和角色(或更多，具體取決於使用者是否可以訪問多個狀態)，您可以將屬性視為動態變數。這意味著使用ABAC，您可以使用單個策略建立包含34個狀態的規則，如下所示：僅顯示狀態為(@user-attribute:state)的行，其中@user-attribute:state是包含它們的動態屬性狀態列表。

這個例子說明了為什麼ABAC會更準確地定義為基於動態的訪問控制。回顧我們最初的類比，ABAC就像使用變數編寫程式碼，無需一遍又一遍地建立相同的程式碼塊(策略)。上面列出的變數列表可以區分使用者是誰，他們在做什麼，以及應該在執行時動態應用什麼策略，而不是透過混淆誰有權訪問基於什麼的內容來預先定義所有策略關於角色，與RBAC一樣。

基於角色的訪問控制不是什麼

人們通常會對基於角色的訪問控制這一術語感到困惑，並假設“角色”是否可以來自多個系統和維度，就像ABAC一樣，它實際上符合基於屬性的訪問控制。雖然角色是RBAC的重要組成部分，但策略仍然是靜態應用的，而不是動態應用的。這就是為什麼基於角色的訪問控制實際上應該稱為基於靜態的訪問控制(SBAC)，而基於屬性的訪問控制應該稱為基於動態的訪問控制(DBAC)。

重要的是要記住，如果您目前正在使用RBAC，則不必放棄現有角色來切換到ABAC。您可以透過ABAC以一種新的、更強大的方式(動態地)簡單地利用它們。此外，RBAC可能會與基於標籤或基於邏輯的策略編寫相混淆，在這些策略中，策略不是基於物理表定義(如表名或列名)而是基於邏輯後設資料(如“無處不在的掩碼”)應用於表有個人身份資訊。”雖然這是構建可擴充套件策略的強大功能，並且資料屬性對於基於屬性的訪問控制至關重要，但它並未完善完整的ABAC模型。

基於角色的訪問控制的優點和缺點

• RBAC的優點

基於角色的訪問控制的主要優點是它已被廣泛採用，並允許中小型組織消除以個人為基礎實施訪問控制的情況。由於RBAC策略可以根據組織中現有的角色編寫，因此易於建立和分配。新員工和內部角色變更不再需要制定新政策;資料團隊可以簡單地分配或更新適當的角色來規定員工的資料訪問級別。

此外，資料工程師可以將單個使用者分配給多個角色並建立訪問層次結構。例如，具有“人力資源”角色分配的經理也可以被賦予“經理”角色分配，並且可能比他們的直接下屬擁有更廣泛的訪問許可權，從而允許經理覆蓋他們基於角色的限制。但是，請務必注意，並非所有RBAC實施引擎都支援分層角色結構，而是支援一種平面結構，即每個使用者一次只允許一個角色。

由於其維度(或缺乏維度)，建立基於角色的訪問控制相對容易。資料團隊對映組織內的角色併為每個角色分配訪問許可權;一旦建立，許可權將根據使用者在系統中分配的角色自動提供或取消提供。這種“一勞永逸”的方法使資料團隊無需手動授予或限制訪問許可權，但也需要他們在必要時主動設定新的角色和許可權。很多時候，這將開始脫離現實世界的組織結構，因為這意味著為了政策的目的而建立角色——記住，對於RBAC，所有政策都必須預先確定。

• RBAC的缺點

基於角色的訪問控制易於設定的相同功能也是其最大的限制之一。對於中小型組織，RBAC可能是可管理的;然而，隨著人員和角色數量的增加，資料團隊的工作很快就會變得更加複雜，尤其是在使用分層方法時。這引入了極有可能出現“角色爆炸”的可能性，這需要資料工程師管理數百或數千個使用者角色，以控制對特定表或資料庫中資料的訪問。這種時間密集型責任首先否定了實施基於角色的訪問控制的一個核心原因——節省了在個人基礎上啟用訪問控制的時間。

角色爆炸還會導致管理員無法再輕鬆瞭解哪些角色屬於哪些訪問許可權，因此將使用者需求轉換為實際角色分配可能非常難以管理。

由於資料團隊必須預先確定所有策略，因此RBAC需要在新資料到達時進行工作。在我們的美國州示例中，如果您已經構建了所有策略(每個州和角色一個)，然後開始從加拿大載入資料，除非您記得先發制人地建立策略，否則沒有人能夠看到加拿大資料在新資料到達之前。有如此多的策略、使用者和其他需要跟蹤的東西，這對任何資料架構師或工程師來說都是一個很大的要求。由於RBAC不會對組織中的任何更改進行未來驗證，因此您必須始終主動記住更新有關任何資料或組織結構更改的策略。

此外，RBAC本質上忽略了最小特權原則，該原則規定資料消費者應該只被授予對完成手頭任務所需資料的訪問許可權，而不能訪問更多。RBAC模型下提供的粗粒度訪問控制不允許資料團隊在某個時刻根據個人的需要自動設定許可權。每個自定義許可權都成為一個新角色，導致前面提到的角色爆炸。

例如，會計人員可能只處理應付賬款，沒有理由訪問員工工資單資訊。同時，同一會計部門的另一個人可能需要訪問員工稅務資訊，但沒有理由訪問合同協議。基於角色的訪問控制可能要麼給兩個人過多的訪問許可權——違反最小特權原則並可能暴露敏感資訊——要麼過於嚴格，在這種情況下，個人可能會請求資料團隊必須手動驗證和授予或拒絕的訪問許可權，增加組織的角色數量。

基於屬性的訪問控制的優點和缺點

• ABAC的優點

基於屬性的訪問控制利用資料和資料消費者的獨特屬性的多個維度來確定是授予還是拒絕資料訪問。與靜態的基於角色的訪問控制模型不同，ABAC的多維方法使資料訪問更加動態。資料團隊定義屬性併為它們建立策略，但一旦分配給系統元件，它們幾乎不需要維護。這避免了手動建立角色和隨後的角色爆炸，同時使資料訪問控制更具可擴充套件性。ABAC模型中的單個策略可以替代數百個單獨的角色，而這些角色對於使用RBAC方法實現相同的結果來說是必需的。

雖然ABAC屬性類別之一涉及使用者角色，但與RBAC不同的是，它們與其他幾個因素一起被考慮在內。因此，基於屬性的訪問控制比基於角色的訪問控制提供了更多的控制變數，使資料更加安全，並堅持最小許可權原則。這意味著資料和合規團隊可以更加確定資料不會被不應訪問的個人過度訪問。減少特定於角色的策略使生態系統更易於管理和監控，從而實現資料策略的執行和審計，從而減少任何敏感資料從裂縫中溜走並落入壞人之手的機會。

回顧我們的會計部門場景，基於屬性的訪問控制可能將兩個使用者都定義為會計人員，但是由於與物件屬性關聯的許可權——例如，合同和發票與稅務資訊——如果負責應付賬款的人試圖訪問W-9，他們將被拒絕。更進一步，負責工資核算的會計師可能能夠訪問W-9，但只能在特定時間段內或執行特定操作，例如檢視但不能編輯。這確保了正確的人可以在正確的時間訪問正確的資料，並且這樣做以不需要耗時的角色更新或建立的可擴充套件方式增加了安全層。

與RBAC不同，後者將使用者是誰與他們應該擁有的訪問許可權混為一談，ABAC將who與what分開。這種靈活性使ABAC充滿活力。此外，由於ABAC是動態的，它也是面向未來的。在美國州示例中，如果在ABAC模型下新增新的加拿大資料，則不需要新策略，因為現有策略-僅顯示stateIN(@user-attribute:state)所在的行-仍然有效。

• ABAC的缺點

雖然基於角色的訪問控制更容易建立但更難擴充套件，但基於屬性的訪問控制恰恰相反：建立更多的工作但更容易擴充套件。這是因為資料團隊的任務是定義用於定義資料訪問策略的標準，然後在其資料環境(包括本地和雲平臺)中建立並統一實施這些策略。

預測資料安全需求並制定適當的計劃來解決這些需求需要與法律和合規團隊合作，以瞭解國家安全法和個人資訊保護法等法規、合同義務和行業標準，以及其他考慮因素。雖然法律和合規團隊可以就這些要求的實質內容提供指導，但資料團隊需要執行安全、一致的保護措施。對資料訪問策略進行標準化定義是第一步，但跨越資料來源並提供ABAC的自動化資料訪問控制解決方案可以簡化流程並使其更加直觀。這可以減輕耗時耗力的前期工作負擔，並確保提供更可靠的保護。

使用哪一個：RBAC還是ABAC?

對於剛開始實施訪問控制管理的小型組織，基於角色的訪問控制似乎是一個合理的起點。由於內部使用者很少、策略很少且資料量有限，這種方法作為初步的資料保護措施更容易起步。

然而，在RBAC和ABAC之間爭論的關注現代隱私法規和/或有發展計劃的小型組織——以及包含多個資料使用者的任何其他組織——實施基於屬性的訪問控制是明智的開始。這樣做將使他們能夠更輕鬆地擴充套件，而無需在資料來源、策略和/或使用者大幅增加後重新評估其資料訪問結構並重寫其訪問控制策略。

考慮世界的現狀也很重要：雖然RBAC過去可能奏效，但複雜的資料合規性法規現在更加普遍並將繼續如此，使RBAC成為一種越來越過時的方法。無論組織規模如何，在當今市場上用於推動分析的敏感資料的激增足以讓任何資料團隊頭暈目眩。使用RBAC提供的粗粒度訪問控制，跟上快速增長和演變的資料集、用例、業務需求和監管要求是非常複雜的。相反，ABAC的動態策略建立使資料工程師更容易跟上傳入資料的步伐並相應地準備資料，而無需花費不必要的時間建立新角色來滿足新需求。