Designing for security

Hallett Bank encrypts customer data in a project named hb-app-prod with Cloud KMS keys. Its regulator requires that the people who manage keys cannot read the protected data, and that application administrators cannot change, disable, or destroy keys. The bank wants to design the key hierarchy for these requirements.

Which two actions should you take? Each correct answer presents part of the solution.

1. ACreate the key rings and keys in a separate, dedicated key management project such as hb-kms-prodPlacing keys in their own project means Owner or Editor on hb-app-prod does not carry permissions over the keys, which is the recommended pattern for separating key administration from data access.
2. BGrant the key custodians the Cloud KMS Admin role on the key project, and grant only the application service agents the CryptoKey Encrypter/Decrypter role on specific keysCloud KMS Admin manages keys but does not include encrypt or decrypt permissions, and limiting Encrypter/Decrypter to the service agents keeps humans on both sides away from the other duty.
3. CGrant the key custodians the Owner role on hb-app-prod so they can verify that encryption is workingOwner on the application project gives the custodians access to the protected data, which breaks the separation the regulator requires.
4. DCreate the keys in hb-app-prod and use IAM conditions to hide them from application administratorsKeys in the application project inherit project-level grants such as Owner, and conditions are a fragile way to undo inherited access.
5. EGrant the application administrators the Cloud KMS CryptoKey Encrypter/Decrypter role so they can troubleshoot encryption errorsThis gives humans the ability to decrypt data directly with the keys and is unnecessary because the service agents do the encryption.

Delacroix Bank must meet an internal rule that key material for its most sensitive Google Cloud data is generated and held in a key manager that the bank operates outside Google infrastructure, so that Google cannot use the key without the bank's system approving each request. The data lives in BigQuery and Cloud Storage, and the bank already runs a supported third-party external key manager.

Which key option should you use?

1. ACloud External Key Manager (Cloud EKM) keys that reference keys in the bank's external key manager, used as CMEK for BigQuery and Cloud StorageCloud EKM keys stay in a supported external key manager; Google services call out for each cryptographic operation, so the bank can deny access and the key material never resides in Google.
2. BCloud HSM keys in the regions where the data livesCloud HSM keys are protected by hardware security modules, but those modules are operated by Google, which fails the outside-Google requirement.
3. CSoftware Cloud KMS keys with imported key material generated by the bankImported key material is stored in Google's Cloud KMS after import, so Google infrastructure holds it.
4. DCustomer-supplied encryption keys (CSEK) for both servicesCSEK is not supported for BigQuery, and the key is still sent to Google with each request rather than staying in the bank's key manager.

Quillfield Health stores de-identified research data in Cloud Storage buckets and BigQuery datasets in a project named qf-research. A researcher with valid IAM permissions could copy data to a bucket in a personal Google Cloud project, and the CISO wants to prevent this kind of exfiltration even when credentials are valid. Access must still work from the corporate network and from Compute Engine VMs in qf-research.

Which control should you implement?

1. ACreate a VPC Service Controls service perimeter around qf-research that restricts the Cloud Storage and BigQuery APIs, with an access level for the corporate IP rangesA service perimeter blocks API calls that move data from resources inside the perimeter to resources outside it, regardless of IAM grants, and access levels allow approved callers such as the corporate network.
2. BRemove the Storage Admin role from all researchers and grant Storage Object Viewer insteadObject Viewer still allows reading objects, which is all a user needs to download data and upload it to another project.
3. CAdd VPC firewall egress rules that deny traffic to 0.0.0.0/0 from VMs in qf-researchFirewall rules control VM network traffic, not Google API calls made from a laptop or Cloud Shell, so a copy between buckets through the API is unaffected.
4. DEnable uniform bucket-level access on every bucket in qf-researchUniform bucket-level access simplifies permissions by disabling ACLs, but it does not stop an authorized user from copying data to an outside project.

Pinecrest Media runs production workloads on a GKE cluster named pc-prod. After an incident in which an engineer deployed an image built on a laptop, the security team requires that only images built by the company's Cloud Build pipeline and approved by the QA stage can be deployed to pc-prod. Unapproved deployments must be blocked at deploy time.

What should you implement?

1. AEnable Binary Authorization on pc-prod with a policy that requires attestations from a Cloud Build attestor and a QA attestorBinary Authorization enforces at admission time that each image carries the required signed attestations, so images that did not pass the pipeline and QA are rejected.
2. BEnable Artifact Analysis vulnerability scanning on the Artifact Registry repositoryScanning reports known vulnerabilities in images, but by itself it does not block deployment of an image built outside the pipeline.
3. CRestrict the Artifact Registry Writer role to the Cloud Build service accountThis limits who can push to that repository but does not stop a deployment that references an image from a different registry.
4. DUse a GKE network policy to block pods that pull images from outside Artifact RegistryNetwork policies control pod-to-pod and pod egress traffic; they do not evaluate which image a pod is allowed to run.