Evaluate Encryption Strategies for Data at Rest and in Transit
Google Cloud automatically protects data at rest using default encryption, which requires no user setup. This encryption uses the AES-256 algorithm and applies at multiple layers, including the infrastructure, storage device, and backup levels, to provide redundant protection. To manage encryption at scale, Google uses envelope encryption, where a Data Encryption Key (DEK) encrypts each chunk of data and a Key Encryption Key (KEK) encrypts the DEK. Storing the encrypted DEK near the data keeps latency low while the central KEKs remain securely managed in a protected repository.
For organizations that need more control, Customer-Managed Encryption Keys (CMEK) allow you to manage your own keys through Cloud Key Management Service (KMS). This gives you control over the key lifecycle, including rotation and destruction. Key benefits of using CMEK include:
- Administrative Control: You decide the rotation schedule and access policies.
- Auditing: You can track exactly when and how keys are used through logs.
- Compliance: It helps meet regulations that require customer key ownership.
Another option is Customer-Supplied Encryption Keys (CSEK), where you provide your own raw keys for services like Compute Engine. This offers the highest level of control but places a heavy administrative burden because Google does not store these keys. Many organizations now use Cloud External Key Manager (EKM) to keep keys in a third-party system outside Google Cloud while maintaining better availability.
Google also protects data in transit using mutual authentication and encrypted internal communications. The system relies on short-lived tickets to prove that a service is acting on behalf of a specific user, preventing unauthorized access across the network. Choosing the right encryption strategy depends on balancing operational efficiency with compliance needs. Default encryption is best for a fully managed service with no extra cost, while CMEK and CSEK are essential for businesses that must legally prove exclusive control over their cryptographic material.
Manage Cryptographic Key Lifecycles and Access Control
Cloud Key Management Service (Cloud KMS) is the central tool for managing cryptographic keys across Google Cloud. It handles the entire key lifecycle, including creation, use, and eventual retirement. Using a centralized service ensures consistent encryption across different cloud resources. The key lifecycle involves several critical stages:
- Key Creation: Generating new cryptographic material within a specific location.
- Automated Rotation: Periodically creating new key versions to reduce risk.
- Key Retirement: Disabling or destroying keys that are no longer in use.
Properly managing these stages helps prevent long-term exposure if a single key version is compromised.
Identity and Access Management (IAM) enforces the principle of least privilege by granting specific roles at the key or key ring level. For example, the Cloud KMS Admin role allows key maintenance, while the CryptoKey Encrypter/Decrypter role is strictly for using the keys. Assigning permissions at the most granular level reduces the risk of unauthorized access. Key Access Justifications adds an extra layer of security by requiring a reason code for every key access request. This feature works with Access Approval to give organizations full visibility and control over when and why their data is decrypted. For sensitive items like passwords or API keys, Google recommends using Secret Manager instead of Cloud KMS, choosing the right tool for the specific type of sensitive information.
Secret Manager is a centralized service for storing and managing sensitive information like API keys, passwords, and certificates. By using this tool, organizations can decouple sensitive configuration from application source code, keeping credentials out of version control systems. This makes it easier to manage, audit, and secure sensitive metadata across different cloud environments. To protect data at a deeper level, Google uses envelope encryption, where a Data Encryption Key (DEK) is encrypted by a Key Encryption Key (KEK). The Cloud Key Management Service (Cloud KMS) allows users to manage these keys, providing features like Customer-Managed Encryption Keys (CMEK) for greater control.
Controlling who can see secrets is handled through Identity and Access Management (IAM) and the Principle of Least Privilege. Developers should avoid using static keys and instead use Workload Identity or Service Accounts to gain programmatic access to their data. Restricting access to the minimum necessary subset of secrets helps prevent unauthorized users from seeing sensitive data they do not need. Security experts recommend avoiding environment variables or local file systems to store secrets, as these can be easily leaked during an attack. Instead, applications should pull secrets directly from the Secret Manager API using official client libraries. Key administration tasks include:
- Secret Rotation: Periodically updating credentials to reduce the impact of a potential leak.
- Versioning: Using specific version numbers to manage rollbacks and ensure application stability.
- Auditing: Monitoring access logs to see exactly who requested a secret and when.