Controlling operator access to customer cloud infrastructure environment

Abstract

Techniques are disclosed for enabling a customer operator of a cloud service provider (CSP) to disable operator access to resources in a customer cloud environment. The operator of the CSP customer may initiate a disable command to disable or suspend operator access. Disabling operator access includes: (a) terminating an existing session providing access to a resource to an operator; (b) denying a new request for credentials for establishing a session providing operator access; and / or (c) revoking existing credentials for establishing a session providing operator access. Disabling operator access may be applied to resources or a subset of resources in a customer cloud environment, and / or may be applied to some operators, but not other operators. The operators may be the same or different categories of operators. And after the specified time period ends, the capability of accessing the client cloud environment of the operator can be recovered.

Description

[0001] Priority claims; related applications; incorporation by reference

[0002] This application claims the priority of U.S. non-provisional patent application 18 / 649,783, filed April 29, 2024, and U.S. provisional patent application 63 / 462,880, filed April 28, 2023, which are incorporated herein by reference.

[0003] The applicant hereby withdraws any disclaimer of the scope of claims in one or more parent applications or their examination history, and informs the United States Patent and Trademark Office (USPTO) that the claims in this application may be more extensive than any claims in one or more parent applications. Technical Field

[0004] This disclosure relates to cloud environments. In particular, this disclosure relates to restricting cloud service provider (CSP) operators' access to the cloud infrastructure environment of CSP customers. Background Technology

[0005] Cloud computing environments can be used to provide access to a range of complementary cloud-based components, such as software applications or services, enabling organizations or enterprise customers to operate their applications and services in a highly available managed environment.

[0006] The benefits of organizations moving their application and service needs to the cloud include reduced costs and complexity in designing, building, operating, and maintaining their own on-premises data centers, software application frameworks, or other IT infrastructure.

[0007] Maintaining and supporting the infrastructure and security of a customer's cloud environment requires access to a set of operator actions. The customer operator (i.e., the operator associated with the CSP's customer) performs a subset of these actions to support certain categories of the customer's cloud environment, such as Level 1 support and Level 2 support. Deeper technical issues are handled by the CSP operator (i.e., the operator associated with the CSP) using another subset of actions that are not available to the customer operator.

[0008] The methods described in this section are possible methods, but not necessarily methods that have been previously conceived or adopted. Therefore, unless otherwise indicated, no method described in this section should be assumed to qualify as prior art simply because it is included in this section. Attached Figure Description

[0009] In the accompanying drawings, embodiments are illustrated by way of example rather than limitation. It should be noted that references to "a" or "an" embodiment in this disclosure do not necessarily refer to the same embodiment, and they mean at least one. In the drawings:

[0010] Figure 1 The illustration depicts a system for providing a cloud infrastructure environment according to an embodiment.

[0011] Figure 2 The illustration further illustrates how a cloud infrastructure environment can be used to provide cloud-based applications or services according to embodiments.

[0012] Figure 3 The illustration shows an example cloud infrastructure architecture according to an embodiment.

[0013] Figure 4 The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0014] Figure 5 The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0015] Figure 6 The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0016] Figure 7 The illustration shows how a system according to an embodiment can provide a dedicated or private tagged cloud environment for use by tenants or customers of a cloud infrastructure environment.

[0017] Figure 8 The illustration further illustrates the use of a private tag cloud domain for tenants or customers in a cloud infrastructure environment, according to an embodiment.

[0018] Figure 9 The illustration further illustrates the use of a private tag cloud domain for tenants or customers in a cloud infrastructure environment, according to an embodiment.

[0019] Figure 10 The illustration depicts a system according to an embodiment for providing access to software products or services in a cloud computing or other computing environment.

[0020] Figure 11 The illustration depicts a system for controlling operator access to resources within a customer cloud environment, according to one or more embodiments.

[0021] Figure 12 The illustration depicts a set of example operations for controlling operator access to resources within a customer's cloud environment, according to one or more embodiments; and

[0022] Figure 13 An example of a customer-facing infrastructure security dashboard is illustrated according to one or more embodiments. Detailed Implementation

[0023] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described in the form of block diagrams to avoid unnecessarily obscuring this disclosure.

[0024] 1. General Overview

[0025] 2. Example Cloud Environment

[0026] 3. Access Control Architecture

[0027] 4. Control operator access to cloud resources

[0028] 5. Example Implementation

[0029] 6. Practical applications, advantages, and improvements

[0030] 7. Other matters; extension

[0031] 1. General Overview

[0032] One or more embodiments enable a cloud service provider's (CSP) customer operator to disable operator access to resources in a customer's cloud environment. Operator access to resources in a customer's cloud environment can be disabled or suspended by issuing a disable command. Disabling operator access includes (a) terminating an existing session that provides the operator with access to the resource, (b) rejecting new requests for credentials used to establish a session that provides operator access, and / or (c) revoking existing credentials used to establish a session that provides operator access. Disabling operator access can apply to all resources or a subset of resources in the customer's cloud environment. Similarly, disabling operator access can apply to some operators but not others. Operators can be, for example, the same or different categories of operators associated with the CSP or with a customer of the CSP. Operator access can be disabled for a specified period of time. At the end of the specified period, the operator's ability to access the customer's cloud environment can be restored.

[0033] One or more embodiments terminate existing sessions via a 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 connected to a region within the customer's cloud environment. The identified session is terminated by the bastion service. Operator-access termination may apply to some operators but not others.

[0034] One or more embodiments deny new requests for credentials through a permissions service configured to manage permissions. The permissions service can also revoke existing credentials. Revoking existing credentials used for operator access may apply to some CSP operators but not others. Similarly, denying new requests for operator access may apply to some CSP operators but not others. The system can set a flag in a database that can be accessed by one or both of: (a) a bastion service configured to supply bastion instances that establish existing sessions through it, or (b) a permissions service configured to manage a set of permissions.

[0035] One or more embodiments described in this specification and / or recited in the claims may not be included in this general overview section.

[0036] 2. Example Cloud Environment

[0037] One or more embodiments provide features associated with a cloud environment, including a private cloud or private tag cloud (PLC) environment. For example, customers or tenants of a cloud infrastructure provider or reseller can leverage the cloud environment to access software products, services, or other cloud offers.

[0038] Cloud computing or cloud infrastructure environments can be used to provide access to a range of complementary cloud-based components, such as software applications or services, enabling organizations or enterprise customers to operate their applications and services in a highly available managed environment.

[0039] The benefits of organizations moving their application and service needs to a cloud infrastructure environment include reduced costs and complexity in designing, building, operating, and maintaining their own on-premises data centers, software application frameworks, or other IT infrastructure.

[0040] cloud infrastructure environment

[0041] Figure 1 and Figure 2 The illustration depicts a system for providing a cloud infrastructure environment according to an embodiment.

[0042] According to an embodiment, Figure 1 The components and processes shown herein, as well as those further described herein with respect to various embodiments, may be provided as software or program code executable by a computer system or other type of processing device (e.g., a cloud computing system).

[0043] The illustrated examples are provided to illustrate computing environments that can be used to provide dedicated or privately tagged cloud environments for tenants of cloud infrastructure to use when accessing subscription-based software products, services, or other provisioning items 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.

[0044] like Figure 1 As shown, according to an embodiment, cloud infrastructure environment 100 can operate on cloud computing infrastructure 102, which includes hardware (e.g., processors, memory), software resources, and one or more cloud interfaces 104 or other application programming interfaces (APIs) that provide access to shared cloud resources via one or more load balancers A 106, B 108. Cloud interface 102 includes user interfaces and APIs provided by cloud service providers for interacting with their cloud services. This includes tools and platforms that allow users and administrators to manage, configure, and monitor cloud resources and services. 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, for example, create, configure, and monitor cloud services such as compute instances, databases, storage devices, and networking components. Cloud interface 102 may also include a command-line interface for users who prefer to operate the cloud infrastructure using command-line tools. In this embodiment, the CLI allows for scripting and automating cloud management tasks.

[0045] According to embodiments, load balancers A 106 and B 108 are services that distribute incoming network traffic across multiple servers, instances, or other resources to ensure that no single resource is overwhelmed by excessive demand. By distributing requests evenly across resources, load balancers enhance the responsiveness and availability of resources such as applications, websites, or databases. Load balancers A 106 and B 108 can be public load balancers accessible from the Internet and used for distributing external traffic, or they can be private load balancers used within a Virtual Cloud Network (VCN) and not accessible from the public Internet (and therefore well-suited for internal traffic distribution). In embodiments, load balancers A 106 and B 108 are designed for high availability and fault tolerance and are implemented in a redundant configuration across multiple availability or fault domains.

[0046] According to an embodiment, the cloud infrastructure environment supports the use of availability domains (such as availability domain A 180 and availability domain B 182), which enable customers to create and access cloud networks 184 and 186, and run cloud instances A 192 and B 194. In this embodiment, availability domain A 180 and availability domain B 182 may represent data centers, or a group 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 a high degree of fault independence and robustness. In this embodiment, a fault domain can provide additional protection and resilience within a single availability domain by grouping hardware and infrastructure into availability domains isolated from other fault domains. This isolation may involve power, cooling, and other potential sources of failure.

[0047] According to an embodiment, a lease (a container of resources used by the tenant) can be created for each cloud tenant / customer (e.g., tenant A 142 and tenant B 144). This lease provides a secure and isolated 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. Leases are isolated from other leases, ensuring that each customer's data and resources are secure and inaccessible to other customers. Within a lease, customers can create, manage, and organize various 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 lease. Through IAM, customers can control who has access to their resources and what actions they can perform. Leases also represent a level of disposal billing and subscription management. Usage and costs associated with resources within a lease are uniformly tracked and billed under that lease. Each lease can be associated with specific service limits and quotas for various resources. These limits can be used to help manage capacity and facilitate resource allocation among each tenant.

[0048] According to an embodiment, a computing device (such as a client device 120 having device hardware 122 (e.g., a processor, memory) and a graphical user interface 126) can enable administrators or other users to communicate with a cloud infrastructure environment via a network (such as a wide area network, a local area network, or the Internet) to create or update cloud services.

[0049] According to an embodiment, the cloud infrastructure environment provides access to the shared cloud resource 140 via, for example, 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 computing and application requirements. After a customer has provisioned and launched a cloud instance, the provisioned cloud instance can be accessed from a client device (such as client device 120).

[0050] According to an embodiment, computing resources 150 may include resources such as bare-metal cloud instances 152, virtual machines 154, graphics processing unit (GPU) computing cloud instances 156, and / or containers 158. A bare-metal instance represents a physical server with dedicated hardware that is fully allocated to a single tenant. Bare-metal instances provide direct access to the server's processor, memory, storage devices, and other hardware resources. A virtual machine (VM) is a software emulation of a physical computer that runs an operating system and applications like a physical computer. VMs allow multiple operating systems to run on a single physical machine or across multiple physical machines. A hypervisor layer sits between the hardware and the VMs, thereby allocating physical resources (such as CPU, memory, and storage devices) to each VM. In an embodiment, GPU computing cloud instances provide GPUs as well as traditional CPU resources. These instances are designed for tasks requiring high levels of parallel processing power, making them well-suited for applications such as machine learning, scientific computing, 3D rendering, and video processing. In an embodiment, container 158 uses a virtualization approach that allows multiple isolated applications to run on a single controlling host, thereby virtualizing the operating system. Each container shares the host system's kernel but runs in an isolated user space, making the containers lightweight and efficient.

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

[0052] According to an embodiment, the cloud infrastructure environment can also provide control over virtual machines within the computing resource layer, which can be launched from, for example, an image, wherein the type and quantity of resources available to the virtual machine cloud instance can be determined, for example, based on the image from which the virtual machine is launched.

[0053] According to an embodiment, the network resource layer may include several network-related resources, such as a Virtual Cloud Network (VCN) 162, a load balancer 164, an edge service 166, and / or a connectivity service 168. In this embodiment, the Virtual Cloud Network (VCN) is a customizable and private network in a cloud environment. The VCN provides a virtual version of a traditional network, including subnets, routing tables, and gateways. It allows users to set up a cloud-based network architecture according to their requirements. In this embodiment, the edge service 166 includes services and technologies designed to bring computing, data storage, and networking capabilities closer to the desired location. The edge service 166 can be used to optimize traffic, reduce latency, or provide other advantages.

[0054] According to embodiments, the storage resource layer may include several resources, such as data / block volume 172, file storage device 174, object storage device 176, and / or local storage device 178. Data / block volume 172 provides unformatted block-level storage, which can be used to create a file system for a managed database or for other purposes requiring unformatted storage. File storage device 174 provides a file system in embodiments and can provide a shared file system that can be accessed simultaneously by multiple instances using standard file storage protocols. Object storage device 176 manages data as objects within buckets. Objects have certain attributes, which may include data, metadata, and unique identifiers. Local storage device 178 refers to a storage device physically attached to a host computer.

[0055] like Figure 2 As shown, according to an embodiment, the cloud infrastructure environment may include a series of complementary cloud-based components, such as cloud infrastructure applications and services 200, which enable organizations or enterprise customers to operate their applications and services in a highly available managed environment.

[0056] According to an embodiment, a self-contained cloud region can be provided as a dedicated area of ​​Oracle Cloud Infrastructure (OCI) within an organization's data center, which provides data center operators with the flexibility, scalability, and cost-effectiveness of, for example, the OCI public cloud, while retaining full control over its data and applications to meet security, regulatory, or data residency requirements.

[0057] For example, according to an embodiment, such an environment may include racks physically and logically managed by a cloud infrastructure provider (e.g., Oracle), customer racks, access rights for cloud operators to configure and support hardware, customer data center power and cooling, customer footprint, customer data center personnel area, and physical access cages.

[0058] According to an embodiment, a dedicated zone 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, finance, HCM, and SCM, available in the public cloud regions of a cloud infrastructure provider (e.g., Oracle). Customers can seamlessly extract and replace legacy workloads using services from the cloud infrastructure provider (e.g., bare metal computing, VMs, and GPUs), database services (e.g., Oracle Autonomous Database), or container-based services (e.g., Oracle Kubernetes Container Engine).

[0059] According to an embodiment, a cloud infrastructure environment can 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).

[0060] In the IaaS model, cloud infrastructure providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, cloud infrastructure providers can also supply various services to complement these infrastructure components; example services include billing software, monitoring software, logging software, load balancing software, or clustering software. Therefore, because these services can be policy-driven, IaaS users can implement policies to drive load balancing, thereby maintaining application availability and performance.

[0061] According to the implementation, IaaS customers can access resources and services via a wide area network (WAN) such as the Internet, and can use the cloud infrastructure provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create buckets for workloads and backups, and install enterprise software into that VM. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application problems, monitoring performance, or managing disaster recovery.

[0062] According to the embodiments, cloud infrastructure providers may, but are not necessarily, third-party services that exclusively provide (e.g., provision, lease, or sell) IaaS. Entities may also choose to deploy private clouds, thereby becoming their own infrastructure service providers.

[0063] According to an embodiment, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the processing of a preparation server (e.g., an installation library or daemon). This is typically managed by the cloud infrastructure provider, below the hypervisor layer (e.g., servers, storage devices, network hardware, and virtualization). Therefore, the customer can be responsible for disposal (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

[0064] According to embodiments, IaaS provisioning may refer to acquiring computers or virtual hosts for use and installing necessary libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0065] According to embodiments, the challenges of IaaS provisioning include: the initial challenge of provisioning an initial set of infrastructure before anything is operational; and the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, or removing services) once everything is provisioned. In some cases, these two challenges can be addressed by enabling configuration that declaratively defines the infrastructure. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more profiles. Therefore, 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, workflows for creating and / or managing the different components described in the profiles can be generated.

[0066] According to embodiments, cloud infrastructure can have many interconnected elements. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as the core network. In some examples, one or more inbound / outbound traffic group rules may also be provided to define how inbound / outbound traffic will be set up for one or more virtual machines (VMs) in the network. Other infrastructure elements, such as load balancers, databases, etc., may also be provided. The infrastructure can evolve incrementally as more and / or more infrastructure elements are expected and added.

[0067] According to embodiments, continuous deployment techniques can be employed to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques enable infrastructure management within these environments. In some examples, service teams may write code that is intended to be deployed to one or more, but typically many, different production environments (e.g., across various geographical locations). However, in some examples, the infrastructure for deploying the code needs to be provisioned. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, the code can be deployed using deployment tools.

[0068] Figure 3 The illustration shows an example cloud infrastructure architecture according to an embodiment.

[0069] like Figure 3 As shown, according to an embodiment, service operator 202 can communicatively couple to secure host lease 204, which may include virtual cloud network (VCN) 206 and secure host subnet 208.

[0070] In some examples, service operators 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), running software such as Microsoft Windows and / or various mobile operating systems (e.g., iOS, Android, etc.), and supporting the Internet, email, short message service (SMS), or other communication protocols. Alternatively, client computing devices may be general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. Client computing devices may be workstation computers running various commercially available UNIX® or UNIX-like operating systems, including but not limited to any of the various GNU / Linux operating systems (such as Chrome OS). Additionally or alternatively, client computing devices may be any other electronic device, such as thin client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles), and / or personal messaging devices capable of communicating over networks with access to VCNs and / or the Internet.

[0071] According to an embodiment, the VCN may include a local peering gateway (LPG) 210, which may be communicatively coupled 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 be communicatively coupled to a control plane VCN 216 via an LPG included in the control plane VCN. Furthermore, the SSH VCN may be communicatively coupled to a data plane VCN 218 via an LPG. The control plane VCN and the data plane VCN may be contained in a service lease 219 that may be owned and / or operated by a cloud infrastructure provider.

[0072] According to an embodiment, the control plane VCN may include a control plane demilitarized zone (DMZ) layer 220 that acts as a peripheral network (e.g., part of an enterprise network between an internal and external network). DMZ-based servers may have limited responsibility to help contain potential vulnerabilities. Furthermore, the DMZ layer may include one or more load balancer (LB) subnets 222, a control plane application layer 224 that may include an application subnet 226, and a control plane data layer 228 that may include database (DB) subnets 230 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). One or more LB subnets included in the control plane DMZ layer may communicatively couple to one or more application subnets included in the control plane application layer and an Internet gateway 234 that may be included in the control plane VCN. One or more application subnets may communicatively couple to one or more DB subnets, a service gateway 236, and a Network Address Translation (NAT) gateway 238 included in the control plane data layer. The control plane VCN may include a service gateway and a NAT gateway.

[0073] According to an embodiment, the control plane VCN may include a data plane mirror application layer 240, which may include one or more application subnets. The one or more application subnets included in the data plane mirror application layer may include a virtual network interface controller (VNIC) capable of executing compute instances. The compute instances may communicatively couple the one or more application subnets of the data plane mirror application layer to the one or more application subnets that may be included in the data plane application layer.

[0074] According to an embodiment, the 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 one or more LB subnets communicatively coupled to one or more application subnets of the data plane application layer and the internet gateway of the data plane VCN. The one or more application subnets may be communicatively coupled to the service gateway and NAT gateway of the data plane VCN. The data plane data layer may also include one or more DB subnets communicatively coupled to one or more application subnets of the data plane application layer.

[0075] According to an embodiment, the internet gateways of the control plane VCN and the data plane VCN can be communicatively coupled to a metadata management service 252, which can be communicatively coupled to a public internet 254. The public internet can be communicatively coupled to a NAT gateway of the control plane VCN and the data plane VCN. The service gateways of the control plane VCN and the data plane VCN can be communicatively coupled to a cloud service 256.

[0076] According to an embodiment, the service gateway of the control plane VCN or data plane VCN can make application programming interface (API) calls to cloud services without traversing the public internet. API calls from the service gateway to the cloud service can be unidirectional; the service gateway can make API calls to the cloud service, and the cloud service can send requested data to the service gateway. Generally, the cloud service cannot initiate API calls to the service gateway.

[0077] According to one embodiment, a secure host lease can be directly connected to a service lease that might otherwise be isolated. A secure host subnet can communicate with an SSH subnet via an LPG, which enables bidirectional communication between otherwise isolated systems. Connecting a secure host subnet to an SSH subnet allows the secure host subnet to access other entities within the service lease.

[0078] According to embodiments, a control plane VCN can allow users of a service lease to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN can 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, which can be included in both the data plane mirror application layer and the data plane application layer.

[0079] According to an embodiment, users or clients of the system can make requests, such as create, read, update, or delete (CRUD) operations, via the public internet that can transmit requests to the metadata management service. The metadata management service can transmit the request to the control plane VCN via an internet gateway. The request can be received by one or more LB subnets contained in the control plane DMZ layer. The one or more LB subnets can determine that the request is valid, and in response to this determination, the one or more LB subnets can transmit the request to one or more application subnets contained in the control plane application layer. If the request is verified and requires a call to the public internet, the call to the internet can be transmitted to a NAT gateway that can make the call to the internet. The metadata to be stored by the request can be stored in one or more DB subnets.

[0080] According to an embodiment, the data plane mirroring 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 suitable modifications to resources contained in the data plane VCN. With the help of the VNIC, the control plane VCN can communicate directly with the resources contained in the data plane VCN, and thus can perform configuration changes, updates, or other suitable modifications.

[0081] According to one embodiment, the control plane VCN and data plane VCN can be included in a service lease. In this case, the system's users or customers may not own or operate the control plane VCN or data plane VCN. Alternatively, the cloud infrastructure provider may own or operate both the control plane VCN and data plane VCN, both of which can be included in a service lease. This embodiment enables network isolation, which can prevent users or customers from interacting with the resources of other users or customers. Furthermore, this embodiment allows the system's users or customers to privately store databases without relying on the public internet for storage, which may not provide the desired level of threat protection.

[0082] According to one embodiment, one or more LB subnets included in the control plane VCN can be configured to receive signals from the serving gateway. In this embodiment, the control plane VCN and the data plane VCN can be configured to be invoked by customers of the cloud infrastructure provider without invoking the public internet. Customers of the cloud infrastructure provider may expect this embodiment because the database(s) used by the customer can be controlled by the cloud infrastructure provider and can be stored on a service lease that is isolated from the public internet.

[0083] Figure 4 The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0084] like Figure 4 As shown, according to an embodiment, the data plane VCN may be included in customer lease 221. In this case, the cloud infrastructure provider may provide a control plane VCN for each customer, and the cloud infrastructure provider may establish a unique compute instance for each customer included in the service lease. Each compute instance may allow communication between the control plane VCN included in the service lease and the data plane VCN included in the customer lease. The compute instance may allow resources provisioned in the control plane VCN included in the service lease to be deployed or otherwise used in the data plane VCN included in the customer lease.

[0085] According to an embodiment, a cloud infrastructure provider's customer may have a database managed and operated within a customer lease. In this example, the control plane VCN may include a data plane mirror application layer, which may include one or more application subnets. The data plane mirror application layer may reside in the data plane VCN, but it may not be provided within the data plane VCN. That is, the data plane mirror application layer may access the customer lease, but it may not exist in the data plane VCN, or be owned or operated by the customer. The data plane mirror application layer may be configured to invoke the data plane VCN, but it cannot be configured to invoke any entity contained within the control plane VCN. A customer may expect to deploy or otherwise use resources provisioned in the control plane VCN within the data plane VCN, and the data plane mirror application layer may facilitate the customer's desired deployment or other use of resources.

[0086] According to one embodiment, a cloud infrastructure provider's customers 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 access to the public internet from the data plane VCN. The cloud infrastructure provider may not be able to apply filters or otherwise control the data plane VCN's access to any external networks or databases. Applying filters and controls to the data plane VCN included in the customer's lease helps isolate the data plane VCN from other customers and the public internet.

[0087] According to embodiments, cloud services can be invoked by a service gateway to access services that may not exist on the public internet, the control plane VCN, or the data plane VCN. The connection between the cloud service and the control plane VCN or data plane VCN may not be contiguous. Cloud services can reside on different networks owned or operated by a cloud infrastructure provider. Cloud services can be configured to accept calls from the service gateway and can be configured not to accept calls from the public internet. Some cloud services may be isolated from other cloud services, and the control plane VCN may be isolated from cloud services that may not be in the same region as the control plane VCN.

[0088] For example, according to an 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 service gateway contained in the control plane VCN located in Region 1 makes a call to Deployment 1, then the call can be transmitted 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 or otherwise communicate with Deployment 1 in Region 2.

[0089] Figure 5The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0090] like Figure 5 As shown, according to an embodiment, a trusted application subnet 260 can be communicatively coupled to a service gateway contained in a data plane VCN, a NAT gateway contained in a data plane VCN, and one or more DB subnets contained in a data plane data layer. An untrusted application subnet 264 can be communicatively coupled to a service gateway contained in a data plane VCN and one or more DB subnets contained in a data plane data layer. The data plane data layer may include one or more DB subnets that can be communicatively coupled to a service gateway contained in a data plane VCN.

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

[0092] According to an embodiment, the public internet can communicatively couple to a NAT gateway contained in a control plane VCN and a data plane VCN. Service gateways contained in the control plane VCN and the data plane VCN can communicatively couple to cloud services.

[0093] According to an embodiment, the data plane VCN can be integrated with customer leases. This integration may be useful or desirable for cloud infrastructure provider customers where additional support may be required when executing code. For example, a customer may provide code to be run that may be potentially destructive, may communicate with other customer resources, or may otherwise cause undesirable effects.

[0094] According to an embodiment, a cloud infrastructure provider's customer can grant temporary network access to the cloud infrastructure provider and request functionality to be attached to the data plane application layer. The code running this functionality can execute within a VM, and this code may not be configured to run anywhere else on the data plane VCN. Each VM can be connected to a customer lease. The corresponding containers (1)-(N) contained within the VM can be configured to run the code. In this case, dual isolation can exist (e.g., containers running code, where the containers may be contained within at least one VM contained in an untrusted application subnet), which helps prevent incorrect or otherwise unintended code from corrupting the cloud infrastructure provider's network or the networks of different customers. Containers can be communicatively coupled to the customer lease and can be configured to transmit or receive data from the customer lease. Containers can be configured not to transmit or receive data from any other entity in the data plane VCN. After the code execution is complete, the cloud infrastructure provider can dispose of these containers.

[0095] According to an embodiment, one or more trusted application subnets may run code that can be owned or operated by a cloud infrastructure provider. In this embodiment, one or more trusted application subnets may be communicatively coupled to one or more database subnets and configured to perform CRUD operations within the one or more database subnets. One or more untrusted application subnets may be communicatively coupled to one or more database subnets and configured to perform read operations within the one or more database subnets. Containers that may be contained within each customer's VM and may run code from the customer may not be communicatively coupled to the one or more database subnets.

[0096] According to embodiments, the control plane VCN and data plane VCN may be coupled without direct communication, or there may be no direct communication between them. However, communication can occur indirectly, where the cloud infrastructure provider can establish an LPG that facilitates communication between the control plane VCN and the data plane VCN. In another example, either the control plane VCN or the data plane VCN can invoke cloud services via a service gateway. For example, an invocation of a cloud service from the control plane VCN may include a request for a service that can communicate with the data plane VCN.

[0097] Figure 6 The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0098] like Figure 6As shown, according to an embodiment, one or more trusted application subnets may be communicatively coupled to a service gateway contained in the data plane VCN, a NAT gateway contained in the data plane VCN, and one or more database subnets contained in the data plane data layer. One or more untrusted application subnets may be communicatively coupled to a service gateway contained in the data plane VCN and one or more database subnets contained in the data plane data layer. The data plane data layer may include one or more database subnets that can be communicatively coupled to a service gateway contained in the data plane VCN.

[0099] According to an embodiment, one or more untrusted application subnets may include primary VNICs that are communicatively coupled to tenant virtual machines (VMs) residing within one or more untrusted application subnets. Each tenant VM may run code in a corresponding container and may be communicatively coupled to an application subnet that may be included in a data plane application layer, which may be included in a container egress VCN 280. Corresponding auxiliary VNICs 282(1)-(N) may facilitate communication between the one or more untrusted application subnets included in the data plane VCN and the application subnets included in the container egress VCN. The container egress VCN may include a NAT gateway that is communicatively coupled to the public internet.

[0100] According to an embodiment, an Internet gateway contained in a control plane VCN and a data plane VCN can be communicatively coupled to a metadata management service, which can be communicatively coupled to the public Internet. The public Internet can be communicatively coupled to a NAT gateway contained in both the control plane VCN and the data plane VCN. A service gateway contained in both the control plane VCN and the data plane VCN can be communicatively coupled to a cloud service.

[0101] According to an embodiment, Figure 6 The pattern shown can be regarded as Figure 5 This is an exception to the pattern shown, and it may be the pattern desired by customers if the cloud infrastructure provider cannot communicate directly with them (e.g., in a disconnected region). Customers have live access to the corresponding containers contained within each customer's VM. Containers can be configured to invoke appropriate secondary VNICs contained in one or more application subnets within the data plane application layer, which may be contained in the container's egress VCN. The secondary VNICs can then route the calls to a NAT gateway, which can then route the calls to the public internet. In this example, the containers that customers can access live can be isolated from the control plane VCN and from other entities contained within the data plane VCN. Containers can also be isolated from resources from other customers.

[0102] In other examples, customers can use containers to invoke cloud services. In this example, a customer can run code within a container that requests a service from the cloud service. The container can then forward the request to a secondary VNIC, which in turn forwards it to a NAT gateway, which in turn forwards it to the public internet. The public internet can then be used to forward the request via an internet gateway to one or more load balancer (LB) subnets contained within the control plane VCN. In response to determining that the request is valid, the LB subnets can forward the request to one or more application subnets, which in turn forward the request to the cloud service via a service gateway.

[0103] It should be recognized that the IaaS architecture depicted in the figures above may have components other than those depicted. Furthermore, the embodiments shown in the figures are merely some examples of cloud infrastructure systems that can be combined with embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations or arrangements.

[0104] In some embodiments, the IaaS system described herein may include a suite of application, middleware, and database service providers delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner.

[0105] Private Tag Cloud Environment

[0106] According to an embodiment, a cloud infrastructure environment can be used to provide a dedicated cloud environment, such as one or more privately tagged cloud environments, for tenants of the cloud infrastructure environment to use when accessing subscription-based software products, services, or other provisioning items associated with the cloud infrastructure environment.

[0107] Figure 7 The illustration shows how a system according to an embodiment can provide a dedicated or private tagged cloud environment for use by tenants or customers of a cloud infrastructure environment.

[0108] like Figure 7 As shown, according to an embodiment, a cloud infrastructure provider (e.g., Oracle Cloud Infrastructure, OCI) may supply one or more private tag cloud (PLC) environments to a PLC operator 320 (e.g., an OCI customer operating as a reseller). The PLC operator / reseller can then customize and extend the private tag cloud for use by its customer 330 when accessing subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0109] For illustrative purposes, examples of such subscription-based products, services, or other offerings may include various Oracle cloud infrastructure software products, Oracle Fusion Applications products, or other types of products or services that allow customers to subscribe to use these products or services.

[0110] Figure 8 The illustration further illustrates the use of a privately labeled cloud domain by a tenant or customer of a cloud infrastructure environment, according to an embodiment.

[0111] like Figure 8 As shown, according to embodiments, the system may include a cloud subscription service or component, referred to herein in some embodiments as such as an Oracle Cloud Subscription (OCS) service or component, which exposes one or more subscription management APIs for creating orders for joining new customers or initiating workflows for creating subscriptions and orchestrating billing and pricing services or other components for PLC Domain 400.

[0112] According to an embodiment, when a PLC operator or its customer requests a PLC environment, the system creates a PLC domain for leased use by one or more providers. A domain is a logical collection of one or more cloud regions, isolated from each other, and customer content is not allowed to cross domain boundaries to reach regions outside that domain. Each domain is accessed independently. The PLC operator accesses cloud resources and services through cloud leases. A cloud lease is a secure and isolated partition of the OCI, and it exists only within a single domain. Within this lease, if policies permit, the operator can access services in all regions within that domain and deploy workloads.

[0113] According to an embodiment, the first step of this process is to create an operator lease for the PLC operator, and then transfer the domain and associated areas to the PLC operator for subsequent management. The PLC operator then becomes the administrator of the lease, able to view and manage everything that happens within the domain, including its customer accounts and those customers' use of cloud resources.

[0114] Generally, once the domain is handed over or provided to the PLC operator, the cloud infrastructure provider cannot subsequently access the data within the operator's lease unless the operator authorizes the cloud infrastructure provider to do so, for example, to provide troubleshooting for potential problems.

[0115] According to an embodiment, the PLC operator can then create additional internal leases intended for its own internal use, such as for evaluating the end-customer experience, providing sales demonstration leases, or operating a database for its own internal use. The operator can also create one or more customer leases, with the end customer acting as its administrator. Cloud infrastructure usage metrics (e.g., compute usage, storage usage, and usage of other infrastructure resources) can be aggregated by the operator to reflect usage by both the operator and customers. Cloud infrastructure usage can be reported to the cloud infrastructure provider.

[0116] According to embodiments, a user interface or console may be provided that allows PLC operators to manage their customer accounts and customer-supplied services. Cloud infrastructure providers may also use cloud infrastructure leasing (e.g., converged application leasing) to install any required infrastructure services for use by operators and their customers.

[0117] Figure 9 The illustration further illustrates the use of a privately labeled cloud domain by a tenant or customer of a cloud infrastructure environment, according to an embodiment.

[0118] like Figure 9 As shown in the example, according to the embodiment, the Oracle Cloud Subscription (OCS) service or component exposes one or more subscription management APIs for creating orders for joining new customers or initiating workflows for creating subscriptions and orchestrating billing and pricing services or other components.

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

[0120] According to an embodiment, the system may also include a subscription pricing service (SPS) or component that operates on a product catalog defining the products that customers can purchase. The subscription pricing service may also be used to provide a price list (e.g., a rate card) that is also available through the pricing service.

[0121] According to an embodiment, to support sales processing for creating subscriptions in the PLC domain, products can be selected from the product hub. Once an order is created, a subscription is created in the OCS, which then manages the subscription's lifecycle and supplies the content that needs to be provided in downstream services. The SPS component then manages pricing and usage aspects for the ability to collect final fees from PLC operators or for operators to charge their customers. Usage events are forwarded to the billing service or component, where, depending on the subscription's billing preferences, an invoice is created and pushed to the accounts receivable component.

[0122] According to an embodiment, although the services provided in the field report their usage to a metering service or component, such usage does not have any associated price. Billing processing, for example, determines the cost of each specific event by applying a rate card, determines the unit and cost of the subscription, associates the cost with the record, and then forwards it to the billing service or component.

[0123] like Figure 9 As further illustrated, according to an embodiment, a PLC operator can control multiple domains A and B. For example, an operator operating in multiple countries might wish to operate a data center completely isolated from the United States, and a separate data center completely isolated from Europe, for example, to meet governance or regulatory requirements. According to an embodiment, usage associated with these multiple domains can be aggregated for billing the operator.

[0124] The examples of the various systems provided above are intended to illustrate computing environments that can be used to provide dedicated or privately tagged cloud environments for tenants of cloud infrastructure to use when accessing subscription-based software products, services, or other provisioning items 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.

[0125] Private tag cloud subscription

[0126] Figure 10 The illustration depicts a system according to an embodiment for providing access to software products or services in a cloud computing or other computing environment.

[0127] like Figure 10 As shown, according to an embodiment, the system can be provided as a cloud computing 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.

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

[0129] According to embodiments, subscriptions may include artifacts such as products, commitments, billing models, and states. The OCS service may expose one or more subscription management APIs for creating orders to join new customers or initiating workflows to create subscriptions and orchestrate appropriate footprints in the billing and pricing service or components, as further described below.

[0130] According to an embodiment, a billing service or component operates on a logical container of billing accounts or subscriptions and preferences used to generate invoices. Each billing account generates one or more invoices per billing period. The billing service includes a first pipeline that receives usage and costs from a metering service or component. Usage can be received via a REST API or other interface. The billing service writes the usage to a database from which the billing service or other services can calculate and aggregate balances. The billing service may include a second pipeline responsible for obtaining aggregated usage and commitments and calculating costs for one or more billing intervals.

[0131] According to an embodiment, a subscription pricing service (SPS) or component operates on a product catalog that defines the products a customer can purchase. The product catalog forms the backbone of a price list (i.e., rate cards) also owned by the pricing service. Rate cards are modeled as pricing rules on top of publicly listed prices. The pricing service maintains a single price list for each product; new product prices can be added, and existing prices can be changed. The price lists have a complete history, with the latest version being the current rate card. Because some contracts may require snapshots of the rate cards, the pricing service handles this by recording when a customer's rate card was created and then querying the price list at that time.

[0132] According to embodiments, the SPS or pricing service is responsible for providing information about products, a global price list, and end-customer subscription-specific price lists and discounts. For example, according to embodiments, the SPS can synchronize product information from the Oracle Fusion Product Hub and a global price list from the Oracle Fusion Pricing Hub.

[0133] According to the embodiment, the OCS service operates as an upstream service to receive new order requests, for example, from the Oracle Fusion Order Management environment. The OCS service can provide subscription information to the SPS service. Subscription details such as the timing of the quote, configuration, and subscription type (commitment, PayG) help the SPS determine the effective base price (rate card) for the subscription. The OCS service can also send subscription discounts, for example, received from Oracle Fusion Order Management, which the SPS stores as a pricing rule entity.

[0134] In one embodiment, the SPS service runs as a background process to manage a rate card service or component responsible for generating rate cards for new subscriptions and updating them when prices change. The SPS service can expose APIs to access rate cards and pricing rules. The metering inline billing engine can leverage these APIs to obtain subscription-specific rate cards and pricing rules, using this data for cost calculations.

[0135] According to an embodiment, additional SPS components may include, for example, the Pricing / Product Hub Oracle Integration Cloud (OIC) integration component, which allows PLC operator entities to manage, for example, their product and price lists provided by the Oracle Fusion Product Hub and the Oracle Fusion Pricing Hub, respectively, within the environment to offer subscription-based products, services, or other offerings.

[0136] For example, according to this embodiment, the SPS OIC product integration process can listen for creation / update events in the product hub and invoke the SPS product API. Similarly, the SPS OIC pricing integration process can retrieve new price list creation from the pricing hub and invoke the corresponding SPS pricing API.

[0137] According to one embodiment, the system may also include an SPS core module that provides APIs for managing and accessing pricing entities. Pricing can be accessed through internal services such as an inline billing engine.

[0138] According to an 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 time. However, the price of a subscribed product depends on the base price at the time of the quote configuration and the subscription's price list change policy attributes. The SPS service uses these attributes to internally maintain the prices to be used for subscriptions. These price lists are grouped in rate cards. The rate card manager can create and maintain rate cards, as well as listen for price list changes and update existing rate cards with the new prices. It also listens for new subscriptions and assigns rate cards based on subscription properties.

[0139] According to an embodiment, the system may also include a rule decoder engine. The SPS service is responsible for managing the pricing rules for subscriptions, including discounts offered to end customers. Pricing rule applicability 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 will apply. To achieve this, the rule decoder engine can compile the pricing rules into a format that the inline billing engine can use for cost calculations. This compilation process can be triggered when a product or pricing rule is created / updated.

[0140] If passed Figure 10As illustrated in the example, according to the embodiment: At 441, product and pricing information, such as that managed in a converged application, is sent to the SPS component. At 442, an order is sent to the OCS component to create a subscription, rate card, and billing account. At 443, the pricing configuration and pricing rules for the new order are sent to the SPS. At 444, the OCS is used to establish a billing account in the billing service or component. At 445, the OCS publishes an event to the OCI streaming component. At 446, fee data is sent to the Accounts Receivable component to generate an invoice. At 447, the OCS uses Recycling and Subscription Lifecycle (RASL) events from the OCI streaming component. At 448, the activation service reads the OCS event stream. At 449, the customer retrieves activation data from the portal. At 450, the Lease Lifecycle Service provisiones the lease as part of the subscription activation. At 451, the Lease Lifecycle Service creates an account footprint during account provisioning. At 452, the Lease Lifecycle Service sets a limit template during account provisioning. At 453, the account component acts as a downstream RASL client to handle legacy repossession. At 454, aggregated costs and usage are sent to the billing service or component. At 455, organizations can create subleases using the lease lifecycle service. At 456, the metering service or component retrieves subscription mapping data. At 457, the subscription service retrieves organizational data used for subscription mapping. At 458, RASL reads the OCS event stream. At 459, the subscription service reads the OCS event stream; and at 460, the metering service or component retrieves rate card data for each subscription, which can then be used to collect final charges from PLC operators or enable PLC operators to charge their customers.

[0141] The examples provided above are intended to illustrate computing environments that can be used to provide dedicated or privately tagged cloud environments for use by tenants of cloud infrastructure when accessing subscription-based software products, services, or other provisioning items 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.

[0142] 3. Access Control Architecture

[0143] Figure 11 A system 1100 according to one or more embodiments is illustrated. For example... Figure 11 As shown, 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, system 1100 may include a cloud infrastructure environment 1102, a customer operator interface 1104, and a CSP provider operator interface 1106. Figure 11 The components shown may have more or fewer components. Figure 11 The components shown can be located locally or remotely to each other. Figure 11The components shown can be implemented using software and / or hardware. Components can be distributed across multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. Operations described for one component can be performed by another component.

[0144] In one or more embodiments, cloud infrastructure environment 1102 refers to hardware, software, networking, and storage components that enable the delivery of cloud computing services. Cloud infrastructure environment 1102 also includes hardware and / or software configured to perform the operations described herein for controlling operator access to cloud resources of cloud infrastructure environment 1102. Reference will be made below. Figure 12 This describes an example of operations used to control operator access to cloud resources in cloud infrastructure environment 1102.

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

[0146] In one or more embodiments, cloud infrastructure environment 1102 is a cloud computing infrastructure provided by a first entity (e.g., a CSP) to a second entity (e.g., a customer of the CSP). 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 support cloud infrastructure environment 1102. The CSP's customer owns and deploys cloud infrastructure environment 1102. The customer operator (i.e., the operator associated with the CSP's customer) is responsible for managing cloud infrastructure environment 1102, including providing Level 1 and Level 2 support. Level 1 support may include an initial point of contact for users or customers and provide basic troubleshooting and assistance with common issues. Level 2 support may include handling escalated support tickets, conducting in-depth analysis and troubleshooting of technical issues, performing root cause analysis to identify potential problems, providing advanced technical guidance and solutions, and collaborating with higher-level support or specialist teams to resolve complex issues requiring further expertise. The CSP operator provides higher-level support. The CSP operator maintains and updates the core functionality of cloud infrastructure environment 1102 to ensure that cloud infrastructure environment 1102 remains secure and is updated with new features in a timely manner.

[0147] In one or more embodiments, the cloud infrastructure environment 1102 is organized into cloud regions. The cloud regions are isolated from each other. A logical collection of one or more cloud regions is called a realm. A realm is accessed individually. Clients of a realm cannot cross the realm boundary to regions outside that realm.

[0148] In one or more embodiments, the cloud regions of cloud infrastructure environment 1102 include isolated regions, such as Oracle Cloud Isolated Region (OCIR) or Oracle Cloud National Security Region (NSR). Isolated regions are highly secure and isolated environments within the cloud infrastructure environment, addressing the needs of customers with stringent security and compliance requirements. Isolated regions are designed to provide enhanced levels of isolation, control, and compliance for sensitive workloads and highly regulated industries such as government, finance, healthcare, and defense.

[0149] In one or more embodiments, the cloud infrastructure environment 1102 includes infrastructure service 1108, bastion service 1110, permission service 1112, and data storage 1114.

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

[0151] In this embodiment, infrastructure service 1108 includes abuse service, fraud service, security service, and compliance service. The abuse service, or abuse management service, addresses and mitigates various forms of abuse or misuse of cloud resources and services. Abuse can include a variety of activities such as spam, phishing, malware distribution, denial-of-service (DoS) attacks, unauthorized access, or any behavior that violates the CSP's terms of service or acceptable use policies. The fraud service, or fraud detection service, detects, prevents, and mitigates fraudulent activities occurring within or involving cloud-based services within the cloud infrastructure. Fraudulent activities can include unauthorized access, data breaches, identity theft, financial fraud, and other forms of malicious activity designed to exploit cloud resources or compromise cloud-based systems. The security service protects cloud-based resources, applications, and data from various security threats and vulnerabilities. The security service can mitigate risks, enforce security policies, and maintain compliance with regulatory requirements. The compliance service ensures compliance with regulatory requirements, industry standards, and internal policies related to data protection, privacy, security, and governance.

[0152] In one or more embodiments, infrastructure service 1108 is performed by the operator performing various operator actions 1116. Operator actions 1116 may include actions related to 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.

[0153] In one or more embodiments, the operator actions 1116 available to operators may differ between operators of different entities, operators of different services, and operators of different tiers. For example, an operator associated with a CSP's customer may not have access to the same operator actions as an operator associated with that 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 permissions service 1112 of the cloud infrastructure environment 1102 manages operator access to operator actions 1116.

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

[0155] In one or more embodiments, a bastion instance 1118, also referred to as a 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 an operator (e.g., a CSP operator) 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 serves as a single entry point for accessing resources within the private network. The bastion instance is deployed with robust security measures to prevent unauthorized access and protect sensitive data. The bastion instance enforces 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 limited to resources that the operator is authorized to manage. The bastion instance may be deployed in a separate subnet or network segment isolated from the rest of the cloud infrastructure environment 1102. This isolation minimizes the attack surface and reduces the risk of unauthorized access to internal systems.

[0156] In one or more embodiments, communication between the operator's client devices and the bastion instance, as well as between the bastion instance and internal resources, is encrypted to protect the confidentiality and integrity of data transmitted over the network. Bastion instance 1118 can generate detailed logs of user activity and access attempts, providing a comprehensive audit trail for monitoring and compliance. Logs created by the bastion instance can be analyzed to identify security incidents, unauthorized access attempts, or policy violations. Bastion instance 1118 can grant users or administrators temporary access for a specific period, after which the access is automatically revoked. The bastion instance can be deployed in a redundant configuration with built-in failover mechanisms to ensure continuous availability and uninterrupted access to internal resources even in the event of hardware or software failures.

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

[0158] In one or more embodiments, the IAM service manages user identity, access rights, and permissions for accessing cloud services and resources. The IAM service includes various features such as user authentication, authorization, user provisioning and deprovisioning, role-based access control, multi-factor authentication, and centralized policy management. The IAM service allows organizations to define and enforce fine-grained access controls based on roles, groups, or individual operators, thereby ensuring that access to specific resources or the performance of certain operations is restricted to authorized operators.

[0159] In one or more embodiments, the IAM service provides Just-In-Time (JIT) credentials. JIT credentials are access credentials dynamically generated and provided on demand to users or systems immediately before credentials are required, such as usernames and passwords, API keys, or temporary tokens. JIT credentials can be short-lived and valid for a limited period or specific use case. JIT credentials provide on-demand generation, short-term validity, limited 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 on demand and are not pre-stored or predefined. JIT credentials are designed to be temporary and have a limited validity period. JIT credentials can be valid for short periods, such as minutes or hours, to minimize the risk of exposure and unauthorized use. JIT credentials can be limited to a specific resource, service, or operation. JIT credentials provide access to the resources or actions required to satisfy an immediate request and do not grant permissions beyond what is necessary. After the allocated time period or use case expires, the JIT credentials are automatically revoked or invalidated by the IAM system. The permissions service 1112 records and audits JIT credential generation and usage to provide visibility into who accessed which resources and when.

[0160] In one or more embodiments, ACLs are used to define and enforce access control policies at the resource level, such as buckets, virtual machines, or databases. An ACL specifies the user or entity granted access to a particular resource, and the actions (e.g., read, write, execute) that are permitted to be performed by those users or entities. A KMS service manages cryptographic keys used to encrypt and decrypt data in a cloud environment. The KMS service controls access to these encryption keys through access policies, allowing organizations to define who can manage and use the encryption keys to protect sensitive data.

[0161] In one or more embodiments, an API provides programmatic access to resources and functions. An API authorization and authentication service manages access to these APIs, ensuring that interactions with cloud resources via the API are limited to authorized applications or services. The API authorization and authentication service can use standards such as OAuth 2.0 or JSON Web Tokens to secure API access. A Service Registry (NSG) is used to define and enforce network-level access control within a cloud environment. An NSG specifies rules for controlling inbound and outbound traffic to and from cloud resources based on source and destination IP addresses, ports, and protocols.

[0162] In one or more embodiments, data repository 1114 is any type of storage unit and / or device for storing data (e.g., file system, database, collection of tables, or any other storage mechanism). Additionally, 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 be located at the same physical site. Furthermore, data repository 1114 may be implemented or executed on the same computing system as cloud infrastructure environment 1102. Additionally or alternatively, data repository 1114 may be implemented or executed on a computing system separate from cloud infrastructure environment 1102. Data repository 1114 may be communicatively coupled to cloud infrastructure environment 1102 via a direct connection or via a network.

[0163] Information describing the cloud infrastructure environment 1102 can be implemented in any component within system 1100. However, for clarity and explanation, this information is illustrated as being in a data store 1114. The data store 1114 may include carrier credentials 1120, algorithms 1122, access policies 1124, a permissions database 1126, session information 1128, and disable configurations 1130.

[0164] In one or more embodiments, operator credentials 1120 refer 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 specific resources or perform certain actions. Operator credentials 1120 may include JIT credentials generated by the IAM of authorization service 1112.

[0165] In one or more embodiments, 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 passcode (password) can be used to authenticate users and grant access to systems, applications, or online accounts. An alphanumeric string or token can be issued to an application or service to verify the operator's identity and authorize access to an API or web service. Certificate authorities can issue digital certificates to cryptographically authenticate the identity of users, devices, or servers. Certificates are commonly used in HTTPS (HTTP over SSL / TLS) connections, VPNs (Virtual Private Networks), and digital signatures. After successful authentication, a token can be issued to the user or application, allowing the operator to access resources or services for a limited time. Public-private key pairs can be used for secure authentication and communication between systems using SSH.

[0166] In one or more embodiments, 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 via a biometric authentication system. A temporary code can be generated and sent to the operator's device (e.g., a mobile phone) for authentication. OTPs are typically valid only once 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 its authenticated session and authorize subsequent requests within a limited timeframe.

[0167] In one or more embodiments, machine learning algorithm 1122 is an algorithm that can iteratively train a target model f, which optimally maps a set of input variables to output variables. The machine learning algorithm is an algorithm that can iteratively train the target model f using a set of training data, which optimally maps a set of input variables to output variables. 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 can be updated based on, for example, feedback on predictions of the target model f and the current accuracy of the target model f. The updated training data is fed back into the machine learning algorithm, which in turn updates the target model f.

[0168] Machine learning algorithm 1122 generates a target model f such that the target model f best fits the training dataset to the labels of the training data. Additionally or alternatively, machine learning algorithm 1122 generates a target model f such that when the target model f is applied to the training 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.

[0169] Machine learning algorithms can include supervised learning and / or unsupervised learning. Various types of algorithms can be used, such as linear regression, logistic regression, linear discriminant analysis, classification and regression trees, Naive Bayes, k-nearest neighbors, learned vector quantization, support vector machines, bagging and random forests, boosting, backpropagation, and / or clustering.

[0170] In one or more embodiments, access policy 1124 defines rules and permissions that govern who can access which resources and what actions they are allowed to perform within the cloud infrastructure environment 1102. Access policies are essential for enforcing security, compliance, and governance requirements. Access policies can specify the user, group, role, or service account granted access to a particular cloud resource. Access policies can define the permissions granted to a user or entity to interact with a particular cloud resource. Access policies can allow for granular control of permissions, enabling organizations to specify fine-grained access based on individual resources, attributes, or conditions. Access policies may include conditions that must be met to grant access, such as requiring multi-factor authentication (MFA), originating from a specific network location, or using a specific client device.

[0171] In one or more embodiments, the permissions database 1126 is a centralized repository of permissions, access control, and authorization settings for various resources within the cloud infrastructure environment 1102. The bastion service 1110 and the permissions service 1112 can utilize the permissions database 1126 to enforce security policies, manage user access, and ensure regulatory compliance. The permissions database 1126 can store information about users, groups, roles, and their associated permissions to access specific resources or perform certain actions. Permission 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. This database provides a centralized location for managing access control and authorization policies within the cloud infrastructure environment 1102. The permissions database 1126 may include audit logs and records of access activity for tracking permission changes, monitoring user access, and demonstrating regulatory compliance. Audit logs provide visibility into who accessed which resources, when they accessed them, and what actions were performed, thereby aiding in security incident investigations and compliance audits.

[0172] In one or more embodiments, session information 1128 refers to data associated with interactions (referred to as sessions) between a user and the cloud infrastructure environment 1102 within a specific time period. 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 sessions and activities. Session information may include session ID, user identity, authentication status, session start and end times, session duration, client information, session state, access permissions, activity logs, and security context.

[0173] In one or more embodiments, a unique identifier may be assigned to a session and 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 username, user ID, or other user attributes. Session information may indicate whether a user has successfully authenticated for the session (i.e., via credentials or authentication token). Session information may include a timestamp indicating the start and end times of the session, and the length of time the session remained active, measured in seconds, minutes, or hours.

[0174] In one or more embodiments, session information 1128 includes detailed information about the client device or application used to access the system, such as 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 a 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 access rights and privileges within the cloud infrastructure environment 1102, including roles, permissions, and authorization tokens. Session information may include a record 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.

[0175] In one or more embodiments, disable configuration 1130 is a predetermined list of configurations used to restrict access by one or more operators to one or more resources in cloud infrastructure environment 1102. Disable configuration 1130 may be associated with the type of operator, such as a customer operator, CSP operator, or administrator. Disable configuration 1130 may be associated with a specific service and / or a specific operator action within those services. Disable configuration 1130 may also be associated with the duration for which operator access is disabled.

[0176] In one or more embodiments, the customer operator interface 1104 refers to hardware and / or software configured to facilitate communication between a customer operator and the cloud infrastructure environment 1102. The customer operator interface 1104 renders user interface elements and receives input via these 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, drop-down lists, list boxes, buttons, toggle buttons, text fields, date and time pickers, command lines, sliders, pages, and forms.

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

[0178] 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 buttons or other icons that can be engaged by a customer operator or administrator. The disable element 1134 may include various elements for configuring the disable command. For example, the disable element may include interface elements for selecting the action to be initiated when the disable element is engaged (i.e., terminating an existing session, revoking credentials, rejecting requests for new credentials, etc.). The disable element may include one or more interface elements for selecting the operator type (i.e., CSP operator, customer operator) for which the service will be disabled. Interface elements may include individual operators. The disable element 1134 may include one or more interface elements for selecting the service type to be disabled when the disable element 1134 is engaged. The disable element 1134 may include operator action 1116 to be disabled when the disable element 1134 is engaged. The disable interface 1134 may include one or more interface elements for selecting the period for which the disable command will remain engaged.

[0179] In one or more embodiments, the disable element 1134 or infrastructure dashboard 1132 may include a visual indication of the remaining time of the disable command. The disable command may be automatically reversed at the end of the specified time period. Alternatively, the customer operator or administrator may reverse the disable command by re-engaging the disable element 1134.

[0180] 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 via these 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, drop-down lists, list boxes, buttons, toggle buttons, text fields, date and time pickers, command lines, sliders, pages, and forms.

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

[0182] 4. Control operator access to cloud resources

[0183] Figure 12 The illustration depicts a set of example operations for controlling operator access to a customer's cloud infrastructure environment, according to one or more embodiments. Figure 12 One or more operations shown can be modified, rearranged, or omitted. Therefore, Figure 12 The specific order of operations shown should not be construed as a limitation on the scope of one or more embodiments.

[0184] One or more embodiments receive a request from an operator (e.g., a CSP operator) to access resources in a customer's 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, ticketing system, self-service portal, or access request form. When submitting the access request, the provider may specify the access through a bastion service. The type of access requested may be indicated by checkboxes, drop-down menus, or other selection mechanisms provided in the operator's access request interface. In addition to providing authentication information, the operator may also specify the type of access it is requesting. The type of access may include the resources the operator is attempting to access, such as one or more services, operator actions, etc. Alternatively, the permissions service may include a set of default services and / or operator actions for a specific type of operator and / or a specific operator.

[0185] In this embodiment, 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 credentials provided in the authentication request to ensure that the credentials are correct and authorized for authentication. Authentication may involve verifying the operator's identity against a pre-approved directory of operators, verifying the authenticity of the provided token, or checking the validity of the API key.

[0186] One or more embodiments determine whether the operator meets the requirements for accessing resources in the customer's cloud environment (Operation 1204). When an operator makes a request to access the cloud infrastructure environment, the authorization service reviews the request. The authorization service uses the authorization database to verify the legitimacy of the request, ensure that the access request complies with security policies and access controls, and assess any associated risks.

[0187] One or more embodiments deny the access request (Operation 1206). When the authorization service cannot verify the user and / or determines that the operator is not authorized to access the resource it is requesting, the operator is denied access.

[0188] One or more embodiments allow operators to access resources in a customer's cloud environment (Operation 1208). An access request is approved when the authorization service is able to authenticate the user and verify authorization for the requested resource. The authorization service provides the necessary access permissions through a bastion service. This may involve configuring user accounts, establishing authentication mechanisms, and granting privileges to access the requested resource via the bastion host. Once access has been provided through the bastion service, the operator can be 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 resource within the customer's cloud environment.

[0189] In one or more embodiments, the operator connects to the bastion service using a secure remote access protocol such as Secure Shell (SSH) or Remote Desktop Protocol (RDP) and authenticates itself using its credentials. The bastion service provides a set of one or more bastion instances. Operator sessions are established through bastion instances. The bastion service may log information associated with sessions established through bastion instances. The logged information may include the type of operator requesting access (e.g., CSP operator or customer operator), and / or whether the session is a region connection to a customer's cloud environment.

[0190] In some embodiments, after successful authentication, the authorization service performs an authorization check to determine whether the operator is permitted to establish the requested session. Authorization includes assessing the operator's permissions, roles, and access policies to determine whether the operator has the rights required to access the requested resource or perform the requested operation.

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

[0192] In one or more embodiments, the operator (such as an administrator or a customer's security team) interacts with a dashboard provided by the CSP. This dashboard may be part of a management console or management portal. The customer operator navigates through the dashboard interface and selects specific resources or permissions associated with the operator access to be disabled. This may include selecting individual operators, roles, or groups, and specifying the types of resources affected. Alternatively, the categories of affected operators and resources may be predetermined or determined using machine learning algorithms. 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 the intent to modify access permissions and initiates processing that sends the command to the bastion service and / or permissions service.

[0193] 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 make it easily identifiable. The disable interface may include additional interfaces for customizing the disable command, such as buttons or drop-down menus. Customization may include selecting some operators and some actions without affecting other operators and other actions. Once the disable command is activated, a countdown clock or other visual effects may be displayed to indicate the length of time before the disable command reverses. The time length may be extended to a maximum length, such as 30 minutes, 2 hours, or 6 hours. Alternatively, the disable command may remain active until the customer operator or administrator deactivates it. The customer operator can deactivate the disable command by re-engaging the large red button.

[0194] In one or more embodiments, the bastion service and / or permissions service receive commands from the dashboard interface. Receiving commands may involve a combination of front-end web technologies (such as JavaScript) that handle user interaction and back-end server-side components that process and execute the commands. The service verifies the authenticity and authorization of the commands. Verification of authenticity and authorization includes verifying the identity of the customer or administrator, checking the operator's permissions or roles, and ensuring that the requested action complies with applicable policies, permissions, and compliance requirements. Once the command is authorized and verified, the service performs the necessary actions to disable the operator's access to the specified resources in the cloud infrastructure environment. Because the operation of disabling operator access propagates throughout the system, there may be a time lag in disabling operator access.

[0195] In one or more embodiments, disabling carrier access may involve updating access control configurations, revoking authentication tokens or credentials, and / or modifying permissions or roles associated with the affected resource. This may include placing markers or other symbols for the affected carrier and / or resource in a permissions database. The dashboard interface provides feedback to the customer carrier to indicate that the command to disable carrier access has been successfully processed. Confirmation may include visual indicators, such as changes in interface color, status messages, or notifications within the dashboard interface informing the customer carrier of the result of the action. Interface features may visually indicate a countdown to the expiration of the disable command.

[0196] In one or more embodiments, the bastion service and / or the permission service logs detailed information about command execution for auditing and compliance purposes. The logged information may include the customer operator or administrator who initiated the command, the affected resources, the time of execution, and any related metadata associated with the action.

[0197] In one or more embodiments, the command to disable operator access is initiated via an API call. A client application or system may send an API request to a cloud infrastructure API endpoint, specifying details of the command to disable operator access. This request may include various parameters, such as the type of resource affected, the specific operator or role whose access should be disabled, and any other relevant information. The API request is authenticated and authorized by the cloud infrastructure API gateway or authentication service. This involves verifying 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 rights to execute the command. The API endpoint receives the request and verifies its content to ensure that the request is consistent with the API's architecture and specifications. Request verification may include checking required parameters, data types, and other verification rules to prevent API errors or misuse.

[0198] In this embodiment, once the request to disable carrier access is authenticated, authorized, and verified, the API endpoint executes a command to disable carrier access to a specified resource in the customer's cloud environment. This involves invoking 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 execution was successful or whether any errors occurred during processing. The response may also include additional details or metadata related to the action taken. By initiating commands through API calls, users can programmatically manage and automate access control operations in a customer's cloud environment, such as disabling carrier access to resources.

[0199] In response to a received command, one or more embodiments terminate existing sessions that provide CSP operators with access to resources in a customer's cloud environment (Operation 1212). The bastion service terminates existing sessions established through a bastion instance by proactively managing and controlling access to the bastion instance. More specifically, the bastion service identifies currently active sessions established through the bastion instance. This may involve querying logs, monitoring network traffic, or consulting the session management database. The bastion service receives requests or triggers to terminate specific sessions. These requests may originate from the customer operator or administrator, security systems, or be automatically triggered based on predefined policies or rules. The bastion service can initiate the termination of identified sessions by sending a termination command or signal to the bastion instance hosting these sessions. This may involve closing network connections, terminating processes, or forcing the operator to exit. Once a session is terminated, the bastion service confirms successful termination and logs the event for auditing and compliance purposes. This includes logging details such as the operator associated with the terminated session, the time of termination, and any relevant metadata.

[0200] In one or more embodiments, the bastion service notifies affected operators that their sessions have been terminated. This notification may include information about the reason for the termination and any instructions or follow-up steps for re-establishing access. The notification may be presented as a banner on the operator's user interface. The notification may include the estimated duration of the access suspension.

[0201] In one or more embodiments, the bastion service verifies that the terminated session is no longer active and that access has been effectively revoked. The bastion service may perform additional cleanup tasks, such as removing 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 involve implementing access controls, authentication mechanisms, or session timeout policies to ensure that access to the bastion instance and the establishment of new sessions is limited to authorized users.

[0202] In response to receiving a command, one or more embodiments reject new requests for credentials used to establish a session granting a CSP operator access to resources in a customer's cloud environment (Operation 1214). As an alternative or addition to terminating an existing session, the authorization service may reject new requests for credentials. When a command is issued to disable an operator's access to resources in a customer's cloud environment, a marker or symbol identifying the operator affected by the disabling command is added to a pre-approved list of operators. When the authorization service receives a request for credentials, it consults the pre-approved list of operators and rejects credentials for operators marked on the list. The disabling command may be limited to individual operators, a group or class of operators, or all operators. Operators can be distinguished by entities associated with the operator and / or resources authorized for access by the operator.

[0203] In response to a received command, one or more embodiments revoke existing credentials used to establish a session providing access to resources in a customer's cloud environment to a CSP operator (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 can 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 credentials should be revoked. This can be initiated by the customer operator or administrator in response to a security event or based on predefined policies or rules. The authorization service updates the authorization repository or database to mark the identified credentials as revoked. This may involve setting flags or conditions to indicate 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 rely on credentials for authentication or access control. This may involve updating caches, databases, or distributed systems to reflect the change in credential status.

[0204] In one or more embodiments, the authorization service notifies one or more operators whose credentials have been revoked, informs the operators of the change, and provides guidance on subsequent steps. The guidance provided to operators can be used for re-authentication, obtaining new credentials, or contacting support for assistance. The authorization service can enforce revocation by refusing any subsequent authentication attempts or access requests using revoked credentials. This prevents operators or entities from continuing to use expired credentials to establish sessions or access resources. The authorization service can periodically review and clean up revoked credentials to ensure the authorization repository remains up-to-date and free of expired or unnecessary entries, thereby maintaining the integrity and efficiency of the authentication and access control system.

[0205] One or more embodiments reverse one or more of the following: terminating an existing session, rejecting a new request for credentials, or revoking existing credentials to allow the CSP operator to access resources in the customer's cloud environment (Operation 1218). Once the specified period for disabling operator access has elapsed, or the customer operator has deactivated the disable access command, the operation used to disable operator access will be reversed. This may include re-establishing the terminated session, approving a new request for credentials, and restoring revoked credentials. The permissions database can be updated by removing any flags placed when the disable command was activated.

[0206] 5. Example Implementation

[0207] For clarity, detailed examples are described below. The components and / or operations described below should be understood as specific examples and may not be applicable to some embodiments. Therefore, the components and / or operations described below should not be construed as limiting the scope of any claims.

[0208] Figure 13 The diagram illustrates a dashboard provided to operators and administrators associated with a cloud service provider's customer. 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 also provides a disable access button 1306. By engaging the disable access button 1306, operator access to the customer's cloud infrastructure environment is disabled. Although the disable access button 1306 is presented as a simple button, it can include interface elements for selecting operator access to be disabled and which resources to disable.

[0209] 6. Practical applications, advantages, and improvements

[0210] The ability of cloud service providers to disable carrier access to their cloud infrastructure environment allows customers to 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 carrier access to a customer's cloud infrastructure environment allows customers to meet regulatory compliance requirements, thus ensuring compliance with data protection and privacy regulations.

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

[0212] 7. Other matters; extension

[0213] Unless otherwise defined, all terms (including technical and scientific terms) shall be given the meanings that are common and customary to those skilled in the art, and are not limited to special or customary meanings, unless otherwise expressly defined herein.

[0214] This application may include references to certain trademarks. While the use of trademarks is permitted in a patent application, the exclusivity of the trademark should be respected, and every effort should be made to prevent the trademark from being used in any way that may adversely affect its validity.

[0215] The embodiments are directed to a system having one or more devices, which include a hardware processor and are configured to perform any of the operations described herein and / or recited in any of the following claims.

[0216] In an embodiment, one or more non-transitory computer-readable storage media include instructions that, when executed by one or more hardware processors, cause to perform any operation described herein and / or recited in any of the claims.

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

[0218] Any combination of the features and functions described herein may be used according to one or more embodiments. In the foregoing description, embodiments have been described with reference to numerous specific details that may vary depending on the implementation. Therefore, the description and drawings should be considered illustrative rather than restrictive. The sole and exclusive measure of the scope of this disclosure, and what the applicant intends to define as the scope of this disclosure, is the literal and equivalent scope of the set of claims issued in this application, in the specific form of such claims, including any subsequent corrections.

Claims

1. One or more non-transitory computer-readable media including instructions that, when executed by one or more hardware processors, cause to perform operations, including: Receive a command from a customer operator associated with a cloud service provider (CSP) to disable the CSP operator's access to the first set of resources in the customer's cloud environment; This allows CSP operators to access the first set of resources in a customer's cloud environment based on a set of permitted permissions; and In response to the command, perform one or more of the following: Terminate one or more existing sessions that provide access to a first set of resources in a customer's cloud environment to a CSP operator, wherein the one or more existing sessions are established at least in part based on the set of permissions; Deny one or more new requests for credentials used to establish a session that grants access to a first set of resources in a customer's cloud environment to a CSP operator, wherein the new request for credentials is made at least in part based on said set of permissions; or Revoke existing credentials used to establish a session granting a CSP operator access to a first set of resources in a customer's cloud environment, wherein the existing credentials were granted at least in part based on said set of permissions.

2. One or more non-transitory computer-readable media as described in claim 1: The termination of an existing session is performed by a bastion service configured to provide a set of bastion instances through which existing sessions are established. The bastion service records information associated with the existing session to generate recorded information, which includes at least one of the following: (a) Whether the requester of the session is a CSP operator, or (b) Whether the session is a connection to the customer's cloud environment; The bastion service identifies existing sessions to be terminated based on recorded information; The bastion service terminates the identified session.

3. One or more non-transitory computer-readable media as claimed in claim 1, wherein the rejection of the one or more new requests for the credentials is performed by a permissions service configured to manage the set of permissions.

4. One or more non-transitory computer-readable media as claimed in claim 1, wherein the revocation of existing credentials is performed by a permissions service configured to manage the set of permissions.

5. The one or more non-transitory computer-readable media of claim 1, wherein the command requests to disable the CSP operator's access to all resources in the customer's cloud environment, and one or more of the following are executed: (a) Terminate all existing sessions; (b) Refuse all new requests for credentials; or (c) Revoke all existing credentials.

6. The one or more non-transitory computer-readable media of claim 1, wherein the command requests to disable CSP operator access to a subset of resources in the customer's cloud environment, and one or more of the following are executed: (a) Terminate a subset of existing sessions corresponding to a subset of the resources; (b) Reject a subset of new requests for credentials corresponding to a subset of the resources; or (c) Revoke the subset of existing credentials corresponding to a subset of the resources.

7. The one or more non-transitory computer-readable media as described in claim 1, wherein the command is associated with a specified time period, and the operation further includes: After the specified time period ends, reverse one or more of the following: (a) Terminate the existing session; (b) Deny new requests for credentials; or (c) Revoke existing vouchers.

8. One or more non-transitory computer-readable media as claimed in claim 1, wherein the command sets a flag in a database that is accessible by one or more of: (a) a bastion service configured to supply a set of bastion instances through which existing sessions are established; or (b) a permissions service configured to manage said set of permissions.

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

10. One or more non-transitory computer-readable media as claimed in claim 1, wherein terminating access to the CSP operator applies to the first CSP operator and does not terminate access to the second CSP operator.

11. One or more non-transitory computer-readable media as claimed in claim 1, wherein the CSP is a first entity, the CSP's customer is a second entity, and the CSP's customer provides cloud services to end users associated with a third entity.

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

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

14. A system comprising components for performing the operations as described in any one of claims 1-12.

15. A system comprising: At least one device including a hardware processor; The system is configured to perform the operations described in any one of claims 1-12.

Images