Google Cloud Platform – Infrastructure and cloud platform security

File Management Commands in Linux

Google is an internet powerhouse and has been building core services and infrastructure, and security has been imperative to Google throughout its journey. Google has security built through layers, from data center security all the way to application and information management. The following diagram gives you a good idea of this layered security approach at Google, along with the different capabilities and features at each layer:

The lowest layer is the hardware infrastructure security, which includes physical security, hardware security, and machine boot stack security. Google designs and fully owns and manages its data centers, and access to these data centers is highly restricted. A fun fact is that Google even uses laser-based intrusion detection systems at their physical data center locations. Google also has some co-location functions hosted at partner data centers, and Google’s physical security standards extend to partner data centers as well. Google hosts thousands of servers at these data centers, and all these servers and pieces of network equipment are custom-designed by Google. Google also designs custom boards, including hardware security chips, that enhance a device’s security. The security boot stack is a system built by Google where cryptographic signatures are used to validate low-level components such as BIOS, bootloader, kernel, and so on. This ensures that any system that may be compromised at that level can quickly be isolated.

As we go up the stack, we have service deployment, where Google deploys and manages services such as an app engine running either Google’s or a customer’s application. Although Google uses ingress and egress firewall filtering to filter traffic, it does not primarily rely on internal network segmentation for security. Google uses cryptographic authentication, which validates authorization at the app layer. Every service is associated with a service account identity, along with cryptographic credentials. The services use these credentials to¬†validate and are only then allowed to make calls to other services. Inter-service access management allows an owner of a service to specify which services are allowed to talk to his service, and this further tightens the access security for your service. Google also provides encryption for all these inter-service calls on the networks. Even if the network is compromised, the messages will mean nothing because of the encryption in place. The access management of end user data allows a service to create an end user permissions ticket, which is used to access another service. This allows a narrow and defined set of access for what the user is trying to do, rather than give full access to the service.

The third layer from the stack allows services such as authentication and login abuse protection. Google offers a range of authentication techniques, which include setting up two-factor authentication to enhance security. Login abuse protection provides best practices that can be enforced on different types of logins, and also remediation and protection methods if logins are compromised.

For storage services, Google provides an Encryption at Rest capability which uses a central KMS to encrypt data, and also allows us to automatically rotate the encryption keys. When a customer wants to delete some data, Google begins that process by first marking that data as scheduled for deletion. This protects the data from accidental deletion and allows for a quick recovery. After a set period of time, set by a service-specific policy, Google permanently deletes the data. If the hard drive needs to be decommissioned, the data is purged in a multi-step process. If the data cannot be properly cleaned, then the hard drive is shredded and destroyed.

While all the layers discussed until now deal with services and infrastructure, with the internet communications layer, we enter the zone that isolates the Google environment from the public internet. Google’s frontend service or GFE allows a service to register to it to get public accessibility. GFE is sort of a gatekeeper that ensures that all TLS communications are terminated using proper certificates. Any service that is published externally uses GFE as a smart reverse-proxy frontend. Google also provides multitier and multilayer denial-of-service (DoS) protection. The DoS service further reduces any attacks on a service running behind GFE. Lastly, Google offers a central identity service, which allows end users to log in and access GCP services.

The last layer of operational security is focused on the different aspects of Google that allow for the secure operation of infrastructure. As part of safe software development, Google provides libraries that prevent developers from using certain classes that can introduce software bugs. Google also uses manual security reviews, from quick triages to in-depth design and implementation reviews. To keep employee devices and credentials safe and to deter phishing, Google has replaced one-time password (OTP) devices with mandatory use of Universal 2nd Factor (U2F)-compatible security keys. Google also logs employee access to end user information through low-level infrastructure hooks, and these logs are actively monitored and investigated.

Comments are closed.