Problem
Security is a concern whether it be on-premises or cloud-native. Google Cloud offers many products and services including SQL Server. What are some of the security controls that should be considered when using Google Cloud services?
Solution
We will cover some best practices for a cloud environment and go through some theoretical concepts to help configure Google Cloud products to be secure, reliable, performant, and aligned with industry best practices.
Google Cloud Security Best Practices
Security in the cloud is shared between Google and us (the clients). We need to remember this aspect and be aware of how the responsibility is split. Google manages the layers related to data center access control, hardware, boot loading, and many other low layers. Below you can see the shared responsibility model in Google Cloud, where the cloud provider protects the cloud infrastructure, and the customer should protect what is put inside using tools already provided for securing, monitoring, and auditing resources.
Principle of Least Privilege
An important part of every security design is to grant a user the minimal permissions needed to perform a task. This should also be expanded and applied to other processes and machine instances. Using Cloud IAM, we can assign predefined roles to users or even create custom roles with only specific actions that can be performed. We can also use service accounts for instances or other processes and follow the same principle. A service account is a type of account used by a VM instance, an app, or a GKE node pool. The service account is used for authorized API calls, and you can grant roles on that account so only specific resources can be accessed.
For better management and permission assignment, it’s best to create groups, add members (users) to a specific group, and grant roles to groups instead of individual users. This way, new members will get the group’s permission, and if a member is removed from a group, it will no longer have the group’s permission.
Organizational Policies
Using organizational policies is a great way to apply specific policies across all resources inside an organization. This simplifies your resource security management because you can apply specific rules across all resources rather than individually. Say you want to restrict the creation of new resources to a particular location or prevent all Cloud Storage resources from being accessible from the public internet. These are a few examples where organizational policies are helpful. Of course, don’t forget about policy inheritance. It’s applied from top to bottom, as shown below.
Separation of Duties
This next best practice helps to prevent a conflict of interest and detect security breaches or information theft. For example, we should be able to detect if someone deletes data or accesses sensitive information, have more than one person assigned for a task, and one individual should not have control over the entire process flow. There should be a different person to design, approve, and implement a particular solution. We can use multiple projects and folders for various duties and assign permissions accordingly.
Audit Logs
We can discover security threats by auditing Google Cloud logs. GCP services write actions in audit logs for administrative activity, system events, data access, policy denied, VPC, and firewall logs. You can create alerts for specific messages and receive notifications when generated.
As expected, GCP is certified and meets many government and third-party compliance standards as HIPAA and ISO/IEC 27001. However, what you run in the cloud is not certified. If needed, make sure to meet compliance on all required levels.
Security Command Center
This product reports threat detection, prevention, and health analysis like asset inventory and tracking, discovers misconfigurations, web app vulnerabilities, and malicious network activity, and can maintain compliance by suggesting best practices for our resources based on industry standards. All these goodies are accessible in a dashboard, and once something is detected, you can take recommended actions.
Network Security
There are several precautions we can take to secure the network. One is to remove external IPs from resources so they are not accessible from the public internet. If resources need external access for patches and updates, use Cloud NAT for external internet access or a bastion host to access private machines. Cloud IAP is another way to securely access apps running in Compute Engine, App Engine, GKE, or even on-premises. You configure who can access the app, and the users log in without a VPN. We can use either method based on our needs. However, remember that internet traffic should be terminated at the firewall level, load balancer, Cloud IAP, or API gateway so that the private VM and services remain protected with no public access.
Private Google Access can be used to access Google services with public IP from resources with a private IP address. To use this feature, you need to enable it when the subnet is created. Below is a visual representation of Compute Engine accessing a bucket in Cloud Storage.
Even if we don’t use external IPs, we should configure firewall rules to control access. The default rules allow egress and deny ingress traffic. A good practice is to block all traffic by default and allow only the traffic to flow to the resources you need on specific protocols and ports. If you want traffic blocked at a larger scope, like the organization level, you can implement hierarchical firewall policy rules.
GCP uses HTTPS for its service endpoints. But we must ensure we use secured connections for our endpoints, so use TLS when needed, like when creating a load balancer. Using global load balancers, Google protects the infrastructure against DDoS at layers 4 and 3. Besides providing a caching mechanism, enabling CDN will protect the backend services because a DDoS attack will hit the cache instead of our backend resources.
Cloud Armor will also help against DDoS but has additional protection features: you can blacklist known attackers, it supports layer 7 web app firewall rules to prevent SQL injection and cross-site scripting, can filter traffic based on location and headers, can create security policies, bot protection, and many more features.
Encryption
Data stored at rest is encrypted by default using AES-256, keys are encrypted, automatically rotated, and managed by Google. If you want more control, you can create your own keys, set the rotation period using Cloud Key Management Service (Cloud KMS), and use these keys in your resources.
Customer Supplied Encryption Keys (CSEK) for Cloud Storage and Compute Engine’s persistent disk lets you generate and manage your own keys outside Google Cloud. The keys are passed alongside API service calls and are used to decrypt the data.
Encryption in use is also possible with Confidential Computing. This applies to VMs, GKE, Dataproc, and Confidential Space. This will ensure that data in use (in memory) is also encrypted during processing.
Encryption in transit refers to data movement between services in the cloud and on-premises and the cloud provider. Data in transit is also encrypted, but there are some differences between the boundaries of the connections and how the network traffic is routed. Learn more about it here Encryption in transit.
Cloud Data Loss Prevention API (Cloud DLP) is a managed service for discovering and protecting sensitive data like emails, credit cards, phone numbers, names, personally identifiable information (PII), and even scanned images. You can delete, mask, tokenize, and redact sensitive data in Cloud Storage, BigQuery, and Datastore.
Conclusion
Just because we are running in the cloud doesn’t mean we are secure and protected. Security in the cloud is a shared responsibility between the client and the cloud provider, and we need to be aware of what needs to be done from our side to have a secure environment.
Next Steps
- Check out these related Google Cloud articles
