When choosing a cloud provider, one of the most important aspects is security. How do the “Big 3” platforms (Amazon Web Services, Google Cloud Platform, and Microsoft Azure) compare in this area? What are their relative strengths and weaknesses?
This article is the first of a two-part series examining this question. It will compare and contrast the three top-tier public clouds in their approaches to security. We’ll start with their overall philosophies.
Security Philosophy
The security of modern cloud infrastructure is based on a model of “shared responsibility.” Both the providers and their customers are obligated to secure cloud infrastructure, but in different ways. While cloud providers like AWS, GCP, and Azure are expected to (and do) devote considerable financial and engineering resources to security “of” the cloud, customers are ultimately tasked with their own security “in” the cloud.
AWS
Amazon publishes their interpretation of the shared responsibility model. That page provides a succinct, high-level overview of the ownership hierarchy within AWS, with some hypothetical examples. It states how AWS views the shared model, and customers can gain an understanding of what their responsibilities are without having to cut through heavy sales copy.
GCP
Google Cloud Platform (GCP) has a comprehensive series of whitepapers on their security transparency page. They also publish a high-level overview of their overall infrastructure security protocols and operational process in this documentation. Unfortunately, GCP does not provide a page clearly dedicated to providing their interpretation of the shared model. Users will instead find a small section regarding GCP data security, including a visual representation of the shared responsibility model here.
Azure
Azure provides documentation describing tools and services available for customers to use when securing their infrastructure, as well as separate documentation that describes the protocols Azure enforces to secure the platform infrastructure itself. They also publish a specific page dedicated to explaining how the shared model applies on Azure.
Compliance
Most organizations fall under the umbrella of one or more compliance regulations: legal requirements governing the security and privacy of customers and their data. For large-scale digital infrastructure, achieving compliance is often a painful, expensive, and time-consuming process. Cloud computing only adds to the potential pitfalls when it comes to safe handling of customer data.
Fortunately, all three cloud providers understand that a non-trivial portion of their potential customer base will have some need for compliance-compatible infrastructure, and they provide tailored services and tools aimed specifically at that market.
AWS
AWS provides a section dedicated to their compliance offerings, with a variety of programs and services aimed at compliance regulations and industry standards worldwide.
GCP
GCP provides this resource for compliance, breaking out information by region, category, and industry specific offerings.
Azure
Azure offers a similar breakout, with compliance offerings detailed by international bodies, US government, industry, and regional requirements.
Networking
With any cloud provider, the network is the highway on which all data eventually travels. To pass from the provider to the customer, and then to their customers, data must cross several logical and physical borders before reaching its destination. In the legacy model of internet-facing infrastructure, one entity typically would be responsible for the end-to-end security of the entire platform. With the shared responsibility model of the cloud, the unitary obligation no longer exists.
Securing the network involves two distinct areas: how the provider designs and secures the underlying physical network infrastructure, and how it designs and shares security of the logical, customer-facing network infrastructure.
AWS
For internal architecture, AWS published a whitepaper detailing various aspects of its internal network design and security controls. Running on top of their internal infrastructure is the virtualized, logical networking services that AWS provides to customers. The core services make up an offering called Virtual Private Cloud (VPC). A VPC is essentially a complete and isolated (logical) network inside the AWS cloud. The VPC is issued a private CIDR block space, and can be segmented into different subnets. Subnets can either be public-facing, with internet connectivity, or private, allowing only access from private networking space. Traffic between subnets, as well as into and out of the VPC, are controlled by route tables and network gateways. Individual instances utilize security groups to define CIDRs, individual IPs and what ports traffic can or cannot traverse.
For external access, VPCs can be equipped with an internet gateway, allowing communication with the public internet, or more secure solutions, such as IPsec or hardware VPN between the VPC and corporate data centers.
GCP
While Google does not provide explicit details on the design of their internal architecture, most of the high-level details can be inferred from this documentation. Like AWS, Google also refers to their core network offering as a Virtual Private Cloud (VPC). A key advantage of their VPC product is that a single VPC can span multiple distributed regions, via subnets, without ever having to transit data across public networks. Under this design, customers do not have to rely on VPNs and complex routing tables to allow traffic between regional networks. Within a VPC, no IP address space is allocated by default: subnets must be created within a VPC to define usable private networking space. To allow traffic to the public internet, a VPC comes configured with an internet gateway and default route. Individual instances must have firewall rules configured to allow egress traffic over this route for internet-facing communication.
For external access, GCP offers several interconnectivity products, including Cloud VPN and Dedicated or Partner interconnect. Like AWS, these utilize hardware or software-based VPN solutions to encrypt traffic via protocols like IPsec to a local network.
Azure
Microsoft provides fairly extensive documentation regarding their internal Azure network architecture here, and documentation regarding network segregation and control here. The internal architecture more closely mirrors the traditional networking designs seen in datacenters and private networks, likely owing to their focus on traditional enterprise customers.
The core networking product is the Azure Virtual Network (VNet). VNet more closely mirrors the AWS VPC in terms of networking and segmentation. A VNet is created with a private IP address space, and subnets are defined as segments of the VNet CIDR block. VNets are confined to a single region, and require peering to communicate with separate VNets. VNets are configured with a default route that allows outbound connections to the internet. Traffic flow is controlled by Network Security Groups (NSG) and Application Security Groups (ASG). An NSG can be assigned to either a subnet, or the NIC of a VM inside the subnet, and functions similar to traditional IP/PORT firewall rules. To handle larger-scale management of traffic, without requiring explicit IP address management, ASGs are applied by defining groups of like resources, like application VMs, and applying rules accordingly.
For on-premise connections, Azure offers point-to-site VPN, for connecting individual machines into Azure, as well as Site-to-Site VPN using IPSec. Higher bandwidth demands can utilize an ExpressRoute to transit traffic through a dedicated connection through a 3rd party provider or co-location facility.
Authentication and Authorization
Authentication and authorization are critically important to any cloud provider. They define “who” (authentication) can do “what” (authorization). Equally critical is providing a system that is both secure and flexible, adapting to customer use cases while providing a fundamental component of security architecture.
AWS
All authentication and authorization for AWS is handled by a Role-Based Access Control (RBAC) system referred to as AWS Identity and Access Management (IAM). At the heart of IAM are the two primary identity constructs: IAM users and IAM roles. An IAM user is a unique identity that is assigned to a principal, which is a person or application that is allowed to perform operations or make requests on AWS resources. IAM users are given a name and credentials, which are used for authentication. Credentials are issued in the form of passwords, access keys, SSH keys, and in some cases certificates. IAM roles are generic identities that can be assumed by any principal with the correct access, and unlike users are only capable of utilizing ephemeral security credentials.
For authorization, IAM defines several different types of policies. For users, groups, and roles, identity-based policies in the form of JSON documents are applied. These policies describe which AWS resources and services an identity can or cannot access. Resource policies apply to specific resources, such as S3 buckets and IAM role trusts, and grant permissions to a principal defined in the policy. Permissions boundaries and Organization SCPs have specific use cases in defining the maximum permission an entity or group can be granted, but do not grant permissions themselves. ACLs are used to define cross-account access to resources between distinct AWS accounts. (These are not ACLs in the traditional definition of networking ACLs, and have a specific connotation here.) Finally, session policies are utilized by the AWS CLI or API when assuming a role or federating a user.
By default, IAM maintains a strict “Deny-All” default, requiring explicit definitions of access before authorization can proceed.
GCP
Google also refers to its offering as IAM. GCP IAM breaks down access into three primary parts: members, roles, and policies. Members are the identities, typically a Google account, service account, G-Suite or Cloud Identity domain. Roles are aggregated collections of permissions, which are defined in the policies.
GCP offers predefined roles, allowing access to specific services, as well as custom roles in which users can define their own. Primitive roles are also present, but are a legacy product that existed prior to IAM. Typically, a GCP admin would define policies and roles that enable the appropriate level of authorization, and then apply that to the appropriate members. User accounts generally will have access delegated by the correct roles, but service accounts depend heavily on the type of data and access needed. GCP provides a helpful matrix that helps choose the right authentication mechanism based on the member and type of data being requested.
GCP IAM also defaults to a “Deny-All” posture. However, not all services provide authorization granularity to a resource level, and are done by project.
Azure
Access and authorization to Azure is handled via Azure Active Directory. Anyone who has worked in a Microsoft-heavy IT environment will immediately recognize the conventions carried over from traditional Active Directory. Azure Active Directory acts as a Single-Sign-On (SSO) portal for a variety of internal and 3rd party apps, including Azure itself.
Identities are defined as users, which occupy the same hierarchy they would in a traditional AD environment, being a member of groups, and those a member of organizations. Access to resources and apps are governed by roles, which can be attached to individual users, groups, organizations, or assigned dynamically based on specific attributes. Again owing to their focus on traditional enterprise customers with existing Microsoft ecosystems, on-premise Active Directory environments can be mapped to an Azure Active Directory.
The Battle, But Not The War
It’s hard to say that any one provider “wins” the war for the best overall security approach. The best way to evaluate each one is to consider the shared responsibility model. All three providers are highly competitive, and are constantly engaged in a multi-billion dollar effort to provide a secure, high-performing cloud environment. Ultimately, the weak link in the chain will almost always be the customer.
Therefore, the relative merits of web security on AWS, web security on Azure, and web security on GCP ultimately come down to one question: “Which cloud provider most closely aligns with your existing architecture and engineering acumen?” Under the shared responsibility model, you need to ensure you have the resources and the know-how to properly secure your part of the cloud.
In part two of the series, we’ll cover specific security tools and services offered by each provider. Stay tuned!
