DE112021005656T5 - ANALYSIS OF ROLE REACHABILITY WITH TRANSITIVE TAGS - Google Patents

Abstract

Methods, systems, and computer-readable media for analyzing role reachability with transitive tags are disclosed. An access control analysis unit determines a graph that includes a plurality of nodes and one or more edges. The nodes represent roles in a provider network that hosts resources. The roles are associated with access control policies that grant or deny access to individual resources. One or more of the access control policies grant or deny access (at least in part) based on one or more key-value attributes. The access control analysis unit determines (at least in part) based on a role reachability analysis of the graph whether a first role can assume a second role using one or more role assumption steps for a particular state of the one or more attributes. The one or more attributes may include one or more transitive attributes that persist during the one or more role assumption steps.

Description

STATE OF THE ART

Many businesses and other organizations operate computer networks that connect numerous computing systems together to support their operations, such as with computing systems co-located (e.g., as part of a local area network) or instead located in multiple different geographic locations (e.g. connected via one or more private or public intermediate networks). For example, distributed systems housing a significant number of interconnected computing systems have become commonplace. Such distributed systems can provide back-end services for servers that interact with clients. Such distributed systems may also include data centers operated by entities to provide computing resources to customers. Some data center operators provide network access, power, and secure installation capabilities for hardware owned by different customers, while other data center operators offer "full-service" facilities that also include hardware resources made available to their customers. As distributed systems have increased in scale and scope, the tasks of provisioning, administering, and managing resources have become more complicated.

A distributed system can provide remote clients with access to various services implemented largely within the distributed system and accessible over a network such as the Internet. Examples of such systems include online retailers, internet service providers, corporate networks, cloud computing services, web-based hosting services, and so on. Distributed systems can attach great importance to the security of user access to system resources using appropriate permissions. Resource owners and resource administrators often use such access control policies to control user access to computing resources to support resource owner, administrator, and user requests. Defining and managing user roles, permissions, or policies can become increasingly complex, particularly as the size and/or complexity of the system or the number of computer system users increases.

character list

• 1 12 illustrates an example system environment for role reachability analysis with transitive tags, according to some embodiments.
• 2 12 illustrates an example of an authorization scheme usable for role reachability analysis with transitive tags, according to some embodiments.
• 3 12 illustrates an example of a role reachability graph usable for analyzing role reachability with transitive tags, according to some embodiments.
• 4 Figure 12 illustrates an example of role-taking steps with transitive tags, according to some embodiments.
• 5 12 is a flow chart illustrating a method for analyzing role reachability with transitive tags, according to some embodiments.
• 6 FIG. 12 is a flow chart illustrating further aspects of the method for analyzing role reachability with transitive tags, according to some embodiments.
• 7 12 is a flow chart illustrating a method for analyzing role reachability using policy additions, according to some embodiments.
• 8th 13 illustrates further aspects of the example system environment for role reachability analysis with transitive tags, including an equivalence result generated in response to a request to analyze the equivalence of two security policies, according to some embodiments.
• 9 1 illustrates an example computing device that may be used in some embodiments.

While embodiments are described herein by way of example of multiple embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and detailed description are not intended to limit the embodiments to the precise form disclosed, but rather the invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope as set forth in the appended claims Are defined. The headings used in this document are for organizational purposes only and should not be used to limit the scope of the description or the claims. As used in this application, the word "may" is used in a permissive sense (ie, "have the potential") rather than in a mandatory sense (ie, "must"). Likewise, the words "include,""comprising," and "includes" mean "including, among others."

DETAILED DESCRIPTION OF EMBODIMENTS

Various embodiments of methods, systems, and computer-readable media for analyzing role reachability with transitive tags are described. Software products (e.g., services or applications) may run on a distributed system, a service-oriented system, or a cloud provider network that includes a variety of resources and other services. To allow or deny access to such resources and services, the distributed system may offer built-in techniques for enforcing access control policies using authentication and authorization. Using previous approaches to access control policy management, delegated role-based management and attribute-level tag-based management have been used to control access to resources in distributed systems. Some approaches have combined role-based management with tag-based management. For example, a cloud provider network may support transitive, or "persistent," session tags, allowing users to maintain tag restrictions along a role inheritance chain. Under certain circumstances, in the presence of subtle transitive tag behavior with potentially overlapping string constraints, a policy configuration can result in an unexpected privilege escalation. In such a system, it may be desirable to determine whether a particular user or role can be granted access to a particular role in the role inheritance chain given a particular transitive tag state.

The above challenges are addressed, among other things, by embodiments of the techniques described herein, where automated techniques can be used to perform symbolic automated reasoning analysis regarding role reachability for an access control system. In particular, an access control analysis entity may perform a role reachability analysis to determine whether a given user or role under a given state of a transitive or "persistent" tag can get to another given role, possibly through one or more role assumption steps. The role reachability analysis can use a graph with nodes representing roles and edges representing role-taking transitions. Role assumption can be made dependent on key-value attributes (tags) for a role session, including transitive tags. Transitive tags (or "persistent" tags) can represent key-value attributes that persist while assuming another role. Under certain circumstances, a status of the tags can change during the role takeover. For each node, the parsing unit can determine its possible neighbors by observing that the current state of the transitive tag is only known by a set of tags whose keys are either explicitly mentioned and therefore their associated conditions are known, or by underspecified tags whose values are unrestricted or partially restricted, can be expanded. The analysis unit may aggregate one or more constraints for the one or more tags as specified by access control policies associated with role assumption steps. Based (at least in part) on performing a role reachability analysis using such a graph, the access control analysis engine can identify potentially unexpected configurations in a distributed system.

Nodes corresponding to a first role and a second role may be adjacent or contiguous in the graph, such that inheriting the second role from the first role may involve only one inheritance step. In determining whether the first role can assume the second role, the role reachability analysis can determine an access control policy that authorizes an addition to a role assumption request for the second role. For example, such a policy may allow all actions except assuming the second role. The new access control policy may represent a negation of the inheritance request and may be referred to as a negated policy. The role reachability analysis can analyze the negated policy that complements a role over authorized to take request in relation to one or more other access control policies. In some embodiments, the negated policy may be compared to a role inheritance policy for the second role for a particular state of the tags. The analysis of the policies may be performed using a policy comparison service that determines whether an access control policy is more valid, less valid, equally valid, or not comparable to another access control policy with respect to another access control policy. As tag string space can be unlimited (e.g. due to wildcards), the role reachability analysis can select one or more representative values for one or more key-value tags from a set of potential values (equivalence classes) for the tag(s). ) choose. The status of the tags can be determined (at least in part) based on the representative value(s). In some embodiments, the negated policy may include the role assumption policy for the second role if and only if there is no context under which the assumption of the second role is authorized. In some embodiments, the first role may be authorized to assume the second role if and only if the negated policy does not include the role assumption policy for the second role.

As one skilled in the art will appreciate in view of this disclosure, embodiments may be able to achieve certain technical advantages, including some or all of the following: (1) enhancing the security of a distributed system by automatically determining whether a role, used for access control for a state of a transitive tag, can gain access to another role through role inheritance; (2) enhancing the security of a distributed system by automatically notifying relevant users or accounts when access control policies are determined to have the potential for unexpected privilege escalation; and so forth.

1 12 illustrates an example system environment for role reachability analysis with transitive tags, according to some embodiments. In various embodiments, an access control analysis engine 100 may use automated techniques to analyze aspects of access control policies 165 and the roles associated therewith, and to draw conclusions about how roles relate to other roles. The access control analysis unit 100 can be implemented in a provider network 190 that provides access to services and resources 170 . Provider network 190 may include an access control policy manager 160 that allows access to services and resources 170 to be granted or denied. For example, policy manager 160 may be used to approve or deny access requests 155 from an entity referred to as principal 150 . Policy manager 160 may use a set of access control policies 165 to determine whether to allow or deny a particular access request. The Client and Policies are referenced to 2 explained in more detail.

Access control in provider network 190 may be implemented with concepts of accounts, users within accounts, and federations of accounts from third party identity providers to authenticate identities. Access control in provider network 190 may be implemented using role concepts, role assumptions, and a general policy language to specify what resources and services these identities can access and under what conditions, e.g. B. using policies 165. A role can represent an identity with associated permissions policies that dictate what the role can and cannot do. In some embodiments, a role is not uniquely associated with an individual, but may also be acceptable to principals such as users, other roles, services, or resources (e.g., computing entities). These users can be associated with the same account, a different account, a service, or an external identity authenticated by a supported identity provider (such as a corporate directory or a Security Assertion Markup Language (SAML) provider). When a role is assumed, role assumption can provide temporary security credentials for a role session to allow only as much access as is required to perform the required task, rather than providing long-term credentials such as passwords or access keys.

The access control policies 165 and corresponding roles can be used in a distributed system where services and resources 170 may be accessible via access requests according to the access control policies. The distributed system may represent a multi-tenant provider network 190, for example. The resources that can be accessed via access control policies 165 can include compute instances, storage resources, database resources, network resources, and so on. Services accessible through access control policies 165 may include software products that vary in response to requests from clients Run tasks, including other services. In some embodiments, the services can offer access to the resources. For example, provider network 190 may offer a virtual computing service that provisions computing instances from pools of available resources and then allows clients to run those instances. As another example, provider network 190 may offer a cloud-based storage service that reserves storage resources from pools of available resources and then allows clients to read from and write to those storage resources. Services and resources 170 may include application programming interfaces (APIs) through which other entities may request actions to be performed.

In one embodiment, access control policy manager 160 associated with provider network 190 may manage access control policies 165 that dictate which users can access which services and resources, and under what circumstances those users can access services and resources 170. Access control policies 165 may include or specify permissions or privileges with respect to particular services and resources 170 . An owner of a service or resource may grant a user (or group of users) access to the service or resource to enable the user to perform one or more actions while maintaining the security of the service or resource. To manage user privileges, a service or resource owner can delegate authority to access a particular service or resource in a variety of ways to allow different levels of access according to the resource's access policies. A principal 150 (or set of principals) who is/are authorized by delegating access rights to a particular service or resource may be referred to herein as an authorized delegate. An access control policy may be associated with a role managed by policy manager 160 or another identity and access management service. The role can be assigned to one or more users or one or more user groups. For example, the role may be used by a service or application during its execution on provider network 190 . In some embodiments, an access control policy may follow the principle of least privilege. A particular policy may allow access to one set of services and resources 170 but not to another set of services and resources 170.

In order to reach conclusions about the security posture of systems built to run in a provider network 190 or other distributed environment, the access control analyzer 100 may use automated techniques to answer role reachability questions. The access control analysis unit 100 can determine what a principal can do via the transitive completion of role assumption steps. For example, the access control analysis unit 100 can determine whether the role r ₁ in account a ₁ can assume the role r ₂ in account a ₂ , which in turn can assume the role r ₃ in account a ₃ . In some circumstances, the r ₃ role may have permissions to sensitive resources that a ₁ should not have access to for security, privacy, or regulatory reasons. In a provider network 190, these resources may include storage resources, devices such as satellite base stations or microprocessors, or write access to the policies governing access to roles. The access control analysis unit 100 may perform a role reachability analysis 120 based (at least in part) on a role reachability graph 110 .

In some embodiments, the access control analysis unit 100 may include a user interface 130 . The user interface 130 may allow users to request the role reachability analysis 120 to be performed, e.g. B. for a specific role or account or for a set of roles or accounts. User interface 130 may present aspects of analysis 120 to users, such as indications of which roles can assume which other roles, and/or other results of the analysis. In some embodiments, user interface 130 may be used to generate notifications of analysis 120 results. For example, the analysis unit 100 can send a notification to an administrator or a security team about any security findings discovered using the analysis of the role reachability analysis 120, e.g. B. Unexpected Privilege Escalation Findings. In some embodiments, the access control analysis unit 100 may be implemented as a service and include one or more service interfaces through which the analysis unit communicates with other services, e.g. the services 170 and/or the policy comparison service. In various embodiments, the analysis unit 100 can be implemented within the provider network 190 or outside of the provider network.

The access control analysis unit 100 can perform a role reachability analysis 120 in terms of transitive or “persistent” session tags. Tags can represent key-value attributes provided upon role assumption. Tags may contain alphanumeric descriptors associated with principals. Policies can restrict these tags to perform attribute-based access control combined with delegated role-based management, e.g. B. to apply an authorization strategy that defines permissions based on tag attributes. For example, if an organization uses a SAML-based identity provider, it can configure its assertions to provide session tags to the cloud provider network. When agents connect to the provider network 190, their attributes such as FirstName, LastName, or Email can be associated with an associated principal in the provider network, and policies can grant or deny access based on those attributes. Session tags can be passed during the role assumption steps. Session tags can optionally be made transitive or "persistent" so that they persist during subsequent inheritance steps to propagate restrictions through a role inheritance chain. When a session tag is set to be transitive, it can become a principal tag associated with the session corresponding to the role inherited.

The role reachability analysis 120 may use a role reachability graph 110 whose nodes represent the roles and whose edges represent the role inheritance transitions. Graph 110 may be a directed graph (in which the edges have directions) but need not be a directed acyclic graph. Role inheritance can be made dependent on key-value attributes (tags) for a role session, including transitive tags, that persist during inheritance of another role. Under certain circumstances, a status of the tags can change during the role takeover. For example, assuming a concrete role may result in tags being added for a principal, and thus the particular path taken by a role assumption chain may result in a different tag state than a different path to the same node in graph 110. Role assumption can be made dependent on tags matching placeholder values of key-value attributes. Based (at least in part) on the existence of such placeholders, the set of potential tag values relevant to a role assumption step may be unlimited and/or infinite. In some embodiments, for each node, the analysis unit 100 can determine its possible neighbors by noting that the current state of the transitive tag can only be extended by a set of tags whose keys are either explicitly named and whose associated conditions are therefore known or by under-specified tags whose values are not or only partially restricted. Analysis unit 100 may aggregate one or more constraints (e.g., upper bounds and/or lower bounds) for the one or more tags as specified by access control policies 165 associated with role assumption steps. Based (at least in part) on performing a role reachability analysis 120 using the graph 110, the access control analysis unit 100 may identify a potentially unexpected configuration. The analysis unit 100 can present security results that describe this configuration.

In some embodiments, the access control analysis unit 100 may use a policy comparison service 180 in the provider network 190 to find semantic level differences (if any) between two access control policies. For example, the policy comparison service 180 can determine whether a policy is inferior or equal to another policy. For example, the policy comparison service 180 can be used to determine whether a role takeover step can be performed. The policy comparison service 180 can determine the conditions for performing a role assumption step. The use of the policy comparison service 180 is explained in more detail below.

The access control analysis unit 100 can be implemented with any number and configuration of computing devices, each of which is defined by the in 9 example computing device 900 illustrated may be implemented. The computing devices may be located in any number of data centers or geographic locations. In various embodiments, at least part of the functions of the access control analysis unit 100 can be provided by the same computing device or by different computing devices. If one of the components of the access control analysis unit 100 is implemented using different computing devices, the components and their respective computing devices may be communicatively coupled, e.g. B. over one or more networks. Each of the components of the access control analysis unit 100 can represent any combination of software and hardware that can be used to perform their respective functions, as discussed below. The Access Tax tion analysis unit 100 performed operations can automatically, z. B. without user initiation or user intervention after an initial configuration phase, and programmatically, e.g. B. by executing program instructions on at least one computing device. It is contemplated that the access control analysis unit 100 may include additional components not shown, fewer components than shown, or other combinations, configurations, or amounts of the components shown.

Various components such as the access control analysis unit 100, the policy manager 160, the services and resources 170 and/or the policy comparison service 180 can be implemented in a service-oriented system in which multiple services work together to perform complex tasks according to a service-oriented architecture. A service (such as one of services 170) may be implemented using a variety of different entities distributed across one or more networks, and each entity may provide different clients with access to the functionality of the corresponding service. In such an environment, the access control analysis unit 100 can offer its functions as a service to multiple clients. It is contemplated that any suitable number and configuration of clients may interact with access control analysis unit 100 . In order for clients to invoke their functions, the access control analysis unit 100 may provide any suitable interface(s), such as one or more APIs or other programmatic interfaces, command-line interfaces (CLIs), and/or graphical user interfaces (GUIs). ), e.g. B. the user interface 130. In one embodiment, the functions of the access control analysis unit 100 can be offered to the clients for a fee.

In the 1 The components shown can transmit network-based service requests and other data to one another via one or more networks. In various embodiments, the network(s) may include any suitable combination of network hardware and protocols necessary to establish network-based communication, e.g. B. between components in the provider network 190 and the access control analysis unit 100. Thus, the network or networks in general can include the various telecommunications networks and service providers that together realize the Internet. The network(s) may also include private networks such as local area networks (LANs) or wide area networks (WANs) and public or private wireless networks. In some embodiments, any of the 1 components shown are provided in companies with their own internal networks. In such an embodiment, the network(s) may include the hardware (e.g., modems, routers, switches, load balancers, proxy servers, etc.) and software (e.g., protocol stack, accounting software, firewall/security software, etc.). , which are required to establish a network connection between one component and the Internet and between the Internet and another component. It is noted that in some embodiments, the components can communicate over a private network and not over the public internet.

In one embodiment, the services and resources 170 may be implemented using provider network 190 resources. In some embodiments, aspects of access control analysis unit 100, policy manager 160, and/or policy comparison service 180 may also be implemented using provider network 190 resources. Provider network 190 may represent a network established by an entity, such as a business entity or public organization, to deliver one or more services (such as various types of network-accessible computing or storage) delivered over the Internet and/or other networks accessible to a distributed set of clients. Provider network 190 may include numerous data centers that house various pools of resources, such as collections of physical and/or virtualized computer servers, storage devices, network equipment, and the like, used to implement and distribute the infrastructure and services offered by the provider. In some embodiments, the computing resources may be offered to the clients in units referred to as "instances," such as virtual or physical compute instances. A virtual computing instance can be, for example, one or more servers with a specified computing capacity (which can be specified by specifying the type and number of CPUs, the size of the main memory, etc.) and a specified software stack (e.g. a specific version of an operating system , which in turn can run on a hypervisor). Various types of computing devices may be used individually or in combination to implement the provider network resources in various embodiments, including computer servers, storage devices, network devices, and the like. Since the resources of Provider network 190 can be controlled by multiple clients (or tenants) simultaneously or sequentially, the provider network may be referred to as multi-tenant and is also referred to as a multi-tenant provider network. Provider network 190 may be "in the cloud" and may be referred to as a cloud provider network or cloud-based provider network.

In some embodiments, a provider network 190 operator may implement a flexible set of resource reservation, control, and access interfaces for its clients. For example, a resource manager can implement a programmatic resource reservation interface (e.g., via a website or set of websites) that allows clients (possibly including other components within the provider network 190) to learn about the compute instances offered by the provider network 190 to select, acquire access to, and/or reserve them. Such an interface may include capabilities to browse a resource catalog and provide details and specifications about the different types or sizes of resources supported, the different reservation types or modes supported, pricing models, etc.

2 12 illustrates an example of an authorization scheme usable for role reachability analysis with transitive tags, according to some embodiments. A principal 150 may have a set of effective permissions 220, which may be an aggregation of the permissions granted by one or more policies associated with that principal's access to resources. The set of effective permissions 220 may specify a variety of permissions detailing which resources the principal 150 is allowed to access, which resources the principal 150 is not allowed to access, and under what conditions access to those resources is permitted (or granted) or denied can be. A set of effective permissions 220 may include, for example, one or more permissions associated with the principal 150 and one or more permissions originating from another source, such as a group policy, a delegation policy, roles inherited by the principal, organizational policies, or default policies. In relation to a policy, the effective permissions of the policy can be the permissions that the policy explicitly or implicitly defines. For example, a policy may explicitly grant a principal a set of permissions to perform a set of actions on a resource. As another example, a policy may implicitly grant permissions to principals by granting permissions to a group (of which principals are members). A policy's effective permissions may change over time. For example, a policy can be a role policy, and the principals who can assume that role can change over time, although the policy remains static. As a result, the effective permissions may change as the principals authorized to assume the role change. In other words, an effective authorization is a principal's access right to perform an action on a resource. A policy may specify effective permissions explicitly (e.g., by specifying the principal, action, and resource) and/or implicitly (e.g., by specifying the permissions in a way that one or more of the principal, action, or the resource does not specify) grant.

In one embodiment, the permissions can specify which resources are allowed when a default policy denies access to resources. In one embodiment, if the default policy allows access to resources, the permissions may specify access to the resources that are not explicitly denied. In an embodiment with a different default policy, the permissions may specify a combination of allowed and denied resource access. In some embodiments, effective permissions set 220 may be an aggregation of permissions for a particular resource and/or class of resources. In some embodiments, the set of effective permissions 220 may be an aggregation of permissions for multiple resources (e.g., an aggregation of permissions associated with all resources managed by a service for the user, an aggregation of permissions associated with a user account , or some other aggregation of permissions).

The set of effective permissions 220 may specify a combination or aggregation of permissions based on aspects of the principal. For example, if the principal 150 is a user, the set of effective permissions 220 can specify one or more user policy permissions 214 . User policy permissions 214 may include permissions related to the nature of the principal 150 (ie, a "user,""group," or "organization") and may also include permissions associated with a specific set of credentials associated with the principal's 150 identity.

In addition to the permissions related to the class and/or identity of the principal 150, the set of effective permissions 220 may specify one or more delegation policy permissions 212 as a result of the principal 150 assuming 204 one or more roles 206 within an organization. As an example, a principal 150 may be a software developer and assume the role of software developer 204 in its day-to-day activities and become an authorized delegate for the set of permissions associated with assuming the software developer role. A software developer role may specify a set of delegation policy permissions 212 that are included in the set of effective permissions 220 associated with the client 150 . There may be an overlap between user policy permissions 214 and delegation policy permissions 212 (e.g., "Permission B"). There may also be conflicts between user policy permissions 214 and delegation policy permissions 212 . For example, "Permission A" in delegation policy 212 can grant access to a resource at any time, while "Permission C" in user policy permissions 214 can deny that access. For such conflicts, a default policy and/or a default policy for resolving conflicts (i.e., preferring to deny or preferring to grant) may prevail.

Likewise, the set of effective permissions 220 may specify one or more group policy permissions 218 resulting from a principal 150 being a member of 208 one or more groups 210 (e.g., a production group). The set of effective permissions 220 may also specify one or more other policy permissions 216, such as those associated with standard policies, organizational policies, policies associated with particular applications, policies associated with heightened security conditions, temporary policies, or other such policies.

A client 150 can also assume multiple roles and thus multiple sets of role policy permissions. For example, a principal 150 who assumes the role of a software developer in his day-to-day activities may, at some point in his working day, require more privileges, such as those associated with the role of system administrator. In such an example, the principal may temporarily assume a system administrator role, perform one or more privileged operations granted by that role, and then relinquish that role, thereby reverting its policy to the less privileged set of privileges. As can be appreciated, the role types and associated privileges described in connection with these roles are illustrative examples, and other role types and associated positions may be considered within the scope of the present disclosure.

Permissions associated with set of effective permissions 220 may be granted to principal 150 by adding and/or removing permissions (e.g., as a result of API calls to a policy management service 160) from delegation policy permissions 212, user policy permissions 214, from the group policy permissions 218, from the other policy permissions 216, or from other such groups of permissions. For example, removing "Permission E" from the set of effective permissions 220 can be accomplished by removing that permission from group policy permissions 218 . Such removal may also result in deprivation of permission for other principals who are members of that group, which may be a desired or undesired effect. Redundant permissions can be removed from a policy. For example, users with User Policy Permissions 214 and with Delegation Policy Permissions 212 will have "Permission B" granted by both policies, and as such, "Permission B" can be removed from either Delegation Policy Permissions 212 or User Policy Permissions 214 without affecting the permissions in the Set of effective permissions 220 to change. In both of these examples, the same result can also be achieved by other policy modification measures (e.g., by changing group membership and/or role assignments as described herein).

For example, principal 150 can be removed from the group (instead of changing the group's permissions), and since in the in 2 illustrated example “Permission A” and "Permission D" granted by other policy permissions, the result would be to remove "Permission E" from the principal without changing the permissions of other principals. Likewise, the permissions for a principal 150 can be changed by adding the principal to a new group with different permissions (ie a newly created and/or previously specified group), by inheriting roles from the principal and/or releasing them by changing roles , by dividing groups based on principals and/or desired permissions, or other such actions. For example, a group can have ten members and grant five permissions. Five of the group members may qualify for the first four permissions and five of the group members may qualify for the last three permissions. By splitting this group into two groups, each having the appropriate permissions, and then making the appropriate principals members of the appropriate groups, the permissions for each of the members can be more optimal.

In one embodiment, a permission may specify a principal 150, a resource, an action, a condition, and/or an effect. In some embodiments, a permission may specify a variety of one or more of these items, such as a set or class of users, a collection of resources, multiple different actions, and/or multiple conditions. Principal 150 may represent a user, group, organization, role, or collection and/or combination of these or other such entities. A principal 150 may be any entity capable of making API calls that cause an action associated with a resource to be performed and/or any entity that has permissions associated with a resource , can be granted. For example, a particular credential may indicate that principal 150 is a user named "USER1." The permission may indicate an action that can be performed on the resource and may be identified, for example, by an API call, library call, program, process, series of steps, workflow, or other such action. For example, an action can be a set of operations that can be performed as part of an API call, for example to an Internet-facing service. The actions performed may be a subset of those actions and/or a single operation. The operations can also be performed in a defined order, repeated, or spread across multiple API calls. For example, the action can be an API call to write data to the resource. A permission may further specify a memory resource, a data write API call for the action, a time condition, and an allowed effect. Such an example authorization could be: "USER1 MAY WRITE to 12345 between 9:00 AM and 9:30 AM".

3 12 illustrates an example of a role reachability graph usable for analyzing role reachability with transitive tags, according to some embodiments. As discussed above, a role reachability graph 110 may include nodes representing roles and edges representing potential role-taking steps. the inside 3 The example graph 300A shown may include nodes representing roles, such as role 310, role 320, role 330, role 340, role 350, role 360, role 370, role 380, role 390, etc. Graph 300A may be a directed graph , in which the edges have directions such that a directed edge between two nodes indicates that a role can potentially assume another role pointed to by the edge. For example, the edge between role 310 and role 320 may indicate that role 310 can potentially assume role 320 . The graph 300A does not necessarily have to be a directed acyclic graph. For example, a set of role-taking steps may allow a role represented by role 340 to take on a role represented by role 370, role 370 to take on role 380, and role 380 to take on role 340. In some embodiments, the set of potential paths may be unbounded, at least in part due to the potentially cyclic nature of graph 300A and also due to the use of string-based tags. Some nodes may be unreachable from other nodes. For example, reel 390 may not be reachable from reels 310-380. In some embodiments, any two roles may belong to different accounts or to the same provider network 190 account. For example, role 310 may belong to a first account, role 370 to a second account, and role 330 to a third account.

4 Figure 12 illustrates an example of role-taking steps with transitive tags, according to some embodiments. the inside 4 Graph 300B shown may represent a portion of example graph 300A discussed above. Role inheritance can be made dependent on key-value attributes (tags) for a role session, including transitive tags, that persist during inheritance of another role. Under certain circumstances, the status of the tags can change during the role takeover change. Assumption of a concrete role can result in one or more tags being added, and thus the concrete path taken by a role assumption chain can lead to a different tag state than a different path to the same node in the graph. For example, subgraph 300A shows two paths to reach reel 350 from reel 310, e.g. e.g., through intermediate role 320 or intermediate role 360. During role inheritance, if role 360 adds a transitive tag to the session and role 320 does not, the tag state at role 350 may vary depending on the path taken.

The state of a tag for a session may represent a context of authority, and assuming a role may depend on that context. In example graph 300B of FIG 4 After assuming the role 310, the state of the session tag may include a key-value tag {k ₁ :v ₁ }. When role 310 assumes role 360, another key-value tag may be added such that the state of the session tag includes {k ₁ :v ₁ ,k ₂ :v ₂ }. However, if role 310 takes over role 320 instead, the tag state can remain the same. When role 350 is role-taken, the state of the session tags may be based (at least in part) on the path taken. Assuming role 350 may also add another key-value tag. For example, inheriting role 350 from role 320 may result in a session tag state that includes {k ₁ :v ₁ ,k ₃ :v ₃ }, while inheriting role 350 from role 360 may result in a state of the session tag which includes {k ₁ : v ₁ , k ₂ : v ₃ , k ₂ : v ₃ }. The ability of role 350 to assume additional roles may then be based (at least in part) on these different tag states.

The role reachability analysis 110 may begin traversing the graph at one or more possible entry points, such as at nodes that do not have the state of the transitive tag. Role assumption can be made dependent on tags matching placeholder values of key-value attributes. Based (at least in part) on the existence of such placeholders, the set of potential tag values relevant to a role assumption step may be unlimited and/or infinite. In some embodiments, for each node, the analysis unit 100 can determine its possible neighbors by noting that the current state of the transitive tag can only be extended by a set of tags whose keys are either explicitly named and whose associated conditions are therefore known or by under-specified tags whose values are not or only partially restricted. Analysis unit 100 may aggregate one or more constraints (e.g., upper bounds and/or lower bounds) for the one or more tags as specified by access control policies 165 associated with role assumption steps.

   {
      "Effect": "Deny",
      "Action": "AssumeRole",
   }"Resource": "123:role/Write*"

As the following example shows, when there is subtle behavior of a transitive tag with potentially overlapping string constraints, role assumption can result in an unexpected privilege escalation. In a provider network 190, a principal p can assume a role r if role r's trust policy trusts principal p and p's identity policy grants access to an AssumeRole action for resource r. If p and r belong to different accounts, p can be given access to the AssumeRole action if its identity policy specifically allows it. If p and r belong to the same account, p can access the AssumeRole action unless its identity policy specifically denies it. In this example, the identity policy for a specific user Jane in account 123 might include:

 {
      "Effect": "Deny",
      "Action": "AssumeRole",
   }"Resource": "123:role/Write*"

{
      "Effect": "Allow",
      "Principal": {"ProviderNetwork": "123:user/Jane"},
      "Action": ["AssumeRole", "TagSession"],
      "Condition": {
          "StringLike": {"RequestTag/FirstName": "J*"},
          "ForAllValues:StringEquals": {"TransitiveTagKeys": ["FirstName",
              "Email"] },
          "ForAnyValue: StringEquals" : {"TransitiveTagKeys": "FirstName"}
   }}

In this example, the trust policy for an Audit role in account 123 might include:

 {
      "Effect": "Allow",
      "Principal": {"ProviderNetwork": "123:user/Jane"},
      "Action": ["AssumeRole", "TagSession"],
      "Conditions": {
          "StringLike": {"RequestTag/FirstName": "J*"},
          "ForAllValues:StringEquals": {"TransitiveTagKeys": ["FirstName",
              "email"] },
"ForAnyValue: StringEquals" : {"TransitiveTagKeys": "FirstName"}
   }}

   {
      "Effect": "Allow",
      "Action": "AssumeRole",
   }"Resource": "321:role/ReadOnly"

In this example, the identity policy for the Audit role can include:

 {
      "Effect": "Allow",
      "Action": "AssumeRole",
   }"Resource": "321:role/ReadOnly"

A condition involving ForAllValues can check whether the value of each member of the query set is a subset of the condition key set. The condition can return true if every key value in the request matches at least one value in the policy. The condition can also return true if there are no keys in the request or if the key values result in a null record, such as an empty string. A condition involving ForAnyValue can check whether at least one member of the set of query values matches at least one member of the set of condition key values. The condition can return true if any of the key values in the request match any of the condition values in the policy. If there is no matching key or a null record, the condition can return false.

According to the sample policy fragments shown above, Audit trusts Jane based on its trust policy, and Jane is not explicitly denied access to the Audit role because Audit does not match the string pattern Write* as denied by Jane's identity policy. Because Jane's policy does not deny the AssumeRole action, and the role's trust policy explicitly allows her access, the AssumeRole operation can be allowed.

   {
      "Effect": "Allow",
      "Principal": {"ProviderNetwork": "role/Audit"},
      "Action": ["AssumeRole", "TagSession"],
      "Condition": {
          "StringLike": {
                    "RequestTag/LastName": "D*",
                    "PrincipalTag/FirstName": "*an*"
          },
   } } "ForAllValues:StringEquals": {"TransitiveTagKeys": "LastName"}

In this example, the trust policy for a ReadOnly role in account 321 might include:

 {
      "Effect": "Allow",
      "Principal": {"ProviderNetwork": "role/Audit"},
      "Action": ["AssumeRole", "TagSession"],
      "Conditions": {
          "StringLike": {
                    "RequestTag/LastName": "D*",
                    "PrincipalTag/FirstName": "*an*"
          },
   } } "ForAllValues:StringEquals": {"TransitiveTagKeys": "LastName"}

   {
      "Effect": "Allow",
      "Action": "GetObject",
   } "Resource": "sensitive-resource/*"

In this example, the identity policy for a StorageAccess role in account 321 might include:

 {
      "Effect": "Allow",
      "Action": "GetObject",
   } "Resource": "sensitive-resource/*"

   {
      "Effect": "Allow",
      "Principal": {"ProviderNetwork": "role/ReadOnly"},
      "Action": ["AssumeRole", "TagSession"],
      "Condition": {
          "StringEquals": {"RequestTag/Email": "jane@doe.com"},
          "StringLike": {
                    "PrincipalTag/LastName": "*oe",
                    "PrincipalTag/FirstName": "*e"
          },
          "ForAllValues:StringEquals": {"TransitiveTagKeys": "Email"},
   } } "ForAnyValues:StringEquals": {"TransitiveTagKeys": "Email"}

In this example, the trust policy for the StorageAccess role can include:

 {
      "Effect": "Allow",
      "Principal": {"ProviderNetwork": "role/ReadOnly"},
      "Action": ["AssumeRole", "TagSession"],
      "Conditions": {
          "StringEquals": {"RequestTag/Email": "jane@doe.com"},
          "StringLike": {
                    "PrincipalTag/LastName": "*oe",
                    "PrincipalTag/FirstName": "*e"
},
          "ForAllValues:StringEquals": {"TransitiveTagKeys": "Email"},
   } } "ForAnyValues:StringEquals": {"TransitiveTagKeys": "Email"}

According to the sample policy fragments shown above, since Audit's identity policy explicitly grants access to the AssumeRole API on ReadOnly due to the Audit role's identity policy, and since ReadOnly trusts Audit due to the ReadOnly role's trust policy, the Audit role is in account 123 allowed to assume the ReadOnly role in account 321. In the meantime, due to the StorageAccess role trust policy, StorageAccess trusts ReadOnly in its own account and therefore ReadOnly can assume the StorageAccess role. However, in some embodiments, there are conditions for these role-taking steps, which are expressed as constraints on tags that should have specific values or match the specified criteria. A cloud provider network 190 may provide tags with condition keys prefixed with RequestTag so that when authorizing an AssumeRole call, a user can refer to the value of the Name tag by referencing RequestTag/Name. The same tag can be attached to the resulting session as PrincipalTag/Name after a successful call.

In the example, to inherit the Audit role, the user Jane must provide a session tag whose key is FirstName and whose value is J* (according to the trust policy for the Audit role). At the same time, the trust policy restricts the session tags that can be specified as transitive to those with the key FirstName or Email, but requires that there be at least one transitive tag whose key is FirstName. If the user Jane chooses a value for FirstName that does not match *an*, any attempt to inherit the ReadOnly role can be denied as it would violate the condition of ReadOnly's trust policy.

In the example, to inherit the ReadOnly role, the Audit role must provide a session tag whose key is LastName and whose value is D*. Although the policy limits transitive tags to those with the LastName key, it does not require that it be made transitive. If the value chosen for LastName does not match *oe and it is set to transitive, any attempt to assume the StorageAccess role may be denied as it would violate the StorageAccess trust policy condition. Conversely, if LastName is not set to be transitive, the session associated with the ReadOnly role does not have the LastName principal tag required to assume the StorageAccess role.

In the example, to inherit the StorageAccess role, the ReadOnly role must provide a session tag whose key is Email and whose value is jane@doe.com. In some embodiments, it would not be possible to pass the Email session tag when inheriting StorageAccess if Jane is passing the Email transitive tag when she inherits Audit because transitive tags cannot be overridden and the request would therefore be rejected. In some embodiments, the request is authorized only if the values chosen for FirstName and LastName in the previous role-taking steps match *e and *oe, respectively.

In some embodiments, provision of session tags during an assume role step may require permission to perform the TagSession action in addition to the action conforming to the AssumeRole API operation. So the trust policy for the Audit role, the trust policy for the ReadOnly role, the trust policy for the StorageAccess role can grant such access. If user Jane assumes the Audit role, which provides a transitive tag with key FirstName and value Jane, then assumes the ReadOnly role, which provides a transitive tag with key LastName and value Doe, and then assumes the StorageAccess role, which provides a transitive tag with key Email and value jane@doe.com, then all role assumption steps can be authorized. Using the temporary credentials associated with the StorageAccess role, user Jane can gain access to the sensitive-resource/* resource. Depending on the circumstances, this behavior may be desirable or undesirable. The access control analysis unit 100 can perform a role reachability analysis in terms of transitive or "persistent" session tags to find such chains of role assumption steps in a large set of policies and their complex interactions in a provider network 190 .

In the provider network 190, a resource can represent the domain of items that can be created, read, updated, or deleted by users. Resources 170 can include, for example, users, roles, policies, queues, databases, virtual machines, and so on. In provider network 190, an action may represent a constant (such as AssumeRole or DeleteObject) that represents an operation that can be performed on a resource. In the provider network 190, a principal can represent an entity that can request an action for a resource. Examples of principals can include accounts, users, roles, services, and so on. A request can be represented by a quadruple (p, a, r, c) such that p is a client, a is an action, r is a resource, and c is a map with additional information. The additional information may be related to the request, principal, and/or resource, such as service-specific information and tags. The term AUTH can represent a predicate governing whether a principal p is authorized to perform an action a on a resource r under a request context c such that the request (p, a, r, c) is authorized if and only if AUTH(p, a, r, c) holds. The underlying complexity of authorization in provider network 190 can be captured with the abstract predicate AUTH.

A role-inheritance (or inheritance-role) transition relationship ⇝ can be defined as follows. A principal p can only be authorized to assume role r if AUTH(p, AssumeRole, r, c) holds for a request context c. However, the condition block of the Audit role trust policy may require the user to pass the FirstName session tag to Jane, otherwise the operation will fail. Tagging a session may require permission to perform the TagSession action in addition to the action that matches the AssumeRole API operation. In some embodiments, AUTH(p, TagSession, r, c) must also apply. In some embodiments, both requests need to be authorized at the same time and in the same request context. In order to determine when it is necessary to provide session tags, the predicate ST can be defined such that ST(p, r) holds if and only if each request context c satisfying AUTH(p, AssumeRole, r, c) met, contains session tags.

In some embodiments, since the policy language may allow lower bounds to be specified for a set of transitive session tags, roles may only be reachable under a certain state of transitive session tags, affecting the authorization outcome. In some embodiments, if the provider network 190 is in state σ (the current state of its users, roles, policies, etc.) and the state of the session transitive tag is t, a principal p may assume role r when the new set transitive session tag t' \ t is introduced when the following role reachability relation holds: $$\begin{array}{l}\left(p,t,\sigma \right)\to E\left(\mathrm{right},t\text{'},\sigma \text{'}\right)\stackrel{\text{def}}{=}\exists c.{\text{AUTH}}_{\sigma }\left(p,Ass\mathrm{and}meROle,\mathrm{right},c\cup t\cup t\text{'}\right)\\ \wedge \left((t\text{'}\ne t\vee \text{ST}\left(p,\mathrm{right}\right)\right)\Rightarrow {\text{AUTH}}_{\sigma }\left(p,TaGSessiOn,c\cup t\cup t\text{'}\right))\\ \wedge t\subseteq t\text{'}\wedge \left(\sigma ,\sigma \text{'}\right)\in E\end{array}$$

The term E can characterize the impact of the environment on the states of the provider network during execution. For example, while pr takes over, the environment might add, update, or delete roles, policies, or resources. In some embodiments, the choice of E may be critical when considering reachability. In some cases, r may be unreachable from p when the provider network state does not change (e.g., E = {(s, s') | s = s'}), but reachable when the environment is unconstrained (e.g. E = {(s, s') | true}). Since t ⊆ t' if t' ≠ t then t' \ t ≠ ∅„ and hence transitive tags can be provided during the transition. In some embodiments, p must be authorized to mark the session. If t' \ t = ∅ and ¬ST(p, r), then it may not be necessary to check if p is authorized to mark the session. On the other hand, c ∪ t ∪ t' can represent the fact that the request context c is extended by the tags in the current state of the transitive tag, which are added as principal tags (i.e. transitive tags become principal tags associated with the inherited role instance are), while the tags in t' \ t can be added as request tags. For example, if t = {FirstName: Jane} and t' = {FirstName: Jane, LastName: Doe}, then c ∪ t ∪ t' c ∪ {PrincipalTag/FirstName: Jane, RequestTag/LastName: Doe}. In some embodiments, the AUTH predicate is responsible for checking that no request tag matches a transitive tag, since transitive tags cannot be overridden. In some embodiments, a role r may be considered reachable from a principal p if and only if there are t,t',σ,σ' such that (p,t,σ)⇝*(r,t',σ ').

In some embodiments, the access control analysis unit 100 may use a policy comparison service 180 in the provider network 190 to find semantic level differences between two access control policies. For example, the policy comparison service 180 can determine whether a policy is inferior or equal to another policy. In this context, the policies may be interpreted as the set of requests they authorize, and the result of the policy comparison service 180 may relate to the inclusion of the set. For example, a first policy may allow user u to assume a role r regardless of context, and a second policy may allow user u to assume not only role r, but also any role that matches the wildcard term r*. The policy comparison service 180 can determine that the second policy is more acceptable than the first policy. In some embodiments, the policy comparison service 180 can determine whether a policy is equal, smaller, larger, or incomparable to a second policy.

   {
      "Version": [date],
      "Statement": [{
          "Effect": "Deny"
          "Principal": {"ProviderNetwork": "Principalldentifier"},
          "Action": "AssumeRole",
          "Resource": "ResourceIdentifier",
          "Null": {"TagKeys": "true"},
      }, {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "*",
   } }] "Resource": "*" 

In some embodiments, the policy comparison service 180 can be used to determine ST(p, r). For a principal p and a role r, let π ₀ be the trust policy of r. The negated policy π ₁ is intended to authorize a complement or negation of the trust policy π ₀ e.g. B. by authorizing all requests except those where p performs the AssumeRole action on r and the request context does not contain session tags. In this example, the negated policy π ₁ can include:

 {
      "version": [date],
      "statement": [{
          "Effect": "Deny""Principal":{"ProviderNetwork":"Principaldentifier"},"Action":"AssumeRole","Resource":"ResourceIdentifier","Null":{"TagKeys":"true"},
      }, {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "*",
   } }] "Resource": "*" 

The policy comparison service 180 may determine that (π ₁ , π ₀ ) ≠ ≥ if and only if there is a request context c such that AUTH(p, AssumeRole, r, c) holds in π ₀ and c has no session tags contains. The policy comparison service 180 may determine that (π ₁ ,π ₀ ) ≠ ≥ if and only if there is a request that is not authorized by π ₁ and that is authorized by π ₀ . Since the only requests not authorized by π ₁ are those that allow p to assume role r when the request context does not contain session tags, as dictated by the TagKeys key constraint, there is one Request authorized by π ₀ .

   {
      "Version": [date],
      "Statement": [{
          "Effect": "Deny"
          "Principal": {"ProviderNetwork": "PrincipalIdentifier"}
          "Action": "AssumeRole",
          "Resource": "ResourceIdentifier"
      }, {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "*",
   } }] "Resource": "*"

In some embodiments, the policy comparison service 180 can be used to determine AUTH. Let p be a principal and r a role, and assume that the analysis unit 100 is trying to determine whether AUTH(p, AssumeRole, r, c ∪ t ∪ t') holds for a query context c, where t = {FirstName: Jane} and t' = {FirstName: Jane, LastName: Doe}. Let π ₀ be a policy that allows any request other than the one allowing p to take the role r, regardless of context. In this example, the guideline π ₀ can include:

 {
      "version": [date],
      "statement": [{
          "Effect": "Deny""Principal":{"ProviderNetwork":"PrincipalIdentifier"}"Action":"AssumeRole","Resource":"ResourceIdentifier"
}, {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "*",
   } }] "Resource": "*"

   {
      "Version": [date], 

      "Statement": [
          "_Role Assumption Policy Statements_"
          {
          "Effect": "Deny"
          "Principal": "*",
          "Action": "*",
          "Resource":"*",
          "Condition": {
             "StringNotEquals": {
                    "PrincipalTag/FirstName": "Jane"
      }, { }}
          "Effect": "Deny"
          "Principal": "*",
          "Action": "*",
          "Resource":"*",
          "Condition": {
             "StringNotEquals": {
   } }] } } "PrincipalTag/LastName": "Doe"

On the other hand, let π ₁ be r's role inheritance policy augmented with statements that reject all requests that do not meet the conditions of the above tags. In this example, policy π ₁ may include:

 {
      "version": [date], 

      "statement": [
          "_Role Assumption Policy Statements_"
          {
          "Effect": "Deny""Principal":"*","Action":"*","Resource":"*","Conditions": {
             "StringNotEquals": {
                    "PrincipalTag/FirstName": "Jane"
      }, { }}
          "Effect": "Deny""Principal":"*","Action":"*","Resource":"*","Conditions": {
             "StringNotEquals": {
   } }] } } "PrincipalTag/LastName": "Doe"

 {
      "Effect": "Deny"
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
             "ForAnyValue:StringNotEquals": { 



             } } } "TransitiveTagKeys": ["LastName"]

Additionally, π ₁ can be extended with a directive that rejects all requests where the set of transitive tag keys is not exactly LastName, as shown below:

 {
      "Effect": "Deny""Principal":"*","Action":"*","resources":"*","Conditions": {
             "ForAnyValue:StringNotEquals": { 



             } } } "TransitiveTagKeys": ["LastName"]

 {
   "Effect": "Deny"
   "Principal": "*",
   "Action": "*",
   "Resource": "*",
   "Condition": {
      "StringLike": {
      } } } "PrincipalTag/_key_": ["*"]

In some embodiments, since the policy comparison service 180 may check for the presence of principal tags that meet the policy conditions, there may be no principal tags other than those that are in the transitive tag state, such as anyone, as will be shown below Principal tag key explicitly mentioned in r's role assumption policy and not FirstName:

 {
   "Effect": "Deny""Principal":"*","Action":"*","resources":"*",
"Conditions": {
      "StringLike": {
      } } } "PrincipalTag/_key_": ["*"]

The policy comparison service 180 may determine that (π ₀ ,π ₁ ) ≠ ≥ if and only if there is a request context c such that AUTH(p, AssumeRole, r, c U t U t) holds, where t = { FirstName: Jane} and t' = {FirstName: Jane, LastName: Doe}. The policy comparison service 180 may determine that (π ₀ ,π ₁ ) ≠ ≥ if and only if there is a request that is not authorized by π ₀ and that is authorized by π ₁ . Since the only requests not authorized by π ₀ are those that allow p to assume role r, there is one such request authorized by π ₁ . In some embodiments, a request authorized by π ₁ cannot satisfy that PrincipalTag/FirstName is not equal to Jane, nor can it satisfy that RequestTag/LastName is not equal to Doe, otherwise it would have been denied. Likewise, in some embodiments, each request authorized by π ₁ may contain only a single transitive session tag with key LastName and no principal tag key other than FirstName, otherwise it would have been denied. Therefore, there is such a request context c that AUTH(p, AssumeRole, r, c U t U t) holds with respect to r's trust policy.

In some embodiments, the analyzer 100 may also check whether p's identity policy allows access to the AssumeRole API operation for the role r, provided that p and r belong to the same account. A similar procedure can be performed when p and r are from different accounts. In some embodiments, it may be sufficient to check that p's identity policy does not explicitly deny access to the AssumeRole operation. Let π ₀ be p's identity policy and π ₁ be p's identity policy, extended by a statement that explicitly denies p to take the role of r. The policy comparison service 180 may determine that (π ₀ ,π ₁ ) ≠ ≥ if and only if p's identity policy does not explicitly deny p es p from assuming the role r. In some embodiments, parsing unit 100 may determine AUTH(p, TagSession, r, c U t U t') in the same manner that AUTH(p, AssumeRole, r, c U t U t') was determined.

In some embodiments, the policy comparison service 180 can be used to determine whether multiple conditions apply simultaneously in a transitive tag value, where the conditions are expressed in the same language as the provider network policies 165 . To avoid having to translate the policy language into the language of a Satisfiability Modulo Theory (SMT) solver, the policy comparison service 180 can be used to check satisfiability. For example, the policy comparison service 180 can be used to determine whether there is a value for the session tag FirstName that simultaneously satisfies the conditions "StringLike": "Yes*" and "StringLike": "*ne". Let π ₀ be a policy that denies any request, and consider policy π ₁ , which allows any request except those where the value of the request tag FirstName does not match "Yes*" or does not match "*ne “ agrees. The policy comparison service 180 may determine that (π ₀ , π ₁ ) = < if and only if there is a value for the session tag FirstName that simultaneously satisfies the conditions "StringLike": "Yes*" and "StringLike": "*ne" fulfilled. Since π ₀ refuses all requests, π ₀ ≤ π ₁ . Thus π ₀ < π ₁ if and only if π ₁ authorizes at least one request. In some embodiments, a request authorized by π ₁ cannot satisfy that the value of FirstName does not match Yes*. So FirstName matches Yes* and FirstName must match *ne.

 [
   {
      "Effect": "Deny",
      "Action": "*",
      "Principal": "*",
      "Resource": "*",
      "Condition": {" StringNotLike" :
             {"RequestTag/FirstName": "Ja*"}
   }, {
      "Effect": "Deny",
      "Action": "*",
      "Principal": "*",
      "Resource": "*",
      "Condition": {" StringNotLike" :
             {"RequestTag/FirstName": "*ne"}
   }, {
      "Effect": "Allow",
      "Action": "*",
      "Principal": "*",
      ] } "Resource": "*",

In some embodiments, the analysis unit 100 may perform an analysis 120 of a role reachability problem under a concrete state of transitive session tags within a provider network account where the environment does not change (e.g., E = {(s, s') | s = s'}). In some embodiments, the analysis unit 100 can monitor the calls to APIs in the provider network 190 that could change the state of the environment (e.g. for a specific account), and the analysis unit 100 can restart the analysis 120 upon completion if the changed the state of the environment. Given a provider network account with state σ, the analysis unit 100 can determine its role reachability graph 110 whose vertices are the pairs (p, t), where p is a principal and t is a state of a transitive tag, and where an edge of (p, t) to (r, t) exists if and only if (p, t, σ) ⇝ (r, t', σ). The term σ can be constant in the analysis. The guideline π ₁ should include the following:

 [
   {
      "Effect": "Deny",
      "Action": "*",
"Principal": "*",
      "resources": "*",
      "Condition": {"StringNotLike" :
             {"RequestTag/FirstName": "Yes*"}
   }, {
      "Effect": "Deny",
      "Action": "*",
      "Principal": "*",
      "resources": "*",
      "Condition": {"StringNotLike" :
             {"RequestTag/FirstName": "*ne"}
   }, {
      "Effect": "Allow",
      "Action": "*",
      "Principal": "*",
      ] } "Resource": "*",

If there is an edge from (Jane, ∅) to (Audit, {"FirstName": s}) for every string s that matches J*, then the role reachability graph can contain an unlimited number of nodes. However, in order to infer the role availability, the analysis unit 100 does not necessarily have to know the specific value that a tag assumes during a role assumption step. Instead, the analysis unit 100 can determine the properties that characterize the tag, e.g. B. that it matches J*. Such an observation may allow the parsing unit 100 to characterize, for each role-taking step, all possible ways in which the state of the transitive tag may be expanded. By abstracting the tag values, the analysis unit 100 can transform the unbounded role reachability graph into a finite abstraction.

{
   "ForAllValues:StringEquals": {
   }, "TagKeys": ["FirstName", "LastName", "Email"]
   "ForAnyValue:StringEquals": {
   } } "TagKeys": ["Email"]

Let (p, t) and (r, t') be such vertices that (p, t) ⇝ (r, t'). Hence t ⊆ t', and each tag in t' \ t can represent a session tag provided during the role assumption step and set to be transitive or "persistent". Thus, if S is the set of all session tags that can be passed when pr takes over, then t' \ t ⊆ S. In some embodiments, S can be determined by static analysis of the policies. To determine the possible keys of a tag in S, note that the policy language may allow the setting of bounds on the set of keys passed with a request by defining conditions on the TagKeys key. Because a request can contain multiple tag-key-value pairs, TagKeys can be a multi-valued variable and therefore can be constrained by the ForAllValues and ForAnyValue set operators along with any of the available string operators (e.g. StringEquals, StringLike, etc.). . For example, the following policy fragment can ensure that a set of session tags conforms to the bounds as long as its keys K satisfy: {Email} ⊆ K ⊆ {FirstName, LastName,Email}:

 {
   "ForAllValues:StringEquals": {
   }, "TagKeys": ["FirstName", "LastName", "Email"]
   "ForAnyValue:StringEquals": {
   } } "TagKeys": ["Email"]

Since these conditions can be absent or can allow an infinite number of different keys (e.g. when using regular expressions), the analysis unit 100 can determine an upper bound for S. In some embodiments, S can be divided into two sets: (i) those tags whose keys are explicitly mentioned in a policy, and (ii) those tags whose keys are not explicitly mentioned in any policy. In some embodiments, the tag keys in the latter set would never match a principal tag key, nor can they have conflicting terms, otherwise they would be mentioned in the corresponding policy. Therefore, these under-specified tags can be considered irrelevant for the role reachability analysis. In some embodiments, such a tag may only be used to meet the lower bound conditions of a policy that allows the transition. By only considering tags whose keys are explicitly mentioned in a policy, the analysis unit 100 can implement primary aspects of the role reachability problem: identifying session tags that can later serve as principal tags and also inferring about conflict conditions.

 {
   "Condition": {
      "_string_operator_": {
      } } "_tag_key_": "_val_"

In some embodiments, to determine all possible keys in t'\t, the parsing unit 100 may start by considering the set S of all explicitly mentioned tag keys in all role inheritance policies, which can be obtained by parsing all occurrences of the following syntactic pattern, where dem Tag key is preceded by either RequestTag or PrincipalTag:

 {
   "Conditions": {
      "_string_operator_": {
      } } "_tag_key_": "_val_"

 {
   "Condition": {
      "ForAllValues: _string_operator ": {
      "RequestTag": "_val_"
      }
   }
   "Condition": { 



      "ForAnyValues: _string_operator_": {
      } } "RequestTag": "_val_"

In some embodiments, S can be refined by applying the upper bound conditions obtained by scanning the role takeover policy that allows the transition for the following syntactic patterns:

 {
   "Conditions": {
      "ForAllValues: _string_operator ": {
      "RequestTag": "_val_"
      }
   }
   "Conditions": { 



      "ForAnyValues: _string_operator_": {
      } } "RequestTag": "_val_"

In some embodiments, after determining S, any S' ⊆ S can be a valid candidate for the set of transitive session tag keys provided during the current role inheritance step, as long as it satisfies the lower bound conditions established by parsing the above syntactic pattern ForAnyValues were extracted. Once the keys are determined, their values can be characterized. For this purpose, the analysis unit 100 can use the policy language in which the properties are specified: e.g. For example, if a tag key is not mentioned in the policy enabling the current transition, its value is unrestricted or partially restricted (e.g. by the condition StringLike: *), while if a tag key is mentioned, all applicable conditions aggregated and assigned to the tag key.

 {
   "Effect": "Allow",
   "Action": "AssumeRole",
   "Principal": {"ProviderNetwork": "role/p"},
   "Condition": {
      "StringLike": {
             "RequestTag/FirstName": "J*",
      }, "RequestTag/LastName": "D*",
      "ForAllValues:StringEquals": {"aws:TagKeys": ["FirstName", "LastName",
             "Email"]},
   } "ForAnyValue:StringEquals": {"aws:TagKeys": ["FirstName", "LastName"]} 



   }

For example, the following policy fragment might contain the sets of session tags {"FirstName": {"StringLike": "J*"}, "LastName": {"StringLike": "D*"}}, and {"FirstName": {"StringLike":"J*"},"LastName":{"StringLike":"D*"},"Email":{"StringLike":"*"}} because FirstName and LastName must be present in order to use the comply with relevant conditions, while email may be optional and unrestricted:

 {
   "Effect": "Allow",
   "Action": "AssumeRole",
   "Principal": {"ProviderNetwork": "role/p"},
   "Conditions": {
      "StringLike": {
             "RequestTag/FirstName": "J*",
      }, "RequestTag/LastName": "D*",
      "ForAllValues:StringEquals": {"aws:TagKeys": ["FirstName", "LastName",
             "E-mail"]},
   } "ForAnyValue:StringEquals": {"aws:TagKeys": ["FirstName", "LastName"]} 



   }

In some embodiments, each candidate set of session tags may contain finitely many keys with finitely many associated conditions, since finitely many tags can be named. While the analysis unit 100 checks that the proposed set of session tags meets all the conditions of the transition-enabling policy, it can also check if it can be extended by a set of under-specified tags to meet the lower-bound conditions. In this way, the analysis unit 100 can carry out an over-approximation in contrast to an exact reachability analysis.

5 12 is a flow chart illustrating a method for analyzing role reachability with transitive tags, according to some embodiments. As shown in 500, the access control analysis unit 100 can determine a graph comprising a plurality of nodes and one or more directed edges. The nodes can represent a variety of roles in a provider network hosting a variety of services and/or resources. The nodes may include a first node representing a first role and a second node representing a second role. The roles may be associated with a variety of access control policies that grant or deny access to any of a variety of services and resources. One or more of the access control policies may grant or deny access based at least in part on one or more key-value tags, e.g. for example, when tags for a session match one or more role assumption conditions. Some role assumption steps can be made dependent on tags matching placeholder values of key-value attributes. Due (at least in part) to the existence of such placeholders and the unlimited length of strings, the set of potential tag values relevant to a role assumption step can be unlimited and/or infinite in size.

In order to perform a role reachability analysis, the analysis unit 100 may restrict the set of keys that need to be considered in determining whether a role assumption step can be performed. In some embodiments, for each node, the analysis unit 100 can determine its possible neighbors by noting that the current state of the transitive tag can only be extended by a set of tags whose keys are either explicitly named and whose associated conditions are therefore known or by under-specified tags whose values are not or only partially restricted (e.g. with placeholders). Analysis unit 100 may aggregate one or more constraints (e.g., upper bounds and/or lower bounds) for the one or more tags as specified by access control policies 165 associated with role assumption steps. In order to infer the role availability, the analysis unit 100 does not necessarily have to know the specific value that a tag assumes during a role assumption step. Instead, the analysis unit 100 can determine the properties that characterize the tag, e.g. B. that it matches J*. Such an observation may allow the parsing unit 100 to characterize, for each role-taking step, all possible ways in which the state of the transitive tag may be expanded. By abstracting the tag values, the parsing unit 100 can transform the unbounded role reachability graph into a finite abstraction that eliminates the potentially unbounded nature of the paths and/or tag states.

As shown in 510, the analysis unit 100 may determine (at least in part) based on a role reachability analysis of the graph whether the first role can assume the second role using one or more role inheritance steps for a particular state of the one or more key-value tags. When performing the role reachability analysis, the analysis unit 100 can consider nodes in which the state of the transitive tag is empty as entry points to a role assumption chain. A single one of the role assumption steps can grant temporary access during a role session. The one or more key-value tags may include one or more transitive tags that persist during the one or more role assumption steps. The set of all session tags that can be passed when a principal assumes a role can be determined by static analysis of the policies. In order to determine a tag's possible keys in the set, note that the policy language may allow the specification of bounds on the set of keys passed with a request by defining conditions on the TagKeys key. Because a request can contain multiple tag-key-value pairs, TagKeys can be a multi-valued variable and therefore can be constrained by the ForAllValues and ForAnyValue set operators along with any of the available string operators (e.g. StringEquals, StringLike, etc.). .

Since these conditions may be absent or may allow an infinite number of different keys (e.g. when using regular expressions), the parsing unit 100 may set an upper bound on the set of all session tags. In some embodiments, the set of all session tags can be divided into two sets: (i) those tags whose keys are explicitly mentioned in a policy, and (ii) those tags whose keys are not explicitly mentioned in any policy. In some embodiments, the tag keys in the latter set would never match a principal tag key, nor can they have conflicting terms, otherwise they would be mentioned in the corresponding policy. Therefore, these under-specified tags can be considered irrelevant for a role reachability analysis. In some embodiments, such a tag may only be used to meet the lower bound conditions of a policy that allows the transition. By only considering tags whose keys are explicitly mentioned in a policy, the analysis unit 100 can identify session tags that may later serve as principal tags and also greens for conflict conditions.

6 FIG. 12 is a flow chart illustrating further aspects of the method for analyzing role reachability with transitive tags, according to some embodiments. The analysis unit 100 may implement a method that given the set of users and roles constructs its role reachability graph and returns its adjacency list representation. An adjacency list can indicate for a specific node which neighbors the node has. As shown in 600, the method may begin by defining a set q containing all nodes yet to be processed, e.g. B. Nodes whose possible neighbors and outgoing edges are to be determined. Hence q can be extended to include all pairs of the form (p, ∅), where p is a user or role. As shown in 610 and 620, the parsing unit 100 can select a node and extract its principal p and transitive tag state as long as there are nodes left to process. In some embodiments, the order in which the nodes are selected may be irrelevant. If there are no unprocessed nodes, the method can end.

The analysis unit 100 can limit the consideration of roles to a finite set and only consider finite paths. As shown in 630, the analysis unit 100 can consider any role r that p could potentially assume. A "candidate" function can return the set of all session tags that could potentially be passed from p to r during role inheritance with the associated conditions as previously described. Since each subset of the set of session tags can be a candidate for the set of transitive tags provided during the current step, the analysis unit 100 can iterate over them and discard tags whose key is in the current state of the transitive tags, since transitive tags are not can be overwritten. Once the keys are determined, their values can be characterized using the policy language in which the properties are specified: , if e.g. For example, if a tag key is not mentioned in the policy enabling the current transition, its value is unrestricted or partially restricted (e.g. by the condition StringLike: *), while if a tag key is mentioned, all applicable conditions aggregated and assigned to the tag key. While the analysis unit 100 checks that the proposed set of session tags meets all the conditions of the transition-enabling policy, it can also check if it can be extended by a set of under-specified tags to meet the lower-bound conditions.

As shown in 640, the analysis unit 100 can consider the role r together with the extended state of the transitive tag as a candidate for a neighbor node in the role reachability graph. In some embodiments, the properties characterizing the values of the tags in the state of the transitive tag need to be updated to reflect the conditions they need to meet during the current step, e.g. B. the conditions that are placed on the client tags by the release statement. As shown in 650, the analysis unit 100 can check whether the conditions characterizing each tag value are actually satisfiable, otherwise the candidate node would not exist. Such a circumstance could arise as a result of conflicting conditions for the key at different stages of a role inheritance chain. In addition, as shown in 660, the analysis unit 100 can check whether the transition between the considered nodes is valid. As shown in 670, if the transition is valid, the analysis unit 100 may update the adjacency list. As shown in 680, if the new node has not yet been seen, the parsing unit 100 may add it to the list of nodes to be processed and indicate that the node has already been introduced into the graph. As previously discussed, the graph may include cyclic sections where traversal of the graph may visit the same node more than once. When creating the graph, the analysis unit must not exceed 100 densel Do not visit ben nodes twice, as subsequent visits do not necessarily add additional permissions.

In some embodiments, the role reachability analysis may not consider the entire history of conditions for tags when transitioning to assume roles. In some embodiments, the role reachability analysis may consider a broader history of conditions for tags, e.g. B. the last N steps as history. In some embodiments, the role reachability analysis may enumerate a broader set of paths. For example, in role reachability analysis, a path merging technique can be used to encode an exponential number of paths. By considering a broader tag history and/or a broader set of paths, the analysis can consume more computational resources but also achieve higher accuracy.

7 12 is a flow chart illustrating a method for analyzing role reachability using policy additions, according to some embodiments. As shown in 700, a first node and a second node in a graph may be determined. The first node may correspond to a first role in a provider network hosting a variety of services and resources. The first role may be associated with a first access control policy that grants or denies access to a first service or resource. The second node may correspond to a second role in the provider network. The second role may be associated with a second access control policy that grants or denies access to a second service or resource based at least in part on one or more conditions. The first and second nodes may possibly share an edge so that role inheritance can occur from the first role to the second role without inheriting any intermediate roles. A role reachability analysis can be initiated to determine whether the first role can assume the second role for a specific state of one or more key-value tags.

As shown in 710, the role reachability analysis may determine a third access control policy that authorizes an addition to a role assumption request for the second role. The third access control policy may allow all actions except assuming the second role. The third access control policy may be a policy supplement related to the role assumption request for the second role. The third access control policy may represent a negation of a role assumption action by a principal in the first role. The third access control policy can be referred to as a negated access control policy.

As shown in 720, the role reachability analysis may perform an analysis of the third (negated) access control policy relative to a role inheritance policy for the second role for the particular state of the one or more tags. In some embodiments, the role inheritance policy can be extended for the second role, e.g. B. with directives that deny all requests that do not meet the conditions of one or more tags. The analysis may be performed using a policy comparison service that determines whether an access control policy is more acceptable, less acceptable, equally acceptable, or not comparable to another access control policy with respect to another access control policy. Because tag string space may be unbounded (e.g., due to wildcards), the unit of analysis may select one or more representative values for one or more key-value tags from a range of potential values (an equivalence class) for the tag(s)( s) select. Based on these representative values, the status of the one or more tags can be determined.

In some embodiments, the third access control policy (specifying the supplementation of the role assumption action) may include the extended role assumption policy for the second role if and only if there is no context in which the assumption of the second role is authorized. In some embodiments, the first role may be authorized to assume the second role if and only if the third access control policy (specifying the supplementation of the role assumption action) does not include the extended role assumption policy for the second role. As shown in 730, if the third access control policy includes the extended role assumption policy for the second role, access to the second service or resource for a principal in the first role may be denied. As shown in 740, if the third access control policy does not include the extended role assumption policy for the second role, access to the second service or resource may be granted to a principal in the first role.

8th 13 illustrates further aspects of the example system environment for role reachability analysis with transitive tags, including an equivalence result generated in response to a request to analyze the equivalence of two security policies, according to some embodiments. As previously mentioned, the policy comparison service 180 can be used to analyze the equivalence of two access control (security) policies in response to a client request. A client of the policy comparison service 180, such as the analysis unit 100, can make an API request to the policy comparison service that includes two or more security policies. A security policy may represent information (e.g. encoded in a file) that specifies one or more security permissions. Security permissions can be elements of the security policy that define access rights associated with resources and/or clients of a system. For example, a credential can be used to restrict access to the computing resources of a computing resource service provider, e.g. B. the provider network 190 to grant or deny. Policies can be expressed in a language-independent format such as JavaScript Object Notation (JSON). The examples discussed in this disclosure may be in JSON or JSON-like format and are provided to illustrate various embodiments that may be implemented. Of course, various other formats that can be used in the manner described in connection with JSON and JSON-like formats are also contemplated and fall within the scope of this disclosure. A security policy can include one or more permission statements and additional information such as version information and policy-wide information. In some cases, policy-wide information may be included in a policy header at the beginning of a policy, or even stored separately from (and associated with) a policy document. A policy can contain multiple policy statements.

In some embodiments, the term "allowance" is used to describe granting access to resources. For example, if a first policy grants access to a first compute resource (e.g. resource "A") and a second resource (e.g. resource "B"), and a second policy grants access only to compute resource "B". , then the first policy can be described as more allowable than the second policy because there is a compute resource that the first policy grants access to that the second policy does not grant access to, and there is no resource that the second policy grants access to granted that the first policy does not grant access to. Two policies can be equivalent if they both grant access to the same resources and deny access to the same resources (either implicitly or explicitly). In some cases, equivalence may refer to two policies that explicitly grant access to the same resources and explicitly deny access to the same resources, e.g. B. A first policy that explicitly denies access to a compute resource and a second policy that implicitly denies access to a compute resource (e.g., by not allowing access in a "default-deny" context affirmatively granted), may not be equivalent in some embodiments. In general, when two policies are not equivalent, they can be said to lack equivalence. When a first policy grants access to a first compute resource "A" and a second compute resource "B" and a second policy grants access to the second compute resource "B" and a third compute resource "C", the policies may in some cases be considered incomparable be designated. It is noted that unless otherwise noted, the examples described in this document may implement a "default-deny" security model in which access to a computing resource is denied if access to the computing resource is not explicitly granted. It should also be noted that in the context of these discussions, security policies may be used to grant or deny access to resources in the context of a computing resource provider, where a request for access to resources is processed by an authorization module or service using an on the request applicable security policy can be assessed. An applicable security policy may be a security policy associated with the supplicant, a security policy associated with a token presented by the supplicant, and so on.

Policy comparison service 180 may include various components and/or modules, such as a policy parser, a propositional translator, and a satisfiability engine. The policy parser can be a component or module that receives a security policy (e.g., a security policy received from a client in connection with an API call or retrieved through a policy management service) and retrieves one or more authorization statements from the policy . For example, if the client provides the policy comparison service 180 with a first policy "A" and a second policy "B", the policy comparison service can use the policy parser to extract a first set of authorization statements from policy "A" and a second set of authorization statements from policy to get "B". The authorization instructions can NEN respectively be associated with granting or denying access to a computing resource. The permission statements can be in a concrete format like JSON, Aspen, etc.

As described in this paper, propositional logic can refer to symbolic logic related to the evaluation of propositions that can be evaluated as either true or false. Propositional logic can be used to evaluate the logical equivalence of propositional formulas. A propositional formula can be a statement that conforms to a syntax that includes propositional variables and logical connectives that connect the propositional variables. Examples of logical connectives or logical operators can be: "AND" (conjunction), "OR" (disjunction), "NOT" (negation) and "IF AND ONLY IF" (biconditional). In this document, propositional logic can also be referred to as “propositional expression” or “propositional logic expression”. In some embodiments, predicate logic may be used instead of propositional logic. First order logic can refer to a formal system that uses quantifiers in addition to propositional logic. Examples of quantifiers are “FOR ALL” (universal quantifier) and “THERE EXISTS” (existential quantifier). Unless expressly noted, embodiments of this disclosure that are described in the context of propositional logic may also be implemented using predicate logic. For example, in some embodiments, a predicate logic translator may be used instead of a propositional translator to translate authorization statements into predicate logic expressions, and a satisfiability engine may evaluate one or more predicate logic expressions to determine whether the expressions are equivalent.

Authorization statements (such as those obtained from the policy parser) can be provided to a propositional translator. A propositional translator can receive a permission statement (e.g. in JSON format) and convert the permission statement into one or more constraints described using propositional logic. The constraints can be described in various formats and according to various standards, such as SMT-LIB standard formats, CVC language, and Center for Discrete Mathematics and Theoretical Computer Science (DIMACS) formats. The propositional expressions generated by the propositional translator may represent a set of constraints that must be satisfied for the corresponding authorization statement to take effect. The constraints may necessarily be satisfied if the preceding permission statement allowing access to APIs beginning with "put" (e.g. "put-object") is satisfied.

In some embodiments, the analysis unit 100 can transmit a web-based API request to the policy comparison service 180 requesting that the policy comparison service determine whether a first security policy (e.g. "security policy A") is more acceptable than the second security policy (e.g "Security Policy B"). The security policies can be encoded in the Web API request, or information can be provided that can be used to retrieve the security policies (e.g., a pointer or a URI indicating the location where a policy is retrieved). can). The policy comparison service 180 can retrieve the security policies (e.g. either directly from the request or via a policy management service using a URI encoded in the request) and use a policy parser to extract a first set of authorization statements from the first policy and a second set of Retrieve authorization instructions from the second policy. The policy statements may be provided to a propositional translator to obtain a set of propositional expressions that conform to the constraints that must be satisfied for the corresponding policy statement to take effect. A first propositional expression can be generated from the first set of policy statements and a second propositional expression can be generated from the second set of policy statements. The propositional expressions can be expressed in a language conforming to an SMT-LIB standard language such as the STM-LIB 2.0 standard. A satisfiability engine can be used to compare the first propositional expression and the second propositional expression to determine whether one of the two propositional logics is more feasible than the other.

A satisfiability engine can be used to analyze the feasibility of two or more propositional expressions. The satisfiability engine can be hardware, software, or a combination thereof. In some embodiments, the satisfiability engine allows the clients (e.g., internal clients such as the propositional translator, the policy comparison service 180, etc.) to determine whether a first propositional expression is more legal than a second propositional expression. The satisfiability engine may generate additional propositional constraints as part of determining whether the first propositional expression is more feasible than the second propositional expression.

The constraints can be generated and evaluated in addition to the constraints of the first propositional expression and the second propositional expression, which can be encoded in the manner described above. The constraints may be generated based at least in part on a client's requests. For example, the satisfiability engine may generate constraints that are satisfied only under circumstances where a first policy grants access to a resource and a second policy denies access to the resource or is neutral with respect to the resource, in response upon a request from a caller (e.g., policy comparison service 180) to determine whether a first propositional expression is more legal than a second propositional expression. Such an embodiment may be implemented in a "default-deny" context, in which a neutral context (ie, a context in which no permission explicitly grants or denies access to a particular resource). In a "default-allow" context, the satisfiability engine can generate various constraints that are satisfied when the first policy grants access to a resource or is neutral towards the resource and the second policy does not deny access to the resource .

The satisfiability engine can be used to check whether the propositional constraints (e.g. those obtained from the first and second propositional expressions and those generated by the satisfiability engine) are equivalent. In some embodiments, an instruction can be used to determine whether the set of constraints is satisfiable. A formula can be satisfiable if there is an interpretation that makes all the asserted formulas true. In other words, the model is satisfiable if each of the constraints is satisfied under some conditions. In some embodiments, the satisfiability engine may be implemented, at least in part, using a Satisfiability Modulo Theory (SMT) constraint solver to determine whether a formula is satisfiable. An example of an SMT-based constraint solver is Z3. Other types of solvers may be used as part of implementing a satisfiability engine, including but not limited to SAT solvers and BDD solvers, consistent with the techniques described herein. The satisfiability engine can generate an equivalence result indicating whether the formula is satisfiable and whether two or more policies are equivalent. In some embodiments, an equivalence result is provided to another computing device, such as the analysis device 100 that made a request, a system administrator, and other computing devices.

In some embodiments, a client, such as analysis engine 100, may query on behalf of a client to determine the equivalence between two security policies. In some embodiments, the request may include a web API request encoding the security policy to be analyzed as part of the request. However, in some embodiments, the security client computing device may provide a reference to one or more security policies that the recipient of the request may use to obtain the one or more security policies. In some embodiments, a web API request is transmitted from analytics unit 100 to a computing resource service provider, such as provider network 190 . The request can be fulfilled by a policy comparison service 180 . A first security policy 804A can be parsed to obtain one or more authorization statements 806A, and the authorization statements 806A can be translated into a first set of propositional expressions 808 that can serve as constraints for a propositional formula. Likewise, a second security policy 804B can be parsed to obtain one or more authorization statements 806B, and the authorization statement 806B can be parsed to obtain a second set of propositional expressions 808 that can serve as constraints. The service 180 may utilize a satisfiability engine 812 to determine whether the two propositional expressions are equivalent, whether one of the two expressions is more feasible than the other, and more.

In some embodiments, an equivalence result 812 may indicate that two policies are equivalent. Two policies can be said to be equivalent if the security permissions of the first policy and the second policy apply equally to all actions, resources, and principals, such that for any set of actions, resources, and principals, both the first policy and the second policy either deny access (either explicitly based on a deny statement or implicitly based on the lack of a permission granting access) or both grant access. In some embodiments, it is not the case that one policy grants access and the other denies access. In some cases where a policy is determined to be more allowable than another policy, one policy grants access to a set of parameters while another policy denies access.

In some embodiments, the equivalence result 812 may be transmitted to the analysis unit 100 in response to a web API request. In some embodiments, the equivalence result 812 may encode the allowability result (e.g., whether one policy was more allowable than a second policy). In some embodiments, other information is provided either in place of or in addition to the acceptability score. For example, in the case where a first policy is more allowable than a second policy, the equivalence result 812 may encode a set of parameters that result in the first policy granting access and the second policy denying access (e.g., For example, a principal, a resource, and an action can be encoded in the response such that a first policy grants the principal access to perform the action on the resource, and the second policy denies the principal access to perform the action of the resource).

Illustrative Computer System

In at least some embodiments, a computer system that implements part or all of one or more technologies described herein may include a computer system that includes or is configured to access one or more computer-readable media. 9 FIG. 9 illustrates one such computing device 900. In the illustrated embodiment, computing device 900 includes one or more processors 910A-910N coupled to system memory 920 via an input/output (I/O) interface 930. FIG. The computing device 900 also includes a network interface 940 coupled to the I/O interface 930 .

In various embodiments, computing device 900 may be a uniprocessor system, including one processor, or a multiprocessor system, including multiple processors 910A-910N (e.g., two, four, eight, or another suitable number of processors) included. Processors 910A-910N can be any suitable processor capable of executing instructions. For example, in various embodiments, processors 910A-910N may be processors that implement any of a variety of instruction set architectures (ISAs), such as x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of the processors 910A-910N may implement a common, but not necessarily the same, ISA.

System memory 920 may be configured to store program instructions and data accessible by processor(s) 910A-910N. In various embodiments, system memory 920 may be implemented using any suitable memory technology, such as using static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile/flash memory, or a any other type of storage. In the illustrated embodiment, program instructions and data that implement one or more desired functions, such as the methods, techniques, and data described above, are shown stored in system memory 920 as code (i.e., program instructions) 925 and data 926 . In the illustrated embodiment, system memory 920 also stores program code and data that implement the aspects of access control analysis unit 100 discussed above.

In one embodiment, I/O interface 930 may be configured to coordinate I/O traffic between processors 910A-910N, system memory 920, and any peripherals in the device, including network interface 940 or other peripheral interfaces. In some embodiments, I/O interface 930 may perform any required protocol, timing, or other data conversions to convert data signals from one component (e.g., system memory 920) to one for use by another component (e.g., system memory 920). B. the processors 910A-910N) suitable format to convert. In some embodiments, I/O interface 930 may include support for devices connected via various types of peripheral buses, such as a variation of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus ( USB) standards, etc. In some embodiments, the function of the I/O interface 930 can be split into two or more separate components, such as a north bridge and a south bridge, etc. In some embodiments, some or all of the functions of the I/O interface 930, such as an interface to system memory 920, may be integrated directly into processors 910A-910N.

The network interface 940 may be configured to enable data exchange between the computing device 900 and other devices 960 connected to a network or networks 950 . In various embodiments, network interface 940 may support communication over any suitable wired or wireless general data network, such as types of Ethernet network, etc. Additionally, network interface 940 may support communication over telecommunications/telephony networks, such as analog voice networks or digital fiber optic communication networks, over storage area networks, such as Fiber Channel SANs, or over any other suitable type of network and/or protocol.

In some embodiments, system memory 920 may be an embodiment of a computer-readable (ie, computer-accessible) medium configured to store program instructions and data as described above for implementing embodiments of the corresponding methods and apparatus. For example, system memory 920 may store program code and data associated with access control analysis unit 100 . In some embodiments, the program instructions and/or data may be received, transmitted, or stored on other types of computer-readable media. In general terms, a computer-readable medium can include non-transitory storage media or data storage media, such as magnetic or optical media, e.g. a floppy disk or DVD/CD, coupled to computing device 900 via I/O interface 930 . A non-transitory computer-readable storage medium may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., embodied in some embodiments of computing device 900 as system memory 920 or other type of memory may be included. Further, a computer-readable medium may include transmission media or signals, such as electrical, electromagnetic, or digital signals, transmitted over a communication medium, such as a network and/or wireless connection, such as may be implemented via network interface 940. Parts or the whole of several computing devices, as in 9 illustrated may be used to implement the described functions in various embodiments; for example, software components running on a variety of different devices and servers can work together to provide the functionality. In some embodiments, portions of the described functionality may be implemented using storage devices, network devices, or various types of computing systems. The term "computing device" as used herein refers to at least all of these types of devices and is not limited to them.

The various methods as illustrated in the figures and described throughout this document represent example method embodiments. The methods may be implemented in software, hardware, or a combination thereof. In various of the methods, the order of the steps may be changed, and various elements may be added, reordered, combined, omitted, modified, and so on. Various of the steps may be performed automatically (e.g., without being directly prompted by user input) and/or programmatically (e.g., according to program instructions).

The terminology used in the description of the present invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular forms "a", "an" and "the" as used in the description of the invention and the appended claims are intended to include the plural forms as well, unless the context clearly dictates otherwise. It is also understood that the term "and/or" as used in this specification includes all possible combinations of one or more of the listed items. It is further understood that the terms "includes," "including," "includes," and/or "comprising" when used in this specification imply the presence of specified features, integers, steps, acts, elements, and/or Identify component, but does not exclude the presence or addition of any other feature, integer, step, operation, element, component and/or group thereof.

As used herein, the term "if" may be understood as "when" or "at" or "in response to determining" or "in response to detecting" depending on the context. Likewise, the phrase "when determined" or "when [a specified condition or event] is detected" may be construed to mean "when determined" or "in response to the determining" or "when detecting [ of the specified condition or event]" or "in response to detecting [the specified condition or event]".

It is also understood that while the terms "first,""second," etc. can be used throughout this specification to describe various elements, these elements are not intended to be limited by those terms. These terms are only used to distinguish one element from another. For example, a first contact could be referred to as a second contact, and similarly a second contact could be referred to as a first contact without departing from the scope of the present invention. The first contact and the second contact are both contacts, but they are not the same contact.

Numerous specific details are set forth throughout this document to aid in understanding the claimed subject matter. However, one skilled in the art will understand that the claimed subject matter may be practiced without these specific details. In other instances, methods, devices, or systems well known to those of ordinary skill in the art have not been described in detail so as not to obscure the claimed subject matter. Various modifications and changes can be made as will become apparent to those skilled in the art having the benefit of this disclosure. It is intended that all such modifications and changes are included in this specification and, accordingly, the foregoing description is to be regarded in an illustrative rather than a restrictive sense.

• Satz 1. System, umfassend:
  • eine Zugriffssteuerungsanalyseeinheit, die einen oder mehrere Prozessoren und einen oder mehrere Speicher zum Speichern von computerausführbaren Anweisungen umfasst, die bei Ausführung den einen oder die mehreren Prozessoren zu Folgendem veranlassen:
    • Bestimmen eines Graphen, der eine Vielzahl von Knoten und eine oder mehrere gerichtete Kanten umfasst, wobei die Knoten eine Vielzahl von Rollen in einem Anbieternetzwerk darstellen, das eine Vielzahl von Diensten und Ressourcen beherbergt, wobei die Knoten einen ersten Knoten, der eine erste Rolle darstellt, und einen zweiten Knoten, der eine zweite Rolle darstellt, umfassen, wobei die Rollen einer Vielzahl von Zugriffssteuerungsrichtlinien zugeordnet sind, die den Zugriff auf einzelne der Vielzahl von Diensten und Ressourcen gewähren oder verweigern, und wobei eine oder mehrere der Zugriffssteuerungsrichtlinien den Zugriff zumindest teilweise basierend auf einem oder mehreren Schlüsselwert-Tags gewähren oder verweigern; und
    • Bestimmen, zumindest teilweise basierend auf einer Rollenerreichbarkeitsanalyse des Graphen, ob die erste Rolle die zweite Rolle unter Verwendung eines oder mehrerer Rollenübernahmeschritte für einen konkreten Zustand des einen oder der mehreren Schlüsselwert-Tags übernehmen kann, wobei ein einzelner der Rollenübernahmeschritte einen temporären Zugriff während einer Rollensitzung bereitstellt und wobei das eine oder die mehreren Schlüsselwert-Tags ein oder mehrere transitive Tags umfassen, die während des einen oder der mehreren Rollenübernahmeschritte bestehen bleiben.
• Satz 2. System nach Satz 1, wobei die Zugriffssteuerungsrichtlinien es der ersten Rolle erlauben, die zweite Rolle zu übernehmen, wenn die erste Rolle ein Sitzungs-Tag bereitstellt, das mit einer Bedingung übereinstimmt, die der zweiten Rolle zugeordnet ist.
• Satz 3. System nach Satz 2, wobei die Bedingung, die der zweiten Rolle zugeordnet ist, einen oder mehrere Platzhalter für einen Wert eines Schlüssels umfasst.
• Satz 4. System nach einem der Sätze 1-2, wobei der Graph bestimmt wird, indem ein oder mehrere Nachbarn für einen konkreten Knoten in dem Graphen zumindest teilweise basierend auf einem Satz der Schlüsselwert-Tags festgestellt werden, deren Schlüssel explizit mit entsprechenden Bedingungen in den Zugriffssteuerungsrichtlinien angegeben sind, oder durch unterspezifizierte Schlüsselwert-Tags, deren Werte uneingeschränkt oder teilweise eingeschränkt sind.
• Satz 5. Verfahren, umfassend:
  • Bestimmen, durch eine Zugriffssteuerungsanalyseeinheit, eines Graphen, der eine Vielzahl von Knoten und eine oder mehrere Kanten umfasst, wobei die Knoten eine Vielzahl von Rollen in einem Anbieternetzwerk darstellen, das eine Vielzahl von Ressourcen beherbergt, wobei die Knoten einen ersten Knoten, der eine erste Rolle darstellt, und einen zweiten Knoten, der eine zweite Rolle darstellt, umfassen, wobei die Rollen einer Vielzahl von Zugriffssteuerungsrichtlinien zugeordnet sind, die den Zugriff auf einzelne der Vielzahl von Ressourcen gewähren oder verweigern, und wobei eine oder mehrere der Zugriffssteuerungsrichtlinien den Zugriff zumindest teilweise basierend auf einem oder mehreren Attributen gewähren oder verweigern; und
  • Bestimmen, durch die Zugriffssteuerungsanalyseeinheit zumindest teilweise basierend auf einer Rollenerreichbarkeitsanalyse des Graphen, ob die erste Rolle die zweite Rolle unter Verwendung eines oder mehrerer Rollenübernahmeschritte für einen konkreten Zustand des einen oder der mehreren Attribute übernehmen kann, und wobei das eine oder die mehreren Attribute ein oder mehrere transitive Attribute umfassen, die während des einen oder der mehreren Rollenübernahmeschritte bestehen bleiben.
• Satz 6. Verfahren nach Satz 5, wobei die Zugriffssteuerungsrichtlinien es der ersten Rolle erlauben, die zweite Rolle zu übernehmen, wenn die erste Rolle ein Sitzungsattribut bereitstellt, das mit einer Bedingung übereinstimmt, die der zweiten Rolle zugeordnet ist.
• Satz 7. Verfahren nach Satz 6, wobei die Bedingung, die der zweiten Rolle zugeordnet ist, einen oder mehrere Platzhalter für einen Wert eines Schlüssels umfasst.
• Satz 8. Verfahren nach einem der Sätze 5-7, ferner umfassend:
  • Aggregieren einer oder mehrerer Randbedingungen für das eine oder die mehreren Attribute, wobei die eine oder die mehreren Randbedingungen durch eine oder mehrere der Zugriffssteuerungsrichtlinien angegeben werden, die dem einen oder den mehreren Rollenübernahmeschritten zugeordnet sind.
• Satz 9. Verfahren nach einem der Sätze 5-8, wobei ein oder mehrere Nachbarn für einen konkreten Knoten in dem Graphen zumindest teilweise basierend auf einem Satz der Attribute bestimmt werden, deren Schlüssel explizit mit entsprechenden Bedingungen in den Zugriffssteuerungsrichtlinien angegeben sind.
• Satz 10. Verfahren nach einem der Sätze 5-9, wobei ein oder mehrere Nachbarn für einen konkreten Knoten in dem Graphen zumindest teilweise basierend auf unterspezifizierten Attributen bestimmt werden, deren Werte uneingeschränkt oder teilweise eingeschränkt sind.
• Satz 11. Verfahren nach einem der Sätze 5-10, wobei die erste Rolle in einem ersten Konto bei dem Anbieternetzwerk ist und wobei die zweite Rolle in einem zweiten Konto bei dem Anbieternetzwerk ist.
• Satz 12. Verfahren nach einem der Sätze 5-11, ferner umfassend:
  • zumindest teilweise basierend auf dem Bestimmen, dass die erste Rolle die zweite Rolle übernehmen kann, Erzeugen einer Benachrichtigung über einen Sicherheitsbefund in Bezug auf eine Konfiguration der Zugriffssteuerungsrichtlinien.
• Satz 13. Ein oder mehrere nichttransitorische computerlesbare Speichermedien, auf denen Programmanweisungen gespeichert sind, die bei Ausführung auf einem oder mehreren oder über einen oder mehrere Prozessoren Folgendes durchführen:
  • Bestimmen, durch eine Zugriffssteuerungsanalyseeinheit, eines Graphen, der eine Vielzahl von Knoten und eine oder mehrere Kanten umfasst, wobei die Knoten eine Vielzahl von Rollen in einem Anbieternetzwerk darstellen, das eine Vielzahl von Diensten oder Ressourcen beherbergt, wobei die Knoten einen ersten Knoten, der eine erste Rolle darstellt, und einen zweiten Knoten, der eine zweite Rolle darstellt, umfassen, wobei die Rollen einer Vielzahl von Zugriffssteuerungsrichtlinien zugeordnet sind, die den Zugriff auf einzelne der Vielzahl von Diensten oder Ressourcen gewähren oder verweigern, und wobei eine oder mehrere der Zugriffssteuerungsrichtlinien den Zugriff zumindest teilweise basierend auf einem oder mehreren Tags gewähren oder verweigern; und
  • Bestimmen, durch die Zugriffssteuerungsanalyseeinheit zumindest teilweise basierend auf einer Rollenerreichbarkeitsanalyse des Graphen, ob die erste Rolle die zweite Rolle unter Verwendung eines oder mehrerer Rollenübernahmeschritte für einen konkreten Zustand des einen oder der mehreren Tags übernehmen kann, und wobei das eine oder die mehreren Tags ein oder mehrere transitive Tags umfassen, die während des einen oder der mehreren Rollenübernahmeschritte bestehen bleiben.
• Satz 14. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach Satz 13, wobei die Zugriffssteuerungsrichtlinien es der ersten Rolle erlauben, die zweite Rolle zu übernehmen, wenn die erste Rolle ein Sitzungs-Tag bereitstellt, das mit einer Bedingung übereinstimmt, die der zweiten Rolle zugeordnet ist.
• Satz 15. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach Satz 14, wobei die Bedingung, die der zweiten Rolle zugeordnet ist, nicht einen oder mehrere Platzhalter für einen Wert für einen Schlüssel umfasst.
• Satz 16. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 13-15, ferner umfassend zusätzliche Programmanweisungen, die bei Ausführung auf dem einen oder den mehreren oder über den einen oder die mehreren Prozessoren Folgendes durchführen:
  • Aggregieren einer oder mehrerer Randbedingungen für das eine oder die mehreren Attribute, wobei die eine oder die mehreren Randbedingungen durch eine oder mehrere der Zugriffssteuerungsrichtlinien angegeben werden, die dem einen oder den mehreren Rollenübernahmeschritten zugeordnet sind.
• Satz 17. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 13-16, wobei der Graph zumindest teilweise basierend auf einem oder mehreren der Tags bestimmt wird, die Schlüssel aufweisen, die explizit in den Zugriffssteuerungsrichtlinien angegeben sind.
• Satz 18. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 13-17, wobei der Graph zumindest teilweise basierend auf der Anwendung einer oder mehrerer Randbedingungen für das eine oder die mehreren Tags bestimmt wird, wobei die eine oder die mehreren Randbedingungen durch eine oder mehrere der Zugriffssteuerungsrichtlinien angegeben werden, die dem einen oder den mehreren Rollenübernahmeschritten zugeordnet sind.
• Satz 19. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 13-18, ferner umfassend zusätzliche Programmanweisungen, die bei Ausführung auf dem einen oder den mehreren oder über den einen oder die mehreren Prozessoren Folgendes durchführen:
  • Überwachen von Aufrufen an die Vielzahl von Diensten in dem Anbieternetzwerk; und wenn bestimmt wird, dass die Aufrufe einen Zustand des Anbieternetzwerks verändern, Neustarten der Rollenerreichbarkeitsanalyse.
• Satz 20. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 13-19, wobei der Graph unter Verwendung eines Richtlinienvergleichsdienstes bestimmt wird, der einen semantischen Unterschied zwischen zwei der Zugriffssteuerungsrichtlinien bestimmt.
• Satz 21. System, umfassend:
  • eine Zugriffssteuerungsanalyseeinheit, die einen oder mehrere Prozessoren und einen oder mehrere Speicher zum Speichern von computerausführbaren Anweisungen umfasst, die bei Ausführung den einen oder die mehreren Prozessoren zu Folgendem veranlassen:
    • Bestimmen eines ersten Knotens in einem Graphen, wobei der erste Knoten einer ersten Rolle in einem Anbieternetzwerk entspricht, das eine Vielzahl von Diensten und Ressourcen beherbergt, wobei die erste Rolle einer ersten Zugriffssteuerungsrichtlinie zugeordnet ist und wobei die erste Zugriffssteuerungsrichtlinie den Zugriff auf eine(n) erste(n) der Dienste und Ressourcen gewährt oder verweigert;
    • Bestimmen eines zweiten Knotens in dem Graphen, wobei der zweite Knoten einer zweiten Rolle in dem Anbieternetzwerk entspricht, wobei die zweite Rolle einer zweiten Zugriffssteuerungsrichtlinie zugeordnet ist und wobei die zweite Zugriffssteuerungsrichtlinie den Zugriff auf eine(n) zweite(n) der Dienste und Ressourcen gewährt oder verweigert;
    • Durchführen einer Rollenerreichbarkeitsanalyse, die bestimmt, ob die erste Rolle die zweite Rolle für einen konkreten Zustand eines oder mehrerer Schlüsselwert-Tags übernehmen kann, wobei der eine oder die mehreren Rollenübernahmeschritte temporären Zugriff während einer Rollensitzung bereitstellen, wobei die Rollenerreichbarkeitsanalyse eine dritte Zugriffssteuerungsrichtlinie bestimmt, die eine Ergänzung einer Rollenübernahmeanfrage für die zweite Rolle autorisiert, wobei die Rollenerreichbarkeitsanalyse bestimmt, ob die erste Rolle die zweite Rolle übernehmen kann, und zwar zumindest teilweise basierend auf einer Analyse der dritten Zugriffssteuerungsrichtlinie in Bezug auf eine Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Schlüsselwert-Tags, und wobei die Rollenübernahmeanfrage nicht autorisiert ist, wenn die dritte Zugriffssteuerungsrichtlinie nicht die Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Schlüsselwert-Tags beinhaltet; und
    • zumindest teilweise basierend auf der Rollenerreichbarkeitsanalyse, Gewähren oder Verweigern des Zugriffs auf den/die zweite(n) der Dienste und Ressourcen für einen Auftraggeber in der erste Rolle.
• Satz 22. System nach Satz 21, wobei die Rollenübernahmerichtlinie für die zweite Rolle so erweitert wird, dass sie eine oder mehrere Anweisungen beinhaltet, die Anfragen ablehnen, die eine oder mehrere Bedingungen der Rollenübernahmerichtlinie für die zweite Rolle nicht erfüllen.
• Satz 23. System nach einem der Sätze 21-22, wobei eine oder mehrere Bedingungen der Rollenübernahmerichtlinie für die zweite Rolle einen oder mehrere Platzhalter für das eine oder die mehreren Schlüsselwert-Tags umfassen.
• Satz 24. System nach Satz 23, wobei die Rollenerreichbarkeitsanalyse einen oder mehrere repräsentative Werte für das eine oder die mehreren Schlüsselwert-Tags aus einem Bereich potenzieller Werte für das eine oder die mehreren Schlüsselwert-Tags auswählt, wobei der Bereich potenzieller Werte zumindest teilweise basierend auf dem einen oder den mehreren Platzhaltern bestimmt wird und wobei der konkrete Zustand des einen oder der mehreren Schlüsselwert-Tags zumindest teilweise basierend auf dem einen oder den mehreren repräsentativen Werten für das eine oder die mehreren Schlüsselwert-Tags bestimmt wird.
• Satz 25. Verfahren, umfassend:
  • Bestimmen, durch eine Zugriffssteuerungsanalyseeinheit, eines ersten Knotens in einem Graphen, wobei der erste Knoten einer ersten Rolle in einem Anbieternetzwerk entspricht, das eine Vielzahl von Ressourcen beherbergt, wobei die erste Rolle einer ersten Zugriffssteuerungsrichtlinie zugeordnet ist und wobei die erste Zugriffssteuerungsrichtlinie den Zugriff auf eine oder mehrere erste der Ressourcen gewährt oder verweigert;
  • Bestimmen, durch die Zugriffssteuerungsanalyseeinheit, eines zweiten Knotens in dem Graphen, wobei der zweite Knoten einer zweiten Rolle in dem Anbieternetzwerk entspricht, wobei die zweite Rolle einer zweiten Zugriffssteuerungsrichtlinie zugeordnet ist und wobei die zweite Zugriffssteuerungsrichtlinie den Zugriff auf eine oder mehrere zweite der Ressourcen gewährt oder verweigert;
  • Durchführen, durch die Zugriffssteuerungsanalyseeinheit, einer Rollenerreichbarkeitsanalyse, die bestimmt, ob die erste Rolle die zweite Rolle für einen konkreten Zustand von einem oder mehreren Attributen übernehmen kann, wobei die Rollenerreichbarkeitsanalyse Folgendes umfasst:
    • Bestimmen einer dritten Zugriffssteuerungsrichtlinie, die eine Negation einer Rollenübernahmeanfrage für die zweite Rolle autorisiert; und
    • Bestimmen, ob die erste Rolle die zweite Rolle übernehmen kann, zumindest teilweise basierend auf der Analyse der dritten Zugriffssteuerungsrichtlinie in Bezug auf eine Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Attribute.
• Satz 26. Verfahren nach Satz 25, ferner umfassend:
  • zumindest teilweise basierend auf der Rollenerreichbarkeitsanalyse, Gewähren oder Verweigern des Zugriffs auf die zweite der Ressourcen für einen Auftraggeber in der erste Rolle.
• Satz 27. Verfahren nach einem der Sätze 25-26, wobei die Rollenübernahmerichtlinie für die zweite Rolle so erweitert wird, dass sie eine oder mehrere Anweisungen beinhaltet, die Anfragen ablehnen, die eine oder mehrere Bedingungen der Rollenübernahmerichtlinie für die zweite Rolle nicht erfüllen.
• Satz 28. Verfahren nach einem der Sätze 25-27, wobei die Rollenübernahmeanfrage nicht autorisiert wird, wenn die dritte Zugriffssteuerungsrichtlinie nicht die Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Attribute umfasst.
• Satz 29. Verfahren nach einem der Sätze 25-28, wobei die Rollenerreichbarkeitsanalyse einen Richtlinienvergleichsdienst aufruft, der ein Äquivalenzergebnis für die dritte Zugriffssteuerungsrichtlinie und die Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Attribute bestimmt.
• Satz 30. Verfahren nach einem der Sätze 25-29, wobei eine oder mehrere Bedingungen der Rollenübernahmerichtlinie für die zweite Rolle einen oder mehrere Platzhalter für das eine oder die mehreren Attribute umfassen.
• Satz 31. Verfahren nach Satz 30, wobei das Durchführen der Rollenerreichbarkeitsanalyse ferner Folgendes umfasst:
  • Auswählen eines oder mehrerer repräsentativer Werte für das eine oder die mehreren Attribute aus einem Bereich potenzieller Werte für das eine oder die mehreren Attribute, wobei der Bereich potenzieller Werte zumindest teilweise basierend auf dem einen oder den mehreren Platzhaltern bestimmt wird und wobei der konkrete Zustand des einen oder der mehreren Attribute zumindest teilweise basierend auf dem einen oder den mehreren repräsentativen Werten für das eine oder die mehreren Attribute bestimmt wird.
• Satz 32. Verfahren nach einem der Sätze 25-31, ferner umfassend:
  • zumindest teilweise basierend auf dem Bestimmen, dass die erste Rolle die zweite Rolle übernehmen kann, Erzeugen einer Benachrichtigung über einen Sicherheitsbefund in Bezug auf eine Zugriffssteuerungsrichtlinienkonfiguration.
• Satz 33. Ein oder mehrere nichttransitorische computerlesbare Speichermedien, auf denen Programmanweisungen gespeichert sind, die bei Ausführung auf einem oder mehreren oder über einen oder mehrere Prozessoren Folgendes durchführen:
  • Bestimmen, durch eine Zugriffssteuerungsanalyseeinheit, eines ersten Knotens in einem Graphen, wobei der erste Knoten einer ersten Rolle in einem Anbieternetzwerk entspricht, das eine Vielzahl von Diensten oder Ressourcen beherbergt, wobei die erste Rolle einer ersten Zugriffssteuerungsrichtlinie zugeordnet ist und wobei die erste Zugriffssteuerungsrichtlinie den Zugriff auf eine(n) oder mehrere erste der Dienste oder Ressourcen gewährt oder verweigert;
  • Bestimmen, durch die Zugriffssteuerungsanalyseeinheit, eines zweiten Knotens in dem Graphen, wobei der zweite Knoten einer zweiten Rolle in dem Anbieternetzwerk entspricht, wobei die zweite Rolle einer zweiten Zugriffssteuerungsrichtlinie zugeordnet ist und wobei die zweite Zugriffssteuerungsrichtlinie den Zugriff auf eine(n) oder mehrere zweite der Dienste oder Ressourcen gewährt oder verweigert; und
  • Durchführen, durch die Zugriffssteuerungsanalyseeinheit, einer Rollenerreichbarkeitsanalyse, die bestimmt, ob die erste Rolle die zweite Rolle für einen konkreten Zustand von einem oder mehreren Tags übernehmen kann, wobei die Rollenerreichbarkeitsanalyse Folgendes umfasst:
    • Bestimmen einer dritten Zugriffssteuerungsrichtlinie, die eine Ergänzung einer Rollenübernahmeanfrage für die zweite Rolle autorisiert; und
    • Bestimmen, ob die erste Rolle die zweite Rolle übernehmen kann, zumindest teilweise basierend auf der Analyse der dritten Zugriffssteuerungsrichtlinie in Bezug auf eine Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Tags.
• Satz 34. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach Satz 33, ferner umfassend zusätzliche Programmanweisungen, die bei Ausführung auf dem einen oder mehreren oder über den einen oder die mehreren Prozessoren Folgendes durchführen:
  • zumindest teilweise basierend auf der Rollenerreichbarkeitsanalyse, Gewähren oder Verweigern des Zugriffs auf den/die eine(n) oder mehreren zweiten der Dienste oder Ressourcen für einen Benutzer in der erste Rolle.
• Satz 35. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 33-34, wobei die Rollenübernahmerichtlinie für die zweite Rolle so erweitert wird, dass sie eine oder mehrere Anweisungen beinhaltet, die Anfragen ablehnen, die eine oder mehrere Bedingungen der Rollenübernahmerichtlinie für die zweite Rolle nicht erfüllen.
• Satz 36. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 33-35, wobei die Rollenübernahmeanfrage nicht autorisiert wird, wenn die dritte Zugriffssteuerungsrichtlinie nicht die Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Tags umfasst.
• Satz 37. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 33-36, wobei die Rollenerreichbarkeitsanalyse einen Richtlinienvergleichsdienst aufruft, der ein Äquivalenzergebnis für die dritte Zugriffssteuerungsrichtlinie und die Rollenübernahmerichtlinie für die zweite Rolle für den konkreten Zustand des einen oder der mehreren Tags bestimmt.
• Satz 38. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 33-37, wobei eine oder mehrere Bedingungen der Rollenübernahmerichtlinie für die zweite Rolle einen oder mehrere Platzhalter für das eine oder die mehreren Tags umfassen.
• Satz 39. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach Satz 38, ferner umfassend zusätzliche Programmanweisungen, die bei Ausführung auf dem einen oder mehreren oder über den einen oder die mehreren Prozessoren Folgendes durchführen:
  • Auswählen eines oder mehrerer repräsentativer Werte für das eine oder die mehreren Tags aus einem Bereich potenzieller Werte für das eine oder die mehreren Tags, wobei der Bereich potenzieller Werte zumindest teilweise basierend auf dem einen oder den mehreren Platzhaltern bestimmt wird und wobei der konkrete Zustand des einen oder der mehreren Tags zumindest teilweise basierend auf dem einen oder den mehreren repräsentativen Werten für das eine oder die mehreren Tags bestimmt wird.
• Satz 40. Ein oder mehrere nichttransitorische computerlesbare Speichermedien nach einem der Sätze 33-39, ferner umfassend zusätzliche Programmanweisungen, die bei Ausführung auf dem einen oder den mehreren oder über den einen oder die mehreren Prozessoren Folgendes durchführen:
  • zumindest teilweise basierend auf dem Bestimmen, dass die erste Rolle die zweite Rolle übernehmen kann, Erzeugen einer Benachrichtigung über einen Sicherheitsbefund in Bezug auf eine Zugriffssteuerungsrichtlinienkonfiguration.

The foregoing can be better understood with reference to the following sentences:

• Set 1. System, comprising:
  • an access control analysis unit comprising one or more processors and one or more memories for storing computer-executable instructions that, when executed, cause the one or more processors to:
    • determining a graph comprising a plurality of nodes and one or more directed edges, the nodes representing a plurality of roles in a provider network hosting a plurality of services and resources, the nodes including a first node representing a first role , and a second node representing a second role, wherein the roles are associated with a plurality of access control policies that grant or deny access to individual ones of the plurality of services and resources, and wherein one or more of the access control policies at least partially grant access grant or deny based on one or more key-value tags; and
    • Determining, based at least in part on a role reachability analysis of the graph, whether the first role can assume the second role using one or more role assumption steps for a particular state of the one or more key-value tags, a single one of the role assumption steps having temporary access during a role session and wherein the one or more key-value tags comprise one or more transitive tags that persist during the one or more role assumption steps.
• Clause 2. The system of Clause 1, wherein the access control policies allow the first role to assume the second role if the first role provides a session tag that matches a condition associated with the second role.
• Clause 3. The system of Clause 2, wherein the condition associated with the second role comprises one or more placeholders for a value of a key.
• Theorem 4. The system of any of theorems 1-2, wherein the graph is determined by determining one or more neighbors for a particular node in the graph based at least in part on a set of the key-value tags whose keys are explicitly specified with appropriate conditions in specified in the access control policies, or by under-specified key-value tags whose values are unrestricted or partially restricted.
• Set 5. Method comprising:
  • Determining, by an access control analysis unit, a graph comprising a plurality of nodes and one or more edges, the nodes representing a plurality of roles in a provider network hosting a plurality of resources, the nodes including a first node having a first Role represents, and a second node representing a second role, wherein the roles are associated with a plurality of access control policies that grant or deny access to individual ones of the plurality of resources, and wherein one or more of access control policies grant or deny access based at least in part on one or more attributes; and
  • Determine, by the access control analysis unit based at least in part on a role reachability analysis of the graph, whether the first role can assume the second role using one or more role assumption steps for a specific state of the one or more attributes, and wherein the one or more attributes one or include multiple transitive attributes that persist during the one or more role assumption steps.
• Clause 6. The method of Clause 5, wherein the access control policies allow the first role to assume the second role if the first role provides a session attribute that matches a condition associated with the second role.
• Set 7. The method of set 6, wherein the condition associated with the second role includes one or more placeholders for a value of a key.
• Clause 8. The method of any one of clauses 5-7, further comprising:
  • Aggregating one or more constraints on the one or more attributes, the one or more constraints being specified by one or more of the access control policies associated with the one or more role assumption steps.
• Theorem 9. The method of any of theorems 5-8, wherein one or more neighbors for a particular node in the graph are determined based at least in part on a set of the attributes whose keys are explicitly specified with corresponding conditions in the access control policies.
• Theorem 10. The method of any of theorems 5-9, wherein one or more neighbors for a particular node in the graph are determined based at least in part on under-specified attributes whose values are unconstrained or partially constrained.
• Clause 11. The method of any of Clauses 5-10, wherein the first role is in a first account with the provider network and wherein the second role is in a second account with the provider network.
• Clause 12. The method of any one of Clauses 5-11, further comprising:
  • based at least in part on determining that the first role can assume the second role, generating a notification of a security finding related to a configuration of the access control policies.
• Clause 13. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or through one or more processors, perform the following:
  • Determining, by an access control analysis unit, a graph comprising a plurality of nodes and one or more edges, the nodes representing a plurality of roles in a provider network hosting a plurality of services or resources, the nodes including a first node that representing a first role, and a second node representing a second role, wherein the roles are associated with a plurality of access control policies that grant or deny access to ones of the plurality of services or resources, and wherein one or more of the access control policies grant or deny access based at least in part on one or more tags; and
  • Determine, by the access control analysis unit based at least in part on a role reachability analysis of the graph, whether the first role can assume the second role using one or more role assumption steps for a specific state of the one or more tags, and wherein the one or more tags one or include multiple transitive tags that persist throughout the one or more role assumption steps.
• Clause 14. One or more non-transitory computer-readable storage media according to Clause 13, wherein the access control policies allow the first role to assume the second role if the first role provides a session tag that matches a condition associated with the second role .
• Clause 15. One or more non-transitory computer-readable storage media according to Clause 14, wherein the condition associated with the second role does not include one or more placeholders for a value for a key.
• Clause 16. One or more non-transitory computer-readable storage media according to any one of Clauses 13-15, further comprising additional program instructions that, when executed on or through the one or more processors, perform the following:
  • Aggregating one or more constraints on the one or more attributes, the one or more constraints being specified by one or more of the access control policies associated with the one or more role assumption steps.
• Clause 17. One or more non-transitory computer-readable storage media according to any of clauses 13-16, wherein the graph is determined based at least in part on one or more of the tags having keys explicitly stated in the access control policies.
• Clause 18. One or more non-transitory computer-readable storage media according to any of clauses 13-17, wherein the graph is determined based at least in part on the application of one or more constraints to the one or more tags, the one or more constraints being governed by one or specifying a plurality of the access control policies associated with the one or more role assumption steps.
• Clause 19. One or more non-transitory computer-readable storage media according to any one of Clauses 13-18, further comprising additional program instructions that, when executed on or through the one or more processors, perform the following:
  • monitoring calls to the plurality of services on the provider network; and if the calls are determined to change a state of the provider network, restarting the role reachability analysis.
• Clause 20. One or more non-transitory computer-readable storage media according to any of clauses 13-19, wherein the graph is determined using a policy comparison service that determines a semantic difference between two of the access control policies.
• Set 21. System comprising:
  • an access control analysis unit comprising one or more processors and one or more memories for storing computer-executable instructions that, when executed, cause the one or more processors to:
    • determining a first node in a graph, the first node corresponding to a first role in a provider network hosting a plurality of services and resources, the first role being associated with a first access control policy, and the first access control policy permitting access to a first to grant or deny services and resources;
    • determining a second node in the graph, the second node corresponding to a second role in the provider network, the second role associated with a second access control policy, and the second access control policy granting access to a second one of the services and resources or denied;
    • performing a role reachability analysis that determines whether the first role can assume the second role for a specific state of one or more key-value tags, the one or more role assumption steps providing temporary access during a role session, the role reachability analysis determining a third access control policy that authorizes an addition to a role assumption request for the second role, wherein the role reachability analysis determines whether the first role can assume the second role based at least in part on an analysis of the third access control policy with respect to a role assumption policy for the second role for the particular state of the one or more key-value tags, and wherein the role assumption request is unauthorized if the third access control policy does not include the role assumption policy for the second role for the particular state of the one or more key-value tags; and
    • Based at least in part on the role reachability analysis, granting or denying access to the second one(s) of the services and resources for a principal in the first role.
• Clause 22. The system of clause 21, wherein the role assumption policy for the second role is extended to include one or more instructions that reject requests that fail to meet one or more conditions of the role assumption policy for the second role.
• Clause 23. The system of any of clauses 21-22, wherein one or more conditions of the role assumption policy for the second role includes one or more placeholders for the one or more key-value tags.
• Clause 24. The system of Clause 23, wherein the role reachability analysis selects one or more representative values for the one or more key-value tags from a range of potential values for the one or more key-value tags, the range of potential values based at least in part on the one or more placeholders and wherein the particular state of the one or more key-value tags is determined based at least in part on the one or more representative values for the one or more key-value tags.
• Set 25. A method comprising:
  • Determining, by an access control analysis unit, a first node in a graph, the first node corresponding to a first role in a provider network hosting a plurality of resources, the first role being associated with a first access control policy, and the first access control policy permitting access to a or multiple first of resources granted or denied;
  • determining, by the access control analysis unit, a second node in the graph, wherein the second node corresponds to a second role in the provider network, wherein the second role is associated with a second access control policy and wherein the second access control policy grants access to one or more second ones of the resources or refused;
  • performing, by the access control analysis unit, a role reachability analysis that determines whether the first role can assume the second role for a specific state of one or more attributes, the role reachability analysis comprising:
    • determining a third access control policy authorizing negation of a role assumption request for the second role; and
    • determining whether the first role can assume the second role based at least in part on analyzing the third access control policy with respect to a role assumption policy for the second role for the particular state of the one or more attributes.
• Clause 26. Method according to Clause 25, further comprising:
  • Based at least in part on the role availability analysis, granting or denying access to the second of the resources for a principal in the first role.
• Clause 27. The method of any of clauses 25-26, wherein the role assumption policy for the second role is extended to include one or more instructions that reject requests that fail to meet one or more conditions of the role assumption policy for the second role.
• Clause 28. The method of any of clauses 25-27, wherein the role inheritance request is not authorized if the third access control policy does not include the inheritance policy for the second role for the particular state of the one or more attributes.
• Clause 29. The method of any of clauses 25-28, wherein the role reachability analysis invokes a policy comparison service that determines an equivalence score for the third access control policy and the role inheritance policy for the second role for the particular state of the one or more attributes.
• Clause 30. The method of any of clauses 25-29, wherein one or more conditions of the role assumption policy for the second role includes one or more placeholders for the one or more attributes.
• Clause 31. The method of Clause 30, wherein performing the role reachability analysis further comprises:
  • selecting one or more representative values for the one or more attributes from a range of potential values for the one or more attributes, wherein the range of potential values is determined based at least in part on the one or more placeholders and wherein the particular state of the one or the plurality of attributes is determined based at least in part on the one or more representative values for the one or more attributes.
• Clause 32. The method of any one of clauses 25-31, further comprising:
  • based at least in part on determining that the first role can assume the second role, generating a notification of a security finding related to an access control policy configuration.
• Clause 33. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or through one or more processors, perform the following:
  • Determining, by an access control analysis unit, a first node in a graph, the first node corresponding to a first role in a provider network that hosts a plurality of services or resources, the first role being associated with a first access control policy, and the first access control policy controlling access granted or denied to one or more of the first of the Services or Resources;
  • determining, by the access control analysis unit, a second node in the graph, the second node corresponding to a second role in the provider network, the second role being associated with a second access control policy, and the second access control policy permitting access to one or more second of the grant or deny services or resources; and
  • performing, by the access control analysis entity, a role reachability analysis that determines whether the first role can assume the second role for a specific state of one or more tags, the role reachability analysis comprising:
    • determining a third access control policy that authorizes an addition to a role assumption request for the second role; and
    • determining whether the first role can assume the second role based at least in part on analyzing the third access control policy with respect to a role assumption policy for the second role for the particular state of the one or more tags.
• Clause 34. One or more non-transitory computer-readable storage media according to Clause 33, further comprising additional program instructions that, when executed on or through the one or more processors, perform the following:
  • Based at least in part on the role reachability analysis, granting or denying access to the second one or more services or resources for a user in the first role.
• Clause 35. One or more non-transitory computer-readable storage media according to any one of clauses 33-34, wherein the role assumption policy for the second role is extended to include one or more instructions denying requests that meet one or more conditions of the role assumption policy for the second not fulfilling the role.
• Clause 36. One or more non-transitory computer-readable storage media according to any one of Clauses 33-35, wherein the role assumption request is not authorized if the third access control policy does not include the role assumption policy for the second role for the particular state of the one or more tags.
• Clause 37. One or more non-transitory computer-readable storage media according to any one of Clauses 33-36, wherein the role reachability analysis invokes a policy comparison service that determines an equivalence result for the third access control policy and the role assumption policy for the second role for the particular state of the one or more tags.
• Clause 38. One or more non-transitory computer-readable storage media according to any of clauses 33-37, wherein one or more conditions of the role assumption policy for the second role includes one or more placeholders for the one or more tags.
• Clause 39. One or more non-transitory computer-readable storage media according to Clause 38, further comprising additional program instructions that, when executed on or through the one or more processors, perform the following:
  • selecting one or more representative values for the one or more tags from a range of potential values for the one or more tags, wherein the range of potential values is determined based at least in part on the one or more placeholders, and wherein the particular state of the one or more tags is determined based at least in part on the one or more representative values for the one or more tags.
• Clause 40. One or more non-transitory computer-readable storage media according to any one of Clauses 33-39, further comprising additional program instructions that, when executed on or through the one or more processors, perform the following:
  • based at least in part on determining that the first role can assume the second role, generating a notification of a security finding related to an access control policy configuration.

Claims (15)

System comprising: an access control analysis unit comprising one or more processors and one or more memories for storing computer-executable instructions that, when executed, cause the one or more processors to: determining a graph comprising a plurality of nodes and one or more directed edges, the nodes representing a plurality of roles in a provider network hosting a plurality of services and resources, the nodes including a first node representing a first role , and a second node representing a second role, wherein the roles are associated with a plurality of access control policies that grant or deny access to individual ones of the plurality of services and resources, and wherein one or more of the access control policies at least partially grant access grant or deny based on one or more key-value tags; and Determining, based at least in part on a role reachability analysis of the graph, whether the first role can assume the second role using one or more role assumption steps for a particular state of the one or more key-value tags, a single one of the role assumption steps having temporary access during a role session and wherein the one or more key-value tags comprise one or more transitive tags that persist during the one or more role assumption steps. system after claim 1 , wherein the access control policies allow the first role to assume the second role if the first role provides a session tag that matches a condition associated with the second role. system after claim 2 , where the condition associated with the second role comprises one or more placeholders for a value of a key. system according to one of the Claims 1 - 3 , wherein the graph is determined by determining one or more neighbors for a particular node in the graph based at least in part on a set of key-value tags whose keys are explicitly specified with appropriate conditions in the access control policies, or by under-specified key-value tags , whose values are unrestricted or partially restricted. Method comprising: Determining, by an access control analysis unit, a graph comprising a plurality of nodes and one or more edges, the nodes representing a plurality of roles in a provider network hosting a plurality of resources, the nodes including a first node having a first Role represents, and a second node, which represents a second role, comprise, wherein the roles are assigned to a plurality of access control policies that grant or deny access to individual ones of the plurality of resources, and wherein one or more of the access control policies at least partially allow access grant or deny based on one or more attributes; and Determine, by the access control analysis unit based at least in part on a role reachability analysis of the graph, whether the first role can assume the second role using one or more role assumption steps for a specific state of the one or more attributes, and wherein the one or more attributes one or include multiple transitive attributes that persist during the one or more role assumption steps. procedure after claim 5 , wherein the access control policies allow the first role to assume the second role if the first role provides a session attribute that matches a condition associated with the second role. procedure after claim 6 , where the condition associated with the second role comprises one or more placeholders for a value of a key. Procedure according to one of Claims 5 - 7 , further comprising: aggregating one or more constraints on the one or more attributes, the one or more constraints being specified by one or more of the access control policies associated with the one or more role assumption steps. Procedure according to one of Claims 5 - 8th , wherein one or more neighbors for a particular node in the graph are determined based at least in part on a set of attributes whose keys are explicitly specified with corresponding conditions in the access control policies. Procedure according to one of Claims 5 - 9 , wherein one or more neighbors for a particular node in the graph are determined based at least in part on under-specified attributes whose values are unconstrained or partially constrained. Procedure according to one of Claims 5 - 10 wherein the first role is in a first account with the provider network and wherein the second role is in a second account with the provider network. Procedure according to one of Claims 5 - 11 , further comprising: based at least in part on determining that the first role can assume the second role, generating a notification of a security finding related to a configuration of the access control policies. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or through one or more processors, perform the following: Determining, by an access control analysis unit, a graph comprising a plurality of nodes and one or more edges, the nodes representing a plurality of roles in a provider network hosting a plurality of services or resources, the nodes including a first node that representing a first role, and a second node representing a second role, wherein the roles are associated with a plurality of access control policies that grant or deny access to ones of the plurality of services or resources, and wherein one or more of the access control policies grant or deny access based at least in part on one or more tags; and Determine, by the access control analysis unit based at least in part on a role reachability analysis of the graph, whether the first role can assume the second role using one or more role assumption steps for a specific state of the one or more tags, and wherein the one or more tags one or include multiple transitive tags that persist throughout the one or more role assumption steps. One or more non-transitory computer-readable storage media Claim 13 , further comprising additional program instructions that, when executed on or through the one or more processors, perform the following: monitor calls to the plurality of services in the provider network; and if the calls are determined to change a state of the provider network, restarting the role reachability analysis. One or more non-transitory computer-readable storage media Claim 13 or Claim 14 , wherein the graph is determined using a policy comparison service that determines a semantic difference between two of the access control policies.

Images