Permissions for backup-related operations

Abstract

Example techniques for granting permission to perform an operation related to a backup copy are described. The backup copy corresponds to first device data, and the first device data is stored on the first device. In one example, in response to receiving a request to perform an operation related to the backup copy, telemetry data received from the first device is analyzed. Based on the analysis, it is determined that the security of the first device has not been compromised. Based on this determination, permission to perform the operation related to the backup copy is granted.

Description

[0001] This divisional application is a divisional application of the Chinese invention patent application with application number 202111245534.7 and application date October 26, 2021. Technical Field

[0002] Data stored on a computing device may become unavailable due to various reasons (e.g., due to data corruption or deletion). To completely prevent data loss due to unavailability, a backup copy of the data can be used to restore the data on the computing device. The backup copy can be stored remotely from the computing device, for example, on a cloud storage device. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The following detailed description refers to the accompanying drawings, in which:

[0004] Figure 1 A system for permitting execution of backup-related operations according to an example implementation of the present disclosure is illustrated;

[0005] Figure 2 FIGURE 1 illustrates a network environment in which a system is implemented to permit execution of backup-related operations according to an example implementation of the present disclosure;

[0006] Figure 3 FIGURE 1 illustrates a network environment for implementing security verification of a first device to permit execution of backup-related operations according to an example implementation of the present disclosure;

[0007] Figure 4 A method for permitting execution of backup-related operations according to an example implementation of the present disclosure is illustrated;

[0008] Figure 5 A method for performing backup-related operations according to an example implementation of the present disclosure is illustrated; and

[0009] Figure 6 A computing environment implementing a non-transitory computer-readable medium for permitting performance of backup-related operations according to one example implementation of the present disclosure is illustrated. DETAILED DESCRIPTION

[0010] For example, data stored on a computing device may become unusable due to the presence of malware on the computing device. For example, ransomware is a type of malware that encrypts files on a computing device, preventing the user from using them. After paying a ransom, a key to decrypt the files may be provided to the user.

[0011] If data becomes unusable, backup copies of the data can be used to restore the data. However, in some cases, the backup copies may become unusable. For example, this may occur if malware spreads to the backup copies during the execution of the backup operation and renders the backup copies unusable, such as by modifying or deleting the backup copies.

[0012] The present disclosure relates to permission for backup-related operations. Utilizing the implementation of the present disclosure, it is possible to prevent backup copies from becoming unusable due to malware attacks.

[0013] According to an example implementation, a request may be received to grant permission to perform an operation related to a backup copy. Operations related to a backup copy may also be referred to as backup-related operations and may include, for example, the creation, modification, or deletion of a backup copy. The backup copy may correspond to first device data stored on the first device. Additionally, the backup copy may be stored on the second device. In one example, the first device data may relate to a virtual machine (VM) hosted on the first device, and the backup copy may be a VM image from which the VM may be restored.

[0014] In response to receiving the request, telemetry data received from the first device is analyzed. The telemetry data may include information about operations performed on the first device. For example, the telemetry data may include login attempt information, the number of file encryptions, the number of file deletions, workload parameters of hardware components of the first device (the hardware components may be, for example, processors, memory, and storage devices), or any combination of the foregoing. In one example, telemetry data received within a specific time period relative to the time of receipt of the request is analyzed. For example, telemetry data received within a first time period before the time the request is received, telemetry data received within a second time period after the time the request is received, or both are analyzed. In one example, analysis of the telemetry data to identify or predict the occurrence of a fault in the first device may be performed by a system that periodically receives telemetry data from the first device.

[0015] Based on the analysis, a determination is made as to whether the security of the first device has been compromised. For example, if the number of login attempts within a specific time period is greater than the average number of login attempts, it may be determined that the security of the first device has been compromised. If it is determined that the security of the first device has not been compromised, permission is granted to perform the backup-related operation. To grant permission, in one example, a token granting permission may be transmitted to the first device, and the first device may send the token to the second device. Based on the token, the second device may perform the backup-related operation. If the security of the first device is determined to be compromised, the request to perform the backup-related operation is denied.

[0016] In one example, to determine whether the security of the first device has not been compromised, in addition to analyzing telemetry data, security handshake-based verification can also be utilized. To perform security handshake-based verification, the system analyzing telemetry data can also attempt to establish a security handshake with the first device. In response to establishing the security handshake, the system can determine that the security of the first device has not been compromised.

[0017] The present disclosure can prevent the loss or unusability of backup copies due to malware attacks on computing devices storing parent data (i.e., data corresponding to the backup copies). Therefore, the backup copies can be protected from malware attacks on computing devices storing parent data. The present disclosure uses telemetry data from computing devices that send requests for backup-related operations to determine whether the security of the computing device has been compromised. Therefore, the present disclosure can provide simpler and more efficient determinations related to the security of the computing device. In addition, the present disclosure can use telemetry data that has been received from the computing device to identify and predict failures. Therefore, the computing device may only need to provide little or no additional data to implement the present disclosure.

[0018] The following description refers to the accompanying drawings. Wherever possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar parts. Although several examples are described in the description, modifications, adaptations and other implementations are possible and are intended to be covered herein.

[0019] Figure 1 A system 100 for permitting execution of backup copy related operations according to an example implementation of the present disclosure is illustrated. The system 100 may be implemented as a computing device such as a desktop computer, a laptop computer, a server, etc. The system 100 includes a processor 102 and a memory 104 coupled to the processor 102.

[0020] Processor 102 may be implemented as a microprocessor, a microcomputer, a microcontroller, a digital signal processor, a central processing unit, a state machine, a logic circuit, and / or any device that can manipulate signals based on operational instructions. Among other capabilities, processor 102 may fetch and execute computer-readable instructions contained in memory 104. Computer-readable instructions may include instructions 106-112. The functionality of processor 102 may be provided using dedicated hardware as well as hardware capable of executing machine-readable instructions.

[0021] The memory 104 may include any non-transitory computer-readable medium, including volatile memory (e.g., RAM) and / or non-volatile memory (e.g., EPROM, flash memory, memristor, etc.). The memory 104 may also be an external memory unit, such as a flash drive, an optical drive, an external hard drive, etc.

[0022] In addition to the processor 102 and the memory 104, the system 100 may also include (a plurality of) interfaces and system data ( Figure 1 The interface(s) may include various instruction-based and hardware interfaces that permit interaction with users and other communication and computing devices, such as network entities, network servers, and external repositories and peripherals. System data may serve as a repository for storing data that may be acquired, processed, received, or created by the instructions.

[0023] In operation, instructions 106 may be executed to receive a request for permission to perform an operation related to a backup copy. An operation related to a backup copy may also be referred to as a backup-related operation and may be, for example, a backup create operation, a backup modify operation, or a backup delete operation. The request may also be referred to as a permission request. The backup copy may correspond to the first device ( Figure 1 The backup copy may be stored on the second device (not shown). For example, the backup copy may be an exact copy of the first device data. The backup copy may be stored on the second device ( Figure 1 (not shown). In one example, the first device data and the backup copy may include data corresponding to the first device. In addition, the backup copy may be an image from which the first device can be restored to its operating state. For example, the first device data and the backup copy may include data corresponding to a virtual machine (VM) hosted on the first device. The data corresponding to the VM may include, for example, files, folders, applications, and an operating system (OS) of the VM. Therefore, the backup copy may be a VM image from which the VM can be instantiated. The permission request may be sent by the first device to the system 100.

[0024] In response to the request, telemetry data received from the first device is analyzed. In one example, the telemetry data may indicate operations performed on the first device, workload information for hardware components of the first device, data read counts for the first device, data write counts for the first device, the number of failed attempts to perform backup-related operations, a backup policy, or a combination thereof. The data may include, for example, first device data. The operations performed on the first device may be, for example, the number of login attempts, the number of file encryption attempts, the number of file modifications, the number of file deletion attempts, or a combination thereof. The workload information for the hardware components may include, for example, the workload of the processor of the first device, the workload of the memory of the first device, the input / output operations per second (IOPS) of the storage device of the first device, or a combination thereof. The data read count and the data write count indicate the number of times the data is read and written, respectively. The number of failed attempts to perform backup-related operations helps track previously identified backup issues. As will be explained later, for example, if the security of the first device is determined to have been compromised, attempts to perform backup-related operations may have failed. The backup policy of the first device may indicate the frequency of backup creation operations (i.e., how often backup copies are created), the backup retention period (i.e., how long the backup copies are retained), and the backup target (i.e., the location where the backup copies are stored). In one example, the telemetry data (instead of the backup policy) may include an identifier for the backup policy. Furthermore, the system 100 may have stored the backup policy and the identifier therein. Thus, upon receiving the identifier as part of the telemetry data, the system 100 may retrieve and analyze the backup policy.

[0025] In one example, the system 100 may analyze telemetry data received within a first time period (also referred to as a "first time period"). The first time period may be defined relative to the time when the request is received. For example, the system 100 may analyze telemetry data received within the first time period before the request is received. Instead of or in addition to analyzing telemetry data received in the first time period before the request is received, the system 100 may analyze telemetry data received within a second time period after the request is received. When the instructions 108 are executed, analysis of the telemetry data may be performed.

[0026] Based on the analysis, a determination is made as to whether the security of the first device has been compromised. For example, the security of the first device may have been compromised due to a malware attack. When instruction 110 is executed, a determination is made regarding the security of the first device. If it is determined that the security of the first device has not been compromised, permission is provided to perform backup-related operations. To provide permission, system 100 may transmit a token indicating permission to the first device. When instruction 112 is executed, permission may be provided.

[0027] Figure 2The diagram illustrates a network environment 200 in which the system 100 is implemented to permit backup-related operations to be performed. The network environment 200 includes a first device 202. In one example, the first device 202 may be a server computer. In another example, the first device 202 may be a hyper-converged infrastructure device in which computing, storage, and networking are integrated. The first device 202 may be provided in a data center or a remote site, such as an offshore drilling platform. The first device 202 may have first device data 204 stored therein. The first device data 204 may include files, folders, and the like. In one example, the first device data 204 may be associated with a VM ( Figure 2 In another example, the first device data 204 may be data corresponding to the first device 202.

[0028] The network environment 200 also includes a second device 206 for storing backup copies of parent data stored in other devices. For example, the second device 206 may store a backup copy 208 corresponding to the first device data 204. The backup copy 208 may include a copy, a replica, an image, etc. of the first device data 204. In one example, the backup copy 208 may be a VM image hosted in the first device 202 and from which a VM can be restored, or may be an image from which the first device 202 can be restored. The second device 206 may include a storage device ( Figure 2 (not shown) such as a hard disk or solid-state drive (SSD). In one example, the first device 202 can be an edge device, and the second device 206 can be a core device corresponding to the edge device. A core device corresponding to an edge device can refer to a device that can receive data from an edge device for further processing, can instruct an edge device to perform a computing task, or both. Compared to an edge device, a core device can have more storage capacity and thus can store backup copies from an edge device.

[0029] When the first device data 204 becomes unusable, the first device data 204 can be restored from the backup copy 208 in the first device 202. For example, the unusability of the first device data 204 may be due to the storage device ( Figure 2The unusability may be caused by damage (not shown), accidental deletion, etc. to the first device 202. The unusability may also be caused by a compromise of the security of the first device 202. For example, the first device 202 may be infected by ransomware, which may result in encryption of the data in the first device 202. In some cases, the security compromise of the first device 202 may also affect the backup copy 208. For example, the ransomware that has infected the first device 202 may result in the deletion of the backup copy 208. The ransomware may also cause the modification of the backup copy 208, such as by causing the deletion of parts of the backup copy 208, the encryption of the backup copy 208, or the modification of the metadata of the backup copy 208, so that the first device data 204 cannot be restored from the backup copy 208. The ransomware may also create an encrypted backup copy 206 in the second device 206 by instructing the second device to store the encrypted backup copy. The key used for encryption may be known to the creator of the ransomware rather than the user of the first device 202. Therefore, encryption makes the backup copy unusable. Ransomware may also cause new backup copies to be created, which replace (and thus delete) uncorrupted backup copies, such as backup copy 208 .

[0030] To help prevent the deletion, modification, or replacement of the backup copy 208 due to a compromise of the security of the first device 202, in one example, the first device 202 includes a backup processing engine 209. In one example, the backup processing engine 209 can be executed by a processor of the first device 202 by executing a set of instructions ( Figure 2 The backup processing engine 209 receives a request to perform a backup-related operation. The backup processing engine 209 may receive a request related to a backup-related operation from, for example, a user of the first device 202 or a storage management device 210 that manages a backup copy of the data corresponding to the first device 202. In the latter case, the storage management device 210 may send the request based on, for example, a backup policy or an instruction from a storage administrator. In one example, if the first device 202 is attacked by malware, the malware may send the request to the backup processing engine 209.

[0031] In one example, the request may specify a backup-related operation to be performed. The request may also specify the name of the device data or the name of the backup copy corresponding to the backup-related operation. For example, the request may specify that a new backup copy of the first device data 204 is to be created or that the backup copy 208 is to be deleted. Upon receiving the request, the backup processing engine 209 sends a permission request 212 to the system 100 to grant permission to perform the backup-related operation. In one example, the permission request 212 may specify the backup-related operation to be performed and may also specify the name of the device data or the name of the backup copy, namely, the first device data 204 or the backup copy 208, or both, corresponding to the backup-related operation. By sending a permission request to the system 100 in response to each received request, the backup processing engine 209 can prevent the execution of malicious requests generated by malware. In another example, the permission request 212 may be sent by the second device 206. The second device 206 may send the permission request 212 in response to receiving a request from the backup processing engine 209 to perform a backup-related operation. The permission request 212 can be said to correspond to the first device 202 because the first device 202 stores the parent data of the backup copy to which the permission request 212 corresponds.

[0032] Upon receiving the permission request 212, the system 100 may determine whether the security of the first device 202 (the device corresponding to the permission request 212) is compromised. Determining whether the security of the first device 202 is compromised may also be referred to as verifying the security of the first device 202.

[0033] System 100 includes a backup protection engine 213 that receives permission requests, such as permission request 212, from computing devices, such as first device 202, and queues the permission requests. Furthermore, backup protection engine 213 causes analysis engine 214 to verify the security of the device corresponding to each queued permission request. In one example, backup protection engine 213 and analysis engine 214 can each be executed by processor 102 by executing an instruction set ( Figure 2 is implemented by

[0034] To verify the security of the first device 202, the analysis engine 214 can utilize telemetry data sent by the first device 202. The information included in the telemetry data can be used to verify whether the first device 202 is under malware attack. For example, as part of the telemetry data, the number of login attempts can indicate the number of successful and unsuccessful attempts to log in to the first device 202 within a time period. A large number of unsuccessful login attempts in a short period of time may indicate an unauthenticated attempt to infiltrate the first device 202. A large number of encryptions in a short period of time may indicate the presence of ransomware activity in the first device 202. Similarly, a large number of file modifications or file deletions, high workload of hardware components, a large number of read or write data, or a large number of failed attempts to perform backup-related operations may indicate the presence of ransomware activity. In addition, a new backup policy (which can be part of the telemetry data) indicating a reduced backup retention period or an increased backup creation frequency may also indicate ransomware activity. Therefore, based on the analysis of the telemetry data, the analysis engine 214 can verify the security of the first device 202.

[0035] In one example, analysis of the telemetry data includes comparing an actual parameter value received as part of the telemetry data with an expected parameter value. The expected parameter value can be a predefined range or value that the corresponding portion of the telemetry data should meet when the security of the first device 202 is not compromised. For example, if the actual parameter value differs significantly from the expected parameter value, it can be determined that the security of the first device 202 is compromised. The expected parameter value can be provided by a user or can be determined by the analysis engine 214.

[0036] In one example, to verify the security of first device 202 based on telemetry data, analysis engine 214 may utilize machine learning techniques, such as an autoregressive integrated moving average (ARIMA) linear regression model, that can detect anomalies in the received data. Analysis engine 214 may monitor parameters of telemetry data received in the past and predict expected parameter values ​​that a corresponding portion of the telemetry data should meet. Analysis engine 214 may also compare the expected parameter values ​​with corresponding actual parameter values ​​received as part of the telemetry data. If the actual parameter value received in the telemetry data differs significantly from the expected parameter value (e.g., if the difference between the actual parameter value and the expected parameter value exceeds a threshold), analysis engine 214 may determine that the security of first device 202 has been compromised. For example, if the actual number of login attempts is significantly higher than the expected number of login attempts, it may be determined that the security of first device 202 has been compromised. Analysis engine 214 may also compare telemetry data received during a previous malware attack with the current telemetry data. If the two telemetry data sets are similar (e.g., if the difference between the parameter values ​​of the two telemetry data sets is less than a threshold), the analysis engine 214 can determine that the security of the first device 202 has been compromised. In one example, the analysis engine 214 can compare the backup policy received in the telemetry data with past telemetry data to identify suspicious changes in the backup policy, such as a decrease in the backup retention period or an increase in the frequency of backup creation.

[0037] As previously described, telemetry data may include read counts and write counts for data. In one example, system 100 may analyze the read counts and write counts for the data corresponding to permission request 212, and may not analyze the read counts and write counts for other data. For example, because permission request 212 corresponds to first device data 204, system 100 may analyze the read counts and write counts for first device data 204, but not the read counts and write counts for other data. Thus, wasteful analysis of other read counts and write counts is avoided.

[0038] After verifying the security of the first device 202 based on the telemetry data, the analysis engine 214 can provide the analysis results to the backup protection engine 213. Based on the results, the backup protection engine 213 can grant permission to perform backup-related operations. For example, if it is determined that the security of the first device 202 has not been compromised, the backup protection engine 213 can grant permission to the first device 202 to perform backup-related operations, for example, by sending a token 216 to the first device 202. If the security of the first device 202 has been compromised, the backup protection engine 213 can grant permission to the first device 202 to perform backup-related operations, such as by not sending the token 216 and / or by sending a rejection message (in the example of FIG. 2 ). Figure 2 ) to deny permission to perform backup-related operations.

[0039] In one example, the token 216 can indicate the backup-related operation for which permission is granted and can indicate the name of the first device data 204 and / or backup copy 208 corresponding to performing the backup-related operation. For example, the token 216 can indicate that permission is granted to create a new backup copy of the first device data 204 or to delete the backup copy 208. The details of the backup-related operation and the device data / backup copy indicated in the token 216 can be obtained from the permission request 212.

[0040] Upon receiving the token 216, the first device 202 may transmit an execution request 218 to the second device 206 for performing a backup-related operation. The execution request 218 may include details of the backup-related operation, such as a new backup copy to be stored in the second device 206, changes to be made to the backup copy 208, or instructions to delete the backup copy 208. In addition to the execution request 218, the first device 202 may also transmit the token 216 to the second device 206. Based on the token 216, the second device 206 may determine that the security of the first device 202 is verified. Furthermore, the second device 206 may verify whether the token 216 authorizes the execution of the backup-related operation specified in the execution request 218.

[0041] The second device 206 can also verify that the token 216 specifies the same name as the device data or the name of the backup copy for the operation. For example, if the execution request 218 indicates that a new backup copy of the first device data 204 is to be created, the second device 206 can check whether the token 216 authorizes the creation of a backup copy of the first device data 204. Thus, the second device 206 verifies that the execution request 218 is consistent with the token 216. In response to successful verification, the second device 206 performs the backup-related operation as specified in the execution request 218. The specification of the backup-related operation and the backup copy name and / or device data name in the token 216, and the verification of the token 216 by the second device 206 ensure that the backup-related operation performed is the same as the operation that the system 100 has granted permission for.

[0042] In one example, instead of or in addition to verifying the consistency between the execution request 218 and the token 216, the second device 206 can determine whether the token 216 is authentic. To perform this determination, the second device 206 can send an authentication request to the system 100, requesting that the system 100 verify whether the token 216 was issued by the system 100 and whether the token 216 is valid. Upon receiving the request, the system 100 can verify the authenticity and validity of the token 216. For example, the system 100 can verify that the token 216 was indeed issued by the system 100 and that the token 216 was issued in response to a recent permission request. In response to the successful verification of the token 216, the system 100 can send a message to the second device 206 indicating that the token 216 is authentic. Performing backup-related operations after authentication of the token 216 prevents the execution of backup-related operations based on a fake token created by malware.

[0043] If the security of the first device 202 is compromised, the backup protection engine 213 may, for example, not send the token 216 and / or send a rejection message (in Figure 2 216 ), denying permission to perform backup-related operations. Therefore, the first device 202 does not send an execution request 218 to the second device 206. Even if the first device 202 sends an execution request 218 to the second device 206, the second device 206 refuses to perform the backup-related operations because the token 216 was not sent to the second device 206. In another example, when verifying the security of the first device 202, the system 100 may send the token 216 to the second device 206 instead of the first device 202. Based on the token 216, the second device 206 may perform the backup-related operations as indicated by the execution request 218.

[0044] Thus, the granting or denial of permission to perform backup-related operations can be performed without having to analyze the contents of the backup copy 208 or the first device data 204. For example, the system 100 does not have to compare the newly created backup copy against the backup copy 208. Similarly, the system 100 does not have to process proposed changes to the backup copy 208 or analyze actions performed on the first device data 204. Instead, as described above, the granting and denial of permission can be performed based on an analysis of telemetry data received from the first device 202. This can help improve the privacy of user data 208 that is part of the first device data 204 and the backup copy 208. Furthermore, because the first device data 204 and the backup copy 208 are not transmitted to the system 100, and because the size of the telemetry data is small (e.g., in the kilobyte range), the amount of data to be transmitted to the system 100 is minimal.

[0045] In one example, the system 100 may periodically receive telemetry data from the first device 202. For example, after a specific time interval expires, the system 100 may receive a telemetry data set. In addition, the telemetry data set may indicate, for example, operations performed on the first device 202 during the time interval, workload information of the hardware components of the first device 202 during the time interval, a backup policy that is effective during the time interval, or any combination of the foregoing. For example, the zeroth telemetry data set 220 may indicate operations performed, workload of hardware components, or effective backup policies during the time interval between T=0 minutes and T=1 minute, the first telemetry data set 222 may indicate operations performed, workload of hardware components, or effective backup policies during the time interval between T=1 minute and T=2 minutes, etc. The received telemetry data sets may be stored in a data repository 224. The data repository 224 may be, for example, a data lake.

[0046] In one example, to verify the security of first device 202, analysis engine 214 can utilize telemetry data sets that are temporally close to the time of receipt of permission request 212. For example, analysis engine 214 can analyze telemetry data sets received within a first time period prior to receipt of permission request 212. Telemetry data sets received within the first time period prior to receipt of permission request 212 can be referred to as qualified past telemetry data. Consider that the first time period is 5 minutes long and permission request 212 is received at the tth minute from a reference time point. Accordingly, analysis engine 214 can analyze telemetry data sets received between the tth minute and 5 minutes prior to the tth minute. Therefore, if the zeroth telemetry data set 220 is received between the tth minute and 5 minutes prior to the tth minute, the zeroth telemetry data set 220 is part of the qualified past telemetry data and is analyzed by analysis engine 214.

[0047] Instead of or in addition to analyzing qualified past telemetry data, analysis engine 214 may analyze telemetry data sets received within a second time period after receiving permission request 212. Telemetry data sets received within the second time period after receiving permission request 212 may be referred to as qualified future telemetry data. Consider that the second time period is five minutes long and permission request 212 is received at the tth minute from the reference time point. Accordingly, analysis engine 214 may analyze multiple telemetry data sets received between the tth minute and five minutes after the tth minute. Thus, if first telemetry data set 222 is received between the tth minute and five minutes after the tth minute, first telemetry data set 222 is part of qualified future telemetry data and is analyzed by analysis engine 214. Furthermore, if second telemetry data set 226 is received five minutes after the tth minute, analysis engine 214 does not analyze second telemetry data set 226. Analyzing telemetry data temporally proximate to permission request 212 ensures that relevant data is considered for verifying the security of first device 202.

[0048] In one example, the analysis of the telemetry data can include comparing telemetry data that is temporally proximate to the permission request 212 with the rest of the telemetry data received from the first device 202 and stored in the data repository 224. Based on the comparison, if it is determined that there is a significant deviation between the telemetry data that is temporally proximate to the permission request 212 and the rest of the telemetry data, the system 100 can determine that the security of the first device 202 has been compromised.

[0049] In one example, the length of the second time period can be equal to the length of the first time period. In addition, in one example, the lengths of the first time period and the second time period can each be a multiple of the length of the time interval for receiving the telemetry data set from the first device 202. For example, the telemetry data set can be received once a minute, and the first and second time periods can each be five minutes long.

[0050] In one example, system 100 may periodically receive heartbeat messages from first device 202. Heartbeat messages may indicate that first device 202 is operational and may be sent at a higher frequency than telemetry data. Furthermore, if the heartbeat message is received after permission request 212, system 100 may initiate the aforementioned analysis of the telemetry data set. Thus, permission request 212 is processed after ensuring that first device 202 is operational. Thus, the present disclosure prevents waste of resources processing requests corresponding to non-operating devices.

[0051] Telemetry data may be received from the first device 202 regardless of whether a backup-related request is received. In one example, the system 100 may be a system that periodically receives and analyzes at least some portion of the telemetry data described above to identify or predict a failure in the operation of the first device 202. For example, the system 100 may perform an analysis operation on certain portions of the telemetry data, such as workload information of a hardware component, and predict that a component of the first device 202 is about to fail. Since the first device 202 has transmitted at least some portion of the telemetry data described above to the system 100 to identify and predict the failure, the present disclosure ensures that the first device 202 transmits almost no additional data to verify the security of the first device 202 and to process backup-related requests corresponding to the first device 202. Therefore, the techniques of the present disclosure may be implemented with minimal overhead for the first device 202.

[0052] Although the system 100 is described as periodically receiving telemetry data, in one example, another device ( Figure 2 In addition, the system 100 may obtain past telemetry data and / or future telemetry data to be analyzed from other devices in response to receiving a backup-related request.

[0053] Although not shown, the various components of the network environment 200 can communicate with each other via a communication network, which can be a wireless or wired network or a combination thereof. A communication network can be a collection of separate networks that are interconnected and used as a single large network (e.g., the Internet or an intranet). Examples of such separate networks include a Global System for Mobile Communications (GSM) network, a Universal Mobile Telecommunications System (UMTS) network, a Personal Communications Service (PCS) network, a Time Division Multiple Access (TDMA) network, a Code Division Multiple Access (CDMA) network, a Next Generation Network (NGN), a Public Switched Telephone Network (PSTN), and an Integrated Services Digital Network (ISDN). Depending on the technology, a communication network can include various network entities such as transceivers, gateways, and routers.

[0054] Figure 3 FIG3 illustrates a network environment 300 according to an example implementation of the present disclosure, which implements security verification of the first device 202 , thereby permitting execution of backup-related operations. The network environment 300 may correspond to the network environment 200 .

[0055] First device data 204 ( Figure 3302) may be associated with a VM 302 hosted in the first device 202. Furthermore, the second device 206 may include a backup copy 304 corresponding to the VM 302. The backup copy 304 corresponding to the VM 302 may be referred to as a VM backup copy. In the following explanation, the present disclosure is explained with reference to an example in which the backup copy stored in the second device 206 is a VM backup copy.

[0056] The system 100 may receive a permission request 306 to perform a VM backup-related operation, such as modifying or deleting the VM backup copy 304 or creating a new VM backup copy. As described above, in response to receiving the request, the system 100 may analyze the telemetry data of the first device 202 to verify the security of the first device 202. Based on the telemetry data, if the security of the first device 202 is determined to be compromised, in one example, the system 100 may verify the security of the first device 202 by establishing a security handshake with the first device 202.

[0057] The authentication 308 based on the secure handshake involves the system 100 transmitting a message 310 to the first device 202. The message 310 is encrypted using a shared secret key 312 known to the first device 202 and the system 100. The secret key 312 may be stored in a storage device or memory (e.g., a computer program product) of the first device 202. Figure 3 (not shown). If the first device 202 is not infected by ransomware, that is, if the security of the first device 202 is not compromised, the shared secret key 312 can be stored in an unencrypted state on the first device 202. Therefore, the shared secret key 312 is accessible to the first device 202 and is used by the first device 202 to decrypt the message 310. Once decrypted, the first device 202 can send a response 314 to the message 310. In one example, the response 314 can be sent as part of a heartbeat message. Receipt of the response 314 establishes a security handshake between the first device 202 and the system 100. If the security of the first device 202 is compromised, because the malware may already have the encrypted data stored on the first device, the shared secret key 312 can be stored in an encrypted state on the first device 202 and may not be accessible to the first device 202. Therefore, the first device 202 cannot send the response 314 to the system 100. Therefore, the security handshake is not established, and the system 100 determines that the security of the first device 202 is compromised. In one example, the system 100 determines that the security of the first device 202 is compromised in response to not receiving the response 314 within a predetermined transmission period of the message 310 .

[0058] System 100 can grant permission to perform backup-related operations when a security handshake is established, and can deny permission in response to not establishing a security handshake. As indicated by arrow 316, the granting or denial of permission can be sent to the first device 202 or the second device 206. As previously described, the granting of permission can be indicated by a transmission token. After granting permission, the first device 202 can send an execution request 318 to the second device 206. The execution request 318 can include a new VM backup copy, a proposed change 304 to the VM backup copy, or an instruction to delete the VM backup copy 304. Therefore, the verification 308 based on the security handshake serves as the second stage of the security verification of the first device 202. Therefore, the accuracy of the security verification is increased, thereby preventing the backup copy from being unusable.

[0059] Figure 4 and Figure 5 Methods 400 and 500 for permitting the execution of backup-related operations, respectively, are illustrated according to example implementations of the present disclosure. The order in which methods 400 and 500 are described is not intended to be construed as limiting, and any number of the described method blocks can be combined in any order to implement method 400 or an alternative method. Furthermore, methods 400 and 500 can be implemented by (a plurality of) processing resources or computing devices via any suitable hardware, non-transitory machine-readable instructions, or a combination thereof.

[0060] It will be appreciated that the blocks of methods 400 and 500 can be executed by a programmed computing device and can be executed based on instructions stored in a non-transitory computer-readable medium. The non-transitory computer-readable medium may include, for example, a digital memory, a magnetic storage medium (such as a disk and tape), a hard drive, or an optically readable digital data storage medium. Although method 400 can be implemented in a variety of systems, for ease of explanation, method 400 is described with respect to system 100. In one example, method 400 can be executed by a system such as system 100.

[0061] refer to Figure 4 At block 402, a permission request for permission to perform an operation related to a backup copy is received. The backup copy corresponds to first device data stored on a first device. The backup copy may be or may need to be stored on a second device. In one example, the permission request may be a request to modify or delete the backup copy stored on the second device. In another example, the permission request may be a request to create a new backup copy on the second device.

[0062] The permission request may be received, for example, from the first device or the second device and may be, for example, permission request 212 or permission request 306. The first device may be first device 202, the second device may be second device 206, the first device data may be first device data 204, and the backup copy may be backup copy 208. In one example, the first device data belongs to a VM hosted in the first device, such as VM 302. Furthermore, the backup copy includes an image from which the VM can be restored, such as VM backup copy 304. In another example, the first device data belongs to the first device, and the backup copy includes an image from which the first device can be restored to its operating state.

[0063] At block 404, in response to the permission request, telemetry data received from the first device is analyzed to determine whether the security of the first device has been compromised. The telemetry data may indicate operations performed in the first device, workload information of hardware components of the first device, backup policies, or other information such as a reference. Figure 1 and Figure 2 Other data interpreted. In one example, the telemetry data does not include the contents of the backup copy or the contents of the first device data. For example, if the operation related to the backup copy is a backup copy modification operation, the telemetry data may not indicate changes made to the first device data. Furthermore, if the operation related to the backup copy is a backup creation operation, the telemetry data may not include the new backup copy. Similarly, if the operation related to the backup copy is a backup deletion operation, the telemetry data may not include the backup copy to be deleted.

[0064] In one example, as referenced Figure 2 As explained, the telemetry data being analyzed includes telemetry data received during a first time period before receiving the permission request, telemetry data received during a second time period after receiving the permission request, or both. In one example, the telemetry data may be received periodically from the first device. Furthermore, the length of each of the first and second time periods may be a multiple of the length of the interval during which the telemetry data is periodically received from the first device. For example, as described above, the interval length may be one minute, and the first and second time periods may each be five minutes.

[0065] At block 406, in response to determining that the security of the first device has not been compromised, an attempt is made to establish a secure handshake with the first device. The attempt may include transmitting a message encrypted using a secret key known to the first device, such as the shared secret key 312. Figure 3 As explained, if a response to the message is received from the first device, it can be determined that the security handshake has been established.

[0066] At block 408 , in response to the establishment of the secure handshake, permission is granted for execution of operations associated with the backup copy. In one example, permission for execution of the operations includes transmitting a token, such as token 216 , to the first device.

[0067] Figure 5 A method 500 for performing backup-related operations according to an example implementation of the present disclosure is illustrated. The method 500 can be performed, for example, by the first device 202 and the second device 206. In addition, the method 500 can be performed when the first device receives a token from the system.

[0068] In one example, the permission request specifies the name of the first device data or the name of the backup copy. Furthermore, the token may specify the name of the first device data or the name of the backup copy, either of which is specified in the permission request. After receiving the token, at block 502, the first device transmits an execution request, such as execution request 218 or execution request 318, to the second device to perform a backup-related operation. At block 504, the second device may then determine that the token specifies the name of the first device data or the name of the backup copy. Subsequently, the second device may perform the operation related to the backup copy.

[0069] In one example, before performing operations related to backup, at block 506, the second device may send a verification request to the system to verify the token. In response to the system's authentication of the token, at block 508, as described with reference to Figure 2 As explained, the second device determines that an operation may be performed. Subsequently, at block 510, the second device may perform an operation associated with the backup copy.

[0070] Figure 6 A computing environment 600 is illustrated that implements a non-transitory computer-readable medium to permit execution of backup-related operations according to an example implementation of the present disclosure. In one example, the non-transitory computer-readable medium 602 can be used by a system such as system 100. In one example, the computing environment 600 can include a processing resource 604 communicatively coupled to the non-transitory computer-readable medium via a communication link 606. The processing resource 604 can be, for example, the processor 102.

[0071] The non-transitory computer-readable medium 602 can be, for example, an internal memory device or an external memory device. In one example, the communication link 606 can be a direct communication link, such as any memory read / write interface. In another example, the communication link 606 can be an indirect communication link, such as a network interface. In this case, the processing resource 604 can access the non-transitory computer-readable medium 602 via a network 608. The network 608 can be a single network or a combination of multiple networks and can use a variety of different communication protocols.

[0072] The processing resource 604 and the non-transitory computer readable medium 602 may also be communicatively coupled to a first device 610, which may be a computer storing first device data ( Figure 6 ), and storing a backup copy ( Figure 6 The first device 610 and the second device 612 may be the first device 202 and the second device 206, respectively. Further, the first device data and the backup copy may be the first device data 204 and the backup copy 208, respectively.

[0073] In one example implementation, the non-transitory computer-readable medium 602 includes a set of computer-readable instructions for enabling the execution of backup-related operations. The set of computer-readable instructions can be accessed and subsequently executed by the processing resource 604 via the communication link 606.

[0074] refer to Figure 6 In one example, the non-transitory computer-readable medium 602 includes instructions 614 that cause the processing resource 604 to receive a request for permission to delete a backup copy corresponding to first device data. The request can be, for example, permission request 212 or permission request 306. As previously described, the first device data is stored on the first device, and the backup copy is stored on the second device.

[0075] The non-transitory computer readable medium 602 includes instructions 616 that cause the processing resource 604 to analyze the telemetry data received from the first device in response to the request. Figure 2 As explained, the telemetry data being analyzed may be telemetry data received within a first time period before the reception time of the request and telemetry data received within a second time period after the reception time of the request.

[0076] The non-transitory computer-readable medium 602 includes instructions 618 for determining, based on the analysis, whether the security of the first device has been compromised. In response to determining that the security of the first device has not been compromised, instructions 620 for authorizing deletion of the backup copy. Deletion can be authorized, for example, by sending a token (such as token 216) to the first device indicating that permission to delete the backup copy is granted.

[0077] In one example, in response to determining that the security of the first device has not been compromised based on the analysis of the telemetry data, the instructions are executable to transmit a message encrypted using a secret key, such as the shared secret key 312, the secret key being known to the first device. Figure 3 As explained, deletion of the permission is effected in response to receiving a response to the message from the first device.

[0078] In one example, in addition to granting and denying permission to delete backup copies, the instructions may also grant and deny permission to modify backup copies. For example, the instructions may cause a request to modify a second backup copy corresponding to first device data to be received. The second backup copy may, for example, be a backup copy of the first device data created after the backup copy was deleted. In response to determining that the security of the first device has not been compromised, the instructions may grant permission to modify the second backup copy. Similarly, in one example, the instructions may also grant and deny permission to create backup copies.

[0079] The present disclosure can prevent the loss and unusability of backup copies due to malware attacks on computing devices storing parent data. The present disclosure utilizes telemetry data from computing devices that send requests for backup-related operations to determine whether the security of the computing device has been compromised. Therefore, it is not necessary to analyze the details of backup-related operations, such as changes made to backup copies or new backup copies. Therefore, the present disclosure can provide simpler and more efficient determinations related to the security of computing devices. In addition, the present disclosure can utilize telemetry data already received from computing devices to identify and predict failures. Therefore, it may not be necessary to receive additional data from computing devices to implement the present disclosure.

[0080] Because the present disclosure verifies the security of the computing device before allowing changes to the backup copy, the teachings of the present disclosure can be implemented to avoid the use of data immutability features in the backup device to prevent the loss or unusability of the backup copy. Therefore, genuine backup-related operations, such as those initiated by the storage administrator, can be performed.

[0081] Although the implementation of the license for backup-related operations has been described in language specific to structural features and / or methods, it should be understood that the present disclosure is not necessarily limited to the specific features or methods described. Instead, the specific features and methods are disclosed and explained as example implementations.

Claims

1. A system comprising: processor; as well as A non-transitory storage medium comprising instructions executable on the processor, the instructions for: receiving a permission request for permission to operate on a backup copy corresponding to first device data stored in a first device, the backup copy to be stored in a second device; In response to the permission request, analyzing telemetry data received from the first device within a first time period relative to a time of receipt of the permission request; determining, based on the analysis, whether the security of the first device is compromised; Based on a determination that the security of the first device has not been compromised, permitting the operation associated with the backup copy by sending a token from the system to the first device, wherein the token includes a name of the first device data or a name of the backup copy, and the token specifies the operation associated with the backup copy that is permitted; receiving, at the system, the token from the second device, the token being sent from the first device to the second device as part of an execution request from the first device to perform the operation associated with the backup copy, wherein the token from the second device is part of an authentication request requesting the system to verify whether the token is valid, and the authentication request being sent from the second device to the system based on a determination at the second device that the execution request from the first device is consistent with the token; verifying, at the system, the token received from the second device; as well as Upon verifying the token, a response is sent from the system indicating that the token is authentic to permit the second device to perform the operation associated with the backup copy.

2. The system of claim 1, wherein the telemetry data comprises one or more of the following: number of login attempts, number of file encryptions, number of file modifications, number of file deletions, workload information of hardware components of the first device, backup policies, read counts of the first device data, or write counts of the first device data.

3. The system of claim 1 , wherein to analyze the telemetry data received from the first device, the instructions executable on the processor are to: An actual parameter value that is part of the telemetry data is compared to an expected parameter value corresponding to an uncompromised security state of the first device.

4. The system of claim 1 , wherein the instructions executable on the processor are to: Identifying the reception time of the permission request; determining the first time period before or after the reception time of the permission request; As part of the analysis, the telemetry data received from the first device during the first time period is compared to a remainder of the telemetry data received from the first device.

5. The system of claim 1, wherein the operation associated with the backup copy is a backup create operation, a backup modify operation, or a backup delete operation.

6. The system according to claim 1, wherein: Based on determining that the operation specified by the execution request is consistent with the operation specified by the token with respect to the backup copy, the execution request from the first device is determined to be consistent with the token.

7. A method comprising: receiving, by a system including a hardware processor, a request for permission to perform an operation related to a backup copy corresponding to first device data stored in a first device, the backup copy to be stored in a second device; analyzing, by the system in response to the permission request, telemetry data received from the first device to determine whether security of the first device has been compromised; Based on a determination that the security of the first device has not been compromised, permitting the operation associated with the backup copy by sending a token from the system to the first device, wherein the token includes a name of the first device data or a name of the backup copy, and the token specifies the operation associated with the backup copy that is permitted; receiving, at the system, the token from the second device, the token being sent from the first device to the second device as part of an execution request from the first device to perform the operation associated with the backup copy, wherein the token from the second device is part of an authentication request requesting the system to verify whether the token is valid, and the authentication request being sent from the second device to the system based on a determination at the second device that the execution request from the first device is consistent with the token; as well as Upon verifying the token, a response is sent from the system indicating that the token is authentic to permit the second device to perform the operation associated with the backup copy.

8. The method of claim 7, wherein the telemetry data comprises: Telemetry data received during a first time period before receiving the permission request, and telemetry data received during a second time period after receiving the permission request.

9. The method according to claim 7, comprising: Based on determining that the security of the first device has not been compromised, attempting, by the system, to establish a security handshake with the first device, Wherein the permission of the system for the operation related to the backup copy is further based on the establishment of the security handshake.

10. The method of claim 9, wherein attempting to establish the secure handshake comprises: A message encrypted using a secret key known to the first device is transmitted, and the method includes determining that the security handshake is established in response to receiving a response to the message from the first device.

11. The method of claim 7, wherein the operation associated with the backup copy is a backup create operation, a backup modify operation, or a backup delete operation.

12. The method of claim 7, wherein the telemetry data comprises one or more of the following: number of login attempts, number of file encryptions, number of file modifications, or number of file deletions.

13. The method according to claim 7, wherein: Based on determining that the operation specified by the execution request is consistent with the operation specified by the token with respect to the backup copy, the execution request from the first device is determined to be consistent with the token.

14. The method of claim 7, wherein the first device data relates to a virtual machine (VM) hosted in the first device, and the backup copy comprises an image from which the VM can be restored.

15. A non-transitory computer-readable medium comprising instructions executable by a system to: receiving a permission request for permission to operate on a backup copy corresponding to first device data, the first device data being stored in a first device and the backup copy being to be stored in a second device; analyzing telemetry data received from the first device in response to the permission request; determining, based on the analysis, whether the security of the first device is compromised; based on a determination that the security of the first device has not been compromised, permitting the operation associated with the backup copy by sending a token from the system to the first device, wherein the token includes a name of the first device data or a name of the backup copy and the token specifies the permitted operation associated with the backup copy, wherein the token from the second device is part of an authentication request requesting the system to verify whether the token is valid, and based on a determination at the second device that the execution request from the first device is consistent with the token, the authentication request is sent from the second device to the system; verifying, at the system, the token received from the second device; as well as Upon verifying the token, a response is sent from the system indicating that the token is authentic to permit the second device to perform the operation associated with the backup copy. 16 . The non-transitory computer-readable medium of claim 15 , wherein the first device data relates to a virtual machine (VM) hosted in the first device, and the backup copy comprises an image from which the VM can be restored.

17. The non-transitory computer-readable medium of claim 15, wherein the operation associated with the backup copy is a backup create operation, a backup modify operation, or a backup delete operation.

18. The non-transitory computer-readable medium of claim 15, wherein the telemetry data comprises one or more of: a number of login attempts, a number of file encryptions, a number of file modifications, or a number of file deletions.

Images