- [Instructor] Now let's review a demo
of managing an MFA device. Okay,
so once again from the management console dashboard
in order to manage MFA devices,
for particular users,
we would need to be in the IAM service.
So, since we've been there recently, we can find it here
and we're going to first let's take a look at our users.
So, our, my user, the admin user that I'm currently
logged in with, already has an MFA device present.
You can see that I have a virtual MFA device,
but the Amy Fowler user does not.
And so very much like axis keys, I could create one for her.
Now and if, so I could go here to her user, I go to
the security credentials tab, and it says here
an MFA device is not assigned.
Now if we worked in the same office, where I could say,
"Hey Amy, come over here to my desk", then I could say,
go through this process and create a QR code
that she could then scan with her virtual MFA application
be it AUTHY or Google Authenticator, or whatever.
If Amy is remote and I'm remote and we're, you know,
not in the same office, then of course that's not possible.
I would have to, if I, created the device for her,
then I would have to somehow
transfer specific information about that MFA device to her.
And I don't really like doing that.
Now you may have a way, a transfer method
that you trust to be secure and that's fine,
but again, for users managing things like this,
access keys and MFA devices, I prefer to
empower them to do it themselves.
So I want, just like I want users to manage
their own password, I want them to manage
their own access keys. I generally want them to
manage their own MFA device as well.
And so, I'm not going to do it for her,
I'm going to make sure that she has the ability to
do that. So, this is true for every user, right,
not just for developers but everyone.
So I wanna take a look at the everyone group.
So if we were to take a look here at the everyone group,
and then we looked at the permissions,
just like a user needs permission to change their password,
they need permission to manage their access keys,
they also need permissions to manage their MFA device.
So I've taken the liberty to create and attach,
this new policy here, called User Self Managed MFA device.
Right, so let's take a look at that policy
and see what kind of permissions that is granting.
So you can see here that we are allowing
several different actions that all relate to
the management of MFA devices and some of these require
the user type, some of them require the MFA type.
So, within the IAM service, there are different types of
resources, users, groups, roles,
policies, and of course, MFA devices.
And so, if we did not include the MFA type resource,
then several of these actions like,
create virtual MFA device, would give us an error.
It would tell us we don't have that permission
because we, some actions require
specific types of resources to be defined.
So, now that we've given our,
everyone group the ability to
manage their MFA device, we can also, what we want to do is
enforce MFA. Now this is up to you.
You don't have to do this, but it's just something
that you can do to add an extra layer of security.
Okay, so let's take a look at another policy that I created,
called (keyboard clicks) ForceMFA.
So actually if we search for MFA, you'll see
the two different policies here, the self manage
and then another one called ForceMFA.
All right so I'm gonna take a look at ForceMFA
and lets just take a look at this policy down here,
you'll see that we are using a deny, an explicit deny.
And remember that deny rules will take precedence
over allow rules. Right so if you have
two conflicting statements, the deny will win.
Now what I really want to draw your attention to here is
the "not action". Right, so all of the other policies
that we've create and make made use of,
have leveraged the action key,
where we here are using the "not action" key.
So what this essentially means is,
we are denying
all actions,
other than
IAM actions,
under the condition that
the Multi-Factor Auth Age header
in the request, or the parameter and the request, is known.
So essentially what this means is that under the condition
that multi-factor authentication was not used,
deny the request for actions other than IAM actions.
Right so user information and create a MFA device
and enable and activate that device.
And then otherwise if they try to do something with
EC2 or Lambda or S3, they can only do those actions
if their multi-factor authentication
was used during their login. So again,
an extra layer of security. Right,
and we have, so we are going to apply this,
let's go back to groups and take a look at
the developer's group and you can see I've already applied
the ForceMFA to the developer's group.
We don't want to, we don't want to force MFA
necessarily for everyone, but maybe only certain users.
Okay so I've done all of that under my admin user,
I'm going to go ahead and sign out and I'm going to
log back in as the A.Fowler user.
Okay, so now that we're logged in as A.Fowler, let's go,
we again, we could find the MFA management under IAM,
we could go there and then find the user,
or we would just go here to my security credentials.
And of course, for A.Fowler, we've already done a password,
we've created access keys,
so here we can say assign MFA device.
And according to those permissions,
we we can only manage one for our current user.
Before we do that though, I want to point out
that because because we logged in without MFA,
we should not be able to do anything in an EC2
or Lambda for example. Let's just experiment here
and lets go to Lambda and it should give us an error.
Yep, you are not authorized to perform,
lamba get account settings, right.
And if we were to try to DynamoDB,
(keyboard clicks)
it should also give us an error, right.
Let's say create table, if we just say test,
test, and create, it should give us an error.
There we go, not authorized, right.
And that's because we did not log in with MFA.
All right, so let's go back
to IAM, or again we could go back to security credentials
We're going to say assign MFA device,
and here you can see that we have our choice of
virtual MFA device, which is some type of application,
on your mobile device or your computer.
My favorite two are AUTHY(A-U-T-H-Y)
and Google Authenticator.
There are others, but those two I've used over the years
and they've never failed me. We could also use a
U2F security key,
or a Gemalto hardware.
So you can order Gemalto hardware key fobs
from Amazon.
So in this case we're going to use a virtual MFA device.
We'll say continue and now we have a couple of options.
We could either get a QR code and we could scan it
into our phone, or we could show the secret key
and then copy and paste that. So, if you're using
an MFA application on your local machine,
you could just show the secret key
and then we could copy and paste that into the application.
For our mobile device, we could go show QR code,
and then what I would want to do is open the device
on my, or open the application on my phone
and we would add a new account and say scan QR code
and we would hold our phone up to the screen
and very quickly, it would grab that QR code
and all of the information that it needs.
The account name, the secret key,
all of that would be included in the QR code, right.
And so once we have that in our virtual device,
then we need to add two different codes, right.
So, and of course, these are generated
about every thirty seconds. So the first one here, 849983,
931, all right and so now that we've gotten
those two MFA codes, two consecutive MFA codes,
now we can say assign MFA device.
Amazon will verify those codes and then we can say close.
Right, so now that we have that, you can see
that the A.Fowler user has the assigned MFA device enabled,
but she still hasn't logged in with it.
We have to actually log in with it for it to
enable us to do things with Lambda or DynamoDB, right.
So let's log out and log back in and see the difference.
So we'll go log right back in as A.Fowler
and there you go.
It's asking for an MFA code and I will just enter one.
(keyboard clicks)
And now we are authenticated.
And so now that MFA is present,
we should be able to go to Lambda
and see everything we need to see without, there you go.
You can see we have a couple of functions in here
and we did not get that same error
and that's because of the ForceMFA policy that we applied.
Right, so again, you can find those MFA information
in manage MFA devices from the security credentials
tab underneath the user. And so now this user is
fairly secure, right, they have a strong password,
they have access keys that they've
downloaded directly themselves,
and they've enabled their own MFA device
and MFA is enforced on a number of things
that they are doing in their day to day operations.