This article compiles the second part 'Implementation issues of enterprise ABAC' of the core thoughts and views of the article 'Guide to Attribute Based Access Control (ABAC) Definition and Considerations', the first part can be seen inBasic Concepts of ABAC.
KeywordsAccess control; access control mechanism; access control model; access control strategy; attribute-based access control (ABAC); authorization; permission.
Part two Implementation issues of enterprise ABAC
Before deploying an ABAC system across enterprises, many factors must be considered. Based on a thorough consideration of the current technical status and the lessons learned from the federal government's multiple attempts to deploy ABAC in large enterprises, some guiding principles are compiled for readers to refer to. These suggestions are provided respectively at each stage of the NIST System Development Life Cycle (SDLC) as shown in Figure 6. For more information on SDLC, please refer to [NIST800-100]. The main considerations for the deployment of enterprise ABAC are the first four stages: initiation, acquisition/development, implementation/evaluation, and operation/maintenance. This section focuses on these stages specifically.
Figure 6 ACM NIST System Development Life Cycle (SDLC)
The development and deployment of the enterprise ABAC need to consider many factors that affect its design, security, and interoperability. These factors lead to a series of issues that should be considered:
• Project justification for ABAC implementation.What are the costs of developing/obtaining new features and transitioning from old features? What important benefits does ABAC provide? What new risks does ABAC introduce (if any), and what new management structures are needed to manage shared functions and strategy documentation? These strategies were previously all decisions made manually. Which datasets, systems, applications, and networks require ABAC functionality? How to manage data loss or misuse?
• Understand operational requirements and the entire enterprise architecture.How to manage, monitor, and verify permissions to achieve compliance? Which interfaces and objects will the enterprise make public for information sharing? What ACM will be used? How to share and manage subject and object attributes? What are the access control rules? How are they extracted, evaluated, and executed? How is trust managed internally?
• Establish or improve business processes to support ABAC.Is the access rule and policy fully understood and documented? How to identify and allocate the required attributes? How to apply multiple policies hierarchically and eliminate conflicts? How to handle access failures? Who creates new policies? How to share and manage public policies?
• Develop and acquire a set of interoperable capabilities.How to achieve interoperability? How to integrate subject attributes in identity management into ABAC? How to handle different or special identity requirements? How to share and maintain subject attributes across corporate entities? What are the advantages and disadvantages of centralized implementation and distributed deployment of authentication, authorization, attribute management, decision-making, or enforcement capabilities? How can environmental conditions be used in policy decision-making? How is trust quantified, transmitted, and used at the security, quality, and accuracy levels in policy decision-making? How to map subject attributes between organizations? How to formulate policies to integrate the latest available subject, object, and environmental condition attribute sets?
• Performance evaluation.How to manage subject attributes for users who are not connected, have bandwidth limitations, or resource constraints? How can the interface specifications for new corporate members be made available? How can the quality and timeliness of attribute and policy changes be measured and implemented? Is the overall system and end-to-end performance sufficient?
The following sections will discuss these principles and issues in more detail.
One Considerations in the startup phase
In the startup phase, the enterprise evaluates the needs and potential applications of the ABAC system, determining whether the ABAC system is an independent information system or a component of an existing system. Once these tasks are completed and the ABAC capabilities requirements are determined, some work is still needed before the ABAC system is approved, including clearly defining goals and high-level requirements. At this stage, the enterprise needs to define the high-level business, operational requirements, and enterprise architecture of the ABAC system.
1 Rationale for the ABAC project
Like the deployment of any major system, before deploying enterprise ABAC, important requirement assessments, business research, and planning activities should be carried out to determine whether ABAC is the correct access control method in the given target environment. The advantage of ABAC is that it can provide access control capabilities even if the subject is not known or understood in advance, and provide large-scale enterprise information sharing for a limited set of tasks or business critical objectives.
It is very important to evaluate and demonstrate the ABAC project and define the enterprise goals of the project before generating any technical requirements or making deployment decisions. Implementing enterprise ABAC will bring huge costs in development, implementation, and operation, and the way in which enterprise objects are shared and protected will also change. Case studies or experience reports from other organizations may help plan the deployment of ABAC. For a limited set of objects, adopting an incremental approach to gradually implement ABAC protection may be more practical. This implementation method will build and utilize strategies and attributes suitable for the entire enterprise to the greatest extent. The feedback from gradually building ABAC functions can refine the definition of strategies and attributes and exercise the necessary governance and configuration management functions to support the broader use of ABAC across the entire enterprise. It should be noted that if the issues raised in the following sections are not resolved, the enterprise may suffer significant delays and additional costs when deploying ABAC.
2 Scalability, feasibility, and performance requirements
When considering the deployment of ABAC (Access Control for Access) products or technologies, issues such as scalability, feasibility, and performance are important factors to consider. Enterprise ABAC (Allowing an organization to access objects managed by another organization within the same enterprise) requires complex interactions between ABAC components. Typically, these components are distributed across the entire enterprise, spanning organizational boundaries and sometimes distributed across different networks. The larger the enterprise and the more diverse the organizational structure, the more complex these interactions become. In the past, accessing documents in a document library could be done with a simple request, but now it has become a process involving pulling policies from the enterprise policy library, pulling different attributes from physically/logically distributed multiple attribute sources, verifying the integrity of the object attributes related to the document through third-party validation, generating policy decisions on an IT facility within the enterprise, and finally executing the policy decision on another IT facility. Feasibility assessments should check whether the business applications support ABAC, whether it is supported natively or through a third party. All these potential interactions have performance costs, and these costs must be evaluated when determining the scope of shared objects to be achieved through enterprise ABAC. To mitigate potential performance and scalability issues, various architectures should be considered. The deployment and distribution of ABAC components should take into account the underlying enterprise architecture and the location of the data and objects to be shared. For example, PDP (Policy Decision Point) and PEP (Policy Enforcement Point) can be deployed under the same management unit.
2.1 Development and maintenance costs
Although ABAC provides many important new features when deployed across enterprises, in the long run, the cost of development, deployment, and maintenance of ABAC may exceed its value. In addition, the cost of modifying applications to use ABAC is completely separate from the cost of purchasing, setting up, and maintaining the authorization infrastructure (referring to the ABAC system). Although some maintenance costs can be saved by giving up the current solution, these savings will be offset by the costs of managing and maintaining the main attributes and policies of ABAC, as well as the support costs for the new system. To determine the balance point between risk costs and security costs, the more precise, consistent, and flexible security features of ABAC must be carefully evaluated and quantified. Considering these factors, ABAC is not a universal solution for all access control issues, but it can be proven that in environments where subjects and objects have various different attributes, ABAC is a feasible solution when access decisions involve complex relationships between these attributes.
2.2 Cost of migrating to ABAC
With the migration to ABAC, there is a major shift in management and business processes, where the subjects are controlled by enterprise policies and attributes under enterprise control (and sometimes also local control). These subjects may now need to be associated with a set of other characteristics that may not have been used in access control. Users accustomed to freely accessing resources after logging into the network may no longer have the convenience. Although policy makers will strive to formulate policies that reflect current tasks and business needs, there will always be some unexpected denials of access when accessing critical tasks or business functions.
With the deployment of ABAC products and the change in enterprise access control, new processes and functions need to be integrated into users' daily business processes and enterprise strategies. During the migration process, it is important to ensure that users understand why these access controls need to be changed and what impact these changes will have on the completion of business. These users need to be trained in the new ABAC systems and processes. The changes brought about by the deployment of ABAC need to be appropriately communicated to users to demonstrate its value, including better user experience, enhanced security, protection of critical information, requirements of the new ABAC system, and the gradual phasing out of traditional access control systems. Users may also be satisfied with the existing business processes and not immediately see the value brought about by the deployment of ABAC. In this case, it is necessary to emphasize the differences between ABAC and existing access control mechanisms in enhancing the enterprise security posture.
2.3 The need for permission review and authorization monitoring
Some enterprises may wish to review the subjects and their permissions, including reviewing access control entries associated with objects. Simply put, before issuing a request, it is necessary to know what access permissions each person has, which is sometimes called 'pre-audit' and is very necessary when proving 'compliance' (compliance with specific regulations or directives). Another common review purpose is to determine who has the right to access a specific object or a specific set of resources. ABAC systems may not be effective for conducting these audits. Instead, a key feature of ABAC is that the object owner can protect and share the object without knowing the subject in advance. The calculation of the set of subjects that can access a given object requires a large amount of data retrieval and computation, which may require each object owner to calculate by simulating the access requests of each known subject in the enterprise. Limiting the scope of ABAC implementation helps to pre-determine access authorization, but if the enterprise needs such verification, it should explore other methods to verify the validity of authorization.
2.4 Understanding Object Protection Requirements
There are a large number of different operations and object types at different positions in the enterprise, which require the enforcement of AC (Access Control) strategies, including operating systems, applications, data services, and database management systems. Although there may be some NLP (Natural Language Processing) to assist in access authorization, the access control for most objects is implemented through local group policies managed by local business rules, or depends on some unrecorded evaluation factors and non-standard implicit rules. Implementing ABAC first requires a thorough understanding of the objects and their protection requirements, otherwise the cost of developing and implementing enterprise ABAC will sharply increase. It is recommended to first apply the enterprise ABAC deployment to objects with well-defined, controlled, and documented characteristics.
2.5 Enterprise Governance and Control
Successful ABAC (Access Control) requires coordination and determination of certain business processes and technical factors, as well as establishing corporate responsibilities and supervisors. Without an appropriate governance model, the enterprise will develop siloed solutions, greatly reducing interoperability. It is recommended to establish a corporate governance body to manage the deployment and operation of all identity, credential, and access management functions, and it is recommended that each subordinate organization establish a similar body to ensure consistency in the management process of ABAC deployment. In addition, it is recommended that the governance body develop a 'trust model' to describe the trust chain and help determine the ownership and responsibility of information and services, determine specific needs for additional policies and governance, and determine technical solutions for verifying or implementing trust relationships. The trust model also helps organizations clarify how to use and protect the shared information, as well as how to trust shared information from other organizations.
In addition, the enterprise authorization service should be tightly integrated with security auditing, data loss prevention, security configuration management, continuous monitoring, and network defense capabilities. The authorization service itself is not sufficient to ensure the security required for critical mission objects on the network, and it is necessary to fully understand the enterprise security requirements and the impact of ABAC implementation. For example, when using a distributed ACM architecture, the audit capability of access control decisions and events may be affected.
The ABAC system can benefit from the trust framework deployed in the enterprise environment. By comparing the traditional trust chain using ACL (Figure 7) and the trust chain using ABAC (Figure 8), it can be seen that many more complex trust relationships are needed for ABAC to work normally. ACL is established by the owner or administrator of the object, and access to the object is set by adding users to the ACL, thereby implementing the execution of object access rules. In ABAC, the root of trust comes from different starting points, such as the competent department of the subject attributes or the policy administrator.
Figure 7 ACL Trust Chain
Figure 8 ABAC Trust Chain
When managing the inherent risks of information sharing and deploying the enterprise ABAC solution, risks must be considered from two perspectives. First, the ABAC solution can be regarded as one of many security control options that protect the enterprise and reduce risks. The implementation of ABAC can reduce the risk of unauthorized access to protected resources because ABAC can respond to constantly changing threats by consistently implementing executable and easily updatable precise policies. Second, ABAC exposes the protected objects to access by unknown entities, and ABAC may increase or decrease the operational risk of the enterprise. Assuming the process of attribute publication is normal, the ABAC system depends to some extent on the attribute publication agency. The diversity of risk sources brings many challenges to ABAC, which must be addressed through governance and formal trust models.
When establishing the governance model for ABAC inherent risks, it is important to ensure that mechanisms and agreements are established with each responsible agency to monitor and manage these trust anchors and any liability arising from unauthorized access.
3 Develop operational requirements and architecture
Before implementing the ABAC solution, the following top-level operational and architectural (architecture) planning requirements must be met:
• First, determine the objects that will be shared and protected by ABAC.
• Second, define rules or strategies.
• Third, together with the competent departments of the main and guest attributes, coordinate the developers of access control rules, and determine and define the main and guest attributes.
• Fourth, develop and write, verify, and manage the processes related to policy development, verification, and management.
• Finally, determine the deployment location of ACM in the enterprise, and how requests and responses related to attributes, policies, and policy decisions are generated.
3.1 Object identification and strategy allocation
The objects that need to be shared and protected in ABAC solutions may differ due to the differences in organizational requirements. Each object or object class must be identified, and the strategies or rules for protecting each object or object class must also be documented. It is necessary to establish a set of business processes to identify, classify, and assign strategies to each new object created within the ABAC deployment scope.
3.2 Attribute architecture
Generally, access control policies are described through some clauses that include attributes. Therefore, all attributes used in the policy must be established, defined, and constrained by the scope of assignment. The data model (Schema) defining 'attributes and their assignment scope' must be published to all participants to help the object owner develop rules. Once attributes and assignment scope are established, it is necessary to establish methods for providing attributes and appropriate attribute values to subjects and objects, as well as the architecture that includes attribute repositories, retrieval services, or integrity check services. To achieve the sharing of these attributes, interfaces and sharing mechanisms need to be developed for their implementation.
3.3 Subject attributes
When a person acts as a subject, their subject attributes are usually provided by the enterprise organization and may be provided by several different competent authorities (human resources, security, organizational leadership, etc.). In this case, the methods for obtaining authoritative data are well-known. For example, only the security department can provide license attributes or assertions about the values of license attributes based on official personal permit information; individuals cannot modify their own license attribute values. Other subject attributes may involve the subject's current task, physical location, and the device sending the request; an evaluation module needs to be developed to ensure the quality (accuracy, validity, etc.) of such subject attribute data.
The subject attributes provided by the authoritative department should have appropriate credibility in terms of quality, assurance, privacy, and service expectations. These expectations can be defined in the Attribute Practice Statement (APS). APS provides a list of attributes to be used throughout the enterprise and can identify the authoritative attribute sources of the enterprise. In addition, it is necessary to further expand the functional capabilities of the network infrastructure (including the ability to maintain the confidentiality, integrity, and availability of attributes) to facilitate the sharing and replication of authoritative subject attribute data within or across organizations.
3.4 Object attributes
The attributes of an object are usually set when the object is created, and can be bound to the object or stored outside the object and referenced by the object. It is obvious that the access control authority cannot closely monitor all events. Usually, these information are driven by non-security processes and requirements. Only complete attribute data can support sound policy decisions, and certain measures must be taken to ensure that object attributes can only be allocated or verified through processes deemed appropriate by the object owner or administrator. For example, object attributes cannot be modified by the subject to manipulate the results of access control decisions. When the access control mechanism calculates policy decisions, the object attributes must be retrievable. Other considerations for creating object attributes include:
• Generally, users are unaware of the values of object attributes (e.g., which sensitive partitions a given user is authorized to access). This should be considered in ACM to ensure that users only see the values applicable to them.
• Like subject attributes, a pattern for object attributes is needed to define attribute names and allowed values.
• Attributes need to be consistent in DP, MP, and NLP.
The federal government and the business community have made many efforts to create object attribute marking tools, which not only provide data marking but also provide encrypted binding of object attributes and verification of object attribute fields to meet the requirements of access control decisions.
3.5 Environmental Conditions
Environmental conditions refer to contextual information necessary in the decision-making process that is unrelated to a specific subject or object. Unlike subject and object attributes, they are not created and managed due to management needs, but are intrinsic and must be detected by the ABAC system. Environmental conditions (such as current date, time, location, threats, and system status) are typically evaluated based on the current matching environmental variables when authorizing access requests. Environmental conditions allow ABAC policies to define exception rules or dynamic AC rules that cannot be described only through subject/object attributes. When writing ABAC rules using environmental conditions, it is necessary to ensure that the environmental condition variables and their values are globally accessible, tamper-proof, and relevant to the current usage environment.
3.6 Access Control Rules
In ABAC, all AC rules must include a combination of properties and allowed operations, and may also include conditions, hierarchical inheritance, and some complex logic, which provide rich options for ABAC implementation. The rule sets and their application methods to objects must be managed appropriately. Rules must accurately and completely reflect NLP, and they must be developed, defined, applied, maintained, shared, and asserted by authoritative departments (corporate organizations or resource owners). ABAC supports multiple rules from multiple stakeholders and requires new technologies to coordinate different rules to achieve a balance between information sharing and protection. In some cases, it may be necessary to limit which rules are visible to which objects to reduce the possibility of unauthorized entities obtaining authorization by manipulating properties. In other cases, subjects denied access should have a method to verify or correct the conditions that led to the denial of access. Some organizations may want to track cases where access is denied to check whether the rules are appropriate. Similarly, the rule definition and deployment mechanisms and processes should include strong rule conflict resolution capabilities (to resolve the problem of inconsistent decision results from different rules) to determine rule conflicts and resolution methods.
3.7 Access control mechanisms and context handling
To avoid conflicts and vulnerabilities in object protection, the composition structure and deployment method of ACM must be pre-determined. For example, if an object is held by two different organizations, unauthorized subjects should not obtain access to the object solely by restricting the authorization of the weaker organization. Enterprise organizations should manage, maintain, and use ACM in a consistent manner to ensure interoperability and comprehensive security.
The sequence of ACM retrieving information, calculating decisions, and executing decisions may vary greatly due to differences in implementation, even when considering environmental conditions in calculating access control decisions. This is context handling, simply referring to the workflow that ACM performs when collecting data required for decision-making.
In addition, for considerations of performance and scalability, the location where strategies, attributes, and decision information are stored and exchanged throughout the enterprise, as well as how to implement it, is also a necessary consideration factor.
Second Considerations in the procurement/development phase
In the procurement/development phase, enterprises build systems through various means such as design, purchase, programming, and development. Typically, at this stage, the organization prepares to run business processes within the enterprise and defines the systems to be deployed and integrated. In the first phase of this stage, the enterprise should define the security and functional requirements of the system simultaneously. In the final phase of this stage, before the project enters the implementation/evaluation phase, the organization should conduct developmental testing of technical and security features/functions to ensure they operate as expected.
1 Business process generation and deployment preparation
1.1 Rule files
For each type of object controlled by the organization, there should be a set of corresponding access control rules recorded in NLP. (Use cases may be the simplest way for a company to define NLP for a group of objects.) These rules should specify whether the subject can or cannot interact with these data or services controlled by the organization (including creation, viewing, modification, deletion, forwarding), and under what contextual or environmental conditions these privileges are held. When recording these rules, it should include the organization's interpretation of applicable policies and guidelines, the special sensitivity of applicable objects, and the user community knowledge related to these objects.
Recording NLP is helpful for DP development and provides traceability from digital strategies to written strategies. For example, many organizations find it difficult to migrate authorized functions from ACL to a more robust ABAC infrastructure due to the lack of NLP. For instance, when receiving access requests, data owners evaluate according to certain principles (usually without documented records), such as 'Is this person a member of the working group?' or 'Am I familiar with this person or their unit?', and then make access decisions before adding the requestor's name to the ACL. Well-documented NLP can transition the access control decision-making process from manually generated methods to a consistent automated strategy-driven generation.
1.2 1.2
Local strategies
When implementing local access strategies in a joint enterprise, it is necessary to base the attribute mapping from the subject's organization to the local organization, and be able to reflect the enterprise access control strategy associated with the object. According to the shared agreements between organizations, objects with shared ownership or control should be protected according to the most stringent strategy. Unless there is a requirement from the superior department or obligation, subordinate organizations should not weaken the strictness of local strategies. If subordinate organizations in the enterprise can independently relax the constraints on the formulation of enterprise strategies, the inherent security of the system may be compromised, possibly allowing local access to enterprise objects that should be prohibited.
1.3 Consistent conventions and understanding of attributes
The definitions and value ranges of enterprise subjects and object attributes must be valid and consistent so that authorization components can calculate authorization decisions based on globally consistent known attribute values throughout the enterprise. Regardless of whether these attributes are used within the organization or across organizations, the lifecycle management of attributes is the responsibility of the attribute主管部门.
1.4 Understanding the meaning of attributes
Attribute service providers need to describe attributes and their relationships with other attributes so that users can use attributes correctly and effectively. Attribute service providers must record the authoritative definitions and meanings of attribute values and guide the use of these attributes. In some cases, it is necessary to combine attributes with other attributes to establish an effective context, such as the combination of roles and organizations - unless the role is defined in the context of the organization, it has no meaning. For example, for the whole organization's operations director, his responsibilities may include finance, human resources, law, and other departments, and its contextual meaning is completely different from that of the operations director of the IT department's web service division. If the attributes, context, and the significance of attribute values to policy decisions are not understood, DP and decisions may be generated with insufficient information or using incorrect algorithms.
1.5 Process for handling access failure
A set of procedures/programs should be established to handle exceptional situations such as access denial and runtime errors, in order to provide users with a method to correct/adjust the results of access decisions, given the task, role, and principles to be known. Since in ABAC, the authorization service has gradually matured from the traditional method of adding accounts to ACLs to an automated decision-making method, system users find it difficult to understand and correct access denials (referring to correcting decision results). The 'attribute discovery' and 'attribute acquisition' processes established for obtaining access authorization in ABAC will help simplify this transition, which can also be extended to solve problems with access authorization service components such as connection loss.
In mission-critical roles, subjects should be able to understand these limitations and request some exceptions, such as turning to the official help system, or trying other paths to access equivalent information or services.
1.6 Privacy considerations of attributes
The development of ABAC should comply with all applicable privacy laws, directives, and policies. Due to the personal and descriptive nature of subject attributes, the implementation of attribute sharing may increase the risk of violating PII privacy due to unintentionally exposing attribute data to untrusted third parties or aggregating sensitive information in environments with lower protection levels. Organizations that support 'attribute sharing' should enter into trust agreements to ensure the correct handling of PII and the execution of PII regulations. These agreements should detail the authorized use and handling of PII by all components in the trust chain, as well as methods for verification, remediation, and adjudication of violations. Another consideration is that subject attributes can be presented in the pattern of granting/refusing decisions. If a subject accesses a specific resource, the subject must have the attributes specified in the access rules of the resource. Organizations should protect access logs or other information that may leak granting/refusing decisions.
1.7 Digital policy creation and maintenance
Each DP defined in the system should meet the requirements of NLP. DP is sensitive data and needs to be protected like an object, according to appropriate policies. These policies may be related to the creation and modification of specific parts of DP. DP must be written or modified by someone who can interpret NLP and has the authority to write or modify DP. A NLP may require defining multiple DP to implement, and it should be particularly considered to ensure that low-level policies do not conflict with high-level policies. Different organizations should develop and maintain local policies or specific policies that apply only to their organization or subordinate organizations.
2 System development solutions
2.1 Standardization and interoperability within the enterprise
Implementers should use comprehensive standardization methods to achieve current interoperability and flexibility for future deployment by leveraging products or capabilities that meet these objectives. The conventional method for implementing interoperable and economically efficient ABAC deployments is to use a set of standards, specifications, and standardized configurations (defining subsets of standard options, i.e., configuration files). Standards with optional elements may be implemented differently by developers, leading to services or applications that fully comply with the standard but cannot support interoperability. Therefore, it is necessary to define clear and standardized configuration files, especially in cross-organizational environments. When obtaining ABAC solutions, implementers should use specialized configuration files commonly agreed upon, while considering standards and configuration files provided by standard registration authorities.
Individual authorization service components (such as, policy decision points, policy enforcement points, policy retrieval points, attribute retrieval points, and metadata retrieval points) should be developed using standard open interfaces to enable simultaneous deployment of systems from multiple products and ensure interoperability. Enterprises should consider the needs for functionality, interfaces, infrastructure, and product support as screening criteria in the procurement process, without considering the classification or relationship of the target product.
2.2 Identity Management Integration
The request for access subjects must be authenticated to prove that it is from a unique subject. Authentication is achieved by using identity credentials and must be completed before making an access decision. The ABAC system needs to support the authentication mechanisms and credentials used by the organization. This may mean that if these authentication mechanisms or credentials hinder the implementation of ABAC, the organization may need to upgrade or transform its authentication infrastructure. The subject attributes passed through these credentials should be able to uniquely identify the subject, and the identity review process responsible for issuing the credentials should ensure that the identity entity can be held accountable. The entire enterprise should consider the identity issuance and review process to be trustworthy and sufficient to meet accountability requirements. The use of strong authentication methods ([NIST800-63-3, NIST800-63B]) can meet these requirements. Once the subject is authenticated, the subject attributes can be used to determine access decisions, and access decisions can be captured by systems that support auditing to provide attribute information about access requests. For example, access requests are authenticated through a secure transport layer protocol TLS1.2 with the client using X.509 certificates issued by a trusted certificate authority.
2.3 Support for NPE
There are special requirements for supporting NPEs in access control services. The authorization service uses any form of attributes associated with the entity. Attributes bound to NPEs not only help define a unique NPE but also reflect the context of the entity in the organization.
In some cases, NPE subjects may represent one or more human subjects. These NPEs can carry their own identity credentials independent of any human subject. Please note that access control systems that generate access decisions based on NPE credentials will not be able to attribute the access request to a specific user, or a person in a role, or a person logged into a group account at the time of the access request. NPEs can act independently or represent authenticated individuals. NPEs can include network devices (such as switches, routers), processes running on servers (such as portal programs), workstations, and other terminal devices. As tasks and security functions become increasingly automated, NPEs will play a greater role in authorization service interactions.
2.4 Authorization and data integrity between ABAC components
When the authorization service component exchanges sensitive information, the authorization service requires mutual authentication between ABAC components (such as PEP, PDP). For each data exchange, it should be considered to verify the data source, data integrity, and timeliness. For example, when the authorization service needs to obtain attributes from an authoritative attribute service, bidirectional authentication should be used, followed by mechanisms to verify the integrity and source of the verification message. During the exchange of attribute data, both parties should use strong authentication protocols (such as X.509 authentication) to provide the required level of security for both parties.
2.5 Integration of Other Security Components
The authorization service itself is not sufficient to ensure the security required for critical task objects distributed throughout the enterprise. It is necessary to build comprehensive and consistent security capabilities to ensure the required assurance levels. By integrating these capabilities, it is possible to provide more comprehensive and complete security information for making and implementing access decisions. These security components include subject authentication, security auditing, security configuration management, intrusion detection, and monitoring functions.
2.6 Selection and Access of Attribute Sources
Authorization permissions require careful handling so that authoritative attribute sources can provide attributes to the policy decision point. When multiple attribute services are available, they may have different metadata (such as assurance levels), and the 'attribute storage/strategy information point' should be balanced between meeting the policy matching, performance, and availability requirements for attribute retrieval.
2.7 Shared Repository for Subject Attributes
If the connectivity of the target network can take full advantage of economies of scale, strengthen quality control, and standardize interfaces, it should be considered to use a shared repository to store subject attributes. Another advantage of using a shared attribute repository is that it can provide a single access point for data from multiple sources. Compared to managing multiple connections, building and managing connections to a single access point may be simpler. In some cases, limited connectivity, insufficient bandwidth, or intermittent network connections may hinder the reliable use of shared repositories by authorization service providers. Therefore, it is necessary to maintain local copies of data that cannot be synchronized with the shared attribute repository and cannot access the most current data.
2.8 Minimum Attribute Set
In some enterprises, a set of minimum attribute collections can be defined. By defining standard enterprise subject/object attribute sets, DP can be conveniently modified to reflect changes in policy. A typical example of this method is the classification and differentiation markers in the classification network. In most cases, without appropriate markers, it is impossible to place objects in the network, and the definition of access control policies must be able to handle limited and well-known classification and partitioning markers.
2.9 Environmental Conditions
When needed by the policy, environmental (or context) information can be input into the access control process. Typical environmental information includes threat levels, subject/object locations, authentication methods, or the current moment. Changes in environmental conditions may be much faster than changes in subject/object attributes within a certain period of time.
2.10 Attribute Management
The permissions for attributing should be explicitly defined and consistent with appropriate attribute strategies. Certain forms of validity verification, integrity checks, and source confirmation mechanisms (used to verify the completeness, permissible values, integrity, and change history of attributes) should be integrated into the framework for attribute management.
2.11 Traceability of NLP/DP
High-level enterprise written policies/NLP and low-level enterprise or local DP should be maintained for comprehensive and consistent traceability by appropriate institutions. This ensures that changes to written policies are fully assessed and that subsequent DP are adjusted accordingly. With the traceability of policies, excessive DP in local organizations will be auditable, verifiable, and can be changed according to any change requirements.
2.12 Policy rule based on agreed-upon attributes
If an organization has reached an agreement with other organizations to use a defined list of attributes (some specific to industry and use case attribute groups), the organization possessing these objects must ensure that it writes access control policies based solely on these attributes. If it only affects limited security information sharing capabilities, no matter how limited, it should strive to use publicly accepted shared enterprise attribute sets to ensure basic interoperability. When new requirements arise, enterprises can choose to introduce new enterprise attributes and their sharing rules.
For example, the OASIS XACML EC-US (Export Control - US) and IPC (Intellectual Property Management) profiles are examples of standardized attributes with limited value domains and specific domain properties. The EC-US profile records the common attributes of access control decisions under the U.S. Department of Commerce's Export Administration Regulations (EAR) and the U.S. Department of State's International Traffic in Arms Regulations (ITAR).
2.13 Externalization of policy decision services
PDPs are usually implemented as services separate from individual enterprise services and applications. This approach can avoid the burden and cost of providing similar decision services for each enterprise service or application, as a single PDP can support multiple enterprise authorization services. Authorization service providers that use PDP services provided by large enterprises or organizations can greatly simplify service/application development; save funds for software licensing, training, configuration, and deployment of these service instances; and remove operations and maintenance from a single application.
3 Other considerations for enterprise ABAC functions
When developing and implementing ABAC enterprise authorization functions, architects and program managers must remember that the process from the currently used access control method to the completion of the final project will be a long-term one. As standards and technologies mature, organizations need to embrace concepts that help enhance interoperability and promote high-assurance solutions while discarding proprietary and siloed solutions.
3.1 Credibility of access control decisions
Access control decisions are calculated based on accurate, timely, and relevant data collected from authoritative sources that correspond to the risk level. The credibility of access control decisions depends on the timeliness, relevance, authority, quality, reliability, and completeness of the information used to calculate the decisions. Other factors that contribute to building trust include the identity verification and authentication process (such as, the strength of authentication mechanisms, identity review, credential issuance and verification, certification, and source IP address). When adopting a risk-based ABAC approach, these factors should be considered.
3.2 Inter-organizational attribute mapping
Organizations can name attributes and attribute values with different names. Providing an attribute mapping scheme for different organizations within the enterprise can maximize the need for attributes called 'enterprise attributes', which may be very important. Attribute mapping is used for the conversion between attributes or attribute values with different names. For example, one organization may use the name 'citizenship', while another organization may use the name 'nationality' to refer to the same set of attribute values.
In practice, cross-organizational ABAC can follow the collaborative methods outlined in Sections 3.1.3.1 and 3.1.3.2. In this way, each organization can make local decisions within the same framework, which can ensure appropriate control between organizations. When creating new policies, if the policy author creates or specifies their own attributes, the policies may not be interoperable. Using pre-agreed attributes will make policies more unified and easier to understand.
III Considerations in the Implementation/Evaluation Phase
During the implementation/evaluation phase, organizations install or implement systems, configure and enable system security features, test these functional features, and finally obtain formal authorization to operate the system. In this phase, most considerations are focused on optimizing performance and ensuring the normal operation of security features.
1 Attribute Caching
When transitioning from prototype/pilot to deployment, ABAC solutions can consider using attribute caching to improve performance. If each access decision requires cross-network attribute requests, ABAC performance may be negatively affected. This is particularly evident in low bandwidth, high latency environments.
In addition to performance issues related to attribute caching, organizations need to weigh the impact of attribute freshness on security. Attributes that cannot be refreshed continuously are obviously less secure than those refreshed in real-time. For example, the access permissions of the subject may have changed since the last refresh, but these changes will not be reflected in the cached data before the next refresh buffer data.
Environments with scattered connectivity require local-level caching of attributes. The security consequences of using local cached attributes need to be determined at the policy level within the organization and appropriate technical means should be used to address them. In these disconnected environments, administrators can use risk-based analysis as the basis for access decisions because local (disconnected) level attributes may change or be deleted before the system refreshes. The use of potentially outdated cached attributes by local (disconnected) systems may pose certain risks to the system because the local system does not use the latest available attributes. Therefore, it is necessary to conduct a risk-based analysis on whether to deploy such solutions.
For example, now it is to be deployed on a ship that has intermittent, non-ideal network connections with the enterprise network. Since the user group to be supported during the entire transportation process only has minor changes, it is not as important to support 'unexpected' system users. In this case, batch download and local storage of principal attributes may be sufficient for most local access control decisions. Therefore, principal attribute data can be stored on the ship throughout the deployment process, and local applications and services can use the data stored in the local storage without accessing the authoritative enterprise attribute source. Although this is a case in a special environment, it should not be considered as the only solution.
2 Attribute source minimization
Minimizing the number of attribute sources in authorization decisions can improve performance and simplify the security management of ABAC solutions. Organizations planning to deploy ABAC solutions may benefit from the close working relationships established among all stakeholders in the organization during the solution deployment process.
3 Interface specifications
To ensure reliable access to ABAC services, all organizations participating in information sharing through the enterprise ABAC function should have a thorough understanding of the interfaces, interaction methods, and prerequisites of various requests (including attribute requests and DP requests). It is also important to ensure that update notifications are provided to all organizations that depend on these components when infrastructure and interface requirements change, so that they can plan modifications to the relevant components.
Four Considerations in the operation/maintenance phase
In the operation/maintenance phase, both the system and the product are in place, and the system's operation, enhancement, and modification have been developed and tested, as well as hardware and software additions or replacements. At this stage, the organization should monitor system performance to ensure it meets the predefined user and security requirements, and that necessary system modifications have been completed.
1 Availability of quality data
Information required for access control decisions (including, in some cases, the decision itself) may be located outside of the subject and user, therefore, access to information and services will be more dependent on the ability of external service providers to deliver timely and accurate data. The infrastructure must be robust, well-tested, flexible, and capable of scaling according to task requirements. This is essential for supporting attribute services, attribute storage, policy storage, policy and attribute generation and verification components, decision engines, metadata repositories, and information channels. If outsourced, the service agreement should specify in detail the requirements for availability, response time, data quality, and integrity. For example, for data and services considered critical components, considerations must be given to failover, redundant backup, and business continuity. To maintain the availability of high-quality data, it is necessary for trained and authorized personnel to perform the addition, update, and deletion of attribute values, and to conduct regular audits.
The formal agreements between attributes, service providers, and users should meet appropriate service, quality, availability, protection, and use standards. Various laws and regulations stipulate responsibilities, liabilities, and penalties related to the protection of corresponding information. The agreements should include these requirements as well as requirements related to data responsibility.
Establishing appropriate levels of trust agreements between organizations is important. These agreements will help formalize these trust relationships into a series of requirements and may help with the punishment of violations. The APS and MOU/MOA of attribute services and authoritative and responsible attribute sources can also transform organizational strategies into operational procedures. These formal agreements describe the purpose, use, participants, responsibilities, and management of these services.
Conclusion
This document organizes many previously independent ABAC knowledge to bridge the gap between existing technology and ABAC implementation, and to meet the interest generated by ABAC within the federal government.
ABAC generates policy decisions by calculating the attribute values of entities (subjects and objects), operations, and the environment in the policy rules, to control access to objects. ABAC relies on the evaluation of the attributes of the subject, the attributes of the object, and formal relationships or access control rules (defining the subject-object attribute combinations that should satisfy the allowed operations). ABAC supports precise access control, allowing a large number of discrete inputs for access control decisions, as well as different combinations of these variables to reflect different rules, strategies, or access restrictions. Therefore, ABAC allows an unlimited number of combinations of attributes to meet the needs of a rich set of policies.
This article defines the basic concepts necessary to understand ABAC. Specifically, it includes subject and object attributes, as well as the general characteristics of the ABAC model and its components. Some suggestions are given according to the system development life cycle for enterprises to refer to in the planning, design, development, implementation, and operation of ABAC projects. In particular, the advantages and common defects of the ABAC mechanism are discussed for large enterprises.
ABAC provides unprecedented flexibility and security while promoting information sharing among different organizations. It is crucial that the development and deployment of these capabilities are based on common conceptual and functional requirements to ensure maximum interoperability. ABAC is particularly suitable for large enterprises. The ABAC system can implement existing role-based access control strategies and support the migration from role-based access control to more granular access control strategies based on the different characteristics of the requestor. It supports external (non-expected) users and provides more efficient management for them. However, compared to simple access control systems, the ABAC system is more complex, resulting in higher implementation and maintenance costs.
评论已关闭