AWS re:Inforce 2022 - Security best practices with AWS IAM (IAM201)

Aug 16, 2023

AWS re:Inforce 2022 - Security best practices with AWS IAM (IAM201)

AWS IAM is an essential service that helps you securely control access to your AWS resources. In this session, learn about IAM best practices like working with temporary credentials, applying least-privilege permissions, moving away from users, analyzing access to your resources, validating policies, and more. Leave this session with ideas for how to secure your AWS resources in line with AWS best practices.

Learn more about AWS re:Inforce at https://bit.ly/3baitIT.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInforce2022 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Content

0.54 -> - All right. Welcome, everyone, to IAM best practices.

4.86 -> It's the afternoon. You're tired.

7.92 -> We're gonna try to keep it fun today,

9.75 -> talk about some permission stuff, some identity stuff.

13.59 -> But since we all know I love policies,

15.9 -> let's start with a fist pump for policies.

18.63 -> There we go. We are the best session here.

22.65 -> No, my name is Brigid.

24.15 -> I am a senior manager, I own Access Analyzer

27.84 -> so we'll talk a little bit about that today.

29.7 -> I've been in identity for a while,

31.08 -> talking about permissions.

32.16 -> You'll see my horse, Pickles.

33.66 -> And I'm joined here today with Matt.

36.239 -> - Hey, everyone. - And we are going to cover

38.55 -> a little bit of identity overview

40.14 -> so you know what we're talking about,

41.58 -> and then we'll dive into each of the best practices.

44.04 -> So fun fact, we just launched

47.16 -> and revamped the new best practices

49.56 -> so you can go check them out.

50.58 -> There are 14 of them.

52.11 -> We are actually only gonna cover 13 today,

54.39 -> so you get to figure out which one we didn't cover,

56.58 -> and we actually didn't cover it on purpose.

58.44 -> But we'll dive into identity and credential management,

61.47 -> permission management, and the tools to guide you.

64.5 -> And for each one, we'll talk about why it's important,

66.87 -> why you need to consider it for your business case,

69.3 -> what it really means, and how to do it at the highest level.

74.85 -> All right, when we talk about identity,

76.77 -> it's always the same, who can access what.

79.95 -> And you can get super fine-grained

82.95 -> in determining and setting those access controls,

85.71 -> Who are your developers and your applications.

88.41 -> These are your human users and your applications,

91.59 -> your workloads, your automated jobs, whatever.

96.72 -> Your what are your resources.

99 -> These are your buckets, your Lambda functions,

101.25 -> your batch jobs, your step functions,

103.38 -> and on and on and on and on across AWS.

105.87 -> And then where it all comes together,

107.25 -> that's my favorite part.

108.39 -> Those are your access controls, that's IAM,

110.58 -> those are your permissions,

111.57 -> it connects the who and the what,

113.22 -> and that's how we think about permissions.

115.56 -> All right, so for the set of identity best practices,

118.29 -> identity and credential best practices,

119.94 -> I'm gonna hand it over to Matt.

123.06 -> - All right. Thanks, Brigid.

125.55 -> Like Brigid mentioned,

126.57 -> I'm going to walk you through each of the best practices,

129.18 -> starting with identity and credentials management.

131.88 -> We're going to explain why we think it's a best practice,

135.36 -> and then we're also going to explain

136.68 -> how to actually implement that practice on AWS.

139.35 -> So hopefully you leave here

140.37 -> with something to take back to your organization

142.23 -> more than just Matt and Brigid said so,

144.93 -> but please feel free to try that

146.34 -> and let me know how it goes.

149.22 -> So the first best practice I wanna talk about today

151.17 -> is require human users

153 -> to use federation with an identity provider

155.64 -> to access AWS using temporary credentials.

160.02 -> Now, I'm gonna start with some definitions.

162.33 -> So we've got human users,

164.01 -> and human users are your developers,

166.74 -> your business analysts, your data scientists.

170.13 -> These are folks that are accessing AWS

172.2 -> using the CLI, the Console, maybe a client application.

176.49 -> They're typically internal to your organization

178.26 -> and we refer to those users as workforce identities.

181.5 -> They can be, less often,

182.64 -> external to your organization as well.

185.13 -> Then we have your workloads.

186.36 -> Your workloads are your CICD pipelines,

188.13 -> your applications, your infrastructure.

190.23 -> These are the things that are authenticating to AWS

192.33 -> where there's not actually a human behind the keyboard

195.3 -> doing that authentication,

196.83 -> and we refer to these as your machine identities.

201.66 -> So why bother using an identity provider in the first place?

205.23 -> And one reason is to centralize user stores.

208.65 -> You've got your joiners, your movers,

210.48 -> your leavers in your organization,

212.4 -> and you don't want to have multiple disparate systems

215.88 -> when somebody changes departments or leaves the organization

218.79 -> that you have to go update.

221.01 -> Reduce password fatigue.

222.87 -> I know, as a user, I don't want to be making,

226.29 -> or I don't want to have to be maintaining passwords

228.93 -> in many separate systems.

231.33 -> Users tend to pick less complex passwords,

233.73 -> easier to remember passwords,

234.99 -> and they also tend to duplicate passwords between systems.

239.46 -> We wanna decrease the number of systems

241.23 -> that you have to secure.

242.52 -> If you have a single identity provider,

244.08 -> you can focus your efforts

245.16 -> on securing that identity provider.

247.38 -> And then ease of auditing.

249.09 -> If you can tie back where the requests are coming from

252.3 -> to a single source of identity,

254.04 -> you make your life a whole lot easier

255.27 -> from an auditing perspective.

259.92 -> In AWS, human access is done with IAM Identity Center.

264.69 -> And if you missed the announcement yesterday,

267.42 -> AWS SSO is now known as IAM Identity Center.

271.62 -> To get started with IAM Identity Center,

273.18 -> you're going to want to choose your identity source.

275.73 -> Now, you can choose Identity Center directory,

278.1 -> which is where you store your usernames and passwords

280.2 -> directly in Identity Center,

283.11 -> you can choose an existing Active Directory domain

286.77 -> to connect to,

288.21 -> or you can choose an external identity provider.

291.84 -> If you choose an external identity provider,

293.61 -> you're going to need to sync your identities

295.38 -> with Identity Center.

297.15 -> You can do that manually

298.23 -> or you can use the SCIM protocol to do that as well.

301.62 -> And once you have those identities

302.97 -> synced into Identity Center,

305.19 -> you now have one place to manage permissions

307.83 -> to your AWS accounts in your AWS organization.

311.4 -> You can also manage connected applications

313.56 -> with Identity Center as well.

316.5 -> So now I'm gonna jump into a quick Identity Center demo,

319.71 -> where we're gonna walk through the console,

321.75 -> we're gonna add a user to a group,

323.55 -> and we're gonna assign some permissions.

324.99 -> So let me go ahead and get that set up here.

327.3 -> - Demo time. Live demo.

329.64 -> Matt's gonna do it.

330.69 -> - All right, so here we are in the Identity Center console.

334.71 -> The first thing I wanna point out

336.27 -> is my favorites bar up here.

338.91 -> Hopefully all of you have this

340.44 -> on your favorites bar as well, so-

343.56 -> - I mean, IAM is my favorite. - Yeah.

346.14 -> I'm gonna go to the Settings first

347.34 -> and just show you my identity source

348.78 -> that I have configured here.

350.686 -> For the sake of this demo,

351.6 -> we're gonna use the Identity Center directory,

353.82 -> meaning I'm storing usernames and passwords

355.83 -> directly in Identity Center.

358.5 -> But if I go over here, I can see

360.3 -> that I can also specify an Active Directory directory

363.36 -> or an external identity provider as well.

368.31 -> I'm gonna take a look at my groups.

370.5 -> I've got a number of groups that correspond

372.72 -> to the job roles that I have in my organization.

375.99 -> And I also have a very lonely organization, it's just me.

380.91 -> So what I'm gonna do is I'm gonna go ahead

382.59 -> and I'm going to add myself to the Developers group.

385.23 -> I have a developer background,

386.43 -> seems like the appropriate group.

390.51 -> Okay.

393.18 -> Now, you wanna manage access in Identity Center with groups.

397.35 -> You don't want to be assigning individual users

399.87 -> to individual accounts,

400.703 -> and I'm gonna show you here in a second

401.64 -> how you assign a group to an account.

404.37 -> So you wanna add your users to a group,

406.38 -> or, like I said,

407.213 -> if you're using an external identity provider,

408.99 -> you can sync those users in groups

410.85 -> from that identity provider.

412.86 -> And then I'm gonna go here to AWS accounts.

419.1 -> I've got a few accounts,

420 -> I've got my demo account and developer account.

423.9 -> Let's say I wanna give my developers access

425.91 -> to both of these accounts.

428.46 -> I'm gonna click up here, Assign users and groups.

430.59 -> Like I said, you wanna manage access at the group level,

434.19 -> and I'm gonna select Developers.

436.62 -> Just gonna validate

437.453 -> that I have selected the correct group here,

439.02 -> and I'm gonna click Next.

442.44 -> Now it's gonna ask me to select my permission set.

445.05 -> Now, what is a permission set?

446.4 -> So let's go ahead and open this up.

449.61 -> A permission set is a template.

451.74 -> A permission set's a template for your IAM roles.

454.98 -> So when I go and assign my developers access

458.52 -> to an individual account,

460.32 -> what's actually going to happen

461.52 -> is Identity Center's going to look at this template,

464.34 -> look at the policies that I have assigned in this template,

466.71 -> and create an IAM role in my destination accounts

470.28 -> that match this template.

473.16 -> So you can see here, I've got a managed policy.

475.44 -> This is a production environment.

477.63 -> I might not trust my developers.

479.43 -> I've got a read-only access policy here.

482.88 -> So I'm saying that this permission set

485.43 -> allows developers read-only access

487.08 -> to the accounts that I assign it to.

489.66 -> Let me go back to my wizard over here.

492.69 -> I'm going to select DeveloperAccess, click Next,

497.25 -> review what I've just configured here, and click Submit.

501.57 -> So this is where it's going to go into my accounts,

504.3 -> associate that permission set with my accounts,

506.85 -> and create roles in my accounts that I can then log into.

511.14 -> So now that I've done that, what I wanna do is,

514.35 -> just refresh this real quick,

519.39 -> I'm gonna log in

524.1 -> as that account, or as that user,

529.08 -> and I land on this page.

531 -> So now I get a page

531.833 -> where I can select either my demo account

533.49 -> or my developer account, either account.

537.48 -> I click to expand.

539.58 -> And if I expand the other one,

540.51 -> you'll see I have the same exact access to both accounts.

543.45 -> I will click on Management console here,

547.56 -> and I'm into my account.

549.27 -> And one important thing to note

550.65 -> is I'm into the account but I'm using an IAM role,

554.4 -> so I'm using temporary credentials.

556.95 -> I've used Identity Center to federate into my account,

559.98 -> and now, you can see up here, I've got this IAM role

563.49 -> with this really long reserved name.

566.403 -> (Brigid laughs)

569.82 -> All right, so let me just switch back.

575.185 -> - There you go.

576.09 -> Thanks for the demo, Matt. That was fun.

579.39 -> Love live demos, and it all worked.

581.61 -> - Yeah, so the next best practice I wanna go to,

585.06 -> we talked about human users,

586.8 -> is require workloads to use temporary credentials

589.92 -> with IAM roles to access AWS.

592.89 -> Now, we just talked about temporary credentials,

594.45 -> but I didn't really explain

595.59 -> why temporary credentials are a good thing.

598.44 -> So the first reason is they have a limited lifetime

600.9 -> and an automatic expiration,

603.03 -> so you don't need to rotate them

604.53 -> and you don't need to explicitly revoke them

606.48 -> when they're no longer needed.

609.09 -> Temporary credentials also eliminate the need

611.07 -> for long-term credential distribution and storage.

614.31 -> So with temporary credentials,

616.14 -> applications just request them when they need them.

621.09 -> So with that said, what we want you to do

623.13 -> is prefer IAM roles or temporary credentials

626.73 -> to IAM users or long-term credentials.

630.51 -> Many of our AWS services

631.83 -> have native integrations with IAM roles.

634.65 -> We want you to use those native integrations.

636.75 -> So here's an example.

638.46 -> In this case, I'm trying to launch an EC2 instance.

641.31 -> What I'm going to do

642.143 -> is I'm gonna start with Matt's IAM role.

644.01 -> I'm gonna add it to what's called an EC2 instance profile,

647.04 -> which is mostly just a container for my IAM roles.

649.92 -> I'm gonna take that and associate it with an EC2 instance.

653.34 -> Once that instance profile

654.69 -> is associated with that EC2 instance,

657.48 -> what my applications

658.53 -> that are running on that instance can do

660.36 -> is they can automatically request

661.56 -> those temporary credentials.

663.78 -> Those temporary credentials are automatically refreshed

666.69 -> and rotated for me.

668.34 -> And if you're using our CLI or SDK,

670.89 -> they're automatically discoverable as well

673.38 -> when you're running on that instance.

676.2 -> So a pro tip as well, when you're dealing with IAM roles,

680.85 -> use a single role for a single responsibility,

683.73 -> use a different role for different applications,

686.37 -> use a different role for different services.

689.28 -> Brigid's gonna talk later about least-privilege.

691.41 -> This is a very important concept

692.97 -> when we talk about least-privilege.

697.56 -> So what do we do for those workloads

698.73 -> that aren't running on AWS?

700.47 -> Now, you might have workloads

701.4 -> that are running in a data center,

703.05 -> you might have workloads

704.52 -> that are running on other infrastructure,

707.25 -> so instead of creating and distributing

709.11 -> and maintaining those long-term credentials,

712.02 -> you can use IAM Roles Anywhere,

713.73 -> and this is a fairly recent launch.

716.43 -> So what IAM Roles Anywhere does

718.02 -> is it uses X.509 certificates

720.6 -> from your certificate authority to authenticate with AWS

725.88 -> and provide secure access to your AWS resources.

730.17 -> So if you have workloads running outside of AWS,

733.89 -> check out IAM Roles Anywhere.

740.97 -> Next best practice,

741.84 -> require multi-factor authentication, or MFA.

746.28 -> Now, most of you probably know what MFA is already,

749.1 -> but MFA combines what you know,

752.28 -> which is typically a username and password,

753.9 -> with what you have, which is typically some sort of token.

757.14 -> But we want you to apply MFA

758.88 -> to all humans accessing AWS resources,

761.61 -> and that includes your IAM users if you do still have them,

765.27 -> your IAM root user especially,

768.39 -> and any other human that's using your identity providers

770.91 -> to log into AWS.

776.25 -> All right, next best practice

778.23 -> is rotate your access keys regularly

780.3 -> for those use cases that do require long-term credentials.

785.22 -> Access keys are a particular type of long-term credentials

788.67 -> associated with both IAM users and IAM root users,

791.91 -> and they're used for programmatic access to AWS.

795.24 -> We don't recommend using,

797.7 -> we don't recommend creating access keys

799.65 -> for your IAM root user,

802.05 -> but for IAM users, you should rotate your access keys.

805.92 -> Now, the waterwheel that you see here

807.39 -> is going through tens of rotations per minute.

810.6 -> That's probably a bit extreme

812.07 -> for how often you should rotate your access keys,

814.71 -> and, typically, what we mean by regularly

816.78 -> is it's defined by your security

818.58 -> and your regulatory requirements.

820.53 -> - [Brigid] I was hoping people

821.363 -> were actually looking at those pictures.

822.767 -> (Matt laughs)

824.61 -> - So why rotate your access keys?

827.01 -> We wanna make those long-term credentials

828.84 -> a little less long-term,

830.7 -> so let's limit the length of time

832.29 -> that the access key is actually valid.

835.08 -> But equally, if not more, important is to practice

838.77 -> for when you actually need to revoke those access keys,

842.25 -> say, when an employee leaves the company.

848.73 -> How do we rotate access keys?

851.31 -> First thing we'll do

852.143 -> is we'll start by creating a new access key,

854.61 -> and now we have two access keys for our IAM user.

857.64 -> We'll update all of our applications

859.62 -> that are using those access keys

861.33 -> to use the new access key.

864.66 -> Step three is we'll validate

866.25 -> all of those applications are updated.

869.19 -> Now, this one tends to be use case specific.

872.88 -> You might have an out-of-band way

874.08 -> to validate that your applications have been updated

876.6 -> and are using those access keys.

878.67 -> You can also look at the old access key,

881.04 -> and in the AWS Console,

882.15 -> there is a Last Used property where you can determine

885.15 -> when that old access key is last used.

887.31 -> You can also do the same look-up

889.08 -> with the CLI or SDK as well.

891.87 -> So once you've validated that your applications are update,

894.33 -> you'll mark that old access key as inactive,

896.91 -> and marking an access key as inactive

898.41 -> just renders it unusable.

900.63 -> You can always go back and mark it active again

902.31 -> if you find that there is still some use cases

904.47 -> that are using that old access key.

907.2 -> And then you'll wait some period of time,

909.12 -> whether that's days or weeks, that's kind of up to you.

912.33 -> You'll wait some period of time

913.41 -> and then you'll delete that old access key

915.18 -> when you're sure that it's no longer in use.

917.85 -> And you can kind of tighten some of these windows

920.28 -> as you get more experienced

921.51 -> and trust your process a bit more.

924.18 -> So once you become very confident

927 -> in your access key rotation process,

928.32 -> maybe you wait hours instead of days

930.9 -> to actually delete the old access key.

933.81 -> Now, this is one of those best practices

936.813 -> that I hope you actually don't have to use.

939.72 -> And I say that meaning,

942.51 -> we want you to use temporary credentials,

944.16 -> we want you to use IAM roles.

945.42 -> We don't want you to have to go through

946.86 -> this access key rotation process.

948.6 -> We want you to take advantage of the fact that IAM roles,

952.65 -> their credentials are rotated for you.

959.97 -> All right, and the next one is a big one.

962.04 -> Safeguard your root user credentials

964.68 -> and don't use them for everyday tasks.

967.8 -> You don't want your environment

969.33 -> to end up looking like this tree over here,

972.21 -> where your root usage is the foundation

974.52 -> of everything that happens in your environment.

978.145 -> - [Brigid] That was a good one.

980.67 -> - So why do we care to limit the use of root credentials

983.58 -> in the first place?

984.9 -> Well, first of all, they're long-term credentials,

986.88 -> and I just got done talking

988.11 -> about how we want to prefer temporary credentials

990.48 -> to long-term credentials.

992.73 -> The second reason is they have full unrestricted access

995.91 -> to your AWS account.

998.67 -> Now, roles created underneath that root user

1001.67 -> can be restricted by IAM,

1003.11 -> whether they're a resource-based policy

1005.63 -> or an identity policy,

1006.74 -> and Brigid's going to get into a little bit of that.

1010.94 -> So for these reasons,

1012.02 -> we want you to limit the use of your root credentials.

1014.18 -> Now, there are some actions in AWS

1015.77 -> that still require the use of root credentials,

1018.47 -> but those are things like updating the email address

1020.84 -> that's associated with the account,

1023.39 -> changing the support plan on the account.

1026.18 -> These are actions that you're not performing frequently

1029.54 -> so you really should not be using your root credentials

1032.36 -> on a day-to-day basis.

1035.36 -> Now, how do we protect our root credentials?

1038.3 -> First thing, we need to protect the credentials themselves.

1042.23 -> Now, when we talk about credentials

1043.7 -> for both IAM users and IAM root users,

1046.19 -> we're talking about two different types of credentials,

1047.99 -> maybe three different types of credentials.

1050.6 -> There's the Console username and password

1053.36 -> that you use to log into the AWS Console,

1055.49 -> there are the access keys that we talked about before,

1057.5 -> which are used for programmatic access to AWS,

1060.83 -> and then there's MFA tokens as well.

1063.92 -> So the easiest credential to protect

1065.78 -> is the one that doesn't exist.

1067.73 -> Don't create access keys for your IAM root user

1070.58 -> and you don't have to worry about protecting them.

1073.22 -> For the Console login,

1075.47 -> we suggest that you create a complex password

1078.05 -> and store it in something like a password vault.

1081.41 -> For the MFA tokens themselves

1083.03 -> that you're going to attach to the root user

1085.25 -> because you saw my previous slide,

1087.62 -> for the MFA tokens themselves, if you have a physical token,

1091.34 -> you can store it in a physical safe

1092.93 -> and can control access to that safe.

1095.36 -> If you have a virtual token, you can take the secret key

1099.71 -> that's used to generate the time-based, one-time password

1102.41 -> and store that in something like a password vault as well.

1106.52 -> Consider using something like a two-person role

1109.822 -> for access to the MFA token as well as the password,

1114.41 -> and what I mean by that

1115.4 -> is no single person should have access to both.

1118.82 -> And that does depend

1119.653 -> on your particular organization's requirements,

1121.94 -> but that's a general good practice.

1124.28 -> The other thing you can do

1125.15 -> is you can just take that login password

1128.18 -> and just throw it away.

1130.04 -> Set a very complex password for it

1134.03 -> and just don't write it down anywhere,

1135.98 -> 'cause then you'll rely

1136.813 -> on the root credential recovery flow process

1139.61 -> for that password, which you have to protect anyway.

1143.51 -> So that brings us to the next thing,

1144.8 -> protecting the root credential recovery flow.

1147.62 -> Now, we can reset either the password itself

1151.67 -> or the MFA token.

1152.66 -> Those are the two things we need to protect here.

1155.12 -> Resetting the password is done via email

1158.15 -> to the mailbox associated with the account.

1160.73 -> Resetting the MFA token is done via a combination of email

1164.51 -> and a phone call.

1166.46 -> So you want to control access to the email address

1168.86 -> associated with the account

1170.48 -> as well as the phone number associated with that MFA token,

1173.99 -> and, again, consider using that two-person role.

1178.22 -> Now, once your credentials are protected,

1180.98 -> you wanna prevent and monitor the usage of them.

1183.47 -> I said prior that the root credentials

1186.56 -> had unrestricted access to your account.

1188.57 -> The one thing that you can do

1189.68 -> is you can create what's called a service control policy,

1192.05 -> which is an AWS Organizations construct,

1195.14 -> that can deny root in child accounts in an organization.

1201.71 -> So you can use IAM to block root in child accounts

1204.02 -> if you're in an organization.

1206.33 -> Now, on the monitoring side,

1207.68 -> we recommend using a service like AWS GuardDuty

1210.5 -> to look for unauthorized uses of those root credentials.

1215.84 -> And with that, I am going to pass it over to Brigid

1218.72 -> to talk about one of my favorite topics as well,

1220.7 -> which is permissions management.

1222.8 -> When Brigid and I were trying to figure out

1224.33 -> who is actually going to talk about what in this topic,

1227.99 -> or in this talk, we flipped a coin,

1229.577 -> and you can see who won that coin flip.

1231.98 -> Also, I don't have a really cool horse.

1233.99 -> - Yeah, permissions and Pickles go together.

1237.68 -> So I'm gonna take it from here

1238.76 -> to talk about best practices for permission.

1242.3 -> So the first...

1243.2 -> Oh, we need to talk about permissions and what they are.

1246.26 -> When we think about permissions, there's two parts.

1249.59 -> One is your job.

1251.03 -> Who's written an IAM policy? Raise your hand.

1253.52 -> Only one person? Okay, there we go, there we go.

1256.4 -> This is where you get to specify who can access what,

1259.07 -> and you get really fine-grained.

1260.36 -> You can specify the principals,

1262.58 -> the actions, there's thousands of them,

1264.83 -> the resources, there's hundreds of types,

1267.41 -> and you get into the conditions

1269.51 -> for specifying who can access what.

1271.82 -> Once you specify that, then it's our job,

1274.58 -> and our job is to enforce,

1275.69 -> so for every access control in AWS,

1278.42 -> we look at the policies, we look at the requests coming in,

1281.24 -> and we give a yes or no answer, an allowed or denied.

1287.72 -> This is a policy. I'm sure you all have seen it, hopefully.

1292.16 -> We like to call this the PARC model.

1294.08 -> And essentially, you can say allow principal,

1298.13 -> which action they can have on which resource

1300.56 -> under which conditions.

1302.9 -> You can use a lot of documentation and tools we have

1305.51 -> to actually specify these items.

1310.43 -> So when we think about the first best practice,

1312.35 -> you think about applying least-privilege.

1314.33 -> And I want you to think about applying it

1316.01 -> just like you would apply makeup.

1317.87 -> Just kidding, that's not really doable,

1320.03 -> but I thought the picture was funny.

1323.15 -> So what is least-privilege?

1324.8 -> Least-privilege is granting users and systems

1327.74 -> the narrowest set of permissions

1329.69 -> to complete the required task.

1331.61 -> And we hear least-privilege

1333.14 -> all over this conference, at re:Inforce,

1335.39 -> we hear it from customers,

1336.95 -> but I need you all to know that that required task

1340.16 -> will change based on your use case.

1342.41 -> You might be in development,

1343.58 -> you might be exploring building something new.

1345.74 -> Your permissions are gonna be broader in that scenario,

1348.86 -> versus if you're in production

1350 -> and you have a hardened workload

1351.29 -> that deals with processing credit card data,

1353.69 -> those better be very tightened permissions.

1356.09 -> And so there is this balance that you wanna work towards

1358.91 -> to let builders build, to let the business innovate,

1362.87 -> also set them up for success

1364.43 -> so you can prevent dangerous actions,

1366.2 -> have an accountable security posture.

1368.36 -> So when you think about least-privilege,

1369.65 -> it's not a checkbox, it is a journey.

1374.48 -> And the journey, you can be anywhere on this,

1377.39 -> and different workloads, different teams are also on this.

1379.97 -> So if you're just getting started and you're exploring,

1383.18 -> you can start with AWS managed policies or custom templates.

1386.36 -> A lot of organizations come out with things they approve of.

1390.05 -> Then you don't wanna stay there.

1391.61 -> You're gonna wanna get to right-sizing,

1393.74 -> and that's where you can generate and customize policies

1396.68 -> with IAM Access Analyzer.

1398.66 -> But if you really wanna get fine-grained,

1400.7 -> and you know that's how I like to operate,

1403.22 -> then you're gonna wanna do the DIY model,

1405.95 -> the do-it-yourself model,

1407.39 -> and that's where you get to specify conditions.

1409.43 -> But don't worry, we have your back there, too,

1411.23 -> because we have policy validation with IAM Access Analyzer.

1415.49 -> And we're gonna demo two of these today.

1418.61 -> But before you get doing that fine-grained permission

1421.52 -> within the account,

1422.63 -> you need to establish permission guardrails

1425.39 -> across multiple accounts.

1426.95 -> So hopefully you're using multiple accounts

1429.05 -> for your workloads,

1430.61 -> and you're using them with AWS Organizations,

1433.55 -> and then you're gonna wanna establish

1435.2 -> those permission guard rails.

1436.64 -> This sets engineering teams up for success.

1438.98 -> It kind of gives them those bumpers

1441.02 -> so they do the right thing.

1442.25 -> You would wanna restrict who can modify network controls,

1445.7 -> who can modify powerful permissions,

1447.65 -> who can grant access

1449.18 -> to modify permissions on a bucket, et cetera.

1452.27 -> So think about what are the general things

1454.28 -> you wanna restrict and bubble them up to the guardrail

1457.88 -> across your entire organization.

1460.58 -> And one of these guardrails is a data perimeter.

1463.76 -> We've heard this more and more from customers.

1466.25 -> We're working on helping you take all of the access controls

1469.94 -> that we have across AWS

1471.56 -> and put them together so you can establish a data perimeter.

1475.4 -> And this will help you meet your compliance requirements,

1477.95 -> build a corporate boundary

1479 -> so your stuff stays within your stuff,

1481.46 -> allow developers to build within a safe place,

1485.36 -> and have defense in depth.

1487.94 -> So what is a data perimeter?

1490.31 -> It is a set of preventative guardrails

1493.88 -> in your AWS environment

1495.68 -> that helps you ensure your trusted identities

1498.11 -> are accessing your resources from your expected networks.

1502.7 -> So if we think about this picture,

1504.47 -> you wanna protect everything that's in your space,

1507.62 -> and that's that green box over there.

1510.32 -> Pickles, he's out on the internet.

1511.94 -> You might not want him in your AWS environment.

1514.04 -> You don't know what he is going to do.

1518.48 -> And so what makes a data perimeter?

1520.37 -> I talked about your trusted identities.

1522.65 -> Those are your users, your roles within your organizations,

1526.34 -> or AWS services operated on your behalf.

1529.67 -> Your trusted resources, that's your stuff.

1531.62 -> Those are your buckets, your Lambda functions,

1533.87 -> your queues, your topics,

1535.34 -> all of the good things that AWS has to offer.

1537.74 -> And then your expected networks,

1539.18 -> these are your on-prem data centers or your VPCs

1543.77 -> or networks that AWS is using to act on your behalf as well.

1547.25 -> We have a lot of those management services

1548.9 -> where we act on your behalf.

1553.67 -> We recommend using conditions to restrict access further,

1557.48 -> and there are a lot of condition keys out there

1559.91 -> and we keep adding more.

1563.69 -> Let me tell you,

1564.523 -> then Matt's gonna tell you his favorite condition key,

1566.9 -> but we'll talk about first.

1568.85 -> So when we talk about conditions,

1570.53 -> think about the term, but only if.

1574.49 -> So you wanna grant access to these actions,

1577.25 -> but only if these conditions are met.

1580.58 -> You can create Lambda functions,

1582.65 -> but only if you're using CloudFormation.

1585.86 -> You can write data,

1587.45 -> but only if that resource is in your organization.

1590.87 -> So if you wanna grant access or restrict access

1593.42 -> and you have this but only if feeling,

1595.64 -> go look for a condition key,

1598.49 -> How do conditions work? There are three parts to it.

1601.43 -> One is the operator, the next is the key,

1604.79 -> and the next is the value.

1607.19 -> The only part that you get to specify something unique

1611.21 -> to your organization is the value.

1613.94 -> The operator is StringEquals, StringLike,

1616.46 -> you don't get to make up your own operator.

1618.11 -> They're there in the IAM policy language.

1620.84 -> The key is also something we define

1622.97 -> because that's what we put in the context

1624.71 -> to evaluate against your policies.

1626.81 -> So the key could be PrincipalIsAWSService,

1631.37 -> ResourceTag, there's a lot out there,

1634.626 -> ViaAWSService, PrincipalArn, the list goes on and on,

1638.72 -> and then you specify the value that is there.

1641.9 -> Maybe you want the tag to be Pickles

1643.97 -> 'cause you're working on Pickles' project.

1645.92 -> So Matt, what is your favorite condition key?

1648.89 -> - So I think it has to be

1650.66 -> what we call one of the global condition keys.

1653.12 -> Global condition keys means they're available

1654.86 -> for all AWS services,

1656.24 -> and since we just talked about data perimeters as well,

1658.82 -> it's applicable to data perimeters.

1660.53 -> So I'm gonna cheat 'cause there's really two condition keys

1662.9 -> that are my favorite, PrincipalOrgID,

1665.267 -> aws:PrincipalOrgID and aws:ResourceOrgID,

1670.16 -> the combination of the two.

1672.02 -> So what those say, effectively,

1674.45 -> is that principals, or sorry,

1678.32 -> this resource is only accessible,

1680.9 -> this resource is accessible,

1682.16 -> but only if the principal is within my organization.

1685.25 -> And conversely, for ResourceOrgID,

1687.53 -> this resource is accessible,

1689.45 -> but only if the resource is within my organization.

1692.63 -> So the combination of the two

1693.83 -> is kind of the foundation of data perimeters.

1697.43 -> - Awesome, and I would say my favorite condition key

1699.89 -> have to do with the management of services.

1701.81 -> A lot of customers are using services

1704.18 -> that perform actions on your behalf,

1705.92 -> Access Analyzer being one of them.

1708.11 -> And so you might wanna say,

1709.467 -> "Hey, I'm granting access to this specific action,

1712.49 -> but only through an AWS service."

1714.92 -> So that's the condition key ViaAWSService,

1717.47 -> or I'm granting this access

1720.59 -> if it is an AWS service acting on your behalf.

1725.78 -> Okay, so we talked about all the ways

1727.79 -> that you can control access

1729.41 -> and the best practices for applying least-privilege

1732.14 -> using conditions to do that.

1733.94 -> But what are the tools out there

1735.32 -> that can help guide you towards these best practices?

1738.74 -> And the way we think about least-privilege

1740.63 -> is it doesn't happen overnight, it is a journey,

1743.39 -> and three steps to that journey.

1745.82 -> You're gonna set permissions, verify permissions,

1748.82 -> and refine them further.

1750.23 -> And as you get more comfortable,

1752 -> as you know what you're building,

1753.92 -> as you make it to production,

1755.48 -> this loop is gonna get tighter and tighter.

1758.24 -> But notice that the data perimeter is on the outside.

1760.88 -> It allows you to go through this journey

1762.59 -> as you innovate and as you build.

1766.13 -> So get started with AWS managed policies

1768.71 -> and move towards least-privilege.

1770.743 -> AWS managed policies are general to all AWS customers.

1774.02 -> They are not gonna be specific to your use case,

1776.36 -> so you can start there to explore but you need to move on.

1780.5 -> And so when would you use AWS managed policies?

1783.44 -> Well, if you're getting started,

1784.76 -> maybe you're just poking around,

1786.14 -> you might wanna use PowerUserAccess.

1788.33 -> If you're exploring a new service,

1790.07 -> maybe you wanna do a read/write.

1792.56 -> If you're like, "Hey, does Secrets Manager

1794.42 -> meet my use case?"

1795.35 -> Go play around with it in a development environment.

1798.32 -> Human users who need general access,

1800.45 -> so maybe a network administrator, a security admin,

1803.9 -> and then service-linked roles,

1805.73 -> and these are the roles that AWS services use

1807.98 -> to act on your behalf,

1809.36 -> and each one of them will have a policy that they need.

1812.27 -> So Access Analyzer does a lot of acting on your behalf

1814.94 -> and there's an Access Analyzer service role policy

1817.7 -> that grants AWS the permission to do that.

1822.65 -> Then you wanna use IAM Access Analyzer

1824.84 -> to generate least-privilege policies

1827.93 -> based on access activity.

1829.58 -> So this is a feature, we launched it in 2021,

1832.52 -> so if you haven't checked it out,

1833.84 -> I'd recommend going and checking it out,

1835.91 -> and here's how it works.

1836.99 -> You run your application, you run your task.

1839.99 -> My team recently used it by running a runbook

1842.45 -> that they needed to perform some steps.

1844.4 -> And then they were creating a fine-grained role

1846.59 -> for that operation,

1847.85 -> and they went to Access Analyzer and they said,

1851.127 -> "Hey, Access Analyzer, will you give me a policy?"

1853.85 -> Access Analyzer went to work, analyzed the CloudTrail logs,

1857.93 -> and then generated a policy.

1859.55 -> And when we generate this policy,

1860.96 -> you can customize it further.

1862.49 -> You can add additional actions, you can specify resources,

1865.55 -> we actually give you the template to do that,

1867.44 -> and you can add conditions along the way.

1869.9 -> So we are actually going to demo it.

1872.78 -> Pickles the unicorn has decided that he wants a policy,

1876.29 -> but it's really Matt.

1877.28 -> And so Matt is gonna do a live demo so hopefully it works.

1881.51 -> There is gonna be a little bit of a break

1883.64 -> 'cause we're gonna wait for the policy

1884.99 -> so maybe I'll try to tell a joke.

1886.64 -> I don't know. You wanna go for it, Matt?

1888.44 -> - Yeah, Pickles the unicorn

1889.397 -> sounds a lot more exciting than me.

1893.24 -> So what we're looking at here is just a Lambda function.

1896.15 -> Don't worry too much about,

1897.47 -> I'm not gonna make you read my code.

1899.03 -> Effectively, we're making a couple AWS calls,

1902.75 -> and I'm just gonna go ahead and run it.

1906.44 -> You can see here that it's looking at some instances,

1909.02 -> getting some details about them,

1910.4 -> it's looking at some secrets,

1912.05 -> it's skipping over the Brigid secret

1914.27 -> and looking at the Matt secrets.

1916.73 -> So what I wanna do is I wanna then go to my IAM role

1920.12 -> that I have associated,

1921.2 -> my execution role that I have associated

1922.94 -> with my Lambda function.

1924.08 -> We talked about native integration with IAM roles earlier.

1929.54 -> I'm going to click on, just give it a second.

1935.3 -> I'm gonna go to the one I already have open

1937.7 -> and I'm gonna scroll to the bottom.

1939.8 -> At the bottom, you'll see Generate policy.

1941.93 -> You can see I have actually generated a policy

1944.09 -> for this IAM role before.

1945.71 -> I'm gonna go ahead and click Generate policy.

1952.07 -> All right, I'm gonna choose just over the last day

1954.56 -> just so it doesn't take more than the minute

1957.23 -> that we said we were gonna have to wait.

1958.43 -> I'm going to select my CloudTrail trail

1961.22 -> because what it's actually going to do

1962.48 -> is it's going to go look in CloudTrail

1964.55 -> at the actions that this role has performed

1966.77 -> and generate a policy based on those actions.

1969.29 -> And I'm also going to just select US East 1

1972.02 -> for the sake of this demo.

1974.66 -> I'll use what's called a service role,

1976.58 -> I'll just select the existing one here,

1978.2 -> and I'll click Generate policy.

1980.9 -> So while this is generating,

1982.82 -> what I wanna do is quickly show you the policies

1984.41 -> that I have attached there now.

1986.45 -> As a developer, I just went in there and said,

1989.457 -> "Hey, I need to perform all EC2 actions

1992.06 -> and all Secrets Managers actions."

1994.28 -> That should be good enough. - That is not

1995.176 -> least-privilege. - No.

1997.37 -> And then I've got even this BasicExecutionRole,

1999.92 -> and this is one of those managed policies

2001.48 -> that I attached to my Lambda functions

2002.92 -> so it can do things that Lambda functions

2005.41 -> need to do, like logging.

2008.5 -> So what it's doing now is it's going ahead

2010.6 -> and looking at my CloudTrail trail,

2013.81 -> looking at the calls that I made and saying,

2017.92 -> how can I build a policy from those CloudTrail calls?

2021.58 -> - One thing we have gotten a lot of customers asking us

2023.95 -> is how does this happen?

2025.03 -> We actually do go look at your CloudTrail,

2027.37 -> we identify the event,

2028.63 -> and we map it to the appropriate IAM permission,

2032.02 -> and so that is something that Access Analyzer

2034.27 -> is doing on your behalf.

2036.16 -> And then we also put it in a policy

2038.29 -> and make sure that it complies with the IAM policy language

2041.92 -> and the specifications there,

2043.66 -> and so that is another thing we're doing on your behalf.

2046.21 -> And so this will help you get closer

2048.49 -> to a least-privilege policy,

2050.71 -> and what we're seeing is a lot of folks

2052.3 -> play around in development and then run this

2054.22 -> so they at least get the actions

2055.87 -> and have a good framework for generating that policy.

2059.23 -> - So one of the other use cases that I've seen used here

2061.78 -> is, let's say, infrastructure as code

2063.82 -> or CloudFormation templates.

2065.38 -> You want to see, hey, what access

2067.9 -> does this infrastructure as code need when I deploy it?

2070.66 -> So you set a broader policy first,

2072.67 -> deploy your CloudFormation template,

2074.68 -> and then go back and generate a policy

2077.08 -> based on that CloudFormation template,

2079.9 -> so you can get the exact permissions that you needed

2082.03 -> to deploy that CloudFormation template.

2085.256 -> - [Brigid] Is it still going

2086.125 -> or do we have to refresh? - It's still going?

2087.43 -> No, it'll stop you when it's done.

2090.25 -> - How many folks have used IAM policy generation?

2094.63 -> Oh, not very many.

2096.04 -> All right, we got, like, one, two, or three.

2098.68 -> So we are continuing to add,

2100.51 -> we generate action level permissions.

2104.65 -> I don't actually know the real number top of my head

2106.48 -> but I think it's 60-ish services

2108.79 -> and we are continuing to add more and more,

2111.04 -> so make sure you keep a lookout

2112.39 -> that we will continue to add some.

2115.27 -> - Ah, there we go. - We got a success.

2117.31 -> Live demo fun.

2119.598 -> - All right.

2121.87 -> All right, so it went through CloudTrail.

2123.76 -> It detected that, hey, Matt, you're using CloudTrail,

2127.93 -> some CloudWatch logs API calls,

2130.69 -> you're using some EC2 API calls,

2132.49 -> and you're using some Secrets Manager API calls.

2135.43 -> If I wanted, I could add additional actions here,

2137.56 -> but for the sake of this,

2139.42 -> I'm just going to go ahead and click Next,

2142.03 -> and it takes me to this template.

2144.49 -> So for some API actions, or some actions,

2148.45 -> it's able to tell me that, okay,

2150.1 -> this applies to all resources.

2153.01 -> Certain actions in IAM,

2155.68 -> certain actions in IAM do apply to all resources,

2157.78 -> certain actions in IAM let you specify the specific resource

2160.93 -> that you're dealing with.

2162.58 -> Now, for when there is a resource in question,

2166.54 -> like in the case of creating a log group,

2168.31 -> it's going to give me this template

2169.84 -> that I can then go back and modify.

2172.06 -> So what I'm gonna do,

2173.08 -> I'm gonna go ahead and fill in some of these values.

2175.63 -> I'm gonna just go ahead

2176.463 -> and grab the account ID from up here.

2182.38 -> And for this,

2185.08 -> I want to do aws/lambda/super-cool-

2191.41 -> - [Brigid] Super secret, super-cool.

2193.12 -> - I really shouldn't name these things so long

2195.01 -> for a live demo.

2195.843 -> - [Brigid] I always just name them Pickles.

2198.97 -> You gotta get yourself

2199.874 -> a horse. - I guess I need a horse.

2200.77 -> - [Brigid] Yeah, then it'll work out.

2203.159 -> - Okay, and then I'm gonna substitute the account ID there.

2204.94 -> And what I wanna do is I wanna say,

2206.98 -> only Matt's secrets, not Brigid's secrets.

2210.07 -> - [Brigid] Not my secrets.

2211.69 -> - So then once I have that all straightened out,

2213.91 -> we're gonna talk about policy validation in a second,

2215.74 -> but you're gonna see that I don't have any warnings

2218.14 -> or errors there.

2220.33 -> I'm gonna go ahead and click Next,

2223.96 -> and I'm going to name this fine-grain-

2228.91 -> - [Brigid] fine-grainer. - fine-grained-policy.

2230.5 -> - [Brigid] It is more fine-grained. (laughs)

2234.13 -> There you go.

2235.132 -> - And I'm gonna click Create,

2235.987 -> and it will automatically create

2237.49 -> and attach that policy to my role.

2239.56 -> Now, I still have these other policies attached to my role

2241.78 -> so I'm gonna go ahead and delete them.

2245.23 -> - [Brigid] So this is really the act

2246.67 -> of fine-tuning permissions right now,

2248.47 -> refining all of what you don't need anymore.

2252.19 -> - [Matt] And it's going to make me...

2257.44 -> Okay.

2259 -> - We'll do questions after.

2261.46 -> - Now with my fine-grained policy,

2263.47 -> I'm gonna go back to my auditing function.

2266.56 -> I'm gonna go ahead and run it again.

2272.23 -> There you go. - And it should work.

2273.28 -> There you go. - It still worked.

2275.05 -> - And now your Lambda function has fine-grained permissions.

2279.04 -> Thanks, Matt, for the demo. We'll go back to the slides.

2282.46 -> Pickles is very impressed with your demo.

2287.02 -> All right, and one other thing we did talk about

2289.72 -> was policy validation,

2291.04 -> and you can also use IAM Access Analyzer

2293.56 -> to validate your policies.

2295.9 -> And when we talk about policy validation, we have your back.

2298.3 -> We have over 100 checks that are making sure your policies

2302.35 -> are secure and functional, and we have four ways to do that.

2306.04 -> We show you checks on security, on errors in your policies,

2309.79 -> general warnings, and suggestions.

2312.07 -> Each check has an actual recommendation

2314.98 -> that goes to documentation

2316.51 -> to give you even more information.

2318.49 -> It shows you where it is in the policy.

2320.53 -> You can do this while you're authoring policies.

2323.68 -> You can also do this for your existing policies.

2326.38 -> And so we have customers that are putting policy validation

2330.79 -> in their CICD pipelines,

2333.73 -> and they're really looking at those security checks

2336.55 -> that are coming up and the errors that are coming up.

2339.1 -> Those are the ones that you would wanna automate

2341.65 -> as you deploy policies as infrastructure as code.

2345.64 -> We're gonna do another live demo.

2347.11 -> Matt's gonna show policy validation in action.

2349.75 -> My favorite policy validation check is iam:PassRole star,

2352.93 -> so maybe you can show that

2353.86 -> but I don't know if you're gonna do that.

2355.78 -> - [Matt] We can show that.

2357.07 -> - Oh, look at that right there.

2358.782 -> - There you go.

2359.615 -> So I am in the Create a policy console here

2362.8 -> and you can see that I do not know how to spell.

2365.89 -> So if I look at the bottom,

2367.09 -> I can see my errors and warnings.

2369.34 -> I click on the errors

2370.42 -> and it tells me that you have an invalid action.

2373.15 -> Now, this one's fairly obvious

2374.41 -> but there's oftentimes that you forget an S

2376.36 -> at the end of an action,

2377.193 -> you said RunInstance instead of RunInstances,

2379.78 -> something like that.

2381.07 -> So what I'm gonna do is I'm gonna go ahead

2382.33 -> and fix the name of that action

2384.97 -> and you can see that error disappears,

2386.8 -> but now I've got new errors.

2388.45 -> So let me first take a look at the warnings,

2390.16 -> and you can see that the findings have classifications here

2392.98 -> so I can focus my effort on errors,

2395.14 -> which means that my policy is just nonfunctional.

2398.71 -> But I'm also gonna take a look at this warning

2400.27 -> which says I have a missing version in my policy

2404.56 -> so I'm gonna go ahead and add that.

2407.86 -> Side note, you generally always want to use

2411.46 -> the latest policy version

2413.23 -> so that you can take advantage of things

2414.49 -> like policy variables in this specific case.

2417.34 -> But now I'm still left with one security warning,

2420.16 -> and this is where, like Brigid was saying,

2421.63 -> IAM Access Analyzer has your back.

2424.09 -> So here, it's saying

2425.29 -> you have PassRole with star in a resource,

2428.2 -> and it's also telling me why that's a bad thing.

2430.81 -> And for those that don't know what this means

2432.82 -> is this means that I can provide any IAM role

2435.97 -> to an AWS service, so even if it has administrative access,

2439.51 -> and that's generally not something that you want to do.

2442.93 -> So what I'm gonna do is,

2444.52 -> it even tells me how to fix it here.

2447.13 -> I'm gonna take its advice.

2449.95 -> - [Brigid] You're gonna take Access Analyzer's advice?

2451.684 -> - And we'll see

2452.642 -> if that's a good idea. - Great!

2454.117 -> (Brigid laughs)

2456.492 -> There you go. - So I'm gonna say,

2457.325 -> yeah, you can only pass Matt's role,

2460.42 -> and now the error goes away.

2463 -> The other thing it told me to do, just as an aside,

2465.43 -> is you can add a condition key

2466.63 -> that says I can only pass Matt's role to a specific service.

2471.43 -> So if you're dealing with PassRole,

2472.72 -> adding that little bit of extra safety

2475.51 -> is usually a good idea.

2480.22 -> - The other thing about policy validation

2481.96 -> is we are continuously adding new checks.

2484.96 -> So if you have an idea, you can tweet us at AWSIdentity

2488.77 -> or tweet me or somehow get a hold of us,

2491.17 -> and we will consider it for our next launch of checks.

2496.78 -> Okay, so the next best practice

2499.27 -> is verifying public and cross-account access.

2502.18 -> When it talks about that data perimeter,

2504.16 -> anything that grants external access

2506.41 -> beyond your zone of trust, you wanna verify it,

2509.35 -> and you can do that with Access Analyzer.

2511.42 -> So let's imagine we have a production account for Pickles,

2514.33 -> 'cause he has his own account with some hay and some treats,

2517.81 -> he has a bucket of carrots, a role,

2520.84 -> and all of these grant external access.

2523.99 -> So Pickles' data processing account, totally okay.

2527.92 -> An account from an unapproved third-party partner, not okay.

2531.67 -> I don't want anyone messing with Pickles

2533.14 -> unless I know who they are.

2535.9 -> Central security account to make sure everything

2538.42 -> is meeting the standards of the organization,

2541.66 -> perfectly okay.

2543.16 -> Developer account, no. Pickles is a production one.

2547.3 -> And so how does this work?

2548.89 -> You enable Access Analyzer for your account

2551.35 -> or your organization, it is free.

2553.78 -> We continuously monitor and review access controls

2557.83 -> on those resources.

2559.12 -> We have seven resource types

2560.77 -> and we're constantly adding more.

2564.16 -> We use automated reasoning

2565.6 -> to determine public or cross-account access

2567.85 -> so we know with certainty if there is a path to public,

2572.35 -> we generate findings for you to review,

2574.54 -> and then you get to go do the verify.

2576.1 -> You can say, "Oh, yep, I agree

2578.08 -> that that data processing account

2579.97 -> is allowed access to the production Pickles.

2582.46 -> Or you can say, "Hey, that third party, not allowed."

2585.1 -> And you can go update your policy.

2589.48 -> And talking about continuously monitoring and reviewing,

2592.03 -> you want to review your users, roles, permissions,

2595.57 -> policies, credentials, and see if they're used,

2598.66 -> and if they are not used, get rid of them.

2601.03 -> They do not bring you joy, they will not make you happy,

2605.17 -> and if you remove them, you help with your security posture.

2608.8 -> So where can you do this, and how can you do this?

2611.41 -> Well, you can look at roles and IAM users.

2613.66 -> We have last access information,

2615.49 -> you can see when they were last used.

2618.55 -> For each role,

2619.57 -> you can go into the permissions that are granted

2622.15 -> and look at the services that they have access to

2625.51 -> and which ones were used or not.

2627.1 -> And then for some actions,

2630.13 -> we tell you which ones are accessed and which ones were not,

2633.49 -> and we will be adding more of those along the way.

2636.73 -> And if you are using Organizations

2639.04 -> and that SCP that Matt talked about,

2641.11 -> that's a service control policy,

2642.94 -> you can go to your organization,

2644.59 -> you can see all the services that your organization used

2647.38 -> and maybe restrict access to the ones that you're not.

2649.72 -> So if you've decided not to use a service,

2651.25 -> it's not valuable for your business use case,

2653.62 -> you can just restrict it

2654.453 -> and you don't have to worry about it ever again.

2655.96 -> You restrict it for your entire org.

2658.24 -> So use that last access information

2660.4 -> to help you know what's okay to remove

2664.6 -> and help improve your security posture.

2668.77 -> All right, and the last slide we have here

2670.48 -> is just what to take back, right?

2672.25 -> If you take four things back with you to your organization,

2675.79 -> you want to confirm that you're using temporary credentials

2679.24 -> for human access and for workload access.

2683.02 -> You should start to cringe a little

2684.73 -> if you see long-term keys

2685.99 -> and really inspect and challenge the use

2688.99 -> of long-term credentials.

2690.34 -> And if you have long-term credentials,

2692.02 -> then you better be rotating them,

2693.43 -> you better have MFA on them if they're for human access.

2697.45 -> Then you wanna think about establishing those guardrails

2700.12 -> to help those teams build and innovate

2702.55 -> and think about it at the org level,

2704.32 -> the organizational unit level, the account level.

2706.87 -> And then finally, you wanna go into those accounts,

2709.09 -> right-size those permissions, verify,

2711.82 -> and really get them to a fine-grained permission model

2716.32 -> for your workloads and your human users.

2720.1 -> Thank you so much for staying with us this afternoon.

2722.5 -> I hope you all had fun at re:Inforce.

2725.56 -> Hopefully you can take a look at those best practices

2727.75 -> and start chipping away at them

2729.31 -> as you go back to your organizations.

2731.92 -> Don't forget to take the survey, and thank you, Matt.

2734.53 -> - [Matt] Thank you. (audience applauds)

Source: https://www.youtube.com/watch?v=SMjvtxXOXdU