Controlling operator access to customer cloud infrastructure environments

Abstract

One or more embodiments disclose techniques for enabling a customer operator of a cloud service provider (CSP) to disable operator access to resources within a customer cloud environment. Operator access can be disabled or suspended by an operator of a CSP customer initiating a disable command. Disabling operator access includes (a) terminating existing sessions that provide the operator with access to resources, (b) rejecting new requests for credentials to establish sessions that provide operator access, and / or (c) revoking existing credentials used to establish sessions that provide operator access. Disabling operator access may apply to resources within the customer cloud environment or to a subset of resources, and / or may apply to some operators but not to others. Operators may be operators of the same category or operators of different categories. At the end of a specified time period, the operator's ability to access the customer cloud environment may be restored.

Description

Technical Field

[0001] Claims of Benefit, Related Applications, Incorporation by Reference This application claims the benefit of U.S. Non-Provisional Application No. 18 / 649,783, filed Apr. 29, 2024, and U.S. Provisional Application No. 63 / 462,880, filed Apr. 28, 2023, which is incorporated herein by reference.

[0002] Applicant hereby disclaims any disclaimer of claim scope in the parent application or during prosecution thereof, and notifies the USPTO that the claims of this application may be broader than any claim of the parent application.

[0003] Technical Field This disclosure relates to cloud environments. In particular, this disclosure relates to restricting operator access of a cloud service provider (CSP) to a cloud infrastructure environment of a CSP customer.

Background Art

[0004] Background Using cloud computing environments, access can be provided to various complementary cloud-based components, such as software applications or services, that enable an organization or enterprise customer to operate its applications and services in a highly available host environment.

Summary of the Invention

[0005] Benefits for an organization to migrate its application and service needs to a cloud environment include reducing the costs and complexities of designing, building, operating, and maintaining its own on-premises data center, software application framework, or other information technology infrastructure.

[0006] Maintaining and supporting the infrastructure and security of customer cloud environments requires access to a variety of operator actions. Customer operators, i.e., operators associated with the CSP's customers, perform a subset of these actions to support some form of triage of the customer cloud environment, such as Level 1 and Level 2 support. For deeper technical issues, CSP operators, i.e., operators associated with the CSP, address them using another subset of actions that are not available to customer operators.

[0007] The methods described in this section are feasible, but they are not necessarily methods that have been conceived or implemented before. Therefore, unless otherwise specified, it should not be assumed that any of the methods described in this section qualify as prior art simply because they are described in this section.

[0008] In each of the accompanying drawings, embodiments are shown as examples, not as limitations. It should be noted that references to “an” or “one” embodiments in this disclosure do not necessarily refer to the same embodiment, but rather mean at least one. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows a system that provides a cloud infrastructure environment according to one embodiment. [Figure 2] This diagram further illustrates how a cloud infrastructure environment can be used to provide a cloud-based application or service or service, according to one embodiment. [Figure 3] This figure shows an example of a cloud infrastructure architecture according to one embodiment. [Figure 4] This figure shows another example of a cloud infrastructure architecture according to one embodiment. [Figure 5] This figure shows another example of a cloud infrastructure architecture according to one embodiment. [Figure 6] This figure shows another example of a cloud infrastructure architecture according to one embodiment. [Figure 7] This diagram shows how, in one embodiment, the system can provide a dedicated or private label cloud environment used by tenants or customers of a cloud infrastructure environment. [Figure 8] This figure further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment. [Figure 9] This figure further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment. [Figure 10] This figure shows a system, according to one embodiment, for providing access to software products or services in a cloud computing environment or other computing environment. [Figure 11] This figure shows a system for controlling operator access to resources within a customer cloud environment, according to one or more embodiments. [Figure 12] This figure shows an example of a set of actions for controlling operator access to resources in a customer cloud environment, according to one or more embodiments. [Figure 13] This figure shows examples of infrastructure security dashboards presented to customers, according to one or more embodiments. [Modes for carrying out the invention]

[0010] Detailed explanation The following description includes numerous specific details for illustrative purposes to ensure a complete understanding. One or more embodiments can be implemented without these specific details. Features described in one embodiment can be combined with features described in a different embodiment. In some examples, well-known structures and devices are described with reference to block diagrams to avoid unnecessarily obscuring this disclosure.

[0011] 1. Overview 2. Examples of cloud environments 3. Access control architecture 4. Controlling operator access to cloud resources 5. Examples of Embodiments 6. Practical applications, benefits, and improvements 7. Other developments 1. Overview One or more embodiments enable a Cloud Service Provider (CSP) customer operator to disable operator access to resources within the customer cloud environment. Operator access to resources within the customer cloud environment can be disabled or suspended by initiating a disable command. Disabling operator access includes (a) terminating existing sessions that provide the operator with access to the resources, (b) rejecting new requests for credentials to establish sessions that provide operator access, and / or (c) revoking existing credentials used to establish sessions that provide operator access. Disabling operator access may apply to all resources within the customer cloud environment, or to a subset of resources. Similarly, disabling operator access may apply to some operators but not to others. Operators may be operators of the same category or different categories, such as operators associated with the CSP or operators associated with the CSP's customers. Operator access may be disabled for a specified period of time. At the end of the specified period of time, the operator's ability to access the customer cloud environment may be restored.

[0012] One or more embodiments terminate existing sessions through the bastion service that established the session. More specifically, the bastion service identifies sessions to be terminated based on information recorded during the session. This information may include details such as whether the session requester is a CSP operator and / or whether the session is a connection to a region in the customer cloud environment. Identified sessions are terminated by the bastion service. Termination of operator access may apply to some operators but not to others.

[0013] One or more embodiments reject new requests for credentials through a permission service configured to manage permissions. The permission service can also revoke existing credentials. Revocation of existing credentials for operator access may apply to some CSP operators but not others. Similarly, rejection of new requests for operator access may apply to some CSP operators but not others. The system can set a flag in a database accessible by one or both of (a) a bastion service configured to provision a bastion instance for which an existing session is established, or (b) a permission service configured to manage a set of permissions.

[0014] One or more embodiments described herein and / or recited in the claims may not be included in this "Overview" section.

[0015] 2. Examples of Cloud Environments One or more embodiments provide features associated with a cloud environment that includes a dedicated cloud environment or a private labeled cloud (PLC) environment. The cloud environment can be utilized, for example, by customers or tenants of a cloud infrastructure provider or reseller when accessing software products, services, or other cloud offerings.

[0016] Access can be provided to various complementary cloud-based components, such as software applications or services, that enable an organization or enterprise customer to operate its applications and services in a highly available host environment using a cloud computing environment or a cloud infrastructure environment.

[0017] The benefits of an organization migrating its application and service needs to a cloud infrastructure environment include reduced costs and complexity associated with designing, building, operating, and maintaining its own on-premises data centers, software application frameworks, or other information technology infrastructure.

[0018] Cloud infrastructure environment Figures 1 and 2 show a system that provides a cloud infrastructure environment according to one embodiment.

[0019] According to one embodiment, components and processes shown in Figure 1 and further described herein in relation to various embodiments may be provided as software or program code that can be executed by a computer system or other type of processing device, such as a cloud computing system.

[0020] The illustrated examples are provided for the purpose of illustrating a computing environment that can be used to provide a dedicated or private label cloud environment for use by cloud infrastructure tenants when accessing subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0021] As shown in Figure 1, according to one embodiment, the cloud infrastructure environment 100 can operate on a cloud computing infrastructure 102 comprising hardware (e.g., processors, memory), software resources, and one or more cloud interfaces 104 or other application program interfaces (APIs) that provide access to shared cloud resources via one or more load balancers A106, B108. The cloud interface 102 includes user interfaces and APIs provided by the cloud service provider for interacting with its cloud services. This includes tools and platforms that enable users and administrators to manage, configure, and monitor cloud resources and services. The cloud interface 102 may include a console, such as a web-based user interface that provides a visual way to interact with and manage cloud resources. Through the console, users can create, configure, and monitor cloud services such as compute instances, databases, storage, and network components. The cloud interface 102 may also include a command-line interface for users who prefer to work with the cloud infrastructure using command-line tools. In one embodiment, the CLI enables the scripting and automation of cloud management tasks.

[0022] In one embodiment, load balancers A106 and B108 are services that distribute incoming network traffic across multiple servers, instances, or other resources to ensure that no single resource bears an excessive burden of requests. By evenly distributing requests across multiple resources, load balancers improve the responsiveness and availability of resources such as applications, websites, or databases. Load balancers A106 and B108 can be either public load balancers accessible from the internet and used for distributing external traffic, or private load balancers used within a virtual cloud network (VCN) and not accessible from the public internet (and therefore ideal for distributing internal traffic). In one embodiment, load balancers A106 and B108 are designed to provide high availability and fault tolerance and are implemented in a redundant configuration spanning multiple availability domains or fault domains.

[0023] According to one embodiment, the cloud infrastructure environment supports the use of availability domains, for example, availability domain A180 and availability domain B182, which enable customers to create and access cloud networks 184, 186 and run cloud instances A192 and cloud instance B194. In one embodiment, availability domains A180 and B182 may represent data centers, or sets of data centers, located within a region. These availability domains may be isolated from each other, meaning they may not share the same physical infrastructure, such as power or cooling systems. This design provides high fault independence and robustness. In one embodiment, fault domains can provide additional protection and resilience within a single availability domain by grouping hardware and infrastructure within availability domains that are isolated from other fault domains. This isolation may relate to electricity, cooling, and other potential sources of failure.

[0024] In one embodiment, a tenancy (a container for resources used by a tenant) can be created for each cloud tenant / customer, for example, tenant A142, tenant B144, providing an isolated and secure partition within the cloud infrastructure environment where customers can create, organize, and manage their cloud resources. Cloud tenants / customers can access availability domains and cloud networks to access each of their cloud instances. Tenancies are isolated from other tenancies, ensuring that each customer's data and resources are secure and inaccessible to others. Within a tenancy, customers can create, manage, and organize a wide range of cloud resources, including compute instances, storage volumes, and networks. Identity and Access Management (IAM) services enable the management of users, groups, and policies within a tenancy. Through IAM, customers can control who has access to their resources and what actions they can perform. Tenancies are also the level where billing and subscription management are handled. Usage and costs associated with resources within a tenancy are tracked and billed collectively under that tenancy. Each tenancy may have associated service restrictions and allocations for various resources. These restrictions can be used to help manage capacity and facilitate the distribution of resources across tenants.

[0025] According to one embodiment, a computing device, for example, a client device 120 having device hardware 122 (e.g., a processor, memory) and a graphical user interface 126, may enable an administrator or other user to communicate with a cloud infrastructure environment via a network such as a wide area network, a local area network, or the internet in order to create or update cloud services.

[0026] According to one embodiment, the cloud infrastructure environment provides access to shared cloud resources 140, for example, via a compute resource layer 150, a network resource layer 160, and / or a storage resource layer 170. Customers can launch cloud instances as needed to meet their compute and application requirements. Once a customer provisions and launches a cloud instance, client devices, such as a client device 120, can access the provisioned cloud instance.

[0027] In one embodiment, compute resource 150 may comprise resources such as a bare metal cloud instance 152, a virtual machine 154, a graphics processing unit (GPU) compute cloud instance 156, and / or a container 158. A bare metal instance represents a physical server with dedicated hardware, all allocated to a single tenant. Bare metal instances provide direct access to the server's processor, memory, storage, and other hardware resources. A virtual machine (VM) is a software emulation of a physical computer that runs operating systems and applications like a physical computer. VMs allow multiple operating systems to run on a single physical machine or across multiple machines. A hypervisor layer exists between the hardware and the virtual machines, allocating physical resources (such as CPU, memory, and storage) to each VM. In one embodiment, a GPU compute cloud instance provides a GPU along with conventional CPU resources. These instances are designed for tasks requiring high parallel processing capabilities, making them ideal for applications such as machine learning, scientific computing, 3D rendering, and video processing. In one embodiment, container 158 uses a virtualization method that virtualizes the operating system to enable the execution of multiple isolated applications on a single control host. Each container shares the kernel of the host system but runs in an isolated user space, making the container lightweight and efficient.

[0028] The compute resource 150 components can be used to provision and manage bare-metal compute cloud instances or to provision cloud instances as needed to deploy and run applications, similar to an on-premises data center. For example, according to one embodiment, the cloud infrastructure environment can provide control of physical host (bare-metal) machines within the compute resource tier that run directly as compute cloud instances on bare-metal servers without the use of a hypervisor.

[0029] According to one embodiment, the cloud infrastructure environment can also provide control over virtual machines within the compute resource tier, which can be launched from, for example, an image, in which case the type and amount of resources available to the virtual machine cloud instance can be determined, for example, based on the image from which the virtual machine was launched.

[0030] In one embodiment, the network resource layer may comprise several network-related resources, such as a virtual cloud network (VCN) 162, a load balancer 164, edge services 166, and / or connectivity services 168. In one embodiment, the virtual cloud network (VCN) is a customizable private network in a cloud environment. The VCN provides a virtual version of a traditional network, including subnets, route tables, and gateways. This allows users to set up a cloud-based network architecture according to their requirements. In one embodiment, the edge services 166 include services and technologies designed to place compute, data storage, and network functions closer to where they are needed. The edge services 166 may be used to provide traffic optimization, reduced latency, or other benefits.

[0031] According to one embodiment, the storage resource layer may comprise several resources, for example, a data / block volume 172, file storage 174, object storage 176, and / or local storage 178. The data / block volume 172 provides unformatted block-level storage that can be used to create a file system that hosts a database or for other purposes that require unformatted storage. In one embodiment, the file storage 174 provides a file system and can provide a shared file system that can be accessed simultaneously by multiple instances using a standard file storage protocol. The object storage 176 manages data as objects in a storage bucket. An object has certain attributes, which may include data, metadata, and a unique identifier. The local storage 178 refers to a storage device physically attached to the host computer.

[0032] As shown in Figure 2, according to one embodiment, the cloud infrastructure environment may include various complementary cloud-based components, such as cloud infrastructure applications and services, which enable an organization or enterprise customer to operate its applications and services in a highly available hosted environment.

[0033] According to one embodiment, a self-contained cloud region can be provided as a complete, dedicated region within an organization's data center, for example, on Oracle Cloud Infrastructure (OCI), which gives the data center operator the agility, scalability, and economics of, for example, the OCI public cloud, while maintaining complete control over its data and applications to meet security, regulatory, or data residency requirements.

[0034] For example, according to one embodiment, such an environment may include racks physically and logically managed by a cloud infrastructure provider (e.g., Oracle), customer racks, access for cloud operators for setup and hardware support, power and cooling for the customer's data center, customer floor space, areas for customer data center personnel, and physical access cages.

[0035] In one embodiment, a dedicated region provides tenants / customers with the same set of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) products or services, such as ERP, Financials, HCM, and SCM, that are available within the public cloud region of a cloud infrastructure provider (e.g., Oracle). Customers can seamlessly lift and shift legacy workloads using the cloud infrastructure provider's services (e.g., bare metal compute, VMs, and GPUs), database services (e.g., Oracle Autonomous Database), or container-based services (e.g., Oracle Container Engine for Kubernetes).

[0036] According to one embodiment, a cloud infrastructure environment may operate according to an Infrastructure as a Service (IaaS) model, which enables the environment to provide virtualized computing resources over a public network (e.g., the Internet).

[0037] In the IaaS model, a cloud infrastructure provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer)). Additionally, the cloud infrastructure provider may offer various services associated with these infrastructure components, such as billing software, monitoring software, logging software, load balancing software, or clustering software. In this case, these services may be policy-driven, allowing IaaS users to implement policies that promote load balancing to maintain application availability and performance.

[0038] In one embodiment, an IaaS customer may access resources and services over a wide area network (WAN), such as the internet, and use the cloud infrastructure provider's services to install the rest of their application stack. For example, a user can log into an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and install enterprise software on those VMs. The customer can then use the provider's services to perform a variety of functions, including distributing network traffic, troubleshooting application issues, monitoring performance, or managing disaster recovery.

[0039] In one embodiment, the cloud infrastructure provider may be a third-party service specializing in providing IaaS (e.g., granting, renting, or selling), although this is not required. Alternatively, an entity may choose to deploy a private cloud and become its own provider of infrastructure services.

[0040] In one embodiment, IaaS deployment is the process of deploying a new application, or a new version of an application, onto a prepared application server. This may also include the process of preparing the server (e.g., installing libraries or daemons). This is often managed by the cloud infrastructure provider at a lower level than the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). In this case, the customer may be responsible for handling the deployment of the (OS), middleware, and / or application (e.g., on self-service virtual machines that can be spun up on demand).

[0041] In one embodiment, IaaS provisioning may refer to acquiring the computers or virtual hosts to be used and installing the necessary libraries or services on them. In most cases, provisioning is not included in the deployment, and provisioning may need to be performed first.

[0042] In one embodiment, the challenges of IaaS provisioning include the initial challenge of provisioning an initial set of infrastructure when nothing is operational. Secondly, after all provisioning is complete, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, or removing services). In some cases, these two challenges can be addressed by allowing the infrastructure configuration to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. In this case, the overall topology of the infrastructure (e.g., which resources depend on other resources and how they work together) can be described declaratively. In some cases, once the topology is defined, it is possible to generate workflows to create and / or manage the various components described in the configuration files.

[0043] In one embodiment, cloud infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as core networks (e.g., pools of configurable and / or shared computing resources, which may be on-demand). In some examples, there may also be one or more inbound / outbound traffic group rules provisioned to define how inbound and / or outbound network traffic for one or more virtual machines (VMs) will be set up. Other infrastructure elements, such as load balancers and databases, may also be provisioned. The infrastructure can evolve incrementally as more infrastructure elements are requested and / or added.

[0044] In one embodiment, continuous deployment techniques may be employed to enable the deployment of infrastructure code across various virtual computing environments. In addition, the techniques described may enable infrastructure management within these environments. In some examples, a service team may write code that is to be deployed to one or more, but often many, different production environments (e.g., across various geographical locations). However, in some examples, the infrastructure to which the code will be deployed needs to be provisioned. In some cases, provisioning can be done manually, using provisioning tools to provision resources and / or, once the infrastructure is provisioned, using deployment tools to deploy the code.

[0045] Figure 3 shows an example of a cloud infrastructure architecture according to an embodiment. As shown in Figure 3, according to one embodiment, the service operator 202 may be communicably coupled to a secure host tenancy 204 which may include a virtual cloud network (VCN) 206 and a secure host subnet 208.

[0046] In some examples, a service operator may use one or more client computing devices, which may be portable handheld devices (e.g., telephones, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., head-mounted displays) that run software such as Microsoft Windows and / or various mobile operating systems such as iOS and Android, and are compatible with the Internet, email, short message service (SMS), or other communication protocols. Alternatively, a client computing device may be a general-purpose personal computer, including personal computers and / or laptop computers that run various versions of operating systems such as Microsoft Windows®, Apple Macintosh®, and / or Linux®. A client computing device may be a workstation computer that runs one of various commercially available UNIX® or UNIX-like operating systems, including but not limited to various GNU / Linux operating systems such as Chrome OS. In addition, or alternatively, a client computing device may be any other electronic device that can communicate over a network accessible via a VCN and / or the Internet, such as a thin client computer, an internet-enabled gaming system (e.g., a Microsoft Xbox game console), and / or a personal messaging device.

[0047] According to one embodiment, the VCN may include a local peering gateway (LPG) 210 that can communicately connect to a Secure Shell (SSH) VCN 212 via an LPG included in the SSH VCN. The SSH VCN may include an SSH subnet 214, and the SSH VCN may communicately connect to a control plane VCN 216 via an LPG included in the control plane VCN. The SSH VCN may also communicately connect to a data plane VCN 218 via an LPG. The control plane VCN and data plane VCN may be included in a service tenancy 219 which may be owned and / or operated by a cloud infrastructure provider.

[0048] According to one embodiment, the control plane VCN may include a control plane buffer zone (DMZ) layer 220 that functions as a perimeter network (e.g., part of the corporate network between the corporate intranet and the external network). DMZ-based servers may have limited liability, which helps to mitigate potential breaches. In addition, the DMZ layer may include one or more load balancer (LB) subnets 222, a control plane application layer 224 which may include an application subnet 226, and a control plane data layer 228 which may include a database (DB) subnet 230 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnets included in the control plane DMZ layer may be communicatively coupled to the application subnets included in the control plane application layer and to an internet gateway 234 which may be included in the control plane VCN. The application subnets may be communicatively coupled to the DB subnets included in the control plane data layer, a service gateway 236, and a network address translation (NAT) gateway 238. The control plane VCN may include the service gateway and the NAT gateway.

[0049] According to one embodiment, the control plane VCN may include a data plane mirror application layer 240 which may include application subnets. The application subnets included in the data plane mirror application layer may include virtual network interface controllers (VNICs) on which compute instances can run. The compute instances can communicately connect the application subnets of the data plane mirror application layer to the application subnets that may be included in the data plane application layer.

[0050] According to one embodiment, a data plane VCN may include a data plane application layer, a data plane DMZ layer, and a data plane data layer. The data plane DMZ layer may include an LB subnet that can be communicatively coupled to the application subnet of the data plane application layer and the internet gateway of the data plane VCN. The application subnet may be communicatively coupled to the service gateway of the data plane VCN and the NAT gateway of the data plane VCN. The data plane data layer may also include a DB subnet that can be communicatively coupled to the application subnet of the data plane application layer.

[0051] According to one embodiment, the internet gateways of the control plane VCN and the data plane VCN may be communicatively coupled to a metadata management service 252 that is communicatively coupled to the public internet 254. The public internet may be communicatively coupled to the NAT gateways of the control plane VCN and the data plane VCN. The service gateways of the control plane VCN and the data plane VCN may be communicatively coupled to a cloud service 256.

[0052] According to one embodiment, a service gateway of a control plane VCN or a data plane VCN can make application programming interface (API) calls to a cloud service without traversing the public internet. API calls from the service gateway to the cloud service can be one-way; that is, the service gateway can make API calls to the cloud service, and the cloud service can send the requested data to the service gateway. Generally, the cloud service cannot initiate API calls to the service gateway.

[0053] In one embodiment, a secure host tenancy can be directly connected to a service tenancy, otherwise the service tenancy may be isolated. A secure host subnet can communicate with an SSH subnet via LPG, which may enable bidirectional communication on systems that are normally isolated. By connecting a secure host subnet to an SSH subnet, the secure host subnet may be able to access other entities within the service tenancy.

[0054] According to one embodiment, the control plane VCN may allow users of a service tenancy to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN can then be deployed or otherwise used in the data plane VCN. In some examples, the control plane VCN can be isolated from the data plane VCN, and the data plane mirror application layer of the control plane VCN can communicate with the data plane application layer of the data plane VCN via VNICs that may be included in the data plane mirror application layer and the data plane application layer.

[0055] According to one embodiment, a user or customer of the system can make requests via the public internet, for example, create, read, update, or delete (CRUD) operations, which can be transmitted to a metadata management service. The metadata management service can transmit requests to the control plane VCN through an internet gateway. Requests may be received by an LB subnet included in the control plane DMZ layer. The LB subnet can determine that the request is valid, and in response to this determination, the LB subnet can send the request to an application subnet included in the control plane application layer. If the request is confirmed to be valid and requires a call to the public internet, the LB subnet can send a call to the internet to a NAT gateway that can make a call to the internet. The metadata to be stored by the request may be stored in a DB subnet.

[0056] According to one embodiment, the data plane mirror application layer can facilitate direct communication between the control plane VCN and the data plane VCN. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN. The VNIC allows the control plane VCN to communicate directly with the resources contained in the data plane VCN, thereby enabling it to perform configuration changes, updates, or other appropriate modifications to those resources.

[0057] According to one embodiment, a control plane VCN and a data plane VCN can be included in the service tenancy. In this case, the system user or customer may not own or operate either the control plane VCN or the data plane VCN. Instead, the cloud infrastructure provider may own or operate the control plane VCN and the data plane VCN, and both can be included in the service tenancy. This embodiment can enable network isolation, which can prevent a user or customer from interacting with resources of other users or other customers. This embodiment can also enable a system user or customer to store databases privately without having to rely on the public internet for storage, which may not provide the desired level of threat prevention.

[0058] According to one embodiment, the LB subnet included in the control plane VCN may be configured to receive signals from the service gateway. In this embodiment, the control plane VCN and the data plane VCN may be configured to be invoked by the cloud infrastructure provider's customers without calling the public internet. A customer of the cloud infrastructure provider may desire this embodiment because the database used by the customer can be controlled by the cloud infrastructure provider and stored in a service tenancy that can be isolated from the public internet.

[0059] Figure 4 shows another example of a cloud infrastructure architecture according to one embodiment. As shown in Figure 4, according to one embodiment, the data plane VCN may be included in the customer tenancy 221. In this case, the cloud infrastructure provider may provide a control plane VCN for each customer, and the cloud infrastructure provider can set up a unique compute instance included in the service tenancy for each customer. Each compute instance may enable communication between the control plane VCN included in the service tenancy and the data plane VCN included in the customer tenancy. The compute instance may enable resources provisioned in the control plane VCN included in the service tenancy to be deployed or otherwise used in the data plane VCN included in the customer tenancy.

[0060] In one embodiment, a customer of a cloud infrastructure provider may have a database managed and operated within the customer tenancy. In this example, the control plane VCN may include a data plane mirror app tier that may contain app subnets. The data plane mirror app tier may reside in the data plane VCN, but may not be provided to the data plane VCN. That is, the data plane mirror app tier may be accessible to the customer tenancy, but may not reside in the data plane VCN, or may not be owned or operated by the customer. The data plane mirror app tier may be configured to make calls to the data plane VCN, but may not be configured to make calls to any entity included in the control plane VCN. The customer may want to deploy or otherwise use resources provisioned in the control plane VCN in the data plane VCN, and the data plane mirror app tier can facilitate the deployment or other use of the resources desired by the customer.

[0061] In one embodiment, a customer of a cloud infrastructure provider can apply filters to a data plane VCN. In this embodiment, the customer can determine what the data plane VCN can access and can restrict the data plane VCN's access to the public internet. It may not be possible for the cloud infrastructure provider to apply filters or otherwise control the data plane VCN's access to any external network or database. Applying customer filters and controls to data plane VCNs included in a customer tenancy can help isolate the data plane VCN from other customers and from the public internet.

[0062] According to one embodiment, a service gateway can invoke cloud services to access services that may not reside on the public internet, on a control plane VCN, or on a data plane VCN. The connection between the cloud services and the control plane VCN or data plane VCN may not be continuous. The cloud services may reside on different networks owned or operated by the cloud infrastructure provider. The cloud services may be configured to receive calls from the service gateway and not to receive calls from the public internet. Some cloud services may be isolated from other cloud services, and a control plane VCN may be isolated from cloud services that may not be in the same region as the control plane VCN.

[0063] For example, according to one embodiment, the control plane VCN may be located in "Region 1," and the cloud service "Deployment 1" may be located in both Region 1 and "Region 2." If a call to Deployment 1 is made by a service gateway included in the control plane VCN located in Region 1, the call may be sent to Deployment 1 in Region 1. In this example, the control plane VCN, or Deployment 1 in Region 1, may not be communicatively coupled to Deployment 1 in Region 2, or may not otherwise communicate with Deployment 1.

[0064] Figure 5 shows another example of a cloud infrastructure architecture according to one embodiment. As shown in Figure 5, according to one embodiment, a trusted application subnet 260 may be communicatively coupled to a service gateway included in the data plane VCN, a NAT gateway included in the data plane VCN, and a DB subnet included in the data plane data layer. An untrusted application subnet 264 may be communicatively coupled to a service gateway included in the data plane VCN and a DB subnet included in the data plane data layer. The data plane data layer may include a DB subnet that can be communicatively coupled to a service gateway included in the data plane VCN.

[0065] According to one embodiment, an untrusted application subnet may include one or more primary VNICs (1) to (N) that can be communicatively coupled to tenant virtual machines (VMs). Each tenant VM may be communicatively coupled to a corresponding application subnet 267(1) to (N) that may be included in a corresponding container output VCN 268(1) to (N) that may be included in a corresponding customer tenancy 270(1) to (N). A corresponding secondary VNIC may facilitate communication between the untrusted application subnet included in the data plane VCN and the application subnet included in the container output VCN. Each container output VCN may include a NAT gateway that can be communicatively coupled to the public internet.

[0066] According to one embodiment, the public internet can be communicatively coupled to NAT gateways included in the control plane VCN and NAT gateways included in the data plane VCN. Service gateways included in the control plane VCN and service gateways included in the data plane VCN can be communicatively coupled to cloud services.

[0067] In one embodiment, a data plane VCN can be integrated with a customer tenancy. This integration may be useful or desirable for a cloud infrastructure provider's customers in cases where additional support may be required during code execution. For example, a customer may provide code that could be executed, potentially be disruptive, communicate with other customer resources, or otherwise have undesirable consequences.

[0068] According to one embodiment, a customer of a cloud infrastructure provider can grant temporary network access to the cloud infrastructure provider and request functionality to be attached to the data plane application layer. The code for performing the functionality may run in a VM, and this code does not have to be configured to run elsewhere on the data plane VCN. Each VM may be connected to one customer tenancy. Corresponding containers (1) to (N) contained within the VM may be configured to run the code. In this case, a double isolation may exist (for example, the containers run the code, but these containers may be contained in a VM that is at least in an untrusted application subnet), which can help prevent improper or otherwise undesirable code from damaging the cloud infrastructure provider's network or the network of a different customer. The containers may be communicatively coupled to a customer tenancy and may be configured to send or receive data to or from the customer tenancy. The containers do not have to be configured to send or receive data to or from any other entity in the data plane VCN. Once the execution of the code is complete, the cloud infrastructure provider may decommission the containers.

[0069] In one embodiment, a trusted application subnet can execute code that may be owned or operated by the cloud infrastructure provider. In this embodiment, the trusted application subnet may be communicatively joined to a DB subnet and configured to perform CRUD operations in the DB subnet. An untrusted application subnet may be communicatively joined to a DB subnet and configured to perform read operations in the DB subnet. Containers that can be included in each customer's VM and execute code from the customer do not need to be communicatively joined to the DB subnet.

[0070] In one embodiment, the control plane VCN and the data plane VCN do not have to be directly coupled in a communicative manner, or there may be no direct communication between the control plane VCN and the data plane VCN. However, communication may occur indirectly, in which case the cloud infrastructure provider may establish an LPG that facilitates communication between the control plane VCN and the data plane VCN. In another example, the control plane VCN or the data plane VCN can make calls to cloud services via a service gateway. For example, a call from the control plane VCN to a cloud service may include a request for a service that can communicate with the data plane VCN.

[0071] Figure 6 shows another example of a cloud infrastructure architecture according to one embodiment. As shown in Figure 6, according to one embodiment, a trusted application subnet can be communicatively coupled to a service gateway included in the data plane VCN, a NAT gateway included in the data plane VCN, and a DB subnet included in the data plane data layer. An untrusted application subnet can be communicatively coupled to a service gateway included in the data plane VCN and a DB subnet included in the data plane data layer. The data plane data layer may include a DB subnet that can be communicatively coupled to a service gateway included in the data plane VCN.

[0072] According to one embodiment, an untrusted application subnet may include a primary VNIC that can be communicatively coupled to tenant virtual machines (VMs) residing within the untrusted application subnet. Each tenant VM can execute code in its corresponding container and may be communicatively coupled to an application subnet that may be included in the dataplane application layer, which may be included in the container output VCN280. Corresponding secondary VNICs 282(1)~(N) may facilitate communication between the untrusted application subnet included in the dataplane VCN and the application subnet included in the container output VCN. The container output VCN may include a NAT gateway that can be communicatively coupled to the public internet.

[0073] According to one embodiment, the Internet gateway included in the control plane VCN and the Internet gateway included in the data plane VCN may be communicatively coupled to a metadata management service that can communicate with the public internet. The public internet may be communicatively coupled to the NAT gateway included in the control plane VCN and the NAT gateway included in the data plane VCN. The service gateway included in the control plane VCN and the service gateway included in the data plane VCN may be communicatively coupled to a cloud service.

[0074] In one embodiment, the pattern shown in Figure 6 can be considered an exception to the pattern shown in Figure 5 and may be desirable for customers when the cloud infrastructure provider cannot communicate directly with the customer (e.g., in a region without connectivity). The corresponding containers contained within each customer's VM are accessible to the customer in real time. The containers may be configured to make calls to the corresponding secondary VNICs contained within the application subnet of the data plane application layer, which may be contained within the container output VCN. The secondary VNICs can then forward the calls to a NAT gateway that can send the calls to the public internet. In this example, the containers accessible to the customer in real time can be isolated from the control plane VCN and also from other entities contained within the data plane VCN. The containers can also be isolated from resources from other customers.

[0075] In another example, a customer can use a container to invoke a cloud service. In this example, the customer may execute code in a container that requests a specific service of the cloud service. The container can send this request to a secondary VNIC, which can then send the request to a NAT gateway, which can then send the request to the public internet. Using the public internet, the request can be sent via an internet gateway to an LB subnet included in the control plane VCN. In response to determining that the request is valid, the LB subnet can send the request to an application subnet that can send requests to the cloud service via a service gateway.

[0076] Please understand that the IaaS architecture depicted in the above diagram may have components other than those depicted. Furthermore, the embodiments shown in the diagram are just a few examples of cloud infrastructure systems that may incorporate embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown in the diagram, may combine two or more components, or may have different configurations or arrangements of components.

[0077] In one embodiment, the IaaS system described herein may include a suite of applications, middleware, and database service offerings, which are delivered to the customer in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner.

[0078] Private label cloud environment According to one embodiment, a cloud infrastructure environment can be used to provide a dedicated cloud environment, for example, as one or more private label cloud environments that tenants of the cloud infrastructure environment use to access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0079] Figure 7 illustrates how, in one embodiment, the system can provide a dedicated or private label cloud environment used by tenants or customers of a cloud infrastructure environment.

[0080] As shown in Figure 7, according to one embodiment, a cloud infrastructure provider (e.g., Oracle Cloud Infrastructure, OCI) can supply one or more private label cloud (PLC) environments to an OCI customer acting as a PLC operator 320, for example, a reseller. The PLC operator / reseller can then customize and extend the private label cloud used by its customer 330 so that it can be used to access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0081] For illustrative purposes, examples of such subscription-based products, services, or other offerings include various Oracle Cloud Infrastructure software products, Oracle Fusion Applications products, or other types of products or services that allow customers to register for use of such products or services.

[0082] Figure 8 further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment.

[0083] As shown in Figure 8, according to one embodiment, the system may include a cloud subscription service or component, referred to in some embodiments herein as the Oracle Cloud Subscriptions (OCS) service or component, which exposes one or more subscription management APIs for onboarding new customers or for creating orders used to create subscriptions and orchestrate billing and pricing services or other components used in PLC Realm 400.

[0084] According to one embodiment, when a PLC operator or its customer requests a PLC environment, the system creates a PLC realm used by one or more provider-owned tenancies. A realm is a logical collection of one or more cloud regions isolated from each other, and does not allow customer content to move across realm boundaries to regions outside of that realm. Each realm is accessed separately. PLC operators access cloud resources and services through cloud tenancies. A cloud tenancy is an isolated, secure partition of OCI and exists only within a single realm. Within this tenancy, operators can access services and deploy workloads across all regions within that realm, if policies permit it.

[0085] According to one embodiment, the first step in the process is to create an operator tenancy for the PLC operator before the realm and associated regions are handed over to the PLC operator for subsequent management. The PLC operator then becomes the administrator of this tenancy and can view and manage everything that happens within that realm, including their customer accounts and the use of cloud resources by those customers.

[0086] Generally, once the realm has been handed over or provided to the PLC operator, the cloud infrastructure provider will no longer be able to access the data within the operator's tenancy, unless the operator grants the cloud infrastructure provider permission to do so, for example, to provide troubleshooting for any problems that may arise.

[0087] According to one embodiment, the PLC operator can then create additional internal tenancies intended for its own internal use, for example, to determine what the end customer experience will be, to provide sales demo tenancies, or to operate databases for its own internal use. The operator can also create one or more customer tenancies where the end customer is the administrator. Cloud infrastructure usage metrics, such as compute usage, storage usage, and usage of other infrastructure resources, can be integrated by the operator to reflect both operator usage and customer usage. Cloud infrastructure usage may be reported to the cloud infrastructure provider.

[0088] According to one embodiment, a user interface or console may be provided that allows the PLC operator to manage customer accounts and customer-provided services. The cloud infrastructure provider may also install any necessary infrastructure services used by the operator and its customers using a cloud infrastructure tenancy, such as Fusion Applications tenancy.

[0089] Figure 9 further illustrates the use of a private label cloud realm by a tenant or customer of a cloud infrastructure environment, according to one embodiment.

[0090] As shown in Figure 9, according to one embodiment, an Oracle Cloud Subscriptions (OCS) service or component exposes one or more subscription management APIs for creating orders used to onboard new customers or to trigger workflows that create subscriptions and orchestrate billing and pricing services or other components.

[0091] According to one embodiment, the system may also include a billing service or component that operates on a billing account or a logical container of subscriptions and preferences used to generate invoices for customers.

[0092] In one embodiment, the system may also include a subscription pricing service (SPS) or component that operates on a product catalog defining products available for purchase by the customer. The subscription pricing service may also be used to provide a price list (e.g., rate cards) which is also owned by the pricing service.

[0093] In one embodiment, products can be selected from a product hub to support the sales process used to create subscriptions in the PLC realm. Once an order is created, a subscription is created in the OCS, which then manages the lifecycle of that subscription and provisions what needs to be provisioned to downstream services. The SPS component then manages the pricing and usage aspects used to bill the PLC operator for the final cost, or the aspect of the PLC operator's ability to bill its own customers. Usage events are forwarded to a billing service or component, where an invoice is created according to the subscription's billing preferences and pushed to the accounts receivable component.

[0094] In one embodiment, a service provided in a realm reports its usage to a metering service or component, but no price is associated with such usage. The rating process determines how much each particular event costs, for example by applying a rate card, determines the unit quantity and cost for that subscription, associates the cost with the record, and then transfers it to a billing service or component.

[0095] As further shown in Figure 9, according to one embodiment, a PLC operator can control multiple realms A, B, etc. For example, an operator operating in multiple countries may want to operate, for example, a data center completely isolated for the United States and a separate data center completely isolated for Europe, in order to address governance or regulatory requirements. According to one embodiment, the usage associated with these multiple realms can be aggregated for use in billing the operator.

[0096] The various system examples presented above are provided for the purpose of illustrating computing environments that can be used to provide a dedicated or private label cloud environment for use when cloud infrastructure tenants access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0097] Private Label Cloud Subscription Figure 10 shows a system, according to one embodiment, for providing access to software products or services in a cloud computing environment or other computing environment.

[0098] As shown in Figure 10, according to one embodiment, the system may be provided as a cloud computing environment or other computing environment, referred to herein as a platform in some embodiments, which supports the use of subscription-based products, services, or other offerings.

[0099] Examples of such subscription-based products, services, or other offerings include various Oracle Cloud Infrastructure (OCI) software products, Oracle Fusion Applications products, or other types of products or services that allow customers to register for use of such products or services.

[0100] According to one embodiment, a subscription may include artifacts such as products, commits, billing models, and state. The OCS service may expose one or more subscription management APIs for creating orders used to onboard new customers or to launch workflows that orchestrate the creation of subscriptions and the creation of appropriate footprints in billing and pricing services or components, as further described below.

[0101] According to one embodiment, a billing service or component operates on a billing account used to generate invoices, or on a logical container of subscriptions and preferences. Each billing account generates one or more invoices per billing cycle. The billing service includes a first pipeline that receives usage and costs from a metering service or component. Usage may be received through a REST API or another interface. The billing service writes usage to a database, from which deductions can be calculated and aggregated by the billing service or other services. The billing service may also include a second pipeline that takes aggregated usage and commitments and is responsible for calculating charges for one or more billing periods.

[0102] In one embodiment, a subscription pricing service (SPS) or component operates on a product catalog that defines the products available to the customer for purchase. The product catalog forms the framework of a price list (i.e., rate cards) also owned by the pricing service. Rate cards are modeled as pricing rules that are higher than public list prices. The pricing service maintains a single price list for each product. It is possible to add new product prices and modify existing ones. The price list has a complete history, and the most recent version is the current rate card. Since some contracts require taking a snapshot of the rate cards, the pricing service handles this by recording the time the customer's rate card was created and then querying the price list at that time.

[0103] In one embodiment, the SPS or pricing service is responsible for providing information on products, global price lists, and subscription-specific price lists and discounts for end customers. For example, in one embodiment, the SPS can synchronize product information from Oracle Fusion Product Hub with global price lists from Oracle Fusion Pricing Hub.

[0104] In one embodiment, the OCS service acts as an upstream service for receiving new order requests, for example, from an Oracle Fusion Order Management environment. The OCS service can provide subscription information to the SPS service. Subscription details such as the estimated timing, configuration, and subscription type (commitment, PayG) help the SPS determine the effective base price (rate card) for that subscription. The OCS service can also send subscription discounts received, for example, from Oracle Fusion Order Management, which the SPS stores as an entity in its pricing rules.

[0105] In one embodiment, the SPS service runs as a background process and manages a rate card service or component responsible for generating rate cards for new subscriptions and updating them when new price changes occur. The SPS service can expose APIs for accessing rate cards and pricing rules. A metering inline rating engine can use these APIs to retrieve subscription-specific rate cards and pricing rules that use this data for cost calculations.

[0106] In one embodiment, additional SPS components could include, for example, an integration component for the Oracle Integration Cloud (OIC) Pricing / Product Hub, which would allow PLC operator entities providing subscription-based products, services, or other offerings within the environment to manage their own product and pricing lists, such as those provided by Oracle Fusion Product Hub and Oracle Fusion Pricing Hub, respectively.

[0107] For example, according to such an embodiment, the SPS OIC product integration flow can listen for create / update events within the product hub and make calls to the SPS product API. Similarly, the SPS OIC pricing integration flow can retrieve new price list creations from the pricing hub and call the corresponding SPS pricing API.

[0108] In one embodiment, the system may also include an SPS core module that manages and provides an API for accessing pricing entities. Pricing can be accessed from internal services such as an inline rating engine.

[0109] In one embodiment, the system may also include a rate card manager component. The SPS service maintains a single base price for a product at a given point in time. However, the product price for a subscription depends on the base price at the time of quotation and the attributes of the subscription's price list change policy. The SPS service uses these properties to internally maintain the prices used for subscriptions. Such price lists are compiled into rate cards. The rate card manager is capable of creating and maintaining rate cards, as well as listening for price list changes and updating existing rate cards with the new prices. The rate card manager also listens for new subscriptions and assigns rate cards based on the subscription's properties.

[0110] In one embodiment, the system may also include a rule decoder engine. The SPS service is responsible for managing subscription pricing rules, including discounts presented to end customers. Eligibility for pricing rules can be based on product attributes, such as discount groups, product categories, or specific SKUs. Internally, the SPS needs to identify a list of products to which these rules apply. To achieve this, the rule decoder engine can compile pricing rules in a format that an inline rating engine can consume for cost calculation. This compilation process may be triggered when a product or pricing rule is created / updated.

[0111] As illustrated in Figure 10, according to one embodiment, in 441, product and pricing information, managed, for example in Fusion Applications, is sent to the SPS component. In 442, an order is sent to the OCS component, and a subscription, rate card, and billing account are created. In 443, pricing configurations and pricing rules are sent to the SPS for the new order. In 444, the OCS is used to set up a billing account for the billing service or component. In 445, the OCS publishes events to the OCI Streaming component. In 446, billing data is sent to the Accounts Receivable component, and an invoice is generated. In 447, the OCS consumes reclaim and subscription lifecycle (RASL) events from OCI Streaming. In 448, the activation service reads the event stream from the OCS. In 449, the customer retrieves activation data from the portal. In 450, the tenancy lifecycle service provisions the tenancy as part of the subscription activation. In 451, the tenancy lifecycle service creates the account footprint during account provisioning. In 452, the tenancy lifecycle service configures the limit template during account provisioning. In 453, the account component acts as a downstream RASL client to handle legacy reclamation. In 454, aggregated costs and usage are sent to the billing service or component. In 455, the organization can use the tenancy lifecycle service to create child tenancies. In 456, the metering service or component retrieves subscription mapping data. In 457, the subscription service retrieves organization data for subscription mapping. In 458, RASL reads the OCS event stream.In 459, the subscription service reads the OCS event stream, and in 460, the metering service or component retrieves rate card data for each subscription and can then use it when billing the PLC operator for the final cost, or in the function of the PLC operator billing its customers.

[0112] The above examples are provided for the purpose of illustrating a computing environment that can be used to provide a dedicated or private label cloud environment for use when a cloud infrastructure tenant accesses subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0113] 3. Access control architecture Figure 11 shows a system 1100 in one or more embodiments. As shown in Figure 11, the system 1100 includes a cloud infrastructure environment 1102, a customer operator interface 1104, and a CSP provider operator interface 1106. In one or more embodiments, the system 1100 may include more or fewer components than those shown in Figure 11. The components shown in Figure 11 may be local or remote from one another. The components shown in Figure 11 may be implemented in software and / or hardware. Components can be distributed across multiple applications and / or machines. Multiple components may be combined into a single application and / or machine. Another component may perform the operation described for one component instead.

[0114] In one or more embodiments, the cloud infrastructure environment 1102 refers to hardware, software, networking, and storage components that enable the provision of cloud computing services. The cloud infrastructure environment 1102 further includes hardware and / or software configured to perform the operations described herein for controlling operator access to the cloud resources of the cloud infrastructure environment 1102. An example of an operation for controlling operator access to the cloud resources of the cloud infrastructure environment 1102 is described below with reference to Figure 12.

[0115] In one embodiment, the cloud infrastructure environment 1102 is implemented on one or more digital devices. The term “digital device” generally refers to any hardware device including a processor. A digital device may refer to a physical device on which an application or virtual machine runs. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, specific-function hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address converters (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile devices, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations, communication management devices, routers, switches, controllers, access points, and / or client devices.

[0116] In one or more embodiments, the cloud infrastructure environment 1102 is a cloud computing infrastructure provided by a first entity, e.g., a CSP, to a second entity, e.g., the CSP's customer. The CSP's customer provides cloud services to a third entity, e.g., an organization or enterprise. The CSP develops and provides the cloud infrastructure technologies that power the cloud infrastructure environment 1102. The CSP's customer owns and deploys the cloud infrastructure environment 1102. A customer operator, i.e., an operator associated with the CSP's customer, is responsible for managing the cloud infrastructure environment 1102, including providing Level 1 and Level 2 support. Level 1 support is the first point of contact with the user or customer and provides basic troubleshooting and assistance for common issues. Level 2 support may include handling higher-level support tickets, conducting deeper analysis and troubleshooting of technical issues, performing root cause analysis to identify underlying problems, providing advanced technical guidance and solutions, and higher levels of support or collaboration with expert teams for complex issues requiring further expertise. Higher levels of support are provided by the CSP operator. The CSP operator maintains and updates the core functionality of the cloud infrastructure environment 1102, ensuring that the security and up-to-dateness of the cloud infrastructure environment 1102 with new features are maintained.

[0117] In one or more embodiments, the cloud infrastructure environment 1102 is organized into multiple cloud regions. The cloud regions are isolated from each other. A logical set of one or more cloud regions is called a realm. Realms are accessed individually. Customers in a region cannot move across the boundaries of that realm to a region outside of that realm.

[0118] In one or more embodiments, the cloud region of the cloud infrastructure environment 1102 includes isolated regions, such as Oracle Cloud Isolated Regions (OCIRs) or Oracle Cloud National Security Regions (NSRs). Isolated regions are isolated, highly secure environments within the cloud infrastructure environment that address the needs of customers with stringent security and compliance requirements. Isolated regions are designed to provide even higher levels of isolation, control, and regulatory compliance for more sensitive workloads, as well as in highly regulated industries such as government, finance, healthcare, and defense.

[0119] In one or more embodiments, the cloud infrastructure environment 1102 includes an infrastructure service 1108, a bastion service 1110, an authorization service 1112, and a data repository 1114.

[0120] In one or more embodiments, the infrastructure services 1108 of the cloud infrastructure environment 1102 include resources that enable the delivery, management, and operation of cloud-based solutions. The infrastructure services 1108 include a wide range of services, including (a) compute services, e.g., virtual machines, containers; (b) storage services, e.g., object storage, block storage; (c) networking services, e.g., virtual networks, load balancing; (d) database services, e.g., relational databases, NoSQL databases; (e) identity and access management, e.g., authorization, authentication; (f) monitoring and logging, e.g., metrics monitoring, logging, and auditing; and / or (g) security services, e.g., firewalls, encryption.

[0121] In several embodiments, the infrastructure service 1108 includes an abuse service, a fraud service, a security service, and a compliance service. The abuse service or abuse management service addresses and mitigates various forms of abuse or misuse of cloud resources and services. Abuse may include a variety of acts, such as spamming, phishing, malware distribution, denial-of-service (DoS) attacks, unauthorized access, or any act that violates the CSP's terms of service or permitted use policies. The fraud service or fraud detection service detects, prevents, and mitigates fraudulent activities occurring within the cloud infrastructure or related to cloud-based services. Fraudulent activities may include unauthorized access, data breaches, identity theft, financial fraud, and other forms of malicious behavior aimed at misusing cloud resources or damaging cloud-based systems. The security service protects cloud-based resources, applications, and data from a variety of security threats and vulnerabilities. The security service can mitigate risks, enforce security policies, and maintain compliance with regulatory requirements. Compliance services ensure adherence to regulatory requirements, industry standards, and internal policies related to data protection, privacy, security, and governance.

[0122] In one or more embodiments, the infrastructure service 1108 is performed by an operator performing a range of operator actions 1116. Operator actions 1116 may include actions for provisioning and configuration, monitoring and alerting, scaling and optimization, backup and disaster recovery, security management, patch management and updates, incident response and troubleshooting, compliance and governance, and performance optimization.

[0123] In one or more embodiments, the operator actions 1116 available to an operator vary depending on the entity to which the operator belongs, the service to which the operator belongs, and the operator's level. For example, an operator associated with a CSP customer may not have access to the same operator actions as an operator associated with the CSP. Similarly, a CSP operator associated with a compliance service may not have access to the same operator actions as a CSP operator associated with a fraud service. The authorization service 1112 of the cloud infrastructure environment 1102 manages operator access to the operator actions 1116.

[0124] In one or more embodiments, the bastion service 1110 refers to a service that provides secure access to infrastructure services 1108 and other resources within the cloud infrastructure environment 1102. The bastion service 1110 creates a bastion instance 1118 through which authorized users establish secure connections to resources within the cloud infrastructure environment 1102.

[0125] In one or more embodiments, the bastion instance 1118, also known as the bastion host or jump host, is a dedicated server deployed within the network to provide secure access to the cloud infrastructure environment 1102. The bastion instance 1118 acts as a gateway for operators, such as CSP operators, to access and manage other systems not directly exposed to the public internet, such as virtual machines (VMs), servers, or databases. The bastion instance 1118 acts as a single entry point for accessing resources within the private network. The bastion instance is deployed with strict security measures in place to prevent unauthorized access and protect sensitive data. The bastion instance implements strong authentication mechanisms, such as multi-factor authentication (MFA) and key-based authentication, to verify the user's identity before granting access to internal resources. The bastion instance may implement role-based access control (RBAC) to ensure that operator access is restricted to resources that the operator is authorized to manage. The bastion instance may be deployed within a separate subnet or network segment, isolated from the rest of the cloud infrastructure environment 1102. Isolating the Bastion instance minimizes the attack surface and reduces the risk of unauthorized access to internal systems.

[0126] In one or more embodiments, communication between the operator's client device and the bastion instance, and between the bastion instance and internal resources, is encrypted to protect the confidentiality and integrity of data transmitted over the network. The bastion instance 1118 can generate detailed logs of user activity and access attempts to provide a comprehensive audit trail for monitoring and compliance purposes. Logs created by the bastion instance can be analyzed to identify security incidents, attempted unauthorized access, or policy violations. The bastion instance 1118 can grant temporary access to a user or administrator for a specific period, after which access is automatically revoked. The bastion instance may be deployed in a redundant configuration with a failover mechanism to ensure continuous availability and uninterrupted access to internal resources in the event of hardware or software failure.

[0127] In one or more embodiments, the authorization service 1112 is a system and component responsible for managing access control and authorization for operators, applications, and resources within the cloud infrastructure environment 1102. The authorization service 1112 ensures that authorized users or entities have an appropriate level of access to cloud resources, data, and functionality. The authorization service 1112 may include Identity and Access Management (IAM), Access Control Lists (ACLs), Key Management Services (KMS), API authorization and authentication, and Network Security Groups (NSGs).

[0128] In one or more embodiments, an IAM service manages user identity, access rights, and permissions for accessing cloud services and resources. The IAM service includes a variety of functions, such as user authentication, authorization, user provisioning and deprovisioning, role-based access control, multi-factor authentication, and centralized policy management. The IAM service enables organizations to define and enforce granular access control based on roles, groups, or individual operators, ensuring that access to specific resources or the execution of certain actions is restricted to authorized operators.

[0129] In one or more embodiments, an IAM service provides just-in-time (JIT) credentials. JIT credentials are access credentials, such as usernames and passwords, API keys, or temporary tokens, that are dynamically generated and provided to the user or system on demand immediately before the credentials are needed. JIT credentials are short-lived and valid for a limited period or for a specific use case. JIT credentials offer on-demand generation, short-term validity, scoped access, dynamic revocation, auditing, and logging. When an operator requests access to a resource or service, the IAM system dynamically generates a set of credentials specifically for that request. These credentials are created just-in-time and are not stored or predefined. JIT credentials are designed to be temporary and have a limited lifespan. JIT credentials may only be valid for a short period, such as minutes or hours, to minimize the risk of exposure and misuse. JIT credentials can be scoped to specific resources, services, or operations. JIT credentials can provide access to the resources or actions necessary to fulfill an immediate request and do not grant overly broad permissions. When the allocated time period or use case expires, JIT credentials are automatically revoked or invalidated by the IAM system. The creation and use of JIT credentials are logged and audited by the authorization service 1112 to provide visibility into who accessed which resources and when.

[0130] In one or more embodiments, ACLs are used to define and enforce resource-level access control policies, such as for storage buckets, virtual machines, or databases. ACLs specify which users or entities are allowed to access a particular resource and which actions those users or entities are allowed to perform (e.g., read, write, execute). KMS services manage cryptographic keys used to encrypt and decrypt data in a cloud environment. KMS services control access to cryptographic keys through access policies and allow organizations to determine who can manage and use cryptographic keys to protect sensitive data.

[0131] In one or more embodiments, APIs provide programmatic access to resources and functionalities. API authorization and authentication services manage access to these APIs and ensure that interactions with cloud resources via the APIs are restricted to authorized applications or services. API authorization and authentication services can secure API access using standards such as OAuth 2.0 or JSON Web Tokens. Network Security Groups (NSGs) are used to define and enforce network-level access control within the cloud environment. NSGs specify rules that control inbound and outbound traffic to cloud resources based on source and destination IP addresses, ports, and protocols.

[0132] In one or more embodiments, the data repository 1114 is any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, or any other storage mechanism). Furthermore, the data repository 1114 may include multiple different storage units and / or devices. These multiple different storage units and / or devices may or may not be of the same type, or may or may not be located at the same physical site. Furthermore, the data repository 1114 may be implemented or run on the same computing system as the cloud infrastructure environment 1102. In addition, or alternatively, the data repository 1114 may be implemented or run on a computing system separate from the cloud infrastructure environment 1102. The data repository 1114 may be communicably coupled to the cloud infrastructure environment 1102 via a direct connection or via a network.

[0133] Information describing the cloud infrastructure environment 1102 can be implemented across any component within system 1100. However, for clarity and explanatory purposes, this information is presented in the data repository 1114. The data repository 1114 may include operator credentials 1120, algorithms 1122, access policies 1124, authorization databases 1126, session information 1128, and disabling configurations 1130.

[0134] In one or more embodiments, operator credentials 1120 refers to information used to authenticate and verify the identity of a user or entity accessing a system, service, or resource. Operator credentials 1120 are used to prove the identity of an operator, device, or application and to determine whether the operator, device, or application is authorized to access a particular resource or perform a certain action. Operator credentials 1120 may include JIT credentials generated by the IAM of the authorization service 1112.

[0135] In one or more embodiments, the operator credentials 1120 include a username and password, an API key, a certificate, an access token, and a Secure Shell (SSH) key. A combination of a unique identifier (username) and a secret passphrase (password) may be used to authenticate a user and grant access to a system, application, or online account. An alphanumeric string or token may be issued to an application or service to authenticate the operator's identity and grant access to an API or web service. A certificate authority may issue a digital certificate to authenticate the identity of a user, device, or server in an cryptographic manner. Certificates are commonly used in HTTPS (HTTP over SSL / TLS) connections, VPNs (Virtual Private Networks), and digital signatures. After successful authentication, a token may be issued to the user or application, allowing the operator to access a resource or service for a limited period of time. A public-private key pair may be used for secure authentication and communication between systems using SSH.

[0136] In one or more embodiments, the operator credentials 1120 include biometric data, a one-time password (OTP), and a session token. Physiological or behavioral characteristics, such as fingerprints, iris scans, facial recognition, or voice patterns, can be used to verify an individual's identity through a biometric authentication system. For authentication purposes, a temporary code can be generated and sent to the operator's device (e.g., a mobile phone). OTPs are typically valid for one use or for a short period and are commonly used in two-factor authentication (2FA) or multi-factor authentication (MFA) systems. After successful authentication, a token can be generated and assigned to the operator to maintain the authenticated session and authorize subsequent requests within a limited timeframe.

[0137] In one or more embodiments, the machine learning algorithm 1122 is a repeatable algorithm for training a target model f that best maps a set of input variables to output variables. The machine learning algorithm is a repeatable algorithm for training a target model f that best maps a set of input variables to output variables using a set of training data. The training data includes a dataset and associated labels. The dataset is associated with the input variables of the target model f. The associated labels are associated with the output variables of the target model f. The training data may be updated, for example, based on feedback to predictions made by the target model f and the current accuracy of the target model f. The updated training data is fed back to the machine learning algorithm, and the machine learning algorithm updates the target model f.

[0138] The machine learning algorithm 1122 generates a target model f such that the target model f best fits the training data dataset to the labels of the training data. In addition, or alternatively, the machine learning algorithm 1122 generates a target model f such that, when the target model f is applied to the training data dataset, the maximum number of results determined by the target model f matches the labels of the training data. Different target models can be generated based on different machine learning algorithms and / or different sets of training data.

[0139] Machine learning algorithms can include supervised and / or unsupervised components. A variety of algorithms can be used, including linear regression, logistic regression, linear discriminant analysis, classification and regression trees, naive Bayes, k-nearest neighbors, learning vector quantization, support vector machines, bagging and random forests, boosting, backpropagation, and / or clustering.

[0140] In one or more embodiments, the access policy 1124 defines rules and permissions that govern who can access which resources and what actions they are permitted to perform within the cloud infrastructure environment 1102. Access policies are essential for enforcing security, compliance, and governance requirements. Access policies can specify users, groups, roles, or service accounts that are permitted to access specific cloud resources. Access policies can define permissions granted to users or entities to interact with specific cloud resources. Access policies can enable fine-grained permission control, allowing organizations to specify high-granularity access based on individual resources, attributes, or conditions. Access policies can include conditions that must be met in order to grant access, such as requiring multi-factor authentication (MFA), originating from a specific network location, or using a specific client device.

[0141] In one or more embodiments, the authorization database 1126 is a centralized repository for permission, access control, and authorization settings for various resources within the cloud infrastructure environment 1102. The authorization database 1126 may be used by the bastion service 1110 and the authorization service 1112 to enforce security policies, manage user access, and ensure compliance with regulatory requirements. The authorization database 1126 can store information about users, groups, roles, and their associated permissions for accessing specific resources or performing certain actions. The authorization information may include various details such as user identity, resource identifier, granted permissions (e.g., read, write, delete), and any conditions or restrictions associated with the permissions. The database provides a centralized location for managing access control and authorization policies across the cloud infrastructure environment 1102. The authorization database 1126 may include audit logs and records of access activity to track changes in permissions, monitor user access, and demonstrate compliance with regulatory requirements. Audit logs provide visibility into who accessed which resources, when that access occurred, and what actions were taken, which is useful for investigating security incidents and conducting compliance audits.

[0142] In one or more embodiments, session information 1128 refers to data associated with a user's interaction with the cloud infrastructure environment 1102 over a specific period of time, known as a session. Session information 1128 may be recorded by the bastion service 1110. Session information 1128 may include various data elements that provide context about the operator's session and activities. Session information may include a session ID, user identity, authentication status, session start and end times, session duration, client information, session state, access permissions, activity logs, and security context.

[0143] In one or more embodiments, a unique identifier can be assigned to a session, which can then be used to associate subsequent requests and interactions with the same session. Session information may include information about the operator associated with the session, such as a username, user ID, or other user attributes. Session information may indicate whether the user was successfully authenticated for that session, i.e., authenticated by credentials or an authentication token. In addition to timestamps indicating when the session started and ended, session information may also include the length of time the session remained active, measured in seconds, minutes, or hours.

[0144] In one or more embodiments, session information 1128 includes details about the client device or application used to access the system, such as an IP address, user agent string, device type, and browser version. Session information may include any data or variables associated with the session that maintain the state of the user's interactions and activities within the system, such as form data, preferences, or other session-specific information. Session information may include information about the operator's permissions and privileges within the cloud infrastructure environment 1102, including roles, permissions, and authorization tokens. Session information may include records of actions performed by the operator during the session, such as operator actions, form submissions, and other interactions. Session information may include security-related information about the session, such as security tokens, encryption keys, and security policies applied to protect the session and its data.

[0145] In one or more embodiments, the disabling configuration 1130 is a predetermined list of configurations for restricting one or more operators' access to one or more resources within the cloud infrastructure environment 1102. The disabling configuration 1130 may relate to operator types, such as customer operators, CSP operators, and administrators. The disabling configuration 1130 may relate to specific services and / or specific operator actions within those services. The disabling configuration 1130 may also relate to the length of time operator access is disabled.

[0146] In one or more embodiments, the customer operator interface 1104 refers to hardware and / or software configured to facilitate communication between the customer operator and the cloud infrastructure environment 1102. The customer operator interface 1104 renders user interface elements and receives input through these user interface elements. Examples of interfaces include graphical user interfaces (GUIs), command line interfaces (CLIs), haptic interfaces, and voice command interfaces. Examples of user interface elements include checkboxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0147] In one embodiment, different components of the customer operator interface 1104 are specified in different languages. The behavior of user interface elements is specified in a dynamic programming language such as JavaScript®. The content of user interface elements is specified in a markup language such as Hypertext Markup Language (HTML) or XML User Interface Language (XUL). The layout of user interface elements is specified in a stylesheet language such as Cascading Style Sheets (CSS). Alternatively, the customer operator interface 1104 is specified in one or more other languages ​​such as Java®, C, or C++.

[0148] In one or more embodiments, the customer operator interface 1104 includes an infrastructure dashboard 1132. The infrastructure dashboard 1132 includes a disable element or interface 1134 for initiating a disable command to disable operator access to the cloud infrastructure environment 1102. The disable element 1134 may include a button or other icon that can be activated by a customer operator or administrator. The disable element 1134 may include various elements for configuring a disable command. For example, the disable element may include interface elements for selecting an action that will be initiated when the disable element is activated, i.e., terminating an existing session, revoking credentials, denying a request for new credentials, etc. The disable element may include one or more interface elements for selecting the type of operator from whom the service will be disabled, i.e., a CSP operator, a customer operator. The interface elements may include individual operators. The disable element 1134 may include one or more interface elements for selecting the type of service that will be disabled when the disable element 1134 is activated. The disable element 1134 may include an operator action 1116 that will be disabled when the disable element 1134 is activated. The disable interface 1134 may include one or more interface elements for selecting a time period during which the disable command remains active.

[0149] In one or more embodiments, the disable element 1134 or the infrastructure dashboard 1132 may include a visual display of the remaining time for the disable command. The disable command may automatically reverse to its pre-execution state at the end of the specified time. Alternatively, a customer operator or administrator may revert the disable command to its pre-execution state by activating the disable element 1134 again.

[0150] In one or more embodiments, the CSP operator interface 1106 refers to hardware and / or software configured to facilitate communication between the CSP operator and the cloud infrastructure environment 1102. The CSP operator interface 1106 renders user interface elements and receives input through these user interface elements. Examples of interfaces include graphical user interfaces (GUIs), command line interfaces (CLIs), haptic interfaces, and voice command interfaces. Examples of user interface elements include checkboxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0151] In one embodiment, different components of the CSP operator interface 1106 are specified in different languages. The behavior of user interface elements is specified in a dynamic programming language such as JavaScript. The content of user interface elements is specified in a markup language such as Hypertext Markup Language (HTML) or XML User Interface Language (XUL). The layout of user interface elements is specified in a stylesheet language such as Cascading Style Sheets (CSS). Alternatively, the CSP provider interface 1106 is specified in one or more other languages ​​such as Java, C, or C++.

[0152] 4. Controlling operator access to cloud resources Figure 12 shows an example of a set of actions for controlling operator access to a customer cloud infrastructure environment, according to one or more embodiments. One or more of the actions shown in Figure 12 may be modified, rearranged, or omitted. Therefore, the particular sequence of actions shown in Figure 12 should not be interpreted as limiting the scope of one or more embodiments.

[0153] One or more embodiments receive requests from an operator, e.g., a CSP operator, to access resources within a customer cloud environment (operation 1202). The operator initiates the access request through a designated access management channel. The designated access channel may include a service desk, ticket management system, self-service portal, or access request form. When submitting an access request, the provider may specify access through a bastion service. Displaying the type of access requested may be done through checkboxes, drop-down menus, or other selection mechanisms provided in the operator access request interface. In addition to providing authentication credentials, the operator may specify the type of access they are requesting. The type of access may include the resources the operator is trying to access, e.g., services, operator actions, etc. Alternatively, the authorized services may include a default set of services and / or operator actions for specific types of operators and / or for specific operators.

[0154] In several embodiments, the operator submits an authentication request to the authorization service. The request may include authentication credentials, such as a username / password pair, an API key, or a token. The authorization service verifies the validity of the credentials provided in the authentication request to ensure that the credentials are valid and that authentication is authorized. Authentication may include verifying the operator's identity against a pre-approved directory of operators, verifying the authenticity and validity of a provided token, or checking the validity of an API key.

[0155] One or more embodiments determine whether an operator meets the requirements for accessing resources within a customer cloud environment (operation 1204). When an operator makes a request for access to the cloud infrastructure environment, the authorization service reviews the request. Using the authorization database, the authorization service verifies the legitimacy of the request, ensures that the access request complies with security policies and access controls, and assesses any associated risks.

[0156] One or more embodiments deny a request for access (operation 1206). If the authorization service determines that it cannot authenticate the user and / or that the operator is not authorized to access the resource the operator is requesting, the operator is denied access.

[0157] One or more embodiments grant operator access to resources within the customer cloud environment (operation 1208). The access request is approved if the authorization service can authenticate the user and verify authorization to the requested resources. The authorization service provisions the necessary permissions through the bastion service. This may include configuring user accounts, setting up authentication mechanisms, and granting privileges to access the requested resources via the bastion host. Once access is provisioned through the bastion service, the operator is notified that the access request has been approved. The operator can receive instructions on how to securely connect to the bastion host and access the requested resources within the customer cloud environment.

[0158] In one or more embodiments, an operator connects to the bastion service using a secure remote access protocol such as Secure Shell (SSH) or Remote Desktop Protocol (RDP) and authenticates themselves using their credentials. The bastion service provisions one or more sets of bastion instances. Operator sessions are established through the bastion instances. The bastion service can record information associated with sessions established through the bastion instances. Recorded information may include the type of operator requesting access, e.g., a CSP operator or a customer operator, and / or whether the session is a connection to a specific region of the customer cloud environment.

[0159] In some embodiments, after successful authentication, the authorization service performs an authorization check to determine whether the operator is authorized to establish the requested session. Authorization includes evaluating the operator's permissions, roles, and access policies to determine whether the operator has the necessary privileges to access the requested resource or perform the requested action.

[0160] One or more embodiments receive a command to disable operator access to resources in the customer cloud environment (operation 1210). A command to disable CSP operator access may be received in response to a customer operator clicking on a feature in the customer dashboard interface. Alternatively, the command may be received as an API call made by the customer operator.

[0161] In one or more embodiments, an operator, such as an administrator or an operator on the customer's security team, interacts with a dashboard provided by the CSP. This dashboard may be part of an administration console or administration portal. The customer operator navigates the dashboard interface and selects specific resources or permissions associated with operator access that should be disabled. This may include specifying the type of resources affected, in addition to selecting individual operators, roles, or groups. Alternatively, the categories of affected operators and resources may be predetermined or determined using a machine learning algorithm. The customer operator triggers a command to disable operator access by clicking an icon, button, or menu option within the dashboard interface. This action signals an intention to change permissions and initiates the process of sending commands to the bastion service and / or permission service.

[0162] In one or more embodiments, the disable interface is provided as a large red button on the dashboard. The size, position, and color of the large red button are made conspicuous to facilitate easy identification. The disable interface may include additional interfaces for customizing the disable command, such as buttons or pull-down menus. Customization may include selecting several operators and several actions without affecting other operators and actions. When the disable command is activated, a countdown clock or other visual element may be displayed to indicate the length of time until the system returns to its state before the disable command is executed. The length of time may be extended up to a maximum length, such as 30 minutes, 2 hours, or 6 hours. Alternatively, the disable command may remain activated until a customer operator or administrator deactivates it. A customer operator can deactivate the disable command by activating the large red button again.

[0163] In one or more embodiments, the bastion service and / or authorization service receives commands from a dashboard interface. Receiving commands may involve a combination of front-end web technologies (such as JavaScript) that handle user interactions and back-end server-side components that process and execute commands. The service verifies the authenticity and authorization of the command. Authenticity verification and authorization include verifying the validity of the customer or administrator identity, verifying the operator's authorization or role, and ensuring that the requested action conforms to applicable policies, authorizations, and compliance requirements. Once the command is authorized and verified as valid, the service takes the necessary actions to disable operator access to specific resources in the cloud infrastructure environment. Disabling operator access may include lag time as the action to disable operator access propagates within the system.

[0164] In one or more embodiments, actions to disable operator access may include updating access control settings, revoking authentication tokens or credentials, and / or modifying permissions or roles associated with the affected resources. This may include placing a flag or other notation in the permissions database for the affected operators and / or resources. The dashboard interface provides customer operators with feedback indicating that the command to disable operator access has been successfully processed. Confirmation may include visual indicators that inform customer operators of the outcome of the action, such as a change in interface color, a status message, or a notification within the dashboard interface. Interface features may visually display a countdown to show when the disable command will expire.

[0165] In one or more embodiments, the Bastion service and / or authorization service logs details of command execution for auditing and compliance purposes. The recorded information may include the customer operator or administrator who initiated the command, the affected resources, the execution time, and any relevant metadata associated with the action.

[0166] In one or more embodiments, a command to disable operator access is initiated through an API call. A client application or system can send an API request to a cloud infrastructure API endpoint specifying the details of a command to disable operator access. The request may include various parameters, such as the type of resource to be affected, the specific operator or role whose access should be disabled, and any other relevant information. The API request is authenticated and authorized by a cloud infrastructure API gateway or authentication service. This includes verifying the validity of the credentials provided in the request (such as an API key, OAuth token, or client certificate), and checking the permissions or roles associated with the customer operator to ensure that the customer operator has the necessary authority to execute the command. The API endpoint receives the request and verifies the validity of the request's contents to ensure that the request conforms to the API's schema and specifications. Validation of the request may include checking the requested parameters, data types, and other validation rules to prevent errors or misuse of the API.

[0167] In several embodiments, once a request to disable operator access is authenticated, authorized, and its validity verified, the API endpoint executes a command to disable operator access to a specified resource within the customer's cloud environment. This may include calling a service or workflow responsible for updating access control configurations, revoking authentication tokens or credentials, and enforcing access restrictions. After executing the command, the API endpoint sends a response back to the client application or system that initiated the API call. This response indicates the result of the command execution, including whether the command execution was successful or whether any errors occurred during processing. The response may also include additional details or metadata related to the actions taken. By initiating commands through API calls, users can programmatically manage and automate access control actions, such as disabling operator access to resources, within the customer's cloud environment.

[0168] In response to receiving a command, one or more embodiments terminate an existing session that provides CSP operator access to resources in the customer cloud environment (operation 1212). The Bastion Service terminates existing sessions established through the Bastion instance by actively managing and controlling access to the Bastion instance. More specifically, the Bastion Service identifies active sessions currently established through the Bastion instance. This may include querying logs, monitoring network traffic, or referring to a session management database. The Bastion Service receives requests or triggers to terminate specific sessions. These requests may come from customer operators or administrators, security systems, or may be automatically triggered based on predefined policies or rules. The Bastion Service may initiate the termination of those sessions by sending a terminate command or signal to the Bastion instance hosting the identified sessions. This may include disconnecting network connections, forcibly terminating processes, or forcibly logging out operators. Once a session is terminated, the Bastion Service confirms the success of the termination and logs this event for auditing and compliance purposes. This includes recording details such as the operator associated with the completed session, the completion time, and any related metadata.

[0169] In one or more embodiments, the Bastion service notifies the affected operator that their session has been terminated. This notification may include the reason for the termination and any instructions or next steps for re-establishing access. The notification may be displayed as a banner on the operator's user interface. The notification may include an estimated length of the access suspension.

[0170] In one or more embodiments, the bastion service verifies that a terminated session is no longer active and that access has been effectively revoked. The bastion service may perform additional cleanup tasks, such as deleting session metadata or updating session management records to reflect the termination. The bastion service enforces access policies to prevent unauthorized re-establishment of terminated sessions. This may include implementing access control, authentication mechanisms, or session timeout policies to ensure that access to the bastion instance and the establishment of new sessions are restricted to authorized users.

[0171] In response to receiving a command, one or more embodiments reject a new request for credentials to establish a session that provides CSP operator access to resources in the customer cloud environment (operation 1214). Instead of, or in addition to, terminating an existing session, the authorization service may reject a new request for credentials. When a command to disable operator access to resources in the customer cloud environment is executed, a flag or notation is added to the list of pre-authorized operators to identify the operators affected by the disable command. When a request for credentials is received by the authorization service, the authorization service refers to the list of pre-authorized operators and denies the credentials to the flagged operators on the list. The disable command may be limited to individual operators, groups or classes of operators, or all operators. Operators can be distinguished by the entities to which they are associated and / or the resources to which they are authorized to access.

[0172] In response to receiving a command, one or more embodiments revoke existing credentials used to establish a session providing CSP operator access to resources within the customer cloud environment (operation 1216). Existing credentials used to establish a session can be revoked by the authorization service. The authorization service identifies the credentials to be revoked. This may include authentication tokens, session identifiers, API keys, or other forms of credentials used to establish a session. The authorization service receives a request or trigger indicating that the credentials should be revoked. This may be initiated by a customer operator or administrator in response to a security incident or based on a predefined policy or rule. The authorization service updates the authentication store or database to mark the identified credentials as revoked. This may include setting a flag or status indicating that the credentials are no longer valid for authentication or access. The authorization service ensures that the revocation status is propagated to relevant components and services that utilize the credentials for authentication or access control. This may include updating caches, databases, or distributed systems to reflect the change in the credential status.

[0173] In one or more embodiments, the authorization service notifies the operator whose credentials have been revoked, informing the operator of this change and providing guidance on the next steps. The guidance provided to the operator may relate to re-authentication, obtaining new credentials, or seeking assistance from support. The authorization service may enforce the revocation by rejecting any subsequent authentication attempts or access requests using the revoked credentials. This prevents the operator or entity from continuing to use the invalidated credentials to establish a session or access resources. The authorization service may periodically review and clean up revoked credentials to ensure that the authentication store is up-to-date and free of expired or unnecessary entries, thereby maintaining the integrity and efficiency of the authentication and access control system.

[0174] One or more embodiments allow a CSP operator to access resources in the customer cloud environment by reverting to a pre-execution state one or more of the following: terminating an existing session, rejecting new requests for credentials, or revoking existing credentials (operation 1218). Once a specified time period for disabling operator access has elapsed, or the customer operator releases the disable access command, the operation for disabling operator access is reverted to its pre-execution state. This may include re-establishing terminated sessions, allowing new requests for credentials, and reinstating revoked credentials. The authorization database may be updated by removing any flags that were placed when the disable command was invoked.

[0175] 5. Examples of Embodiments For clarity, detailed examples are provided below. The components and / or operations described below should be understood as one specific example, and may not be applicable to certain embodiments. Therefore, the components and / or operations described below should not be construed as limiting the scope of any of the claims.

[0176] Figure 13 shows a dashboard provided to operators and administrators associated with a cloud service provider's customers. As shown, the security monitoring dashboard 1300 provides customer operators and administrators with information related to the infrastructure security of the customer's cloud infrastructure environment. More specifically, the dashboard 1300 includes interfaces for providing security notifications 1302 and security support tickets 1304. The dashboard 1300 further provides an access disable button 1306. Activating the access disable button 1306 disables operator access to the customer's cloud infrastructure environment. Although shown as a simple button, the access disable button 1306 may include interface elements for selecting which operator access should be disabled and to which resources.

[0177] 6. Practical applications, benefits, and improvements By enabling cloud service provider customers to disable operator access to their cloud infrastructure environment, customers can respond quickly to security incidents or potential threats, thereby limiting the attack surface and reducing the risk of unauthorized access. The ability to disable or suspend operator access to the customer's cloud infrastructure environment allows customers to meet regulatory compliance requirements and ensure compliance with data protection and privacy regulations.

[0178] In the event of a security breach or suspicious activity, the ability to disable operator access gives customers time to investigate the cause of the breach or activity and prevent further damage or data loss. Disabling or suspending operator access can also reduce the risk of insider threats, human error, or fraudulent activity that could compromise the integrity, confidentiality, or availability of cloud resources.

[0179] 7. Other developments Unless otherwise defined, all terms (including technical and scientific terms) are given their ordinary, conventional meanings to those skilled in the art, and are not limited to any special or customized meanings unless expressly defined herein.

[0180] This application may include references to a trademark. While the use of a trademark is permitted in a patent application, the nature of a trademark as a proprietary property should be respected, and every effort should be made to prevent any use in any form that could adversely affect its validity as a trademark.

[0181] The embodiments are directed to a system comprising one or more devices, each including a hardware processor and configured to perform any of the operations described herein and / or in any of the following claims.

[0182] In one embodiment, one or more non-temporary computer-readable storage media include instructions that cause one or more hardware processors to perform any of the operations described herein and / or any of the claims.

[0183] In one embodiment, the method includes an operation described herein and / or described in any of the claims, and the method is performed by at least one device including a hardware processor.

[0184] Any combination of the features and functionalities described herein may be used according to one or more embodiments. The embodiments have been described with reference to numerous specific details, which may vary from implementation to implementation. This specification and the drawings should therefore be considered in an illustrative rather than restrictive sense. The scope of this disclosure, and the sole and exclusive indicator of what the applicants intend to be the scope of this disclosure, is the literal and equivalent scope of the set of claims issued from this application, in the specific form in which such claims are issued, including any subsequent amendments.

Claims

1. When executed by one or more hardware processors, the system includes instructions that cause an operation to be performed, and the operation is: This includes receiving a command from a customer operator associated with a Cloud Service Provider (CSP) customer to disable CSP operator access to a first set of resources within the customer cloud environment, CSP operator access to the first set of resources within the customer cloud environment is granted based on a set of permissions, and the operation further, In response to the command, the process includes terminating, rejecting, or canceling one or more of the following: The termination described above involves terminating one or more existing sessions that provide CSP operator access to the first set of resources within the customer cloud environment, wherein the one or more existing sessions are established at least in part based on the set of permissions. The rejection means rejecting one or more new requests that seek credentials to establish a session that provides CSP operator access to the first set of resources in the customer cloud environment, and that such new requests seeking credentials are based at least in part on the set of permissions. The revocation is to revoke existing credentials used to establish a session providing CSP operator access to the first set of resources within the customer cloud environment, one or more non-temporary computer-readable media that are authorized at least in part based on the set of permissions.

2. Terminating the existing session is performed by a bustion service configured to provision a set of bustion instances on which the existing session is established, the bustion service records the information associated with the existing session and generates recorded information, the recorded information is, (a) Whether the requester of the session is a CSP operator, (b) whether the session is a connection to the customer cloud environment, including at least one of the above, The Bastion service identifies the existing session that should be terminated based on the recorded information, The aforementioned bustion service terminates the identified session. One or more non-temporary computer-readable media according to claim 1.

3. The rejection of one or more new requests seeking the aforementioned credentials is performed by a licensing service configured to manage the set of licenses, one or more non-temporary computer-readable media according to claim 1.

4. The revocation of the existing credentials is performed by a licensing service configured to manage the set of licenses, one or more non-temporary computer-readable media according to claim 1.

5. The aforementioned command requests that CSP operator access to all resources within the customer cloud environment be disabled, and the following: (a) Terminate all existing sessions, (b) Reject all new requests for credentials, (c) One or more non-temporary computer-readable media according to claim 1, wherein one or more of the following are performed: (c) revoking all existing credentials.

6. The aforementioned command requests that CSP operator access to a subset of resources within the customer cloud environment be disabled, as follows: (a) Terminate a subset of existing sessions corresponding to the subset of the resource, (b) Rejecting a subset of new requests seeking credentials corresponding to a subset of the said resources, (c) One or more non-temporary computer-readable media according to claim 1, wherein one or more of the following are performed: (c) revoking a subset of existing credentials corresponding to a subset of the resources.

7. The command is associated with a specified time period, and the operation occurs after the end of the specified time period. (a) Terminate the existing session, (b) Refusing to grant the new request for the aforementioned credentials, (c) One or more non-temporary computer-readable media according to claim 1, further comprising reversing one or more of the existing credentials to a state prior to execution.

8. The command sets a flag in a database accessible by one or more of the following: (a) a bustion service configured to provision a set of bustion instances on which the existing session is established; or (b) an authorization service configured to manage the set of authorizations.

9. One or more non-temporary computer-readable media according to claim 1, wherein terminating CSP operator access to a first set of resources does not terminate CSP operator access to a second set of resources in the customer cloud environment.

10. The termination of CSP operator access applies to the first CSP operator but does not terminate access for the second CSP operator, according to claim 1, one or more non-temporary computer-readable media.

11. The CSP is a first entity, the customer of the CSP is a second entity, and the customer of the CSP provides cloud services to end users associated with a third entity, according to one or more non-temporary computer-readable media according to claim 1.

12. The command to disable the access of the CSP operator is an application programming interface call made in response to user input provided by the customer operator, one or more non-temporary computer-readable media according to claim 1.

13. A method comprising the operation described in any one of claims 1 to 12.

14. A system comprising means for performing the operation described in any one of claims 1 to 12.

15. It is a system, A device comprising at least one hardware processor, The system is configured to perform the operation described in any one of claims 1 to 12.

Images