Ensuring data protection

Sensitive Data Protection

Sensitive Data Protection (SDP), formerly Cloud DLP, discovers, classifies and transforms sensitive data in Cloud Storage, BigQuery, Cloud SQL, Datastore, text, structured data and images.

Inspect

• infoTypes are detectors. Built-in ones cover credit card numbers, national IDs, emails, phone numbers, credentials and more. Add custom infoTypes from a dictionary or regex, plus hotword rules (boost or reduce likelihood near a word) and exclusion rules (ignore known false positives).
• A likelihood threshold (VERY_UNLIKELY to VERY_LIKELY) trades false positives against misses. You can sample large tables or objects to cut cost.
• Run as a content request (small inline text or image, synchronous, ideal for APIs and chat redaction) or as a job over storage (asynchronous) with actions that save findings to BigQuery, publish to Pub/Sub, send to Security Command Center, or tag in Data Catalog / Dataplex.
• Templates (inspect and de-identify) hold reusable configuration. Job triggers run on a schedule.
• Discovery (data profiling) continuously scans an organisation, folder or project and generates data profiles for BigQuery, Cloud SQL, Cloud Storage and others, giving sensitivity and data risk scores, with no job to write. Profiles can feed SCC findings and tags.

De-identify

Keys for crypto-based methods are a KMS-wrapped key (or plain base64 key, not recommended) and an optional tweak/context. Pseudonymization means replacing identifiers with tokens, and if you need to reverse it, use FPE or deterministic encryption. If you need irreversibility, use hashing, masking or redaction. Risk analysis (k-anonymity, l-diversity, k-map, delta-presence) measures re-identification risk of a de-identified table.

Typical architectures: a Dataflow pipeline that de-identifies streaming data before it lands in BigQuery, a Cloud Run service that calls the DLP API to redact chat text, or an image redaction call for scanned forms.

Restricting access to data services

BigQuery

• IAM at the project, dataset, table and view level, plus row-level access policies (filter rows per principal) and column-level security using policy tags from a Data Catalog taxonomy (users need Fine-Grained Reader on the tag). Dynamic data masking shows a hash, null or default value to users without the unmasked role.
• Authorized views and datasets expose a subset without giving access to the base tables.
• CMEK for datasets or tables, VPC Service Controls perimeter, and audit logs for queries.
• Keep public access off: the org policy iam.allowedPolicyMemberDomains stops allUsers and outside domains from being granted.

Cloud Storage

• Uniform bucket-level access (IAM only, no object ACLs) and public access prevention (enforced by org policy storage.publicAccessPrevention).
• Signed URLs (time-limited, V4 up to 7 days) and signed policy documents grant temporary access to specific objects without IAM.
• Retention policy and Bucket Lock (irreversible) for WORM, object holds, object versioning, and soft delete (7 days by default) to recover deletions.
• Default CMEK on the bucket, VPC-SC perimeter, and Data Access audit logs.

Cloud SQL (and other databases)

• Private IP only and the org policy sql.restrictPublicIp. If a public IP exists, restrict authorised networks (sql.restrictAuthorizedNetworks) or, better, use the Cloud SQL Auth Proxy or connectors (IAM-authenticated, TLS to the instance).
• IAM database authentication for users and service accounts instead of stored passwords. Enforce SSL/TLS (ssl_mode, require trusted client certificates for the strictest mode).
• CMEK, automated backups in the same protection, and Cloud SQL audit logging (pgAudit for PostgreSQL, audit plugin for MySQL) for query-level records.

Secret Manager

Secret Manager stores API keys, passwords and certificates. Know the model:

• A secret holds versions. Access is by version (latest or number). Versions can be disabled, destroyed (with optional delayed destroy) and the secret can have a TTL or expiry.
• Replication: automatic or user-managed (pick regions for residency). CMEK is supported.
• IAM at secret level: secretmanager.secretAccessor reads values, secretmanager.viewer sees metadata only, secretmanager.admin manages. Give accessor to the workload’s service account on the specific secret.
• Rotation: configure a rotation schedule that publishes to a Pub/Sub topic, where your function creates a new version. Secret Manager doesn’t rotate third-party credentials by itself.
• Audit: Admin Activity logs are always on. Enable Data Access logs to record AccessSecretVersion calls.
• Mount secrets in Cloud Run and GKE (Secrets Store CSI driver) rather than passing them as environment variables in plain text or in code and images. Don’t store secrets in instance metadata, startup scripts or source control.

Compute instance metadata

• The metadata server (metadata.google.internal, 169.254.169.254) requires the header Metadata-Flavor: Google, which stops simple SSRF. Block application SSRF further by disallowing server-side fetches of that address.
• A VM’s attached service account token is available to anything running on it. Limit damage with least-privilege SAs per workload.
• GKE: use Workload Identity Federation for GKE so Pods don’t reach the node service account, and the metadata server is replaced by a GKE metadata server.
• OS Login (compute.requireOsLogin) ties SSH access to IAM (compute.osLogin, osAdminLogin) and supports 2SV, replacing shared SSH keys in project metadata. Also set block-project-ssh-keys and disable the serial port (compute.disableSerialPortAccess).
• Don’t put secrets in custom metadata or startup scripts, because anyone with compute.instances.get sees them.

Encryption at rest and in transit

Default encryption

All data in Google Cloud is encrypted at rest by default with AES-256, with no setup. Data is split into chunks, each encrypted with a data encryption key (DEK). DEKs are wrapped by a key encryption key (KEK) held in Google’s internal Keystore, and the KEK is rotated regularly. This is envelope encryption.

In transit: traffic from users to Google front ends uses TLS. Between Google services inside the infrastructure, ALTS authenticates and encrypts RPCs. VM-to-VM traffic in a VPC is encrypted at the network layer on physical links crossing boundaries. For your own requirements (certificates, mTLS between services, customer-controlled TLS versions), configure TLS on load balancers or use service mesh.

Key management options

Cloud KMS concepts:

• Key rings (location, can’t be deleted) contain keys with versions. Keys have a purpose: symmetric encrypt/decrypt, asymmetric sign or decrypt, or MAC.
• Protection levels: SOFTWARE (FIPS 140-2 Level 1), HSM (Cloud HSM, Level 3), EXTERNAL and EXTERNAL_VPC (Cloud EKM).
• Autokey automatically creates and assigns CMEKs when users create supported resources (a key handle model), following your key-ring layout. Good answer for “CMEK everywhere without a ticket queue”.
• Roles: cloudkms.admin manages keys but cannot encrypt or decrypt; cryptoKeyEncrypterDecrypter uses them. Keep these separate. Service agents of the data service need the encrypter/decrypter role on the key (cross-project is common: key in a security project).
• Keep keys in a separate project owned by security, with the same location as the data.
• Direct KMS encrypt is limited to small payloads (64 KiB). For bigger data use envelope encryption (a client library such as Tink generates a DEK, KMS wraps it).
• Org policies: gcp.restrictNonCmekServices (require CMEK for listed services) and gcp.restrictCmekCryptoKeyProjects (keys only from approved projects).
• Cloud KMS audit logs: Admin Activity always, Data Access for encrypt/decrypt calls if enabled.

Rotation, revocation and import

• Automatic rotation for symmetric keys: set a rotation period (for example 90 days). A new version becomes primary and old versions stay available for decryption. Rotation does not re-encrypt existing data for most services, so data stays under the old version until rewritten. Re-encrypt if policy says old versions must go.
• Asymmetric keys do not auto-rotate. You rotate by creating a new version.
• Version states: pending generation, enabled, disabled, scheduled for destruction (default 30 days, can be set from 24 hours at key creation), destroyed. Disabling or destroying a key version is the revocation mechanism: data protected by it becomes unreadable (crypto-shredding). Within the scheduled period you can restore.
• Key import (BYOK): create an import job (wrapping key, RSA 3072 or 4096), wrap your key material locally and import as a new version. Imported keys must be rotated manually. Use for “must generate keys on-premises”.
• Key Access Justifications (with EKM) attaches a reason code to every external key request, and the external key manager can approve or deny.

Software versus hardware keys

Applying encryption to use cases

Cloud Storage lifecycle

Lifecycle rules apply actions to objects that match conditions:

• Actions: Delete, SetStorageClass (move to Nearline, Coldline, Archive), AbortIncompleteMultipartUpload.
• Conditions: age, createdBefore, isLive (current vs noncurrent version), numNewerVersions, matchesStorageClass, daysSinceNoncurrentTime, customTimeBefore.
• Use for retention and deletion requirements (delete personal data after N days), cost control, and cleaning old object versions. A retention policy blocks deletion until the age is met and wins over a lifecycle delete. Autoclass moves objects automatically by access pattern.

Confidential Computing

Confidential Computing protects data in use by encrypting memory with hardware keys the host cannot read.

• Confidential VMs: AMD SEV, SEV-SNP, and Intel TDX, on selected machine families. No application changes. Org policy compute.restrictNonConfidentialComputing forces them.
• Confidential GKE Nodes, Confidential Dataflow, Dataproc (Managed Service for Apache Spark), and Confidential GPU for AI.
• Confidential Space: a hardened VM image with remote attestation so multiple parties can pool data and only an approved workload image can access it. Combined with Workload Identity Federation attestation conditions.
• Shielded VMs are different: secure boot, vTPM and integrity monitoring protect against boot and kernel tampering, not memory snooping.

Securing AI workloads

Threats and controls

Google’s Secure AI Framework (SAIF) frames these as extending standard security to AI.

IaaS-hosted versus PaaS-hosted training

Gemini Enterprise Agent Platform controls

The Gemini Enterprise Agent Platform (formerly Vertex AI; Vertex AI Studio is now Agent Studio) covers training, deployment, models and agents. The security controls to know:

• Use a custom service account per training job, pipeline or endpoint, with least privilege. Avoid the default service agent’s broad access.
• CMEK for datasets, models, training and endpoints, and VPC Service Controls to keep data and models inside a perimeter.
• Private networking: private endpoints with Private Service Connect or private services access, no public IP on training and Workbench instances, and Workbench hardening (no root, idle shutdown, private IP).
• Org policy can limit which models may be used (for example Model Garden access constraints) and where resources run.
• Data governance: customer data is not used to train foundation models without permission. Prompt and response logging is opt-in, so enable audit logging and apply Model Armor where needed.
• Apply the same IAM, audit logging, Access Transparency and data residency controls as other services.

Choosing the data control

Common traps

• CSEK covers only Compute Engine disks and Cloud Storage.
• Rotating a key does not re-encrypt old data.
• Key admin and key user must be different roles.
• Key ring and key location should match the data location.
• A DLP content call is synchronous and size-limited. Use jobs for big stores.
• Hashing is irreversible, so it fails any “restore original values” requirement.
• Secret Manager needs accessor on the secret, not project-wide admin.
• Destroying a key is irreversible after the scheduled period.