Spending on the public cloud isn’t slowing down anytime soon. Gartner predicted that it will reach $482 billion in 2022. That’s up 21.7% from the total of $396 billion a year earlier. Cloud management and security services will grow from $25,987 million in 2021 to $29,736 million the following year.

These budgets show that all organizations are struggling to ensure cloud security. A 2021 study revealed that organizations had suffered at least one security incident in their public cloud environment over the preceding 12 months. When asked about their security efforts, three in 10 teams said they had no formal sign-off for pushing to production. Four in 10 admitted that they didn’t have a DevSecOps workflow. Just over 70% noted that more than 10 individuals could make changes to the infrastructure in their AWS environments.

In this blog, we’ll do a cloud provider security comparison.

Learn how ReliaQuest can keep you secure in the cloud >

Platform-Specific Public Cloud Security Policies

Taking into account the findings above, organizations should get familiar with the security policies of their public cloud provider, whether that’s Microsoft Azure, Amazon Web Services (AWS), or Google Cloud Platform (GCP). There are three elements they should research in particular: the shared responsibility model, compliance, and networking/infrastructure.

Shared Responsibility Model

The shared responsibility model divvies up security obligations between public cloud service providers (CSPs) and customers. The former is responsible for ensuring security of the cloud, while providing security in the cloud falls on the latter.

AWS

AWS is always responsible for protecting the hardware, software, networking, facilities, and other physical infrastructure for running cloud services. By contrast, the customer’s obligations vary depending on the type of cloud service they’ve selected (Infrastructure-, Platform-, or Software-as-a-service—IaaS, PaaS, Saas, respectively). There are also different levels of configuration the customer is responsible for.

There are three categories of controls AWS customers need to be aware of.

  • Inherited controls, which reference physical and environmental controls along with other security measures that a customer inherits from AWS.
  • Shared controls require AWS to provide the infrastructure requirements for patch management and other measures but require the customer to provide their own implementation.
  • Customer-specific controls are the sole responsibility of the customer depending on which application they’re deploying within the AWS services. An example of a customer-specific control is zone security, where customers might need to route zone data through specific security environments.

Read how to monitor and investigate AWS events >

Azure

In its documentation, Microsoft is clear that Azure customers own their data and identities regardless of cloud deployment type. Customers are therefore responsible for protecting their data, endpoints, account, and access management. And, of course, responsibility for protecting on-premises resources remains with the customer.

Like with AWS, physical security falls to Microsoft as the cloud service provider. The remaining obligations are typically shared between customers and Microsoft. Those controls include implementing multi-factor authentication (MFA) for identity and access management (IAM). Azure is responsible the effective functioning of MFA, but the customer is ultimately responsible for configuring it.

GCP

Let’s use Google Kubernetes Engine (GKE), which is powered by GCP, to describe how the platform approaches the shared responsibility model. Like the other cloud service platforms above, Google protects the underlying infrastructure. It encrypts data at rest, uses custom-designed hardware, protects data centers from physical access, and follows secure software development practices.

Meanwhile, the customer is responsible for maintaining their workloads including their application code, container images, and IAM policy. It’s also on them to enroll clusters in auto-upgrade or upgrade clusters to supported versions, monitor the cluster and applications so that they can respond to potential issues, and provide Google with details for troubleshooting.

Compliance

AWS

In its documentation, AWS outlined the requirements for strong customer compliance. First, customers need to review the AWS shared responsibility model, security documentation, compliance reports, and other information so that they can document all their compliance requirements into a comprehensive security approach. Per those requirements, customers must then design and implement control objectives, identify and document controls owned by third parties, and verify that they’re meeting all their control objectives with effective security measures.

Azure

Microsoft said that customers must securely identify, label, and classify their data to be compliant. This holds true for wherever the data resides, whether in the cloud or on-premises.

Organizations can still use Microsoft products to meet their compliance obligations, though. For instance, customers can use Office Lockbox and Data Loss Prevention, capabilities that come with SaaS solutions such as Office 365 and Dynamics 365, to manage, classify, and configure their solutions to align with their compliance obligations. For PaaS, customers can leverage Azure Rights Management for data protection. Finally, IaaS customers need to consider data classification across all layers of the solution and audit deployed virtual machines within the solution itself.

GCP

For this one, let’s take Health Insurance Portability and Accountability Act (HIPAA) compliance as an example. First, customers need to determine whether they are a Covered Entity. If they are, they’ll need to enter into a Business Associate Agreement (BAA) with Google. Part of this process might involve confirming that they’re not intending to use or that they are not already using any GCP products that are not explicitly covered by a BAA.

With that agreement in place, Google is responsible for providing secure and compliant infrastructure. But as with the shared responsibility model, the customer needs to make sure that they’ve properly configured and secured the applications that they’ve built on top of GCP. To do this, customers can tightly control access to service accounts and their corresponding keys, account for any encryption requirements that might extend beyond what’s required by HIPAA, enable Object Versioning, and configure audit log export destinations.

Networking/Infrastructure

AWS

In a whitepaper, Amazon noted that customers can choose a level of network security and resiliency that best fits their needs. It went on to explain that it’s implemented a firewall and other boundary devices along with secure access points to enable customers to build dispersed, fault-tolerant web architectures using its cloud services.

Azure

Microsoft noted that network controls include virtual networking, load balancing, and gateways. In its SaaS solutions, Microsoft manages and secures those controls for its customers. Most of the controls follow this same model in a PaaS solution, though customers have more ability to configure network-level service. In an IaaS solution, meanwhile, customers share responsibility with Microsoft for managing, securing, and configuring network solutions.

GCP

Google specified that GCP offers network security tools that customers can use to build a defense-in-depth security strategy. It went on to recommend that customers follow best practices when it comes to securing the network. Those actions include securing web-facing servers as well as micro-segmenting access to apps and services.

Fulfilling Your Share of the Responsibilities in the Public Cloud

Maintaining security and compliance in the public cloud takes two: the provider and the customer. By familiarizing themselves with the policies of their cloud providers, customers can be sure they’re compliant and secure. In addition, some organizations turn to third parties like ReliaQuest to help manage their cloud security. With ReliaQuest Open XDR-as-a-Service, you can integrate disparate tools across the security stack—including the cloud—to build a single, complete view of threats. This contextual visibility enables organizations to visualize and respond to attacks.

Looking for tips on securing the cloud? Download our free white paper >

For more information, visit: Cloud Security Best Practices.