Whitepaper: Google produced a white paper with some interesting insights to how it addresses security.
Google Apps runs on a technology platform that is conceived, designed and built to operate securely.
Google is an innovator in hardware, software, network and system management technologies.
We custom designed our servers, proprietary operating system, and geographically distributed data centers.
Using the principles of "defense in depth," we’ve created an IT infrastructure that is more secure and easier to manage than more traditional technologies.
Google’s focus on security and protection of data is among our primary design criteria.
Google data center physical security features a layered security model, including safeguards like custom-designed electronic access cards, alarms, vehicle access barriers, perimeter fencing, metal detectors, and biometrics, and the data center floor features laser beam intrusion detection.
Our data centers are monitored 24/7 by high-resolution interior and exterior cameras that can detect and track intruders.
Access logs, 6 7 activity records, and camera footage are available in case an incident occurs. Data centers are also routinely patrolled by experienced security guards who have undergone rigorous background checks and training.
As you get closer to the data center floor, security measures also increase. Access to the data center floor is only possible via a security corridor which implements multifactor access control using security badges and biometrics.
Only approved employees with specific roles may enter. Less than one percent of Googlers will ever step foot in one of our data centers.
Powering our data centers
To keep things running 24/7 and ensure uninterrupted services, Google’s data centers feature redundant power systems and environmental controls. Every critical component has a primary and alternate power source, each with equal power. Diesel engine backup generators can provide enough emergency electrical power to run each data center at full capacity. Cooling systems maintain a constant operating temperature for servers and other hardware, reducing the risk of service outages.
Fire detection and suppression equipment helps prevent damage to hardware. Heat, fire, and smoke detectors trigger audible and visible alarms in the affected zone, at security operations consoles, and at remote monitoring desks.
Custom designed and built hardware and operating systems
Google’s data centers house energy-efficient custom, purpose-built servers and network equipment that we design and manufacture ourselves. Unlike much commercially available hardware, Google servers don’t include unnecessary components such as video cards, chipsets, or peripheral connectors, which can introduce vulnerabilities. Our production servers run a custom-designed operating system (OS) based on a stripped-down and hardened version of Linux.
Google’s servers and their OS are designed for the sole purpose of providing Google services. Server resources are dynamically allocated, allowing for flexibility in growth and the ability to adapt quickly and efficiently, adding or reallocating resources based on customer demand.
This homogeneous environment is maintained by proprietary software that continually monitors systems for binary modifications. If a modification is found that differs from the standard Google image, the system is automatically returned to its official state. These automated, self-healing mechanisms are designed to enable Google to monitor and remediate destabilizing events, receive notifications about incidents, and slow down potential compromise on the network.
Hardware Tracking from acquisition to destruction
Google meticulously tracks the location and status of all equipment within our data centers from acquisition to installation to retirement to destruction, via bar codes and asset tags. Metal detectors and video surveillance are implemented to help make sure no equipment leaves the data center floor without authorization.
If a component fails to pass a performance test at any point during its lifecycle, it is removed from inventory and retired. Google hard drives leverage technologies like FDE (full disk encryption) and drive locking, to protect data at rest. When a hard drive is retired, authorized individuals verify that the disk is erased by writing zeros to the drive and performing a multiple-step verification process to ensure the drive contains no data. If the drive cannot be erased for any reason, it is stored securely until it can be physically destroyed. Physical destruction of disks is a multistage process beginning with a crusher that deforms the drive, followed by a shredder that breaks the drive into small pieces, which are then recycled at a secure facility.
Each data center adheres to a strict disposal policy and any variances are immediately addressed.
The Security of the Network
A global network with unique security benefits Google’s IP data network consists of our own fiber, public fiber, and undersea cables.
This allows us to deliver highly available and low latency services across the globe. In other cloud services and on-premises solutions, customer data must make several journeys between devices, known as "hops," across the public Internet.
The number of hops depends on the distance between the customer’s ISP and the solution’s data center. Each additional hop introduces a new opportunity for data to be attacked or intercepted.
Because it’s linked to most ISPs in the world, Google’s global network improves the security of data in transit by limiting hops across the public Internet.
Defense in depth describes the multiple layers of defense that protect Google’s network from external attacks. Only authorized services and protocols that meet our security requirements are allowed to traverse it; anything else is automatically dropped.
Industry-standard firewalls and access control lists (ACLs) are used to enforce network segregation.
All traffic is routed through custom GFE (Google Front End) servers to detect and stop malicious requests and Distributed Denial of Service (DDoS) attacks.
Additionally, GFE servers are only allowed to communicate with a controlled list of servers internally; this "default deny" configuration prevents GFE servers from accessing unintended resources.
Logs are routinely examined to reveal any exploitation of programming errors. Access to networked devices is restricted to authorized personnel. 8 Google’s IP data network consists of our own fiber, public fiber, and undersea cables.
This allows us to deliver highly available and low latency services across the globe.
Securing data in transit
Data is most vulnerable to unauthorized access as it travels across the Internet or within networks. For this reason, securing data in transit is a high priority for Google. Data traveling between a customer’s device and Google is encrypted using HTTPS/TLS (Transport Layer Security).
In fact, Google was the first major cloud provider to enable HTTPS/TLS by default.
When sending to or receiving email from a non-Google user, all links of the chain (device, browser, provider of the email service) have to be strong and work together to make encryption work.
We believe this is so important that we report on the industry’s adoption of TLS on our safe email site. Google has also upgraded all our RSA certificates to 2048-bit keys, making our encryption in transit for Google Apps and all other Google services even stronger.
Perfect forward secrecy (PFS) minimizes the impact of a compromised key, or a cryptographic breakthrough.
It protects network data by using a shortterm key that lasts only a couple of days and is only held in memory, rather than a key that’s used for years and kept on durable storage.
Google was the first major web player to enable perfect forward secrecy by default. Google encrypts all Google Apps data as it moves between our data centers on our private network.
Low latency and highly available solution Google designs the components of our platform to be highly redundant. This redundancy applies to our server design, how we store data, network and Internet connectivity, and the software services themselves.
This "redundancy of everything" includes the handling of errors by design and creates a solution that is not dependant on a single server, data center, or network connection. Google’s data centers are geographically distributed to minimize the effects of regional disruptions such as natural disasters and local outages.
In the event of hardware, software, or network failure, data is automatically shifted from one facility to another so that Google Apps customers can continue working in most cases without interruption. Customers with global workforces can collaborate on documents, video conferencing and more without additional configuration or expense. Global teams share a highly performant and low latency experience as they work together on a single global network.
Google’s highly redundant infrastructure also helps protect our customers from data loss. For Google Apps, our recovery point objective (RPO) target is zero, and our recovery time objective (RTO) design target is also zero. We aim to achieve these targets through live or synchronous replication: 9
Testing for Zombie Invasion
Google’s data centers are geographically distributed to minimize the effects of regional disruptions such as natural disasters and local outages. Actions you take in Google Apps Products are simultaneously replicated in two data centers at once, so that if one data center fails, we transfer your data over to the other one that’s also been reflecting your actions.
Customer data is divided into digital pieces with random file names. Neither their content nor their file names are stored in readily human-readable format, and stored customer data cannot be traced to a particular customer or application just by inspecting it in storage. Each piece is then replicated in near-real time over multiple disks, multiple servers, and multiple data centers to avoid a single point of failure. To further prepare for the worst, we conduct disaster recovery drills in which we assume that individual data centers — including our corporate headquarters — won’t be available for 30 days. We regularly test our readiness for plausible scenarios as well as more imaginative crises, like alien and zombie invasions.
The above are edited extracts from a Google for Work Security White Paper. The full paper is available here.