A Comprehensive Guide to Cloud Security (Part 1)
We recently presented an overview of top five cloud security trends you should follow nowadays. In the article, we covered important trending security methodologies and technical concepts, such as DevSecOps, advanced cloud networking features (WAF or managed DDoS protection), as well as the idea of microservices fueled by Docker containers and Kubernetes orchestration.
If your company already has some cloud presence, these concepts can come in handy in the upcoming months and years, but what if you’re just preparing to embrace the public cloud? What if you’ve just started to draw your cloud blueprints and have no clue about what cloud security really is?
Then the trending terms and buzzwords won’t help you and you’ll need to start from the basics. This mini series of articles will prepare you for that scary jump into the unknown.
What Does “Traditional IT” Security Look Like?
Before the cloud, all companies were running something that’s typically known as the “traditional IT” infrastructure. By this term, we refer to any environment used for hosting applications/services or storing data. This environment is managed and owned completely by one organization (business entity, enterprise, etc).
The environment can be a data center operated by the same organization providing the services or a third-party specialized company, which is usually the case with big enterprises.
However, smaller companies can also have their own, modest server farm at an on-premises location (e.g. a server room inside your corporate building) or just a bunch of servers lying around on your IT team’s desks. The main difference comparing this model to the cloud is that in a “traditional” IT environment, there is no elasticity or scalability on the fly. Simply put, you cannot just expand your resources with a few clicks or API calls.
Also, running a traditional IT environment requires considerable capital expenses up front — preparing the environment (creating a separate server room or leasing a datacenter rack), purchasing equipment (network, servers, storage) and provisioning services (licensing, man hours to deploy the environment, etc).
This is all vastly different in the cloud. You can scale in a single click (or in an automated way, based on your consumption), and you pay as you go for the resources you consume, when you consume them.
To run a successful IT operation in traditional IT environments, IT teams are in charge of “everything”. This means that they also have end-to-end ownership of IT security. It’s up to internal IT teams to:
- ensure proper physical access to on-premises server rooms or data centers,
- secure the entire network infrastructure both externally and internally from unauthorized access or hacker attacks, and
- provide adequate application security for the services they run on their servers, both physical or virtual.
This seems like a lot to take on, right?
That’s why cloud is so popular these days, because besides the flexibility it gives you in terms of resource scaling and costs, it can also significantly ease up your IT workload when it comes to securing your cloud services.
The Shared Responsibility Model — The Pillar of Cloud Security
Migration to the public cloud requires a fundamental shift in how organizations design and perceive their IT infrastructure.
You will lose direct access to your servers. You won’t even know the exact geographic location where your data is at. On top of that, most public cloud services are offered as API/endpoint — combination of URL and port, which you access either by HTTPS or some other protocol.
Just as you don’t have complete access to your resources, you’re also not fully responsible for your security. Organizations share this responsibility with the cloud provider, and the concept of shared responsibility is the most important one when it comes to cloud security.
Public cloud providers are your biggest partners when it comes to security, and organizations which are moving to the cloud or have already migrated should explore the public cloud provider’s best practices for security and compliance.
How Shared Responsibility Works on AWS
As an example of shared responsibility in the public cloud, we’ll take a look at how Amazon defines this concept in its cloud:
As we can see from the picture, AWS manages the entire physical layer — data centers, which are divided into regions with availability zones and edge locations. Customers pick the region and availability zone (AZ) where the data or service will reside, but they don’t have physical access to it nor is the exact location ever disclosed to the public (customers cannot request this information from Amazon). AWS also has full control of servers/virtualization hosts, as well as different managed services that provide storage, database or networking to end users.
The client’s responsibility is to provision and maintain a desired operating system (in case you use EC2), to configure internal networking and firewall rules, and to ensure client-side data encryption.
It’s also up to the customer to organize and maintain identity management i.e. to configure access for internal users to AWS resources, with desired authentication and authorization rules. All of this is achieved by leveraging the AWS IAM service.
Further customer’s security responsibilities are determined based on the AWS services a customer uses. These services can be divided into three separate groups:
Infrastructure-as-a-Service (IaaS) — a typical representative of this group of services on AWS is AWS EC2. AWS in this case provides everything up to the OS layer, and it’s on the customer to provision an OS, configure it and deploy the desired application. This category also includes AWS ECS, AWS VPC, AWS EBS, AWS ELB etc.
Platform-as-a-Service (PaaS) — for this type of services, the OS is completely configured for you, but you need to deploy your application, maintain it and keep it secure. Most popular PaaS services on AWS are AWS BeanStalk and AWS EKS (managed Kubernetes). When it comes to EKS, there’s a debate regarding which group this service should belong to (it has some similarities to IaaS, PaaS and SaaS) but since you deploy apps onto EKS, we’ll consider it a PaaS service.
Software-as-a-Service (SaaS) — these services are fully managed by your public cloud provider, and the only thing the customer needs to take care of is how to import/export data to and from SaaS services. Most of the AWS services are in this group, like AWS RDS (relational databases), S3 (object storage) or DynamoDB (NoSQL datastore).
In Part 1 of our series on cloud security, we explained its most essential part — the shared responsibility model. Although we focused on AWS, the other big players in cloud computing, such as Google or Microsoft, follow pretty much the same principles. In the second part of this series, we’ll dive deeper into security aspects of AWS’s most used services, such as VPC and IAM, in order to give you a solid foundation for your secure AWS deployments.
Jatheon Cloud is a next-generation cloud email archiving solution that runs on AWS. To learn how your organization can improve compliance, ediscovery and email management using Jatheon’s cloud archive, contact us or schedule your personal demo.
Originally published at https://jatheon.com on September 19, 2019.
