1 of 8

LEARNINGS FROM THE WILD

Google Cloud Platform

1:1

2 of 8

About Me

  • Working with Cloud for over 10 years

​

  • Fintech Security, DevSecOps and Software Security

​

  • Working on GCP for around 3 years

3 of 8

The Pitch

  • Get more insights from your data using Google Cloud

​

  • Network is owned and manged by Google

​

  • Encrypt everything, everywhere, all the time by default

Google innovates all the time, so can you

​

4 of 8

Security Toolbox

  • Organisation Policy

​

  • Security Command Centre,

​

  • IAM, Service Controls, Identity Aware Proxy

​

  • VPC, Firewalls

​

  • Cloud Armour, Apigee, Secrets Manager

​

  • Encryption by default

5 of 8

Googling + Chatting

  • You can only have one Org Policy in a GCP Tenant

​

  • Projects are used as a security boundary, no real way to group them

​

  • Security configuration is at component level in many cases

​

  • Consideration for Google Public and Private API Access

​

  • Security Command Centre did not map to a security

compliance standard

6 of 8

Security Implications

​

​

​

  • Org Policy is the lowest common denominator – to support several teams

​

  • Security Configuration of Projects becomes critical

​

  • All Infrastructure component code need to go through assurance process,

similar to application code

​

  • Internal DNS needs to be reconfigured when using the Interconnect

​

  • Third party tools for security compliance, posture management

and alerting

7 of 8

Approach

​

​

​

  • Author security configuration specifications for all components

​

  • Use Developers to write Security Tests, which validated the

component in the pipelines (from Dev)

​

  • Used tools to detect abnormal IAM activity given that

​

  • Ensured applications are coded securely and fail safe

when deployed in GCP

​

  • Didn’t let Google mark their own homework

8 of 8