Common controls for generative AI use cases

Google Cloud supports multiple TLS protocol versions. To meet compliance requirements, you might want to deny handshake requests from clients that use older TLS versions.

To configure this control, use the Restrict TLS Versions( gcp.restrictTLSVersion ) organization policy constraint. You can apply this constraint to organizations, folders, or projects in the resource hierarchy. The Restrict TLS Versionsconstraint uses a deny list, which denies explicit values and allows all others. An error occurs if you try to use an allow list.

Due to the behavior of organization policy hierarchy evaluation, the TLS version restriction applies to the specified resource node and all of its folders and projects (children). For example, if you deny TLS version 1.0 for an organization, it is also denied for all children that descend from that organization.

You can override the inherited TLS version restriction by updating the organization policy on a child resource. For example, if your organization policy denies TLS 1.0 at the organization level, you can remove the restriction for a child folder by setting a separate organization policy on that folder. If the folder has any children, the folder's policy will also be applied on each child resource due to policy inheritance.

To further restrict the TLS version to TLS 1.3 only, you can set this policy to also restrict TLS version 1.2. You must implement this control on applications that you host inside of Google Cloud. For example, at the organization level, set:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

All data in Google Cloud is encrypted at rest by default using NIST-approved algorithms.

Ensure that Cloud Key Management Service (Cloud KMS) only uses NIST-approved algorithms to store sensitive keys in the environment. This control ensures secure key usage by only NIST-approved algorithms and security. The CryptoKeyVersionAlgorithm field is a provided allowlist.

Remove algorithms that don't comply with your organization's policies.

Set the purpose for Cloud KMS keys to ENCRYPT_DECRYPT so that keys are only used to encrypt and decrypt data. This control blocks other functions, such as signing, and ensures that keys are only used for their intended purpose. If you use keys for other functions, validate those use cases and consider creating additional keys.

The protection level indicates how cryptographic operations are performed. After you create a customer-managed encryption key (CMEK), you can't change the protection level. Supported protection levels are the following:

• SOFTWARE:Cryptographic operations are performed in software.
• HSM:Cryptographic operations are performed in a hardware security module (HSM).
• EXTERNAL:Cryptographic operations are performed using a key that is stored in an external key manager that is connected to Google Cloud over the internet. Limited to symmetric encryption and asymmetric signing.
• EXTERNAL_VPC:Cryptographic operations are performed using a key that is stored in an external key manager that is connected to Google Cloud over a Virtual Private Cloud (VPC) network. Limited to symmetric encryption and asymmetric signing.

Ensure that the rotation period of your Cloud KMS keys are set to 90 days. A general best practice is to rotate your security keys on a regular interval. This control enforces key rotation for keys that are created with HSM services.

When you create this rotation period, also create appropriate policies and procedures to securely handle the creation, deletion, and modification of keying material so that you can help protect your information and ensure availability. Ensure that this period adheres to your corporate policies for key rotation.

Use the Domain restricted sharing( iam.allowedPolicyMemberDomains ) organization policy constraint to define one or more Cloud Identity or Google Workspace customer IDs whose principals can be added to Identity and Access Management (IAM) policies.

Google Cloud services write audit log entries to answer who did what, where, and when with Google Cloud resources.

Enable audit logging at the organization level. You can configure logging using the pipeline that you use to set up the Google Cloud organization.

VPC Flow Logs record a sample of network flows that are sent from and received by VM instances, including those used as Google Kubernetes Engine (GKE) nodes. The sample is typically 50% or less of the VPC network flows.

When you enable VPC Flow Logs, you enable logging for all VMs in a subnet. However, you can reduce the amount of information written to logging.

Enable VPC Flow Logs for each VPC subnet. You can configure logging using a pipeline that you use to create a project.

Firewall Rules Logging creates a record each time that a firewall rule allows or denies traffic.

Enable logging for each firewall rule. You can configure logging using a pipeline that you use to create a firewall.

Use the Restrict which projects may supply KMS CryptoKeys for CMEK( gcp.restrictCmekCryptoKeyProjects ) organization policy constraint to define which projects can store customer-managed encryption keys (CMEKs). This constraint lets you to centralize the governance and management of encryption keys. When a selected key doesn't meet this constraint, resource creation fails.

To modify this constraint, administrators need the Organization Policy Administrator( roles/orgpolicy.policyAdmin ) IAM role.

If you want to add a second layer of protection, such as bring your own key, change this constraint to represent the key names of the CMEK that is enabled.

Product specifics:

• In Vertex AI, you store your keys in the KEY PROJECTSproject.

If you require more control over key operations than what Google-owned and Google-managed encryption keys allow, you can use customer-managed encryption keys (CMEKs). These keys are created and managed using Cloud KMS. Store the keys as software keys, in an HSM cluster, or in an external key management system.

Cloud KMS encryption and decryption rates are subject to quotas.

Cloud Storage specifics

In Cloud Storage, use CMEKs on individual objects, or configure your Cloud Storage buckets to use a CMEK by default on all new objects added to a bucket. When using a CMEK, an object is encrypted with the key by Cloud Storage at the time it's stored in a bucket, and the object is automatically decrypted by Cloud Storage when the object is served to requesters.

The following restrictions apply when using CMEKs with Cloud Storage:

• You can't encrypt an object with a CMEK by updating the object's metadata. Include the key as part of a rewrite of the object instead.
• Your Cloud Storage uses the objects update command to set encryption keys on objects, but the command rewrites the object as part of the request.
• You must create the Cloud KMS key ring in the same location as the data you intend to encrypt. For example, if your bucket is located in us-east1 , any key ring used for encrypting objects in that bucket must also be created in us-east1 .
• For most dual-regions, you must create the Cloud KMS key ring in the associated multi-region. For example, if your bucket is located in the pair us-east1 , us-west1 , any key ring used for encrypting objects in that bucket must be created in the US multi-region.
• For the asia1 , eur4 , and nam4 predefined dual-regions, you must create the key ring in the same predefined dual-region.
• The CRC32C checksum and MD5 hash of objects encrypted with CMEKs aren't returned when listing objects with the JSON API.
• Using tools like Cloud Storage to perform additional metadata GET requests on each encryption object to retrieve the CRC32C and MD5 information can make listing substantially shorter. Cloud Storage can't use the decryption portion of asymmetric keys stored in Cloud KMS to automatically decrypt relevant objects in the same manner that CMEKs do.

Google Cloud recommends using Sensitive Data Protection. The infoTypes or job templates that you select depend on your particular systems.

To track who accessed data in your Google Cloud environment, enable Data Access audit logs. These logs record API calls that read, create, or modify user data, as well as API calls that read resource configurations.

We highly recommend enabling Data Access audit logs for generative AI models and sensitive data to ensure you can audit who has readthe information. To use Data Access audit logs, you must set up your own custom detection logic for specific activities, like super admin logins.

Data Access audit logs volume can be large. Enabling Data Access logs might result in your Google Cloud project being charged for the additional logs usage.

For every service perimeter, confirm in the Google Cloud console that the perimeter type is set to regular.

For every service perimeter, use Access Context Manager to confirm that the perimeter is protecting the API.

Access Transparency provides logs that capture the actions that Google personnel take when accessing your content.

You can enable Access Transparency at the organization level.