With the step into the public cloud, various security challenges become apparent. Google Cloud sometimes takes the following 5 measures.
Author: Matthias Hert
The step into the public cloud presents companies with new security challenges. Some of these challenges are already being addressed by public cloud providers. In this article we present 5 measures that Google Cloud takes to protect customers and their data.
Infrastructure protection begins with the physical protection of the data centers and extends to the technical protection of the computers on which services and customer workloads are operated (compute) and data is stored (storage).
At the application level, it is all about protecting the business applications themselves. Here it must be ensured that only authorized users have access, but also that individual applications only access the data and other applications that they really need. As a connecting element, the network plays a central role and must be protected accordingly. This applies both within the cloud for connections between services and for connections to on-premise systems or the Internet. In concrete terms, Google Cloud pursues the following measures to protect its own customers and their data.
Known under the name BeyondCorp, Google propagates the Zero Trust Security Model. Zero Trust means that access controls move from the perimeter to the depths of individual users and services. So instead of relying on a single firewall and privileged intranet, each service behaves as if it were potentially exposed to the Internet. In concrete terms, this means that each service is protected by encryption and strong mechanisms for authentication and authorization.
Encryption provides effective protection to prevent unauthorized access to data. A distinction is made whether the data is «at rest», i.e. persisted in a data store, or whether it is «in transit», i.e. moved between the data store and the application. Encryption is possible in both states. In the Google Cloud this is also the standard or it is not possible at all that data is «at rest» unencrypted. In the simplest case keys are used which are automatically generated by Google. But this is only one of several possibilities.
Google Cloud encrypts data automatically. In the simplest case, the keys are generated and managed by Google. If more control over the keys used is desired, there are two options: Customer-managed encryption keys (CMEK) and customer-supplied encryption keys (CSEK). With CMEK, the customer is responsible for generating the keys. However, they are stored in the cloud (e.g. in the Cloud KMS Service) and can be used directly by Cloud Services. In CSEK, the customer is also responsible for managing the keys. This is done on-premise and the keys are only loaded into the cloud when needed and are only stored in main memory. When choosing a solution, it is important to weigh simplicity against control or protection needs.
Two-factor authentication (2FA) is becoming more and more widely used. This involves supplementing the first factor for authentication (password; «know something») with a second factor (token, key or mobile phone; «possess something»). Google offers with the Titan Security Key an easy to use second factor. Inside the key there is a security chip developed by Google itself, which ensures the integrity of the key. The same security chip is also used in the servers of the Google Cloud Infrastructure to prevent deep level compromise and ensure integrity.
The measures taken so far have all related to infrastructure and network. At the application level, Google Cloud offers a range of services to protect content.
For applications that are built as docker containers and stored in the Google Container Registry (GCR), an automatic vulnerability scanning also exists. The containers are checked for vulnerabilities according to the CVE database. In addition, the Binary Authorization feature of the Google Kubernetes Engine (GKE) service ensures that only certain signed Docker Containers can be deployed. This ensures that only appropriately tested and approved versions of an application run in production. This process is shown graphically in Figure 2.
In addition to the measures described here, transparency and trust are also key issues. How can I as a customer be sure that the cloud provider itself is not accessing my content? Google Cloud offers the following services under the keyword «Access Transparency» a solution to this problem. In a first step, Google Cloud employees, e.g. from support, must explicitly submit a request for access. The customer can allow or deny this. Once access has been granted, each action is written in fine granularity to an audit log. Detailed information about the access is recorded, thus ensuring traceability.
The measures described here are all technical in nature. Of course, the contracts and provisions between Google Cloud and its customers also include legal aspects to protect the content. In addition, Google strives to have its efforts verified by third parties through audits and certifications. Specifically, the ISAE 3000 Type 2 Report, which is important for Swiss customers, and the Swiss-U.S. Privacy Shield Framework should be mentioned here.
In this paper only an extract of all measures could be discussed. However, it should have become clear that Google provides effective mechanisms to enable companies to take the step into the public cloud with a clear conscience.
Further links and sources: