The 8 Biggest Google Cloud security mistakes to avoid

By on
The 8 Biggest Google Cloud security mistakes to avoid

Avoiding Pitfalls

Businesses have traditionally moved to the cloud for cost savings or to augment private data center capacity, according to Google. But Google said security has become a central selling point for cloud migration as companies realize that cloud providers can invest more in people and processes that create a secure infrastructure.

Google said it has made security a priority in its own operations and that its cloud services are designed to deliver better security than many traditional on-premises tools. Since Google runs on the same infrastructure that it makes available to customers, businesses can benefit from the emphasis the company places on data protection when it comes to primary design criteria.

But great technology only provides protection if it’s implemented correctly, and organizations that are new to Google Cloud might overlook or opt out of vital features that protect data or virtual machines. From exposing sensitive data in BigQuery tables to overauthorizing access on new projects to leaving virtual machines unguarded, here are eight key Google Cloud security mishaps that occur too frequently.

photo

8. Failing To Implement Application-Level Segmentation

Google’s VPC Service Controls implement segmentation in a smarter way across servers, which allows multiple virtual machines (VMs) to talk with databases, according to Sunil Potti, vice president and general manager for Google Cloud security. Customers frequently leverage VPC when building or moving applications, Potti said.

The tool puts application-level segmentation policies in place, Potti said, meaning that databases with personal customer information are identified and only specific applications are allowed to access it. VPN Service Controls offer simple, easy-to-use policies and ensure that adversaries can’t access a database even if the port was left open.

VPC Service Controls have a purpose that’s similar to the firewall, but Potti said firewalls are used mostly for external communications while Google’s tool is intended to provide segmentation internally. It is offered as a built-in capability within Google Cloud.

photo

7. Overlooking Configuration Settings In Gmail

Organizations using both Google Cloud and Gmail need to define some configurations in terms of user access and how projects are taking place, according to Marina Segal, Check Point Software Technologies’ head of product management for Cloud SecOps and compliance. Specifically, Segal said that whatever is being set up with Gmail will extend to Google Cloud as well.

How Gmail defines subscriptions and groups for users affects the Google Cloud Platform if the user is starting with Gmail and then moving to Google Cloud, according to Segal. Organizations must therefore keep in the back of their mind that the structure of subscriptions and groups today will affect how people can use Google Cloud in the future, Segal said.

The process for granting permissions and access in Google is somewhat similar to Active Directory in Azure, according to Segal.

photo

6. Not Assessing How Visibility Needs Can Be Met

Google Cloud has done a lot from a security standpoint over the past two years, highlighted by the new services and functionality introduced into the company’s Security Command Center, according to Matt Chiodi, Palo Alto Networks’ chief security officer of public cloud.

As businesses work with the Google Cloud Platform, Chiodi said they should look at these capabilities and ask if the Security Command Center gives them sufficient visibility across all of their cloud deployments. As a best practice, Chiodi said organizations must get and maintain multi-cloud visibility since it’s very difficult for them to secure what they can’t see.

Companies that enjoy success with cloud security are logging key information, contextualizing those logs, maintaining an asset inventory, and monitoring who’s accessing their data and what’s happening with it, Chiodi said. Organizations must invest in cloud security data platforms that are compatible with multiple providers since very few businesses are operating in just a single public cloud, Chiodi said.

photo

5. Lack Of Guardrails Around Anthos, Kubernetes Usage

Containerization and Kubernetes have changed the paradigm in which the cloud can migrate and exist, and Google’s unique mentality and mindset provides flexibility and different ways by which these platforms can be consumed and adopted, according to Matt Pley, Fortinet’s vice president of cloud and service providers.

Kubernetes started out of how Google developed its own software for its products, and the company then brought the technology to the masses to make building environments easier by leveraging repeatable and automated functions, Pley said. Plus, Google brings a unique dimension to the table with Anthos, which provides customers flexibility by giving them the ability to run on other clouds.

If an organization is running Anthos across multiple clouds, Pley said it must have visibility into all of its deployments, the ability to automate and orchestrate across all platforms, and the ability to get detailed reporting. And given that Kubernetes has a native integration into the Google platform, Pley recommended that businesses put guardrails around what they’re doing with Kubernetes.

photo

4. Leaving Virtual Machines Susceptible To Attack

When traditional VMs are spun up, nothing is natively secure beyond what the hypervisor provides under its cover, according to Google’s Potti. As a result, Potti said the VMs are susceptible to remote attacks as well as privileged insiders.

Google’s Virtual Trust Platform Module (vTPM) is highly secure firmware that provides deeper monitoring for the integrity of the system, Potti said. It’s part of Google’s Shielded VM, which Potti said packages together a number of of features and capabilities into a single platform to, for example, constantly monitor every VM for evidence of tampering.

Shielded VMs help make traditional VMs more secure at very little cost, and Potti said the vTPM has become faster and more complete after a few years of investment. Now that the optimization has been complete, Potti said Shielded VMs are turned on by default since there’s such limited downside.

photo

3. Exposing Sensitive Data In BigQuery Tables

A lot of businesses are using Google’s BigQuery tables to perform data analysis, and they must ensure they’re not exposing sensitive data to someone who isn’t part of their organization, according to Check Point’s Segal. It requires some additional thinking on how to structure permissions to ensure that only people who need to have access to the tables actually do, Segal said.

There are little tables within Google that provide more granularity in defining which people have permission to access those services, according to Segal. But managing permissions for BigQuery tables isn’t as straightforward as for other services, Segal said.

Businesses need to determine which tables are the most sensitive and restrict access only to those people who truly need it, Segal said. There are tools both within Google as well as from third parties that can provide organizations with visibility into their tables while reducing unnecessary access, according to Segal.

photo

2. Overauthorizing Access When Starting A Project

All permissions and security structures are set up on a project-by-project basis in Google Cloud to avoid collisions, and projects don’t cross over unless a connection is made between the two for specific services, according to Mark Nunnikhoven, Trend Micro’s vice president of cloud research. As a result, Nunnikhoven said security decisions must be made for every single project.

This can be challenging since Google’s tooling is still maturing to make it easy to apply cookie-cutter settings from one project to the next, according to Nunnikhoven. When a project is created, he said it by default has access to nothing, and the user has to explicitly enable everything that’s required such as spinning up an API. In other public cloud platforms, he said the APIs are automatically accessible.

As a result, he said developers often overauthorize very quickly in Google to get an open and permissive framework at the onset, and the enabled capabilities tend to stay on whether they’re needed or not. An approach where developers have to think beforehand about what’s being called for in the project can be painful, but he it’s ultimately more secure when they stick with authorizing as little privilege as possible.

photo

1. Allowing Abnormal Access To Sensitive Data

Every time an organization stores data in a bucket, they should have DLP (data loss prevention) turned on to ensure that buckets are being consistently scanned for sensitive data such as personally identifiable information (PII) or data that’s subject to PCI compliance, according to Google’s Potti.

If someone is accessing sensitive data out of context or is exfiltrating PII data, Potti said Google’s DLP tool flags it. Google Cloud DLP leverages advanced data lake technology that the company has been harnessing for years in the consumer side of the business, where DLP is built into the capabilities of Gmail, according to Potti.

Google Cloud has a highly optimized runtime, but it does consume compute time in order to scan data, Potti said. Customers therefore must go to the data protection page to turn on DLP capabilities, which Potti said is done in line with turning on storage capabilities. Concerns about the associated compute overhead and the nominal compute cost has resulted in some customers not turning DLP on, he said.

 

This article originally appeared at crn.com

Got a news tip for our journalists? Share it with us anonymously here.
Copyright © 2018 The Channel Company, LLC. All rights reserved.
Tags:

Most Read Articles

Log In

Username / Email:
Password:
  |  Forgot your password?