The way we go about data access has shifted. This is due to technology constantly changing. With that, you need to have the right amount of people equally equipped to tackle such challenges. The truth is, not so many people are interested in diving deeper into understanding why things are what they are. This is a problem because, if you can’t get people on the same page, then it allows a weakness that some will take and use to their advantage.
So what can we do to help push for more data protection? Assume the absolute worst. Meaning, not trusting anyone in the first place. It makes sense in real life, so why not do so digitally?
That main concept is where zero trust is starting to make its moment. More than ever, has it been necessary to understand what is truly going on with our data? And who has access to it?
Who else to start building this conversation, other than the tech giant that has made it hard for you to check in anywhere other than your personal verified device?
Google Cloud follows a zero-trust security model, meaning that you need to provide authentication at every access. And the best way to do that is by thinking as it was a castle. ( I didn’t come up with this, google did and it makes sense). Most castles if you think of it historically, focus on the security being at the entrance of the castle. This means the focus of security is on the surrounding areas and establishing a wall that prevents people from infuriating on the inside.
Now if you remember most movies, once you make it past the perimeter, then you can pretty much assume that your castle is taken, and overthrown by the enemy. Zero trust, goes a bit deeper, instead of focusing just on the surrounding areas and the perimeter, it includes more security past the gate, at every hallway, door, entryway, the kitchen the oven, you name it.
In such scenarios, you are preventing and reducing the risk of breaches because, for the most part, you’re saying you’ve identified every area that may cause a leak and secured it.
How Does Zero Trust Differ from Traditional Models?
In traditional models, once you are within the perimeter, you are good. Validation has occurred and there is no second guessing that you are who you say you are. Zero Trust puts a different twist to this, it’s more on not focusing to much on the person per say but the behaviors and the resources they may want to have access to.
The biggest component to think about is = no implicit trust.
Instead, trust is based on the behavior of the users, how they access the resources, and from where. This means you need to define those dynamics from an ABAC and RBAC philosophy.
This is harder than you think it seems. Mostly because it requires defining what that consists of and then establishing code that can help make this more readable to automate based on the actions done by a user.
Access is no longer, assuming you are doing what you said you were going to do at the beginning. Instead, it looks at validation after every session, an interaction that requires authentication.
Benefits of Zero Trust
- Better understanding of the behavior of users and their resources.
- Cost is reduced
- Compliance – from an audit perspective easier to see end to end where controls are in place.
How is it Done?
Google relies heavily on NIST 800-27.
That speaks on the following pillars: Identity, Device, Application, Network and data.
Two components to focus on, which is the functional and the core products to implement Zero trust.
Core components speak on those decision that help grant access to a particular resource, establish communication to the policy administrator on the actions that should happen between the resource and the organization, enabling and close connections to state that access has been verified, and authenticated. If access is good, then they are approved, if not denied.
Functionality is the opposite, its main objective is to automate where feasible, govern and ensure that everything is configured and secured, and monitor for optimization and catching vulnerabilities.
Principles Google follows:
- Assume breach: Deny by default
- If access is needed, individuals should give a valid business justification, along with standards keys followed by standards, and have an understanding of where data is coming from and where it’s going. If someone who is seeking access can’t answer a basic understanding of why the access is needed, then they shouldn’t have access in the first place.
- Always verify: Treat every person as a stranger, and validate everything. It’s easier to impersonate more than you know. Verifying helps keep your butt off the line, at the end of the day this should and always be documented. You want to be the person who did their part, and allow the ball to fall on the other person’s part if the information was not given correctly.
- Never Trust: which speaks on the always verify, just because they have the name or your company in their keys or user account doesn’t mean they should have access. There are laws in place that determine who should have access. All this should be considered before access should be granted.
- Follow Least privilege: Limit access based on business need. Focus on minimum access need to do the job. Access should follow a few different concepts but should be based on JIT – Just In Time, meaning your using it for what you stated you would use it for, within the dedicated time and it follows the companies purpose of use standard.
- Continuous monitoring: Feel like a lot of companies drop the ball here, if you put in all that work, you need to make sure that the current framework is consistent with current trends.
Does this make sense here
It does this by encrypting and managing your end-to-end private network to keep your cloud environment secure. This pretty much simplifies encryption management for organizations by:
- Enforcing TLS (Transport Layer Security) for externally exposed applications and APIs.
- Encrypting all stored data by default reducing the complexity of key management.
- Offering Google-managed encrypted keys which eliminates the need for manual lifecycle management.
All these nuances, help position Google as one of the industry leaders in security by design concepts.
Data Privacy & Shared Responsibility Concepts You need to be aware of
Google has built security into the foundation of its cloud platform, and a big part of that is privacy. As you notice, as tech gets more advanced so will the need to be aware of who is doing what with our data. Which is why Google created services such as access transparency.
Access transparency is a service that Google provides for real-time logs whenever a Google engineer accesses customers’ data.
This is usually necessary when:
A customer is trying to troubleshoot an issue, that is out of control for the user and more towards the platform itself.
In this case, a request is submitted for support, and Google then assigns a resource to help solve the issue. This information should ideally be logged for compliance reasons. It also can be the deal breaker in determining who is accountable for what within the essence of the request.
Most logs are just a snapshot of a series of questions, that someone may ask such as:
- Who accessed what?
- When and why?
- What actions were taken?
This service exists for a reason and that is to eliminate the blind spots and ensure customers always have visibility when Google interacts with their workloads.
But let’s be honest here, transparency is just one part of the layer. The other part is legal. If you are not aware by now, there are contracts in place and legal agreements that companies lock into for these types of protections.
This brings us to the next concept, if a customer is using GCP, then who owns the Data – GCP or The customer?
From the beginning, Google makes it clear that customers own their data. Legally, Google cannot access, use, or sell customer data without consent.
Some of the legal mechanisms that enforce this to happen are:
- Business Associate Agreements (BAAs) -> Required for HIPAA compliance (healthcare).
- Non-Disclosure Agreements (NDAs) -> Preventing unauthorized sharing of customer data.
- Third-Party Compliance Audits -> External assessments to verify data security and privacy in place to ensure that the customer’s data remains protected.
These agreements set clear rules on who can do what with data and reinforce Google’s shared security model – which defines responsibilities between Google and its Customers.
Google’s Shared Responsibility has two key areas that divide who does what.
- Security of the cloud is Google’s responsibility
- This includes:
- Global network security
- Data center security
- Underlying infrastructure
- Default encryption mechanism
- This includes:
- Security in the cloud is the customers of Google ( People using the product)
- This Includes:
- IAM ( Identity & Access Management) – Who can do what
- Firewall configuration – ingress and egress rules
- Data encryption policies – how sensitive data is protected or classified
- Application security
- This Includes:
This applies across different cloud service models as well.
For more details on how that works, here is a sample diagram:
| Service Model | Google’s Responsibility | Customer’s Responsibility |
| Software as a Service (SaaS) | Usage, Deployment, web application security, identity, Operations, Access and Authentication, Network and security, physical hardware | Gmail, Drive |
| Infrastructure as a Service (IaaS) | Auditing logging, network, encryption and storage, hardened Kernel + IPC, Boot Hardware | Guest Os, data & content, network security, access and authentication, identity, operations, web application security, Deployment, Usage, Content, Access Policies |
| Platfoorm as a Service (PaaS) | everything from IaaS + Guest OS, data and content, network security, access & authentication, Operations, identity | Deployment, Usage, Access policies, Content |
The key takeaways here are:
Google focuses on providing a secure foundation, but it’s up to the customer to ensure that configuration and managing their security settings properly based on their needs.
Most recently this model has shifted from shared responsibility to a shared fate. This just means that Google is actively working with customers to help them deploy securely on GCP.
With a shared fate, there is no hardline between who does what. Instead, Google is considered what we call an “active partner” helping customers achieve security by sharing best practices and remaining supportive and active throughout the process.
Cloud Compliance
Privacy and compliance are also major selling points for cloud adoption. Google builds trust by meeting global compliance standards and offering certifications that customers can inherit.
Some major compliance standards include:
- PCI DSS (Payment Card Industry Data Security Standard) – Required for handling credit card transactions.
- ISO 27001, 27017, 27018 – International security and privacy certifications.
- SOC 2 (System and Organization Controls 2) – Security and availability assurance.
- NIST (National Institute of Standards and Technology) – Framework for government and regulated industries.
- Regional Data Protection Laws – Compliance with GDPR (Europe), PDPA (Asia), CCPA (California), etc.
When a customer moves to Google Cloud, whether hosting a single virtual machine or a full enterprise system, they inherit many of Google’s security controls automatically.
But here’s the catch:
Just because Google is compliant doesn’t mean you are. It’s based on your business.
Compliance ≠ Automatic Security
🚫 If you run workloads on Google Cloud, you still need to configure security controls properly.
🚫 Customer workloads, applications, and services are not part of Google’s core infrastructure remember—they’re your responsibility.
This means due diligence is critical. Security and compliance are on you—Google provides the framework, but you have to make sure your workloads align with the necessary regulations for your industry.
Security by Design: Layers of Protection
This is done on multiple layers:
1. Operational Security
Operational security focuses on how Google deploys and maintains its cloud infrastructure securely. This includes:
- Secure software development → Google provides internal tools to prevent vulnerabilities like XSS (Cross-Site Scripting).
- Credential security → Strong identity management for employees and users.
- Intrusion detection → Monitoring for insider threats and external attacks.
- Two-way code reviews → Ensuring only secure, verified software is deployed.
- Automated security testing → Source code is analyzed for vulnerabilities before deployment.
- Manual penetration testing → Google security teams proactively find and fix weaknesses.
- Bug Bounty Program → Google pays researchers to find vulnerabilities in its systems—if you find one, you might even get a job! – NO SERIOUSLY
2. BeyondCorp Enterprise: Zero Trust Security Model
Google operates on a Zero Trust model, known as BeyondCorp Enterprise. This ensures that only the right people get access to the right data at the right time.
- Continuous monitoring of devices and users – Access is verified in real time.
- Regular patching & updates – Google ensures its infrastructure stays secure.
- Strong authentication enforcement – 2FA (Two-Factor Authentication) is required for all critical accounts.
BeyondCorp ensures users get access only when necessary, reducing the risk of privilege misuse and unauthorized access. And I can personally tell you, this is one of the challenges companies face. A lot of individuals believe that they need excessive privilege for the type of work they are doing. But when you add business justification and reasoning behind each action, you realize a lot of individuals really don’t need that much access. Understanding a least privilege principle helps with that.
Network Security: No Public Internet Exposure
One of the biggest advantages of Google Cloud’s network is that once traffic enters Google’s infrastructure, it no longer travels across the public internet. This reduces the risk of:
✅ Man-in-the-middle attacks
✅ Data interception
✅ Traffic manipulation
Simply put, Google’s private, global infrastructure ensures customer traffic stays protected.
Google Front Ends (GFEs): Securing Public-Facing Services
When a service in Google Cloud needs to be accessible from the internet, it registers with Google Front Ends (GFEs). Which handles the following:
- TLS termination – Ensuring traffic is encrypted with the correct certificates.
- Perfect Forward Secrecy (PFS) – Making sure encryption keys aren’t reused, reducing the risk of compromised keys.
- DDoS mitigation – Acting as a first line of defense against Distributed Denial-of-Service (DDoS) attacks.
In short, GFEs serve as Google’s secure entry points, ensuring only trusted connections reach cloud workloads.
DDoS Protection: Multi-Tier & Multi-Layer Defense
Google Cloud doesn’t rely on just one layer, instead, it uses a multi-tiered, multi-layered approach to shield workloads from massive-scale attacks.
Here is how it works:
- Traffic is filtered at the edge – Before reaching workloads, traffic is screened for malicious patterns.
- Rates are limited & any anomaly is detected – This is done by monitoring spikes in traffic that indicate DDoS attempts.
- Global load balancing – Traffic is distributed across multiple regions to prevent overloading a single location.
If an attack happens, Google’s automated systems identify, filter, and neutralize the threats before they reach the target service.
User Authentication: Risk-Based Access Controls
This is done by strong authentication before granting access to the GCP network. All focused on risk-based authentication to determine whether additional security measures are needed.
✅ Factors that influence authentication challenges are:
- IP address – Is the login coming from a known or unusual location?
- Device location – Is the login coming from an expected country or region?
- User behavior – Is the access attempt consistent with previous logins?
When Google detects a risk, it prompts for a second authentication factor (such as a security key or mobile verification) before granting access. You may have seen this plenty of times when you try to log on to your Google account from different devices.
If the system is not used to the type of device you are using, it will prompt you for another form of verification. Now, we are starting to see where Google has started implementing checkboxes for users to be able to state that the device can be trusted. Most are still timebound. I am sure they heard many of our complaints and this is a form that doesn’t compromise the integrity of the system.
Data Security: Encryption at Rest & In Transit
Google Cloud follows a default encryption policy, ensuring that both data at rest and in transit are protected automatically.
🔹 Data in transit (in motion) – Secured using TLS encryption while moving between systems.
🔹 Data at rest – Encrypted by default, without requiring customers to configure anything.
For customers needing more control, Google offers additional encryption options:
✅ Default encryption – Handled by Google with automatic key rotation.
✅ Cloud Key Management Service (KMS) – Customers can generate, manage, and rotate their own encryption keys.
✅ Customer-Supplied Encryption Keys (CSEK) – Customers bring their own keys, giving them full ownership.
Regardless of which option you choose, you own and control your data—Google does not have access to your encryption keys unless you explicitly grant it.
Data Security: Protection Throughout the Data Lifecycle
Data security is about ensuring that data remains secure at every stage of its lifecycle—from creation to deletion. No matter where data is in the process—creation, sharing, storage, analysis, archiving, or deletion.
So what happens when someone needs to stop using GCP?
If you delete sensitive data stored on Google Cloud, how do you know it’s gone?
When data is deleted, it’s not immediately removed from Google’s infrastructure. Instead, it is marked as scheduled for deletion—this is a safety mechanism in case of accidental deletion. Once scheduled for deletion, the data is permanently removed according to Google’s data retention policies. This is due to legal and contractual requirements for data retention, which vary by service and industry.
Service Identity & Access: Beyond Network-Based Security
Google enforces authentication and authorization at the application layer before granting access to any service. This means that even if a network is secured by firewalls, VPCs, and perimeter-based security controls, Google still applies an additional layer of verification.
This follows Google’s Zero Trust model, where no implicit trust (remember future) is granted—every request must be verified and authenticated before access is approved.
Some of the core service identity techniques include:
- Cryptographic authentication – Verifying service identities using cryptographic credentials.
- IAM-based controls – Role-based permissions to limit access to sensitive services.
- Isolation & sandboxing – Applying multiple isolation techniques to protect workloads running on shared infrastructure.
Speaking of sandboxing, here are some common techniques used:
- Language-based sandboxing – Restricts what applications can do based on the programming language they use.
- Kernel-based sandboxing – Isolates processes within the operating system to prevent unauthorized access.
- Hardware virtualization – Separates workloads at the hardware level to enforce strict access boundaries.
- Linux user separation – Uses OS-level security mechanisms to isolate workloads running on shared systems.
These layered security controls ensure that even if a malicious actor gains access to a network, they still need to pass multiple authentication and authorization checks before being able to do anything meaningful.
Threat & Vulnerability Management
Google’s Vulnerability Management Program is designed to proactively detect, assess, and mitigate security threats. This includes:
- Technical controls and automated threat detection
- Manual and automated penetration testing
- Security assurance programs
- Automated source code scanning and manual code reviews
If a security vulnerability is identified, it is managed, contained, and controlled immediately. The issue is then prioritized based on severity and assigned to the appropriate team. The goal is efficiency—getting security issues to the right people as quickly as possible to prevent delays in resolution.
Malware Protection & Incident Response
Google has automated and manual malware detection tools that monitor for malware infections and suspicious activity across its cloud infrastructure.
For incident response, Google follows the NIST SP 800-61 framework, which many organizations also adopt for handling security incidents. But just like most, this is just a guide to help you understand the baselines that should be followed. In turn, google follows the same approach
but follows these key stages when it comes to incidents in their platforms:
- Identification → Detecting and reporting security threats
- Coordination → Triaging issues and engaging the right teams
- Resolution → Investigating, containing, recovering, and communicating findings
- Closure → Conducting post-incident analysis to prevent future issues
- Continuous Improvement → Enhancing security processes based on lessons learned
Google’s Security Response Team operates 24/7, ensuring continuous monitoring and response to security threats.
Final thoughts
This post was just the starting point—a high-level look at Google Cloud Security to lay the foundation for what’s ahead.
For the exam and training, you will need to understand how Google approaches security as a whole before diving into the specifics. This part was written to be easy to digest, breaking down the core areas without overloading you. Here is what we covered:
- Operational Security – How Google secures its own environment.
- Data Security – How data is protected at every stage.
- Service & Identity Controls – Who has access and how it’s managed?
- Low-Level Security Mechanisms – The extra layers that keep everything locked down.
- Incident Response – the process of how operates and measures/responds to security threats.
