Security in the AWS Cloud
Security in the AWS Cloud
Security and AWS Shared Responsibility Model
In simpler terms, using AWS is like renting an apartment in a large, secure building complex. AWS is like the building’s management, providing and maintaining the structure of the building itself. They make sure the building is secure, keep the elevators and other facilities running smoothly, and take care of the physical security, like the guards and surveillance systems.
On the other hand, you as the tenant are responsible for the security and management of your own apartment. You have to lock your doors, manage who has access to your keys, and secure your personal belongings inside. If you want to install an extra lock or a security camera inside your apartment, that’s up to you.
This is similar to how security works in AWS. AWS ensures the security of the ‘cloud’, which includes the physical data centers where your data is stored, the servers, the network infrastructure, and the hypervisors that allow multiple virtual machines to run on a single physical machine. This is like the building structure and security provided by the building management.
You, as the user of AWS, are responsible for the security ‘in’ the cloud. This includes securing the data you store on the AWS services, configuring who can access your data, managing your user accounts, and ensuring your applications are secure from threats. This is like the security of your own apartment.
The AWS shared responsibility model ensures that both AWS and the customer work together to create a secure environment. Just like in a secure building, security is a shared responsibility between the building management and the tenants.
Hypervisor
Think of a hypervisor like a hotel manager. In a hotel, you have a lot of rooms and a diverse set of guests. The manager’s job is to make sure every guest has their own room and that they don’t interfere with each other. They allocate resources such as rooms, food, and other services to each guest based on what they’ve paid for, and they make sure all these operations run smoothly.
In computing, a hypervisor (also called a virtual machine monitor) works a bit like that hotel manager. You have one big, powerful computer (the hotel) and the hypervisor allows you to split up that one big computer into many smaller, virtual computers (the rooms), each running its own operating system and applications. Each of these virtual machines thinks it’s running on its own separate hardware, but in fact, they’re all sharing the same physical resources (like CPU, memory, and storage) of the host machine.
The hypervisor’s job is to manage these resources and make sure each virtual machine gets what it needs without interfering with the others. It allows for greater efficiency and flexibility because you can run multiple different operating systems and applications on the same physical machine, each isolated from the others, much like guests in separate hotel rooms.
In the context of AWS or any other cloud service provider, hypervisors enable them to provide virtual servers to multiple customers, all running on the same physical hardware but completely isolated from each other. Just like a hotel manager making sure guests in different rooms don’t interfere with each other.
Difference between authentication and authorization
Authentication
Think of authentication like showing your ID to get into a club. It’s the process where you prove you are who you claim to be. You provide the system with something it recognizes, usually a username and password. If the system recognizes these as valid, it lets you in. So, in our club analogy, if your ID matches the name on the guest list and your face matches the picture on the ID, you’re allowed in.
Authorization
Now, imagine once you’re inside the club, there are different areas, some of which are VIP-only. Authorization is the process of determining what you’re allowed to do once you’re inside. Even though you’ve proven who you are (authentication), it doesn’t mean you have access to everything. In our club analogy, being allowed into the club doesn’t automatically grant you access to the VIP area. You need a special pass for that.
Protect the AWS root user
AWS Root User
When you sign up for an AWS (Amazon Web Services) account, you’re automatically given a root user. This is like being the owner of the club. You have access to every area, and you have the power to do anything, such as add or remove guests, change the music, or even shut the club down. You log in as the root user using the email address and password you signed up with.
Supported MFA devices
Multi-factor authentication (MFA) is like a two-step check at the club entrance. First, you show your ID, and then you also need to show a unique code that changes every time you try to log in. This could be from a special app on your phone (Virtual MFA), a physical device like a keychain (Hardware MFA), or a USB device (U2F security key). Using MFA makes your account much more secure because even if someone manages to guess your password, they won’t be able to log in without that second unique code. It’s like if someone stole your ID to get into the club, but they also needed a unique, changing passcode that only you have.
Hardware MFA:
Imagine a small gadget, similar to a keychain or remote car key, that has a little screen on it. This screen displays a series of numbers that change every 30 seconds or so. This is a hardware multi-factor authentication (MFA) device. When you log into a system, like your AWS account, after entering your password, the system asks for the number displayed on the device. Because these numbers change frequently and are uniquely tied to your device, it provides an additional layer of security. If someone found out your password, they would also need this physical device in their possession to access your account. It’s like a constantly changing, physical second password that would be very hard for a thief to get.
U2F Security Key:
U2F stands for “Universal 2nd Factor,” and it’s a type of physical device used for extra security during the login process, just like the Hardware MFA. A common form of a U2F device is a small USB stick. When you’re logging into a system, after you’ve entered your password, you’re asked to insert this USB stick into your computer and touch or press a button on it. Only when you’ve done this will you be allowed into the system. It’s like a physical key to a door. Even if someone else knows the password (the door code), they can’t open the door without the key.
Access and Credential Management in Cloud Applications
When developing and managing applications, especially in the cloud, one important aspect to focus on is access control. Access control and credential management is all about determining who is allowed to do what in the context of your application.
Let’s say we’re building an employee directory application hosted on a service like Amazon EC2, a cloud computing service provided by Amazon. There are several places where we would need to manage access and credentials:
1. User Authentication
The first level is the application itself. To access the application, users would need to log in with their credentials (usually a username and password). This is a form of access management at the application level.
2. Access Control within AWS Services
The code for our application would need to make API calls to Amazon S3, an object storage service by Amazon, to read and write data like employee images. However, just because both Amazon EC2 and Amazon S3 are in the same account, it doesn’t mean API calls between them are automatically allowed. They need to be signed and authenticated, which means the EC2 instance running the application needs access to credentials to make the API call to S3. This represents another layer of credential and access management.
3. Account Management
To build this architecture, we would need access to an AWS account. We would need permissions to do things like creating a network, launching EC2 instances, and creating other resources in AWS. This would require another set of credentials, and each person working on the application would ideally have their unique credentials for logging in.
To manage these aspects of credential and access control, we can use AWS Identity and Access Management (IAM).
IAM helps manage the login credentials and permissions for the AWS account and also the credentials used to sign API calls made to AWS services. However, IAM is not responsible for application-level access management. The code running on the EC2 instance would use separate mechanisms for authenticating users into the application itself.
Further Explanation of the context above
AWS Identity and Access Management (IAM) is a tool provided by Amazon Web Services (AWS) that helps you control access to AWS resources. It helps manage who can log into your AWS account (authentication) and what they can do once they’re logged in (authorization).
When we say IAM manages the “login credentials,” it means that IAM handles the usernames and passwords (or other forms of credentials) for logging into the AWS console or making API calls to AWS services.
For instance, if you’re a developer and you need to access AWS to set up a server or access a database, you’ll have a unique IAM user with a specific set of permissions. These permissions are controlled by IAM and determine what AWS services and resources you can access and what actions you can perform.
However, when we talk about “application-level access management,” we are talking about controlling who can access the application you’re hosting on AWS and what they can do within that application.
Let’s use an analogy. Imagine your AWS account is a building and the application is an office within that building. IAM is like the security desk at the front of the building. It checks your ID, confirms you work in the building (authentication), and determines what floors or rooms you can access (authorization).
But once you’re in the office (the application), the office has its own set of rules about who can access which files or use certain equipment. This would be the “application-level access management.” IAM doesn’t manage this – it’s usually handled within the application itself, often through a system built into the app or through another service like a user management or identity provider service.
So, in summary, IAM controls who can access your AWS resources and what they can do there, but it does not control who can use your application or what they can do within that application. That’s typically handled by a different system designed specifically for managing user access at the application level.
AWS IAM Users, Groups, and Policies
In IAM, you can create users, and each individual person who needs access to your AWS account would have their unique IAM user. This takes care of authentication, i.e., verifying someone’s identity.
To manage what a user can or cannot do, we introduce authorization. Once a user is authenticated, they might want to perform actions, like creating an EC2 instance. Whether they are authorized to perform these actions is controlled by IAM policies, which can be attached to users or groups.
IAM policies are essentially rules that define what actions (represented by AWS API calls) a user or group can perform. These policies are usually written in JSON format and can be very specific, allowing you to restrict access to certain AWS resources or services.
IAM groups are collections of IAM users. By attaching a policy to a group, any user in that group would inherit the permissions defined by that policy. This makes it easier to manage permissions when people change roles or when multiple users need the same permissions.
IAM Roles and Temporary Access
For the EC2 instance to make API calls to S3, we wouldn’t create an IAM user for the application. Instead, we’d use an IAM role, which provides temporary access credentials that the application can use to make the necessary API calls.
Difference between IAM users and IAM roles
An IAM user is typically created for an actual person. Each person interacting with AWS resources (like admins, developers, or other employees) will have their own IAM user with a unique set of credentials (username and password). This IAM user will have specific permissions that define what AWS resources they can and cannot access.
On the other hand, an IAM role is more commonly used for applications or services. These are not tied to a specific person but to the services that need to perform actions on AWS resources. For example, an IAM role can be assigned to an EC2 instance, allowing the application running on that instance to make API calls to other AWS services like S3.
Here’s another way to think about it: IAM users are like individual employees in a company, each with their own ID card (credentials) and job description (permissions). IAM roles, meanwhile, are like temporary ID cards given to machines or applications to do specific tasks for a certain period of time. After that time, the ID card is taken back and a new one is issued if the task needs to be done again. This ensures that only the necessary permissions are granted for the necessary duration, enhancing the security of your AWS environment.
In the context of an application running on an EC2 instance that needs to interact with S3, the application doesn’t need a permanent IAM user with a fixed username and password. Instead, it needs temporary access to perform certain tasks – in this case, making API calls to S3. This is why we’d use an IAM role for this purpose.
Role Based Access in AWS
DynamoDB
Imagine DynamoDB as a big, super-fast virtual spreadsheet stored on Amazon’s computers, where you can put and get data anytime you want. Unlike your physical spreadsheet at home, it’s always available, can grow as big as you need, and multiple people can update it at the same time, even if they are on different sides of the world.
Federated Users
Let’s say you own a big office building (your business), and inside that building, there are many rooms (different services and resources). Now, you already have a security system that lets your employees use a single keycard (their corporate identity) to access the building and rooms they need for their job. Federated users are like letting your employees use their existing keycards to also open doors inside the AWS ‘building’ (AWS resources). This way, you don’t need to give them a separate key (create an IAM user) for AWS.
How Federated users can access AWS?
Federated users are a bit like guests at a hotel. When a guest checks into a hotel, they don’t get an actual key to the room. Instead, they’re given a temporary card that works for the duration of their stay. The card doesn’t belong to any specific room; the hotel’s system assigns it to a particular room when the guest checks in. Once the guest checks out, that card is de-activated for that room.
In a similar way, federated users don’t have a permanent IAM user account in AWS. Instead, their identities are managed by an external Identity Provider (IdP), which could be a company’s internal user directory, a social media account, or a third-party identity service.
When a federated user needs to access AWS resources, they don’t log in directly to AWS. Instead, they authenticate (prove their identity) with the IdP. The IdP then gives them a temporary ‘card’ (a set of AWS access credentials), and tells AWS which ‘rooms’ (resources) the user is allowed to access. These permissions are defined by an IAM role in AWS.
So, in this way, federated users can access AWS resources without needing to have a permanent IAM user account. This can simplify user management, particularly for large organizations or for scenarios where users need temporary access to AWS.
Identity Provider (IdP)
In the context of AWS, an Identity Provider (IdP) is a tool that allows you to manage the process of assigning IAM roles to IAM users.
When you use an IdP, you’re effectively implementing a system that lets you manage user identities and their access to different AWS services in a streamlined and centralized manner. You don’t need to create separate IAM users for each individual and manage their permissions separately within AWS.
Instead, you manage the identities (like Martha in your example) in the IdP, and the IdP interacts with AWS on behalf of the users. When a user needs to access AWS, they get a temporary set of credentials from the IdP, which corresponds to an IAM role in AWS. This IAM role determines what the user can and can’t do in AWS.
So, the IdP is a sort of “middleman” that simplifies the process of managing user identities and access to AWS. It takes care of verifying the user’s identity and providing them with the correct access permissions in AWS, which are represented by IAM roles.
This is particularly helpful in large organizations with many employees who need access to AWS, as it significantly reduces the complexity and overhead of managing user access to AWS resources.
AWS IAM Identity Center
AWS IAM Identity Center is a service provided by AWS which acts as an Identity Provider (IdP). It is like an upgraded version of IAM, providing additional features that simplify the management of users and access permissions, especially in more complex environments that involve multiple AWS accounts or third-party IdPs.
Think of IAM Identity Center like a sophisticated keycard system in a large building with many doors. Employees in the building don’t carry a set of individual keys to access each door. Instead, they carry a single keycard that’s programmed to unlock certain doors based on their role in the company. The building management doesn’t have to manually update each door lock when an employee’s role changes or when a new employee joins the company; they just update the access permissions on the employee’s keycard.
Similarly, IAM Identity Center allows you to manage user access across multiple AWS accounts from a central location. You can create users, organize them into groups, and assign permissions to these groups. You can also connect IAM Identity Center to a third-party IdP, allowing you to synchronize users and groups from that IdP to IAM Identity Center. This means you don’t have to re-create users in AWS that already exist in your third-party IdP, saving you time and effort.