Okay, let's talk about AWS Identity and Access Management, or IAM. Now IAM lets you create individual users within your AWS account and give them each their own username, password, and if required, access keys. Individual users can then log into the console using a URL that's specific to your account. As a best practice, create an IAM user for admin or privileged users so that you do not use your route counter credentials for everyday access to AWS. Always enable MFA, or multi-factor authentication, on privileged users. You can always create access keys for individual users so that they can make programmatic calls to access AWS resources. If they do not need this access there is no need to create access keys. Ensuring that users have least privileged permissions to access the resources you have in your account is an important part of your security management. You can use IAM to help perform this function. You can create IAM users under your AWS account and then assign them permissions directly or assign them to groups which you can then assign permissions to. IAM policies define relationships between principals and resources. A principal is a user, a group, or an AWS service, like an EC2 instance. A resource can mean an S3 bucket or its contents, or an EC2 instance and the data that services are provided to it. A policy is a way to control who can read, write, create, or delete an object or a service. We associate either directly or indirectly IAM policies with users, groups, and roles. Using IAM, you can define the way users access AWS through passwords, access keys, multi-factor authentication, or identity providers. When users are associated with groups any policies attached to the group by definition are now binding on all the users who are part of that group. A role is not associated with the user or a group but with a service, like an EC2 instance. Let's set up users and groups for a company, Acme Widgets, so that our users will be able access their own ES3 buckets and their shared company-wide ES3 bucket. So let's go into the AWS console and click the IAM and then Groups, Options. We're going to create a new group for admin users. So let's call this group Admin and click Next Step. We now have the option to select an access policy for this admin group. Let's give them administrator access, which is full access to all AWS services and resources. Now looking at what makes up these templates is a really good way to get to understand how security works in AWS. You'll notice that the access policy is defined in adjacent formatted text. Now the key element is the effect of the policy. The star or asterisk is allowing all actions on all resources in this policy, so users in this group will have access to all AWS resources in their account. Now let's go to the next step and create the group. The group at this point has no members. Let's create another group and we'll cal that one Devs for the developers in our company. Rather than having to give them full administrator access, which they don't need, let's scroll down and give them AWS Connector access, which is another AWS template. That will enable limited access to EC Objects and ES3 buckets, which are the services that the Dev team needs to access in the process of their work. Here we see they're allowed access via IAM to get or list users. So they could list all the users that IAM defines in our system. In ES3, they'll be able to list all buckets concerning any resource in ES3. That's that star and asterisk again. Similarly, they'll be able to create buckets, to delete buckets, delete an object, get a bucket from all locations. Now in EC2 Computing Resources, the group members will be able to delete tags, create volumes, create tags, and perform many of the functions necessary in the lifecycle of EC2 instances. Because of the asterisk or star, which allows all, they'll be able to do that on any EC2 instance associated with this account. Let's go to the next step and create this group. We now have two groups but still no users. Let's create some users. So we'll click Create New Users. We'll call one user Ted, one Allan. Let's say Alice and Steve. We'll show their security credentials, which we may have to securely transfer those credentials to these users so they will be able to log into the system. But once that's done, they have access to whatever we allow them. So let's close this out. Now let's go back into Groups. Let's click on Admin and add users to the Admin group. I only want to add Allan because he's our sys admin, so I'll add him to the Admin group. He now has full rights and accesses that have been associated with the Admin group. Let's go back to Groups. Let's now click on Devs and add users to the Dev group. And we'll add the three others and they will now have all the rights, and nothing but the rights, and accesses that were defined as part of the Dev group. Let's go back to Users and let's click on Alice. Let's create a new user policy for Alice. So beyond the general rights and accesses that she has because she is part of the Devs group, we're going to give her her own ES3 bucket where she can store objects. We'll click on Custom Policy and select the editor to allow a custom policy. So let's give this custom policy a name. Let's call this policy Alice's Private Bucket. And assuming that we've already created an ES3 bucket on our account called Alice's Bucket Acme, as our company name is Acme Widgets, then this policy will give Alice access to everything on S3 that is associated with this resource, Alice's Bucket Acme. Let's apply the policy and Alice now has access to her private ES3 bucket on our AWS account. We can do the same thing, of course, for all the other users. However, there's a group policy that we'd also like to apply to the Devs group, which already has these three users, Ted, Alice, and Steve. Let's scroll down and attach another policy. This, too, will be a custom policy and we will open the Custom Policy Editor. Let's call this one Shared Bucket Access and paste the jacent formatted code for this policy. This one will allow any members of this group full access, that's the star and asterisk again, to all ES3 resources that are associated with this bucket that we've created under the name Shared Bucket Acme. Assuming we'd created a bucket policy on ES3, that will allow access. Now any users who are currently a part of the Devs group will be able to access all the resources on Shared Bucket Acme and also to create and edit their own. So let's apply this policy. So what we've done now is create users and assign them to specific groups, Dev and Admin. We've assigned access policies to each of the groups and we've given access to each user to just those ES3 buckets where they need access. Now the AWS Policy Simulator is really useful to test the results of any action against a particular policy. So let's try it out here. Let's click on Manage Policy for any policy. Then click on the IAM Policy Simulator and let's work by users. We could also work by groups, but let's work by a user. Let's take Alice. And Alice has three policies associated with her account. So let's click on this one, which tells us that requests or lists to in my ES3 buckets are allowed. Alice can get user requests from IAM, are allowed. Has a few other request types as well. Let's now select a service we'd like to test. Let's say there's three and let's say List All My Buckets, which we know is something that's permitted and let's then try and delete a bucket. Let's try those two actions and see how Alice will be able to perform them. Let's run the simulation. So List All My Buckets is allowed but Delete Buckets is denied, which is exactly what the policy had outlined. IAM Roles are the AWS mechanism for controlling the access and behavior of services and instances without having to share user credentials. So roles provide an abstraction that reduces the risk of sharing credentials when services need to talk to each other. Now policies work the same way for roles as they do for users and groups. Unlike policies for users and groups, however, when you are creating a new role you must first define the role type and only then apply its policies. Let's create a new role and call it New Role. We'll click on the Next Step. And first we have to define the role type. There are three broad categories. A role for cross-account access. That is if we want to allow access to one of our local services from a service or a user in a different Amazon account. If we want to allow access to our services from users who may be logging in using other accounts, like a Google account or a Facebook account, for example, then we can do that by using a role for identity provider access. Today we'll use an AWS service role, which will define what access the account will have to other Amazon services once it's associated with this particular role. We can create a role for an Amazon EC2 instance that will determine what, where, when, and how the services running our instance can access an ES3 bucket or some other Amazon service. We could, for example, define how a Data Pipeline might behave, Elastic MapReduce might behave, OpsWorks might behave. All of these role-type templates Amazon has already created under this section. So let's select Amazon EC2 and now let's define the policy that will determine how a session associated with this role will be allowed to behave. Do we give it full access? Administrator access to every service and resource? Or do we give local instances the ability to access services and resources elsewhere on the account, but not the management of users and groups, for example? Will they have read-only access? What will their access to CloudFormation, CloudSearch, CloudTrail, CloudWatch, Data Pipeline, Direct Connect, et cetera? What will that be? All the services and resources that could be available by category in your Amazon account, basically. The access to them from our EC2 instance will be defined by this role. So let's select Amazon Direct Connect, full access, which is as it says here, "To provide full access to AWS Direct Connect "via the Amazon AWS Management Console." This is the policy that defines this role. That is the effect which will be to allow any resource that a user or service on our instance will try to apply this action to Direct Connect. That will be allowed. And the resource will be any resource because of the asterisk or star. It means any resource associated with our Amazon account that this instance uses Direct Connect will be permitted. Click on Next Step and review and then create the role. The role now exists! Okay, so let's walk through 12 IAM Best Practices. Number one. Place multi-factor authentication on the root account and remove the access keys. Number two. Create individual IAM users so that you have more control over account access. Number three. Use groups to assign permissions to IAM users, because groups make it much easier to manage accounts at scale. Number four. Grant least privilege. Start by using or allowing users to do as little as possible and only allow access to services on a needs basis. Number five. Configure a strong password policy for your users. Number six. Enable multi-factor authentication for privileged users. Now that protects those users and reduces the blast radius should, say, a privileged or admin user lose their machine or their account is compromised. Number seven. Use roles for accounts that run on Amazon EC2 instances. So setting the role at launch enables you to control what instances can and can't do once they're running. Eight. Delegate by using roles instead of sharing credentials. Now roles reduce the need to share credentials when you need systems to talk to each other. Number nine. Rotate credentials regularly. Number 10. Remove unnecessary credentials and users. So regularly download the credentials report and remove any account or keys that you're not using. Number 11. Use policy conditions for extra security. These are great. So for example, only allow users to terminate or delete if that user is logged in with multi-factor authentication. Or it could even be where a tag exists. Number 12. Monitor activity on your AWS account. Amazon CloudWatch, Amazon CloudTrail, AWS Config are all great tools to help with detection and monitoring.