India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Google Cloud Security, IAM & Data Protection Services
Google Cloud security and identity is the set of controls that decide who can act on which resource, how keys and secrets are held, and how data is fenced from exfiltration. NTSPL designs IAM hierarchies, Cloud KMS and Secret Manager patterns, VPC Service Controls perimeters and Cloud Armor policies for Indian firms facing DPDP Act, CERT-In and RBI audits.
Google Cloud services in scope
The Problem Identity and Access Management (IAM) with Workload Identity Federation and Cloud KMS, Cloud HSM and Cloud External Key Manager Solve
Most Google Cloud breaches we investigate are not exotic. They start with a service account key committed to a repository, a project-level Editor grant given to an intern two years ago, or a BigQuery dataset that can be copied to any project in the world because no VPC Service Controls perimeter exists. Google's resource hierarchy makes these mistakes easy to repeat: a role granted at a folder silently flows to every project below it, and a single allUsers binding on a Cloud Storage bucket exposes data to the internet. The real problem is not missing tools; it is uncontrolled inheritance, long-lived credentials and an absent data boundary.
NTSPL starts with the organization node, not the workload. We read the existing IAM policy export and Cloud Asset Inventory, flag every basic role, user-managed key and public binding, then rebuild the hierarchy as folders per environment and business unit with Organization Policy constraints applied at the top. Workloads move to Workload Identity Federation, keys move into Cloud KMS with Autokey or Cloud HSM, and sensitive datasets are placed inside VPC Service Controls perimeters run in dry-run mode for two weeks before enforcement.
When Google Cloud IAM, VPC Service Controls and Cloud Armor Are the Right Fix (and When They Are Not)
Signals that point to security & identity on Google Cloud
- A Cloud Asset Inventory export shows more than a handful of principals holding roles/owner or roles/editor at project or folder level.
- You hold personal data of Indian users at scale and must demonstrate DPDP Act 2023 safeguards, including purpose-limited access and breach detection.
- CERT-In asks for logs from the last 180 days during an incident and you cannot produce Admin Activity and Data Access audit logs for all projects.
- Your web tier sees bot traffic above 30 percent of requests, or account-takeover attempts spike during sales and campaigns.
- An enterprise or BFSI customer's security questionnaire demands CMEK, key rotation evidence and data exfiltration controls before signing.
- You are merging projects from an acquisition or a shadow-IT Google account into one governed organization.
When a different approach is better
- If you only run a few Google Workspace users and a static website, a full VPC Service Controls programme is overkill; a hardened Cloud Storage bucket behind Cloud CDN with Organization Policy defaults is enough.
- If your primary need is a 24x7 security operations centre with threat hunting and SOAR playbooks, Security Command Center alone is not a SIEM; pair it with Google Security Operations or your existing SIEM.
- If the workload runs mostly on-prem with only backups in Google Cloud, invest first in on-prem identity hardening and Backup and DR vault isolation rather than perimeter design.
Google Cloud Security Building Blocks: IAM, Cloud KMS, Secret Manager, Cloud Armor and Security Command Center
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Identity and Access Management (IAM) with Workload Identity Federation | Grants predefined or custom roles at organization, folder and project level, and lets GitHub Actions, GitLab, AWS or on-prem workloads exchange their own OIDC or SAML tokens for short-lived Google credentials. | Your Cloud Asset Inventory shows user-managed service account keys older than 90 days or CI pipelines authenticating with JSON key files. |
| Cloud KMS, Cloud HSM and Cloud External Key Manager | Holds customer-managed encryption keys (CMEK) for BigQuery, Cloud SQL, Cloud Storage and persistent disks, with Cloud HSM for FIPS 140-2 Level 3 protection and Cloud EKM for keys held outside Google. | An auditor, regulator or enterprise customer asks who controls the encryption keys and how quickly access to data can be revoked. |
| Secret Manager | Stores API keys, database passwords and signing certificates as versioned secrets with per-secret IAM, regional replication policies and rotation notifications through Pub/Sub. | Credentials live in environment variables, Kubernetes ConfigMaps or Terraform state files. |
| Google Cloud Armor | Applies WAF rules, preconfigured OWASP rule sets, rate-based bans, Adaptive Protection and reCAPTCHA-based bot management at the external Application Load Balancer edge. | Origin logs show credential stuffing, scraping or Layer 7 floods that your application cannot distinguish from real users. |
| Security Command Center | Aggregates misconfiguration findings, vulnerability findings, threat detections such as Event Threat Detection, and attack path simulation across the organization. | Security teams have no single view of public buckets, open firewall rules and anomalous IAM grants across dozens of projects. |
| VPC Service Controls | Draws a service perimeter around projects so that Google-managed APIs such as BigQuery and Cloud Storage reject requests from outside the perimeter, even with valid credentials. | A stolen credential could otherwise copy a production dataset to an attacker-owned project. |
| Organization Policy Service | Enforces guardrails such as resource location restrictions, disabled service account key creation, domain-restricted sharing and no default network across every project under a node. | You need to guarantee by construction that no team can create resources outside asia-south1 and asia-south2 or share data with external Gmail accounts. |
Zero-trust landing zone with data perimeter for India regions
Zero-trust landing zone with data perimeter for India regions
A user or workload authenticates through Cloud Identity or Workload Identity Federation, reaches the application through Cloud Armor and Identity-Aware Proxy, and the application reads sensitive data only from inside a VPC Service Controls perimeter using CMEK keys. Every call is written to audit logs routed to a locked log bucket in asia-south1 and analysed by Security Command Center.
Select any component
Zero-trust landing zone with data perimeter for India regions: click any of its 11 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Identity and Data-Perimeter Decisions: Resource Hierarchy, Key Elimination, CMEK Tiers and Perimeter Rollout
Resource hierarchy and where roles are granted
We build folders by environment first (prod, non-prod, sandbox) and business unit second, because Organization Policy and VPC Service Controls are usually environment-scoped. Roles are granted to Google Groups, never individuals, and at the lowest level that works. Basic roles (Owner, Editor, Viewer) are removed everywhere except a monitored break-glass group. For teams above about 50 engineers, we add IAM deny policies at the folder to block destructive permissions such as resourcemanager.projects.delete regardless of what is granted below.
Eliminating service account keys
Every CI/CD system that supports OIDC moves to Workload Identity Federation with attribute conditions on repository, branch or environment claim. GKE workloads use Workload Identity Federation for GKE, and Cloud Run uses its attached service account. Only after all callers are migrated do we enforce iam.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyUpload. For legacy on-prem tools that cannot do OIDC, we allow one key per tool, stored in Secret Manager, with a 30-day rotation alert from Security Command Center.
Key management tier: Google default, CMEK, Cloud HSM or EKM
Google default encryption is adequate for logs and non-sensitive assets. CMEK in Cloud KMS is our default for PII, financial and health data because it gives revocation and an audit trail of decrypt calls. Cloud HSM is chosen when a contract or regulator names FIPS 140-2 Level 3. Cloud EKM is reserved for organizations that must hold keys outside Google; it adds latency and an availability dependency, so we only apply it to a narrow set of datasets and test the external manager's failure mode.
VPC Service Controls rollout without breaking pipelines
Perimeters fail closed, so we always start in dry-run mode and read the violation logs for at least two business cycles, including a month-end batch. Typical surprises are Looker Studio connectors, Terraform runners outside the perimeter and partner SFTP projects. Each is solved with a named ingress or egress rule, not by adding services to the bridge. We use one perimeter per sensitivity tier, not per team, to keep the rule count under control.
Cloud Armor policy design for login, search and checkout
We separate policies by backend service so that a strict rule for the login path does not throttle catalogue pages. Login and OTP endpoints get rate-based bans keyed on IP and a header such as a device ID, plus reCAPTCHA action tokens. Search gets throttling rather than bans so real users degrade gracefully. Adaptive Protection runs in alert mode first; we only auto-deploy its suggested rules once false positives stay under about 0.1 percent of legitimate requests.
How NTSPL Builds a Governed Google Cloud Organization with a Data Perimeter
IAM and asset baseline
Export organization IAM policies and Cloud Asset Inventory, then rank basic-role grants, external members, public bindings and user-managed keys by blast radius.
Folder hierarchy and Organization Policy
Recreate folders per environment and business unit in Terraform and apply location, key-creation, domain-restricted sharing and default-network constraints at the top node.
Workload Identity Federation cutover
Move CI/CD, GKE and on-prem callers to federated identity one by one, disable unused keys for two weeks, then enforce the key-creation block.
CMEK and Secret Manager migration
Create key rings in asia-south1 and asia-south2 in a dedicated security project, re-encrypt PII stores with CMEK and move every credential into Secret Manager.
VPC Service Controls dry run and enforcement
Run perimeters in dry-run mode across a month-end cycle, resolve each violation with a named ingress or egress rule, then enforce.
Edge policy and detection wiring
Deploy Cloud Armor rules in preview mode, enable the locked audit-log sink for CERT-In retention and route Security Command Center high-severity findings to ticketing.
What you receive
Threat Model for Google Cloud Identities: Leaked Keys, Inherited Grants and API Exfiltration
The threat model here centres on credential misuse rather than infrastructure compromise: leaked service account keys, over-privileged human accounts, OAuth consent abuse and insiders exporting data through legitimate APIs. Google Cloud's answer is short-lived federated credentials, deny policies that override grants, VPC Service Controls that ignore credentials from the wrong context, and CMEK so that disabling a key renders data unreadable even to someone holding valid IAM permissions.
- IAM deny policies to block high-risk permissions irrespective of inherited grants
- Privileged Access Manager for just-in-time, approval-gated elevation to production roles
- Domain-restricted sharing constraint so data cannot be shared with personal Gmail accounts
- Data Access audit logs enabled for BigQuery, Cloud Storage and Cloud SQL in PII projects
- Event Threat Detection findings for anomalous IAM grants and service account self-investigation
Google Cloud Security Billing: SCC Tiers, KMS Operations, Cloud Armor Requests and Data Access Log Volume
Security spend on Google Cloud is driven by a few meters: Security Command Center tier (Standard is no-cost, Premium and Enterprise are subscription or usage based), Cloud KMS key versions and cryptographic operations, Cloud HSM key versions, Cloud Armor policies, rules and requests processed, and Cloud Logging ingestion for Data Access logs. Data Access logs on a busy BigQuery project can become the single largest line item if left unfiltered.
- Enable Data Access logs only on PII projects and use exclusion filters for high-volume read-only service accounts
- Use CMEK with software keys for most datasets and reserve Cloud HSM for named regulated data
- Choose Cloud Armor Standard per-policy pricing for low-traffic apps and evaluate Cloud Armor Enterprise once you need Adaptive Protection on many backends
- Route audit logs to a log bucket rather than BigQuery unless you query them weekly; enable Log Analytics on the bucket instead of a duplicate export
- Start Security Command Center on Standard and move to Premium when attack path simulation and compliance reporting are needed
VPC Service Controls vs IAM vs firewall rules: which one actually stops data exfiltration on Google Cloud?
They solve different layers, and only VPC Service Controls addresses API-level exfiltration. Identity: IAM decides whether a principal may call bigquery.tables.export; if an attacker steals that principal's token, IAM says yes. Network: VPC firewall rules and Cloud NGFW govern packets between VMs; they do not see calls to Google-managed APIs like BigQuery or Cloud Storage, which travel to Google endpoints. Context: VPC Service Controls checks where the request comes from and where data is going, so a valid token used from outside the perimeter, or a copy to a project outside it, is refused. Use IAM for least privilege, firewall rules for east-west traffic, and VPC Service Controls around every project that holds PII or financial data.
Key facts about security & identity on Google Cloud
Security & Identity on Google Cloud in Practice
3 security & identity scenarios from Education technology, Financial services, digital lending, Online classifieds marketplace: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
EdTech platform puts 4.2 million student records inside a DPDP-ready data perimeter
Digital lending app removes 96 service account keys ahead of its NBFC partner's RBI audit
Classifieds marketplace cuts scraper traffic 81 percent with Cloud Armor and reCAPTCHA
Accounting SaaS makes ledger backups immune to admin compromise with locked vaults
Aerospace components maker protects its PLM vault with 1-hour restore points
Security & Identity on Google Cloud: Frequently Asked Questions
How is Google Cloud security priced, and what will NTSPL's work add to my bill?
Most of the platform controls, including IAM, Organization Policy, VPC Service Controls and Security Command Center Standard, carry no direct charge. Costs appear in Cloud KMS and Cloud HSM key versions and operations, Cloud Armor policies and requests, Security Command Center Premium or Enterprise, and Cloud Logging ingestion for Data Access logs. For a mid-size estate of 30 to 60 projects, NTSPL typically sees incremental run cost of roughly INR 40,000 to 1.5 lakh per month, dominated by logging and Cloud Armor.
Does Google Cloud help us comply with the DPDP Act 2023?
Google Cloud gives you the controls, but compliance is your obligation as a Data Fiduciary. Organization Policy can restrict resources to asia-south1 and asia-south2, CMEK supports erasure by key destruction, Sensitive Data Protection discovers personal data, and audit logs evidence who accessed it. NTSPL maps each DPDP obligation, such as reasonable security safeguards and breach intimation, to a specific control and evidence source so your DPO can answer the Data Protection Board with facts.
We have hundreds of service account keys in use. How do we migrate without outages?
Migrate caller by caller, then enforce. NTSPL uses the service account key usage insights and Policy Analyzer to find which keys are actually used and by what. CI systems move to Workload Identity Federation, GKE to Workload Identity Federation for GKE, and on-prem tools to federation through your IdP where possible. Unused keys are disabled for two weeks before deletion. Only after usage reaches zero do we enable the Organization Policy that blocks new key creation.
What logs do we need to keep for CERT-In, and where should they live?
CERT-In's April 2022 directions require ICT system logs to be retained securely for a rolling 180 days within Indian jurisdiction and incidents to be reported within six hours of noticing them. NTSPL configures an organization-level aggregated sink to a log bucket in Mumbai with retention of 180 days or more and bucket lock, plus Security Command Center notifications so the six-hour clock starts from a real alert, not a customer complaint.
Can Cloud Armor stop scraping and fake account creation, or do we need a separate bot vendor?
For most Indian consumer apps, Cloud Armor with reCAPTCHA bot management covers the bulk of the problem. reCAPTCHA scores each session, and Cloud Armor rules can allow, throttle, redirect to a challenge or deny based on that score at the load balancer. Dedicated bot vendors still help where attackers emulate full mobile app sessions, but we recommend proving the Cloud Armor baseline first because it removes a second CDN hop.
Should we use Cloud HSM or Cloud External Key Manager for RBI-regulated data?
Start with Cloud HSM unless policy requires keys to sit outside Google. Cloud HSM keeps keys in FIPS 140-2 Level 3 validated hardware in India regions with the same API as Cloud KMS. Cloud EKM keeps keys in your own or a partner's key manager, which gives the strongest separation but makes every decrypt depend on that external system's availability and latency. NTSPL usually limits EKM to the most sensitive datasets.