CONSISTENT RULE-BASED POLICY ENFORCEMENT FOR ACCESS AUTHORIZATION

The technology disclosed herein enables control of permissions to access resources of data environments based on business requirements. In a particular example, a method provides determining a high-level requirement for access to data environments and defining an access policy that maps to the high-level requirement. The method further provides generating one or more rules to implement the access policy and enforcing the rules on access requests to the data environments to satisfy the high-level requirement.

TECHNICAL BACKGROUND

Modern enterprises use numerous data environments to store, manage, and/or process data and those environments may be managed by different systems, applications, and/or platforms from different providers and each may use its own data repository (e.g., database). For instance, different departments may employ different database systems depending on the features offered by the respective system (e.g., accounting may use a first database system while human resources uses a second). In some cases, a single department may itself use multiple platforms for data repositories depending on the capabilities of each platform even if the platforms manage similar data sets. For example, human resources may use one platform to onboard and terminate employees from the enterprise while another platform is used to handle employees' compensation and benefits. Even though identity environments, such as IAM and Okta, may be employed to manage user identities and access, it can still be difficult to ensure an overarching business requirement is properly implemented across all data environments and users.

SUMMARY

The technology disclosed herein enables control of permissions to access resources of data environments based on high-level requirements. In a particular example, a method provides determining a high-level requirement for access to data environments and defining an access policy that maps to the high-level requirement. The method further provides generating one or more rules to implement the access policy and enforcing the rules on access requests to the data environments to satisfy the high-level requirement.

In another example, an apparatus is provided having one or more computer readable storage media and a processing system operatively coupled with the one or more computer readable storage media. Program instructions stored on the one or more computer readable storage media, when read and executed by the processing system, direct the apparatus to perform the steps of the above-recited method.

DETAILED DESCRIPTION

The rule and policy engine described herein automates Identity Governance and Administration (IGA) by mapping business requirements to enforceable policies and rules across data environments used by a business. A business requirement indicates, in a general sense, which users (e.g., employees, contractors, etc.) should have access to which resources of the data environments. A business requirement may exist to ensure compliance with regulatory schemes, information security needs, or some other type of compliance that may affect a business' operations. For example, a business requirement may be employees located outside of the United States cannot access financial data. The rule and policy engine converts that business into one or more policies/rules that effect the requirement in the data environments of the business. While referred to herein as a business requirement since business requirements art often the impetus for access policies, the high-level nature of the rule may be associated with other types of requirements (e.g., those for educational institutions or other types of entities).

FIG.1illustrates implementation100for controlling permissions to access resources based on high-level requirements. Implementation100includes rule and policy engine101, data environments102, identity environments103, user terminal104, and user terminal105. Rule and policy engine101and data environments102communicate over respective communication links111. Rule and policy engine101and user terminal104communicate over communication link112. Rule and policy engine101and user terminal105communicate over communication link114. Rule and policy engine101and identity environments103communicate over respective communication links113. While communication links111-114are shown as direct links, communication links111-113may include intervening systems, networks, and/or devices. Rule and policy engine101executes on one or more computing systems, such as server systems, having processing and communication circuitry to operate as described below. User terminals104and105are each a user operated computing system, such as a desktop workstation, laptop, tablet computer, smartphone, etc.

In operation, rule and policy engine101performs operation200to generate rules for implementation across identity environments103and data environments102to ensure business requirements are enforced in data environments102. Data environments102include one or more systems that host databases, such as databases for Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP), tables, files, applications, or other computing resources provided to accessing systems—including combinations thereof. Identity environments103include one or more systems that maintain information about users (e.g., user identity information, user attributes, etc.) and information about which of data environments102(including specific data/features therein) each user is allowed to access. Identity environments103may include an active directory (AD) server, an Okta® system, an Identity and Access Management (IAM) system, a privilege access management (PAM) system, human resources management system (HRMS), identity and access governance (IAG) system, or any other type of system that maintains the user information discussed above. Identity environments103maintain identity information about users that may access one or more of data environments102. The identity information may include authorization information indicating whether given users are allowed to access particular resources provided by data environments102or ones of data environments102as a whole. In some examples, a data environment of data environments102may authorize a user itself based on identity information for the user included in identity environments103. For instance, identity environments103may indicate information about a user, such as a work group for the user, the user's job title/role, a seniority of the user, a security clearance level for the user, or any other type of information that may affect which of data environments102the user can access. In further examples, a data environment of data environments102may authorize users independently.

Regardless of the arrangement between data environments102and identity environments103to determine access privileges of users, rules are implemented by the environments to define which users have access to which resources of data environments102. The rules may indicate which users have access to which resources or may indicate which users do not have access to which resources. The rules may further indicate specific activities that a user is able, or is not able, to perform with a particular resource rather than a blanket allowance or denial of access. For example, a rule may indicate whether a user is allowed data read, data write, metadata read, metadata write, and non-data access—including combinations thereof. The rules can, therefore, be used to enforce a business requirement regarding access to data environments102and rule and policy engine101ensures the appropriate rules are in place to enforce that business requirement.

FIG.2illustrates operation200to control permissions to access resources based on high-level requirements. In operation200, rule and policy engine101determines a business requirement for access to data environments102(step201). The business requirement may be defined from a guardrail perspective or an allowed-activity perspective. Guardrail requirements are those business requirements that indicate activity that cannot occur in data environments102. For instance, a business requirement that users located outside a particular geographic area cannot access financial information in data environments102is a guardrail requirement because it is guarding against undesired access outside of the area. Allowed-activity requirements are those business requirements that indicate activity that is allowed to occur in data environments102. For example, a business requirement that users in the financial workgroup can access financial information in data environments102is an allowed-activity requirement. The business requirement in this example may be received from user terminal104. For instance, user141may be an administrator in charge of data environments102for the business and may enter the business requirement into user terminal104(e.g., via an interface to rule and policy engine101executing on user terminal104). It should be understood that, while the examples herein refer to business requirements, the other types of entities, such as educational institutions, also use environments like data environments102and identity environments103. Those entities may also have high-level rules (e.g., business requirements) that can be implemented by rule and policy engine101as described herein.

Rule and policy engine101defines an access policy that maps to the business requirement (step202). The access policy is defined relative to the specific systems and resources of data environments102. For example, while a business requirement may define “financial information,” the access policy defines specific resources of data environments102that contain financial information (e.g., specific databases or entire environments). Rule and policy engine101may track resources of data environments102or receive information about the resources to determine attributes of the resources (e.g., the type of information contained in the resource). From the access policy, rule and policy engine101generates one or more rules to implement the access policy (step203). In some cases, a single rule may be able to implement the access policy. However, in many cases, multiple rules may be required to implement the access policy. For example, different ones of data environments102may use different ones of identity environments103. A different rule may be necessary to account for each of the identity environments103(e.g., different formatting or conventions used by the respective environments). For instance, a first of identity environments103may identify users in one manner (e.g., by unique user number) while a second of identity environments103may identify users in another manner (e.g., by username).

Rule and policy engine101enforces the rules on access requests to the data environments to satisfy the business requirement (step204). To enforce the rules, rule and policy engine101may transmit respective rules to the corresponding ones of data environments102and/or identity environments103that will apply the rules. In some examples, identity environments will handle all authorizations and, therefore, receive the rules from rule and policy engine101while, in some other examples, data environments handle at least a portion of the authorizations and implement rules independently of an identity environment. When a new access request (e.g., to read or write data) is received from user terminal105by one of data environments102, the receiving data environment, or an identity environment associated with the data environment, applies one of the rules from rule and policy engine101(in addition to other existing rules) to determine whether the access request associated with user142is allowed. If the rule indicates that user142is allowed access, then a response to the access request allows access. If the rule indicates that user142is not allowed access, then a response to the access request denies access.

In some examples, the rules generated by rule and policy engine101may not be enforced immediately. Instead, the rules may go through a lifecycle to ensure rule and policy engine101has generated rules that will not adversely affect operations of data environments102. The lifecycle may include five stages. A proposed stage, an informational stage, an alerting stage, a recommendation stage, and then an auto-enforced stage. Other examples may use fewer stages than the five described (e.g., the alerting stage may be skipped). When in the proposed stage, rule and policy engine101proposes the rules to user141via user terminal104. By first proposing the rules, user141can identify any glaring issues the rules may have (e.g., may determine that a resource has been misidentified as being covered by the business requirement). Upon user141approving moving to the informational stage, rule and policy engine101begins tracking when an access request is received to which one of the rules would apply if enforced. Rule and policy engine101can then provide information about the access requests to user141. For instance, the information may include details about the access requests and whether a response to the access request (e.g., access allowance or denial) would have changed had the rules been in force.

If user141is satisfied with the information received from rule and policy engine101, user141may direct rule and policy engine101to move the rules to the alerting stage. In the alerting stage, rule and policy engine101may alert user141each time one of the rules would have been triggered by an access request. The alerts may be provided while still collecting information like in the information stage. In some cases, rather than simply notifying user141, the alerts may allow user141to direct rule and policy engine101to go ahead with enforcing the rule on the access request that triggered the alert. Subsequent to the alerting stage, the rules move to the recommendation stage where rule and policy engine101recommends to data environments102whether to start automatically enforcing the rules. The recommendation may be based on feedback received from user141during the informational and alerting stages and/or may be based on rule and policy engine101's own determinations. For instance, rule and policy engine101may compare the performance of the rules to the performance of other rules already in force. If the performance is similar, then rule and policy engine101may recommend that the new rules be auto-enforced as well. Upon user141indicating to rule and policy engine101that the rules are ready for auto-enforcement, rule and policy engine101implements enforcement of the rules as discussed above in step204.

The lifecycle may apply to policies rather than the rules that make up the policies. As such, user141may be able to determine whether a policy as a whole should be auto enforced through the discussed lifecycle stages rather than looking directly at the rules of the policy.

It should be understood that, while human users are described in the examples above, users accessing data environments102may include non-human users, such as systems, applications, micro-services, etc., or some combination thereof.

FIG.3illustrates operational scenario300for controlling permissions to access resources based on high-level requirements. Operational scenario300is an example of how business requirement301(i.e., a high-level requirement) is enforced by rule and policy engine101using rules generated by rule and policy engine101. Business requirement301, in this example, states “no one outside of human resources (HR) can access HR information systems.” The language used for business requirement301is natural language that may be spoken or written by a human user. English is used in this case, although, other languages may be used. As such, a user need not be trained on a particular syntax required to draft an access rule but can, instead, describe the desired effect of the access rule(s) at a higher-level

Based on business requirement301, rule and policy engine101creates access policy302at step 1. Rule and policy engine101may create access policy302by parsing the natural language of business requirement301to determine components of the language that are relevant to access policies and rules. A natural language processing algorithm may be used. Upon the processing indicating that HR information systems are relevant, rule and policy engine101determines that data environment102A and data environment102B of data environments102are HR information systems. Different ones of data environments102may be defined in rule and policy engine101as being systems of particular types, rule and policy engine101may query data environments102to determine which type of systems they are, or rule and policy engine101may determine the system type in some other manner. Similarly, when a policy applies to components of data environments102(e.g., datasets, applications, etc.), rule and policy engine101may determine which components belong to which aspects of the business (or entity) in a similar manner. Rule and policy engine101can then create access policy302, which is a more specific version of business requirement301tailored to the specific data environment situation that rule and policy engine101oversees. In this case, access policy302states “HR team allowed read access to data environment102A and data environment102B.”

From access policy302, rule and policy engine101creates access rule303and access rule304at step 2. Rule and policy engine101may create two rules because data environment102A and data environment102B may use different ones of identity environments103. Thus, access rule303may be a rule in a format required by a first of identity environments103and access rule304may be a rule in a format required by a second of identity environments103. Each rule indicates a source (e.g., the user requesting access), a condition of the source (e.g., a business department, workgroup, title, seniority level, or some other type of attribute describing a user), a destination (e.g., a data environment or resource of a data environment), a condition of the destination (e.g., a business department, workgroup, or other type of attribute describing the destination, and an action to be taken if an access request satisfies the rule (e.g., allow/deny read, allow/deny write, etc.). The source and destination may be considered to have a “has relation to” relationship in a query. So, when determining whether a rule should apply to an access request a query may use the source has relation to the destination as the query. In access rule303, the source is user142, user142is on the HR team, the destination is data environment102A, and data environment102A is an HR information system. Access rule304is similar to access rule303but the destination is data environment102B, which is also a HR information system. While the components of access rule303and access rule304are shown similarly in operational scenario300, it should be understood that different formats or conventions may be used for access rule303and access rule304depending on the identity environment the rule is destined for. Once access rule303is generated, rule and policy engine101may implement access rule303in the one of identity environments103that handles authorization for data environment102A. Likewise, once access rule304is generated, rule and policy engine101may implement access rule304in the one of identity environments103that handles authorization for data environment102B. Alternatively, before implementation, rule and policy engine101may enter access rule303and access rule304into a lifecycle like that described above (e.g., may propose access rule303and access rule304in accordance with the first stage of the lifecycle).

In some examples, rule and policy engine101may check to determine whether access rule303and access rule304conflicts with any other rules in use by data environments102. For instance, while access rule303indicates that user142has read access to data environment102A, another rule may deny that read access. In that case, rule and policy engine101will not implement access rule303due to the conflict. Additionally, rule and policy engine101may implement exceptions to a rule. For example, a user may be new to the HR team and may not yet be allowed to access data environment102A. User141may direct rule and policy engine101to create an exception to access rule303.

FIG.4illustrates operation400to control permissions to access resources based on high-level requirements. In operation400, rule and policy engine101identifies rules with overlapping entity types to access rule303and access rule304(step401). A rule with an overlapping entity type is a rule with a source or a destination in common with access rule303or access rule304. In this specific example, access rule303and access rule304have only user142, data environment102A, and data environment102B as entities. Therefore, rule and policy engine101is only looking for other rules having one or more of those entities.

Rule and policy engine101identifies conflicting rules from within the overlapping rules (step402). For example, if another rule indicates that user142cannot read data environment102A, then access rule303conflict with that other rule. If there are any conflicting rules, rule and policy engine101does not implement access policy302(i.e., does not implement access rule303or access rule304) (step403). In some examples, rule and policy engine101may alert user141to the conflict indicating access policy302cannot be enforced. User141may then change business requirement301or create an exception to overcome the conflict.

Similarly, in some examples, rule and policy engine101may determine the one or more access rules to be inconsistent. That is, the rules may be inconsistent by indicating a condition that cannot possibly be met (e.g., the source may be users in a particular department and the condition may be a role that does not exist in that department). For example, a rule may define a condition for a source that is not possible for that source. In those cases, rule and policy engine101may notify user141about the inconsistency to indicate the rule will not be enforced. User141can then make changes to account for the inconsistency.

FIG.5illustrates operation500to control permissions to access resources based on high-level requirements. Operation500is an example of how rule and policy engine101may handle the lifecycle of an access rule, or rules in some cases (e.g., access rules303and304generated from business requirement301), generated from a high-level requirement (step501). A rule may begin in a proposed stage where rule and policy engine101presents the rule to user141, which is a user tasked with overseeing rules implemented by rule and policy engine101. The rule may be presented through an interface to rule and policy engine101executing in user terminal104. The rule may be presented in a format that enables user141to clearly understand to which source the rule applies, to which destination the source has relation, one or more conditions that must be met, and an action taken when the conditions are satisfied. User141can then determine whether the rule is consistent with the high-level policy/requirement for which the rule was generated to enforce. User141may be the user that provided the high-level policy to rule and policy engine101or another user, such as one not technically versed in rule creation, may have provided the rule in the plain language allowed by rule and policy engine101for high-level rules.

The rule remains at the proposed stage until user141confirms the rule consistent with the desired high-level policy (step502). If the user does not confirm the rule is consistent, then rule and policy engine101does not advance the rule to the next stage in the lifecycle. Rule and policy engine101may discard the rule and await a new rule to be generated that is consistent with the high-level policy. In some examples, user141may be able to reword the high-level policy for rule and policy engine101to generate an acceptable rule or user141may be able to edit the generated rules.

Once the user confirms that a generated rule is consistent with the intentions of the high-level policy, the rule moves to an informational stage of its lifecycle. In the informational stage, rule and policy engine101identifies access requests to data environments102satisfying the rule and presents those access requests to user141without taking the proscribed action (step503). The access requests may be presented to user141individually (e.g., in real time upon being identified) or may be presented in groups (e.g., user141may receive a report of identified access requests from the past day). User141can review the identified access requests to determine whether the rule is being satisfied by the right type of access requests (e.g., those that the high-level policy intended to capture). Since no action is taken on the access requests during the informational stage, no harm is done if the rule is satisfied by unintended access requests. Instead, user141is afforded with another opportunity to change the rule or high-level policy to capture the appropriate access requests.

If user141is happy with the results they are presented with during the informational stage, user141directs rule and policy engine101to advance the rule to an alerting stage (step504). Should user141desire additional information (e.g., due to the sample set of access requests being too low for user141to decide), user141may allow the rule to remain in the informational stage. Once directed to enter the alerting stage for the rule, rule and policy engine101alerts user141when an access request is received that satisfies the rule (step505). The alert notifies user141about the access request and indicates the rule has been satisfied, enabling user141to decide whether the rule should be enforced. If user141does not want the rule to be enforced on the identified access request, user141may indicate such to rule and policy engine101(step506). User141may explicitly indicate that the rule should not be enforced or rule and policy engine101may be configured to not enforce the rule if a response from user141is not received within a predefined amount of time. Alternatively, rule and policy engine101may be configured to enforce the rule if no response is received within the predefined amount of time. In some examples, the informational stage may be omitted since the alerting stage informs user141about rule-satisfying access requests while also providing user141with the option to enforce the rule.

If user141wants rule and policy engine101to enforce the rule, rule and policy engine101provides user141with the option to auto-enforce the rule (step507). If user141declines to have the rule auto-enforced, rule and policy engine101enforces the rule on the access request by performing the action defined by the rule (e.g., blocking the access request) (step508). The rule remains in the alerting stage and rule and policy engine101returns to step505to identify and notify user141about a subsequent access request that satisfies the rule.

In contrast, if user141determines that the rule is ready for auto-enforcement, rule and policy engine101moves the rule to the auto-enforced stage of the lifecycle. The auto-enforced stage is the final stage of the rule's lifecycle where the rule reaches maturity and is enforced with other existing rules also at the auto-enforced stage. At the auto-enforced stage, rule and policy engine101enforces the rule on the identified access request and continues to enforce the rule on subsequent access requests that rule and policy engine101identifies as satisfying the rule (step509).

FIG.6illustrates operation600to control permissions to access resources based on high-level requirements. The rules described above may have exceptions. For example, a rule may prevent employees in one department from accessing certain data in data environments102. An exception to that rule may allow a particular employee (e.g., the head of the department) to access the data. In operation600, an exception to a rule being enforced is received by rule and policy engine101(step601). The exception may be one of multiple exceptions to the rule either received at the same time or already enforce. The exception may be received from user141or another user. The exception may be first defined in a high-level language like a high-level requirement. The exception must be disjoint from the other exceptions (i.e., has no overlap with other exceptions). If the exception is not disjoint (step602), then rule and policy engine101notifies user141that the exception cannot be enforced (step604). Rule and policy engine101may further provide a recommendation for user141to change the exception in a manner that is enforceable (step605). For example, the rule may indicate that everyone in a department can access a particular dataset. An exception may define a subset of employees that can only access the dataset during certain times of day and another exception may define an employee in that subset as not being able to access the dataset at any time. Those two exceptions are not disjoint. Rule and policy engine101may recommend that the former exception be modified to remove the employee from the subset so that the latter exception can be implemented.

When rule and policy engine101determines that the received exception is disjoint (step602), rule and policy engine101begins enforcing the rule with the exception (step605). Any future exceptions received at step601will, therefore, have to be disjoint from this enforced exception. Although, in some examples, exceptions may be received all at once and rule and policy engine101may process them all together to ensure they are disjoint from one another before enforcing the exceptions.

FIG.7illustrates operation700to control permissions to access resources based on high-level requirements. In operation700, an exception to a rule is received (step701). Rule and policy engine101compares the exception to existing rules (step702). An exception can been seen as a rule in itself so it is possible that rules being enforced by rule and policy engine101may be satisfied by access requests similar to what will satisfy the exception. Rule and policy engine101determines whether there is a candidate in the existing rules that can be modified to continue performing as it already is while also capturing the exception (step703). For instance, an existing rule may include the same source and destination entities as the exception along with similar conditions and actions. Using the dataset example from above, one of the exceptions allowed access to a dataset by a subset of employees only during certain times of day. Rule and policy engine101may identify a rule that allows a different set of employees access to that same data set only during the same times of day. Rule and policy engine101may, therefore, determine that rule is a candidate for modification. Rule and policy engine101modifies the existing rule accordingly (step704) and continues to enforce the existing rules after modification (step705). In the above example, rule and policy engine101will modify the existing rule to cover the subset of employees defined by the exception in addition to the different set of employees already included in the rule. If rule and policy engine101is unable to find a candidate rule, rule and policy engine101enforces the exception in conjunction with the rule for which the exception was defined (step706).

It should be understood that both operation600and operation700may be performed on exceptions. For instance, operation600may first be performed to ensure the exception does not conflict with other exceptions and then operation700may be performed to incorporate the exception into a rule if possible.

FIG.8illustrates computing architecture800for controlling permissions to access resources based on high-level requirements. Computing architecture800is an example computing architecture for rule and policy engine101, although rule and policy engine101may use alternative configurations. A similar architecture may also be used for other systems described herein (e.g., data environments102, identity environments103, and user terminals104-105), although alternative configurations for those systems may also be used. Computing architecture800comprises communication interface801, user interface802, and processing system803. Processing system803is linked to communication interface801and user interface802. Processing system803includes processing circuitry805and memory device806that stores operating software807.

Communication interface801comprises components that communicate over communication links, such as network cards, ports, RF transceivers, processing circuitry and software, or some other communication devices. Communication interface801may be configured to communicate over metallic, wireless, or optical links. Communication interface801may be configured to use TDM, IP, Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format—including combinations thereof.

User interface802comprises components that interact with a user. User interface802may include a keyboard, display screen, mouse, touch pad, or some other user input/output apparatus. User interface802may be omitted in some examples.

Processing circuitry805comprises microprocessor and other circuitry that retrieves and executes operating software807from memory device806. Memory device806comprises a computer readable storage medium, such as a disk drive, flash drive, data storage circuitry, or some other memory apparatus. In no examples would a computer readable storage medium of memory device806, or any other computer readable storage medium herein, be considered a transitory form of signal transmission (often referred to as “signals per se”), such as a propagating electrical or electromagnetic signal or carrier wave. Operating software807comprises computer programs, firmware, or some other form of machine-readable processing instructions. Operating software807includes rule and policy engine808. Operating software807may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When executed by processing circuitry805, operating software807directs processing system803to operate computing architecture800as described herein.

In particular example, rule and policy engine808directs processing system803to determine a business requirement for access to data environments and define an access policy that maps to the business requirement. Rule and policy engine808further directs processing system803to generate one or more rules to implement the access policy and enforce the rules on access requests to the data environments to satisfy the business requirement.

The descriptions and figures included herein depict specific implementations of the claimed invention(s). For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. In addition, some variations from these implementations may be appreciated that fall within the scope of the invention. It may also be appreciated that the features described above can be combined in various ways to form multiple implementations. As a result, the invention is not limited to the specific implementations described above, but only by the claims and their equivalents.