Blog

Google Cloud Deep Dive

Table of Contents

prevent healthcare data breaches Deep Dive Background and integrations with Sonrai Security

Data security has changed dramatically with the rise of cloud. Older security models based on fortified perimeter defenses have given way to new models based on authentication and authorization. Not only can perimeter defenses no longer provide adequate security for data because, like walls in the physical world, they can always be breached, but a modern organization’s data can no longer be confined behind a walled garden.

With identity as the new perimeter, organizations need to fashion their data protection strategy as if the network controls they’ve implemented don’t exist. In that “Zero Trust” world, anyone or anything that accesses data needs to be authenticated, not just once, but continually. What’s more, they shouldn’t be given more access than they need to fulfill their job, commonly referred to as “least privilege.”

Maintaining a Zero Trust environment can be a complex task. It can require the creation of thousands of rules to achieve the granular permissions needed to make the process work. That’s why it’s important for organizations to understand public cloud providers’ security approaches.

Let’s take a deeper look into Google Cloud

Google Cloud grew out of the company’s App Engine framework for hosting web applications from Google’s data center. From that modest beginning in 2008, the platform has become a major public cloud player, although it still trails Amazon and Microsoft in market share.

The platform provides organizations with infrastructure tools and services on which they can build applications and services. Although suitable for organizations of any size, Google Cloud can be an especially good fit for small- and medium-sized businesses, which were the initial focus of the platform.

Following the release of its App Engine, Google introduced a number of tools to build its position as an Infrastructure As A Service provider. They included the addition of a data storage layer and Google Compute Engine, which supports the use of virtual machines.

After that, it began adding components to enable it to be more competitive with AWS and Azure, components such as a load balancer, DNS, monitoring tools, and data analysis services.

When designing its security environment, Google Cloud is closer to AWS than Azure, although its identity model has some similarities to Microsoft’s role-based approach to identity security and the use of Active Directory. On the other hand, Google Cloud’s design of bucket policies resembles AWS. So Google has embraced some of its competitors’ features, as well as some of the risks of those features.

Google Cloud is known in the industry as “the builder’s cloud.” DevOps engineers like it a lot. It has very good Kubernetes support — with a more secure implementation than any other cloud provider — and the machine learning services built into it are as good as you can get in this kind of model.

Engineers also like Google Cloud because it’s easy to collaborate in it. That, though, can have its downside. If it’s not locked down properly, anyone with a Gmail address may end up getting invited into a project. Inviting random people into enterprise workload projects isn’t something most organizations want to foster.

Sonrai - Definitive Guide to Public Cloud eBook

A major distinction of Google Cloud compared to its competitors is that it speaks multi-cloud. Some of its security services will actually work on AWS and Azure data.

Support of multi-cloud workloads and administration was pretty much a necessity for Google in order to differentiate itself from other cloud providers, and because it knows it’s highly likely it won’t be the only cloud provider for an enterprise.

As with AWS, boundaries can be used to compartmentalize data. In the case of Google Cloud, the boundaries are constructed around projects. Identities are linked to the projects, which gives the identities the access they need to do what they need to do with a workload. It allows an organization to get very granular with its policies but not as granular as locking down parts of services.

Google Cloud is also the only cloud vendor that does nested audit data. When a command is issued in the cloud — delete a workload, for example — there are many subcommands running behind it. Google does a nice job of wrapping those subcommands up into a package that enables a user to see the command and all its subcommands in a single view.

That contrasts with other cloud providers that show all the subcommands separately, often with different user agent strings and different IP addresses. So sometimes it looks like a user is performing the service, and other times it looks like the service performing the service, which makes it much more difficult to track identities than it is in the Google Cloud.

While some security features of Google Cloud are quite strong, overall, security remains very much a work in progress compared to AWS and Azure. Many security services are released in beta mode, and given Google’s historical modus operandi, it remains to be seen whether any of those services will be around in three years.

Another problem with Google Cloud is its permissions and granularity can be frustrating. When users try to restrict permissions and are thwarted by a cloud’s services, they will just stop trying. And when they stop trying, they start over-permissioning and security suffers. The greatest security controls in the world aren’t any good if users can’t get them to work.

Tracking down identities in a project can become complicated when members of a GSuite group are involved. GSuite members have their own identities apart from Google Cloud identities. From within a project, identifying GSuite members requires access to APIs that are controlled by another part of the enterprise, which adds complexity to the process.

Google Cloud’s design also has build-in risks for identity management. Because identities are associated with projects, there’s no central place to see all an identity’s access privileges. For the same reason, there’s no way to see who or what has access to a particular resource.

Creating an identity-based security environment in a public cloud may seem daunting, but it need not be. First, controls need to be built for the enterprise, not the individual public cloud. Then those controls need to be mapped to the public cloud an organization will be working with. That can be done through third-party tools that can normalize controls across clouds or through knowledge of how each public cloud works.

Organizations also need to be nimble enough to deal with the kind of surprises that typically pop up when implementing identity-based security. For example, poorly protected access keys that may not have been discovered in years may be discovered. Poor network configurations that expose data to the Internet is another common problem, as is over-provisioning of workloads from machines, which could lead to privilege self-escalation if they are hacked.

Sonrai Security can help

If your organization has implemented Microsoft Azure and your organization is not sure where risks maybe, Sonrai Security can help. Our platform delivers a complete risk model of all these identity and data relationships, including activity and movement across cloud accounts, cloud providers, and third-party data stores.

The Sonrai Security platform has been developed to help organizations improve security, ensure compliance and increase operational efficiencies for Microsoft Azure and other cloud platforms. Core to the service is the ability to gain a centralized and consistent view into cloud identity and data relationships, activity, and data movement across cloud accounts, cloud providers, and third-party data stores. Request a demo of the Sonrai Security platform to see if this solution is right for your cloud environment.