General guidelines for web app security in the cloud.

DISCLAIMER: This is written with GCP in mind, but should apply to all cloud providers.

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 were too loose, management wasn’t paying enough attention, “We will take care of this when we have the chance, later”. When (sh*t) storm is here, let the blame game commence! 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 their development and operations team. Who remembers DJI firmware keys were left in public for years? If everyone thought about security we wouldn’t have issues where people kicking door and screaming for budget, security already would be included in the budget. (How about that migrating to managed database?)

People are the weakest link.

Assign only those permissions 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 go extra step to 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 play many roles. 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.
• Infrastructure as a code is your friend.
• Test constantly.
• Integrate CI/CD to prevent human error.
• If you have 3 tier 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.
• Backward compatibility is the key.

Why managed services?

I mentioned to use managed services where possible. Purpose for this is when using cloud services the load and responsibilities are off loaded to cloud provider. There are couple elements to choose from on the cloud:

• Infrastructure as a service (IaaS) you most control to configure, but you have to own security also.
• Platform as a service (PaaS) is somewhere in the middle.
• 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.