Preventing destructive operations in production software service environments

Abstract

In some embodiments, a system comprising a client computing device; a third-party service; and a request management computing system is provided. The request management computing system comprises a request management engine configured to perform actions that include: receiving, from the client computing device, a request associated with a user to access the third-party service, and determining whether the request is a destructive action request. In response to determining that the request is a destructive action request, the request management engine determines whether the user is authorized to execute the destructive action request. In response to determining that the user is authorized to execute the destructive action request, the request management engine transmits the request to the third-party service; and in response to determining that the user is not authorized to execute the destructive action request, the request management engine blocks the request.

Description

Docket No. 4291-P3WOPREVENTING DESTRUCTIVE OPERATIONS IN PRODUCTION SOFTWARE SERVICE ENVIRONMENTSCROSS REFERENCE(S) TO RELATED APPLICATION(S)

[0001] This application claims the benefit of Provisional Application No. 63 / 740227, filed December 30, 2024, the entire disclosure of which is hereby incorporated by reference herein for all purposes.TECHNICAL FIELD

[0002] This disclosure relates generally to cloud computing, and in particular but not exclusively, relates to architectures for controlling access to software deployed in a cloud computing environment.BACKGROUND

[0003] Cloud-based software applications, in which complex services are provided by one or more microservices deployed in a cloud computing environment, are becoming increasingly popular. The reliability and scalability provided by cloud computing systems is an attractive deployment option for developers seeking to provide Internet-grade services without having to implement distributed computing features from the ground up.

[0004] That said, the difficulty of managing development in such environments increases with the complexity of the service. When both test versions and production versions of microservices are deployed in the cloud, the danger of accidentally executing destructive actions (e.g., actions that cause data loss or that could otherwise threaten the reliable operation of the software application, etc.) against production services instead of test services becomes acute. What is desired are computing systems that help protect against the dangers of such inadvertent execution of destructive actions.SUMMARY

[0005] 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 of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0006] In some embodiments, a system comprising a client computing device; a third-party service; and a request management computing system is provided. The request management computing system comprises a request management engine configured to perform actionsDocket No. 4291-P3WOthat include: receiving, by the request management engine from the client computing device, a request associated with a user to access the third-party service; determining, by the request management engine, whether the request is a destructive action request; and in response to determining that the request is a destructive action request: determining, by the request management engine, whether the user is authorized to execute the destructive action request; in response to determining that the user is authorized to execute the destructive action request, transmitting, by the request management engine, the request to the third-party service; and in response to determining that the user is not authorized to execute the destructive action request, blocking, by the request management engine, the request.

[0007] In some embodiments, a computer-implemented method of preventing inadvertent execution of destructive actions is provided. A request management computing system receives, from a client computing device, a request associated with a user to access a third-party service. The request management computing system determines whether the request is a destructive action request. In response to determining that the request is a destructive action request, the request management computing system determines whether the user is authorized to execute the destructive action request. In response to determining that the user is authorized to execute the destructive action request, the request management computing system transmits the request to the third-party service, and in response to determining that the user is not authorized to execute the destructive action request, the request management computing system blocks the request.

[0008] In some embodiments, a non-transitory computer-readable medium is provided. The computer-readable medium has computer-executable instructions stored thereon that, in response to execution by one or more processors of a computing system, cause the computing system to perform actions of a method as described above.

[0009] In some embodiments, a computing system configured to perform actions of a method as described above is provided.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

[0011] FIG. 1 is a block diagram of a system for centralized management of access to third-party services according to various aspects of the present disclosure.Docket No. 4291-P3WO

[0012] FIG. 2 is a block diagram that illustrates further details of the system according to various aspects of the present disclosure.

[0013] FIGs. 3A-3C are a flowchart that illustrates a non-limiting example embodiment of a method of preventing inadvertent execution of destructive actions, according to various aspects of the present disclosure.

[0014] FIG. 4 is a block diagram that illustrates aspects of an example computing device appropriate for use as a computing device of the present disclosure.DETAILED DESCRIPTION

[0015] FIG. 1 is a block diagram of a system for centralized management of access to third-party services according to various aspects of the present disclosure. In the system 100, a client computing device 102 (e.g., a laptop computing device, a desktop computing device, a mobile computing device, etc.) connects to one or more third-party services 106 via a request management computing system 104. The third-party services 106 may include cloud services (e.g., Amazon Web Services (AWS) services, Google Cloud services, Microsoft Azure services, etc.), database services (e.g., a MongoDB database service, a Redis database service, a Postgres database service, etc.), a web service, or any other type of service accessible via a network that uses authentication. In some embodiments, a user of the client computing device 102 may have authentication credentials (e.g., login information such as usemame / password) for each of the separate third-party services 106.

[0016] The request management computing system 104 is implemented by one or more computing devices, such as server computing devices, rack-mount computing devices, one or more computing devices of a cloud computing system, or any other types of computing devices. In some embodiments, the request management computing system 104 is provided within a Kubemetes system or another container orchestration system. In some embodiments, one or more of the third-party services 106 are also provided within the same container orchestration system that provides the request management computing system 104.

[0017] In some embodiments, the client computing device 102 provides credentials for accessing the request management computing system 104, after which the client computing device 102 is considered authenticated by the request management computing system 104. Thereafter, the request management computing system 104 intercepts requests from the client computing device 102 that are otherwise directed to the third-party services 106. If the requests do not include credentials for accessing the third-party services 106, the request management computing system 104 retrieves the credentials from a credential vaultDocket No. 4291-P3WOcomputing system, and injects the credentials into the request before relaying it to the appropriate third-party service 106.

[0018] In this way, the client computing device 102 can seamlessly access a third-party service 106 without needing to provide separate access credentials for each of the third-party services 106. The request management computing system 104 may also manage access policies in its own right (e.g., user A has the right to access Third-Party Service B), and so access by users to the third-party services 106 via the request management computing system 104 may be easily controlled by administrators of the request management computing system 104 without having administrative rights to any of the third-party services 106.

[0019] An additional example of functionality that may be provided by the request management computing system 104 is the ability to seamlessly switch between transmitting requests to production services 214 or test services 216. When developing the third-party service 106, a developer may switch back and forth between submitting requests to the test services 216 and the production services 214 for many reasons, including comparing results from the production version of a service and the version of the service under development. In some embodiments, a technology such as that described in commonly owned, co-pending International Application No. PCT / CA2024 / 050594, filed May 2, 2024 and published as WO 2024 / 227254 on November 7, 2024, and Provisional Application No. 63 / 500138, the entire disclosures of which are incorporated herein by reference in their entireties for all purposes, may be used to selectively transmit requests to a production service 214 or a test service 216.

[0020] Switching back and forth between the production service 214 and the test service 216 can lead to a dangerous situation. When operating in a test environment, a developer may create, modify, and / or delete temporary data; may start and stop services; may change the availability of or version of service dependencies; and / or may perform other actions that, if performed against a production service 214, could cause a loss of end-user data, a loss in service availability for end-users, or otherwise disturb the stability and reliability of the production service 214. For example, when operating against the test service 216 to perform a test, a developer may run a series of actions in which a user table is cleared of content before being populated with pre-determined test data. If the requests that implement this test were accidentally run against the production service 214 instead of the test service 216, it could cause the deletion of all of the end user data in the production environment, which would be incredibly destructive.Docket No. 4291-P3WO

[0021] What is desired are techniques for detecting and preventing destructive actions such as this from being inadvertently executed against production services 214.

[0022] FIG. 2 is a block diagram that illustrates further details of the system according to various aspects of the present disclosure. Details of the client computing device 102 are illustrated at the bottom of the drawing, details of the request management computing system 104 are illustrated at the top left of the drawing, and various different systems operated by third-parties (i.e., parties other than the request management computing system 104 and the client computing device 102) are illustrated at the top right of the drawing.

[0023] The client computing device 102 includes at least a client engine 202 (e.g., a web browser or other program that accesses third-party services 106) and a proxy engine 204. The client engine 202 may be configured to generate requests (e.g., HTTP requests or requests in any other suitable request format), which are intercepted by the proxy engine 204. If the proxy engine 204 determines that the request is intended for a third-party service 106 managed by the request management computing system 104, then the proxy engine 204 provides the request to the request management computing system 104. Otherwise, if the proxy engine 204 determines that the request is intended for some other destination, the proxy engine 204 provides the request directly to the other destination. In some embodiments, the proxy engine 204 may use DNS to determine whether a request is targeted to a third-party service 106 or another location.

[0024] As illustrated, the request management computing system 104 includes at least a request management engine 206 and one or more request decoder engines 208. In some embodiments, an operator of a given third-party service 106 may provide the request management computing system 104 with a given request decoder engine 208 configured to handle requests formatted for the given third-party service 106. In this way, the request management computing system 104 can easily be updated to support new third-party services 106, regardless of the request format used. In some embodiments, if a standard request format is shared by more than one third-party service 106, then a shared request decoder engine 208 may be used by those third-party services 106.

[0025] In some embodiments, the request management engine 206 works with a policy service 210 to determine whether a given user has rights to submit a given request to a production service 214 or a test service 216. In some embodiments, the policy service 210 may be implemented by the request management computing system 104. In some embodiments, the policy service 210 may be a policy service provided by another party (e.g., an Open Policy Agent (OPA) service, an Amazon Web Services Identity and AccessDocket No. 4291-P3WOManagement (AWS IAM) service, etc.). In some embodiments, the policy service 210 may also be configured to cause actions to be taken in response to receiving request (e.g., generating an alert if a request is being transmitted to a production service 214, and / or if a policy is allowing a destructive action request to be executed).

[0026] In some embodiments, the request management engine 206 also works with a credential vault computing system 212. The credential vault computing system 212 may store and manage user credentials for accessing the third-party services 106. In some embodiments, the credential vault computing system 212 may store and manage credentials, encryption keys, or other information usable by a given request decoder engine 208 to decode requests directed to a given third-party service 106. In some embodiments, the credential vault computing system 212 may be a credential vault operated by another party (e.g., a Google Cloud Secret Manager, a Microsoft Azure Key Vault, a Bitwarden Secrets Manager, an Amazon Web Services Secrets Manager, etc.). In some embodiments, the credential vault computing system 212 may be implemented by the request management computing system 104.

[0027] Further description of the configuration of the components of the system 100 is provided below.

[0028] FIGs. 3A-3C are a flowchart that illustrates a non-limiting example embodiment of a method of preventing inadvertent execution of destructive actions, according to various aspects of the present disclosure. In the method 300, the request management computing system 104 filters requests from users to prevent inadvertent execution of requests that take destructive actions against production services 214.

[0029] From a start block, the method 300 proceeds to block 302, where a request management engine 206 of a request management computing system 104 receives a request associated with a user to access a third-party service 106. It is assumed in the description of the method 300 that a user of the client computing device 102 has previously authenticated with the request management computing system 104, and so the request management computing system 104 has identified the user associated with the client computing device 102 from which the request is received. In some embodiments, the authentication / identification of the user is associated with a connection between the proxy engine 204 and the request management computing system 104. In some embodiments, the user may be identified by and / or within the received request itself.

[0030] At block 304, the request management engine 206 determines a third-party service 106 associated with the request. In some embodiments, the request management engine 206Docket No. 4291-P3WOmay use a portion of the URL of the request (e.g., a host value or a service being requested) to identify the third-party service 106 being targeted. The third-party service 106 may include one or more production services 214 and / or one or more test services 216. For example, a cloud-based third-party service 106 may be provided using a plurality of microservices, with some of the micro-services being used to provide public functionality of the third-party service 106 to end-users (the production services 214), and with other microservices being used for internal development and testing purposes, with functionality that is not necessarily exposed to end-users (the test services 216).

[0031] At block 306, the request management engine 206 determines a request decoder engine 208 of a plurality of request decoder engines 208 that is associated with the third-party service 106. In some embodiments, a look-up table or other technique may be used to map between the supported third-party services 106 and the request decoder engines 208, and the request management engine 206 may determine the request decoder engine 208 for the third-party service 106 by consulting the look-up table.

[0032] Assuming the user is permitted to submit requests to the third-party service 106 per the policies maintained by the policy service 210, at block 308, the request management engine 206 transmits the request to the request decoder engine 208. At block 310, the request decoder engine 208 decodes the request using a decoding technique associated with the third-party service 106 to determine a type of the request. By using a request decoder engine 208 to determine a type of the request instead of using a static technique for the determination, technical improvements are provided by making the request management computing system 104 capable of flexibly supporting different techniques for making the determination for different third-party services 106.

[0033] In some embodiments, if a simple encoding scheme (e.g., a GET, POST, PATCH, or other request transmitted to a RESTful API via plaintext) is being used, the request decoder engine 208 may process the text of the request based on commonly used request formats to determine a type of action being requested. For example, the request decoder engine 208 may review the text or URL of the request to extract a name of an endpoint being accessed and / or names of the parameters and / or return values. In some embodiments, if a format proprietary to a given third-party service 106 is used to encode or encrypt the request, then the request decoder engine 208 may use associated proprietary techniques to determine the type of action being requested. For example, the request decoder engine 208 associated with a given third-party service 106 may have access to decoding credentials associated with the given third-party service 106 (e.g., a private key, anencryption / decrypt! on key, etc.) usable to decode the request. Such decoding credentialsDocket No. 4291-P3WOmay be retrieved from a credential vault computing system 212 or from any other suitable location. The proprietary techniques may include retrieving and using the decoding credentials to determine the content of the request.

[0034] At block 312, the request management engine 206 determines whether the request is a destructive action based on the type of the request. In some embodiments, the request decoder engine 208 may compare the name, URL, or other text extracted from the request by the request decoder engine 208 to entries in a list of actions known to be destructive actions. For instance, the action names “delete item” or “clear table” may be included in the list of known destructive actions, and a request that is determined to be directed to an endpoint with such a name may be considered a destructive action request. In some embodiments, the request decoder engine 208 may provide a name of the endpoint, a function, a table, and / or other text returned by the request decoder engine 208 that describes the action being invoked by the request to a machine learning model trained to classify requests as being destructive action requests or as not being destructive action requests. Such a machine learning model may use any suitable architecture (including but not limited to artificial neural networks), and may be trained using a labeled set of training data that includes destructive action requests and requests that are not destructive action requests using any suitable technique (including but not limited to gradient descent). In some embodiments, the request decoder engine 208 itself may determine whether the request is a destructive action request, and may return the indication of whether the request is a destructive action request in the type information generated at block 310. The request decoder engine 208 may use any suitable technique for this determination - since the request decoder engine 208 may be associated with a given third-party service 106, it may be practical for the provider of the given third-party service 106 to configure the request decoder engine 208 with a look-up table of whether or not each supported endpoint represents a destructive action.

[0035] The method 300 then proceeds to a decision block 314, where a decision is made based on the determination from block 312 of whether the request is a destructive action. If it was determined that the request is not a destructive action, then the result of decision block 314 is NO, and the method 300 proceeds to block 316 where the request management engine 206 transmits the request to the third-party service 106. Since the request has been determined to not include a destructive action, the request management engine 206 can safely pass it on to the third-party service 106. As with the other instances described below in which the request management engine 206 passes the request on to the third-party service 106, in some embodiments, the third-party service 106 will respond to the request, and theDocket No. 4291-P3WOresponse is transmitted to the client computing device 102. The method 300 then proceeds to an end block and terminates.

[0036] Returning to decision block 314, if it was determined that the request includes a destructive action, then the result of decision block 314 is YES, and the method 300 proceeds to a continuation terminal ("terminal A") to take appropriate action to reduce the likelihood that the destructive action request is being inadvertently transmitted to a production service 214.

[0037] From terminal A (FIG. 3B), the method 300 proceeds to block 318, where the request management engine 206 determines whether the request is being sent to a production service 214 or a test service 216. In some embodiments, the request management engine 206 may be configured with a list of production services 214 and test services 216, which may be identified by IP address, host name, or other readily available identifiable component of the destination address of the request, and the request management engine 206 may compare the request to the list to determine whether it is directed to a production service 214 or a test service 216.

[0038] In some embodiments, the request management engine 206 may delegate the determination of whether the request is being sent to a production service 214 or a test service 216 to the request decoder engine 208 associated with the third-party service 106. In some embodiments, the result received by the request management engine 206 from the request decoder engine 208 may include an indication of whether the target of the request is a production service 214 or a test service 216 as determined by the request decoder engine 208. In some embodiments, the request management engine 206 may transmit a separate query to the request decoder engine 208 for an indication of whether the request is directed to a production service 214 or a test service 216. The request decoder engine 208 may use any suitable technique for the determination, including but not limited to a comparison to a list of production services 214 and test services 216 as described above. As with the determination of whether a request includes a destructive action, one technical benefit of using the request decoder engine 208 to determine whether a request is directed to a production service 214 or a test service 216 is that it improves the expandability and flexibility of the request management computing system 104, because the request management computing system 104 does not itself need to support every way of determining whether a request is directed to a production service 214 or a test service 216 but can instead delegate the determination to a request decoder engine 208 created specifically for a previously unsupported third-party service 106.Docket No. 4291-P3WO

[0039] At decision block 320, a decision is made based on whether the request is being sent to a production service 214 or a test service 216. If it was determined at block 318 that the request is being sent to a test service 216, then the result of decision block 320 is YES, and the method 300 proceeds to block 322, where the request management engine 206 transmits the request to the test service 216 of the third-party service 106, whether or not the request includes a destructive action. While the request may be associated with a destructive action, it would not be desirable to block such actions in a test environment in which a developer would desire greater flexibility and freedom of action. The method 300 then proceeds to an end block and terminates.

[0040] Returning to decision block 320, if it was determined that the request is being sent to a production service 214, then the result of decision block 320 is NO, and the method 300 advances to block 324. It may at times be desirable for the user to submit destructive action requests to production services 214 via the request management computing system 104. The 300 therefore includes steps taken by the request management computing system 104 to ensure that such requests are only passed on to the production services 214 in situations in which the user has been pre-approved to do so. By restricting the pre-approval of users to submit destructive action requests to cases where the requests are expected, inadvertent execution of destructive action requests against production services 214 can be prevented by the request management computing system 104.

[0041] In some embodiments, the request management computing system 104 may provide permanent and / or temporary authorization, based on a user identity, to submit destructive action requests to production services 214. Accordingly, at block 324, the request management engine 206 determines whether the user is permanently authorized for destructive actions. In some embodiments, the request management engine 206 may consult the policy service 210 to determine whether the user is permanently authorized to transmit destructive action requests to production services 214. While this status is described as “permanent,” the permanence of this status may be in comparison to the “temporary” authorization described below in that the status is applied until changed by an administrator. For example, the status of the user may be set by an administrator to “permanently authorized” at the policy service 210 to allow for the submission of a set of several destructive action requests without the need for further action to authorize individual destructive action requests, after which action would be taken by the administrator to remove the “permanently authorized” status for the user from the policy service 210 to prevent inadvertent submission of further destructive action requests.Docket No. 4291-P3WO

[0042] The method 300 then proceeds to a decision block 326, where a decision is made based on whether the user is permanently authorized for destructive actions. If it was determined at block 324 that the user is permanently authorized for destructive actions, then the result of decision block 326 is YES, and the method 300 advances to block 328 where the request management engine 206 transmits the request to the production service 214 of the third-party service 106. The method 300 then proceeds to an end block and terminates.

[0043] Returning to decision block 326, if it was determined at block 324 that the user is not permanently authorized for destructive actions, then the result of decision block 326 is NO, and the method 300 proceeds to a continuation terminal ("terminal B").

[0044] From terminal B (FIG. 3C), the method 300 proceeds to block 330, where the request management engine 206 determines whether a temporary authorization for destructive actions is available for the user. A temporary authorization may be an authorization for a finite number of destructive action requests to be submitted by a given user, after which point further destructive action requests will be considered unauthorized. In some embodiments, the policy service 210 may maintain a flag that indicates whether the next destructive action request received from the user is temporarily authorized, and the determination at block 330 may include checking whether the flag is set. In some embodiments, the policy service 210 may maintain a count of temporary authorizations that are available to the user, and the determination at block 330 may include checking whether the count of temporary authorizations available to the user is greater than zero. An administrator may increment the count of temporary authorizations for a user to allow some expected number of destructive action requests to be submitted by the user without having to submit a separate temporary authorization for each individual request. For example, if a user desires to submit a single destructive action request to a production service 214, an administrator may set the count of temporary authorizations available to the user to one. As another example, if a user desires to submit a pair of destructive action requests to a production service 214 in order to complete an overall task (say, for example, removing records associated with a customer by submitting a first request that deletes an order history for the customer and a second request that deletes the customer record for the customer), an administrator may set the count of temporary authorizations available to the user to two.

[0045] In some embodiments, the policy service 210 may implement a lifetime for temporary authorizations for a user. That is, if a temporary authorization is granted to a user, the policy service 210 may automatically revoke the temporary authorization if it is not used within a predetermined time period. This may help prevent a temporaryDocket No. 4291-P3WOauthorization from being granted for an expected request that does not end up getting submitted, and then being applied later to an unexpected request.

[0046] The method 300 proceeds from block 330 to a decision block 332, where a decision is made based on whether the user is temporarily authorized for destructive actions. If it had been determined at block 330 that the user is temporarily authorized for destructive actions, then the result of decision block 332 is YES, and the method 300 advances to block 334.

[0047] At block 334, the request management engine 206 updates the temporary authorization for the user. For example, if a count of temporary authorizations is used to keep track of the number of times the user is authorized to submit a destructive action request, the request management engine 206 may decrement (or cause the policy service 210 to decrement) the count of temporary authorizations for the user at block 334. As another example if a flag is used to keep track of whether the next destructive action request from the user is authorized, the request management engine 206 may clear the flag at block 334.

[0048] The method 300 then proceeds to block 336, where the request management engine 206 transmits the request to the production service 214 of the third-party service 106. By updating the temporary authorization for the user prior to transmitting the request to the production service 214, the request management engine 206 can avoid race conditions wherein multiple destructive action requests submitted in parallel might be submitted prior to adjusting the temporary authorization. In some embodiments, the update to the temporary authorization at block 334 and the transmission of the request to the third-party service 106 may be performed in an atomic manner. In some embodiments, the update to the temporary authorization at block 334 alone may be performed in a thread-safe manner, such that only one of a plurality requests submitted in parallel will be able to check for and update the temporary authorization at a time.

[0049] The method 300 then proceeds to an end block and terminates.

[0050] Returning to decision block 332, if it had been determined at block 330 that the user is not temporarily authorized for destructive actions, then the result of decision block 332 is NO, and the method 300 advances to block 338. The user may be determined to not be temporarily authorized if no temporary authorization had ever been granted to the user, if a flag indicating temporary authorization is not set, if the count of temporary authorizations previously assigned to the user has been decremented to zero, or based on any other indication that the user is not temporarily authorized. At block 338, the request management engine 206 blocks the request. When blocking the request, the request management engineDocket No. 4291-P3WO206 prevents the request from being transmitted to the production service 214, and may send a suitable error result to the client computing device 102 that informs the user of the reason why the request was blocked. In some embodiments, the error result sent to the client computing device 102 may cause the presentation of instructions to the user regarding how to request or set temporary authorization to allow the request to be permitted when resubmitted (e.g., by having an administrator increment the temporary authorization count).

[0051] The method 300 then proceeds to an end block and terminates.

[0052] While method 300 is illustrated as ending at each end block, one of skill in the art will recognize that the method 300 may be performed each time a request is received from the client computing device 102 by the request management computing system 104. One of skill in the art will also recognize that more than one instance of the method 300 may be executed by the system 100 at least partially concurrently.

[0053] By using the techniques of the method 300, a developer can both be protected from inadvertently executing destructive actions against a production service 214 instead of a test service 216, but can also be granted permission to carefully execute destructive actions against a production service 214 when desired and expected.

[0054] In a non-limiting example embodiment of use of the method 300, a user may be working on development of the third-party service 106, and may be transmitting requests to the third-party service 106 via the request management computing system 104. The user may direct requests to either the test service 216 or the production service 214 based on code on the client computing device 102, or may use settings on the request management computing system 104 to have the request management computing system 104 direct requests to the test service 216 or the production service 214 as appropriate.

[0055] The user may create a test case to be executed against the test service 216 that includes submitting a request that causes an activity log to be cleared so that new activity logged during the execution of the test case is apparent. Because the test case includes a step that deletes information, the associated request would be identified as a destructive action request. While continuing to develop the third-party service 106, the user may change a configuration that points traffic from the client computing device 102 to the production service 214 instead of the test service 216.

[0056] At this point, the user may, without considering the reconfiguration, execute the test case. Since traffic is now pointing at the production service 214, if the method 300 is not being used the test case will delete the information from the activity log in the production service 214, which could be disastrous. However, when using the method 300,Docket No. 4291-P3WOthe request management engine 206 will identify the request as a destructive action request, block the request, and potentially inform the user of the reason for the failure.

[0057] In other circumstances, the user may wish to clear the content of the activity log on the production service 214. Such a request would still be blocked by the request management engine 206, and the user may be informed of the reason for the error. An administrator may then be asked to set a temporary authorization flag for the user. Once the temporary authorization flag has been set, the user may resubmit the request to clear the activity log on the production service 214, which will then be allowed by the request management engine 206 before clearing the temporary authorization flag to block future inadvertent destructive action requests. As can be seen, the user is given both protections from inadvertent destructive actions and the flexibility to use the request management computing system 104 to handle request traffic as desired at various times.

[0058] The discussion above refers to actions performed by an administrator to grant authorization to the user. In some embodiments, the users themselves may be given administrative privileges, and may be able to provide permanent or temporary authorizations for themselves. In such embodiments, the request management computing system 104 acts as a warning system and a backstop against inadvertent destructive actions. In other embodiments in which the users do not have administrative privileges to grant permanent or temporary authorizations, the request management computing system 104 can act as a security layer in which administrative oversight is provided before destructive actions are taken against the production service 214.

[0059] Further, the discussion above describes two categories of actions: destructive actions and actions that are not destructive actions. In some embodiments, additional categories of actions may be provided, and permanent and / or temporary authorizations may be managed separately for each category. As a non-limiting example, separate authorizations may be provided for actions that return information from a third-party service 106. For third-party services 106 that store sensitive customer information, developers may be allowed to freely retrieve information from the test service 216 during the course of development of the third-party service 106, but may need special authorization to access live, sensitive data on the production service 214. As another non-limiting example, separate authorizations may be provided for actions that affect small amounts of data (e.g., an update or delete to a single object or database row, etc.) versus large amounts of data (e.g., a bulk update or delete; an action that changes a database structure, etc.).Docket No. 4291-P3WO

[0060] FIG. 4 is a block diagram that illustrates aspects of an example computing device 400 appropriate for use as a computing device of the present disclosure. One or more computing devices 400 may be used to provide any of the computing systems described above. While multiple different types of computing devices were discussed above, the example computing device 400 describes various elements that are common to many different types of computing devices. While FIG. 4 is described with reference to a computing device that is implemented as a device on a network, the description below is applicable to servers, personal computers, mobile phones, smart phones, tablet computers, embedded computing devices, and other devices that may be used to implement portions of embodiments of the present disclosure. Some embodiments of a computing device may be implemented in or may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other customized device. Moreover, those of ordinary skill in the art and others will recognize that the computing device 400 may be any one of any number of currently available or yet to be developed devices.

[0061] In its most basic configuration, the computing device 400 includes at least one processor 402 and a system memory 410 connected by a communication bus408. Depending on the exact configuration and type of device, the system memory 410 may be volatile or nonvolatile memory, such as read only memory (“ROM”), random access memory (“RAM”), EEPROM, flash memory, or similar memory technology. Those of ordinary skill in the art and others will recognize that system memory 410 typically stores data and / or program modules that are immediately accessible to and / or currently being operated on by the processor 402. In this regard, the processor 402 may serve as a computational center of the computing device 400 by supporting the execution of instructions.

[0062] As further illustrated in FIG. 4, the computing device 400 may include a network interface 406 comprising one or more components for communicating with other devices over a network. Embodiments of the present disclosure may access basic services that utilize the network interface 406 to perform communications using common network protocols. The network interface 406 may also include a wireless network interface configured to communicate via one or more wireless communication protocols, such as WiFi, 2G, 3G, LTE, WiMAX, Bluetooth, Bluetooth low energy, and / or the like. As will be appreciated by one of ordinary skill in the art, the network interface 406 illustrated in FIG. 4 may represent one or more wireless interfaces or physical communication interfaces described and illustrated above with respect to particular components of the computing device 400.Docket No. 4291-P3WO

[0063] In the exemplary embodiment depicted in FIG. 4, the computing device 400 also includes a storage medium 404. However, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Therefore, the storage medium 404 depicted in FIG. 4 is represented with a dashed line to indicate that the storage medium 404 is optional. In any event, the storage medium 404 may be volatile or nonvolatile, removable or nonremovable, implemented using any technology capable of storing information such as, but not limited to, a hard drive, solid state drive, CD ROM, DVD, or other disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, and / or the like.

[0064] Suitable implementations of computing devices that include a processor 402, system memory 410, communication bus 408, storage medium 404, and network interface 406 are known and commercially available. For ease of illustration and because it is not important for an understanding of the claimed subject matter, FIG. 4 does not show some of the typical components of many computing devices. In this regard, the computing device 400 may include input devices, such as a keyboard, keypad, mouse, microphone, touch input device, touch screen, tablet, and / or the like. Such input devices may be coupled to the computing device 400 by wired or wireless connections including RF, infrared, serial, parallel, Bluetooth, Bluetooth low energy, USB, or other suitable connections protocols using wireless or physical connections. Similarly, the computing device 400 may also include output devices such as a display, speakers, printer, etc. Since these devices are well known in the art, they are not illustrated or described further herein.

[0065] As used herein, "engine" refers to logic embodied in hardware or software instructions, which can be written in one or more programming languages, including but not limited to C, C++, C#, COBOL, JAVA™, PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, Go, and Python. An engine may be compiled into executable programs or written in interpreted programming languages. Software engines may be callable from other engines or from themselves. Generally, the engines described herein refer to logical modules that can be merged with other engines, or can be divided into sub-engines. The engines can be implemented by logic stored in any type of computer-readable medium or computer storage device and be stored on and executed by one or more general purpose computers, thus creating a special purpose computer configured to provide the engine or the functionality thereof. The engines can be implemented by logic programmed into an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another hardware device.Docket No. 4291-P3WO

[0066] As used herein, "computer-readable medium" refers to a removable or nonremovable device that implements any technology capable of storing information in a volatile or non-volatile manner to be read by a processor of a computing device, including but not limited to: a hard drive; a flash memory; a solid state drive; random-access memory (RAM); read-only memory (ROM); a CD-ROM, a DVD, or other disk storage; a magnetic cassette; a magnetic tape; and a magnetic disk storage.

[0067] While illustrative embodiments have been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.Docket No. 4291-P3WOEXAMPLES

[0068] Below are a set of numbered, non-limiting, example embodiments of the present disclosure.

[0069] Embodiment 1 : A system, comprising: a client computing device; a third-party service; and a request management computing system comprising a request management engine configured to perform actions comprising: receiving, by the request management engine from the client computing device, a request associated with a user to access the third-party service; determining, by the request management engine, whether the request is a destructive action request; and in response to determining that the request is a destructive action request: determining, by the request management engine, whether the user is authorized to execute the destructive action request; in response to determining that the user is authorized to execute the destructive action request, transmitting, by the request management engine, the request to the third-party service; and in response to determining that the user is not authorized to execute the destructive action request, blocking, by the request management engine, the request.

[0070] Embodiment 2: The system of embodiment 1, wherein the actions further comprise, in response to determining that the request is not a destructive action request, transmitting, by the request management engine, the request to the third-party service.

[0071] Embodiment 3: The system of any one of embodiments 1-2, wherein the third-party service includes a production service and a test service; and wherein determining whether the request is a destructive action request includes determining whether the request is directed to the production service or the test service.

[0072] Embodiment 4: The system of any one of embodiments 1-3, wherein the third-party service includes a cloud function, a web service, a MongoDB database, a Redis database, or a Postgres database.

[0073] Embodiment 5: The system of any one of embodiments 1-4, wherein determining whether the user is authorized to execute the destructive action request includes using a policy service to consult a policy for the user.

[0074] Embodiment 6: The system of embodiment 5, wherein the policy service is an Open Policy Agent (OPA) service or an Amazon Web Services Identity and Access Management (IAM) service.

[0075] Embodiment 7: The system of any one of embodiments 1-6, wherein determining whether the user is authorized to execute the destructive action request includes determining that a temporary authorization flag is set for the user; and wherein transmitting the requestDocket No. 4291-P3WOto the third-party service in response to determining that the user is authorized to execute the destructive action request includes resetting the temporary authorization flag.

[0076] Embodiment 8: The system of any one of embodiments 1-7, further comprising a plurality of third-party services, wherein the third-party service is included in the plurality of third-party services; and wherein the actions further comprise: determining, by the request management engine, the third-party service of the plurality of third-party services associated with the request based on content of the request.

[0077] Embodiment 9: The system of embodiment 8, wherein determining the third-party service associated with the request based on the content of the request includes extracting a host value from a URL of the request.

[0078] Embodiment 10: The system of any one of embodiments 8-9, wherein the request management computing system further comprises a plurality of request decoder engines; wherein each request decoder engine of the plurality of request decoder engines is associated with a third-party service of the plurality of third-party services; wherein determining whether the request is a destructive action request includes providing the request to the request decoder engine associated with the third-party service; and wherein each request decoder engine is configured to perform actions comprising: receiving the request from the request management engine; and decoding the request using a decoding technique associated with the third-party service to determine whether the request is a destructive action request.

[0079] Embodiment 11 : A computer-implemented method of preventing inadvertent execution of destructive actions, the method comprising: receiving, by a request management computing system from a client computing device, a request associated with a user to access a third-party service; determining, by the request management computing system, whether the request is a destructive action request; and in response to determining that the request is a destructive action request: determining, by the request management computing system, whether the user is authorized to execute the destructive action request; in response to determining that the user is authorized to execute the destructive action request, transmitting, by the request management computing system, the request to the third-party service; and in response to determining that the user is not authorized to execute the destructive action request, blocking, by the request management computing system, the request.Docket No. 4291-P3WO

[0080] Embodiment 12: The method of embodiment 11, further comprising, in response to determining that the request is not a destructive action request, transmitting, by the request management computing system, the request to the third-party service.

[0081] Embodiment 13: The method of any one of embodiments 11-12, wherein the third-party service includes a production service and a test service; and wherein determining whether the request is a destructive action request includes determining whether the request is directed to the production service or the test service.

[0082] Embodiment 14: The method of any one of embodiments 11-13, wherein the third-party service includes a cloud function, a web service, a MongoDB database, a Redis database, or a Postgres database.

[0083] Embodiment 15: The method of any one of embodiments 11-14, wherein determining whether the user is authorized to execute the destructive action request includes using a policy service to consult a policy for the user.

[0084] Embodiment 16: The method of embodiment 15, wherein the policy service is an Open Policy Agent (OP A) service or an Amazon Web Services Identity and Access Management (IAM) service.

[0085] Embodiment 17: The method of any one of embodiments 11-16, wherein determining whether the user is authorized to execute the destructive action request includes determining that a temporary authorization flag is set for the user; and wherein transmitting the request to the third-party service in response to determining that the user is authorized to execute the destructive action request includes resetting the temporary authorization flag.

[0086] Embodiment 18: The method of any one of embodiments 11-17, further comprising determining, by the request management computing system, a third-party service of a plurality of third-party services associated with the request based on content of the request.

[0087] Embodiment 19: The method of embodiment 18, wherein determining the third-party service associated with the request based on the content of the request includes extracting a host value from a URL of the request.

[0088] Embodiment 20: The method of any one of embodiments 18-19, wherein determining whether the request is a destructive action request includes: determining a request decoder engine of a plurality of request decoder engines that is associated with the third-party service; decoding the request using the request decoder engine using a decoding technique associated with the third-party service to determine whether the request is a destructive action request.Docket No. 4291-P3WO

[0089] Embodiment 21: A non-transitory computer-readable medium having computerexecutable instructions stored thereon that, in response to execution by one or more processors of a computing system, cause the computing system to perform actions of a method as recited in any one of embodiments 11 to 20.

[0090] Embodiment 22: A computing system configured to perform actions of a method as recited in any one of embodiments 11 to 20.

Claims

Docket No. 4291-P3WOCLAIMSThe embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A system, comprising:a client computing device;a third-party service; anda request management computing system comprising a request management engine configured to perform actions comprising:receiving, by the request management engine from the client computing device, a request associated with a user to access the third-party service;determining, by the request management engine, whether the request is a destructive action request; andin response to determining that the request is a destructive action request: determining, by the request management engine, whether the user is authorized to execute the destructive action request;in response to determining that the user is authorized to execute the destructive action request, transmitting, by the request management engine, the request to the third-party service; andin response to determining that the user is not authorized to execute the destructive action request, blocking, by the request management engine, the request.

2. The system of claim 1, wherein the actions further comprise, in response to determining that the request is not a destructive action request, transmitting, by the request management engine, the request to the third-party service.

3. The system of claim 1, wherein the third-party service includes a production service and a test service; andwherein determining whether the request is a destructive action request includes determining whether the request is directed to the production service or the test service.

4. The system of claim 1, wherein the third-party service includes a cloud function, a web service, a MongoDB database, a Redis database, or a Postgres database.

5. The system of claim 1, wherein determining whether the user is authorized to execute the destructive action request includes using a policy service to consult a policy for the user.Docket No. 4291-P3WO6. The system of claim 5, wherein the policy service is an Open Policy Agent (OPA) service or an Amazon Web Services Identity and Access Management (IAM) service.

7. The system of claim 1, wherein determining whether the user is authorized to execute the destructive action request includes determining that a temporary authorization flag is set for the user; andwherein transmitting the request to the third-party service in response to determining that the user is authorized to execute the destructive action request includes resetting the temporary authorization flag.

8. The system of claim 1, further comprising a plurality of third-party services, wherein the third-party service is included in the plurality of third-party services; andwherein the actions further comprise:determining, by the request management engine, the third-party service of the plurality of third-party services associated with the request based on content of the request.

9. The system of claim 8, wherein determining the third-party service associated with the request based on the content of the request includes extracting a host value from a URL of the request.

10. The system of claim 8, wherein the request management computing system further comprises a plurality of request decoder engines;wherein each request decoder engine of the plurality of request decoder engines is associated with a third-party service of the plurality of third-party services;wherein determining whether the request is a destructive action request includes providing the request to the request decoder engine associated with the third-party service; andwherein each request decoder engine is configured to perform actions comprising:receiving the request from the request management engine; and decoding the request using a decoding technique associated with the third- party service to determine whether the request is a destructive action request.

11. A computer-implemented method of preventing inadvertent execution of destructive actions, the method comprising:receiving, by a request management computing system from a client computing device, a request associated with a user to access a third-party service;Docket No. 4291-P3WOdetermining, by the request management computing system, whether the request is a destructive action request; andin response to determining that the request is a destructive action request:determining, by the request management computing system, whether the user is authorized to execute the destructive action request;in response to determining that the user is authorized to execute the destructive action request, transmitting, by the request management computing system, the request to the third-party service; andin response to determining that the user is not authorized to execute the destructive action request, blocking, by the request management computing system, the request.

12. The method of claim 11, further comprising, in response to determining that the request is not a destructive action request, transmitting, by the request management computing system, the request to the third-party service.

13. The method of claim 11, wherein the third-party service includes a production service and a test service; andwherein determining whether the request is a destructive action request includes determining whether the request is directed to the production service or the test service.

14. The method of claim 11, wherein the third-party service includes a cloud function, a web service, a MongoDB database, a Redis database, or a Postgres database.

15. The method of claim 11, wherein determining whether the user is authorized to execute the destructive action request includes using a policy service to consult a policy for the user.

16. The method of claim 15, wherein the policy service is an Open Policy Agent (OPA) service or an Amazon Web Services Identity and Access Management (IAM) service.

17. The method of claim 11, wherein determining whether the user is authorized to execute the destructive action request includes determining that a temporary authorization flag is set for the user; andwherein transmitting the request to the third-party service in response to determining that the user is authorized to execute the destructive action request includes resetting the temporary authorization flag.Docket No. 4291-P3WO18. The method of claim 11, further comprising determining, by the request management computing system, a third-party service of a plurality of third-party services associated with the request based on content of the request.

19. The method of claim 18, wherein determining the third-party service associated with the request based on the content of the request includes extracting a host value from a URL of the request.

20. The method of claim 18, wherein determining whether the request is a destructive action request includes:determining a request decoder engine of a plurality of request decoder engines that is associated with the third-party service;decoding the request using the request decoder engine using a decoding technique associated with the third-party service to determine whether the request is a destructive action request.

21. A non-transitory computer-readable medium having computer-executable instructions stored thereon that, in response to execution by one or more processors of a computing system, cause the computing system to perform actions of a method as recited in any one of claims 11 to 20.

22. A computing system configured to perform actions of a method as recited in any one of claims 11 to 20.

Images