Blog

AWS Security vs Azure Security vs Google Cloud Security

Table of Contents

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

With the rise of the cloud, data security has changed dramatically. Older data security models based on fortified perimeter defenses have given way to new cloud security models based on authentication and authorization. Perimeter defenses provide inadequate security for data because, like walls in the physical world, they can always be breached. A modern organization’s data can no longer be confined behind a walled garden. With these changes, it is important to review the top considerations for public cloud, like AWS, Microsoft Azure, and Google Cloud.

Today’s modern enterprises may have data stored in traditional places, like data centers and on-premise networks, but data is also stored elsewhere, such as in endpoints, with third-party vendors, and, of course, in the public cloud. In those environments, identifying who or what is accessing data and ensuring access is limited to need and nothing more is critically important. Just as perimeter defenses were once the prime way to protect data, now identity has assumed that role. Identity is the new perimeter.

With that in mind, 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. Making the process work in one of the major cloud providers — Amazon Web Services (AWS), Microsoft Azure, or Google Cloud — can be challenging, too. That’s why it’s important for organizations to understand each provider’s approach to cloud security.

AWS Cloud Security

AWS has a bit of an edge over some of its competitors, who built their public clouds on an existing base. By essentially building its cloud from the ground up, AWS had greater flexibility in the design of its offering.

They have also done a nice job of pinning identity as the prime control mechanism across the platform. What’s more, AWS has continued to add functionality to those identity controls to make its security better and better.

For example, earlier this year AWS incorporated the ability to add tags as a control to an identity policy. That gives an organization a way to add granularity to its access policy by linking an identity to specific tags.

By the same token, AWS allows policies to be created to restrict commands to regions within the cloud. Features like that give an organization the kinds of levers required to manage the thicket of rules needed to manage an identity-based security environment.

Nevertheless, an organization still needs to figure out how to make those levers work. AWS helps users do that with some excellent documentation and clear examples.

The good news about AWS is it provides lots of security tools, such as AWS Config, CloudWatch, CloudTrail, GuardDuty, Macie, and Security Hub, just to name a few. Unfortunately, there’s no way to tie everything together, but they give organizations a good base for their cloud security needs.

AWS allows users to put projects or workloads in separate accounts, which creates boundaries that can limit the blast radius of any data breach.

It’s also important to understand that some AWS features, like Elastic Compute Cloud (EC2) and Simple Cloud Storage Service (S3), support other features in Amazon. That can affect a user’s security posture on the service. For example, a user may believe they’ve blocked off all direct Internet access to their data, but exposure may still exist through EC2 or S3 APIs.

AWS differs from some of its competitors by locating all an organization’s access rules in a central repository. That can make it very difficult to determine from within a resource what identities — whether they be people or non-people identities — have access to that resource. In addition, there can be secondary resource policies that can actually override what’s going on in an identity policy. All that creates complexity that makes it difficult to look at a resource and know who or what has access to it.

A big plus of AWS is its ability to assign roles to entities. It allows a strong identity and access policy to be imposed on things like serverless functions, containers, or workloads. It helps developers to avoid bad practices, such as embedding credentials where they shouldn’t be embedded.

Dependability is another AWS asset. Day after day, it exhibits rock-solid performance and consistency.

On the downside, it can be hard to find things in a user’s cloud because there’s no central view. That can create complexity. Something as common as finding an account linked to an access key in a service can be a chore.

Naming patterns in permissions and actions in AWS can also be puzzling. Finding consistency in the patterns can be complicated.

Consistency in the handling of resource statements can also be challenging. Resource statements can be used to restrict access to a resource.

For example, in S3 there are many buckets, there might be a directory of security log information, as well as one with credit card information. A resource statement could be used in a security control to make sure identities with access to the security log data don’t have access to the credit card data.

The problem is that not all resources in AWS support resource statements, which can lead to overprivileged access. To address that problem, users often create more and more accounts, which can add complexity to managing their AWS environment.

In a similar vein, there are inconsistencies in the implementation of regions. Some security tools work in some regions but not others. In addition, some services aren’t supported in all regions. What’s more, resources can be lost by putting them in a region where they’re unsupported.

Explore How Sonrai Secures AWS.

Azure Cloud Security

Microsoft Azure is an immigrant to the cloud, migrating from the enterprise world. The company realized early on that the cloud was an existential threat to its business, and that it had to make a strong cloud offering, or there would be no more Microsoft. That’s why it has shown a tremendous commitment to Microsoft Azure.

Microsoft Azure was created for building, testing, deploying, and managing applications and services through its global network of data centers. It is built with customized hardware and has security controls integrated into its hardware and firmware components.

Microsoft has more than 3,500 cybersecurity experts working to keep Azure secure and an extensive threat intelligence operation that includes analysis of 18 billion Bing web pages, 400 billion emails, a billion Windows device updates, and 450 billion monthly authentications.

Azure is based on Microsoft’s Active Directory product, with some modifications for cloud operation. Because Active Directory is popular — it has a 95% market share in Fortune 500 companies — Microsoft Azure will appear familiar to many IT professionals, which makes it comfortable for them to work with. On the other hand, because Active Directory has on-premise networking roots, some of its mechanisms aren’t as well-suited to the cloud as some of Azure’s competitors.

For example, multi-tenancy wasn’t a Microsoft strong suit. Hence, some features that worked in on-premise deployments didn’t work when they were cut and pasted into the cloud. In addition, some functions don’t work the way they do in an on-premise world.

Nevertheless, because of the strong connection to Active Directory, it’s easy to sync an enterprise Active Directory to Azure so all the identities, groups, and memberships from the enterprise just float into the cloud where all the controls on those things are preserved.

Microsoft’s enterprise experience is evident in Azure in other ways, too. When designing Azure, Microsoft imposed tighter controls on setting up accounts to prevent scenarios where anyone with a credit card can spin up an account for an organization. Once an email domain is registered with an account, it’s difficult to set up another Azure account with it. That helps avoid a problem that pops up in AWS where organizations don’t know where all their accounts are. It also helps put a damper on the use of “Shadow IT” in the cloud.

Another strong suit of Azure is its use of encryption by default. It supports several encryption models. They include server-side encryption that uses service-managed keys, customer-managed keys in Key Vault, or customer-managed keys on customer-controlled hardware. With client-side encryption, keys can be managed and stored on-premises or in another secure location.

Explore How Sonrai Secures Azure.

Google Cloud Platform Security

Google Cloud Platform 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 Web Services and Microsoft Azure 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 (IAAS) 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 cloud 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 (or even DevSecOps) 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 would want to foster.

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 cloud 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.

Cloud Security Without Blindspots for All Major Clouds

Sonrai Security delivers cloud security for AWS, Azure and GCP environments. We stop high-impact attacks and protect your critical assets by eliminating opportunities for lateral movement through your cloud. We believe securing identities is the most efficient way to protect your cloud so we leverage our patented identity graph and analytics to reveal every toxic identity in your environment creating unintended paths to your data via overpermissioning, trust relationships, managed policies and every combination of compounding privilege.