CN116601621A - Role reachability analysis with transitive labels - Google Patents

Abstract

Methods, systems, and computer readable media for role reachability analysis using transitive labels are disclosed. The access control analyzer determines a graph comprising a plurality of nodes and one or more edges. The node represents a role in the provider network hosting the resource. 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 based, at least in part, on one or more key-value attributes. The access control analyzer determines whether a particular state first persona for the one or more properties can act as a second persona using one or more personas based, at least in part, on a persona reachability analysis of the graph. The one or more attributes may include one or more transitive attributes that persist during the one or more roles functioning as steps.

Description

Role reachability analysis with transitive labels

Background

Many companies and other organizations operate computer networks that interconnect multiple computing systems to support their operations, such as where the computing systems are co-located (e.g., as part of a local network) or alternatively located in multiple different geographic locations (e.g., connected by one or more private or public intermediary networks). For example, distributed systems that accommodate a large number of interconnected computing systems have become inadequate. Such distributed systems may provide backend services to servers that interact with clients. Such distributed systems may also include data centers operated by entities to provide computing resources to clients. Some data center operators provide network access, power, and secure installation facilities for hardware owned by various customers, while other data center operators provide "full service" facilities that also include hardware resources available to their customers. As the size and scope of distributed systems increases, the task of provisioning, implementing, and managing resources has become increasingly complex.

The distributed system may provide remote clients with access to various services that are implemented primarily within the distributed system and are accessible over a network, such as the internet. Examples of such systems include online merchants, internet service providers, corporate networks, cloud computing services, web-based hosted services, and the like. The distributed system may use the appropriate rights to place a high emphasis on the security of the user's access to the system resources. Resource owners and resource administrators typically use such access control policies to control user access to computing resources in order to support the requirements of the resource owners, administrators, and users. Defining and maintaining user roles, rights or policies can become increasingly complex, particularly as the size and/or complexity of the system or the number of computer system users increases.

Drawings

FIG. 1 illustrates an exemplary system environment for role reachability analysis with transitive labels, in accordance with some embodiments.

FIG. 2 illustrates an example of a rights scheme that may be used for role reachability analysis with transitive labels, in accordance with some embodiments.

Fig. 3 illustrates an example of a role reachability graph that may be used for role reachability analysis with transitive labels, in accordance with some embodiments.

Fig. 4 illustrates an example of role-playing steps with a transitive label, in accordance with some embodiments.

Fig. 5 is a flow chart illustrating a method for role reachability analysis using a transitive label, in accordance with some embodiments.

Fig. 6 is a flow chart illustrating other aspects of a method for role reachability analysis using a transitive label, in accordance with some embodiments.

Fig. 7 is a flow diagram illustrating a method for role reachability analysis using policy complementary sets, in accordance with some embodiments.

FIG. 8 illustrates other aspects of an exemplary system environment for role reachability analysis with transitive labels, including equivalence results generated in response to a request to analyze the equivalence of two security policies, in accordance with some embodiments.

FIG. 9 illustrates an exemplary computing device that may be used in some embodiments.

Although embodiments are described herein by way of example for several implementations and illustrative drawings, those skilled in the art will recognize that the implementations are not limited to the described implementations or drawings. It should be understood that the drawings and detailed description thereto are not intended to limit the embodiment to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this disclosure, the word "may" is used in a permissive sense (i.e., meaning "having the potential to"), rather than the mandatory sense (i.e., meaning "must"). Similarly, the word "include" means "including but not limited to".

Detailed Description

Various embodiments of methods, systems, and computer-readable media for role reachability analysis using transitive labels are described. The software product (e.g., a service or application) may execute in a distributed system, a service-oriented system, or a cloud provider network that includes various resources and other services. To allow or deny access to such resources and services, the distributed system may provide an integrated technique for enforcing access control policies using authentication and authorization. Using existing methods of access control policy management, delegated role-based management and attribute-level tag-based management are used to control access to resources in a distributed system. In some approaches, role-based management has been combined with tag-based management. For example, the cloud provider network may support transitive or "sticky" session tags that allow users to maintain constraints on the tags along the role play chain. In some cases, policy configuration may result in unexpected privilege upgrades in the presence of subtle transitive tag behavior with potentially overlapping string constraints. In such a system, it may be desirable to determine whether a particular user or character may gain access to a particular character in the chain that the character plays given a particular transitive tag state.

The foregoing challenges, as well as others, are addressed by embodiments of the technology described herein whereby automated techniques may be used to perform symbolic automated inference analysis of character reachability with respect to an access control system. In particular, the access control analyzer may perform a role reachability analysis to determine whether a particular user or role may gain access to another particular role in a particular transitive or "sticky" tag state, possibly through one or more role-acting steps. Role reachability analysis may use a graph with nodes representing roles and edges representing roles acting as transformations. Roles are conditioned on the key-value properties (labels) of the role session, including transitive labels. The transitive labels (or "sticky" labels) may represent key-value properties that persist during the role of the different roles. In some cases, the state of the tag may change during role play. For each node, the analyzer may determine the likely neighbors of each node by: observing whether the current transitive tag state can only be extended by a set of tags whose keys are explicitly mentioned and whose associated conditions are therefore known or under-specified tags whose values are unrestricted or partially restricted. The analyzer may aggregate one or more boundary conditions of one or more tags as indicated by an access control policy associated with the role-playing step. Based (at least in part) on performing role reachability analysis using such graphs, the access control analyzer may identify potentially unexpected configurations in the distributed system.

Nodes corresponding to the first and second roles may be adjacent or contiguous in the graph such that assuming the second role from the first role may include only one role assuming step. In determining whether the first persona may act as the second persona, the persona reachability analysis may determine an access control policy that authorizes the second persona to act as a complement to the persona request. For example, such a policy may allow all actions except taking on the second role. The new access control policy may represent a negation of the role request and may be referred to as a negation policy. Role reachability analysis may analyze negative policies that authorize acting as a complement to role requests relative to one or more other access control policies. In some embodiments, the negative policy may be compared to the role play policy of the second role for a particular state of the tag. Analysis of policies may be performed using a policy comparison service that determines whether one access control policy is more tolerant, less tolerant, equally tolerant, or incomparable relative to another access control policy. Because the space of the string of labels may be unbounded (e.g., due to wildcards), the role reachability analysis may select one or more representative values of one or more key-value labels from a range of potential values (equivalence classes) of the labels. The state of the tag may be determined based, at least in part, on the representative value. In some embodiments, negating the policy may include the role of the second role acting as a policy if and only if there is no context under which the role of the second role is authorized. In some embodiments, the role of the first role in the second role may be authorized if and only if the negative policy does not include the role of the second role in the policy.

As will be appreciated by one of skill in the art in view of this disclosure, embodiments may be able to achieve certain technical advantages, including some or all of the following: (1) Improving security of a distributed system by automatically determining whether one character for access control can gain access to another character through role play in a transitive tag state; (2) Increasing security of the distributed system by automatically notifying an associated user or account when an access control policy is found to have a likelihood of unexpected privilege elevation; etc.

FIG. 1 illustrates an exemplary system environment for role reachability analysis with transitive labels, in accordance with some embodiments. In various embodiments, the access control analyzer 100 may use automation techniques to analyze aspects of the access control policies 165 and their related roles and draw conclusions about how the roles relate to other roles. Access control analyzer 100 may 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 may be used to grant or deny access to services and resources 170. For example, policy manager 160 may be used to approve or reject access request 155 from an entity called 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 principals and policies are discussed in more detail with reference to fig. 2.

Access control in provider network 190 may be implemented using concepts of an account for identity authentication, a user within an account, and a federation of accounts from third party identity providers. Access control in provider network 190 may be implemented using concepts of roles, role roles, and generic policy language that specifies which resources and services these identities may access, for example, using policies 165, and under which conditions. Roles may represent identities with associated rights policies that specify what a role may do and what may not. In some embodiments, instead of being uniquely associated with a person, a persona may be performable by a principal such as a user, other persona, service, or resource (e.g., computing instance). These users may be associated with the same account, different accounts, services, or external identities authenticated by a supported identity provider (e.g., an enterprise directory or security assertion markup language [ SAML ] provider). When functioning as a role, the role functioning may provide temporary security credentials for the role session to allow only enough access to perform the required work, rather than providing long-term credentials such as passwords or access keys.

The access control policies 165 and their corresponding roles may be used within a distributed system where services and resources 170 are potentially accessible through access requests according to the access control policies. For example, the distributed system may represent a multi-tenant provider network 190. Resources accessible through the access control policy 165 may include computing instances, storage resources, database resources, networking resources, and the like. Services accessible through the access control policy 165 may include software products that perform various tasks in response to requests from clients (including other services). In some embodiments, a service may provide access to a resource. For example, provider network 190 may provide virtual computing services that provision computing instances from a pool of available resources and then allow clients to operate on those instances. As another example, provider network 190 may provide a cloud-based storage service that reserves storage resources from a pool 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 to perform actions.

In one embodiment, access control policy manager 160 associated with provider network 190 may manage access control policies 165 that specify which users may access which services and resources and in which circumstances those users may access services and resources 170. Access control policy 165 may include or determine rights 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 in order for the user to perform one or more actions while ensuring the security of the service or resource. To manage user privileges, a service or resource owner may delegate rights to access a given service or resource in a number of different ways to allow different levels of access to the resource according to a resource access policy. Principals 150 (or a group of principals) that are authorized by delegating rights to access a given service or resource may be referred to herein as authorized delegates. The access control policy may be attached to a role managed by policy manager 160 or another identity and access management service. A role may be associated with one or more users or groups of users. For example, a role may be used by a service or application during its execution in provider network 190. In some embodiments, the access control policy may adhere to a minimum privilege principle. A given policy may allow access to one set of services and resources 170 but not allow access to another set of services and resources 170.

To get out about the structureConclusion of security posture for systems built to execute in provider network 190 or other distributed environments, access control analyzer 100 may use automation techniques to answer role reachability questions. The access control analyzer 100 may determine what the principal can do through the transitive closure of the role play step. For example, access control analyzer 100 may determine account a ₁ Role r in (a) ₁ Whether or not to be able to function as an account a ₃ Role r in (a) ₃ Account a of (2) ₂ Role r in (a) ₂ . In some cases, role r ₃ Can have the pair a ₁ Rights to sensitive resources that are not intended to be accessed for security, privacy, or compliance reasons. In provider network 190, these resources may include storage resources, devices such as satellite base stations or microprocessors, or write access to policies governing access to roles themselves. Access control analyzer 100 may perform role reachability analysis 120 based, at least in part, on role reachability graph 110.

In some embodiments, the access control analyzer 100 may include a user interface 130. The user interface 130 may allow a user to request that the role reachability analysis 120 be performed, for example, for a particular role or account or for a group of roles or accounts. The user interface 130 may present aspects of the analysis 120 to the user, such as indications of which roles may play which other roles and/or other analysis results. In some embodiments, the user interface 130 may be used to generate notifications regarding the output of the analysis 120. For example, the analyzer 100 may send a notification to an administrator or security team of any security findings (e.g., findings of unexpected privilege elevations) discovered using the role reachability analysis 120. In some embodiments, access control analyzer 100 may be implemented as a service and may include one or more service interfaces through which the analyzer may interact with other services, such as service 170 and/or a policy comparison service. In various embodiments, analyzer 100 may be implemented within provider network 190 or external to the provider network.

The access control analyzer 100 may perform analysis 120 of role reachability based on a transitive or "sticky" session ticket. The labels may represent key-value properties provided during role play. The tag may include an alphanumeric descriptor attached to the body. Policies may restrict these tags to perform attribute-based access control in conjunction with delegated role-based management, e.g., to apply authorization policies that define permissions based on tag attributes. For example, if an organization uses SAML-based identity providers, the organization may configure its assertions to provide session tags to the cloud provider network. When employees join into provider network 190, their attributes such as first name, lastName, or Email may be attached to the associated principals in the provider network, and policies may grant or deny access based on these attributes. Session tags may be transferred during the role play step. Session tags may optionally be set to be transitive or "sticky" such that they persist during subsequent role play steps to propagate constraints across role plays. When the session tag is set to transitive, it can become a subject tag associated with the session corresponding to the role played.

The role reachability analysis 120 may use a role reachability graph 110 having nodes representing roles and edges representing roles acting as transformations. The graph 110 may be a directed graph (where edges have directions), but is not necessarily a directed acyclic graph. Role play is conditioned on key-value properties (labels) of the role session, including transitive labels that persist during play of different roles. In some cases, the state of the tag may change during role play. For example, the role-specific role can result in tagging for the principal, and thus, the role-specific path taken by the chain can result in a different tag state than another path to the same node in graph 110. Roles are conditioned on labels that can match wild cards of values of key-value attributes. Based (at least in part) on the presence of such wild cards, the set of potential tag values associated with the role-playing step may be unbounded and/or infinite. In some embodiments, for each node, analyzer 100 may determine the likely neighbors of each node by: observing whether the current transitive tag state can only be extended by a set of tags whose keys are explicitly mentioned and whose associated conditions are therefore known or under-specified tags whose values are unrestricted or partially restricted. The analyzer 100 can aggregate one or more boundary conditions (e.g., upper and/or lower bounds) of one or more tags, as indicated by the access control policy 165 associated with the role-playing step. Based (at least in part) on performing role reachability analysis 120 using graph 110, access control analyzer 100 may identify potentially unexpected configurations. The analyzer 100 may present security findings describing the configuration.

In some embodiments, the access control analyzer 100 may use the policy comparison service 180 in the provider network 190 to find semantic level differences (if any) between two access control policies. For example, policy comparison service 180 may determine whether one policy is less tolerant or equally tolerant than another policy. For example, policy comparison service 180 may be used to determine whether an executable role plays a step. Policy comparison service 180 may determine conditions for performing the role steps. The use of policy comparison service 180 is discussed in more detail below.

The access control analyzer 100 may be implemented using any suitable number and configuration of computing devices, any of which may be implemented by the exemplary computing device 900 shown in fig. 9. The computing devices may be located in any suitable number of data centers or geographic locations. In various embodiments, at least a portion of the functionality of access control analyzer 100 may be provided by the same computing device or different computing devices. If any of the components of access control analyzer 100 are implemented using different computing devices, these components and their respective computing devices may be communicatively coupled, for example, through one or more networks. Each component of access control analyzer 100 may represent any combination of software and hardware that may be used to perform its respective functions, as discussed below. The operations implemented by the access control analyzer 100 may be performed automatically, e.g., without user initiation or without user intervention after an initial configuration phase, and programmatically, e.g., by executing program instructions on at least one computing device. It is contemplated that access control analyzer 100 may include additional components not shown, fewer components than shown, or a different combination, configuration, or number of components shown.

Various components such as access control analyzer 100, policy manager 160, services and resources 170, and/or policy comparison service 180 may be implemented in a service-oriented system in which multiple services cooperate to perform complex tasks according to a service-oriented architecture. A service, such as one of services 170, may be implemented using a plurality of different instances distributed throughout one or more networks, and each instance may provide various clients with access to the functionality of the corresponding service. In such an environment, the access control analyzer 100 may provide its functionality as a service to a plurality of clients. It is contemplated that any suitable number and configuration of clients may interact with access control analyzer 100. To enable clients to invoke their functionality, access control analyzer 100 may expose any suitable interface, such as one or more APIs or other programming interfaces, a Command Line Interface (CLI), and/or a Graphical User Interface (GUI), for example, user interface 130. In one embodiment, the functionality of the access control analyzer 100 may be provided to the client in exchange for a fee.

The components shown in fig. 1 may communicate network-based service requests and other data to each other over one or more networks. In various embodiments, the network may encompass any suitable combination of networking hardware and protocols necessary to establish network-based communications between, for example, components in the provider network 190 and the access control analyzer 100. For example, the network may typically encompass a variety of telecommunications networks and service providers that collectively implement the internet. The network may also include private networks such as a Local Area Network (LAN) or a Wide Area Network (WAN), as well as public or private wireless networks. In some embodiments, any of the components shown in fig. 1 may be provisioned separately within an enterprise having its own internal network. In such an embodiment, the network may include hardware (e.g., modems, routers, switches, load balancers, proxy servers, etc.) and software (e.g., protocol stacks, accounting software, firewall/security software, etc.) necessary to establish a networking link between one component and the internet and between the internet and another component. It should be noted that in some embodiments, the components may communicate using a private network instead of the public internet.

In one embodiment, services and resources 170 may be implemented using resources of provider network 190. In some embodiments, aspects of access control analyzer 100, policy manager 160, and/or policy comparison service 180 may also be implemented using resources of provider network 190. Provider network 190 may represent a network established by an entity, such as a business entity or public sector organization, to provide one or more services (such as various types of network-accessible computing or storage) to a set of distributed clients, accessible via the internet and/or other networks. Provider network 190 may include numerous data centers hosting various resource pools, such as a collection of physical and/or virtualized computer servers, storage devices, networking equipment, etc., for implementing and distributing the infrastructure and services provided by the provider. In some embodiments, computing resources may be referred to as "instances" such as units of virtual or physical computing instances to be provided to clients. Virtual compute instances may include, for example, one or more servers with specified compute capabilities (which may be specified by indicating the type and number of CPUs, main memory size, etc.) and specified software stacks (e.g., a particular version of an operating system, which in turn may run on top of a hypervisor). In different embodiments, the resources of the provider network may be implemented using a variety of different types of computing devices, including computer servers, storage devices, network devices, etc., singly or in combination. Because the resources of the provider network 190 may be under the control of multiple clients (or tenants) simultaneously or continuously, the provider network may be said to provide multi-tenants and may be referred to as a multi-tenant provider network. Provider network 190 may be hosted in a "cloud" and may be referred to as a cloud provider network or a cloud-based provider network.

In some embodiments, an operator of provider network 190 may implement a flexible set of resource reservation, control, and access interfaces for its clients. For example, the resource manager may implement a programmed resource reservation interface (e.g., through a website or set of web pages) that allows clients (potentially including other components within provider network 190) to learn, select, purchase access to, and/or reserve computing instances provided by provider network 190. Such interfaces may include the ability to allow browsing of resource directories and provide detailed information and specifications of supported different types or sizes of resources, supported different reservation types or modes, pricing models, etc.

FIG. 2 illustrates an example of a rights scheme that may be used for role reachability analysis with transitive labels, in accordance with some embodiments. Principal 150 can have a set of valid rights 220, which can be an aggregate of rights granted by one or more policies associated with the principal's access to resources. The set of valid rights 220 may specify a number of rights that specify which resources are accessible to the principal 150, which resources are inaccessible to the principal 150, and under which conditions access to those resources may be allowed (or granted) or denied. For example, the set of valid rights 220 may include one or more rights associated with the principal 150, as well as one or more rights from different sources such as, for example, a group policy, a delegation policy, a role the principal plays, an organization policy, or a default policy. For policies, the valid rights for the policies may be those rights that the policies explicitly or implicitly define. For example, a policy may explicitly grant a principal a set of permissions to perform a set of operations in conjunction with a resource. As another example, a policy may implicitly grant rights to a principal by granting rights to a group of which the principal is a member. The effective rights of policies may change over time. For example, a policy may be a role policy, and a principal that is able to take on a role may change over time, although the policy remains unchanged. Thus, the valid rights may change as the principal authorized to play the role changes. In other words, a valid right is an access right of a principal to perform an action on a resource. Policies may grant valid rights explicitly (e.g., by specifying principals, actions, and resources) and/or implicitly (e.g., by specifying rights in a manner that explicitly leaves one or more of principals, operations, or resources unspecified).

In one embodiment, when the default policy is to deny access to resources, the permissions may specify which resources are allowed. In one embodiment, when the default policy is to allow access to a resource, the permissions may specify access to the resource that is not explicitly denied. In one embodiment, in the case of some other default policy, the permissions may specify a combination of allowed and denied resource access. In some embodiments, the set of valid rights 220 may be an aggregate of rights to a particular resource and/or resource category. In some embodiments, the set of valid rights 220 may be an aggregation of rights to multiple resources (e.g., an aggregation of rights associated with all resources managed by the user's service, an aggregation of rights associated with the user account, or some other aggregation of rights).

The set of valid rights 220 may specify a combination or aggregate of rights based on aspects of the principal. For example, if principal 150 is a user, the set of valid rights 220 may specify one or more user policy rights 214. User policy rights 214 may include rights associated with the type of principal 150 (i.e., "user," "group," or "organization"), and may also include rights associated with a particular set of credentials associated with the identity of principal 150.

In addition to permissions related to the class and/or identity of principal 150, the set of valid permissions 220 may specify one or more delegation policy permissions 212 as a result of principal 150 acting as 204 on one or more roles 206 specified within the organization. For example, principal 150 can be a software developer and can assume 204 a software developer role in his or her daily activities and can become an authorized delegate of the set of rights associated with assuming the software developer role. The software developer role may specify a set of delegation policy rights 212 that are included in the set of valid rights 220 associated with the principal 150. There may be some overlap in user policy rights 214 and delegation policy rights 212 (e.g., "rights B"). A conflict may also exist between user policy rights 214 and delegation policy rights 212. For example, "rights A" in delegation policy rights 212 may always grant access to resources, while "rights C" in user policy rights 214 may deny such access. In the case of such conflicts, the default policy and/or default policy conflict resolution criteria may be in control (i.e., either preferentially denied or preferentially granted).

Similarly, since principal 150 is a member 208 of one or more groups 210 (e.g., production groups), the set of valid rights 220 may specify one or more group policy rights 218. The set of valid rights 220 may also specify one or more other policy rights 216, such as those associated with a default policy, an organization policy, policies associated with certain applications, policies associated with enhanced security conditions, temporary policies, or other such policies.

The principal 150 can also assume multiple roles and thus assume multiple sets of role policy rights. For example, a principal 150 that plays a role of a software developer in his or her daily activities may require more rights at some point during his or her day, such as those rights that may be associated with a system administrator role. In such an example, the principal may temporarily assume a system administrator role, perform one or more privileged operations granted by the role, and then may release the role, returning his or her policy to a set of lower-privileged rights. As may be expected, these types of roles and associated permissions described in association with those roles are illustrative examples, and other types of roles and associated locations may be considered within the scope of the present disclosure.

Rights associated with this set of valid rights 220 may be altered for principal 150 by adding rights and/or removing rights from delegated policy rights 212, from user policy rights 214, from group policy rights 218, from other policy rights 216, or from other such rights groups (e.g., as a result of API calls to policy management service 160). For example, removing "rights E" from the set of valid rights 220 may be accomplished by removing the rights from the group policy rights 218. Such removal may also remove the rights from any other principal that is a member of the group, which may or may not be a desired effect. Redundant rights can be removed from the policy. For example, a user having user policy rights 214 and having delegation policy rights 212 has "rights B" granted by both policies, and thus "rights B" may be removed from delegation policy rights 212 or user policy rights 214 without altering rights in the set of valid rights 220. In both examples, other policy modification actions may also achieve the same results (e.g., alter group membership and/or role assignments, as described herein).

For example, principal 150 may be removed from the group (rather than altering the permissions of the group), and because in the example shown in FIG. 2, "permission A" and "permission D" are granted by other policy permissions, the result will be that "permission E" is removed from the principal without altering the permissions of the other principal. Similarly, the principals' rights can be altered by adding the principal 150 to a new group having different rights (i.e., a newly created and/or previously designated group), taking a role and/or releasing a role from the principal, altering a role, splitting a group based on the principal and/or required rights, or other such actions. For example, a group may have ten members and five rights may be granted. Five of the group members may be adapted to have the first four rights and five of the group members may be adapted to have the last three rights. Splitting this group into two groups, each of which has the appropriate rights, then letting the appropriate principal be a member of the appropriate group may make the rights more optimal for each member.

In one embodiment, the rights may specify the principal 150, resources, actions, conditions, and/or effects. In some embodiments, the rights may specify one or more of a plurality of these elements, such as, for example, a group or class of users, a set of resources, a number of different actions, and/or a plurality of conditions. The body 150 may represent a user, group, organization, role, or collection and/or combination of these or other such entities. The body 150 may be any entity capable of submitting an API call that results in performing an action associated with a resource, and/or any entity to which rights associated with a resource may be granted. For example, a particular right may indicate that principal 150 is a USER identified as "USER 1". Rights may indicate that an action may be performed in association with a resource and that the action may be identified, for example, by a type of API call, library call, program, procedure, series of steps, workflow, or some other such action. For example, an action may be a set of operations that may be performed as part of an implementation of an API call to, for example, a web-accessible service. The actions performed may be a subset of those actions and/or may be a single operation. Operations may also be performed in a defined order, may be repeated, or may be shared among multiple API calls. For example, the action may be an API call to write data to the resource. Rights may also specify storage resources, data write API calls for actions, time conditions, and permission effects. Thus, such exemplary permissions may specify that "USER1 is allowed to write to 12345 between 9:00 and 9:30 AM.

Fig. 3 illustrates an example of a role reachability graph that may be used for role reachability analysis with transitive labels, in accordance with some embodiments. As discussed above, the persona reachability graph 110 may include nodes representing personas and edges representing potential personas acting as steps. The exemplary graph 300A shown in fig. 3 can include nodes representing roles such as role 310, role 320, role 330, role 340, role 350, role 360, role 370, role 380, role 390, and so forth. Graph 300A may be a directed graph in which edges have directions such that a directed edge between two nodes indicates that one role may potentially take on another role to which the edge points. For example, an edge between roles 310 and 320 may indicate that role 310 may potentially play role 320. The graph 300A may not necessarily be a directed acyclic graph. For example, a set of roles may act in a step that allows the role represented by role 340 to act as the role represented by role 370, role 370 to act as role 380, and role 380 to act as role 340. In some embodiments, the set of potential paths may be unbounded due, at least in part, to the potential looping nature of the graph 300A and also due to the use of string-based tags. Some nodes may not be reachable from other nodes. For example, character 390 may not be reachable from characters 310-380. In some embodiments, any two roles may belong to different accounts or the same account of provider network 190. For example, role 310 may belong to a first account, role 370 may belong to a second account, and role 330 may belong to a third account.

Fig. 4 illustrates an example of role-playing steps with a transitive label, in accordance with some embodiments. The diagram 300B shown in fig. 4 may represent a portion of the exemplary diagram 300A discussed above. Role play is conditioned on key-value properties (labels) of the role session, including transitive labels that persist during play of different roles. In some cases, the state of the tag may change during role play. The role-specific role can result in the addition of one or more labels, and thus, the specific path taken by the role-specific role-chain can result in a different label state compared to another path to the same node in the graph. For example, the partial graph 300A shows two paths from the character 310 to the character 350, e.g., via the intermediate character 320 or the intermediate character 360. If character 360 adds a transitionable label to the session during character's role play but character 320 does not, the label state at character 350 may differ depending on the path taken.

The state of any tag of a session may represent an authorization context and role play may be conditioned on that context. In the exemplary diagram 300B of FIG. 4, the session tag state after assuming role 310 may include a key-value tag { k } ₁ :v ₁ }. If role 310 takes on role 360, another key-value tag may be added such that the session tag state includes { k ₁ :v ₁ ,k ₂ :v ₂ }. However, if role 310 instead acts as role 320, the tag state may remain unchanged. If role play is performed for role 350, the state of the session tag may change based (at least in part) on the path taken. Roles of role 350 can also add another key-value tag. For example, acting role 350 from role 320 may result in the inclusion of { k ] ₁ :v ₁ ,k ₃ :v ₃ Session tag state of }, and role 350 from role 360 can result in a session tag state that includes { k } ₁ :v ₁ ,k ₂ :v ₃ ,k ₂ :v ₃ Session tag state of }. The ability of character 350 to assume additional roles may then be based (at least in part) on thisThe state of the tag varies somewhat.

Role reachability analysis 110 may begin traversing the graph at one or more possible entry points, such as nodes lacking transitive label states. Roles are conditioned on labels that can match wild cards of values of key-value attributes. Based (at least in part) on the presence of such wild cards, the set of potential tag values associated with the role-playing step may be unbounded and/or infinite. In some embodiments, for each node, analyzer 100 may determine the likely neighbors of each node by: observing whether the current transitive tag state can only be extended by a set of tags whose keys are explicitly mentioned and whose associated conditions are therefore known or under-specified tags whose values are unrestricted or partially restricted. The analyzer 100 can aggregate one or more boundary conditions (e.g., upper and/or lower bounds) of one or more tags, as indicated by the access control policy 165 associated with the role-playing step.

As demonstrated using the following example, role play can lead to unexpected privilege upgrades in the presence of subtle transitive tag behavior with potentially overlapping string constraints. In provider network 190, if role r's trust policy trusts principal p, and if p's identity policy grants access to resource r's AssumeRole action, then p may act as role r. If p and r are from different accounts, then p may be granted access to the AssumeRole action if the identity policy of p is displayable granting access to the AssumeRole action. If p and r are from the same account, p may access the AssumeRole action as long as p's identity policy denies access to the AssumeRole action without display. In this example, the identity policy of a particular user Jane in account 123 may include the following:

in this example, the trust policy for the audit role in account 123 may include the following:

in this example, the identity policy of the persona audio may include the following:

the condition comprising forallvues may test whether the value of each member in the request set is a subset of the condition key set. If each key value in the request matches at least one value in the policy, the condition may return true. The condition may also return true if there are no keys in the request or if the key value resolves to a null data set such as a null string. A condition comprising ForAnyValue may test whether at least one member of the request value set matches at least one member of the condition key value set. If any of the key values in the request match any of the condition values in the policy, the condition may return true. For no matching key or empty data set, the condition may return false.

According to the exemplary policy fragment shown above, due to its trust policy, jane is trusted by audi and Jane is not shown denied access in the role audi because audi does not match string pattern Write (as denied by Jane's identity policy). The AssumeRole operation may be allowed because Jane's policy does not reject the AssumeRole action and the role's trust policy explicitly allows her access.

In this example, the trust policy for role ReadOnly in account 321 may include the following:

in this example, the identity policy of the role StorageAccess in account 321 may include the following:

in this example, the trust policy of the role StorageAccess may include the following:

/>

according to the exemplary policy fragment shown above, the role audios in account 123 are allowed to play the role ReadOnly in account 321 because the identity policy of audios explicitly grants access to the AssumeRole API on ReadOnly due to the identity policy of the role audios, and because ReadOnly trusts audios due to the trust policy of the role ReadOnly. Meanwhile, the storage access trusts ReadOnly in its own account due to the trust policy of the role storage access, and thus ReadOnly can act as the role storage access. However, in some embodiments, these roles act as step presence conditions expressed as constraints corresponding to tags having particular values or matching specified criteria. Cloud provider network 190 may disclose a tag with a conditional key prefixed with a RequestTag, so the user may reference the value of the Name tag when authorizing an AssumeRole call by referencing RequestTag/Name. After successful invocation, this same tag may be attached to the resulting session as a pricipaltag/Name.

In the example, in order for user Jane to take on role audiot, the user must provide a session tag whose key is FirstName and whose value matches J (according to the trust policy of role audiot). At the same time, the trust policy limits the session tags that can be set as transitive to session tags with keys FirstName or Email, but requires the presence of at least one transitive tag with a key FirstName. If user Jane selects a value for FirstName that does not match an, any attempt to take on the role of ReadOnly can be denied because this would violate the conditions set forth by the trust policy of ReadOnly.

In this example, in order for the character audiot to act as a character ReadOnly, the character audiot must provide a session tag whose key is LastName and whose value matches D. Although policies define the upper of the transitive labels as those labels having the key LastName, policies do not require the keys to be set transitive. If the value chosen for LastName does not match with soe and it is set as transitive, any attempt to assume the role of StorageAccess may be rejected, as this would violate the conditions set forth by the trust policy of the StorageAccess. On the other hand, if LastName is not set as transitionable, then the session associated with role ReadOnly will not have the body token LastName necessary to function as role StorageAccess.

In this example, in order for the role ReadOnly to function as a role StorageAccess, the role ReadOnly must provide a session tag whose key is Email and whose value is jane@doe.com. In some embodiments, if Jane passes the deliverable tag Email when acting as audiot, it is not possible to pass the session tag Email when acting as StorageAccess because the deliverable tag cannot be overwritten and thus the request will be denied. In some embodiments, the request is only granted if the values selected for FirstName and LastName in the previous role play step match ×e and ×oe, respectively.

In some embodiments, in order to provide a session tag during the role-playing step, it may be necessary to have the right to perform the action TagSession in addition to the action matching the API operation AssumeRole. Thus, the trust policy of role audios, the trust policy of role ReadOnly, the trust policy of role storage access may grant such access. If user Jane acts as a role audiot providing a transitive label with a key FirstName and a value Jane, then acts as any role ReadOnly providing a transitive label with a key LastName and a value Doe, then acts as a role storage access providing a transitive label with a key Email and a value jane@doe.com, then all roles may be authorized to act as steps. By using temporary credentials associated with the role StorageAccess, user Jane can gain access to the resource active-resource/. This behavior may or may not be desirable, depending on the circumstances. The access control analyzer 100 may perform role reachability analysis based on transitive or "sticky" session tags to find such roles to act as a chain of steps in a large number of policies and their complex interactions in the provider network 190.

In provider network 190, a resource may represent a domain of elements that may be created, read, updated, or deleted by a user. For example, resources 170 may include users, roles, policies, queues, databases, virtual machines, and the like. In provider network 190, the actions may represent constants (such as AssumeRole or DeleteObject) that represent operations that may be performed on the resource. In provider network 190, a principal may represent an entity that may request to act on a resource. Examples of principals may include accounts, users, roles, services, and the like. The request may be represented by a quadruple (p, a, r, c) such that p is the body, a is the action, r is the resource, and c is the map containing the additional information. Additional information may be related to the request, the body, and/or the resource, such as service specific information and tags. The item AUTH may represent an assertion that governs whether the principal p is authorized to perform operation a on resource r under request context c such that the request (p, a, r, c) is authorized if and only if AUTH (p, a, r, c) is true. The potential complexity of the authorization in the provider network 190 may be captured using the abstract predicate AUTH.

Roles take on (or take on roles) transformation relationshipsCan be defined as follows. The principal p may be authorized to assume role r only if AUTH (p, assumeRole, r, c) holds for certain request contexts c. However, the conditional block of the trust policy for role audios may require user Jane to pass the FirstName session tag, otherwise the operation will fail. In order to mark a session, it may be necessary to have the right to perform the action TagSession in addition to the action matching the API operation AssumeRole. In some embodiments, the AUTH (p, tagSession, r, c) must also be held. In some embodiments, both requests must be granted simultaneously and in the same request context. To determine when a session tag must be provided, an assertion ST may be defined such that ST (p, r) holds if and only if any request context c that satisfies AUTH (p, assumeRole, r, c) contains a session tag.

In some embodiments, because the policy language may allow a lower bound to be established for a set of deliverable session tags, a role may be reachable only in a particular state of the deliverable session tags that affects the authorization output. In some embodiments, when provider network 190 is in state σ (the current state of its user, role, policy, etc.) and the deliverable session label state is t, principal p may only assume role r when a new set of deliverable session labels t' \t are introduced when the following role reachability relationships are established:

item E may characterize the impact of the environment on the cloud provider network state during execution. For example, when p acts as r, the environment may 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 not be reachable from p when the provider network state is not changing (e.g., E = { (s, s ') |s=s ' }), but may be reachable if the environment is unrestricted (e.g., E = { (s, s ') |true). Because ofSo if t' +.t +.>And thus may provide a transitionable tag during the transformation. In some embodiments, p must be authorized to mark the session. If- >And ST (p, r), it may not be necessary to check whether p is authorized to mark the session. On the other hand, c U.T.. U.T. 'may represent the fact that the request context c extends through tags in the current transitive tag state, which are added as principal tags (i.e., transitive tags become principal tags associated with the role instance being acted upon), while tags in t' \t may be added as request tags. For example, if t= {FirstName: jane } and t' = { FirstName: jane, lastName: doe }, then c & &t' is c & { prime Tag/first name }: jane, requestTag/LastName: doe }. In some embodiments, the responsibility of the AUTH assertion is to check that no request tag corresponds to a transitive tag because the transitive tag cannot be overwritten. In some embodiments, if and only if t, t ', σ, σ' are present such that +.>The character r can be considered reachable from the body p.

In some embodiments, the access control analyzer 100 may use the policy comparison service 180 in the provider network 190 to find semantic level differences between two access control policies. For example, policy comparison service 180 may determine whether one policy is less tolerant or equally tolerant than another policy. In this context, policies may be interpreted as a collection of requests that they authorize, and the results of policy comparison service 180 may refer to collection inclusion. For example, a first policy may allow user u to assume role r regardless of context, and a second policy may allow user u to assume not only role r, but any role that matches wild card term r. Policy comparison service 180 may determine that the second policy is more tolerant than the first policy. In some embodiments, policy comparison service 180 may determine whether one policy is equal, smaller, larger, or incomparable relative to a second policy.

In some embodiments, policy comparison service 180 may be used to determine ST (p, r). For the subject p and the character r, let pi be ₀ A trust policy of r. Making negative policy pi ₁ Authorization trust policy pi ₀ E.g., by authorizing all requests except those in which p performs the action AssumeRole on r and the request context does not contain any session tags. In this example, the negative policy pi ₁ The following may be included:

if and only if the request context c exists such that AUTH (p, assumerol, r, c) is at pi ₀ When none is true and c does not contain any session tags, policy comparison service 180 may determine (pi ₁ ,π ₀ ) Not less than equal to the following. If and only if there is no quilt pi ₁ Authorized and pi-authorized ₀ Upon request for authorization, policy comparison service 180 may determine (pi ₁ ,π ₀ ) Not less than equal to the following. Because only is not pi ₁ The requests of authorization are those that enable p to take role r, where the request context does not include any session tags, as imposed by the conditions on key TagKeys, so there is a key that is pi-acted ₀ Such a request for authorization.

In some embodiments, the policy comparison service 180 may be used to determine AUTH. Let p be the main body, let r be the role, and assume that analyzer 100 tries to determine if AUTH (p, assumeRole, r, c. Let pi be ₀ Is a policy that allows each request except those that enable p to take role r regardless of context. In this example, policy pi ₀ The following may be included:

on the other hand, let pi ₁ Is r, which acts as a role policy by rejecting all requested statement extensions that do not satisfy the tag conditions described above. In this example, policy pi ₁ The following may be included:

in addition, pi ₁ Statement extensions that reject all requests in which the deliverable label key set is not entirely LastName may be obtained by:

/>

because policy comparison service 180 may check for the presence of principal labels that satisfy the policy conditions, in some embodiments, no principal labels can be present other than those in the transitive label state (such as any principal label key explicitly mentioned in the role-in-role policy of non-FirstName of r) as shown below:

if and only if there is a request context c such that AUTH (p, assumeRole, r, c U.T. ') is established, where t= { FirstName: jane } and t' = { FirstName: jane, lastName: doe }, the policy comparison service 180 may determine (pi ₀ ,π ₁ ) Not less than equal to the following. If and only if there is no quilt pi ₀ Authorized and pi-authorized ₁ Upon request for authorization, policy comparison service 180 may determine (pi ₀ ,π ₁ ) Not less than equal to the following. Because only is not pi ₀ The requests for authorization are those that enable p to take role r, so there is a request that is pi ₁ Such a request for authorization. In some embodiments, is pi ₁ Any request that is granted cannot meet the criteria tag/first name being not equal to Jane nor the RequestTag/LastName being not equal to Doe, otherwise the request will be denied. Similarly, in some embodiments, is pi ₁ Any request that is authorized can only contain a single deliverable session tag with a key LastName and no body tag keys other than FirstName, otherwise the request will be denied. Thus, there is a request context c such that the trust policy of AUTH (p, assumerol, r, c u t') with respect to r holds.

In some embodiments, the analyzer 100 may also check the identity of p, assuming that p and r are from the same accountWhether the policy grants access to the API operation AssumeRole for role r. A similar process may be performed when p and r come from different accounts. In some embodiments, it may be sufficient that the identity policy checking p does not explicitly deny access to AssumeRole operations. Let pi be ₀ Is the identity policy of p, and pi ₁ Is an identity policy of p that is extended by explicitly rejecting statements that p takes on role r. If and only if p's identity policy does not explicitly reject p from role r, policy comparison service 180 may determine (pi ₀ ,π ₁ ) Not less than equal to the following. In some embodiments, the analyzer 100 may determine AUTH (p, tagSession, r, c U.T ') in the same manner as AUTH (p, assumerol, r, c U.T').

In some embodiments, policy comparison service 180 may be used to determine whether multiple conditions are simultaneously established in the transitive tag values, where the conditions are expressed in the same language as provider network policy 165. To avoid having to translate the policy language into the language of a Satisfiability Modulo Theory (SMT) solver, the policy comparison service 180 may be used to check satisfiability. For example, policy comparison service 180 may be used to determine whether the session tag FirstName exists that satisfies both the values "StringLike" and "StringLike": ". Let pi be ₀ Is the policy that denies each request and considers policy pi ₁ Each request except those in which the value of the request tag FirstName does not match "Ja" or does not match ". Ne" is allowed. Policy comparison service 180 may determine (pi) if and only if the session tag FirstName exists that satisfies both the values of "StringLike" and "StringLike": ", ne ] ₀ ,π ₁ )＝<. Due to pi ₀ Reject all requests, so pi ₀ ≤π ₁ . Thus if and only if pi ₁ Pi when authorizing at least one request ₀ <π ₁ . In some embodiments, is pi ₁ Any request that is authorized cannot satisfy the value of FirstName not matching Ja. Thus, firstName matches Ja and FirstName must match ne.

In some implementations, the analyzer 100 may be in the provider network without an environmental change (e.g., E = { (s, s ') |s = s' })Analysis 120 of the role reachability problem is performed under the specific state of the transitive session ticket within the account. In some implementations, the analyzer 100 may monitor calls to APIs in the provider network 190 that may change the environmental state (e.g., for a particular account), and if the environmental state has changed, the analyzer 100 may restart the analysis 120 upon completion. Given a provider network account with state σ, analyzer 100 can determine its role reachability graph 110 whose nodes are pairs (p, t), where p is the principal and t is the transitive label state, and where if and only if When there is a side from (p, t) to (r, t'). The term σ may be a constant in the analysis.

Set policy pi ₁ The following may be included:

there is a slave to any string s matching JTo the edge of (audiot, { "FirstName": s }), the role reachability graph may contain an unlimited number of nodes. However, to infer persona reachability, the analyzer 100 need not necessarily know the specific values that the tag takes during the persona assuming step. Instead, the analyzer 100 may determine a characteristic that characterizes the tag, e.g., the tag matches J. Such observation may allow analyzer 100 to act as all possible ways of characterizing the state of the extensible transitive labels for each role. By abstracting the tag values, the analyzer 100 can translate the unbounded role reachability graph into a limited abstraction.

Let (p, t) and (r, t') be nodes such thatThus->And each tag in t' \t may represent a session tag provided during the role-playing step, the session tag being set to be transitive or "sticky". Thus, if S is the set of all session tags that can be transferred when p acts as r, < +.>In some embodiments, S may be determined by a static analysis strategy. To determine the possible keys in S, a view is made of whether the policy language may allow a boundary to be established for a set of keys that are passed along with the request by defining conditions for the keys TagKeys. Because the request may contain multiple tag key-value pairs, tagKeys may be multi-valued variables and thus may be constrained by one of the ForAllValues and ForAnyValue set operators and the available string operators (e.g., stringEquals, stringLike, etc.). For example, the following policy fragments may ensure that a set of session tags meet the boundary, as long as its key K meets

Because these conditions may not exist or may allow an unlimited number of different keys (e.g., when using regular expressions), analyzer 100 may determine an upper bound for S. In some embodiments, S can be divided into two groups: (i) Those labels whose keys are explicitly mentioned in some policies, and (ii) those labels whose keys are not explicitly mentioned in any policies. In some embodiments, the label keys in the latter group will never match the subject label keys, nor will they have a conflicting condition, or they will be mentioned in the corresponding policy. Thus, these under-specified tags may be considered unrelated to role reachability analysis. In some embodiments, such tags can only be used for the purpose of meeting the lower bound condition of the transformation-enabled policies. By considering only labels whose keys are explicitly mentioned in some policies, the analyzer 100 can implement the main aspects of the role reachability problem: session tags that can later be used as a body tag are identified and conflict conditions are inferred.

In some embodiments, to determine all possible keys in t' \t, analyzer 100 may begin with consideration of the set S of all explicitly mentioned label keys across all role policies that may be obtained by parsing all occurrences of the following syntax patterns, with the label keys prefixed with either RequestTag or priapitaltag:

In some implementations, S can be refined by applying an upper bound condition obtained by scanning role policies that enable transformation of the following syntax patterns:

in some embodiments, once S has been determined, anyMay be a valid candidate to be a set of transitive session label keys provided during the current role functioning step as long as it meets the lower bound condition extracted by parsing the ForAnyValues syntax pattern shown above. Once the keys have been determined, their values can be characterized. To this end, the analyzer 100 may utilize a policy language in which the characteristics are stated as: for example, if a tag key is not mentioned in the policy that enables the current transformation, then the value of the tag key is not or partially limited (e.g., represented by the condition StringLike:), whereas if a tag key is mentioned, then all may be mentionedCorresponding conditions are aggregated and associated with the label key.

For example, the following policy fragments may allow a session tag set of { "FirstName" { "Stringlike": "J" }, "LastName": { "Stringlike": "D" }, and { "firstName": { "Stringlike": "J" }, "LastName": { "Stringlike": "D" }, "Email": { "Stringlike": "" }, as firstName and LastName must exist to satisfy the associated conditions, and Email may be optional and unrestricted:

In some embodiments, because a limited number of tags may be mentioned, each candidate session tag set may contain a limited number of keys, each key having a limited number of associated conditions. Upon checking whether the proposed session tag set meets all the conditions set forth by the transformation-enabled policy, the analyzer 100 may verify that it is expandable by a set of under-specified tags meeting the lower bound condition. In this way, analyzer 100 may perform over-approximation rather than exact reachability analysis.

Fig. 5 is a flow chart illustrating a method for role reachability analysis using a transitive label, in accordance with some embodiments. As shown at 500, the access control analyzer 100 may determine a graph including a plurality of nodes and one or more directed edges. These nodes may represent multiple roles in a provider network hosting multiple services and/or resources. The nodes may include a first node representing a first role and a second node representing a second role. These roles may be associated with multiple access control policies that grant or deny access to individual ones of the multiple services and resources. The one or more access control policies may grant or deny access based at least in part on the one or more key-value tags (e.g., where the tag of the session matches one or more conditions under which the role plays). Some roles take on the condition that the step can match a label of the wild card of the value of the key-value property. Based (at least in part) on the presence of such wild cards and the unbounded length of the character string, the set of potential tag values associated with the role-playing step may be unbounded and/or infinitely large.

To perform role reachability analysis, analyzer 100 may limit the set of keys to consider in determining whether an executable role plays a role. In some embodiments, for each node, analyzer 100 may determine the likely neighbors of each node by: observing whether the current transitive tag state can only be extended by a tag whose key is explicitly mentioned and whose associated condition is therefore a set of tags whose values are known or are unrestricted or partially restricted (e.g., by wild cards) of under-specified tags. The analyzer 100 can aggregate one or more boundary conditions (e.g., upper and/or lower bounds) of one or more tags, as indicated by the access control policy 165 associated with the role-playing step. To infer character reachability, the analyzer 100 need not necessarily know the specific values that the tag takes during the character's role-playing step. Instead, the analyzer 100 may determine a characteristic that characterizes the tag, e.g., the tag matches J. Such observation may allow analyzer 100 to act as all possible ways of characterizing the state of the extensible transitive labels for each role. By abstracting the tag values, the analyzer 100 can transform the unbounded role reachability graph into a limited abstraction that eliminates the potentially unbounded nature of the path and/or tag states.

As shown at 510, the analyzer 100 may determine whether the first persona may act as a second persona using one or more personas for a particular state of one or more key-value tags based, at least in part, on the persona reachability analysis of the graph. In performing the role reachability analysis, the analyzer 100 may treat nodes in which the transitive label state is empty as entry points of the role play chain. A separate one of the role-playing steps may provide temporary access during the role session. The one or more key-value tags may include one or more transitive tags that persist during the one or more roles playing steps. By statically analyzing the policy, a set of all session tags that can be delivered when the principal takes on a role can be determined. To determine the possible keys of the labels in the set, it is observed whether the policy language may allow to establish a bound for a set of keys that are passed along with the request by defining conditions for the keys TagKeys. Because the request may contain multiple tag key-value pairs, tagKeys may be multi-valued variables and thus may be constrained by one of the ForAllValues and ForAnyValue set operators and the available string operators (e.g., stringEquals, stringLike, etc.).

Because these conditions may not exist or may allow an unlimited number of different keys (e.g., when using regular expressions), analyzer 100 may determine the upper bound of the set of all session tags. In some embodiments, the set of all session tags can be divided into two groups: (i) Those labels whose keys are explicitly mentioned in some policies, and (ii) those labels whose keys are not explicitly mentioned in any policies. In some embodiments, the label keys in the latter group will never match the subject label keys, nor will they have a conflicting condition, or they will be mentioned in the corresponding policy. Thus, these under-specified tags may be considered unrelated to role reachability analysis. In some embodiments, such tags can only be used for the purpose of meeting the lower bound condition of the transformation-enabled policies. By considering only labels whose keys are explicitly mentioned in some policies, the analyzer 100 can identify session labels that can later be used as body labels and can also infer conflict conditions.

Fig. 6 is a flow chart illustrating other aspects of a method for role reachability analysis using a transitive label, in accordance with some embodiments. Analyzer 100 may implement a method that builds its role reachability graph given a set of users and roles and returns its adjacency list representation. For a particular node, the adjacency list may indicate what the node's neighbors are. The method may begin, as shown at 600, by defining a set q that contains all nodes that have not yet been processed, such as nodes whose possible neighbors and edges are to be determined. Thus, q can pass through All pairs of extensions in form, where p is the user or role. As shown at 610 and 620, although there is stillUnprocessed nodes, but the analyzer 100 may pick the nodes and extract their body p and their transitive label state. In some embodiments, the order in which the nodes are selected may be irrelevant. If there are no unprocessed nodes, the method may end.

The analyzer 100 may limit consideration of roles to a limited set and may consider only limited paths. As shown at 630, analyzer 100 may consider each role r that p may potentially take. The "candidate" function may return a set of all session tags and their associated conditions that may potentially pass from p to r during role play, as previously described. Because any subset of the set of session tags may be candidates for the set of transitive tags provided during the current step, analyzer 100 may iterate through the session tags and discard tags whose keys are in the current transitive tag state because transitive tags cannot be overwritten. Once the keys have been determined, the values of these keys can be characterized by a policy language, the characteristics in which can be stated as: for example, if a tag key is not mentioned in the policy that enables the current transformation, the value of the tag key is not or partially limited (e.g., represented by the condition StringLike:. X), and if a tag key is mentioned, all corresponding conditions may be aggregated and associated to the tag key. Upon checking whether the proposed session tag set meets all the conditions set forth by the transformation-enabled policy, the analyzer 100 may verify that it is expandable by a set of under-specified tags meeting the lower bound condition.

As shown at 640, the analyzer 100 may consider the role r, along with the extended transitive label state, as a candidate for a neighboring node in the role reachability graph. In some embodiments, the characteristics of the values characterizing the tags in the transitive tag state must be updated to reflect the conditions that they must satisfy during the current step, e.g., the conditions that enable statements put on subject tags. As shown at 650, the analyzer 100 may verify that the conditions characterizing each tag value are in fact satisfied, otherwise candidate nodes will not exist. This may occur due to conflicting conditions regarding the key being in different phases of the character's play chain. In addition, as shown at 660, the analyzer 100 may verify whether the transformation between the considered nodes is true. If the transformation is true, the analyzer 100 may update the adjacency list as shown in 670. Finally, if a new node has not been viewed, the analyzer 100 may add it to the list of nodes to be processed and may indicate that the node has been introduced into the graph, as shown at 680. As described above, a graph may include a loop portion in which traversal of the graph may access the same node more than once. In building the graph, the analyzer 100 may not access the same node twice, as no additional rights have to be added for subsequent accesses.

In some embodiments, the role reachability analysis may not consider the entire history of conditions about the tag when transforming to perform role roles. In some embodiments, the role reachability analysis may consider a broader history of conditions about the tag, e.g., consider the last N steps as a history. In some implementations, role reachability analysis may enumerate a broader set of paths. For example, role reachability analysis may use path merging techniques to encode an exponential number of paths. By considering a wider set of tag histories and/or paths, analysis may consume more computing resources, but may also achieve greater accuracy.

Fig. 7 is a flow diagram illustrating a method for role reachability analysis using policy complementary sets, in accordance with some embodiments. As shown at 700, a first node and a second node may be determined in a graph. The first node may correspond to a first role in a provider network hosting a plurality of services and resources. The first role may be associated with a first access control policy that grants or denies access to the 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 node and the second node may potentially share a common edge such that roles may be performed from the first role to the second role without taking any intermediate roles. Role reachability analysis may be initiated to determine whether a first role may play a second role for a particular state of one or more key-value tags.

As shown at 710, the role reachability analysis may determine a third access control policy that authorizes the role for the second role to act as a complement to the request. The third access control policy may allow all actions except taking the second role. The third access control policy may represent a complement of policies that act as requests with respect to the role for the second role. The third access control policy may represent a negation of the role of the principal in the first role as an action. The third access control policy may be referred to as a negative access control policy.

As shown at 720, the role reachability analysis may perform an analysis of a third (negative) access control policy with respect to role roles policy for the second role for the particular state of the one or more tags. In some embodiments, the role of the extensible second role acts as a policy, e.g., with statements rejecting all requests that do not satisfy the condition of the one or more tags. Analysis may be performed using a policy comparison service that determines whether one access control policy is more tolerant, less tolerant, equally tolerant, or incomparable relative to another access control policy. Because the space of the string of labels may be unbounded (e.g., due to wild cards), the analyzer may select one or more representative values of one or more key-value labels from a range of potential values (equivalence classes) of the labels. These representative values may be used to determine the status of one or more tags.

In some embodiments, the third access control policy (which specifies the complement of the role play action) may include an extended role play policy for the second role if and only if there is no context for the second role to play under which it is authorized. In some embodiments, the role of the first role in the second role may be authorized if and only if the third access control policy (which specifies that the role acts as a complement to the action) does not include the extended role of the second role to act as a policy. If the third access control policy does include the extended role of the second role acting as a policy, then the principal in the first role may be denied access to the second service or resource, as indicated at 730. If the third access control policy does not include the extended role of the second role acting as a policy, then access to the second service or resource by the principal in the first role may be granted, as indicated at 740.

FIG. 8 illustrates other aspects of an exemplary system environment for role reachability analysis with transitive labels, including equivalence results generated in response to a request to analyze the equivalence of two security policies, in accordance with some embodiments. As discussed above, the policy comparison service 180 may 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 analyzer 100, may make an API request to the policy comparison service that includes two or more security policies. The security policy may represent information (e.g., encoded in a file) specifying one or more security rights. The security rights may be an element of a security policy that defines access rights associated with resources and/or principals of the system. For example, the permissions may be used to grant or deny access to computing resources of a computing resource service provider, such as provider network 190. Policies may be expressed in a language independent format such as JavaScript Object Notation (JSON). Examples discussed in this disclosure may be in JSON format or JSON-like format and as illustrations of the various embodiments that may be implemented. Of course, various other formats that may be used in conjunction with the manner described by the JSON and JSON-like formats are also contemplated and within the scope of the present disclosure. The security policy may include one or more rights statements and additional information such as version control information and policy scope information. In some cases, the policy-wide information may be included in a policy header at the beginning of the policy, or may even be stored separately (and in association) with the policy document. The policy may include a plurality of policy statements.

In some embodiments, forcibility is used to describe permissions for access to a resource. For example, if a first policy grants access to a first computing resource (e.g., resource "a") and a second resource (e.g., resource "B") and the second policy grants only access to computing resource "B", then the first policy may be described as being more tolerant than the second policy because there are computing resources for which the first policy grants access and the second policy does not grant access and there are no resources for which the second policy grants access and the first policy does not grant access. Two policies may be equivalent if they both grant access to the same resource and deny access (implicitly or explicitly) to the same resource. In some cases, equivalence may refer to both policies explicitly granting access to and explicitly denying access to the same resource, e.g., in some embodiments, a first policy that explicitly denies access to a computing resource and a second policy that implicitly denies access to a computing resource (e.g., by not positively granting access in a default denial context) may lack equivalence. In general, two strategies can be said to lack equivalence if they are not equivalent. In some cases, a first policy may be said to be incomparable if it grants access to first computing resource "a" and second computing resource "B" and a second policy grants access to second computing resource "B" and third computing resource "C". It should be noted that unless specified otherwise, examples described herein may implement a default denial security model in which access to computing resources is denied unless there is an explicit grant of access to the computing resources. It should also be noted that in the context of these discussions, security policies may be utilized in the context of a computing resource service provider to grant or deny access to resources, where requests to access resources may be evaluated by an authorization module or authorization service by utilizing the security policies applicable to the requests. The applicable security policies may be security policies associated with the requestor, security policies associated with tokens presented by the requestor, and so forth.

Policy evaluation service 180 may include various components and/or modules, such as a policy resolver, a proposition logic converter, and a satisfiability engine. The policy resolver may be a component or module that receives a security policy (e.g., a security policy received from a client associated with an API call or obtained through a policy management service) and obtains one or more rights statements from the policy. For example, if the client provides a first policy "a" and a second policy "B" to the policy comparison service 180, the policy comparison service may obtain a first set of rights statements from policy "a" and a second set of rights statements from policy "B" using a policy resolver. Rights statements may each be associated with granting or denying access to a computing resource. Rights statements may take a particular format such as JSON, aspen, and the like.

As described herein, proposition logic may refer to symbolic logic related to the evaluation of propositions, which may be evaluated as true or false. Proposition logic may be used to evaluate the logical equivalence of proposition formulas. The proposition formula may be a sentence according to a syntax including a proposition variable and a logical connection word connecting the proposition variable. Examples of logical connectives or logical operators may include: and, or, no, and if and only if, the terms conjunctive. Propositional logic may also be described herein as a "propositional expression" or a "propositional logic expression". In some implementations, the proposition logic may be replaced with first order logic. First order logic may refer to a formal system that uses the quantifiers in addition to the proposition logic. Examples of adjectives include "all" (generic adjective) and "present" (present adjective). Embodiments of the present disclosure described in connection with propositional logic may also be implemented using first order logic unless explicitly stated. For example, in some implementations, a first order logical converter may be used in place of a proposition logical converter to convert the rights statement into a first order logical expression, and the satisfiability engine may evaluate one or more first order logical expressions to determine whether the expressions are equivalent.

Rights statements (e.g., those obtained by a policy resolver) may be provided to the proposition logic converter. The proposition logic converter may receive the permission statement (e.g., in JSON format) and convert the permission statement into one or more constraints described using the proposition logic. Constraints can be described in various formats and according to various standards, such as SMT-LIB standard formats, CVC language, and discrete mathematical and theoretical computer science center (DIMACS) formats. The proposition logic expression generated by the proposition logic converter may represent a set of constraints that must be satisfied to validate the corresponding rights statement. Constraints may have to be satisfied if the rights statement that previously allowed access to the API beginning with "put" (e.g., "put-object") is to be fulfilled.

In some implementations, the analyzer 100 can transmit a web-based API request to the policy comparison service 180 requesting the policy comparison service to determine whether a first security policy (e.g., "security policy a") is more tolerant than a second security policy (e.g., "security policy B"). The security policy may be encoded in the web API request or may provide information that may be used to obtain the security policy (e.g., a pointer or URI indicating the location where the policy may be obtained). The policy comparison service 180 may obtain the security policy (e.g., directly from the request or by the policy management service using a URI encoded in the request) and obtain a first set of rights statements from the first policy and a second set of rights statements from the second policy using a policy resolver. The policy statements may be provided to a proposition logic converter to obtain a set of proposition logic expressions corresponding to constraints that must be satisfied to validate the corresponding policy statement. A first propositional logic expression may be generated from the first set of policy statements and a second propositional logic expression may be generated from the second set of policy statements. The propositional logic expression may be expressed in a language conforming to an SMT-LIB standard language, such as the STM-LIB 2.0 standard. The satisfiability engine may be used to compare the first proposition logic expression and the second proposition logic expression to determine whether one proposition logic is more tolerant than the other.

The satisfiability engine may be used to analyze the forgeability of two or more propositional logic expressions. The satisfiability engine may be hardware, software, or a combination thereof. In some implementations, the satisfiability engine allows a client (e.g., an internal client such as a proposition logic converter, policy comparison service 180, etc.) to determine whether a first proposition logic expression is more tolerant than a second proposition logic expression. The satisfiability engine may generate additional proposition logic constraints as part of determining whether the first proposition logic expression is more tolerant than the second proposition logic expression.

In addition to the constraints of the first propositional logic expression and the second propositional logic expression, which may be encoded in the above-described manner, constraints may be generated and evaluated. Constraints may be generated based at least in part on what is requested by the client. For example, the satisfiability engine may generate constraints that are satisfied only if: the first policy grants access to the resource and the second policy denies access to the resource or remains neutral to the resource in response to a request from a caller (e.g., policy comparison service 180) to determine whether the first proposition logic expression is more tolerant than the second proposition logic expression. Such an implementation may be implemented in a default reject context, where a neutral context (i.e., a context in which access to a particular resource is explicitly granted or denied without permission). In a default permission context, the satisfiability engine may generate different constraints that are satisfied if: the first policy grants access to the resource or remains neutral to the resource and the second policy does not deny access to the resource.

The satisfiability engine may be used to verify whether the proposition logic constraints (e.g., those obtained from the first proposition logic expression and the second proposition logic expression and those generated by the satisfiability engine) are equivalent. In some implementations, a command may be used to determine whether a set of constraints is satisfiable. A formula may be satisfied if there is an interpretation that causes all of the asserted formulas to be true. In other words, the model is satisfied if each constraint is satisfied under certain conditions. In some embodiments, the satisfiability engine may be implemented, at least in part, using a Satisfiability Modulo Theory (SMT) constraint solver that determines whether the formula is satisfiable. An example of an SMT-based constraint solver is Z3. Other types of solvers may be used as part of implementing the satisfiability engine according to the techniques described herein, including, but not limited to, satisfiability (SAT) solvers and Binary Decision Diagram (BDD) solvers. The satisfiability engine may generate an equivalence result indicating whether a formula may be satisfied and extended to indicate whether two or more policies are equivalent. In some embodiments, the equivalence result is available to another computing entity, such as the requesting analyzer 100, a system administrator, and other computing entities.

In some embodiments, a client, such as analyzer 100, may issue a request on behalf of the client to determine equivalence between two security policies. In some embodiments, the request may include a web API request that encodes the security policy to be analyzed as part of the request. However, in some embodiments, the secure 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, the web API request is transmitted from the analyzer 100 to a computing resource service provider, such as the provider network 190. The request may be fulfilled by the policy comparison service 180. First security policy 804A may be parsed to obtain one or more rights statements 806A, and rights statements 806A may be converted into a first set of propositional logic expressions 808 that may act as constraints on the propositional logic formula. Likewise, second security policy 804B may be parsed to obtain one or more rights statements 806B, and rights statements 806B may be parsed to obtain a second set of propositional logic expressions 808 that may act as constraints. The service 180 can utilize the satisfiability engine 812 to determine whether two proposition logic expressions are equivalent, whether one proposition logic expression is more tolerant than the other proposition logic expression, and so on.

In some embodiments, the equivalence result 812 may indicate that the two policies are equivalent. Two policies can be said to be equivalent if security rights from the first policy and the second policy apply in the same manner to all actions, resources, and principals such that for any given set of actions, resources, and principals, both the first policy and the second policy will deny access (either explicitly based on a denial statement or implicitly based on lack of rights to grant access) or both will grant access. In some embodiments, there is no case where one policy grants access and another policy denies access. In some embodiments, where it is determined that one policy is more tolerant than another, a situation will occur in which one policy grants access under the set of parameters under which the other policy denies access.

In some implementations, the equivalence result 812 can be transmitted to the analyzer 100 as a response to the web API request. In some implementations, the equivalence result 812 can encode rights results (e.g., whether one policy is more tolerant than a second policy). In some embodiments, other information is provided instead of or in addition to the tolerant results. For example, where the first policy is more tolerant than the 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., the principal, resource, and action may be encoded in the response such that the first policy will grant the principal access to perform the action on the resource and the second policy will deny the principal access to avoid performing the action on the resource).

Exemplary computer System

In at least some embodiments, a computer system implementing a portion or all of one or more of the techniques described herein may comprise a computer system that is accessible or configured to access one or more computer-readable media. Fig. 9 illustrates such a computing device 900. In the illustrated embodiment, computing device 900 includes one or more processors 910A-910N coupled to a system memory 920 through an input/output (I/O) interface 930. Computing device 900 also includes a network interface 940 that is coupled to I/O interface 930.

In various embodiments, computing device 900 may be a single processor system including one processor, or a multi-processor system including several processors 910A through 910N (e.g., two, four, eight, or another suitable number). Processors 910A through 910N may include any suitable processor capable of executing instructions. For example, in various embodiments, processors 910A through 910N may be processors implementing any of a variety of Instruction Set Architectures (ISAs), such as the x86, powerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In a multiprocessor system, each of processors 910A-910N may typically, but need not necessarily, implement the same ISA.

The system memory 920 may be configured to store program instructions and/or data that are accessible to the processors 910A-910N. In various embodiments, system memory 920 may be implemented using any suitable memory technology, such as Static Random Access Memory (SRAM), synchronous Dynamic RAM (SDRAM), non-volatile/flash memory, or any other type of memory. In the illustrated embodiment, program instructions and data (such as those methods, techniques, and data described above) that implement one or more desired functions are shown stored as code (i.e., program instructions) 925 and data 926 in system memory 920. In the illustrated embodiment, system memory 920 also stores program codes and data implementing aspects of access control analyzer 100 discussed above.

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

The network interface 940 may be configured to allow data to be exchanged between the computing device 900 and other devices 960 attached to one or more networks 950. In various embodiments, network interface 940 may support communication over any suitable wired or wireless general-purpose data network, such as other types of ethernet networks, for example. In addition, network interface 940 may support communication over a telecommunications/telephony network (such as an analog voice network or a digital fiber communications network), over a storage area network (such as a fibre channel SAN), or over any other suitable type of network and/or protocol.

In some embodiments, system memory 920 may be one embodiment of a computer-readable (i.e., 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 codes and data associated with access control analyzer 100. In other embodiments, program instructions and/or data may be received, transmitted, or stored on different types of computer-readable media. In general, computer-readable media may include non-transitory storage media or memory media, such as magnetic media or optical media, e.g., magnetic disks or DVD/CDs coupled to computing device 900 through I/O interface 930. Non-transitory computer-readable storage media may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in some embodiments of computing device 900 as system memory 920 or another type of memory. Furthermore, computer-readable media may include transmission media or signals (such as electrical, electromagnetic, or digital signals) conveyed via a communication medium (such as a network and/or wireless link), such as may be implemented through network interface 940. Some or all of the plurality of computing devices (such as the computing device shown in fig. 9) may be used to implement the functionality described in the various embodiments; for example, software components running on various different devices and servers may cooperate to provide functionality. In some implementations, portions of the described functionality may be implemented using storage devices, network devices, or various types of computer systems. As used herein, the term "computing device" refers to at least all of these types of devices, and is not limited to these types of devices.

The various methods shown in the figures and described herein represent examples of embodiments of the methods. The method may be implemented in software, hardware, or a combination thereof. In various methods, the order of steps may be changed, and addition, reordering, combining, omitting, modifying, etc., of various elements may be performed. The various steps may be performed automatically (e.g., without direct prompting by user input) and/or programmatically (e.g., according to program instructions).

The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the description of the invention and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It is also to be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term "if" may be interpreted to mean "when … …", "at … …" or "in response to a determination" or "in response to detection", depending on the context. Similarly, the term "if determined" or "if [ stated condition or event ] is detected" may be interpreted to mean "upon determination … …" or "in response to determination" or "upon detection of [ stated condition or event ] or" in response to detection of [ stated condition or event ] "depending on the context.

It will be further understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first contact may be referred to as a second contact, and similarly, a second contact may be referred to as a first contact, without departing from the scope of the invention. The first contact and the second contact are both contacts, but they are not the same contacts.

Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, it will be understood by those skilled in the art that the claimed subject matter may be practiced without these specific details. In other instances, methods, devices, or systems known by those of ordinary skill have not been described in detail so as not to obscure the claimed subject matter. Various modifications and alterations will become apparent to those skilled in the art having the benefit of this disclosure. It is intended that all such modifications and changes be included herein, and therefore, the above description should be regarded in an illustrative rather than a restrictive sense.

The foregoing may be better understood in view of the following clauses:

clause 1. A system, comprising:

an access control analyzer 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, wherein the nodes represent a plurality of roles in a provider network hosting a plurality of services and resources, wherein the nodes comprise 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 grant or deny access based at least in part on one or more key-value tags; and is also provided with

Based at least in part on the role reachability analysis of the graph, determining whether the first role is capable of functioning as the second role using one or more role-functioning steps, wherein individual ones of the role-functioning steps provide temporary access during a role session, and wherein the one or more key-value labels include one or more transitive labels that persist during the one or more role-functioning steps.

Clause 2 the system of clause 1, wherein the access control policy allows the first persona to assume the second persona if the first persona provides a session tag that matches a condition associated with the second persona.

Clause 3 the system of clause 2, wherein the condition associated with the second role comprises one or more wild cards of a value of a key.

Clause 4 the system of any of clauses 1-2, wherein the map is determined by: one or more neighbors of a particular node in the graph are found based at least in part on the set of key-value tags whose keys and corresponding conditions are explicitly indicated in the access control policy, or by underspecified key-value tags whose values are unrestricted or partially restricted.

Clause 5. A method, comprising:

determining, by an access control analyzer, a graph comprising a plurality of nodes and one or more edges, wherein the nodes represent a plurality of roles in a provider network hosting a plurality of resources, wherein the nodes comprise 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 resources, and wherein one or more of the access control policies grant or deny access based at least in part on one or more attributes; and

Determining, by the access control analyzer, whether the first persona is capable of functioning as the second persona using one or more personas for a particular state of the one or more properties based at least in part on a persona reachability analysis of the graph, and wherein the one or more properties include one or more transitive properties that persist during the one or more personas functioning as steps.

Clause 6. The method of clause 5, wherein the access control policy allows the first persona to assume the second persona if the first persona provides a session attribute that matches a condition associated with the second persona.

Clause 7 the method of clause 6, wherein the condition associated with the second role comprises one or more wild cards of the value of the key.

The method of any one of clauses 5 to 7, further comprising:

one or more boundary conditions for the one or more attributes are aggregated, wherein the one or more boundary conditions are indicated by one or more of the access control policies associated with the one or more role-playing steps.

Clause 9 the method of any of clauses 5 to 8, wherein one or more neighbors of a particular node in the graph are determined based at least in part on the set of attributes whose keys and corresponding conditions are explicitly indicated in the access control policy.

Clause 10 the method of any of clauses 5 to 9, determining one or more neighbors of a particular node in the graph based at least in part on attributes of which values are unrestricted or partially restricted.

Clause 11 the method of any of clauses 5 to 10, wherein the first persona is in a first account of the provider network, and wherein the second persona is in a second account of the provider network.

The method of any one of clauses 5 to 11, further comprising:

based at least in part on determining that the first role can take the second role, a notification of security discovery regarding configuration of the access control policy is generated.

Clause 13, one or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, perform:

Determining, by an access control analyzer, a graph comprising a plurality of nodes and one or more edges, wherein the nodes represent a plurality of roles in a provider network hosting a plurality of services or resources, wherein the nodes comprise 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 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 labels; and

determining, by the access control analyzer, whether the first persona is capable of functioning as the second persona using one or more personas for a particular state of the one or more personas based at least in part on a persona reachability analysis of the graph, and wherein the one or more personas include one or more transitive personas that persist during the one or more personas functioning as steps.

Clause 14 the one or more non-transitory computer-readable storage media of clause 13, wherein the access control policy allows the first persona to assume the second persona if the first persona provides a session tag that matches a condition associated with the second persona.

Clause 15 the one or more non-transitory computer-readable storage media of clause 14, wherein the condition associated with the second role does not include one or more wild cards of the value of the key.

Clause 16 the one or more non-transitory computer-readable storage media of clauses 13-15, further comprising additional program instructions that, when executed on or across the one or more processors, perform:

one or more boundary conditions for the one or more attributes are aggregated, wherein the one or more boundary conditions are indicated by one or more of the access control policies associated with the one or more role-playing steps.

Clause 17 the one or more non-transitory computer-readable storage media of any of clauses 13-16, wherein the map is determined based at least in part on one or more of the labels having keys explicitly indicated in the access control policy.

Clause 18 the one or more non-transitory computer-readable storage media of any of clauses 13-17, wherein the graph is determined based at least in part on one or more boundary conditions for applying the one or more labels, wherein the one or more boundary conditions are indicated by one or more access control policies in the access control policy associated with the one or more role-playing steps.

Clause 19 the one or more non-transitory computer-readable storage media of clauses 13-18, further comprising additional program instructions that, when executed on or across the one or more processors, perform:

monitoring calls to the plurality of services in the provider network; and

if the call is determined to change the state of the provider network, the role reachability analysis is restarted.

Clause 20 the one or more non-transitory computer-readable storage media of 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.

Clause 21, a system, comprising:

an access control analyzer 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, wherein the first node corresponds to a first role in a provider network hosting a plurality of services and resources, wherein the first role is associated with a first access control policy, and wherein the first access control policy grants or denies access to a first service and resource of the services and resources;

Determining 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 or denies access to a second service and resource of the services and resources;

performing a role reachability analysis that determines whether the first role is capable of functioning as the second role for a particular state of one or more key-value tags, wherein one or more role functioning steps provide temporary access during a role session, wherein the role reachability analysis determines a third access control policy that authorizes a role functioning as a complement to a request for the second role, wherein the role reachability analysis determines whether the first role is capable of functioning as the second role based at least in part on an analysis of the third access control policy for the particular state of the one or more key-value tags relative to a role functioning policy of the second role, and wherein the role functioning request is not authorized if the third access control policy does not include the role functioning policy of the second role for the particular state of the one or more key-value tags; and is also provided with

Based at least in part on the role reachability analysis, a principal in the first role is granted or denied access to the second one of the services and resources.

Clause 22 the system of clause 21, wherein the role of the second role is extended to include one or more statements rejecting requests failing to satisfy one or more conditions of the role of the second role in the policy.

Clause 23 the system of any of clauses 21 to 22, wherein the one or more conditions under which the character of the second character acts as a policy comprise one or more wild cards of 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 of the one or more key-value labels from a range of potential values of the one or more key-value labels, wherein the range of potential values is determined based at least in part on the one or more wild cards, and wherein the particular state of the one or more key-value labels is determined based at least in part on the one or more representative values of the one or more key-value labels.

Clause 25, a method comprising:

determining, by an access control analyzer, a first node in a graph, wherein the first node corresponds to a first role in a provider network hosting a plurality of resources, wherein the first role is associated with a first access control policy, and wherein the first access control policy grants or denies access to a first one or more of the resources;

determining, by the access control analyzer, 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 or denies access to a second one or more of the resources; and

performing, by the access control analyzer, a role reachability analysis that determines whether the first role is capable of functioning as the second role for a particular state of one or more attributes, the role reachability analysis comprising:

determining a negative third access control policy authorizing a role for the second role to assume a request; and

Determining whether the first persona is capable of assuming the second persona based at least in part on an analysis of the third access control policy by a persona assuming policy for the particular state of the one or more properties relative to the second persona.

The method of clause 26, clause 25, further comprising:

based at least in part on the role reachability analysis, a principal in the first role is granted or denied access to the second one or more of the resources.

Clause 27 the method of clauses 25-26, wherein the role play policy of the second role is extended to include one or more statements rejecting requests failing to satisfy one or more conditions of the role play policy of the second role.

The method of any of clauses 25 to 27, wherein the role play request is not authorized if the third access control policy does not include the role play policy of the second role for the particular state of the one or more attributes.

Clause 29 the method of any of clauses 25 to 28, wherein the role reachability analysis invokes a policy comparison service that determines an equivalence result of the role of the third access control policy and the second role to act as a policy for the particular state of the one or more attributes.

The method of any of clauses 25 to 29, wherein the one or more conditions under which the character of the second character acts as a policy include one or more wild cards of the one or more attributes.

Clause 31 the method of clause 30, wherein performing the role reachability analysis further comprises:

one or more representative values of the one or more attributes are selected from a range of potential values of the one or more attributes, wherein the range of potential values is determined based at least in part on the one or more wild cards, and wherein the particular state of the one or more attributes is determined based at least in part on the one or more representative values of the one or more attributes.

The method of any one of clauses 25 to 31, further comprising:

based at least in part on determining that the first role can take the second role, a notification of security discovery of access control policy configuration is generated.

Clause 33, one or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, perform:

Determining, by an access control analyzer, a first node in a graph, wherein the first node corresponds to a first role in a provider network hosting a plurality of services or resources, wherein the first role is associated with a first access control policy, and wherein the first access control policy grants or denies access to a first one or more of the services or resources;

determining, by the access control analyzer, 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 or denies access to a second one or more of the services or resources; and

performing, by the access control analyzer, a role reachability analysis that determines whether the first role is capable of assuming the second role for a particular state of one or more tags, the role reachability analysis comprising:

determining a third access control policy authorizing a role for the second role to act as a complement to the request; and

Determining whether the first persona is capable of assuming the second persona based at least in part on an analysis of the third access control policy for a role assuming policy for the particular state of the one or more tags relative to the second persona.

Clause 34 the one or more non-transitory computer-readable storage media of clause 33, further comprising additional program instructions that, when executed on or across the one or more processors, perform:

based at least in part on the role reachability analysis, a user in the first role is granted or denied access to the second one or more of the services or resources.

Clause 35 the one or more non-transitory computer-readable storage media of clauses 33-34, wherein the role play policy of the second role is extended to include one or more statements rejecting requests that fail to satisfy one or more conditions of the role play policy of the second role.

Clause 36 the one or more non-transitory computer-readable storage media of any of clauses 33-35, wherein the role play request is not authorized if the third access control policy does not include the role play policy of the second role for the particular state of the one or more tags.

Clause 37 the one or more non-transitory computer-readable storage media of any of clauses 33-36, wherein the role reachability analysis invokes a policy comparison service that determines an equivalence result of the third access control policy and the role of the second role to act as a policy for the particular state of the one or more tags.

The one or more non-transitory computer-readable storage media of any one of clauses 33-37, wherein the one or more conditions under which the character of the second character acts as a policy comprise one or more wild cards of the one or more tags.

Clause 39 the one or more non-transitory computer-readable storage media of clause 38, further comprising additional program instructions that, when executed on or across the one or more processors, perform:

one or more representative values of the one or more tags are selected from a range of potential values of the one or more tags, wherein the range of potential values is determined based at least in part on the one or more wild cards, 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 of the one or more tags.

Clause 40 the one or more non-transitory computer-readable storage media of clauses 33-39, further comprising additional program instructions that, when executed on or across the one or more processors, perform:

based at least in part on determining that the first role can take the second role, a notification of security discovery of access control policy configuration is generated.

Claims (15)

1. A system, comprising:

an access control analyzer 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, wherein the nodes represent a plurality of roles in a provider network hosting a plurality of services and resources, wherein

The node includes 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 grant or deny access based at least in part on one or more key-value tags; and is also provided with

Based at least in part on the role reachability analysis of the graph, determining whether the first role is capable of functioning as the second role using one or more role-functioning steps, wherein individual ones of the role-functioning steps provide temporary access during a role session, and wherein the one or more key-value labels include one or more transitive labels that persist during the one or more role-functioning steps.

2. The system of claim 1, wherein the access control policy allows the first persona to assume the second persona if the first persona provides a session tag that matches a condition associated with the second persona.

3. The system of claim 2, wherein the condition associated with the second role comprises one or more wild cards of a value of a key.

4. A system as claimed in any one of claims 1 to 3, wherein the map is determined by: one or more neighbors of a particular node in the graph are found based at least in part on the set of key-value tags whose keys and corresponding conditions are explicitly indicated in the access control policy, or by underspecified key-value tags whose values are unrestricted or partially restricted.

5. A method, comprising:

determining, by an access control analyzer, a graph comprising a plurality of nodes and one or more edges, wherein the nodes represent a plurality of roles in a provider network hosting a plurality of resources, wherein the nodes comprise 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 resources, and wherein one or more of the access control policies grant or deny access based at least in part on one or more attributes; and

determining, by the access control analyzer, whether the first persona is capable of functioning as the second persona using one or more personas for a particular state of the one or more properties based at least in part on a persona reachability analysis of the graph, and wherein the one or more properties include one or more transitive properties that persist during the one or more personas functioning as steps.

6. The method of claim 5, wherein the access control policy allows the first persona to assume the second persona if the first persona provides a session attribute that matches a condition associated with the second persona.

7. The method of claim 6, wherein the condition associated with the second role comprises one or more wild cards of a value of a key.

8. The method of any one of claims 5 to 7, further comprising:

one or more boundary conditions for the one or more attributes are aggregated, wherein the one or more boundary conditions are indicated by one or more of the access control policies associated with the one or more role-playing steps.

9. The method of any of claims 5 to 8, wherein one or more neighbors of a particular node in the graph are determined based at least in part on a set of the attributes whose keys and corresponding conditions are explicitly indicated in the access control policy.

10. The method of any of claims 5 to 9, determining one or more neighbors of a particular node in the graph based at least in part on an underspecified attribute whose value is unrestricted or partially restricted.

11. The method of any of claims 5 to 10, wherein the first persona is in a first account of the provider network, and wherein the second persona is in a second account of the provider network.

12. The method of any one of claims 5 to 11, further comprising:

based at least in part on determining that the first role can take the second role, a notification of security discovery regarding configuration of the access control policy is generated.

13. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, perform:

determining, by an access control analyzer, a graph comprising a plurality of nodes and one or more edges, wherein the nodes represent a plurality of roles in a provider network hosting a plurality of services or resources, wherein the nodes comprise 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 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 labels; and

determining, by the access control analyzer, whether the first persona is capable of functioning as the second persona using one or more personas for a particular state of the one or more personas based at least in part on a persona reachability analysis of the graph, and wherein the one or more personas include one or more transitive personas that persist during the one or more personas functioning as steps.

14. The one or more non-transitory computer-readable storage media of claim 13, further comprising additional program instructions that, when executed on or across the one or more processors, perform:

monitoring calls to the plurality of services in the provider network; and

if the call is determined to change the state of the provider network, the role reachability analysis is restarted.

15. The one or more non-transitory computer-readable storage media of 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.