Data security (key management, encryption, secret management)

Evaluate Encryption Strategies for Data at Rest and in Transit

Google Cloud automatically protects your data with default encryption at rest using the AES-256 algorithm before it is written to physical storage. This protection is applied at multiple layers, including the infrastructure, storage devices, and backups, so data is always redundantly safe. To manage encryption at massive scale, Google uses envelope encryption: a Data Encryption Key (DEK) encrypts a chunk of data, and a Key Encryption Key (KEK) encrypts (or "wraps") the DEK. The encrypted DEK is stored near the data to keep latency low, while the central KEKs are kept securely in a protected repository.

For organizations that need more control, Customer-Managed Encryption Keys (CMEK) let you manage your own keys through Cloud Key Management Service (KMS). This gives you administrative control over the key lifecycle, such as setting rotation schedules and access policies, plus full auditing of when and how keys are used. It also helps meet compliance rules that require customer key ownership. A higher-control option is Customer-Supplied Encryption Keys (CSEK), where you provide your own raw keys for services like Compute Engine. However, CSEK places a heavy administrative burden because Google does not store these keys. Many organizations now prefer 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, with short-lived tickets to prove a service is acting on behalf of a specific user. Choosing the right encryption strategy balances operational efficiency with compliance needs. Default encryption is best for a fully managed service with no extra cost or effort. CMEK and CSEK are essential when you must legally prove exclusive control over cryptographic material.

Manage Cryptographic Key Lifecycles and Access Control

Cloud Key Management Service (Cloud KMS) is a central tool for managing cryptographic keys across Google Cloud. It handles the entire key lifecycle: creation, use, automated rotation, and retirement. Using a centralized service ensures encryption is consistent across different cloud resources. The key lifecycle includes several critical stages:

• Key Creation: Generating new cryptographic material within a specific location.
• Automated Rotation: Periodically creating new key versions to reduce the risk of a compromised key.
• Key Retirement: Disabling or destroying keys that are no longer in use.

Properly managing these stages, including rotating certificate authority keys, helps prevent long-term exposure if a single key version is ever 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, working with Access Approval to give full visibility and control over when and why data is decrypted. For sensitive items like passwords or API keys, use Secret Manager instead of Cloud KMS—choosing the right tool for each type of sensitive information is a critical part of security and compliance design.

Secure Application Secrets and Sensitive Metadata

Secret Manager centralizes the storage and management of sensitive information like API keys, passwords, and certificates. By decoupling this sensitive configuration from application source code, you keep credentials out of version control systems and make them easier to manage, audit, and secure across different cloud environments. Secret Manager uses envelope encryption internally: a Data Encryption Key (DEK) is encrypted by a Key Encryption Key (KEK) managed through Cloud Key Management Service (Cloud KMS). This ensures data remains unreadable even if the physical storage device is compromised.

Controlling access to secrets relies on Identity and Access Management (IAM) and the Principle of Least Privilege. Developers should avoid static keys and instead use Workload Identity or Service Accounts to gain programmatic access. Restricting access to the minimum necessary subset of secrets prevents unauthorized users from seeing data they do not need. Security experts recommend avoiding environment variables or local file systems to store secrets, because 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.