The Google Professional Cloud Security Engineer certification is a Google credential to ensure that a security engineer has the requisite knowledge and skills to ensure security in Google Cloud and outside Google’s perimeter with services that interact with GCP.
The certification ensures that you understand security best practices and as an engineer you are proficient in IAM, defining organizational security structure, configuring network security & monitoring active environments for threats using Google native solutions and using AI to solve zero-day attacks in today’s world.
The certification exam is divided into 5 topic sections that each carry a different weight that is reflected in the exam. They are.
- Configuring access (~27% of the exam)
- Securing communications and establishing boundary protection (~21% of the exam)
- Ensuring data protection (~20% of the exam)
- Managing operations (~22% of the exam)
- Supporting compliance requirements (~10% of the exam)
purchase Professional Cloud Security Engineer Exam Q & A(Amazon) Barnes and Noble Apple books
Configuring access
cloud identity is a Google Cloud authentication service. under a single pane of glass, cloud identity manages SSO, device management, account security, user lifecycle management, and cloud directory among other features.
If you use Active Directory in your on-premises environment, you can use the GCDS tool to configure Active Directory and import users, groups, and memberships to Google Cloud Identity.
Federating active directory with cloud identity
Cloud Identity has a super admin role, which is not the same as the Google Cloud IAM Organization Administrator, but the super admin is by default an Organization Administrator and has administrator privileges for both platforms.
Super administrator best practices
- Always enable 2SV/multi-factor authentication for the super admin account.
- Keep a backup security key in a secure location.
- Disable device trust and limit the web session length
- Set recovery phone and email options, and ensure the recovery email is secure and protected with 2SV.
Service accounts
A special type of Google account that grants permissions to services instead of end users. When granting IAM roles , you treat a service account either as a resource or identity.
Service account keys
When you create a service account key, you are creating a private-public key pair. The public key is stored within Google Cloud, and you get a private part of that key pair. This is how you establish the identity of the service account. The key is used to authenticate that service account to Google Cloud from outside of Google Cloud.
Workload Identity Federation (WIF). WIF lets your workloads access resources directly, using a short-lived access token, and eliminates the maintenance and security burden associated with service account keys.
Best practices when managing service account keys
- Determine whether you truly need to use service account keys or whether your application could use a more secure method such as WIF.
- The service accounts created for development purposes shouldn’t have access to production resources.
- Have a procedure to rotate your service account keys. Rotate them often—daily, if possible—in development environments.
- Developers should download a new key every day, and enable this by developing a daily key rotation mechanism.
- Make it impossible for developers to upload their private keys to external code repositories.
To impersonate service accounts from outside of Google Cloud or from GKE workloads, use the Workload Identity User role.
Organization policy resource hierarchy
Restricting resource locations
IAM Conditions
You can provide access to principals only if certain requirements are met using IAM Conditions. A condition is part of the role binding. If a condition exists, access is only permitted if the condition expression evaluates to true. Each condition expression is made up of a series of logical statements that indicate which attributes should be checked.
Access Control Lists (ACLs)
You can use an ACL to determine who has access to your buckets and objects, as well as what level of access they have. ACLs are applied to specific buckets and objects in Cloud Storage. There are one or more entries in each ACL. An entry enables a certain user (or group) to carry out specific tasks. Each entry is made up of two bits of data:
- A permission, which defines what actions can be performed (for example, read or write)
- A scope (sometimes referred to as a grantee), defines who can
perform the specified actions (for example, a specific user or group of users)
Best practices for Cloud Storage access while using ACLs
- Do not use sensitive information in the Cloud Storage bucket name.
- Follow the principle of least privilege when granting access to buckets and objects. This will make sure that the data contained in the bucket is not accidentally exposed.
- Do not grant OWNER permission to anyone in the organization.
- Be aware of how you grant permissions to anonymous users. The allUsers and allAuthenticatedUsers scopes provide access to everyone on the internet
- Avoid setting ACLs that result in inaccessible objects. An inaccessible object is an object that cannot be downloaded (read) and can only be deleted. This can happen when the owner of an object leaves a project without granting anyone else OWNER or READER permission on the object.
Access Context Manager
Access Context Manager is a policy engine that allows administrators to create access control policies based on factors such as user geolocation and source IP address.
These policies can be used as part of VPC Service Controls to ensure that a set of controls is applied to protect data in the project from adversaries
Vpc service controls dry run mode
2. Securing communications and establishing boundary protection
Identity-Aware Proxy
IAP lets you configure centralized authorization to manage secure remote access to your VMs and applications. IAP and load balancers are in front of all your data requests.
Using IAP, you can not only secure access to resources on Google Cloud, such as GCE, Google App Engine, and GKE, but you can also create secure access for your on-premises or third-party cloud provider.
Securing your app with signed headers
Firewall rules
Your VPC instance must have firewall rules for your VMs that allow access from VMs to the IP addresses used by Google APIs and services. Every VPC has two implied firewall rules that permit outgoing connections and block incoming connections.
firewall rule features
- Firewall rules are stateful in nature and are applied to a network inside a project.
- Enforcement is done on the host level, which means there is a negligible performance penalty.
- All communication between a VM and its corresponding metadata server (169.254.169.254) is allowed.
- Each firewall rule has an allow or deny associated with it, and you have the option to disable firewall rules.
- The control paths that you can manage using firewall rules are VM to VM, VM to the internet, and VM to on-premises.
Cloud NAT
Cloud NAT is offered as a managed service that provides high availability and seamless scalability. It allows outbound connections only to the internet, whereas inbound traffic is allowed only if it is in response to a connection initiated by an instance.
Cloud Armor
You can protect your Google Cloud workloads from a wide range of threats, including DDoS attacks and application attacks, such as XSS and SQL injection, with Cloud Armor (SQLi).
Cloud Armor leverages Google’s global and distributed infrastructure to detect and absorb attacks and filter traffic through configurable security policies at the edge.
DNSSEC
DNSSEC is a security feature of DNS that helps prevent attackers from poisoning or manipulating DNS requests.
Global external HTTP(S) load balancer: This load balancer handles both HTTP and HTTPS traffic and is a proxy-based Layer 7 function
that caters to your services and is configured behind a single external IP.
Regional external TCP/UDP load balancer: This is also referred to as a regional network load balancer and is configured as a pass-through. It balances the traffic for VMs in the same region.
SSL proxy load balancer (global): This is a reverse proxy load balancer that distributes SSL traffic from the internet to the closest available backend VMs.
TCP proxy load balancer (global): This is a reverse proxy load balancer, and it distributes the traffic to the VMs configured as your backends inside the Google Cloud VPC network.
Internal HTTP(S) load balancer: An internal HTTP(S) load balancer is a regional proxy-based Layer 7 load balancer.
Internal TCP/UDP load balancer: This load balancer distributes traffic to your internal VMs within the region in a VPC network.
3. Ensuring data protection
Cloud Key Management Service
Envelope encryption
This is the process of encrypting data is to generate a DEK locally, encrypt data with the DEK, use a KEK to wrap the DEK, and then store the encrypted data and the wrapped DEK together. The KEK never leaves Cloud KMS.
Customer-managed encryption keys (CMEKs)
CMEKs just mean that the customer decides the key type (software versus hardware), algorithm strength, and key rotation period when creating a key in Cloud KMS.
Customer-supplied encryption key
You can provide your own AES-256 key, encoded in standard Base64, as an additional layer on top of Google-managed encryption keys. This key is known as a customer-supplied encryption key.(CSEK)
CSEKs with Compute Engine
Compute Engine encrypts all data at rest by default on the persistent disks by using Google default encryption keys. You can bring your own encryption key if you want to control and manage this encryption yourself.
If you provide your own encryption key, Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data. Only users who can provide the correct key can use resources protected by a CSEK.
Customer-managed encryption key
Cloud Data Loss Prevention
Data Loss Prevention (DLP) is a strategy for detecting and preventing the exposure and exfiltration of sensitive data.
de-identification is a process that removes personal information from a dataset. Cloud DLP supports the following methods of de-identification:
Masking: Replaces the original data with a specified character, either partially or completely.
Replacement: Replaces original data with a token or the name of theinfoType if detected.
Date shifting: Date-shifting techniques randomly shift a set of dates but preserve the sequence and duration of a period of time.
Generalization and bucketing: Generalization is the process of taking a distinguishing value and abstracting it into a more general, less distinguishing value. Generalization attempts to preserve data utility while also reducing the identifiability of the data. One common generalization technique that Cloud DLP supports is bucketing. With bucketing, you group records into smaller buckets in an attempt to minimize the risk of an attacker associating sensitive information with identifying information.
Pseudonymization: This is a de-identification technique that replaces sensitive data values with cryptographically generated tokens:
Two-way tokenization pseudonymization: Replaces the original data with a token that is deterministic, preserving referential integrity.
characterMaskConfig Setting characterMaskConfig to a CharacterMaskConfig object partially masks a string by replacing a given number of characters with a fixed character.
cryptoHashConfig Setting cryptoHashConfig to a CryptoHashConfig object performs pseudonymization on an input value by generating a surrogate value using cryptographic hashing.
Best practices for secret management
- Use secret-level IAM bindings or IAM conditions to limit access to the necessary subset of secrets when numerous services’ secrets are in a single project.
- Follow the principle of least privilege when granting permissions to secrets to your applications.
- Divide applications and environments (staging/production) into independent projects.
- Rotate your secrets periodically to minimize the impact of leaked Secrets.
4. Managing operations
Log categories
Security logs
Cloud Audit Logs and Access Transparency Logs. Cloud Audit Logs generates the following types of audit logs for each cloud project, folder, and organization.
Admin Activity audit logs include information on API calls and actions that potentially alter cloud resource settings or metadata
Data Access audit logs show who accessed which data, the access time, and what actions they performed.
System Event audit logs: Events that alter resource configurations are recorded in System Event audit logs.
Policy Denied audit logs: Policy Denied audit logs are created when a Google Cloud service rejects a user or service account access for a security policy violation.
Best practices for logging and auditing.
- Ensure that you specify the correct log storage destination—Google Cloud Storage for archival and retention and BigQuery for analytics and Forensics.
- Configure appropriate permissions for the access of your logs.
- Ensure that sensitive data is stripped from the logs before they are Stored.
- Periodically review your audit logs that are stored in Cloud Logging,
BigQuery, or your third-party SIEM solutions.
Bigquery column-level security
Row-level security in big query
CI/CD security
Securing your CI/CD pipeline is essential for ensuring the integrity, availability, and confidentiality of the application and its data.
Source Composition Analysis (SCA) is a process used in CI/CD pipelines to assess the security posture of the source code used in development. SCA runs scans on the source code to identify vulnerabilities and security issues.
Static Application Security Testing (SAST) is a process of analyzing the source code of an application for potential security vulnerabilities. It is typically done before the application is deployed, and it is the first step of the security testing process.
Container registry scanning
It is the process of scanning container images in a container registry to detect and prevent the introduction of any malicious code that could lead to a security breach.
best practices for securing CI/CD pipelines
- Take advantage of Google Cloud’s security offerings to secure your CI/CD pipeline.
- It is important to regularly back up the CI/CD pipeline so that any modifications can be undone if needed.
- Implement the principle of least privilege access by utilizing Google Cloud IAM to define roles and assign users with the minimum necessary access level to the CI/CD pipeline.
- Enable authentication and authorization in the CI/CD pipeline using a centralized authentication system such as Google Cloud IAM.
- Take advantage of Google Cloud’s security offerings to secure your CI/CD pipeline. These include Cloud Armor, Cloud Security Scanner, and Cloud IAM.
GKE security features
In Kubernetes, namespaces are used to separate groups of resources in a cluster.
Kubernetes RBAC
This is a built-in feature of Kubernetes that grants granular permissions to Kubernetes cluster objects. Within the cluster, permissions are represented by ClusterRole or Role objects. Roles in Kubernetes RBAC provide permissions at the namespace level, while ClusterRoles offer cluster-wide permissions.
Service mesh
A service mesh is a Layer 7 proxy. Microservices can use this service mesh to abstract the network. In Kubernetes, the service mesh is usually implemented as a set of network proxies. These proxies, which are deployed as a sidecar of an application, serve as an entry point for service mesh functionality and manage communication between microservices. Istio is a popular open-service mesh that connects, manages, and invariably secures microservices.
Container Analysis and Binary Authorization can be combined to provide attestations, which can prohibit known security vulnerabilities in container images from running in your production environment.
You can utilize Binary Authorization to construct a vulnerability allowlist as part of your Cloud Build workflow based on the vulnerability information provided by Container Analysis
Google Cloud professional cloud security engineer free practice test.
Supporting compliance requirements
Access Transparency
Access Transparency logs are a feature provided by Google Cloud that offers customers visibility into the actions performed by Google employees when they access customer data.
Compliance in the cloud
Google is compliant with international standards such as ISO 27001, ISO 27017, ISO 27018, SOC 2, and SOC 3.
ISO 27017: This framework is an extension of ISO 27001 and focuses specifically on information security relating to cloud computing beyond the general guidelines in the preceding document.
ISO 27018: This is a set of security guidelines that specifically focus on the processing and protection of Personally Identifiable Information (PII).
ISO 27001: This is an Information Security Management System(ISMS) framework, consisting of 14 groups, 35 control objectives, and 114 controls.
