RU2807463C2 - Ransomware mitigation in integrated isolated applications - Google Patents

Abstract

FIELD: computer engineering.

SUBSTANCE: invention is aimed to increase the security of the network and/or resources associated with it. It is achieved due to the fact that a token request from an application running in the first computing environment can be received in the second computing environment. The second computing environment may assign a trust level to the received token request that indicates that the first computing environment may not be trusted. The token request along with the trust level may be provided to the authorization server to generate an authorization token that includes a trust indicator indicating the trust level of the second computing environment. When an application running on a second computing environment passes an authorization token to a resource manager to access a resource, the resource manager may be configured to take precautionary actions to protect the resource before granting access, such as creating a backup copy of the resource.

EFFECT: increase in the security of the network and/or resources associated with it.

15 cl, 7 dwg

Description

State of the art

[0001] In isolated computing devices, applications can be executed in an environment that is partially or completely isolated from the main computing environment of the computing host. Such isolated devices can provide additional security to the host environment by limiting and/or preventing applications from accessing host environment resources. In many cases, an application running in a sandboxed environment cannot be trusted or may have a higher risk of being susceptible to malicious activity, thereby making the isolation barrier between the application and the host environment more critical from a security perspective. In other words, even if the malicious code was executed in an application sandbox, the risk to the host environment could be minimized by an isolation barrier.

[0002] However, to improve the user experience, certain holes in the isolation barrier may be present intentionally, for example, when allowing access to host environment files for an application in an isolated environment. While such holes in the isolation barrier may improve integration between the sandboxed environment and the host environment, these seemingly innocuous attempts to improve the user experience may nonetheless introduce security vulnerabilities to the host environment. For example, malicious code called ransomware, which can penetrate sandboxed environments, can be enabled to encrypt a user's private data stored in the host environment with an encryption key known only to the attacker. In such situations, the user is forced to pay a ransom to the attacker in order to regain access to their data. Thus, even though an application may be isolated, holes in the isolation barrier can still lead to these and other types of vulnerabilities.

The essence of the invention

[0003] This summary is provided to introduce in a simplified form a selection of concepts that are further described below in the detailed description. This summary of the invention is not intended either to identify key features or essential features of the claimed invention, nor to be used to limit the scope of the claimed invention.

[0004] Methods, systems, devices, and computer program products are provided for providing secure access to a resource. A token request from an application running in a first computing environment (eg, a virtual machine) may be received in a second computing environment (eg, a host computing environment). The host computing environment may assign a trust level to the received token request, for example, a trust level that indicates that the first computing environment cannot be trusted. The token request along with the trust level may be provided to the token issuer (eg, an authorization server), which may validate the identification information in the token and generate an authorization token that includes a trust indicator. The trust indicator may indicate, for example, the level of trust of the second computing environment. The host computing environment can obtain the authorization token and provide it to the application. When an application running on a second computing environment passes an authorization token to a resource manager to access a resource, the resource manager may be configured to perform precautionary actions before granting access, such as creating a backup copy of the resource.

[0005] Additional features and advantages of the invention, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It should be noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented here for illustrative purposes only. Additional embodiments will be apparent to those skilled in the relevant art(s) based on the teachings contained herein.

Brief description of drawings/figures

[0006] The accompanying drawings, which are included herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and to enable one skilled in the related art to make and use the embodiments.

[0007] FIG. 1 shows a block diagram of a system for providing access to a resource in a secure manner according to an exemplary embodiment.

[0008] FIG. 2 shows a flowchart of a method for granting authorization that includes a trust indicator for an application, according to an exemplary embodiment.

[0009] FIG. 3 shows a block diagram of a system for providing access to a network resource in a secure manner according to an exemplary embodiment.

[0010] FIG. 4 shows a flowchart of a method for generating an authorization token that includes a trust indicator, according to an exemplary embodiment.

[0011] FIG. 5 shows a flowchart of a method for performing a preventive action to protect a resource according to an exemplary embodiment.

[0012] FIG. 6 shows a block diagram of a system for providing access to a local resource in a secure manner according to an exemplary embodiment.

[0013] FIG. 7 shows a block diagram of an example computing device that may be used to implement example embodiments.

[0014] Features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference numerals denote corresponding elements throughout the document. In the drawings, like reference numerals generally indicate the same, functionally similar and/or structurally similar elements. The drawing on which the element first appears is indicated by the leftmost number(s) in the corresponding reference number.

Detailed Description of the Invention

I. Introduction

[0015] The present description and the accompanying drawings disclose one or more embodiments that include features of the present invention. The scope of the present invention is not limited to the disclosed embodiments. The disclosed embodiments merely illustrate the present invention, and modified versions of the disclosed embodiments are also encompassed by the present invention. Embodiments of the present invention are defined by the accompanying claims.

[0016] References in the specification to “one embodiment,” “an embodiment,” “an exemplary embodiment,” etc. indicate that the described embodiment may include a particular feature, structure or characteristic, but each embodiment may not necessarily include a particular feature, structure or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Additionally, when a particular feature, structure or characteristic is described in connection with an exemplary embodiment, it is believed that it is within the knowledge of one skilled in the art to implement such feature, structure or characteristic in connection with other embodiments explicitly or implicitly described.

[0017] In the discussion, unless otherwise stated, terms such as “substantially” and “about” modifying a condition or characteristic of the relationship of a feature or features of an exemplary embodiment of the invention are understood to mean that the condition or characteristic is defined within tolerances that are acceptable for the operation of the embodiment for the application for which it is intended.

[0018] Numerous exemplary embodiments are described as follows. It should be noted that any section/subsection headings presented herein are not intended to be limiting. Embodiments are described in this document, and any type of embodiment may be included in any section/subsection. In addition, embodiments disclosed in any section/subsection may be combined with any other embodiments described in the same section/subsection and/or another section/subsection in any manner.

II. Example implementations

[0019] In isolated computing devices, applications may run in an environment that is partially or completely isolated from the main computing environment of the computing host. Such isolated devices can provide additional security to the host environment by limiting and/or preventing applications from accessing host environment resources. In many cases, an application running in a sandboxed environment cannot be trusted or may have a higher risk of being susceptible to malicious activity, thereby making the isolation barrier between the application and the host environment more critical from a security perspective. In other words, even if the malicious code was executed in an application sandbox, the risk to the host environment could be minimized by an isolation barrier.

[0020] However, to improve the user experience, certain holes in the isolation barrier may be present intentionally, for example, when allowing access to host environment files for an application in an isolated environment. While such holes in the isolation barrier may improve integration between the sandboxed environment and the host environment, these seemingly innocuous attempts to improve the user experience may nonetheless introduce security vulnerabilities to the host environment. For example, malicious code called ransomware, which can penetrate sandboxed environments, can be enabled to encrypt a user's private data stored in the host environment with an encryption key known only to the attacker. In such situations, the user is forced to pay a ransom to the attacker in order to regain access to their data. Thus, even though an application may be isolated, holes in the isolation barrier can still lead to these and other types of vulnerabilities.

[0021] The embodiments described herein solve these and other problems by providing a system for providing access to a resource in a reliable manner. In an exemplary system, a first environment that receives a token request from another environment at least partially isolated from it (eg, an application running on a virtual machine of the first environment) may receive an authorization token that includes a trust indicator. The trust indicator may indicate the trust level of the environment in which the token request was initiated, which may contain an untrusted environment that may be vulnerable to malicious activity. When an application attempts to access a trusted resource using an authorization token, the resource provider can take preventative action.

[0022] In this way, resources can be protected from malicious activity or malicious code, such as ransomware or any other type of malware, malicious code, or breach in which an unauthorized entity attempts to access the user's resources (e.g., data or services). For example, even if an attacker attempted to encrypt a user's data in an attempt to obtain ransom, a backup copy of the user's resources could be automatically created when the attacker accesses the data based on the trust indicator included in the authorization token. A backup copy of the user's resources, which may be stored in a location inaccessible to the attacker and/or encrypted, can later be restored by the user so that the user does not have to pay a ransom to the attacker. In this way, the harm caused by malicious actions in a less secure computing environment can be reduced or completely prevented.

[0023] Providing access to resources in a secure manner, as described herein, has numerous benefits, including increasing the security of the network and/or resources (eg, computing devices, storage devices, etc.) associated with it. For example, by providing an authorization token that includes a trust indicator, resource providers that may grant access to resources in response to receipt of an authorization token (which may be local resource providers or network-accessible resource servers) may take one or more proactive actions to protect the resource, such as backing up the resource, limiting the scope of access (for example, providing read-only access instead of read/write access), performing an enhanced authentication procedure (for example, two-factor authentication), or other preventive action. As a result, resources can be protected from malicious activities initiated from environments considered less secure. Additionally, since resource providers can obtain authentication tokens that include trust indicators built into them, resource providers can be configured to detect anomalous network activity (for example, when a particular application accesses an abnormal amount of resources with that authorization token). As a result, malicious activity occurring on the network and/or its associated resources can be contained, reduced and/or prevented in accordance with the principle described herein.

[0024] Described below are exemplary embodiments of systems and methods for providing access to a resource in a secure manner. For example, FIG. 1 shows a block diagram of a system 100 according to an exemplary embodiment. As shown in FIG. 1, system 100 includes a computing device 102, an authorization server 108, and a resource server 112 that are communicatively connected by a network 110, and secure resources 116 connected to the resource server 112. System 100 may contain any number of computing devices and/or servers, including those shown in FIG. 1, and possibly one or more additional devices not explicitly illustrated. As shown in FIG. 1, computing device 102 includes a hosted virtual machine 104 and an authorization token manager 106. As described in more detail below, the authorization token manager 106 may be configured to receive a token request from an application running on the virtual machine 104, obtain an authorization token with a trust indicator, and provide an authorization token including a trust indicator to an application on the virtual machine 104. Server 108 authorization includes the publisher of 110 tokens. The resource server 112 includes a resource manager 114 . Although fig. 1 is described with respect to an application running on virtual machine 104, such implementation is not intended to be limiting. Other types of partially and/or fully isolated computing environments in which token requests may occur are also considered, as described below. The system 100 is further described as follows.

[0025] Network 110 may include one or more of any of a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a combination of communications networks such as the Internet, and/or a virtual network. In exemplary implementations, computing device 102, authorization server 108, resource server 112, and/or secure resources 116 may be communicatively coupled to each other via network 110. In an implementation, any one or more computing devices 102, authorization server 108, resource server 112, and/or or the protected resources 116 may communicate through one or more application programming interfaces (APIs) and/or in accordance with other interfaces and/or technologies. The computing device 102, authorization server 108, resource server 112, and/or secure resources 116 may include at least one network interface that communicates with each other. Examples of such a network interface, wired or wireless, include an IEEE 802.11 wireless local area network (WLAN) interface, a Worldwide Compatibility Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, Bluetooth™ interface, near field communication (NFC) interface, etc. Additional examples of network interfaces are described elsewhere in this document.

[0026] Computing device 102 includes any computing device of one or more users (e.g., individual users, family users, enterprise users, government users, etc.), which may contain one or more applications, operating systems, virtual machines , storage devices, etc., which may be executed, hosted, and/or stored therein or through one or more other computing devices via network 110. In some examples, computing device 102 may access one or more server devices, such as an authentication server 108 and/or a resource server 112, for accessing one or more secure resources 116, as described herein. Computing device 102 may include any number of computing devices, including tens, hundreds, thousands, millions, or even more computing devices. Each computing device of computing device 102 may be any type of desktop or mobile computing device, including a mobile computer or a mobile computing device (e.g., a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer, such as an Apple iPad™, netbook, etc.), a mobile phone, a wearable computing device or other mobile device, or a desktop computing device such as a desktop computer or PC (personal computer) or server. The computing device 102 is not limited to a physical machine, but may include other types of machines or nodes, such as a virtual machine. Each computing device 102 may interact with the authorization server 108 and/or resource server 112 through APIs and/or other mechanisms. Please note that any number of software interfaces may be present.

[0027] Authorization server 108 may comprise any computing device, server, and/or service for issuing one or more authorization tokens to computing devices on network 110 requesting such tokens. As will be described in more detail below, an authorization token may include any object (eg, a set of data) that allows a computing device, computing environment, and/or applications to access a resource. For example, an authorization token may be a file or other object that includes one or more of an identifier for the token, an identifier for the corresponding login session, an identifier for the application requesting access, a user identifier for the user of the application requesting access, and an indicator of one or more privileges granted by the authorization token.

[0028] In some examples, the authorization server 108 may include an identity service or identity provider configured to verify the identity information of an entity requesting an authorization token, including, but not limited to, user credentials (e.g., username and/or password), user alias, account number, biometric information, or any other information or credentials that can be used to securely access a resource. According to implementations, the token issuer 110 of the authorization server 108 may generate and issue a token for transmission to the computing device 102, which further includes a trust indicator that may indicate the trust level of the environment in which the token was requested and/or is intended to used to access a resource (eg, protected resources 116). In some cases, the authorization server 108 may be configured to provide, based on verified identity information, access to multiple resources not associated with and/or authorized by the authorization server 108. In some other cases, the authorization server 108 and/or the resource server 112 may contain affiliated entities and/or may be implemented on a single server or a collection of servers.

[0029] Resource server 112 may contain any one or more computing devices, servers, services, local processes, remote machines, web services, etc. for hosting, managing, and/or providing access to protected resources 116 by users of the computing device 102. For example, the resource server 112 may include a server located on the organization's premises and/or connected to the organization's local network, a remotely located server, a cloud server (for example, one or more servers in a distributed manner) or any other device or service that can host, manage, and/or provide access to secure resources 116. Secured resources 116 may include any type of resource connected to a network, including, but not limited to, computing or processing resources, software resources (e.g. software as a service (SaaS), platform as a service (PaaS), etc.), storage resources (e.g. physical storage devices, local storage devices, cloud storage, hard drives, solid state drives, random access memory (RAM), etc.), databases, etc.

[0030] For example, secure resources 116 may include storage devices for storing any data that is confidential, critical, private, secure and/or otherwise not intended for public dissemination, such as personal information, educational information, medical information, professional information, organizational or company information, banking or other financial records, legal documents, biographical information such as birth certificates, driver's licenses, passports, etc. These examples are illustrative only, and protected resources 116 may include any other type of data (including both sensitive and non-sensitive information) that may be stored on any device, either locally and/or in the cloud. In some examples, protected resources 116 may be stored in a secure manner, such as through password protection, encryption (e.g., public/private key encryption, symmetric keys, etc.), or any other secure manner that would be appreciated by those skilled in the art. technology so that read/write access can only be granted by the owner of the data.

[0031] In exemplary embodiments, computing device 102 may comprise a plurality of computing environments, including, but not limited to, a host computing environment (e.g., the environment on which the host operating system of computing device 102 is running), and one or more other computing environments. environments that can be completely or partially isolated from the host computing environment. For example, such sandboxed environments may contain a virtual machine 104 and/or applications running within it. In examples, the virtual machine 104 and/or the applications running thereon may be restricted by an isolation mechanism (e.g., a container managed by the host operating system, etc.) from accessing resources outside the sandbox in the absence of a "hole" provided in the isolation barrier or an authorization token allowing an application running in a sandboxed environment to access an external resource (eg, stored in the host computing environment and/or stored in another device accessible through network 110).

[0032] In examples, when an application of the virtual machine 104 wishes to access a resource outside of the virtual machine 104, the application may provide a token request to the authorization token manager 106 for the corresponding authorization token. According to implementations, the authorization token 106 may be configured to assign a trust level to the token request. The trust level may indicate, for example, that the virtual machine 104 and/or the application running therein are not trusted and/or are susceptible to compromise or hacking. The authorization token manager 106 may provide a token request and assign a trust level to the token issuer 110 to obtain the authorization token. The token issuer 110 may verify identification information (eg, login credentials) and generate an authorization token that includes a trust indicator embedded therein. The token issuer 110 may provide an authorization token, which includes an embedded trust indicator, to the authorization token manager 106, which may provide the authorization token to the requesting application running on the virtual machine 104.

[0033] When an application attempts to access an external resource, such as protected resources 116, using an authorization token, resource manager 114 may retrieve a trust indicator in the authorization token. Thus, if the trust indicator indicates that the authorization token was initiated in an environment that is not trusted (e.g., may be vulnerable to various types of malicious behavior such as ransomware attacks), resource manager 114 may take preventive action (e.g., creating backup) to protect protected resources 116 before granting access to the application.

[0034] It should be noted and understood that implementations are not limited to the illustrative arrangement shown in FIG. 1. In contrast, network 110 may contain any number of computing devices and/or servers (including, but not limited to, machines and/or virtual machines) connected in any manner. For example, although computing device 102 is shown separately from authorization server 108, resource server 112, and secure resources 116, in an embodiment, one or more of computing device 102, authorization server 108, resource server 112, and/or secure resources (or components thereof) may be co-located, remotely located, may be implemented on a single computing device or virtual machine, or may be implemented or distributed across one or more additional computing devices or virtual machines not explicitly illustrated in FIG. 1. An example arrangement in which the authorization token manager, token issuer 110, resource manager 114, and secure resources 116 may be implemented on a computing device is illustrated in FIG. 6 and is described in more detail below.

[0035] The authorization token manager 106 may operate in various ways to provide access to a resource in a secure manner. For example, the authorization token manager 106 may operate as shown in FIG. 2. In FIG. 2 shows a flowchart 200 of a method for granting authorization that includes a trust indicator for an application, according to an exemplary embodiment. For illustrative purposes, flowchart 200 and authorization token manager 106 are described as follows with reference to FIG. 3.

[0036] FIG. 3 shows a block diagram of a system 300 for providing access to a network resource in a secure manner according to an exemplary embodiment. As shown in FIG. 3, system 300 includes an example implementation of computing device 102, authorization server 108, and resource server 112. Computing device 102 includes a virtual machine 104 and an authorization token manager 106 . The virtual machine 104 may include an application 302 running therein. The authorization token manager 106 may include a trust level assignor 304 and a token requestor 306 . The authorization server 108 includes a token issuer 110 . The token issuer 110 includes an identity authenticator 314 and a token generator 316 . The resource server includes a resource manager 114 . The resource manager 114 includes a resource access provider 318 and a resource protector 320 . The resource manager 114 may be associated with the protected resources 116 and the resource snapshot 322 . As shown in system 300 in FIG. 3, the authorization token manager 106 may pass the token request 308 and the associated trust level 310 to the token issuer 110. The token issuer 110 may generate an authorization token 312, which includes a trust indicator that may be embedded therein. Authorization token manager 106 may provide an authorization token to application 302. Subsequently, when application 302 provides an authorization token to resource manager 114 to access protected resources 116, resource manager 114 may be configured to take proactive actions to protect protected resources 116 before granting access to such resources. . The flowchart 200 and system 300 are described in more detail below.

[0037] Flowchart 200 in FIG. 2 begins at block 202. At block 202, a token request is received from an application running on a second computing environment at least partially isolated from the first computing environment to access a resource. For example, with reference to FIG. 3, trust level assignor 304 may be configured to receive a token request 324 from application 302. Virtual machine 104 may comprise a computing environment that is partially or completely isolated from another computing environment (e.g., a host environment in which a host operating system may be running). computing device 102). For example, virtual machine 104 may include an operating system (eg, the same or a different type as the operating system running in the host environment) and/or one or more applications running therein. The virtual machine 104 runs on top of the host operating system of the computing device 102. The application 302 may contain any type of application that can run on the virtual machine 104, including, but not limited to, software packages installed on the virtual machine 104 or accessible from a remote computer or server , web applications, web services, or any other code or binary that may run on or within the virtual machine 104. In exemplary implementations, virtual machine 104 and/or application 302 may not be trusted (e.g., may be insecure, susceptible to malicious code execution, etc.) due to any number of factors, including, but not limited to, application types, executed by a user of the virtual machine 104, remote services or websites accessed by a user who could potentially use the application 302 and/or the virtual machine 104, and/or integral aspects of the virtual machine 104 or the application 302 itself (e.g., the operating system, running on virtual machine 104 may generally be considered unreliable).

[0038] Although in FIG. 3 illustrates that computing device 102 may include a virtual machine and an application running therein, implementations are not limited to this particular arrangement. For example, the isolated computing environment on computing device 102 may instead contain an application running on computing device 102 (e.g., on the same underlying operating system as the host environment), such as an application that runs in guest mode, private mode, or incognito mode, a layout that includes one or fully or partially isolated containers or isolated processes or applications, a first central processing unit (CPU) computing environment that is separate from the second CPU computing environment (on the same or a different circuit board or motherboard) , or other mode or configuration in which a full or partial isolation boundary can be implemented between the executing application and the host computing environment.

[0039] In examples, application 302 may, through user interaction or in response to software execution on virtual machine 104, attempt to connect to resources outside of virtual machine 104, such as protected resources 116. For example, application 302 may attempt to connect to a cloud file a server remote from the virtual machine 104 and/or computing device 102. To access such protected resources 116, the application 302 may need to provide the appropriate authorization token to the resource manager 114. In implementations, the token request for such an authorization token generated by application 302 may be forwarded such that the token request is provided to the host computing environment. For example, with reference to FIG. 3, an authorization token request initiated by application 302 may be forwarded to trust level assigner 304 indicating that the application is attempting to access certain resources. The trust level assigner 304 may receive such a request through one or more holes provided in an isolation barrier implemented between the virtual machine 104 and the host computing environment of the computing device 102.

[0040] The authorization request received by the trust assignor 304 from the application 302 may include, but is not limited to, identification of the resources for which access is being requested (e.g., identification of protected resources 116), identification of the requesting application, login credentials for the appropriate authorizing entity (eg, identity provider), the type of access requested (eg, read-only access, read/write access, etc.), the length of time for which the token is requested, and any other information that may be associated with an authorization token request as understood by those skilled in the art.

[0041] At step 204, the token request is assigned a trust level. For example, with reference to FIG. 3, a trust level assigner 304 may be configured to assign a trust level to a token request received by an application 302 running on a virtual machine 104. In some examples, as described previously, the virtual machine 104 and/or one or more applications running on it may be considered unreliable. In such examples, trust level assigner 304 may assign a trust level that indicates that the entity requesting the token request (eg, by identifying application 302 and/or virtual machine 104) is not trusted. In some additional implementations, the trust level assigner 304 may assign a trust level that includes a score, such as an alphanumeric value, that may indicate the confidence level of the token request based on a predetermined scale.

[0042] In examples, the trust level assigner 304 may assign the trust level in various ways. For example, the trust level assigner 304 may assign a trust level based on predetermined knowledge (e.g., stored in a database or other data structure) regarding characteristics of the isolated computing environment, such as the identifier of the virtual machine 104, the operating system running on the virtual machine 104, and /or any other 302 applications that may be running on it. In one illustrative example, the trust level assigner 304 may automatically consider certain types of token requests (or all token requests) originating from the sandbox to be untrusted, and accordingly assign a reduced trust level to each such token request. In other examples, the trust level assignor 304 may assign reduced trust levels to token requests associated with certain applications, operating systems, or virtual machines that may be hosted as part of a sandbox on the computing device 102. In other examples, the trust level assignor 304 may assign levels of confidence in token requests received from application 302 based on on-the-fly determination. The level of trust can be specified in any form, including a numeric value (for example, ranging from 0 to 10, where "0" means no trust and "10" means maximum trust), a text value (for example, "high", "medium", "low", "none", etc.), alphanumeric value, string, etc.

[0043] At step 206, an authorization token is obtained that includes a trust indicator corresponding to the trust level of the token request. For example, with reference to FIG. 3, token requestor 306 may obtain an authorization token 312 that includes a trust indicator from the token issuer 110. The token requester 306 may obtain the authorization token 312 in various ways. In the exemplary arrangement shown in FIG. 3, for example, token requester 306 may be configured to obtain 328 trust level 310 from trust level assignor 304. The token requester 306 may communicate 332 a trust level 310 and also communicate 330 the token request 308 to the token issuer 110 identity authenticator 314 in accordance with one or more APIs or network calls. The token request 308 may include information associated with the requested access, as described previously, such as login credentials, the identity of the resource to be accessed, the amount of access requested, etc. The token request 308 may correspond to the token request received by the trust level assignor 304 from the application 302 (eg, to access a resource) and the corresponding trust level. For example, if the trust level assigns a trust level indicating that the virtual machine 104 and/or application 302 are not trusted, the token requester 306 may pass the token request 308 and the assigned trust level 310 to the appropriate token issuing service to obtain a token that provides access to the requested resource.

[0044] In implementations, the token request 308 may be transmitted separately from the trust layer 310 (eg, in different data packets, sequentially, out of order, etc.). In some other examples, the token request 308 and the trust level 310 may be sent together (eg, as part of the same data packet or set of data packets). For example, a trust level 310 may be added, included, or otherwise communicated with a token request 308 as a tag, identifier, marking, flag, claim, metadata, new or changed scope associated with the request, etc. Implementations are not limited to these illustrative examples and may include any other method of conveying a trust level 310 with a token request 308 that may indicate information about the trustworthiness of the token request (e.g., the trust level of the virtual machine 104 and/or application 302) to the token issuer (e.g., publisher 110 markers).

[0045] In examples, the token generator 316 may generate an authorization token 312 that includes a trust indicator indicating the trust level of the environment in which the token can be used. The trust indicator may contain any suitable format (eg, numeric, text, string, etc.) and may be included, appended, combined, or otherwise associated with the authorization token 312. For example, the trust indicator may similarly comprise a tag, identifier, marking, flag, claim, metadata, new or revised scope, etc. that are part of or integral to the authorization token 312. In the example where the authorization token 312 is a file, the trust indicator may be written to an existing field or as a new entry to the file. When the trust indicator is turned on, the authorization token 312 is considered "tagged". Accordingly, in implementations, the authorization token 312 may include a marked token that indicates that the requesting entity may be insecure. In examples, token generator 316 may transmit 334 an authorization token 312, which includes a trust indicator, to token requestor 306 (eg, over a network).

[0046] At step 208, an authorization token, which includes a trust indicator, is provided to an application running on the second computing environment. For example, with reference to FIG. 3, token requestor 306 may be configured to provide 326 an authorization token 312 that includes a trust indicator to application 302 running on virtual machine 104. In implementations, token requestor 306 may provide authorization token 312 to application 302 without changing the authorization token. Application 302 may then use authorization token 312 to access a resource, such as protected resources 116 (or a resource that may be stored locally to computing device 102). In the examples, because the trust indicator is included as part of the authorization token 312, the application 302 (or any malicious code that may be running on the virtual machine 104) cannot modify the received authorization token. In other words, if the authorization token has been modified by any activity occurring in the potentially compromised environment (e.g., virtual machine 104), the modified authorization token will not allow access to the resource provider's resources because the modified authorization token cannot be verified between the resource provider and an authorization service (eg, token issuer 110 and resource manager 114, as shown in the example of FIG. 3). As a result, the trust indicator can be embedded in the authorization token in a manner that cannot be changed, thereby increasing the integrity of the authorization token.

[0047] As will be described in more detail below, when application 302 attempts to access a resource by passing 336 a received authorization token to the appropriate resource provider, the resource provider may be configured to retrieve (e.g., read or copy) a trust indicator from the authorization token and determine, whether a precautionary action should be taken before granting access to the resource. For example, if resource protector 320 retrieves a trust indicator that indicates that application 302 and/or virtual machine 104 may be insecure, resource protector 320 may be configured to protect protected resources 116 by creating a backup of the requested resources (e.g., by creating snapshot 322 of resources before granting access 338 to such resources. An exemplary flowchart depicting the implementation of preventive actions to protect a resource will be described below in more detail with reference to Fig. 6.

[0048] As described above, token issuer 110 may be configured to generate an authorization token that includes a trust indicator in various ways. For example, in FIG. 4 shows a flowchart 400 of a method for generating an authorization token that includes a trust indicator, according to an exemplary embodiment. In an implementation, the flowchart method 400 may be implemented using an identity authenticator 314 and a token generator 316 . Fig. 4 is described with reference to FIG. 3. Other structural and functional implementations will be apparent to those skilled in the art based on the following discussion of flowchart 400 and system 300 in FIG. 3.

[0049] Flowchart 400 begins at block 402. At block 402, a token request is received that includes identification information and an indication that the token request was initiated in an application of a second computing environment at least partially isolated from the first. computing environment. For example, with reference to FIG. 3, the identity authenticator 314 of the authorization server 108 may be configured to receive a token request 308 that includes identification information and a trust level 310 that indicates the associated trust level. In examples, the identity information may include one or more user credentials (e.g., username and/or password), user alias, account number, biometric information, or any other information or credentials that the identity authenticator 314 can verify to determine whether to allow access to a resource (for example, protected resources 116). As described previously, the trust level 310 may include information corresponding to the trust level of the environment in which the token request 308 was initiated. For example, with reference to FIG. 3, trust level 310 may indicate the level of trust associated with application 302 that is running in virtual machine 104. In other examples, trust level 310 may include a flag or other indicator that indicates that the request was initiated in an environment other than the host computing environment. , or was executed in it. These examples are illustrative only, and the trust level 310 may include any type of information (eg, flag, marking, assertion, metadata, etc.) that indicates that the token request 308 may have been initiated from a potentially untrusted environment.

[0050] At step 404, the validity of the identification information is verified. For example, with reference to FIG. 3, the identity authenticator 314 may be configured to validate the identity information received in the token request 308 to determine whether to allow the requesting entity to obtain an authorization token allowing access to the requested resource. The identification authenticator 314 may verify the validity of the identification information in various ways, as will be appreciated by those skilled in the art, such as by searching the identification information in a database (e.g., a user or account database, etc.) and making a comparison. providing identification information to another server or service for verification, etc. For example, if the verification is unsuccessful (eg, incorrect user credentials are received), the identity authenticator 314 may determine that access should not be allowed, and therefore the authorization token will not be provided to the application 302. If the authentication is successful, the authenticator Identity authentication 314 may allow token generator 316 to generate an appropriate authorization token that can be provided to application 302 to access the requested resource.

[0051] At step 406, an authorization token is generated that includes a trust indicator. For example, with reference to FIG. 3, token generator 316 may be configured to generate an authorization token 312 that includes a trust indicator indicating the trust level of the computing environment in which the token request 308 was initiated. In examples, the trust indicator may indicate the level of trust associated with the virtual machine 104 and/or application 302 running therein, for example, indicating that the computing environment is not trusted. As described previously, a trust indicator may be embedded in the authorization token 312 and may comprise any suitable form, including a tag, marking, flag, claim, etc., that may indicate to the resource provider (e.g., resource server 112) that the token authorization may be used by an application in an untrusted computing environment.

[0052] In some example implementations, the trust indicator may be different for each accepted token request. For example, certain types of sandboxed environments (for example, certain applications and/or operating systems running on them that are known to be insecure) may be considered less trusted than other applications or operating systems, and therefore the trust indicator for such less secure applications or operating systems systems may indicate an additional decrease in the level of trust. In other examples, the trust indicator may contain a different type of indicator, such as when an application may only be considered potentially trustworthy (as opposed to being known to be insecure). Thus, the token generator 316 can mark the authorization token 312 with an appropriate trust indicator that indicates the trust level of the application in an untrusted environment, thereby allowing the resource provider to perform various preventive measures based on the built-in trust indicator.

[0053] Authorization token 312 may include any type of token that allows a computing entity (eg, applications, services, etc.) to access a resource. Examples of authorization token 312 include, but are not limited to, web tokens that provide access to the Internet or other network resources, access tokens, tokens generated in accordance with the Open Authorization (OAuth) standard, Microsoft® Windows NT tokens, etc. . Authorization token 312 may be generated for a specific requesting application or resource, or may comprise a single token associated with multiple such applications.

[0054] In some example embodiments, the token generator 316 may also be configured to store each generated authorization token 312 in a suitable storage device (either locally or in one or more cloud storage locations). Accordingly, when application 302 attempts to access a resource by providing an authorization token 312 to resource manager 114, resource protector 320 may obtain the authorization token stored on authorization server 108 to determine the authenticity of the token received from application 302 before granting access to the requested resource. . In other cases, token generator 316 may also be configured to retransmit a previously generated and not yet expired token (including a trust indicator) to token requestor 306, such as when token generator 316 has previously generated an authorization token corresponding to application 302 for accessing the same resource.

[0055] At step 408, an authorization token that includes a trust indicator is provided to an application running on the second computing environment. For example, with reference to FIG. 3, token generator 316 may be configured to pass authorization token 312 to token requester 306 for provision to application 302 (e.g., by passing authorization token 312 across an isolation boundary) and/or by providing authorization token 312 directly to application 302 (e.g., without passing token to the token requester 306 as an intermediary). As described above, application 302 may use authorization token 312 to access the requested resource.

[0056] As described herein, resource manager 114 may be configured to protect protected resources 116 in response to receiving an authorization token. For example, in FIG. 5 is a flowchart of a method for performing a preventive action to protect a resource according to an exemplary embodiment. In an implementation, the method of flowchart 500 may be implemented by a resource access provider 318 and a resource protector 320. Fig. 5 is described with reference to FIG. 3. Other structural and functional implementations will be apparent to those skilled in the art based on the following discussion of flowchart 500 and system 300 in FIG. 3.

[0057] Flowchart 500 begins at block 502. At block 502, an authorization token is received from an application running in the computing environment. For example, with reference to FIG. 3, resource protector 320 may be configured to receive an authorization token 312 from an application 302 running on a virtual machine 104 via a network 110. As described herein, the authorization token 312 may also include a trust indicator that indicates the trust level of the environment. associated with the authorization token 312. Therefore, in this example, the trust indicator may indicate the level of trust of the computing environment in the virtual machine 104 and/or the application 302 may be running.

[0058] However, it should be noted that in some other exemplary embodiments, the authorization token 312 may not include a trust indicator, such as where the token request originated in a trusted environment (eg, from an application running on the computing device's host operating system). For example, if a trusted application (or an application running in a trusted environment) requests an authorization token, the generated authorization may not contain a trust indicator for that application. Thus, in some examples, resource protector 320 may also be configured to determine whether a trust indicator is present in a received authorization token.

[0059] After application 302 receives an authorization token 312 as described previously, application 302 may attempt to access resources consistent with the scope of the provided authorization token by interacting with an appropriate resource provider, such as resource server 112 . In examples, application 302 may also provide an authorization token 312 to resource protector 320 along with an attempt to access the resource. The resource protector 320 may verify the authenticity of the authorization token 312 in a similar manner as described previously, for example, by interacting with the authorization server 108 to determine whether the authentication token received from the application 302 is valid and/or has not expired.

[0060] At step 504, the trust indicator is retrieved from the authorization token. For example, resource protector 320 may be configured to parse authorization token 312 to extract a trust indicator from it. For example, if a trust indicator is embedded in the authorization token 312 as an identifier, token, flag, claim, metadata, etc., the resource protector 320 may extract such an indicator. In some implementations, resource protector 320 may also receive a trust indicator from authorization server 108 (eg, when a received token is verified to be authentic).

[0061] At step 506, it is determined that a preventative action needs to be taken to protect the resource. For example, with reference to FIG. 3, resource protector 320 may be configured to determine, in response to receiving the authorization token and retrieving the trust indicator, that a preventative action should be taken to protect the resource. For example, if the trust indicator indicates that the environment from which the authorization token 312 was received is not trustworthy, the resource protection engine 320 may determine that one or more preventive actions must be performed to protect the protected resources 116. The preventive actions may include actions of any type performed to prevent (e.g., proactively) or mitigate potentially malicious changes to protected resources 116.

[0062] For example, if the retrieved trust indicator indicates that the computing environment from which the authorization token 312 was obtained is not trustworthy, the resource protector 320 may be configured to take certain actions to prevent corruption, compromise, and/or compromise of user data. In some examples, resource protector 320 may determine that multiple preventive actions need to be taken. In some other cases, resource protector 320 may determine that preventative action is not required, such as when an authentication token was received from a computing environment known to be trusted by resource server 112. In some other cases, resource protector 320 may also decide not to take preventive actions, such as when resource protector 320 believes that application 302 is not malicious based on previous access granted to application 302 in response to receiving the same authorization token.

[0063] At step 508, a proactive action is performed to protect the resource in response to receiving the authorization token. For example, with reference to FIG. 3, resource protector 320 may be configured to perform one or more proactive actions to protect protected resources 116 in response to receiving an authorization token 312 from application 302. In examples, the type (or types) of proactive actions performed to protect protected resources 116 may be based on a combination of factors, including the type of resource being accessed, the amount of access (e.g., read-only access, modification of the resource, etc.), and/or the level of trust, which may be indicated by a trust indicator in the token 312 authorization. For example, if the resource being accessed has been identified as confidential and/or sensitive, resource protector 320 may be configured to implement one or more security measures to protect the resource. In another example, if the retrieved trust indicator indicates that the computing environment (e.g., application 302) from which the authorization token 312 was obtained is known to be untrusted, the resource protector 320 may perform one or more enhanced security measures to protect the protected resources 116.

[0064] In one example, resource protector 320 may be configured to automatically create a resource snapshot 322 in response to receiving an authorization token 312 that indicates that application 302 cannot be trusted. Resource snapshot 322 may contain, for example, a backup copy of protected resources 116 that are not accessible to application 302, even with authorization token 312. In some implementations, the resource protector 320 may generate a snapshot 322 of the protected resources 116 in various ways, including by creating a snapshot consistent with the entire scope of the authorization token 312 (for example, copying all of the user's files if the authorization token 312 is extensive), and/or copying resources on a file-by-file basis (eg, copying only the individual files that application 302 is attempting to access).

[0065] Although in some examples the resource snapshot 322 may be stored locally with respect to the protected resources 116, it is contemplated that the resource snapshot 322 may also be stored remotely (e.g., on another server) in a manner that is not accessible to the application 302 and/or any another potentially unreliable application. In some implementations, resource protector 320 may be configured to encrypt (or further encrypt) resource snapshot 322 to further enhance security by preventing unauthorized access in the event of a potential compromise.

[0066] Creating a backup copy of protected resources 116 is just one illustrative example of a precaution that resource protector 320 can take to protect a resource. The resource protector 320 may also perform one or more other measures in addition to or as an alternative to creating a resource snapshot 322, including, but not limited to, authorizing an access scope that is more restricted than the scope specified in the authorization token 312 ( for example, read-only access to accessed files on a storage device, preventing withdrawal of funds from a financial institution, etc.), allowing access only for a certain period of time (for example, days, hours, minutes, seconds and etc.), after which access may be terminated with complete denial of access (for example, when protected resources may be deemed too sensitive or sensitive, such as banking or financial information, to allow any potentially untrusted access), and/or one or more additional or alternative procedure resolutions.

[0067] In some other cases, resource protector 320 may perform enhanced identity authentication in response to receiving an authorization token that includes a trust indicator. For example, the resource protector 320 may require, before granting access to the protected resources 116, that the user of the computing device 102 perform an additional authentication procedure, or repeat the same authentication procedure from a trusted environment (e.g., from an application running on a trusted host operating system), perform a multi-factor procedure (eg, verified a randomly generated code that is sent to a mobile device, email account, etc.) to confirm that the authorization token 312 was initiated by a legitimate application before granting access to the resource.

[0068] In some additional implementations, resource protector 320 may also be configured to detect anomalous activity using the authentication tokens described herein. For example, if resource protector 320 receives an abnormal number of access requests associated with a particular authorization token 312 (e.g., a number of access requests above a threshold or in a certain period of time) from application 302, resource protector 320 may conclude that application 302 is involved in potentially malicious activity or may otherwise be compromised. In such a case, resource protector 320 may decide to stop servicing access requests from application 302 as an additional precaution.

[0069] In some other cases, resource protector 320 may also perform preventative action on one or more resources not associated with authorization token 312. For example, if resource protector 320 receives a request from a potentially untrusted computing environment, resource protector 320 may be configured to automatically protect (e.g., by encrypting, locking, moving to a more secure location, etc.) unrelated files that may contain increased sensitivity or importance to further improve safety. Thus, even if certain malicious code may compromise protected resources 116, the movement of malicious code may still be limited because resource protector 320 may prevent code from accessing not only the resource snapshot 322, but also other data that may be present on or accessible to the same server.

[0070] At step 510, access to the resource is granted by an application running in the computing environment. For example, with reference to FIG. 3, resource access provider 318 may be configured to provide access to protected resources 116 by application 302 running in a computing environment (ie, a potentially untrusted environment). In some examples, the type of access provided by resource access provider 318 may be based on proactive actions performed to protect protected resources 116. For example, if resource protector 320 has created a snapshot of resources 322 that is not accessible to application 302, access provider 318 resources may be allowed full read/write access to protected resources 116.

[0071] In other examples, if a backup is not taken, resource access provider 318 may grant application 302 more limited access, such as read-only access, to prevent potentially malicious activities from affecting protected resources 116. For example, resource access provider 318 resources may be configured to grant access to application 302, based on a trust indicator included in the token, to open existing content in the user's file space and/or generate new content for storage in the user's file space, while preventing application 302 from modifying or deleting existing content. In some other implementations, the resource access provider 318 may also be configured to implement markings or tags for any new content generated by the application 302, so that the application can not only generate new content (each content item is identified by the marking or tag), but modify or delete newly created content based on tagged content items. In an additional implementation, such marking or tag may be automatically cleared, for example, after a predetermined period of time has passed or when a full access authorization token (eg, a token granted to an application running in a trusted environment) gains access to the marked content.

[0072] Resource access provider 318 may also be configured to allow application 302 access to resource snapshot 322 (instead of protected resources 116, which may be protected from application 302). In either case, resource protector 320 may be configured to automatically delete the backup upon determining that access by application 302 was not malicious and/or after a specified time has elapsed. In other cases, such as when resource protector 320 may be notified that application 302 has maliciously modified protected resources 116 (e.g., due to ransomware or the like), resource protector 320 may be configured to recover protected resources 116 from a snapshot of 322 resources. As a result, even if an untrusted application attempts to inject ransomware to encrypt or otherwise modify a user's files, the backed-up files can be easily restored, thereby minimizing the harm of such malicious behavior.

[0073] It should be noted and understood that the circuit described in FIG. 3 is illustrative only, and implementations may include various other types of schemes, including schemes in which one or more of the authorization token manager 106, token issuer 110, resource manager 114, protected resources 116, and resource snapshot 322 may be implemented locally to computing device 102. For example, FIG. 6 shows a block diagram of a system 600 for providing access to a local resource in a secure manner according to an exemplary embodiment. System 600 includes a computing device 602. Like computing device 102, computing device 602 may include multiple computing environments. For example, computing device 602 may include a computing environment that can run a host operating system, including desktop and/or mobile operating systems (eg, Microsoft® Windows, Apple® macOS, Apple® iOS, Google® Android). Computing device 602 may also include one or more other computing environments as described herein, such as an isolated environment that may include virtual machine 104 and applications running therein (eg, application 302).

[0074] In the exemplary arrangement of FIG. 6, the first computing environment (eg, a computing environment that may host an isolated environment) may include one or more of an authorization token manager 106, a token issuer 110, a resource manager 114, a protected resource 116, and a resource snapshot 322. For example, rather than one or more such components being implemented on one or more network entities, such components may be implemented locally to computing device 602. For example, token request module 306 may provide a token request (e.g., an NT token request or the like). an identity authenticator 314 that is configured to manage authorization tokens for local activities on the computing device 602. In some example implementations, the identity authenticator 314 and/or token generator 316 may be implemented as part of the host operating system of the computing device 602. file system manager and/or like any other application running on it, so that access to locally stored data (or remotely stored data that can be accessed through local interaction, such as a shortcut, etc.) can be controlled from using local authorization tokens. In other words, token generator 316 may be configured to generate and provide authorization tokens that allow applications running on computing device 602 (including any applications that may be hosted in sandboxed environments) to access local resources, such as protected resources 116.

[0075] Accordingly, when application 302 requests a token and token requester 306 provides a token request 308 and assigns a trust level 310 to the token issuer 110, the token generator 316 may generate an authorization token that includes a trust indicator indicating the trust level 310, similar in the manner as described previously. The authorization token may include, for example, information associated with authorized access, such as user information (e.g., user identification as administrator, guest, etc.), permission level (e.g., read-only, read/write access etc.), identification of requested resources, etc. The token requester 306 may provide an authorization token, which includes a trust indicator (e.g., a tagged authorization token), to the application 302, allowing the application to access local resources that may be accessible outside of the virtual machine 104.

[0076] Accordingly, when application 302 attempts to access or modify a resource outside of an isolated computing environment, such as protected resources 116, resource access provider 318 may extract a trust indicator from the authorization token provided by application 302 and determine that application 302 cannot to be trusted. In response to receiving such a flagged authorization request indicating that the application 302 cannot be trusted, the resource protector 320 may perform one or more proactive actions in the computing environment containing the host operating system to protect the protected resources 116, such as creating a resource snapshot 322. which contains a backup copy of the protected resources 116, prior to providing access to the protected resources 116. As described previously, the resource protector 320 may also contain any other types of preventive actions in addition to or as an alternative to creating a snapshot of the resources 322, including, but not limited to , allowing limited access (eg, read-only access) to protected resources 116, preventing encryption (or additional encryption) of protected resources 116, requiring enhanced authorization, or any other precautions that will be understood by those skilled in the art.

[0077] It should be noted and understood that sandboxed environments do not necessarily have to include virtual machine 104 as described with reference to FIG. 3 and 6. For example, application 302 may also include any type of application (eg, a web browser) running in a host computing environment, which may include a partial or complete isolation boundary. Thus, even if the sandbox contains another application that can access resources stored either locally or remotely, implementations can still provide more secure access to such resources (for example, by creating a backup, restricting access, etc. .) by marking the authorization tokens that are used for such access with the access environment trust information as described in this document.

III. Examples of Mobile and Desktop Device Embodiments

[0078] Computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, protected resources 116, trust level assigner 304, token requester 306, checker 314 identity authentication, token generator 316, resource access provider 318, resource protector 320, resource snapshot 322, flowchart 200, flowchart 400, and/or flowchart 500 may be implemented in hardware software or in hardware in combination with software and/or firmware, for example, in the form of computer program code/instructions stored on a physical/hardware computer-readable storage medium and configured for execution on one or more processors, or may be implemented as hardware logic/electrical circuitry (e.g., electrical circuitry consisting of transistors, logic gates, operational amplifiers, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs)). For example, one or more of computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, secure resources 116, trust level assigner 304, token requester 306, Identity authenticator 314, token generator 316, resource access provider 318, resource protector 320, resource snapshot 322, flowchart 200, flowchart 400, and/or flowchart 500 may be implemented separately or together in an SoC. The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), a microcontroller, a microprocessor, a digital signal processor (DSP), etc.), a memory, and one or more interfaces communications and/or additional circuitry and may optionally execute received program code and/or incorporate firmware to perform functions.

[0079] FIG. 7 depicts an exemplary implementation of a computing device 700 in which exemplary embodiments may be implemented. For example, any of computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, secure resources 116, trust level assigner 304, token requester 306, token requester 314 identity authentication, token generator 316, resource access provider 318, security 320, and/or resource snapshot 322 may be implemented in one or more computing devices, similar to computing device 700 in desktop or mobile computer embodiments, including one or more features of the computing device 700 and/or alternative features. The description of computing device 700 provided herein is provided for purposes of illustration and is not intended to be limiting. Example embodiments may be implemented in other types of computer systems as is known to those skilled in the art.

[0080] As shown in FIG. 7, computing device 700 includes one or more processors, referred to as processor circuitry 702, system memory 704, and a bus 706 that communicates various system components, including system memory 704 and processor circuitry 702. Processor circuitry 702 is electrical and/or optical circuitry implemented in one or more physical hardware elements of an electrical circuit device and/or integrated circuit devices (chipsets of semiconductor material or chips) such as a central processing unit (CPU), microcontroller, microprocessor, and/or other physical hardware processing circuitry. Processor circuit 702 may execute program code stored on a computer-readable medium, such as operating system program code 730, application programs 732, other programs 734, etc. Bus 706 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. System memory 704 includes read only memory (ROM) 708 and random access memory (RAM) 710. Basic input/output system (BIOS) 712 is stored in ROM 708.

[0081] Computer device 700 also has one or more of the following drives: a hard drive 714 for reading from or writing to a hard disk, a magnetic disk drive 716 for reading or writing to a removable magnetic disk 718, and an optical disk drive 720 for reading or writing recording onto a removable optical disk 722, such as a CD-ROM, DVD-ROM, or other optical media. Hard disk drive 714, magnetic disk drive 716, and optical disk drive 720 are connected to bus 706 via hard disk drive interface 724, magnetic disk drive interface 726, and optical disk drive interface 728, respectively. Drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for a computer. Although a hard disk, a removable magnetic disk, and a removable optical disk are described, other types of hardware computer-readable storage media may be used to store data, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media.

[0082] A plurality of program modules may be stored on a hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 730, one or more application programs 732, other programs 734, and program data 736. Application programs 732 or other programs 734 may include, for example, computer program logic (e.g., computer program code or instructions) to implement computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, protected resources 116, trust level assigner 304, token requester 306, authenticator 314 identification, token generator 316, resource access provider 318, resource protector 320, resource snapshot 322, flowchart 200, flowchart 400, and/or flowchart 500 (including any suitable flowchart steps 200, 400, or 500) and/or other exemplary embodiments described herein.

[0083] The user may enter commands and information into the computing device 700 through input devices such as a keyboard 738 and pointing device 740. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, touch a screen and/or touchpad, a voice recognition system to accept voice input, a gesture recognition system to accept gesture input, or the like. These and other input devices are often connected to the processor circuit 702 via a serial port interface 742, which is coupled to bus 706, but may be connected via other interfaces, such as a parallel port, a game port, or a universal serial bus (USB).

[0084] Display screen 744 is also coupled to bus 706 through an interface, such as video adapter 746. Display screen 744 may be external to or embedded in computing device 700. Display screen 744 may display information as well as be a user interface for receiving user commands. and/or other information (for example, through touch, finger gestures, virtual keyboard, etc.). In addition to the display screen 744, the computing device 700 may include other peripheral output devices (not shown), such as speakers and printers.

[0085] The computing device 700 connects to a network 748 (eg, the Internet) through an adapter or network interface 750, a modem 752, or other network communication means. Modem 752, which may be internal or external, may be coupled to bus 706 via serial port interface 742, as shown in FIG. 7, or may be coupled to bus 706 using another type of interface, including a parallel interface.

[0086] When used herein, the terms “computer program medium,” “computer readable medium,” and “computer readable storage medium” are used to refer to physical hardware media, such as a hard disk drive associated with hard drive 714. disk, removable magnetic disk 718, removable optical disk 722, other physical hardware media such as RAM, ROM, flash memory cards, digital video disks, zip disks, MEM, nanotechnology-based storage devices, and additional types of physical/tangible hardware media storage Such computer-readable storage media are distinct from and do not interfere with the communication media (do not include the communication media). The communication medium carries computer-readable instructions, data structures, program modules, or other data in a modulated information signal, such as a carrier wave. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a way as to encode information in the signal. By way of example, and not limitation, communication media include wireless media such as acoustic, RF, infrared and other wireless media, as well as wired media. Example embodiments are also directed to such media that are separate and do not overlap with embodiments directed to computer-readable storage media.

[0087] As noted above, computer programs and modules (including application programs 732 and other programs 734) may be stored on a hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Such computer programs may also be received through network interface 750, serial port interface 742, or any other type of interface. Such computer programs, when executed or loaded by an application, allow computing device 700 to implement features of the exemplary embodiments described herein. Accordingly, such computer programs are controllers of the computing device 700.

[0088] Exemplary embodiments are also directed to computer program products comprising computer code or instructions stored on any computer-readable medium. Such computer software products include hard disk drives, optical disk drives, storage modules, portable flash cards, memory sticks, and other types of physical storage hardware.

IV. Exemplary Embodiments

[0089] This document describes a system on a computing device for providing an authorization token with a trust indicator. The system includes: one or more processors; and one or more storage devices storing program code configured for execution by one or more processors, the program code comprising: an identification authenticator configured to: receive a token request from an authorization token manager of a first computing environment, which includes: an identification information and an indicator that the token request was initiated in an application running in a second computing environment at least partially isolated from the first computing environment; and verification of identification information; and a token generator configured to: generate an authorization token that includes a trust indicator indicating a trust level of the second computing environment; and transmitting an authorization token that includes a trust indicator to the first computing environment.

[0090] In one implementation of the above system, the trust indicator includes an indicator that an application running on the second computing environment is not trusted.

[0091] In another implementation of the above system, the second computing environment includes a virtual machine hosted on the first computing environment.

[0092] In another implementation of the above system, the authorization token is configured to allow an application running on a second computing environment to access a protected resource on a first computing environment.

[0093] In another implementation of the above system, the authorization token is configured to allow an application running on a second computing environment to access a protected resource over a network.

[0094] In another implementation of the above system, access to a protected resource by an application running on a second computing environment includes read-only access to the protected resource.

[0095] This document discloses a method for providing access to a resource in a secure manner. The method includes: receiving a token request from an application running on a second computing environment at least partially isolated from the first computing environment to access a resource; assigning a trust level to the token request; obtaining an authorization token that includes a trust indicator, wherein the trust indicator corresponds to the trust level of the token request; and providing an authorization token, which includes a trust indicator, to an application running on the second computing environment.

[0096] In one implementation of the above method, obtaining an authorization token includes: transmitting a token request and an assigned trust level to the issuer of the token; and obtaining an authorization token that includes a trust indicator corresponding to the trust level from the issuer of the token.

[0097] In another implementation of the above method, the trust indicator includes an indicator that an application running on the second computing environment is not trusted.

[0098] In another implementation of the above method, the resource is stored in a first computing environment; and the method further includes: obtaining an authorization token from an application running on the second computing environment; and performing a preventive action in the first computing environment to protect the resource in response to receiving the authorization token.

[0099] In another implementation of the above method, the preventive action includes creating a backup copy of the resource in response to receiving an authorization token.

[0100] In another implementation of the above method, the method further comprises: providing read-only access to the resource by the first computing environment in response to receiving the authorization token.

[0101] In another implementation of the above method, the resource is stored on a server that is configured to perform proactive actions in response to: receiving an authorization token; extracting the trust indicator from the authorization token; and determining that preventive actions should be performed based on the extracted trust indicator.

[0102] In another implementation of the above method, the second computing environment includes a virtual machine hosted on the first computing environment.

[0103] A system for providing access to a resource is described here. The system includes: one or more processors; and one or more storage devices storing program code configured for execution by one or more processors, the program code comprising: resource protection means configured to: receive from an application running in the computing environment an authorization token for access to the resource, an authorization token includes a trust indicator indicating the trust level of the application; performing a proactive action to protect the resource in response to receiving an authorization token, including a trust indicator; and a resource access provider configured to provide access to the resource by an application running in the computing environment.

[0104] In one implementation of the above system, the trust indicator includes an indicator that an application running in the computing environment is not trusted.

[0105] In another implementation of the above system, the computing environment includes a virtual machine hosted in another computing environment.

[0106] In another implementation of the above system, the preventive action performed by the resource protector includes: creating a backup copy of the resource in response to receiving an authorization token.

[0107] In another implementation of the above system, a resource access provider is configured to provide limited access to a resource by an application running in a computing environment in response to receiving an authorization token.

[0108] In another implementation of the above system, the resource protector is configured to perform enhanced identity authentication in response to receiving an authorization token; and the resource access provider is configured to provide access to the resource in response to performing enhanced identity authentication.

V. Conclusion

[0109] Although various embodiments of the invention have been described above, it should be understood that they are presented by way of example only and not limitation. Those skilled in the relevant art(s) will appreciate that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Accordingly, the breadth and scope of the present invention should not be limited by any of the exemplary embodiments described above, but should be defined only in accordance with the following claims and their equivalents.

Claims (34)

1. A system in a computing device for providing an authorization token with a trust indicator, comprising: one or more processors; And one or more storage devices storing program code adapted for execution by one or more processors, the program code comprising: Identity authenticator configured: receiving from the authorization token manager of the first computing environment a token request that includes identification information and an indication that the token request was initiated in an application executing on a second computing environment that is at least partially isolated from the first computing environment, and confirm the authenticity of identification information; And token generator configured: generate an authorization token that includes a trust indicator indicating the level of trust of the second computing environment, and transmit the authorization token, which includes the trust indicator, to the first computing environment. 2. The system according to claim 1, wherein the trust indicator contains an indication that the application running in the second computing environment is not trusted. 3. The system according to claim 1, wherein the second computing environment comprises a virtual machine hosted in the first computing environment. 4. The system of claim 1, wherein the authorization token is configured to allow an application running in the second computing environment to access a protected resource in the first computing environment. 5. The system of claim 1, wherein the authorization token is configured to allow an application running in the second computing environment to access the protected resource over the network. 6. The system of claim 4, wherein access to the protected resource by an application executing in the second computing environment includes read-only access to the protected resource. 7. A method of providing access to a resource in a secure manner, containing the steps of: receiving from an application running in a second computing environment, at least partially isolated from the first computing environment, a request for a token to access a resource; assigning a trust level to the token request; obtaining an authorization token that includes a trust indicator, wherein the trust indicator corresponds to the trust level of the token request; And providing an authorization token, which includes a trust indicator, to an application executing on the second computing environment. 8. The method of claim 7, wherein said obtaining an authorization token comprises the steps of: transmitting the token request and the assigned trust level to the token issuer; And receiving an authorization token that includes a trust indicator corresponding to the trust level from the issuer of the token. 9. The method of claim 7, wherein the trust indicator comprises an indication that the application running on the second computing environment is not trusted. 10. The method of claim 7, wherein the resource is stored in the first computing environment; the method further comprises the steps of: receiving an authorization token from an application running on the second computing environment; And performing preventive actions in the first computing environment to protect the resource in response to receiving the authorization token. 11. The method of claim 10, wherein the preventative action includes creating a backup copy of the resource in response to receiving the authorization token. 12. The method of claim 10, further comprising providing, by the first computing environment, read-only access to the resource in response to receiving the authorization token. 13. The method of claim 7, wherein the resource is stored on a server that is configured to perform preventative actions in response to: receiving an authorization token; extracting the trust indicator from the authorization token; And determining the preventive action to be performed based on the extracted trust indicator. 14. The method of claim 7, wherein the second computing environment comprises a virtual machine hosted on the first computing environment. 15. A computer-readable storage medium on which are stored program instructions containing the logic of a computer program for causing the processor to execute the method according to any one of claims 7 to 14.

Images