基于属性的访问控制（ABAC）定义与思考 ——企业ABAC的实施问题
本文整理了《Guide to Attribute Based Access Control (ABAC) Definition and Considerations》一文核心思想和觀點的第二部分《企業ABAC的實施問題》，第一部分詳見《ABAC的基本概念》，如需完整版下載請點擊文末閱讀原文。
關鍵詞：訪問控制；訪問控制機制；訪問控制模型；訪問控制策略；基于屬性的訪問控制（ABAC）；授權；權限。
?第二部分?
企業ABAC的實施問題?
在跨企業部署ABAC系統之前，必須考慮許多因素。在充分考慮目前技術狀況和總結聯邦政府內部多次嘗試在大型企業中部署ABAC的經驗教訓的基礎上，整理了一些指導原則供讀者借鑒。這些建議按照圖6所示的NIST系統開發生命周期（SDLC）的各個階段分別給出。有關SDLC的更多信息，請參閱[NIST800-100]。企業ABAC部署主要考慮前四個階段：啟動、獲取/開發、實施/評估和操作/維護。本節專門關注這些階段。
圖6 ACM NIST系統開發生命周期（SDLC）
企業ABAC的開發和部署需要考慮許多影響其設計、安全性和互操作性的因素。這些因素導致了一系列應該考慮的問題：
?? ABAC實施的項目論證。開發/獲取新功能和從舊功能過渡的成本是多少？ABAC提供了哪些重要的好處？ABAC引入了哪些新的風險（如果有的話），需要哪些新的管理結構來管理共享的功能和策略文檔？這些策略以前都是由人工介入的決策。哪些數據集、系統、應用程序和網絡需要ABAC功能？數據丟失或誤用如何管理？
?? 了解運營需求和整個企業架構。如何管理、監視和驗證權限以實現合規？企業將公開哪些接口和客體用于信息共享？將使用什么ACM？如何共享和管理主體和客體屬性？訪問控制規則是什么？它們是如何抽取、評估和執行的？企業內部如何管理信任？
?? 建立或完善業務流程以支持ABAC。訪問規則和策略是否被充分理解和記錄？如何識別和分配所需的屬性？如何以層次化方式應用多個策略并消除沖突？如何處理訪問失敗？新策略由誰創建？如何共享和管理公共策略？
?? 開發和獲取一套可互操作的能力。互操作性如何實現？如何將身份管理中的主體屬性集成到ABAC中？如何處理不同或特殊的身份需求？如何跨企業實體共享和維護主體屬性？身份驗證、授權、屬性管理、決策或強制執行能力的集中化實現和分布式部署的利弊是什么？如何在策略決策中使用環境條件？在策略決策中，信任在安全、質量、準確等層面是如何量化、傳遞和使用的？如何在組織之間映射主體屬性？如何制定策略以整合最新的可用主體、客體和環境條件屬性集？
?? 性能評估。如何為未連接、帶寬受限或資源受限的用戶管理主體屬性？企業新成員的接口規范如何可用？屬性和策略更改的質量和及時性如何衡量和實現？整個系統和端到端性能是否足夠？
以下各節將更詳細地討論這些原則和問題。
壹
啟動階段的考慮
在啟動階段，企業評估ABAC系統的需求及其潛在用途，確定ABAC系統是一個獨立的信息系統，還是已有系統的一個組件。一旦這些任務完成并確定ABAC的能力需求，在ABAC系統獲得批準之前，還需要一些工作，包括明確定義目標和高級需求。在這個階段，企業需要定義ABAC系統的高級業務、操作需求以及企業架構。
1
ABAC項目的論證
與任何主要系統的部署一樣，在部署企業ABAC之前，應進行重要的需求評估、商業研究和規劃活動，以確定在給定目標環境下，ABAC是否是正確的訪問控制方式。ABAC的優點是可以在事先不知道或不了解主體的情況下提供訪問控制能力，并對有限的一組任務或業務關鍵目標提供大規模的企業信息共享。
在生成任何技術需求或做出部署決策之前，評估和論證ABAC項目以及定義該項目的企業目標非常重要。實施企業ABAC會帶來巨大的開發、實現和操作成本，企業客體的共享和保護方式也會發生改變。來自其他組織的案例研究或經驗報告可能有助于規劃ABAC的部署。對于有限的一組客體，采用增量方法逐步實現ABAC保護可能更為實際。這一實施方式將在最大程度上建立和利用適合于整個企業的策略和屬性。逐步構建ABAC功能所帶來的反饋能夠完善策略和屬性定義，并行使必要的治理和配置管理功能，以支持整個企業更廣泛地使用ABAC。應當指出，如果不解決以下各小節中提出的問題，企業在部署ABAC時可能會遭受重大延誤并產生額外費用。
2
可擴展性、可行性和性能要求
在考慮ABAC產品或技術的部署時，可擴展性、可行性和性能是需要考慮的重要問題。企業ABAC（允許一個組織訪問同一企業中由另一個組織管理的客體）需要ABAC組件之間的復雜交互。通常，這些組件跨組織邊界分布在整個企業中，有時分布在不同的網絡上。企業越大、組織機構越多樣化，這些交互就越復雜。以往通過一個簡單的請求就可以訪問文件庫里的文檔，現在變成了，從企業策略庫拉取策略、從物理/邏輯上分散的多個屬性源拉取不同的屬性、通過第三方驗證與該文檔相關的客體屬性的完整性、在企業的某個IT設施上生成策略決策，最后又在另一個IT設施上執行該策略決策。可行性評估應該檢查業務應用是否支持ABAC，無論它是原生地支持，還是通過第三方來實現支持。所有這些潛在的交互都存在性能成本，在確定通過企業ABAC實現共享的客體范圍時，必須對這些成本進行評估。為了減輕潛在的性能和可擴展性問題，應該考慮各種體系結構。ABAC組件的部署分布應該考慮到底層企業架構，以及要共享的數據和客體的位置。例如，PDP和PEP可部署在同一個管理單元下。
2.1
開發維護費用
雖然ABAC在跨企業部署時提供了許多重要的新功能，但從長遠來看，ABAC的開發、部署和維護成本可能會超過它的價值。此外，為了使用ABAC而對應用程序進行改造的成本與采購、設置和維護授權基礎設施（指ABAC系統）是完全分開。雖然可以通過放棄當前的解決方案來節約一些維護成本，但這些節余的部分很快就會被ABAC的主體屬性和策略的管理和維護成本，以及對新系統的支持成本抵消掉。為了確定風險成本和安全成本之間的平衡點，ABAC這種更精確、一致和靈活的安全特性必須被仔細地評估并量化。綜合考慮到這些因素，ABAC并不是解決所有訪問控制問題的通用方案，但可證明的是，在主體和客體具有各種不同屬性的環境中，如果訪問決策涉及這些屬性之間的復雜關系，那么ABAC就是一種可行的解決方案。
2.2
向ABAC遷移的成本
伴隨著遷移到ABAC，管理和業務流程面臨重大的轉變，即客體由企業制定的策略和企業控制的屬性（有時還包括本地控制）控制。這些客體現在可能需要與一組其他的特性相關聯，而這些特性可能并未在訪問控制中使用過。習慣于登錄網絡后隨意訪問資源的用戶可能不會再擁有便利。雖然策略制定者將盡其所能制定出反映當前的任務和業務需求的策略，但在訪問那些關鍵任務或業務功能時，總會出現一些意料之外的拒絕訪問。
隨著ABAC產品的部署實現和企業訪問控制的變化，新的流程和功能需要集成到用戶的日常業務流程和企業策略中。在遷移過程中，重要的是確保用戶理解為什么要改變這些訪問控制，以及這些更改會對業務的完成產生什么影響。這些用戶需要在新的ABAC系統和過程中接受培訓。部署ABAC所帶來的這些變化需要適當地傳達給用戶，以便展示其價值，包括更好的用戶體驗、增強的安全性和對關鍵信息的保護、新的ABAC系統的要求以及將逐步淘汰的傳統訪問控制系統。用戶也可能對現有業務流程比較滿意，不能立刻看到部署ABAC所帶來的價值，那就需要重點強調ABAC在增強企業安全態勢方面與現有的訪問控制機制之間的差別。
2.3
權限審查和授權監控的需求
有的企業可能希望對主體及其權限能力進行審查，包括對與客體關聯的訪問控制條目的審查。簡單地說，在發出請求之前，需要知道每個人有哪些訪問權限，有時被稱為“事前審計”，通常在證明“合規性”（符合特定的法規或指令）的時候，是非常必要的。另一個常見的審查目的是確定誰有權訪問特定客體或特定資源集。ABAC系統可能不適合有效地進行這些審計。相反，ABAC的一個關鍵特性是客體屬主能夠在事先不知道主體的情況下保護和共享客體。對能夠訪問給定客體的主體集的計算需要大量的數據檢索和運算量，這可能需要每個客體屬主通過模擬企業中每個已知主體的訪問請求來計算。限制ABAC實現的范圍有助于預先確定訪問授權，但如果企業需要此類驗證，則應研究驗證授權有效性的其他方法。
2.4
理解客體保護要求
企業的不同位置存在大量不同的操作和客體類型，需要對其強制執行AC策略，包括操作系統、應用程序、數據服務和數據庫管理系統。盡管可能存在一些NLP來輔助訪問授權，但大多數客體的訪問控制是通過由本地業務規則管理的本地組策略實現的，或者取決于一些未記錄的評估因素和非標準的潛規則。實現ABAC首先需要對客體及其保護要求有一個透徹的理解，否則開發和實現企業ABAC的成本將急劇增加。建議首先將企業ABAC部署應用于具有良好定義、控制，以及文檔記錄的客體。
2.5
企業治理與控制
成功的企業ABAC需要協調和確定一些業務流程和技術因素，也要建立企業的職責和主管。如果沒有適當的治理模型，企業將開發出煙囪式解決方案，企業的互操作性將大大降低。建議組建一個企業治理機構來管理所有身份、憑證和訪問管理功能的部署和操作，并建議每個下屬組織建立一個類似的機構，以確保ABAC部署實現過程中的管理一致性。此外，建議治理機構開發一個“信任模型”，用于描述信任鏈，并幫助確定信息和服務的所有權和責任，確定對附加策略和治理的具體需求，以及確定驗證或實施信任關系的技術方案。信任模型也有助于組織明確，如何使用和保護他們共享信息，以及怎樣信任來自其他組織的共享信息。
此外，企業授權服務應與安全審計、數據丟失預防、安全配置管理、持續監控和網絡防御能力緊密集成。授權服務本身不足以保障網絡上關鍵任務客體所需的安全性，應充分理解企業安全需求以及ABAC實施將帶來的影響。例如，當使用分布式ACM架構時，訪問控制決策和事件的審計能力可能會受到影響。
ABAC系統可以受益于企業環境中部署的信任框架。通過對使用ACL的傳統信任鏈和使用ABAC的信任鏈比較（圖7和圖8）可知，要使ABAC正常工作，需要有許多更復雜的信任關系。ACL由客體屬主或管理員建立，通過將用戶添加到ACL來設置對客體的訪問，實現客體訪問規則的執行。在ABAC中，信任的根來源于不同的起點，例如主體屬性的主管部門或策略管理員。
圖7 ACL信任鏈
圖8 ABAC信任鏈
在管理信息共享的固有風險、部署企業ABAC解決方案時，必須從兩個角度考慮風險。首先，ABAC解決方案可以被視為諸多保護企業、降低風險的安全控制選項之一。ABAC的實施可以降低未授權操作訪問受保護資源的風險，因為ABAC可以通過一致地實施執行易更新的精確策略，應對不斷變化的威脅。第二，ABAC將受保護的客體暴露給未知實體訪問，ABAC可能增加，也可能減少企業的運營風險。假設屬性發布過程是正常的，ABAC系統在一定程度上依賴于屬性發布機構。風險源的多樣性給ABAC帶來了許多挑戰，必須通過治理和正式的信任模型來應對這些挑戰。
在建立ABAC固有風險的治理模型時，重要的是確保與每個責任機構建立機制和協議，以便監測和管理這些信任根以及由于不正當訪問而產生的任何責任。
3
開發操作需求和體系結構
在實施ABAC解決方案之前，必須滿足下列幾個頂層的操作和架構（architecture）規劃需求：
?? 首先，確定將由ABAC共享和保護的客體。
?? 第二，定義規則或策略。
?? 第三，與主、客體屬性的主管部門一起，協調訪問控制規則開發人員，確定和定義主、客體屬性。
?? 第四，開發與策略編寫、驗證和管理相關的流程。
?? 最后，確定ACM在企業中的部署位置，與屬性、策略和策略決策相關的請求和響應如何產生。
3.1
客體標識和策略分配
ABAC解決方案需要共享和保護的客體可能隨著組織要求的差異而有所不同。每個客體或客體類都必須被標識出來，保護每個客體或客體類的策略或規則也都必須寫入文檔。需要建立一組業務流程來給在ABAC部署范圍內創建的每個新客體建立標識、分類和分配策略。
3.2
屬性體系結構
通常，訪問控制策略通過一些包含屬性的條文來描述。因此，策略中所有用到的屬性都必須建立、定義，并受賦值范圍的約束。定義"屬性及其賦值范圍"的數據模式（Schema）必須發布給所有參與者，以幫助客體屬主開發規則。一旦建立了屬性和賦值范圍，就需要建立為主體和客體提供屬性和適當屬性值的方法，以及包含屬性存儲庫、檢索服務或完整性檢查服務的體系結構，為了實現這些屬性的共享，還需要為其實現開發接口和共享機制。
3.3
主體屬性
人作為主體時，其主體屬性通常是由企業組織提供，并且可能由幾個不同的主管部門（人力資源、安保、組織領導等）提供。在這種情況下，獲取權威數據的方法是眾所周知的。例如，只有安保部門能夠基于官方的個人許可信息，提供許可屬性或對許可屬性值的斷言；個人不能修改自己的許可屬性值。其他主體屬性可能涉及主體的當前任務、物理位置和發送請求的設備等；需要開發評估模塊來確保此類主體屬性數據的質量（精準度，有效性等）。
權威部門提供的主體屬性應該在質量、保證、隱私和服務期望方面具有適當的可信性。這些期望可以在屬性實踐聲明（APS）中定義。APS提供將在整個企業中使用的屬性列表，并且可以標識企業的權威屬性源。另外，還需要進一步擴展網絡基礎設施功能（包括維護屬性機密性、完整性和可用性的能力），以便在組織內部或跨組織共享和復制權威的主體屬性數據。
3.4
客體屬性
客體屬性通常在客體創建時設置，可綁定到客體或存儲在客體以外并被客體引用。顯然，訪問控制機構無法密切監測所有事件。通常，這些信息是由非安全流程和需求驅動的。完好的屬性數據才能支持完好的策略決策，必須采取某種措施，確保客體屬性只能以客體屬主或管理員認為合適的流程來進行分配或驗證。例如，客體屬性不能被主體修改以操縱訪問控制決策的結果。訪問控制機制在計算策略決策時，客體屬性必須可供檢索。創建客體屬性的其他注意事項包括：
???一般來說，用戶不知道客體屬性的值（例如，給定用戶被授權訪問哪個敏感分區）。這應該在ACM中考慮，以便用戶只看到適用于他們的值。
?? 與主體屬性一樣，需要一個定義屬性名和允許值的客體屬性模式。
?? 屬性需要在DP、MP和NLP中保持一致。
聯邦政府和商業界已經做出了許多努力來創建客體屬性標記工具，這些工具不僅提供數據標記，還提供客體屬性的加密綁定和客體屬性字段的驗證，以滿足訪問控制決策要求。
3.5
環境條件
環境條件是指與特定的主體或客體無關，但在決策過程中必需的上下文信息。與主體和客體屬性不同的是，它們不是因管理需要才被創建和管理，而是內在的、必須由ABAC系統檢測到。環境條件（如當前日期、時間、位置、威脅和系統狀態）通常在授權訪問請求時根據當前匹配的環境變量進行評估。環境條件允許ABAC策略定義例外規則，或者只通過主體/客體屬性無法描述的動態AC規則。在使用環境條件編寫ABAC規則時，需要確保環境條件變量及其值是全局可訪問的、防篡改的、并且與當前的使用環境相關。
3.6
訪問控制規則
在ABAC中，所有AC規則都必須包含一些屬性的組合和允許操作還可能包括條件、層次化的繼承和一些復雜邏輯，它們為ABAC實現提供了豐富的選項。規則集和它們到客體的應用方式都必須進行適當的管理。規則必須準確、完整地反映NLP，并且由權威部門（企業組織或資源屬主）開發定義、應用、維護、共享和斷言。ABAC支持來自多個利益相關方的多個規則，也需要新的技術來協調不同的規則，以獲得信息共享與保護之間的平衡。在某些情況下，可能需要限制哪些規則對哪些客體可見，以降低未經授權的主體通過操縱屬性來獲取授權的可能性。在其他情況下，被拒絕訪問的主體應該需要一種方法驗證或糾正那些導致拒絕訪問的條件。某些組織可能希望跟蹤訪問被拒絕的情況，以便檢查規則是否合適。同樣，規則定義和部署機制和過程中應該包括強大的規則沖突消解（解決不同規則的決策結果不一致的問題）能力，以便確定規則沖突和解決方式。
3.7
訪問控制機制與上下文處理
為避免客體保護中的沖突和脆弱性，ACM的組成結構和部署方式必須預先確定。例如，如果某一客體由兩個不同的組織持有，未經授權的主體不應該僅通過限制較弱的組織的授權，就獲得對象的訪問權。企業組織應以一致的方式管理、維護和使用ACM，以確保互操作性和全面的安全性。
ACM檢索信息、計算決策和執行決策的順序可能因實現的差異而大不相同，甚至在計算訪問控制決策時還要考慮環境條件。這就是上下文處理，簡單指ACM在收集決策所需數據時執行的工作流。
此外，出于性能和可擴展性的考慮，策略、屬性和決策信息在整個企業中存儲和交換的位置，以及如何實現也是一個需要的考慮因素。
貳
采購/開發階段的考慮
在采購/開發階段，企業通過設計、購買、編程、開發等各種方式來搭建系統。通常，在此階段，組織準備要在企業范圍內運行的業務流程，并定義要部署和集成的系統。在這個階段的第一環節，企業應該同時定義系統的安全性和功能需求。在這一階段的最后環節，在項目進入實施/評估階段之前，組織應對技術和安全特性/功能進行開發性測試，以確保它們能夠按預期運轉。
1
業務流程生成和部署準備
1.1
規則文件
對于由組織控制的每種類型的客體，都應該有一組對應的訪問控制規則記錄在NLP中。（用例可能是企業為一組對象定義NLP的最簡單的方法）這些規則應該規定主體能或不能與這些由組織控制的數據或服務進行交互（包括創建、查看、修改、刪除、轉發），以及在什么上下文或環境條件下擁有這些特權。記錄這些規則的時候，應當包含組織對適用策略和指南的解釋、適用客體的特殊敏感性以及與這些客體相關的用戶社區知識。
記錄NLP有助于DP的開發，并提供從數字策略到書面策略的追溯。例如，許多組織難以將授權功能從ACL遷移到更健壯的ABAC基礎設施，原因在于缺少NLP。例如，在接收到訪問請求時，數據屬主按照某種原則（通常沒有文檔記錄）進行評估，“此人是否為工作組成員？”或“我對他或他的單位熟悉嗎？”，然后在將請求者的名稱添加到ACL之前作出訪問決策。有良好文檔記錄的NLP能夠將訪問控制的決策過程，從人工生成的方式過渡到由一致的自動策略驅動生成的方式。
1.2
本地策略
除非上級部門或義務要求，下級組織不應降低本地策略的嚴格程度。如果企業中的下屬組織能夠獨立地放寬企業策略制定的限制條件，那么系統固有的安全性就會受到破壞，可能允許本地訪問本應被禁止的企業客體。
在聯合企業中，本地訪問策略實現的時候，需要基于主體所在的組織到本地組織的屬性映射，并能夠反映與客體關聯的企業訪問控制策略。根據組織之間的共享協議，具有共享所有權或控制權的客體應根據最嚴格的策略進行保護。
1.3
屬性的一致性約定與理解
企業主體和客體屬性的定義和取值范圍必須是有效且一致的，以便授權組件能夠在整個企業中，按照全局一致的已知屬性值計算授權決策。無論這些屬性是在組織內專用還是跨組織使用，屬性的生命周期管理是屬性主管部門的責任。
1.4
理解屬性的意義
屬性服務提供者需要描述屬性及其與其他屬性的關系，以便使用者能夠正確、有效地使用屬性。屬性服務提供者必須記錄屬性值的權威定義和含義，并指導這些屬性的使用。在某些情況下，必須將屬性與其他屬性結合使用，才能建立有效的上下文，例如角色和組織的組合——除非角色定義在組織上下文中，否則它沒有任何意義。例如，對于整個組織的運營總監，他的職責可能包括財務、人力資源、法律和其他部門，其上下文含義與IT部門Web服務分部的運營總監完全不同。如果不了解屬性、上下文，也不理解屬性值對策略決策的意義，那么DP和決策可能會在信息不足的情況下或使用錯誤的算法生成。
1.5
訪問失敗的處理過程
應建立一套針對拒絕訪問和運行錯誤等異常情況進行處理的流程/程序，以便在給定任務、角色以及確保知其所需原則的前提下，為用戶提供一種能夠矯正/調整訪問決策結果的方法。由于在ABAC中，授權服務從傳統的將帳戶添加到ACL中的方式逐漸成熟，發展到自動決策的方式，系統用戶很難理解和矯正訪問拒絕（指矯正決策結果）。ABAC為獲得訪問授權而建立的“屬性發現”和“屬性獲取”流程將有助于簡化這種轉變,這也可以擴展到解決連接丟失等訪問授權服務組件時的問題。
在任務關鍵型角色中，主體應該能夠理解這些限制，并請求一些例外的操作，如轉向官方的幫助系統，或者嘗試其他路徑來訪問等效的信息或服務。
1.6
屬性的隱私考慮
開發ABAC應依從所有適用的隱私法律、指令和政策。由于主體屬性的個人性和描述性，屬性共享的實施可能會由于無意中將屬性數據暴露給不受信任的第三方，或將敏感信息聚集在保護程度較低的環境中，而增加侵犯個人身份信息（PII）隱私的風險。支持“屬性共享”的組織應通過信托協議，以確保正確處理PII和執行PII條例。這些協議應詳細說明信任鏈中所有組成部分對PII的授權使用和處理，以及驗證、補救和裁定違規責任的方法。第二個考慮是，主體屬性可以通過授予/拒絕決策的模式來呈現。如果主體訪問某個特定資源，則該主體必須具有該資源的訪問規則中指定的屬性，組織應保護訪問日志或其他可能泄漏授予/拒絕決策的信息。
1.7
數字策略創建和維護
系統中定義的每個DP都應滿足NLP的要求。DP屬于敏感數據，需要像客體一樣，按照適當的策略來進行保護。這些策略可能與DP特定部分的創建和修改有關。DP必須由能夠解釋NLP，并有權編寫DP的人來編寫或修改。一個NLP可能需要定義多個DP來實施，應特別考慮確保低級策略不會與高級策略沖突。不同的組織應制定和維持只適用于其組織或下屬組織的本地策略（local policy）或特定策略。
2
系統開發解決方案
2.1
企業內的標準化和互操作性
實現者應該使用全面的標準化方法，通過利用滿足這些目標的產品或能力，實現當前的互操作性和未來部署的靈活性。實現互操作性和經濟高效的ABAC部署的慣例方法是使用一系列標準、規范和標準化配置（定義標準選項的子集，即配置文件）。具有可選元素的標準可能會被開發者以不同的方式實現，最終導致完全符合標準的服務或應用程序卻無法支持互操作。因此，應該定義明確和標準化的配置文件，特別是在跨組織環境中。當獲取ABAC解決方案時，實施者應該使用通常約定的專門配置文件，同時考慮標準注冊機構提供的標準和配置文件。
單個授權服務組件（例如，策略決策點、策略執行點、策略檢索點、屬性檢索點、元屬性檢索點）應使用標準的開放接口開發，以便來自多個產品的系統可以同時部署，并能夠確保互操作性。企業應考慮將功能、接口、基礎設施和產品支持的需求作為采購流程的篩選條件，而不用考慮目標產品的分類或從屬關系。
2.2
身份管理集成
訪問客體的請求必須經過身份驗證，證明是來自唯一的主體。身份驗證通過使用身份憑證來實現，并且必須在做出訪問決策之前完成。ABAC系統需要支持組織使用的認證機制和憑證。這可能意味著，如果這些認證機制或憑證阻礙了ABAC的實現，組織就需要對其身份驗證基礎設施進行升級改造。這些憑證中傳遞的主體屬性應能唯一地確定主體，負責頒發憑證的身份審查過程應確保該身份實體可被追責。在整個企業中，身份發行和審查過程應被認為是可信的，并足以執行問責要求。采用強身份驗證方法（[NIST800-63-3，NIST800-63B]）能夠滿足這些要求。一旦主體被認證，其主體屬性就可以用來確定訪問決策，并且訪問決策可以被支持審計的系統捕捉到，以提供訪問請求的屬性信息。例如，采用可信的證書頒發機構頒發的X.509證書，通過安全傳輸層協議TLS1.2與客戶端完成認證會話的訪問請求，通過證書與實體建立綁定關聯。
2.3
支持NPE
在訪問控制服務中對NPE的支持有特殊的要求。授權服務使用與實體關聯的任何形式的屬性。綁定到NPE的屬性不僅有助于定義唯一的NPE，而且還反映了組織中該實體的上下文。
在某些情況下，NPE主體可能代表一個或多個人類主體。這些NPE可以攜帶自己的、獨立于任何人類主體的身份憑證。請注意，基于NPE憑證生成訪問決策的訪問控制系統將無法在訪問請求發生時，將該請求歸結于某個用戶、或擔任某個角色的人，或登錄到組帳戶的人。NPE可以獨立行事，也可以代表經過認證的個人。NPE可以包括網絡設備（如交換機、路由器），運行在服務器（如門戶程序）、工作站和其他終端設備上的進程。隨著任務和安全功能的日益自動化，NPE將在授權服務交互中扮演更大的角色。
2.4
ABAC組件間的授權和數據完整性
當授權服務組件交換敏感信息時，授權服務要求ABAC組件（如PEP、PDP）之間進行雙向認證。對于每次數據交換，都應考慮對數據源、數據完整性和及時性進行驗證。例如，當授權服務需要從權威的屬性服務獲取屬性時，應使用雙向身份驗證，然后使用驗證消息完整性和消息來源的機制。在屬性數據的交換過程中，雙方都應使用強身份驗證協議（例如，X.509身份驗證）來提供雙方所需的安全保障級別。
2.5
集成其他安全組件
授權服務本身不足以確保分布在整個企業中的關鍵任務客體所需的安全性。需要建設全面和一致的安全能力來確保所需的保證級別，通過集成這些能力，能夠為制定和實施訪問決策提供更全面、更完備的安全信息。這些安全組件包括主體身份驗證、安全審計、安全配置管理、入侵檢測和監視功能。
2.6
屬性源的選擇和訪問
授權權限需要仔細的處理，以便權威的屬性源能夠向策略決策點提供屬性。當有多個屬性服務可用時，可能具有不同的元屬性（如保障級別），屬性“存儲/策略信息點”應在滿足屬性檢索的策略匹配度、性能和可用性要求之間進行平衡。
2.7
主體屬性的共享存儲庫
如果目標網絡的連通性可以充分利用規模效益、加強質量控制和標準接口，則應考慮采用共享存儲庫來存儲主體屬性。使用共享屬性庫的另一個優點是，可以為來自多個源的數據提供單一的訪問點。與管理多個連接相比，構建和管理到單個訪問點的連接可能更簡單。在某些情況下，連通性受限、帶寬不足或時斷時續的網絡連接都會妨礙授權服務提供商可靠地使用共享存儲庫。因此，有必要維護數據的本地副本，它們不能與共享屬性存儲庫保持同步，也無法訪問當前最新數據。
2.8
最小屬性集
在某些企業中，可以定義一組最小的屬性集合。通過定義標準的企業主、客體屬性集，可以方便地修改DP以反映策略的變化。這種方法的典型例子是分類網絡中的分類和區分標記。在大多數情況下，如果沒有適當的標記，就無法將客體放置在網絡上，訪問控制策略的定義要能夠處理有限且眾所周知的分類和分區標記。
2.9
環境條件
在策略需要的時候，環境（或上下文）信息能夠輸入到訪問控制過程中。典型的環境信息包括包括威脅級別、主體/客體位置、身份驗證方法或當前時刻。在一定時間內，環境條件的變化可能比主、客體屬性的變化要快得多。
2.10
屬性管理
分配屬性的權限應該被明確地定義，并與適當的屬性策略保持一致。某些形式的有效性驗證、完整性檢查和來源確認機制（用于驗證屬性的完備性、允許值、完整性和更改歷史）應集成到用于屬性管理框架中。
2.11
NLP/DP可溯性
高層級的企業書面策略/NLP和低層級的企業或本地DP之間的、全面和一致的可溯性應由合適的機構維護。這樣可以確保書面策略的變更能得到充分評估，并相應地調整后續的DP。有了策略的可溯性，本地組織中多余的DP將是可審計的、可驗證的，并且可以根據任何更改需求進行更改。
2.12
基于約定屬性的策略規則
如果組織與其他組織達成了使用已定義屬性列表的協議（某些特定于行業和用例專用的屬性組），則擁有這些客體的組織必須確保它僅基于這些屬性編寫訪問控制策略。如果只影響有限的安全信息共享能力，無論多有限，都應盡力使用公認可接受的共享企業屬性集，以確保基本的互操作性。當新的需求出現時，企業可以選擇引入新的企業屬性和它們的共享規則。
例如，OASIS XACML 美國出口管制（EC-US）和知識產權管理（IPC）概要文件是具有限定值域、特定領域的標準化屬性的范例。EC-US概要文件記錄了美國商務部出口管理條例（EAR）和美國國務院國際武器貿易條例（ITAR）訪問控制決策的共同屬性。
2.13
策略決策服務的外部化
通常將PDP實現為與單個企業服務和應用程序分離的服務。這種方式可以避免為每個企業服務或應用提供相似決策服務所帶來負擔和費用，因為單個PDP可以支持多個企業授權服務。授權服務提供商使用由大型企業或組織提供的PDP服務，可以極大地簡化服務/應用程序開發；節省了用于軟件許可、培訓、配置和部署這些服務實例的資金；并將運營和維護從單個應用中移除。
3
企業ABAC功能的其他考慮
在開發和實現ABAC企業授權功能時，架構師和程序管理人員必須記住，從現在使用的當前訪問控制方法到最終項目完成將會是一個長期的過程。隨著標準和技術的成熟，組織需要接受一些概念，這些概念有助于增強互操作性并促進高保障性的解決方案，同時拋棄專有的、煙囪式的解決方案。
3.1
訪問控制決策的可信度
訪問控制決策是通過從權威來源收集的、與風險水平相適應的準確、及時和相關的數據計算出來的的。訪問控制決策的可信度取決于用于計算決策的信息的及時性、相關性、權威性、質量、可靠性和完備性。建立信任的其他因素包括身份識別和身份驗證過程（例如，身份驗證機制的強度、身份審查、憑證發放和校對、認證、源IP地址）。在采用基于風險的ABAC方法時，應考慮上述因素。
3.2
組織間的屬性映射
組織可以用不同的名稱命名屬性和屬性值。為企業的不同組織提供屬性映射方案，可以最大限度地減少對被稱為“企業屬性”的這類屬性的需要，這一點可能很重要。屬性映射用作不同命名的屬性或屬性值之間的轉換。例如，一個組織可以使用名稱“公民身份”，而另一個組織可能使用名稱“國籍”來引用同一組屬性值。
在實踐中，跨組織ABAC可以遵循第3.1.3.1節和第3.1.3.2節中概述的協作方法。這樣，每個組織能夠在同一個框架內作出本地決定，該框架可以保證組織之間的適當控制。創建新策略時，如果策略作者創建或指定自己的屬性，則策略可能無法互操作。使用預先約定的屬性將使策略更加統一和易于理解。
叁
實施/評估階段的考慮
在實現/評估階段，組織安裝或實現系統，配置并啟用系統的安全特性，測試這些功能特性，最后獲得操作運行該系統的正式授權。在這個階段中，大多數的考慮都集中在優化性能和確保安全功能的正常運行方面上。
1
屬性緩存
當ABAC解決方案從原型/試點轉移到部署時，可以考慮使用屬性緩存來提高性能。如果每個訪問決策都需要跨網絡的屬性請求，ABAC的性能可能會受到負面影響。這在低帶寬、高延遲的環境中尤其明顯。
除了與屬性緩存有關的性能問題外，組織還需要對屬性新鮮度對安全性的影響進行權衡。不能持續刷新的屬性顯然不如實時刷新的屬性安全。例如，上次刷新后，主體的訪問權限可能已發生變化，但在下次刷新緩沖數據之前，這些變化不會反映在緩沖數據中。
具有零星連通性的環境需要在本地級別緩存屬性。使用本地緩存屬性的安全后果需要在組織范圍內的策略級來確定，并需要使用適當的技術手段來解決。在這些斷開連接的環境中，管理員可以使用基于風險的分析作為訪問決策的基礎，因為本地（斷開連接的）級別的屬性可能會在系統刷新前更改或刪除。本地（斷開連接的系統）對可能過時的緩存屬性的使用可能會給系統帶來一定的風險，因為本地系統沒有使用最新的可用屬性。因此，有必要對是否部署此類解決方案進行基于風險的分析。
例如，現在要在一艘船上部署，該船僅與企業網絡之間存在間斷性的，非理想的網絡連接。因為部署的用戶群在整個運輸過程中只有微小的變化，所以支持“意料之外”的系統用戶就不那么重要了。在這種情況下，主體屬性的批量下載和本地存儲對于大多數本地訪問控制決策來說可能就足夠了。因此，主體屬性數據可以在整個部署過程中存儲在船上，本地應用程序和服務可以使用本地存儲中的數據，而無需訪問權威的企業屬性源。雖然這是特殊環境的一個案例，但不應認為這是唯一的解決辦法。
2
屬性源最小化
最小化授權決策中的屬性源的數量，可以提高性能并簡化ABAC解決方案的安全管理。計劃部署ABAC解決方案的組織，可能會受益于在解決方案部署過程中，組織的所有利益相關者之間建立起來的密切的工作關系。
3
接口規范
為了確保能夠可靠地訪問ABAC服務，所有通過企業ABAC功能參與信息共享的組織都應充分了解各類請求（包括屬性請求和DP請求）的接口、交互方式和先決條件。同樣重要的是，當基礎設施和接口需求發生變化時，要確保能向所有依賴這些部件的組織提供更新通知，以便他們能夠規劃相應組件的修改。
肆
操作/維護階段的考慮
在操作/維護階段，系統和產品均已就位，系統的操作、增強和修改已經開發和測試完畢，硬件和軟件也得以到添加或更換。在此階段，組織應當監控系統的性能，以確保其符合預先設定的用戶和安全需求，同時所需的系統修改也已完成。
1
質量數據的可用性
由于訪問控制決策所需的信息（在某些情況下包括決策本身）可能處在客體和使用者外部，因此對信息和服務的訪問將更加依賴于外部服務提供及時和準確數據的能力。基礎設施必須是健壯的、經過良好測試的、有彈性的，并且可以根據任務需求進行擴展。這對于支持屬性服務、屬性存儲、策略存儲、策略和屬性生成和驗證組件、決策引擎、元屬性存儲庫和信息通道。如果外包，服務協議應詳細說明可用性、響應時間、數據質量和完整性要求。例如，對于被視為關鍵部件的數據和服務，必須考慮故障轉移、冗余備份和業務連續性。為了保持高質量數據的可用性，需要由經過培訓、授權的人員執行屬性值的添加、更新和刪除，并定期進行審核。
屬性、服務的提供者和使用者之間的正式協議應該滿足適當的服務、質量、可用性、保護和使用標準。各種法律法規規定了與相應保護信息相關的職責、責任和處罰。協議應包含這些要求以及與數據責任相關的要求。
在組織之間建立適當程度的信任協議是重要的。這些協議將有助于用一系列要求形式化這些信任關系，并可能有助于對違規項的處罰。屬性服務的APS和MOU/MOA以及權威和負責的屬性源也可以將組織策略轉化為操作規程。這些正式協議描述了這些服務的目的、用途、參與者、責任和管理。
結論
該文件整理了許多以前獨立的ABAC知識，以彌合現有技術和ABAC實現之間的鴻溝，并滿足聯邦政府內對ABAC產生的興趣。
ABAC通過計算策略規則中實體（主體和客體）、操作和與環境的屬性值，生成策略決策，來控制對客體的訪問。ABAC依賴于對主體的屬性、客體的屬性以及形式關系或訪問控制規則（定義允許操作所應滿足的主體-客體屬性組合）的求值。ABAC支持精確的訪問控制，允許為訪問控制決策提供大量的離散輸入，以及這些變量的不同組合，以反映不同的規則、策略或訪問限制。因此，ABAC允許數量不受限制的組合屬性，以滿足豐富的策略集需求。
本文定義了理解ABAC所必需的基本概念。具體來說，包括主體和客體屬性，以及ABAC模型及其組件的一般特性。按照系統開發生命周期給出了一些思考建議，供企業在ABAC項目的規劃、設計、開發、實現和運營過程中借鑒。特別針對大型企業，討論了ABAC機制的優點和常見缺陷。
ABAC提供了前所未有的靈活性和安全性，同時促進了不同組織之間的信息共享。至關重要的是，這些能力的開發和部署基于共同的概念和功能要求，以確保最大程度的互操作性。ABAC非常適合大型企業。ABAC系統可以實現現有的基于角色的訪問控制策略，并且可以支持從基于角色的訪問控制遷移到基于請求方不同特性的、更細粒度的訪問控制策略。它支持外部（非可預期）用戶，并為其提供更高效的管理。然而，與簡單的訪問控制系統相比，ABAC系統更復雜，因此實現和維護成本更高。
總結
以上是生活随笔為你收集整理的基于属性的访问控制（ABAC）定义与思考 ——企业ABAC的实施问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 访问控制模型（DAC,MAC,RBAC,
- 下一篇： 用计算机娱乐教学反思,计算机教学反思