Licensed user facilitation and control system

Abstract

A request to perform a command or operation on a computing system is received from a user. A permission level required to perform the requested command or operation is identified, and a data store having a pool of permitted users is accessed to identify permitted users having a sufficient permission level. A secure user is assigned to the request. A risk level corresponding to the requested command or operation is identified and surfaced for the secure user. The requested command or operation can be automatically performed after being authorized by the secure user.

Description

BACKGROUND

[0001] Computer systems are currently in widespread use. Many computer systems host services that are accessed and used by remote client computing systems. For example, many computing systems provide cloud-based services in which various software applications are provided as a service to customers.

[0002] These types of services can be provided within different compliance boundaries. Compliance boundaries define what is sometimes referred to as a "sovereign cloud." Different sovereign clouds can be demarcated along compliance boundaries. Each different sovereign cloud can have different compliance rules or regulations for governing how data is handled, data access, and other security concerns. Data that resides in a sovereign cloud that is geographically located in one region (e.g., Europe) can be governed by different compliance rules and require different levels of security credentials or permissions that are applicable in that region. However, data that resides in a sovereign cloud that is located in another geographic region (e.g., the United States) can be governed by a different set of compliance rules used in that region, or require different levels of permissions or security credentials that are used in that region. Thus, these two sovereign clouds are referred to as being demarcated by compliance boundaries because they are governed by different compliance rules, or because they require different levels of security permissions or permissions to access data.

[0003] In these types of services, it is not uncommon for incidents (e.g., errors, faults, or other issues) to occur that require handling by a support engineer. However, the support engineer can not have sufficient levels of security permissions or other credentials to access data within that compliance boundary, or otherwise perform actions or operations on the service within that compliance boundary.

[0004] The above discussion is merely provided for general background information and does not intend to be used as an aid in determining the scope of the claimed subject matter. SUMMARY SUMMARY

[0005] A request to execute an upline command or operation on a computing system is received from a support user. A level of permissions required to perform the requested command or operation is identified, and a data store having a pool of permitted users is accessed to identify a permitted user having a sufficient level of permissions. The permitted user is assigned to the request. A risk level corresponding to the requested command or operation is identified and surfaced for the secure user. The requested command or operation can be automatically executed after being authorized by the secure user.

[0006] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1 is a block diagram of one example of a computing system architecture.

[0008] Figure 2 is a block diagram showing one example of a cleared user facilitation and control system in more detail.

[0009] Figure 3A and Figure 3B (identified collectively herein as FIG. 3) illustrates a flowchart showing one example of the operation of a cleared user facilitation and control system in assigning a cleared user to a received request to execute a command or operation.

[0010] Figure 4 is a flowchart showing one example of the operation of a cleared user facilitation and control system in surfacing a risk level corresponding to a requested command or operation, and in automatically executing the requested command or operation.

[0011] Figure 5 is a block diagram showing one example of a computing system architecture deployed in a cloud computing architecture. Figure 1 is a block diagram of one example of a computing system architecture.

[0012] Figure 6 is a block diagram showing one example of a computing environment that can be used in the architectures shown in the previous figures. DETAILED DESCRIPTION

[0013] As noted above, a support engineer (or other support user) can need to perform an operation or command on a service that is deployed within a particular compliance boundary. For the purposes of this discussion, the terms operation and command will be used interchangeably. However, the support engineer can not have sufficient clearance credentials (e.g., sufficient clearance) to access the service or data to perform the required command or operation. In this case, the support engineer typically works with a cleared user who does have sufficient clearance to perform the required command or operation within the particular compliance boundary in order to execute the requested command or operation.

[0014] This raises a number of different issues. For example, it is not uncommon for a support engineer to have more knowledge than a licensed user about how a command or operation will affect the service on which it is executed. Thus, a licensed user can have difficulty knowing whether a support engineer is requesting that the licensed user perform a risky operation or a fairly routine operation (e.g., a maintenance operation). Similarly, a support engineer can have difficulty finding a licensed user with sufficient permissions. A support engineer can not even know the permission level or permission credentials required to execute a command or operation. Moreover, once a support engineer has found a licensed user and has requested that the licensed user execute a command or operation, the licensed user typically needs to type in the requested command or operation in order to execute it on the required service within the required compliance boundaries. This operation is error prone and time consuming.

[0015] Accordingly, the present discussion is directed to a system that automatically identifies a licensed user to execute a requested command or operation for a particular compliance boundary upon receiving a request from a support user. The system can also identify a risk level associated with the requested command or operation and surface the risk level for the licensed user. Once the licensed user authorizes execution of the requested command or operation, the system can automatically execute the requested command or operation without further user involvement. Similarly, the system facilitates communication between the support user and the licensed user over a secure communication channel, which can be entirely within the compliance boundaries of the service to be run.

[0016] Figure 1 FIG. 1 is a block diagram illustrating one example of a computing system architecture 100. Figure 1 A support user (e.g., support engineer) computing system 102 is shown as being in communication with a computing system 104 on which it is to operate. Similarly, a plurality of licensed user computing systems 106-108 are shown as being in communication with the systems 102 and 104 as well as a licensed user data storage system 110. All of the systems are also shown as illustratively being in communication with a licensed user facilitation and control system 112 over a network 114. Thus, the network 114 can be a wide area network, a local area network, a near field communication network, a cellular communication network, or any one or combination of a variety of other networks.

[0017] An interface / update logic 118 is illustratively exposed to the licensed user data storage system 110 so that the licensed user records 122-124 can be added, deleted, updated, etc. with new security levels.

[0018] The support user computing system 102 is shown as generating an interface 140 for interaction by a support user (e.g., support engineer) 142. The licensed user computing systems 106 and 108 are shown as generating interfaces 144 and 146, respectively, for interaction by licensed users 148 and 150.

[0019] Before describing the overall operation of the architecture 100 in more detail, a brief description will first be provided. Assume that a support user 142 wishes to perform a command or operation on a computing system 104 on which the operation is to be performed. However, also assume that the support user 142 does not have sufficient permissions to perform the requested command or operation on the computing system 104. Thus, the support user 142 submits a request 152 for performing the command or operation on the computing system 104 to the permitted user facilitation and control system 112. The permitted user facilitation and control system 112 (which is described in more detail below with respect to Figure 2 more detail) identifies the permissions or permission level required to perform the requested command or operation on the computing system 104 and accesses the permitted user data storage system 110. The permitted user data storage system 110 illustratively includes records corresponding to the permitted users 148 and 150 that identify the particular permission levels those users have. Thus, it identifies the permitted users 148-150 that can perform the requested operation on the computing system 104 and automatically assigns that permitted user to the request 152. It also facilitates secure communications between the support user 142 and the selected permitted user (e.g., the permitted user 148). It identifies the risk level associated with the requested command or operation in the request 152 and surfaces that risk level for the permitted user 148. The permitted user 148 can provide input through the interface 144 that authorizes the requested command or operation to be performed within the computing system 104. The permitted user facilitation and control system 112 then automatically extracts the command or operation from the communications between the support user 142 and the permitted user 148 and automatically performs the command or operation within the computing system 104. It can archive all communications corresponding to the requested command or operation in a secure archive for later analysis.

[0020] A brief description of some of the items in the architecture 100 and their operation will now be provided.

[0021] In the illustrated example, the permitted user data storage system 110 illustratively includes one or more processors or servers 116, interface / update logic 118, and a permitted user pool data store 120 (which itself includes a plurality of permitted user records 122-124, and it can include other items 126). The permitted user data storage system 110 can also include other items 128. Each of the permitted user records 122-124 can include a user ID 130 that identifies a different respective permitted user, a permission level 132 associated with the respective permitted user, an experience indicator 134 that identifies an experience level or subject experience of the respective permitted user, and availability data / link 136 that identifies an availability of the respective permitted user (or a link to its calendar), and it can include other items 138.

[0022] The computing system 104 on which operations are to be performed can include one or more processors or servers 156, various different logic or functionality 158 to implement services performed by the computing system 104, a data store 160 in which customer data or other data can be stored, and it can include other items 162.

[0023] The licensed user computing systems 106 and 108 can be similar or different. For the present discussion, it is assumed that they are similar, so only the licensed user computing system 106 will be described in more detail. The licensed user computing system 106 illustratively includes one or more processors or servers 164, a communication system 166, interface logic 168, and it can include other items 170. The interface logic 168 illustratively generates the interface 144 for interaction by the licensed user 148. The licensed user 148 illustratively interacts with the interface 144 in order to control and manipulate the licensed user computing system 106 and some other systems in the architecture 100. Figure 1 The communication system 166 is illustratively configured to communicate over the network 114 and to provide any other desired communication. Thus, the communication system 166 can vary depending on the type of network 114 used. For example, it can be a chat message communication system, or any of a variety of other types of communication systems.

[0024] The support user computing system 102 illustratively includes one or more processors or servers 172, a communication system 174, interface logic 176, and it can include other items 178. As with the communication system 166, the communication system 174 can vary depending on the type of network 114 or other communication type to be used. It can be a chat message communication system or a variety of other communication systems.

[0025] The interface logic 176 illustratively generates the interface 140 for interaction by the support user 142. The support user 142 illustratively interacts with the interface 140 in order to control and manipulate the support user computing system 102 and some other systems in the architecture 100.

[0026] As briefly discussed, the support user 142 can use the support user computing system 102 to submit the request 152 to perform an operation on the computing system 104 to be operated as described above. The computing system 102 can also communicate with other systems in a variety of other ways over the network 104. This other communication is indicated by block 178.

[0027] Figure 2is a block diagram showing one example of the licensed user facilitation and control system 112 in more detail. The system 112 illustratively includes one or more processors or servers 182, a request processing system 184, a licensed user pool access system 186, a licensed user assignment system 188, a licensed user interaction system 190, a security profile 192, and it can include other items 194. The request processing system 184 illustratively includes request resolution logic 196, command / operation identifier logic 198, command / operation permission identifier logic 200, timing identifier logic 202, and it can include other items 204. The licensed user assignment system 188 illustratively includes permission level filtering system 206, job type filtering logic 208, availability filtering logic 210, licensed user selection logic 212, and it can include other items 214. The licensed user interaction system 190 can include secure communication channel logic 216, request lifecycle control system 218, command / operation risk assessment logic 220, risk manifestation logic 222, automated execution system (bot) 224, encryption system 226, communication pipeline storage system 228, licensed user interface logic 230, and it can include other items 232. The automated execution system (bot) 224 can include execution trigger detector 234, command / operation retrieval logic 236, command / operation execution logic 238, and it can include other items 232.

[0028] In brief overview, by operation, the request processing system 184 receives a request 152 from a supporting user computing system 102 to perform a command or operation on a computing system 104 to be operated. The request resolution logic 196 resolves the request so that the command / operation identifier logic 198 can identify the particular command or operation to be performed, and so that the command / operation permission identifier logic 200 can identify the permissions (e.g., permission levels, security permission credentials, etc.) required to perform the operation in the requested environment (e.g., within the requested compliance boundary, on the requested server or other machine, etc.). The timing identifier logic 202 identifies the request timing corresponding to the command or operation to be performed. For example, it can identify how long it will take to perform the requested command or operation, etc.

[0029] The licensed user pool access system 186 illustratively interfaces with the licensed user data store 110 Figure 1The request 152 is received by the request lifecycle control system 218, which identifies the requesting user 142 and the requested environment 130. The request lifecycle control system 218 then identifies the appropriate interaction (e.g., chat, email, or other interaction) to access the pool of permitted users data store 120. Using the pool of permitted users access system 186, the pool of permitted users assigns system 188 identifies the permitted users 148-150 from the permitted user records 122-124 in the pool of permitted users data store 120 that have sufficient permissions to perform the requested operation in the requested environment and also have sufficient availability and experience. Thus, the permission level filter system 206 filters the various permitted user records 122-124 based on the permission level 132 of the respective user. It only identifies permitted user records 122-124 that have sufficient permission level to perform the requested command or operation in the requested environment.

[0030] The availability filter logic 210 then filters those records according to the availability data or link 136. For example, if the requested command or operation is to be performed immediately, and requires two hours, it can be that some of the permitted users that have sufficient permissions do not have availability to assist the request. Similarly, the work type filter logic 208 illustratively filters the permitted user records 122-124 based on the experience indicator 134 that indicates the type of command or operation that the respective user has used or other work experience that the respective user has. Thus, when a list of permitted users has been identified based on having sufficient permissions and availability, the work type filter logic 208 can filter the remaining permitted user records to identify the permitted user 134 that has the most applicable level of experience based on the experience indicator in that user's corresponding permitted user record. It should be noted that the records 122-124 can be filtered in different orders (e.g., availability, permission level, experience, or other order) and other filters can also be applied.

[0031] The permitted user selection logic 212 then selects a particular permitted user (for this example it is assumed to be the permitted user 148) and assigns that permitted user 148 to the request 152.

[0032] The permitted user interaction system 190 then facilitates communication between the supporting user 142 that submitted the request 152 and the permitted user 148 that has been assigned to the request 152. Thus, the secure communication channel logic 216 facilitates secure communication over a communication channel that is within the compliance boundaries of the computing system 104 that is to be operated. By way of example, the logic 216 can facilitate a chat communication channel or another communication channel that is secure and within the desired compliance boundaries. Once the request 152 has been serviced, the request lifecycle control system 218 allows the permitted user 148 to open a ticket or other record corresponding to the request 152 and close the ticket or record.

[0033] The command / operation risk assessment logic 220 receives an indication of a particular command or operation to be executed from the command / operation identifier logic 198. It then assesses the risk corresponding to the requested command or operation. For example, the requested command or operation can be a routine maintenance command or operation that has been executed many times on the computing system 104 without any negative consequences. In this case, the risk assessment can be relatively low. However, the command / operation risk assessment logic 220 can have never encountered this particular command or operation before, and there is no record that it is being executed on the target computing system 104. This can carry a relatively high risk rating. Similarly, the command / operation risk assessment logic 220 can identify a history that indicates the last time the command or operation was executed, which resulted in significant downtime of the target computing system 104. In this case, the risk rating can be extreme. Of course, different rules, models, or other risk assessment logic can be used to assess the risk rating in a variety of other ways.

[0034] Once the risk rating has been identified by the logic 220, it is provided to the risk presentation logic 222, which illustratively generates an output indicating the risk rating for presentation to the licensed user 148. It can be that the licensed user 148 does not have sufficient knowledge to know whether the requested operation is high risk or low risk. Thus, when the risk rating is presented to the licensed user 148, this provides the licensed user 148 with a measure of the degree of risk of the request. The risk presentation logic 222 can also illustratively present the authorization actuator, either along with the risk rating, or separately from it. When the licensed user 148 actuates the execution actuator, this can trigger automatic execution of the requested command or operation.

[0035] The automatic execution system (bot) 224 automatically executes the requested command or operation, without the licensed user 148 needing to perform any other operation other than authorizing execution of the requested command or operation. Thus, the execution trigger detector 234 detects an execution trigger, which indicates that the licensed user 148 has indicated that he or she wishes to have the requested command or operation executed on the computing system 104. This can be done by actuating the authorization actuator, or by providing another input.

[0036] Once the execution trigger is detected, the command / operation retrieval logic 236 retrieves or extracts the requested command or operation from the request 152. For example, assume that the request 152 is communicated to the authorized user 148 using a secure chat communication system. When the authorized user 148 authorizes execution of the command or operation, the command / operation retrieval logic 236 parses the chat message to identify the command or operation to be executed. It can do this based on a tag in the chat message, based on its own processing of the chat message, or in other ways. Once it extracts the command or operation (or an identifier that identifies the requested command or operation), it provides it to the command / operation execution logic 238, which automatically executes the command or operation within the computing system 104. In this way, the authorized user 148 does not need to retype anything to execute the requested command or operation. It is executed automatically based on the authorized user 148 authorizing its execution.

[0037] Figure 3A and Figure 3B FIG. 3 (collectively referred to herein as FIG. 3) shows a flowchart that illustrates one example of how the authorized user facilitation and control system 112 processes a request 152 from the support user computing system 102 and assigns an authorized user (e.g., the authorized user 148) to help process the request.

[0038] It is first assumed that the authorized user pool data store 120 is functioning properly and populated with authorized user records 122-124 corresponding to different authorized users. The records include a user ID 130 that identifies the user and a permission level 132 that identifies the permission level or permission credentials for that user. It includes availability data or a link to availability data 136, and it can include other items. Populating the authorized user data store is indicated by block 250 in the flowchart of FIG. 3.

[0039] The request processing system 184 then receives the request 152 from the support user computing system 102 to execute a command or operation within the computing system 104. Receiving the request is indicated by block 252. Any approvals needed by the support user 142 to submit and process the request 152 can be obtained by a separate approval system. Obtaining any needed approvals is indicated by block 254.

[0040] Request resolution logic 196 then resolves the request to identify features that are used to determine what type of permissions are needed. This is indicated by block 256. For example, it can resolve the request to identify the server or machine name where the command or operation requested is to be performed. This is indicated by block 258. It can resolve the request 152 to identify the particular environment where the command or operation requested is to be performed. This is indicated by block 260. It can use command / operation identifier logic 198 to identify the particular command or operation that is being requested. This is indicated by block 262. It can resolve the request 152 to identify a variety of other information or features that can be used to determine the adequate level of permissions needed to perform the command or operation requested. This is indicated by block 264.

[0041] Command / operation permission identifier logic 200 then identifies the permissions needed based on the features of the request 152. This is indicated by block 266. For example, it can access an environment (or machine) to permissions mapping, or another lookup table or matrix, or apply a set of rules that map from the features identified in step 256 to the level of permissions needed to perform the command or operation requested. Accessing the environment to permissions mapping, matrix, or set of rules is indicated by block 268. Permissions can also be identified in a variety of other ways, as indicated by block 270.

[0042] Permitted user pool access system 186 then accesses the permitted user data storage system 110, and in particular the permitted user pool data store 120. Accessing the permitted user pool is indicated by block 272.

[0043] Permission level filtering system 206 then accesses the various permitted user records 122-124 and filters them to identify the corresponding permitted users in the pool that have adequate permissions to perform the command or operation requested on the computing system 104 requested, in the environment requested, etc. This is indicated by block 274.

[0044] Once the permission level filtering system 206 identifies the permitted users that have adequate permissions, availability filtering logic 210 can identify which of those permitted users have availability based on the timing identified by timing identifier logic 202. The permitted users identified based on availability filtering are indicated by block 276. It can identify the desired timing corresponding to the request 152, as indicated by block 278. It can access the calendar / availability data or links 136 in the various records 122-124. This is indicated by block 280. It can also filter the permitted users based on availability in other ways, and this is represented by block 282.

[0045] Once a set of licensed users with sufficient permissions and sufficient availability are identified, the work type filtering logic 208 then filters those users based on the subject matter of the command or operation requested in the request 152. It first identifies the subject matter of the command or operation, as indicated by block 284. It then filters the available, licensed users based on the subject matter or experience identified by the experience indicator 134 in the licensed user records corresponding to those users. This is indicated by block 286.

[0046] The licensed user selection logic 212 then selects a licensed user to assign to the request 152. This is indicated by block 288, and for purposes of this discussion, it will be assumed that the licensed user selection logic 212 selects the licensed user 148.

[0047] The licensed user selection logic 212 then assigns the request 152 to the selected licensed user 148. This is indicated by block 290. It can also store an indication of this assignment in the security archive 192. This is indicated by block 292. It can also assign the request to the selected security user 148 in other ways, and this is indicated by block 294.

[0048] The secure communication channel logic 216 then facilitates a secure communication channel between the support user 142 and the selected, licensed user 148. This is indicated by block 296. For example, it can open or establish a chat message communication channel between the two users within the desired compliance boundaries. It can also establish other secure communication channels.

[0049] Figure 4 is a flowchart illustrating one example of the operation of the licensed user interaction system 190 in assessing a risk level corresponding to a requested command or operation, surfacing this risk level for the assigned licensed user 148, and automatically executing it when authorized to do so. It is first assumed that the secure communication channel logic 216 transmits the request 152 to the assigned licensed user 148 over a secure communication channel. This is indicated by block 300 in the flowchart of Figure 4 At some point, the security user 148 uses the interface 144 and the communication system 166 to acknowledge that he or she has received the request 152 and accepts the assignment. The acknowledgment request is indicated by block 302. The request lifecycle control system 218 can then open a record corresponding to the request (if it has not already been opened) and store the acknowledgment of the assigned licensed user 148 in the security archive 192. This is indicated by block 304. The security user 148 can also acknowledge the request in other ways, which is indicated by block 306.

[0050] The command / operation risk assessment logic 220 then identifies or generates a risk level corresponding to the requested command or operation. This is indicated by block 308. In doing so, the logic 220 can analyze historical command / operation records in the security profile 192 and / or in the data store 162 in the target computing system 104 to determine whether the requested command or operation has been executed before, whether in the requesting environment, how many times, and the results of the execution (e.g., downtime, execution success, etc.). Analyzing the historical command / operation records is indicated by block 310.

[0051] The command / operation risk assessment logic 220 can generate the risk level by applying rules. For example, rules can map from the command or operation to a risk level based on the intrusiveness of the command or operation, based on the sensitivity of the data to be operated on, or based on other criteria. This is indicated by block 312. The logic 220 can access a lookup table that provides a matrix of commands or operations, environments, data to be operated on, and risk levels. Accessing the lookup table is indicated by block 314. The command / operation risk assessment logic 220 can also generate the risk level in a variety of other ways, which is indicated by block 316.

[0052] The risk surfacing logic 222 then generates output that can be used to surface the risk level to the assigned permitted user 148. Surfacing the risk level to the protected user is indicated by block 318. In one example, the risk level is surfaced with an actuator that can describe the command or operation to be executed. When the actuator is actuated by the user 148, this can be detected by the permitted user interface logic 230 (or elsewhere) and act as a trigger to begin execution of the requested command or operation. Surfacing the risk level of the command or operation and the command / operation approval executor are indicated by block 320. The risk level can also be surfaced in a variety of other ways, which is indicated by block 322.

[0053] The user 148 then authorizes the requested command / operation. This can be done, for example, by interacting with the approval executor. Authorizing the requested command / operation is indicated by block 323. When the user 148 authorizes execution of the requested command or operation, the execution trigger detector 234 detects the execution trigger. This is indicated by block 324.

[0054] In response, the command / operation retrieval logic 236 automatically extracts the command or operation from the request 152 provided in the secure communication channel. This is indicated by block 326. As described above, this can be done by retrieving the command / operation identifier generated by the command / operation identifier logic 198, by parsing the request again to identify the command or operation, or in other ways.

[0055] The command / operation execution logic 238 then automatically executes the command or operation in the target computing system 104. This is indicated by block 328.

[0056] Once the requesting user 148 and the supporting user 142 have agreed that the request 152 has been satisfied, then the secure user 148 closes the record corresponding to the request. This is indicated by block 330. An indication that the record has been closed can also be stored in the secure archive 192.

[0057] The communication pipe storage system 228 then copies the messages in the entire communication pipe (all communications in the secure communication channel between the user 142 and 148 corresponding to the request 152) and stores them in the secure archive 192. This is indicated by block 332. It should be noted that in one example, the secure archive 192 is a read-only data store, so the records of the archive cannot be altered later.

[0058] Further, in one example, the encryption system 226 encrypts the communication pipe and other records or information stored in the secure archive 192. This is indicated by block 334. The communication pipe can also be stored in the secure archive in other ways, and this is indicated by block 336.

[0059] It should be noted that the above discussion has described various different systems, components, and / or logic. It should be appreciated that such systems, components, and / or logic can be made up of hardware items such as processors and associated memory or other processing components, some of which are described below, that perform the functions associated with those systems, components, and / or logic. Further, the systems, components, and / or logic can be made up of software that is loaded into memory and subsequently executed by a processor or server or other computing component, as described below. The systems, components, and / or logic can also be made up of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are just a few examples of different structures that can be used to make up the systems, components, and / or logic described above. Other structures can also be used.

[0060] The present discussion has mentioned processors and servers. In one embodiment, the processors and servers include computer processors with associated

[0061] In addition, a number of user interface displays are discussed. They can take a number of different forms, and a number of different user actuatable input mechanisms can be provided thereon. For example, the user actuatable input mechanisms can be text boxes, check boxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in a variety of different ways. For example, they can be actuated using a pointing device such as a trackball or mouse. They can be actuated using hardware buttons, switches, a joystick or keyboard, thumb switches or thumb pads, etc. They can also be actuated using a virtual keyboard or other virtual actuators. In addition, where the screen on which they are displayed is a touch sensitive screen, they can be actuated using touch gestures. Furthermore, where the device on which they are displayed has a speech recognition component, they can be actuated using voice commands.

[0062] A number of data stores are also discussed. Notably, each of them can be broken down into a number of data stores. All can be local, all can be remote, or some can be local and others can be remote, to the systems that access them. All of these configurations are contemplated herein.

[0063] In addition, the figures show a number of blocks with functionality attributed to each block. It should be noted that fewer blocks can be used, with the functionality being performed by fewer components. In addition, more blocks can be used with the functionality being distributed among more components.

[0064] Figure 5 is Figure 1 a block diagram of the architecture 100 shown. Except that its elements are arranged in a cloud computing architecture 500, it is the same as Figure 1 Cloud computing provides computation, software, data access, and storage services that do not require end user knowledge of the physical location or configuration of the system that delivers the services. In various examples, cloud computing delivers services over a wide area network, such as the internet. As an example, a cloud computing provider delivers applications over a wide area network and they can be accessed through a web browser or any other computing component. The software or components of the architecture 100 and the corresponding data can be stored on servers at remote locations. The computing resources in a cloud computing environment can be consolidated at a remote data center location, or they can be dispersed. Cloud computing infrastructure can provide services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided using a cloud computing architecture from a service provider at a remote location. Alternatively, they can be provided from a traditional server, or they can be installed directly on a client device, or in other ways.

[0065] This description is intended to include both public and private cloud computing. Cloud computing (public and private) provides a basic seamless pool of resources and reduces the need to manage and provision underlying hardware infrastructure.

[0066] A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Further, as opposed to a private cloud, a public cloud can free end users from managing the hardware. A private cloud can be managed by the organization itself, and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, e.g., installation and repair, etc.

[0067] In Figure 5 In the example shown, some items are similar to those shown in Figure 1 and their numbering is similar. Figure 5 It is specifically shown that systems 104, 110, and 112 can be located in cloud 502 (which can be public, private, or a combination where portions are public and others are private). Thus, users 142, 148, and 150 access these systems through cloud 502 using user devices.

[0068] Figure 5 Another example of a cloud architecture is also depicted. Figure 5 It is shown that some elements of architecture 100 are also contemplated to be arranged in cloud 502, while others are not. For example, licensed user data storage system 110 can be disposed outside of cloud 502 and accessed through cloud 502. Regardless of where they are located, users can access them directly through a network (wide area or local area), they can be hosted by a service at a remote site, or they can be provided as a service through the cloud or accessed through a connection service that resides in the cloud. All of these architectures are contemplated herein.

[0069] It will also be noted that architecture 100 or portions thereof can be arranged on a variety of different devices. Some of these devices include servers, desktop computers, notebook computers, tablet computers, or other mobile devices such as palm computers, cell phones, smart phones, multimedia players, personal digital assistants, etc.

[0070] Figure 6 is one example of a computing environment in which architecture 100 or portions thereof (for example) can be deployed. Reference is made to Figure 6An example system for implementing some embodiments includes a computing device in the form of a computer 810, configured to operate as described above. The components of computer 810 can include, but are not limited to, a processing unit 820 (which can include a processor or server from a previous figure), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 can 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. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. For further details on these bus architectures, consult any one of several individually available computer architecture Figure 1 The described memory and programs can be deployed in respective portions of the system. Figure 6

[0071] Computer 810 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 810 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media can comprise computer storage media and communication media. Computer storage media is different from, and does not include, a modulated data signal or carrier wave. It includes hardware storage media including both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 810. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.

[0072] ​System memory 830 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. The basic input / output system 833 (BIOS) is typically stored in ROM 831 and contains routines that help transfer information between components within computer 810 (e.g., during startup). RAM 832 typically contains data and / or program modules that can be immediately accessed by processing unit 820 and / or operated by the currently processed unit 820. By way of example and not limitation, Figure 6 The diagram illustrates the operating system 834, application program 835, other program modules 836, and program data 837.

[0073] Computer 810 may also include other removable / non-removable volatile / non-volatile computer storage media. This is just one example. Figure 6 A hard disk drive 841 is shown that reads from or writes to a non-removable, non-volatile magnetic medium, and an optical disk drive 855 that reads from or writes to a removable, non-volatile optical disk 856, such as a CD-ROM or other optical medium. Other removable / non-removable, volatile / non-volatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic tape cartridges, flash memory cards, digital multifunction disks, digital videotapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface such as interface 850.

[0074] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. Exemplary types of hardware logic components that may be used, such as but not limited to, include field-programmable gate arrays (FPGAs), program-specific integrated circuits (ASICs), program-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and the like.

[0075] The above discussion and Figure 6 The drive and its associated computer storage media shown provide storage for computer-readable instructions, data structures, program modules, and other data for the computer 810. Figure 6In the depicted example, the hard disk drive 841 is shown as storing the operating system 844, the application programs 845, other program modules 846, and program data 847. Note that these components can either be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to illustrate that, at a minimum, they are different copies.

[0076] A user can enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and a pointing device 861, such as a mouse, trackball or touch pad. Other input devices (not shown) can include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 820 through a user input interface 860 that is coupled to the system bus, but can be connected by other interface and bus structures, such as a parallel port or a universal serial bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface, such as a video interface 890. In addition to the monitor, computers can also include other peripheral output devices such as speakers 897 and a printer 896, which can be connected through an output peripheral interface 895.

[0077] The computer 810 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 can be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 810. Figure 6 The logical connections depicted in FIG. 8 include a local area network (LAN) 871 and a wide area network (WAN) 873, but can also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

[0078] When used in a LAN networking environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which can be internal or external, can be connected to the system bus 821 via the user input interface 860, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 810, or portions thereof, can be stored in the remote memory storage device. By way of example, and not limitation, as Figure 6The remote application programs 885 are illustrated as residing on remote computer 880. It is appreciated that the network connections illustrated are exemplary and other means of establishing a communications link between the computers can be used.

[0079] It is also noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of these are considered within the scope of the present disclosure.

[0080] Example 1 is a computing system comprising:

[0081] a request processing system that receives a request to execute a command on a target computing system in a computing environment and identifies a permission level sufficient to execute the command on the target computing system in the computing environment;

[0082] a pool of licensed user access system that accesses a set of licensed user records, each licensed user record corresponding to a licensed user, and each licensed user record having a respective permission level indicator indicating a permission level of the respective user;

[0083] a licensed user assignment system that assigns a licensed user to the request based on the licensed user records and based on the permission level sufficient to execute the command on the target computing system in the computing environment; and

[0084] a licensed user interaction system that sends the request to the assigned licensed user.

[0085] Example 2 is the computing system of any or all previous examples, wherein the request processing system comprises:

[0086] a command permission identifier logic configured to identify a permission level sufficient to execute the command and generate a sufficient permission level indicator indicating the sufficient permission level.

[0087] Example 3 is the computing system of any or all previous examples, wherein the licensed user assignment system comprises:

[0088] a permission level filtering system configured to filter the set of licensed user records based on the respective permission level indicators and the sufficient permission level to identify permission level records having permission level indicators that satisfy the sufficient permission level.

[0089] Example 4 is the computing system of any or all previous examples, wherein each of the licensed user records comprises an availability indicator indicating an availability of the respective licensed user, and wherein the request processing system comprises:

[0090] a timing identifier logic configured to identify a timing corresponding to the request to execute the command.

[0091] Example 5 is the computing system of any or all previous examples, wherein the licensed user assignment system comprises:

[0092] availability filter logic configured to filter the licensed user records based on the availability indicators and the identified timing corresponding to the request to execute the command.

[0093] Example 6 is the computing system of any or all previous examples, wherein each of the licensed user records comprises an experience indicator indicative of an experience of the respective licensed user, and wherein the licensed user assignment system comprises:

[0094] work type filter logic configured to filter the licensed user records based on a subject of the command to be executed and the experience indicator in each of the licensed user records.

[0095] Example 7 is the computing system of any or all previous examples, wherein the licensed user interaction system comprises:

[0096] command risk assessment logic configured to identify a risk indicator indicative of a risk level corresponding to the command.

[0097] Example 8 is the computing system of any or all previous examples, wherein the licensed user interaction system comprises:

[0098] risk surfacing logic configured to generate a risk output based on the risk indicator for surfacing to the assigned licensed user.

[0099] Example 9 is the computing system of any or all previous examples, wherein the licensed user interaction system comprises:

[0100] an automatic execution system configured to detect an execution trigger and automatically execute the command based on the execution trigger.

[0101] Example 10 is the computing system of any or all previous examples, wherein the automatic execution system comprises:

[0102] an execution trigger detector configured to detect an authorization input indicative of an authorization of the assigned licensed user to execute the command and generate a trigger detection signal; and

[0103] a command execution logic configured to automatically execute the command on the target computing system in the computing environment based on the trigger detection signal.

[0104] Example 11 is the computing system of any or all previous examples, wherein the request is received from a client computing system, and wherein the permitted user interaction system comprises:

[0105] secure communication channel logic configured to facilitate communication between the client computing system and the permitted user over a communication channel that is in the same compliance boundary as the target computing system.

[0106] Example 12 is the computing system of any or all previous examples, wherein the request is received in a message on the communication channel, and wherein the automatic execution system comprises:

[0107] command retrieval logic configured to automatically retrieve the command from the message on the communication channel and provide the command to the command execution logic for automatic execution.

[0108] Example 13 is the computing system of any or all previous examples, wherein the permitted user interaction system comprises:

[0109] communication pipeline storage system configured to retrieve messages related to the request on the communication channel and provide the messages to an archive data store.

[0110] Example 14 is a computer-implemented method comprising:

[0111] receiving, at a request processing system, a request to execute a command on a target computing system in a computing environment;

[0112] identifying a level of permission sufficient to execute the command on the target computing system in the computing environment;

[0113] accessing a set of permitted user records, each of the permitted user records corresponding to a permitted user, and each permitted user record having a respective permission level indicator indicative of a permission level of the respective user;

[0114] assigning a permitted user to the request based on the permitted user records and based on the level of permission sufficient to execute the command on the target computing system in the computing environment; and

[0115] sending the request to the assigned permitted user.

[0116] Example 15 is the computer-implemented method of any or all previous examples, wherein assigning a permitted user comprises:

[0117] filtering the set of permitted user records based on the respective permission level indicators and the level of permission sufficient to identify permission level records having permission level indicators that satisfy the level of permission sufficient.

[0118] Example 16 is the computer-implemented method of any or all previous examples, wherein each licensed user record includes an availability indicator indicative of an availability of the respective licensed user, and wherein assigning a licensed user comprises:

[0119] identifying a timing corresponding to the request to execute the command;

[0120] filtering the licensed user records based on the availability indicators and the identified timing corresponding to the request to execute the command.

[0121] Example 17 is the computer-implemented method of any or all previous examples, wherein each licensed user record includes an experience indicator indicative of an experience of the respective licensed user, and wherein assigning a licensed user comprises:

[0122] filtering the licensed users based on a subject matter of the command to be executed and the experience indicator in each licensed user record.

[0123] Example 18 is the computer-implemented method of any or all previous examples, wherein sending the request to the assigned licensed user comprises:

[0124] identifying a risk indicator indicative of a risk level corresponding to the command; and

[0125] generating a risk output based on the risk indicator for presentation to the assigned licensed user.

[0126] Example 19 is the computer-implemented method of any or all previous examples, and further comprising:

[0127] detecting an authorization input indicative of the assigned licensed user authorizing execution of the command;

[0128] generating a trigger detection signal; and

[0129] automatically executing the command on the target computing system in the computing environment in accordance with the trigger detection signal.

[0130] Example 20 is a computing system comprising:

[0131] a request processing system that receives a request to execute a command on a target computing system in a computing environment and identifies a level of permission sufficient to execute the command on the target computing system in the computing environment;

[0132] a licensed user pool access system that accesses a set of licensed user records, each of the licensed user records corresponding to a licensed user, and each of the licensed user records having a respective permission level indicator indicative of a level of permission of the respective user;

[0133] a licensed user assignment system that assigns a licensed user to the request based on the licensed user record and based on a permission level sufficient to execute the command on the target computing system in the computing environment;

[0134] a command risk assessment logic configured to identify a risk indicator indicative of a risk level corresponding to the command;

[0135] a risk manifestation logic configured to generate a risk output based on the risk indicator for manifestation to the assigned licensed user;

[0136] a licensed user interaction system that transmits the request and the risk output to the assigned licensed user; and

[0137] an automatic execution system configured to detect an execution trigger indicative of an authorization by the assigned licensed user to execute the command and automatically execute the command based on the execution trigger.

[0138] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A computing system comprising: a request processing system that receives a request to execute a command on a target computing system in a computing environment, and that identifies a command permission level sufficient to execute the command on the target computing system in the computing environment, the target computing system comprising a computing service within a particular compliance boundary, the command permission level indicating a security credential in the particular compliance boundary; a pool of permitted user access system that accesses a set of permitted user records, each permitted user record corresponding to a permitted user, and each permitted user record having a corresponding permission level indicator that indicates a user permission level of the corresponding permitted user; a permitted user assignment system that assigns a permitted user to the request based on a determination that the permitted user has a user permission level that satisfies the command permission level sufficient to execute the command on the target computing system in the computing environment, the user permission level being indicated by the permission level indicator in the permitted user record corresponding to the permitted user; and a permitted user interaction system that sends the request to the assigned permitted user.

2. The computing system of claim 1, wherein, the request processing system comprising: a command permission identifier logic configured to identify the command permission level sufficient to execute the command and to generate a sufficient permission level indicator that indicates that sufficient permission level.

3. The computing system of claim 2, wherein, the permitted user assignment system comprising: a permission level filter system configured to filter the set of permitted user records based on the corresponding permission level indicator and the sufficient permission level to identify a permission level record having a permission level indicator that satisfies the sufficient permission level.

4. The computing system of claim 3, wherein, each of the permitted user records comprising an availability indicator that indicates an availability of the corresponding permitted user, and wherein the request processing system comprises: a timing identifier logic configured to identify a timing corresponding to the request to execute the command.

5. The computing system of claim 4, wherein, the permitted user assignment system comprising: an availability filter logic configured to filter the permitted user records based on the availability indicator and the identified timing corresponding to the request to execute the command.

6. The computing system of claim 3, wherein, each of the permitted user records comprising an experience indicator that indicates an experience of the corresponding permitted user, and wherein the permitted user assignment system comprises: a work type filter logic configured to filter the permitted user records based on a subject matter of the command to be executed and the experience indicator in each of the permitted user records.

7. The computing system of claim 1, wherein, the permitted user interaction system comprising: a command risk assessment logic configured to identify a risk indicator that indicates a risk level corresponding to the command.

8. The computing system of claim 7, wherein, the permitted user interaction system comprising: a risk surfacing logic configured to generate a risk output based on the risk indicator for surfacing to the assigned permitted user.

9. The computing system of claim 1, wherein, the permitted user interaction system comprising: an automated execution system configured to detect an execution trigger and automatically execute the command based on the execution trigger.

10. The computing system of claim 9, wherein, the automated execution system includes: an execution trigger detector configured to detect an authorization input indicating that the assigned permitted user authorizes execution of the command and configured to generate a trigger detection signal; and a command execution logic configured to automatically execute the command on the target computing system in the computing environment based on the trigger detection signal.

11. The computing system of claim 10, wherein, the request is received from a client computing system, and wherein the permitted user interaction system includes: a secure communication channel logic configured to facilitate communication between the client computing system and the permitted user over a communication channel that is in the same compliance boundary as the target computing system.

12. The computing system of claim 11, wherein, the request is received in a message over the communication channel, and wherein the automated execution system includes: a command retrieval logic configured to automatically retrieve the command from the message over the communication channel and provide the command to the command execution logic for automatic execution.

13. The computing system of claim 12, wherein, the permitted user interaction system includes: a communication pipeline storage system configured to retrieve a message related to the request over the communication channel and provide the message to an archival data store.

14. A computer-implemented method comprising: receiving, at a request processing system, a request to execute a command on a target computing system in a computing environment, the target computing system including a computing service within a particular compliance boundary; identifying a command permission level sufficient to execute the command on the target computing system in the computing environment, the command permission level indicating a security credential in the particular compliance boundary; accessing a set of permitted user records, each permitted user record corresponding to a permitted user and each permitted user record having a corresponding permission level indicator indicating a user permission level of the corresponding permitted user; assigning a permitted user to the request based on determining that the permitted user has a user permission level that satisfies the command permission level sufficient to execute the command on the target computing system in the computing environment, the user permission level being indicated by the permission level indicator in the permitted user record corresponding to the permitted user; and sending the request to the assigned permitted user.

15. A computing system comprising: a request processing system that receives a request to execute a command on a target computing system in a computing environment and identifies a command permission level sufficient to execute the command on the target computing system in the computing environment, the target computing system including a computing service within a particular compliance boundary, the command permission level indicating a security credential in the particular compliance boundary; a permitted user pool access system that accesses a set of permitted user records, each permitted user record corresponding to a permitted user and each permitted user record having a corresponding permission level indicator indicating a user permission level of the corresponding permitted user; a licensed user assignment system that assigns one licensed user to the request based on determining that the licensed user has a user permission level that satisfies the command permission level sufficient to execute the command on the target computing system in the computing environment, the user permission level being indicated by the permission level indicator in a licensed user record corresponding to the licensed user; command risk assessment logic configured to identify a risk indicator that indicates a risk level corresponding to the command; risk surfacing logic configured to generate a risk output based on the risk indicator for surfacing to the assigned licensed user; a licensed user interaction system that sends the request and the risk output to the assigned licensed user; and an automatic execution system configured to detect an execution trigger that indicates that the assigned licensed user authorizes execution of the command, and automatically execute the command based on the execution trigger. ​

Images