Permissions for backup-related operations

Abstract

A system (100) comprising: a processor (102); and a non-transitory computer-readable storage medium (602) containing instructions (106, 108, 110, 112) that can be executed on the processor (102) to: receive a permission request (212, 306) to enable the performance of an operation with respect to a backup copy (208), wherein the backup copy (208) corresponds to initial device data (204) stored in a first device (202), and wherein the backup copy (208) is to be stored on a second device (206); in response to the permission request (212, 306), analyze telemetry data (220, 222, 226) received by the first device (202) within an initial time interval relative to a time of receipt of the permission request (212, 306); and determine whether a security of the first device has been compromised based on the analysis. is;based on the finding that the security of the first device is not compromised, to enable the operation with respect to the backup copy (208) by sending a token (216) from the system (100) to the first device, wherein the token (216) includes a name of the first device data (204) or the backup copy (208) and the token (216) indicates the operation with respect to the backup copy (208) that is permitted;to receive from the system (100) of the second device (206) the token (216) which was sent from the first device (202) as part of a service request from the first device (202) to perform the operation with respect to the backup copy (208), wherein the token (216) from the second device (206) is part of an authentication request which asks the system (100) to verify that the token (216) is valid, and the authentication request is sent from the second device (206) to the system (100) on the basis of a finding that the service request from the first device (202) is consistent with the token (216); to validate the token (216) received from the second device (206) in the system (100);and based on the validation of the token (216), a response (314) from the system (100) is sent indicating that the token (216) is authentic, in order to enable the second device (206) to perform the operation with respect to the backup copy (208).

Description

BACKGROUNDData stored in a computer may become unusable for various reasons, such as by erasing or damaging the data. To prevent the data from being lost altogether due to non-useability, a back-up copy of the data may be used to restore the data to the computing device. The backup copy may be stored remotely from the computing device, e.g., on a cloud storage device. US 2020 / 0 057 697 A1 describes methods for optimizing crash-proof backup replication. The article by KUR Prabhjeet et al. entitled "Secure VM Backup and VulnerabilityRemoval in Infrastructure Clouds" published in the Proceedings of the 2014 International Conference on Advances in Computing, Communications and Information (ICACCI) 2014" which took place from 24 to 27 September 2014 in Delhi, India (ISBN 978-1-4799-3079-1. DOI: 10.1109 / ICACCI.2014.6968311) describes a VM-SAVER framework with a flexible and scalable virtual machine backup and restore system. US 2018 / 0285207 A1 describes a system for providing a virtual network-accessible folder that makes saved files directly available to users without actually migrating the files into the folder itself. US 2018 / 0 373 877 A1 describes a system for proactively monitoring and detecting anomalies in cloud-hosted user data in order to trigger a multi-level quarantine of the entire user data area and not just individual files. DE 10 2020 101 084 A1 describes a system for improving safety and reliability in multi-node computing platforms by a combination of diverse execution, anomaly detection and dynamic environmental changes. It is an object of the invention to provide a system, method and non-transitory computer readable medium for securely managing backup operations. This object is achieved by a system according to the invention as claimed in claim 1, a method according to the invention as claimed in claim 7 and a non-transitory computer-readable medium according to the invention as claimed in claim 15.BRIEF DESCRIPTION OF THE DRAWINGSThe following detailed description refers to the figures, in which: FIG. 1 illustrates a system that enables backup operations to be performed, according to an example implementation of the present subject matter; FIG. 2 illustrates a network environment in which a system is implemented that enables performing backup operations according to an example implementation of the present subject matter; FIG. 3 illustrates a network environment that implements checking security of a first device to enable performing backup-related operations, according to an example implementation of the present subject matter; FIG. 4 illustrates a method for performing backup operations according to an example implementation of the present subject matter; FIG. 5 illustrates a method for performing backup-related operations according to an example implementation of the present subject matter; and FIG. 6 illustrates a computing environment implementing a non-transitory computer readable medium to enable performance of backup-related operations, according to an example implementation of the present subject matter.DETAILED DESCRIPTIONData stored on a computing device may be rendered unusable, for example, by the presence of malware on the computing device. Ransomware, a type of malware, encrypts files on the computing device, for example, and thus prevents the user from using the files. A key for decrypting the files can be provided to the user against payment of a release money.A back-up copy of the data may be used to restore the data when the data becomes unusable. In some cases, however, the backup copy may also become unusable. This may be the case, for example, if the malware spreads to the backup copy during the execution of backup operations and makes it unusable, for example by changing or erasing the backup copy.The present subject matter relates to permissions for backup-related operations. With the implementations of the present theme, backup copies can be prevented from becoming unusable due to malware attacks.According to an example implementation, a request may be received to enable performance of a backup copy-related operation. A process related to a backup copy may also be referred to as a backup-related process and may include, for example, creating, modifying, or deleting the backup copy. The backup copy may correspond to first device data stored in a first device. In addition, the backup copy may be stored in a 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.In response to receiving the request, the telemetry data received from the first device is analyzed. The telemetry data may include information about the operations performed on the first device. The telemetry data can contain, for example, information about log-in attempts carried out, the number of file encryptions, the number of file deletions, the load parameters of the hardware components of the first device (the hardware components can be, for example, the processor, the working memory and the memory) or any combination of the aforementioned parameters. In one example, telemetry data received within a certain time period is analyzed with respect to the time of the request being received. For example, telemetry data received within a first time period prior to the time of receiving the request, telemetry data received within a second time period after the time of receiving the request, or both, are analyzed. In one example, the analysis of the telemetry data may be performed by a system that periodically receives the telemetry data from the first device to identify or predict the occurrence of an error in the first device.Based on the analysis, it is determined whether the safety of the first device is compromised. The security of the first device can be considered to be endangered, for example, if the number of log-in attempts in a certain period of time is greater than the average number of log-in attempts. When it is determined that the safety of the first device is not compromised, the backup operation may be performed. To enable performance, in one example, a token that grants permission may be transmitted to the first device that may send the token to the second device. Based on the token, the second device may perform the backup operation. If it is determined that the security of the first device is compromised, the request to perform the backup operation is rejected.In one example, to determine whether the first device's security has not been compromised, a secure handshake-based check may be used in addition to the telemetry data analysis. To perform the secure handshake-based check, the system analyzing the telemetry data may also attempt to establish a secure handshake with the first device. In response to the establishment of the secure handshake, the system may determine that the security of the first device is not compromised.The present subject matter can prevent loss or non-useability of a backup copy due to malware attacks on a computing device that stores superordinate data, i.e., the data to which the backup copy corresponds. In this way, the backup copies can be rendered immune to malware attacks on the computing devices storing the parent data. The present subject matter utilizes telemetry data from a computing device that sends a request for the backup operation to determine whether the security of the computing device is compromised. Thus, the present subject matter may enable easier and more efficient determination of the security of the computing device. Moreover, the present subject matter may utilize the telemetry data already received from the computing device to identify and predict errors. Therefore, only a few or no additional data need be provided by the data processing system for implementing the present subject matter.The following description refers to the accompanying drawings. Wherever possible, the same reference numbers will be used in the drawings and the following description to refer to the same or like parts. While several examples are provided in the specification, modifications, adaptations, and other implementations are possible and are to be treated herein.FIG. 1 illustrates a system 100 that enables performing backup copy operations according to an example implementation of the present subject matter. The system 100 may be implemented as a computing device, such as a desktop computer, a laptop computer, a server, or the like. The system 100 includes a processor 102 and a memory 104 connected to the processor 102.The processor 102 may be implemented as a microprocessor, microcomputer, microcontroller, digital signal processor, central processing unit, state machine, logic circuit, and / or any device capable of manipulating signals based on operating instructions. Among other capabilities, processor 102 may fetch and execute computer readable instructions included in memory 104. The computer readable instructions may include instructions 10-1126. The functions of processor 102 may be provided by employing dedicated hardware as well as hardware capable of executing machine readable instructions.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 storage unit, e.g., a flash drive, a compact disk drive, an external hard disk drive, or the like.In addition to the processor 102 and the memory 104, the system 100 may also include one or more interfaces and system data (not shown in FIG. 1 ). The interface(s) may include a variety of instruction-based interfaces and hardware interfaces that enable interaction with a user and with other communication and computing devices, such as network devices, web servers, and external repositories as well as peripheral devices. The system data may serve as memory for data that may be fetched, processed, received, or created by the instructions.In operation, the instructions 106 are executable to receive a request that enables performance of a backup copy operation. A backup copy related process may also be referred to as a backup related process, and may be, for example, a backup copy creation process, a backup copy change process, or a backup copy deletion process. The request may also be referred to as an approval request. The backup copy may correspond to first device data stored in a first device (not shown in FIG. 1 ). The backup copy may be, for example, an exact copy of the data of the first device. The backup copy may be stored in a second device (not shown in FIG. 1 ). In an example, the first device data and the backup copy may include data corresponding to the first device. Furthermore, the backup copy can be an image with which the first device can be reset into its operating state. For example, the first device data and 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 the VM's operating system (OS). Accordingly, the backup copy may be a VM image from which the VM may be instantiated. The permission request may be sent from the first device to the system 100.In response to the request, the telemetry data received from the first device is analyzed. In an example, the telemetry data may indicate the operations performed on the first device, the utilization information of the hardware components of the first device, the number of read data of the first device, the number of written data of the first device, the number of failed attempts to perform a backup-related operation, a backup policy, or a combination thereof. The data may include, for example, the data of the first device. The operations performed on the first device may be, for example, a number of login attempts, a number of file encryptions, a number of file changes, a number of file deletions, or a combination thereof. The information about the load on the hardware components may include, for example, the load on a processor of the first device, the load on a memory of the first device, the input / output operations per second (IOPS) of a memory of the first device, or a combination thereof. The read counter of the data and the write counter of the data indicate how many times the data has been read and written, respectively. The number of failed attempts to perform a backup-related operation helps track previously identified backup problems. An attempt to perform a safety-related process may, for example, fail if the safety of the first device has been impaired, as will be explained later. A backup policy of the first device may indicate a frequency of backup creation (i.e., how often a backup copy is to be created), a backup retention duration (i.e., how long a backup copy is to be retained), and a backup destination (i.e., where a backup copy is to be stored). In one example, the telemetry data may include an identifier of the backup policy instead of the backup policy. In addition, the system 100 may have stored the backup policy and the identifier. Accordingly, upon receiving the identifier as part of the telemetry data, the system 100 may retrieve and analyze the backup policy.In an example, the system 100 may analyze telemetry data received within a first time period (also referred to as a "first time period"). The first period of time may be defined relative to a time at which the request is received. For example, the system 100 may analyze telemetry data received within a first time period prior to the receipt of the request. Instead of or in addition to analyzing the telemetry data received in the first time period prior to receiving the request, the system 100 may analyze telemetry data received in a second time period after receiving the request. The analysis of the telemetry data may be performed when the instructions 108 are executed.The analysis determines whether the safety of the first device is impaired. The security of the first device may be impaired by a malware attack, for example. The determination of the security of the first device is performed when executing the instructions 110. When it is determined that the safety of the first device is not impaired, permission is given to perform the backup operation. To issue the permission, the system 100 may transmit a token indicating the permission to the first device. Permission may be granted when the instructions 112 are executed.FIG. 2 illustrates a network environment 200 in which the system 100 is implemented to enable performance of backup operations, according to an example implementation of the present subject matter. The network environment 200 includes a first device 202. In an example, the first device 202 may be a server computer. In another example, the first device 202 may be a hyperconvergent infrastructure device incorporating computing, storage, and network functions. The first device 202 may be provided at a data center or remote location, e.g., on a rig. First device data 204 may be stored on first device 202. The first device data 204 may include files, folders, or the like. In an example, the first device data 204 may be data corresponding to a VM (not shown in FIG. 2 ) hosted on the first device 202. In another example, the first device data 204 may be data corresponding to the first device 202.The network environment 200 also includes a second device 206 that is to store backup copies of the parent data stored in other devices. For example, the second device 206 may store a backup copy 208 corresponding to the data of the first device 204. Backup copy 208 may include a copy, replica, image, or the like of first device data 204. In an example, backup copy 208 may be an image of the VM hosted in first device 202 and from which the VM may be recovered, or it may be an image from which first device 202 may be recovered. The second device 206 may include a memory (not shown in FIG. 2 ), e.g., a hard disk or a solid state disk (SSD), for storing the backup copies. In one example, the first device 202 may be a border device and the second device 206 may be a core device corresponding to the border device. A core device corresponding to a border device may refer to a device that can receive data from the border device for further processing, instruct the border device to perform a computing task, or both. The core device may have more storage capacity compared to the edge device and therefore store backup copies of the edge device.The first device data 204 may be recovered from the backup copy 208 in the first device 202 when the first device data 204 becomes unusable. The non-usability of the first device data 204 may be due to, for example, damage to a memory (not shown in FIG. 2 ) of the first device 202, accidental deletion, or the like. The non-usability may also be due to a degradation in the safety of the first device 202. For example, the first device 202 may be infected by a ransomware that causes encryption of the data on the first device 202. In some cases, the security impairment of the first device 202 may also affect the backup copy 208. For example, the ransomware that has infected the first device 202 may cause the clearing of the backup copy 208. The ransomware may also effect a backup copy 208 change, e.g., by deleting portions of the backup copy 208, encrypting the backup copy 208, or changing the metadata of the backup copy 208 so that the data of the first device 204 cannot be recovered from the backup copy 208. The ransomware may also cause the creation of an encrypted backup copy on the second device 206 by instructing the second device 206 to store the encrypted backup copy. The key for encryption may be known to the originators of the ransomware, but not to a user of the first device 202. Therefore, the encryption makes the backup copy unusable. The ransomware may also result in a new backup copy being created that replaces (and thus deletes) an undamaged backup copy, such as backup copy 208.To prevent the clearing, changing, or replacing of the backup copy 208 due to a degradation in the security of the first device 202, the first device 202 includes, for example, a backup handling engine 209. In an example, the backup handling engine 209 may be implemented by a processor of the first device 202 by executing a set of instructions (not shown in FIG. 2 ). The backup handling engine 209 receives a request to perform a backup-related operation. The backup management engine 209 may receive the request for the backup-related operation from, for example, a user of the first device 202 or a storage management device 210 that manages storage of backup copies corresponding to the data in the first device 202. In the latter case, the storage management device 21 may send the request based on, for example, a backup policy or an instruction of a storage administrator. In the case of a malware attack on the first device 202, the request may be sent to the backup handling engine 209, for example, from the malware.In one example, the request may indicate a backup operation to be performed. The request may also specify the name of the device data or backup copy corresponding to the backup-related process. For example, the request may indicate that a new backup copy of the first device data 204 is to be created or the backup copy 208 is to be deleted. Upon receiving the request, the backup handling engine 209 sends an approval request to the system 100 to enable performance of the backup-related operation. In one example, the permission request 212 may specify the backup-related operation to be performed and indicate the name of the device data or backup copy, i.e., the first device data 204 and backup copy 208, respectively, or both, according to the backup-related operation. By sending a permission request to the system 100 in response to each received request, the backup handling engine 209 may prevent execution of a malicious request generated by malware. In another example, the permission request 212 may be sent from the second device 206. The second device 206 may send the approval request 212 in response to receiving a request to perform a safety-related operation from the backup handling engine 209. The approval request 212 may be referred to as corresponding to the first device 202 because the first device 202 stores the parent data of the backup copy corresponding to the approval request 212.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.The system 100 includes a backup protection engine 213 that receives permission requests, such as the permission request 212, from computing devices, such as the first device 202, and queues the permission requests. In addition, backup protection engine 213 causes analysis engine 214 to verify the security of a device corresponding to each queued entitlement request. In one example, the backup protection engine 213 and the analysis engine 214 may each be implemented by the processor 102 by executing a set of instructions (not shown in FIG. 2 ).To verify the security of the first device 202, the analysis engine 214 may use the telemetry data sent from the first device 202. The information included in the telemetry data may be used to verify that the first device 202 is subject to malware attack. For example, the number of attempts to log in, which may be part of the telemetry data, may indicate the number of successful and unsuccessful attempts to log in to the first device 202 in a particular period of time. A high number of unsuccessful log-in attempts within a short period of time may indicate an unauthorized attempt to enter the first device 202. A high number of file encryptions within a short period of time may indicate ransomware activities on the first device 202. Similarly, a large number of file changes or deletions, a high load on hardware components, a large number of reads or writes of data, or a large number of failed attempts to perform a backup-related operation may be indicative of ransomware activities. Moreover, a new backup policy, which may be part of the telemetry data indicating reduced backup retention time or increased frequency of backup creation, may also indicate ransomware activities. Accordingly, the analysis engine 214 may verify the security of the first device 202 based on the analysis of the telemetry data.In one example, the 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 may be a predefined range or value that a corresponding portion of the telemetry data should satisfy if the security of the first device 202 is not compromised. For example, if the actual parameter value deviates significantly from the expected parameter value, it may be determined that the safety of the first device 202 is endangered. The expected parameter value may be provided by a user, for example, or determined by the analysis engine 214.To verify the security of the first device 202 from the telemetry data, in one example, the analysis engine 214 may use machine learning techniques, such as a Auto Regressive Integrated Moving Average (ARIMA) linear regression model that may detect anomalies in the received data. The analysis program 214 may monitor the parameters of the telemetry data received in the past and predict an expected parameter value that a corresponding portion of the telemetry data should satisfy. Analyzer 214 may also compare the expected parameter value to a corresponding actual parameter value received as part of the telemetry data. If the actual parameter value received in the telemetry data deviates significantly from the expected parameter value (e.g., if the difference between the actual parameter value and the expected parameter value exceeds a threshold), the analysis program 214 may determine that the safety of the first device 202 is impaired. For example, if the actual number of login attempts is significantly higher than the expected number of login attempts, the security of the first device 202 may be deemed compromised. The analysis engine 214 may also compare the telemetry data received during the previous occurrence of a malware attack with the current telemetry data. If the two sets of telemetry data are similar (e.g., if the difference between the parameter values of the two sets of telemetry data is less than a threshold), analyzer 214 may determine that the security of first device 202 has been compromised. In one example, the analysis engine 214 may compare the backup policy received in the telemetry data with the past telemetry data to identify a suspect backup policy change, such as a decrease in backup retention time or an increase in frequency of backup creation.As mentioned above, the telemetry data may include the count of the read and written data. In one example, the system 100 may analyze the read and write count of the data corresponding to the permission request 212 and may not analyze the read and write count of the other data. For example, since the permission request 212 corresponds to the first device data 204, the system 100 may analyze the read and write counts of the first device data 204 and may not analyze the read and write counts of the other data. In this way, wasteful analysis of the other read and write counts is avoided.After the analysis engine 214 checks the security of the first device 202 from the telemetry data, it may forward the result of the analysis to the backup protection engine 213. Based on the result, the backup protection engine 213 may allow execution of the backup-related operation. For example, if it is determined that the security of the first device 202 is not compromised, the backup protection engine 213 may give the first device 202 permission to perform the backup associated operation by, for example, sending a token 216 to the first device 202. If the security of the first device 202 is compromised, the backup protection engine 213 may deny permission to perform the backup operation by, for example, not sending the token 216 and / or sending a deny message (not shown in FIG. 2 ).In an example, the token 216 may indicate the backup-related operation for which permission is issued and the name of the first device data 204 and / or the backup copy 208 for which the backup-related operation is to be performed. For example, token 216 may indicate that permission to create a new backup copy of first device data 204 or to delete backup copy 208 has been granted. The details of the backup-related process and device data / backup copy to be specified in token 216 may be extracted from permission request 212.Upon receipt of the token 216, the first device 202 may send a power request 218 to the second device 206 to perform the backup-related operation. The power request 218 may include details of the backup-related operation, e.g., a new backup copy to be stored in the second device 206, changes to be made to the backup copy 208, or an instruction to delete the backup copy 208. In addition to the power 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. Additionally, the second device 206 may check whether the token 216 allows performance of the backup operation specified in the power request 218.The second device 206 may also check whether the token 216 indicates the name of the device data or backup copy for which an operation is desired. For example, if the performance request 218 indicates that a new backup copy of the first device data 204 is to be created, the second device 206 may check whether the token 216 allows creation of a backup copy of the first device data 204. The second device 206 thus checks whether the power request 218 matches the token 216. Upon successful verification, the second device 206 performs the backup operation indicated in the power request 218. By indicating the backup operation and the names of the backup copy and / or device data in token 216 and checking token 216 by second device 206, it is ensured that the backup operation performed matches that for which system 100 has granted permission.In one example, instead of or in addition to checking consistency between the power request 218 and the token 216, the second device 206 may determine whether the token 216 is authentic. To make the determination, the second device 206 may send an authentication request to the system 100 and request the system 100 to verify whether the token 216 has been issued by the system 100 and whether the token 216 is valid. Upon receiving the request, the system 100 may verify the authenticity and validity of the token 216. For example, the system 100 may check whether the token 216 has actually been issued by the system 100 and whether the token 216 has been issued in response to a recently made permission request. In response to successful authentication of the token 216, the system 100 may send a message to the second device 206 indicating that the token 216 is authentic. Performing the backup operation after authenticating the token 216 prevents a scenario in which the backup operation is performed based on a counterfeit token created from malware.If the security of the first device 202 is compromised, the backup protection engine 213 may deny permission to perform the backup operation by, e.g., not sending the token 216 and / or sending a reject message (not shown in FIG. 2 ). Accordingly, the first device 202 does not send the power request 218 to the second device 206. Even if the first device 202 sends the power request 218 to the second device 206, the second device 206 refuses to perform the backup associated process because the token 216 is not sent to the second device 206. In another example, after verifying the security of the first device 202, the system 100 may send the token 216 to the second device 206 rather than to the first device 202. Based on the token 216, the second device 206 may perform 218 the backup operation indicated in the power request.Thus, permission to perform the backup-related operation may be granted or denied without having to analyze the contents of the backup copy 208 or the first device data 204. For example, the system 100 does not need to compare a backup copy to be newly created with the backup copy 208. Likewise, the system 100 does not need to process the proposed changes to the backup copy 208 or analyze the actions performed on the first device data 204. Instead, as discussed above, grant and deny permission may be performed based on an analysis of the telemetry data received from the first device 202. This may help improve confidentiality of user data that is part of the data of the first device 204 and backup copy 208. Since the data of the first device 204 and the backup copy 208 are not to be transmitted to the system 100 and the size of the telemetry data is small (e.g., in the range of kilobytes), the amount of data to be transmitted to the system 100 is also minimal.In an example, the system 100 may periodically receive the telemetry data from the first device 202. For example, the system 100 may receive a set of telemetry data upon expiration of a particular time interval. Further, the set of telemetry data may indicate, for example, the operations performed on the first device 202 at this time interval, the loading information of the hardware components of the first device 202 at this time interval, the backup policy applicable at this time interval, or any combination of the foregoing data. For example, a zeroth set of telemetry data 220 may indicate the operations performed in a time interval between T=0 and T=1 minute, the load on the hardware components, or the current backup policy, a first set of telemetry data 222 may indicate the operations performed in a time interval between T=Minute 1 and T=Minute 2, the load on the hardware components, or the current backup policy, etc. The received telemetry data sets may be stored in a data store 224. The data memory 224 may be, for example, a data series.For example, to verify the security of the first device 202, the analysis unit 214 may use the telemetry datasets that are in temporal proximity at the time of receiving the permission request 212. For example, analyzer 214 may analyze the sets of telemetry data received in a first time period prior to receiving permission request 212. The telemetry records received in the first time period prior to the receipt of the permit request may be referred to as 212 historical telemetry data in question. Assume that the first time period is 5 minutes and that the permission request was received th minutes from a reference time point 212. Accordingly, the analysis program 214 may analyze the telemetry data sets received between t th minutes and 5 minutes prior to the t th minute. Thus, if the zeroth telemetry record 220 was received between t th minutes and 5 minutes before the t th minute, the zeroth telemetry record 220 is part of the candidate telemetry data of the past and is analyzed by the analysis unit 214.Instead of or in addition to analyzing the telemetry data in question from the past, the analysis program 214 may analyze the telemetry data sets received in a second time period after the receipt of the permission request 212. The sets of telemetry data received in the second time period after receiving the permit request 212 may be referred to as candidate future telemetry data. Assume that the second time period is 5 minutes and that the permission request was received by t th minutes after a reference time point 212. Accordingly, the analysis program 214 may analyze the telemetry data sets received between t th minutes and 5 minutes after t th minutes. Thus, if the first set of telemetry data 222 is received between the t-minute th and 5 minutes after the t-minute th the first set of telemetry data 222 is part of the future telemetry data in question and is analyzed by the analysis unit 214. When a second set of telemetry data 226 is received 5 minutes after t-minute th the second set of telemetry data 226 is not analyzed by the analysis engine 214. The analysis of the telemetry data in the temporal proximity to the permission request 212 ensures that relevant data is taken into account for the checking of the security of the first device 202.In an example, the analysis of the telemetry data may include comparing the telemetry data in time proximity to the grant request 212 with the remaining telemetry data received from the first device 202 and stored in the data store 224. If it is determined based on the comparison that there are significant differences between the telemetry data in the temporal vicinity of the grant request 212 and the remaining telemetry data, the system 100 may determine that the security of the first device 202 is compromised.In an example, the length of the second time period may be equal to the length of the first time period. In an example, the lengths of the first time period and the second time period may also each be a multiple of the length of the time interval in which the telemetry data sets are received from the first device 202. For example, the telemetry records may be received once a minute and the first and second periods may each have a length of five minutes.In an example, the system 100 may periodically receive a heartbeat message from the first device 202. The heartbeat message may indicate that the first device 202 is operable and may be transmitted at a higher frequency than the telemetry data. Further, the system 100 may initiate the analysis of the telemetry records as discussed above when a heartbeat message is received after the grant request 212. Thus, the permission request 212 is processed after it is ensured that the first device 202 is operable. Therefore, the present subject matter prevents unnecessary agreement of resources for processing a request related to a non-functioning device.The telemetry data may be received by the first device 202 regardless of whether a request for backup has been received. In one example, the system 100 may be a system that periodically receives and analyzes at least some portions of the above telemetry data to identify or predict errors in operation of the first device 202. For example, the system 100 may perform analytical operations on some portions of the telemetry data, such as information about the load on the hardware components, and predict an impending failure of a component of the first device 202. Because the first device 202 already transmits at least some portions of the aforementioned telemetry data to the system 100 for identification and prediction of errors, the present subject matter ensures that only a few, if any, additional data need be transmitted from the first device 202 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 subject matter can be implemented with minimal overhead for the first device 202.Although the system 100 is described as receiving the telemetry data periodically, in one example, another device (not shown in FIG. 2 ) connected to the system 100 may receive the telemetry data. In addition, the system 100 may retrieve the past telemetry data and / or the future telemetry data to be analyzed from the other device when receiving a backup request.Although not shown, the various components of the network environment 200 may communicate with each other via a communication network, which may be a wireless or wired network or a combination thereof. The communication network may be a collection of individual networks that are interconnected and function as a single large network (e.g., the Internet or an intranet). Examples of such single networks are the GSM (Global System for Mobile Communication) network, the UMTS (Universal Mobile Telecommunications System) network, the PCS (Personal Communications Service) network, the TDMA (Time Division Multiple Access) network, the CDMA (Code Division Multiple Access) network, the NGN (Next Generation Network) network, the PSTN (Public Switched Telephone Network) and the ISDN (Integrated Services Digital Network). Depending on the technology, the communication network can comprise different network units, e.g. transmitting and receiving devices, gateways and routers.FIG. 3 illustrates the network environment 300 implementing the security verification of the first device 202 to enable performance of backup-related operations according to an example implementation of the present subject matter. The network environment 300 may correspond to the network environment 200.The data of the first device 204 (not shown in FIG. 3 ) may refer to a VM 302 hosted in the first device 202. Further, the second device 206 may include a backup copy 304 corresponding to the VM 302. Backup copy 304 corresponding to VM 302 may be referred to as a VM backup copy. In the following explanation, the present subject matter will be explained by way of an example in which a backup copy stored in the second device 206 is a VM backup copy.The system 100 may receive an entitlement request 306 to perform a VM backup operation, such as changing or deleting the VM backup copy 304 or creating a new VM backup copy. As discussed 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. If the security of the first device 202 is determined to be intact based on its telemetry data, the system 100 may verify the security of the first device 202 by making a secure handshake with the first device 202.In a secure handshake-based check 308, the system 100 transmits a message 310 to the first device 202. The message 310 is encrypted with a shared secret key 312 known to the first device 202 and the system 100. The shared secret key 312 may be stored in a memory (not shown in FIG. 3 ) of the first device 202. If the first device 202 is not infected with ransomware, i.e., if the security of the first device 202 is not compromised, the shared secret key 312 may be stored in an unencrypted state in the first device 202. Thus, shared secret key 312 is accessible by first device 202 and is used by first device 202 to decrypt message 310. After decryption, the first device 202 may send a response 314 to the message 310. In one example, the response 314 may be sent as part of a heartbeat message. Receipt of the response 314 establishes a secure handshake between the first device 202 and the system 100. If the security of the first device 202 is compromised, the shared secret key 312 may be stored in an encrypted state on the first device 202, as the malicious software may have encrypted data on the first device and is inaccessible to the first device 202. Therefore, the first device 202 cannot send the response 314 to the system 100. Thus, the secure handshake does not occur 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 if the response 314 is not received within a predetermined period of time after the transmission of the message 310.The system 100 may issue permission to perform the backup operation when the secure handshake has been accomplished and deny permission when the secure handshake has not been accomplished. The grant or deny of permission may be sent to the first device 202 as indicated by arrow 316 or to the second device 206. The grant of permission may be indicated by the transmission of a token, as already explained. Upon granting permission, the first device 202 may send a power request to 318 the second device 206. The power request 318 may include a new VM backup copy, proposed changes to the VM backup copy 304, or an instruction to delete the VM backup copy 304. Thus, the secure handshake-based verification 308 acts as a second stage of the verification of the security of the first device 202. In this way, the accuracy of the security check is increased, thereby preventing the non-useability of the security copies.FIGS. 4 and 5 show methods 400 and 500, respectively, that enable backup operations to be performed in accordance with example implementations of the present subject matter. The order in which methods 400 and 500 are described is not intended to be limiting, and any number of the described method blocks may be combined in any order to implement method 400 or alternative methods. Moreover, the methods 400 and 500 may be implemented by (a) processing resource(s) or (a) computing device(s) using suitable hardware, non-transitory machine readable instructions, or a combination thereof.It may be understood that blocks of methods 400 and 500 may be performed by programmed computing devices and may be executed based on instructions stored on a non-transitory computer readable medium. The non-transitory computer readable medium may include, for example, digital memories, magnetic storage media such as magnetic disks and magnetic tapes, hard disks, or optically readable digital data storage media. Although method 400 may be implemented in a variety of systems, method 400 is described with respect to system 100 for ease of explanation. In one example, method 400 may be performed by a system, such as system 100.As shown in FIG. 4, at block 402, a permission request for performing a backup copy operation is received. The backup copy corresponds to first device data stored in the first device. The backup copy may be stored in a second device or must be stored there. In one example, the entitlement request may be a request to change or delete a backup copy stored in the second device. In another example, the entitlement request may be a request to create a new backup copy on the second device.The permission request may be received from, for example, the first device or the second device, and may be, for example, the permission request or 212 the permission request 306. The first device may be the first device 202, the second device may be the second device 206, the first device data may be the first device data 204, and the backup copy may be the backup copy 208. In an example, the first device data refers to a VM, such as the VM,302, hosted in the first device. In addition, the backup copy includes an image from which a VM can be recovered, such as the VM backup copy 304. In another example, the data of the first device relates to the first device and the backup copy contains an image from which the first device can be returned to its operating state.In response to the grant request, the telemetry data received from the first device is analyzed in block 404 to determine whether the first device security is compromised. The telemetry data may indicate the operations performed in the first device, the loading information of the hardware components of the first device, a backup policy, or other data, as discussed in FIGS. 1 and 2. In one example, the telemetry data does not include either the back-up copy content or the first device data content. For example, if the backup copy related operation is a backup copy change operation, the telemetry data may not indicate the changes made to the first device data. If the backup copy operation is a backup copy creation operation, the telemetry data may not contain the new backup copy. If the backup copy operation is a backup copy erasing operation, the telemetry data may not include the backup copy to be erased.In an example, the analyzed telemetry data includes telemetry data received for a first period of time prior to receiving the permit request, or the telemetry data received for a second period of time after receiving the permit request, or both, as discussed with reference to FIG. 2. In an example, the telemetry data may be received periodically from the first device. Further, the length of the first and second periods may be a multiple of the length of an interval in which the telemetry data is periodically received by the first device. For example, the length of the interval may be 1 minute, and the first time period and the second time period may each be five minutes, as discussed above.In response to determining that the security of the first device is not compromised, an attempt is made to establish a secure handshake with the first device at block 406. The attempt may include transmitting a message encrypted with a secret key, such as shared secret key 312, known to the first device. When a response to the message is received from the first device, it may be determined that the secure handshake is established, as explained in FIG. 3.In response to the secure handshake being made, the process related to the backup copy is permitted to be performed at block 408. In one example, permitting the operation to be performed includes transmitting a token, such as token 216, to the first device.FIG. 5 illustrates a method 500 for performing backup operations according to an example implementation of the present subject matter. The method 500 may be performed by the first device 202 and the second device 206, for example. Further, the method 500 may be performed by the first device after receiving the token from the system.In one example, the approval request specifies the name of the first device data or the backup copy. Further, the token may indicate the name of the first device data or the backup copy depending on what was indicated in the approval request. Upon receipt of the token, the first device transmits a power request, such as the power request 218 or the power request 318, to the second device to perform the backup-related operation and the token, at block 502. In block 504, the second device may then determine that the token indicates the name of the data of the first device or the backup copy. Then, the second device can perform the operation with respect to the backup copy.In one example, prior to performing the backup operation in block 506, the second device may send an authentication request to the system to authenticate the token. In response to authentication of the token by the system, the second device determines at block 508 that the process may be performed as explained with reference to FIG. 2. Next, in block 510, the second device may perform the operation related to the backup copy.FIG. 6 illustrates a computing environment 600 implementing a non-transitory computer readable medium to enable performance of backup-related operations according to an example implementation of the present subject matter. In an example, the non-transitory computer readable medium 602 may be used by a system such as the system 100. In an example, computing environment 600 may include a processing resource 604 communicatively coupled to non-transitory computer readable medium 602 via a communication link 606. The processing resource 604 may be, for example, the processor 102.The non-transitory computer readable medium 602 may be, for example, an internal or external storage medium. In an example, communication link 606 may be a direct communication link, such as a memory read / write interface. In another example, communication link 606 may be an indirect communication link, e.g., a network interface. In such a case, the processing resource 60 may 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 use a variety of different communication protocols.The processing resource 604 and the non-transitory computer readable medium 602 may also be communicatively connected to a first device 610, which may be a computing device that stores first device data (not shown in FIG. 6 ), and a second device 612, which stores a backup copy (not shown in FIG. 6 ) corresponding to the first device data. 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 backup copy may be the first device data 204 and backup copy 208, respectively.In an example implementation, non-transitory computer readable medium 602 includes a set of computer readable instructions to enable performance of backup-related operations. The set of computer readable instructions may be accessed by the processing resource 60 4 via the communication link 606 and subsequently executed it.In an example related to FIG. 6, the non-transitory computer readable medium 602 includes instructions that cause the processing resource 60 4 614 to receive a request that allows the backup copy corresponding to the first device data to be deleted. The request can be, for example, the permission request or 212 the permission request 306. As mentioned above, the first device data is stored in the first device and the backup copy is stored in the second device.The non-transitory computer readable medium 602 includes instructions 616 that cause the processing resource 604 to analyze telemetry data received from the first device in response to the request. In an example, the analyzed telemetry data may be the telemetry data received within a first time period before a time of receiving the request and telemetry data received within a second time period after a time of receiving the request, as discussed with reference to FIG. 2.The non-transitory computer readable medium 602 includes instructions 618 that determine whether the security of the first device is compromised based on the analysis. In response to determining that the security of the first device is not compromised, instructions 620 cause the permission to delete the backup copy. The deletion may be permitted, for example, by sending a token, such as token 216, to the first device that indicates the grant of permission to delete the backup copy.In one example, the instructions are executable to transmit a message encrypted with a secret key, such as shared secret key 312 known to the first device, in response to determining that security of the first device is not compromised based on analysis of the telemetry data. Further, the deleting is permitted in response to receiving a response to the message from the first device, as explained with reference to FIG. 3.In one example, the instructions allow, in addition to granting and denying permissions to delete backup copies, also granting and denying permissions to change backup copies. The instructions cause, for example, a request to change a second backup copy corresponding to the first device data to be received. The second backup copy may be, for example, a backup copy of the first device data created after the backup copy is deleted. In response to determining that the security of the first device is not compromised, the instructions may issue permission to change the second backup copy. Similarly, in one example, the instructions may also enable permission to be granted and denied to create backup copies.The present subject matter can prevent loss and non-useability of a backup copy due to malware attacks on a computing device that stores superordinate data. The present subject matter utilizes telemetry data from a computing device that sends a request for the backup operation to determine whether the security of the computing device is compromised. Therefore, the details of the backup operation, such as the changes to be made to the backup copy or the new backup copy, may not need to be analyzed. Thus, the present subject matter may enable a simpler and more efficient determination of the security of the data processing plant. Moreover, the present subject matter may utilize the telemetry data already received from the computing device to identify and predict errors. Thus, no additional data need be received from the data processing system in order to implement the present subject matter.The use of a datauniformity function in a backup device that prevents changes to backup copies to prevent loss or non-useability of the backup copies can be avoided by implementing the teachings of the present subject matter because it checks the security of the computing device before it allows changes to the backup copies. Therefore, true backup-related operations, such as the backup-related operations initiated by a storage manager, may be performed.Although implementations of permissions for backup-related operations have been described in language specific to structural features and / or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed and explained as example implementations.

Claims

A system (100) comprising: a processor (102); and a non-transitory computer readable storage medium (602) having instructions (106, 108, 110, 112) executable on the processor (102) to: receive an admission request (212, 306) to enable performance of an operation relating to a backup copy (208), wherein the backup copy (208) corresponds to first device data (204) stored in a first device (202), and wherein the backup copy (208) is to be stored on a second device (206); in response to the admission request (212, 306), analyze telemetry data (220, 222, 226) received from the first device (202) within a first time period relative to a time of receiving the admission request (212, 306); determining whether security of the first device is compromised based on the analysis; based on determining that the security of the first device is not compromised, enabling the operation related to the backup copy (208) by sending a token (216) from the system (100) to the first device, wherein the token (216) comprises a name of the first device data (204) or the backup copy (208), and the token (216) indicates the operation related to the backup copy (208) that is permitted; from the system (100) of the second device (206) to receive the token (216) sent from the first device (202) as part of a power request from the first device (202) to perform the operation related to the backup copy (208), wherein the token (216) from the second device (206) is part of an authentication request requesting the system (100) to verify whether the token (216) is valid and the authentication request from the second device (206) to the system (100) is sent to the second device (206) based on a determination that the power request from the first device (202) is consistent with the token (216); to validate the token (216) received from the second device (206) in the system (100); and based on the validation of the token (216), send a response (314) from the system (100) indicating that the token (216) is authentic to enable the second device (206) to perform the operation with respect to the backup copy (208).The system (100) of claim 1, wherein the telemetry data (220, 222, 226) comprises one or more of a number of login attempts, a number of file encryptions, a number of file changes, a number of file deletions, first device hardware component utilization information, a backup policy, a first device data read counter (204), or a first device data write counter (204).The system (100) of claim 1, wherein to analyze the telemetry data (220, 222, 226) received from the first device, the instructions (106, 108, 110, 112) are executable on the processor (102) to determine an actual parameter value that is part of the telemetry data (220, 222, 226) with an expected parameter value corresponding to an uncompromised first device security condition.The system (100) of claim 1, wherein the instructions (106, 108, 110, 112) are executable on the processor (102) to: indicate the time of entry of the permission request (212, 306); determine the first time period that is before or after the time of entry of the permission request (212, 306); and as part of the analysis, compare the telemetry data (220, 222, 226) received from the first device (202) within the first time period to a remainder of the telemetry data (220, 222, 226) received from the first device (202).The system (100) of claim 1, wherein the operation related to the backup copy (208) is a backup creation operation, a backup change operation, or a fuse erase operation.The system (100) of claim 1, wherein the determination that the power request from the first device (202) matches the token (216) is based on a determination that an operation specified by the power request matches the operation related to the backup copy (208) specified by the token (216).A method (400, 500) comprising: receiving, by a system (100) having a hardware processor (102), an admission request (212, 306) for admission to perform an operation with respect to a backup copy (208), the backup copy (208) corresponding to first device data (204) stored in a first device (202) and the backup copy (208) to be stored on a second device (206); analyzing, by the system (100), telemetry data (220, 222, 226) received from the first device (202) in response to the admission request (212, 306) to determine whether the security of the first device is compromised; based on the determination that the security of the first device is not compromised, enabling the operation associated with the backup copy (208) by sending a token (216) from the system (100) to the first device, wherein the token (216) comprises a name of the first device data (204) or the backup copy (208), and the token (216) indicates the operation associated with the backup copy (208) that is allowed; receiving, in the system (100), from the second device (206), the token (216) sent from the first device (202) to the second device (206) as part of a power request from the first device (202) to perform the operation associated with the backup copy (208), wherein the token (216) from the second device (206) is part of an authentication request requesting the system (100) to verify whether the token (216) is valid and the authentication request is sent from the second device (206) to the system (100) based on a determination at the second device (206) that the power request from the first device (202) matches the token (216); validating, by the system (100), the token (216) obtained from the second device (206); and based on the validation, by the system (100)s, of the token (216), sending a response (314) from the system (100) to the second device (206) indicating that the token (216) is authentic to enable execution, by the second device (206), of the operation associated with the backup copy (208).The method (400, 500) of claim 7, wherein the telemetry data (220, 222, 226) comprises telemetry data (220, 222, 226) received in a first time period prior to receiving the permit request (212, 306) and telemetry data (220, 222, 226) received in a second time period after receiving the permit request (212, 306).The method (400, 500) of claim 7, comprising: based on the determination that the security of the first device is not compromised, attempting with the system (100) to establish a secure handshake (308) with the first device (202), wherein permission of the operation with respect to the secure copy (208) by the system (100) is further based on establishment of the secure handshake (308).The method (400, 500) of claim 9, wherein attempting to establish a secure handshake (308) comprises transmitting a message (310) encrypted with a secret key (312) known to the first device (202), and wherein the method (400, 500) comprises determining that the secure handshake (308) is established in response to receiving a response (314) to the message (310) from the first device (202).The method (400, 500) of claim 7, wherein the operation related to the backup copy (208) is a backup creation operation, a backup change operation, or a fuse erase operation.The method (400, 500) of claim 7, wherein the telemetry data (220, 222, 226) comprises one or more of: a number of login attempts, a number of file encryptions, a number of file changes, or a number of file deletions.The method (400, 500) of claim 7, wherein the determination that the power request from the first device (202) matches the token (216) is based on a determination that an operation specified by the power request matches the operation related to the backup copy (208) specified by the token (216).The method (400, 500) of claim 7, wherein the first device data (204) relates to a virtual machine VM (302) hosted in the first device (202), and the backup copy (208) comprises an image from which the VM (302) can be recovered.A non-transitory computer readable medium (602) including instructions (614, 616, 618, 620), the instructions (614, 616, 618, 620) executable by a system (100) to: receive a permission request (212, 306) to permit operation associated with a backup copy (208) corresponding to first device data (204), wherein the first device data (204) is stored in a first device (202) and the backup copy (208) is stored in a second device (206); in response to the permission request (212, 306), analyze the telemetry data (220, 222, 226) received from the first device (202); determine whether a security of the first device is compromised based on the analysis; and based on the determination that the security of the first device is not compromised, allowing the operation associated with the backup copy (208) by sending a token (216) from the system (100) to the first device, wherein the token (216) comprises a name of the first device data (204) or the backup copy (208), and the token (216) indicates the allowed operation related to the backup copy (208); in the system, from the second device (206), receiving the token (216) sent from the first device (202) to the second device (206) as part of a power request from the first device (202) to perform the operation associated with the backup copy (208), wherein the token (216) from the second device (206) is part of an authentication request requesting the system to verify whether the token (216) is valid and the authentication request is sent from the second device (206) to the system based on a determination at the second device (206) that the power request from the first device (202) matches the token (216); validating the token (216) received from the second device (206) in the system (100); and based on the validation of the token (216), send a response (314) from the system (100) indicating that the token (216) is authentic to enable the second device (206) to perform the operation with respect to the backup copy (208).The non-transitory computer readable medium (602) of claim 15, wherein the first device data (204) pertains to a virtual machine VM (302) hosted in the first device (202), and the backup copy (208) comprises an image from which the VM (302) can be recovered.The non-transitory computer readable medium (602) of claim 15, wherein the operation related to the backup copy (208) is a backup creation operation, a backup change operation, or a backup erase operation.The non-transitory computer readable medium (602) of claim 15, wherein the telemetry data (220, 222, 226) 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