Karolis Scerbiakas

General guidelines for web app security in the Google Cloud Platform.

Karolis Ščerbiakas -

Security folks are viewed like those crazy, paranoid doomsday callers on one hand, and on the other hand they viewed like boogeyman who have power to shutdown sprint and give you work so you won’t see sunlight anymore. In fast paced environment security is not at the top of the TODO list. Permissions are too loose, management isn’t paying enough attention, “We will take care of this when we have the chance, later”. To prevent this here are few key points to pay attention to. Inside the cloud and on organisational level.

Fun fact: Most security breaches in the cloud occur as a result of customer not setting the security culture in the first. Who remembers DJI keys were left in public for years?

Assign only those permissions (roles) which are required to get the job done. For example there is no need for a junior developer together access to .env file of production application instance.
Also utilise infrastructure as a code (IaC) tool like Terraform to track changes in your infrastructure to prevent unwanted human error and if it happens track down easily.
Integrate CI/CD.
When person leaves organisation - deactivate all accounts, not just GSuite. Please. I've meet quite a few developers who switched their jobs long time ago, but they still can access some critical resources from their previous job.

Least privilege

  • Follow principle of least privilege. Assign only required permissions. Also good idea is to follow principle of separation, meaning the user don’t wear that many hats. This will prevent inside threats and minimise attack surface from inside.
  • When person switches role in organisation also reassign roles and permissions required to get job done.
    Also make sure to use short lived tokens instead of downloading service account.
  • Assign Roles, not permissions

More public IPs - larger attack surface

It is considered a best practice to use as less public IPs as possible. If you need to reach out to outside your network then use Cloud NAT instead, so VM can download updates without having public IP. Utilize Cloud Armor on your LoadBalancer and other web application services to prevent and defend against attacks (CSRF, XSS, SQL Injection, DDoS to name a few).

Firewall

Open firewall rules only when necessary. Automate firewall rule editing if possible (IaC). Either track changes in git or have single person do it.

Application layer.

  • Harden compute resources. Constantly.
  • Set up proper logging and monitoring. Major cloud providers have decent tools, some are more pain to implement than others.
  • Use managed services where possible or if budget allows it.
  • Have your infrastructure as a code in place.
  • Test constantly.
  • Use CI/CD.
  • If you have web app and you constantly need to coordinate releases between the teams it ussualy is a sign of tight coupling or releases are too bulky.
  • Ensure backwards compatibility across releases. This will help tremendously in case you would need to revert.

Why managed services?

Use managed services whenever possible. Purpose of this is cloud services part of security and maintenance are off-loaded to the cloud vendor. There are few options to choose from each of them gives different levels of control and are priced differently.:

  • Infrastructure as a service (IaaS) you have the most control to configure, but you have to own security as well end to end. Compure Engine would be a great example.
  • Platform as a service (PaaS) is somewhere in the middle. Google App Engine, Cloud Dataflow to name a few. This is where security responsibility is shared.
  • Function as a service. (FaaS) this mostly refers to Cloud Functions, AWS Lambda etc. this is where cloud provider handles security, scalability etc. Most secure, least flexible.