EP4348475A2

EP4348475A2 - Compliance of access permissions in identity and access management (iam) systems

Info

Publication number: EP4348475A2
Application number: EP22812307.1A
Authority: EP
Inventors: Matthew A. GHIOLD; Gavin MCGREW; Devon Powley; Christopher Schultz; Muhammad Saad TAHIR; James SIMONETTI; Britton LEE; Joseph Chen; John VALIN; Anika GERA; Nicholas MIRALLEGRO; Jessica FEINSTEIN; Nicholas KOTAKIS
Original assignee: Capital One Services LLC
Current assignee: Capital One Services LLC
Priority date: 2021-05-28
Filing date: 2022-05-27
Publication date: 2024-04-10
Also published as: EP4348475A4; WO2022251702A2; WO2022251702A3

Abstract

Disclosed herein are system, method, and computer program product embodiments for generating a list of deny policy statements associated with an allow policy statement with respect to the effective access permissions for a principal in an identity and access management system. The operations can include identifying a first policy statement that specifies members of a first identity set including the principal are allowed to access a first system resource set. The operations further include identifying a second policy statement specifying that members of a second identity set are denied access to a second system resource set. Moreover, the operations include determining that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal, and placing the second policy statement into the list of deny policy statements associated with an allow policy statement.

Description

COMPLIANCE OF ACCESS PERMISSIONS IN IDENTITY AND ACCESS

MANAGEMENT (IAM) SYSTEMS

RELATED APPLICATION

[0001] This application claims priority to U.S. Application No. 17/333,425, filed on May

28, 2021, U.S. Application No. 17/333,454, filed on May 28, 2021, U.S. Application No. 17/333,469, filed on May 28, 2021, which are incorporated herein by reference in their entireties.

BACKGROUND

[0002] Computer applications often have to provide access control (AC) to system resources. AC is concerned with determining the allowed activities of legitimate users, roles, or principals, mediating every request to access a system resource in the system. Identity and access management (IAM) is a framework of business processes, policies and technologies that facilitates the management of electronic or digital identities of principals and system resources.

[0003] With an IAM framework in place, information technology managers can manage

AC to information or system resources within their organizations. IAM systems can be deployed on premises, provided by a third-party vendor through a cloud-based subscription model, or deployed in a hybrid model. An IAM system can evaluate whether a user, a role, or a principal can access a system resource protected by the IAM system on a per-request basis. An IAM system can receive a request to access a system resource. The IAM system can evaluate whether to allow or deny the requested access to the system resource based on a set of security policies assigned to the user, the role, or the principal.

[0004] For security purposes, it is important to have the right security policies so that an

IAM system can grant a principal access only to the system resources the principal is supposed to access. Accordingly, approaches are needed to ensure that the IAM system is limiting access appropriately.

[0005] Computer applications often involve access control (AC) to system resources. AC is concerned with determining the allowed activities of legitimate users, mediating every request by a role to access a system resource in the system. Identity and access management (IAM) is a framework of business processes, policies and technologies that facilitates the management of electronic or digital identities of roles and system resources. With an IAM framework in place, information technology managers can manage AC to information or system resources within their organizations.

[0006] IAM systems can be deployed on premises, provided by a third-party vendor through a cloud-based subscription model, or deployed in a hybrid model. An IAM system can evaluate whether a role can access a system resource protected by the IAM system on a per-request basis. An IAM system can receive from a role a request to access a system resource. The IAM system can evaluate whether to grant or deny the requested access to the system resource based on a set of security policies assigned to the role. Current IAM systems still have many security issues that need further improvements.

[0007] Almost all computer applications involve access control (AC) to system resources. AC is concerned with determining the allowed activities of legitimate users, mediating every request by a role to access a system resource in the system. Identity and access management (IAM) is a framework of business processes, policies and technologies that facilitates the management of electronic or digital identities of roles and system resources. With an IAM framework in place, information technology managers can manage AC to information or system resources within their organizations. IAM systems can be deployed on premises, provided by a third-party vendor through a cloud-based subscription model, or deployed in a hybrid model. An IAM system can evaluate whether a role can access a system resource protected by the IAM system on a per-request basis. An IAM system can receive from a role a request to access a system resource and evaluate whether to grant or deny the requested access to the system resource. For security purposes, it is important for an IAM system to grant a role access only to the system resources the role is supposed to access. Accordingly, approaches are needed to ensure that the IAM system is limiting role access appropriately.

BRIEF SUMMARY

[0008] Disclosed herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof for evaluating effective access permissions defined by a set of security policies for a principal, where the principal can be an identity and access management (IAM) user, an IAM role, or an application. A security policy can include multiple policy statements. Hence, there can be many security policy statements associated with a principal in an IAM system. Some policy statements may allow access to a system resource set of the IAM system, while some other policy statements may deny access to a system resource set of the IAM system. The effective access permissions for the principal is the overall access permissions defined by all the policy statements of the entire set of security policies. In order to evaluate the effective access permissions for a principal, embodiments herein classify the policy statements of the security policies into a set of allow policy statements, and a set of deny policy statements. The set of allow policy statements includes policy statements that specify that members of an identity set including the principal are allowed to access a system resource set of the IAM system. The set of deny policy statements includes policy statements that specify that members of an identity set are denied access to a system resource set of the IAM system. For an allow policy statement of the set of allow policy statements, embodiments determine a list of deny policy statements associated with the allow policy statement with respect to the effective access permissions. A deny policy statement is included in the list of deny policy statements associated with the allow policy statement when there is a shared system resource belonging to the system resource set of the allow policy statement and the system resource set of the deny policy statement, and the identity set of the deny policy statement includes the principal. The effective access permissions associated with the principal are defined by a system resource included in the system resource set of the allow policy statement but not included in the system resource set of the deny policy statement.

[0009] In some examples, a computer-implemented method is presented for evaluating effective access permissions defined by security policies associated with a principal managed by an IAM system. The method includes identifying a first policy statement associated with the principal, and identifying a second policy statement. The first policy statement specifies that members of a first identity set including the principal are allowed to access a first system resource set of the IAM system, while the second policy statement specifies that members of a second identity set are denied access to a second system resource set of the IAM system. The method further includes determining whether or not there is a shared system resource belonging to both the first system resource set and the second system resource set, and whether or not the second identity set includes the principal. When the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal, the method includes determining that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal. The effective access permissions associated with the principal are defined by a system resource included in the first system resource set but not included in the second system resource set. The method further includes placing, when the second policy statement is determined to overlap with the first policy statement, the second policy statement into a list of policy statements associated with the first policy statement with respect to the effective access permissions.

[0010] Descriptions provided in the summary section represent only examples of the embodiments. Other embodiments in the disclosure may provide varying scopes different from the description in the summary. In some examples, systems and computer program products of the disclosed embodiments may include a computer-readable device storing computer instructions for any of the methods disclosed herein or one or more processors configured to read instructions from the computer readable device to perform any of the methods disclosed herein.

[0011] Disclosed herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof for displaying a compliance status of a role of an identity and access management (IAM) system with respect to a set of security rules. The compliance status is determined by comparing a permissible scope of a name for a system resource defined by the set of security rules with a scope of the name for the system resource defined by a set of security policies, and by comparing a permissible scope of a name for a role defined by the set of security rules with a scope of the name for the role defined by the set of security policies. Multiple roles and their corresponding compliance status can be displayed in various forms on a graphical user interface (GUI), e.g., in a tabular form on the GUI.

[0012] In some examples, a computer-implemented method performed by a system can include selecting a first role administered by an entity and a second role administered by the entity. Afterwards, the method includes determining, based on a set of security rules, a first compliance status of the first role associated with a first set of security policies; and determining, based on the set of security rules, a second compliance status of the second role associated with a second set of security policies. In addition, the method includes displaying on a GUI, the first role and the first compliance status with respect to the set of security rules, and the second role and the second compliance status with respect to the set of security rules. In some examples, the first role and the first compliance status, and the second role and the second compliance status are displayed in a tabular form on the GUI.

[0013] In some examples, an apparatus for managing system resources can include a display device configured to display a GUI, a storage device coupled to the display device and configured to store a set of security rules, and a processor communicatively coupled to the storage device and the display device. The processor can be configured to select a first role administered by an entity and a second role administered by the entity. The processor can be further configured to determine, based on the set of security rules, a first compliance status of the first role associated with a first set of security policies; and determine, based on the set of security rules, a second compliance status of the second role associated with a second set of security policies. In addition, the processor can be configured to display on the GUI, the first role and the first compliance status with respect to the set of security rules, and the second role and the second compliance status with respect to the set of security rules.

[0014] In some examples, a non-transitory computer-readable medium can store instructions that, when executed by a processor, cause the processor to perform various operations. The operations can include selecting a first role administered by an entity and a second role administered by the entity. In addition, the operations include determining, based on a set of security rules, a first compliance status of the first role associated with a first set of security policies; and determining, based on the set of security rules, a second compliance status of the second role associated with a second set of security policies. In addition, the operations include displaying on a GUI, the first role and the first compliance status with respect to the set of security rules, and the second role and the second compliance status with respect to the set of security rules.

[0015] Descriptions provided in the summary section represent only examples of the embodiments. Other embodiments in the disclosure may provide varying scopes different from the description in the summary. In some examples, systems and computer program products of the disclosed embodiments may include a computer-readable device storing computer instructions for any of the methods disclosed herein or one or more processors configured to read instructions from the computer readable device to perform any of the methods disclosed herein.

[0016] Disclosed herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof for determining, whether a role has an access permission to a system resource defined by a set of security policies that is over-privileged with respect to a set of security rules.

[0017] In some examples, a computer-implemented method performed by a system can include comparing a scope of a name for a system resource defined in a first security policy with a permissible scope of the name for the system resource defined in a security rule to obtain a first comparison result, and comparing a scope of a name for a role defined in a second security policy with a permissible scope of the name for the role defined by the security rule to obtain a second comparison result. Afterwards, the method includes determining, based on the first comparison result and the second comparison result, whether or not the role has an over-privileged access permission contained in a set of effective access permissions to the system resource defined by the first security policy and the second security policy. In addition, the method includes generating a notification to indicate a compliance status of the first security policy and the second security policy for the role based on whether or not the role has the over-privileged access permission.

[0018] In some examples, an apparatus for managing system resources can include a storage device configured to store a security rule set, and a processor communicatively coupled to the storage device. The processor can be configured to compare a scope of a name for a system resource defined in a first security policy with a permissible scope of the name for the system resource defined by a security rule to obtain a first comparison result, and compare a scope of a name for a role defined in a second security policy with a permissible scope of the name for the role defined by the security rule to obtain a second comparison result. Furthermore, the processor can be configured to determine, based on the first comparison result and the second comparison result, whether or not the role has an over-privileged access permission contained in a set of effective access permissions to the system resource defined by the first security policy and the second security policy. Afterwards, the processor can be configured to generate a notification to indicate a compliance status of the first security policy and the second security policy for the role based on whether or not the role has the over-privileged access permission.

[0019] In some examples, a non-transitory computer-readable medium can store instructions that, when executed by a processor, cause the processor to perform various operations. The operations can include comparing a scope of a name for a system resource defined in a first security policy with a permissible scope of the name for the system resource defined by a security rule to obtain a first comparison result, and comparing a scope of a name for a role defined in a second security policy with a permissible scope of the name for the role defined by the security rule to obtain a second comparison result. In addition, the operations can include determining, based on the first comparison result and the second comparison result, whether or not the role has an over privileged access permission contained in a set of effective access permissions to the system resource defined by the first security policy and the second security policy. Furthermore, the operations can include generating a notification to indicate a compliance status of the first security policy and the second security policy for the role based on whether or not the role has the over-privileged access permission.

[0020] Descriptions provided in the summary section represent only examples of the embodiments. Other embodiments in the disclosure may provide varying scopes different from the description in the summary. In some examples, systems and computer program products of the disclosed embodiments may include a computer-readable device storing computer instructions for any of the methods disclosed herein or one or more processors configured to read instructions from the computer readable device to perform any of the methods disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the arts to make and use the embodiments.

[0022] FIG. l is a block diagram of an environment for evaluating effective access permissions defined by a set of security policies associated with a principal in an identity and access management (IAM) system, according to some embodiments. [0023] FIGS. 2A-2B illustrate example security policy statements of a security policy and rules for resolving conflicts between security policy statements, according to some embodiments.

[0024] FIG. 3 illustrates example effective access permissions defined by a set of security policies associated with a principal, according to some embodiments.

[0025] FIGS. 4A-4C illustrate example methods for evaluating effective access permissions defined by a set of security policies associated with a principal, according to some embodiments.

[0026] FIG. 5 is an example computer system useful for implementing various embodiments.

[0027] FIG. 6 is a block diagram of an environment for displaying a compliance status of a role of an identity and access management (IAM) system with respect to a set of security rules, according to some embodiments.

[0028] FIGS. 7A-7B are diagrams illustrating example security policies and a set of effective access permissions defined by security policies used in determining a compliance status of a role, according to some embodiments.

[0029] FIG. 8 is a flowchart illustrating a method for displaying a compliance status of a role with respect to a set of security rules, according to some embodiments.

[0030] FIGS. 9A-9C are diagrams illustrating example displays of a compliance status of a role with respect to a set of security rules, according to some embodiments.

[0031] FIG. 10 is an example computer system useful for implementing various embodiments.

[0032] FIG. 11 is a block diagram of an environment for determining whether a role has an effective access permission defined by a set of security policies to a system resource that is over-privileged with respect to a security rule, according to some embodiments.

[0033] FIGS. 12A-12B are diagrams illustrating example security policies, according to some embodiments.

[0034] FIGS. 13A-13D are diagrams illustrating example effective access permissions defined by a set of security policies, according to some embodiments.

[0035] FIG. 14 is a flowchart illustrating a method for determining whether a role has an effective access permission defined by a set of security policies to a system resource that is over-privileged with respect to a security rule, according to some embodiments. [0036] FIG. 15 is an example computer system useful for implementing various embodiments.

[0037] In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

DETAILED DESCRIPTION

[0038] Identity and access management (IAM) is a framework of business processes, policies, and technologies that facilitates the management of electronic or digital identities of users, roles, or principals, and system resources. A principal can include an IAM user, an IAM role, or an application. In the following, a role can be used as an example of a principal. Descriptions about a role can be applicable to a principal.

[0039] IAM systems can provide access control to system resources by a principal on a per-request basis. In general, an IAM system can grant or deny a request from a principal to access system resources based on access permissions assigned to the principal by one or more security policies. Such a request can be received from an enterprise system, and the request can identify the principal. The following discussion presents interactions between an IAM system and an enterprise system but one skilled in the art would understand that the interactions apply to any requesting system that seeks access to a system resource based on access controls. The requesting system is therefore not limited to an enterprise system but any system that uses principals and permissions as part of access control to the system resource. A request for access can be granted or allowed, which are used interchangeably in the current description.

[0040] The request-response dynamic between the IAM system and an enterprise system presents challenges to the requesting system. First, the requesting system is not informed of any potential issues with respect to principals in its system until a request is made to the IAM system. Any corrective action to its principals is therefore reactive and presents a potential security concern because principals are not evaluated until a request is made. This provides an opportunity for compromised and/or over-privileged principals (e.g., by a hacker) to be hijacked and used to improperly gain access to system resources. Second, the requesting system relies on the IAM system in determining whether its principals are compliant with permission controls for accessing system resources. [0041] The features described in this disclosure allow for an enterprise system to monitor access permission compliance of principals with access control (AC) for accessing system resources of an IAM system without any requests being made. Access privileges or permissions to system resources by a principal are granted according to security policies. There are many kinds of security policies, which work together to provide effective access permissions for a principal to access system resources. However, due to the complexity of many security policies, sometimes a principal can have an unintended, improper, or over-privileged access permission to some system resources for which the principal should not have access to. For security reasons, it is important to prevent a principal from having an over-privileged access permission to system resources. In some embodiments, the enterprise system can detect over-privileged access permissions because the operations are performed by the enterprise system independent of the IAM system. Accordingly, the mechanisms discussed in the current disclosure are implemented by a machine with a specific arrangement, where the policy engine is separated from the IAM system to provide more security protection for the IAM system. In some embodiments, the enterprise system detecting over-privileged access permissions is separated from the IAM system.

[0042] In some examples, an over-privileged access permission is detected by comparing permissible scopes of access permissions defined by a set of security rules with a set of effective access permissions defined by a set of security policies associated with the principal. Based on the set of effective access permissions, an enterprise system can perform preemptive evaluation of access permissions associated with a principal to identify any over-privileged access permission of the principal to system resources.

Hence, the enterprise system can detect over-privileged access permissions associated with a principal in an IAM system without having to submit any requests to the IAM system.

[0043] Accordingly, in order to identify any over-privileged access permission, it is important to determine the effective access permissions defined by security policies associated with the principal managed by the IAM system. When the number of security policies associated with a principal can be in the magnitude of hundreds of thousands or millions, it becomes infeasible to evaluate the effective access permissions defined by security policies by hand or by visual inspection. Effective mechanisms are needed for an enterprise system to evaluate the effective access permissions defined by security policies associated with the principal.

[0044] Embodiments herein present mechanisms to evaluate the effective access permissions defined by security policies associated with a principal. A security policy can include multiple policy statements. Instead of performing the evaluation for individual security policies, embodiments herein classify the policy statements of the security policies into a set of allow policy statements, and a set of deny policy statements. Such a classification can improve the efficiency of the effective access permissions evaluation compared to the evaluation based on security policies. In addition, the effective access permissions is represented by a specially designed structure, which further improves the efficiency of the computation, the compactness of the representation, and the readability of the resulting effective access permissions by a human user or administrator. For each allow policy statement of the set of allow policy statements, a list of deny policy statements associated with the allow policy statement with respect to the effective access permissions is identified. The effective access permissions associated with the principal related to the allow policy statement are defined by a system resource included in the system resource set of the allow policy statement but not included in the system resource set of the list of deny policy statements. The total effective access permissions associated with the principal is the union of all the effective access permissions associated with the principal related to the allow policy statements in the set of allow policy statements.

[0045] FIG. 1 is a block diagram of an environment 100 for evaluating effective access permissions defined by a set of security policies associated with a principal in an IAM system. Environment 100 can include enterprise system 110, policy engine 120, and IAM system 131, which can reside in a cloud computing system 130. Policy engine 120 can generate the set of effective access permissions 125. Based on the set of effective access permissions 125, environment 100 can be used to determine a compliance status of a principal of the IAM system with respect to a set of security rules 124. In addition, enterprise system 110 can be communicatively coupled to a computing device 140 that can be used by a person 142.

[0046] In some examples, environment 100 can include a network formed by some or all of computing device 140, enterprise system 110, and cloud computing system 130. For example, environment 100 can include an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless wide area network (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, any other type of network, or a combination of two or more such networks.

[0047] In some examples, cloud computing system 130 can include an environment that delivers computing as a service or shared resources. Cloud computing system 130 can provide computation, software, data access, storage, and/or other services that do not require end-user knowledge of a physical location and configuration of a system and/or a device that delivers the services. In some examples, cloud computing system 130 can include Amazon® Web Services (AWS), Microsoft® Azure, Google® Cloud, IBM® Cloud, Oracle® Cloud Infrastructure, or any other cloud computing system.

[0048] Cloud computing system 130 can include IAM system 131, which can manage system resources 133. IAM system 131 can receive a request 191 for access to system resources 133 from entities in enterprise system 110 such as principal 111. Principal 111 can be auser 116, a role 113, a machine 115, or an application 151. IAM system 131 can include a plurality of data storage systems for storing system resources 133 to be accessed by enterprise system 110. IAM system 131 can include a database management system or relational database tool. IAM system 131 can further include a message queue or stream processing platform such as Apache Kafka or Apache Spark or other data storage systems like Apache Hadoop, Hadoop Distributed File System (HDFS), or Amazon S3, to name just some examples. IAM system 131 can be a data lake, data silo, semi-structured data system (comma-separated values file, logs, xml, etc.), unstructured data system, binary data repository, or other suitable repository. IAM system 131 can store thousands, millions, billions, or trillions (or more) of objects, rows, transactions, records, files, logs, etc. while allowing for the creation, modification, retrieval, archival, and management of this data.

[0049] System resources 133 can include hardware, e.g., processor, memory, storage, or software, e.g., operating system, application software, database, used for various computing purposes. A system resource can be referred to as a resource. Examples of system resources 133 can include Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift, an Amazon® Web Services (AWS) service, an EC2 instance, a S3 bucket, or a DynamoDB table, S3 Glacier vaults, Amazon Simple Notification Service (SNS) topics, or Amazon Simple Queue Service (SQS) queues. System resources 133 can be products or services provided by any other vendors besides Amazon®.

[0050] In some examples, computing device 140 can be a wireless communication device, a smart phone, a laptop, a tablet, a personal assistant, a monitor, a wearable device, an Internet of Thing (IoT) device, a mobile station, a subscriber station, a remote terminal, a wireless terminal, or a user device. Computing device 140 can be configured to operate based on a wide variety of wireless communication techniques. These techniques can include, but are not limited to, techniques based on 3rd Generation Partnership Project (3 GPP) standards. In some other examples, computing device 140 can be a desktop workstation, a server, and/or embedded system, a computing device communicatively coupled to enterprise system 110 by wired lines, to name a few non limiting examples, or any combination thereof. Person 142 can use computing device 140 to interact with enterprise system 110, and request system resources 133 managed by IAM system 131 and residing in cloud computing system 130. Computing device 140 can include processor 141, memory device 143, and a GUI 145. The functions and operations performed by person 142 can be performed by an application, or some other machines as well. Hence, functions and operations performed by person 142 can be equally applicable to other applications and machines.

[0051] In some examples, enterprise system 110 can include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. Enterprise system 110 can include processor 117, memory device 118, display device 152 communicatively coupled to each other. GUI 119 can be displayed on display device 152. Enterprise system 110 further includes other components, e.g., an operating system, a storage coupled to processor, not shown. Enterprise system 110 may be implemented as any system that requests access to resources 133 protected by IAM system 131 that utilizes security policies and access permissions for controlling access to requested resources. [0052] In some embodiments, enterprise system 110 can include any number of principals, e.g., principal 111, a policy database 112, and a security governance guideline 114, which can be stored in memory device 118. Principal 111 can include role 113, which can be user 116 or machine 115, or application 151. In the following descriptions, role 113 can be used as an example of principal 111. Policy database 112 can include one or more security policies, which can be referred to as a policy, associated with roles or principals. For example, policy 113a, policy 113b, and policy 113c are associated with role 113. Combined, the security policies, e.g., policy 113a, policy 113b, or policy 113c, can generate an effective policy 123 for role 113, which can define a set of effective access permissions 125 by role 113 to access system resources 133.

[0053] In some embodiments, security governance guideline 114 can define a set of security rules 124 including various security rules, e.g., security rule 126. Security rule 126 can set up a permissible scope of a name for role 113 or a permissible scope of a name for system resources 133 being specified by any security policies. Compliance engine 122 can be configured to receive the effective policy 123 indicating the set of effective access permissions 125 from effective policy generator 121, and security rule 126, and determine whether there is over-privileged access permission 128. If the set of effective access permissions 125 contains over-privileged access permission 128, role 113 has a compliance status 153 as non-compliant. On the other hand, if compliance engine 122 cannot detect any over-privileged access permission for the set of effective access permissions 125, role 113 has compliance status 153 as compliant. Role 113 and its compliance status 153 can be displayed on GUI 119 of enterprise system 110.

[0054] Enterprise system 110 can be communicatively coupled to policy engine 120, where effective policy generator 121 and compliance engine 122 can be implemented to perform operations about security policies and access permissions. In some embodiments, policy database 112 can be implemented separately from enterprise system 110, such as in policy engine 120 and/or IAM system 131 coupled to enterprise system 110. In some other embodiments, policy engine 120 can be implemented as a part of enterprise system 110.

[0055] In some examples, role 113 can be used to delegate access to users, applications, or services that do not normally have access to system resources 133. For example, role 113 can be used to delegate access by a mobile app on computing device 140 to use system resources 133, which would not be normally accessible by a mobile application. Role 113 can be used to grant access to resources in one account to a trusted principal in a different account. Instead of being uniquely associated with one person, role 113 is intended to be assumable by anyone who needs it. Also, role 113 may not have standard long term credentials such as a password or access keys associated with it. Instead, role 113 can be provided with temporary security credentials for a session when the role is effective or valid.

[0056] Role 113 can include a machine 115 or a user 116. Machine 115 can be a representation of computing device 140, while user 116 can be a representation of person 142. User 116 can be an identity of person 142 in the service. Role 113 can be an identity that has specific access permissions. Role 113 can access system resources 133 based on access permissions defined by associated security policies, e.g., policy 113a, policy 113b, and policy 113c, which can be collectively referred as “policies 113.”

[0057] Principal 111, e.g., role 113, can submit request 191 for accessing system resources such as system resources 133 which are protected by IAM system 131. Request 191 can include a request context information, which is used to evaluate and authorize the request. The request context information can include actions or operations to be performed, resources upon which the actions or operations are performed, a principal that can be a person or an application that an entity to send request 191, environment data such as IP address, user agent, SSL enabled status, or the time of day; and resource data such as data related to the resource that is being requested. Information about the principal can include the policies that are associated with the entity that the principal used to sign in. Resource data can include information such as a database table name or a tag on an Amazon EC2 instance, for example. Request 191 can be allowed or denied based on the security policies, e.g., policy 113a, policy 113b, and policy 113c, associated with role 113.

[0058] A security policy, e.g., policy 113a, policy 113b, or policy 113c, can be stored in a storage of cloud computing system 130. Combined, the security policies, e.g., policy 113a, policy 113b, or policy 113c, can generate effective policy 123, which can define a set of effective access permissions 125 by role 113 to access system resources 133. The generation of effective policy 123 and the set of effective access permissions 125 can be performed by effective policy generator 121 within policy engine 120. The set of effective access permissions 125 represent the actual access permissions granted to role 113 by the security policies associated with role 113. In some examples, a system administrator can create the set of security policies that generates the set of effective access permissions 125 for role 113.

[0059] In addition, security governance guideline 114 can define a set of security rules 124 including various security rules, e.g., security rule 126. Security rule 126 can specify what kind of access permissions should be granted to various roles or system resources in an enterprise or an organization. As such, security rule 126 can set up the scope for what access permission is allowed to be granted to various roles, e.g., role 113. For example, security rule 126 can set up a permissible scope of a name for role 113 or a permissible scope of a name for system resources 133 being specified by any security policies. As an example, security rule 126 can include various statements, e.g., “a role name must be a machine”, “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket,” and more.

[0060] Often, the set of security policies actually defining the set of effective access permissions 125 for role 113 and the set of security rules 124 defining the permissible scopes for access permissions for role 113 are defined or generated at different times, by different people within the enterprise. Hence, it is possible that the set of effective access permissions 125 actually granted to role 113 can be different from what is allowed to be granted to role 113 as defined by security rule 126 or the set of security rules 124. An access permission of the set of effective access permissions 125 is an over-privileged access permission when the access permission exceeds the permissible scope defined by security rule 126. Detection of over-privileged access permission 128 is performed by compliance engine 122 based on security rule 126 of the set of security rules 124 that is defined based on security governance guideline 114.

[0061] If role 113 has been granted an over-privileged access permission, request 191 may be able to access system resources 133 that should not be allowed to be accessed according to security rule 126. However, IAM system 131 or enterprise system 110 may not know such an over-privileged access permission has been granted until some bad consequence has happened after role 113 has accessed the system resource. Any corrective action to its roles is therefore reactive and presents a potential security concern because roles are not evaluated until a request is made and granted, and potentially some bad consequence may have already happened.

[0062] In some examples, policy engine 120 can be used to evaluate the set of effective access permissions 125 of role 113 without performing any request or without receiving any request context information. Policy engine 120 can be implemented as a separate component as shown in FIG. 1 or integrated as part of enterprise system 110. Policy engine 120 can include effective policy generator 121, the set of security rules 124, and compliance engine 122. Effective policy generator 121 can be configured to receive all policies associated with a role, such as policy 113a, policy 113b, and policy 113c associated with role 113, and generate effective policy 123 from the received policies. Effective policy 123 further defines the set of effective access permissions 125. Effective policy 123 and the set of effective access permissions 125 can be saved in a storage located outside IAM system 131 and separated from IAM system 131. Therefore, policy engine 120 is implemented by a particular machine, instead of a generic computing system. For example, IAM system 131, which is a generic computing system, is separated from policy engine 120 so that policy engine 120 can evaluate the policies without accessing IAM system 131. Based on such an implementation on a special machine, policy engine 120 can provide added security protection for IAM system 131.

[0063] FIGS. 2A-2B illustrate example security policy statements of a security policy, e.g., security policy 210, and rules for resolving conflicts between security policy statements. Security policy 210 can be an example of policy 113a, policy 113b, policy 113c as shown in FIG. 1. Security policy 210 can include a policy statement 212 and a policy statement 214.

[0064] In some examples, security policy 210 can be an identity -based policy, a resource- based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, a session policy, an inline policy, or any kind of security policy. An identity -based policy can be attached to an identity such as a user, a group of users, or a role, and grant permissions to the identity. A resource-based policy can grant permissions to a principal (account, user, role, or federated user) specified in the policy to access the resource. The permissions define what the principal can do with the resource to which the policy is attached. A permissions boundary, an organizational service control policy (SCP), an access control list, or a session policy can also be referred to as a limiting security policy that allows the principal to the system resource set of the limiting security policy.

[0065] In some examples, security policy 210 can be stored in a storage of cloud computing system 130. In some examples, security policy 210 can be specified by nature language. In some other examples, security policy 210 can be specified by one or more statements in a markup language or structured language. Security policy 210 can be contained in a document specified by a markup language, such as a JavaScript Object Notation (JSON) document, a XML document, a YAML document, or any other documents containing statements in structured languages. Natural language processing can be used to convert a security policy in natural language, e.g., English, to a structured language.

[0066] In some examples, security policy 210 can include multiple statements, e.g., policy statement 212, policy statement 214, or more. A policy statement can further include various component statements. In some examples, policy statement 212 can include an effect statement 211, a principal statement 213, an action statement 215, a resource statement 217, a condition statement 219, or some other component statements. Policy statement 214 can include similar component statements. In addition, there can be other statements, such as a version statement, a statement name (also referred to as an identification (ID)), and more, not shown.

[0067] Effect statement 211 can specify either Allow or Deny to indicate whether the policy statement 212 allows or denies access. Principal statement 213 can be used to indicate an account, an application, a user, a role, or a group of users to which the access permission is allowed or denied. Action statement 215 can include a list of actions to be performed on the one or more system resources that the policy allows or denies. Action statement 215 can include a read-only action, a view action, an update action, a write action, a delete action, an NotAction, or some other actions. Resource statement 217 can specify a list of resources to which the actions apply. Condition statement 219 can specify the circumstances under which the policy grants permission.

[0068] A policy statement can specify whether members of an identity set are allowed or denied access to a system resource set of the IAM system. A policy statement, e.g., policy statement 212, can be referred to as an allow policy statement when the effect statement specifies Allow to indicate that members of an identity set are allowed access to a system resource set of the IAM system. In addition, a policy statement can be referred to as a deny policy statement when the effect statement specifies Deny to indicate that members of an identity set are denied access to a system resource set of the IAM system.

[0069] The identify set can include more than more principal, and the system resource set can include more than one system resource. The identify set and the system resource set of a policy statement are both represented by various names. In some examples, a policy statement can include a name for a principal, e.g., name 221 within principal statement 213; a name for a system resource, e.g., name 223, name 225, name 227, within resource statement 217; or a name for an action, e.g., name 229 within action statement 215, or some other names.

[0070] A name for a system resource can refer to one or more system resources. For example, name 223 includes only “*”, which is a wildcard referring to any system resources in the account. On the other hand, name 227 includes “example buckef ’, which refers to only one bucket stored in S3. In addition, name 225 includes “confidential-data/*”, which refers to a set of system resources within the folder “confidential-data.” Therefore, a name for a system resource can refer to system resource set of the IAM system of various sizes, as shown above For example, name 227 specifies only one system resource, “example_bucket”, while name 223 specifies every system resource of the account, The set of system resources referred by a name for a system resource defines a scope of the name for the system resource. When a scope of the name for a system resource in a security policy statement includes more than one system resource, the security policy statement can be applicable to any system resource whose name is included in the scope of the name for the system resource.

[0071] Similarly, a scope of a name for a principal can define members of an identity set. For example, name 221 “AWS-account-ID:user/user-name” can refer to only one user.

On the other hand, a name “AWS-account-ID:user/*” can refer to a group of users or principals. AWS is used here as an example. Other IAM systems can have similar examples. When a scope of a name for a principal in a security policy statement includes more than one principal, the security policy statement can be applicable to any principal whose name is included in the scope of the name for the role. A principal is a member of an identity set defined by a name of the principal. Accordingly, a policy statement can indicate members of an identity set are allowed to access a system resource set of the I AM system.

[0072] Accordingly, for a system resource, the name of the system resource can be included in multiple policy statements of multiple security policies, either explicitly or implicitly as shown above. In some examples, a first security policy can include a first policy statement applicable to the system resource, and a second security policy can include a second policy statement applicable to the same system resource. Moreover the first policy statement may grant access to the system resource while the second policy statement may deny access to the system resource by the same principal. Accordingly, a conflict between the first security policy and the second security policy occurs when the first policy statement and the second policy statement have conflicting effects on the system resource or the role. Depending on the kind of policy statements and the kind of security policies, different conflict can be resolved in different ways.

[0073] FIG. 2B illustrates example rules 230 for resolving conflicts between policy statements. The rules 230 can be applied by effective policy generator 121 when evaluating effective access permissions for a set of security policies associated with a principal, e.g., security policy 210.

[0074] According to rule 231, to determine whether a principal can access a system resource, effective policy generator 121 can first determine all the security policy statements applicable to the principal and the system resource. Effective policy generator 121 can identify a deny policy statement associated with the principal and applicable to the system resource that specifies “Deny” in its effect statement. In addition, effective policy generator 121 can identify an allow policy statement associated with the principal and applicable to the system resource that explicitly specifies “Allow” in its effect statement. Effective policy generator 121 can systematically go through all the policy statements of all the security policies associated with the principal and applicable to the system resource.

[0075] As indicated by rule 233, if a deny policy statement is identified, the effective access permission by the principal for the system resource is Deny. In other words, a deny statement can overwrite any other policy statement, and the principal is denied access to the system resource. [0076] As indicated by rule 235, if no deny policy statement is identified, but an allow policy statement is identified, the effective access permission by the principal for the system resource is allow, and the principal is allowed to access the system resource. Otherwise, if no deny policy statement and no allow policy statement is identified to be associated with the principal and applicable to the system resource, the principal is implicitly denied access to the system resource.

[0077] Rules 230 are some examples of rules for resolving conflicts between different security policy statements associated with a principal. In some other examples, an allow policy statement to grant access to the system resource by the principal can overwrite a deny policy statement. In some other examples, when there is no deny policy statement and no allow policy statement associated with the principal and applicable to the system resource, the principal can be implicitly allowed to access the system resource. Different IAM system 131 can implement different rules. Examples shown in FIG. 2B are just some specific rules and implementations, not a generic or abstract idea to resolve the conflicts between different security policies.

[0078] FIG. 3 illustrates an example set of effective access permissions 330 defined by multiple security policies, which can be an example of the set of effective access permissions 125 shown in FIG. 1. As shown in FIG. 3, multiple security policies, e.g., policy 311, policy 313, policy 325, and policy 337, can be associated with a principal to generate a set of effective access permissions 330, which can be an example of the set of effective access permissions 125. Different security policies can generate the set of effective access permissions in different ways. Each of the security policies, e.g., policy 311, policy 313, policy 325, and policy 337, can be an example of security policy 210 and can contain multiple policy statements.

[0079] In some examples, both policy 311 and policy 313 are identity -based policy.

Policy 313 is applicable to a single role, e.g., role 113, while policy 313 is applicable to a group of roles including role 113. Hence, the scope of policy 311 is a set of roles including only one role, while the scope of policy 313 is a set of roles including a group of roles. In the description below, the scope of policy 311 can be simply denoted by the policy number “311”, and the scope of policy 313 can be simply denoted by the policy number “313”. For an action to be performed, an effective access permission can be in a union of the set of access permissions defined by policy 311 or policy 313. Hence, the set of effective access permissions 125 defined by policy 311 and policy 313 is 311 U 313. Accordingly, given policy 311 and policy 313, for request 191, IAM system 131 can check both policy 311 and policy 313 for at least one allow policy statement for granting an access to the system resource for role 113.

[0080] In addition, policy 325 is a resource-based policy. For an action to be performed, an effective access permission can be in a union of the set of access permission defined by policy 311, policy 313, and policy 325, e.g., 311 U 313 U 325. Hence, for request 191, IAM system 131 can check policy 231, policy 233, and policy 235 for an allow policy statement for granting an access to the system resource.

[0081] Further, policy 337 can be a SCP. In this case, policy 337 limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting effective access permissions are the intersection of the session policies and either the resource-based policy or the identity -based policy, denoted as (311 U 313 U 325) P 337.

[0082] The examples of effective access permissions shown in FIG. 3 are only for example purpose and are not limiting. There can be other kinds of security policies. An organization's SCP can specify the maximum permissions for an organization or organizational unit (OU), which is applicable to individual roles, e.g., role 113. The SCP maximum applies to principals in member accounts, including each account root user of the organization. If an SCP is present, identity-based and resource-based policies grant permissions to principals in member accounts only if those policies and the SCP allow the action. If both a permissions boundary and an SCP are present, then the boundary, the SCP, and the identity -based policy must all allow the action. In addition, access control lists (ACLs) are service policies that control which principals in another account can access a resource.

[0083] Accordingly, FIG. 3 illustrates an example for the set of effective access permissions 330, which can be examples of the set of effective access permissions 125 defined by a set of security policies. The set of effective access permissions 125 can be generated by effective policy generator 121 within policy engine 120. Effective policy generator 121 can receive all of the security policies applicable or associated with role 113, which is called the effective policy 123. Based on the effective policy 123, the set of effective access permissions 125 can be generated similar to examples shown in FIG. 3. [0084] FIGS. 4A-4C illustrate example methods, e.g., method 400, method 410, method

430, for determining effective access permissions defined by a set of security policies associated with a principal, according to some embodiments. Method 400, method 410, method 430 can be performed by effective policy generator 121 within policy engine 120. Method 400 operates on an allow policy statement and a deny policy statement, while method 410 and method 430 operate on security policies that may include multiple policy statements.

[0085] In 402, effective policy generator 121 can identify a first policy statement associated with the principal, where the first policy statement specifies that members of a first identity set including the principal are allowed to access a first system resource set of the IAM system. For example, as shown in FIGS. 1 and 2A, effective policy generator 121 can identify policy statement 212 specifying that members of a first identity set including role 113 are allowed to access a first system resource set of the IAM system.

[0086] In 404, effective policy generator 121 can identify a second policy statement, where the second policy statement specifies that members of a second identity set are denied access to a second system resource set of the IAM system. For example, as shown in FIGS. 1 and 2 A, effective policy generator 121 can identify policy statement 214 specifying that members of a second identity set are denied access to a second system resource set of the IAM system.

[0087] In 406, effective policy generator 121 can determine whether or not there is a shared system resource belonging to both the first system resource set and the second system resource set, and whether or not the second identity set includes the principal. For example, as shown in FIGS. 1 and 2 A, effective policy generator 121 can determine whether or not there is a shared system resource belonging to both the first system resource set of policy statement 212 and the second system resource set of policy statement 214, and whether or not the second identity set includes role 113.

[0088] In 408, effective policy generator 121 can determine that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal. For example, effective policy generator 121 can determine that policy statement 214 overlaps with policy statement 212 with respect to the effective access permissions for the principal when the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal. The effective access permissions associated with role 113 are defined by a system resource included in the first system resource set but not included in the second system resource set.

[0089] In 409, when the second policy statement is determined to overlap with the first policy statement, effective policy generator 121 can place the second policy statement into a list of policy statements associated with the first policy statement with respect to the effective access permissions. For example, when policy statement 214 is determined to overlap with policy statement 212, effective policy generator 121 can place policy statement 214 into a list of policy statements associated with policy statement 212 with respect to the effective access permissions.

[0090] FIGS. 4B-4C illustrate method 410 and method 430 operating on security policies that may include multiple policy statements. Method 410 and method 430 can call method 400 to operate on individual policy statements when needed. Method 410 and method 430 can be performed by effective policy generator 121 within policy engine 120.

[0091] According to method 410, at 411, a user can enter a principal name. At 412, effective policy generator 121 can gather all the security policies from the IAM attached to the principal. In some examples, all the security policies attached to the principal can be a large number of security policies, e.g., millions of security policies. For each security policy 413, which can be similar to security policy 210, method 410 can perform iteration 420. The iteration 420 can be operated multiple times, one for each policy. Iteration 420 can include operations performed at 414, 415, 416, 418, 419, and 421.

[0092] For policy 413, at 414, effective policy generator 121 can retrieve the policy version, which can help to ensure the policy is a current version. At 415, effective policy generator 121 can further retrieve the policy document stored in the IAM, a database, or cache. The policy document for policy 413 can be stored in a cloud and specified by a markup language. The policy document for policy 413 can contain multiple policy statements. Effective policy generator 121 can inspect the policy document for policy 413.

[0093] For each policy statement 416 of policy 413, at 418, effective policy generator

121 can check the effect statement to determine whether the specified effect is “allow” or not. If the effect statement of policy statement 416 is Allow, at 419, effective policy generator 121 can add the actions, resources, conditions of policy statement 416 into an allow list 422. On the other hand, when the effect statement of policy statement 416 is Deny, at 421, effective policy generator 121 can add the actions, resources, conditions of policy statement 416 into a deny list 424.

[0094] As a result of method 410, effective policy generator 121 can gather all the security policies associated with the principal, and sort out all the policy statements inside each policy into two lists of policy statements, one for allow policy statements, and one for deny policy statements. The two classified lists can improve the efficiency for the evaluation of effective access permissions. Without the classification of all the policy statements of different security policies into two separated allow list and deny list, effective policy generator 121 can quickly become overwhelmed by the computations to evaluate the effective access permissions defined by millions of security policies. Allow list 422 may refer to the set of allow policy statements, which can be implemented by a list, a tree, a table, or any other data structure. Similarly, deny list 424 may refer to the set of deny policy statements, which can be implemented by a list, a tree, a table, or any other data structure.

[0095] Method 430 shown in FIG. 4C is a continuation of method 410 shown in FIG. 4B, and can be performed by effective policy generator 121.

[0096] At 431, allow list 422 and deny list 424 are provided from method 410 described above. At 433, for each allow policy statement 432 of allow list 422, effective policy generator 121 creates a new and separated list 441, and adds allow policy statement 432 into list 441. List 441 may be specified in JSON format. List 441 can be referred to as a list of policy statements associated with allow policy statement 432 with respect to the effective access permissions. The effective access permission for a principal is generated based on each allow policy statement 432. A list of policy statements associated with allow policy statement 432 with respect to the effective access permissions includes allow policy statement 432 together with other deny policy statements that overlaps with allow policy statement 432 with respect to the effective access permissions.

[0097] At 434, allow policy statement 432 is tested to see whether allow policy statement

432 contains “NotAction” in its action statement or not. If allow policy statement 432 contains Actions, without “NotAction,” at 435, effective policy generator 121 can check deny list 424 for deny policy statements with overlapping actions and resources, and further add overlapping deny policy statements to list 441 for allow policy statement 432. Detailed operations at 435 can be similar to method 400.

[0098] On the other hand, if allow policy statement 432 contains “NotAction,” at 436, effective policy generator 121 can check deny list 424 for deny policy statements for two conditions, (1) the allowed NotAction does not overlap with denied actions, (2) the resources of the deny policy statement overlaps with the resources of allow policy statement 432. If both conditions are satisfied, effective policy generator 121 can add the deny policy statements into list 441 for allow policy statement 432. Detailed operations at 435 can be similar to method 400.

[0099] Operations performed at 435 or at 436 include iterations to go through deny list 424 for each deny policy statement of deny list 424. For a selected deny policy statement specifying that members of an identity set are denied access to a system resource set of the IAM system, effective policy generator 121 can determine whether or not there is a shared system resource belonging to both the system resource set of allow policy statement 432 and the system resource set of the selected deny policy statement, and whether or not the identity set of the selected deny policy statement includes the principal. If the identity set of the selected deny statement does not include the principal, or there is no shared system resource belonging to both the system resource set of allow policy statement 432 and the system resource set of the selected deny policy statement, the selected deny policy statement does not overlap with allow policy statement 432. Hence, the selected deny policy statement is not added to list 441 of deny policy statements associated with the allow policy statement 432 with respect to the effective access permissions.

[0100] In addition, method 430 can include iterations of operations performed at 433,

434, 435, or 436 for different allow policy statements. For example, effective policy generator 121 can identify a second allow policy statement of allow list 422. The second allow policy statement of allow list 422 can specify that members of a second identity set including the principal are allowed to access a second system resource set of the IAM system. At 433, a list of policy statements associated with the second allow policy statement with respect to the effective access permissions can be generated. At 435, effective policy generator 121 can identify a deny policy statement, wherein the deny policy statement specifies that members of an identity set are denied access to a system resource set of the IAM system. Effective policy generator 121 can determine whether or not there is a shared system resource belonging to both the second system resource set and the system resource set of the deny policy statement, and whether or not the identity set of the deny policy statement includes the principal. When there is a shared system resource belonging to the second system resource set and the system resource set of the deny policy statement, and the identity set of the deny policy statement includes the principal, the second allow policy statement overlaps with the deny policy statement. The effective access permissions associated with the principal are defined by a system resource included in the second system resource set but not included in the system resource set of the deny policy statement. The deny policy statement can be added to the list of policy statements associated with the second allow policy statement with respect to the effective access permissions.

[0101] In some examples, there can be different policy statements. For example, effective policy generator 121 can pull all identity -based policy, resource-based policy, and SCP policy documents attached to a principle. Effective policy generator 121 can further identify any policy statements of the SCP policy that contain an Allow policy statement.

If there is an allow policy statement of the SCP policy, according to the rules established in FIG. 3, effective policy generator 121 can loop through the identity -based and resource-based policy statements, and add the statement to a list if it is an allow statement and either there is no SCP Allow statement or it overlaps with the existing SCP Allow statement. When an allow policy statement from an identity -based and resource-based policy does not overlap with the SCP Allow statement, the allow policy statement is discarded. In addition, effective policy generator 121 can add all Deny policy statements in all types of policies to a different list. As a result, two lists of policy statements are generated, one for allow policy statements and one for deny policy statements, similar to the two lists 422 and 424 generated at 419 and 421 as shown in FIG. 4B. Afterwards, effective policy generator 121 can perform method 430 as shown in FIG. 4C to generate a group of lists, where each list is a list of policy statements associated with an allow policy statement with respect to the effective access permissions. Each list of policy statements associated with the allow policy statement with respect to the effective access permissions can contain one allow statement followed by any number of overlapping deny statements. [0102] In some embodiments, a policy statement including NotAction or NotResource is not evaluated to its resultant Action or Resource since there can be possible hundreds of actions with each service type and to list every action or resource would overwhelm a human user. The list of lists generated by method 430 in FIG. 4C can be a useful form of representation for effective access permissions. Such group of lists, where each list is a list of policy statements associated with an allow policy statement with respect to the effective access permissions, can be operated by effective policy generator 121, while it is also readable by a human user. Such a group of lists are not simply an abstract idea of a list of lists. Instead, it is specifically tied to lists including an allow policy statement followed by a set of deny policy statements to define the effective access permissions.

[0103] Example 1 - A computer-implemented method for determining effective access permissions defined by security policies associated with a principal managed by an identity and access management (IAM) system, the method comprising: identifying a first policy statement associated with the principal, wherein the first policy statement specifies that members of a first identity set including the principal are allowed to access a first system resource set of the IAM system; identifying a second policy statement, wherein the second policy statement specifies that members of a second identity set are denied access to a second system resource set of the IAM system;_determining whether or not there is a shared system resource belonging to both the first system resource set and the second system resource set, and whether or not the second identity set includes the principal; determining that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal, wherein the effective access permissions associated with the principal are defined by a system resource included in the first system resource set but not included in the second system resource set; and placing, when the second policy statement is determined to overlap with the first policy statement, the second policy statement into a list of policy statements associated with the first policy statement with respect to the effective access permissions.

[0104] Example 2 - The computer-implemented method of example 1, wherein the first policy statement includes a first action to be allowed on the first system resource set or by the first identify set, and the second policy statement includes a second action to be denied on the second system resource set or by the second identify set.

[0105] Example 3 - The computer-implemented method of example 2, wherein the first action or the second includes a read-only action, a view action, an update action, a write action, a delete action, or an Not Action.

[0106] Example 4 - The computer-implemented method of claim 1, wherein an action contained in the second policy statement includes NotAction.

[0107] Example 5 - An apparatus for managing an identity and access management

(IAM) system, the apparatus comprising: a storage device configured to store a set of security policies associated with a principal managed by an identity and access management (IAM) system, wherein the set of security policies includes a first policy statement and a second policy statement; and a processor communicatively coupled to the storage device, and configured to: identify a first identity set including the principal specified by the first policy statement, wherein members of the first identity set are allowed to access a first system resource set of the IAM system; identify a second identity set specified by the second policy statement, wherein the second policy statement specifies that members of the second identity set are denied access to a second system resource set of the IAM system; determine whether or not there is a shared system resource belonging to both the first system resource set and the second system resource set, and whether or not the second identity set includes the principal; determine that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal, wherein the effective access permissions associated with the principal are defined by a system resource included in the first system resource set but not included in the second system resource set; and place, when the second policy statement is determined to overlap with the first policy statement, the second policy statement into a list of policy statements associated with the first policy statement with respect to the effective access permissions.

[0108] Example 6 - The apparatus of example 5, wherein the processor is further configured to: identify a third policy statement, wherein the third policy statement specifies that members of a third identity set are denied access to a third system resource set of the IAM system;_determine whether or not there is a shared system resource belonging to both the first system resource set and the third system resource set, and whether or not the third identity set includes the principal; determine that the third policy statement does not overlap with the first policy statement with respect to the effective access permissions for the principal when there is no shared system resource belongs to the first system resource set and the third system resource set, or the third identity set does not include the principal, wherein the third policy statement is not placed on the list of policy statements associated with the first policy statement with respect to the effective access permissions.

[0109] Example 7 - The apparatus of Example 5, wherein the processor is further configured to: identify a third policy statement associated with the principal, wherein the third policy statement specifies that members of a third identity set including the principal are allowed to access a third system resource set of the IAM system; identify a fourth policy statement, wherein the fourth policy statement specifies that members of a fourth identity set are denied access to a fourth system resource set of the IAM system; determine whether or not there is a shared system resource belonging to both the third system resource set and the fourth system resource set, and whether or not the fourth identity set includes the principal; determine that the fourth policy statement overlaps with the third policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the third system resource set and the fourth system resource set, and the fourth identity set includes the principal, wherein the effective access permissions associated with the principal are defined by a system resource included in the third system resource set but not included in the fourth system resource set; and place, when the fourth policy statement is determined to overlap with the third policy statement, the fourth policy statement into a list of policy statements associated with the third policy statement with respect to the effective access permissions.

[0110] Example 8 - The apparatus of Example 5, wherein the first policy statement or the second policy statement is a resource based policy statement or an identity based policy statement.

[0111] Example 9 - The apparatus of Example 5, wherein the first system resource set or the first identity set of the first policy statement overlaps with a system resource set or an identity set of a limiting security policy that allows the principal to the system resource set of the limiting security policy, or there is no limiting security policy associated with the principal to limit the effective access permissions of the principal.

[0112] Example 10 - The apparatus of Example 5, wherein the limiting security policy includes a permissions boundary, an organizational service control policy (SCP), or an access control list.

[0113] Example 11 - A non-transitory computer-readable medium storing instructions, the instructions, when executed by a processor, cause the processor to perform operations for determining effective access permissions defined by security policies associated with a principal managed by an identity and access management (IAM) system, the operations comprising: identifying a first policy statement associated with the principal, wherein the first policy statement specifies that members of a first identity set including the principal are allowed to access a first system resource set of the IAM system; identifying a second policy statement, wherein the second policy statement specifies that members of a second identity set are denied access to a second system resource set of the IAM system; determining whether or not there is a shared system resource belonging to both the first system resource set and the second system resource set, and whether or not the second identity set includes the principal; determining that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal, wherein the effective access permissions associated with the principal are defined by a system resource included in the first system resource set but not included in the second system resource set; and placing, when the second policy statement is determined to overlap with the first policy statement, the second policy statement into a list of policy statements associated with the first policy statement with respect to the effective access permissions.

[0114] Example 12 - The apparatus of Example 11, The non-transitory computer- readable medium of claim 19, wherein the operations further comprising: identifying a third policy statement, wherein the third policy statement specifies that members of a third identity set are denied access to a third system resource set of the IAM system; determining whether or not there is a shared system resource belonging to both the first system resource set and the third system resource set, and whether or not the third identity set includes the principal; determining that the third policy statement does not overlap with the first policy statement with respect to the effective access permissions for the principal when there is no shared system resource belongs to the first system resource set and the third system resource set, or the third identity set does not include the principal, wherein the third policy statement is not placed on the list of policy statements associated with the first policy statement with respect to the effective access permissions.

[0115] Various embodiments may be implemented, for example, using one or more well- known computer systems, such as computer system 500 shown in FIG. 5. One or more computer systems 500 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof. In some examples, computer system 500 can be used to implement computing device 140, enterprise system 110, effective policy generator 121, policy engine 120 as shown in FIG. 1, or operations shown in FIGS. 4A-4C.

[0116] Computer system 500 may include one or more processors (also called central processing units, or CPUs), such as a processor 504. Processor 504 may be connected to a communication infrastructure or bus 506.

[0117] Computer system 500 may also include user input/output device(s) 503, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 506 through user input/output interface(s) 502.

[0118] One or more of processors 504 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0119] Computer system 500 may also include a main or primary memory 508, such as random access memory (RAM). Main memory 508 may include one or more levels of cache. Main memory 508 may have stored therein control logic (i.e., computer software) and/or data.

[0120] Computer system 500 may also include one or more secondary storage devices or memory 510. Secondary memory 510 may include, for example, a hard disk drive 512 and/or a removable storage device or drive 514. Removable storage drive 514 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive. [0121] Removable storage drive 514 may interact with a removable storage unit 518.

Removable storage unit 518 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 518 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 514 may read from and/or write to removable storage unit 518.

[0122] Secondary memory 510 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 500. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 522 and an interface 520. Examples of the removable storage unit 522 and the interface 520 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and EiSB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

[0123] Computer system 500 may further include a communication or network interface

524. Communication interface 524 may enable computer system 500 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 528). For example, communication interface 524 may allow computer system 500 to communicate with external or remote devices 528 over communications path 526, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 500 via communication path 526.

[0124] Computer system 500 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

[0125] Computer system 500 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

[0126] Any applicable data structures, file formats, and schemas in computer system 500 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

[0127] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 500, main memory 508, secondary memory 510, and removable storage units 518 and 522, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 500), may cause such data processing devices to operate as described herein. For example, control logic may cause processor 504 to select a first role administered by an entity and a second role administered by the entity; identify a first set of security policies associated with the first role, and a second set of security policies associated with the second role, wherein the first set of security policies includes a first security policy and a second security policy; generate a first set of effective access permissions associated with the first role, and a second set of effective access permissions associated with the second role, wherein the first set of effective access permissions is generated based on the first set of security policies by resolving at least a conflict between the first security policy and the second security policy, and wherein the first set of effective access permissions defines a scope of a name for a system resource, or defines a scope of a name for a role; compare a permissible scope of the name for the system resource defined by a set of security rules with the scope of the name for the system resource to generate a first comparison result, and compare a permissible scope of the name for the role defined by the set of security rules with the scope of the name of the role to generate a second comparison result; and display on a graphical user interface (GUI), the first role and a first compliance status with respect to the set of security rules, and the second role and a second compliance status with respect to the set of security rules, wherein the first compliance status of the first role with respect to the set of security rules is determined based on the first comparison result and the second comparison result.

[0128] Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 5. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.

[0129] It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

[0130] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

[0131] Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof.

The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

[0132] References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0133] The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0134] It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.

[0135] The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof.

The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[0136] The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0137] The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0138] The claims in the instant application are different than those of the parent application or other related applications. The Applicant therefore rescinds any disclaimer of claim scope made in the parent application or any predecessor application in relation to the instant application. The Examiner is therefore advised that any such previous disclaimer and the cited references that it was made to avoid, may need to be revisited. Further, the Examiner is also reminded that any disclaimer made in the instant application should not be read into or against the parent application.

[0139] Identity and access management (IAM) is a framework of business processes, policies, and technologies that facilitates the management of electronic or digital identities of roles and system resources. IAM systems can provide access control to system resources by a role on a per-request basis. In general, an IAM system can grant or deny a request from a role to access system resources based on access permissions assigned to the role by one or more security policies. Such a request can be received from an enterprise system, and the request can identify the role. The following discussion presents interactions between an IAM system and an enterprise system but one skilled in the art would understand that the interactions apply to any requesting system that seeks access to a system resource based on access controls. The requesting system is therefore not limited to an enterprise system but any system that uses roles and permissions as part of access control to the system resource.

[0140] The request-response dynamic between the IAM system and an enterprise system presents challenges to the requesting system. First, the requesting system is not informed of any potential issues with respect to roles in its system until a request is made to the IAM system. Any corrective action to its roles is therefore reactive and presents a potential security concern because roles are not evaluated until a request is made. This provides an opportunity for compromised and/or over-privileged roles (e.g., roles controlled by a hacker) to be hijacked and used to improperly gain elevated access to system resources. Second, the requesting system relies on the IAM system in determining whether its roles are compliant with permission controls for accessing system resources.

[0141] The features described in this disclosure allow an enterprise system to monitor access permission compliance of roles with access control (AC) for accessing system resources of an IAM system without any requests being made. Access privileges or permissions to system resources by a role are granted according to security policies.

There are many kinds of security policies that work together to provide effective access permissions for a role to access system resources. However, due to the complexity of many security policies, sometimes a role can have an unintended, improper, or over privileged access permission to some system resources for which the role should not have access to. For security reasons, it is important to prevent a role from having an over privileged access permission to system resources.

[0142] In some examples, an over-privileged access permission is detected by comparing permissible scopes of access permissions defined by a set of security rules with a set of effective access permissions defined by a set of security policies associated with the role. Based on the set of effective access permissions, an enterprise system can perform preemptive evaluation of access permissions associated with a role to identify any over privileged access permission of the role to system resources. The preemptive evaluation of the access permissions can be performed with respect to a set of security rules, which can be defined by an enterprise or a corporation based on their security needs and some information security standards. Security rules based on information security standards, e.g., International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 27000 series of standard, can be used to implement information security controls to meet an organization’s requirements and prevent from granting a role some over-privileged access to system resources.

[0143] Hence, the enterprise system can detect over-privileged access permissions associated with a role in an IAM system without having to submit any requests to the IAM system. When a role has an over-privileged access permission, the compliance status of the role is non-compliant. On the other hand, if the role does not have any over privileged access permission, the compliance status of the role is compliant. The enterprise system can further display on a graphical user interface (GUI) a set of roles and its corresponding compliance status. In some embodiments, the enterprise system can detect over-privileged access permissions because the operations are performed by the enterprise system independent of the IAM system. Accordingly, the mechanisms discussed in the current disclosure are implemented by a machine with a specific arrangement, where the policy engine is separated from the IAM system to provide more security protection for the IAM system. In some embodiments, the enterprise system detecting over-privileged access permissions is separated from the IAM system.

[0144] In some enterprise systems, there can be a large number of roles, e.g., hundreds of thousands to millions of roles. A GUI can help the enterprise system to manage the large number of roles and its compliance status. Without a GUI for the enterprise system, it will be time consuming (if even possible) to manage the large number of roles. In addition, the GUI for the set of roles can further generate a notification to the role or the entity administering the role to inform the compliance status of the role, generate a remediation security policy for correcting the security policies providing the over privileged access permissions, and transmit an indication of the remediation policy to the role or the entity administering the role. A sequence of the above identified tasks for millions of roles would be impossible to be accomplished using the current computer system due to large complexity. Accordingly, embodiments herein improve the functionalities and security of enterprise systems.

[0145] FIG. 6 is a block diagram of an environment 6100 for displaying a compliance status of a role of an IAM system with respect to a set of security rules, according to some embodiments. Environment 6100 can include enterprise system 6110, policy engine 6120, and IAM system 6131, which can reside in a cloud computing system 6130. In addition, enterprise system 6110 can be communicatively coupled to a computing device 6140 that can be used by a person 6142. Enterprise system 6110 can include a GUI 6119 to display on display device 6152, with respect to a set of security rules 6124, various roles and their corresponding compliance status, e.g., role 6113 and its compliance status 6153, and role 6151 and its compliance status 6155. [0146] In some examples, environment 6100 can include a network formed by some or all of computing device 6140, enterprise system 6110, and cloud computing system 6130. For example, environment 6100 can include an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless wide area network (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, any other type of network, or a combination of two or more such networks.

[0147] In some examples, cloud computing system 6130 can include an environment that delivers computing as a service or shared resources. Cloud computing system 6130 can provide computation, software, data access, storage, and/or other services that do not require end-user knowledge of a physical location and configuration of a system and/or a device that delivers the services. In some examples, cloud computing system 6130 can include Amazon® Web Services (AWS), Microsoft® Azure, Google® Cloud, IBM® Cloud, Oracle® Cloud Infrastructure, or any other cloud computing system.

[0148] Cloud computing system 6130 can include IAM system 6131, which can manage system resources 6133. IAM system 6131 can receive a request 6191 for access to system resources 6133 from entities in enterprise system 6110 such as entity 6111. Entity 6111 can be resource objects to be used for authentication to access an account of IAM system 6131, e.g., an account. IAM system 6131 can include a plurality of data storage systems for storing system resources 6133 to be accessed by enterprise system 6110. IAM system 6131 can include a database management system or relational database tool. IAM system 6131 can further include a message queue or stream processing platform such as Apache Kafka or Apache Spark or other data storage systems like Apache Hadoop, Hadoop Distributed File System (HDFS), or Amazon S3, to name just some examples. IAM system 6131 can be a data lake, data silo, semi -structured data system (comma- separated values file, logs, xml, etc.), unstructured data system, binary data repository, or other suitable repository. IAM system 6131 can store thousands, millions, billions, or trillions (or more) of objects, rows, transactions, records, files, logs, etc. while allowing for the creation, modification, retrieval, archival, and management of this data. [0149] System resources 6133 can include hardware, e.g., processor, memory, storage, or software, e.g., operating system, application software, database, used for various computing purposes. A system resource can be referred to as a resource. Examples of system resources 6133 can include Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift, an Amazon® Web Services (AWS) service, an EC2 instance, a S3 bucket, or a DynamoDB table, S3 Glacier vaults, Amazon Simple Notification Service (SNS) topics, or Amazon Simple Queue Service (SQS) queues. System resources 6133 can be products or services provided by any other vendors besides Amazon®.

[0150] In some examples, computing device 6140 can be a wireless communication device, a smart phone, a laptop, a tablet, a personal assistant, a monitor, a wearable device, an Internet of Thing (IoT) device, a mobile station, a subscriber station, a remote terminal, a wireless terminal, or a user device. Computing device 6140 can be configured to operate based on a wide variety of wireless communication techniques. These techniques can include, but are not limited to, techniques based on 3rd Generation Partnership Project (3 GPP) standards. In some other examples, computing device 6140 can be a desktop workstation, a server, and/or embedded system, a computing device communicatively coupled to enterprise system 6110 by wired lines, to name a few non limiting examples, or any combination thereof. Person 6142 can use computing device 6140 to interact with enterprise system 6110, and request system resources 6133 managed by IAM system 6131 and resided in cloud computing system 6130. Computing device 6140 can include processor 6141, memory device 6143, and a GUI 6145. The functions and operations performed by person 6142 can be performed by an application, or some other machines as well. Hence, functions and operations performed by person 6142 can be equally applicable to other applications and machines.

[0151] In some examples, enterprise system 6110 can include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. Enterprise system 6110 can include processor 6117, memory device 6118, display device 6152 communicatively coupled to each other. GUI 6119 can be displayed on display device 6152. Enterprise system 6110 further includes other components, e.g., an operating system, a storage coupled to processor, not shown. Enterprise system 6110 may be implemented as any system that requests access to resources 6133 protected by IAM system 6131 that utilizes security policies and access permissions for controlling access to requested resources.

[0152] In some embodiments, enterprise system 6110 can include any number of entities, e.g., entity 6111, a policy database 6112, and a security governance guideline 6114, which can be stored in memory device 6118. Entity 6111 can include one or more roles, e.g., role 6113, and role 6151. In the following descriptions, role 6113 can be used as an example of any roles of entity 6111. Policy database 6112 can include one or more security policies, which can be referred to as a policy, associated with roles. For example, policy 6113a, policy 6113b, and policy 6113c are associated with role 6113, and policy 6151a is associated with role 6151. Combined, the security policies, e.g., policy 6113a, policy 6113b, or policy 6113c, can generate an effective policy 6123 for role 6113, which can define a set of effective access permissions 6125 by role 6113 to access system resources 6133. On the other hand, security governance guideline 6114 can define a set of security rules 6124 including various security rules, e.g., security rule 6126. Security rule 6126 can set up a permissible scope of a name for role 6113 or a permissible scope of a name for system resources 6133 being specified by any security policies. Compliance engine 6122 can be configured to receive the effective policy 6123 indicating the set of effective access permissions 6125 from effective policy generator 6121, and security rule 6126, and determine whether there is over-privileged access permission 6128. If the set of effective access permissions 6125 contains over-privileged access permission 6128, role 6113 has a compliance status 6153 as non-compliant. On the other hand, if compliance engine 6122 cannot detect any over-privileged access permission for the set of effective access permissions 6125, role 6113 has compliance status 6153 as compliant. Role 6113 and its compliance status 6153 can be displayed on GUI 6119 of enterprise system 6110. Multiple roles and their corresponding compliance status can be displayed on GUI 6119. For example, role 6151 together with its compliance status 6155 can be displayed on GUI 6119 as well.

[0153] Enterprise system 6110 is communicatively coupled to policy engine 6120, where effective policy generator 6121 and compliance engine 6122 can be implemented to perform operations about security policies and access permissions. In some embodiments, policy database 6112 can be implemented separately from enterprise system 6110, such as in policy engine 6120 and/or IAM system 6131 coupled to enterprise system 6110. In some other embodiments, policy engine 6120 can be implemented as a part of enterprise system 6110.

[0154] In some examples, entity 6111 can be resource objects to be used for authentication to access an account of IAM system 6131. Entity 6111 can include one or more associated roles, e.g., role 6113 or role 6151. Role 6113 can be stored in policy database 6112. Role 6113 can be used to delegate access to users, applications, or services that do not normally have access to system resources 6133. For example, role 6113 can be used to delegate access by a mobile app on computing device 6140 to use system resources 6133, which would not be normally accessible by a mobile application. Role 6113 can be used to grant access to resources in one account to a trusted principal in a different account. Instead of being uniquely associated with one person, role 6113 is intended to be assumable by anyone who needs it. Also, in some embodiments, role 6113 may not have standard long term credentials such as a password or access keys associated with it. Instead, role 6113 can be provided with temporary security credentials for a session when the role is effective or valid.

[0155] Role 6113 can include a machine 6115 or a user 6116. Machine 6115 can be a representation of computing device 6140, while user 6116 can be a representation of person 6142. User 6116 can be an identity of person 6142 in the service. Role 6113 can be an identity that has specific access permissions. Role 6113 can access system resources 6133 based on access permissions defined by associated security policies, e.g., policy 6113a, policy 6113b, and policy 6113c.

[0156] Entity 6111, e.g., role 6113, can submit request 6191 for accessing system resources such as system resources 6133 which are protected by IAM system 6131. Request 6191 can include a request context information, which is used to evaluate and authorize the request. The request context information can include actions or operations to be performed, resources upon which the actions or operations are performed, a principal that can be a person or an application that an entity to send request 6191, environment data such as IP address, user agent, SSL enabled status, or the time of day; and resource data such as data related to the resource that is being requested. Information about the principal can include the policies that are associated with the entity that the principal used to sign in. Resource data can include information such as a database table name or a tag on an Amazon EC2 instance. Request 6191 can be allowed or denied based on the security policies, e.g., policy 6113a, policy 6113b, and policy 6113c, associated with role 6113.

[0157] A security policy, e.g., policy 6113a, policy 6113b, or policy 6113c, can be stored in a storage of cloud computing system 6130. Combined, the security policies, e.g., policy 6113a, policy 6113b, or policy 6113c, can generate effective policy 6123, which can define a set of effective access permissions 6125 by role 6113 to access system resources 6133. The generation of effective policy 6123 and the set of effective access permissions 6125 can be performed by effective policy generator 6121 within policy engine 6120. The set of effective access permissions 6125 represent the actual access permissions granted to role 6113 by the security policies associated with role 6113. In some examples, a system administrator can create the set of security policies that generates the set of effective access permissions 6125 for role 6113.

[0158] In addition, security governance guideline 6114 can define a set of security rules

6124 including various security rules, e.g., security rule 6126. Security rule 6126 can specify what kind of access permissions should be granted to various roles or system resources in an enterprise or an organization. As such, security rule 6126 can set up the scope for what access permission is allowed to be granted to various roles, e.g., role 6113. For example, security rule 6126 can set up a permissible scope of a name for role 6113 or a permissible scope of a name for system resources 6133 being specified by any security policies. As an example, security rule 6126 can include various statements, e.g., “a role name must be a machine”, “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket,” and more.

[0159] Often, the set of security policies actually defining the set of effective access permissions 6125 for role 6113 and the set of security rules 6124 defining the permissible scopes for access permissions for role 6113 are defined or generated at different times, by different people within the enterprise. Hence, it is possible that the set of effective access permissions 6125 actually granted to role 6113 can be different from what is allowed to be granted to role 6113 as defined by security rule 6126 or the set of security rules 6124. An access permission of the set of effective access permissions 6125 is an over-privileged access permission when the access permission exceeds the permissible scope defined by security rule 6126. Detection of over-privileged access permission 6128 is performed by compliance engine 6122 based on security rule 6126 of the set of security rules 6124 that is defined based on security governance guideline 6114.

[0160] If role 6113 has been granted an over-privileged access permission, request 6191 may be able to access system resources 6133 that should not be allowed to access according to security rule 6126. However, IAM system 6131 or enterprise system 6110 may not know such an over-privileged access permission has been granted until some bad consequence has happened after role 6113 has accessed the system resource. Any corrective action to its roles is therefore reactive and presents a potential security concern because roles are not evaluated until a request is made and granted, and potentially some bad consequence may have already happened.

[0161] In some examples, policy engine 6120 can be used to evaluate the set of effective access permissions 6125 of role 6113 without performing any request or any request context information. Policy engine 6120 can be implemented as a separate component as shown in FIG. 6 or integrated as part of enterprise system 6110. Policy engine 6120 can include effective policy generator 6121, the set of security rules 6124, and compliance engine 6122. Effective policy generator 6121 can be configured to receive all policies associated with a role, such as policy 6113a, policy 6113b, and policy 6113c associated with role 6113, and generate effective policy 6123 from the received policies. Effective policy 6123 further defines the set of effective access permissions 6125.

[0162] FIGS. 7A-7B are diagrams illustrating example security policies and a set of effective access permissions defined by a set of security policies used in determining a compliance status of a role, according to some embodiments. FIG. 7A shows an example security policy 7210. Security policy 7210 can be an example of policy 6113a, policy 6113b, policy 6113c, or policy 6151a as shown in FIG. 6. FIG. 7B shows an example set of effective access permissions 7230 defined by multiple security policies, which can be an example of the set of effective access permissions 6125 shown in FIG. 6.

[0163] In some examples, security policy 7210 can be an identity -based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, a session policy, an inline policy, or any kind of security policy. An identity-based policy can be attached to an identity such as a user, a group of users, or a role, and grant permissions to the identity. A resource-based policy can grant permissions to a principal (account, user, role, or federated user) specified in the policy to access the resource. The permissions define what the principal can do with the resource to which the policy is attached. A security policy can be stored in a storage of cloud computing system 6130. In some examples, a security policy can be specified by natural language. In some other examples, a security policy can be specified by one or more statements in a markup language or structured language. A security policy can be contained in a document specified by a markup language, such as a JavaScript Object Notation (JSON) document, a XML document, a YAML document, or any other documents containing statements in structured languages. Natural language processing can be used to convert a security policy in natural language, e.g., English, to a structured language.

[0164] In some examples, security policy 7210 can include an effect statement 7211, a principal statement 7213, an action statement 7215, a resource statement 7217, a condition statement 7219, or some other statements. Effect statement 7211 can specify either Allow or Deny to indicate whether the policy allows or denies access. Principal statement 7213 can be used to indicate an account, a user, a role, or a group of users to which the access permission is allowed or denied. Action statement 7215 can include a list of actions to be performed on the one or more system resources that the policy allows or denies. Action statement 7215 can include a read-only action, a view action, an update action, a write action, a delete action, or some other actions. Resource statement 7217 can specify a list of resources to which the actions apply. Condition statement 7219 can specify the circumstances under which the policy grants permission. In addition, there can be other statements, such as a version statement, a statement name (also referred to as an identification (ID)), and more, not shown.

[0165] In some examples, a statement can include a name for a role, e.g., name 7221 within principal statement 7213; a name for a system resource, e.g., name 7223, name 7225, name 7227, within resource statement 7217; or a name for an action, e.g., name 7229 within action statement 7215, or some other names. A name for a system resource can include one or more system resources. For example, name 7223 includes only “*”, which is a wildcard referring to any system resources in the account. On the other hand, name 7227 includes “example bucket”, which refers to only one bucket stored in S3. In addition, name 7225 includes “confidential-data/*”, which refers to a set of system resources within the folder “confidential-data.” The set of system resources referred by a name for a system resource defines a scope of the name for the system resource. For example, a scope of name 7227 includes only “example bucket”, while a scope of name 7223 includes every system resource of the account, A name for a system resource can be defined in a resource statement or other statement for a security policy. Similarly, a scope of a name for a role can include one or more roles. For example, name 7221 “AWS-account-ID:user/user-name” can refer to only one user. On the other hand, a name “AWS-account-ID:user/*” can refer to a group of users. When a scope of the name for a system resource in a security policy statement includes more than one system resource, the security policy statement can be applicable to any system resource whose name is included in the scope of the name for the system resource. Similarly, when a scope of a name for a role in a security policy statement includes more than one role, the security policy statement can be applicable to any role whose name is included in the scope of the name for the role.

[0166] Accordingly, for a system resource, the name of the system resource can be included in multiple policy statements of multiple security policies, either explicitly or implicitly as shown above. In some examples, a first security policy can include a first policy statement applicable to the system resource, and a second security policy can include a second policy statement applicable to the same system resource by a role. Moreover the first policy statement may grant access to the system resource while the second policy statement may deny access to the system resource by the same role. Accordingly, a conflict between the first security policy and the second security policy occurs when the first policy statement and the second policy statement have conflicting effects on the system resource or the role. Depending on the kind of policy statements and the kind of security policies, different conflicts can be resolved in different ways. In some examples, a grant access to the system resource by the role specified by the first policy statement can overwrite a deny access to the system resource by the role specified by the second policy statement. In some other examples, a deny access to the system resource by the role specified by the first policy statement can overwrite a grant access to the system resource by the role specified by the second policy statement. In some examples, there can be implicit grant, explicit grant, implicit deny, and explicit deny, and various interactions between the different kinds of statements can be defined. The details of a conflict resolving mechanism can be determined by IAM system 6131 or enterprise system 6110.

[0167] As shown in FIG. 7B, multiple security policies, e.g., policy 7231, policy 7233, policy 7235, and policy 7237, can be associated with a role to generate a set of effective access permissions 7230, which can be an example of the set of effective access permissions 6125. Different security policies can generate the set of effective access permissions in different ways.

[0168] In some examples, as shown in FIG. 7B, both policy 7231 and policy 7233 are identity-based policies. Policy 7231 is applicable to a single role, e.g., role 6113, while policy 7233 is applicable to a group of roles including role 6113. Hence, the scope of policy 7231 is a set of roles including only one role, while the scope of policy 7233 is a set of roles including a group of roles. In the description below, the scope of policy 7231 can be simply denoted by the policy number “7231”, and the scope of policy 7233 can be simply denoted by the policy number “7233”. For an action to be performed, an effective access permission can be in a union of the set of access permissions defined by policy 7231 or policy 7233. Hence, the set of effective access permissions 6125 defined by policy 7231 and policy 7233 is 7231 U 7233. Accordingly, given policy 7231 and policy 7233, for request 6191, IAM system 6131 can check both policy 7231 and policy 7233 for at least one Allow action for granting an access to the system resource for role 6113. As long as one Allow action is found for role 6113, role 6113 can still be allowed access based on the union of the scopes of the policy statements. Hence, the conflict between an Allow action and an implicit Deny action for role 6113 can be resolved by having the Allow action overwrites the implicit Deny action for role 6113. On the other hand, an explicit Deny action can overwrite an Allow action.

[0169] In addition, policy 7235 is a resource-based policy. For an action to be performed, an effective access permission can be in a union of the set of access permission defined by policy 7231, policy 7233, and policy 7235, e.g., 7231 U 7233 U 7235. Hence, for request 6191, IAM system 6131 can check policy 7231, policy 7233, and policy 7235 for at least one Allow action for granting an access to the system resource.

[0170] Further, policy 7237 can be a session policy. In this case, the permissions from resource-based policy 7235 are added to the role or user's identity -based policy 7231 and policy 7233 before the session is created. Session policy 7237 limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session’s permissions are the intersection of the session policies and either the resource- based policy or the identity-based policy, denoted as (7231 U 7233 U 7235) (3 7237. Hence, the conflict between an Allow action indicated by the resource-based policy or the identity -based policy and a Deny action indicated by the session policy for role 6113 can be resolved by having the Deny action overwrites the Allow action for role 6113.

[0171] The examples of effective access permissions shown in FIG. 7B are only for example purposes and are not limiting. There can be other kinds of security policies. An organization’s service control policies (SCPs) can specify the maximum permissions for an organization or organizational unit (OU), which is applicable to individual roles, e.g., role 6113. The SCP maximum applies to principals in member accounts, including each AWS account root user of the organization. If an SCP is present, identity -based and resource-based policies grant permissions to principals in member accounts only if those policies and the SCP allow the action. If both a permissions boundary and an SCP are present, then the boundary, the SCP, and the identity -based policy must all allow the action. In addition, access control lists (ACLs) are service policies that control which principals in another account can access a resource.

[0172] Accordingly, FIG. 7B illustrates an example for the set of effective access permissions 7230, which can be examples of the set of effective access permissions 6125 defined by a set of security policies. The set of effective access permissions 6125 can be generated by effective policy generator 6121 within policy engine 6120. Effective policy generator 6121 can receive all of the security policies applicable or associated with role 6113, which is called the effective policy 6123. Based on the effective policy 6123, the set of effective access permissions 6125 can be generated similar to examples shown in FIG. 7B. In some examples, effective policy 6123 can include a first security policy and a second security policy. The set of effective access permissions 6125 can be generated based on effective policy 6123 by resolving at least a conflict between the first security policy and the second security policy. For example, the conflict can be resolved for various security policies as described above. Furthermore, the set of effective access permissions 6125 is provided as inputs to compliance engine 6122 to detect whether there is an over-privileged access permission 6128 with respect to security rule 6126. [0173] Referring back to FIG. 6, compliance engine 6122 can be configured to receive effective policy 6123 indicating the set of effective access permissions 6125 from effective policy generator 6121, and security rule 6126, and determine whether there is over-privileged access permission 6128. In some other examples, compliance engine 6122 can detect whether there is over-privileged access permission 6128 by directly receiving the security policies, e.g., policy 6113a, policy 6113b, and policy 6113c. If the set of effective access permissions 6125 contains over-privileged access permission 6128, compliance engine 6122 can identify the related security policies that generate such over privileged access permission 6128, and label the identified security policies having a compliance status as non-compliant. Accordingly, role 6113 has a compliance status as non-compliant. On the other hand, if the set of effective access permissions 6125 does not contain any over-privileged access permission, compliance engine 6122 can label the effective policy 6123 having a compliance status as compliant. Accordingly, role 6113 has a compliance status as compliant.

[0174] Compliance engine 6122 can be configured to receive the set of security rules

6124 including security rule 6126. Security rule 6126 can be generated based on security governance guideline 6114. In some examples, security rule 6126 can be created based on an information security standard, an International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 27000 series of standard, a National Institute of Standards and Technology (NIST) Special Publications 800 standard, an Information Security Forum (ISF) Standard of Good Practice (SoGP) standard, or a Control Objectives for Information and related Technology (COBIT) standard. In some examples, security rule 6126 can be referred to as permission controls.

[0175] In some examples, security rule 6126 can be specified in plain English. For example, security rule 6126 can include any or all of the following statements: “a resource name can include 5 characters, and followed by a wild card *”; “a role name must be a machine”; “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket”; or “a role name must be limited to a single entity account.”

In some examples, the English statement can be translated into a more structured statement. For example, “5 characters, and followed by a wild card *” can be translated into the format of “?????” + Security rule 6126 can include multiple statements, where each statement can impose a condition on a name for a system resource, a name for a role, a name for an action, or some other conditions. All the statements together in security rule 6126 can define a permissible scope of a name for system resources, which can be an intersection set of the allowable names for system resources defined by all statements in security rule 6126. Similarly, all the statements together in security rule 6126 can define a permissible scope of a name for a role, a permissible scope of a name for an action, and other permissible scopes.

[0176] In some examples, compliance engine 6122 can compare a scope of a name for a system resource indicated by the set of effective access permissions 6125, which is defined by effective policy 6123, with a permissible scope of the name for the system resource defined by a security rule to obtain a first comparison result. For example, compliance engine 6122 can compare a scope of name 7223, name 7225, and name 7227 for system resources within resource statement 7217 of security policy 7210, with a permissible scope of the name for system resources defined by security rule 6126. The statement of security rule 6126, “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket,” defines a permissible scope for a name for system resources. Accordingly, the scope of name 7227 includes only one system resource, “example bucket”. Hence, the scope of name 7227 is within the permissible scope of a name for system resources defined by security rule 6126. On the other hand, the scope of name 7223 includes any system resources in the account, which is referred by Hence, the scope of name 7223 exceeds the permissible scope of a name for system resources defined by security rule 6126. Furthermore, the scope of name 7225 includes system resources within a folder “confidential-data/*”, which can be within a single bucket. Hence, the scope of name 7225 is within the permissible scope of a name for system resources defined by security rule 6126 if the folder “confidential -data/” is within a single bucket. The first comparison result indicates whether the scope of the name for a system resource indicated by the set of effective access permissions 6125 exceeds the permissible scope of the name for the system resource defined by the security rule.

[0177] In some examples, compliance engine 6122 can compare a scope of a name for a role indicated by the set of effective access permissions 6125 with a permissible scope of the name for the role defined by the security rule to obtain a second comparison result.

For example, compliance engine 6122 can compare a scope of name 7221 for a role within principal statement 7213 of security policy 7210, with a permissible scope of the name for the role defined by security rule 6126. The scope of name 7221 includes only one user account, “AWS-account-ID:user/user-name”. If security rule 6126 includes the statement, “a role name must be a machine”, the permissible scope of a role must be a machine. Hence, the scope of name 7221 for a role exceeds the permissible scope of a role as defined by security rule 6126. On the other hand, if security rule 6126 includes a different statement, “a role name must be limited to a single entity account”, the permissible scope of a name for a role can include multiple roles within a single entity account. Hence, the scope of name 7221, including “AWS-account-ID:user/user-name”, is within the permissible scope of the name for the role as defined by security rule 6126. Similarly, the scope of a role name, “AWS-account-ID:user/*”, is within the permissible scope of the name for a role as defined by security rule 6126. The second comparison result indicates whether the scope of the name for a role defined in the second security policy exceeds the permissible scope of the name for the role defined by the security rule.

[0178] In some other examples, compliance engine 6122 can compare a scope of a name for other components of security policy statements, e.g., an action name as indicated by the set of effective access permissions 6125 with a permissible scope of the name for the component defined by the security rule to obtain further comparison result. Similar principles applied to the scope of a name for a system resource or the scope of a name for a role can be applied to the scope of the name for other components of security policies. Since compliance engine 6122 is located outside IAM system 6131 and separated from IAM system 6131, compliance engine 6122 is implemented by a particular machine, instead of a generic computing system. For example, compliance engine 6122 can be separated from IAM system 6131. Based on such an implementation on a special machine, compliance engine 6122 can provide added security protection for IAM system 6131.

[0179] FIG. 8 is a flowchart illustrating a method 8300 for displaying a compliance status of a role with respect to a set of security rules, according to some embodiments. Method 8300 can be performed by processor 6117 of enterprise system 6110 to display on GUI 6119 role 6113 and its compliance status 6153, and/or role 6151 and its compliance status 6155.

[0180] In 8302, processor 6117 can be configured to select a first role administered by an entity and a second role administered by the entity. For example, as shown in FIG. 6, processor 6117 can be configured to select role 6113 and role 6151 administered by entity 6111, which can own an account used for authentication to access IAM system 6131. As shown in FIG. 9A, entity 6111 can have an account name 9401 displayed on GUI 6119 of enterprise system 6110. Furthermore, account name 9401 can have multiple roles, e.g., role 9411, BackupDefaultServiceRole; role 9413, BatchServiceRole; and role 9415, Connects AMLRole. Role 9411, role 9413, and role 9415 can be selected by selecting a parameter 9403, e.g., “all,” to select all roles administered by account name 9401. In some other examples, there can be other ways to select one or more roles by different parameters, e.g., by selection of one or more roles of a role list displayed on GUI 6119. The first role and the second role are described as examples. In some examples, there can be one or more roles selected.

[0181] In 8304, processor 6117 can be configured to identify a first set of security policies associated with the first role, and identify a second set of security policies associated with the second role. For example, as shown in FIG. 6, processor 6117 can be configured to identify a first set of security policies, security policy 6113a, security policy 6113b, and security policy 6113c, associated with role 6113. Processor 6117 can be further configured to select a second set of security policies, security policy 6151a, associated with role 6151. Security policy 6113a, security policy 6113b, and security policy 6113c can be an example of effective policy 6123, which includes all of the security policies applicable to role 6113. In some examples, some filters can be applied to select a subset of all of the security policies applicable to role 6113.

[0182] In 8306, processor 6117 can be configured to generate a first set of effective access permissions associated with the first role, and a second set of effective access permissions associated with the second role. For example, as shown in FIG. 6, processor 6117 can be configured to generate the set of effective access permissions 6125 for effective policy 6123, which can be applicable to role 6113. The set of effective access permissions 6125 can be generated based on effective policy 6123 by resolving at least a conflict between the first security policy and the second security policy of effective policy 6123, as described for FIG. 7B. The set of effective access permissions 6125 can define a scope of a name for a system resource, or define a scope of a name for a role.

[0183] In 8308, processor 6117 can be configured to compare a permissible scope of the name for the system resource defined by a set of security rules with the scope of the name for the system resource to generate a first comparison result, and compare a permissible scope of the name for the role defined by the set of security rules with the scope of the name of the role to generate a second comparison result. Operations performed in 8308 can be performed by compliance engine 6122 operated by processor 6117, or by sending a request to compliance engine 6122 to perform the related operations as described above for compliance engine 6122. For example, processor 6117 can operate compliance engine 6122 to, or cause compliance engine 6122 to, compare a scope of name 7221 for a role within principal statement 7213 of security policy 7210, with a permissible scope of the name for the role defined by security rule 6126 or the set of security rules 6124 to generate a first comparison result. Similarly, processor 6117 can operate compliance engine 6122 to, or cause compliance engine 6122 to, compare a scope of name 7223 for a system resource within resource statement 7217 of security policy 7210, with a permissible scope of the name for the role defined by security rule 6126 to generate a second comparison result.

[0184] In 8309, processor 6117 can be configured to display on a GUI, the first role and a first compliance status with respect to the set of security rules, and the second role and a second compliance status with respect to the set of security rules. The first compliance status of the first role with respect to the set of security rules is determined based on the first comparison result and the second comparison result. For example, as shown in FIG. 6, processor 6117 can be configured to determine, based on the set of security rules 6124, compliance status 6155 of role 6151 associated with the set of security policies, e.g., policy 6151a. Similarly, processor 6117 can be configured to determine, based on the set of security rules 6124, compliance status 6153 of role 6113 associated with the set of security policies, e.g., policy 6113a, 6113b, and 6113c, based on the two comparison results performed at 8308. As shown in FIG. 9 A, GUI 6119 can display role 9411 with a compliance status 9412 having a value as compliant, role 9413 with a compliance status 9414 having a value as compliant, and role 9415 with a compliance status 9416 having a value as non-compliant. Compliance engine 6122 can determine role 9415 has over privileged access permission 6128 when the scope of the name 7223 for a system resource exceeds the permissible scope of the name for the system resource defined in security rule 6126, or when the scope of the name 7221 for a role exceeds the permissible scope of name for the role defined in security rule 6126. On the other hand, compliance engine 6122 can determine role 9411 or role 9413 does not have an over-privileged access permission. Accordingly, in such cases, role 9411 or role 9413 has a compliance status as compliant. As shown in window 9407, role 9411, role 9413, and role 9415 together with their corresponding compliance status can be shown in a tabular form on GUI 6119.

[0185] In addition, as shown in FIG. 9A, processor 6117 can be further configured to display more information on GUI 6119. For example, GUI 6119 can display a summary window 9405 to show how many roles having compliant status, e.g., 2 roles having compliant status, and how many roles having a non-compliant status, e.g., 1 role having non-compliant status. Further, GUI 6119 can display the security policy that is non- compliant with respect to the set of security rules, e.g., security policy 9417, “AC-3”.

[0186] As shown in FIG. 9B, processor 6117 can be further configured to display more information about an individual role on GUI 6119 in a role details window 9421. For example, role details window 9421 can include a role 9415 with a role name “ConnectSAMLRole.” Role 9415 is used as an example. Other roles, e.g., role 9411, role 9413, or other roles can be displayed with more detailed information as well. Role details window 9421 can further include an indication of effective security policy 9422, which can list some or all of the effective security policy 9422; and an indication of non- compliance security policy 9424, e.g., AC-3. Processor 6117 can be further configured to generate a remediation security policy 9426 for correcting the non-compliance security policy 9424.

[0187] As shown in FIG. 9C, processor 6117 can be further configured to generate a notification 9430, which can be an email, to be sent to the role when the compliance status of the first role is non-compliant. Notification 9430 can be an email that includes an email header 9431, role 9415 with a role name “ConnectSAMLRole,” and an indication of remediation security policy 9426 for correcting the non-compliance security policy 9424. Furthermore, processor 6117 can be configured to transmit to role 6113 or entity 6111, notification 9430 with the indication of remediation policy 9426.

[0188] Various embodiments may be implemented, for example, using one or more well- known computer systems, such as computer system 10500 shown in FIG. 10. One or more computer systems 10500 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof. [0189] Computer system 10500 may include one or more processors (also called central processing units, or CPUs), such as a processor 10504. Processor 10504 may be connected to a communication infrastructure or bus 10506.

[0190] Computer system 10500 may also include user input/output device(s) 10503, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 10506 through user input/output interface(s) 10502.

[0191] One or more of processors 10504 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0192] Computer system 10500 may also include a main or primary memory 10508, such as random access memory (RAM). Main memory 10508 may include one or more levels of cache. Main memory 10508 may have stored therein control logic (i.e., computer software) and/or data.

[0193] Computer system 10500 may also include one or more secondary storage devices or memory 10510. Secondary memory 10510 may include, for example, a hard disk drive 10512 and/or a removable storage device or drive 10514. Removable storage drive 10514 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.

[0194] Removable storage drive 10514 may interact with a removable storage unit 10518.

Removable storage unit 10518 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 10518 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 10514 may read from and/or write to removable storage unit 10518.

[0195] Secondary memory 10510 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 10500. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 10522 and an interface 10520. Examples of the removable storage unit 10522 and the interface 10520 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

[0196] Computer system 10500 may further include a communication or network interface 10524. Communication interface 10524 may enable computer system 10500 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 10528). For example, communication interface 10524 may allow computer system 10500 to communicate with external or remote devices 10528 over communications path 10526, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 10500 via communication path 10526.

[0197] Computer system 10500 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

[0198] Computer system 10500 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

[0199] Any applicable data structures, file formats, and schemas in computer system

10500 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

[0200] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 10500, main memory 10508, secondary memory 10510, and removable storage units 10518 and 10522, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 10500), may cause such data processing devices to operate as described herein. For example, control logic may cause processor 10504 to select a first role administered by an entity and a second role administered by the entity; identify a first set of security policies associated with the first role, and a second set of security policies associated with the second role, wherein the first set of security policies includes a first security policy and a second security policy; generate a first set of effective access permissions associated with the first role, and a second set of effective access permissions associated with the second role, wherein the first set of effective access permissions is generated based on the first set of security policies by resolving at least a conflict between the first security policy and the second security policy, and wherein the first set of effective access permissions defines a scope of a name for a system resource, or defines a scope of a name for a role; compare a permissible scope of the name for the system resource defined by a set of security rules with the scope of the name for the system resource to generate a first comparison result, and compare a permissible scope of the name for the role defined by the set of security rules with the scope of the name of the role to generate a second comparison result; and display on a graphical user interface (GUI), the first role and a first compliance status with respect to the set of security rules, and the second role and a second compliance status with respect to the set of security rules, wherein the first compliance status of the first role with respect to the set of security rules is determined based on the first comparison result and the second comparison result.

[0201] Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 10. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.

[0202] It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

[0203] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

[0204] Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

[0205] References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0206] The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0207] It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.

[0208] The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof.

[0209] The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0210] The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. [0211] The claims in the instant application are different than those of the parent application or other related applications. The Applicant therefore rescinds any disclaimer of claim scope made in the parent application or any predecessor application in relation to the instant application. The Examiner is therefore advised that any such previous disclaimer and the cited references that it was made to avoid, may need to be revisited. Further, the Examiner is also reminded that any disclaimer made in the instant application should not be read into or against the parent application.

[0212] Identity and access management (IAM) is a framework of business processes, policies, and technologies that facilitates the management of electronic or digital identities of roles and system resources. IAM systems can provide access control to system resources by a role on a per-request basis. In general, an IAM system can grant or deny a request from a role to access system resources based on access permissions assigned to the role by one or more security policies. Such a request can be received from an enterprise system, and the request can identify the role. The following discussion presents interactions between an IAM system and an enterprise system, but one skilled in the art would understand that the interactions apply to any requesting system that seeks access to a system resource based on access controls. The requesting system is therefore not limited to an enterprise system but can include any system that uses roles and permissions as part of access control to the system resource.

[0213] The request-response dynamic between the IAM system and an enterprise system presents challenges to the requesting system. First, the requesting system is not informed of any potential issues with respect to roles in its system until a request is made to the IAM system. Any corrective action to its roles is therefore reactive and presents a potential security concern because roles are not evaluated until a request is made. This provides an opportunity for compromised and/or over-privileged roles (e.g., by a hacker) to be hijacked and used to improperly gain access to system resources. Second, the requesting system must rely on the IAM system in determining whether its roles are compliant with permission controls for accessing system resources.

[0214] The features described in this disclosure allow for an enterprise system to monitor access permission compliance of roles with access control (AC) for accessing system resources of an IAM system without any requests being made. Access privileges or permissions to system resources by a role are granted according to security policies. There are many kinds of security policies, which work together to provide effective access permissions for a role to access system resources. However, due to the complexity of many security policies, sometimes a role can have unintended, improper, or over privileged access to some system resources for which the role should not have access to. For security reasons, it is important to prevent a role from having an over-privileged access permission to system resources. Hence, the enterprise system can detect over privileged access permissions associated with a role in an IAM system without having to submit any requests to the IAM system. In some embodiments, the enterprise system can detect over-privileged access permissions because the operations are performed by a policy engine independent of the IAM system. Accordingly, the mechanisms discussed in the current disclosure are implemented by a machine with a specific arrangement, where the policy engine is separated from the IAM system to provide more security protection for the IAM system. In some embodiments, the enterprise system detecting over privileged access permissions is separated from the IAM system.

[0215] In some examples, a role can be associated with a number of security policies, with each security policy defining a number of permissions for accessing different system resources. There may be different types of policies, such as identity -based policies whose permissions relate to an identity, resource-based policies whose permissions are for a specific resource, and permission boundaries whose permissions define a maximum scope of permissions that may be granted but do not define specific permissions. For example, an identity-based policy may control what actions a role can perform on a resource (and may also define the conditions); a resource-based policy may also define certain permissions on certain actions that can be performed on that resource. These permissions may overlap or even conflict in scope with respect to the level of access for role, for a system resource, or both. Because a role may be assigned more than one policy, the number of interactions between access permissions defined by multiple security policies may grow exponentially large as the number of roles and policies increases. For a requesting system with a large number of roles and a large number of policies, evaluation of each role and its associated permissions is neither efficient nor feasible. A set of effective access permissions provides a means for a system to efficiently evaluate all access permissions assigned to a role by resolving the interdependencies of the different access defined by all the security policies associated with a role. [0216] Based on the set of effective access permissions, an enterprise system may perform preemptive evaluation of all access permissions associated with a role to identify roles that have over-privileged access permission to system resources. The preemptive evaluation of all access permissions can be performed with respect to a set of security rules, which can be defined by an enterprise or a corporation based on their security needs and some information security standards. Security rules based on information security standards can be used to implement information security controls to meet an organization’s requirements and prevent from granting a role some over-privileged access to system resources. There are many information security standards, e.g., International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 27000 series of standard. Security rules based on information security standards can demonstrate in a methodical and certifiable manner that an organization conforms to industry best practices and procedures.

[0217] A further technical benefit is the improvement in the functionality of the enterprise system which may now persistently monitor roles across the entire system, ascertaining non-compliance with permission controls established by the enterprise system and/or the IAM system, and provide corrective measures to the over-privileged role prior to any request being submitted to the IAM system. The enterprise system may preemptively identify any potential security concerns with regard to its roles such as over privileged roles or roles that have been compromised and prevent any requests from that role being submitted to the IAM system. In this manner, the enterprise system may prevent security breaches associated with its roles before they occur.

[0218] FIG. 11 is a block diagram of an environment 11100 for determining whether a role has an effective access permission defined by a set of security policies to a system resource that is over-privileged with respect to a security rule, according to some embodiments. Environment 11100 can include enterprise system 11110, policy engine 11120, and IAM system 11131, which may reside in a cloud computing system 11130. In addition, enterprise system 11110 can be communicatively coupled to a computing device 11140 that can be used by a person 11142.

[0219] In some examples, environment 11100 can include a network formed by some or all of computing device 11140, enterprise system 11110, and cloud computing system 11130. For example, environment 11100 can include an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless wide area network (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, any other type of network, or a combination of two or more such networks.

[0220] In some examples, cloud computing system 11130 can include an environment that delivers computing as a service by sharing resources, services, etc. located in cloud computing system 11130. Cloud computing system 11130 can provide computation, software, data access, storage, and/or other services that do not require end-user knowledge of a physical location and configuration of a system and/or a device that delivers the services. In some examples, cloud computing system 11130 can include Amazon® Web Services (AWS), Microsoft® Azure, Google® Cloud, IBM® Cloud, Oracle® Cloud Infrastructure, or any other cloud computing system.

[0221] Cloud computing system 11130 can include IAM system 11131, which can manage system resources 11133. A system resource can be referred to as a resource. IAM system 11131 can receive a request 11119 for access to system resources 11133 from entities in enterprise system 11110 such as entity 11111. IAM system 11131 can include a plurality of data storage systems for storing system resources 11133 to be accessed by enterprise system 11110. IAM system 11131 can include a database management system or relational database tool. IAM system 11131 can further include a message queue or stream processing platform such as Apache Kafka or Apache Spark or other data storage systems like Apache Hadoop, Hadoop Distributed File System (HDFS), or Amazon S3, by way of non-limiting examples. IAM system 11131 can be a data lake, data silo, semi- structured data system (comma-separated values file, logs, xml, etc.), unstructured data system, binary data repository, or other suitable repository. IAM system 11131 can store thousands, millions, billions, or trillions (or more) of objects, rows, transactions, records, files, logs, etc. while allowing for the creation, modification, retrieval, archival, and management of this data.

[0222] System resources 11133 can include hardware, e.g., processor, memory, storage, or software, e.g., operating system, application software, database, used for various computing purposes. Examples of system resources 11133 can include Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift, an Amazon® Web Services (AWS) service, an EC2 instance, a S3 bucket, or a DynamoDB table, S3 Glacier vaults, Amazon Simple Notification Service (SNS) topics, or Amazon Simple Queue Service (SQS) queues. System resources 11133 can be products or services provided by any other vendors besides Amazon®.

[0223] In some examples, computing device 11140 can be a wireless communication device, a smart phone, a laptop, a tablet, a personal assistant, a monitor, a wearable device, an Internet of Thing (IoT) device, a mobile station, a subscriber station, a remote terminal, a wireless terminal, or a user device. Computing device 11140 can be configured to operate based on a wide variety of wireless communication techniques. These techniques can include, but are not limited to, techniques based on 3rd Generation Partnership Project (3 GPP) standards. In some other examples, computing device 11140 can be a desktop workstation, a server, and/or embedded system, a computing device communicatively coupled to enterprise system 11110 by wired lines, to name a few non limiting examples, or any combination thereof. Person 11142 can use computing device 11140 to interact with enterprise system 11110, and request system resources 11133 managed by IAM system 11131 and residing in cloud computing system 11130.

Computer device 140 can include processor 11141, memory device 11143, and a graphical user interface (GUI) 11145.

[0224] In some examples, enterprise system 11110 can include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. Enterprise system 11110 can include processors, an operating system, a storage coupled to processor, etc.. Enterprise system 110 may be implemented as any system that requests access to resources 11133 protected by IAM system 11131 that utilizes security policies and access permissions for controlling access to requested resources.

[0225] In some embodiments, enterprise system 11110 can include any number of entities, e.g., entity 11111, a policy database 11112, and a security governance guideline 11117. In some examples, entity 11111 can be resource objects to be used for authentication to access an account of IAM system 11131. Entity 11111 can include one or more roles, e.g., role 11113. Policy database 11112 can include one or more security policies, e.g., policy 11113a, policy 11113b, or policy 11113c, associated with roles, e.g., role 11113. A security policy can be referred to as a policy. Enterprise system 11110 is communicatively coupled to policy engine 11120, where operations about security policies and access permissions can be performed. In some embodiments, policy database 11112 can be implemented separately from enterprise system 11110, such as in policy engine 11120 and/or IAM system 11131 coupled to enterprise system 11110. In some other embodiments, policy engine 11120 can be implemented as a part of enterprise system 11110.

[0226] Combined, the security policies, e.g., policy 11113a, policy 11113b, or policy

11113c, can generate an effective policy 11123, which can define a set of effective access permissions 11125 by role 11113 to access system resources 11133. The generation of effective policy 11123 and the set of effective access permissions 11125 can be performed by an effective policy generator 11121 within policy engine 11120. The set of effective access permissions 11125 represent the actual access permissions granted to role 11113 by the security policies associated with role 11113. More details of generation of the set of effective access permissions 11125 are shown in FIGS. 13A-13D. In some examples, a system administrator creates the set of security policies that generates the set of effective access permissions 11125 for role 11113.

[0227] In addition, security governance guideline 11117 defines a set of security rules

11124 including various security rules, e.g., security rule 11126. Security rule 11126 can specify what kind of access permissions should be granted to various roles or system resources in an enterprise or an organization. As such, security rule 11126 can set up the scope for what access permission is allowed to be granted to various roles, e.g., role 11113. For example, security rule 11126 can set up a permissible scope of a name for role 11113 or a permissible scope of a name for system resources 11133 being specified by any security policies. As an example, security rule 11126 can include various statements, e.g., “a role name must be a machine” or “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket.”

[0228] Often, the set of security policies defining the actual effective security permission for role 11113 and the set of security rules 11124 defining the permissible scopes for access permissions for role 11113 are defined or generated at different times by different people within the enterprise. Hence, it is possible that the set of effective access permissions 11125 actually granted to role 11113 can be different from what is allowed to be granted to role 11113 as defined by security rule 11126 or the set of security rules 11124. An access permission of the set of effective access permissions 11125 is an over privileged access permission when the access permission exceeds the permissible scope defined by security rule 11126. Detection of an over-privileged access permission 11128 is performed by compliance engine 11122 based on security rule 11126 of the set of security rules 11124 that is defined based on security governance guideline 11117. More details of detection of an over-privileged access permission are shown in FIG. 14.

[0229] In some examples, entity 11111 can be resource objects to be used for authentication to access an account of IAM system 131. Entity 11111 can have one or more associated roles, e.g., role 11113. Role 11113 can be stored in policy database 11112. Role 11113 can be used to delegate access to users, applications, or services that do not normally have access to system resources 11133. For example, role 11113 can be used to delegate access by a mobile app on computing device 11140 to use system resources 11133, which would not be normally accessible by a mobile application. Role 11113 can be used to grant access to resources in one account to a trusted principal in a different account. Instead of being uniquely associated with one person, role 11113 is intended to be assumable by anyone who needs it. Also, role 11113 may not have standard long term credentials such as a password or access keys associated with it. Instead, role 11113 can be provided with temporary security credentials for a session when the role is effective or valid.

[0230] Role 11113 can include a machine 11115 or a user 11116. Machine 11115 can be a representation of computing device 11140, while user 11116 can be a representation of person 11142. User 11116 can be an identity of person 11142. Role 11113 can be an identity that has specific access permissions. Role 11113 can access system resources 11133 based on access permissions defined by associated security policies. Role 11113 can be associated with any number of different policies such as policy 11113a, policy 11113b, and policy 11113c. A security policy, e.g., policy 11113a, policy 11113b, or policy 11113c can be stored in a storage of cloud computing system 11130.

[0231] Entity 11111, e.g., role 11113, can submit a request 11119 for accessing system resources such as system resources 11133 which are protected by IAM system 11131. Request 11119 can be allowed or denied based on the security policies, e.g., policy 11113a, policy 11113b, and policy 11113c, associated with role 11113. Request 11119 can include a request context information, which is used to evaluate and authorize the request. The request context information can include actions or operations to be performed, resources upon which the actions or operations are performed, a principal sending request 11119, environment data such as IP address, user agent, SSL enabled status, or the time of day; and resource data such as data related to the resource that is being requested. Information about the principal can include the policies that are associated with the principal. Resource data can include information such as a database table name or a tag on an Amazon EC2 instance.

[0232] If role 11113 has been granted an over-privileged access permission, request

11119 may be able to access system resources 11133 that should not be allowed to be accessed according to security rule 11126. However, IAM system 11131 or enterprise system 11110 may not know such an over-privileged access permission has been granted until some bad consequence has happened after role 11113 has accessed the system resource. Any corrective action to its roles is therefore reactive and presents a potential security concern because roles are not evaluated until a request is made and granted, and potentially some bad consequence may have already happened.

[0233] In some examples, policy engine 11120 can be used to evaluate the set of effective access permissions 11125 of role 11113 without performing any request. Policy engine

11120 can be implemented as a separate component as shown in FIG. 11 or integrated as part of enterprise system 11110. Policy engine 11120 can include effective policy generator 11121, the set of security rules 11124, and compliance engine 11122. Effective policy generator 11121 can be configured to receive all policies associated with a role, such as policy 11113a, policy 11113b, and policy 11113c associated with role 11113, and generate effective policy 11123 from the received policies.

[0234] Compliance engine 11122 can be configured to receive the effective policy 11123 indicating the set of effective access permissions 11125 from effective policy generator 11121, and security rule 11126, and determine whether there is an over-privileged access permission 11128. If the set of effective access permissions 11125 contains over privileged access permission 11128, compliance engine 11122 can identify the related security policies that generated such over-privileged access permission 11128, and label the identified security policies having a compliance status as “non-compliant.” On the other hand, if the set of effective access permissions 11125 does not contain any over- privileged access permission, compliance engine 11122 can label the effective policy 11123 having a compliance status as “compliant”. Accordingly, role 11113 has a compliance status as “compliant”. Therefore, operations performed by compliance engine 11122 can improve the security of IAM system 11131 or enterprise system 11110, before any request is made to IAM system 11131 by enterprise system 11110. More detailed operations of compliance engine 11122 are provided after FIGS. 12A-12B and 13A-13D are described below to provide more details for the set of effective access permissions 11125 as inputs to compliance engine 11122.

[0235] FIGS. 12A-12B are diagrams illustrating example security policies, according to some embodiments. FIG. 12A shows identity -based policy 12201, identity -based policy 12203, resource-based policy 12202, and resource-based policy 12204, which can be examples of policy 11113a, policy 11113b, and policy 11113c, as shown in FIG. 11. A security policy, e.g., policy 201, policy 202, policy 203, and policy 204, can be stored in a storage of cloud computing system 11130. A security policy, e.g., e.g., policy 12201, policy 12202, policy 12203, and policy 12204, can be an identity -based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, a session policy, an inline policy, or any kind of security policy.

[0236] In some examples, an identity-based policy can be attached to an identity such as a user, a group of users, or a role, and grant permissions to the identity. For example, as shown in FIG. 12A, policy 12201 specifies a user John Doe can list or read resource X, while policy 12203 specifies a user Jane Doe can list, read, or write resource X, Y, Z.

[0237] In some examples, a resource-based policy can grant permissions to a principal

(account, user, role, or federated user) specified in the policy. The permissions define what the principal can do with the resource to which the policy is attached. For example, as shown in FIG. 12A, policy 12202 specifies for resource X, user John Doe can be granted read or write permission, user Jane Doe can be granted list or write permission.

In addition, for resource Y, policy 12204 specifies that user John Doe can be granted list or write permission, user Alice Smith can be granted list or read permission, and user Jane Doe can be denied any access.

[0238] In some examples, a security policy can be specified by natural language as shown in FIG. 12 A. In some other examples, as shown in FIG. 12B, a security policy can be specified by one or more statements in a markup language or structured language. A security policy, e.g., policy 12201, policy 12202, policy 12203, and policy 12204, can be contained in a document specified by a markup language, such as a JavaScript Object Notation (JSON) document, a XML document, a YAML document, or any other documents containing statements in structured languages.

[0239] In some examples, as shown in FIG. 12B, a security policy 12210 can include an effect statement 12211, a principal statement 12213, an action statement 12215, a resource statement 12217, a condition statement 12219, or some other statements. Effect statement 12211 can specify either Allow or Deny to indicate whether the policy allows or denies access. Principal statement 12213 can be used to indicate an account, a user, a role, or a group of users to which the access permission is allowed or denied. Action statement 12215 can include a list of actions to be performed on the one or more system resources that the policy allows or denies. Action statement 12215 can include a read only action, a view action, an update action, a write action, a delete action, or some other actions. Resource statement 12217 can specify a list of resources to which the actions apply. Condition statement 12219 can specify the circumstances under which the policy grants permission. In addition, there can be other statements, such as a version statement, a statement name (also referred to as an identification (ID)), and more, not shown.

[0240] In some examples, a statement can include a name for a role, e.g., name 12221 within principal statement 12213; a name for a system resource, e.g., name 12223, name 12225, name 12227, within resource statement 12217; or a name for an action, e.g., name 12229 within action statement 12215, or some other names. A name for a system resource can include one or more system resources. For example, name 12223 includes only “*”, which is a wildcard referring to any system resources in the account. On the other hand, name 12227 includes “example bucket”, which refers to only one bucket stored in S3. In addition, name 12225 includes “confidential-data/*”, which refers to a set of system resources within the folder “confidential-data.” The set of system resources referred to by a name for a system resource defines a scope of the name for the system resource. For example, a scope of name 12227 includes only “example bucket”, while a scope of name 12223 includes every system resource of the account, A name for system resource can be defined in a resource statement or other statement for a security policy. Similarly, a scope of a name for a role can include one or more roles. For example, name 12221 “AWS-account-ID:user/user-name” can refer to a single user. On the other hand, a name “AWS-account-ID:user/*” can refer to a group of users. When a scope of the name for a system resource in a security policy statement includes more than one system resource, the security policy statement can be applicable to any system resource whose name is included in the scope of the name for the system resource. Similarly, when a scope of a name for a role in a security policy statement includes more than one role, the security policy statement can be applicable to any role whose name is included in the scope of the name for the role.

[0241] FIGS. 13A-13D are diagrams illustrating example effective access permissions defined by a set of security policies, according to some embodiments. FIGS. 13A-13D illustrate security policy 13311, policy 13313, policy 13325, policy 13337, and policy 13349, which can be examples of policy 11113a, policy 11113b, and policy 11113c, as shown in FIG. 11.

[0242] As illustrated in FIG. 13 A, both policy 13311 and policy 13313 are identity-based policies. Policy 13311 is applicable to a single role, e.g., role 11113, while policy 13313 is applicable to a group of roles including role 11113. Hence, the scope of policy 13311 is a set of roles including only one role, while the scope of policy 13313 is a set of roles including a group of roles. In the description below, the scope of policy 13311 can be simply denoted by the policy number “13311”, and the scope of policy 13313 can be simply denoted by the policy number “13313”. For an action to be performed, an effective access permission can be in a union of the set of access permissions defined by policy 13311 or policy 13313. Hence, the set of effective access permissions 11125 defined by policy 13311 and policy 13313 is 13311 U 13313. Accordingly, given policy 13311 and policy 13313, for request 11119, IAM system 11131 can check both policy 13311 and policy 13313 for at least one Allow action for granting an access to the system resource for role 11113. As long as one Allow action is found for a role, even if there is another policy statement that indicates a Deny action, the role is still allowed access based on the union of the scopes of the policy statements.

[0243] As illustrated in FIG. 13B, policy 13325 is a resource-based policy. For an action to be performed, an effective access permission can be in a union of the set of access permission defined by policy 13311, policy 13313, and policy 13325, e.g., 13311 U 13313 U 13325. Hence, for request 11119, IAM system 11131 can check policy 13311, policy 13313, and policy 13325 for at least one Allow action for granting an access to the system resource.

[0244] As illustrated in FIG. 13C, policy 13337 is a session policy. In this case, the permissions from resource-based policy 13325 are added to the role or user's identity- based policy 13311 and policy 13313 before the session is created. Session policy 13337 limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session’s permissions are the intersection of the session policies and either the resource-based policy or the identity -based policy, denoted as (13311 u 13313 U 13325) P 13337.

[0245] As illustrated in FIG. 13D, policy 13349 is a permissions boundary, which sets the maximum permissions that an identity-based policy can grant to an entity (user or role). When a permissions boundary is set for an entity, the entity can perform only the actions that are allowed by both its identity-based policies or resource-based policies and its permissions boundaries. Hence, the effective access permission is (13311 U 13313 U 13325) P 13337 P 13349.

[0246] The examples of effective access permissions shown in FIGS. 13A-13D are only for example purpose and are not limiting. There can be other kinds of security policies. An organization’s service control policies (SCPs) can specify the maximum permissions for an organization or organizational unit (OU), which is applicable to individual roles, e.g., role 11113. The SCP maximum applies to principals in member accounts, including each AWS account root user of the organization. If an SCP is present, identity -based and resource-based policies grant permissions to principals in member accounts only if those policies and the SCP allow the action. If both a permissions boundary and an SCP are present, then the boundary, the SCP, and the identity -based policy must all allow the action. In addition, access control lists (ACLs) are service policies that control which principals in another account can access a resource.

[0247] Accordingly, FIGS. 13A-13D illustrate examples for the set of effective access permissions, which can be examples of the set of effective access permissions 11125 defined by a set of security policies. The set of effective access permissions 11125 can be generated by effective policy generator 11121 within policy engine 11120. Effective policy generator 11121 can receive all of the security policies applicable or associated with role 11113, which is called the effective policy 11123. Based on the effective policy 11123, the set of effective access permissions 11125 can be generated similar to examples shown in FIGS. 13A-13D. Furthermore, the set of effective access permissions 11125 is provided as inputs to compliance engine 11122 to detect whether there is an over privileged access permission 11128 with respect to security rule 11126.

[0248] Referring back to FIG. 11, compliance engine 11122 can be configured to receive the set of security rules 11124 including security rule 11126. Security rule 11126 can be generated based on security governance guideline 11117. In some examples, security rule 11126 can be created based on an information security standard, an International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 27000 series of standard, a National Institute of Standards and Technology (NIST)

Special Publications 800 standard, an Information Security Forum (ISF) Standard of Good Practice (SoGP) standard, or a Control Objectives for Information and related Technology (COBIT) standard. In some examples, security rule 11126 can be referred to as permission controls.

[0249] In some examples, security rule 11126 can be specified in natural language (e.g., in plain English). For example, security rule 11126 can include any or all of the following statements: “a resource name can include 5 characters, and followed by a wild card *”; “a role name must be a machine”; “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket”; or “a role name must be limited to a single entity account.” In some examples, the English statement can be translated into a more structured statement. For example, “5 characters, and followed by a wild card *” can be translated into the format of “?????” + The process of converting security rule 11126 in natural language into structured statement can be performed by natural language processing, by analyzing the syntax rules and semantics rules of the security rule statements. Security rule 11126 can include multiple statements, where each statement can impose a condition on a name for system resource, a name for role, a name for action, or some other conditions. All the statements together in security rule 11126 can define a permissible scope of a name for system resources, which can be an intersection set of the allowable names for system resources defined by all statements in security rule 11126. Similarly, all the statements together in security rule 11126 can define a permissible scope of a name for a role, a permissible scope of a name for an action, and other permissible scopes. [0250] Compliance engine 11122 can detect whether there is over-privileged access permission 11128 among the set of effective access permissions 11125 with respect to security rule 11126. Compliance engine 11122 performs such detection based on a method presented in FIG. 14. In some other examples, compliance engine 11122 can detect whether there is an over-privileged access permission 11128 by directly receiving the security policies, e.g., policy 11113a, policy 11113b, and policy 11113c. Compliance engine 11122 can detect over-privileged access permissions without having to submit requests to IAM system 11131. The request-response interactions between enterprise system 11110 and IAM system 11131 can be considered to occur independently of the policy evaluations performed by compliance engine 11122 or policy engine 11120. Since compliance engine 11122 is located outside IAM system 11131 and separated from IAM system 11131, compliance engine 11122 is implemented by a particular machine, instead of a generic computing system. For example, compliance engine 11122 is separated from IAM system 11131. On the other hand, a generic computing system such as IAM system 11131 should be separated from compliance engine 11122 to be protected, and should not be used to implement compliance engine 11122. Therefore, this particular machine implementation of compliance engine 11122 can provide added security protection for IAM system 11131. Based on such an implementation on a special machine, compliance engine 11122 can provide added security protection for IAM system 11131. Some detailed operations performed by compliance engine 11122 are shown in FIG. 14.

[0251] FIG. 14 is a flowchart illustrating a method 14400 for determining whether a role has an effective access permission defined by a set of security policies to a system resource that is over-privileged with respect to a security rule, according to some embodiments. Method 14400 can be performed by compliance engine 11122, which can be operated by enterprise system 11110. In addition, method 14400 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 14, as will be understood by a person of ordinary skill in the art(s). [0252] In 14402, compliance engine 11122 can compare a scope of a name for a system resource defined in a first security policy with a permissible scope of the name for the system resource defined by a security rule to obtain a first comparison result. For example, compliance engine 11122 can compare a scope of name 12223, name 12225, and name 12227 for system resources within resource statement 12217 of security policy 12210, with a permissible scope of the name for system resources defined by security rule 11126. The statement of security rule 11126, “a wildcard is allowed after a specific bucket to enable access to all objects in a single bucket,” defines a permissible scope for a name for system resources. Accordingly, the scope of name 12227 includes only one system resource, “example bucket”. Hence, the scope of name 12227 is within the permissible scope of a name for system resources defined by security rule 11126. On the other hand, the scope of name 12223 includes any system resources in the account, which is referred by Hence, the scope of name 12223 exceeds the permissible scope of a name for system resources defined by security rule 11126. Furthermore, the scope of name 12225 includes system resources within a folder “confidential-data/*”, which can be within a single bucket. Hence, the scope of name 12225 is within the permissible scope of a name for system resources defined by security rule 11126 if the folder “confidential-data/” is within a single bucket. The first comparison result indicates whether the scope of the name for a system resource defined in the first security policy exceeds the permissible scope of the name for the system resource defined by the security rule.

[0253] In 404, compliance engine 11122 can compare a scope of a name for a role defined in a second security policy with a permissible scope of the name for the role defined by the security rule to obtain a second comparison result. For example, compliance engine 11122 can compare a scope of name 12221 for a role within principal statement 12213 of security policy 12210, with a permissible scope of the name for the role defined by security rule 11126. The scope of name 12221 includes only one user account, “AWS-account-ID:user/user-name”. If security rule 11126 includes the statement, “a role name must be a machine”, the permissible scope of a role must be a machine. Hence, the scope of name 12221 for a role exceeds the permissible scope of a role as defined by security rule 11126. On the other hand, if security rule 11126 includes a different statement, “a role name must be limited to a single entity account”, the permissible scope of a name for a role can include multiple roles within a single entity account. Hence, the scope of name 12221, including “AWS-account-ID:user/user-name”, is within the permissible scope of the name for the role as defined by security rule 11126. Similarly, the scope of a role name, “AWS-account-ID:user/*”, is within the permissible scope of the name for a role as defined by security rule 11126. The second comparison result indicates whether the scope of the name for a role defined in the second security policy exceeds the permissible scope of the name for the role defined by the security rule.

[0254] In 406, compliance engine 11122 can determine, based on the first comparison result and the second comparison result, whether or not the role has an over-privileged access permission contained in a set of effective access permissions to the system resource defined by the first security policy and the second security policy. For example, compliance engine 11122 can determine role 11113 has over-privileged access permission 11128 when the scope of the name 11223 for a system resource exceeds the permissible scope of the name for the system resource defined in security rule 11126, or when the scope of the name 11221 for a role exceeds the permissible scope of name for the role defined in security rule 11126. On the other hand, compliance engine 11122 can determine role 11113 does not have an over-privileged access permission when the scope of the name for a system resource does not exceed the permissible scope of the name for the system resource defined in the security rule, and the scope of the name for a role does not exceed the permissible scope of the name for the role defined in the security rule.

[0255] In 14408, compliance engine 11122 can generate a notification to indicate a compliance status of the first security policy and the second security policy for the role based on whether or not the role has the over-privileged access permission. For example, the first security policy and the second security policy can represent any policy of effective policy 11123. When role 11113 is determined to have over-privileged access permission 11128, compliance engine 11122 can generate the notification to indicate that the compliance status of the effective security policies for role 113 is non-compliant. On the other hand, when determining role 11113 does not have an over-privileged access permission, compliance engine 11122 can generate the notification to indicate that the compliance status of the effective security policies for role 11113 is compliant.

[0256] In some examples, there can be other operations not shown in method 14400. For example, method 14400 only illustrates operations performed on the first security policy and the second security policy. In some embodiments, method 14400 can be performed in many iterations on all the security policies associated with a role. If the set of effective access permissions 11125 contains over-privileged access permission 11128, compliance engine 11122 can identify the related security policies that generate such over-privileged access permission 128, and label the identified security policies having a compliance status as non-compliant. Similarly, role 11113 has a compliance status as non-compliant. On the other hand, if the set of effective access permissions 11125 does not contain any over-privileged access permission, compliance engine 11122 can label effective policy 11123 having a compliance status as compliant. Accordingly, role 11113 has a compliance status as compliant.

[0257] In some examples, when the compliance engine 11122 generates a notification to indicate an over-privileged access permission, the notification may be transmitted to enterprise system 11110 to allow enterprise system 11110 to take corrective action with respect to that role or the effective policy. For example, compliance engine 11122 can generate a remediation security policy for correcting effective policy 11123 including the name for the system resource or the name for the role that exceeds the permissible scopes defined by security rule 11126. Other actions may be performed. For example, the role can be disabled or restricted from transmitting requests for system resources until the corrective action is taken. Such restrictions may be implemented by having a restriction module in compliance engine 11122 to check any request for compliance before sending the request to IAM system 11131. Actions taken against a role may impact user accounts associated with that role. In an embodiment, the notification may also be transmitted to IAM system 11131 so that IAM system 11131 may also track compliance with its permissive scope of access for its resources.

[0258] In some embodiments, because determining whether access permissions or roles are over-privileged occurs independently of access requests to IAM system 11131, compliance engine 11122 can efficiently perform persistent monitoring of the roles to determine whether all its roles are compliant with permissible scopes established by security rule 11126. Accordingly, compliance monitoring may occur as needed: weekly, daily, or even 24/7. Such frequent compliance monitoring cannot be efficiently performed for request-based access control. Without the operations disclosed in this disclosure, enterprise system 11110 would be required to submit requests from each role for each policy and for each permission in order to evaluate whether a permission is allowed for that role.

[0259] Various embodiments may be implemented, for example, using one or more well- known computer systems, such as computer system 15500 shown in FIG. 15. One or more computer systems 15500 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

[0260] Computer system 15500 may include one or more processors (also called central processing units, or CPUs), such as a processor 15504. Processor 15504 may be connected to a communication infrastructure or bus 15506.

[0261] Computer system 15500 may also include user input/output device(s) 15503, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 15506 through user input/output interface(s) 15502.

[0262] One or more of processors 15504 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0263] Computer system 15500 may also include a main or primary memory 15508, such as random access memory (RAM). Main memory 15508 may include one or more levels of cache. Main memory 15508 may have stored therein control logic (i.e., computer software) and/or data.

[0264] Computer system 15500 may also include one or more secondary storage devices or memory 15510. Secondary memory 15510 may include, for example, a hard disk drive 15512 and/or a removable storage device or drive 15514. Removable storage drive 15514 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.

[0265] Removable storage drive 15514 may interact with a removable storage unit 15518.

Removable storage unit 15518 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 15518 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 15514 may read from and/or write to removable storage unit 15518. [0266] Secondary memory 15510 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 15500. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 15522 and an interface 15520. Examples of the removable storage unit 15522 and the interface 15520 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

[0267] Computer system 15500 may further include a communication or network interface 15524. Communication interface 15524 may enable computer system 15500 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 15528). For example, communication interface 15524 may allow computer system 15500 to communicate with external or remote devices 15528 over communications path 15526, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 15500 via communication path 15526.

[0268] Computer system 15500 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

[0269] Computer system 15500 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms. [0270] Any applicable data structures, file formats, and schemas in computer system

15500 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

[0271] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 15500, main memory 15508, secondary memory 15510, and removable storage units 15518 and 15522, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 15500), may cause such data processing devices to operate as described herein. For example, control logic may cause processor 15504 to compare a scope of a name for a system resource defined in a first security policy with a permissible scope of the name for the system resource defined in a security rule to obtain a first comparison result; compare a scope of a name for a role defined in a second security policy with a permissible scope of the name for the role defined in the security rule to obtain a second comparison result; determine, based on the first comparison result and the second comparison result, whether or not the role has an over privileged access permission contained in a set of effective access permissions to the system resource defined in the first security policy and the second security policy; and generate a notification to indicate a compliance status of the first security policy and the second security policy for role based on whether or not the role has the over-privileged access permission.

[0272] Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 15. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.

[0273] It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

[0274] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

[0275] Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

[0276] References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0277] The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0278] It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.

[0279] The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof.

[0280] The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0281] The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0282] The claims in the instant application are different than those of the parent application or other related applications. The Applicant therefore rescinds any disclaimer of claim scope made in the parent application or any predecessor application in relation to the instant application. The Examiner is therefore advised that any such previous disclaimer and the cited references that it was made to avoid, may need to be revisited. Further, the Examiner is also reminded that any disclaimer made in the instant application should not be read into or against the parent application.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method for determining effective access permissions defined by security policies associated with a principal managed by an identity and access management (IAM) system, the method comprising: identifying a first policy statement associated with the principal, wherein the first policy statement specifies that members of a first identity set including the principal are allowed to access a first system resource set of the IAM system; identifying a second policy statement, wherein the second policy statement specifies that members of a second identity set are denied access to a second system resource set of the IAM system; determining whether or not there is a shared system resource belonging to both the first system resource set and the second system resource set, and whether or not the second identity set includes the principal; determining that the second policy statement overlaps with the first policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the first system resource set and the second system resource set, and the second identity set includes the principal, wherein the effective access permissions associated with the principal are defined by a system resource included in the first system resource set but not included in the second system resource set; and placing, when the second policy statement is determined to overlap with the first policy statement, the second policy statement into a list of policy statements associated with the first policy statement with respect to the effective access permissions.

2. The computer-implemented method of claim 1, further comprising: identifying a third policy statement, wherein the third policy statement specifies that members of a third identity set are denied access to a third system resource set of the IAM system; determining whether or not there is a shared system resource belonging to both the first system resource set and the third system resource set, and whether or not the third identity set includes the principal; determining that the third policy statement does not overlap with the first policy statement with respect to the effective access permissions for the principal when there is no shared system resource belongs to the first system resource set and the third system resource set, or the third identity set does not include the principal, wherein the third policy statement is not placed on the list of policy statements associated with the first policy statement with respect to the effective access permissions.

3. The computer-implemented method of claim 1, identifying a third policy statement associated with the principal, wherein the third policy statement specifies that members of a third identity set including the principal are allowed to access a third system resource set of the IAM system; identifying a fourth policy statement, wherein the fourth policy statement specifies that members of a fourth identity set are denied access to a fourth system resource set of the IAM system; determining whether or not there is a shared system resource belonging to both the third system resource set and the fourth system resource set, and whether or not the fourth identity set includes the principal; determining that the fourth policy statement overlaps with the third policy statement with respect to the effective access permissions for the principal when the shared system resource belongs to the third system resource set and the fourth system resource set, and the fourth identity set includes the principal, wherein the effective access permissions associated with the principal are defined by a system resource included in the third system resource set but not included in the fourth system resource set; and placing, when the fourth policy statement is determined to overlap with the third policy statement, the fourth policy statement into a list of policy statements associated with the third policy statement with respect to the effective access permissions.

4. The computer-implemented method of claim 1, wherein the first policy statement or the second policy statement is a resource based policy statement or an identity based policy statement.

5. The computer-implemented method of claim 1, wherein the first system resource set or the first identity set of the first policy statement overlaps with a system resource set or an identity set of a limiting security policy that allows the principal to the system resource set of the limiting security policy, or there is no limiting security policy associated with the principal to limit the effective access permissions of the principal.

6. The computer-implemented method of claim 5, wherein the limiting security policy includes a permissions boundary, an organizational service control policy (SCP), or an access control list.

7. The computer-implemented method of claim 1, wherein the first policy statement, the second policy statement, and the list of policy statements associated with the first policy statement are stored in a cloud storage.

8. The computer-implemented method of claim 1, wherein the principal includes an IAM user, an IAM role, or an application.

9. The computer-implemented method of claim 1, wherein the first policy statement and the second policy statement are specified by a markup language.

10. The computer-implemented method of claim 1, wherein the first policy statement includes a first action to be allowed on the first system resource set or by the first identify set, and the second policy statement includes a second action to be denied on the second system resource set or by the second identify set.

11. An apparatus for managing system resources, the apparatus comprising: a display device configured to display a graphical user interface (GUI); a storage device coupled to the display device, and configured to store a set of security rules; and a processor communicatively coupled to the storage device and the display device, and configured to: select a first role administered by an entity and a second role administered by the entity; identify a first set of security policies associated with the first role, and a second set of security policies associated with the second role, wherein the first set of security policies includes a first security policy and a second security policy; generate a first set of effective access permissions associated with the first role, and a second set of effective access permissions associated with the second role, wherein the first set of effective access permissions is generated based on the first set of security policies by resolving at least a conflict between the first security policy and the second security policy, and wherein the first set of effective access permissions defines a scope of a name for a system resource, or defines a scope of a name for a role; compare a permissible scope of the name for the system resource defined by a set of security rules with the scope of the name for the system resource to generate a first comparison result, and compare a permissible scope of the name for the role defined by the set of security rules with the scope of the name of the role to generate a second comparison result; and display on a graphical user interface (GUI), the first role and a first compliance status with respect to the set of security rules, and the second role and a second compliance status with respect to the set of security rules, wherein the first compliance status of the first role with respect to the set of security rules is determined based on the first comparison result and the second comparison result.

12. The apparatus of claim 11, wherein the first compliance status is non-compliant when the scope of the name for the system resource defined by the first set of effective access permissions exceeds the permissible scope of the name for the system resource defined by the set of security rules, or when the scope of the name for the role defined by the first set of effective access permissions exceeds the permissible scope of the name for the role defined by the set of security rules.

13. The apparatus of claim 12, wherein the processor is further configured to: generate a notification to the first role when the first compliance status of the first role is non-compliant.

14. The apparatus of claim 13, wherein the processor is further configured to: generate a remediation security policy for correcting the first set of security policies that generates the first set of effective access permissions including the name for the system resource or the name for the role; and transmit, to the first role, an indication of the remediation policy.

15. The apparatus of claim 11, wherein the first compliance status is compliant when the scope of the name for the system resource defined by the first set of effective access permissions does not exceed the permissible scope of the name for the system resource defined by the set of security rules, and the scope of the name for the role defined by the first set of effective access permissions does not exceed the permissible scope of the name for the role defined by the set of security rules.

16. The apparatus of claim 11, wherein the first role and the first compliance status, and the second role and the second compliance status are displayed in a tabular form on the GUI.

17. The apparatus of claim 11, wherein the first set of security policies are stored in a cloud storage, the first set of security policies are specified by a markup language, and the first set of security policies include an identity -based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, or a session policy.

18. The apparatus of claim 11, wherein the first set of security policies includes an action to be performed on the system resource, and an effect to indicate Allow or Deny of the action to be performed on the system resource.

19. A non-transitory computer-readable medium storing instructions, the instructions, when executed by a processor, cause the processor to perform operations comprising: comparing a scope of a name for a system resource defined in a first security policy with a permissible scope of the name for the system resource defined in a security rule to obtain a first comparison result; comparing a scope of a name for a role defined in a second security policy with a permissible scope of the name for the role defined in the security rule to obtain a second comparison result; determining, based on the first comparison result and the second comparison result, whether or not the role has an over-privileged access permission contained in a set of effective access permissions to the system resource defined in the first security policy and the second security policy, and generating a notification to indicate a compliance status of the first security policy and the second security policy for the role based on whether or not the role has the over privileged access permission.

20. The non-transitory computer-readable medium of claim 19, wherein the determining whether or not the role has the over-privileged access permission comprises determining the role has the over-privileged access permission when the scope of the name for the system resource exceeds the permissible scope of the name for the system resource defined in the security rule, or when the scope of the name for the role exceeds the permissible scope of the name for the role defined in the security rule; and wherein the generating the notification comprises generating the notification to indicate that the compliance status of the first security policy and the second security policy for the role is non-compliant.