Security zone policy enforcement in cloud infrastructure system

Abstract

To provide a cloud-based security solution that provides a robust and secure framework that manages and enforces a security policy related to various resources managed in a cloud.SOLUTION: A cloud-based security solution is achieved by a security zone policy enforcement system in a cloud service provider infrastructure. A method includes: receiving a request to execute an operation for a resource; determining a compartment associated with the resource; determining that the compartment is associated with a security zone; determining a set of one or more security zone policies applicable to the resource; determining that the operation for the resource is permitted on the basis of the set of one or more security zone policies; and allowing the operation to be executed for the resource in response to the determination that the operation for the resource is permitted.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. Provisional Patent Application No. 17 / 393,344, filed August 3, 2021, entitled "Security Zone Policy Enforcement in a Cloud Infrastructure System." This application claims the benefit of and priority to U.S. Provisional Patent Application No. 17 / 393,347, the contents of which are incorporated herein by reference in their entirety for all purposes.

[0002] This application is a continuation of U.S. Provisional Patent Application No. 63 / 068,94, filed August 21, 2020, entitled "Secure Resource Provisioning in a Virtual Computing Environment." 3, and a paper entitled "Secure Resource Provisioning in a virtual computing environment using intention-based security policies" submitted on August 21, 2020. This application claims the benefit of and priority under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 63 / 068,945, the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0003] background Generally, the use of cloud-based applications (e.g., enterprise public cloud applications, third-party cloud applications, etc.) is pervasive, with access coming from a variety of devices (e.g., desktop and mobile devices) and a variety of users (e.g., employees, partners, customers, etc.). For businesses and enterprises making the transition to the cloud, it is essential that cloud service providers be able to offer robust security solutions to their users. Cloud-based security services offer security solutions that enable businesses and enterprises to take advantage of the many benefits of cloud computing while remaining safe and ensuring that data privacy and compliance requirements are met. With the rich variety and accessibility of cloud-based services and cloud-based applications, the amount of cloud resources that need to be securely managed by cloud providers continues to grow rapidly. Existing cloud-based security services for securely configuring and managing resources in the cloud need to be improved to provide more robust, secure, and reliable access to resources in the cloud. Summary of the Invention [Means for solving the problem]

[0004] overview The present disclosure relates generally to cloud-based security solutions. More specifically, but not by way of limitation, the present disclosure describes a cloud-based security solution that provides a robust and secure framework for managing and enforcing security policies associated with various resources managed in the cloud.

[0005] In one embodiment, a security zone policy enforcement system in a cloud service provider infrastructure is disclosed. The security zone policy enforcement system receives a request to perform an operation on a resource, determines a compartment associated with the resource, determines that the compartment is associated with a security zone, and enforces one or more security zone policies applicable to the resource. The system then determines that the operation on the resource is permitted based on the set of one or more security zone policies, and enables the operation to be performed on the resource in response to determining that the operation on the resource is permitted.

[0006] In some examples, the system determines a compartment identifier for a compartment associated with the resource and a set of one or more compartment policies applicable to the resource, where the set of one or more compartment policies applicable to the resource comprises a union of one or more compartment policies associated with the compartment and one or more compartment policies associated with one or more parent compartments hierarchically related to the compartment.

[0007] In some examples, the system determines that an action is permitted on a resource based on the set of one or more compartment policies, and in response to determining that an action is permitted on the resource based on the set of one or more compartment policies, determines that the compartment is associated with a security zone.

[0008] In some examples, the system includes determining that an operation is not allowed on the resource based on a set of one or more compartment policies, and in response to so determining, disallowing performance of the operation on the resource. In some examples, the system includes determining that an operation is not allowed on the resource based on a set of security zone policies, and in response to so determining, disallowing performance of the operation on the resource.

[0009] In some examples, the set of one or more security zone policies applicable to a resource includes a union of one or more security zone policies associated with the security zone and one or more security zone policies associated with one or more parent security zones hierarchically related to the security zone.

[0010] In some examples, a security zone policy in a set of one or more security zone policies is expressed as a set of one or more expressions. Each expression in the set of expressions includes a set of one or more conditions, and each condition in the set of one or more conditions specifies a restriction on operations to be performed on a resource. In some examples, the restriction specifies criteria that require encryption of the resource, restrict movement of the resource from the compartment in which it resides, or prohibit the resource from being accessible from the public internet. In some examples, the restriction specifies criteria related to one or more secondary resources associated with the resource, the one or more secondary resources affecting the operation of the resource. In some examples, the set of one or more security zone policies prohibits a particular configuration of operations from being performed on a resource.

[0011] In some examples, the system sends a result to the user indicating that the operation was successfully performed on the resource. In some examples, the result indicates that the operation was not successfully performed on the resource.

[0012] In a particular example, a system receives a request to associate a compartment with a security zone. The compartment is associated with a set of one or more compartment policies. In response to the request, the system associates the compartment with a security zone. The security zone is associated with a set of one or more security zone policies. As a result of the association, the compartment is associated with a set of one or more security zone policies and a set of one or more compartment policies. In some examples, the system receives a request to add a resource to a compartment and, in response to the request, determines access to the resource based at least in part on a set of one or more compartment policies and a set of one or more security zone policies. In some examples, the set of one or more security zone policies prohibits a set of operations from being performed on the resource or prohibits a particular version of an operation from being performed on the resource.

[0013] In one embodiment, a centralized application programming interface (API) request processing system in a cloud service provider infrastructure (CSPI) is disclosed. The API request processing system receives an API request identifying an operation to be performed on a resource in the CSPI. The system determines compartment information and context information associated with the resource from the API request. In response to determining the compartment information and context information associated with the resource, the system determines that the resource resides in a compartment associated with a security zone. The system then processes the API request and sends a processing result of the API request to a user of the centralized API processing system.

[0014] In some examples, the system determines a primary resource from the API request. In some examples, the primary resource is a resource identified in the API request. The system determines a secondary resource affected by the API request. The secondary resource is a resource associated with the primary resource. In some examples, the secondary resource is not identified as part of the API request.

[0015] In some examples, the compartment information includes a compartment identifier and a set of one or more compartment policies associated with a primary resource identified in the API request. In some examples, the context information is associated with a secondary resource affected by the API request. The context information may include a resource identifier associated with the secondary resource, a compartment identifier associated with the secondary resource, or a resource state associated with the secondary resource. In some examples, the context information identifies a downstream service in the CSPI that is configured to execute the API request.

[0016] In some examples, the system determines that the operation is permitted to be performed on the resource identified in the API request based on compartment information and context information associated with the resource, and in response to the determination, determines that the resource resides in a compartment associated with the security zone. In some examples, processing the API request by the centralized API processing system includes sending the API request and compartment information associated with the resource to a security zone policy enforcement system for processing. The processing further includes the centralized API processing system receiving a result of processing the API request from the security zone policy enforcement system. In some examples, the result indicates that the operation is permitted to be performed on the resource. In some examples, the result indicates that the operation is not permitted to be performed on the resource. In particular examples, the centralized API processing system sends the result to a user. In some examples, processing the API request includes the security zone policy enforcement system evaluating a set of one or more security zone policies associated with the security zone of the compartment.

[0017] In some examples, the system determines that the user is authorized to perform an action on a resource identified in the API request before determining compartment information and context information associated with the resource. The compartment and context information associated with the API request is stored in a security zone specification associated with the API request.

[0018] Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media that store programs, code, or instructions executable by one or more processors, etc. These exemplary embodiments are mentioned not to limit or define the disclosure, but to provide examples to aid in understanding thereof. Additional embodiments are discussed in the "Detailed Description," where further description is provided.

[0019] The features, embodiments, and advantages of the present disclosure will be better understood by reading the following Detailed Description in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 illustrates a high-level view of a computing environment with a Cloud Service Provider Infrastructure (CSPI) including capabilities for providing a secure framework for managing and enforcing security policies associated with various resources managed by the CSPI, according to one embodiment. [Figure 2] 2 is an exemplary diagram of a computing environment 200 comprising a secure framework provided by the security zone policy management system 116 shown in FIG. 1, according to an embodiment. [Figure 3] 3 illustrates an example of a process 300 performed by the security zone policy management subsystem 116 in the CSPI shown in FIG. 1 according to one embodiment. [Figure 4] 4 illustrates an example of a process 400 performed by a security zone policy validation subsystem within the CSPI shown in FIG. 1 according to one embodiment. [Figure 5A] 2 is an exemplary illustration of compartment policy inheritance by compartments created by users of a tenant of the CSPI shown in FIG. 1, according to an embodiment. [Figure 5B] 2 is an exemplary illustration of inheritance of security zone policies associated with security zones by compartments created by tenants of the CSPI shown in FIG. 1 , according to an embodiment. [Figure 6]FIG. 6 illustrates a high-level view of a computing environment 600 comprising a Cloud Service Provider Infrastructure (CSPI) 110 that includes a centralized API request processing system and a security zone policy enforcement system to provide a secure framework for enabling secure access to various resources managed by the CSPI, according to one embodiment. [Figure 7] 7 illustrates an example process 700 performed by a centralized API request processing system to provide users with secure access to various resources managed by the CSPI, according to one embodiment. [Figure 8] 8 illustrates an example process 800 of processing performed by the security zone policy enforcement system 112 to determine whether an operation is allowed to be performed on a resource based on evaluating a set of security zone policies associated with the resource, according to an embodiment. [Figure 9] FIG. 7 is a sequence diagram illustrating interactions between the centralized API request processing system shown in FIG. 6 and one or more other systems to provide user secure access to various resources managed by the CSPI, according to one embodiment. [Figure 10] 7 is an example of a secure zone specification corresponding to an API request identifying an operation for invoking a compute instance resource using a compute service in the CSPI shown in FIG. 6, according to an embodiment. [Figure 11] 1 is an example of a Secure Zone specification corresponding to API requests identifying operations for attaching a volume to an instance, attaching a boot volume to an instance, and changing a compartment identifier for an instance using compute services in CSPI, according to an embodiment. [Figure 12]1 is an example of a security zone specification corresponding to an API request identifying operations to create a subnet, create an Internet gateway, change a compartment identifier for a subnet, and change a compartment identifier for an Internet gateway using compute services in CSPI, according to an embodiment. [Figure 13] 13 is a block diagram 1300 illustrating an example pattern of an IaaS architecture, according to at least one embodiment. [Figure 14] 14 is a block diagram 1400 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. [Figure 15] 15 is a block diagram 1500 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. [Figure 16] 16 is a block diagram 1600 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. [Figure 17] 17 illustrates an exemplary computer system 1700 upon which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0021] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. It will be apparent, however, that various embodiments may be practiced without these specific details. The figures and description are not intended to be limiting. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0022] The present disclosure relates generally to cloud-based security solutions. More specifically, but not by way of limitation, the present disclosure describes a cloud-based security solution that provides a robust and secure framework for managing and enforcing security policies associated with various resources managed in the cloud.

[0023] As more and more enterprises move their data centers and applications to the cloud every day, cloud data security is becoming increasingly important. Cloud-based security solutions ensure that high-quality cloud data security is achieved for their users through comprehensive data security policies. For example, identity and access management (IAM) is a common type of security solution provided in the cloud. IAM technology ensures cloud data security by managing user identities and thereby defining policies that may regulate users' access to resources in the cloud. IAM policies may be configured to limit a user's ability to access resources that the user does not have the right to access and / or define user roles that limit a user's ability to perform certain actions / operations in the cloud.

[0024] Existing cloud-based security solutions are limited in their ability to provide users with a robust and secure framework for configuring, accessing, and managing resources in the cloud (e.g., networks, servers, storage, applications, and services). For example, cloud-based security solutions that employ IAM policies are generally user / group specific and tied to the identity of the user requesting access. For example, enterprise or cloud-based security solutions often have limited ability to provide users with a robust and secure framework for configuring, accessing, and managing resources in the cloud (e.g., networks, servers, storage, applications, and services). A cloud provider's administrator may customize access privileges for a specific set of users (e.g., users belonging to a specific department within an enterprise), so that a specific group of users may always be given access to specific resources based on their role / identity within the enterprise. This may jeopardize the overall security needs of the enterprise, especially if the enterprise is required to ensure that access is tightly regulated to provide robust data security controls for the enterprise. Furthermore, the use of IAM technology requires the enterprise or cloud administrator to maintain updated and synchronized information for all of its users. This involves managing sensitive identity information and raises privacy concerns for the enterprise.

[0025] The cloud-based security solution described in this disclosure offers several technological advances and / or improvements over traditional cloud-based security services. The cloud-based security solution provides a robust and secure framework for managing and enforcing security policies associated with various resources managed by a cloud service provider (CSP). The disclosed secure framework comprises a set of security zones and security zone policies that can be enforced on a set of resources in the cloud accessed by users of an enterprise. Access to the set of resources is governed by the set of security zone policies and is not tied to the identity of the user accessing the resource. Thus, a user who may be permitted by an IAM policy to access (and / or perform an action on) a resource can be denied access by the disclosed security solution if they violate the set of security zone policies associated with that resource. The security zone policies are based on "deny semantics" that aim to disallow certain actions or behaviors from being performed on a set of resources by any user of an enterprise. This contrasts with the traditional "allow semantics" employed by existing IAM authorization policies, which allow certain users to perform certain actions on resources based on the user's role / identity within the enterprise.

[0026] In some examples, the disclosed cloud-based security solution is realized by a security zone policy enforcement system within a Cloud Service Provider Infrastructure (CSPI) that is made available on-demand (e.g., via a subscription model) by the CSPI to users or customers using systems and infrastructure (cloud infrastructure) provided by the CSP. The disclosed security zone policy enforcement system provides enterprise users with a robust and secure framework for securely configuring, accessing, and managing their resources in the cloud. The resources may include, but are not limited to, compute, networking, object storage, or database resources hosted in a distributed environment by the CSPI. Details regarding the implementation and processing performed by the security zone policy enforcement system are described in the following figures and their accompanying descriptions.

[0027] Security Zone Policy Enforcement System in Cloud Service Provider Infrastructure (CSPI) Referring now to the drawings, Figure 1 illustrates a high-level view of a computing environment 100 with a Cloud Service Provider Infrastructure (CSPI) including capabilities for providing a secure framework for managing and enforcing security policies associated with various resources managed by the CSPI 110, according to one embodiment. In one embodiment, the secure framework is provided by a security zone policy enforcement system 112 within the CSPI 110. The resources managed by the CSPI are managed by a CSPI policy enforcement system 112. The resources may include, but are not limited to, compute resources, networking resources, object storage resources, or database resources hosted in a distributed environment by the SPI 110. Users 102 of the CSPI 110 may use these resources to build their own networks. For example, users may use resources provided by the CSPI 110 to build one or more customizable and private networks called virtual cloud networks (VCNs) (also referred to herein as "virtual customer networks"). Users may deploy one or more resources, such as compute instances, on these VCNs. The compute instances may take the form of virtual machines, bare metal instances, etc.

[0028] The security zone policy enforcement system 112 may be realized by one or more computing systems that execute computer-readable instructions (e.g., code, programs) to implement the security zone policy enforcement system 112. As shown in FIG. 1 , the security zone policy enforcement system 112 includes various subsystems, including a security zone policy management subsystem 116 and a security zone policy validation subsystem 118. Portions of data or information used or generated by the security zone policy enforcement system 112 as part of its processing may include security zone information 120, which may be stored by the security zone policy enforcement system 112 in one or more databases or files. The systems and subsystems shown in FIG. 1 may be realized using software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the computing system, hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device).

[0029] The security zone policy enforcement system 112 may be implemented in a variety of different configurations. In the embodiment shown in FIG. 1, the security zone policy enforcement system 112 is implemented on one or more servers within the CSPI 110, and its secure resource access and management services may be provided to cloud service subscribers on a subscription basis. The computing environment 100 shown in FIG. 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. For example, in some implementations, the security zone policy enforcement system 112 may be implemented using more or fewer subsystems than those shown in FIG. 1, may combine two or more subsystems, or may have a different configuration or arrangement of subsystems.

[0030] In the embodiment shown in FIG. 1 , security zone policy enforcement system 112 comprises security zone policy management system 116 and security zone policy verification subsystem 118. Security zone policy management system 116 includes capabilities for providing a secure framework for managing security policies associated with various resources (e.g., compute resources, networking resources, object storage resources, or database resources) within CSPI. In some examples, the secure framework provided by security zone policy management system 116 includes security zone information 120, which may consist of a set of security zones and a set of security zone policies associated with the set of security zones. A “security zone” may refer to a specialized zone within the secure framework managed by security zone policy management subsystem 116 that is designed to enforce implicit and explicit security zone policies on a set of resources that reside within a compartment within CSPI 100. A security zone policy prevents certain actions that violate security requirements defined by a security zone from being performed on a set of resources that reside within a compartment. Prevent. A "compartment" may refer to a logical container used to organize and control access to resources managed by CSPI 110. A compartment may be associated with a set of compartment policies that restrict the use of resources residing within the compartment. Each policy in the set of compartment policies may affect one or more resources, such as compute resources, networking resources, object storage resources, and database resources, within the CSPI. Resources within a compartment may be logically organized according to various criteria. For example, resources within a compartment may be logically organized based on particular services provided by the CSPI (e.g., compute services, memory services, and networking services), based on departments within the user's enterprise (e.g., engineering, human resources, IT, etc.), etc. The criteria may be specified by a user (e.g., administrator) 102 associated with a customer / tenant (e.g., 120, 122, or 124) of CSPI 110. An example of a secure framework including security zones and security zone policies implemented by security zone policy management system 116 is described in detail in FIG. 2.

[0031] In particular embodiments, the security zone policy management system 116 includes the ability to associate compartments with security zones, add resources to compartments associated with security zones, view security zone policies associated with security zones, designate security zones as “maximum security zones,” etc. A “maximum security zone” may represent a security zone configured to include all available security zone policies defined by the security zone policy enforcement system. Compartments associated with a security zone automatically inherit the set of security zone policies associated with that security zone. In some examples, security zone policies represent an additional layer of security policy that may be enforced against a set of resources residing in a compartment, in addition to the compartment policies associated with the compartment. A security zone policy may prohibit an entire set of operations from being performed on a set of resources residing in the compartment, may prohibit a subset of operations from being performed on a set of resources, or may prohibit a particular version / configuration of an operation from being performed on a set of resources. As an example, a user may have permission to create a resource (e.g., a compute instance) in a compartment with a public Internet Protocol (IP) address based on the compartment policy associated with that compartment, but may not be allowed to create that resource with a public IP address based on the security zone policy associated with that compartment. Additional details of the implementation of security zone policies by the security zone policy management system 116 are described in FIG. 2.

[0032] Security zone policy validation subsystem 118 includes the capability to evaluate whether an operation can be performed on a resource that resides within a compartment associated with a security zone. Based on the evaluation, security zone policy validation subsystem 118 may grant or deny a user of CSPI 110 the ability to perform an operation on the resource. For example, security zone policy validation subsystem 118 may prohibit a user from attempting to access a resource from the public Internet, ensure that resources created by a user are encrypted using a customer-managed key, etc.

[0033] In a particular example, a user 102 of the CSPI 110 may communicate with a computing device communicatively coupled to the CSPI 110, possibly via one or more communication networks. A user 102 may interact with the security zone policy enforcement system 112 using a computing device 104. The computing device may be of various types, including but not limited to, a mobile phone, a tablet, a desktop computer, etc. A user 102 may be associated with a customer or tenant (e.g., 120, 122, or 124) of the CSPI 110 who wishes to utilize services provided by the security zone policy enforcement system 112 to securely manage and access resources within the CSPI. A user may use a console user interface (UI) connected to the user's computing device (e.g., 104) to interact with the security zone policy enforcement system 112 via an application programming interface (API) or via a command line interface (CLI) 106 to securely manage and access resources deployed within the CSPI 110. For example, the console UI may be a web-based user interface (UI) (or web-based application) provided by the security zone policy enforcement system 112, allowing the user to interact with the security zone policy enforcement system 112 to securely access and manage the user's resources within the CSPI. As an example, a user may interact with the security zone policy enforcement system 112 to create a compartment, associate a compartment with a security zone, add resources to a compartment, view security zone policies associated with a security zone, delete a compartment, create a subcompartment within a compartment, move a compartment to a different parent compartment within the same tenancy, designate a security zone as a "maximum security zone," etc.

[0034] In some examples, the security zone policy enforcement system 112 may be configured to receive a request from a user to perform an operation on a resource. For example, a user may send a request via a UI connected to the user's device to create or start a virtual machine instance in the user's VCN. The security zone policy enforcement system 112 may process the request and send a result of the processing to the user. The result may include information that the operation was successfully performed on the resource, a message that the operation could not be performed due to a policy violation, and possibly other information included in the result. The result may be output to the user, for example, via a UI connected to the user's device 104.

[0035] FIG. 2 is an exemplary diagram of a computing environment 200 including a secure framework provided by the security zone policy management system 116 shown in FIG. 1 , according to an embodiment. In some examples, the secure framework includes security zone information 120, which consists of a set of security zones 202, 204, and 206 and a set of security zone policies 208, 210, and 212 associated with the set of security zones. As previously mentioned, a “security zone” may refer to a specialized zone designed to enforce implicit and explicit security zone policies that prevent operations that violate security requirements defined by the security zone from being performed on a set of resources residing within the compartment. In some implementations, a security zone policy (e.g., 208, 210, or 212) associated with a security zone (e.g., 202, 204, or 206) may be expressed as a set of one or more expressions, each including a set of one or more conditions. Each expression may evaluate to true or false, performing a logical “and” on the conditions it contains. In some examples, each condition may specify restrictions on certain actions that may be performed on resources within CSPI. A security zone policy performs a logical "or" on all expressions it contains, so if any expression is true, the security zone policy returns a true value. A true evaluation for a security zone policy indicates a violation, which means that the user's action / requested action is not permitted on the resource. This will result in preventing the

[0036] As an example, a security zone policy that requires object storage resources (e.g., object storage buckets) within a security zone to be encrypted may be expressed as shown below: Security Zone Policy(Object Storage Resource) = expr1(context.part1) | expr2(context.part2), where: expr1(context.part1) = condition 1(Bucket.Encryption.Type = Symmetric) & condition 2(Bucket.Encryption.Key.Size < 512), and expr2 (context.part2) = condition 1(Bucket.Encryption.Key.Type = customer-managed).

[0037] In the above example, the first expression expr1(context.part1) expressed by the security zone policy is the first condition, condition 1(Bucket.Encryption.Type = Symmetric), and the second condition, condition 2(Bucket.Encryption.Type = Symmetric). The first condition is condition 2 (Bucket.Encryption.Key.Size < 512). restricts a user's ability to create object storage resources (buckets) using encryption types that are not symmetric. A second condition restricts a user's ability to create object storage resources with keys smaller than 512 bytes. The second expression, expr2 (context.part2), expressed by the security zone policy, contains one condition that enforces the requirement that object storage resources should be created using a customer-managed master encryption key, as opposed to a default encryption key managed by the object storage service.

[0038] Each expression expr1(context.part1) and expr2(context.part2) is used for the conditions they contain. For example, the first expression expr1(context.part1) denies the user the ability to create object storage resources using symmetric encryption with a key size of less than 512 bits. The second expression expr2(context.part2) denies the user the ability to create object storage resources with a default encryption key. The security zone policy for an object storage resource performs a logical "OR" on all expressions, so if any expression is true, the policy returns a value of true. A true evaluation for a security zone policy indicates a violation, which results in blocking the user's action; i.e., it prevents the user from creating an object storage resource using symmetric encryption with a key size less than a 512-bit key or from creating an object storage resource using the default encryption key.

[0039] In an alternative implementation, based on the structure of the resource's metadata, the expression for the security zone policy for an object storage resource may be expressed using wildcard characters as shown below: Expr 1: *.Encryption.Type = Symmetric && *.Encryption.Key.Size < 512 In yet another implementation, the expression for the security zone policy for a resource (e.g., an object storage resource) may be expressed as shown below: Expr 1: Encryption.Type = Symmetric && Encryption.Key.Size < 512 In one example, a security zone policy (e.g., 208, 210, or 212) may belong to a particular security zone policy category. Each security zone policy category includes policies that prohibit a set of actions from being performed on a set of resources. Different security zone policy categories may include, for example, an access restriction security zone policy category, a data security / data encryption security zone policy category, a resource association restriction security zone policy category, a resource movement restriction security zone policy category, or a data durability security zone policy category. It may also include security zone policy categories. Various security zone policy categories are described below.

[0040] Access Restriction Security Zone Policy Examples of policies in this category include policies that prohibit resources created in a security zone from being accessible from the public internet. For example, policies in this category ensure that subnets within a security zone cannot be made public, that an internet gateway cannot be added to a virtual cloud network (VCN) within a security zone, that object storage buckets created within a security zone cannot be made public, that databases within a security zone cannot be assigned to a public subnet, etc.

[0041] Data Security / Data Encryption Security Zone Policy Examples of policies in this category include policies that require resources within a security zone to be encrypted using customer-managed keys and policies that require data to be encrypted in motion and at rest. For example, a policy in this category ensures that resources such as block volumes, boot volumes, object storage buckets, and databases created in a security zone use a customer-managed master encryption key as opposed to a default encryption key managed by the service. Furthermore, a policy in this category ensures that block volumes, boot volumes, object storage buckets, and databases created in a security zone are encrypted using a key with a specific number of bits.

[0042] Resource Association Restrictions Security Zone Policy Examples of policies in this category include policies that require that components (e.g., secondary resources) of a resource (e.g., a primary resource) that affect the security posture of the primary resource must also be placed in a security zone. For example, policies in this category ensure that all block storage volumes / boot volumes attached to compute instances in a security zone must themselves be within the security zone, that compute instances not within a security zone cannot be attached to block storage volumes / boot volumes that are within a security zone, that block volumes / boot volumes cannot be moved into a security zone if they are attached to a compute instance not within a security zone, that compute instances within a security zone must use subnets that are also within the security zone, that databases within a security zone must use subnets that are also within the security zone, etc.

[0043] Resource movement restriction security zone policy Examples of policies in this category include policies that ensure data integrity by not allowing the movement of certain resources from a security zone to a standard compartment because they may be less secure, not allowing the movement of existing resources from a standard compartment to a security zone unless all security zone policies are met, etc. For example, a policy in this category may ensure that block volumes / boot volumes, compute instances, subnets, buckets, or databases cannot be moved from a security zone to a standard compartment.

[0044] Data Durability Security Zone Policy Examples of policies in this category are resources created in security zones. Includes policies that ensure automatic backups must be performed periodically for databases in a security zone. For example, policies in this category ensure that a database backup in a security zone cannot be used to create a database that is not in the security zone, that a database in a security zone cannot be cloned to create a database that is not in the security zone, etc.

[0045] Returning to the description of Figure 2, as previously mentioned, security zone policy management system 116 may be configured with capabilities to manage a secure framework including security zone information 120, which consists of a set of security zones (202, 204, and 206) and their associated security zone policies (208, 210, and 212). Security zone policy management system 116 may further include capabilities for associating compartments with security zones, adding resources to compartments, viewing security zone policies associated with security zones, deleting compartments, creating subcompartments within compartments, moving compartments to different parent compartments within the same tenancy, designating security zones as maximum security zones, etc. For example, in the embodiment shown in Figure 2, compartment A1 216 may be created by a user of first tenant A121 of CSPI 110 and is associated with a set of compartment policies 218. Similarly, compartment B1 220 may be created by a user of second tenant B122 and is associated with a set of compartment policies. Further, in this embodiment, compartment A1 216 and compartment B1 220 are both associated with security zone-1 202.

[0046] As described above, creation of a compartment and association of the compartment with a security zone may be performed by a user of a customer or tenant of CSPI 110 by sending a request to security zone policy management subsystem 116 via a console UI connected to the user's computing device, via an API, or via CLI 106. Upon receiving the user's request, security zone policy management subsystem 116 creates the compartment and associates the compartment with a security zone. When a compartment (216 or 220) is associated with a security zone (e.g., security zone-1 202), the compartment automatically inherits the set of security zone policies (e.g., 208) associated with the security zone. In one embodiment, a compartment associated with a security zone may be referred to herein as a “security zone compartment.” A user may then add resources to the security zone compartment. Any resource added to a security zone compartment is automatically associated with (i.e., automatically inherits) the security zone policies associated with the security zone in addition to the set of compartment policies associated with the compartment.

[0047] In the embodiment shown in FIG. 2, compartment A1 216 of tenant A 121 and compartment B1 of tenant B 122 are both associated with the same security zone-1 202. In some implementations, compartment A1 216 of tenant A 121 and compartment B1 220 of tenant B 122 may be associated with different security zones. For example, compartment A1 216 may be associated with security zone-1 202, and compartment B1 220 may be associated with a different security zone-2 204. Additionally, the secure framework including security zone information 120 shown in FIG. 2 is shown as a generic framework accessible to and shared by various tenants of CSPI 110. In alternative embodiments, security zone information 120 may be tenant-specific or may be shared by multiple tenants. 2 may be defined per tenant or per tenant. The secure framework illustrated in FIG. 2 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. Other implementations are possible, such as multiple compartments associated with a tenant, multiple compartments associated with the same / different security zones, a compartment associated with multiple security zones, etc. In some implementations, security zone information 120, including security zones and security zone policies, may be defined by either an administrator of CSPI 110 or a user of a tenant of CSPI 110.

[0048] 2 may be hierarchically related to one another. For example, in one example, security zone-1 202 and security zone-2 204 may be hierarchically related, with security zone-1 202 being the parent security zone of child security zone-2 204. In this example, when compartment A1 216 is associated with security zone-2 204, it is automatically associated with security zone-1 202 and therefore inherits the security zone policy 210 associated with security zone-2 204. Continuing with this example, in one implementation, if the set of security zone policies 208 associated with security zone-1 202 belongs to the "Access Restrictions" category and the set of security zone policies 210 associated with security zone-2 204 belongs to the "Data Encryption" category, when resource R1 or R2 is added to compartment A1 216, the resource is automatically associated with both the "Data Encryption" security zone policy and the "Access Restrictions" security zone policy, in addition to the compartment policy associated with compartment A1 216 in which the resource resides. The association of resources within a compartment with one or more security zones and their associated security zone policies prohibits users from performing certain actions on resources residing within the compartment if the certain actions violate the security requirements defined by the security zone policies.

[0049] In some examples, the security requirements defined by a security zone policy may prohibit an entire set of actions that may be performed on resources residing in the compartment, may prohibit a subset of actions that may be performed on resources, or may prohibit a particular version / configuration of an action that may be performed on resources. For example, a set of actions (O1...On) may be specified in an IAM policy associated with resource R1. Based on the operations O1, O2, O5, and O6 policies associated with a compartment, the set of operations that may be permitted to be performed on resource R1 may be reduced to the subset of operations (O1, O2, O5) permitted by the compartment policy associated with that compartment. Thus, a compartment policy associated with a compartment may represent a first filter on the set of operations that may be permitted to be performed on resources that reside in that compartment.

[0050] When compartment A1 216 is associated with a security zone (e.g., security zone-1 202), it further inherits the security zone policy of that security zone and the security zone policies associated with any security zones hierarchically related to that security zone. Based on the example above, the set of actions that may be permitted to be performed on R1 may now be further reduced to an even smaller subset of actions (e.g., O1) based on the security zone policies. Thus, the security zone policies may be applied to compartments A1 216, R1 216, and O1 216. A security zone may represent a second or additional filter on the set of actions that may be permitted to be performed on resources residing within the compartment. An exemplary diagram of the association of security zones and their associated security policies to compartments is shown in Figure 5B.

[0051] In some examples, a security zone policy may prohibit certain configurations of operations (e.g., O1) that may be performed on resources residing in the compartment. As an example, a compartment policy for R1 residing in compartment A1 216 may allow a user to create resource R1 such that it is publicly accessible from the public network (i.e., the Internet), i.e., R1 may be created using a public Internet Protocol (IP) address. When compartment A1 216 is associated with security zone-1 202, security zone policy 208 associated with security zone-1 202 may prohibit a user from being able to create R1 using a public IP address. As another example, if a resource references / is attached to a public subnet resource, the security zone policy may not allow a user to create / launch a “virtual machine” resource instance because the subnet resource may be associated with a security zone policy that prohibits a user from launching a “virtual machine” instance from a subnet resource that uses a public IP address.

[0052] In some implementations, a compartment (e.g., compartment A1 216) may also be hierarchically related to other compartments created within a tenancy. For example, in the embodiment shown in FIG. 2, compartment A1 216 may be hierarchically related (i.e., may be a child compartment) to one or more compartments (i.e., parent compartments) created within the tenancy. When a resource (e.g., R1) is added to compartment A1 216, the resource automatically inherits the compartment policies associated with that compartment in addition to the compartment policies of one or more parent compartments associated with that compartment. An exemplary diagram of compartment policy inheritance for a compartment is shown in FIG. 5A.

[0053] FIG. 3 illustrates an example of a process 300 performed by the security zone policy management subsystem 116 in the CSPI shown in FIG. 1 , according to one embodiment. The process illustrated in FIG. 3 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective system, hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device). The process 300 presented in FIG. 3 and described below is intended to be exemplary and non-limiting. While FIG. 3 illustrates various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the steps may be performed in some different order, or some steps may be performed in parallel.

[0054] 3 begins at block 302 when the security zone policy management subsystem 116 receives a request to associate a compartment with a security zone. A compartment may be associated with a set of compartment policies and may contain zero or more resources. At block 304, the security zone policy management subsystem 116 associates the compartment with the security zone. As a result of the association, the compartment is associated with a set of security zone policies and a set of compartment policies that are associated with the security zone. You will be able to do this.

[0055] In block 306, the security zone policy management subsystem 116 determines access to existing resources (if any) in the compartment based on the compartment policy and the security zone policy. In some examples, in block 308, the security zone policy management subsystem 116 may receive a request to add a new resource to the compartment. In block 310, the security zone policy management subsystem 116 determines access to the new resource based on the compartment policy and the security zone policy.

[0056] FIG. 4 illustrates an example of a process 400 performed by the security zone policy validation subsystem in the CSPI shown in FIG. 1 , according to one embodiment. The process illustrated in FIG. 4 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective system, hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device). The process 400 presented in FIG. 4 and described below is intended to be exemplary and non-limiting. While FIG. 4 illustrates various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the steps may be performed in some different order, or some steps may be performed in parallel.

[0057] The process shown in FIG. 4 begins in block 402 when the security zone policy validation subsystem 118 receives a request to perform an operation on a resource. For example, the request may identify an operation (e.g., a “launch instance” operation) to be performed on an “instance” (i.e., a virtual machine instance) to create a virtual machine instance in a user's tenancy using a public IP address. In block 404, the security zone policy validation subsystem 118 determines a compartment associated with the resource. In block 406, the security zone policy validation subsystem 118 determines a set of compartment policies applicable to the resource based on the compartment identified in block 404. The compartment policies applicable to the resource may include the compartment policy associated with the compartment in addition to the compartment policies of one or more parent compartments hierarchically related to the compartment. In block 408, the security zone policy validation subsystem 118 determines whether the operation on the resource is permitted based on the compartment policies determined in block 406. For example, a compartment policy applicable to a resource may allow a user to create a virtual machine instance such that it is publicly accessible from a public network (i.e., the Internet), i.e., may allow the virtual machine instance to be created with a public IP address.

[0058] If the operation cannot be performed on the resource based on the compartment policy determined in block 406, then in block 410, the security zone policy validation subsystem 118 does not allow the operation to be performed on the resource. If the operation can be performed on the resource based on the compartment policy determined in block 406, then in block 412, the security zone policy validation subsystem 118 determines whether the compartment determined in block 404 is associated with a security zone. If the compartment is not associated with a security zone, then in block 414, the security zone policy validation subsystem 118 allows the operation to be performed on the resource. If the compartment is associated with a security zone, then in block 416, the security zone policy validation subsystem 118 determines the security zone associated with the compartment. In block 418, the security zone policy validation subsystem 118 determines a set of security zone policies applicable to the resource based on the security zone determined in block 416. The security zone policies applicable to the resource may include the security zone policies associated with the security zone in addition to the security zone policies of one or more parent security zones hierarchically associated with the security zone. In block 420, the security zone policy validation subsystem 118 determines whether an operation on the resource is allowed based on the security zone policies determined in 418. For example, the security zone policies applicable to the resource may not allow a virtual instance resource to be created using a public IP address.

[0059] If the operation on the resource is not permitted based on the security zone policy determined in 418, then in block 410, the security zone policy verification subsystem 118 does not permit the operation to be performed on the resource. If the operation on the resource is permitted based on the policy determined in 418, then in block 414, the security zone policy verification subsystem 118 permits the operation to be performed on the resource. In some examples, the processing performed in block 414 may include the security zone policy verification subsystem 118 sending the request to a downstream service in the CSPI for further processing of the request. As a result of the processing performed by the downstream service, the security zone policy verification subsystem 118 may send a result to the user indicating that the operation was successfully performed on the resource.

[0060] 5A is an exemplary diagram of compartment policy inheritance by compartments created by a user of the CSPI tenant shown in FIG. 1, according to an embodiment. In the example shown in FIG. 5A, compartment C1 502, compartment C2 504, and compartment C3 506 are hierarchically related to one another, with compartment C1 502 being the parent compartment of compartment C2 504, and compartment C2 504 being the parent compartment of compartment C3 506. Compartment C1 502 is associated with a set of compartment policies 508 that allow operation O1 to be performed on a set of resources that reside within the compartment. Compartment C2 504 is associated with a set of compartment policies 510 that allow operation O2 to be performed on a set of resources that reside within the compartment. Because compartment C2 504 is a child compartment of compartment C1 502, it automatically inherits the compartment policy 508 of compartment C1 502. Compartment C3 506 is associated with a set of compartment policies 512 that allow action O3 to be performed on the set of resources that reside within the compartment. Because compartment C3 506 is a child compartment of both compartment C2 504 and compartment C1 502, it automatically inherits the compartment policy 510 of compartment C2 504 and the compartment policy of compartment C1 502.

[0061] 5B is an exemplary diagram of inheritance of security zone policies associated with security zones by compartments created by tenants of the CSPI shown in FIG. 1, according to one embodiment. The example shown in FIG. 5B illustrates the inheritance of compartment C1 502, compartment C2 504, and compartment C3 506 shown in FIG. 5A with their associated compartment policies 508, 510, and 512. 1 also illustrates a security zone policy 516 associated with a compartment (e.g., compartment C3 506) that is associated with a security zone (security zone-1 514). In a particular example, when a compartment (e.g., compartment C3 506) is associated with security zone-1 514, the security zone policy 516 associated with security zone-1 514 applies to the compartment. Due to the association of compartment C3 506 with security zone policy 516, the set of operations (O1, O2, O3) originally permitted to be performed on resource R1 residing within the compartment is now reduced to a subset of operations (O1). Thus, the security zone policy represents an additional layer of security policy that may be enforced against the set of resources residing in the compartment, in addition to the compartment policy associated with the compartment. The security zone policy may prohibit an entire set of operations that may be performed on the set of resources residing in the compartment, may prohibit a subset of operations that may be performed on the set of resources, or may prohibit a particular configuration / version of the operations.

[0062] In some implementations, the security zone policy enforcement system described above in FIGS. 1-4, 5A, and 5B may cooperate with a centralized request processing system configured to provide a centralized point for providing secure resource access to users of the CSPI. The centralized request processing system may operate in conjunction with the security zone policy enforcement system to provide a centralized, robust, and secure framework for managing and enforcing security policies associated with various resources managed by the CSPI. In some examples, processing performed by the centralized request processing system may include evaluating compartment policies and security zone policies associated with one or more compartments in which the resources reside to determine whether a particular operation may be performed on the resource identified in the request. If processing results in a violation of a policy (i.e., a compartment policy or a security zone policy), the user is not authorized to perform the operation identified in the request, and the centralized request processing system transmits information to the user that the user is not authorized to perform the operation. In one embodiment, the centralized request processing system may be implemented by a centralized application programming interface (API) request processing system within the CSPI 110, as shown in FIG. 6 below. Details regarding the implementation and processing performed by the centralized application programming interface (API) request processing system are described below with reference to FIGS. 6-12 and their accompanying descriptions.

[0063] A centralized application programming interface (API) request processing system in a cloud service provider infrastructure (CSPI) 6 illustrates a high-level view of a computing environment 600 comprising a Cloud Service Provider Infrastructure (CSPI) 110 that includes a centralized API request processing system and a security zone policy enforcement system to provide a secure framework for enabling secure access to various resources managed by the CSPI, according to one embodiment. As previously described, the resources may include, but are not limited to, compute resources, networking resources, object storage resources, and database resources hosted in the distributed environment by the CSPI 110. Users 102 of tenants or customers of the CSPI 110 may use the resources provided by the CSPI 110 to build their own networks (e.g., VCNs 620) and deploy one or more resources 622A-622N, such as compute instances (e.g., virtual machines, bare metal instances), on the VCNs 620.

[0064] The CSPI infrastructure 110 executes computer-readable instructions (e.g., code, programs) to administer security associated with various resources managed by the CSPI. The CSPI 110 may be implemented by one or more computing systems to provide a secure framework for managing and enforcing security policies. As shown in FIG. 6 , the CSPI 110 includes various systems and subsystems, including a centralized API request processing system 604, an identity management system 606, a compartment identifier system 608, and a security zone policy enforcement system 112. Portions of data or information used or generated by the centralized API request processing system 604 as part of its processing may be stored in a persistent memory data store 610 and security zone information (e.g., 120 shown in FIG. 1 ) by the security zone policy enforcement system 112. The CSPI 110 further includes a set of one or more downstream services 618A-618N that may be communicatively coupled to the centralized API request processing system 604 via one or more communication networks. Users 102 of a customer of the CSPI 110 may utilize the downstream services to provision or deploy infrastructure resources in the customer's VCN 620. The systems and subsystems shown in FIG. 1 may be implemented using software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of a computing system, hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (eg, on a memory device).

[0065] The centralized API request processing system 604 may be implemented in a variety of different configurations. In the embodiment shown in FIG. 6, the centralized API request processing system 604 is implemented on one or more servers within CSPI 110, and the centralized secure resource access service may be provided to cloud service subscribers on a subscription basis. The computing environment 600 shown in FIG. 6 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Those skilled in the art will recognize many possible variations, alternatives, and modifications. For example, in some implementations, CSPI 110 may be implemented using more or fewer subsystems than those shown in FIG. 1, may combine two or more subsystems, or may have a different configuration or arrangement of the subsystems.

[0066] 6 , users 102 of CSPI 110 may interact with centralized API request processing system 604 using computing devices 104 communicatively coupled to CSPI 110, possibly via one or more communication networks. The computing devices may be of various types, including but not limited to, mobile phones, tablets, desktop computers, etc. Users 102 may represent customers or tenants of CSPI 110 who wish to utilize services provided by centralized API request processing system 604 and security zone policy enforcement system 112 to securely manage and access their resources within CSPI. For example, users 102 may use a console user interface (UI) connected to the user's computing device (e.g., 104) to interact with centralized API request processing system 604 via an application programming interface (API) or via a command line interface (CLI) 106 to securely manage and access the user's resources within CSPI 110. For example, the console UI may be a web-based user interface (UI) (or web-based application) provided by the centralized API request processing system 604 to allow a user to interact with the centralized API request processing system 604.

[0067] In an embodiment, a user may submit an API request 602 to a centralized API request processing system 604 via a console UI connected to the user's computing device 104, via an API, or via the CLI 106. The API request 602 may identify an operation to be performed on a resource managed by the CSPI 110. As an example, the API request may identify a “Launch Instance” operation to be performed on an “Instance” resource (e.g., a virtual machine instance) managed by the CSPI. Other example API requests may include, for example, a “Create Subnet” operation to create a “Subnet” resource, a “Create Block Storage Volume” operation to create a “Block Storage Volume” resource, etc. Upon receiving the request, the centralized API request processing system 604 performs processing to determine whether the operation can be safely performed on the resource identified in the API request without violating any policies (e.g., compartment policies and security zone policies) related to the resource identified in the request. Based on this processing, the centralized API request processing system 604 returns a result 624 to the requesting computing device 104. The result 624 may include information that the operation was successfully performed on the resource, a message that the operation could not be performed due to a policy violation, and possibly other information included in the result. The result 624 may be output to the user, for example, via a UI 106 connected to the user's device 104.

[0068] Portions of data or information used or generated by centralized API request processing system 602 as part of its processing may be stored in persistent memory data store 610. In some examples, the information stored in the persistent memory data store may include security zone specification 612, API-downstream service mapping information 614, and API specification 616. Security zone specification 612 may store information related to the resource identified in the API request, the downstream service identified to perform the operation identified on the resource in the API request, contextual information needed to evaluate the API request, etc. API-downstream service mapping information 614 may store information about how an API request maps to a downstream service within the CSPI, and API specification 616 includes information about the set of APIs utilized by the downstream service.

[0069] The security zone specification 612, the API-downstream service mapping information 614, and the API specification 616 may be used by the centralized API request processing system 602 as part of its processing to evaluate whether an operation on a resource identified in an API request is authorized to be performed by a user. In some examples, the information 612, 614, and 616 may be uploaded to the persistent memory data store 610 by a user (e.g., an administrator) of the centralized API request processing system 604 as part of the centralized secure resource access service provided by the centralized API request processing system 604 to users of the CSPI 110.

[0070] In some approaches, in addition to utilizing information 612, 614, or 616 stored in persistent memory data store 610, centralized API request processing system 602 may also interact with one or more systems, such as identity management system 606, compartment identifier system 608, and security zone policy enforcement system 112, to obtain information needed to evaluate whether the operation identified in the API request is authorized to be performed by the user. Further details of the processing performed by centralized API request processing system 604 and its interaction with the various systems 606, 608, and 112 to provide secure access to resources within CSPI 110 are described below with respect to the flowchart shown in FIG. 7 and its accompanying description.

[0071] 7 illustrates an example process 700 performed by a centralized API request processing system to provide users with secure access to various resources managed by the CSPI, according to one embodiment. The process illustrated in FIG. 7 may involve one or more processes in each system. The process 700 may be implemented in software (e.g., code, instructions, programs) executed by a processing unit (e.g., processor, core), hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device). The process 700 presented in FIG. 7 and described below is intended to be exemplary and non-limiting. While FIG. 7 depicts various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the steps may be performed in some different order, or some steps may be performed in parallel. In certain embodiments, such as the embodiment shown in FIG. 6, the processing shown in FIG. 7 may be performed by the centralized API request processing system 604.

[0072] 7, processing begins at block 702 when centralized API request processing system 604 receives an API request (e.g., 602) from a user. The API request may identify an operation to be performed on a resource managed by the CSPI. As an example, the API request may identify a "launch instance" operation to be performed on an "instance" resource (e.g., a virtual machine instance) to create / launch a virtual machine instance within the user's VCN 620 in CSPI 110.

[0073] At block 704, the centralized API request processing system 604 sends instructions (e.g., an API authorization request) to the identity management system 606 to determine whether the user is authorized to perform the API request received in block 702. The processing performed by the identity management system 704 may include authenticating the user (e.g., based on the user's username and password) and, upon successfully authenticating the user, determining whether the user is authorized to perform the operation identified in the API request. For example, the identity management system 704 may utilize system-defined IAM policies to determine whether the user is authorized to perform the operation identified in the API request.

[0074] At block 706 , the centralized API request processing system 604 receives a response from the identity management system 606 based on the processing performed by the identity management system 606 .

[0075] At block 708, the centralized API request processing system 604 determines whether the identity management system 606 has authorized the user to perform the operation identified in the API request. If the user is not authorized to perform the operation, at block 710, the centralized API request processing system 604 sends an error message to the user indicating the termination of processing of the API request.

[0076] If the identity management system 606 authorizes the user to perform the operation identified in the API request, at block 712, the centralized API request processing system 604 determines from the API request (a) a “primary resource,” which includes the resource named in the API request itself. At block 714, the centralized API request processing system 604 determines from the API request zero or more “secondary” or “related” resources, which include resources associated with the primary resource. Related resources may not be identified in the request itself, but may include resources affected by the API request. As an example, the primary resource in an API request performing a “launch instance” operation may represent a “compute” resource instance, and the related resources may be “boot volume,” “image,” or “subnet” resources used to launch the primary resource (i.e., the compute instance). In an alternative approach, both the primary and secondary resources may be included in the API request.

[0077] In some examples, the centralized API request processing system 604 may determine the secondary resources affected by the API request in block 714 from the API specification information 616 stored in the persistent memory data store 610. For example, from the API specification information 616, the centralized API request processing system 604 may obtain an API specification corresponding to the API request received in block 702. The API specification may identify the primary resource and the secondary resources affected by the API request, along with the operation to be performed on the primary resource. In another approach, the centralized API request processing system 604 may determine the primary resource and the related resources affected by the API request in block 712 based on accessing a security zone specification corresponding to the API request from the security zone specification 612 stored in the data store 610. Examples of security zone specifications corresponding to API requests are described in detail in FIGS. 10-12 below.

[0078] At block 716, the centralized API request processing system 604 determines compartment information for the primary resource determined at block 712. The compartment information may include a compartment identifier for the compartment in which the resource resides and compartment policies applicable to the resource. The compartment policies applicable to the resource may include the compartment policy associated with the compartment in addition to the compartment policies of one or more parent compartments hierarchically related to the compartment. In certain examples, the centralized API request processing system 604 may send an instruction to the compartment identifier system 608 to obtain the compartment information. In other examples, the centralized API request processing system 604 may obtain the compartment information from a security zone specification associated with the API request.

[0079] At block 718, the centralized API request processing system 604 determines context information related to the secondary resource determined at block 714. The context information may include compartment information associated with the secondary resource, a resource identifier associated with the secondary resource, a downstream service responsible for performing the API request, etc. For example, for an API request identifying a "launch instance" operation, the primary resource may be determined to be an "instance" resource, and the secondary resource may be determined to be a "boot volume" resource used to launch the primary resource. The context information may include a boot volume resource identifier and a downstream service (e.g., a block storage service) for performing the "launch instance" operation identified in the API request.

[0080] Various approaches may be utilized by the centralized API request processing system 604 to determine / obtain context information for the secondary resource. For example, in one approach, the centralized API request processing system 604 may utilize security zone specification information 612 stored in persistent memory data store 610 to determine context information applicable to the secondary resource. In another approach, the centralized API request processing system 604 may determine or obtain context information applicable to the resource directly from API-downstream service mapping information 614 or from downstream services responsible for fulfilling the API request.

[0081] At block 720, the centralized API request processing system 604 transmits the compartment information associated with the primary resource and the context information related to the secondary resource to the identity management system 606 for processing. The processing performed by the identity management system 606 may, for example, use the context information to determine the compartment associated with the compartment in which the primary resource resides. In block 722, the centralized API request processing system 604 receives an indication from the identity management system whether the operation identified in the API request is permitted to be performed on the resource.

[0082] At block 724, the centralized API request processing system 604 determines whether the operation is permitted to be performed on the resource. If the operation is not permitted, at block 710, the centralized API request processing system 604 sends an error message to the user indicating the termination of processing of the API request.

[0083] If the API request is allowed, processing continues to block 726, where the centralized API request processing system 604 determines whether the primary resource resides within a compartment associated with the security zone. Details regarding the association of compartments with security zones are explained in detail in FIG. 2 and its accompanying description. If the primary resource does not reside in a compartment associated with the security zone, processing continues to block 734, where the user is allowed to perform the API request.

[0084] If the primary resource is within a compartment associated with the security zone, then in block 728, the centralized API request processing system 604 calls the security zone policy enforcement system 112 to determine whether the operation is allowed to be performed on the resource.

[0085] At block 730, based on the processing performed by the security zone policy enforcement system 112, the centralized API request processing system 604 receives an indication from the security zone policy enforcement system 112 of whether the operation on the resource is permitted. For example, the security zone policy enforcement system 112 may determine that the operation on the resource is permitted based on evaluating the security zone policy associated with the security zone determined at block 726. Further details of the processing performed by the security zone policy enforcement system 112 to determine whether the operation on the resource is permitted are described in FIG. 8 and its accompanying description.

[0086] If it is determined in block 732 that the operation is not permitted, then in block 710 the centralized API request processing system 604 sends an error message to the user indicating the end of processing of the API request. If it is determined in block 732 that the operation is permitted, then in block 734 the centralized API request processing system 604 allows the API request to be executed.

[0087] FIG. 8 illustrates an example process 800 of processing performed by the security zone policy enforcement system 112 to determine whether an operation is allowed to be performed on a resource based on evaluating a set of security zone policies associated with the resource, according to an embodiment. The process illustrated in FIG. 8 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective system, hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device). The process 800 presented in FIG. 8 and described below is intended to be illustrative and non-limiting. While FIG. 8 illustrates various processing steps occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative embodiments, the steps may be performed in some different order, or some steps may be performed in parallel. In some embodiments, the process illustrated in FIG. 8 7 shows further details of the processing performed by the security zone policy enforcement system 112 in block 730 of FIG.

[0088] 8 begins in block 802 when the security zone policy enforcement system 112 receives an action to be performed on a resource and a compartment (i.e., a compartment ID) associated with the resource. In block 804, the security zone policy enforcement system 112 determines security zone policies applicable to the resource. The security zone policies applicable to the resource may include the security zone policies associated with the security zone in addition to the security zone policies of one or more parent security zones hierarchically associated with the security zone. For example, the security zone policy enforcement system 112 may obtain information about the security zone policies from security zone information (e.g., 120 shown in FIG. 1 ) managed by the security zone policy enforcement system 112.

[0089] In block 806, the security zone policy enforcement system 112 performs an evaluation to determine whether the operation is allowed on the resource based on the policy determined in block 804. If the operation is allowed, in block 808, the security zone policy enforcement system 112 sends an "operation is allowed" response to the centralized API request processing system. If the operation is not allowed, in block 810, the security zone policy enforcement system 112 sends an "operation is not allowed" response to the centralized API request processing system.

[0090] Figure 9 is a sequence diagram illustrating interactions between the centralized API request processing system shown in Figure 6 and one or more other systems to provide a user secure access to various resources managed by the CSPI, according to one embodiment. The process shown in Figure 9 begins when a user sends an API request 902 to the centralized API request processing system 604. As an example, the API request may identify an operation (e.g., "Launch Instance") to be performed on a "Virtual Machine" resource instance identified in the API request. Upon receiving the request, the centralized API request processing system 604 sends an authorization request (AuthZ request) 904 to the identity management system 606 to determine whether the user is authorized to perform the API request. At operation 906, the identity management system 606 returns a response (AuthZ response) to the centralized API request processing system 604 indicating whether the user is authorized to perform the API request.

[0091] If the user is authorized to perform the API request, at operation 908, the centralized API request processing system 604 sends an instruction to the compartment identifier system 608 to obtain / fetch compartment information for the primary resource identified in the API request. The "primary resource" may include the resource identified in the API request itself. For example, a "compute" resource instance may be determined to be the primary resource in an API request performing a "launch instance" operation. As mentioned above, the compartment information may include a compartment identifier and a compartment policy applicable to the resource. At operation 910, the centralized API request processing system 604 receives the compartment information from the compartment identifier system 608.

[0092] At operation 912, the centralized API request processing system 604 sends a request to a downstream service responsible for executing the API request to obtain context information related to a secondary resource affected by the API request. "Secondary" or "related" resources may include resources that are associated with the primary resource. Related Resources The "context" may include resources affected by the API request, but may not be identified in the request itself. As an example, the primary resource in an API request to perform a "launch instance" operation may represent a "compute" resource instance, and the related / secondary resource may be a "boot volume," "image," or "subnet" resource used to launch the primary resource (i.e., the compute instance). For example, based on the example "launch instance" API request, the boot volume identifier (bootVolumeId) may be relevant input (context information) required to launch the "instance" primary resource from the secondary (related) "boot volume" resource. In some examples, the centralized API request processing system 604 may fetch the context information from a downstream service (e.g., compute service 618A) configured to perform the operation identified in the API request. In other examples, the centralized API request processing system 604 may fetch the context information from a security zone specification 612 associated with the API request stored in persistent memory data store 610. Additional details describing how context information associated with an API request may be specified and / or obtained are described in connection with the security zone specification described in FIGS. 10-12.

[0093] At operation 914, the centralized API request processing system 604 receives context information needed to process the API request. In some examples, at block 916, the centralized API request processing system 604 may optionally prepare additional context variables based on the primary resource and related resources identified in the API request. The additional context variables may include, for example, obtaining the current state of the resources identified in the API request. For example, in the example of attaching a boot volume to a compute instance, the additional context variables may include obtaining information related to an encryption key to be used with the block volume.

[0094] At operation 918, the centralized API request processing system 604 sends the compartment information and context information to the identity management system 606 for processing. At operation 920, the identity management system 606 processes / evaluates the compartment information and context information to determine whether the operation on the resource is allowed and sends an indication of whether the operation identified in the API request is allowed to be performed on the resource to the centralized API request processing system 604. If the API request is not allowed, in one embodiment, the centralized API request processing system 604 may send an error message to the user at operation 922 indicating the termination of processing of the API request.

[0095] At 924, the centralized API request processing system 604 determines whether the primary resource resides in a compartment associated with a security zone, and if so, sends the security zone information (e.g., a security zone ID) to the security zone policy enforcement system 112. At operation 926, the security zone policy enforcement system 112 performs processing to determine whether the operation on the resource is allowed based on evaluating the security zone policies associated with the security zone (and any security zone policies associated with security zones hierarchically related to that security zone). Based on that processing, at operation 928, the security zone policy enforcement system 122 sends a response to the centralized API request processing system 604.

[0096] If the response indicates that the operation is permitted, then at operation 932 the centralized API request processing system forwards (routes) the API request to the identified downstream service 618A (e.g., a computing service) for further processing. As a result of successful processing of the API request, at operation 934 the downstream service 618 returns a downstream response that the operation was successfully performed. 930 to the centralized API request processing system 604. At operation 936, the centralized API request processing system 604 sends an indication to the user that the API request was successfully executed. If the response indicates that the API request is not authorized, at operation 930, the centralized API request processing system 604 sends a message to the user indicating a policy violation error and terminates processing of the user's API request.

[0097] FIG. 10 is an example security zone specification corresponding to an API request identifying an operation for launching a compute instance resource using a compute service in the CSPI shown in FIG. 6 , according to one embodiment. In the illustrated example, the security zone specification for a “Launch Instance” API request identifies the operation to be performed on the compute instance resource (i.e., “LaunchInstance”), the downstream service (the “Compute Service”) that performs the operation, the primary resource identified in the API request (the “Instance”), and a set of related resources (the “Boot Volume,” “Image,” and “Subnet”) that are associated with the primary resource. As shown in FIG. 10 , in one example, an “associationPredicate” parameter in the security zone specification may be used to identify resources as related resources. For example, when launching a primary “Instance” resource from a secondary “Boot Volume” resource, the boot volume resource is considered to be a related resource; when launching an “Instance” resource from an “Image,” the image resource is considered to be a related resource; when launching an “Instance” resource from a “Subnet,” the subnet resource is considered to be a related resource; and so on.

[0098] The security zone specification further includes a "contextFetchExpression" parameter configured to fetch context information of related resources associated with the primary resource. For example, a boot volume identifier (bootVolumeId) may be a relevant input (context) required to boot an instance from a "bootVolume" and an image identifier (imageId) may be a relevant input (context) required to boot an instance from an "image". A subnet identifier (subnetId) may be a relevant input (context) required to launch an instance from a "subnet." In some examples, the security zone specification further includes a "compartmentIdExpression" parameter that may be used to obtain a compartment identifier associated with the primary resource and related resources identified in the API request.

[0099] 11 is an example of a security zone specification corresponding to an API request that identifies operations for attaching a volume to an instance, attaching a boot volume to an instance, and changing a compartment identifier for an instance using a compute service in CSPI, according to an embodiment. In the illustrated example, the security zone specification for the "Attach Volume" API request identifies the operation to be performed on the compute instance resource (i.e., "AttachVolume"), the downstream service ("Compute Service") that performs the operation, the primary resource ("Instance") identified in the API request, and related resources ("Volumes") associated with the primary resource. The security zone specification for the "Attach Volume" API request also identifies the context information (volume id) needed to attach a volume to an instance and the compartment identifiers associated with the primary and related resources identified in the API request.

[0100] Similarly, the security zone specification for an "Attach Boot Volume" API request identifies the operation to be performed on the instance resource ("AttachBootVolume") and the downstream service that performs that operation ("Compute Service") in the API request. Identifies the primary resource ("instance") and the related resource ("bootvolume") associated with the primary resource. The security zone specification for an "Attach Boot Volume" API request also identifies the context information needed to attach a volume to an instance (bootvolume id) and the compartment identifiers associated with the primary and related resources identified in the API request. The security zone specification for a "Change Instance Compartment" API request identifies the operation performed on the instance resource ("ChangeInstanceCompartment"), the downstream service ("Compute Service") that performs the operation, and the compartment identifiers associated with the API resource. Identifies the primary resource ("instance") identified in the request. The security zone specification for a "change instance compartment" API request also identifies the context information (resource id) needed to change the instance's compartment and the compartment identifier associated with the primary resource and identified in the API request.

[0101] 12 is an example of a security zone specification corresponding to an API request that identifies operations to create a subnet, create an Internet gateway, change the compartment identifier for the subnet, and change the compartment identifier for the Internet gateway using the virtual cloud network service in CSPI, according to an embodiment. In the illustrated example, the security zone specification for the "create subnet" API request identifies the operation to be performed on the subnet resource ("CreateSubnet"), the downstream service ("Virtual Network Service") that performs the operation, and the primary resource ("subnet") identified in the API request. The security zone specification for the "create subnet" API request also identifies the context information needed to create the subnet and the compartment identifier associated with the primary resource. In this example, the context information includes information about the IP address of the subnet to determine whether the create subnet operation in the API request uses a public IP to create the subnet.

[0102] Similarly, the security zone specification for a "Create Internet Gateway" API request specifies the operation to be performed on the Internet gateway resource ("CreateInternetGateway") and the downstream service that performs that operation ("Virtual Network Service"). The security zone specification for a "Create Internet Gateway" API request also identifies the compartment identifier associated with the primary resource identified in the API request. The security zone specification for a "Change Subnet Compartment" API request identifies the operation to be performed on the subnet resource ("ChangeSubnetCompartment") and the downstream service ("Virtual Network Compartment") that will perform that operation. The security zone specification for a "Change Internet Gateway Compartment" API request identifies the operation to be performed on the Internet gateway resource ("ChangeInternetGatewayCompartment"), the downstream service ("Virtual Network Service") that will perform the operation, the primary resource ("Internet Gateway") identified in the API request, and the compartment identifier associated with the primary resource.

[0103] The cloud-based security solution enabled by the disclosed security zone policy enforcement system provides enterprise users with a robust and secure framework for securely configuring, accessing, and managing their resources in the cloud. As previously mentioned, in one embodiment, the security zone policy enforcement system , operates in conjunction with a centralized request processing system to manage and enforce security policies associated with the various resources managed by the CSPI.

[0104] The cloud-based security solution described in this disclosure offers several technological advances and / or improvements over traditional cloud-based security services. The disclosed secure framework comprises a set of security zones and security zone policies that can be enforced on a set of resources in the cloud accessed by users of an enterprise. Access to the set of resources is governed by the set of security zone policies and is not tied to the identity of the user accessing the resource. Thus, a user who is permitted by an IAM policy to access (and / or perform an action on) a resource may be denied access by the disclosed security solution if they violate the set of security zone policies associated with that resource. Security zone policies are based on "deny semantics" that aim to disallow certain actions or behaviors from being performed on a set of resources by any user of an enterprise. This contrasts with the traditional "allow semantics" employed by existing IAM authorization policies, which may allow certain users to perform certain actions on resources based on that user's role / identity within the enterprise.

[0105] Exemplary Architecture The term cloud services is generally used to refer to services made available on demand (e.g., via a subscription model) by a cloud service provider (CSP) to users or customers using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that make up the CSP's infrastructure are separate from the customer's own on-premises servers and systems. Thus, customers can utilize cloud services provided by a CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide customers with easy, scalable access to applications and computing resources without requiring subscribing customers to invest in acquiring the infrastructure used to deliver the service.

[0106] There are several cloud service providers that offer various types of cloud services. There are various different types or models of cloud services, including Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), etc.

[0107] A customer may subscribe to one or more cloud services offered by a CSP. A customer may be any entity, such as an individual, an organization, or a business. When a customer subscribes or registers for a service offered by a CSP, a tenancy or account is created for the customer. The customer may then access one or more subscribed cloud resources associated with the account through this account.

[0108] As mentioned above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider may host the infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider may also , may provide various services (e.g., billing, monitoring, logging, load balancing, clustering, etc.) to accompany those infrastructure components. Accordingly, these services may be policy-driven, allowing IaaS users to implement policies to drive load balancing to maintain application availability and performance.

[0109] In some cases, IaaS customers may access resources and services over a wide area network (WAN), such as the Internet, and may use the cloud provider's services to install the remaining elements of their application stack. For example, a user may log in to an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer may then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application issues, monitoring performance, managing disaster recovery, etc.

[0110] In most cases, the cloud computing model will require the participation of a cloud provider, which may be, but need not be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS. Entities may also choose to deploy private clouds and become their own provider of infrastructure services.

[0111] In some examples, IaaS deployment is the process of putting a new application or a new version of an application onto a prepared application server, etc. It may also include the process of provisioning the server (e.g., installing libraries, daemons, etc.), which is often managed below the hypervisor layer (e.g., server, storage, network hardware, and virtualization) by the cloud provider. Thus, the customer may be responsible for handling (e.g., on self-service virtual machines (which may be launched on demand, for example)), middleware, and / or application deployment, etc.

[0112] In some instances, IaaS provisioning may refer to obtaining computers or virtual hosts for use and even installing required libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0113] In some cases, IaaS provisioning presents two distinct challenges. First, there is the initial challenge of provisioning an initial set of infrastructure before anything is operational. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) once everything is provisioned. In some cases, these two challenges may be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) may be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on which resources and how they work together with each other) may be described declaratively. In some examples, once the topology is defined, workflows may be generated to create and / or manage the different components described in the configuration files.

[0114] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on-demand pool of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more inbound / outbound traffic group rules and one or more virtual machines (VMs) provisioned to define how the network's inbound and / or outbound traffic is set up. Other infrastructure elements, such as load balancers, databases, etc., may also be provisioned. The infrastructure may evolve incrementally as more and more infrastructure elements are desired and / or added.

[0115] In some examples, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques may enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across a variety of different geographic locations, sometimes spanning the entire world). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning may be done manually, utilizing a provisioning tool to provision resources and / or a deployment tool to deploy the code once the infrastructure is provisioned.

[0116] 13 is a block diagram 1300 illustrating an example pattern of an IaaS architecture according to at least one embodiment. A service operator 1302 may be communicatively coupled to a secure host tenancy 1304, which may include a virtual cloud network (VCN) 1306 and a secure host subnet 1308. In some examples, the service operator 1302 may employ one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, cellular phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc., and internet, email, short message service (SMS), Blackberry®, or other enabled communication protocols. Alternatively, the client computing devices may be general-purpose personal computers, including, by way of example, personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device, capable of communicating over a network that may have access to VCN 1306 and / or the Internet.

[0117] The VCN 1306 may include a local peering gateway (LPG) 1310, which may be communicatively coupled to a Secure Shell (SSH) VCN 1312 via an LPG 1310 included in the SSH VCN 1312. The SSH VCN 1312 may include an SSH subnet 1314, which may be communicatively coupled to a control plane VCN 1316 via an LPG 1310 included in the control plane VCN 1316. The SSH VCN 1312 may also be communicatively coupled to a data plane VCN 1318 via an LPG 1310. The control plane VCN 1316 and the data plane VCN 1318 may be included in a service tenancy 1319, which may be owned and / or operated by the IaaS provider.

[0118] The control plane VCN 1316 may include a control plane demilitarized zone (DMZ) tier 1320 that serves as a perimeter network (e.g., the portion of the enterprise network between the enterprise intranet and external networks). DMZ-based servers may have limited responsibility and help keep breaches contained. Additionally, the DMZ tier 1320 may include one or more load balancer (LB) subnets 1322, a control plane app tier 1324 that may include an app subnet 1326, and a control plane data tier 1328 that may include a database (DB) subnet 1330 (e.g., a front-end DB subnet and / or a back-end DB subnet). LB subnet 1322 included in control plane DMZ tier 1320 may be communicatively coupled to app subnet 1326 included in control plane app tier 1324 and to an Internet gateway 1334 that may be included in control plane VCN 1316, and app subnet 1326 may be communicatively coupled to DB subnet 1330 included in control plane data tier 1328, to service gateway 1336, and to network address translation (NAT) gateway 1338. Control plane VCN 1316 may include service gateway 1336 and NAT gateway 1338.

[0119] Control plane VCN 1316 may include a data plane mirror app layer 1340 that may include an app subnet 1326. The app subnet 1326 included in data plane mirror app layer 1340 may include a virtual network interface controller (VNIC) 1342 that may run a compute instance 1344. The compute instance 1344 may communicatively couple the app subnet 1326 of data plane mirror app layer 1340 to the app subnet 1326 that may be included in the data plane app layer 1346.

[0120] Data plane VCN 1318 may include a data plane app layer 1346, a data plane DMZ layer 1348, and a data plane data layer 1350. Data plane DMZ layer 1348 may include LB subnet 1322, which may be communicatively coupled to app subnet 1326 of data plane app layer 1346 and an internet gateway 1334 of data plane VCN 1318. App subnet 1326 may be communicatively coupled to service gateway 1336 of data plane VCN 1318 and a NAT gateway 1338 of data plane VCN 1318. Data plane data layer 1350 may also include DB subnet 1330, which may be communicatively coupled to app subnet 1326 of data plane app layer 1346.

[0121] The internet gateways 1334 of the control plane VCN 1316 and the data plane VCN 1318 may be communicatively coupled to a metadata management service 1352, which may be communicatively coupled to the public internet 1354. The public internet 1354 may be communicatively coupled to a NAT gateway 1338 of the control plane VCN 1316 and the data plane VCN 1318. The service gateways 1336 of the control plane VCN 1316 and the data plane VCN 1318 may be communicatively coupled to cloud services 1356.

[0122] In some examples, a service gateway 1336 of a control plane VCN 1316 or a data plane VCN 1318 may make an application programming interface (API) call to a cloud service 1356 without traversing the public Internet 1354. An API call from a service gateway 1336 to a cloud service 1356 may be one-way: the service gateway 1336 may make an API call to the cloud service 1356, and the cloud service 1356 may send the requested data to the service gateway 1336. However, the cloud service 1356 may not initiate the API call to the service gateway 1336.

[0123] In some examples, secure host tenancy 1304 can connect directly to service tenancy 1319, which may otherwise be isolated. Secure host subnet 1308 may communicate with SSH subnet 1314 through LPG 1310, which may allow bidirectional communication through otherwise isolated systems. Connecting secure host subnet 1308 to SSH subnet 1314 may give secure host subnet 1308 access to other entities within service tenancy 1319.

[0124] The control plane VCN 1316 may enable users of the service tenancy 1319 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 1316 may be deployed or otherwise used in the data plane VCN 1318. In some examples, the control plane VCN 1316 may be isolated from the data plane VCN 1318, and the data plane mirror app layer 1340 of the control plane VCN 1316 may communicate with the data plane app layer 1346 of the data plane VCN 1318 via a VNIC 1342, which may be included in the data plane mirror app layer 1340 and the data plane app layer 1346.

[0125] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, via the public internet 1354, which may communicate the request to the metadata management service 1352. The metadata management service 1352 may communicate the request to the control plane VCN 1316 via the internet gateway 1334. The request may be received by the LB subnet 1322 included in the control plane DMZ tier 1320. The LB subnet 1322 may determine that the request is valid, and in response to this determination, the LB subnet 1322 may send the request to the app subnet 1326 included in the control plane app tier 1324. If the request is validated and requires a call to the public internet 1354, the call to the public internet 1354 may be sent to the NAT gateway 1338, which may make the call to the public internet 1354. Memory that may be desired to be stored with the request may be stored in the DB subnet 1330.

[0126] In some examples, the data plane mirror app layer 1340 may facilitate direct communication between the control plane VCN 1316 and the data plane VCN 1318. For example, it may be desired that a configuration change, update, or other suitable modification be applied to resources included in the data plane VCN 1318. Through the VNIC 1342, the control plane VCN 1316 may communicate directly with the resources included in the data plane VCN 1318, thereby performing the change, update, or other suitable modification to the configuration.

[0127] In some embodiments, the control plane VCN 1316 and the data plane VCN 1318 may be included in a service tenancy 1319. In this case, a user or customer of the system may choose to use either the control plane VCN 1316 or the data plane VCN 1318. The IaaS provider may not own or operate the control plane VCN 1316 and the data plane VCN 1318. Instead, the IaaS provider may own or operate the control plane VCN 1316 and the data plane VCN 1318, both of which may be included in the service tenancy 1319. This embodiment may enable network isolation that may prevent users or customers from interacting with the resources of other users or other customers. This embodiment may also allow users or customers of the system to store databases privately without having to rely on the public internet 1354 for storage, which may not have the desired level of threat protection.

[0128] In another embodiment, LB subnet 1322 included in control plane VCN 1316 may be configured to receive signals from service gateway 1336. In this embodiment, control plane VCN 1316 and data plane VCN 1318 may be configured to be called by customers of the IaaS provider without calling the public internet 1354. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored on service tenancy 1319, which may be controlled by the IaaS provider and isolated from the public internet 1354.

[0129] Figure 14 is a block diagram 1400 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1402 (e.g., service operator 1302 of Figure 13) may be communicatively coupled to a secure host tenancy 1404 (e.g., secure host tenancy 1304 of Figure 13), which may include a virtual cloud network (VCN) 1406 (e.g., VCN 1306 of Figure 13) and a secure host subnet 1408 (e.g., secure host subnet 1308 of Figure 13). VCN 1406 may include a local peering gateway (LPG) 1410 (e.g., LPG 1310 of Figure 13), which may be communicatively coupled to a secure shell (SSH) VCN 1412 (e.g., SSH VCN 1312 of Figure 13) via an LPG 1310 included in SSH VCN 1412. SSH VCN 1412 may include SSH subnet 1414 (e.g., SSH subnet 1314 in FIG. 13 ), and SSH VCN 1412 may be communicatively coupled to control plane VCN 1416 (e.g., control plane VCN 1316 in FIG. 13 ) via LPG 1410 included in control plane VCN 1416. Control plane VCN 1416 may be included in service tenancy 1419 (e.g., service tenancy 1319 in FIG. 13 ), and data plane VCN 1418 (e.g., data plane VCN 1318 in FIG. 13 ) may be included in customer tenancy 1421, which may be owned or operated by a user or customer of the system.

[0130] The control plane VCN 1416 may include a control plane DMZ tier 1420 (e.g., the control plane DMZ tier 1320 of FIG. 13 ) that may include a LB subnet 1422 (e.g., the LB subnet 1322 of FIG. 13 ), a control plane app tier 1424 (e.g., the control plane app tier 1324 of FIG. 13 ) that may include an app subnet 1426 (e.g., the app subnet 1326 of FIG. 13 ), and a control plane data tier 1428 (e.g., the control plane data tier 1328 of FIG. 13 ) that may include a database (DB) subnet 1430 (e.g., similar to the DB subnet 1330 of FIG. 13 ). The LB subnet 1422 included in the control plane DMZ layer 1420 may be communicatively coupled to an app subnet 1426 included in the control plane app layer 1424 and to an Internet gateway 1434 (e.g., Internet gateway 1334 in FIG. 13 ) that may be included in the control plane VCN 1416, and the app subnet 1426 may be communicatively coupled to a DB subnet 1430 included in the control plane data layer 1428, to a service gateway 1436 (e.g., service gateway in FIG. 13 ), and to a network address translation (NAT) gateway 1438 (e.g., NAT gateway 1338 in FIG. 13 ). The control plane VCN 1416 is communicatively coupled to the service gateway 1436 and the NAT gateway 1438. It may include 8.

[0131] Control plane VCN 1416 may include a data plane mirror app layer 1440 (e.g., data plane mirror app layer 1340 of FIG. 13 ), which may include an app subnet 1426. App subnet 1426 included in data plane mirror app layer 1440 may include a virtual network interface controller (VNIC) 1442 (e.g., VNIC 1342) that may run a compute instance 1444 (e.g., similar to compute instance 1344 of FIG. 13 ). Compute instance 1444 may facilitate communication between app subnet 1426 of data plane mirror app layer 1440 and app subnet 1426 that may be included in data plane app layer 1446 (e.g., data plane app layer 1346 of FIG. 13 ) via VNIC 1442 included in data plane mirror app layer 1440 and VNIC 1442 included in data plane app layer 1446.

[0132] An internet gateway 1434 included in the control plane VCN 1416 may be communicatively coupled to a metadata management service 1452 (e.g., metadata management service 1352 of FIG. 13 ), which may be communicatively coupled to the public internet 1454 (e.g., public internet 1354 of FIG. 13 ). The public internet 1454 may be communicatively coupled to a NAT gateway 1438 included in the control plane VCN 1416. A service gateway 1436 included in the control plane VCN 1416 may be communicatively coupled to cloud services 1456 (e.g., cloud services 1356 of FIG. 13 ).

[0133] In some examples, data plane VCN 1418 may be included in customer tenancy 1421. In this case, the IaaS provider may provide a control plane VCN 1416 for each customer, and the IaaS provider may set up a unique compute instance 1444, included in service tenancy 1419, for each customer. Each compute instance 1444 may enable communication between the control plane VCN 1416 included in service tenancy 1419 and the data plane VCN 1418 included in customer tenancy 1421. The compute instance 1444 may enable resources provisioned in the control plane VCN 1416 included in service tenancy 1419 to be deployed or otherwise used in the data plane VCN 1418 included in customer tenancy 1421.

[0134] In another example, a customer of the IaaS provider may have a database residing in customer tenancy 1421. In this example, control plane VCN 1416 may include data plane mirror app tier 1440, which may include app subnet 1426. Data plane mirror application tier 1440 may reside in data plane VCN 1418, but data plane mirror application tier 1440 may not reside in data plane VCN 1418. That is, data plane mirror application tier 1440 may have access to customer tenancy 1421, but data plane mirror application tier 1440 may not reside in data plane VCN 1418 or be owned or operated by the IaaS provider's customer. Data plane mirror application tier 1440 may be configured to make calls to data plane VCN 1418, but may not be configured to make calls to any entities included in control plane VCN 1416. A customer may desire to deploy or otherwise use resources in the data plane VCN 1418 that are provisioned in the control plane VCN 1416, and the data plane mirror application layer 1440 may facilitate the desired deployment or other use of the customer's resources.

[0135] In some embodiments, the IaaS provider's customer may apply filters to the data plane VCN 1418. In this embodiment, the customer may determine what the data plane VCN 1418 can access, and the customer may restrict access from the data plane VCN 1418 to the public internet 1454. The IaaS provider may not be able to filter or otherwise control access of the data plane VCN 1418 to any external networks or databases. Applying filters and controls by the customer on the data plane VCN 1418 included in the customer tenancy 1421 can help isolate the data plane VCN 1418 from other customers and the public internet 1454.

[0136] In some embodiments, cloud services 1456 may be invoked by service gateway 1436 to access services that may not reside on the public internet 1454, on control plane VCN 1416, or on data plane VCN 1418. The connection between cloud services 1456 and control plane VCN 1416 or data plane VCN 1418 may not be live or continuous. Cloud services 1456 may reside on different networks owned or operated by the IaaS provider. Cloud services 1456 may be configured to receive calls from service gateway 1436 and may not be configured to receive calls from the public internet 1454. Some cloud services 1456 may be isolated from other cloud services 1456, and control plane VCN 1416 may be isolated from cloud services 1456 that may not be in the same region as control plane VCN 1416. For example, control plane VCN 1416 may be located in “Region 1,” and cloud service “Deployment 13” may be located in Region 1 and Region 2. If a call to deployment 13 is made by a service gateway 1436 included in control plane VCN 1416 located in region 1, the call may be transmitted to deployment 13 in region 1. In this example, control plane VCN 1416, or deployment 13 in region 1, may not be communicatively coupled to or otherwise in communication with deployment 13 in region 2.

[0137] 15 is a block diagram 1500 illustrating another exemplary pattern of an IaaS architecture, according to at least one embodiment. A service operator 1502 (e.g., service operator 1302 of FIG. 13 ) may be communicatively coupled to a secure host tenancy 1504 (e.g., secure host tenancy 1304 of FIG. 13 ), which may include a virtual cloud network (VCN) 1506 (e.g., VCN 1306 of FIG. 13 ) and a secure host subnet 1508 (e.g., secure host subnet 1308 of FIG. 13 ). VCN 1506 may include an LPG 1510 (e.g., LPG 1310 of FIG. 13 ), which may be communicatively coupled to an SSH VCN 1512 via the LPG 1510 included in SSH VCN 1512 (e.g., SSH VCN 1312 of FIG. 13 ). SSH VCN 1512 may include SSH subnet 1514 (e.g., SSH subnet 1314 in FIG. 13 ), which may be communicatively coupled to control plane VCN 1516 via LPG 1510 included in control plane VCN 1516 (e.g., control plane VCN 1316 in FIG. 13 ), and may be communicatively coupled to data plane VCN 1518 via LPG 1510 included in data plane VCN 1518 (e.g., data plane 1318 in FIG. 13 ). Control plane VCN 1516 and data plane VCN 1518 may be included in service tenancy 1519 (e.g., service tenancy 1319 in FIG. 13 ).

[0138] The control plane VCN 1516 includes a control plane DMZ layer 1520 (e.g., the control plane DMZ layer 1320 in FIG. 13 ) that may include a load balancer (LB) subnet 1522 (e.g., the LB subnet 1322 in FIG. 13 ), and a control plane DMZ layer 1520 (e.g., the app subnet 1322 in FIG. 13 ). 13 ) that may include an app subnet 1526 (similar to control plane VCN 1326), and a control plane data layer 1528 (e.g., control plane data layer 1328 of FIG. 13 ) that may include a DB subnet 1530. The LB subnet 1522 included in the control plane DMZ layer 1520 may be communicatively coupled to the app subnet 1526 included in the control plane app layer 1524 and to an Internet gateway 1534 (e.g., Internet gateway 1334 of FIG. 13 ) that may be included in the control plane VCN 1516, and the app subnet 1526 may be communicatively coupled to the DB subnet 1530 included in the control plane data layer 1528, as well as to a service gateway 1536 (e.g., service gateway of FIG. 13 ) and a network address translation (NAT) gateway 1538 (e.g., NAT gateway 1338 of FIG. 13 ). The control plane VCN 1516 may include a service gateway 1536 and a NAT gateway 1538.

[0139] The data plane VCN 1518 may include a data plane app layer 1546 (e.g., the data plane app layer 1346 in FIG. 13 ), a data plane DMZ layer 1548 (e.g., the data plane DMZ layer 1348 in FIG. 13 ), and a data plane data layer 1550 (e.g., the data plane data layer 1350 in FIG. 13 ). The data plane DMZ layer 1548 may include a LB subnet 1522 that may be communicatively coupled to a trusted app subnet 1560 and an untrusted app subnet 1562 of the data plane app layer 1546 and to an Internet gateway 1534 included in the data plane VCN 1518. The trusted app subnet 1560 may be communicatively coupled to a service gateway 1536 included in the data plane VCN 1518, a NAT gateway 1538 included in the data plane VCN 1518, and a DB subnet 1530 included in the data plane data layer 1550. The untrusted app subnet 1562 may be communicatively coupled to a service gateway 1536 included in the data plane VCN 1518 and a DB subnet 1530 included in the data plane data layer 1550. The data plane data layer 1550 may include a DB subnet 1530 that may be communicatively coupled to a service gateway 1536 included in the data plane VCN 1518.

[0140] The untrusted app subnet 1562 may include one or more primary VNICs 1564(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1566(1)-(N). Each tenant VM 1566(1)-(N) may be communicatively coupled to a respective app subnet 1567(1)-(N), which may be included in a respective container egress VCN 1568(1)-(N), which may be included in a respective customer tenancy 1570(1)-(N). Each secondary VNIC 1572(1)-(N) may facilitate communication between the untrusted app subnet 1562 included in the data plane VCN 1518 and the app subnet included in the container egress VCN 1568(1)-(N). Each container egress VCN 1568(1)-(N) may include a NAT gateway 1538, which may be communicatively coupled to the public internet 1554 (e.g., public internet 1354 in FIG. 13 ).

[0141] An internet gateway 1534 included in the control plane VCN 1516 and in the data plane VCN 1518 may be communicatively coupled to a metadata management service 1552 (e.g., metadata management system 1352 of FIG. 13 ), which may be communicatively coupled to the public internet 1554. The public internet 1554 may be communicatively coupled to a NAT gateway 1538 included in the control plane VCN 1516 and in the data plane VCN 1518. A service gateway 1536 included in the control plane VCN 1516 and in the data plane VCN 1518 may be communicatively coupled to cloud services 1556.

[0142] In some embodiments, data plane VCN 1518 may be integrated with customer tenancy 1570. This integration may be useful or desirable to an IaaS provider's customer in some cases, such as when they may want support when executing code. A customer may provide code to run that may be disruptive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided to the IaaS provider by the customer.

[0143] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request that a function be attached to data plane layer app 1546. The code to perform the function may run in VMs 1566(1)-(N) and may not be configured to run anywhere else on the data plane VCN 1518. Each VM 1566(1)-(N) may be connected to one customer tenancy 1570. Each container 1571(1)-(N) contained in VM 1566(1)-(N) may be configured to run code. In this case, there may be double isolation (e.g., containers 1571(1)-(N) may execute code, and containers 1571(1)-(N) may be included in at least VMs 1566(1)-(N) included in untrusted app subnet 1562), which may help prevent incorrect or otherwise unwanted code from damaging the IaaS provider's network or damaging a different customer's network. Containers 1571(1)-(N) may be communicatively coupled to customer tenancy 1570 and may be configured to send or receive data to or from customer tenancy 1570. Containers 1571(1)-(N) may not be configured to send or receive data to or from any other entity in data plane VCN 1518. Once the code execution is complete, the IaaS provider may kill or otherwise discard containers 1571(1)-(N).

[0144] In some embodiments, trusted app subnet 1560 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 1560 may be communicatively coupled to DB subnet 1530 and may be configured to perform CRUD operations within DB subnet 1530. Untrusted app subnet 1562 may be communicatively coupled to DB subnet 1530, but in this embodiment, the untrusted app subnet may be configured to perform read operations within DB subnet 1530. Containers 1571(1)-(N) that may be included in each customer's VMs 1566(1)-(N) and that may execute code from that customer may not be communicatively coupled to DB subnet 1530.

[0145] In other embodiments, the control plane VCN 1516 and the data plane VCN 1518 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 1516 and the data plane VCN 1518. However, communication may occur indirectly through at least one method. An LPG 1510 may be established by the IaaS provider to facilitate communication between the control plane VCN 1516 and the data plane VCN 1518. In another example, the control plane VCN 1516 or the data plane VCN 1518 may make a call to a cloud service 1556 through the service gateway 1536. For example, a call from the control plane VCN 1516 to the cloud service 1556 may include a request for a service that may communicate with the data plane VCN 1518.

[0146] 16 is a block diagram 1600 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1602 (e.g., 13 ) may be communicatively coupled to a secure host tenancy 1604 (e.g., secure host tenancy 1304 of FIG. 13 ), which may include a virtual cloud network (VCN) 1606 (e.g., VCN 1306 of FIG. 13 ) and a secure host subnet 1608 (e.g., secure host subnet 1308 of FIG. 13 ). VCN 1606 may include an LPG 1610 (e.g., LPG 1310 of FIG. 13 ), which may be communicatively coupled to an SSH VCN 1612 via the LPG 1610 included in SSH VCN 1612 (e.g., SSH VCN 1312 of FIG. 13 ). SSH VCN 1612 may include SSH subnet 1614 (e.g., SSH subnet 1314 in FIG. 13 ), which may be communicatively coupled to control plane VCN 1616 via LPG 1610 included in control plane VCN 1616 (e.g., control plane VCN 1316 in FIG. 13 ) and to data plane VCN 1618 via LPG 1610 included in data plane VCN 1618 (e.g., data plane 1318 in FIG. 13 ). Control plane VCN 1616 and data plane VCN 1618 may be included in service tenancy 1619 (e.g., service tenancy 1319 in FIG. 13 ).

[0147] The control plane VCN 1616 may include a control plane DMZ layer 1620 (e.g., the control plane DMZ layer 1320 of FIG. 13 ) that may include a LB subnet 1622 (e.g., the LB subnet 1322 of FIG. 13 ), a control plane app layer 1624 (e.g., the control plane app layer 1324 of FIG. 13 ) that may include an app subnet 1626 (e.g., the app subnet 1326 of FIG. 13 ), and a control plane data layer 1628 (e.g., the control plane data layer 1328 of FIG. 13 ) that may include a DB subnet 1630 (e.g., the DB subnet 1530 of FIG. 15 ). The LB subnet 1622 included in the control plane DMZ layer 1620 may be communicatively coupled to an app subnet 1626 included in the control plane app layer 1624 and to an Internet gateway 1634 (e.g., Internet gateway 1334 in FIG. 13 ) that may be included in the control plane VCN 1616, and the app subnet 1626 may be communicatively coupled to a DB subnet 1630 included in the control plane data layer 1628 and to a service gateway 1636 (e.g., service gateway in FIG. 13 ) and a network address translation (NAT) gateway 1638 (e.g., NAT gateway 1338 in FIG. 13 ). The control plane VCN 1616 may include the service gateway 1636 and the NAT gateway 1638.

[0148] Data plane VCN 1618 may include a data plane app layer 1646 (e.g., data plane app layer 1346 in FIG. 13 ), a data plane DMZ layer 1648 (e.g., data plane DMZ layer 1348 in FIG. 13 ), and a data plane data layer 1650 (e.g., data plane data layer 1350 in FIG. 13 ). Data plane DMZ layer 1648 may include LB subnet 1622, which may be communicatively coupled to trusted app subnet 1660 (e.g., trusted app subnet 1560 in FIG. 15 ) and untrusted app subnet 1662 (e.g., untrusted app subnet 1562 in FIG. 15 ) of data plane app layer 1646 and to an Internet gateway 1634 included in data plane VCN 1618. Trusted app subnet 1660 may be communicatively coupled to service gateway 1636 included in data plane VCN 1618, NAT gateway 1638 included in data plane VCN 1618, and DB subnet 1630 included in data plane data layer 1650. Untrusted app subnet 1662 may be communicatively coupled to service gateway 1636 included in data plane VCN 1618 and DB subnet 1630 included in data plane data layer 1650. Data plane data layer 1650 may include DB subnet 1630, which may be communicatively coupled to service gateway 1636 included in data plane VCN 1618.

[0149] The untrusted app subnet 1662 may include primary VNICs 1664(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1666(1)-(N) residing within the untrusted app subnet 1662. Each tenant VM 1666(1)-(N) may execute code in a respective container 1667(1)-(N), which may be communicatively coupled to an app subnet 1626, which may be included in a data plane app tier 1646, which may be included in a container egress VCN 1668. Each secondary VNIC 1672(1)-(N) may facilitate communication between the untrusted app subnet 1662, which is included in the data plane VCN 1618, and the app subnet included in the container egress VCN 1668. The container egress VCN may include a NAT gateway 1638, which may be communicatively coupled to the public internet 1654 (e.g., public internet 1354 in FIG. 13 ).

[0150] An internet gateway 1634 included in the control plane VCN 1616 and in the data plane VCN 1618 may be communicatively coupled to a metadata management service 1652 (e.g., metadata management system 1352 of FIG. 13 ), which may be communicatively coupled to the public internet 1654. The public internet 1654 may be communicatively coupled to a NAT gateway 1638 included in the control plane VCN 1616 and in the data plane VCN 1618. A service gateway 1636 included in the control plane VCN 1616 and in the data plane VCN 1618 may be communicatively coupled to cloud services 1656.

[0151] In some examples, the pattern illustrated by the architecture of block diagram 1600 in FIG. 16 may be considered an exception to the pattern illustrated by the architecture of block diagram 1500 in FIG. 15 , which may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 1667(1)-(N) contained in VM 1666(1)-(N) for each customer may be accessed by the customer in real time. The containers 1667(1)-(N) may be configured to make calls to each secondary VNIC 1672(1)-(N) contained in app subnet 1626 of data plane app tier 1646, which may be contained in container egress VCN 1668. The secondary VNICs 1672(1)-(N) may send the calls to NAT gateway 1638, which may send the calls to the public Internet 1654. In this example, containers 1667(1)-(N) that may be accessed in real time by a customer may be isolated from control plane VCN 1616 and may be isolated from other entities included in data plane VCN 1618. Containers 1667(1)-(N) may also be isolated from resources from other customers.

[0152] In another example, a customer may invoke cloud service 1656 using container 1667(1)-(N). In this example, the customer may execute code within container 1667(1)-(N) that requests a service from cloud service 1656. Container 1667(1)-(N) may send the request to secondary VNICs 1672(1)-(N), which may send the request to a NAT gateway, which may send the request to public Internet 1654. Public Internet 1654 may send the request to LB subnet 1622, which is included in control plane VCN 1616, via Internet gateway 1634. In response to determining that the request is valid, LB subnet 1626 may send the request to app subnet 1626, which may send the request to cloud service 1656 via service gateway 1636.

[0153] The illustrated IaaS architectures 1300, 1400, 1500, and 1600 are It should be appreciated that the IaaS system may have components other than those shown. Additionally, the illustrated embodiments are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than those illustrated, may combine two or more components, or may have a different configuration or arrangement of components.

[0154] In one embodiment, the IaaS system described herein may include a suite of application, middleware, and database service offerings that are self-service, subscription-based, elastically scalable, reliable, highly available, and securely delivered to customers. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0155] 17 illustrates an exemplary computer system 1700 upon which various embodiments may be implemented. System 1700 may be used to implement any of the computer systems described above. As shown in the figure, computer system 1700 includes a processing unit 1704 that communicates with several peripheral subsystems via a bus subsystem 1702. These peripheral subsystems may include a processing acceleration unit 1706, an I / O subsystem 1708, a storage subsystem 1718, and a communication subsystem 1724. Storage subsystem 1718 includes a tangible computer-readable storage medium 1722 and a system memory 1710.

[0156] Bus subsystem 1702 provides a mechanism for allowing the various components and subsystems of computer system 1700 to communicate with each other as intended. While bus subsystem 1702 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1702 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0157] Processing unit 1704 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of computer system 1700. One or more processors may be included in processing unit 1704. These processors may include single-core processors or multi-core processors. In particular embodiments, processing unit 1704 may be implemented as one or more independent processing units 1732 and / or 1734, with each processing unit including a single-core processor or a multi-core processor. In other embodiments, processing unit 1704 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0158] In various embodiments, processing unit 1704 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed may reside in processor 1704 and / or storage subsystem 1718. Through suitable programming, processor 1704 may provide the various functionality described above. Computer system 1700 may include processing acceleration units 1704, which may include digital signal processors (DSPs), special purpose processors, etc. 706 may further be included.

[0159] The I / O subsystem 1708 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, a motion-sensing and / or gesture-recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. The user interface input device may detect eye movements from the user (e.g., "blinking" while taking a picture and / or making a menu selection) and transmit eye gestures to an input device (e.g., a Google The user interface input devices may also include eye gesture recognition devices such as a Google Glass® blink detector that converts eye movements as input to the Google Glass®. Additionally, the user interface input devices may include a voice recognition sensing device that allows the user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0160] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, user interface input devices may include medical imaging input devices, such as computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound machines, etc. User interface input devices may also include audio input devices, such as MIDI keyboards, digital musical instruments, etc.

[0161] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all conceivable types of devices and mechanisms for outputting information from computer system 1700 to a user or to another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0162] Computer system 1700 may include a storage subsystem 1718 that includes software elements currently shown as located in system memory 1710. System memory 1710 may store program instructions that are loadable and executable on processing unit 1704, as well as data generated during the execution of these programs.

[0163] Depending on the configuration and type of computer system 1700, system memory 1710 The system memory 1710 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or presently being operated on and executed by the processing unit 1704. In some implementations, the system memory 1710 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 1700, such as during start-up, may typically be stored in ROM. By way of example and not limitation, the system memory 1710 also illustrates application programs 1712, program data 1714, and an operating system 1716, which may include client applications, a web browser, a middle-tier application, a relational database management system (RDBMS), etc. By way of example, operating system 1716 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0164] The storage subsystem 1718 may also provide a tangible, computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above may be stored in the storage subsystem 1718. These software modules or instructions may be executed by the processing unit 1704. The storage subsystem 1718 may also provide a repository for storing data used in accordance with the present disclosure.

[0165] Storage subsystem 1700 may also include computer-readable storage medium reader 1720, which may be further connected to computer-readable storage medium 1722. Along with, and optionally in combination with, system memory 1710, computer-readable storage medium 1722 may collectively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0166] The computer-readable storage medium 1722 containing the code or portions of code can also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for information storage and / or transmission. This may include tangible computer-readable storage media, such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage, or other tangible computer-readable medium. This may also include non-tangible computer-readable media, such as a data signal, data transmission, or any other medium that can be used to transmit desired information and that can be accessed by computing system 1700.

[0167] By way of example, the computer readable storage medium 1722 may be a hard disk drive that reads from and writes to a non-removable, non-volatile magnetic medium, a magnetic disk drive that reads from and writes to a removable, non-volatile magnetic disk, a CD ROM, a DVD, and a Blu-Ray (registered trademark) The computer system 1700 may also include an optical disk drive or other optical medium that reads from and writes to a removable, nonvolatile optical disk, such as a USB (Universal Serial Bus) disk. The computer-readable storage medium 1722 may include, but is not limited to, a Zip® drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, or the like. The computer-readable storage medium 1722 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on nonvolatile memory such as solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1700.

[0168] The communications subsystem 1724 provides an interface to other computer systems and networks. The communications subsystem 1724 serves as an interface for sending and receiving data between other systems and the computer system 1700. For example, the communications subsystem 1724 may enable the computer system 1700 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 1724 may include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular telephone technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family standards, or other mobile communications technologies, or any combination thereof), global positioning system (GPS) receiver components, and / or other components. In some embodiments, the communications subsystem 1724 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0169] In some embodiments, the communications subsystem 1724 may also receive incoming communications in the form of structured and / or unstructured data feeds 1726, event streams 1728, event updates 1730, etc., on behalf of one or more users who may be using the computer system 1700.

[0170] For example, the communication subsystem 1724 may provide a Twitter feed, Facebook feed, Registered Trademark) updates, web feeds such as Rich Site Summary (RSS) feeds, and and / or may be configured to receive data feeds 1726 in real time from users of social networks and / or other communication services, such as real-time updates from one or more third-party sources.

[0171] Additionally, the communications subsystem 1724 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1728 of real-time events and / or event updates 1730, which may be continuous or infinite in nature with no explicit termination. Examples of applications that generate continuous data include, for example, sensor data applications, financial stock ticker boards, network performance measurement tools (e.g., network monitoring and traffic management applications), and the like. ), clickstream analysis tools, and automobile traffic monitoring.

[0172] The communications subsystem 1724 may also be configured to output structured and / or unstructured data feeds 1726, event streams 1728, event updates 1730, etc. to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1700.

[0173] The computer system 1700 can be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0174] Due to the ever-changing nature of computers and networks, the description of computer system 1700 shown in the figure is intended merely as a specific example. Many other configurations are possible, having more or fewer components than the system depicted in the figure. For example, customized hardware might also be used, and / or particular elements might be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, might be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other aspects and / or methods for implementing the various embodiments.

[0175] While specific embodiments have been described, various modifications, variations, alternative configurations, and equivalents are encompassed within the scope of the present disclosure. The embodiments are not limited to operation in one particular data processing environment, but can freely operate in multiple data processing environments. In addition, while the embodiments are described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described sequence of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or together.

[0176] Furthermore, while embodiments have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, when a component or module is described as being configured to perform certain operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, programming a programmable electronic circuit (such as a microprocessor) to perform the operations, or any combination thereof. Processes may communicate using various techniques, including, but not limited to, conventional techniques for inter-process communication; different pairs of processes may use different techniques, and the same pair of processes may use different techniques at different times.

[0177] Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and changes may be made without departing from the broader spirit and scope of the appended claims. Accordingly, while certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

[0178] The use of the words "a," "an," and "the" and similar referents in the context of describing disclosed embodiments (particularly in the context of the claims) should be construed to encompass both the singular and the plural unless otherwise indicated herein or clearly contradicted by context. The words "comprising," "having," "including," and "containing" are used in open-ended language (i.e., "including but not limited to"), unless otherwise noted. The term "connected" should be interpreted as partially or wholly contained within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values ​​herein, unless otherwise indicated herein, is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, and each separate value is incorporated herein as if it were individually set forth herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., "etc.") provided herein is intended merely to better describe embodiments and does not limit the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0179] Disjunctive language such as the phrase "at least one of X, Y, or Z" is intended to be understood within the context in which it is generally used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, encompass that an embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0180] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to adopt such variations as appropriate, and the present disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure unless otherwise indicated herein.

[0181] All references cited herein, including publications, patent applications, and patents, are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0182] While the foregoing specification describes aspects of the present disclosure with reference to specific embodiments thereof, those skilled in the art will recognize that the present disclosure is not limited thereto. Various features and aspects of the above disclosure may be used individually or together. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

Claims

1. 1. A method comprising: receiving, by a security zone policy enforcement system within a cloud service provider infrastructure, a request to perform an action on a resource; the security zone policy enforcement system determining a compartment associated with the resource; the security zone policy enforcement system determining that the compartment is associated with a security zone; the security zone policy enforcement system determining a set of one or more security zone policies applicable to the resource; determining, by the security zone policy enforcement system, that the action on the resource is permitted based on the set of one or more security zone policies; In response to determining that the action on the resource is permitted, the security zone policy enforcement system allows the action to be performed on the resource.

2. 10. The method of claim 1, wherein determining the compartment associated with the resource includes determining a compartment identifier of the compartment associated with the resource and a set of one or more compartment policies applicable to the resource.

3. 3. The method of claim 2, wherein the set of one or more compartment policies applicable to the resource comprises a union of one or more compartment policies associated with the compartment and one or more parent compartments hierarchically related to the compartment.

4. determining that the action on the resource is permitted based on the set of one or more compartment policies; The method of claim 2 , further comprising: in response to said determining, determining that said compartment is associated with said security zone.

5. determining that the operation on the resource is not permitted based on the set of one or more compartment policies; 3. The method of claim 2, further comprising: in response to determining that the operation is not allowed to be performed on the resource based on the set of one or more compartment policies, not allowing the operation to be performed on the resource.

6. determining that the operation on the resource is not permitted based on the set of one or more security zone policies; The method of claim 1 , further comprising, in response to said determining, not allowing said operation to be performed on said resource.

7. 2. The method of claim 1 , wherein the set of one or more security zone policies applicable to the resource comprises a union of one or more security zone policies associated with the security zone and one or more security zone policies associated with one or more parent security zones hierarchically related to the security zone.

8. a security zone policy in the set of one or more security zone policies 2. The method of claim 1 , wherein: is expressed as a set of one or more expressions, each expression in the set of expressions including a set of one or more conditions, each condition in the set of one or more conditions specifying a restriction on the operation to be performed on the resource.

9. 9. The method of claim 8, wherein the restrictions specify criteria that require encryption of the resource, restrict movement of the resource from the compartment in which it resides, or prohibit the resource from being accessible from the public internet.

10. The method of claim 9 , wherein the restriction specifies criteria related to one or more secondary resources associated with the resource, the one or more secondary resources affecting the operation of the resource.

11. The method of claim 1 , wherein the set of one or more security zone policies prohibits certain configurations of the operations from being performed on the resource.

12. The method of claim 1 , further comprising the security zone policy enforcement system sending a result to a user indicating that the action was successfully performed on the resource.

13. The method of claim 1 , further comprising the security zone policy enforcement system sending a result to a user, the result indicating that the operation was not successfully performed on the resource.

14. 1. A security zone policy enforcement system in a cloud service provider infrastructure, comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the system to: receiving a request to perform an action on a resource; determining a compartment associated with the resource; determining that the compartment is associated with a security zone; determining a set of one or more security zone policies applicable to the resource; determining that the operation on the resource is permitted based on the set of one or more security zone policies; a security zone policy enforcement system configured to, in response to determining that the action on the resource is permitted, allow the action to be performed on the resource;

15. The system of claim 14 , further comprising instructions for determining a compartment identifier for the compartment associated with the resource and a set of one or more compartment policies applicable to the resource.

16. 2. The system of claim 1, wherein a security zone policy in the set of one or more security zone policies is expressed as a set of one or more expressions, each expression in the set of expressions including a set of one or more conditions, and each condition in the set of one or more conditions specifies a restriction on the operation to be performed on the resource.

17. a non-transitory computer-readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform operations; The operation is A security zone policy enforcement system for providing secure access to resources within a cloud service provider infrastructure includes receiving a request to associate a compartment with a security zone, the compartment being associated with a set of one or more compartment policies, the operations further comprising: In response to the request, the security zone policy enforcement system associates the compartment with the security zone, the security zone being associated with a set of one or more security zone policies; A non-transitory computer-readable medium, wherein as a result of associating the compartment with the security zone, the compartment is associated with the set of one or more security zone policies and the set of one or more compartment policies.

18. receiving, by the security zone policy enforcement system, a request to add a resource to the compartment; 20. The non-transitory computer-readable medium of claim 17, further comprising: in response to the request, the security zone policy enforcement system determining access to the resource based at least in part on the set of one or more compartment policies and the set of one or more security zone policies.

19. 20. The non-transitory computer-readable medium of claim 18, wherein the set of one or more security zone policies prohibits a set of operations from being performed on the resource or prohibits a particular version of an operation from being performed on the resource.

20. 20. The non-transitory computer-readable medium of claim 18, wherein a security zone policy in the set of one or more security zone policies is expressed as a set of one or more expressions, each expression in the set of expressions including a set of one or more conditions, each condition in the set of one or more conditions specifying a restriction on an operation to be performed on the resource.

Images