Multi-factor authentication for applications and virtual instance identities

Disclosed embodiments relate to systems and methods for implementing secure and multi-factor authentication for computing resources. Techniques include accessing at least one portion of identity data for a computing resource; providing the at least one portion of the identity data to the computing resource; identifying network address information unique to the computing resource; identifying a request, from the computing resource, to perform an action requiring an access token; provisioning the network address information unique to the computing resource, for use in transmitting the access token to the computing resource; and verifying both the at least one portion of the identity data and the network address information unique to the computing resource.

BACKGROUND

In recent years, multi-factor authentication for human users of computers has increased in popularity. Part of the impetus for multi-factor authentication is that single-factor authentication (e.g., based on a password, by itself) is vulnerable to attacks. For example, through use of malware (e.g., keylogging software), data breaches, and brute force attacks, this type of authentication is relatively easy to defeat by committed attackers. In an effort to achieve stronger security, multi-factor authentication involves two or more forms of authentication credentials of different types. For example, one form of authentication may be based on something the user knows (e.g., a password) while another form of authentication may be based on something the user has (e.g., a valid numerical code sent to the user's smartphone). In combination, these two forms of authentication may be used to restrict access to sensitive resources. The result is a level of authentication confidence higher than single-factor authentication can deliver.

Multi-factor authentication, however, has been uniquely designed for authentication of human users. No comparable or similarly effective techniques have been developed for authenticating software-based services themselves. Indeed, human-focused authentication techniques do not translate to the world of application-based and machine-based identities. Currently, when such services (e.g., network-based applications, virtual machines, container instances, etc.) engage in secure communications, they utilize an embedded privileged identity token or credential that was initially given to them at instantiation. This is a form of single-factor authentication, and one that is particularly vulnerable to attacks. If attackers are able to steal the embedded privileged identity token or credential, they can impersonate the software-based service and potentially cause widespread network compromise. Further, in addition to malicious attacks, existing forms of software-based service authentication are vulnerable to oversights and accidents. For example, if the code for a software-based service is leaked, or made available publicly (e.g., via GitHub™, Google Developers™, etc.), the embedded privileges or credentials may become known to unauthorized users.

In view of these and other deficiencies in existing techniques, technological solutions are needed for deploying secure and efficient forms of multi-factor authentication for software-based services (e.g., applications, application-based machines, etc.). According to such techniques, even if embedded privileges or credentials from an application or virtual instance or stolen or leaked, they will be powerless to perform a successful authentication. Instead, the application or virtual instance should be required to successfully undergo multi-factor authentication in a manner suitable for a software-based service environment. As described below, the techniques for multi-factor authentication should advantageously be designed for a software-based service environment, should be efficient (e.g., with minimal or no service interruption or downtime), should be flexible (e.g., capable of changing as network parameters and compositions change), and should be scalable (e.g., to support growing or shrinking numbers of applications or instances).

SUMMARY

Some disclosed embodiments describe non-transitory computer readable media, systems, and methods for implementing secure and multi-factor authentication for computing resources. For example, in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for implementing secure and multi-factor authentication for computing resources. The operations may comprise accessing at least one portion of identity data for a computing resource; providing the at least one portion of the identity data to the computing resource; identifying network address information unique to the computing resource; identifying a request, from the computing resource, to perform an action requiring an access token; provisioning the network address information unique to the computing resource, for use in transmitting the access token to the computing resource; and verifying both the at least one portion of the identity data and the network address information unique to the computing resource; wherein only the computing resource is configured to assert its identity data and receive at the provisioned network address the access token.

According to a disclosed embodiment, the identity data comprises the network address information unique to the computing resource and at least one of: a certificate, a token, a password, or a secret.

According to a disclosed embodiment, the network address information unique to the computing resource includes an IP address and a port number associated with the computing resource.

According to a disclosed embodiment, the port number is dynamically assigned to the computing resource.

According to a disclosed embodiment, the network address information unique to the computing resource is obtained from a network router or firewall associated with the computing resource.

According to a disclosed embodiment, the operations further comprise, conditional on the verification being successful, providing a privileged credential to the computing resource.

According to a disclosed embodiment, the computing resource is at least one of: a virtual computing instance or an application.

According to a disclosed embodiment, provisioning the network address information includes transmitting the network address information to a network router or firewall associated with the computing resource.

According to a disclosed embodiment, provisioning the network address information occurs transparently to the computing resource.

According to a disclosed embodiment, the at least one portion of the identity data and the network address information are each, by themselves, insufficient to successfully perform the verification.

According to another disclosed embodiment, there may be a computer-implemented method for implementing secure and multi-factor authentication for computing resources. The method may comprise accessing at least one portion of identity data for a computing resource; providing the at least one portion of the identity data to the computing resource; identifying network address information unique to the computing resource; identifying a request, from the computing resource, to perform an action requiring an access token; provisioning the network address information unique to the computing resource, for use in transmitting the access token to the computing resource; and verifying both the at least one portion of the identity data and the network address information unique to the computing resource; wherein only the computing resource is configured to assert its identity data and receive at the provisioned network address the access token.

According to a disclosed embodiment, the providing of the at least one portion of the identity data occurs during an initialization phase for the computing resource.

According to a disclosed embodiment, the providing of the at least one portion of the identity data occurs in response to the request from the computing resource.

According to a disclosed embodiment, identifying the request from the computing resource includes intercepting the request.

According to a disclosed embodiment, identifying the request from the computing resource includes receiving a re-routed version of the request.

According to a disclosed embodiment, the method further comprises, conditional on the verification being successful, providing a privileged credential to the computing resource.

According to a disclosed embodiment, the privileged credential is supplied from a credentials vault.

According to a disclosed embodiment, the privileged credential is sufficient to enable the computing resource to engage in secure communications with an access-restricted resource.

According to a disclosed embodiment, the network address information is obtained from a network router or firewall associated with the computing resource.

According to a disclosed embodiment, provisioning the network address information occurs transparently to the computing resource.

Aspects of the disclosed embodiments may include tangible computer-readable media that store software instructions that, when executed by one or more processors, are configured for and capable of performing and executing one or more of the methods, operations, and the like consistent with the disclosed embodiments. Also, aspects of the disclosed embodiments may be performed by one or more processors that are configured as special-purpose processor(s) based on software instructions that are programmed with logic and instructions that perform, when executed, one or more operations consistent with the disclosed embodiments.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosed example embodiments. However, it will be understood by those skilled in the art that the principles of the example embodiments may be practiced without every specific detail. Well-known methods, procedures, and components have not been described in detail so as not to obscure the principles of the example embodiments. Unless explicitly stated, the example methods and processes described herein are not constrained to a particular order or sequence, or constrained to a particular system configuration. Additionally, some of the described embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

The techniques for secure and multi-factor authentication for computing resources, as addressed herein, overcome several important technical problems in the fields of data communications security, authentication, virtualized or cloud-based computing, and authorization to access secure resources. In contrast to current techniques, which allow for applications or virtual instances to authenticate themselves via hardcoded credentials (e.g., embedded passwords, tokens, or certificates), the techniques discussed below allow for elevated security while maintaining efficient and flexible operations. In accordance with the techniques discussed below, applications or virtual instances may be verified in terms of both identity data that they assert and inherent network address information that they are assigned. Through a combined verification of these two different types of data, the application or virtual instance may be verified in terms of varying attributes, which enhances security. Accordingly, if the identity data of a legitimate application or virtual instance is stolen or leaked, the identity data will not, by itself, be sufficient to verify the entity asserting it. Correspondingly, if an unauthorized application or user attempts to mimic or utilize the network address information of a legitimate application or virtual instance, that information will also be insufficient to validate the unauthorized application or user. In some embodiments, moreover, these techniques for multi-factor verification of a computing resource may occur transparently to the computing resource itself, and to the target resource it is seeking to access.

Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings.

FIG. 1illustrates an exemplary system100for implementing secure and multi-factor authentication for computing resources. In accordance with system100, one or more software-based services106a-nmay be initiated or already running in an on-premises computing environment104. Before the resources106a-nare verified and able to perform certain secure functionality (e.g., communicate with access-restricted target resources103a-c, or with each other), they may undergo a multi-factor verification process. For example, as discussed below, software-based services106a-nmay assert a portion of identity data (e.g., a certificate or other data they have been provisioned) to security server101. In addition, network address information inherently associated with software-based services106a-nmay be received at security server101. Conditional on a verification of both the identity data and the network address information, resources106a-nmay be verified. In some embodiments, upon a successful verification, a credential may be retrieved from credentials vault102, which may be used by or on behalf of resources106a-nfor authentication and secure access to access-restricted target resources103a-c. The credential may be transmitted to the network address information (e.g., IP address and port number) associated with the validated identity data, which ensures that a malicious entity who has stolen the identity data cannot receive the credential. Because such a malicious entity would not have the same network address information, it would not receive the credential. These aspects ofFIG. 1and further discussed below.

Security server101may be implemented in a variety of configurations. In some embodiments, security server101may be a server within on-premises network104. For example, security server101may be an administrator server or a special-purpose server configured to perform the operations described below in connection withFIGS. 3A-3G and 4. Further, in some embodiments security server101may be separate from on-premises network104. In such embodiments, security server101may be operated by a third-party service provider and hosted in a separate on-premises or cloud-based (i.e., virtualized) network. In these various implementations, security server101may include hardware-based memory storing instructions configured to perform the functionality ofFIGS. 3A-3G and 4.

For example, security server101may include one or more hardware-based processors, such as microprocessors, embedded processors, or the like, or may take the form of a system-on-a-chip (SoC). According to some embodiments, the processor may be from the family of processors manufactured by Intel®, AMD®, Qualcomm®, Apple®, NVIDIA®, or the like. Further, the processor may also be based on the ARM architecture, or may be a graphics processing unit, etc. The disclosed embodiments are not limited to any particular type of processor configured in security server101. In addition, security server101may include one or more network adapter, such as network interfaces or communication devices (e.g., Ethernet, cellular, WiFi, Bluetooth®, RFID, NFC, RF, infrared, etc.) to communicate with the other components ofFIG. 1(e.g., resources106a-106n, through router or firewall105, or credentials vault102, etc.).

Security server101may also include one or more hardware-based memories, such as storage devices or media configured to store instructions used by the processor(s) to perform the functions described below. The memory may be configured to store software instructions, such as programs that, when executed by the processor, perform the operations described in connection withFIGS. 3A-3G and 4. The disclosed embodiments are not limited to particular software types or devices configured to perform dedicated tasks. For example, the memory may store a single program, such as a user-level application, that performs the functions of the disclosed embodiments, or may comprise multiple software programs. Additionally, the processor may in some embodiments execute one or more programs (or portions thereof). Furthermore, the memory may include one or more storage devices or media configured to store data for use by the programs.

In some embodiments, security server101may be configured to access a credentials vault102. Credentials vault102may be a network resource configured to store credentials (e.g., passwords, hashes based on passwords, tokens, cryptographic keys, certificates, secrets, or other data) that may be asserted to achieve authenticated access to secure (e.g., password-protected) network resources. In some embodiments, for example, credentials vault102may be a CyberArk™ vault. Credentials vault102may include integrated security techniques, such as periodic or automatic rotation of credentials stored within, monitoring capabilities regarding usage of credentials, detection and alerting capabilities to identify instances of misuse of credentials, and least-privilege policies that limit credentials to the lowest level of privileged access needed to perform defined privileged tasks (i.e., no excess or unnecessary privileges granted).

In some embodiments, credentials vault102may be internal to security server101(e.g., an internal database), where the two are an integrated single machine or system. Further, credentials vault102may be external to security server101but part of the same network as security server101, or may be in a separate network (e.g., an isolated and secure network). Consistent with the embodiments below, when one of services106a-nis successfully verified by security server101, credentials vault102may provision a credential or access token in several ways. One such technique may be to provide the credential or token to the verified service106a-nitself. Alternatively, for enhanced security, credentials vault102may provision the credential on behalf of the service106a-nbut without providing the credential to the service106a-n. For example, the credentials vault102may provide the credential to security server101for assertion on behalf of service106a-n, or may provide the credential directly to the access-protected target resource being accessed by the service106a-n. As discussed further below, the credential may provide secure and authenticated access to a resource such as a server103a(e.g., application server, web server, data server, etc.), IoT device103b(e.g., network-connected sensor device, surveillance device, vehicle device, appliance, telephony equipment, power grid device, etc.), or computer103c(e.g., personal computer, laptop, smartphone, smart watch, smart clothing, smart jewelry, etc.). Consistent with the embodiments below, such target devices103a-cmay have authentication requirements that may be satisfied based on security server101verifying a particular software-based service106a-nand/or credentials vault102supplying a credential to be used in the authentication.

Security server101, credentials vault102, and target devices103a-cmay communicate with each other, and with on-premises network104, through network107. Network107may be various types of data communication networks that can carry data communications between the components of system100. For example, network107may be based on any type of computer networking arrangement used to exchange data, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g., IEEE 802.11, etc.), a mesh network, a mobile network, a private data network, a virtual private network using a public network, a nearfield communications technique (e.g., Bluetooth™, infrared, etc.) that enables the system100to send and receive information between the components in the system100. In some embodiments, network107may include two or more of these forms of communications. As an example, on-premises network104may communicate with security server101over a LAN or WAN, while services106a-nmay communicate with target devices103a-cover a WAN or cellular network (e.g., 4G/5G, etc.).

On-premises network104may be implemented in a variety of embodiments. For example, on-premises network104may be a corporate or business network, educational institution network, IoT network, or various other types of networks. In such embodiments, on-premises network104may be implemented as a local area network (LAN), wireless local area network (WLAN), campus area network (CAN), etc., or a combination of these. On-premises network104may include a router or firewall105. For example, if router/firewall105is a router, it may handle network traffic management for the various services106a-nwithin network104, such as by IP address, MAC address, and/or port number. For example, such a router may perform packet switching among these components. Further, if router/firewall105is a firewall, it may implement security policies to protect services106a-cfrom outside threats. For example, such a firewall may implement whitelists and/or blacklists of IP addresses, URLs, URIs, etc., as well as behavioral or analytical security policies based on the timing, contents, addressing attributes, and other parameters of communications. In some embodiments, as discussed below, router/firewall105is configured to perform port forwarding, where it may receive incoming communications addressed to a particular service106a-c(e.g., by port number) and route the communications to the service. Such port forwarding may be performed by a firewall, router, or other network device (e.g., gateway, switch, etc.). In some embodiments, router/firewall105may be an integrated device, performing both routing and firewall functionality.

Software-based services106a-cwithin on-premises network104may be a variety of different types of software applications, agents, IoT devices, or other network-addressable devices. For example, services106a-cmay be applications or agents running on computers, servers, mobile devices, personal or wearable devices, etc. Further, services106a-cmay be IoT devices (e.g., network-connected utility equipment, sensors, vehicles, clothing, telephony devices, appliances, etc.). In some embodiments, services106a-cmay each be a different instance of the same application or device (e.g., each running the same software, perhaps with identical configuration settings), while in other embodiments services106a-cmay run different applications, perhaps on different types of devices.

FIG. 2is a block diagram of an exemplary system200for implementing secure and multi-factor authentication for computing resources in a virtual computing network. In many respects, system200is similar to system100. For example, both systems may include one or more security servers101, credentials vaults102, and target devices103a-c. Unlike the on-premises network104, however, virtual network202may be a cloud-based network comprising multiple virtualized computing instances203a-n. For example, virtualized network202may be based on cloud platform software such as AWS™, Azure™, IBM Cloud™ VMware™ Google Cloud Platform™ or others. As such, virtualized computing instances203a-nmay be software-based services or other types of computing instances such as virtual machines, container instances (e.g., Docker™, Kubernetes™ Java™ containers, etc.), serverless code instances (e.g., AWS Lambda™), etc.

In accordance withFIG. 2, virtualized network202may include, or may be controlled by, a cloud environment orchestrator201. In system200, cloud environment orchestrator201may perform a variety of functions relating to the virtual instances203a-n. For example, cloud environment orchestrator201may instantiate or spin up instances203a-n, configure the parameters and settings of instances203a-n, provision IP address or port number network address information for instances203a-n, monitor the operations and communications activity of instances203a-n, and deactivate or wind down instances203a-n, among other functions. In various embodiments, virtual environment orchestrator201may be based on cloud platform tools such as OpenStack™, IBM Cloud Orchestrator™, Apache CloudStack™, Puppet™, AWS CloudFormation™, Chef™, and others. In some embodiments, virtual instances203a-nmay be developed, spun up, and operated in a DevOps (e.g., continuous development or continuous deployment) environment, such as an environment using Jenkins™, Docker™, Puppet™, Kubernetes™, Chef™, OpenShift™, etc. In various embodiments, virtual instances203a-nmay be copies of the same instance (e.g., based on a common image, and created through a scaling function by virtual environment orchestrator201), or may each be different.

WhileFIGS. 1 and 2illustrate different environments including, respectively, on-premises network104and virtualized network202, in some embodiments the techniques described below in connection withFIGS. 3A-3G and 4may be practiced in a combination of both types of networks. Such embodiments may be hybrids of cloud-based and on-premises networks. For example, such embodiments may include both on-premises application services106a-nand virtualized instances203a-n.

FIG. 3Aillustrates an exemplary technique for provisioning a portion of identity data to a computing resource. InFIG. 3A, system300A includes a subset of the components ofFIGS. 1 and 2, solely for ease of illustration. In practice, system300A may include additional components, fewer components, or alternative components. With respect toFIGS. 3A-3G, while they are illustrated as virtualized (e.g., cloud-based) environments in accordance withFIG. 2, the techniques may be practiced in on-premises networks as well, consistent withFIG. 1.

In accordance with system300A, a first portion of identity data may be provided to a particular software-based service106ain an operation301. The identity data may be one or more of several different types of identifying data. For example, in some embodiments the identity data may be a user account name or identifier (e.g., Microsoft™, Linux, or other account name or identifier), an application account name or identifier, a digital certificate (e.g., SSL certificate, X.509 certificate, etc.), a token containing unique data, or other types of identifying data. Consistent with the embodiments below, the identity data may be provisioned for the service106afrom the security server101or from the credentials vault102. Further, the identity data may be provisioned by virtual environment orchestrator201in some embodiments.

Operation301may occur in a variety of ways. For example, in some embodiments service106amay be provisioned with the identity data as part of an instantiation or spinning up process of service106a. This may involve, for example, virtual environment orchestrator201creating service106a, or identifying the creation of service106aby a separate resource (e.g., a DevOps pipeline resource). Further, in some embodiments service106amay already be running in virtualized network202, and may later be provisioned with identity data in operation301. For example, virtual environment orchestrator201may be configured to scan existing virtualized instances in network202, and determine that newly identified service106ashould receive identity data. Further, this may involve an identification of service106abeing configured to need access to a remote target resource that is access protected (e.g., service106ais hardcoded with a URL or IP address of an external target resource requiring authentication). Further, in some embodiments an organization responsible for instantiating service106amay report the deployment of service106ain network202(e.g., report to security server101or virtual environment orchestrator201), and in response to the report the identity data may be provisioned in operation301.

Once computing resource106ahas received the identity data in operation301, it may store the identity data. For example, if computing resource106ais a virtual machine or container instance, it may store the identity data in a hard disk or in a memory accessible to it in its virtualized environment.

FIG. 3Billustrates an exemplary system300B for identifying network address information associated with a computing resource106a, in accordance with disclosed embodiments. For example, in operation302ofFIG. 3B, network address information assigned to computing resource106amay be transmitted to security server101or to credentials vault102. This may happen in several ways. In some embodiments, where virtual environment orchestrator201provisions the IP address and port number for computing resource106a, it may automatically report that network address information to security server101or credentials vault102upon the instantiation of computing resource106aor later, after the instantiation (e.g., when computing resource106aseeks to access an external access-protected resource). In other embodiments, virtual environment orchestrator201may not provision the network address information for computing resource106a, but may receive a report or notification of that network address information, or may detect the network address information during a scan of virtual environment202. Further, in some embodiments, computing resource106amay itself report its network address information (e.g., IP address and port number) to security server101or credentials vault102. Computing resource106amay do this automatically when it is first instantiated. Further, computing resource106amay do this after it is already running (e.g., when it seeks to access an access-protected target resource).

In some embodiments, such as those involving a router/firewall105as discussed in connection withFIG. 1, operation302may include the router/firewall105sending the network address information (e.g., IP address and port number) to security server101or credentials vault102. For example, router/firewall105may be configured to automatically, or upon request, transmit such network address information to security server101or credentials vault102.

Once security server101(or credentials vault102) has received the identity data (e.g., certificate as received in operation301) and network address data (e.g., IP address and port number, in operation302) of a particular computing resource106a, it may create or update a table, list, or database. For example, the table, list, or database may maintain profiles for individual computing resources106a-n, each indicating a corresponding element of identity data from operation301, and network address information from operation302. Consistent with the above embodiments, this table, list, or database may be updated automatically upon receiving reports from virtual environment orchestrator201of newly instantiated, or newly identified, virtual instances in environment202. Similarly, the table, list, or database may be updated automatically based on router/firewall105forwarding network address information and identity data corresponding to individual computing resources106a-n.

FIG. 3Cillustrates an exemplary system300C where computing resource106amakes a request in operation303to perform a privileged action. With reference toFIGS. 1 and 2, for example, this may involve computing resource106arequesting access to another of the software-based services106b-n, which may be an application, agent, software-based device, or virtualized computing instance. If the target software-based service106b-nhas a secure-access limitation (e.g., an authentication requirement, an authorization requirement, etc.), the computing resource106a's access to it may be considered privileged. In further embodiments, computing resource106amay be seeking to access an access-restricted external resource, such as server103a, IoT device103b, or computer103c. Likewise, if these external resources have an access limitation (e.g., authentication or authorization restrictions), computing resource106a's access to them may be considered privileged. Further, in some embodiments, all external access requests by computing resource106amay be considered privileged by default, or stated differently, all such access requests may involve an authentication or authorization requirement. This may occur, for example, in situations where some or all of software-based services106a-nare configured (e.g., by virtual environment orchestrator201) to require themselves to undergo an authentication or authorization process before externally connecting to other resources.

In some embodiments, the request in operation303from computing resource106ais made directly from computing resource106ato the target resource it is seeking access to. In other embodiments, the request in operation303may be intercepted based on target address information it includes. For example, virtual environment orchestrator201or router/firewall105may be configured to intercept requests from computing resource106athat involve privileged access to target resources. This intercepting may only occur for certain target resources that are sensitive or access-protected, or may occur for all requests by computing resource106a(e.g., as a default setting). In embodiments involving this type of intercepting, virtual environment orchestrator201or router/firewall105may then forward the intercepted request, from operation303, to security server101or credentials vault102.

FIG. 3Dillustrates an exemplary system300D where a computing resource106arequests a privileged access credential in operation304. For example, in embodiments where computing resource106ais seeking to access another resource that has an authentication or authorization requirement, a privileged access credential may be needed for such access. Accordingly, computing resource106amay need to retrieve such a credential in operation304from security server101or credentials vault102. As discussed above, credentials vault102(which may be part of security server101, or separate) may maintain privileged access credentials that permit access to particular resources, such as software-based services106b-n, servers103a, IoT devices103b, computers103c, and more. In some embodiments, credentials vault102may periodically, or according to a security policy, rotate and update the credentials that it stores for such access. For example, if a particular credential is determined to have been compromised or used in an attack, it may be rotated and replaced with a new credential.

In some embodiments, the request in operation304may come directly from computing resource106aitself. Such a request may include the network address information (e.g., IP address, port number, etc.) of computing resource106a. In further embodiments, the request in operation304may be made by virtual environment orchestrator201on behalf of computing resource106a. In such embodiments, the request by virtual environment orchestrator201may be configured to likewise include the network address information of computing resource106a.

The request in operation304may include identifying information of the target resource to which computing resource106ais seeking access. For example, the request in operation304may include an IP address, MAC address, network resource name, account name, unique identifier, or other identifying information associated with the target resource. This information may then be used by security server101or credentials vault102to identify an appropriate credential or token for the requested access. For example, security server101and/or credentials vault102may maintain lists, tables, or databases linking particular privileged access credentials or tokens to particular target network resources. Upon receiving the request in operation304, the security server101and/or credentials vault102may access the lists, tables, or databases to retrieve the appropriate privileged credential or access token.

In accordance with operation304, the computing resource106amay send its identity data (e.g., certificate as received in operation301) and its network address data (e.g., IP address and port number) in a single communication, or in separate communications, to security server101and/or credentials vault102. In embodiments where the identity data and network address data and transmitted in separate communications, they may be transmitted in one or multiple different transmission formats. For example, transmission formats may include LAN communications, WAN communications, WLAN communications, cellular communications, SMS or other text communications, or others. Accordingly, in embodiments where the identity data and network address data and transmitted in separate communications, one or multiple of these communications formats may be used, thus providing both multi-factor and multi-band (e.g., out of band) verification of computing resource106ain accordance withFIG. 3E.

FIG. 3Eillustrates an exemplary system300E for a multi-factor verification of identity data and network address information associated with a computing resource106a. Consistent with the discussion above, security server101and/or credentials vault102may have received both the identity data (e.g., certificate as received in operation301) and its network address data (e.g., IP address and port number) of particular computing resources106a-n. This data may be stored in tables, lists, or databases at security server101and/or credentials vault102. Accordingly, in operation305, security server101and/or credentials vault102may compare the received identity data and the received network address information, and verify whether they match a particular entry in the table, list, or database. That is, if in operation305the received identity data is found in the list, table, or database, but the received network address information is not found (or doesn't match the identity data), operation305may result in a lack of verifying the computing resource106a. Similarly, if in operation305the received network address information is found in the table, list, or database, but the received identity data is not found (or doesn't match the network address information), operation305may result in a lack of verifying the computing resource106a. On the other hand, if both the identity data and the network address data are found in the table, list, or database, and they are associated with each other (e.g., linked), operation305may result in successfully verifying the computing resource106a.

In some embodiments, operation305may additionally include, conditional on a successful verification of the computing resource106a, retrieving a privileged credential or access token from credentials vault102. Consistent with the discussion above, if the computing resource106ais verified in operation305, a particular privileged credential or access token may be retrieved from credentials vault102based on information in the request of operation303. This may include, for example, a network address (e.g., IP address or MAC address, etc.) of the target resource, a network name or account of the target resource, or another unique identifier of the target resource. Credentials vault102may use this information from the request of operation303to query a list, table, or database associating such information with particular credentials that may be used to access the target resource. For example, such credentials may be effective to authenticate or authorize the computing resource106ato access the target resource.

FIG. 3Fillustrates an exemplary system300F for provisioning a credential to a computing resource computing resource106a. As discussed above, the techniques ofFIG. 3Fmay be performed conditional on a successful verification of computing resource106ain accordance withFIG. 3E. If the computing resource106ais not successfully verified, operation306may not occur.

In operation306, a privileged access credential (e.g., accessed from credentials vault102, as discussed above) is provided to, or made available to, computing resource106a. For example, in some embodiments the privileged credential may be provided directly to computing resource106ain operation306. In that situation, computing resource106amay then use the credential to access the particular access-limited resource it is seeking access to (e.g., based on the request in operation303). Alternatively, in some embodiments the access token may be made available to a separate resource for use on behalf of computing resource106a. This may add security to system300F, since the privileged credential itself may not be stored on, and thus exposed on, computing resource106a. This technique may include, for example, sending the privileged credential or token in operation306to virtual environment orchestrator201, to router/firewall105, or to a separate proxy server that is configured to intercept and reroute communications from computing resource106a. Alternatively, in some embodiments the privileged credential or token may be transmitted from credentials vault102directly to the target resource to which the computing resource106aseeks access (e.g., based on operation303). In this situation, for example, credentials vault102may provide the privileged credential or token to the target resource together with identifying information associated with the computing resource106a(e.g., the identity data of operation301, the network address information of operation302, both, or different identifying data). The target resource may then use the privileged credential or access token for a successful authentication, and may use the received identifying information to permit the computing resource106ato engage in a secure session with it. In other words, the privileged credential or access token may be used for authentication or authorization at the target resource, and the authentication or authorization will be specific to the computing resource106a.

FIG. 3Gillustrates an exemplary system300G for a computing resource106ato engage in a secure session with an access-protected network resource using a provisioned credential. As discussed above, the privileged credential or access token may be retrieved from credentials vault102, and be provided directly to computing resource106aor to a separate resource (e.g., virtual environment orchestrator201, router/firewall105, a proxy server, etc.) on behalf of computing resource106a. In this situation, computing resource106a(or another resource, on its behalf) may then use the privileged credential or access token to engage in a secure session307with a target resource (e.g., resource identified in operation303). The particular target resource that is part of the secure session307may be, for example, another of software-based services106a-nor203a-n, server103a, IoT device103b, computer103c, or another target resource.

In some embodiments, the particular privileged access credential used in secure session307may be a limited-use credential or a one-time-use credential valid only for a single session. In such embodiments, credentials vault102may rotate or update the credentials it stores at the end of a session. For example, at the end of session307, virtual environment orchestrator201or computing resource106aitself may send a notification to security server101or credentials vault102confirming that the session has ended. Credentials value102may then rotate the credential that was used in secure session307to a new credential. Thus, any attempted reuse of the credential used in secure session307would be invalid and unable to achieve authentication or authorization at the particular target resource.

FIG. 4illustrates an exemplary process400for implementing secure and multi-factor authentication for computing resources. In accordance with the above discussion, process400may be implemented at, for example, security server101(which may include, or access, credentials vault102). Alternatively, process400may be implemented by router/firewall105or by virtual environment orchestrator201.

In operation401, process400may include accessing at least one portion of identity data for a computing resource106a. For example, as discussed above, a portion of identity data may be a user account name or identifier (e.g., Microsoft™′ Linux, or other account name or identifier), an application account name or identifier, a digital certificate (e.g., SSL certificate, X.509 certificate, etc.), a token containing unique data, or other types of identifying data. As discussed above, this type of data may be uniquely associated with the particular computing resource106a, and may represent something that the computing resource106a“has” or “knows” as a matter of multi-factor authentication.

The identity data may be accessed in operation401in a variety of ways. For example, the identity data may be generated dynamically at security server101or credentials vault102. The identity data may be generated in response to an identification from router/firewall105or virtual environment orchestrator201that the computing resource106ahas been spun up or newly identified. Further, in some embodiments the identity data may already be created, and operation401may include accessing the identity data from storage (e.g., a list, table, or database maintained at security server101or credentials value102). Consistent with the discussion above, the identity data may constitute only a portion of identity data that is sufficient to verify the computing resource106a. As discussed, the verification of computing resource106amay be based on such identity data as well as network address information uniquely associated with computing resource106a.

In operation402, process400may include providing the at least one portion of the identity data to the computing resource. For example, as discussed in connection withFIG. 3A, the identity data may be transmitted from security server101(or credentials vault102) to on-premises network104or virtual computing network202. The identity data may be received at router/firewall105and routed to computing resource106a, or may be send directly (e.g., via a secure tunnel connection) to computing resource106a. Further, the identity data may be received at virtual environment orchestrator201, or may be transmitted directly to computing resource106a(e.g., with or without a virtual environment router or firewall as part of network202). Once computing resource106areceives the identity data, it may store the identity data (e.g., in local physical storage, or virtually allocated storage in the case of virtualized network202), for later access.

In operation403, process400may include identifying network address information unique to the computing resource106a. For example, with reference toFIG. 1, router/firewall105may provide or forward such network address information (e.g., IP address and port number for computing resource106a) to security server101or credentials vault202. Similarly, virtual environment orchestrator201may provide such network address information to security server101or credentials vault102. This network address information may be provided in a variety of ways. For example, it may be provided to security server101or credentials vault102automatically upon the instantiation of computing resource106a, upon the subsequent identification of computing resource106a(e.g., based on a network scan), or as part of computing resource106asending a request for access to a particular target resource. In some embodiments, the IP address of computing resource106amay be unique (e.g., associated only with computing resource106a) or semi-unique (e.g., associated with a group of computing resources106a-nin environment104or202). The port number of computing resource106a, however, may be more unique. For example, while a group of computing resources106a-nmay share the same IP address, their respective port numbers may serve to uniquely identify them against each other. Thus, the combination of IP address and port number may serve to uniquely identify computing resource106a. In other embodiments, variations on this type of network address information, or different network address information, may be used.

In operation404, process400may include identifying a request, from the computing resource106a, to perform an action requiring an access token. For example, as described in connection withFIG. 3C, computing resource106amay request in operation303to access another network resource that has an access-limited restriction (e.g., authentication or authorization requirement). In some embodiments, the request from computing resource106amay be addressed and transmitted to the particular target resource itself. In other embodiments, the request from computing resource106amay be intercepted (e.g., based on an address field for the particular target resource, or based on any address field outside of computing resource106aitself). The intercepting may be performed by virtual environment orchestrator201or by router/firewall105, which may then forward the request to security server101or credentials vault102. Further, in some embodiments the intercepting may be performed by a separate proxy server. In other embodiments, the request may be sent directly from computing resource106ato security server101. For example, computing resource106amay be configured to route (e.g., based on a hooking function, or a prestored address for security server101) its outbound communications to access-protected resources to security server101.

In operation405, process400may include provisioning the network address information unique to the computing resource, for use in transmitting the access token to the computing resource. In some embodiments, this may include accessing a table, list, or database maintained by security server101, and looking up the network address information (e.g., IP address and port number) associated with the computing resource106a. In further embodiments, this may additionally include retrieving the particular access token (e.g., privileged access credential) from vault102, and sending the access token to the network address information that was looked up. Because the network address information is uniquely associated with computing resource106a, even if an attacker wrongfully gains access to the computing resource106a's identity data and attempts to use it, the attacker will not receive the access token because it will not have the same network address information of the rightful computing resource106a, to which the access token is sent. Thus, even in situations where computing resource106a's identity data is stolen, leaked, or otherwise compromised, that identity data, by itself, is insufficient to perform a successful verification.

In particular, in operation406, process400includes verifying both the at least one portion of the identity data and the network address information unique to the computing resource106a. An attacker who steals the portion of identity data, or a simply unauthorized user who obtains the identity data from a leakage of the data on which computing resource106ais built (e.g., a source image for computing resource106a), is thus unable to validate themselves because they will not have the same network address information (e.g., IP address and port number) as the rightful computing resource106a. If the verification in operation406is successful, process400may continue to operation408, where a successful verification is confirmed. At that point, computing resource106amay access its requested target resource, as described above in connection withFIG. 3G. Alternatively, if one or both of the identity data and network address information are unsuccessfully verified (e.g., because they cannot be located, or do not match each other), process400continues to operation407of performing a control action. The control action in operation407may include, for example, denying computing resource106aaccess to the target resource, rotating a credential (e.g., in credentials vault102) associated with computing resource106a, assigning new network address information (e.g., a new port number) to computing resource106a, performing keystroke logging or recording on computing resource106a, performing activity monitoring or recording on computing resource106a, performing network communications activity monitoring or recording for computing resource106a, or various other control actions.

It is to be understood that the disclosed embodiments are not necessarily limited in their application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the examples. The disclosed embodiments are capable of variations, or of being practiced or carried out in various ways.

The disclosed embodiments may be implemented in a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

It is expected that during the life of a patent maturing from this application many relevant virtualization platforms, virtualization platform environments, trusted cloud platform resources, cloud-based assets, protocols, communication networks, security tokens and authentication credentials will be developed and the scope of these terms is intended to include all such new technologies a priori.