Permission Brokering

Abstract

Described herein is a framework for managing credentials for access to a secured entity of an infrastructure service, in which a computing system performs operations including receiving a request to perform an action from a customer device, determining a subscriber corresponding to the customer device, determining that the subscriber has granted the customer device permission to perform the action, generating a credential for accessing the secured entity on behalf of the customer device, maintaining the credential separate from the customer device, and using the credential to perform the action on behalf of the customer device.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Non-Provisional Patent Application No. 17 / 571,338, entitled "Authorization Brokering," filed on January 7, 2022, the entire disclosure of which is incorporated herein by reference for all purposes.

[0002] Field The present disclosure relates to a framework for managing credentials used to access secure entities of infrastructure services. [Background technology]

[0003] background A cloud service provider (CSP) uses different systems and infrastructure services to provide a variety of services to users or customers on demand. CSPs provide infrastructure services that customers can use to build their networks and deploy customer resources. In order for a customer to be given access to a CSP, the customer may need to provide the CSP with credentials that grant the customer access.

[0004] Traditional approaches to credentials to access a CSP require the CSP to provide credentials to the customer, which are then provided by the customer to the CSP upon request for services to gain access to the CSP. Credentials provided to the customer can be used by fraudsters to perform unauthorized actions against the CSP. Thus, credentials shared with the customer can be a weak point within the CSP. Summary of the Invention [Means for solving the problem]

[0005] overview The present disclosure generally relates to a framework for managing credentials for access to computing systems, such as cloud infrastructure services. Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, codes or instructions executable by one or more processors, and the like. These exemplary embodiments are mentioned not to limit or define the disclosure, but to provide examples to aid in understanding the disclosure. Additional embodiments are described in the detailed description section, where further description is provided.

[0006] One aspect of the disclosure is directed to one or more non-transitory computer-readable media having instructions stored thereon that, when executed by a computing system, can cause the computing system to receive a request to perform an action from a customer device, the request including an identifier of the customer device and an action to be performed by a secured entity. The instructions can further cause the computing system to determine a subscriber corresponding to the customer device based at least in part on the identifier of the customer device, and to determine that the subscriber has granted the customer device permission to perform the action. The instructions can also cause the computing system to generate a credential for access to the secured entity on behalf of the customer device based at least in part on determining that the customer device has permission to perform the action, maintain the credential separate from the customer device, and use the credential to perform the action on behalf of the customer device.

[0007] One aspect of the disclosure is directed to a computing system including a memory for storing one or more credentials and one or more processors coupled to the memory, where the one or more processors can receive a request for performance of an action by a secured entity, the request being received from a customer device. The one or more processors can further determine a subscriber corresponding to the customer device based at least in part on an identifier of the customer device, and determine that the subscriber has granted the customer device permission to perform the action. The one or more processors can further generate a credential for access to the secured entity based at least in part on determining that the subscriber has granted the customer device permission to perform the action, and store the credential in the memory, where the credential is stored separately from the customer device, and where the one or more processors can use the credential to perform the action on behalf of the customer device.

[0008] One aspect of the present disclosure is directed to a method of performing an action with a secured entity, the method including a broker receiving a request from a customer device for the action to be performed by the secured entity and the broker determining that the customer device is authorized to perform the action. The method may further include the broker generating a credential for access to the secured entity based at least in part on the determination that the customer device is authorized to perform the action, and the broker using the credential to have the secured entity perform the action on behalf of the customer device.

[0009] The above, together with other features and embodiments, will become more apparent with reference to the following specification, claims and accompanying drawings.

[0010] The features, embodiments and advantages of the present disclosure will become better understood from the following Detailed Description, when read in conjunction with the accompanying drawings. [Brief description of the drawings]

[0011] [Figure 1] FIG. 2 illustrates an example infrastructure service configuration, according to an embodiment. [Diagram 2] FIG. 2 illustrates an example access configuration, according to an embodiment. [Diagram 3] FIG. 2 illustrates an example procedural flow for customer device registration, according to an embodiment. [Figure 4] FIG. 1 illustrates an example procedural flow for action execution, according to an embodiment. [Diagram 5] FIG. 2 illustrates an example procedural flow for key refresh, according to an embodiment. [Figure 6] FIG. 2 illustrates an example procedure for the execution of an action, according to an embodiment. [Figure 7] FIG. 13 illustrates another example procedure for execution of an action, according to an embodiment. [Figure 8] FIG. 13 illustrates another example procedure for execution of an action, according to an embodiment. [Figure 9] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 10] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, in accordance with at least one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, in accordance with at least one embodiment. [Figure 12] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, in accordance with at least one embodiment. [Figure 13] FIG. 1 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0013] This disclosure describes techniques for managing credentials for access to and / or performance of actions by infrastructure services (cloud infrastructure services, e.g., the cloud infrastructure of FIG. 9, the cloud infrastructure of FIG. 10, the cloud infrastructure of FIG. 11, and / or the cloud infrastructure of FIG. 12) provided by a cloud service provider (CSP). More specifically, to be granted access to a secured entity in the infrastructure service, the secured entity can examine the credentials to determine whether the actor is authorized to perform an action by the secured entity. The infrastructure service, or a portion thereof, can cooperate with the secured entity and the customer device to generate a credential for the customer device. The infrastructure service, or a portion thereof, can maintain the credential rather than providing the credential to the customer device. The infrastructure service, or a portion thereof, can use the credential on behalf of the customer device to perform actions requested by the customer device without the customer device having access to the credential. Thus, the credential can remain in a trusted environment, such as a customer device, without being provided to an untrusted environment. By maintaining the credential in a trusted environment, an unauthorized actor is less likely to obtain and / or use the credential to access the secured entity.

[0014] A CSP can provide various services to customers on demand using different systems and infrastructure services (referred to herein as cloud infrastructure services). In an embodiment, a CSP can provide services under an Infrastructure-as-a-Service (IaaS) model, where the CSP provides infrastructure services that customers can use to build their networks and deploy customer resources. The CSP-provided infrastructure can include interconnected high-performance computer resources, including various host machines (also referred to as hosts), memory resources, and network resources, that form a physical network called a substrate network or underlay network. The CSP-provided infrastructure can be distributed across one or more data centers, which can be geographically distributed across one or more regions.

[0015] The CSP's physical network, which may include various host machines, memory resources, and / or network resources, may provide the basis for creating one or more virtual or overlay networks on top of the physical network. These virtual or overlay networks (also called software-based or software-defined networks) may be implemented using software virtualization techniques to create a layer of network abstraction that can run on top of the physical network. Overlay networks can take many forms. Overlay networks may use Layer 3 IP addressing with endpoints specified by virtual IP addresses in those networks. This method of overlay networking is often referred to as virtual Layer 3 networking.

[0016] When a customer subscribes or registers for an IaaS service offered by a CSP, a tenancy can be created for that customer, where a tenancy is a secure, isolated division within the CSP's infrastructure service where the customer can create, organize, and manage their cloud resources. For example, a customer can use the resources offered by the CSP to build one or more customizable private virtual networks called virtual cloud networks (VCNs) within the customer's tenancy. One or more customer resources, such as compute instances (e.g., virtual machines, bare metal instances, etc.), can be deployed onto these customer VCNs.

[0017] When a customer attempts to access the infrastructure service to set up a tenancy or perform other actions, the customer may send a request to the infrastructure service to set up a tenancy or perform other actions. The infrastructure service may receive the request and determine that the customer is requesting the infrastructure service to perform an action with a secured entity within the infrastructure service. Based on the action, the infrastructure service may generate a credential associated with the customer that grants access to the secured entity. The infrastructure service may use the credential to perform the requested action on behalf of the customer without providing the credential to the customer. Thus, the credential may remain within the infrastructure service, which provides protection for the credential.

[0018] FIG. 1 illustrates an example infrastructure service configuration 100 according to an embodiment. In particular, the infrastructure service configuration 100 illustrates a portion of an infrastructure service that may implement one or more of the approaches for maintaining credentials described throughout this disclosure. In an embodiment, the infrastructure service may include one or more of the features of the cloud infrastructure of FIG. 9, the cloud infrastructure of FIG. 10, the cloud infrastructure of FIG. 11, and / or the cloud infrastructure of FIG. 12. The infrastructure service may include a computing system. In an embodiment, the infrastructure service may include a cloud computing system. The infrastructure service may include infrastructure hardware and / or software that may provide services to customers.

[0019] An infrastructure service may include one or more devices 102 communicatively coupled to provide a portion of the infrastructure service. For example, in the illustrated embodiment, the infrastructure service configuration 100 includes a first device 102a, a second device 102b, and a third device 102c. The devices 102 may include computing devices such as computer terminals, servers, other computing devices, or some combination thereof. The devices 102 may communicate with each other to form part of the infrastructure service, where the infrastructure service may provide an infrastructure service such as a cloud infrastructure service.

[0020] The devices 102 can be grouped into different enclaves. For example, a first device 102a, a second device 102b, and a third device 102c can form part of an infrastructure service enclave 104. Each of the infrastructure service enclaves can form its own secured entity or can be part of a secured entity that includes multiple enclaves. The enclaves 104 can perform specific operations. For example, the enclaves 104 can include a management enclave that provides management operations, a service enclave that provides service operations, or a customer enclave that provides customer operations to customers. The enclaves 104 can implement a software-defined perimeter (SDP) security model to create a protected IaaS instance. The enclave 104 may have a defined SDP that includes one or more devices (such as the first device 102a, the second device 102b, and the third device 102c) and / or certain software, and the boundaries of the enclave 104 are defined by the isolation of the devices and / or software from elements outside the enclave 104. The enclave 104 may have a unique communication profile that may differ from other communication profiles of different enclaves in the infrastructure service. Access into and out of the enclave 104 may be controlled, monitored, and / or policy driven. For example, access to the enclave 104 may be based on authorization, in which case access to the enclave 104 may be limited to authorized customers. The enclave 104 may determine authorization for access to the enclave 104 based on one or more credentials provided to the enclave 104.

[0021] The infrastructure services may include one or more security brokers, such as broker 106. Broker 106 may include a device, software, or some combination thereof. Broker 106 may be located at the boundary of enclave 104. For example, broker 106 may be located at the boundary of enclave 104 to enable communication with broker 106 without accessing a secured portion of enclave 104.

[0022] The broker 106 may receive a registration request from a client. The registration request may include an identifier for the client, which the broker 106 may use to determine that future requests received are from the client. In one embodiment, the identifier may include a key (e.g., a public key) corresponding to the client. The broker 106 may store the identifier received from the client for future use in identifying the client.

[0023] In some cases, the registration request may further include an indication of the subscriber with whom the customer is requesting association. For example, a subscriber to the infrastructure service may have previously set up a tenancy within the infrastructure service. The customer may indicate that the customer should be associated with the subscriber and should operate with the tenancy created by the subscriber. The broker 106 may perform authentication and / or authorization procedures to verify that the customer is authorized to be associated with the subscriber and to operate with the tenancy created by the subscriber. If the broker 106 determines that the customer is authorized to be associated with the subscriber, the broker 106 may allow the customer to operate with the tenancy associated with the subscriber. In certain other cases, the broker 106 may operate using another portion of the infrastructure service to generate a tenancy for the customer based on the registration request. In cases where the broker 106 generates a tenancy for the customer based on the registration request, the customer may act as a subscriber to the infrastructure service.

[0024] After or in addition to registering a customer, the customer may send a request to the infrastructure service to perform an action. The broker 106 may receive the request and determine that the customer is requesting an action based on an identifier of the customer included in the request. The broker 106 may determine whether the customer is authorized to perform the action with the infrastructure service. For example, the broker 106 or another part of the infrastructure service may maintain a group of one or more actions or types of actions that the subscriber is authorized to perform with the infrastructure service, or a group of one or more actions or types of actions that the subscriber is authorized to perform with the infrastructure service. The broker 106 may compare the requested action with the actions or types of actions authorized for the customer to determine whether the requested action corresponds to the authorized action or type of action. If the broker 106 determines that the requested action does not correspond to the authorized action or type of action, the broker 106 may prevent the action from being performed for the customer. If the broker 106 determines that the requested action corresponds to the authorized action or type of action, the broker 106 may proceed toward performing the operation.

[0025] Based on the action, the broker 106 can determine which service of the infrastructure services should be used to perform the requested action on behalf of the customer. For example, the broker 106 can determine that the action should be performed by a service in the enclave 104. The broker 106 can collaborate with the enclave 104 to generate a credential for access to the enclave 104. In an embodiment, the credential can be a token, a key, or some combination thereof. The credential can also be signed by the enclave 104 in an embodiment. The credential can be presented to the enclave 104 so that the enclave 104 can determine whether to grant access to the requester. In an embodiment, the broker 106 can send a request to the enclave 104 for the generation of a credential. The request for the generation of a credential can include an identifier of the customer in an embodiment. The enclave 104 can respond to the request with a key (sometimes referred to herein as a “proof key”) that the broker 106 uses to generate the credential. The broker 106 can use the proof key to generate a credential for access to the enclave 104. For example, in one embodiment, the broker 106 can generate a credential based on the proof key and a customer identifier. In some cases, rather than requesting the proof key at the time of the request, the broker 106 can have previously received the proof key from the enclave 104 and use the previously received proof key to generate the credential.

[0026] Once generated, the broker 106 may store the credential. For example, the broker 106 may store the credential in association with the customer, such as the credential being stored by the broker 106 with an association with an identifier for the customer. Unlike conventional approaches, the broker 106 may maintain the credential separate from the customer. Specifically, the broker 106 may not provide the credential to the customer. Thus, the credential may remain stored by the broker 106 rather than being provided to the customer for storage. The broker 106 and the enclave 104 may be part of a trusted environment, where an operator of the infrastructure service may manage the security of the trusted environment and may have a higher confidence in the security of the data managed in the trusted environment. The customer may be separate from the trusted environment, where the customer may be managed by an entity separate from the operator of the infrastructure service, where the operator of the infrastructure service may not manage the security of the customer. Because the customer is isolated from the trusted environment, there may be a higher probability that a fraudster (which may include the customer) can use credentials provided to the customer to perform unauthorized actions with the infrastructure service and / or derive proof tokens from credentials provided to the customer than if the credentials were maintained within the trusted environment.

[0027] In one embodiment, the broker 106 can store the credential with an association with the actions or types of actions for which the customer has permission. For example, the broker 106 can identify the actions or types of actions for which the customer has permission, such as the actions or types of actions for which the corresponding subscriber has given the customer permission. The broker 106 can store the credential with an indication of the actions or types of actions for which the customer has permission. The broker 106 can then limit the use of the credential to the actions or types of actions for which the customer has permission. Limiting the use of the credential to the actions or types of actions for which the customer has permission can be in contrast to traditional approaches in which a customer is provided with a credential. Specifically, a credential provided to a customer in traditional approaches can grant the customer access to the enclave 104 without limiting the actions that the customer can perform with the enclave 104. By the broker 106 limiting the use of a credential to an action or type of action, the broker 106 can prevent a customer from using the credential to perform unauthorized actions with the enclave 104, whereas a traditional approach of providing a credential to a customer would not prevent a customer from using the credential to perform unauthorized actions with the enclave 104.

[0028] The broker 106 can then use the credentials to perform the action requested by the customer. Specifically, rather than the customer performing the action with the enclave 104, the broker 106 can perform the action with the enclave 104 on behalf of the customer. For example, the broker 106 can provide a request for an action requested by the customer to the enclave 104 along with the credentials that grant access to the enclave 104. The service in the enclave 104 can perform the action and respond to the broker 106 with a result of the action. The broker 106 can forward the result of the action to the customer after the action is performed. Having the broker 106 perform the action on behalf of the customer rather than the customer performing the action with the enclave 104 can prevent unauthorized actions from being performed by the customer. For example, if the customer is able to perform the action with the enclave 104, the customer can receive authorization for the performance of one action and then request that the enclave 104 perform a different action. The broker 106 may maintain the same requested action for both authorizing the action and performing the action, thereby preventing the action from being changed between authorizing and performing the action.

[0029] After the action is completed and / or the customer terminates the session with the broker 106, the broker 106 may, in some embodiments, delete the credential from storage. For example, the broker 106 may determine that the action is completed and / or the customer terminates the session. The session between the broker 106 and the customer may be terminated based on the customer signing out of the broker 106, or the connection between the broker 106 and the customer being terminated, or some combination thereof. Based on a determination that the action is completed and / or the customer terminates the session, the broker 106 may delete the credential. Thus, in some embodiments, the credential may be temporary. Even if a fraudster manages to gain access to the broker after the action is completed and / or the customer terminates the session, the broker 106 will no longer have the credential and the fraudster will not be able to steal the credential that would give access to the enclave 104.

[0030] While infrastructure service configuration 100 illustrates some embodiments of infrastructure services, it should be understood that other embodiments of infrastructure services having features of infrastructure service configuration 100 are within the scope of this disclosure. For example, an enclave (such as enclave 104) can be formed by one or more devices and / or one or more devices may be included in multiple enclaves. Also, an infrastructure service can include multiple enclaves rather than the single enclave illustrated. Each enclave can further include multiple security elements, where each of the multiple security elements can be accessible by any of the customers, each of the security elements can be dedicated to a corresponding customer such that the corresponding customer can access the corresponding security element, or some combination thereof.

[0031] Also, while the enclave of infrastructure services configuration 100 is described in the illustrated embodiment as a secured entity, it should be understood that in other embodiments the secured entity may be a different part of infrastructure services configuration 100. For example, the secured entity of infrastructure services configuration 100 may be any part of infrastructure services configuration 100 that requires a credential for access. Additionally, while broker 106 is shown in the illustrated embodiment as a stand-alone element, it should be understood that in other embodiments broker 106 may be included in one or more elements or combined with one or more elements, such as combined with a security element.

[0032] 2 illustrates an example access configuration 200 according to one embodiment. For example, the access configuration 200 illustrates an example layout of devices to illustrate an authorization broker approach according to one embodiment. It should be understood that the access configuration 200 is one embodiment used to illustrate the approach, and that implementations of the approach are not limited to the example layout shown.

[0033] The access configuration 200 may include an enclave 202. The enclave 202 may include one or more of the features of the enclave 104 (FIG. 1). The enclave 202 may include an infrastructure service, or a portion thereof, such as the infrastructure service described with respect to FIG. 1. The infrastructure service, in an embodiment, may include a computing system, such as a cloud computing system.

[0034] The access configuration 200 may further include a broker 204. The broker 204 may include one or more of the characteristics of the broker 106 (FIG. 1). The broker 204 may correspond to the enclave 202 and have access to the enclave 202 and the execution of actions by the enclave 202. The broker 204 may be located at the boundary of the enclave 202 to enable communication with the broker 204 without providing access to the secure portion of the enclave 202.

[0035] The enclave 202 and the broker 204 may operate within a trusted environment 206. The trusted environment 206 may be defined as an environment that may be controlled by an operator of the infrastructure service. For example, the operator of the infrastructure service may have exclusive control of the trusted environment 206. The operator may control the security of the trusted environment 206, where security may allow only the operator and / or selected users to access the trusted environment 206. The operator who controls the trusted environment 206 may provide more trust to the data stored within the trusted environment 206 than if users not explicitly indicated by the operator could access the trusted environment 206. The trusted environment 206 may include specific hardware, specific software, or some combination of these. Limited access may be provided to the trusted environment 206.

[0036] The access arrangement 200 may further include a customer device 208. The customer device 208 may include a single device, another infrastructure service, or a cloud computing system. The customer device 208 may be maintained by an operator separate from the trusted environment 206. The customer device 208 may communicate with elements in the trusted environment 206 (e.g., the broker 204) over a network, such as the Internet. The customer device 208 may be capable of requesting services to be provided by the enclave 202. A user may access the customer device 208 to request services from the enclave 202. For example, the user may be an individual who can sign in to the customer device 208, where the user signing in to the customer device 208 may authenticate the user's identity.

[0037] A customer device 208 may request to register with the infrastructure service and / or the enclave 202. For example, the customer device 208 may transmit a registration request that includes an identifier of the customer device 208 and / or a user. The registration request may further include an indication of a subscriber with which the customer device 208 requests association, in some cases. The broker 204 may receive the registration request from the customer device 208. The broker 204 may store an identifier of the customer device 208 and / or a user in association with the customer device 208 and / or a user. If the registration request includes an indication of a subscriber, the broker 204 may further determine whether the customer device 208 and / or a user has authorization for the subscriber. For example, the enclave 202 may have subscriber information 210 associated with one or more subscribers stored in the enclave 202. In other embodiments, the subscriber information 210 may be stored within the broker 204 or in another part of the infrastructure service. The broker 204 can obtain subscriber information associated with the subscriber indicated in the registration request from subscriber information 210 and can determine whether the subscriber has authorized the customer device 208 and / or user. If the broker 204 determines that the subscriber has authorized the customer device 208 and / or user, the broker 204 can store an identifier for the customer device 208 and / or user in association with the subscriber.

[0038] In other cases, the customer device 208 may act as a subscriber, in which case the registration request may not include an indication of the subscriber, and the customer device 208 and / or user's subscriber information may be stored in the subscriber information 210. The customer device 208 and / or user's subscriber information may include indications of other customer devices and / or users that may be associated with the subscriber, and actions or types of actions that may be performed in association with the subscriber.

[0039] The customer device 208 may further request that one or more actions be performed by the infrastructure service. For example, the customer device 208 may send a request to perform an action to the infrastructure service, where the request may include an identifier of the customer device 208 and / or a user. The broker 204 may receive the request from the customer device 208. From the request, the broker 204 may identify an identifier of the customer device 208 and / or a user and an action being requested by the customer device 208. Based on the identifier and the action, the broker 204 may determine whether the customer device 208 is authorized to perform the action. For example, the broker 204 may identify a subscriber with which the customer device 208 is associated based on the identifier. The broker 204 may then determine which action or type of action is authorized for the customer device 208 by the subscriber. The broker 204 may determine whether the action being requested by the customer device 208 corresponds to an action and / or type of action for which the customer device 208 has permission. If the broker 204 determines that the action being requested by the customer device 208 does not correspond to an action and / or type of action for which the customer device 208 has permission, the broker 204 may prevent the action from being performed without sharing information about the infrastructure service with the customer device 208.

[0040] If the broker 204 determines that the action requested by the customer device 208 corresponds to an action and / or type of action for which the customer device 208 has permission, the broker 204 may proceed to perform the action. For example, the broker 204 may coordinate with the enclave 202 to generate a credential to access the enclave 202. The broker 204 may send a request to the enclave 202 to generate a credential. The request to generate a credential may include an identifier of the customer device 208 and / or a user in one embodiment. The enclave 202 may respond to the request with a key that is used by the broker 204 to generate the credential. The broker 204 may use the key to generate the credential. In one embodiment, the broker 204 may generate the credential based on the key and an identifier of the customer device 208 and / or a user. In some cases, the broker 204 may have previously received a key from the enclave 202, and the broker 204 may use the previously received key to generate the credential.

[0041] The broker 204 can store the credential with an association with the customer device 208 and / or user. For example, the broker 204 can store the credential with an association with an identifier of the customer device 208 and / or user, in which case the broker 204 can determine to use the credential for an authorized action request that includes the identifier of the customer device 208 and / or user. The broker 204 can maintain the credential separate from the customer device 208, in which case the broker does not provide the credential to the customer device 208. Thus, the broker 204 can maintain the credential within the trusted environment 206, which can provide greater security to prevent a fraudster from accessing the credential and / or deriving a key corresponding to the enclave 202 from the credential.

[0042] In an embodiment, the broker 204 can store the credentials along with an association with actions or types of actions for which the customer device 208 has permission. For example, the broker 204 can identify actions or types of actions for which the customer device 208 and / or user has permission, such as actions or types of actions for which the corresponding subscriber has given the customer permission. The broker 204 can limit use of the credentials to those actions or types of actions for which the customer has permission.

[0043] The broker 204 can use the credentials to perform an action requested by the customer device 208. For example, rather than the customer device 208 performing the action with the enclave 202, the broker 204 can perform the action with the enclave 202 on behalf of the customer device 208. The broker 204 can provide a request for an action requested by the customer device 208 to the enclave 202 along with the credentials that grant access to the enclave 202. A service within the enclave 202 can perform the action based on the request for the action. The enclave 202 can provide the result of the action (confirmation that the action was completed, an indication that the action failed for some reason, and / or one or more values ​​generated by the action) to the broker 204. The broker 204 can then provide the result of the action to the customer device 208.

[0044] In an embodiment, the broker 204 may delete the credentials from storage after the action is completed and / or the customer device 208 has ended the session with the broker 204. For example, the broker 204 may determine that the action is completed and / or the customer has ended the session. The session between the broker 204 and the customer device 208 may end based on the customer device 208 providing a request to end the session, the connection between the broker 204 and the customer device 208 being terminated, or some combination thereof. The broker 204 may delete the credentials based on a determination that the action is completed and / or the session is ended.

[0045] 3 illustrates an example procedural flow 300 for customer device registration, according to an embodiment. For example, procedural flow 300 illustrates example operations that may be performed by customer device 302 and broker 304 upon registration of customer device 302, according to an embodiment. Customer device 302 may include one or more of the features of customer device 208 (FIG. 2). Broker 304 may include one or more of the features of broker 106 (FIG. 1) and / or broker 204 (FIG. 2). It should be understood that the illustrated operations are an example of one embodiment, and that in other embodiments, the operations may be performed in a different order, one or more of the operations may be performed simultaneously, additional operations may be included in procedural flow 300, and / or one or more of the operations may be omitted from procedural flow 300.

[0046] To begin the procedure flow 300, a user of the customer device 302 may request that the customer device 302 register with an infrastructure service (such as the infrastructure service described with respect to FIG. 1 and / or FIG. 2 ) that includes a broker 304. The customer device 302 may send a registration request 306 to the broker 304 to register with the infrastructure service. The registration request 306 may include an identifier of the customer device 302 and / or the user of the customer device 302. The registration request 306 may indicate to the broker 304 that the customer device 302 and / or the user of the customer device 302 wishes to register with the infrastructure service. In some cases, the registration request 306 may further include an indication of a subscriber with which the customer device 302 and / or the user of the customer device 302 wishes to be associated.

[0047] The broker 304 may receive a registration request 306 from the customer device 302. The broker 304 may perform authentication and / or authorization procedures 308 for the customer device 302 based on the registration request 306. For example, if the registration request 306 includes an indication of a subscriber with which the customer device 302 and / or the user of the customer device 302 wants to be associated, the broker 304 may identify information associated with the subscriber, which may include indications of customer devices and / or users with which the subscriber grants permission to associate, based on the identifiers received in the registration request. The broker 304 may determine whether the customer device 302 and / or the user of the customer device 302 is included among the customer devices and / or users with which the subscriber grants permission to associate, based on the identifiers received in the registration request. In some cases, the subscriber may include one or more authentication procedures (such as a passcode check, token authentication, multi-factor authentication, or some combination thereof) that the customer device 302 must complete in order for the customer device 302 and / or the user of the customer device 302 to prove its identity.

[0048] In some cases, the customer device 302 may act as a subscriber via a registration request 306. For example, the registration request 306 sent by the customer device 302 may be part of a procedure whereby the customer device 302 subscribes to and / or creates tenancy with an infrastructure service. In these cases, an indication of the subscriber for association may be omitted from the registration request 306. Additionally, the authentication and / or authorization procedure 308 may be omitted in these cases. In these cases, the registration request 306 or another message may include information about the subscriber, such as information about other customer devices and / or users to whom the customer device 302 will grant authorization for the subscription.

[0049] Based on the broker 304 authenticating the customer device 302 and / or determining authorization, the broker 304 can store the identifier 310. For example, the broker 304 can store the identifier provided in the registration request 306 associated with the customer device 302 and / or the user of the customer device 302. The broker 304 can then use the identifier to identify a transmission from the customer device 302 based on the identifier. If the broker 304 determines that the customer device 302 and / or the user of the customer device 302 can be associated with a subscriber or if the broker 304 acts as a subscriber, the broker 304 can further associate the stored identifier with the subscriber. The broker 304 can then use the identifier to determine that the customer device 302 and / or the user of the customer device 302 can act in association with the subscriber.

[0050] The broker 304 may send a confirmation message 312 to the customer device 302 upon completion of the customer device registration. The confirmation message 312 may indicate whether the customer device 302 and / or the user of the customer device 302 have been successfully registered. For example, the confirmation message 312 may indicate whether the customer device 302 and / or the user of the customer device 302 have been successfully registered based on an identifier being stored in association with the customer device 302 and / or the user of the customer device 302. The confirmation message 312 may further indicate whether the customer device 302 and / or the user of the customer device 302 have been successfully associated with a subscriber. Based on receiving the confirmation message 312, the customer device 302 may indicate whether the customer device registration has been successfully completed.

[0051] FIG. 4 illustrates an example procedural flow 400 for performing an action, according to an embodiment. For example, procedural flow 400 illustrates example operations that may be performed by customer device 402, broker 404, and secured entity 406 upon execution of an action for customer device 402. Customer device 402 may include one or more of the features of customer device 208 (FIG. 2). Broker 404 may include one or more of the features of broker 106 (FIG. 1) and / or broker 204 (FIG. 2). Secure entity 406 may include one or more of the features of enclave 104 (FIG. 1), enclave 202 (FIG. 2), and / or other secured entities described throughout this disclosure. It should be understood that the illustrated operations are an example of one embodiment, and that in other embodiments, operations may be performed in a different order, one or more of the operations may be performed simultaneously, additional operations may be included in procedural flow 400, and / or one or more of the operations may be omitted from procedural flow 400.

[0052] To begin the procedure flow 400, the customer device 402 can send an action request 408 to the infrastructure service. The action request 408 can indicate an action that the customer device 402 is requesting the infrastructure service to perform. Additionally, the action request 408 can further include an identifier of the customer device 402 and / or a user of the customer device 402. The broker 404 can receive the action request 408 at the infrastructure service. Based on the action request 408, the broker 404 can determine an action requested by the customer device 402 and / or an identifier of the customer device 402 and / or a user of the customer device 402.

[0053] The broker 404 can perform action authorization 410 based on the action and the identifier determined from the action request 408. For example, the broker 404 can determine the customer device 402 and / or the user of the customer device 402 based on the identifier. In some cases, the broker 404 can further determine a subscriber associated with the customer device 402 and / or the user of the customer device 402 based on the identifier. For example, the broker 404 can have one or more identifiers stored, and the stored identifiers can indicate the customer device, user, and / or subscriber associated with each of the identifiers. The broker 404 can determine which action or type of action the customer device 402 and / or the user of the customer device 402 has permission to perform. In some cases, the action or type of action the customer device 402 and / or the user of the customer device 402 is authorized to perform can be defined by the subscriber the broker 404 determines to be associated with the customer device 402 and / or the user of the customer device 402. The broker 404 may compare the action requested by the customer device 402 in the action request 408 to the actions and / or types of actions for which the customer device 402 and / or the user of the customer device 402 are authorized to perform to determine whether the customer device 402 and / or the user of the customer device 402 has permission for the action. If the broker 404 determines that the customer device 402 and / or the user of the customer device 402 does not have permission for the action, the broker 404 may prevent the action from being performed. If the broker 404 determines that the customer device 402 and / or the user of the customer device 402 has permission for the action, the broker 404 may proceed to perform the action.

[0054] Based on the broker 404 determining that the customer device 402 and / or a user of the customer device 402 has permission to perform the action, the broker 404 may send a key request 412 to the secured entity 406. The key request 412 may request from the secured entity 406 a key to be used for generation of a credential to be used to access the secured entity 406. In an embodiment, the key request 412 may include an indication of the customer device 402 and / or a user of the customer device 402, an indication of a subscriber associated with the customer device 402 and / or a user of the customer device 402 (e.g., an indication of a tenancy associated with the subscriber), or some combination thereof.

[0055] The secured entity 406 may receive a key request 412 from the broker 404. In an embodiment, the secured entity 406 may verify the customer device 402 and / or the user of the customer device 402, the subscriber, or some combination thereof. For example, the secured entity 406 may verify that the subscriber, the customer device 402, and / or the user of the customer device 402 are authorized to access the secured entity 406. The secured entity 406 may return a key 414 to the broker 404 in response to the key request 412. In an embodiment, the secured entity 406 may return the key 414 further based on the secured entity 406 verifying that the subscriber, the customer device 402, and / or the user are authorized to access the secured entity 406. In an embodiment, the secured entity 406 may indicate a validity period during which the key may be valid for use for accessing the secured entity 406. The key may be used for accessing the secured entity 406. In some cases, the secured entity 406 may have previously provided the key to the broker 404 , in which case the key request 412 and return of the key 414 may be omitted from the procedural flow 400 .

[0056] The broker 404 can receive a key from the secured entity 406. The broker 404 can store the key for generation of a credential that provides access to the secured entity 406. The broker 404 can generate a credential 416 for the customer device 402 for access to the secured entity. In an embodiment, the broker can generate the credential based on an identifier of the customer device 402 and / or the user, subscriber (e.g., tenancy), or some combination thereof of the customer device 402. The broker 404 can store the credential to be used to access the secured entity 406 for performance of an action associated with the customer device 402.

[0057] The broker 404 can send 418 an action request to the secured entity 406 along with the credentials. The broker 404 can request the secured entity 406 to perform the action requested by the customer device 402 in the action request 408. The secured entity 406 can receive the action request from the broker 404. The secured entity 406 can determine that access to the secured entity 406 should be permitted based on the credentials. The secured entity 406 can perform the action based on the action request and the credentials. Because the broker 404 requests the action and the secured entity 406 performs the action in response to a request from the broker 404, the broker 404 can cause the action to be performed on behalf of the customer device 402. Because the broker 404 accesses the secured entity 406 rather than the customer device 402, the broker 404 can store the credentials without having to provide the credentials to the customer device 402 for the action to be performed. By storing the credentials separately from the customer device 402, the credentials can be maintained in a trusted environment that includes the broker 404 and the secure entity 406, thereby providing protection against fraudsters obtaining the credentials and / or deriving keys from the credentials.

[0058] The secured entity 406 may provide a confirmation message 420 to the broker 404. If the secured entity 406 completes the action requested by the broker 404, the confirmation message 420 may indicate that the action was performed. In some cases, the confirmation message 420 may further include a result of the action, such as a value produced by the action. The broker 404 may receive the confirmation message 420 from the secured entity 406 and may store the information included in the confirmation message 420.

[0059] The broker 404 may provide a confirmation message 422 to the customer device 402. If the secured entity 406 completes the action and provides a confirmation message 420, the confirmation message 422 sent by the broker 404 to the customer device 402 may include information from the confirmation message 420 or may be the confirmation message 420 forwarded to the customer device 402. If the broker 404 determines that the customer device 402 is not authorized for the action, the confirmation message 422 may indicate to the customer device 402 that the action was not performed.

[0060] FIG. 5 illustrates an example process flow 500 for key refresh, according to an embodiment. For example, process flow 500 illustrates example operations that can be performed by broker 502 and secured entity 504 to refresh a key used to generate a credential to access secured entity 504, according to an embodiment. The key to be refreshed may have been previously provided to broker 502 by secured entity 504, such as the key provided in process flow 400 (FIG. 4). Broker 502 may include one or more of the features of broker 108 (FIG. 1) and / or broker 204 (FIG. 2). Secure entity 504 may include one or more of the features of enclave 104 (FIG. 1), enclave 202 (FIG. 2), and / or other secured entities described throughout this disclosure. It should be understood that the actions shown are examples of one embodiment and that in other embodiments the actions may be performed in a different order, one or more of the actions may be performed simultaneously, additional actions may be included in procedural flow 500, and / or one or more of the actions may be omitted from procedural flow 500.

[0061] The procedural flow 500 may begin with the broker 502 determining that a key's validity period has expired 506. For example, if the secured entity 504 previously provided a key to the broker 502, the secured entity 504 may have indicated a validity period when the provided key will expire and / or a validity period for which the key will remain valid. The broker 502 may determine that the validity period of the key indicated by the secured entity 504 has expired.

[0062] Based on the broker 502 determining that the key's validity period has expired, the broker 502 may send a key refresh request 508 to the secured entity 504. The key refresh request 508 may request a new key to be used to access the secured entity 504. In an embodiment, the key refresh request 508 may further indicate that a previously provided key has expired and / or the value of the previously provided key. The key refresh request 508 may indicate that the requested key replaces the previously provided key.

[0063] The secured entity 504 may receive a key refresh request 508 from the broker 502. The secured entity 504 may generate a new key for accessing the secured entity based on the key refresh request 508. The key may be generated by the secured entity 504 and may be used to generate one or more credentials for accessing the secured entity 504. The secured entity 504 may return a key 510 to the broker 502. In an embodiment, the secured entity 504 may further indicate a validity period for the new key with the return of the key. The broker 502 may store the key and / or the validity period for the key provided by the secured entity 504. The broker 502 may use the key to generate one or more credentials for accessing the secured entity 504.

[0064] FIG. 6 illustrates an example procedure 600 for performing an action, according to an embodiment. The process (e.g., procedure 600) is illustrated as a logic flow diagram in which each operation can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0065] Procedure 600 can be performed by a broker (such as broker 106 (FIG. 1) and / or broker 204 (FIG. 2)) or another part of an infrastructure service (such as the infrastructure services described with respect to FIG. 1, which may include computing systems and / or cloud computing systems, the cloud infrastructure of FIG. 10, the cloud infrastructure of FIG. 11, the cloud infrastructure of FIG. 12, and / or the cloud infrastructure of FIG. 13, etc.). Procedure 600 can be performed for the performance of an action requested by a customer device (such as customer device 208 (FIG. 2)).

[0066] For simplicity, the procedure 600 is described herein as being performed by a computing system, but it should be understood that the procedure 600 may be performed by an infrastructure service, a broker, or some combination thereof. In an embodiment, the computing system may include a cloud infrastructure service.

[0067] At 602, a computing system may implement a broker. For example, the computing system may implement the broker at a boundary of a secured entity. In one embodiment, the secured entity may be an enclave of the computing system (e.g., enclave 104 (FIG. 1) and / or enclave 202 (FIG. 2)). The computing system may implement the broker at a boundary of an enclave in one embodiment. In some embodiments, 602 may be omitted.

[0068] At 604, the computing system may receive a request to perform an action. For example, the computing system may receive a request to perform an action from a customer device. The request may include an identifier for the customer device and / or a user of the customer device and an action to be performed by the secured entity. In an embodiment, the action may be a request to write a billing record for a subscriber, and the billing record may indicate a number of resources consumed.

[0069] At 606, the computing system can determine a subscriber. For example, the computing system can determine a subscriber corresponding to a customer device based at least in part on an identifier of the customer device. The computing system can store one or more identifiers and their association with subscribers. The computing system can compare the identifier received from the customer device to the stored identifiers and determine a subscriber associated with the customer device based on the comparison.

[0070] At 608, the computing system may determine that the subscriber has granted permission to perform the action. For example, the computing system may determine that the subscriber has granted permission to the customer device to perform the action. In an embodiment, determining that the subscriber has granted permission to the customer device to perform the action may include determining one or more actions for which the subscriber has granted permission to the customer device. The computing system may determine that the action indicated by the request is included in the one or more actions.

[0071] At 610, the computing system may generate a credential. For example, the computing system may generate a credential to access a secured entity on behalf of the customer device based at least in part on determining that the customer device has permission to perform the action. In one embodiment, generating the credential may include using a key corresponding to the secured entity to generate the credential. The computing system may have received the key from the secured entity. In one embodiment, the credential may be generated by a broker implemented at 602.

[0072] At 612, the computing system may maintain the credentials. For example, the credentials may be maintained separately from the customer device. In an embodiment, the computing system and the secure entity may be located in a trusted environment (such as trusted environment 206 (FIG. 2)). Maintaining the credentials separately from the customer device may include maintaining the credentials in the trusted environment. In an embodiment, the broker implemented at 602 may maintain the credentials separately from the customer device.

[0073] At 614, the computing system can use the credentials to perform an action. For example, the computing system can use the credentials to perform an action on behalf of the customer device. In an embodiment, the computing system can provide the credentials to a secured entity to gain access to the secured entity. The computing system can also request the secured entity to perform an action. The secured entity can perform the action based on the request from the computing system. In an embodiment, the broker implemented at 602 can use the credentials to perform an action on behalf of the customer device.

[0074] At 616, the computing system may determine that the validity period of the key has expired. For example, the computing system may determine that the validity period of the key received from the secured entity has expired. When providing the key, the secured entity may indicate a validity period during which the key may be used to generate credentials. In some embodiments, 616 may be omitted.

[0075] At 618, the computing system may refresh the key. For example, the computing system may refresh the key with the secured entity based at least in part on determining that the key's validity period has expired. The computing system may provide a request for a new key to the secured entity to refresh the key. In some embodiments, 618 may be omitted.

[0076] At 620, the computing system can maintain the refreshed key. For example, the computing system can maintain the refreshed key separate from the customer device. The computing system can receive a new key from the secure entity and store the new key as the refreshed key. The computing system can maintain the credential separate from the customer device by maintaining the credential in a trusted environment.

[0077] FIG. 7 illustrates another exemplary procedure 700 for performing an action, according to an embodiment. The process (e.g., procedure 700) is illustrated as a logic flow diagram in which each operation can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0078] Procedure 700 can be performed by a broker (such as broker 106 (FIG. 1) and / or broker 204 (FIG. 2)) or another part of an infrastructure service (such as the infrastructure services described with respect to FIG. 1, which may include computing systems and / or cloud computing systems, the cloud infrastructure of FIG. 10, the cloud infrastructure of FIG. 11, the cloud infrastructure of FIG. 12, and / or the cloud infrastructure of FIG. 13, etc.). Procedure 700 can be performed for execution of an action requested by a customer device (such as customer device 208 (FIG. 2)).

[0079] For simplicity, the methodology 700 is described herein as being performed by a computing system, but it should be understood that the methodology 700 may be performed by an infrastructure service, a broker, or some combination thereof. In an embodiment, the computing system may include a cloud infrastructure service.

[0080] At 702, a computing system may implement a broker. For example, the computing system may include a cloud infrastructure service. The cloud infrastructure service may include a secured entity. In one embodiment, the secured entity may be an enclave within the cloud infrastructure service. The computing system may implement the broker at a boundary of the secured entity. In some embodiments, 702 may be omitted.

[0081] At 704, the computing system may receive a request to perform an action. For example, the computing system may receive a request to perform an action by a secured entity, where the request may be received from a customer device. The request may include an identifier for the customer device and / or a user of the customer device and an action to be performed by the secured entity. In an embodiment, the action may be a request to write a billing record for a subscriber, where the billing record may indicate a number of resources consumed.

[0082] At 706, the computing system can determine a subscriber. For example, the computing system can determine a subscriber corresponding to a customer device based at least in part on an identifier of the customer device. The computing system can store one or more identifiers and their association with subscribers. The computing system can compare the identifier received from the customer device to the stored identifiers and determine a subscriber associated with the customer device based on the comparison.

[0083] At 708, the computing system may determine that the subscriber has granted permission to perform the action. For example, the computing system may determine that the subscriber has granted permission to the customer device to perform the action. In an embodiment, determining that the subscriber has granted permission to the customer device to perform the action may include determining one or more actions for which the subscriber has granted permission to the customer device. The computing system may determine that the action indicated by the request is included in the one or more actions.

[0084] At 710, the computing system may retrieve the key. For example, the computing system may retrieve the key from a secured entity. The computing system may request the key from the secured entity based at least in part on a determination that the subscriber has granted the customer device permission to perform the action. In some embodiments, 710 may be omitted.

[0085] At 712, the computing system may generate a credential. For example, the computing system may generate a credential for access to a secured entity based at least in part on a determination that the subscriber has granted the customer device permission to perform the action. In an embodiment, generating the credential may include generating the credential based at least in part on the key. In an embodiment, the broker implemented at 702 may generate the credential for access to the secured entity.

[0086] At 714, the computing system may store the credential. For example, the computing system may store the credential in memory. The credential may be stored separately from the customer device. The computing system and the secure entity may be located in a trusted environment (such as trusted environment 206 (FIG. 2)) in some embodiments. Storing the credential separately from the customer device may include maintaining the credential in the trusted environment.

[0087] At 716, the computing system can use the credentials to perform an action. For example, the computing system can use the credentials to perform an action on behalf of the customer device. The computing system can provide the credentials to the secured entity to gain access to the secured entity and cause the secured entity to perform the action. If the action is entry of a billing record, the computing system can cause the secured entity to enter the billing record. In an embodiment, the broker implemented at 702 can use the credentials to perform the action.

[0088] At 718, the computing system may determine that the validity period of the key has expired. For example, the computing system may determine that the validity period of the key received from the secured entity has expired. When providing the key, the secured entity may indicate a validity period during which the key may be used to generate credentials. In some embodiments, 718 may be omitted.

[0089] At 720, the computing system may refresh the key. For example, the computing system may refresh the key with the secured entity based at least in part on determining that the key's validity period has expired. The computing system may provide a request for a new key to the secured entity to refresh the key. In some embodiments, 720 may be omitted.

[0090] FIG. 8 illustrates another exemplary procedure 800 for performing an action, according to an embodiment. The process (e.g., procedure 800) is illustrated as a logic flow diagram in which each operation can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement a process.

[0091] Procedure 800 can be performed by a broker (such as broker 106 (FIG. 1) and / or broker 204 (FIG. 2)) or another part of an infrastructure service (such as the infrastructure services described with respect to FIG. 1, which may include computing systems and / or cloud computing systems, the cloud infrastructure of FIG. 10, the cloud infrastructure of FIG. 11, the cloud infrastructure of FIG. 12, and / or the cloud infrastructure of FIG. 13, etc.). Procedure 800 can be performed for the performance of an action requested by a customer device (such as customer device 208 (FIG. 2)).

[0092] For simplicity, the procedure 800 is described herein as being performed by a broker, but it should be understood that the procedure 800 can be performed by an infrastructure service, a broker, or some combination thereof. In an embodiment, the computing system may include a cloud infrastructure service.

[0093] At 802, a broker may receive a request to perform an action. For example, the broker may receive a request from a customer device to perform an action by a secured entity. The request may include an identifier of the customer device and an action to be performed by the secured entity. In one embodiment, the action may be a request to write a billing record for a subscriber, and the billing record may indicate a number of resources consumed. In one embodiment, the secured entity may be an enclave. The broker may receive the request to perform the action at a boundary of the enclave.

[0094] At 804, the broker may determine that the customer device is authorized to perform the action. In an embodiment, determining that the customer device is authorized to perform the action may include determining one or more actions for which the subscriber has authorized the customer device. The computing system may determine that the action indicated by the request is included in the one or more actions.

[0095] At 806, the broker may retrieve the key. For example, the broker may retrieve the key from the secured entity. The computing system may request the key from the secured entity based at least in part on a determination that the subscriber has given the customer device permission to perform the action. In some embodiments, 806 may be omitted.

[0096] At 808, the broker may generate a credential. For example, the broker may generate a credential for access to the secured entity based at least in part on determining that the customer device is authorized to perform the action. In an embodiment, generating the credential may include generating the credential based at least in part on the key.

[0097] At 810, the broker can maintain the credential within the trusted environment. For example, the secured entity and the broker can be located within the trusted environment. The customer device can be located outside the trusted environment. The broker can maintain the credential within the trusted environment that includes the secured entity and the broker.

[0098] At 812, the broker can use the credentials to have the secured entity perform an action. For example, the broker can use the credentials to have the secured entity perform an action on behalf of the customer device. The broker can provide the credentials to the secured entity to gain access to the secured entity and have the secured entity perform the action. If the action is to enter a billing record, the broker can have the secured entity enter the billing record.

[0099] At 814, the broker may determine that the validity period of the key has expired. For example, the broker may determine that the validity period of the key received from the secured entity has expired. When providing the key, the secured entity may indicate a validity period during which the key may be used to generate credentials. In some embodiments, 814 may be omitted.

[0100] At 816, the broker may refresh the key. For example, the broker may refresh the key with the secured entity based at least in part on determining that the key's validity period has expired. The broker may provide a request for a new key to the secured entity to refresh the key and may receive the new key based on the request for the new key. In some embodiments, 816 may be omitted.

[0101] As mentioned above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider 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, an IaaS provider can also provide various services (e.g., billing, monitoring, logging, load balancing, and clustering, etc.) that accompany those infrastructure components. Thus, these services can be policy-driven, so that an IaaS user can enforce policies to drive load balancing to maintain application availability and performance.

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

[0103] In most cases, the cloud computing model will require the involvement of a cloud provider, which can be, but is not necessarily, a third-party service that specializes in providing IaaS (e.g., offering, renting, selling). An entity may choose to deploy a private cloud, thereby becoming its own provider of infrastructure services.

[0104] In one embodiment, an IaaS deployment is the process of placing a new application or a new version of an application onto a provisioned application server, etc. It may also include the process of provisioning the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider below the hypervisor layer (e.g., server, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling (OS), middleware, and / or application deployment (e.g., self-service virtual machines (e.g., that can be spun up on demand)).

[0105] In one embodiment, IaaS provisioning can refer to obtaining a computer or virtual host for use and then installing the necessary libraries or services on it. In many cases, deployment does not include provisioning, which may need to occur first.

[0106] In some cases, there are two different challenges in IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before putting anything into production. Second, there is the challenge of evolving the existing infrastructure (e.g. adding new services, modifying services, removing services, etc.) after everything has been provisioned. In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, one or more configuration files can define the infrastructure (e.g. what components are needed and how they interact). Thus, the overall topology of the infrastructure (e.g. what resources depend on which resources and how each of them work together) can be described declaratively. In some cases, after the topology is defined, workflows can be generated that create and / or manage the different components described in the configuration files.

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

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

[0109] 9 is a block diagram 900 illustrating an example pattern of an IaaS architecture in accordance with at least one embodiment. A service operator 902 can be communicatively coupled to a secure host tenancy 904, which can include a virtual cloud network (VCN) 906 and a secure host subnet 908. In one example, the service operator 902 can use one or more customer computing devices, which can be portable handheld devices (e.g., iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass head-mounted displays) running software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and capable of Internet, email, short message service (SMS), Blackberry, or other communications protocols. Alternatively, the customer computing devices may be general purpose personal computers, including, for example, personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The customer computing devices may be workstation computers running any of the various commercially available UNIX or UNIX-like operating systems, including, but not limited to, the various GNU / Linux operating systems, such as Google Chrome OS.Alternatively or additionally, the customer computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating via VCN 906 and / or an Internet-accessible network.

[0110] The VCN 906 may include a local peering gateway (LPG) 910 that may be communicatively coupled to a secure shell (SSH) VCN 912 via an LPG 910 that is included in the SSH VCN 912. The SSH VCN 912 may include an SSH subnet 914, which may be communicatively coupled to a control plane VCN 916 via an LPG 910 that is included in the control plane VCN 916. The SSH VCN 912 may also be communicatively coupled to a data plane VCN 918 via the LPG 910. The control plane VCN 916 and the data plane VCN 918 may be included in a service tenancy 919 that may be owned and / or operated by the IaaS provider.

[0111] The control plane VCN 916 may include a control plane demilitarized zone (DMZ) tier 920 that serves as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers may have limited duties and help thwart intrusions. Additionally, the DMZ tier 920 may include one or more load balancer (LB) subnets 922, a control plane application tier 924 that may include application subnets 926, a control plane data tier 928 that may include database (DB) subnets 930 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 922 included in the control plane DMZ tier 920 can be communicatively coupled to an application subnet 926 included in the control plane application tier 924 and an Internet gateway 934 that may be included in the control plane VCN 916, which can be communicatively coupled to a DB subnet 930 included in the control plane data tier 928 and a service gateway 936 and a network address translation (NAT) gateway 938. The control plane VCN 916 can include the service gateway 936 and the NAT gateway 938.

[0112] The control plane VCN 916 can include a data plane mirrored application tier 940 that can include an application subnet 926. The application subnet 926 included in the data plane mirrored application tier 940 can include a virtual network interface controller (VNIC) 942 capable of running a compute instance 944. The compute instance 944 can communicatively couple the application subnet 926 of the data plane mirrored application tier 940 to the application subnet 926 that can be included in the data plane application tier 946.

[0113] The data plane VCN 918 can include a data plane application layer 946, a data plane DMZ layer 948, and a data plane data layer 950. The data plane DMZ layer 948 can include a LB subnet 922 that can be communicatively coupled to an application subnet 926 of the data plane application layer 946 and an Internet gateway 934 of the data plane VCN 918. The application subnet 926 can be communicatively coupled to a service gateway 936 of the data plane VCN 918 and a NAT gateway 938 of the data plane VCN 918. The data plane data layer 950 can also include a DB subnet 930 that can be communicatively coupled to the application subnet 926 of the data plane application layer 946.

[0114] The internet gateways 934 of the control plane VCNs 916 and the data plane VCNs 918 may be communicatively coupled to a metadata management service 952, which may be communicatively coupled to the public internet 954. The public internet 954 may be communicatively coupled to NAT gateways 938 of the control plane VCNs 916 and of the data plane VCNs 918. The service gateways 936 of the control plane VCNs 916 and of the data plane VCNs 918 may be communicatively coupled to cloud services 956.

[0115] In one embodiment, a service gateway 936 in the control plane VCN 916 or in the data plane VCN 918 can make application programming interface (API) calls to cloud services 956 without traversing the public Internet 954. API calls from the service gateway 936 to the cloud services 956 can be one-way; that is, the service gateway 936 can make API calls to the cloud services 956 and the cloud services 956 can send the requested data to the service gateway 936. However, the cloud services 956 may not originate API calls to the service gateway 936.

[0116] In one embodiment, a secure host tenancy 904 can be directly connected to an otherwise separable service tenancy 919. A secure host subnet 908 can communicate with an SSH subnet 914 through an LPG 910, which can enable bidirectional communication through otherwise separate systems. Connecting the secure host subnet 908 to the SSH subnet 914 can give the secure host subnet 908 access to other entities in the service tenancy 919.

[0117] The control plane VCN 916 can enable users of the service tenancy 919 to configure or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 916 can be deployed or otherwise used in the data plane VCN 918. In one embodiment, the control plane VCN 916 can be separate from the data plane VCN 918, and a data plane mirror application tier 940 of the control plane VCN 916 can communicate with a data plane application tier 946 of the data plane VCN 918 via a VNIC 942, which can be included in the data plane mirror application tier 940 and the data plane application tier 946.

[0118] In one embodiment, a user or customer of the system may make a request, for example, a create, read, update or delete (CRUD) operation, via the public internet 954, which may communicate the request to a metadata management service 952. The metadata management service 952 may communicate the request to the control plane VCN 916 via an internet gateway 934. The request may be received by a LB subnet 922 included in the control plane DMZ layer 920. The LB subnet 922 may determine that the request is valid, and in response to this determination, the LB subnet 922 may send the request to an application subnet 926 included in the control plane application layer 924. If the validity of the request is verified and a call to the public internet 954 is required, the call to the public internet 954 may be sent to a NAT gateway 938, which may make the call to the public internet 954. Memory that may be desired to be stored by the request may be stored in the DB subnet 930.

[0119] In one embodiment, a data plane mirror application layer 940 can facilitate direct communication between the control plane VCN 916 and the data plane VCN 918. For example, it may be desired that configuration changes, updates, or other suitable modifications be applied to resources included in the data plane VCN 918. VNICs 942 enable the control plane VCN 916 to communicate directly with the resources included in the data plane VCN 918, thereby enabling it to perform configuration changes, updates, or other suitable modifications to those resources.

[0120] In an embodiment, the control plane VCN 916 and the data plane VCN 918 may be included in the service tenancy 919. In this case, a user or customer of the system may not own or operate the control plane VCN 916 or the data plane VCN 918. Instead, an IaaS provider may own or operate the control plane VCN 916 and the data plane VCN 918, both of which may be included in the service tenancy 919. This embodiment may allow for network isolation that may prevent a user or customer from interacting with the resources of other users or other customers. This embodiment may also allow a user or customer of the system to store databases privately without having to rely on the public internet 954, which may not have the desired level of threat protection for storage.

[0121] In another embodiment, the LB subnet 922 included in the control plane VCN 916 can be configured to receive signals from the service gateway 936. In this embodiment, the control plane VCN 916 and the data plane VCN 918 can be configured to be called by the IaaS provider's customers without calling the public Internet 954. Customers of the IaaS provider may desire this embodiment because databases used by the customers can be controlled by the IaaS provider and stored on a service tenancy 919 that is separable from the public Internet 954.

[0122] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1002 (e.g., service operator 902 of FIG. 9 ) can be communicatively coupled to a secure host tenancy 1004 (e.g., secure host tenancy 904 of FIG. 9 ), which can include a virtual cloud network (VCN) 1006 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1008 (e.g., secure host subnet 908 of FIG. 9 ). The VCN 1006 can include a local peering gateway (LPG) 1010 (e.g., LPG 910 of FIG. 9 ) that can be communicatively coupled to a secure shell (SSH) VCN 1012 (e.g., SSH VCN 912 of FIG. 9 ) via an LPG 910 included in the SSH VCN 1012. The SSH VCN 1012 can include an SSH subnet 1014 (e.g., SSH subnet 914 in FIG. 9 ), which can be communicatively coupled to a control plane VCN 1016 (e.g., control plane VCN 916 in FIG. 9 ) via an LPG 1010 included in the control plane VCN 1016. The control plane VCN 1016 can be included in a service tenancy 1019 (e.g., service tenancy 919 in FIG. 9 ), and the data plane VCN 1018 (e.g., data plane VCN 918 in FIG. 9 ) can be included in a customer tenancy 1021, which can be owned or operated by a user or customer of the system.

[0123] The control plane VCN 1016 may include a control plane DMZ layer 1020 (e.g., control plane DMZ layer 920 of FIG. 9 ) that may include a LB subnet 1022 (e.g., LB subnet 922 of FIG. 9 ), a control plane application layer 1024 (e.g., control plane application layer 924 of FIG. 9 ) that may include an application subnet 1026 (e.g., application subnet 926 of FIG. 9 ), and a control plane data layer 1028 (e.g., control plane data layer 928 of FIG. 9 ) that may include a database (DB) subnet 1030 (e.g., similar to DB subnet 930 of FIG. 9 ). The LB subnet 1022 included in the control plane DMZ tier 1020 can be communicatively coupled to an application subnet 1026 included in the control plane application tier 1024 and to an Internet gateway 1034 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in the control plane VCN 1016, and the application subnet 1026 can be communicatively coupled to a DB subnet 1030 included in the control plane data tier 1028 and to a service gateway 1036 (e.g., service gateway 636 in FIG. 9 ) and a network address translation (NAT) gateway 1038 (e.g., NAT gateway 938 in FIG. 9 ). The control plane VCN 1016 can include the service gateway 1036 and the NAT gateway 1038.

[0124] The control plane VCN 1016 can include a data plane mirrored application tier 1040 (e.g., data plane mirrored application tier 940 of FIG. 9 ), which can include an application subnet 1026. The application subnet 1026 included in the data plane mirrored application tier 1040 can include a virtual network interface controller (VNIC) 1042 (e.g., VNIC 942 of FIG. 9 ), which can run a compute instance 1044 (e.g., similar to compute instance 944 of FIG. 9 ). The compute instance 1044 can facilitate communication between the application subnet 1026 of the data plane mirrored application tier 1040 and the application subnet 1026 that can be included in the data plane application tier 1046 (e.g., data plane application tier 946 of FIG. 9 ) via the VNIC 1042 included in the data plane mirrored application tier 1040 and the VNIC 1042 included in the data plane application tier 1046.

[0125] The Internet gateway 1034 included in the control plane VCN 1016 can be communicatively coupled to a metadata management service 1052 (e.g., metadata management service 952 of FIG. 9), which can be communicatively coupled to a public Internet 1054 (e.g., public Internet 954 of FIG. 9). The public Internet 1054 can be communicatively coupled to a NAT gateway 1038 included in the control plane VCN 1016. The service gateway 1036 included in the control plane VCN 1016 can be communicatively coupled to cloud services 1056 (e.g., cloud services 956 of FIG. 9).

[0126] In one embodiment, the data plane VCN 1018 may be included in the customer tenancy 1021. In this case, the IaaS provider may provide each customer with a control plane VCN 1016, and the IaaS provider may configure a unique compute instance 1044 included in the service tenancy 1019 for each customer. Each compute instance 1044 may enable communication between the control plane VCN 1016 included in the service tenancy 1019 and the data plane VCN 1018 included in the customer tenancy 1021. The compute instance 1044 may enable resources provisioned in the control plane VCN 1016 included in the service tenancy 1019 to be deployed or otherwise used in the data plane VCN 1018 included in the customer tenancy 1021.

[0127] In another example, an IaaS provider customer may have a database that resides within the customer tenancy 1021. In this example, the control plane VCN 1016 may include a data plane mirrored application tier 1040 that may include an application subnet 1026. The data plane mirrored application tier 1040 may reside in the data plane VCN 1018, but the data plane mirrored application tier 1040 may not reside in the data plane VCN 1018. That is, the data plane mirrored application tier 1040 may have access to the customer tenancy 1021, but the data plane mirrored application tier 1040 may not reside in the data plane VCN 1018, or may not be owned or operated by the IaaS provider customer. The data plane mirrored application tier 1040 may be configured to make calls to the data plane VCN 1018, but may not be configured to make calls to any entities included in the control plane VCN 1016. A customer may wish to deploy or otherwise use resources in the data plane VCN 1018 that have been provisioned in the control plane VCN 1016, and the data plane mirror application tier 1040 can facilitate the desired deployment or other use of the customer's resources.

[0128] In one embodiment, the IaaS provider's customer can filter the data plane VCN 1018. In this embodiment, the customer can determine what the data plane VCN 1018 can access, and the customer can limit access to the public internet 1054 from the data plane VCN 1018. The IaaS provider may not be able to filter or otherwise control the data plane VCN 1018's access to external networks or databases. The customer's application of filters and controls to the data plane VCN 1018 included in the customer tenancy 1021 can facilitate isolating the data plane VCN 1018 from other customers and from the public internet 1054.

[0129] In an embodiment, cloud services 1056 can be invoked by the service gateway 1036 to access services that may not be on the public internet 1054, on the control plane VCN 1016, or on the data plane VCN 1018. The connection between the cloud services 1056 and the control plane VCN 1016 or the data plane VCN 1018 may not be live or continuous. The cloud services 1056 can be on different networks owned or operated by the IaaS provider. The cloud services 1056 can be configured to receive calls from the service gateway 1036 and not receive calls from the public internet 1054. Some cloud services 1056 can be isolated from other cloud services 1056, and the control plane VCN 1016 can be isolated from cloud services 1056 that may not be in the same region as the control plane VCN 1016. For example, the control plane VCN 1016 may be located in “Region 1” and cloud service “Deployment 9” may be located in Region 1 and Region 2. When a call is made to deployment 9 by a service gateway 1036 included in a control plane VCN 1016 located in region 1, the call may be sent to deployment 9 in region 1. In this example, the control plane VCN 1016, or deployment 9 in region 1, may not be communicatively coupled or otherwise in communication with deployment 9 in region 2.

[0130] 11 is a block diagram 1100 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1102 (e.g., service operator 902 of FIG. 9 ) can be communicatively coupled to a secure host tenancy 1104 (e.g., secure host tenancy 904 of FIG. 9 ) which can include a virtual cloud network (VCN) 1106 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1108 (e.g., secure host subnet 908 of FIG. 9 ). The VCN 1106 can include an LPG 1110 (e.g., LPG 910 of FIG. 9 ) which can be communicatively coupled to an SSH VCN 1112 (e.g., SSH VCN 912 of FIG. 9 ) via an LPG 1110 included in the SSH VCN 1112. SSH VCN 1112 can include an SSH subnet 1114 (e.g., SSH subnet 914 in FIG. 9 ), which can be communicatively coupled to a control plane VCN 1116 (e.g., control plane VCN 916 in FIG. 9 ) via an LPG 1110 included in control plane VCN 1116 and to a data plane VCN 1118 (e.g., data plane 918 in FIG. 9 ) via an LPG 1110 included in data plane VCN 1118. The control plane VCN 1116 and the data plane VCN 1118 can be included in a service tenancy 1119 (e.g., service tenancy 919 in FIG. 9 ).

[0131] The control plane VCN 1116 may include a control plane DMZ tier 1120 (e.g., control plane DMZ tier 920 of FIG. 9 ) that may include a load balancer (LB) subnet 1122 (e.g., LB subnet 922 of FIG. 9 ), a control plane application tier 1124 (e.g., control plane application tier 924 of FIG. 9 ) that may include an application subnet 1126 (e.g., similar to application subnet 926 of FIG. 9 ), and a control plane data tier 1128 (e.g., control plane data tier 928 of FIG. 9 ) that may include a DB subnet 1130. The LB subnet 1122 included in the control plane DMZ tier 1120 can be communicatively coupled to an application subnet 1126 included in the control plane application tier 1124 and to an Internet gateway 1134 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in the control plane VCN 1116, and the application subnet 1126 can be communicatively coupled to a DB subnet 1130 included in the control plane data tier 1128 and to a service gateway 1136 (e.g., service gateway 936 in FIG. 9 ) and a network address translation (NAT) gateway 1138 (e.g., NAT gateway 938 in FIG. 9 ). The control plane VCN 1116 can include the service gateway 1136 and the NAT gateway 1138.

[0132] The data plane VCN 1118 can include a data plane application layer 1146 (e.g., data plane application layer 946 in FIG. 9 ), a data plane DMZ layer 1148 (e.g., data plane DMZ layer 948 in FIG. 9 ), and a data plane data layer 1150 (e.g., data plane data layer 950 in FIG. 9 ). The data plane DMZ layer 1148 can include a LB subnetwork 1122 that can be communicatively coupled to a trusted application subnetwork 1160 and an untrusted application subnetwork 1162 of the data plane application layer 1146 and to an Internet gateway 1134 included in the data plane VCN 1118. The trusted application subnetwork 1160 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118, a NAT gateway 1138 included in the data plane VCN 1118, and a DB subnetwork 1130 included in the data plane data layer 1150. The untrusted application subnet 1162 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118 and a DB subnet 1130 included in the data plane data layer 1150. The data plane data layer 1150 can include a DB subnet 1130 that can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118.

[0133] The untrusted application subnet 1162 may include one or more primary VNICs 1164(1)-(N) communicatively coupled to tenant virtual machines (VMs) 1166(1)-(N). Each tenant VM 1166(1)-(N) may be communicatively coupled to a respective application subnet 1167(1)-(N) that may be included in a respective container egress VCN 1168(1)-(N) that may be included in a respective customer tenancy 1170(1)-(N). Each secondary VNIC 1172(1)-(N) may facilitate communication between the untrusted application subnet 1162 included in the data plane VCN 1118 and the application subnet included in the container egress VCN 1168(1)-(N). Each container egress VCN 1168(1)-(N) may include a NAT gateway 1138 communicatively coupled to the public Internet 1154 (e.g., public Internet 954 of FIG. 9 ).

[0134] An Internet gateway 1134 included in the control plane VCN 1116 and included in the data plane VCN 1118 may be communicatively coupled to a metadata management service 1152 (e.g., metadata management system 952 of FIG. 9 ), which may be communicatively coupled to the public Internet 1154. The public Internet 1154 may be communicatively coupled to a NAT gateway 1138 included in the control plane VCN 1116 and included in the data plane VCN 1118. A service gateway 1136 included in the control plane VCN 1116 and included in the data plane VCN 1118 may be communicatively coupled to cloud services 1156.

[0135] In one embodiment, the data plane VCN 1118 can be integrated with a customer tenancy 1170. This integration can be useful or desirable in some cases for an IaaS provider's customer, such as when support is desired when executing code. A customer can provide code for execution that may be disruptive, communicate with other customer resources, or otherwise cause undesirable effects. In response, the IaaS provider can determine whether or not to execute the code provided to the IaaS provider by the customer.

[0136] In one embodiment, a customer of an IaaS provider may be granted temporary network access to the IaaS provider and may request to add functionality to the data plane application layer 1146. The code to perform that functionality may be executed in VMs 1166(1)-(N), which may not be configured to run anywhere else on the data plane VCN 1118. Each VM 1166(1)-(N) may be connected to one customer tenancy 1170. Each container 1171(1)-(N) contained in a VM 1166(1)-(N) may be configured to execute this code. In this case, there may be double isolation (e.g., containers 1171(1)-(N) execute code, and containers 1171(1)-(N) may be at least contained in VMs 1166(1)-(N) that are contained in untrusted application subnet 1162), which may help prevent malformed or otherwise undesirable code from damaging the IaaS provider's network or from damaging a different customer's network. Containers 1171(1)-(N) can be communicatively coupled to customer tenancy 1170 and can be configured to send or receive data from customer tenancy 1170. Containers 1171(1)-(N) may not be configured to send or receive data from any other entities in data plane VCN 1118. Upon completion of code execution, the IaaS provider can disable or otherwise discard containers 1171(1)-(N).

[0137] In one embodiment, trusted application subnet 1160 may execute code owned or operated by the IaaS provider. In this embodiment, trusted application subnet 1160 may be communicatively coupled to DB subnet 1130 and may be configured to perform CRUD operations on DB subnet 1130. Untrusted application subnet 1162 may be communicatively coupled to DB subnet 1130, but in this embodiment, the untrusted application subnet may be configured to perform read operations on DB subnet 1130. Containers 1171(1)-(N) may be included in each customer's VMs 1166(1)-(N) and may execute code from the customer, but may not be communicatively coupled to DB subnet 1130.

[0138] In other embodiments, the control plane VCN 1116 and the data plane VCN 1118 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 1116 and the data plane VCN 1118. However, communication may be indirect in at least one manner. An IaaS provider may configure an LPG 1110 that may facilitate communication between the control plane VCN 1116 and the data plane VCN 1118. In another example, the control plane VCN 1116 or the data plane VCN 1118 may make a call to a cloud service 1156 through a service gateway 1136. For example, a call from the control plane VCN 1116 to the cloud service 1156 may include a request for a service that may communicate with the data plane VCN 1118.

[0139] 12 is a block diagram 1200 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1202 (e.g., service operator 902 of FIG. 9 ) can be communicatively coupled to a secure host tenancy 1204 (e.g., secure host tenancy 904 of FIG. 9 ), which can include a virtual cloud network (VCN) 1206 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1208 (e.g., secure host subnet 908 of FIG. 9 ). VCN 1206 can include an LPG 1210 (e.g., LPG 910 of FIG. 9 ) that can be communicatively coupled to an SSH VCN 1212 (e.g., SSH VCN 912 of FIG. 9 ) via an LPG 1210 included in SSH VCN 1212. SSH VCN 1212 can include SSH subnet 1214 (e.g., SSH subnet 914 in FIG. 9 ), which can be communicatively coupled to a control plane VCN 1216 (e.g., control plane VCN 916 in FIG. 9 ) via an LPG 1210 included in control plane VCN 1216 and to a data plane VCN 1218 (e.g., data plane 918 in FIG. 9 ) via an LPG 1210 included in data plane VCN 1218. Control plane VCN 1216 and data plane VCN 1218 can be included in service tenancy 1219 (e.g., service tenancy 919 in FIG. 9 ).

[0140] The control plane VCN 1216 may include a control plane DMZ layer 1220 (e.g., control plane DMZ layer 920 of FIG. 9 ) which may include a LB subnet 1222 (e.g., LB subnet 922 of FIG. 9 ), a control plane application layer 1224 (e.g., control plane application layer 924 of FIG. 9 ) which may include an application subnet 1226 (e.g., application subnet 926 of FIG. 9 ), and a control plane data layer 1228 (e.g., control plane data layer 928 of FIG. 9 ) which may include a DB subnet 1230 (e.g., DB subnet 1130 of FIG. 11 ). The LB subnet 1222 included in the control plane DMZ tier 1220 can be communicatively coupled to an application subnet 1226 included in the control plane application tier 1224 and to an Internet gateway 1234 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in the control plane VCN 1216, and the application subnet 1226 can be communicatively coupled to a DB subnet 1230 included in the control plane data tier 1228 and to a service gateway 1236 (e.g., service gateway in FIG. 9 ) and a network address translation (NAT) gateway 1238 (e.g., NAT gateway 938 in FIG. 9 ). The control plane VCN 1216 can include the service gateway 1236 and the NAT gateway 1238.

[0141] The data plane VCN 1218 can include a data plane application layer 1246 (e.g., data plane application layer 946 in FIG. 9), a data plane DMZ layer 1248 (e.g., data plane DMZ layer 948 in FIG. 9), and a data plane data layer 1250 (e.g., data plane data layer 950 in FIG. 9). The data plane DMZ layer 1248 can include a LB subnetwork 1222 that can be communicatively coupled to a trusted application subnetwork 1260 (e.g., trusted application subnetwork 1160 in FIG. 11), an untrusted application subnetwork 1262 (e.g., untrusted application subnetwork 1162 in FIG. 11) of the data plane application layer 1246, and an Internet gateway 1234 included in the data plane VCN 1218. The trusted application subnetwork 1260 can be communicatively coupled to a service gateway 1236 included in the data plane VCN 1218, a NAT gateway 1238 included in the data plane VCN 1218, and a DB subnetwork 1230 included in the data plane data layer 1250. The untrusted application subnet 1262 may be communicatively coupled to a service gateway 1236 included in the data plane VCN 1218 and a DB subnet 1230 included in the data plane data layer 1250. The data plane data layer 1250 may include the DB subnet 1230, which may be communicatively coupled to the service gateway 1236 included in the data plane VCN 1218.

[0142] The untrusted application subnet 1262 may include primary VNICs 1264(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1266(1)-(N) that are in the untrusted application subnet 1262. Each tenant VM 1266(1)-(N) may execute code in a respective container 1267(1)-(N) and may be communicatively coupled to an application subnet 1226 that may be included in a data plane application layer 1246 that may be included in a container egress VCN 1268. Each secondary VNIC 1272(1)-(N) may facilitate communication between the untrusted application subnet 1262 included in the data plane VCN 1218 and the application subnet included in the container egress VCN 1268. The container egress VCN may include a NAT gateway 1238 that may be communicatively coupled to the public Internet 1254 (e.g., public Internet 954 of FIG. 9 ).

[0143] An Internet gateway 1234 included in the control plane VCN 1216 and included in the data plane VCN 1218 can be communicatively coupled to a metadata management service 1252 (e.g., metadata management system 952 of FIG. 9 ), which can be communicatively coupled to the public Internet 1254. The public Internet 1254 can be communicatively coupled to a NAT gateway 1238 included in the control plane VCN 1216 and included in the data plane VCN 1218. A service gateway 1236 included in the control plane VCN 1216 and included in the data plane VCN 1218 can be communicatively coupled to cloud services 1256.

[0144] In one embodiment, the pattern illustrated by the architecture of block diagram 1200 of FIG. 12 can be considered an exception to the pattern illustrated by the architecture of block diagram 1100 of FIG. 11 and may be desirable for customers of an IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., disconnected region). Each container 1267(1)-(N) contained in a VM 1266(1)-(N) for each customer is accessible in real time by that customer. The containers 1267(1)-(N) can be configured to make calls to a respective secondary VNIC 1272(1)-(N) contained in an application subnet 1226 of a data plane application layer 1246 that can be contained in a container egress VCN 1268. The secondary VNIC 1272(1)-(N) can send the calls to a NAT gateway 1238 that can send the calls to the public Internet 1254. In this example, containers 1267(1)-(N) that are accessible to a customer in real time are segregated from control plane VCN 1216 and are segregated from other entities contained within data plane VCN 1218. Containers 1267(1)-(N) are also segregated from resources from other customers.

[0145] In another example, a customer can use container 1267(1)-(N) to invoke cloud service 1256. In this example, the customer can execute code in container 1267(1)-(N) that requests a service from cloud service 1256. Container 1267(1)-(N) can send the request to secondary VNIC 1272(1)-(N), which can send the request to a NAT gateway, which can send the request to public Internet 1254. Public Internet 1254 can send the request via Internet gateway 1234 to LB subnet 1222 included in control plane VCN 1216. In response to determining that the request is valid, the LB subnet can send the request to application subnet 1226, which can send the request via service gateway 1236 to cloud service 1256.

[0146] It should be understood that the IaaS architectures 900, 1000, 1100, 1200 depicted in the figures may have components other than those depicted, and the depicted embodiments are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than depicted in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

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

[0148] 13 illustrates an exemplary computer system 1300 in which various embodiments may be implemented. The system 1300 may be used to implement any of the computer systems described above. As shown, the computer system 1300 includes a processing unit 1304 that communicates with several peripheral subsystems via a bus subsystem 1302. These peripheral subsystems may include a processing acceleration unit 1306, an I / O subsystem 1308, a storage subsystem 1318, and a communication subsystem 1324. The storage subsystem 1318 includes a tangible computer readable storage medium 1322 and a system memory 1310.

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

[0150] A processing unit 1304, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1300. The processing unit 1304 may include one or more processors. These processors may include single-core or multi-core processors. In an embodiment, the processing unit 1304 may be implemented as one or more independent processing units 1332 and / or 1334, with each processing unit including a single-core or multi-core processor. In other embodiments, the processing unit 1304 may be implemented as a quad-core processing unit formed by integrating two dual-core processors on a single chip.

[0151] In various embodiments, the processing unit 1304 may execute various programs in response to program code and may maintain multiple parallel executing programs or processes. At any given time, some or all of the program code being executed may reside within the processor 1304 and / or within the storage subsystem 1318. With appropriate programming, the processor 1304 may provide the various functions discussed above. The computer system 1300 may further include a processing acceleration unit 1306, which may include a digital signal processor (DSP), special purpose processor, and / or the like.

[0152] The I / O subsystem 1308 can include user interface input devices and user interface output devices. User interface input devices can include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices can include motion sensing and / or gesture recognition devices, such as, for example, a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device, such as a Microsoft Xbox® 360 game controller, through a natural user interface using gestures and speech commands. User interface input devices can also include eye gesture recognition devices, such as a Google Glass® blink detector, that detects eye activity from a user (e.g., “blinking” when taking pictures and / or selecting menus) and translates the eye gestures as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0153] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads, and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser distance meters, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasound devices. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

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

[0155] Computer system 1300 may include a storage subsystem 1318 that includes software elements currently shown as being within system memory 1310. System memory 1310 may store executable program instructions loadable into processing unit 1304, as well as data generated during the execution of those programs.

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

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

[0158] Storage subsystem 1300 may further include a computer readable storage medium reader 1320 connectable to a computer readable storage medium 1322. Along with, and optionally in combination with, the system memory 1310, computer readable storage medium 1322 may comprehensively represent remote, local, fixed and / or removable storage devices and storage media for containing, storing, transmitting and retrieving computer readable information on a temporary and / or more permanent basis.

[0159] The computer readable storage medium 1322 containing the code or portions of code may include any suitable medium known or used in the art, including storage and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media, implemented in any manner or technology for storing and / or transmitting information. This includes tangible computer readable storage media, such as RAM, ROM, Electrically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media. This may also include non-tangible computer readable media, such as a data signal, data transmission, or any other medium usable to transmit the desired information and accessible by the computing system 1300.

[0160] For example, the computer readable storage medium 1322 may include hard disk drives that read or write non-removable, non-volatile magnetic media, magnetic disk drives that read or write removable, non-volatile magnetic disks, and optical disk drives that read or write removable, non-volatile optical disks, such as CD ROMs, DVDs and Blu-Ray disks or other optical media. The computer readable storage medium 1322 may include, but is not limited to, Zip drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer readable storage medium 1322 may also include solid state drives (SSDs) based on non-volatile memory, such as flash memory-based SSDs, enterprise flash drives, solid state ROMs, SSDs based on volatile memory, such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the computer system 1300.

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

[0162] In some embodiments, the communications subsystem 1324 may also receive incoming communications in the form of structured and / or unstructured data feeds 1326, event streams 1328, event updates 1330, etc., on behalf of one or more users who may use the computer system 1300.

[0163] For example, the communications subsystem 1324 can be configured to receive data feeds 1326 in real time from users of social networks and / or other communications services, such as web feeds, such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party sources.

[0164] Additionally, the communications subsystem 1324 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1328 of real-time events and / or event updates 1330, which may be of a continuous or unbounded nature with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0165] The communications subsystem 1324 may also be configured to output structured and / or unstructured data feeds 1326, event streams 1328, event updates 1330, etc. to one or more databases in communication with one or more streaming data source computers coupled to the computer system 1300.

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

[0167] Due to the ever-changing nature of computers and networks, the description of the computer system 1300 shown in the figure is intended as an example only. Many other configurations having more or fewer components than the system shown in the figure are possible. For example, customized hardware may also be used, and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Also, connections to other computing devices, such as network input / output devices, may be employed. Based on this disclosure and the teachings presented herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0168] Although specific embodiments have been described, various modifications, variations, alternative constructions and equivalents are encompassed within the scope of the disclosure. The embodiments are not limited to operating in one particular data processing environment, but can freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments can be used individually or in combination.

[0169] Also, while the embodiments are described using a particular combination of hardware and software, it should be understood that other combinations of hardware and software are within the scope of the present disclosure. The embodiments can be implemented using only hardware, only software, or a combination thereof. The embodiments may be implemented using a computer program product that includes computer programs / instructions that, when executed by a processor, cause the processor to perform any of the methods described in the present disclosure. The various processes described herein can be performed on the same processor or on different processors in any combination. Thus, when a component or module is described as being configured to perform an operation, such configuration can be achieved, for example, by designing an electronic circuit to perform the operation, or by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. The processes can communicate using various techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0170] Accordingly, the specification and drawings are to be regarded in an illustrative rather than restrictive sense. However, it will be apparent that additions, deductions, deletions and other modifications and alterations may be made thereto without departing from the broader spirit and scope of the appended claims. Thus, although certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are intended to be encompassed within the scope of the following claims.

[0171] Use of the terms "a," "an," "the," and similar referents in the context of describing embodiments of the present disclosure (particularly in the context of the claims below) should be construed to include both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" should be construed as open-ended (i.e., meaning "including, but not limited to"), unless otherwise indicated. The term "connected" should be construed as being partly or wholly contained within, attached to, or joined to one another, even if there are intervening elements. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually set forth herein. All methods described herein can be performed in any suitable order, unless otherwise indicated herein or clearly contradicted by context. The use of any examples or exemplary language (e.g., "etc.") described herein, unless otherwise required, is intended merely to facilitate a better understanding of the embodiments and does not limit the scope of the disclosure. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0172] Disjunctive phrases such as the phrase "at least one of X, Y, or Z" are intended to be interpreted as generally used within the context to indicate that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X, Y and / or Z), unless specifically stated otherwise. Thus, such disjunctive phrases are generally not intended to, and should not, imply that an embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

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

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

[0175] Although aspects of the disclosure have been described herein above with reference to specific embodiments thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the disclosure above can be used individually or in combination. Also, the embodiments can be used in any number of environments and applications other than those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

Claims

Claim 1 A computer-readable program in which commands are recorded, and when the commands are executed by a computing system, the computing system is caused to receive, from a customer device, a request for execution of an action, the request including an identifier of the customer device and an action to be executed by a secure entity; determine a subscriber corresponding to the customer device based at least in part on the identifier of the customer device; determine that the subscriber has granted permission for execution of the action on the customer device; generate, based at least in part on a determination that the customer device has permission for execution of the action, credentials for access to the secure entity on behalf of the customer device; maintain the credentials separately from the customer device; and use the credentials for execution of the action on behalf of the customer device. A computer-readable program Claim 2 The computer-readable program according to claim 1, wherein the computing system and the secure entity are located in a trusted environment, and maintaining the credentials separately from the customer device includes maintaining the credentials within the trusted environment. Claim 3 Determining that the subscriber has granted permission for execution of the action includes determining one or more actions for which the subscriber has granted permission to the customer device; and determining that the action indicated by the request is included in the one or more actions. The computer-readable program according to claim 1 or claim 2 Claim 4 The computer-readable program according to claim 1 or claim 2, wherein generating the credentials includes using a key corresponding to the secure entity to generate the credentials. Claim 5 When the commands are executed by the computing system, the commands further cause the computing system to determine that an expiration period of the key has expired; and refresh the key by the secure entity based at least in part on the determination that the expiration period of the key has expired. The computer-readable program according to claim 4, which causes the refreshed key to be separated from and maintained by the customer device. **Claim 6** When the instruction is executed by the computing system, the computing system is further caused to implement a broker at the boundary of the secure entity, and the broker of the computing system generates the credential, separates and maintains the credential from the customer device, and uses the credential for execution of the action on behalf of the customer device. The computer-readable program according to claim 1 or claim 2. **Claim 7** The computer-readable program according to claim 6, wherein the secure entity is an enclave of the computing system. **Claim 8** Using the credential for execution of the action includes providing the credential to the secure entity to obtain access to the secure entity and requesting the secure entity to execute the action. The computer-readable program according to claim 1 or claim 2. **Claim 9** A memory storing one or more credentials, and one or more processors coupled to the memory, the one or more processors receive a request for execution of an action by a secure entity, the request being received from a customer device, the one or more processors determine a subscriber corresponding to the customer device based at least in part on an identifier of the customer device, determine that the subscriber has granted permission for execution of the action on the customer device, generate a credential for access to the secure entity based at least in part on the determination that the subscriber has granted permission for execution of the action on the customer device, store the credential in the memory, the credential being stored separately from the customer device, the one or more processors use the credential for execution of the action on behalf of the customer device. A computing system. **Claim 10** The one or more processors further obtain a key from the secure entity, and generating the credentials includes generating the credentials based at least in part on the key, the computing system of claim 9.

11. The one or more processors further determine that an expiration period of the key has expired, and refresh the key by the secure entity based at least in part on the determination that the expiration period of the key has expired, the computing system of claim 10.

12. Determining that the subscriber has granted permission to execute the action on the customer device includes determining one or more actions that the subscriber has permitted on the customer device, and determining that the action is included in the one or more actions, the computing system according to any one of claims 9 to 11.

13. The credentials are associated with the one or more actions, the computing system of claim 12.

14. The action includes inputting a consideration claim record, and using the credentials for execution of the action includes providing the credentials to the secure entity to obtain access to the secure entity, and causing the secure entity to input the consideration claim record, the computing system according to any one of claims 9 to 11.

15. The computing system includes a cloud infrastructure service, the secure entity includes an enclave within the cloud infrastructure service, the one or more processors further implement a broker at the boundary of the enclave, and the broker of the computing system generates the credentials for access to the secure entity and uses the credentials for execution of the action, the computing system according to any one of claims 9 to 11.

16. A method of performing an action by a secure entity, comprising The broker receives a request to execute an action by the secure entity from the customer device, The broker determines that the customer device is permitted to execute the action, The broker generates credentials for access to the secure entity based at least in part on the determination that the customer device is permitted to execute the action, The broker uses the credentials to cause the secure entity to execute the action on behalf of the customer device. A method comprising:

17. The secure entity and the broker are located within a trusted environment, the customer device is located outside the trusted environment, and the method further comprises the broker maintaining the credentials within the trusted environment. The method according to claim 16.

18. The secure entity includes an enclave of a computing system, and receiving the request to execute the action includes the broker receiving the request to execute the action at the boundary of the enclave. The method according to claim 16 or claim 17.

19. The method according to claim 16 or claim 17, further comprising the broker retrieving a key from the secure entity, wherein the credentials are generated based at least in part on the key.

20. The broker determines that the expiration period of the key has expired, The method according to claim 19, further comprising the broker refreshing the key by the secure entity based at least in part on the determination that the expiration period of the key has expired.

Images