Cloud Security Handbook E-Book

Eyal Estrin

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 456

Veröffentlichungsjahr: 2022

Beschreibung

Securing resources in the cloud is challenging, given that each provider has different mechanisms and processes. Cloud Security Handbook helps you to understand how to embed security best practices in each of the infrastructure building blocks that exist in public clouds.
This book will enable information security and cloud engineers to recognize the risks involved in public cloud and find out how to implement security controls as they design, build, and maintain environments in the cloud. You'll begin by learning about the shared responsibility model, cloud service models, and cloud deployment models, before getting to grips with the fundamentals of compute, storage, networking, identity management, encryption, and more. Next, you'll explore common threats and discover how to stay in compliance in cloud environments. As you make progress, you'll implement security in small-scale cloud environments through to production-ready large-scale environments, including hybrid clouds and multi-cloud environments. This book not only focuses on cloud services in general, but it also provides actual examples for using AWS, Azure, and GCP built-in services and capabilities.
By the end of this cloud security book, you'll have gained a solid understanding of how to implement security in cloud environments effectively.

Leseprobe

Cloud Security Handbook

Find out how to effectively secure cloud environments using AWS, Azure, and GCP

Eyal Estrin

BIRMINGHAM—MUMBAI

Cloud Security Handbook

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Rahul Nair

Publishing Product Manager: Rahul Nair

Senior Editor: Arun Nadar

Content Development Editor: Sulagna Mohanty

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Project Coordinator: Shagun Saini

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Joshua Misquitta

Marketing Coordinator: Hemangi Lotlikar

First published: March 2022

Production reference: 1100322

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80056-919-5

www.packt.com

I wish to dedicate this book to my loving wife for all the support she provided me with during the long hours spent writing this book.

– Eyal Estrin

Contributors

About the author

Eyal Estrin is a cloud security architect who has been working with cloud services since 2015. He has been involved in the design and implementation of cloud environments from both the IT and security aspects.

He has worked with AWS, Azure, and Google Cloud in a number of different organizations (in the banking, academia, and healthcare sectors).

He has attained several top cloud security certifications – CCSP, CCSK, and AWS.

He shares his knowledge through social media (LinkedIn, Twitter, Medium, and more) for the benefit of cloud experts around the world.

About the reviewers

Randy M. Black is a 25-year veteran in the IT industry and an early adopter of DevOps. Randy has spent the last decade working in some form or other of cloud technology and security. He abhors the silos that traditional IT creates and the detriment they pose to organizations. Randy is a strong advocate of transferring knowledge without fear of being transparent, misunderstood, or seemingly odd.

To Jesus, my rock and salvation, for His grace and peace in accompanying me through this crazy, upside-down world. And to my wife, Jill, who has supported and stood by me in everything that I do, and who is the cornerstone of my success. And finally, to my four children, who don't always understand what I do, but appreciate the fact that I am doing it.

Timothy Orr (@easttim0r on Twitter) designs, builds, and operates secure systems in complex cloud environments. He supports customers with cloud security automation, serverless architecture, threat detection and response, security analysis, and multi-tenant cloud brokering and governance. Tim holds a master's degree in InfoSec, CISSP, AWS Security Specialty, AWS Solutions Architect Professional, and AWS SysOps Administrator Associate certifications.

Table of Contents

Preface

Section 1: Securing Infrastructure Cloud Services

Chapter 1: Introduction to Cloud Security

Technical requirements

What is a cloud service?

What are the cloud deployment models?

What are the cloud service models?

Why we need security

What is the shared responsibility model?

AWS and the shared responsibility model

Azure and the shared responsibility model

GCP and the shared responsibility model

Command-line tools

AWS CLI

Azure CLI

Google Cloud SDK

Summary

Chapter 2: Securing Compute Services

Technical requirements

Securing VMs

Securing Amazon Elastic Compute Cloud (EC2)

Securing Azure Virtual Machines

Securing Google Compute Engine (GCE) and VM instances

Securing managed database services

Securing Amazon RDS for MySQL

Securing Azure Database for MySQL

Securing Google Cloud SQL for MySQL

Securing containers

Securing Amazon Elastic Container Service (ECS)

Securing Amazon Elastic Kubernetes Service (EKS)

Securing Azure Container Instances (ACI)

Securing Azure Kubernetes Service (AKS)

Securing Google Kubernetes Engine (GKE)

Securing serverless/function as a service

Securing AWS Lambda

Securing Azure Functions

Securing Google Cloud Functions

Summary

Chapter 3: Securing Storage Services

Technical requirements

Securing object storage

Securing Amazon Simple Storage Service

Securing Azure Blob storage

Securing Google Cloud Storage

Securing block storage

Best practices for securing Amazon Elastic Block Store

Best practices for securing Azure managed disks

Best practices for securing Google Persistent Disk

Summary

Securing file storage

Securing Amazon Elastic File System

Securing Azure Files

Securing Google Filestore

Securing the CSI

Securing CSI on AWS

Securing CSI on Azure

Securing CSI on GCP

Summary

Chapter 4: Securing Networking Services

Technical requirements

Securing virtual networking

Securing Amazon Virtual Private Cloud

Securing Azure VNet

Securing Google Cloud VPC

Securing DNS services

Securing Amazon Route 53

Securing Azure DNS

Securing Google Cloud DNS

Securing CDN services

Securing Amazon CloudFront

Securing Azure CDN

Securing Google Cloud CDN

Securing VPN services

Securing AWS Site-to-Site VPN

Securing AWS Client VPN

Securing Azure VPN Gateway (Site-to-Site)

Securing Azure VPN Gateway (Point-to-Site)

Securing Google Cloud VPN

Securing DDoS protection services

Securing AWS Shield

Securing Azure DDoS Protection

Securing Google Cloud Armor

Securing WAF services

Securing AWS WAF

Securing Azure WAF

Summary

Section 2: Deep Dive into IAM, Auditing, and Encryption

Chapter 5: Effective Strategies to Implement IAM Solutions

Technical requirements

Introduction to IAM

Failing to manage identities

Securing cloud-based IAM services

Securing AWS IAM

Auditing AWS IAM

Securing Azure AD

Auditing Azure AD

Securing Google Cloud IAM

Auditing Google Cloud IAM

Securing directory services

Securing AWS Directory Service

Securing Azure Active Directory Domain Services (Azure AD DS)

Securing Google Managed Service for Microsoft AD

Configuring MFA

Summary

Chapter 6: Monitoring and Auditing Your Cloud Environments

Technical requirements

Conducting security monitoring and audit trails

Security monitoring and audit trails using AWS CloudTrail

Security monitoring using AWS Security Hub

Best practices for using AWS Security Hub

Security monitoring and audit trails using Azure Monitor

Best practices for using Azure Monitor

Security monitoring and approval process using Customer Lockbox

Best practices for using Customer Lockbox

Security monitoring and audit trail using Google Cloud Logging

Security monitoring using Google Security Command Center

Security monitoring and approval process using Access Transparency and Access Approval

Conducting threat detection and response

Using Amazon Detective for threat detection

Using Amazon GuardDuty for threat detection

Security monitoring using Microsoft Defender for Cloud

Using Azure Sentinel for threat detection

Using Azure Defender for threat detection

Using Google Security Command Center for threat detection and prevention

Conducting incident response and digital forensics

Conducting incident response in AWS

Conducting incident response in Azure

Conducting incident response in Google Cloud Platform

Summary

Chapter 7: Applying Encryption in Cloud Services

Technical requirements

Introduction to encryption

Symmetric encryption

Asymmetric encryption

Best practices for deploying KMSes

AWS Key Management Service (KMS)

AWS CloudHSM

Azure Key Vault

Azure Dedicated/Managed HSM

Google Cloud Key Management Service (KMS)

Best practices for deploying secrets management services

AWS Secrets Manager

Google Secret Manager

Best practices for using encryption in transit

IPSec

Transport Layer Security (TLS)

Best practices for using encryption at rest

Object storage encryption

Block storage encryption

Full database encryption

Row-level security

Encryption in use

AWS Nitro Enclaves

Azure Confidential Computing

Google Confidential Computing

Summary

Section 3: Threats and Compliance Management

Chapter 8: Understanding Common Security Threats to Cloud Services

Technical requirements

The MITRE ATT&CK framework

Detecting and mitigating data breaches in cloud services

Common consequences of data breaches

Best practices for detecting and mitigating data breaches in cloud environments

Common AWS services to assist in the detection and mitigation of data breaches

Common Azure services to assist in the detection and mitigation of data breaches

Common GCP services to assist in the detection and mitigation of data breaches

Detecting and mitigating misconfigurations in cloud services

Common AWS services to assist in the detection and mitigation of misconfigurations

Common Azure services to assist in the detection and mitigation of misconfigurations

Common GCP services to assist in the detection and mitigation of misconfigurations

Detecting and mitigating insufficient IAM and key management in cloud services

Common AWS services to assist in the detection and mitigation of insufficient IAM and key management

Common Azure services to assist in the detection and mitigation of insufficient IAM and key management

Common GCP services to assist in the detection and mitigation of insufficient IAM and key management

Detecting and mitigating account hijacking in cloud s ervices

Common AWS services to assist in the detection and mitigation of account hijacking

Common Azure services to assist in the detection and mitigation of account hijacking

Common GCP services to assist in the detection and mitigation of account hijacking

Detecting and mitigating insider threats in cloud services

Common AWS services to assist in the detection and mitigation of insider threats

Common Azure services to assist in the detection and mitigation of insider threats

Common GCP services to assist in the detection and mitigation of insider threats

Detecting and mitigating insecure APIs in cloud services

Common AWS services to assist in the detection and mitigation of insecure APIs

Common Azure services to assist in the detection and mitigation of insecure APIs

Common GCP services to assist in the detection and mitigation of insecure APIs

Detecting and mitigating the abuse of cloud services

Common AWS services to assist in the detection and mitigation of the abuse of cloud services

Common Azure services to assist in the detection and mitigation of the abuse of cloud services

Common GCP services to assist in the detection and mitigation of the abuse of cloud services

Summary

Chapter 9: Handling Compliance and Regulation

Technical requirements

Compliance and the shared responsibility model

Introduction to compliance with regulatory requirements and industry best practices

How to maintain compliance in AWS

How to maintain compliance in Azure

How to maintain compliance in GCP

Summary

What are the common ISO standards related to cloud computing?

ISO/IEC 27001 standard

ISO 27017 standard

ISO 27018 standard

Summary

What is a SOC report?

Summary

What is the CSA STAR program?

STAR Level 1

STAR Level 2

Summary

What is PCI DSS?

Summary

What is the GDPR?

Summary

What is HIPAA?

Summary

Summary

Chapter 10: Engaging with Cloud Providers

Technical requirements

Choosing a cloud provider

What is the most suitable cloud service model for our needs?

Data privacy and data sovereignty

Auditing and monitoring

Migration capabilities

Authentication

Summary

What is a cloud provider questionnaire?

Summary

Tips for contracts with cloud providers

Summary

Conducting penetration testing in cloud environments

Summary

Summary

Section 4: Advanced Use of Cloud Services

Chapter 11: Managing Hybrid Clouds

Technical requirements

Hybrid cloud strategy

Cloud bursting

Backup and disaster recovery

Archive and data retention

Distributed data processing

Application modernization

Summary

Identity management over hybrid cloud environments

How to manage identity over hybrid AWS environments

How to manage identity over hybrid Azure environments

How to manage identity over GCP hybrid environments

Best practices for managing identities in hybrid environments

Summary

Network architecture for hybrid cloud environments

How to connect the on-premises environment to AWS

How to connect the on-premises environment to Azure

How to connect the on-premises environment to GCP

Summary

Storage services for hybrid cloud environments

How to connect to storage services over AWS hybrid environments

How to connect to storage services over Azure hybrid environments

How to connect to storage services over GCP hybrid environments

Summary

Compute services for hybrid cloud environments

Using compute services over AWS hybrid environments

Using compute services over Azure hybrid environments

Using compute services over GCP hybrid environments

Summary

Securing hybrid cloud environments

How to secure AWS hybrid environments

How to secure Azure hybrid environments

How to secure GCP hybrid environments

Summary

Summary

Chapter 12: Managing Multi-Cloud Environments

Technical requirements

Multi-cloud strategy

Freedom to select a cloud provider

Freedom to select your services

Reduced cost

Data sovereignty

Backup and disaster recovery

Improving reliability

Identity management

Data security

Asset management

Skills gap

Summary

Identity management over multi-cloud environments

How to manage identity in AWS over multi-cloud environments

How to manage identity in Azure over multi-cloud environments

How to manage identity in GCP over multi-cloud environments

Summary

Network architecture for multi-cloud environments

How to create network connectivity between AWS and GCP

How to create network connectivity between AWS and Azure

How to create network connectivity between Azure and GCP

Summary

Data security in multi-cloud environments

Encryption in transit

Encryption at rest

Encryption in use

Summary

Cost management in multi-cloud environments

Summary

Cloud Security Posture Management (CSPM)

Summary

Cloud Infrastructure Entitlement Management (CIEM)

Summary

Patch and configuration management in multi-cloud environments

Summary

The monitoring and auditing of multi-cloud environments

Summary

Summary

Chapter 13:Security in Large-Scale Environments

Technical requirements

Managing governance and policies at a large scale

Governance in AWS

Governance in Azure

Governance in Google Cloud

Automation using IaC

AWS CloudFormation

Azure Resource Manager (ARM) templates

Google Cloud Deployment Manager

HashiCorp Terraform

Summary

Security in large-scale cloud environments

Managing security at a large scale while working with AWS

Managing security at a large scale while working with Azure

Managing security at a large scale while working with Google Cloud

Summary

What's next?

Plan ahead

Automate

Think big

Continue learning

Other Books You May Enjoy

Section 1: Securing Infrastructure Cloud Services

On completion of this part, you will have a solid understanding of how to secure the basic building blocks of cloud services (cloud deployment and service models, compute, storage, and network)

This part of the book comprises the following chapters:

Chapter 1, Introduction to Cloud SecurityChapter 2, Securing Compute ServicesChapter 3, Securing Storage ServicesChapter 4, Securing Network Services

Chapter 1: Introduction to Cloud Security

This book, Cloud Security Techniques and Best Practices, is meant for various audiences. You could be taking your first steps working with cloud services, or you could be coming from an IT perspective and want to know about various compute and storage services and how to configure them securely. Or, you might be working in information security and want to know the various authentication, encryption, and audit services and how to configure them securely, or you might be working with architecture and want to know how to design large-scale environments in the cloud in a secure way.

Reading this book will allow you to make the most of cloud services while focusing on security aspects. Before discussing cloud services in more detail, let me share my opinion regarding cloud services.

The world of IT is changing. For decades, organizations used to purchase physical hardware, install operating systems, and deploy software. This routine required a lot of ongoing maintenance (for patch deployment, backup, monitoring, and so on).

The cloud introduced a new paradigm – that is, the ability to consume managed services to achieve the same goal of running software (from file servers to Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) products), while using the expertise of the hyper-scale cloud providers.

Some well-known use cases of cloud computing are as follows:

Netflix – one of the largest video streaming services world-wide. It uses AWS to run its media streaming services:

https://aws.amazon.com/solutions/case-studies/netflix-case-study

Mercedes-Benz – one of the most famous automotive brands. It uses Azure to run its research and development:

https://customers.microsoft.com/en-us/story/784791-mercedes-benz-r-and-d-creates-container-driven-cars-powered-by-microsoft-azure

Home Depot – the largest home improvement retailer in the United States. It uses Google Cloud to run its online stores:

https://cloud.google.com/customers/featured/the-home-depot

In this book, we will compare various aspects of cloud computing (from fundamental services such as compute, storage, and networking, to compliance management and best practices for building and maintaining large-scale environments in a secure way), while reviewing the different alternatives offered by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

It does not matter which organization you are coming from – this book will allow you to have a better understanding of how to achieve security in any of the large hyper-scale cloud providers.

You do not have to read everything – simply find out which cloud provider is common at your workplace or which cloud provider you wish to focus on, and feel free to skip the rest.

In this chapter, we will cover the following topics:

Why we need securityCloud service modelsCloud deployment modelsThe shared responsibility model

Technical requirements

This chapter is an introduction to cloud security, so there are no technical requirements.

What is a cloud service?

As part of this introduction, let's define the terminology to make sure we are all on the same page.

The National Institute of Standards and Technology (NIST) defines cloud as a technology that has the following five characteristics:

On-demand self-service: Imagine you wish to open a blog and you need compute resources. Instead of purchasing hardware and waiting for the vendor to ship it to your office and having to deploy software, the easier alternative can be a self-service portal, where you can select a pre-installed operating system and content management system that you can deploy within a few minutes by yourself.Broad network access: Consider having enough network access (the type that large Internet Service Providers (ISPs) have) to serve millions of end users with your application.Resource pooling: Consider having thousands of computers, running in a large server farm, and being able to maximize their use (from CPU, memory, and storage capacity), instead of having a single server running 10% of its CPU utilization.Rapid elasticity: Consider having the ability to increase and decrease the amount of compute resources (from a single server to thousands of servers, and then back to a single server), all according to your application or service needs.Measured service: Consider having the ability to pay for only the resources you consumed and being able to generate a billing report that shows which resources have been used and how much you must pay for the resources.

Further details relating to the NIST definition can be found at the following link:

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

What are the cloud deployment models?

Now that we understand what the cloud characteristics are, let's talk about cloud deployment models:

Private cloud: An infrastructure deployed and maintained by a single organization. Let's say we are a large financial organization (such as a bank or insurance organization), we would like to serve various departments in our organization (from HR, IT, sales, and so on), and we might have regulatory requirements to keep customers' data on-premises – a private cloud can be a suitable solution.Public cloud: An infrastructure deployed and maintained by a service provider for serving multiple customers and organizations, mostly accessible over the internet. Naturally, this book will focus on the public cloud model, with reference to various services offered by AWS, Azure, and GCP.Hybrid cloud: A combination of a private cloud (or on-premises cloud) and at least one public cloud infrastructure. I like to consider the hybrid cloud as an extension of the local data center. We should not consider this extension as something separate, and we should protect it the same way we protect our local data center.Multi-cloud: A scenario where our organization is either using multiple managed services (see the definition of SaaS in the next section) or using multiple public cloud infrastructure (see the definitions of IaaS and PaaS in the next section).

What are the cloud service models?

An essential part of understanding clouds is understanding the three cloud service models:

Infrastructure as a Service (IaaS): This is the most fundamental service model, where a customer can select the virtual machine size (in terms of the amount of CPU and memory), select a pre-configured operating system, and deploy software inside the virtual machine instance according to business needs (services such as AmazonEC2, AzureVirtual Machines, and GoogleCompute Engine).Platform as a Service (PaaS): This type of service model varies from managed database services to managed application services (where a customer can import code and run it inside a managed environment) and more (services such as AWSElastic Beanstalk, AzureWeb Apps, and Google App Engine).Software as a Service (SaaS): This is the most widely used service model – a fully managed software environment where, as a customer, you usually open a web browser, log in to an application, and consume services. These could be messaging services, ERP, CRM, business analytics, and more (services such as MicrosoftOffice 365, GoogleWorkspaces, Salesforce CRM, SAPSuccessFactors, and OracleCloud HCM).

Understanding the cloud service models will allow you to understand your role as a customer, explained later in the What is the shared responsibility model? section.

Why we need security

As mentioned previously, we can see clear benefits of using cloud services that enable our business to focus on what brings us value (from conducting research in a pharmaceutical lab, to selling products on a retail site, and so on).

But what about security? And, specifically, cloud security?

Why should our organization focus on the overhead called information security (and, in the context of this book, cloud security)?

The cloud has changed the paradigm of organizations controlling their data on-premises (from HR data to customers' data) and investing money in maintaining data centers, servers, storage, network equipment, and the application tier.

Using public clouds has changed the way organizations look at information security (in the context of this book, cloud security).

The following are a few common examples of the difference between on-premises data solutions and the cloud:

Table 1.1 – Differences between on-premises data solutions and the cloud

Organizations are often unwilling to migrate to a public cloud for security reasons because the physical servers are located outside of the organization's direct control, and sometimes even outside their physical geography.

Here are a few questions often asked by organizations' management:

Are my servers going to behave the same as if they were on-premises?How do I protect my servers outside my data center from a data breach?How do I know the cloud provider will not have access to my data?Do my employees have enough knowledge to work in new environments such as the public cloud?

Perhaps the most obvious question asked is – is the public cloud secure enough to store my data?

From my personal experience, the answer is yes.

By design, the hyper-scale cloud providers invest billions of dollars protecting their data centers, building secure services, investing in employee training, and locating security incidents and remediating them fast. This is all with much higher investment, attention, and expertise than most organizations can dedicate to protecting their local data centers.

The reason for this is simple – if a security breach happens to one of the hyper-scale cloud providers, their customers' trust will be breached, and the cloud providers will run out of business.

At the end of the day, cloud security enables our organization to achieve (among other things) the following:

Decreased attack surface: Using central authentication, data encryption, DDoS protection services, and moreCompliance with regulation: Deploying environments according to best practicesStandardization and best practices: Enforcing security using automated tools and services

Reading this book will allow you to have a better understanding of various methods to secure your cloud environments – most of them using the cloud vendor's built-in services and capabilities.

What is the shared responsibility model?

When speaking about cloud security and cloud service models (IaaS/PaaS/SaaS), the thing that we all hear about is the shared responsibility model, which tries to draw a line between the cloud provider and the customer's responsibilities regarding security.

As you can see in the following diagram, the cloud provider is always responsible for the lower layers – from the physical security of their data centers, through networking, storage, host servers, and the virtualization layers:

Figure 1.1 – The shared responsibility model

Above the virtualization layer is where the responsibility begins to change.

When working with IaaS, we, as the customers, can select a pre-installed image of an operating system (with or without additional software installed inside the image), deploy our applications, and manage permissions to access our data.

When working with PaaS, we, as the customers, may have the ability to control code in a managed environment (services such as AWS Elastic Beanstalk, Azure Web Apps, and Google App Engine) and manage permissions to access our data.

When working with SaaS, we, as the customers, received a fully managed service, and all we can do is manage permissions to access our data.

In the next sections, we will look at how the various cloud providers (AWS, Azure, and GCP) look at the shared responsibility model from their own perspective.

For more information on the shared responsibility model, you can check the following link: https://tutorials4sharepoint.wordpress.com/2020/04/24/shared-responsibility-model/.

AWS and the shared responsibility model

Looking at the shared responsibility model from AWS's point of view, we can see the clear distinction between AWS's responsibility for the security of the cloud (physical hardware and the lower layers such as host servers, storage, database, and network) and the customer's responsibility for security in the cloud (everything the customer controls – operating system, data encryption, network firewall rules, and customer data). The following diagram depicts AWS and the shared responsibility model:

Figure 1.2 – AWS and the shared responsibility model

As a customer of AWS, reading this book will allow you to gain the essential knowledge and best practices for using common AWS services (including compute, storage, networking, authentication, and so on) in a secure way.

More information on the AWS shared responsibility model can be found at the following link: https://aws.amazon.com/blogs/industries/applying-the-aws-shared-responsibility-model-to-your-gxp-solution/.

Azure and the shared responsibility model

Looking at the shared responsibility model from Azure's point of view, we can see the distinction between Azure's responsibility for its data centers (physical layers) and the customer's responsibility at the top layers (identities, devices, and customers' data). In the middle layers (operating system, network controls, and applications) the responsibility changes between Azure and the customers, according to various service types. The following diagram depicts Azure and the shared responsibility model:

Figure 1.3 – Azure and the shared responsibility model

As a customer of Azure, reading this book will allow you to gain the essential knowledge and best practices for using common Azure services (including compute, storage, networking, authentication, and others) in a secure way.

More information on the Azure shared responsibility model can be found at the following link: https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility.

GCP and the shared responsibility model

Looking at the shared responsibility model from GCP's point of view, we can see that Google would like to emphasize that it builds its own hardware, which enables the company to control the hardware, boot, and kernel of its platform, including the storage layer encryption, network equipment, and logging of everything that Google is responsible for.

When looking at things that the customer is responsible for we can see a lot more layers, including everything from the guest operating system, network security rules, authentication, identity, and web application security, to things such as deployment, usage, access policies, and content (customers' data). The following diagram depicts GCP and the shared responsibility model:

Figure 1.4 – GCP and the shared responsibility model

As a customer of GCP, reading this book will allow you to gain the essential knowledge and best practices for using common GCP services (including compute, storage, networking, authentication, and more) in a secure way.

More information about the GCP shared responsibility model can be found at the following link: https://services.google.com/fh/files/misc/google-cloud-security-foundations-guide.pdf.

As a customer, understanding the shared responsibility model allows you, at any given time, to understand which layers are under the cloud vendor's responsibility and which layers are under the customer's responsibility.

Command-line tools

One of the things that makes cloud environments so robust is the ability to control almost anything using the Application Programming Interface (API) or using the command line.

Most mature cloud providers have already published and maintain their own Command-Line Interface (CLI) to allow customers to perform actions in an easy and standard way.

An alternative to using the command line to interact with the cloud provider's API is using a Software Developer Kit (SDK) – a method to control actions (from deploying a virtual machine to encrypting storage), query information from a service (checking whether auditing is enabled for my customers logging into my web application), and more.

Since this book doesn't require previous development experience, I will provide examples for performing actions using the command-line tools.

During various chapters of this book, I will provide you with examples of commands that will allow you to easily implement the various security controls over AWS, Azure, and GCP.

I highly recommend that you become familiar with those tools.

AWS CLI

AWS CLI can be installed on Windows (64 bit), Linux (both x86 and ARM processors), macOS, and even inside a Docker container.

The AWS CLI documentation explains how to install the tool and provides a detailed explanation of how to use it.

The documentation can be found at https://aws.amazon.com/cli.

Azure CLI

Azure CLI can be installed on Windows, Linux (Ubuntu, Debian, RHEL, CentOS, Fedora, openSUSE), and macOS.

The Azure CLI documentation explains how to install the tool and provides a detailed explanation of how to use it.

The documentation can be found at https://docs.microsoft.com/en-us/cli/azure.

Google Cloud SDK

The Google command-line tool (gcloudCLI) can be installed on Windows, Linux (Ubuntu, Debian, RHEL, CentOS, Fedora), and macOS.

The Google Cloud SDK documentation explains how to install the tool and provides a detailed explanation of how to use it.

The documentation can be found at https://cloud.google.com/sdk.

Summary

In the first chapter of this book, we learned the definition of a cloud, the different cloud deployment models, and the different cloud service models.

We also learned what the shared cloud responsibility model is, and how AWS, Azure, and GCP look at this concept from their own point of view.

Lastly, we had a short introduction to the AWS, Azure, and GCP built-in command-line tools, and, during the next chapters, I will provide you with examples of how to implement various tasks using the command-line tools.

This introduction will be referred to in the following chapters, where we will dive deeper into the best practices for securing cloud services using (in most cases) the cloud providers' built-in capabilities.

Securing cloud environments can be challenging, depending on your previous knowledge in IT or information security or cloud services in general.

Reading this book will assist you in gaining the necessary knowledge of how to secure cloud environments, regardless of your role in the organization or your previous experience.

In the next chapter, we will review the various compute services in the cloud (including virtual machines, managed databases, container services, and finally serverless services).

Chapter 2: Securing Compute Services

Speaking about cloud services, specifically Infrastructure as a Service (IaaS), the most common resource everyone talks about is compute – from the traditional virtual machines (VMs), through managed databases (run on VMs on the backend), to modern compute architecture such as containers and eventually serverless.

This chapter will cover all types of compute services and provide you with best practices on how to securely deploy and manage each of them.

In this chapter, we will cover the following topics:

Securing VMs (authentication, network access control, metadata, serial console access, patch management, and backups)Securing Managed Database Services (identity management, network access control, data protection, and auditing and monitoring)Securing Containers (identity management, network access control, auditing and monitoring, and compliance)Securing serverless/function as a service (identity management, network access control, auditing and monitoring, compliance, and configuration change)

Technical requirements

For this chapter, you need to have an understanding of VMs, what managed databases are, and what containers (and Kubernetes) are, as well as a fundamental understanding of serverless.

Securing VMs

Each cloud provider has its own implementation of VMs (or virtual servers), but at the end of the day, the basic idea is the same:

Select a machine type (or size) – a ratio between the amount of virtual CPU (vCPU) and memory, according to their requirements (general-purpose, compute-optimized, memory-optimized, and so on).Select a preinstalled image of an operating system (from Windows to Linux flavors).Configure storage (adding additional volumes, connecting to file sharing services, and others).Configure network settings (from network access controls to micro-segmentation, and others).Configure permissions to access cloud resources.Deploy an application.Begin using the service.Carry out ongoing maintenance of the operating system.

According to the shared responsibility model, when using IaaS, we (as the customers) are responsible for the deployment and maintenance of virtual servers, as explained in the coming section.

Next, we are going to see what the best practices are for securing common VM services in AWS, Azure, and GCP.

Securing Amazon Elastic Compute Cloud (EC2)

Amazon EC2 is the Amazon VM service.

General best practices for EC2 instances

Following are some of the best practices to keep in mind:

Use only trusted AMI when deploying EC2 instances.Use a minimal number of packages inside an AMI, to lower the attack surface.Use Amazon built-in agents for EC2 instances (backup, patch management, hardening, monitoring, and others).Use the new generation of EC2 instances, based on the AWS Nitro System, which offloads virtualization functions (such as network, storage, and security) to dedicated software and hardware chips. This allows the customer to get much better performance, with much better security and isolation of customers' data.

For more information, please refer the following resources:

Best practices for building AMIs:

https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html

Amazon Linux AMI:

https://aws.amazon.com/amazon-linux-2/

AWS Nitro System:

https://aws.amazon.com/ec2/nitro/

Best practices for authenticating to an instance

AWS does not have access to customers' VMs.

It doesn't matter whether you choose to deploy a Windows or a Linux machine, by running the EC2 launch deployment wizard, you must choose either an existing key pair or create a new key. This set of private/public keys is generated at the client browser – AWS does not have any access to these keys, and therefore cannot log in to your EC2 instance.

For Linux instances, the key pair is used for logging in to the machine via the SSH protocol.

Refer to the following link: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html.

For Windows instances, the key pair is used to retrieve the built-in administrator's password.

Refer to the following link: https://docs.amazonaws.cn/en_us/AWSEC2/latest/WindowsGuide/ec2-windows-passwords.html.

The best practices are as follows:

Keep your private keys in a secured location. A good alternative for storing and retrieving SSH keys is to use AWS Secrets Manager.Avoid storing private keys on a bastion host or any instance directly exposed to the internet. A good alternative to logging in using SSH, without an SSH key, is to use AWS Systems Manager, through Session Manager.Join Windows or Linux instances to an Active Directory (AD) domain and use your AD credentials to log in to the EC2 instances (and avoid using local credentials or SSH keys completely).

For more information, please refer the following resources:

How to use AWS Secrets Manager to securely store and rotate SSH key pairs:

https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-manager-securely-store-rotate-ssh-key-pairs/

Allow SSH connections through Session Manager:

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html

Seamlessly join a Windows EC2 instance:

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html

Seamlessly join a Linux EC2 instance to your AWS-managed Microsoft AD directory:

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/seamlessly_join_linux_instance.html

Best practices for securing network access to an instance

Access to AWS resources and services such as EC2 instances is controlled via security groups (at the EC2 instance level) or a network access control list (NACL) (at the subnet level), which are equivalent to the on-premises layer 4 network firewall or access control mechanism.

As a customer, you configure parameters such as source IP (or CIDR), destination IP (or CIDR), destination port (or predefined protocol), and whether the port is TCP or UDP.

You may also use another security group as either the source or destination in a security group.

For remote access and management of Linux machines, limit inbound network access to TCP port 22.

For remote access and management of Windows machines, limit inbound network access to TCP port 3389.

The best practices are as follows:

For remote access protocols (SSH/RDP), limit the source IP (or CIDR) to well-known addresses. Good alternatives for allowing remote access protocols to an EC2 instance are to use a VPN tunnel, use a bastion host, or use AWS Systems Manager Session Manager.For file sharing protocols (CIFS/SMB/FTP), limit the source IP (or CIDR) to well-known addresses.Set names and descriptions for security groups to allow a better understanding of the security group's purpose.Use tagging (that is, labeling) for security groups to allow a better understanding of which security group belongs to which AWS resources.Limit the number of ports allowed in a security group to the minimum required ports for allowing your service or application to function.

For more information, please refer the following resources:

Amazon EC2 security groups for Linux instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html

Security groups for your virtual private cloud (VPC): https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

AWS Systems Manager Session Manager:

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html

Compare security groups and network ACLs:

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html#VPC_Security_Comparison

Best practices for securing instance metadata

Instance metadata is a method to retrieve information about a running instance, such as the hostname and internal IP address.

An example of metadata about a running instance can be retrieved from within an instance, by either opening a browser from within the operating system or using the command line, to a URL such as http://169.254.169.254/latest/meta-data/.

Even though the IP address is an internal IP (meaning it cannot be accessed from outside the instance), the information, by default, can be retrieved locally without authentication.

AWS allows you to enforce authenticated or session-oriented requests to the instance metadata, also known as Instance Metadata Service Version 2 (IMDSv2).

The following command uses the AWS CLI tool to enforce IMDSv2 on an existing instance:

aws ec2 modify-instance-metadata-options \

    --instance-id <INSTANCE-ID> \

    --http-endpoint enabled --http-tokens required

For more information, please refer the following resource:

Configure the instance metadata service:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

Best practices for securing a serial console connection

For troubleshooting purposes, AWS allows you to connect using a serial console (a similar concept to what we used to have in the physical world with network equipment) to resolve network or operating system problems when SSH or RDP connections are not available.

The following command uses the AWS CLI tool to allow serial access at the AWS account level to a specific AWS Region:

aws ec2 enable-serial-console-access --region <Region_Code>

Since this type of remote connectivity exposes your EC2 instance, it is recommended to follow the following best practices:

Access to the EC2 serial console should be limited to the group of individuals using identity and access management (IAM) roles.Only allow access to EC2 serial console when required.Always set a user password on an instance before allowing the EC2 serial console.

For more information, please refer the following resource:

Configure access to the EC2 serial console:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-access-to-serial-console.html

Best practices for conducting patch management

Patch management is a crucial part of every instance of ongoing maintenance.

To deploy security patches for either Windows or Linux-based instances in a standard manner, it is recommended to use AWS Systems Manager Patch Manager, following this method:

Configure the patch baseline.Scan your EC2 instances for deviation from the patch baseline at a scheduled interval.Install missing security patches on your EC2 instances.Review the Patch Manager reports.

The best practices are as follows:

Use AWS Systems Manager Compliance to make sure all your EC2 instances are up to date.Create a group with minimal IAM privileges to allow only relevant team members to conduct patch deployment.Use tagging (that is, labeling) for your EC2 instances to allow patch deployment groups per tag (for example, prod versus dev environments).For stateless EC2 instances (where no user session data is stored inside an EC2 instance), replace an existing EC2 instance with a new instance, created from an up-to-date operating system image.

For more information, please refer the following resource:

Software patching with AWS Systems Manager:

https://aws.amazon.com/blogs/mt/software-patching-with-aws-systems-manager/

Best practices for securing backups

Backing up is crucial for EC2 instance recovery.

The AWS Backup service encrypts your backups in transit and at rest using AWS encryption keys, stored in AWS Key Management Service (KMS) (as explained in Chapter 7, Applying Encryption in Cloud Services), as an extra layer of security, independent of your Elastic Block Store (EBS) volume or snapshot encryption keys.

The best practices are as follows:

Configure the AWS Backup service with an IAM role to allow access to the encryption keys stored inside AWS KMS.Configure the AWS Backup service with an IAM role to allow access to your backup vault.Use tagging (that is, labeling) for backups to allow a better understanding of which backup belongs to which EC2 instance.Consider replicating your backups to another region.

For more information, please refer the following resources:

Protecting your data with AWS Backup:

https://aws.amazon.com/blogs/storage/protecting-your-data-with-aws-backup/

Creating backup copies across AWS Regions:

https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html

Summary

In this section, we have learned how to securely maintain a VM, based on AWS infrastructure – from logging in to securing network access, troubleshooting using a serial console, patch management, and backup.

Securing Azure Virtual Machines

Azure Virtual Machines is the Azure VM service.

General best practices for Azure Virtual Machines

Following are some of the best practices to keep in mind:

Use only trusted images when deploying Azure Virtual Machines.Use a minimal number of packages inside an image, to lower the attack surface.Use Azure built-in agents for Azure Virtual Machines (backup, patch management, hardening, monitoring, and others).For highly sensitive environments, use Azure confidential computing images, to ensure security and isolation of customers' data.

For more information, please refer the following resources:

Azure Image Builder overview:

https://docs.microsoft.com/en-us/azure/virtual-machines/image-builder-overview

Using Azure for cloud-based confidential computing:

https://docs.microsoft.com/en-us/azure/confidential-computing/overview#using-azure-for-cloud-based-confidential-computing-

Best practices for authenticating to a VM

Microsoft does not have access to customers' VMs.

It doesn't matter whether you choose to deploy a Windows or a Linux machine, by running the create a virtual machine wizard, to deploy a new Linux machine, by default, you must choose either an existing key pair or create a new key pair.

This set of private/public keys is generated at the client side – Azure does not have any access to these keys, and therefore cannot log in to your Linux VM.

For Linux instances, the key pair is used for logging in to the machine via the SSH protocol.

For more information, please refer the following resource:

Generate and store SSH keys in the Azure portal:

https://docs.microsoft.com/en-us/azure/virtual-machines/ssh-keys-portal

For Windows machines, when running the create a new virtual machine wizard, you are asked to specify your own administrator account and password to log in to the machine via the RDP protocol.

For more information, please refer the following resource:

Create a Windows VM:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-portal#create-virtual-machine

The best practices are as follows:

Keep your credentials in a secured location.Avoid storing private keys on a bastion host (VMs directly exposed to the internet).Join Windows or Linux instances to an AD domain and use your AD credentials to log in to the VMs (and avoid using local credentials or SSH keys completely).

For more information, please refer the following resources:

Azure Bastion:

https://azure.microsoft.com/en-us/services/azure-bastion

Join a Windows Server VM to an Azure AD Domain Services-managed domain using a Resource Manager template:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/join-windows-vm-template

Join a Red Hat Enterprise Linux VM to an Azure AD Domain Services-managed domain:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm

Best practices for securing network access to a VM

Access to Azure resources and services such as VMs is controlled via network security groups, which are equivalent to the on-premises layer 4 network firewall or access control mechanism.

As a customer, you configure parameters such as source IP (or CIDR), destination IP (or CIDR), source port (or a predefined protocol), destination port (or a predefined protocol), whether the port is TCP or UDP, and the action to take (either allow or deny).

For remote access and management of Linux machines, limit inbound network access to TCP port 22.

For remote access and management of Windows machines, limit inbound network access to TCP port 3389.

The best practices are as follows:

For remote access protocols (SSH/RDP), limit the source IP (or CIDR) to well-known addresses. Good alternatives for allowing remote access protocols to an Azure VM is to use a VPN tunnel, use Azure Bastion, or use Azure Privileged Identity Management (PIM) to allow just-in-time access to a remote VM.For file sharing protocols (CIFS/SMB/FTP), limit the source IP (or CIDR) to well-known addresses.Set names for network security groups to allow a better understanding of the security group's purpose.Use tagging (that is, labeling) for network security groups to allow a better understanding of which network security group belongs to which Azure resources.Limit the number of ports allowed in a network security group to the minimum required ports for allowing your service or application to function.

For more information, please refer the following resources:

Network security groups:

https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview

How to open ports to a VM with the Azure portal:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/nsg-quickstart-portal

Azure Bastion:

https://azure.microsoft.com/en-us/services/azure-bastion

What is Azure AD PIM?

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure

Best practices for securing a serial console connection

For troubleshooting purposes, Azure allows you to connect using a serial console (a similar concept to what we used to have in the physical world with network equipment) to resolve network or operating system problems when SSH or RDP connections are not available.

The following commands use the Azure CLI tool to allow serial access for the entire Azure subscription level:

subscriptionId=$(az account show --output=json | jq -r .id)

az resource invoke-action --action enableConsole \

    --ids "/subscriptions/$subscriptionId/providers/Microsoft.SerialConsole/consoleServices/default" --api-version="2018-05-01"

Since this type of remote connectivity exposes your VMs, it is recommended to follow the following best practices:

Access to the serial console should be limited to the group of individuals with the Virtual Machine Contributor role for the VM and the Boot diagnostics storage account.Always set a user password on the target VM before allowing access to the serial console.

For more information, please refer the following resources:

Azure serial console for Linux:

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-linux

Azure serial console for Windows:

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-windows

Best practices for conducting patch management

Patch management is a crucial part of every instance of ongoing maintenance.

To deploy security patches for either Windows or Linux-based instances in a standard manner, it is recommended to use Azure Automation Update Management, using the following method:

Create an automation account.Enable Update Management for all Windows and Linux machines.Configure the schedule settings and reboot options.Install missing security patches on your VMs.Review the deployment status.

The best practices are as follows:

Use minimal privileges for the account using Update Management to deploy security patches.Use update classifications to define which security patches to deploy.When using an Azure Automation account, encrypt sensitive data (such as variable assets).When using an Azure Automation account, use private endpoints to disable public network access.Use tagging (that is, labeling) for your VMs to allow defining dynamic groups of VMs (for example, prod versus dev environments).For stateless VMs (where no user session data is stored inside an Azure VM), replace an existing Azure VM with a new instance, created from an up-to-date operating system image.

For more information, please refer the following resources:

Azure Automation Update Management:

https://docs.microsoft.com/en-us/azure/architecture/hybrid/azure-update-mgmt

Manage updates and patches for your VMs:

https://docs.microsoft.com/en-us/azure/automation/update-management/manage-updates-for-vm

Update management permissions:

https://docs.microsoft.com/en-us/azure/automation/automation-role-based-access-control#update-management-permissions

Best practices for securing backups

Backing up is crucial for VM recovery.

The Azure Backup service encrypts your backups in transit and at rest using Azure Key Vault (as explained in Chapter 7, Applying Encryption in Cloud Services).

The best practices are as follows:

Use Azure role-based access control (RBAC) to configure Azure Backup to have minimal access to your backups.For sensitive environments, encrypt data at rest using customer-managed keys.