Google’s trusted infrastructure

Study guide for Cloud Digital Leader, Unit 5 · Topic 2. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Explain the business value of Google’s defense-in-depth multilayered approach to infrastructure security.

Objectives, quoted from the exam guide:

1. Describe the benefits of Google designing and building its own data centers, using purpose-built servers, networking, and custom security hardware / software.
2. Describe the role of encryption in securing an organization’s data and the ways that it can protect data exposed to risks in different states.
3. Differentiate between authentication, authorization, and auditing.
4. Describe the benefits of using two-step verification (2SV) and IAM.
5. Describe how an organization can protect against network attacks using Google products, including distributed denial-of-service (DDoS) using Google Cloud Armor.
6. Define Security Operations (SecOps) in the cloud and describe its business benefits.

Google's trusted infrastructure

Defense in depth, built by Google and used by you

What Google builds — data centers, servers, chips and boot chains of its own. What protects the data — encryption in all three states, and who holds the keys. Who gets in — authentication, authorization and audit, with 2-step verification and IAM. What stops attacks, and who watches — Cloud Armor at the edge, and security operations behind it.

The previous topic defined the vocabulary of cloud security: zero trust, least privilege, defense in depth. This one shows Google applying it to its own infrastructure, and the guide's summary says so directly: explain the business value of Google's defense-in-depth, multilayered approach to infrastructure security. Google describes that infrastructure as designed in progressive layers, and the six objectives climb them. First, what Google gains by designing its own data centers and hardware. Second, encryption, in every state data can be in. Third and fourth, identity: proving who you are, deciding what you may do, recording what you did, and the two tools the guide names for it — 2-step verification and identity and access management, or IAM. Fifth, network attacks, including distributed denial-of-service, or DDoS, and the product that absorbs them, Cloud Armor. And sixth, security operations — the people and tools that watch everything else. Each layer assumes the one below it has already done its job, and none assumes it is the last line of defense.

What Google builds itself, and what each piece buys

Owning the design means owning the trust at every level

Worked example (synthetic). A bank's risk officer asks how it can trust hardware it never sees. The graded answer is not a contract clause but the design: Google builds the boards, the chips that authenticate them, and the boot chain they run.

The first objective asks for the benefits of Google designing and building its own data centers, servers, networking and security hardware, and Google's infrastructure security paper answers it one layer at a time. The buildings: Google says it designs and builds its own data centers, which incorporate multiple layers of physical security, and access to them is tightly controlled — biometric identification, metal detection, cameras, vehicle barriers and laser-based intrusion detection. The machines: Google designs the server boards and the networking equipment. The chips: it also designs custom security chips that let it identify and authenticate legitimate Google devices at the hardware level and serve as hardware roots of trust. The software as it starts: Google servers use various technologies to ensure that they boot the intended software stack. And the fleet as a whole: the infrastructure is composed of tens of thousands of homogeneous machines, and Google uses more layers of isolation for riskier workloads. The business value is that trust does not depend on a supplier Google cannot inspect. A customer inherits every one of these layers without building any of them.

Security in progressive layers

Each layer is built on the one below, and none trusts it blindly

Figure. Five stacked layers from bottom to top: low-level infrastructure (buildings, hardware and boot), service deployment (isolation between workloads), data storage (encryption at rest and drive cleaning), internet communication (traffic and denial-of-service defense), and operations (software development and staff protection).

Worked example (synthetic). An auditor asks what happens to a failed disk. The answer lives in the data storage layer: the drive is encrypted, and it is cleaned with two independent verifications before it can leave Google's custody.

Google's paper names its layers explicitly: low-level infrastructure, service deployment, data storage, internet communication, and operations. Drawn as a stack, the point of defense in depth becomes visible — every layer is designed on the assumption that something in another layer might fail. The bottom layer is the one the first objective is about: buildings, hardware and boot. Service deployment adds isolation between workloads sharing those machines. Data storage adds encryption at rest and a discipline most customers never think about: before a decommissioned, encrypted storage device can physically leave Google's custody, it is cleaned using a multi-step process that includes two independent verifications. Internet communication is where denial-of-service defense lives, which is Objective 5. And operations covers how Google writes its software and protects its own people, which returns in Objective 4. The rest of this deck walks up this stack.

Encryption in every state data can be in

At rest, in transit, in use — three states, three protections

• At rest: while stored — Google encrypts all customer content by default
• In transit: while moving — protected if communications are intercepted
• In use: while processed — Confidential Computing, in a hardware enclave
• Keys: Google's by default; customer-managed keys give you ownership and control

Worked example (synthetic). A clinic stores scans, sends them to a specialist, and runs an analysis on them. Each step is a different state, and each is protected by a different mechanism — storage, transport, and a trusted execution environment.

The second objective asks for the role of encryption and how it protects data exposed to risk in different states, and Google's Confidential Computing overview lists the states in one place. Encryption at rest protects your data while it is being stored. Encryption in transit protects your data when it is moving between two points. Encryption in use protects your data while it is being processed. The first two are Google defaults. Google encrypts all customer content at rest, without any action required by you, using the Advanced Encryption Standard, AES-256, at the storage layer. And encryption in transit helps protect your data if communications are intercepted while it moves between the end user and Google Cloud, or between two services. The third state is the newest: Confidential Computing is the protection of data in use using a hardware-based trusted execution environment, and Google calls it the last piece of end-to-end encryption. The last question is keys. Google says it owns and manages the keys used in default encryption at rest. An organization that needs to own them instead uses customer-managed encryption keys through Cloud Key Management Service, or Cloud KMS, which Google says gives you ownership and control of the keys that protect your data at rest.

Three states, side by side

What each protects against, and whether you have to do anything

Worked example (synthetic). A candidate is told data is "encrypted by default" and asked what is still exposed. The graded answer is data in use — the one state that needs Confidential Computing.

Side by side, the three states differ in two ways the exam likes to test: what each defends against, and whether anyone has to act. At rest, the risk is storage media in the wrong hands. Google defines encryption at rest as encryption that helps protect data stored on a disk, including solid-state drives, or backup media, and it is on by default. In transit, the risk is interception. Google uses various technologies here, including transport layer security, or TLS, and its own application layer transport security, and it also protects integrity — integrity prevents data you send from being altered while in transit between the source and the destination. That is on by default too. In use is different. Confidential Computing is something a customer chooses, running the workload in a hardware-based trusted execution environment. So when a question says data is encrypted by default and asks what remains exposed, the answer is the state that is not on by default: data while it is being processed.

Who holds the keys

Default encryption and customer-managed keys protect the same data

Figure. Two cards. Google default encryption: all data at rest encrypted with no customer action, keys owned and managed by Google. Customer-managed encryption keys: the same data protected by keys the customer creates in Cloud KMS, which the customer owns and controls. A band beneath says what changes is who controls the key, not whether the data is encrypted.

Worked example (synthetic). A regulator requires a bank to hold the keys to its own data. Default encryption does not satisfy that; customer-managed keys in Cloud KMS do.

This figure prevents the most common wrong answer in this objective, which is to think customer-managed keys encrypt data that would otherwise be unencrypted. They do not. Google encrypts all customer content at rest by default, and it owns and manages the keys used in that default encryption. Cloud Key Management Service, or Cloud KMS, lets you create and manage cryptographic keys for use in compatible Google Cloud services, and customer-managed encryption keys give you ownership and control of the keys that protect your data at rest. So the difference between the two cards is not whether the data is encrypted. It is who controls the key — which is exactly the difference a regulator, or a contract, may care about.

Authentication, authorization and auditing

Who are you, what may you do, and what did you do

Worked example (synthetic). A contractor signs in successfully but cannot delete a dataset, and the deletion attempt is recorded. That is authentication passing, authorization refusing, and auditing keeping the record.

The third objective asks the candidate to differentiate three words that are easy to blur, and each has one Google sentence behind it. Authentication is the process by which your identity is confirmed through the use of some kind of credential — Google's shorter version is that authentication is about proving that you are who you say you are. Authorization is the next question: what may that identity do? Google says authorization for Google Cloud is primarily handled by identity and access management, or IAM, which is a tool to manage fine-grained authorization. And auditing is the record afterwards. Google Cloud services write audit logs that record administrative activities and resource access, and you can use Cloud Audit Logs to answer who did what, where, and when. The three happen in order and none replaces another. Passing authentication grants nothing on its own; being authorized leaves no trace unless it is logged; and a log is only meaningful because the first two established who the actor was.

One request, three checks

Authorization sits between identity and the action; the audit follows

Figure: A flow chart: a person or workload presents a credential and is authenticated; IAM then checks whether it has the required permission; if yes the action is performed, if no it is prevented; either way the event is recorded in Cloud Audit Logs as who, what, where and when.

Worked example (synthetic). A security team wants to know who changed a project's access policy last week. Authentication and IAM are the wrong places to look; the audit logs are where the answer is.

Drawn as one request, the three become a sequence. The caller presents a credential and is authenticated. Then identity and access management, or IAM, decides: Google says that when someone tries to perform an action in Google Cloud — for example, create a virtual machine instance or view a dataset — IAM first checks if they have the required permissions, and if they don't, IAM prevents them from performing the action. Whichever branch is taken, the record is written, and those audit logs help security, auditing and compliance teams monitor data and systems for vulnerabilities or misuse. One practice Google recommends sits exactly on that last arrow: use logs from Cloud Audit Logs to regularly audit changes to your allow policy — the policy that drives the authorization step itself.

2-step verification and IAM

A stolen password is no longer enough, and a signed-in user is not all-powerful

• Accounts are compromised by phishing, social engineering and password spraying
• 2-step verification helps mitigate those threats
• Google recommends phishing-resistant security keys for every account
• IAM then limits what even a verified user can do, action by action

Worked example (synthetic). An employee types their password into a fake login page. With a security key as the second step, the attacker holds a password that does not open the account.

The fourth objective asks for the benefits of the two controls the guide names, which it writes as two-step verification, or 2SV, and IAM. Google's own documents write 2-step verification, and they are precise about the threat it answers: user accounts might be compromised through phishing, social engineering, password spraying, or various other threats, and 2-step verification helps mitigate these threats. Google goes further than recommending a second step; it recommends which kind. The enterprise foundations guidance says to enforce 2-step verification for all user accounts with a phishing-resistant mechanism such as Titan Security Keys. And it recommends enforcing it for everyone, because by enforcing 2-step verification for all users, you avoid the risk of accidentally missing users. That covers the first check — proving who you are. IAM is the benefit on the other side of sign-in, and it is the one Topic 1 introduced as least privilege: identity and access management manages fine-grained authorization, so a verified user can still only do what they have been granted. Together they close both halves of an account takeover. A phished password does not complete a sign-in, and a signed-in account cannot reach beyond its role.

Not every second step is equal

Google moved its own staff from one-time codes to security keys

Figure. Two cards comparing second factors: a one-time code, which is better than a password alone but can still be requested by a fake page; and a security key, which is phishing-resistant and which Google made mandatory for its own employees. A band beneath states Google's recommendation to enforce 2-step verification for all accounts with phishing-resistant keys.

Worked example (synthetic). Asked why a firm with one-time codes was still breached through a fake login page, the graded answer is that the codes were not phishing-resistant; a security key would have been.

The strongest evidence for this objective is what Google does itself. Its infrastructure security paper says that when users sign in, they can use second factors such as one-time passwords or phishing-resistant security keys such as the Titan Security Key. For its own employees, Google chose: to help protect them against sophisticated phishing attempts, it replaced one-time-password second-factor authentication with the mandatory use of security keys. That is the distinction the exam can test. Any second step is better than a password alone, but a one-time code can be typed into a fake page just as a password can, while a security key is designed to resist exactly that. Google's recommendation to customers follows its own practice: enforce 2-step verification for all user accounts with a phishing-resistant mechanism such as Titan Security Keys.

Where Cloud Armor stops a network attack

At the load balancing proxies, before any backend sees the traffic

Figure. Internet traffic, including attack traffic, reaches Cloud Load Balancing with a Cloud Armor security policy applied. Only well-formed requests pass through to two backend services, which read and write application data. A callout notes that attack traffic is dropped at the proxies before any backend sees it.

Worked example (synthetic). A retailer's checkout is flooded on its busiest day. With Cloud Armor on its external load balancer, the flood is absorbed at Google's edge and the checkout servers see only real orders.

The fifth objective asks how an organization protects against network attacks with Google products, including distributed denial-of-service, or DDoS, attacks using Google Cloud Armor. The diagram answers the question of where. Google Cloud Armor helps protect your Google Cloud deployments from threats such as DDoS attacks and application attacks like cross-site scripting and SQL injection. It provides always-on protection from layer 3 and layer 4 volumetric and network protocol-based DDoS attacks, with automated inline mitigations in real time and with no latency impact — and Google is explicit that this protection is for applications or services behind load balancers. The mechanism is the one the diagram draws: Cloud Armor is able to detect and mitigate network attacks in order to allow only well-formed requests through the load balancing proxies. So the backends in the middle of the picture never see the flood. That placement is the business value: capacity to absorb an attack is Google's, not the customer's.

Denial-of-service defense, layer by layer

Google's scale first, then Cloud Armor's policies, then detection

Worked example (synthetic). An item offers "buy more servers" as the answer to a DDoS threat. The graded answer is a layer from this table — absorbing an attack is Google's scale and Cloud Armor's policy, not the customer's capacity.

Defense in depth applies to denial of service as much as to anything else, and Google's own description has several layers. The first is scale: Google says the scale of its infrastructure enables it to absorb many denial-of-service attacks, and that it adds multi-tier, multi-layer protections — when a central denial-of-service service detects an attack, it can configure the load balancers to drop or throttle the traffic. Cloud Armor then adds the customer's own policies. Beyond the always-on network protection, its preconfigured rules add a layer of protection to web applications and services from common internet attacks and help mitigate the OWASP Top 10 risks, and Adaptive Protection guards against application-layer distributed denial-of-service, or DDoS, attacks by analyzing traffic patterns to your backend services and responding to sudden changes. The last layer watches rather than blocks: Security Command Center detects and responds to active threats, including DDoS attacks. No layer is expected to stop everything, which is the whole idea.

Security operations in the cloud

Collect everything, detect what matters, investigate and respond

• Security operations: the core of active defense — detect and respond
• Google SecOps retains, analyzes and searches security telemetry at scale
• It detects threats, investigates cause and scope, and drives remediation
• Benefit: a central view of attacks, going back months or longer

Worked example (synthetic). A breach is discovered in June that began in February. A security operations platform that keeps months of searchable telemetry is what lets the team trace it back.

The last objective asks the candidate to define security operations in the cloud and describe its business benefits. The guide writes Security Operations, or SecOps. Google's framework puts the idea in one line: detect and respond are the functions that make up the core of active defense, which involves identifying and addressing malicious activity. Google's product for it is Google Security Operations, often shortened to Google SecOps; its documentation still sits under a path named for its former name, Chronicle, and its log ingestion interface is still the Chronicle API. Google describes it as a cloud service, built as a specialized layer on top of Google infrastructure, designed for enterprises to privately retain, analyze and search the large amounts of security and network telemetry they generate. It can detect threats, investigate the scope and cause of those threats, and provide remediation. The business benefits follow from that description. Google SecOps centralizes security data and provides enriched logs with timelines. It lets you examine aggregated security information going back for months or longer. And its threat hunting and curated detections let you proactively identify weaknesses in your controls — finding the gap before an attacker does, rather than after.

The security operations lifecycle

Four stages, each feeding the next

Figure: A flow chart of four stages: collection of telemetry, detection by normalizing data and matching it to threat intelligence, investigation through cases, search and context, and response through automated playbooks, with a dotted line from response back to detection.

Worked example (synthetic). A team's alerts sit unread because each one needs manual triage. The stage it is missing is response automation — playbooks — not more collection.

Google describes the platform as letting analysts handle a threat throughout its lifecycle, and the stages are worth knowing by name. Collection brings telemetry in. Detection: the data is aggregated, normalized, and linked to detections and threat intelligence. Investigation: threats are investigated through case management, search, collaboration and context-aware analytics. Response: analysts respond quickly and provide resolutions using automated playbooks and case management. The dotted line back from response to detection is this deck's addition, not Google's wording — it marks that what a team learns from one incident becomes a detection for the next. Security Command Center sits alongside this cycle for Google Cloud itself, as a risk management solution that helps security professionals prevent, detect and respond to security issues. When an exam item describes a team drowning in alerts, find the stage that is missing.

What this topic actually tests

Five discriminations, six objectives

Which state? at rest and in transit are default; in use needs Confidential Computing. Whose key? default encryption is Google's key; CMEK is yours. Which check? authentication proves, authorization permits, auditing records. Which second step? security keys resist phishing; codes do not. Where does Cloud Armor act? at the load balancer, before the backends.

Close on the five discriminations this topic turns on. First, which state of data is exposed: storage and transport are encrypted by default, and processing needs Confidential Computing. Second, whose key: default encryption uses keys Google owns and manages, and customer-managed keys give you ownership and control — the data is encrypted either way. Third, which check: authentication proves who you are, authorization decides what you may do, and auditing records who did what, where and when. Fourth, which second step: any 2-step verification helps, and Google recommends phishing-resistant security keys, the same ones it requires of its own staff. Fifth, where network defense acts: Cloud Armor at the load balancing proxies, so attack traffic stops before any backend sees it. The next topic turns from how Google secures its infrastructure to how it proves it — its trust principles and compliance.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 5
• Google infrastructure security design overview
• Confidential Computing overview
• Default encryption at rest — Google Cloud
• Encryption in transit for Google Cloud
• Customer-managed encryption keys (CMEK)
• Authentication methods at Google
• IAM overview
• Cloud Audit Logs overview
• Enterprise foundations blueprint — Authentication and authorization
• Best practices for federating Google Cloud with an external identity provider
• Google Cloud Armor overview
• Well-Architected Framework — Implement preemptive cyber defense
• Google Security Operations overview
• Cloud Key Management Service overview
• Use IAM securely
• Security Command Center overview