Securing Web Applications on Google Cloud Platform

Image credit: Flickr.com

Securing web apps is a major challenge in this internet world. In this blog I will try to list all the parameters that you should be configuring before deploying the application. Although this blog is written keeping Google Cloud Platform in mind, the concepts are applicable to any cloud — public or private. Here are the 7 step security guidelines for the application owners, system administrator and developers wishing to deploy the application on Google Cloud Platform.

1. Define Organization, Folders and Project: First things first. Google Cloud Platform lets you define the hierarchy of the organization, folders for each departments and projects and resources under these departments. It is very important to define the project boundaries well. This will help you in defining the right access policies. You should try keeping all the required resources in the same project.

2. Define Networks (VPC): Although GCP supports 5 VPC (virtual private cloud) networks per project, it is usually a best practice to have a single VPC network per project so that all resources are accessible within the network. By default, GCP will create a default VPC network for every project. There are instances when multiple projects under the same organization, needs to talk to each other, in such scenario it is advisable to use Shared VPC. If the network needs to be shared with projects outside the organization, then VPC Peering would help. It is important to note here that configuring VPC in the early stages (before any deployments), usually proves beneficial.

3. Define Subnetworks: Plan out your subnets in such a way that only the required resources can access the secured resources. Boundaries of subnets can be within the zone or across the zones in the same region. With subnets, you can apply firewall and other networking policies to all the resources under that subnet. Define the routes and firewall rules for your subnets to avoid unwanted access from outside, reduce traffic hops and reduce egress traffic. By default, when a project is created, GCP will create default VPC network and corresponding subnet. This default subnet blocks all ingress traffic and allows all egress traffic. By configuring firewall, you can enable traffic for right IP address and ports for your application.

4. IAM & Service Account: With Identity and Access Management, application owners should give access to right persons with right access levels for right amount of time. Similarly, for application access also service account should be created with required privileges only. You need to follow principle of least privilege (POLP) to avoid any accidental misuse and attacks.

5. Encryption: It is at most important to secure the data in transit (on wire while communicating) as well as at rest (storage) to ensure that the data can be understood only by the application that is entitled to read it. Here are some of the best practices that every developer must consider while designing the application

5.1. SSL / TLS for data in transit: Deploy TLS 1.3 certificates for all your application servers so that all the communication between the client and server is encrypted.

5.2. Encryption keys for data at rest: By default, GCP encrypts all data that is being stored in GCP services, be it a persistent disk or cloud storage or managed services like BigQuery or Cloud SQL. Management of keys and encryption policies are implemented the same way that Google uses for all its production services. GCP supports 3 methods of managing encryptions keys

• Encryption by default: Smart defaults and no config
• Customer managed encryption keys (CMEK): using Cloud KMS
• Customer supplied encryption keys (CSEK): Stores keys on premise

5.3. Key Rotation: It is a good practice to implement key rotation policy to avoid storing all your data with same encryption key. To comply with some of the business standards like PCI DSS, this is a requirement. Based on your requirement, you can implement manual rotation or automatic key rotation.

5.4. Security Key Enforcement (Two-factor Authentication): It is a good practice to enable two-factor authentication for admins and high value users who work with sensitive data, as an additional security measure. In GCP, there are multiple options supported for 2-step verification like security keys, Google Prompt, Google Authenticator and OTP as text message / email / phone call.

6. Bastion Host / NAT Gateway: As an owner of the application, you need to ensure minimal access to your secured resources from outside world. 2 techniques which will help you in achieving this is NAT Gateway and Bastion host.

• If you wish to access the secured resource from outside but do not wish to expose it through external IP address, then NAT gateway would be a useful technique which works on the IP forwarding mechanism
• If the client of the secured resource is within the network, you can very well disable the external IP address of that resource. For maintenance of that resource (specifically SSH), you should not expose that resource using external IP address. In such scenarios bastion host will be a helpful.

7. Protect from Attacks: Understand the kinds of attacks and design for it. Multiple tools are available to help you in identifying and protecting from attacks. For ex.

1. Web Security Scanner: This is a tool provided by the Google Cloud Platform to check the security vulnerabilities in apps deployed within Google platform. It crawls your web application and detects multiple types of vulnerabilities as defined in CIS Google Cloud Foundation. As of now, it supports apps deployed in GCE, GKE and GAE.
2. Cloud Armor: It is a tool which lets you protect your application from multiple attacks like DDoS, OWASP top 10 risks etc. The flexible rule engine will let you configure the parameters for blocking the traffic as per your need.

Final Words:

Initially securing the app may look like an overhead but it is a mandatory step to protect from attacks and threats. Also securing the application should not be seen as a one-time job, rather it should be evaluated and corrected regularly. Responsibility of securing the application does not lie only with network administrators and application owners; application developers are also equally responsible. And hence the security has to be considered at every stage viz, designing, development, deployment and QA — It has to be By-design and not by force or policy.

Compromising on security would be a nightmare that no application owner would like to imagine ..