本文件為聯邦機構提供了基于屬性的訪問控制（ABAC）的定義。ABAC是一種邏輯訪問控制方法，在這種方法中，對執行操作的授權是通過評估與主體、客體、申請操作相關聯的屬性來確定的，在某些情況下，還會根據描述許可操作的策略的環境條件來確定。本文檔還提供了使用ABAC改進組織內部和組織之間的信息共享的注意事項，同時保持對該信息的控制。

關鍵詞：訪問控制；訪問控制機制；訪問控制模型；訪問控制策略；基于屬性的訪問控制（ABAC）；授權；權限。

?第一部分 ABAC的基本概念?

?理解ABAC?

全面理解ABAC需要理解邏輯訪問控制的基本原理。邏輯訪問控制的目的是保護客體（無論是數據、服務、應用程序、網絡設備還是其他類型的IT資源）不受未授權操作的影響，這些操作可能包括發現、讀取、創建、編輯、刪除和執行客體。受保護客體歸個人或組織所有，并具有某種內在價值，激勵這些所有者保護它們。作為客體的所有者，他們有責任建立一個策略，來描述可以對客體執行哪些操作、由誰執行，以及主體在什么上下文中可以執行這些操作。如果主體滿足客體屬主所建立的訪問控制策略，則該主體被授權可以對客體執行所需的操作，即該主體被授予對該客體的訪問權限。如果主體不滿足策略，則拒絕對該客體的訪問。

計算機安全架構師和管理員在邏輯上部署訪問控制機制（ACM），通過控制來自主體的訪問請求來保護客體。ACM可以使用很多方法來執行應用于客體的訪問控制策略。ACM可以定義為：

訪問控制機制（ACM）：能夠接收來自主體的訪問請求，并決定和強制執行訪問控制決策的邏輯組件。

ACM如何工作可以通過各種邏輯訪問控制模型來描述。這些訪問控制模型提供了一個框架和一組邊界條件，客體、主體、操作和規則可以在這些邊界條件上組合起來生成和執行訪問控制決策。每個模型都有其自身的優點和局限性，但重要的是要注意這些模型的發展演變過程，以充分理解ABAC模型的靈活性和適用性。

MAC/DAC

伴隨著自主訪問控制（DAC）和強制訪問控制（MAC）概念的出現，邏輯訪問控制在20世紀60年代和70年代早期應用于國防部（DoD）的某些項目中。在國防部可信計算機系統評估標準（TCSEC）或“橙皮書”[TCSEC]中有這些術語的詳細定義，在[NIST800-53]中也可以找到相關定義。

IBAC/ACL

隨著計算機網絡的發展，限制對特定受保護客體的訪問的需求刺激了基于身份的訪問控制（IBAC）的發展。IBAC使用訪問控制列表（ACL）等機制來提取那些允許訪問客體的身份標識。如果主體提供的身份憑證與ACL中保存的身份憑證匹配，則會授予該主體訪問該客體的權限。主體執行讀、寫、編輯、刪除等操作所需的每個權限都由客體屬主單獨管理。每個客體都有自己的ACL和分配給每個主體的權限集。在IBAC模型中，授權決策是在任何特定的訪問請求之前做出的，這就決定了主體也要被添加到ACL中。對于要放置在ACL中的每個主體，客體屬主必須根據客體的管理策略，來評估主體的身份、客體和上下文屬性，最后決定是否將該主體添加到ACL。這個決定是靜態的，而且客體屬主需要一個通知機制，以便在需要時能夠重新進入評估流程，并從ACL中移除某個主體，來應對主體、客體或上下文變化所帶來的影響。隨著時間的推移，如果無法刪除或撤消訪問權限，則會導致用戶權限累積。

RBAC

基于角色的訪問控制模型（RBAC）[FK92，ANSI359，SCFY96]采用了可分配給主體、具有特定權限集的預定義角色。例如，被分配“經理”和“分析員”角色的主體將能夠訪問不同的客體集。在這個模型中，訪問權限是由為每個個體分配角色的人預先隱式定義的，但最終由客體屬主在確定角色權限時明確。在處理主體的訪問請求時，訪問控制機制需要在執行訪問控制決策前，評估分配給主體的角色，以及該角色對客體所擁有的操作權限。請注意，角色可以被視為主體的一個屬性，訪問控制機制基于對“主體角色”這一屬性的計算，生成對客體的策略決策。隨著RBAC規范的流行，它減少了對ACL的需求，并使企業訪問控制能力的集中管理成為可能。

ABAC

從實施訪問控制時所使用的屬性來看，ACL和RBAC可以看做是ABAC的特例。ACL使用“身份標識”的屬性。RBAC使用“角色”屬性。它們之間的關鍵區別在于ABAC的策略概念，ABAC的策略可以表示為針對多種不同屬性的復雜的布爾運算。雖然可以使用ACL或RBAC來實現ABAC的策略目標，但是由于ABAC訪問控制的需求與ACL和RBAC模型之間的抽象層次不同，這種實現方式執行起來非常困難，而且代價非常大。ACL或RBAC模型的另一個問題是，如果AC需求發生了變化，可能很難確定所有需要更新的數據在ACL或RBAC實現中的位置。

與ABAC的訪問控制框架一致的一個例子是可擴展訪問控制標記語言（XACML）[XACML]。XACML模型使用規則、策略、基于規則和策略的組合算法、屬性（主體、資源或客體、操作和環境條件）、職責和建議等元素。它的參考體系結構包括策略決策點（PDP）、策略執行點（PEP）、策略管理點（PAP）和策略信息點（PIP）等功能來控制訪問。另一個例子是下一代訪問控制標準NGAC[ANSI499]。

一般來說，在主體發出請求之前，ABAC避免將權限（“操作-客體”對）直接分配給主體/角色/組。相反，當主體請求訪問時，ABAC引擎根據請求者的指派屬性、客體的指派屬性、環境條件以及根據這些屬性和條件指定的一組策略，來做出訪問控制決策。根據這種設計，策略在創建和管理時無需直接引用過多的用戶和客體，用戶和客體也不會直接引用策略。

01

ABAC的優點

在許多AC系統中，邏輯訪問控制解決方案主要基于主體的身份。例如，在IBAC或RBAC中，對客體的訪問權被單獨授予本地標識的主體，或者被授予該主體所屬的本地定義的角色。這種AC實現方式通常管理起來很麻煩。在非ABAC的多組織訪問方法示例（如圖1所示）中，組織A的主體（已通過身份認證）在對組織B的客體發起訪問時，需要預先在組織B為其創建身份標識（如賬號），并將該身份添加至組織B的訪問控制列表。

圖1 傳統（非ABAC）多組織訪問方法

此外，如身份和角色這樣的主體信息，在表達現實世界的AC需求時往往不夠充分。RBAC根據主體與角色的關聯做出策略決策，但它不太容易支持多因素決策（例如，基于物理位置的決策，以及醫療保險可移植性和責任法案（HIPAA）專業培訓記錄；最近關于HIPAA數據保護的培訓可能是查看醫療記錄的先決條件）。RBAC通常基于相對固定的組織位置來進行角色分配，在某些需要動態訪問控制決策的環境中，RBAC架構就會暴露其不足，因為需要創建大量的臨時角色，并限制其成員資格，通常會導致所謂的“角色爆炸”。

為了在AC決策時，避免要求主體預先獲悉客體信息，或者客體屬主預先獲悉主體信息，我們需要一種特殊的方法。通過組織間統一的主、客體屬性定義，ABAC避免了將訪問權限直接顯式地授予某個主體。此外，對于需要耗費大量時間來管理ACL/角色/用戶組的大型企業來說，ABAC模型更具靈活性。通過調整主、客體屬性定義的一致性，在不影響安全等級的同時，身份認證（主要與主體屬性有關）和授權功能（與主、客體屬性都有關系）可以在相同或獨立的基礎設施中實現。

02

ABAC的定義

ABAC的描述方式多種多樣。例如，早期一篇關于web服務的論文認為ABAC“基于請求者擁有的屬性授予其對服務的訪問能力”[WWJ04]，地理信息系統中的安全性討論將ABAC描述為一種“用與用戶相關聯的屬性值確定用戶權限”的方法[CGLO09]。

還有一篇論文將ABAC總結為一個“基于主體、客體和環境屬性，并支持強制和自主訪問控制需求”的模型[YT05]。所有這些定義的共同點是，ABAC通過將主體屬性、客體屬性和環境條件結合起來，按照它們與訪問控制規則的匹配情況來確定訪問（即對系統客體的操作）。以下是ABAC高級別的定義：

基于屬性的訪問控制（ABAC）：一種訪問控制方法，根據主體的指派屬性、客體的指派屬性、環境條件和與這些屬性和條件相關的一組策略，允許或拒絕主體對客體所請求的操作。

屬性是主體、客體或環境條件的特征。屬性信息以“名稱-值”對的形式定義。

主體是人或NPE（如對客體發起訪問請求的設備）。主體可以被指派一個或多個屬性。在本文檔中，假設主體和用戶是通過義的。

生成由ABAC系統管理其訪問的系統資源，例如包含或接收信息的設備、文件、記錄、表、進程、程序、網絡或域。它可以是資源或被請求訪問的實體，也可以是任何可被主體操作的對象，包括數據、應用程序、服務、設備和網絡。

操作是應主體對客體的請求而需要被執行的功能。操作包括讀、寫、編輯、刪除、復制、執行和修改。

策略是規則或關系的表達，它使我們能夠，根據給定的主體、客體和可能的環境條件的屬性值來確定是否允許主體所請求的訪問。

環境條件：訪問請求所處的環境/態勢上下文。環境條件是可檢測的環境特征，獨立于主體或客體，可以包括當前時間、星期幾、用戶位置或當前威脅級別。

高級ABAC定義如圖2所示，其中ABAC ACM接收主體的訪問請求，然后根據特定策略檢查主體和客體的屬性。然后，ACM確定主體可以對客體執行哪些操作。

圖2 ABAC的基本場景

1)主體請求訪問客體

2)訪問控制機制評估a）規則，b）主體屬性，c）客體屬性，以及d）環境條件，來計算策略決策

3)如果被授權，主體可以訪問客體

03

ABAC基本概念

在最基本的組成形式中，ABAC主要包括對主體屬性、客體屬性、環境條件以及訪問控制規則或策略（定義了基于主、客體的屬性組合的一些允許操作）的評估計算。所有的ABAC解決方案都包含這些用于評估屬性的基本組件，并強制執行通過這些屬性所生成的策略決策（參見下面的圖3）。

圖3 ABAC的核心機制

即使在一個小型的獨立系統中，ABAC也依賴于主體和客體的屬性分配，以及訪問規則的設計。系統中的每個客體都必須指派特定的屬性，用來描述該客體。某些屬性可能屬于某個完整的客體實例，例如“所有者”屬性。但有些屬性可能只能屬于客體的某一部分。例如，某個文檔客體的屬主為組織A，但文檔中部分內容的知識產權是組織B的，該文檔同時又是組織C所運行的程序的一部分。另一個示例，考慮文件管理系統中位于某個目錄中的某個文檔。此文檔具有標題、作者、創建日期和上次編輯日期等，所有的客體屬性都由文檔的創建者、作者或編輯者確定，還可以為其指派其他客體屬性，如歸屬組織、知識產權種類、出口管制分類或安全級別。每次創建或修改新文檔時，都必須抽取這些客體屬性。這些客體屬性通常嵌入在文檔中，但也可以由專門的應用程序將其提取到一張單獨的數據表中，引用合并或管理。

使用系統的每個主體都必須指派特定的屬性。以用戶訪問文件管理系統為例。管理員在系統中將用戶映射為主體，并將該用戶的特征轉化為主體屬性。此主體可能有一個名字、角色和組織隸屬關系。其他主體屬性可能包括美國公民身份、國籍和安全許可等。這些主體屬性由組織內負責維護文件管理系統主體標識信息的機構分配和管理。在添加新用戶，刪除老用戶，或者主體（即用戶）特征發生變化時，這些主體屬性可能就需要更新。

對于系統中的每個客體來說，必須至少存在一條策略，用于描述該客體的訪問規則，其中包含所允許的主體、操作和環境條件。此策略通常從描述組織業務流程和運營規范的文檔或程序性規章制度派生。例如，醫院制度規定只有經授權的醫務人員才能訪問患者的病歷。在實際系統中，如果客體是“類型”屬性為“患者病歷”的文檔，訪問控制機制就會篩選出“病歷訪問規則”并計算策略決策，從而拒絕那些“人員類型”屬性為“非醫務支持人員”的主體的讀取請求。注意，這只是實現屬性和規則之間關聯的方法之一。

實現主、客體屬性綁定的規則間接地指定了特權（即哪些主體可以對哪些客體執行哪些操作）。允許的操作規則可以通過多種計算機語言表示，例如：

?◆ 用屬性和條件的布爾組合來表示特定操作的授權條件

?◆ 能夠把主、客體屬性和許可操作關聯在一起的某種關系運算

一旦建立了客體屬性、主體屬性和策略，就可以使用ABAC保護客體。訪問控制機制通過限制手段（只有允許的主體能夠對客體執行允許的操作）來介入對客體的訪問。ACM將策略、主體屬性和客體屬性組合在一起，然后根據策略中定義的算法計算和執行策略決策。ACM必須能夠管理策略的決策和執行流程，包括確定要檢索的策略、要以何種順序檢索何種屬性以及從哪里檢索屬性，然后，ACM執行必要的計算以便生成策略決策。

ABAC模型中可實現的策略僅受限于計算機語言的策略表示能力和可用屬性的豐富性。這種靈活性使得不必單獨指定每個主體和每個客體之間的關系，就可以實現最大范圍內的主體對最大范圍內的客體的訪問控制。例如，一個主體被分配了一組基于工作崗位的主體屬性（例如，南希·史密斯是心臟科的護士），客體在創建時被分配了客體屬性（例如，包含心臟病患者病歷的文件夾）。主管機構制定相應的規則來管理允許的操作（例如，心臟科的所有護士都可以查看心臟病患者的醫療記錄）。這種靈活性使得在主體、客體和屬性的整個生命周期中，屬性和它們的值都可以非常方便地修改。

為受規則集（指定了哪些操作是允許的）控制的主體和客體提供屬性的這種做法，使得無限多的主體能夠請求對客體執行操作——完全不需要客體屬主或規則生成器事先知道主體的任何信息。當新的主體加入組織時，也不需要修改規則和客體。只要主體被分配了訪問客體所必需的屬性（例如，心臟科的所有護士都被分配了這些屬性），不需要對現有規則或客體屬性做任何修改。這種特性通常被稱為適應外部（非預期）用戶，是使用ABAC的主要好處之一。

與其他一些方案相反，在ABAC的定義中，操作沒有“屬性”。如定義所述“屬性是以‘名稱-值’對形式所提供的信息”。例如，“read = all”（或“all = read”）都是不合適的。操作可以有許多類型或類別，它們不是“屬性”，而是一組固定的值。可以將操作本身設置為“屬性名”，例如“operation = read ”，但這將是操作的唯一屬性，而且是多余的。

為實現追責能力，需要跟蹤特定主體（與特定用戶有關）對客體的訪問。如果訪問決策是基于屬性的，但是特定的訪問請求和決策不能追溯到主體或用戶ID，則可能會失去追責能力。

04

企業ABAC概念

雖然ABAC推動了信息共享，但在企業中部署實現ABAC時，其關鍵組件會變得更加復雜。隨著企業規模的擴大，部署架構中需要復雜的、甚至是獨立建設的管理設施，以確保企業范圍的一致的信息共享、策略和屬性的使用、受控的數據分發，以及訪問控制機制的實施。

企業：一組需要相互協作和聯合的實體，實體之間要求支持信息共享和管控。

圖4展示了部署企業ABAC所需的主要組件。有些企業已具備實施ABAC的基礎。例如，大多數企業都有某種形式的身份和憑證管理系統，用來管理主體屬性（如名稱、唯一ID、角色、許可等）。同樣，許多企業可能有一些組織策略或準則來建立訪問規則，對訪問企業客體的主體進行授權。但是，這些規則通常不是以機器可執行的格式編寫的，無法在不同的應用程序中使用。ABAC策略必須以機器可執行的格式實現，存儲在策略庫中，并發布給ACM使用。這些數字策略包括計算訪問控制決策所需的主體和客體屬性。企業主體屬性必須通過主體屬性管理組件創建、存儲，并在企業各組織之間共享。同樣，企業客體屬性必須通過客體屬性管理組件建立并綁定到客體。最后，剩下的任務就是部署ABAC訪問控制機制。本節的其余部分將詳細介紹企業級ABAC的主要組件。

圖4 企業ABAC的場景示例

4.1

早期的訪問控制模型

自然語言策略（NLP）是策略的高級表達形式，它定義了如何管理信息訪問，以及在什么情況下誰可以訪問什么信息。NLP用人類可以理解的語言來表述策略，但是在ACM中可很難直接使用。NLP含混不清的語義，使它很難通過形式化的方法，推導出可操作的元素，最終導致企業策略無法編碼為計算機可以理解的形式。然而，NLP可能是程序專用的（注：指由/為專門的應用編寫），考慮應用系統的情況，NLP適用于定義跨多個應用的主體行為的策略。例如，NLP可能適用于針對組織單位內部或跨組織單位的客體的策略，或者基于知其所需、能力、授權、義務或利益沖突因素等情況下的策略。這些策略可能需要跨越多個計算平臺和應用程序。NLP在本文件中定義如下：

自然語言策略（NLP）：用于描述企業客體的管理和訪問方式的語句。NLP是可以轉換為機器可執行的訪問控制策略的自然語言表述。

給出與企業內每個組織都相關的NLP，下一步是將這些NLP轉換成一組可以在企業內部ACM中部署執行的通用規則。為了實現這一步，必須先確定策略中需要的主體/客體屬性的組合和允許的操作。通常，這些值在不同組織中可能是不同的，因此需要組織間達成某種形式的共識，或者將其映射到每個組織的現有屬性中，以實現企業內不同組織間的互操作性。最后，達成一致的主、客體屬性列表、許可操作和來自現有組織特定屬性的所有映射被翻譯成機器可執行的格式。

NLP實現必須包含數字策略（DP）算法或機制。為了提高性能和簡化規范，NLP可能需要分解并轉換為不同的DP，以適應企業基礎設施中已有的功能組件。DP在本文件中定義為：

數字策略（DP）：直接編譯成機器可執行代碼或信號的訪問控制規則。主體/客體屬性、操作和環境條件是DP的基本元素，DP規則的編譯結果由訪問控制機制執行。

多個DP可能需要元策略（Metapolicy）或指導DP使用和管理的策略，來處理DP的分級授權、沖突消除以及存儲和更新。MP用于管理DP。根據復雜性等級，基于NLP所指定的策略優先級和組合策略的結構，可能需要層次化的MP。MP在本文件中定義為：

元策略（MP）：與策略相關的策略，或用于管理策略的策略，例如優先級的分配和DP的沖突消除方法或其他MP。

一旦開發定義了DP和MP，接下來需要對它們進行管理、存儲、驗證、更新、按優先級排序、消除沖突、共享、引退和部署執行。上述每一個操作都需要通過一組功能來實現，這些功能通常分布部署在整個企業中，統稱為數字策略管理（DPM）。組織中可能有多個策略主管部門和層級化的管理架構，他們在企業策略上可能存在差異，DP和MP的管理規則可能需要由總部機構決定。

正確的DP定義和開發對于識別出訪問控制決策所需的主、客體屬性至關重要。請記住，DP語句由主體和客體屬性對，以及滿足一組允許操作所需的環境條件組成。一旦確定了滿足企業客體集的整個允許操作集所需的主體和客體屬性集，該屬性集就包含了滿足ABAC決策定義、分配、共享和評估所需的整個屬性集。因此，在實現企業ABAC功能時，對NLP和DP的定義必須通過屬性來實現。有關DP管理的其他問題，請參見本文件第3節。

4.2

企業ABAC中的屬性管理

接下來，考慮在審查NLP和DP時定義的屬性列表。如果沒有足夠的客體和主體屬性集，ABAC就無法工作。屬性需要被命名、定義、確定賦值范圍、分配一個模式，并與主體和客體建立關聯。主體屬性需要由主管部門建立、發布、存儲和管理。客體屬性必須被指派給客體。跨組織共享的屬性還需要定位、檢索、公布、驗證、更新、修改和撤消。

主體屬性由屬性主管機構提供，這些機構通常通過屬性管理點來管理屬性，而且通常有多個主管部門，分別負責對不同屬性的管理。例如，安全部門可能主管“許可”屬性，而人力資源部門可能主管“姓名”屬性。為支持主體跨組織訪問客體而共享的主體屬性必須在組織之間是一致可比的，或映射到等價策略進行部署執行。例如，組織A中具有“Job Lead”角色的某個成員希望訪問組織B中的信息，但組織B使用“Task Lead”表示等效的角色。這個方式還適用于企業屬性模式與特定應用模式之間的映射，特別是在定義企業模式之前已經構建的，或使用自有內置模式的商用現貨（COTS）產品。組織必須規范主體屬性名稱和值，或者為所有組織維護等價術語的映射，這應該由總部機構來負責管理。

在創建或修改客體時，需要建立、維護客體屬性，并將其指派給客體。雖然可能不需要在整個企業中使用一套通用的客體屬性，但應該一致地使用客體屬性，來滿足企業策略的要求，并且應該為其他人公布可用的屬性集，以便他們可以標記、標注或以其他方式將這些屬性應用于他們自己的客體。有時，還需要確保客體屬性沒有出于滿足訪問請求的目的，而被篡改或更改。客體可以通過密碼技術綁定到其客體屬性，以識別客體或其相應屬性是否被篡改。必須部署某種機制以確保所有客體被創建并指派適當的客體屬性集，以滿足ACM中實施的策略，部署必要的企業級的客體屬性管理器應該可以滿足這些需求。

在管理屬性的過程中，出現了“元屬性”（即屬性的特征）的概念。元屬性作為擴展屬性信息應用于主體、客體和環境條件，用于實施更細化的策略，這些策略包含與屬性相關的信息（用于管理企業屬性管理所需的數據）。元屬性在本文檔中定義為：

元屬性：在ACM中實現MP和DP處理時所必需的與屬性相關的信息。

有關屬性管理的其他問題，請參見本文檔的第3節。

4.3

企業ABAC中訪問控制機制的部署實施

最后，考慮ACM在整個企業中的分布和管理。根據用戶的需求、企業的規模、資源的分布以及需要訪問或共享的客體的敏感性，ACM的分布對于ABAC實現的成功至關重要。ACM的功能組件可以物理上和邏輯上分散部署在企業中，而不是像ABAC的系統級視圖描述的那種集中式。

ACM中有幾個重要的功能“點”，用于檢索和管理策略的服務節點，其中包含了用于處理策略上下文或工作流、以及檢索和評估屬性的一些邏輯組件。圖5給出了這些功能點：策略執行點（PEP）、策略決策點（PDP）、策略信息點（PIP）和策略管理點（PAP）。這些組件處于同一環境中，相互配合以實現訪問控制決策和策略執行。

圖5 ACM功能點示例

PDP對DP和MP進行評估以產生訪問控制決策。PDP和PEP在本文件中定義如下：

策略決策點（PDP）：通過評估適用的DP和MP來計算訪問決策。PDP的主要功能之一是根據MP調節或消除DP間的沖突。

PEP執行PDP做出的策略決策：

策略執行點（PEP）：以執行策略決策的方式響應主體對受保護客體的訪問請求；訪問控制決策由PDP生成。

PDP和PEP功能可以是分布式的或集中式的，并且可以在物理和邏輯上彼此分離。例如，企業可以建立一個集中控制的企業決策服務，該服務評估屬性和策略，生成策略決策并傳遞給PEP。這種方式方便對主體屬性和策略進行集中管理和控制。或者，企業內的本地組織可以利用集中的DP存儲庫，實現獨立的PDP。ACM組件的設計和部署需要一個管理單元來協調ABAC的各組件功能。

要計算策略決策，PDP必須具有有關屬性的信息，這些信息由PIP提供。本文件中的PIP定義為：

策略信息點（PIP）：作為屬性或策略評估所需數據的檢索源，提供PDP做出決策所需的信息。

在執行這些策略決策之前，必須對它們進行徹底的測試和評估，以確保它們滿足預期的需要，這些功能由PAP執行。PAP可定義為：

策略管理點（PAP）：提供一個用戶接口，用于創建、管理、測試和調試DP和MP，并將這些策略存儲在適當的策略庫中。

最后，作為ACM中的可選組件，上下文處理器負責管理策略和屬性的檢索順序。對實時性要求比較高的場合，或“決策結果要求立即終止訪問”的那些策略來說，該部件非常重要。例如，需要在訪問請求之前提前檢索屬性，或者緩存屬性以避免在訪問請求時檢索所帶來的時間延遲。上下文處理器還需要與PIP協調，向請求上下文添加屬性值，并將規范形式（例如XACML）的授權決策轉換為本機支持的格式。上下文處理器可以定義為：上下文處理器：按工作流邏輯定義的順序，檢索并執行策略和屬性。

總結

以上是生活随笔為你收集整理的基于属性的访问控制（ABAC）定义与思考 ——ABAC的基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。