Google Cloud Platform has many security features built in and provided by default to its users. You can read more about the platform’s security on this link: https://cloud.google.com/security/.

But, as always, security is made up of many separate, highly tunable controls, each of which can be improved upon until you achieve complete unusability of your system.

With security controls, your goal is usually to set up an initial target level of security. To find where this level should be for your specific use case, it may be a good idea to look for specific guidelines for your industry or stored data types. For example, if you store or handle credit card information in any way, then you must meet the Payment Card Industry Data Security Standard (PCI DSS).

If you’ve determined the right security target for your application, you should aim to reach that while maximizing the ease of system use.

There’s also a concept in security called defense in depth. This says that you’ll never be able to patch every possible hole in your system, but that you should create security measures with multiple layers, so if there is a way to circumvent one, then there’ll be other measures in place before an attacker can seize full control of your resources. It’s highly advisable to practice defense in depth in most situations regarding information systems.

On Google Cloud Platform, besides the built-in security measures, there are some settings and additional controls given to the administrators. I’ve decided to write a series of posts to describe some of these settings along with expected or at least reasonable values to set them to.

In the next post, I’ll write about the security-related options of Identity & Access Management (IAM). Since everything starts there, you should consider securing that part of your project first. If you follow the steps written in the next post, then you’ll have a much better chance of protecting yourself against account compromises, runaway spending, or even mistakes by human administrators.