As promised in the last episode, we will start with Amazon Web Services security today. As this is large topic, I’ve decided to split it into two articles in a similar way I did with AWS networking. In the first part, we will cover the fundamental service from the security group: Identity and Access Management and all concepts related to it. In the second part, we will look into other security services and AWS security in general.
Identity and Access Management is a service that let us control how people and machines access and operate on AWS resources. It’s used to facilitate authentication and authorization of different types of principals, organize them in groups and assign polices that allow flexible and fine grained regulation over who can do what and when. Not surprisingly, IAM can be controlled via AWS console, CLI or SDK.
First important concept in IAM is the Principal. It’s an entity that is allowed to interact with AWS resources, that may be permanent or temporary and it might be human being or an application. Principal related concepts include: Root user, IAM users, Roles, Temporary Security Tokens and Federations.
Root user is the first principal available after creating an AWS account, similar in concept to Linux root or Windows administrator. Root user has full access to everything and cannot be limited. It’s a good practice to use it only to create first user account after root, and then securely lock away root credentials and restrain from using it.
IAM user is a permanent entity associated with individual person, application or process. They help enforcing principle (not to be confused with principal) of least privilege: allowing exactly what is necessary to perform a task for a principal, but nothing more.
Roles are used to grant specific privileges to specific actors for a given time. Roles are commonly used with EC2 instances in order to avoid a need to store credentials on the instance itself. We could access AWS resources from EC2 instance via SDK and store keys to them on the instance, but it poses a security risk. We need to protect the keys and take care of rotating them. Using roles releases us from this burden. We can also grant roles to users from other AWS accounts.
Temporary Security Token is granted when an actor assumes role. It should then be included with request to given resource. Tokens lifetime is between 15 minutes and 36 hours.
Federation, also known as Identity Provider, is a concept of leveraging existing external web-based user identity stores, like Google, Facebook or on premise repositories. IAM supports integration using OpenID Connect (OIDC), as well as with providers compliant with Security Assertion Markup Language (SAML) such as Active Directory (AD) or Lightweight Directory Access Protocol (LDAP)
Authentication is a process of proving subjects identity. There are three basic ways to do that in IAM:
User Name and Password pair is used to authenticate principals represented by human beings interacting with AWS console. IAM allows to enforce password complexity and rotation policies.
Access Key, or more precisely a combination of access key ID (20 chars) and secret access key (40 chars) is used when manipulating AWS through REST calls directly or via SDK. When users are created, they may be assigned passwords, access key pairs or both.
Access Key and Session Token are used when operating under assumed role, not as a particular IAM user.
Beside those, we can add an extra layer of security in the form of Multi Factor Authentication. In that case, besides normal credentials, principals are required to provide a One Time Password (OTP) that can be obtained either from a special physical device or an application running on smartphone or other device. Its is a good practice to use MFA for Root user.
IAM allows two active set of keys at the time, thus facilitates key rotation. As the older the credential is, the bigger security liability it becomes, it is recommended to change keys from time to time. We can introduce new key, test whether our system works, and if there is any problem – fall back to the old key.
Authorization is granting access to specific resources after successful authentication is performed. In case of IAM it’s mostly about Policies and various ways to associate them with Principals.
Policy is a JSON document containing a set of permission to access and manipulate AWS resources. Each permission defines whether it allows or denies something, name of the service and resource in the form of: “arn:aws:service:region:account-id:[resourcetype:]resource”, set of actions on a given resource and optionally one or more conditions. Conditions may include specific IP addresses, time intervals and more.
Policies may exist in the context of particular user, particular group of users or can be managed policies – independent from principals that could be associated with many users, groups or roles. There is a number of predefined managed policies in IAM. It might happen that multiple permissions apply for particular principal to the same resource. By default, the access is denied unless there is at least one explicit “allow” and there are no explicit “deny” to that particular action on a given resource under given conditions.
Where is my application security?
That’s it about IAM for the time being. It’s important to remember, that it’s all about access to AWS resources only. It’s not about identity store or access to applications we host on our instances, nor identity management for operating systems installed on those instances. That’s a different layer of abstraction. If you are interested in security from developer’s perspective, at the application layer, you are welcome to check out the episode about Spring Security I’ve written not so long ago. Meanwhile, next week we are going to look into remaining services from the AWS security group. Stay tuned!