Patent Description:
Unfortunately, traditional systems for deploying signed certificates on backup servers and client devices may be slow and/or ineffective. For example, because backup servers and client devices may have varying computing environments, backup services may be unable to deploy certificates via a standard process or infrastructure. As such, deploying a signed certificate may require manual input or confirmation from one or more administrators within a backup service. Administrators managing vast numbers of backup servers or client devices may be unable to deploy certificates quickly enough to meet the demands of backup clients. As such, backup services may be unable to complete requested backup operations, or may be unable to provide backup clients with sufficient security during backup operations. The instant disclosure, therefore, identifies and addresses a need for systems and methods for performing secure backup operations.

<CIT> describes that an order to back up a user's set of data through a telecommunications network, a terminal retrieves, from an application server, a table containing sets of risk factors respectively associated with backup servers, assigns a trust level to each backup server identified in the table based on the set of risk factors associated with the backup server, selects at least three backup servers based on the trust levels respectively assigned to the backup servers, and transmits the set of data to each selected backup server, which saves the set of data.

<CIT> describes a technique to enable the user of storage clouds to use of a plurality of storage clouds without the user of storage clouds being aware of which data is being entrusted to which storage cloud and without sacrificing safety or ease-of-use by selecting at least one storage cloud to store an entity file storable in a cloud-utilizing terminal from among a plurality of storage clouds connected via a network to the cloud-utilizing terminal. This technique includes referencing the attributes or context of an entity file, or the attributes of a virtual folder and each attribute of a plurality of storage clouds, in response to the creation or update of the entity file in the virtual folder in the cloud-utilizing terminal, and selecting at least one storage cloud from among a plurality of storage clouds for storing the entity file so as to satisfy predefined rules.

<CIT> proposes a communication system and a security assurance device, which are stated to be capable of assuring that a target party for communication is implementing security countermeasures. A server transmits information necessary for AC issuance to a security assurance authority. The security assurance authority verifies the security of the server during communication based upon this information necessary for AC issuance. And, when the security of the server during communication is confirmed, the security assurance authority issues an AC which proves the security of the server during communication, and transmits it to the server. Upon receipt of this AC, the server transmits the AC to a client, according to a connection request from the client. And, upon receipt of this AC, the client verifies the security during communication of the server, based upon the AC.

Particular aspects of the invention are set out in the appended independent claims.

As will be described in greater detail below, the instant disclosure describes various systems and methods for performing secure backup operations. In one example, a method for performing secure backup operations may include (i) identifying a group of backup servers with heterogeneous computing environments that provide backup services for at least one backup client, (ii) determining, for each backup server within the group, a trust level of the backup server by identifying at least one security characteristic of the backup server, (iii) deploying, on each of the backup servers within the group, a signed certificate that enables the backup server to transfer backup data with a security level that corresponds to the trust level of the backup server, and (iv) performing secure backup operations for the backup client by (a) identifying a sensitivity level of a backup task to be performed and (b) assigning the backup task to a backup server within the group of backup servers that has a signed certificate with a security level appropriate for the sensitivity level of the backup task.

In some examples, identifying the security characteristic of the backup server may include identifying settings of a security infrastructure of the backup server. Additionally or alternatively, identifying the security characteristic of the backup server may include identifying a security characteristic of a network the backup server uses to transfer backup data and/or a security characteristic of a data storage system of the backup server.

In some embodiments, identifying the security characteristic of the backup server may include identifying an initial security characteristic that indicates the backup server meets an initial trust level that is appropriate for a sensitivity level of a type of backup task the backup server will likely perform. In such embodiments, deploying the signed certificate on the backup server may include deploying an initial signed certificate with a security level that corresponds to the initial trust level. Additionally in such embodiments, assigning the backup task to the backup server may include (i) determining that the security level of the initial signed certificate is not appropriate for the sensitivity level of the backup task assigned to the backup server, (ii) identifying an additional security characteristic of the backup server that indicates the backup server meets an additional trust level that is appropriate for the sensitivity level of the backup task (where the additional trust level is higher than the initial trust level) and then (iii) deploying an additional signed certificate on the backup server that has a security level corresponding to the additional trust level.

In some examples, deploying the signed certificate on the backup server may include storing, within the signed certificate, the security characteristic of the backup server. In these examples, the backup client may facilitate performing the secure backup operations by authenticating the backup server based on the security characteristic within the signed certificate.

In some examples, deploying the signed certificate on the backup server may include selecting, from within multiple types of signed certificates with various security levels, a type of signed certificate appropriate for the trust level of the backup server. In one embodiment, types of signed certificates with high security levels are appropriate for backup servers with high trust levels. Furthermore, in some examples, the multiple types of signed certificates may include (i) signed certificates manually deployed by an administrator of the group of backup servers, (ii) signed certificates deployed using an authorization token, (iii) signed certificates deployed using a challenge-response protocol, and/or (iv) self-signed certificates that are not signed by a certificate authority.

In some embodiments, identifying the sensitivity level of the backup task may include identifying a type of backup operation and/or a type of backup data involved in the backup task. Additionally or alternatively, identifying the sensitivity level of the backup task may include identifying a security characteristic of the backup client. In addition, in some examples, assigning the backup task to the backup server that has the signed certificate with the appropriate security level may include assigning backup tasks with high sensitivity levels to backup servers that have signed certificates with high security levels.

In some examples, the method may further include (i) determining a trust level of the backup client by identifying at least one security characteristic of the backup client and then (ii) deploying a signed certificate on the backup client that enables the backup client to facilitate backup operations with a security level that corresponds to the trust level of the backup client. In these examples, performing the secure backup operations for the backup client may include ensuring that the security level of the signed certificate deployed on the backup client is appropriate for the sensitivity level of the backup task.

In one embodiment, a system for performing secure backup operations may include several modules stored in memory, including (i) an identification module that identifies a group of backup servers with heterogeneous computing environments that provide backup services for at least one backup client, (ii) a determination module that determines, for each backup server within the group, a trust level of the backup server by identifying at least one security characteristic of the backup server, (iii) a deployment module that deploys, on each of the backup servers within the group, a signed certificate that enables the backup server to transfer backup data with a security level that corresponds to the trust level of the backup server, and (iv) a backup module that performs secure backup operations for the backup client by (a) identifying a sensitivity level of a backup task to be performed and (b) assigning the backup task to a backup server within the group of backup servers that has a signed certificate with a security level appropriate for the sensitivity level of the backup task. In addition, the system may include at least one physical processor configured to execute the identification module, the determination module, the deployment module, and the backup module.

In some examples, the above-described method may be encoded as computer-readable instructions on a non-transitory computer-readable medium. For example, a computer-readable medium may include one or more computer-executable instructions that, when executed by at least one processor of a computing device, may cause the computing device to (i) identify a group of backup servers with heterogeneous computing environments that provide backup services for at least one backup client, (ii) determine, for each backup server within the group, a trust level of the backup server by identifying at least one security characteristic of the backup server, (iii) deploy, on each of the backup servers within the group, a signed certificate that enables the backup server to transfer backup data with a security level that corresponds to the trust level of the backup server, and (iv) perform secure backup operations for the backup client by (a) identifying a sensitivity level of a backup task to be performed and (b) assigning the backup task to a backup server within the group of backup servers that has a signed certificate with a security level appropriate for the sensitivity level of the backup task.

Features from any of the above-mentioned embodiments may be used in combination with one another in accordance with the general principles described herein. These and other embodiments, features, and advantages will be more fully understood upon reading the following detailed description in conjunction with the accompanying drawings and claims.

Throughout the drawings, identical reference characters and descriptions indicate similar, but not necessarily identical, elements. While the example embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, the example embodiments described herein are not intended to be limited to the particular forms disclosed. Rather, the instant disclosure covers all modifications, equivalents, and alternatives falling within the scope of the appended claims.

The present disclosure is generally directed to systems and methods for performing secure backup operations. As will be explained in greater detail below, by determining a level of trustworthiness of backup servers managed by a backup service and/or backup clients that subscribe to the backup service, the disclosed systems and methods may deploy signed certificates on the devices that enable the devices to perform backup operations with security levels appropriate for each device. As such, the disclosed systems and methods may ensure that sensitive backup tasks are performed with sufficient levels of security, while reducing the need to deploy secure but labor-intensive signed certificates on backup servers and clients that do not handle sensitive backup data.

Moreover, the systems and methods described herein may improve the functioning and/or performance of a group of backup servers with heterogeneous computing environments by enabling the backup servers to securely perform backup tasks most suited for the security properties of the backup servers. These systems and methods may also improve the field of data backup and restoration by providing more efficient, flexible, and effective methods of selecting and deploying signed certificates on backup servers and backup clients.

The following will provide, with reference to <FIG> and <FIG>, detailed descriptions of example systems for performing secure backup operations. Detailed descriptions of corresponding computer-implemented methods will also be provided in connection with <FIG> and <FIG>. In addition, detailed descriptions of example backup host trust levels and corresponding backup tasks will be provided in connection with <FIG>.

<FIG> is a block diagram of an example system <NUM> for performing secure backup operations. As illustrated in this figure, example system <NUM> may include one or more modules <NUM> for performing one or more tasks. As will be explained in greater detail below, example system <NUM> may include an identification module <NUM> that identifies a group of backup servers with heterogeneous computing environments that provide backup services for at least one backup client. In addition, example system <NUM> may include a determination module <NUM> that determines, for each backup server within the group, a trust level of the backup server by identifying at least one security characteristic of the backup server.

In addition, and as will be explained in greater detail below, example system <NUM> may include a deployment module <NUM> that deploys, on each backup server within the group, a signed certificate that enables the backup server to transfer backup data with a security level that corresponds to the trust level of the backup server. Finally, example system <NUM> may include a backup module <NUM> that performs secure backup operations for the backup client by (i) identifying a sensitivity level of a backup task to be performed and (ii) assigning the backup task to a backup server within the group of backup servers that has a signed certificate with a security level appropriate for the sensitivity level of the backup task. Although illustrated as separate elements, one or more of modules <NUM> in <FIG> may represent portions of a single module or application.

In certain embodiments, one or more of modules <NUM> in <FIG> may represent one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks. For example, and as will be described in greater detail below, one or more of modules <NUM> may represent modules stored and configured to run on one or more computing devices, such as the devices illustrated in <FIG> (e.g., backup servers <NUM>(<NUM>)-(N) and/or control server <NUM>). One or more of modules <NUM> in <FIG> may also represent all or portions of one or more special-purpose computers configured to perform one or more tasks.

As illustrated in <FIG>, example system <NUM> may also include one or more memory devices, such as memory <NUM>. Memory <NUM> generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and/or computer-readable instructions. In one example, memory <NUM> may store, load, and/or maintain one or more of modules <NUM>. Examples of memory <NUM> include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives, (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, or any other suitable storage memory.

As illustrated in <FIG>, example system <NUM> may also include one or more physical processors, such as physical processor <NUM>. Physical processor <NUM> generally represents any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions. In one example, physical processor <NUM> may access and/or modify one or more of modules <NUM> stored in memory <NUM>. Additionally or alternatively, physical processor <NUM> may execute one or more of modules <NUM> to facilitate performing secure backup operations. Examples of physical processor <NUM> include, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable physical processor.

As illustrated in <FIG>, example system <NUM> may also include one or more additional elements <NUM>. In one example, additional elements <NUM> may include security characteristics <NUM>, which generally represent any type or form of property or feature indicating the hygiene and/or trustworthiness of one or more backup servers. In addition, additional elements <NUM> may include signed certificates <NUM>, which generally represent any type or form of electronic credentials used to certify the identity of a backup server or backup client.

As illustrated in <FIG>, additional elements <NUM> may additionally include trust levels <NUM>. Trust levels <NUM> generally represent any quantification or assessment of the trustworthiness, hygiene, or security state of a backup server. In some embodiments, trust levels <NUM> may be based on one or more of security characteristics <NUM>. As shown in <FIG>, additional elements <NUM> may also include security levels <NUM>. Security levels <NUM> generally refer to any indication of the degree to which one or more signed certificates (e.g., signed certificates <NUM>) enable backup servers and backup clients to securely perform backup operations. In one example, security levels <NUM> may correspond to trust levels <NUM>. Finally, as illustrated in <FIG>, additional elements <NUM> may include sensitivity levels <NUM>. Sensitivity levels <NUM> generally represent any quantification or assessment of the importance and/or confidentiality of a backup task or the data involved in a backup task.

Example system <NUM> in <FIG> may be implemented in a variety of ways. For example, all or a portion of example system <NUM> may represent portions of example system <NUM> in <FIG>. As shown in <FIG>, system <NUM> may include backup servers <NUM>(<NUM>)-(N) in communication with a control server <NUM> via a network <NUM>. In one example, all or a portion of the functionality of modules <NUM> may be performed by backup servers <NUM>(<NUM>)-(N), control server <NUM>, and/or any other suitable computing system. As will be described in greater detail below, one or more of modules <NUM> from <FIG> may, when executed by at least one processor of backup servers <NUM>(<NUM>)-(N) and/or control server <NUM>, enable control server <NUM> to perform secure backup operations.

For example, identification module <NUM> may cause control server <NUM> to identify backup servers <NUM>(<NUM>)-(N) with heterogeneous computing environments <NUM>(<NUM>)-(N) that provide backup services for a backup client <NUM>. Next, determination module <NUM> may cause control server <NUM> to determine, for backup servers <NUM>(<NUM>)-(N), trust levels <NUM>(<NUM>)-(N) of backup servers <NUM>(<NUM>)-(N) by identifying security characteristics <NUM>(<NUM>)-(N) of backup servers <NUM>(<NUM>)-(N). In addition, deployment module <NUM> may cause control server <NUM> to deploy, on backup servers <NUM>(<NUM>)-(N), signed certificates <NUM>(<NUM>)-(N) that enable backup servers <NUM>(<NUM>)-(N) to transfer backup data with security levels <NUM>(<NUM>)-(N) that correspond to trust levels <NUM>(<NUM>)-(N). Finally, backup module <NUM> may cause control server <NUM> to perform secure backup operations for backup client <NUM> by (i) identifying a sensitivity level <NUM>(<NUM>) of a backup task <NUM> and (ii) assigning backup task <NUM> to one of backup servers <NUM>(<NUM>)-(N) that has a signed certificates with a security level appropriate for sensitivity level <NUM>(<NUM>).

Backup servers <NUM>(<NUM>)-(N) generally represent any type or form of computing device capable of reading computer-executable instructions. In some examples, backup servers <NUM>(<NUM>)-(N) may represent media servers that run backup software configured to securely store and transfer backup data for one or more backup clients. Additional examples of backup servers <NUM>(<NUM>)-(N) include, without limitation, laptops, tablets, desktops, servers, cellular phones, Personal Digital Assistants (PDAs), multimedia players, embedded systems, wearable devices (e.g., smart watches, smart glasses, etc.), gaming consoles, variations or combinations of one or more of the same, or any other suitable computing device.

Control server <NUM> generally represents any type or form of computing device that is capable of directing or managing backup servers. In some examples, control server <NUM> may represent a media server with administrative privileges that enable control server <NUM> to communicate with, deploy signed certificates on, and/or assign backup tasks to backup servers <NUM>(<NUM>)-(N) and backup clients that subscribe to the backup service that manages control server <NUM>. Additional examples of control server <NUM> include, without limitation, storage servers, database servers, application servers, and/or web servers configured to run certain software applications and/or provide various storage, database, and/or web services. Although illustrated as a single entity in <FIG>, control server <NUM> may include and/or represent a plurality of servers that work and/or operate in conjunction with one another.

Network <NUM> generally represents any medium or architecture capable of facilitating communication or data transfer. In one example, network <NUM> may facilitate communication between backup servers <NUM>(<NUM>)-(N) and control server <NUM>. In this example, network <NUM> may facilitate communication or data transfer using wireless and/or wired connections. Examples of network <NUM> include, without limitation, an intranet, a Wide Area Network (WAN), a Local Area Network (LAN), a Personal Area Network (PAN), the Internet, Power Line Communications (PLC), a cellular network (e.g., a Global System for Mobile Communications (GSM) network), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable network.

Many other devices or subsystems may be connected to computing system <NUM> in <FIG> and/or computing system <NUM> in <FIG>. Conversely, all of the components and devices illustrated in <FIG> and <FIG> need not be present to practice the embodiments described and/or illustrated herein. The devices and subsystems referenced above may also be interconnected in different ways from that shown in <FIG>. Computing systems <NUM> and <NUM> may also employ any number of software, firmware, and/or hardware configurations. For example, one or more of the example embodiments disclosed herein may be encoded as a computer program (also referred to as computer software, software applications, computer-readable instructions, and/or computer control logic) on a computer-readable medium.

The term "computer-readable medium," as used herein, generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable media include, without limitation, transmission-type media, such as carrier waves, and non-transitory-type media, such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media), and other distribution systems.

<FIG> is a flow diagram of an example computer-implemented method <NUM> for performing secure backup operations. The steps shown in <FIG> may be performed by any suitable computer-executable code and/or computing system, including system <NUM> in <FIG>, system <NUM> in <FIG>, and/or variations or combinations of one or more of the same. In one example, each of the steps shown in <FIG> may represent an algorithm whose structure includes and/or is represented by multiple sub-steps, examples of which will be provided in greater detail below.

As illustrated in <FIG>, at step <NUM> one or more of the systems described herein may identify a group of backup servers with heterogeneous computing environments that provide backup services for at least one backup client. For example, identification module <NUM> may, as part of control server <NUM> in <FIG>, identify backup servers <NUM>(<NUM>)-(N) with heterogeneous computing environments <NUM>(<NUM>)-(N) that provide backup services for backup client <NUM>.

The term "computing environment," as used herein, generally refers to all or a portion of the software and/or hardware components of a computing device that may control or affect the computing device's operation or functionality. In one example, the computing environment of a backup server may include the backup server's operating system, applications running on the backup server, security settings of the backup server, an amount and/or type of data storage on the backup server, a network accessible by the backup server, and/or a physical location of the backup server.

The systems described herein may identify a group of backup servers with heterogeneous computing environments in a variety of ways. In some examples, identification module <NUM> may, while hosted on a control server that directs backup operations within a backup service, identify all or a portion of the backup servers managed by the backup service. In one embodiment, identification module <NUM> may identify each new backup server configured to perform backup operations for a backup service (e.g., each backup server that has not yet received a signed certificate).

In some embodiments, identification module <NUM> may identify characteristics of the computing environments of one or more backup servers. For example, identification module <NUM> may identify an operating system of each backup server, as well as any program or service (e.g., ACTIVE DIRECTORY) on the backup servers that enables fast deployment of signed certificates. In addition, identification module <NUM> may identify characteristics of one or more backup clients used by the backup servers. In some examples, identification module <NUM> may determine that a group of identified backup servers and/or backup clients have varying computing environments. For example, identification module <NUM> may determine that the identified devices have various operating systems, or determine that only a portion of the devices run programs such as ACTIVE DIRECTORY. As such, identification module <NUM> may determine that a backup service may be unable to implement a standard infrastructure or method to deploy signed certificates on the backup servers and backup clients.

Returning to <FIG>, at step <NUM> one or more of the systems described herein may determine, for each backup server within the group of backup servers, a trust level of the backup server by identifying at least one security characteristic of the backup server. For example, determination module <NUM> may, as part of control server <NUM> in <FIG>, determine trust levels <NUM>(<NUM>)-(N) of backup servers <NUM>(<NUM>)-(N) by identifying security characteristics <NUM>(<NUM>)-(N).

The term "trust level," as used herein, generally refers to any quantification or assessment of the trustworthiness, hygiene, or security state of a computing device. In some examples, a trust level may represent an overall measure of the security characteristics of a computing device. In addition, a trust level may be represented as a number within any type or form of range or scale.

The term "security characteristic," as used herein, generally refers to any type of property or feature indicative of a computing device's ability to safely receive, store, handle, and/or transfer backup data (i.e., without the data being lost, corrupted, or accessed by an unauthorized entity). Examples of security characteristics of a backup server include, without limitation, characteristics of a network used by the backup server to transfer backup data (e.g., settings of a Domain Name Server (DNS) and/or Dynamic Server Configuration Protocol (DHCP) used by the backup server), characteristics of a data storage system of the backup server, settings of the security infrastructure of the backup server, and/or privileges granted to a user or administrator of the backup server.

The systems described herein may identify trust levels of a group of backup servers based on security characteristics of the backup servers in a variety of ways. In some embodiments, determination module <NUM> may identify multiple security characteristics of a backup server to determine the highest trust level that the backup server meets. For example, determination module <NUM> may perform a standard set of security tests on a backup server (based on identifying a standard set of security characteristics) and then calculate a trust level of the backup server based on the number and/or type of security tests successfully completed by the backup server. As specific examples, determination module <NUM> may assign a backup server a trust level of <NUM> (within a scale of <NUM>-<NUM>, with <NUM> representing the highest trust level) in the event that the backup server uses a certain type of secure data storage system, and assign a backup server a trust level of <NUM> in the event that the backup server both implements the secure data storage system and uses a particular DNS known to be secure.

In other embodiments, determination module <NUM> may identify one or a limited number of security characteristics of a backup server to determine whether the backup server meets a particular trust level appropriate for backup tasks the backup server is likely to perform. For example, a backup service may designate one or more backup servers to handle particular types of backup data and/or perform backup tasks for particular clients. As a high level of security may generally not be necessary for these designated tasks or clients, determination module <NUM> may conserve time and computing resources by simply identifying a small number of security characteristics to determine whether the designated backup servers have a sufficient trust level for the backup tasks they will likely perform.

In some examples, determination module <NUM> may identify security characteristics of a backup server from a control server within a backup service that directs or manages the backup service's backup operations (e.g., as illustrated in <FIG>). In other examples, determination module <NUM> may identify security characteristics of a backup server while operating directly on the backup server. Additionally or alternatively, all or a portion of determination module <NUM> may operate as part of or within a certificate authority server. As will be explained below, the systems described herein may work with (or as part of) certificate authorities to deploy signed certificates on backup servers based on security characteristics of the backup servers.

Furthermore, in some embodiments, determination module <NUM> may determine a trust level of one or more backup clients based on security characteristics of the backup clients. For example, in addition to calculating trust levels of a group of backup servers, determination module <NUM> may calculate trust levels of one or more backup clients that employ the backup servers to perform backup operations. Determination module <NUM> may calculate trust levels for backup clients using any one or more of the techniques described above in connection with backup servers.

Returning to <FIG>, at step <NUM> one or more of the systems described herein may deploy, on each backup server within the group of backup servers, a signed certificate that enables the backup server to transfer backup data with a security level that corresponds to the trust level of the backup server. For example, deployment module <NUM> may, as part of control server <NUM> in <FIG>, deploy signed certificates <NUM>(<NUM>)-(N) that enable backup servers <NUM>(<NUM>)-(N) to transfer backup data with security levels <NUM>(<NUM>)-(N). In addition, deployment module <NUM> may deploy signed certificates on one or more backup clients that enable the backup clients to transfer backup data with a security level that corresponds to trust levels of the backup clients.

The term "signed certificate," as used herein, generally refers to any type or form of electronic credential used to assert the identity of a user or device. In some examples, a signed certificate may assert the identity of a device by encrypting a signature associated with the device with a private encryption key (e.g., an encryption key known only to the device or a trusted third party). Another device that wishes to verify the identity of the device providing the certificate may decrypt the signature using a public encryption key that corresponds to the private encryption key. After the verification is complete, a secure, encrypted communication channel may be established between the two devices.

In some embodiments, a user or device that wishes to generate a trusted certificate may enlist a certificate authority to sign the certificate. As used herein, the term "certificate authority" generally refers to any trusted party that verifies the identity of a user or device requesting a signed certificate and then signs the certificate on behalf of the user or device. Another device verifying the certificate may determine that the device providing the certificate is trusted based on determining that the certificate was signed by the certificate authority. In other embodiments, a certificate may simply be signed by the entity whose identity the certificate is asserting (i.e., creating a self-signed certificate). While a self-signed certificate may not necessarily be malicious, a device attempting to verify the self-signed certificate may be unable to determine whether the certificate should be trusted.

Deployment module <NUM> may deploy signed certificates on backup hosts using a variety of security or authentication protocols. The term "backup host," as used herein, generally refers to any device running backup software (i.e., either a backup client or a backup server). In some examples, the process used to deploy a signed certificate on a backup host may define or represent the security level of the signed certificate. The term "security level," as used herein, generally refers to any indication or quantification of the ability of a signed certificate to facilitate a backup host in safely transmitting and/or handling backup data.

In general, deployment processes that result in highly secure signed certificates may involve greater time and/or resources from backup services, backup clients, and/or certificate authority servers (as well as administrators of these devices) compared to deployment processes that result in less secure certificates. As such, the disclosed systems may deploy signed certificates on a group of backup servers and/or backup clients using a variety of deployment processes to minimize the burden and/or overhead of deployment while still ensuring that sensitive backup tasks are handled with appropriate security levels.

In one embodiment, deployment module <NUM> may deploy signed certificates on backup hosts by facilitating a deployment process that involves manual input from one or more administrators of a backup host and/or certificate authority. In general, such a manual deployment process may generate highly secure certificates, but may be slower and more tedious than other deployment processes.

Method <NUM>(a) in <FIG> illustrates an example of a manual deployment process. In particular, method <NUM>(a) describes steps that may be performed by a certificate authority <NUM> and an administrator <NUM> while deploying a signed certificate on a backup host <NUM>. At step <NUM> of method <NUM>(a), administrator <NUM> may receive or configure security credentials used to generate a signed certificate (e.g., a public or private key associated with backup host <NUM>). Administrator <NUM> may then send the security credentials to certificate authority <NUM> with a request to generate a signed certificate for backup host <NUM>. At step <NUM>, certificate authority <NUM> and/or administrator408 may deploy the signed certificate on backup host <NUM>. For example, certificate authority <NUM> may generate the certificate and then administrator <NUM> may manually copy the certificate onto backup host <NUM>.

In other embodiments, deployment module <NUM> may deploy signed certificates on backup hosts using an authorization token. In general, deployment processes involving authorization tokens may generate certificates that are less secure than the certificates deployed via the manual deployment process described above. However, these deployment processes may be faster and/or require less input from administrators than a manual process.

Method <NUM>(b) in <FIG> illustrates an example of a deployment process involving an authorization token. In particular, method <NUM>(b) shows steps that may be performed by a certificate authority <NUM> and an administrator <NUM> while deploying a signed certificate on a backup host <NUM>. At step <NUM> in method <NUM>(b), administrator <NUM> may send, along with a request to generate a signed certificate for backup host <NUM>, an authorization token that verifies the identity of backup host <NUM> to certificate authority <NUM>. In one example, the authorization token may have been configured and/or provided to administrator <NUM> from an administrator of certificate authority <NUM>. At step <NUM>, certificate authority <NUM> may generate a signed certificate based on receiving the authorization token and then deploy the signed certificate on backup host <NUM> (e.g., without requiring input from administrator <NUM>).

In a further embodiment, deployment module <NUM> may deploy signed certificates on backup hosts based on identifying or verifying security characteristics of the backup servers. In general, deployment processes involving security verifications may be less secure than either the manual deployment processes or token-based processes described above, but may also be more efficient (e.g., these processes may not require any manual input from an administrator).

Method <NUM>(a) in <FIG> illustrates an example of a deployment process involving a security verification. In particular, method <NUM>(a) shows steps that may be performed by a certificate authority <NUM> and a backup host <NUM> while deploying a signed certificate on backup host <NUM>. At step <NUM> in method <NUM>(a), backup host <NUM> may send a request to certificate authority <NUM> to receive a signed certificate. At step <NUM>, certificate authority <NUM> may verify one or more security characteristics of backup host <NUM> to determine whether backup host <NUM> is authorized to receive a signed certificate. For example, certificate authority <NUM> may perform one or more of the security tests described above in connection with step <NUM>, or certificate authority <NUM> may identify the results of a previously-performed security test. At step <NUM>, after verifying the security characteristics of backup host <NUM>, certificate authority <NUM> may deploy a signed certificate on backup host <NUM>.

In another embodiment, deployment module <NUM> may deploy signed certificates on backup hosts based on simply verifying the identity of the backup hosts. In general, deployment processes involving identity verifications may be less secure (but more efficient) than the other processes described above.

Method <NUM>(b) in <FIG> illustrates an example of a deployment process involving identity verification. In particular, method <NUM>(b) shows steps that may be performed by a certificate authority <NUM> and a backup host <NUM> while deploying a signed certificate on backup host <NUM>. At step <NUM> in method <NUM>(b), backup host <NUM> may send a request to certificate authority <NUM> to receive a signed certificate. At step <NUM>, certificate authority <NUM> may verify the identity of backup host <NUM> (e.g., based on information within the request sent by backup server <NUM>). At step <NUM>, after verifying the identity of backup host <NUM>, certificate authority <NUM> may deploy a signed certificate on backup host <NUM>.

Deployment module <NUM> may deploy signed certificates on backup clients or backup servers using any additional or alternative deployment process not illustrated in <FIG> and <FIG>. For example, deployment module <NUM> may deploy signed certificates using multi-use authorization tokens capable of authenticating multiple backup servers or by using challenge-response protocols. Furthermore, in some embodiments, deployment module <NUM> may deploy self-signed certificates on backup hosts, thereby avoiding the time and computing resources required for a certificate authority to sign certificates.

The systems described herein may deploy signed certificates that enable backup hosts to transfer backup data with appropriate security levels in a variety of ways. In general, deployment module <NUM> may determine that signed certificates deployed via processes that result in high security levels (such as certificates manually deployed by administrators) are appropriate for highly trusted backup hosts, while signed certificates with low security levels (such as certificates deployed without verification processes) are appropriate for untrusted backup hosts.

As an example of assigning types of signed certificates to backup host trust levels, <FIG> illustrates a table of backup host trust levels and corresponding backup tasks <NUM>. In this example, table <NUM> may map trust levels of backup hosts to appropriate certificate types. As shown in <FIG>, table <NUM> may illustrate four trust levels (i.e., trust levels <NUM>-<NUM>, with trust level <NUM> representing the highest trust level). In this example, deployment module <NUM> may determine that certificates signed by a certificate authority and deployed with input from an administrator are most appropriate for backup hosts with trust level <NUM>, certificates deployed based on an authorization token are most appropriate for backup hosts with trust level <NUM>, certificates deployed based on a challenge-response protocol are most appropriate for backup hosts with trust level <NUM>, and self-signed certificates are most appropriate for backup hosts with trust level <NUM>.

After determining a type of signed certificate most appropriate for a backup host based on the trust level of the backup server, deployment module <NUM> may facilitate the process of deploying the signed certificate (e.g., via the processes described above in connection with <FIG> and <FIG>). For example, deployment module <NUM> may configure appropriate security protocols involved in the certificate's deployment process, as well as implement the deployment process based on the computing environment of the backup host (e.g., determined by identification module <NUM> in step <NUM>). In some examples, deployment module <NUM> may deploy (or facilitate deploying, in the event that administrator input is required) a signed certificate on a backup host while the backup server is being configured with backup software that initializes the backup host and/or enables the backup host to perform backup operations.

Additionally, in some embodiments, deployment module <NUM> may store one or more security characteristics of a backup host within the signed certificate deployed on the backup host. In particular, deployment module <NUM> may store this information within a user-defined extension or field within the certificate. In this way, a backup client may efficiently identify a backup server's trust level before the backup server performs a backup task for the backup client (rather than performing a more resource-intensive authentication process based on information provided by a certificate authority or external database). Furthermore, the security characteristics of one or more backup hosts may be stored in additional locations for user and administrator reference, such as in control servers and/or audit logs within a backup service.

Returning to <FIG>, at step <NUM> one or more of the systems described herein may perform secure backup operations for the backup client by (i) identifying a sensitivity level of a backup task to be performed and (iii) assigning the backup task to a backup server within the group of backup servers that has a signed certificate with a security level appropriate for the sensitivity level of the backup task. For example, backup module <NUM> may, as part of control server <NUM> in <FIG>, perform secure backup operations for backup client <NUM> by (i) identifying a sensitivity level <NUM>(<NUM>) of a backup task <NUM> and (ii) assigning backup task <NUM> to one of backup servers <NUM>(<NUM>)-(N) that has a signed certificates with a security level appropriate for sensitivity level <NUM>(<NUM>).

The term "backup task," as used herein, generally refers to any type or form of project, job, or operation involving receiving, transmitting, storing, handling, and/or restoring backup data (or metadata describing backup data). In some examples, a backup task may involve data transfer between a backup client and a backup server. In other examples, a backup task may involve backup data or metadata manipulation on backup servers (e.g., identifying backup images, deleting backup data, and updating backup policies or software). In addition, backup tasks may have a variety of sensitivity levels. The term "sensitivity level," as used herein, generally refers to any indication or quantification of the importance and/or desired confidentiality of a backup task or the backup data involved in the backup task.

The systems described herein may identify a sensitivity level of a backup task in a variety of ways. In some examples, backup module <NUM> may determine a sensitivity level of a backup task based on a type of data involved in the backup task. For example, backup module <NUM> may determine that a backup task involving data that a backup client has identified as classified or critical is more sensitive than a backup task involving unclassified or non-critical data. In another example, backup module <NUM> may determine that a backup task involving unencrypted data is more sensitive than a backup task involving encrypted data, as unencrypted data may represent a greater security risk to a backup client if accessed by unauthorized parties.

Additionally or alternatively, backup module <NUM> may determine a sensitivity level of a backup task based on a type of backup operation involved in the backup task. For example, backup module <NUM> may determine that backup tasks involving restoring data to a backup client are more sensitive than backup tasks that involve only receiving and storing data for a backup client. Furthermore, backup module <NUM> may determine a sensitivity level of a backup task based on security characteristics or properties of a backup client that initiated the backup task. For example, backup module <NUM> may assign high sensitivity levels to backup tasks initiated by clients known to handle private or restricted information (such as financial information or government projects).

After identifying a sensitivity level of a backup task, backup module <NUM> may assign or designate the backup task to be performed by a backup server that has an appropriate trust level (e.g., a backup server that has a signed certificate with an appropriate security level). In general, backup module <NUM> may assign backup tasks with low sensitivity levels to backup servers that have signed certificates with low security levels, and assign highly sensitive backup tasks to backup servers that have highly secure signed certificates.

As specific examples, table <NUM> in <FIG> illustrates backup tasks that backup module <NUM> may determine are appropriate for backup hosts with various trust levels and certificate types. Specifically, table <NUM> may illustrate that only backup servers with trust levels of <NUM> (i.e., servers with signed certificates manually deployed by an administrator) are permitted to perform backup tasks involving restricted data. In addition, table <NUM> may illustrate that backup servers with trust levels of <NUM> are permitted to perform backup tasks involving unencrypted data, while backup data must be encrypted to be handled by backup servers with a trust level of <NUM>. Finally, table <NUM> may illustrate that backup servers with trust levels of <NUM> (i.e., servers with self-signed certificates) are only allowed to perform backup tasks for a specified client (e.g., a client known to handle non-sensitive data).

In some examples, backup module <NUM> may determine that a backup server does not have a signed certificate with a security level appropriate for a backup task assigned to the backup server. For example, as described above, a backup service may delegate a backup server to perform backup tasks for a particular backup client. In addition, deployment module <NUM> may have deployed a signed certificate on the delegated backup server that is appropriate for backup tasks that the backup client will likely request. As such, in the event that the backup client requests a backup task with an unexpectedly high sensitivity level, the delegated backup server may be unable to perform the backup task with an appropriate level of security.

Accordingly, the systems described herein may replace the signed certificate on the backup server with an additional signed certificate to enable the backup server to securely perform the sensitive backup task. For example, determination module <NUM> may identify one or more additional security characteristics of the backup server to ensure that the backup server meets a higher trust level that is appropriate for the sensitive backup task. Deployment module <NUM> may then deploy an additional signed certificate on the backup server that has a security level appropriate for the sensitivity level of the backup task. As such, the disclosed systems may ensure that sensitive backup tasks are only performed by backup servers capable of providing a sufficient level of security.

Furthermore, in some embodiments, backup module <NUM> may ensure that a backup client is able to facilitate a backup task with a sufficient level of security. For example, backup module <NUM> may determine whether a backup client involved in a backup task has a trust level appropriate for a sensitivity level of the backup task (or a signed certificate with an appropriate security level) before permitting backup data to be transferred to or from the backup client.

Method <NUM> in <FIG> illustrates an example process of facilitating a backup task for a backup client based on a trust level of the backup client. In particular, method <NUM> illustrates steps performed by a backup server <NUM> while performing a backup task that involves restoring data to a backup client <NUM>. At step <NUM> in method <NUM>, backup server <NUM> may establish a secure connection with backup client <NUM>. For example, backup server <NUM> and backup client <NUM> may identify and/or verify each other based on information within signed certificates deployed on both devices. At step <NUM>, backup server <NUM> may determine whether a trust level of backup client <NUM> is appropriate for a sensitivity level of the backup task. For example, backup server <NUM> may analyze security information included within the signed certificate on backup client <NUM> to identify the security level of the certificate and/or the trust level of backup client <NUM>. In the event that backup server <NUM> determines that the trust level of backup client <NUM> is appropriate, backup server <NUM> may perform step <NUM>(a), which involves restoring backup data to backup client <NUM>. However, in the event that backup server <NUM> determines that the trust level of backup client <NUM> is not appropriate, backup server <NUM> may perform step <NUM>(b), which involves backup server <NUM> aborting the backup task or otherwise declining to restore backup data to backup client <NUM>.

As explained above in connection with <FIG>, a backup service (such as NETBACKUP) may deploy signed certificates on backup servers that enable the backup servers to perform backup operations with security levels appropriate for the trust levels of the backup servers. For example, a NETBACKUP control server may designate highly trusted backup servers to receive signed certificates manually deployed by administrators to enable the backup servers to perform highly sensitive backup tasks, while deploying less-secure certificates via more automatic processes on backup servers that are not required to performed such sensitive backup tasks. In this way, the NETBACKUP control server may ensure that sensitive backup tasks are performed with an appropriate level of security, while avoiding excess time and computing resources spent deploying certificates with labor-intensive deployment processes on backup servers that handle less sensitive tasks.

While the foregoing disclosure sets forth various embodiments using specific block diagrams, flowcharts, and examples, each block diagram component, flowchart step, operation, and/or component described and/or illustrated herein may be implemented, individually and/or collectively, using a wide range of hardware, software, or firmware (or any combination thereof) configurations. In addition, any disclosure of components contained within other components should be considered example in nature since many other architectures can be implemented to achieve the same functionality.

In some examples, all or a portion of example system <NUM> in <FIG> may represent portions of a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

In various embodiments, all or a portion of example system <NUM> in <FIG> may facilitate multi-tenancy within a cloud-based computing environment. In other words, the modules described herein may configure a computing system (e.g., a server) to facilitate multi-tenancy for one or more of the functions described herein. For example, one or more of the modules described herein may program a server to enable two or more clients (e.g., customers) to share an application that is running on the server. A server programmed in this manner may share an application, operating system, processing system, and/or storage system among multiple customers (i.e., tenants). One or more of the modules described herein may also partition data and/or configuration information of a multi-tenant application for each customer such that one customer cannot access data and/or configuration information of another customer.

According to various embodiments, all or a portion of example system <NUM> in <FIG> may be implemented within a virtual environment. For example, the modules and/or data described herein may reside and/or execute within a virtual machine. As used herein, the term "virtual machine" generally refers to any operating system environment that is abstracted from computing hardware by a virtual machine manager (e.g., a hypervisor).

In some examples, all or a portion of example system <NUM> in <FIG> may represent portions of a mobile computing environment. Mobile computing environments may be implemented by a wide range of mobile computing devices, including mobile phones, tablet computers, e-book readers, personal digital assistants, wearable computing devices (e.g., computing devices with a head-mounted display, smartwatches, etc.), variations or combinations of one or more of the same, or any other suitable mobile computing devices. In some examples, mobile computing environments may have one or more distinct features, including, for example, reliance on battery power, presenting only one foreground application at any given time, remote management features, touchscreen features, location and movement data (e.g., provided by Global Positioning Systems, gyroscopes, accelerometers, etc.), restricted platforms that restrict modifications to system-level configurations and/or that limit the ability of third-party software to inspect the behavior of other applications, controls to restrict the installation of applications (e.g., to only originate from approved application stores), etc. Various functions described herein may be provided for a mobile computing environment and/or may interact with a mobile computing environment.

While various embodiments have been described and/or illustrated herein in the context of fully functional computing systems, one or more of these example embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using modules that perform certain tasks. These modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these modules may configure a computing system to perform one or more of the example embodiments disclosed herein.

The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the example embodiments disclosed herein. This example description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claim 1:
A computer-implemented method for performing secure backup operations, at least a portion of the method being performed by a computing device comprising at least one processor, the method comprising:
identifying a plurality of backup servers with heterogeneous computing environments that provide backup services for at least one backup client;
determining, for each of the plurality of backup servers, a trust level of the backup server by identifying at least one security characteristic of the backup server;
selecting, for each of the plurality of backup servers and from multiple types of signed certificates with various security levels, a type of signed certificate that, when deployed on the backup server, enables the backup server to perform backup operations with a security level that corresponds to the trust level of the backup server;
deploying, on each of the plurality of backup servers, a signed certificate of the type selected for the backup server; and
performing secure backup operations for the backup client by:
identifying a sensitivity level of a backup task to be performed; and
assigning the backup task to at least one backup server within the plurality of backup servers that has a signed certificate with a security level appropriate for the sensitivity level of the backup task.