StudyCerts
StudyCertsProfessional Cloud Data Engineer
professional-cloud-data-engineer
Advanced
Gauge your current knowledge
Advanced
Gauge your current knowledge
professional-cloud-data-engineer
Gauge your current knowledge
Gauge your current knowledge
Encryption for data in transit protects information as it moves between systems. While Google Cloud automatically encrypts traffic within its own data centers, you are responsible for securing data when it moves externally or to specific managed services. This involves creating secure communication channels.
A primary method is to enforce Transport Layer Security (TLS). For managed database services like Cloud SQL and Spanner, you must explicitly configure client connections to use TLS. For proxy load balancers, such as the Global External Application Load Balancer, you should select HTTPS or HTTP/2 as the backend protocol. This provides end-to-end encryption from the load balancer to your backend instances.
For comprehensive network isolation, you use VPC Service Controls. This service creates a security perimeter around managed services like BigQuery to prevent data leaks. To securely connect into these perimeters from on-premises networks, you use Cloud Interconnect or Cloud VPN. These services establish encrypted tunnels over the internet or dedicated lines, protecting all traffic entering or leaving your cloud environment.
Google Cloud provides different levels of control over encryption keys for data at rest. By default, data is encrypted with Google-managed keys. For more control, you can use customer-managed encryption keys (CMEK). With CMEK, you create and manage the keys in Cloud Key Management Service (Cloud KMS), while Google performs the encryption. This is ideal for meeting compliance requirements. CMEK can protect services like BigQuery datasets, Cloud Storage buckets, and Compute Engine disks.
For the highest level of control, customer-supplied encryption keys (CSEK) allow you to generate and manage keys entirely outside of Google Cloud. You supply these keys when creating resources. However, for new implementations, Cloud External Key Manager (Cloud EKM) is now recommended over CSEK because it supports more services and offers higher availability.
When using CMEK, key location and rotation are important. The key must be stored in the same region as the resource it protects. Enabling automatic key rotation, which happens every 30 days by default, is a security best practice. For data sovereignty, Cloud EKM lets you store key material outside Google Cloud geographically while still using Google services.
To implement CMEK, you use Cloud Key Management Service (Cloud KMS) to create key rings and keys. This gives you control over the key lifecycle, including rotation policies. Choosing between CMEK, automated Cloud KMS Autokey, or CSEK affects your pipeline's cost, complexity, and transparency.
You apply these keys directly to the services in your data pipeline. For example, you can configure CMEK to encrypt Compute Engine persistent disks, BigQuery datasets, and Google Kubernetes Engine (GKE) node boot disks. For a Cloud SQL database, you must grant the Cloud KMS Encrypter/Decrypter role to a dedicated service agent so it can access the key.
Key management requires planning for rotation and regionality. You should set up automatic key rotation in Cloud KMS. Be aware that you must never delete the original key versions, as this would make older backups unusable. Also, a regional resource, like a Cloud SQL instance, can only be encrypted by a key located in the same region.
For strict compliance, Cloud External Key Manager (Cloud EKM) allows keys to be stored externally. You can add advanced controls like Access Transparency to log Google personnel actions, Access Approval to require manual consent for access, and Key Access Justifications to provide a reason for each decryption request. This ensures you remain in ultimate control of your data.