Hello and welcome to this lecture where I'm going to review the dashboard of the user Console. In IAM, we can create user objects to represent an identity with long-term credentials, this could be a real person within your organization who requires access to operate and maintain your AWS environment, or it could be an account to be used by an application that may require permissions to access your AWS resources programmatically. Users are simply objects representing an identity which are used to authenticate to your AWS account with an associated set of permissions.

When you open the AWS IAM dashboard and select users, you will be presented with a screen similar to the following. This screen provides a summary of the key points of interest relating to your IAM users and it can quickly help you identify any potential security risks that you might encounter. As we can see, we have a number of different warnings on this screen in different colors. We have a green tick which symbolizes activity was measured within the last 90 days An amber exclamation mark showing activity was last measured between 91 and 365 days ago. And a red exclamation mark, which highlight anything older than 365 days ago. Anything either amber or red should be looked at and addressed as a priority to reduce potential security issues.

Let's take a closer look at this table and its columns to understand exactly what it's trying to show you. The complete list of field names are shown here, and you can toggle them on an off as you need. Let me go through each of them one-by-one to explain what they represent. So username. This column is self-explanatory, it provides the username of that user.

Path. If you create your users using the IAM API or the AWS Command Line Interface, the CLI, then you can specify a path structure for your users. This is useful when you have a large organization and you want to define a management structure to help you organize your users more effectively.

For example, you could add a path for a user Stuart of /ContentTeam/AWS/UK/Stuart. This would help to define where your users might be in accordance with your organization structure. In addition to this, you can also reference paths in your access policies, so for example you could allow all users in the /ContentTeam/AWS/UK/ path to have full access to S3 with a simple policy like this.

Groups. This shows the different groups that the user belongs to. In the screenshot, you can see that the user Stuart belongs to the Admin group. Last activity. This column is really useful to show the last time your users logged into the AWS Management Console or if they accessed any of your AWS resources programmatically using their access keys. As we can see from my example, the user Alice hasn't accessed anything for 467 days, as a result I can say with some confidence that this user can be removed and deleted from IAM. So it's a great way to ensure that you don't have any unused user accounts, and deleting unused accounts is an IAM best practice.

MFA. MFA stands for Multi-Factor Authentication, and so this will highlight any users that have been configured with MFA which adds an additional level of verification, enhancing security. The users in my example that show virtual mean that these users are using MFA on a virtual device, and in this example it's the Google Authenticator app on a mobile phone. For those unfamiliar with MFA, let me give a brief explanation of what it is. Typically, when a user logs into the AWS Management Console, they will authenticate to your AWS account by providing their identification, typically their username, and then verify this identification, usually with a password. These two elements, the identification and verification, allow the user to authenticate. For many cases, the verification, the password, is sufficient enough to confirm the identity, the username. However, for users who have an elevated level of privileges, for example the users may have full access to a large number of AWS services, then you may want to, or be required to due to governance controls, implement an additional verification step within the authentication process. This adds another layer of security attached to the identity, and this is where Multi-Factor Authentication comes in, MFA. The name explains itself, it's used to create an additional factor for authentication in addition to your existing methods, such as a password. Therefore creating a multi-factor level of authentication. So what is this additional level of security that MFA brings with AWS? MFA utilizes a random six-digit number that is only available for a very short time period before the number changes again which is generated by an MFA device. There is no additional charge for this level of authentication, however, you will need your own MFA device, which can be a physical token or a virtual device. AWS provides a summary of all supported devices here. Personally, I use Google Authenticator on my phone because it is simple and easy to set up and configure. Password age. This shows how long ago it was until the password of the user was changed. As a security best practice, your passwords should be changed regularly.

Console last sign-in. This column simply shows the last time a user signed in to the management console.

Access key ID. The access key ID will identify if it's active or inactive and will display the key in use. Before I continue, let me just quickly explain a little more about Access Keys. Access Keys are used for programmatic access to your AWS resources, and they are comprised of two elements. An access key ID and a Secret Access Key ID The Access Key ID is made up of 20 random uppercase alphanumeric characters, such as the one shown here. The Secret Access Key ID is made up of 40 random upper and lowercase alphanumeric and non-alphanumeric characters, such as the one displayed on the screen. During the creation of a user who requires programmatic access, you are prompted to download and save these details and it'll only be displayed once, and if you lose it, then you will have to delete the associated Access Key ID and recreate new keys for the user. It's not possible to retrieve lost Secret Access Key IDs as AWS does not retain copies. These access keys must then be applied and associated with the application that you are using that requires the relevant access. For example, if you were using the AWS CLI to access AWS resources, you would first have to instruct the AWS CLI to use these Access Keys to authenticate you providing authorization. The method of performing this association varies based on the application and system that you are using. However, once this association has taken place it ensures that all API requests made to AWS are signed with this digital signature.

Active key age. The active key age refers to the age of the access keys that are associated with the user which, as I explained, are required for programmatic access. Access key last used. This column just shows the last time that the user used their Access Keys within your AWS account. As a security best practice, it's a good idea to remove any access keys that haven't been used for quite some time. This removes possible entry points for malicious users to gain access to your environment.

The ARN. The ARN, or Amazon Resource Name provides the unique identifier for referencing that particular user. For example, the one showne here for the user Stuart. Creation time. This is a simple time metric to show you how long ago the user was created Console access. The console access helps you to determine which users have access to the Management console. When creating a new user, you have the option to configure their access type as seen here. Each user can be configured to have Programmatic Access, or AWS Management Console Access, or both. If they have access to the Console, then this column will show as Enabled for the user and Disabled if the user does not have console access.

Signing certs. Finally, the last column of signing certs will show if the user has a Signing Certificate or X.509 Certificate associated with them for secure access to certain AWS product interfaces. For example, EC2 uses a Signing Certificate for access to its SOAP, Simple Object Access Protocol, and command line utilities. Finally, before we finish this lecture, you can also create and delete users as required, and search for any of your users via their username or access key from within the user dashboard.