Security In The AWS Cloud

Click to share! ⬇️

Shared responsibility model
Well-architected framework
Principle of least privilege
AWS Cloud Compliance
On-Premise Vs. The Cloud

Like many people, when you think about security for your data and your IT infrastructure, you probably think of the server room in your office, locked with a card key that only the IT department has. Or maybe your company has a data center off-site that you must drive for two hours to ensure your backups are being saved securely. When you get to the data center, you probably encounter a lot of security personnel. You need to submit many credentials to enter the facility and get anywhere near the servers. This image of securing data is quickly replaced by cloud-based security, where you no longer have to keep costly data centers functioning and connected for ssh. Instead, you can have a cloud computing service provider manage their data centers on your behalf so you can focus on other aspects of IT infrastructure management. When you deploy your IT resources into AWS Cloud, you benefit from the global network of data centers and architecture built with security in mind. AWS helps you keep your data safe in its highly secure data centers, and safeguards are in place to help protect customer privacy. There are dozens of compliance programs embedded into AWS to help you meet your industry’s compliance requirements for data security. Securing your data on AWS Cloud allows you to maintain the highest safety standard without having to manage your own data centers, saving you time and money. It also allows you to scale the size of your business quickly, as AWS is designed to keep data safe no matter how big or small your cloud usage is. Before discussing AWS’s specific security-related services, let’s learn about a few concepts and frameworks for security in the Cloud.

Shared responsibility model

When utilizing the Cloud to house any part of your technical infrastructure, you must first consider the security impacts of moving your resources onto the Cloud. Unlike the on-premises data center protected by being within your physical reach, data centers hosting your cloud resources are in an undisclosed location in data centers managed by AWS. So who’s responsible for the data center’s security, servers, networks, and the data itself? All those EC2 instances that are running computations. Who makes sure their security patches are up to date? Who protects the data from being corrupted? AWS has a model that helps to puzzle these questions out, called the Shared Responsibility Model. As you might expect from the name, the Shared Responsibility Model asserts that the security of cloud functioning infrastructures is a shared responsibility between the customer and AWS. While there are certain parts of the infrastructure that the customers no longer have to worry about, there are still components that are the customer’s responsibilities to secure. In the most basic breakdown, AWS is responsible for the security of the Cloud, while you, the customer, are responsible for security in the Cloud. Let’s see if we can deconstruct what AWS might mean by this. When AWS says that they are responsible for the security of the Cloud, they suggest that AWS is responsible for protecting the infrastructure that runs all of the services offered by AWS Cloud. This includes hardware, software, vpc networking, and the data center facilities that run their cloud computing platform. You can think of it like this, AWS is responsible for the security of the components that make up the AWS Cloud, like the data centers and physical servers. On the other hand, when AWS says that the customers are responsible for security in the Cloud, they mean that the customers are responsible for varying security functions, depending on which services they are using. These could be protecting customer data, platform, application, and identity or access management. Or operating systems of virtual machines, configuring firewalls and data encryption. You can think about this: we are responsible for securing things inside the AWS Cloud, like data encryption and patching Ubuntu servers. There are many granular settings and concepts within the Shared Responsibility Model for AWS Cloud, which you can read on their website. But the basic idea you need to know

Well-architected framework

When you’re considering architecting how your AWS cloud IT infrastructure will look, you will have to consider how to make sure that it is secure from both external and internal threats. AWS has developed the concept called the five pillars of a well-architected framework to help you build the most secure, fault-resilient, efficient, and high performing IT infrastructure possible. Identity and Access Management or IAM, Detective Controls, Infrastructure Protection, Data Protection, and Incident Response. You would want to implement a robust identity foundation to manage user access correctly. This would entail utilizing the principle of least privilege, which means that you only provide access to what people need to do their jobs and no more.

You should enable traceability by monitoring alerts, audit actions, and changes to your environment in real time. Security should be applied on all layers instead of just a single outer layer of your infrastructure. This could mean ensuring your infrastructure is secured at the organizational subnet, load balancer virtual machine in the operating system layers for a virtual server. Security best practices should also be automated to scale more rapidly and cost-effectively. If the security methods are automated, You can replicate that for every new instance or resource you deploy instead of manually setting them up. Data should be protected At Rest and In Transit. Data is At Rest when it is stored somewhere, like in an S3 bucket. Data is In Transit when it is moving from one place to another, such as sending an email from your mail server to your friend’s mail server. Security mechanisms should be adjusted depending on the sensibility of the data. You should also keep people away from the data by eliminating the need for direct access or manual data processing. This way, human error and loss or modification of sensitive data can be prevented. Finally, when a security event occurs, you should be prepared to intervene, investigate and deal with the event. And once the issue is resolved, update the incident management process to learn from the security event. Security is a very vital part of running and architecting a well-architected framework. You can strive for stability by focusing on protecting the data and resources against security events. And when an event occurs, learn from the event and update Incident Management procedures.

Principle of least privilege

Principle of least privilege. Who can access what? When you start a new job, you get some accounts to log in to. It can be your not-so-new computer with someone else’s coffee stains on the keys or your corporate email account with fifty emails waiting for you. Or, it could be your company’s shared network drive on the server, where your team and predecessors have kept documents everyone needs to access. Say you work in the sales department. You should only have access to resources and information you require to do your job. That could be the client list for your team or deck templates for slideshows you will now be created to present to potential clients. Or even the products you are selling. However, you will not expect it. You should not have access to resources like pending legal cases being handled by the legal department, the not-yet-released product mock-ups being developed by your dev teams, or a list of personnel reshuffling that the HR department is contemplating. This concept of providing access only to resources that a person needs to do his job, and no more, is called the principle of least privilege. The idea is this. The company’s CEO should have access to many corporate resources. The newly hired sales associate should not. The IT department should be able to administer the services but probably not have access to the sensitive information and files themselves. Every role has a set of access permissions necessary to complete its job effectively, and the individual in the position should have no more or no less than the optimal level of access. To follow the principle of least privilege in AWS, you provide access to services and resources for your users and other AWS services using Identity Access Management, or IAM. When you provide users or services access using IAM policies, you should start with a minimum set of permissions and grant additional permissions only as necessary. Determine what the user or service needs to be able to do and craft policies to allow them to perform only those specific tasks. For example, a marketing manager might need to access a particular marketing-related S3 bucket to upload flat files for the company’s website. You may remember that S3 is a file storage service offered by AWS, and buckets are like folders inside the service that holds your files. However, he will not need access to the S3 buckets where air logs are being dumped into an app developed by the dev team. The IAM access granted to the marketing manager should provide him only the necessary access to the company’s AWS cloud infrastructure. Remember to give

AWS Cloud Compliance

AWS has many compliance programs available for your review to determine whether your industry allows you to store data or use AWS for your business. You can find the AWS Compliance Programs by going to AWS Compliance Programs. On that website, we can see that the AWS Compliance Programs are divided into regions worldwide. There’s also an entire section on privacy. That’s a big one for the data on the Cloud. If your organization deals with patient data in the United States, you must be mindful of HIPAA. You can find out how AWS complies with HIPAA and how data is secured on AWS. Laws, regulations, privacy, and HIPAA are covered extensively. If you have questions, the quick FAQ will respond to many common questions. There are many compliance programs available for review. And this page allows you to quickly find out whether your resources can or cannot be hosted on AWS if you have compliance requirements for your data.

On-Premise Vs. The Cloud

What are the differences between security in the Cloud and security in an on-premises data center? Security in the Cloud may look a little different and include some added benefits. Some topics to study are security in the Cloud, the Shared Responsibility Model, the security pillar of the Well-Architected Framework, the Principle of Least Privilege, and AWS Cloud Compliance. One of the most significant benefits of utilizing Cloud computing is that you no longer have to purchase equipment and maintain your own data center to run IT resources. Cloud computing providers like AWS manage the data centers so you can focus on other aspects of IT infrastructure management. When you deploy to the AWS Cloud, you benefit from the global network of data centers and architecture built with security in mind. Dozens of compliance programs are embedded into AWS to help you meet your industry’s compliance requirements.AWS is designed to keep your data safe, no matter how big or small your Cloud usage is, so you are free to scale your business as quickly as you want. There are three major concepts that outline AWS’ recommended security practices. These are the Shared Responsibility Model, the Security Pillar of a Well-Architected Framework, and the Principle of Least Privilege. The first concept addresses the question of who is responsible for security. The answer is slightly complicated. You, as the consumer, are responsible for security in the Cloud. As the Cloud computing service provider, AWS is responsible for the Cloud’s security. This concept is called the Shared Responsibility Model, which asserts that the security of the data and resources in the Cloud is a shared responsibility between the Cloud computing service provider and the customer. While the customer no longer has to worry about certain aspects of IT infrastructure, like securing the physical data center or hardware, there are other aspects that they are still responsible for, including patching VMs regularly and using proper permission sets so only people who should be accessing specific resources, do access them. Next, AWS addresses how you can best protect your AWS Cloud infrastructure from both internal and external security threats. AWS has the six pillars of a Well-Architected Framework to help its customers build the most secure, fault-resilient, efficient, and high performing IT infrastructure possible. Within the six pillars is the security pillar, which outlines how you can secure your infrastructure by adhering to best practices. Security in the Cloud comprises five areas: Identity and Access Management, Detective Controls, Infrastructure Protection, Data Protection, and Incident Response. Architecting a Well-Architected Framework can go a long way to making your IT infrastructure stable and secure. Next is the Principle of Least Privilege. What resources should you provide access to? The Principle of Least Privilege states that you should only give access to resources that an entity requires to do its job. Every role has a set of access permissions necessary to execute its job effectively, and the resources and individuals should have no more or no less than the optimal level of access. In AWS, you would make this happen using Identity and Access Management, or IAM provides granular access permissions. Providing the minimum amount of access to entities to complete their work is vital to keep your IT infrastructure secure. The Principle of Least Privilege coincides with the Shared Responsibility Model, where the customer, you, are responsible for security in the Cloud by ensuring access is provided responsibly. Many industries have compliance requirements for storing your data, such as HIPAA for medical organizations. You can learn more about AWS’s compliance by visiting aws.amazon.com/compliance. AWS wants you to be able to explain what concepts like the Shared Responsibility Model and the Principle of Least Privilege may mean in real-life scenarios.