How Google's cloud data deletion process can influence security policies

How does Google Cloud data deletion work?

With these facts in mind, let's look at what Google's document, "Data deletion on Google Cloud Platform," actually says.

Google is not alone in making the implementation details of its cloud data deletion available to customers. Amazon, for example, includes some details about data deletion in its "Amazon Web Services: Overview of Security Processes" white paper, while Microsoft spells its out in its "Protecting Data in Microsoft Azure" document. These documents and others like them should be required reading for those that want to take cloud security seriously.

In the white paper, Google describes its deletion process as having four phases. The first phase is the deletion request, in which the user employs either the UI or an API to delete a particular resource, project or account.

The second phase is soft deletion, a 30-day grace period during which the deletion request is recorded. However, during this phase, objects and data can still be recovered if a resource is deleted in error or if the user decides later that he still needs it.

Next is the logical deletion phase, in which the resources are removed from active use. It typically takes about two months for the data to be fully removed.

The last phase, expiration from backup systems, is when the data is removed from backup systems, which typically occurs over about six months. Media is tracked throughout its lifecycle until it is decommissioned and sanitation occurs via overwriting or physical destruction.

One important thing to note is that data is deleted according to two different mechanisms: for example, under "Compute, Storage & Databases, and Big Data except Google Cloud Storage," data is deleted in piecemeal fashion using garbage collection to overwrite data over time.

For cloud storage, data is encrypted using cryptographic erasure. Sometimes referred to as crypto-shredding, this term refers to the deliberate destruction of a key that has been used to encrypt data. Without the key, the data is still there but inaccessible in its encrypted form.

Taking this information forward

This process is fairly straightforward, but reading the white paper will be time well-spent. Informative as it is, though, this information only becomes actionable and truly relevant when evaluated in the context of your individual security program, goals and risk tolerances.

The white paper is particularly helpful when evaluating where there might be differing requirements from those that are provided by default from Google. It can help the security team decide where to take additional measures over and above those provided natively.

For example, the security team might decide that for high-security applications or high-sensitivity workloads, a two-month deletion timeline -- or six months for backups -- is too long based on risk tolerances. Based on this, the enterprise could implement additional controls to take more direct control.

The company might choose to implement encryption measures within an application for PaaS services or at the OS level for compute workloads. If these aren't options, it's possible to move those applications and workloads to a different environment that offers more specialized security functionality or that provides direct control over data deletion.

These decisions should be based on two factors: understanding how cloud data deletion occurs and the processes you should follow -- which Google provides in the white paper -- and understanding information more specific to your organization. Specifically, you must understand the risk assessment, risk mitigation and risk tolerance decisions that your organization makes for cloud usage.

This information, along with other security-relevant information from Google and other cloud providers, can serve as one more proof point for using these measures.