In this summarized article, we will see how we can securely design systems in Google Cloud Platform. We will start with Security Concepts, Securing People and then move on to the Securing Machine Access and Encryption topics.
Security Concepts
Google Cloud Security
- It’s a shared responsibility between Google and the clients
- Transparency
- The client is responsible for certain actions, and Google is responsible for others.
- Google Cloud provides the tools and access to monitor your service.
- Google Cloud provides the controls and features needed to leverage platform security.
- Separation of duties
- What is provided by the platform?
- What are you responsible for?
Principle of least privilege
- The principle of least privilege is the practice of granting a user only the minimal set of permissions required to perform a duty. This should apply to machine instances and processes, as well as users.
- Google Cloud best practices:
- Use IAM to enforce this principle.
- Identify users with their login.
- Identify machines and code using service accounts.
- Assign IAM roles to users and service accounts to restrict what they can do.
Separation of duties
- Separation of duties means:
- No one person can change or delete data without being detected.
- No one person can steal sensitive data.
- No one person is in charge of designing, implementing, and reporting on sensitive systems.
- For example, the people who write the code shouldn’t deploy the code, and those who deploy the code shouldn’t be able to change it.
- Google Cloud best practices:
- Use multiple projects to separate duties.
- Different people can be given different rights in different projects.
- Use folders to help organize projects.
Regular Audit of Logs to discover attacks
- All Google Cloud services write to audit logs, so there is a rich source of information available.
- Google Cloud best practices:
- Audit
- Admin logs
- Data access logs
- VPC Flow logs
- Firewall logs
- System logs
- Audit
- Google Cloud best practices:
Google Cloud Security Command Center
Google Cloud also offers the Security Command Center, which provides access to organizational and project security configuration.
The Security Command Center provides a dashboard that reports security health analysis, threat detections, anomaly detection, and a summary report. Once a threat is detected, a set of actionable recommendations is provided.
Securing People
Google Best Practices
- When granting people access to your projects, you should add them as members and assign them one or more roles. Roles are simply a list of permissions.
- For simplifying management of members and their permissions, Google recommend that you create groups. That way, you just need to add members to a group and new members automatically acquire the permissions of the group. It’s better to use multiple groups for better control.
- The same applies for removing members from a group, which also removes the permissions of that group.
- Google also recommend using organizational policies and folders to simplify securing your environments and managing your resources.
- Organizational policies apply to all resources underneath an organization. Cloud IAM policies are also inherited top to bottom. Folders inherit policies of the organization, projects inherit policies of the folders, and so on.
- When it comes to roles, it’s better to use predefined roles over custom roles. Google has defined the roles for a reason, and it should be an exceptional case that a role does not fit your use case.
- When granting roles, remember the principle of least privilege. Always grant the smallest scope required. Owner and editor roles should be limited. These are not or should not be required by the majority of users.
Leverage Identity-Aware Proxy
- Cloud IAP provides managed access to applications running in App Engine standard environment, App Engine flexible environment, Compute Engine, and GKE.
- It allows employees to securely access web-based applications deployed on Google Cloud without requiring a VPN.
- Administrators control who has access and users are required to log on to gain access to the applications.
Identity Platform (Customer Identity and Access Management – CIAM)
- Provides federated login that integrates with many common providers like Google, Twitter (X), Facebook, Microsoft, LinkedIn, OpenID Connect, SAML, etc.
- Identity Platform provides sign up and sign-in for end user applications.
- A broad range of protocol support is available, including SAML, OpenID, e-mail and password, phone, social, and Apple.
Securing Machine Access
Service Accounts
- A service account is a special kind of account used by an application, a virtual machine instance, or a GKE node pool.
- Applications or services use service accounts to make authorized API calls.
- The service account is the identity of the service and defines permissions which control the resources the service can access.
- A service account is both an identity and a resource.
- A service account is used as an identity for your application or service to authenticate, for example, a Compute Engine VM running as a service account.
- To give the VM access to the necessary resources, you need to grant the relevant Cloud IAM roles to the service account.
- At the same time, you need to control who can create VMs with the service account so random VMs cannot assume the identity. Here, the service account is the resource to be permissioned.
- You assign the ServiceAccountUser role to the users you trust to use the service account.
- Each service account is associated with public/private RSA key-pairs that are used to authenticate to Google. These keys can be Google-managed or user-managed.
- Google-managed keys, both the public and private keys, are stored by Google, and they are rotated regularly. The maximum usage period is two weeks.
- Generate and download a key when absolutely necessary.
- Key is downloaded as JSON.
- For user-managed keys, the developer owns both public and private keys. They can be used from outside Google Cloud. User-managed keys can be managed by the Cloud IAM API, gcloud command-line tool, or the service accounts page in the Cloud Console.
- User-managed keys are extremely powerful credentials. Store the key safely.
- It can represent a security risk if they are not managed correctly.
- You can limit their use by applying the constraints/iam.disableServiceAccountKeyCreation Organization Policy Constraint to projects, folders, or even your entire organization.
- Maximum 10 key-pairs per service account allowed to create and to support key rotation.
Network Security
Remove external IPs
- To prevent access to machines from outside their network wherever possible.
- These services do not have a public IP address because they are deployed to be consumed by other instances in the project, or maybe through dedicated interconnect options.
- How to communicate securely with VMs that do not have public IP address?
- Those instances that do not have an external IP address, but can have a requirement to gain external access, for instance, for updates or patches to be applied.
- Use a bastion host to provide access to private machines.
- Can also SSH into internal machines using IAP from the console and CLI.
- Use Cloud NAT to provide egress to the internet from internal machines.
- All internet traffic should terminate at a load balancer, third-party firewall (proxy or WAF), API Gateway, or IAP. That way, internal services cannot be launched and get public IP addresses.
- The following diagram shows an external client accessing Compute Engine resources via a bastion host.
Private Google Access
- VM instances that only have internal IP addresses can use private Google access to access Google services that have external IP addresses. For example, a machine with only an internal IP would be able to reach a Cloud Storage bucket.
- Private Google access must be enabled when creating the subnet.
Configure firewall rules
- Regardless of whether you’re VM instances have public IP addresses, you should always configure a firewall rules to control access.
- By default, ingress on all ports is denied and all egress is allowed.
- It’s your responsibility to define separate rules to allow or deny access to specific instances for specific IP ranges, protocols, and ports.
- For example:
- Egress from Compute Engine to external servers is the first scenario.
- For ingress, firewall rules should be configured if direct access to an instance is being provided or if via a load balancer.
- The right-hand side shows the scenario of VM instance to instance communication.
Firewall rules should be considered here to control access also.
Cloud Endpoints
- If you need to manage APIs, you can use Cloud Endpoints to control access to APIs.
- Protect and monitor your public APIs.
- Control who has access to your API.
- Validate every call with JSON Web Tokens and Google API keys.
- Integrates with Identity Platform.
Restrict access to your services to TLS only
- All Google Cloud service endpoints use HTTPS.
- Google recommends that you use TLS for your service endpoints and it is your responsibility to configure your service endpoints for TLS.
- When configuring load balancers, only create secure front ends (HTTPS).
Leverage Google Cloud network services for DDoS protection
- Google provides Infrastructure DDoS support through global load balancers at level 3 and level 4 traffic.
- If you have enabled CDN, this will also protect backend resources because a DDOS results in a cache hit instead of hitting your resources.
Google Cloud Armor
- For additional features over the built-in DDoS protection, you can use Google Cloud armor to create network security policies. For example, you can create allow lists that allow known/required addresses through and deny lists to block known attackers.
- It can allow or deny access to your Google Cloud resources using IP addresses or ranges.
- It can create allow lists to allow known addresses.
- It can create deny lists to block known attackers.
- In addition to layer 3 and layer 4 security, Google Cloud armor supports layer 7 application rules. For example:
- Predefined rules for preventing common attacks like SQL injection and cross-site scripting.
- Flexible rules language allows you to allow or deny traffic using request headers, geographic location, IP addresses, cookies, etc.
Encryption
Server-side encryption of data at rest by default
- Data Encryption Key (DEK) uses AES-256 symmetric key.
- Keys are encrypted by Key Encryption Keys (KEK).
- Google controls root keys in Cloud KMS.
- Keys are automatically periodically rotated.
- On-the-fly decryption by authorized user access with no visible performance impact.
- For example a simple App Engine application that uses Cloud Storage, the data is encrypted using AES 256 using a DEK and decrypted transparently to the application where the data is read.
Cloud Key Management Service (KMS)
- Customer-managed encryption keys are created in the cloud using Cloud Key Management Service (KMS).
- You create the keys and specify the rotation frequency.
- You can then select your keys when creating storage resources like bucket and disks.
Customer-supplied encryption keys (CSEK) created in your environment
- Those keys are kept on premises and not in Google Cloud.
- The keys are provided as part of API service calls and Google only keeps the key in memory and uses it to decrypt a single payload or block of returned data.
- Currently, customer supplied encryption keys can be used with Cloud Storage and Compute Engine.
Cloud Data Loss Prevention API
- Scans data in Cloud Storage, BigQuery, or Firestore.
- Can also scan images.
- Detects many different types of sensitive data, including:
- Emails
- Credit Cards
- Tax IDs
- GCP Credentials
- IMEI
- MAC Address
- Phone Numbers
- US SSN
- Bank MICR
- Passport
- US Employer IDs
- And many more
- You can add your own information types.
- Can delete, mask, tokenize, or just identify the location of the sensitive data.