In this lecture we introduce and explore the Identity and Access Management Service, or IAM. Which is a very important security service offered by AWS. Let's first ensure we understand the security context at the Identity and Access Management service, and ensure we understand what the service is and is not. IAM is a web service that allows you to control access to your AWS resources. So to fully understand how this works, let's first ensure we know the difference between authentication, authorization, and access control. Many people assume these words mean the same thing with no obvious distinction between them. This is, however, untrue. And as a result, people often use the wrong term to describe their security mechanisms. 

Before we go further into what the IAM service does for security, in AWS, let's first review each of these concept, so you understand the differences. It's important to know these differences in order to control access to your current resources effectively. And with the appropriate level of security. Let's start by looking at authentication. The authentication process is comprised of two parts of information. The first part of this process is to define who you are. Effectively presenting your identity. And example of this would be your login username to your AWS account, or environment. This identification is a unique value within the system, that you are trying to authenticate to. And in this example, AWS would not allow two identical user accounts to be created within the same, single, AWS account. The second part of the authentication process is to verify that you are who you say you are, in the first step. This is achieved by the additional information, which should be kept private and secret for security purposes. However, this private information does not have to be a unique value within the system. 

So in the example I just gave, whereby you provide your identity, in the form of a username to your AWS account, which will be a unique value. The next step would be to verify the identity by providing a password. Putting AWS and the cloud to one side for a moment, usernames and passwords are not the only forms of authentication from our identity and verification process. In our everyday lives we are presented with multiple forms of authentication methods. For example, credit, debit cards and PIN numbers. So when we use these to pay for something, we authenticate to our banks. In this process, we firstly identify ourselves by providing the credit, debit card details with our personal information on them. And then verify this information by entering a private, secret PIN number. This combination then allows authentication to our bank. Authentication is not just for verifying human access to systems. Authentication takes place by systems that require access to other systems. For example, one AWS service requiring access to another, to perform a function. In this instance, these same authentication principles and process is followed. Identity first, and then verification of that identity. Now that we have a clear definition of authentication, let's take a look at authorization. And see how authentication and authorization differ from each other. Authorization only takes place once an identity has been authenticated. So there is a clear order, as to which these two operate. 

Authentication takes place before the correct level of authorization can be obtained. Authorization is the process in which a system you have authenticated to, establishes what you can access and at what level. So here, we're really looking at your access privileges and permissions. Staying with our AWS example, we have authenticated ourselves by providing the correct identity and password. Now AWS security features, and in this case, AWS IAM, Identity and Access Management service, defines the level of authorized access assigned to that identity within the AWS environment. Each identity can have a different level of authorization properties associated to it. It's these properties that determine what that identity can then access. 

So, IAM is the service that controls access to your AWS resources, by controlling authentication and authorization of users and systems. IAM is not, however, an identity store or authorization system for your applications. It's important to remember that IAM does not enable you to manage the permissions within your applications. IAM is a global service. Meaning that you don't have to create rules for each region. The identities that you create are valid throughout all AWS regions, used by your AWS account. 

Now that we have a basic understanding of how IAM works and the context of cloud security, next I'll show you how to get started using the service in the AWS console. However, before we do that, let's define a few key concepts. There are three principles in the IAM service. First, we have the root user. The root user is the most powerful access credentials in an AWS account. The root user is associated to a unique to the account record. And it cannot be restricted in any way. It's recommended best practice to strictly limit the use of the root user credentials to privileged tasks only, such as billing and entity management. The second principle is the IAM user. IAM users are persistent identities controlled via IAM. This means you can associate roles and policies to an IAM user. Thereby restricting or allowing access to services or resources. In a corporate account, you might have 20 IAM users, each with different access policies and groups attached. 

IAM users are identities that we can create within the IAM service. In the context of IAM, a user can be anything. As the name suggests, you probably would associate it with a person. However, you can also associate it to a service, a cellphone, or in these days with the emergence of the internet of things, even your refrigerator. So an IAM user is an identity that you can create, in order to grant access to your AWS resources. An IAM user can have a password associated with it. But it's important to highlight, that using a password with an IAM user is optional. You will only need a password, if your user is going to interact with AWS, by the AWS console. 

Another optional tool is using the access keys. Access keys are used to interact with AWS programmatically. So you'll need them if your user will be working with, for example, one of the AWS SDKs or AWS command line interface. Also known as the AWS CLI. The most important addition for user authentication is multi factor authentication. Multi factor authentication adds a hardware or software generated key to the login authentication process. This device reduces risk of username password compromise, by requiring the IAM user to enter a one time generated key, when logging into the console. Multi factor authentication adds another layer of security when logging into the AWS console. As your user will not only have to provide a password driven login, but also the secret number through the MFA device. IAM groups simplify the management of IAM users. We can assign permissions to a group, instead of assigning it to an individual user. And then insert the user into a group. In this way, you can create general permissions that will apply to a certain group of users. 

The key benefit is that you only need to do it once and it will be set for all users in the group. If you want to revoke the permission for a single user, you can simply remove it from the group. Moving a user or users between groups is simple as well. Much easier than constantly manipulating individual user permissions, as work situations change for example. The third principle is roles. Roles provide temporary access with different credentials. Roles, are in essence, identities. They're similar to users in that you can assign policies to them, to specify the permissions that they might have. However, roles were designed to be used by more than one entity. It means that many entities can assume a role. And IAM user, a service such as EC2 or even users outside your AWS account can assume a role, since roles can be used for more than one entity. It makes sense that they have no credentials of their own. You just need to have permissions, allowing you to assume the role, in order to absorb permissions that were assigned to the IAM role. This is both helpful and secure. You only need to specify exactly who can assume the role, and AWS will manage credential verification for you. For example, let's say that you have a back up service, running in your AWS services, that sends data to S3 buckets. 

You can create an IAM user, with access keys, to send data to the back up bucket, using a script that relies on the AWS CLI. For that you'll need to configure the AWS CLI with your access keys. But that would require you to either have the keys saved on the instance, or configure them manually. The issue is, that it is not secure to store credentials on an instance. And updating the credentials on all instances that use them would be painful. A better approach would be to assign permissions to the instances, to assume a role that already has permission to store files in the backup bucket on S3. In this case, you won't need to configure credentials into any instances. It's all done automatically. Further, AWS will dynamically rotate the access keys, used to grant access to the S3 bucket. Roles are a powerful tool in managing secure access to services and resources.

A role is generally assumed via a temporary security token, e.g. simple token service, STS. And will expire after a set period of time. Roles provide a powerful and flexible way to keep control of who and what is authorized to access your resources and services. If an IAM user account is compromised, we can reduce access to services by disabling or expiring the role credentials assumed by that user. Policies are the way to define the permissions and rights an identity will have. You can associate policies with users, groups, or roles. The standard role gives an identity no rights at all, so you need to explicitly declare the rights of an identity, though a policy. The policy document is written in JSON format. And will look something like the example shown here. Learning how to create and read policy files is beyond the scope of this course. What you do need to know, is that policies are used to allow or deny actions. However, since the default behavior is that the user has no rights, unless you explicitly add them, it's more common to have policies with allow actions. It's important to realize, however, that an explicit deny action overrides any allow actions. Now that we've defined the key concepts of IAM, let's take a look at the IAM console, and actually get started. 

Let's go to the IAM console and create our first IAM user. We click on users. And then create new users. We can create more than one user at once, so I'll create a couple. One called Steve and the other called backup. I'll click here to turn off generation of access keys for these users. Unless we intend using these accounts for programmatic access to resources, we don't need an access key. Remember the guiding IAM principle of, least privileged. Now we can click on create. An IAM user can be associated with multiple policies and groups. So let's create the required credentials for each of our users. First, our user Steve. Since Steve's a person and he will only interact with our account, via the management console, we'll give him a password. We just need to click on manage password. Then we should decided whether to assign an auto-generated password or a custom password. I'll click here to specify that the user has to change his password at the next sign in. This will cause some problems that we'll discuss in a few minutes. Click on apply. And now I can see the generated password. And also download the credentials in a CSV file. The CSV file that we downloaded contains the credentials for the user. And also a sign in link. This is an important address. The IAM users can only login to the management console though this link. Let me copy it and open another browser. So we can login to the console as Steve. Now, we'll copy the information in the right fields, and we're done.

Okay, now it's time to change the password, as we specified just before. As we can see, due to the deny aspects of the default policy, Steve cannot change his own password. We can solve this by granting Steve permission to change his password. To do this, we'll need to return to our root account screen, and grant Steve the required permissions while acting as the root user. To grant permissions, we go to the permissions tab and click on attach policy. Attaching this policy template, will provide Steve with administrator access. That means, Steve will have almost the same access rights as a root account. 

Let's return to the change password dialogue to see what happens. Now Steve has access. By attaching this policy, Steve's account is now a privileged user. So it would be best practice to enforce multi factor authentication on Steve's account, to ensure Steve's privileged account is as secure as possible. In the security credentials tab, I'll click on assign MFA, or multi factor identification device. There are two types of multi factor authentication devices, currently supported by AWS. A hardware based token device, such as the secure ID device from Gemalto. These devices are no bigger than a USB drive. And can be ordered from the AWS marketplace or from AWS support. You can also use a virtual token device. Which is a software application, which is compliant with RFC 6238. A standards based, time based, one time password algorithm. 

Google Authenticator, is an example of a virtual MFA app. And you can install this on a smart phone or tablet. Both types of multi factor authentication devices display a temporary authorization code, that's synchronized with a master token server. If your device number and the server generated number match up, your authentication request will be allowed. For our user Steve, we'll enable a virtual, multi factor authentication device. Now we're asked to configure an MFA compatible application. The process is very easy. I'm using Google Authenticator as my application. In this case, I can simply read this QR code. And enter the first two codes that the application would generate here. Now let's see what's changed on our login page. You can see now, that we need to provide the token, generated on Google Authenticator, to login, not just a password. 

Let's assume the use case for our back up user is different from that of user Steve. For Steve, we only needed to provide access via the AWS web console. For our backup user, we'll want programmatic access, i.e., we may want to access services from the command line interface or via an API core. For that, we'll need an access key. When you create an access key, AWS gives you an opportunity to view and download the secret access key only once. If you don't download it or if you lose it, you can delete the access key and create a new one. A newly created access key has a status of active. Which means you can use the access key for API cores. You can have up to, two access keys for your AWS account. Which is useful, when you want to rotate the access keys. When you disable an access key, you can't use it for API cores. You can create or delete an access key anytime. However, when you delete an access key, it's gone forever and can't be retrieved. So, let's create an access key for our backup user. We just need to click on users. Select the backup user. And again, in the security credentials tab, click on create access keys. 

Now we can see the access keys or download them as we did for the passwords. An access key is made up of an access key ID and a secret access key. Let's now click on the dashboard to go back to the main screen of the IAM console. Remember that we used a sign in link to login as an IAM user. Here's the link. We can customize this link, as long as our customized version is unique. I'm not gonna change it here. That concludes our introduction to the IAM console. In this demo, we created two users and assigned policy permissions to them. We created a unique address for our user, Steve, to login to the AWS console. We enabled a password policy on the user account, Steve. We then enabled multi factor authentication on Steve's user account, to increase security on it. We then created an access key for our backup user. So the backup user can access AWS programmatically. T

hat concludes this lecture on the AWS Identity and Access Management service. Let's summarize the features we've covered in this lecture. First, we learned that the root user is the most powerful access credential in an AWS account. The root user is associated as unique to the account record and it can't be restricted in any way. Second, we learned that IAM users are persistent identities, controlled by IAM. This means you can associate roles and policies to an IAM user, thereby restricting or allowing access to services or resources. We learned that IAM groups simplify the management of IAM users. We can assign permissions to a group, instead of assigning it to an individual user. And then insert the user into a group. Then we explored roles. Roles provide temporary access with different credentials. Roles, are in essence identities. They're similar to users, in that you can assign policies to them to specify the permissions they might have. However, roles were designed to be used by more than one entity. It means that many entities can assume a role. 

An IAM user, a service, such as EC2 or even users outside your AWS account can assume a role. That concludes this introduction to the IAM service. I do encourage you to get started with our lab, so you can experience the IAM console and set up firsthand. The Cloud Academy Labs, provide a great way to experience the IAM services firsthand. Thank you for attention. Any questions or feedback, please reach out to us, at support at cloudacademy.com.

Lectures:

• AWS Security Fundamentals
• AWS Shared Responsibility Model
• Identity and Access Management
• Amazon Cloud Directory
• Inspector
• Web Application Firewall
• Security Overview