CLOUD-SECURITY-ENGINEER Practice Questions

https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints -

constraints/compute.trustedImageProjects

This list constraint defines the set of projects that can be used for image storage and disk

instantiation for Compute Engine. If this constraint is active, only images from trusted projects will be

allowed as the source for boot disks for new instances.

To enable developer teams to deploy new applications without the extensive overhead of network

and security reviews, it’s recommended to mandate the use of infrastructure as code (IaC) and

enforce policies through static analysis in CI/CD pipelines. This approach ensures that security and

compliance policies are checked automatically during the development process.

Step-by-Step:

Adopt IaC: Use tools like Terraform or Google Cloud Deployment Manager to manage infrastructure

as code.

CI/CD Pipeline Integration: Integrate static analysis tools such as TFLint or Checkov in the CI/CD

pipeline to enforce security policies.

Policy Definition: Define security policies and best practices that need to be adhered to in the code.

Automated Checks: Configure automated checks in the CI/CD pipeline to review code against these

policies before deployment.

Monitor and Audit: Continuously monitor and audit deployed applications to ensure ongoing

compliance.

Reference::

Infrastructure as Code on Google Cloud

Static Analysis for Terraform

Checkov for IaC

To delegate management of access control permissions to each business unit effectively, organizing

projects into folders and assigning permissions to Google groups at the folder level allows for

scalable and manageable access control. Using Google Cloud Directory Sync (GCDS) to synchronize

users and groups from the on-premises directory service ensures that access controls are maintained

and updated automatically as users change roles or leave the company.

Steps:

Organize Projects in Folders: Create a folder structure in the Google Cloud Resource Manager to

organize projects by business unit.

Assign Permissions to Google Groups: Use IAM to assign necessary permissions to Google Groups at

the folder level, ensuring each business unit can manage access controls for their own projects.

Synchronize Users and Groups: Use GCDS to sync users and group memberships from your on-

premises directory service to Google Cloud Identity, ensuring that changes in the on-premises

directory are reflected in Google Cloud.

Reference::

Google Cloud Resource Manager

Google Cloud Directory Sync

Reference:: https://cloud.google.com/docs/enterprise/best-practices-for-enterpriseorganizations#centralize_network_control

Use Shared VPC to connect to a common VPC network. Resources in those projects can communicate

with each other securely and efficiently across project boundaries using internal IPs. You can manage

shared network resources, such as subnets, routes, and firewalls, from a central host project,

enabling you to apply and enforce consistent network policies across the projects.

https://cloud.google.com/access-transparency Access approval Explicitly approve access to your data

or configurations on Google Cloud. Access Approval requests, when combined with Access

Transparency logs, can be used to audit an end-to-end chain from support ticket to access request to

approval, to eventual access.

Storing secrets securely is crucial for maintaining the integrity and confidentiality of your

applications. Here is how you can achieve this using Google Cloud Platform:

Encrypt the Secrets: Use Customer-Managed Encryption Keys (CMEK) to encrypt your secrets. CMEK

allows you to have greater control over the encryption keys used to protect your data. This ensures

that even if the storage medium is compromised, the secrets remain protected by strong encryption.

Store in Cloud Storage: Store the encrypted secrets in Google Cloud Storage. Cloud Storage is a

secure and scalable object storage service. By using encrypted storage, you can ensure that the

secrets are securely stored and can only be accessed by authorized entities.

This method provides a secure and managed way to store secrets, ensuring that they are not exposed

in plain text within your source code management system.

Reference:

Customer-Managed Encryption Keys (CMEK)

Google Cloud Storage Security

https://cloud.google.com/resource-manager/docs/organization-policy/restrictingdomains#setting_the_organization_policy

The domain restriction constraint is a type of list constraint. Google Workspace customer IDs can be

added and removed from the allowed_values list of a domain restriction constraint. The domain

restriction constraint does not support denying values, and an organization policy can't be saved with

IDs in the denied_values list. All domains associated with a Google Workspace account listed in the

allowed_values will be allowed by the organization policy. All other domains will be denied by the

organization policy.

De-identifying sensitive data Cloud Data Loss Prevention (DLP) can de-identify sensitive data in text

content, including text stored in container structures such as tables. De-identification is the process

of removing identifying information from data. The API detects sensitive data such as personally

identifiable information (PII), and then uses a de-identification transformation to mask, delete, or

otherwise obscure the data. For example, de-identification techniques can include any of the

following: Masking sensitive data by partially or fully replacing characters with a symbol, such as an

asterisk (*) or hash (#). Replacing each instance of sensitive data with a token, or surrogate, string.

Encrypting and replacing sensitive data using a randomly generated or pre-determined key. When

you de-identify data using the CryptoReplaceFfxFpeConfig or CryptoDeterministicConfig infoType

transformations, you can re-identify that data, as long as you have the CryptoKey used to originally

de-identify the data. https://cloud.google.com/dlp/docs/deidentify-sensitive-data

Use Cloud Data Loss Prevention (DLP) with cryptographic hashing:

Cloud DLP allows you to de-identify sensitive data using several techniques, including cryptographic

hashing.

Choose a suitable hashing algorithm like SHA-256 for non-reversible anonymization.

This method converts the original data into a fixed-length hash that does not preserve the original

data's format or character set.

Set up a Cloud DLP job to scan your data sources, identify PHI, and apply the cryptographic hashing

transformation.

Reference::

Cloud DLP Overview

De-identification with Cloud DLP

For managing and rotating encryption keys in a Compute Engine-based cluster using Managed

Instance Groups (MIGs), Customer-Managed Encryption Keys (CMEK) with Cloud KMS is the

appropriate solution.

Set Up Cloud KMS:

Go to the Cloud Console and navigate to Security > Cryptographic Keys.

Create a keyring and a key.

Create and Use CMEK:

While creating or updating a Compute Engine instance, specify the CMEK key.

Example command:

gcloud compute instances create example-instance \ --image-family=debian-9 \ --image-

project=debian-cloud \ --boot-disk-kms-

key=projects/[PROJECT_ID]/locations/global/keyRings/[KEY_RING]/cryptoKeys/[KEY]

Rotate Keys:

Rotate keys periodically using Cloud KMS by creating new key versions and updating the instances to

use the new key versions.

Reference::

Customer-Managed Encryption Keys (CMEK)

Using Customer-Managed Encryption Keys