There is one enemy that no software will ever be able to protect itself against—its own users. There is no software on earth that can comprehend the intentions of a user, so there is no software solution to an employee—or any other authorized user of your Software as a Service solution—intentionally seeking to cause harm to your cloud data.
If a disgruntled employee wants to delete or corrupt data to which he or she has been granted legitimate access, there is little to nothing the software can do to stop it, any more than a car can stop a driver from intentionally steering it off a cliff. Fortunately, there are processes and practices you can deploy to prevent a rogue employee from acting on his or her malicious impulses.
Terminate Accounts Before Employees
It’s a simple practice that is far too often ignored: when you opt to terminate an employee, revoke their access to your cloud data before you inform them that their services are no longer required. Nothing motivates a user to damage your systems like a loss of employment; all loyalty evaporates and anger at the loss of the job can make even rational individuals act rashly. Recently terminated users are the last people you want to have unfettered access to your cloud data.
There are documented, step-by-step processes for “deprovisioning” users—but they should all be initiated before the users are themselves dismissed.
Principle of Least Privilege
There’s a very basic and very well-proven concept in security circles known as the principle of least privilege. It means simply giving your employees and users only the barest minimum of access necessary to perform their duties, so that if one of them proves untrustworthy, their potential for damage is as limited as possible. When it comes to cloud applications, this means granting a particular user access only to the data and data-management functions that are strictly required for their jobs.
In practice this can prove tedious, especially in job environments where duties are fluid and data access is necessary for a wide array of tasks and functions. Nonetheless, in an “offline” business, janitors don’t typically have access to cash drawers, and frontline employees don’t typically have access to confidential human resources records. There are obvious parallels when it comes to data within your Software-as-a-Service applications. The principle of least privilege serves to mitigate the damage that a rogue employee can and will inflict if given the chance.
No process is perfect, no prevention infallible. For example, not all employees wait until they are fired to turn rogue. Some plan to defect to your competitor and hope to do unnoticed damage on their way out the door. Others have personal motivations for corrupting or destroying data—anger at a coworker or manager, rather than the organization as a whole. Some simply suffer some sort of psychological break and act out their trauma on your information systems.
Moreover, these pre-termination rationalizations for destroying data can occur in employees who rightfully have broad access to your cloud data. A department manager, or even a member of your information security staff, could be among those you seek to inflict harm on your SaaS data, and thus your business. The principle of least privilege can’t protect you from a rogue employee who has broad privileges as part of their job description.
In these cases, only a cloud to cloud backup can mitigate or reverse the damage caused by a rogue employee. A backup represents a separate copy of your cloud data insulated from the attacks of rogue employees with access to your primary SaaS applications. As such, a backup can restore the data a rogue employee corrupted or purged. A cloud to cloud backup enjoys all the same hardware redundancy, centralized control and web-accessible convenience that benefit your frontline SaaS solutions. As such, a cloud to cloud backup is the fastest, most reliable way to get backup data restored to your SaaS solutions.
A cloud to cloud backup can reverse the damage that even good HR policies and access control practices can’t prevent.
That’s an employee-proof backup plan.