Public Cloud Security Best Practices Across AWS, Azure, GCP and Kubernetes

Discover how each public cloud provider’s cybersecurity stacks up, and how today’s companies are making intelligent, tactical investments in protecting identity and data access in the cloud.

Read this article to learn:

• Pros and Cons for AWS, Azure, and Google Cloud’s Identity and Access Management Mechanisms
• Review Differences in Security Practices Between The 3 Major Cloud Providers
• Gain Insight Into Least Privilege as the Default Organizing Principle for Cloud Security
• How IT Security & DevSecOps Teams can Explain How The Shift to Public Cloud is Changing the Rules for Security
• What Principles Each Public Cloud Vendor is Using
• Different Approaches to Account Organization & How Resources are Protected.

Table of contents

Identity is the perimeter
Least Privilege is True North for Cloud Security
Cloud Security needs a strong identity model
Cloud Security Is Not Automatic
A brief overview of AWS Security Implementation
AWS Security Pros and Cons
A brief overview of Microsoft Azure Security Implementation
Microsoft Azure Security Implementation
A brief overview of Google Cloud Platform Security Implementation
Google Cloud Platform Pros and Cons
So What’s The Problem?
Sonrai Recommends

Identity is the perimeter

Digital transformation has made the traditional perimeter-based network defense obsolete. A new approach to securing the enterprise needs to be adapted.

In the cloud, identity is now the security perimeter. As organizations, lift and shift workloads from enterprise data centers into the public cloud, IT Security and Cloud teams should plan security as if the network controls don’t exist at all.

Least Privilege is True North for Cloud Security

The traditional security models assumed an organization could establish a strong perimeter, and then trust that activities within that perimeter were “safe.” The problem is today’s digital assets are utilizing technology in the public cloud that the traditional perimeter-based model was never built to protect. Organizations need to transform their security model to one which assumes breach, and as a result, explicitly verifies activities and automatically enforces security controls using all available signal and employs the principle of least privilege access or “Zero Trust.” In the new public cloud world, it is not always users as identities. It is pieces of compute, serverless functions, pieces of the workload that have these identities, and have these permissions to do things especially in the public cloud.

Cloud Security needs a strong identity model

A strong identity model with fine-grain permissions and security tools assisting in the center of public cloud security. This model becomes a system where an organization can put those very fine grain controls on areas, know what the data is, know who the owners are, and can create a security state that is so much stronger than organizations ever could in the traditional perimeter-based model. This model is based on the idea that identity controls all access.

Cloud Security Is Not Automatic

The pleasure and pain of security in the public cloud is a trade-off of responsibility.

Shared responsibility model

The cloud provider is responsible for the security of the cloud, while the organization is responsible for security in the cloud.

The cloud vendor manages and controls the host Operating System (OS), the virtualization layer, and the physical security of its facilities. The organization configures and manages the security controls, infrastructure, identities, is responsible for controls around data in-transit and at-rest.

Cloud security mechanisms

The cloud vendor may provide tools but it is up to the organization to implement and manage security tools. The organization is responsible for the use of common security mechanisms like authentication, authorization, encryption, and access control are the responsibility of the organization.

Application security

It is well documented by public cloud providers, like AWS and Azure, that application security is a shared responsibility between the cloud infrastructure providers and the application owners. However, cloud providers have no visibility into what happens at the application layer.

Application Security is the responsibility of the organization.

A brief overview of AWS Security Implementation

AWS platform launched in July 2002. The security model is built from the ground up natively in the cloud. AWS treats identities as the prime control mechanism across the entire infrastructure. While there may be some legacy oddities in EC2 and Amazon S3. They continue to extend IAM policies to control based on Regions and TAGs that are applied at all levels including SCP and Roles

• AWS accounts are your main workload/security boundary.
• AWS provides a lot of individual security tools. For example AWS config, cloud watch, guard duty, security hub, etc.
• Amazing documentation and examples are available though not always security first.

AWS Security Pros and Cons

Pros:

• Non-people identities leverage STS
• Rock-solid performance and consistency
• SLAs always met
• Few edge cases
• Complete set of security and compliance controls

Cons:

• Finding out what identities have access to a single resource or piece of data is overly complex
• No one spot to see everything in your cloud
• Resource statements not always supported
• Account separation
• The naming pattern for permissions and actions inconsistent across services
• Many things separated by regions requiring duplication

A brief overview of Microsoft Azure Security Implementation

Microsoft’s familiar Active Directory Model for role-based access control is the foundation of the Azure platform which launched in February 2010.

Enterprise AD admins will be familiar with this model. Permissions controlled at resources which grant access to users or group.

Subscription/Resource Groups become your main Workload/Security become your boundary for your workload.

• Encryption by default.
• Documentation is extensive, inconsistent, incomplete and out of date.
• Designed to avoid Shadow IT by default.
• Overly open by default, especially with VMs.

Microsoft Azure Security Implementation

Pros:

• Active Directory is a widely known model
• Finding out who has access to a single resource is easy
• Extended service principal to over service accounts

Cons:

• Not rock-solid performance and Consistency
• Significant exceptions use different models
• God accounts exist outside the core security model
• Mixed duties between Development
• and Production can be complex to set up
• Shifting sea of APIs
• Service principal, app registration, the key generation has a little too much
• in common with service accounts and hardcoded passwords stored in code from our enterprise past
• Getting a centralized view of what a user can access, almost impossible

A brief overview of Google Cloud Platform Security Implementation

In April 2008, Google announced App Engine, a platform for developing and hosting web applications in Google-managed data centers, which was the first cloud computing service from the company. The service became generally available in November 2011.

Unified Identity and Access Management Service, but with many sources of identities

Resources connected at the project level, which can reduce the granularity

Some odd features like S3-like bucket permissions; some half-baked beta features

• Projects are your main Workload/Security Boundary Impressive but incomplete security model
• The beginnings of multi-cloud security
• The only cloud that also speaks multi-cloud

Google Cloud Platform Pros and Cons

Pros:

• Data science workloads
• Cross-cloud services like Stack driver
• Fast real-time info from a security audit perspective
• Security analytics
• Amazing container management support

Cons:

• Frustrating and confusing granularity sometimes leads to over-permissions
• Groups from GSuite can be complicated to understand from within a project level access
• No one place to see an identity’s access and no easy way to see from a resource all the identities that have access to it
• Originating user identification impossible in some cases

So What’s The Problem?

• Organizations use more than one public cloud. Security teams don’t want to build separate controls for each cloud – AWS, Azure, GCP
• Traditional Enterprise security thinking and habits may backfire in the public cloud
• Too easy to use over permission templates

Sonrai Recommends

• Build your organization controls first, independent of any cloud
• Establish proper separation of duties and identities
• Then apply that strategy to each cloud using its tactics
• Start with a strong identity
• Knowledge of tools to detect individual cloud unique controls required so an organization doesn’t accidentally expose something

Source: Sonrai Security