Managing Security in Google Cloud

Security is everybody’s responsibility

While organisations are moving rapidly towards digital transformation to stay competitive and achieve higher growth by migration, the biggest challenge is Security. Although all the major cloud providers are providing tools and techniques to keep the hybrid or cloud native infrastructure safe and cost effective but it is actually a Shared Responsibility of cloud provider and business.

Google Cloud’s Shared Responsibility Model also emphasises on the same fact and provides a clear guidance on responsibilities of Google as cloud provider and business.

Responsibilities of business team keeps decreasing when they define workloads in following order —

Shared Responsibility Model means, the tools, best practices and framework are provided by Google Cloud and the responsibility to configure the tools as per the requirements sits with business.

Following are some of the approaches and tools provided by Google Cloud to implement security at different levels for a fictional company named Secured Comp.

I’ll not go into the implementation details for each concerned area of security but will give you the wider picture of what all services and tools are available to use and the official documentation links for more details.

1- Identity and Access Security —

What ? —

• For a strongly protected cloud environment, it is imperative to grant least privilege to any user or group. Granular access to required Google Cloud resources and preventing the access to any other non required resource is a must for secured operations.

How ? —

• Secured Comp will utilise the shared responsibility model provided by Google Cloud to establish a hybrid cloud model to connect it’s on-prem office infra with Google Cloud.
• They will start with synchronising their identity management system with Google Cloud Identity. This helps keeping the same on-prem authentication mechanism and identities to authenticate against Google Cloud resources, it can be achieved at both user or group level.
• This Synchronisation between on-prem AD and Cloud Identity can be achieved using Google Cloud Directory Sync tool. Whatever changes to the groups/users are made in on-prem AD, they are updated into Google Cloud Identity based on a CRON job scheduled.
• Separate Service Accounts also needs to be created for different resources e.g. — Compute Engine and GKE, to achieve least privileged access. Role assignment to Users or Service Accounts should happen as lower level in hierarchy as possible.
• Google Cloud KMS should be used to keep the encryption keys and certificates secured. Proper rotation of the Customer Managed Encryption Keys should also be managed carefully by Secured Comp.
• Setting up Organisational Policy constraints at organisation / folder / project levels to restrict the use of approved services, regions or zones among many other constraints.

2- Network Security —

What ? —

• Network security is a way to keep the networks secured in private, public, or hybrid cloud environments. It can be achieved through automation, controls, policies to prevent access to unauthorised users and inappropriate use of the cloud network.

How ? —

• The first golden rule for network security is to keep the traffic internal as much as possible, exposure to internet should be limited for maximum resources. Special care is needed for the resources those are exposed to internet.
• Using Firewall Rules to only allow the traffic that is expected between IP Addresses and Ports used by the applications and VMs. All other traffic should be blocked by-default. Hierarchical firewall rules are also very helpful in achieving uniform rules across all projects in organisation.
• Web based applications should be secured with Google Cloud Armor (WAF). This service helps in monitoring the traffic patterns and blocks or filter the attack traffic. In conjunction with HTTPS External Load Balancer, Cloud Armor provides a configurable service that protects against Layer 7 attacks e.g. — cross site scripting, SQL injection etc.
• All the Google services and APIs should be accessed only via Private Service Connect. Private Service Connects enables the user to consume the services that require a publicly routable IP (Cloud Storage, BigQuery, Cloud Spanner etc.) privately inside Google Network with the help of global private IPs within user’s VPC network.
• Connection to Google Cloud Services should happen through IAP (Identity Aware Proxy). IAP with Identity Platform can also help Secured Comp to enable SSO with External Entities.
• Security for public DNS Zones should also be ensured to prevent the manipulated DNS responses. Activating DNSSEC ensures the authenticated responses to the DNS requests. Google Domains and Domain’s registry service also supports DNSSEC.
• Use of Shared VPC also helps keeping the VPC network at one centralised location and the subnets can be shared among many service projects, it makes the administration of the network easy and secured within a single team.
• There could be a need of standalone VPC network in a project to run isolated workloads but in case they need some communication with the standard resources under Shared VPC network then VPC Peering concept should be utilised to make this connection with any of the service projects.
• To achieve hybrid connectivity between on-prem servers and Google Cloud services, Google Cloud VPN or Google Cloud Interconnect connectivity should be established. While Cloud VPN communication happens over internet but secured through IPSec tunnel over VPN. Cloud Interconnect provides completely private communication via internal IP addresses at both the ends.
• One more aspect of security is to allow only Internal IPs to the Compute Engine machines or Private GKE clusters (as much as possible) in organisation. If such machines needs internet access then it must be provided through Cloud NAT service.

3- Data Security —

What ? —

• Cloud data security refers to preventing data loss, unauthorised use of data while the data is in transit, at rest or in use.
• Securing this data using technologies, services, controls and organisational policies is referred as Data Security.

How ? —

• After securing the network, Secured Comp will focus on secured use of data, maintaining confidentiality and controlling the access on the data that is stored or travels through those networks.
• First step to achieve data security is through encryption. Google Cloud provides several means to achieve data encryption be it through default Google Managed Encryption Keys (GMEK), Customer Managed Encryption Keys (CMEK), Customer Supplied Encryption Keys (CSEK) or Hardware Security Module (HSM).
• Least Privileged Access Control also helps keeping the data secured. Group the related data with similar access control and provide the access to groups / service accounts at appropriate levels.
• Defining the data’s level of confidentiality by classifying the data stored on different storage services (e.g. — BigQuery, Cloud Storage etc.) is also very important so that appropriate access related rules can be enforced.
• Prevention of data exfiltration or invalid transfer between unwanted resources by a person who has access to the data using VPC Service Controls. It is very helpful maintaining security in a multi-tenant architecture by enabling context-aware access.
• Cloud DLP is a great way to scan all the data for Personally Identifiable Information (PII) i.e. — names, email address, residential address, phone numbers etc. Using the country specific and global standard based patterns in Cloud DLP users can detect and transform (redact, obfuscate) the sensitive portion in data. New customised patterns can also be created in Cloud DLP.
• Data in Storage Tables can be protected with Uniform Bucket Level Protection (same for all the objects in the bucket) or IAM conditions based access along with object level Access Control Lists (ACLs).
• Data in BigQuery tables is generally protected at Dataset level since the role based access is given at Dataset level, but in some cases owner doesn’t want to expose all the rows and columns of a table to everyone given the data reader permission in such cases Authorised Views are very handy.
• Key values, Passwords and Connection Strings must be secured in Google Cloud Secret Manager. These secrets can be rotated, encrypted and versioned and access to a user can be given at secret level.

4- Secured Cloud Operations —

What ? —

• Running the operations securely with automated processes in place for infrastructure, data, software and BAU operations is called Secured Cloud Operations.

How ? —

• Supply-chain Levels for Software Artifacts (SLSA). It is a standard proposed by Google to maintain the integrity and securing the entire software development lifecycle. It is a process that establishes the trust during development and supply stages, verify the trust during deployment stage and maintains the trust during operations stage.
• A robust Logging and Monitoring system to capture information and identify the actions and events that can impact the security. Google Cloud effectively indicates the attempts of attack on user’s system, data or infrastructure.
• Automated Centralised Logging for audit purpose also adds a layer of security at organisation level that can periodically scanned for unusual patterns and security incidents.
• Approved CICD Build Pipelines in production environment and quick rollback to previous stable state is also a key aspect of secured automation.
• Secured Comp must use the Infrastructure as Code (tools such as - Terraform and Packer) for quick and safe provisioning / destroying of whole environment.
• Secured Comp must use Artifact Registry for storing the images so that they can be tested for trusted repository and other tests and vulnerabilities. The Binary Authorisation feature of the Artifact Registry makes sure of attestation of image and approving or disapproving the deployment.
• Google Cloud Operations Suite must be used to get notified based on the logs / metrics for security incidents. It can create the tickets based on the severity of the incidents automatically.
• Secured Comp should subscribe Security Command Center (Premium Tier) to get the security config of the project / organisation. SCC can be accessed through the GCP Console and it helps users to detect, avoid and respond to the threat.

5- Regulatory Compliance —

What ? —

• Meeting regulatory compliance is also imperative for achieving overall security posture for Secured Comp.
• The compliance standards e.g. — HIPPA, SOC 1 and SOC 2 and many others need to meet based on the operational landscape of the organisation.

How ? —

• The prime objective of these standards to check whether other security measures e.g. — Authentication, Authorisation, IAM etc. are configured appropriately or not, how Data security, Network security, encryption is achieved.
• Although Google Cloud is already certified for most of the third party standards worldwide, still there is information and best practices made available by Google Cloud to follow for the services / applications that are built and deployed by users on the top of Google Cloud infrastructure.
• One such example is Google Cloud’s documentation on setting up HIPPA approved project.
• Wherever a compliance requirement needs to secure keys not only software based encryption, Google Cloud provides Hardware based key encryption via Cloud HSM.
• Separation of duties and least privilege access are also required for compliance purpose so these can be achieved through Conditional IAM Policies by fine grained access based on conditions e.g. — access on a storage bucket for a specific time period to a group of users.

Conclusion —

• Managing cloud security is a very vast area, I’ve tried to touch base with some of the important areas of concern and these areas may vary business to business.
• For detailed information on various security needs and controls in place to cater those needs in entirety, please refer following article from Google Cloud—

Security Solutions | Google Cloud