34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Security issues are still a major concern for all IT organizations. For many enterprises, the move to cloud computing has raised concerns for security, but when applications are architected with focus on security, cloud platforms can be made just as secure as on-premises platforms. Cloud instances can be kept secure by employing security automation that helps make your data meet your organization's security policy. This book starts with the basics of why cloud security is important and how automation can be the most effective way of controlling cloud security. You will then delve deeper into the AWS cloud environment and its security services by dealing with security functions such as Identity and Access Management and will also learn how these services can be automated. Moving forward, you will come across aspects such as cloud storage and data security, automating cloud deployments, and so on. Then, you'll work with OpenStack security modules and learn how private cloud security functions can be automated for better time- and cost-effectiveness. Toward the end of the book, you will gain an understanding of the security compliance requirements for your Cloud. By the end of this book, you will have hands-on experience of automating your cloud security and governance.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 311
Veröffentlichungsjahr: 2018
Ähnliche
Cloud Security Automation
Copyright © 2018 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.
Commissioning Editor: Gebin GeorgeAcquisition Editor: Rohit RajkumarContent Development Editor: Nithin VargheseTechnical Editor: Khushbu SutarCopy Editors: Safis Editing, Laxmi SubramanianProject Coordinator: Virginia DiasProofreader: Safis EditingIndexer: Aishwarya GangawaneGraphics: Tom ScariaProduction Coordinator: Shraddha Falebhai
First published: March 2018
Production reference: 1270318
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78862-786-3
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Prashant Priyam is an astute professional with a great deal of experience in cloud technologies, specifically requirement analysis, solution architecture, design, and delivery. He also has experience in cloud services and solutions, cloud consultancy and deployment, and data center services.
About the reviewers
Fabio Alessandro Locati, commonly known as Fale—is the director of Otelia, a public speaker, author, and open source contributor. His main areas of expertise are Linux, automation, security, and cloud technologies. Fale has over 12 years, working experience in IT; many of those years were spent consulting for many companies, including dozens of Fortune 500 companies. This has allowed him to consider technologies from different points of view and to develop critical thinking about them.
Deep Mehta is currently working as a DevOps engineer in the San Francisco Bay Area. He is currently working with different clients to help them to improve their CI/CD and DevOps cycles. He helps them to follow the microservices pattern and create resilient and fault tolerant infrastructure. Deep is mainly interested in distributed systems, containers, data science, and the cloud. He also worked as a reviewer on the book, Learning Continuous Integration with Jenkins.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Cloud Security Automation
Packt Upsell
Why subscribe?
PacktPub.com
Contributors
About the author
About the reviewers
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Download the color images
Conventions used
Get in touch
Reviews
Disclaimer
Introduction to Cloud Security
Types of cloud
Public cloud
Private cloud
Hybrid cloud
Software as a Service
Platform as a Service
Infrastructure as a Service
Cloud security
Confidentiality
Integrity
Availability
Authentication
Authorization
Auditing
Shared responsibility model
Shared responsibility model for infrastructure 
Shared responsibility model for container service
Shared responsibility model for abstract services
Key concern areas of cloud security
Infrastructure level
User access level 
Storage and data level 
Application access level
Network level
Logging and monitoring level
Summary
Understanding the World of Cloud Automation
What is DevOps?
Why do we need automation?
Infrastructure as Code
Configuration management
Automate deployment – AWS OpsWorks
Quick recap
Summary
Identity and Access Management in the Cloud
IAM features
How does AWS work in IAM?
Anatomy of IAM users, groups, roles, and policies 
IAM users
IAM groups
IAM roles
IAM policies
Access right delegation using IAM 
Temporary credentials
Cross-account access
Identity federation
IAM best practices
Other security options in AWS
AWS Certificate Manager
WAF and Shield
Cloud hardware security module
Cognito
Amazon Macie
AWS Inspector
AWS GuardDuty
Quick recap
Summary
Cloud Network Security
Virtual private cloud
NACL
Security group
VPN connection
Direct Connect
DNS security
CDN-level security
Logging and monitoring
CloudTrail
CloudWatch
Quick recap
Summary
Cloud Storage and Data Security
EBS
Fault tolerance at EBS
RAID 0
RAID 1
Encryption in EBS
S3
Security in S3
AWS Glacier 
Security in AWS Glacier
EFS 
Security in EFS
Storage gateway
Security in the storage gateway
AWS Snowball
Security in Snowball
A quick recap
Summary
Cloud Platform Security
RDS
Security in RDS
Using security groups
Using IAM
Using SSL to encrypt database connections
Security best practices for AWS RDS 
Back up and restore database
Monitoring of RDS
AWS Redshift 
Security in Redshift
AWS DynamoDB
Security in DynamoDB
ElastiCache 
Securing ElastiCache
VPC-level security
Authentication and access control
Authenticating with Redis authentication
Data encryption
Data-in-transit encryption
Data-at-rest encryption
AWS ECS
Securing ECS
SQS
Securing SQS
Let's have a recap
Summary
Private Cloud Security
Securing hypervisor
Securing  KVM
Securing XenServer
Securing ESXi
Securing compute 
IAM
Authentication
Authentication methods – internal and external
Authorization
Policy, tokens, and domains
Federated identity
Horizon – OpenStack dashboard service
Cinder – OpenStack block storage
Glance – OpenStack image storage
Manila – OpenStack shared file storage
Neutron – OpenStack network
Swift – OpenStack object storage
Message queue 
Database services
Data privacy and security for tenants
Security for instances
Quick recap
Summary
Automating Cloud Security
Infrastructure as Code
CI/CD
Monitoring
Summary
Cloud Compliance
Cloud security compliance
Security compliance – ISMS
Security compliance – PCI DSS
Quick recap
Summary
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
Security is critical for organizations when they are planning to run, or are already running, their workload on the cloud. On the cloud, security also comes under the sharing responsibility model, where the cloud provider and cloud consumer have defined boundaries for their security responsibilities based on cloud services (IaaS, PaaS, or SaaS).
On a private cloud, one has to take complete responsibility for security, from physical components to the application itself.
In addition to security, organizations also have to meet compliance requirements if they are applicable.
Although there are different sets of security tools and services available on AWS, it's always the customers'/users' responsibility to use these tools and services effectively to ensure the security of their data and applications and to meet compliance requirements.
This book is a comprehensive learning guide to securing your cloud account's structure in AWS and the OpenStack environment. It also gives you insight on how DevOps processes can help you to automate the security processes.
Who this book is for
This book is targeted at DevOps engineers, security professionals, and any stakeholders responsible for securing cloud workloads. Prior experience with AWS or OpenStack will be an advantage.
What this book covers
Chapter 1, Introduction to Cloud Security, helps you understand cloud security models for the public cloud (AWS) and OpenStack at different levels for different services.
Chapter 2, Understanding the World of Cloud Automation, introduces the basics of automation, the automation process, tools and requirements, and the benefits of cloud automation.
Chapter 3, Identity and Access Management in the Cloud, gives you an in-depth understanding of IAM and other AWS services, such as Inspector, WAF, HSM, and Certificate Manager, in order to improve security.
Chapter 4, Cloud Network Security, talks about different components, such as NACL, security groups, and VPN, that help us to ensure the security of data in transit.
Chapter 5, Cloud Storage and Data Security, gives you an in-depth understanding of how to secure storage and data accessibility using data encryption and IAM roles and policies.
Chapter 6, Cloud Platform Security, discusses how to ensure security for PaaS services, such as database and analytics services.
Chapter 7, Private Cloud Security, explains how to secure your private cloud on the compute, network, and storage and application levels.
Chapter 8, Automating Cloud Security, helps you understand automation and the role of automation in securing cloud infrastructure.
Chapter 9, Cloud Compliance, introduces you to different aspects of security compliance for the cloud and how to make a solution compliant with ISMS and PCI DSS.
To get the most out of this book
Readers should have a basic understanding of AWS, OpenStack, and CentOS.
An AWS user account is required. If you don't have a user account, ensure that you have your credit card ready in order to open a free account. (While we have taken care to use the free-tier systems in AWS, make sure that you use the appropriate instance sizes and AMI IDs if you are creating an environment in a different region.)
Download the example code files
You can download the example code files for this book from your account at www.packtpub.com. If you purchased this book elsewhere, you can visit www.packtpub.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packtpub.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub athttps://github.com/PacktPublishing/Cloud-Security-Automation. We also have other code bundles from our rich catalog of books and videos available athttps://github.com/PacktPublishing/. Check them out!
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/CloudSecurityAutomation_ColorImages.pdf.
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "We have selected the bucket called velocis-manali-trip-112017."
A block of code is set as follows:
{ "Sid": "AllowCreationOfServiceLinkedRoles", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": "*"}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
{ "Sid": "AllowCreationOfServiceLinkedRoles", "Effect": "Allow", "Action": [ "
iam:CreateServiceLinkedRole
" ], "Resource": "*"}
Any command-line input or output is written as follows:
wget https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
sudo bash install
Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "On the wizard, select Choose or create role, tag your instance, and install the AWS agent."
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
Disclaimer
The information within this book is intended to be used only in an ethical manner. Do not use any information from the book if you do not have written permission from the owner of the equipment. If you perform illegal actions, you are likely to be arrested and prosecuted to the full extent of the law. Packt Publishing does not take any responsibility if you misuse any of the information contained within the book. The information herein must only be used while testing environments with proper written authorizations from appropriate persons responsible.
Introduction to Cloud Security
In this chapter, we will learn the basics of the cloud and cloud security.
To understand cloud security, we first need to understand the types of clouds and their architecture. There are many global standard organizations such as NIST and CSA who are defining the different aspects of clouds.
As per the NIST definition of cloud computing (https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp), in simple terms we can say that the cloud offers on-demand accessibility of computing, networking, storage, databases, and applications. Here you do not have to worry about the purchase of physical boxes (CapEx) to run your application. You pay the cost of the resource based on the usage (OpEx).
CapEx stands for capital expenditures and denotes one-time cost investment to purchase any resource, for example, the purchase of a physical server.
OpEx stands for operating expenditures and denotes expenses to make the resource operational, for example, the purchase of manpower, power, OS, and so on to make the server operational.
We can say that the cloud provides abstraction of the underlying infrastructure using hypervisors and orchestrates to allocate resources to multiple tenants from the aggregated resource pool on demand.
The cloud offers multitenancy, agility, scalability, availability, and security. Let's understand what all these terms mean.
We will cover the following topics in this chapter:
Types of cloud
Cloud security
Shared responsibility model
Key concern areas of cloud security
Types of cloud
There are different models of the cloud. We broadly categorize them on the basis of deployment and service.
If we look at the cloud from a deployment perspective, there are three models.
Public cloud
This model of cloud is open to the public. This means that anyone can sign up and subscribe to set up their infrastructure to host their solution. For example, we have AWS, Microsoft Azure, Google Cloud Platform , IBM Cloud (SoftLayer), Alibaba Cloud, and so on.
Private cloud
This model of cloud is specific to an organization that wants to run their workload in a self-provisioned, secure way, internal to the organization. Organizations deploy private clouds using OpenStack, Apache CloudStack, Eucalyptus, OpenNebula, and so on as orchestration, and for hypervisors they are using VMware ESXi, XenServer, Hyper-V, KVM, and so on.
Hybrid cloud
This model of cloud combines the features of both private and public cloud, or you can say it integrates the public cloud and the on-premise hosted cloud. For example, suppose we have an internally deployed OpenStack cloud platform and now we want it to integrate with any of the public clouds. For this, there are multiple tools available that enable you to integrate both clouds and also facilitate you to lift and shift the workload to and fro. Recently, Cisco came up with a product called Cisco CloudCenter (formerly known as CliQr) providing the same facility.
On the basis of service, we categorize clouds into three parts, which we call the SPI model.
In the SPI model, S represents Software as a Service, P represents Platform as a Service, and I represents Infrastructure as a Service.
Software as a Service
In this model, an application running on the cloud is offered directly to the end consumer as a service. Being the end consumer, we subscribe the service and start using it. You do not have access to control and manage the infrastructure layer and platform. Here, you do not need to worry about the IT infrastructure, application, and security. In this model, the Software as a Service (SaaS) provider is responsible for managing the underlying infrastructure.
Platform as a Service
In this model, the cloud provider sets up a platform to develop your application or run your application. For example, AWS provides the relational database service (RDS) service, which is a DBMS service wherein you just need to subscribe the RDS service and dump your database and start using it. You need not worry about infrastructure, OS, and other operational stuff. Platform as a Service (PaaS) services can be accessed using the API too.
Infrastructure as a Service
IaaS stands for Infrastructure as a Service. In this model of cloud, you can subscribe to the complete infrastructure (networking, computing, and storage) that is required to run your application. Here, you will get the building blocks that you need to assemble to run your application as per your requirement. Suppose you want to run one web application that is developed in PHP and MySQL. To run this on the IaaS platform you need to subscribe to computing, networking, and storage. Now, you will configure each of them to run your application.
As we have now got a fair understanding of the cloud and cloud models, let's see the architecture so that we can correlate it when we start learning about the security aspects:
In the aforementioned architecture, we can see that the base layer of every cloud is a physical server, storage, and network. On top of it, we have installed the Virtualization Layer (hypervisor), which abstracts all the resources.
Before the hypervisor, we have the Orchestration Layer, which communicates with the Virtualization Layer and makes available resource chunks (computing, storage, and network) to be shared among the multiple tenants on demand.
The user logs in to the cloud dashboard to subscribe the resource and starts running their service or application on it.
One thing we can see here is that the Security layer starts from base and goes up until the top. This means that we need to focus on the security aspect at each layer (from the physical layer to the user layer).
Cloud security
Organizations started shifting their workload from on-premise physical infrastructures to the public cloud, or started to deploy their own private clouds to get all the benefits of the cloud. But security is a major concern, mostly in the case of the public cloud where we do not have control of the physical infrastructure. Also, there are compliance requirements that organizations need to match for example, ISO/IEC, NIST, FedRAMP, PCI DSS, HIPAA, and so on.
In this section, we will learn the basics of security and the security options available in the public cloud.
In any environment for security, we always start with the following models:
CIA
AAA
The CIA model focuses on Confidentiality, Integrity, and Availability. We also call it the CIA triad:
Confidentiality
Confidentiality denotes protecting the data from unauthorized access. We cannot disclose our data to everyone if it is critical, such as the bank statement, which includes all our financial transactions. We must ensure that a bank statement is disclosed only to our banker or the accountant who works on it. Similarly, this applies for an organization as well. In an organization, we have multiple departments and different roles. Here we define the roles for each user to access the information. Alternatively, you can say we define rules to decide who will access what.
Integrity
Integrity means protecting the data from unauthorized modification. All the data that we have in our organization is valuable. If it's modified this could be a huge loss for the organization. Let's take a financial statement as an example, which includes all the financial information of the organization. If it is tampered with or modified it can cause huge business losses. We must ensure that the data we are storing and that is being accessed by users is secure enough to maintain its integrity.
Availability
Availability denotes that the information is available to authorized users. If it isn't available to authorized users, again it will incur a loss. Information has value if the right people can access it at the right time. Almost every week you can find news about high profile websites being taken down by distributed denial of service (DDoS) attacks. The main aim of a DDoS attack is not to allow users with any website access to the resources of the website. Such downtime can be very costly.
Now coming onto the next model, the AAA model focuses on Authentication, Authorization, and Auditing.
Authentication
Only authenticated users should be able to access the data. The focus is on user validation, or authenticity of users. User validation is done with the user login credentials, or access keys, which are matched with the user database, LDAP, Active Directory, or key stores.
Authorization
Once the user is authenticated, there must be some authority defined for the user to access the data so that he can perform the required action. Basically, here we define the access policies and roles for users. Users with read permission should not be able to modify the data.
Auditing
Auditing does the accounting of user activity on data. Here, we log all the activity of users including login time, session duration, and all the activities that they perform.
The cloud offers multiple options to implement the security, but it solely depends upon the security requirement and our expertise to implement it.
One thing we need to understand is that implementing security in the cloud is a bit different from what we have been practicing with on-premise or traditional infrastructures.
We learned previously that the cloud runs on top of physical boxes, such as storage, servers, and networking equipment. All these resources are controlled by a layer of abstraction that we call a hypervisor or virtualization layer. Further, all the aggregated resources are being controlled and managed by an orchestration. Internally, all these layers communicate with each other through an application program interface (API).
In the cloud we can also start implementing security with CIA and AAA models. Here, we have the following services in the cloud to implement CIA and AAA models:
Confidentiality
: Here, we use
Identity and Access Management
(
IAM
) to define the resource accessibility permissions. In IAM, we can define users, groups, roles, and policies. IAM also helps to manage the API access using access keys and secret keys. Similarly, we have a keystone in OpenStack to define users, groups, roles, and policies. You can define policies to access the other
OpenStack
services and APIs.
Integrity
: For integrity, we have multiple types of encryption for the storage where data is stored and for data in transit we can use SSL. If we want to implement an additional layer of security, we can use the AWS CloudHSM module as well. In OpenStack, we have the following process to manage integrity. It starts from the bootstrap level and goes up until the file level. (We've studied this process in detail in the
Private cloud
section.)
Availability
: For availability, AWS offers you many services that ensure the service availability at different layers. We have Route 53 as DNS,
Elastic Load Balancing
(
ELB
), and autoscaling. All three services ensure that you have the service available in case of DDoS attacks as well. Availability of the application or solution also depends on how it is designed and deployed. Let's take an example of a web application; here, in order to ensure maximum availability of the application, we should always design the solution in such a way that there is no single point of failure. For this, we must consider
high availability
(
HA
), autoscaling, and also try to decouple the resources (using message queuing) so that it can be fault tolerant as well.
Now, let's map the AAA model in the cloud:
Authentication
: In AWS, we have IAM for user identity. Here, we can define users and groups. IAM enables you to define the password-based authentication and key-based authentication for users. Apart from this, for the application, we can use the AWS Directory Service and Cognito (token-based authentication) for user authentication. For console users, we can also enable
multi-factor authentication
(
MFA
) as well. In OpenStack, we have a keystone, which provides user and service authentication. Here, we also create users and groups and define password-based and key-based authentication for users. Apart from this, we can use SAML-based authentication, OAuth, and OpenID-based authentication.
Authorization
: For authorization, AWS uses IAM roles and policies. There are many predefined user roles for different services. Apart from this, we can define custom roles. For example, suppose we have an EC2 instance, that needs to access the
Simple Storage Service
(
S3
) resource and CloudWatch Logs. Here we can also define a custom role of an EC2 instance which grants access to the S3 bucket and CloudWatch Logs and binds that role with the EC2 instances. There is no need to store the access keys in text format on EC2 instances, but you will find that people are not practicing this. In the same way, if you need to manage multiple or linked accounts then you should define the role for cross-account access and use it instead of logging in using the root account. Similarly, in OpenStack, we have a keystone where we can define different roles and policies for users and groups. For each service, there is an associated access policy file defined in JSON format.
Auditing
: AWS provides CloudTrail to log all the action or activity for AWS services. Apart from this, we have
Virtual Private Cloud
(
VPC
) logs and ELB logs, which can be stored in the S3 bucket or can be transferred to CloudWatch Logs. For analysis, we can use the Elasticsearch service or query it using Athena. For solution auditing, you can use AWS Config and Trusted Advisor. Now we are moving toward machine learning and
Internet of Things
(
IoT
). For this, AWS started a new service called Macie, which uses machine learning to identify the accessibility of data and services. In OpenStack, we have a telemetry service called
Ceilometer
to store and manage logs. Apart from this, you can use custom monitoring solutions called
New Relic
.
Shared responsibility model
In the cloud, we can define stakeholders in two categories:
Cloud provider
: This is the one who provides cloud services
Cloud consumer
: This is the one who consumes cloud services
In cloud security, compliance is defined on the shared responsibility model. Here, the cloud provider is responsible for managing security and compliance at the physical infrastructure level, hypervisor level, physical network level, storage level, and orchestration layer.
The cloud consumer assumes responsibility for managing security and compliance from the virtual machine level to the application level.
In AWS it's a bit more clarified, and here the security responsibility model is defined in three different categories:
A shared responsibility model for infrastructure
A shared responsibility model for container service
A shared responsibility model for abstract service
Let's see the broad shared responsibility models of AWS:
In the shared responsibility model, the cloud provider (AWS) is responsible for managing security and compliance at the data center level or the physical infrastructure level, such as server, storage, and physical network.
The cloud consumers (end users) will be responsible for managing security and compliance from the guest OS level (security patches and updates); VPC security, such as configuration of security groups, network access control lists (ACLs); and other software configuration, as well as the integration of other services (for example, RDS, S3, Simple Queue Service (SQS), Simple Email Service (SES), and more).
In the shared security model, AWS is responsible for the security of infrastructure where all the AWS cloud service offering is running. Here, the infrastructure consists of all the hardware, software, and the physical perimeters.
The customer's responsibility is determined on the basis of the services they subscribe. For example, if the customer subscribed the EC2 instance, they need to ensure security of the guest OS and configuration. For S3, they need to define the ACL and roles. Similarly, for the RDS, they need to define passwords, security group policy, encryption, and backup policy.
For the customers to ensure the security at each level, there are many services that are already available, such as AWS Config, Trusted Advisor, IAM, X-Ray, and Macie, which helps to make your security work easier.
Now, let's look at the previously mentioned categories of the shared responsibility model.
Shared responsibility model for infrastructure
In this model, AWS is responsible for securing its virtualization, server, storage, physical network, and data center. The customer who has subscribed to the infrastructure service is responsible for defining security from the guest OS, application level, virtual network (VPC) level, data level, and finally, the user access level.
Shared responsibility model for container service
In AWS, we have container-based services. In computing, we have ECS, for databases, we have RDS, and so on. Here, AWS security responsibility goes higher up to the guest OS and platform level. Similar to RDS, AWS is responsible for managing security from the physical level to the database application level. Customers are only responsible for defining security at a subnet level, security group, encryption and password policy, and IAM roles.
Shared responsibility model for abstract services
AWS also provides abstract services such as SQS, SES, Simple Notification Service (SNS), and S3. For all these services, AWS is responsible for the complete security of the physical layer, virtualization layer, network level, storage, OS, software, and so on. Users or consumers need to define only the user-level permission and encryption if it is applicable for the service.
Now, let's understand the shared responsibility model in the cloud from the service perspective.
In IaaS, the cloud provider is responsible for only managing the physical infrastructure and security at the physical level. Being a user, we are responsible for the following:
VM level security
Application and data security
User management
Virtual network level security
In the case of IaaS, the API plays a significant role, as all the internal components talk to each other using the API via HTTP methods: GET, PUT, and DELETE. The API enables cloud consumers to access the service using the REST API (available in all the clouds). We will look at the use of APIs in the automation section and also learn about how automation uses APIs to speed up deployment and enhance security.
In the cloud, we have multiple options to apply security on all the aforementioned levels but it completely depends on us as to how we are utilizing it.
In the PaaS model, the cloud provider responsibility increases; it is responsible for managing the platform too. Here, the platform denotes the environment on which our application will run. For example, most of the cloud providers have Database as a Service. Here, the cloud provider is responsible for managing the physical infrastructure, compute, and OS level security. Being a user, we will focus on user management, virtual networks, and data security.
In the SaaS model, the cloud provider is responsible for providing end-to-end security until the application levels. We are only responsible for ensuring user management and data security. In AWS, there is no SaaS service, which is a part of the AWS cloud offering, but there are many partners who provide SaaS services. AWS equips you to ensure maximum security for your SaaS offering as well.
Key concern areas of cloud security
There are many agencies who are continuously working to define the global standards and also publish their recommendations for cloud computing.
Cloud Security Alliance (CSA) is one of them. It continuously works to address the security options of the cloud. CSA has identified key areas where we need to focus on cloud security:
Infrastructure level
User access level
Storage and data level
Application access level
Network level
Logging and monitoring level
Infrastructure level
Infrastructure level security is of the utmost importance. In a public cloud, the physical infrastructure is the cloud provider's responsibility. But in a private cloud, we must ensure the security at the infrastructure level as well. In OpenStack, all the components are separate services and they communicate with each other via APIs. It's very complex to ensure security at each level.
In OpenStack, we have services such as keystone, nova, and neutron, which have dependencies on their underlying databases. Here, it is always advisable that each database has its unique access credentials. This will help when any particular component gets compromised as it will not affect the other components.
Hypervisor in OpenStack must be enabled with SELinux or AppArmor. Most of the time, people disable it during configuration, but it's not recommended as it gives you a virtual boundary to protect your VMs. Apart from this, all the security patches must be deployed on the hypervisor.
There should always be an isolation between networks responsible for management, guest, and storage traffic. It's always preferred to have a separate VLAN for internal users so that users with infected or compromised machines cannot affect the cloud infrastructure.
There must be use of internal and external firewalls with OpenStack to control external and internal traffic.
