AWS re:Inforce 2022 - Strategies for achieving least privilege (IAM303)

Aug 16, 2023

AWS re:Inforce 2022 - Strategies for achieving least privilege (IAM303)

Implementing the principle of least privilege is often considered a journey, and a confident journey should have a map. This session proposes such a map by considering relevant design principles and mental models that can accelerate your journey to least privilege. The session also reviews successful patterns that organizations use, including policy generators, policy reviewers, access reviewers, and policy reducers, that support the journey.

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.87 -> - All right, thank you for coming this morning for 8:00 AM.

5.76 -> I hope you're enjoying your re:Inforce.

7.68 -> Can I get a thumbs up that everyone can hear me okay?

10.5 -> Awesome.

11.34 -> Well, cool.

12.39 -> This is IAM 303, strategies for achieving least privilege.

16.26 -> My name is Josh Du Lac.

17.76 -> I am a Security SA Manager with AWS.

22.14 -> - Hello everyone, my name is Mathangi Ramesh

24.45 -> and I'm a Senior Product Manager

26.04 -> with the Access Analyzer team.

28.92 -> - Awesome.

29.88 -> And just to kind of level set as well,

32.22 -> this is strategies for achieving least privilege in AWS IAM.

36.66 -> So we're gonna be focusing

37.62 -> on AWS Identity and Access Management,

40.55 -> not application identity, not infrastructure identity.

46.08 -> And so I just wanna level set

48.96 -> and make sure you're in the right place for that.

53.61 -> So let me start with three, okay, cool.

57.61 -> Well, lemme start with three questions.

60.75 -> Where should I start?

62.4 -> Which policies should I use?

64.44 -> And who can access what?

67.26 -> If these are questions you've thought of,

69.45 -> or are wrestling with,

71.01 -> at least in the context of AWS IAM,

73.44 -> then I do think you're in the right place.

75.69 -> And we've spoken about least privilege before.

78.42 -> We've spoken on

79.44 -> these questions or these topics before at re:Invent 2021

84.03 -> and re:Invent 2020 and even before that.

87.66 -> And so, you know,

88.83 -> feel free to take scans of the QR codes

92.22 -> throughout today's talk,

93.15 -> we're gonna have a number of QR codes,

94.86 -> or if you're watching the recording later,

96.48 -> those will be available to you.

98.73 -> So this is more of a complimentary

100.38 -> to those previous talks as well.

102.69 -> So hopefully fresh material for you.

105.709 -> But I do think you're in the right place

109.41 -> if these are questions you're thinking of,

110.99 -> at least in the context of AWS IAM.

114.06 -> And we're here to give you some simple strategies

115.77 -> to get started.

118.62 -> So the agenda today is we're gonna look at an overview

121.47 -> of least privilege on AWS.

123.99 -> And we're gonna dive into nine strategies for implementing

127.23 -> least privilege in AWS IAM.

130.17 -> And then we're gonna zoom back out for some key takeaways.

133.59 -> All right.

135.54 -> So let's jump into kind of a overview of least privilege.

140.07 -> So what is least privilege?

141.78 -> Well, essentially it's to grant users and systems

144.6 -> the narrowest set of privileges to complete required tasks.

148.44 -> And in principle, this is great, right?

150.6 -> This is the ideal that we want.

153.24 -> We want just the right amount of permissions.

155.43 -> Ideally not any more than necessary.

158.7 -> But it's not so simple, users change or systems change.

163.11 -> The cloud changes,

164.577 -> AWS is adding new services or features.

167.79 -> Individuals on your team might want to adopt

170.34 -> those new services or features.

172.11 -> Perhaps there's a cheaper way of doing

174.21 -> what you've been doing before.

175.89 -> And then the permissions would need to be updated

177.81 -> to reflect that as well.

179.76 -> And so choosing the narrowest set of permissions

183 -> could be too restrictive.

184.35 -> And so a lot of customers we talk to are looking for a more

187.59 -> pragmatic approach or a more pragmatic answer.

191.76 -> And to be more pragmatic,

193.08 -> you'll wanna recognize that you're kind of balancing

195.479 -> two competing goals, right?

198.18 -> There's things you don't want and things you do want.

201.57 -> Things you don't want would include dangerous actions

204.39 -> or maybe expensive actions,

206.7 -> teams launching expensive resources,

210.03 -> or even terminating static resources

212.13 -> that you don't want to disappear.

214.23 -> And just generally being unaccountable, right?

217.2 -> And then there's things you do want.

218.94 -> You want your organization to innovate.

221.82 -> You want your builders to have a little bit more freedom,

224.7 -> to be agile,

225.533 -> to find cheaper ways of approaching the same problem.

229.08 -> So there's a natural tension here

230.977 -> between these two competing goals

232.65 -> when you're thinking about least privilege.

234.75 -> And we're gonna talk about how to try to find

236.43 -> a better balance across them.

239.61 -> And Maddie and I speak with a lot of customers

242.16 -> about this topic,

243.06 -> and they tell us that we have a lot

244.98 -> of these components in our cloud environment.

249.15 -> And I often get asked, where should I start?

252.36 -> And you might feel inclined coming into this session

255.72 -> that we're just gonna hyperfocus on policies

258.87 -> and kind of brute force our way to least privilege,

262.65 -> but that that's not very effective.

264.75 -> And so, you know,

265.583 -> we're gonna take a slightly different approach there

268.84 -> because more importantly,

270.39 -> you need the context about the applications,

274.62 -> about the users,

275.58 -> about the workloads.

276.51 -> You need to understand the intent

279.36 -> and the constructs behind that,

281.25 -> what APIs is the code referencing.

284.1 -> And then obviously you'll also need to take into account

286.2 -> the roles and the accounts that they live in.

291.45 -> So we're gonna try to break this question down

292.92 -> into three kind of sub-components,

295.83 -> strategies, mental models, and tools.

299.25 -> And I often asked about mental models.

301.74 -> Like what is that?

305.31 -> Or why are we using mental models?

307.35 -> Well, it's a fairly loosely defined term.

309.36 -> But I think of it more as conceptual models

312.36 -> or frameworks for thinking

313.5 -> that takes something relatively complex and tries

316.59 -> to break it down into something simpler

319.11 -> that you can reason about the complex topic in a better way.

325.696 -> And this means we're naturally leaving out detail, right?

327.96 -> If we move from something complex

329.28 -> to something relatively simpler,

331.36 -> we're choosing to leave out some detail

333.87 -> just so we can reason about the complexity

336.45 -> a little bit better.

339.21 -> And I like this quote from George Box, he says,

341.617 -> "All models are wrong, but some are useful."

344.94 -> And I think that's very applicable here as well.

347.55 -> And so, you know, there might be an edge case

348.636 -> that during today's talk that you're thinking of,

354.03 -> and I'm happy to talk with you after the session

356.7 -> as well about that.

357.533 -> But just keep in mind that we're simplifying

359.97 -> some of the discussion in order to reason about it better.

363.75 -> So whenever we're highlighting a mental model,

365.61 -> we're going to use this little pink tag to kind of point out

369.78 -> where those exist.

373.53 -> All right, so let's start by breaking this down

375.27 -> into who, when and how.

378.63 -> Who is important because

380.73 -> we want to talk about the personas

382.38 -> that are using least privilege.

384.87 -> And then we wanna talk about when they are implementing

387.36 -> least privilege in AWS IAM, and then how they're doing that.

393.69 -> And again,

394.523 -> we're talking in the context of just AWS IAM,

396.39 -> so if you're joining us a little bit late,

398.19 -> we're not looking at application identity

400.26 -> or infrastructure identity, we're just focusing

402.27 -> on those cloud identities.

405.03 -> And so this is what we typically see within

407.76 -> or with customers in the cloud.

410.425 -> In a lot of cases, they have essentially two sets of teams,

414.63 -> decentralized teams on the right

416.61 -> and centralized teams on the left.

418.86 -> If you think of decentralized teams,

420.18 -> you might think of developers or groups of developers,

424.14 -> operators, contractors, working in your cloud environment.

428.4 -> On the left hand side,

429.36 -> you might recognize names like the cloud platform team

432.24 -> or the infrastructure team or the security team,

435.24 -> the network team, the identity and access team, right?

439.32 -> And each organization is different though.

442.05 -> I talk with enterprises, government agencies, startups,

446.37 -> and there's variations of this.

448.28 -> So if this doesn't reflect your organization,

450.87 -> that's completely acceptable and that's okay.

453.66 -> You know, not everything here will apply to you today,

456.39 -> but it could apply to your organization

458.01 -> as it continues to grow, so just keep that in mind.

461.73 -> But this is typically what we see,

463.8 -> and it is split into two kind of categories

465.87 -> of decentralized and centralized.

470.16 -> And so knowing that we wanna talk about

471.9 -> when they're working with least privilege, right?

474.96 -> And often we break that down into three scenarios.

478.74 -> There's kind of the baseline set of roles and permissions

482.35 -> that are necessary to start using the cloud.

485.37 -> And those are created by the centralized team.

487.59 -> So that could be creating the initial default roles

490.41 -> and policies that you deploy using your account factory

494.22 -> or Control Tower

495.6 -> in order to allow your teams to federate into.

499.14 -> Ir maybe you have some automation that's doing

501.09 -> the monitoring and the accounts,

502.68 -> but those need roles and policies as well.

505.35 -> So the first scenario would be deploying that kind of

507.66 -> baseline set of default roles and policies

509.85 -> into the individual AWS accounts.

512.34 -> And centralized teams usually perform those actions.

517.11 -> After that, the more decentralized teams

519.87 -> or what I wrote here, developers,

521.82 -> are gonna go build something in that cloud environment

524.97 -> using those roles that we just talked about, right?

528.15 -> So they need to create new roles and policies

530.49 -> for the applications,

532.14 -> 'cause those applications need to interact with data, S3,

535.737 -> SQS queues, that sort of thing.

537.93 -> So creating those roles and policies is that next scenario.

540.9 -> And that typically happens by a more decentralized team.

544.68 -> And then lastly,

545.79 -> the third scenario would be verifying

547.95 -> and refining existing permissions.

550.227 -> And that's the responsibility, or at least in my eyes,

552.96 -> the responsibility of both sets of those teams, right?

555.87 -> It's everyone's responsibility.

559.41 -> And so how do they pursue least privilege?

562.17 -> Well, it's a life cycle, right?

564.12 -> They're setting permissions,

565.35 -> they're verifying the permissions, and then they're refining

568.47 -> those permissions over time.

569.67 -> And this continuous improvement or feedback loops

574.2 -> adds up to the journey to least privilege.

578.19 -> And we often call least privilege a journey.

581.19 -> It's not something you achieve day one.

583.23 -> Because again, things are changing, user systems,

586.77 -> the services change or add additional features, right?

591.45 -> But the journey here is made up of these feedback loops

594.09 -> of continuous improvement.

597.81 -> All right, so now that we've kind of level set

600.72 -> a little bit of overview knowledge,

603.42 -> let's dive into strategies for implementing least privilege

606.75 -> in AWS IAM.

611.46 -> And we actually have nine strategies to talk about,

614.55 -> but to kind of simplify it a little bit better

616.32 -> and to structure it more logically,

618.12 -> we divided them into three categories

619.83 -> of plan, policy and process.

622.2 -> Plan is where you consider your goals and the outcomes

624.9 -> that you want to achieve

625.733 -> and then design your cloud environment to simplify

627.81 -> those outcomes.

629.19 -> Policy is where

630.023 -> you're gonna implement some of those goals

631.86 -> in either the IAM policy language or as code,

636.81 -> infrastructure as code perhaps.

638.85 -> And the process is where you're gonna take

640.273 -> a more iterative approach to continuous improvement.

646.17 -> So let's look at the first one,

647.82 -> begin with coarse grained controls.

652.29 -> With coarse grained controls

653.55 -> we want to start higher up or broader

656.13 -> within our cloud environment.

658.95 -> And most systems have relationships

661.38 -> and these relationships can be modeled or visualized.

664.39 -> And so it's helpful to think in terms of a hierarchy, right?

667.65 -> And perhaps this is not new to you.

669.969 -> There's, you know,

671.43 -> a organization's management account and you can group

674.4 -> your accounts within that, which we'll dive into.

676.98 -> But I think it's helpful to, you know,

679.29 -> construct a hierarchy mental model in your mind.

682.53 -> This is a high school diagram that can help visualize this

686.023 -> a little bit better.

686.856 -> And we're gonna kind of use variations of this

689.114 -> throughout the talk.

693.54 -> And you might be tempted to come into this session thinking

696 -> we're just gonna hyper focus down here on the principals

699.21 -> and the policies that are assigned to the principals

701.43 -> or to the resources.

703.14 -> But we're not, we're gonna start higher up than that.

706.56 -> And we're gonna use

707.393 -> some of these coarse grained, broad controls,

710.01 -> such as multi account strategy,

711.9 -> service control policies, block public access

714.84 -> before tailoring the permissions lower, right?

718.68 -> We want coarse grained at the top

720.06 -> before we do fine grained controls at the bottom.

725.37 -> And one broad based control

727.23 -> that you'll want to keep in mind,

728.85 -> but not necessarily pursue directly right now,

732.33 -> is a concept of a data perimeter.

735.54 -> If you're not familiar,

736.373 -> data perimeter is just a set of preventative guardrails

739.29 -> that ensure that only your trusted identities are accessing

743.49 -> trusted resources from your expected networks.

747.51 -> Now, to be clear,

748.77 -> data perimeters is not a service or a feature,

752.13 -> it's kind of the culmination of a set of these features

754.56 -> or capabilities on the left.

755.79 -> So as you layer in these controls,

759.3 -> they can culminate or add up to data perimeters

763.41 -> protecting your data, right?

765 -> And so you'll establish these secure controls on the left

768.09 -> and build upon each other over time.

770.28 -> So it's not something to, you know, set out to cover today,

774.39 -> but rather as you approach some of the other items

777.3 -> that we talk about,

778.8 -> you'll ultimately add up to this.

781.74 -> And hopefully you can scan the QR code here

784.8 -> if you're not familiar, but you know,

787.02 -> this will be available in the recording as well.

789.81 -> So we have additional information and resources

792.014 -> on what data perimeters are and how to achieve that.

797.25 -> Okay, so let's move on to our second one,

800.46 -> use accounts as strong boundaries around resources.

803.88 -> And you've probably heard someone mention it today

806.07 -> or yesterday or later in the week,

810.36 -> but about multi account strategies,

813.03 -> which is a best practice in AWS.

814.93 -> While you can start with a single account

817.29 -> just as your workloads are growing

819.18 -> or as your organization grows,

820.47 -> you should split those up into various accounts

824.038 -> that you can group together.

826.62 -> This is a security best practice,

828.72 -> but it also simplifies other things like billing, right?

832.68 -> And customers can then group these accounts

835.41 -> into different assortments using AWS organizations.

840.878 -> You can group them

842.1 -> into what's known as an organizational unit or OU.

845.61 -> Some customers will choose to do this by environment.

848.25 -> So dev, pre-production, test, production,

852.39 -> or business units or cost center.

856.38 -> The choice is yours on how you want to construct this.

858.96 -> But one thing to keep in mind is you can leverage this

861.6 -> for grouping security controls.

863.49 -> So as you layer in preventative or detective controls,

867.48 -> you can do that on the groups of accounts

872.22 -> based on the grouping you choose.

874.02 -> So when you're thinking of how to group these accounts,

876.42 -> also think is, you know,

877.44 -> where do you want to apply your security controls

879.63 -> that could affect permissions and therefore assist you

884.1 -> in that journey to least privilege?

888.739 -> And so the point is though that AWS accounts give you

891.33 -> strong boundaries between resources and the principals

895.44 -> and networks in those accounts.

896.787 -> And so by default,

897.87 -> these principals and resources at the bottom

900.45 -> cannot cross these boundaries.

902.19 -> And we're just representing that here

903.42 -> with the kind of pink dotted line,

905.7 -> but we have our organization with two accounts

908.97 -> and then we have someone else's account here in pink, right?

912.12 -> And in order for any of these accounts to communicate

915.57 -> with each other, we need to explicitly enable access, right?

918.57 -> We need to add the permission for them to communicate.

921.36 -> So things like cross account resource sharing,

923.4 -> or cross VBC or cross account role assumptions,

926.79 -> we would need to explicitly enable that access.

930.84 -> And so, because that access is explicitly enabled,

933.87 -> someone has to create the permission for it.

935.73 -> And then we could review those permissions

939.54 -> in order to see if something is enabled

942.12 -> to cross those boundaries, right?

944.67 -> And we can do that using IAM Access Analyzer.

948 -> And we're gonna talk about IAM Access Analyzer a lot today,

951.03 -> there's essentially three major components to it.

953.4 -> So the first one we wanna talk about

954.66 -> is cross account findings, right?

957.6 -> And Access Analyzer helps you identify resources

959.97 -> in your organization or accounts

962.22 -> such as Amazon S3 buckets,

964.2 -> IAM roles, SQS queues and so on.

967.44 -> That could be shared with an external entity

969.78 -> like we just kind of visualized there.

971.76 -> And this helps you identify if there's unintended access

974.58 -> that, you know, your resources and data are being shared

977.31 -> with another entity or another account

981.3 -> and could be a security risk to your organization.

985.77 -> And so it's pretty simple to get started.

987.42 -> It is essentially four steps.

989.37 -> You just create the analyzer and it begins analyzing

992.79 -> those permissions that we just talked about.

995.027 -> And they will start producing findings, right?

998.79 -> And you'll wanna review those findings and look

1000.41 -> for two things, intended access and unintended access.

1004.73 -> So if it's intended and you wanted to share your data

1007.94 -> with another account, you could just archive that.

1010.49 -> But you'll want to hyperfocus

1011.69 -> on the unintended access, right?

1014.9 -> You wanna look for whether or not that account

1017.99 -> was in your organization, perhaps who enabled it.

1020.99 -> But you'll want to go remove that unintended access

1025.58 -> and remove that security risk.

1028.16 -> Now I wanna also highlight

1029.45 -> what I think is an underrated feature here.

1032.36 -> IAM Access Analyzer is integrated

1034.43 -> at the organization level.

1035.9 -> So you can go to your organization management account

1038.21 -> or the delegated member account

1040.37 -> and configure an Access Analyzer

1042.68 -> for your entire organization set as the zone of trust.

1048.05 -> So if you're sharing beyond your organization rather than

1051.38 -> just individual accounts.

1055.4 -> So let's look at more of a visual example here.

1057.5 -> Let's say we have three accounts, A, B, and C,

1060.56 -> and we want to consider whether a role from account B

1063.11 -> can access a resource or SQS queue in account A

1067.7 -> and a role from account C,

1069.05 -> can access a bucket in account A.

1072.29 -> Well before IAM Access Analyzer

1074.3 -> I would have to go look at these policies

1076.34 -> and evaluate the permissions in them and understand

1079.37 -> what APIs are available

1081.02 -> and whether or not the conditions are allowing something

1083.45 -> or not.

1084.62 -> But with IAM Access Analyzer, once you turn it on,

1087.5 -> it starts evaluating those policies

1089.84 -> and it uses automated reasoning and SMT solvers,

1092.84 -> which you could just think of as fancy math,

1095.36 -> to prove whether or not those policies are allowing

1098.45 -> or not allowing that access.

1101 -> So whether or not something is true or false, right?

1103.58 -> And this helps us validate our assumptions and find

1106.64 -> intended or unintended access in a more automated way

1109.79 -> across all of our strong boundaries.

1115.37 -> All right, so let's move on to our third strategy,

1118.34 -> prioritize short-term credentials.

1121.82 -> So when it comes to access control,

1123.89 -> I tend to think that shorter is better.

1126.429 -> Short-term credentials are requested dynamically

1130.55 -> using strong identities,

1131.63 -> and rather than keeping a long term access key

1134.45 -> that's stored in plain text on your laptop

1136.94 -> and could find its way in interesting places.

1140.93 -> And there's several hopefully obvious benefits

1144.05 -> with that is if they're being requested dynamically,

1146.39 -> they're also temporary and they automatically expire.

1149.87 -> So you don't have to revoke them or rotate them.

1153.41 -> You don't have to embed them within your application.

1156.2 -> Using the AWS SDKs

1157.97 -> they can just request through a credential chaining

1160.88 -> to get a short term credential from a credential provider.

1165.71 -> And which in the case of AWS is essentially IAM roles

1169.52 -> using STS, right?

1171.08 -> Security Token Service.

1173.03 -> And so in the context of AWS IAM,

1175.91 -> which is the context for this talk,

1178.52 -> when we're talking about short term credentials,

1181.4 -> we're effectively using IAM roles.

1183.86 -> And we kind of split that into two categories

1185.9 -> with subcategories, but I look at it as

1188.21 -> short term credentials for builders

1190.55 -> and short-term credentials for applications.

1193.55 -> So builders typically interact with the cloud

1195.86 -> in one of two ways, either through the console on a webpage

1200.87 -> or more programmatically through the CLI for example.

1204.624 -> And for the console access,

1206.51 -> they can use direct federation from your identity provider

1209.69 -> to individual AWS accounts or something more centralized

1212.99 -> through IAM Identity Center,

1215.36 -> which is the successor for AWS SSO.

1218.87 -> And then programmatic access,

1220.464 -> you can get short term credentials for CLI access

1225.62 -> into an AWS account.

1228.38 -> And this is actually fairly simple to do

1230.51 -> with IAM Identity Center or, you know,

1234.56 -> you might think of as AWS SSO.

1238.34 -> But those are typically the two ways to get

1239.96 -> short term credentials for interacting with AWS

1242.36 -> if you're a human, a builder in your environment.

1246.2 -> Now those builders are creating applications

1248.57 -> and those applications need their own permissions.

1251.3 -> And so typically for short term credentials

1254.24 -> for applications, we're looking at IAM roles for EC2

1258.38 -> or IAM roles for Lambda or tasks.

1261.35 -> And you can actually even use IAM roles on premise now.

1264.86 -> Recently we just launched IAM roles anywhere,

1267.5 -> which gives you the ability to have an IAM role for like,

1271.88 -> an on-prem machine that perhaps needs to upload some logs

1275.78 -> or data to an S3 bucket.

1278.84 -> And then lastly, cross account access,

1280.55 -> which we are kind of talking about there

1282.11 -> with crossing those strong boundaries.

1285.29 -> There are use cases for that.

1286.123 -> You know, if you have a build tool, for example,

1288.8 -> in one account that needs to push or deploy resources

1292.46 -> or infrastructure to another account,

1294.89 -> or a partner tool that needs cross account access

1297.29 -> for monitoring, that sort of thing.

1301.49 -> But obviously organizations still have long term secrets

1305.57 -> like passwords that don't use IAM roles

1309.89 -> or need to be stored somewhere

1312.8 -> because an application needs to access the database.

1316.1 -> And so you can protect these with AWS Secrets Manager,

1319.64 -> which will encrypt the secret using a KMS key.

1322.79 -> And you can configure automatic rotation of that secret.

1326.6 -> And this will help reduce the risk

1328.16 -> of those long term secrets, and kind of mentally,

1331.94 -> I think it was more turning a long term secret

1333.83 -> into a shorter term secret

1335.36 -> because of that automatic rotation.

1340.43 -> All right, kind of closing out the plan category there

1344.06 -> and moving into policy.

1345.95 -> Our fourth strategy is to enforce

1348.02 -> broad security invariants.

1351.32 -> And so what do we mean by invariants?

1353.78 -> Well, invariants are essentially conditions

1355.4 -> that should always be true, right?

1358.28 -> And we can enable that by using service control policies

1362.51 -> at either the organization level for all of our accounts,

1365.99 -> or perhaps a group of accounts using an organizational unit

1369.44 -> or just individual accounts, right?

1371.39 -> So we can apply a service control policy

1373.31 -> at any of these layers, which is again,

1375.5 -> that coarse grained, broad set of controls.

1379.16 -> So what are some examples?

1381.17 -> Well, a best practice at AWS is not to use the root user.

1385.85 -> And so we would encourage you to block access

1388.19 -> for that root user.

1390.56 -> Or perhaps there's regions that you, as an organization,

1393.56 -> are not using.

1395.03 -> And so you can choose to disable access to specific regions

1399.05 -> that you don't want resources deployed into.

1402.86 -> And you're also probably configuring logging and monitoring.

1407.45 -> And so you could use service control policies

1410.27 -> to disable CloudTrail, CloudWatch, GuardDuty,

1414.44 -> that sort of thing.

1415.273 -> Once you enable them,

1416.39 -> you don't want your users to disable them, right?

1419.84 -> So notice these words, block, disable, prevent.

1422.57 -> If you're thinking of these words in the context

1424.49 -> of all users or all principals

1428.15 -> except for the administrators,

1430.64 -> that's where service control policies can come into play.

1433.61 -> And that's when you'll want to think about

1434.96 -> broad security invariants.

1437.69 -> So this sounds great, and the customers will ask me for,

1439.887 -> you know, what else should we prevent,

1442.31 -> help me kind of analyze this more broadly.

1445.73 -> And I use a mental model,

1447.59 -> a relatively simple mental model here, just a XY graph.

1450.98 -> And along the X axes at the bottom would be

1453.23 -> the potential risk of somebody using that service or API

1459.14 -> in a particular account or environment.

1462.41 -> And then the Y axes would be the frequency of the use.

1465.86 -> How often does that action occur?

1469.13 -> And so at the top left would be those actions

1471.05 -> that are probably occurring more,

1472.1 -> the read only actions, right?

1473.27 -> Describe and list, those are relatively safe.

1476.12 -> Well at the bottom right

1477.2 -> is where I would want to focus my time.

1479.48 -> If I'm enabling CloudTrail for logging

1481.91 -> I would wanna make sure somebody doesn't call

1483.44 -> the stop logging API or to delete the CloudTrail.

1488.3 -> And so those actions would be risky in my environment,

1491.99 -> but they also have a fairly low use.

1494 -> People shouldn't be just calling

1495.17 -> stop logging every day, right?

1497.21 -> Or, you know, more situationally, direct connect.

1500.21 -> You are configuring your network

1502.361 -> and you're probably not changing it very often,

1506 -> or the only users that are changing it

1507.74 -> are the network administrators.

1509.777 -> And so over time,

1512.36 -> you can kind of think of this as you know,

1517.82 -> what do I wanna block or prevent?

1520.19 -> What can I use as preventative guardrails

1522.29 -> for things that should never happen

1524.24 -> versus maybe there's other guardrails

1526.7 -> for things that are more situational, right?

1528.86 -> And you could move from preventative to detective.

1533.09 -> You'll need to take into account

1534.14 -> maybe what personas are using these

1536.69 -> or what environment they're in.

1538.73 -> And so,

1539.72 -> but you can do this essentially service by service

1541.61 -> before thinking of it more fine grained

1544.52 -> feature by feature, right?

1548.06 -> So here's an example of a service control policy.

1551.81 -> You can put

1555.311 -> a block public access configuration in S3 for an account

1560.3 -> in order to ensure that

1563.14 -> even if a bucket has a permission to make it public,

1567.8 -> that at the account level, you're disabling that,

1570.11 -> that overrides that permission, right?

1572.33 -> So buckets by default aren't public.

1574.82 -> Somebody could choose to add a permission to make it public,

1578.09 -> But you as an administrator could override that

1581.51 -> and restrict that with that feature,

1584.57 -> that block public access, right?

1586.746 -> And so you wanna make sure that people

1588.23 -> are not manipulating that access

1590.45 -> unless they're the administrator, right?

1592.88 -> And so this SCP essentially says, we're gonna deny that API

1596.57 -> unless your principal is the role named admin, right?

1602.6 -> So essentially we can add this broad security invariant

1606.56 -> for all of our accounts.

1608.3 -> Now you'll notice that we're just denying this permission

1610.85 -> unless you're the admin.

1612.23 -> There's nothing here that grants a permission.

1615.86 -> And so we need that permission on the admin somewhere else.

1620.78 -> We can't do that at the SCP level.

1622.4 -> SCPs are just guardrails.

1623.69 -> They don't grant permissions.

1625.58 -> And we're gonna look at kind of choosing the right tool

1627.44 -> for the job here in a second.

1631.43 -> And rather than kind of coming up with these yourselves,

1633.53 -> I like to point customers to two documentation pages.

1637.07 -> On the left is some example

1639.08 -> documented service control policies.

1641.99 -> But I do want to point you more to the right hand side

1644.21 -> of Control Tower guardrail references.

1646.91 -> These are ones that Control Tower offers

1649.43 -> if you choose to use it, but they're publicly documented.

1652.37 -> So even if you're not using AWS Control Tower,

1655.52 -> you could still take advantage of the SCPs

1657.8 -> that are defined there

1659.45 -> and tailor them based on your environment.

1663.75 -> Okay, and with that, I'm gonna hand it over to my colleague.

1667.46 -> - Thank you, Josh.

1669.62 -> Good morning, everyone.

1671.21 -> So as per what Josh mentioned,

1674.36 -> you've set up your organization.

1676.73 -> You've mapped out all your accounts.

1678.68 -> And you've identified what is the hierarchy that you want?

1682.31 -> The next step is to control who can access or like,

1686.39 -> what access is allowed in those accounts.

1688.28 -> And for that,

1689.12 -> the important strategy here is to identify

1691.28 -> the right tool for the job.

1694.04 -> You've probably heard the saying that goes,

1696.74 -> if hammer is the only tool that you have,

1699.29 -> then you'd be tempted to treat every problem as a nail.

1702.68 -> And that wouldn't work.

1704.75 -> In the same way,

1705.583 -> IAM offers a lot of tools and each of those

1708.95 -> is valuable in its own way.

1711.5 -> If you have to bucket those,

1713.78 -> I'd bucket those into two different things,

1716.15 -> the guard rails and the grants.

1719.6 -> The guard rails are those set of tools that help you

1723.47 -> restrict or deny access to your accounts.

1726.5 -> So at a high level,

1727.91 -> they help you figure out what's the boundary

1731.45 -> for the right set of permissions that you want to retain.

1734.69 -> So service control policies, as Josh mentioned,

1737.84 -> is a great example that helps you restrict

1740.03 -> what the principals in your account

1741.86 -> and your organizations cannot do.

1744.65 -> For example, if you have CloudTrail,

1747.29 -> you'd wanna say that no one in this account should be able

1749.81 -> to disable my CloudTrail.

1751.97 -> Permission boundaries is another great example

1754.49 -> that allows you to say what's the maximum set of permissions

1758.66 -> that are allowed to a particular role?

1760.64 -> We'll get to that in more detail a little later.

1764.3 -> So these are the grants.

1766.28 -> These are the guard rails that sort of help you

1768.92 -> restrict access,

1769.82 -> but they don't inherently grant the required permissions

1773.63 -> for what is allowed in your account.

1775.94 -> To be able to do that

1777.32 -> you use either an identity based policy, or as it says here,

1782.24 -> principal policy or resource based policies.

1787.43 -> The identity or the principal policy is something

1789.62 -> that you attach to a role or a user.

1792.38 -> And the resource based policies are some things

1794.42 -> that you add to your resources, like an S3 bucket.

1799.22 -> If you could boil down the whole of IAM

1802.67 -> to one single sentence,

1803.96 -> it comes down to who can access what?

1807.62 -> So when you're thinking about grants,

1809.75 -> you can address that from the who angle

1811.82 -> by focusing on the identity based policy.

1814.58 -> So imagine you have Bob, who's a developer in your team.

1818.3 -> And you know that Bob traditionally works with EC2 and S3.

1822.5 -> So then it's easy for you to create an identity based policy

1826.34 -> that grants Bob's role just those permissions.

1829.85 -> On the other hand,

1830.87 -> if you know that you have a set of resources

1833.6 -> like S3 buckets where you want to save

1835.76 -> all your financial reports,

1837.65 -> then you know what actions can be taken on that bucket.

1841.19 -> So that's when you target the grants from the resource

1844.91 -> or the what angle, and identify what your resources are

1848.51 -> and what permissions or what actions

1851.09 -> can be taken on those resources.

1854.21 -> The one nuanced difference here is in the case

1857.21 -> of the identity policies, the principal is implicit.

1860.51 -> You know that you're creating that policy

1862.88 -> to provide Bob's role that required access.

1866.27 -> Versus in a resource based policy

1868.67 -> you need to call out the principal explicitly.

1871.01 -> You need to be able to say like,

1872.24 -> can Bob's role access this bucket?

1874.85 -> If yes, then add the roles in that policy.

1882.23 -> So these were the grants and the guard rails

1884.12 -> at a very high level.

1885.23 -> And there's a lot of documentation that takes you

1887.72 -> in more depth.

1889.76 -> But to summarize this,

1892.04 -> if you have multiple guardrails in your accounts,

1894.68 -> the net effective permissions is going to be a combination

1897.95 -> or a union of all of them.

1899.84 -> If you have multiple grants,

1901.1 -> like an identity based policy

1902.87 -> and a resource based policy, again,

1905.18 -> the permissions or the net effective permissions

1907.37 -> are going to be a combination of the two.

1910.01 -> But if you have, say, an SCP policy

1912.2 -> and an identity based policy,

1914.57 -> the net effective permissions is the intersection

1916.94 -> or whatever is common between the two.

1918.89 -> So if, for example,

1920.06 -> you have an SCP that says no one can access CloudTrail,

1923.99 -> then no matter what permissions you provide Bob's role,

1928.22 -> the role cannot access CloudTrail.

1931.76 -> And I would like to call out a blog,

1933.98 -> like this is a great blog that talks about

1935.87 -> all the different tools that are available in IAM

1939.05 -> and how can you put all of those together

1941.39 -> and make them work well together?

1951.44 -> So you've identified the right tool.

1955.1 -> You start writing policies.

1957.59 -> And you start working with the flow.

1961.61 -> And then you see, how many of you have seen this happen?

1964.79 -> We hear this often from customers.

1968.18 -> So you have a lot of developers in your account,

1970.22 -> in your team.

1971.18 -> And they are the ones

1972.26 -> who are focusing on building the application,

1974.9 -> they know what are the permissions

1976.28 -> that's required for that application,

1978.62 -> but they're either not comfortable authoring those policies,

1982.46 -> or they just wanna focus elsewhere.

1985.01 -> So that's where the administrator comes in.

1986.99 -> That's where they step in.

1988.34 -> They help the teams to create those policies.

1993.47 -> And this works well for a while, but as the business grows,

1998.72 -> as the team grows, this soon becomes a bottleneck.

2001.48 -> And the mental model to remember here is that,

2005.59 -> always be on the lookout for what the bottlenecks are

2009.37 -> for your team and your organization,

2010.87 -> and try to identify the root cause and solve for it.

2014.14 -> Sounds obvious.

2014.973 -> But then like, as you get into the motion,

2018.31 -> this doesn't be any obvious anymore.

2021.76 -> And what happens is like something that worked for you say,

2024.79 -> two years ago,

2025.623 -> doesn't work for you anymore

2026.68 -> because your teams are changing,

2028.157 -> your organization is growing.

2031.54 -> And the root cause here still is that the developers

2034.481 -> are not as comfortable authoring those policies.

2037.48 -> So the question is,

2038.313 -> how do you create that safe space or provide opportunities

2042.46 -> in such a way that developers can confidently and safely

2045.79 -> create those policies for their applications?

2050.53 -> We can start with something basic, invest in training.

2054.07 -> AWS offers a lot of workshops that help you get started

2057.4 -> with authoring policies.

2059.23 -> And you can either leverage that

2060.91 -> or have something in house more custom for your organization

2065.38 -> to give them that hands on experience to get them started.

2069.22 -> And as time progresses,

2070.27 -> you can help them along the way by setting up processes

2073.9 -> that work for you.

2075.73 -> For example,

2076.563 -> peer reviews that we'll get into a little later.

2079.48 -> And along the way,

2080.65 -> you can also leverage a lot of AWS native tools

2083.77 -> such as permission boundaries,

2085.3 -> IAM Access Analyzer policy generation

2087.79 -> that help you empower your developers

2089.74 -> to do this on their own.

2093.19 -> So in the next few slides,

2094.78 -> I'll talk about what are those native tools

2096.73 -> and how you can leverage them.

2099.19 -> I mentioned permission boundaries earlier,

2101.53 -> and what it helps you do is it helps you set

2104.32 -> what's the maximum available permissions

2106.36 -> to a particular role.

2109.48 -> And a common way in which we've heard a lot of customers

2112.48 -> use this is by adding this to your developer

2116.38 -> or builder roles

2117.55 -> to sort of define what's the boundary for what they can do.

2121.84 -> This way they create a space for like,

2124.18 -> with the maximum set of permissions

2126.4 -> that's available to the developers,

2128.35 -> and confidently let them play around in that account.

2132.82 -> I wanna call out another key way

2135.28 -> in which permission boundaries can be leveraged

2137.68 -> is to delegate the responsibility of policy creation

2141.88 -> to your developers.

2143.83 -> What you're seeing here is that you can add conditions

2147.94 -> for the builder role or Bob's role to say that,

2151.69 -> whenever this person or this role creates a policy

2155.17 -> or creates a role,

2156.64 -> they need to add a permission boundary.

2159.07 -> So this way,

2159.903 -> whenever they are working on their application

2162.16 -> and they're creating roles to grant those applications

2164.92 -> the required permissions,

2166.45 -> they are required to add those permission boundaries

2169.51 -> which then bounds the maximum permissions available

2172.63 -> to those applications.

2174.01 -> So even if the policy that they end up writing

2177.88 -> which is custom for their use cases is not too fine grained,

2181.3 -> the permission boundary helps you ensure

2184 -> that it is not outside what you intended for your account.

2192.46 -> The next tool that I wanna talk about

2194.47 -> is IAM Access Analyzer policy generation.

2197.89 -> So at a very high level,

2199.3 -> what this feature or what this tool helps you do

2202.18 -> is it looks at your CloudTrail.

2205.24 -> It reviews your CloudTrail to identify what are

2207.7 -> all the services and all the actions

2209.71 -> that you've used recently

2211.45 -> to then create a fine grain policy that meets your needs.

2215.65 -> So the classic use case, again, the application scenario.

2219.7 -> If the developer has tested the application for a while

2223.27 -> in their account, say for the last seven days,

2225.88 -> and they want to now write a policy

2227.98 -> that they want to submit for review

2230.71 -> before they can move the application to production,

2233.05 -> a great way to do this is run policy generation

2236.29 -> in that account for the last seven days,

2238.21 -> and then figure out like, IAM Access Analyzer

2241.21 -> will give you back that policy

2243.04 -> which can then be a starting point.

2245.8 -> The developer can make some changes in that policy to fit it

2249.31 -> or change it to their needs.

2251.14 -> And then just skip a few steps

2253.27 -> in this iteration of policies.

2256.87 -> I wanna quickly show you how you can use this

2258.75 -> in the console.

2260.29 -> The feature is available through APIs also.

2263.05 -> In the console when you look at a roles page,

2265.54 -> there's a section that goes generate policies.

2269.29 -> And for that you can create a policy in three simple steps.

2276.43 -> First is to select a time window.

2277.81 -> A lot of customers share that they

2280.937 -> select the last seven days.

2283.076 -> That traditionally captures

2284.98 -> all the required or regular activity that happens.

2288.91 -> Select the trail

2289.743 -> from which you want the data to be reviewed.

2292.12 -> Provide some permissions for Access Analyzer

2294.52 -> to be able to access that CloudTrail.

2296.44 -> And just click generate.

2298.87 -> And once you do this, the policy is generated.

2302.2 -> Take a look, identify if something is missing,

2304.87 -> put that information and create the policy.

2314.65 -> So you've identified all the right policies.

2316.69 -> You've empowered your developers

2318.52 -> to start authoring policies.

2322.18 -> How do you account for scale?

2324.94 -> By investing in processes.

2326.5 -> And that's the area where we want to focus

2329.71 -> with our next three strategies,

2331.18 -> starting with maintaining well written policies.

2336.88 -> Not every policy needs to at this level.

2339.67 -> And we say that it's actually wise to reuse your policies

2344.68 -> across your accounts.

2346.15 -> And in this rare case,

2347.56 -> I'd actually say that plagiarizing a good policy

2350.35 -> is actually a great strategy.

2352.48 -> How do you do this?

2353.313 -> When you're getting started in a new account,

2355.75 -> we actually recommend using AWS managed policies.

2359.26 -> These tend to be broad policies, but as time progresses,

2363.13 -> what you need to do is identify those use cases

2365.92 -> that keep happening or that's common in your accounts

2369.37 -> and create templates for those.

2372.49 -> A classic example is you have your accounts

2375.88 -> for your development teams to work in.

2378.55 -> And when they create applications,

2380.14 -> the applications tend to read and write data, say, from S3.

2383.65 -> So create templates for such policies

2386.11 -> to be able to read and write,

2387.55 -> like that grants permissions to read and write from S3.

2390.73 -> And the key here, so the important step here

2394.63 -> is to make these templates findable.

2396.82 -> We have heard some customers who do this

2398.74 -> through internal wikis

2400.42 -> where they want to keep it well documented so that

2403.48 -> their teams can just search and find what template

2406.55 -> works for their use case.

2408.73 -> Some customers, we've heard, version it,

2410.92 -> use infrastructure as code to save it in their repositories

2413.95 -> and then just work from there.

2417.28 -> So figure out what process works for your team

2419.86 -> and go from there is what we'll say.

2423.82 -> The one thing that I'd like to call out here

2425.68 -> is developer needs tend to be very different

2428.95 -> from application needs.

2430.499 -> For example,

2431.62 -> when a developer is working with resources in your accounts

2434.83 -> it could be to create a resource, delete a resource,

2437.98 -> for example, creating and deleting S3 buckets.

2440.64 -> Whereas when an application is working in your account,

2443.74 -> it's to read data.

2445.42 -> So it'll be to read and write objects to the bucket

2448.15 -> that was created.

2449.26 -> So when you're creating these templates,

2452.29 -> identify the new answers of like,

2453.97 -> who are you creating this template for?

2457.21 -> And find out what the difference is

2460.12 -> and create a template accordingly.

2464.95 -> And another thing I wanna call out

2467.2 -> is the reuse of these templates or creation of policies

2470.59 -> that work across your accounts.

2472.63 -> For certain use cases,

2473.83 -> it's easier to create those policies across all accounts.

2478.42 -> For example,

2479.253 -> if you have central security teams who want to go

2481.78 -> into all of the accounts to routinely review

2484.3 -> what's happening there,

2485.68 -> the kind of practices they do in each of these accounts

2488.8 -> is going to be pretty constant.

2490.6 -> So you might wanna give them access to CloudTrail.

2492.76 -> You might wanna give them access to guard duty

2495.01 -> and other such services.

2496.63 -> But you can create this policy and have the same policy

2499.51 -> across all your accounts.

2502.75 -> They're gonna have repeatable patterns.

2504.31 -> So this can be replicated across all your accounts.

2507.22 -> Permission boundary's another great example,

2509.17 -> wherein you know what is the maximum set of permissions

2512.98 -> that you want to allow an application and that's, again,

2516.46 -> you can commonly replicate it across your accounts.

2519.88 -> But if your team is working on applications,

2524.2 -> based on what team's building it,

2525.85 -> based on what the application is achieving,

2529.51 -> the kind of things that the application does

2532.57 -> tends to change.

2533.56 -> So here, instead of creating a template,

2535.33 -> you can create examples that the developers can use

2538.93 -> as a starting point and work from there.

2542.2 -> So identify, like,

2543.37 -> talk to your team, talk to your organization

2545.2 -> to identify what are the use cases that happen

2547.27 -> across your organization

2548.89 -> and start creating the same policy

2551.98 -> for those use cases across all your accounts.

2557.86 -> The next strategy is to peer review and validate policies.

2562.87 -> If you remember, Josh mentioned a while ago,

2565.51 -> that least privilege is a journey

2568 -> and feedback loop is a very, very important part

2570.91 -> of this journey.

2572.59 -> And for that feedback,

2573.46 -> you can either do that through human review,

2575.59 -> or you can automate it to review and validate

2579.19 -> what's happening.

2580.15 -> Let's focus on automation first.

2583.3 -> Again, another great feature here that I want to talk about

2586.36 -> is Access Analyzer policy validation.

2589.04 -> Policy validation is something that helps you

2591.76 -> while you're authoring your policy

2593.71 -> to set secure and functional policies.

2596.23 -> Again, the feature is available through APIs

2598.9 -> and in the console.

2600.01 -> How you can use it in the console is

2602.02 -> if you're using policy editor to write any policies,

2605.65 -> as you're doing that,

2606.76 -> a small window pane opens up below the policy editor

2610.27 -> that shows any possible issue with your policy.

2613.51 -> And how Access Analyzer finds it is it runs

2616.21 -> more than hundreds of checks on your policy

2619.21 -> based on what we think is important on our side.

2622.45 -> And the Access Analyzer highlights any possible issues

2627.01 -> that you might wanna fix.

2628.03 -> And it actually gives you some steps

2629.8 -> on how you can address it

2631.03 -> and how you can get rid of that issue.

2633.88 -> So the example that you see here

2635.64 -> is you have pass role action, but resource is star.

2638.8 -> So Access Analyzer thinks

2640.18 -> it's going to be overly permissive.

2641.62 -> So you might want to go back in and add

2643.6 -> the exact resource information in there.

2646.48 -> So this is what we would call a security warning.

2649.57 -> Like Access Analyzer would flag this issue

2651.94 -> as a security warning.

2653.71 -> There are some other buckets in which Access Analyzer

2657.31 -> or policy validation shows you some more issues.

2660.34 -> Error is a classic one,

2662.29 -> which is anything that prevents your policy

2665.32 -> from functioning as intended.

2667.03 -> So an example would be misspelling of an action.

2670.42 -> We saw the example for security warning earlier.

2673.66 -> General warning is anything that does not conform

2677.62 -> to AWS best practices.

2679.27 -> So for example,

2680.103 -> if there was a condition key that's deprecated,

2682.99 -> then Access Analyzer would flag that.

2685.54 -> This doesn't harm your policy, but it stops your policy

2689.62 -> from functioning the way you intended.

2691.207 -> And Access Analyzer is calling that out.

2693.91 -> And finally,

2695.29 -> the tool also provides some suggestions that, for example,

2698.98 -> if you have the same resource called out multiple times,

2701.98 -> Access Analyzer would flag that

2703.45 -> to help you improve the quality of your policy.

2706.42 -> So if this is something that you've not tried out,

2708.46 -> I'd really ask you to go check this feature out.

2713.71 -> One technique that can help us with both peer reviews

2717.07 -> and automation is use of infrastructure as code.

2721.9 -> Having your policies version controlled, stored somewhere

2725.17 -> so that you can test and easily deploy that

2727.21 -> into multiple accounts.

2728.74 -> Let's take a look at how we can do this.

2731.62 -> This is a very simplified version of your CICD pipeline.

2735.25 -> You have commit, you have validation, and you have deploy.

2738.13 -> In the commit stage,

2739.72 -> if your developers are authoring policies

2742.45 -> then you can quickly incorporate some peer reviews in there.

2746.289 -> Whenever someone is saving a policy

2748.75 -> you can ask for the policy to be peer reviewed.

2751.36 -> And this is a great way of incorporating that feedback loop.

2754.51 -> And this creates some accountability in the developers

2757.57 -> or in your team to write good policies.

2761.68 -> And if you want to use automation instead,

2764.17 -> you would use that in the validation stage

2766.75 -> wherein you can incorporate the validation tool

2769.48 -> that I talked about earlier to automate the whole process.

2774.22 -> And this block talks about that.

2778.09 -> The final strategy we have here today

2780.52 -> is to remove excessive privileges over time.

2784.69 -> When we talk about removing something,

2786.19 -> it generally needs to be substantiated

2788.65 -> by some kind of analysis.

2790.81 -> And IAM or AWS offers a lot of data to help you

2793.99 -> with this analysis.

2795.757 -> You can start broad at the SCP level to identify, okay,

2799.39 -> what are the services denied in my SCPs?

2801.7 -> What are the ones that are not

2803.5 -> but are not being used to identify those

2805.87 -> and actually deny or restrict access to those services

2808.988 -> over time?

2809.92 -> So that at the organization level,

2811.96 -> you just retain access to the services

2814.48 -> that are actually required in your accounts.

2817.54 -> And then you can go a little more narrow

2819.46 -> at the account level to identify what are all the roles

2822.46 -> in your account, which are the roles that are active,

2825.07 -> that are actively being used.

2826.45 -> What are the inactive ones, to identify those inactive ones

2829.36 -> and remove those from the account?

2832.337 -> If you then find that, okay,

2833.23 -> there are a lot of roles that are still being used.

2835.87 -> I go a next step deeper to identify what are the permissions

2839.71 -> granted to this role,

2841.3 -> what's being used from those permissions,

2843.04 -> what's not being used, and remove those unused permissions.

2845.8 -> And finally, if you want to go more granular,

2848.17 -> we say, take a look at CloudTrail,

2850.12 -> identify the resources that are actually being used

2853.15 -> by this role, and restrict permissions

2855.49 -> to just those resources.

2857.5 -> So I wanna double click on step three here.

2860.41 -> Again, this is something that's available

2862.24 -> through APIs and console.

2864.1 -> In the console if you're on the role page,

2866.8 -> there's something called the access advisor tab.

2869.26 -> Click on that

2870.16 -> to identify all the permissions granted to your role.

2872.77 -> Identify from the last access information

2874.96 -> what permission is being used

2876.31 -> and what's not being used,

2877.66 -> and remove the unused permissions.

2880.84 -> And identifying and removing permissions

2883.18 -> is a constant thing.

2884.35 -> You tend to do this routinely.

2886.267 -> To save your bandwidth we recommend automating this process.

2890.08 -> Either use config rules or use CloudWatch,

2892.5 -> or it can be some custom script on your side that tells you,

2895.78 -> hey, these permissions have not been used

2898.51 -> in the last 90 days, go in and take a look.

2900.55 -> So this sort of helps you be on top of all

2903.49 -> of those investigation activities and helps you save time.

2907.33 -> And one mental model I want to call out here

2910.57 -> is the 80-20 rule,

2913.69 -> which says basically that 80% of your outcome

2916.75 -> comes from 20% of the effort.

2919.12 -> And whenever we talk to customers, we hear this often,

2922.66 -> that least privilege is great,

2925.27 -> but I wanna focus on just enough privilege.

2927.82 -> Because, and this is important,

2930.43 -> like for you to figure out what that acceptable spot is.

2934.3 -> And also realize that anything after that

2936.67 -> is going to have diminishing returns.

2939.04 -> And you still want to work on the remaining 20%,

2942.88 -> identify what processes work for your organization,

2945.82 -> like feedback loops and incorporate those.

2948.48 -> And also be pragmatic about the remainder of the effort.

2952.48 -> For example, we say focus on what is sensitive

2955.66 -> to your accounts and your team.

2957.79 -> For example, focus on prod role first

2960.13 -> and then move on to the development roles,

2962.71 -> development accounts.

2963.88 -> And if you have roles with external access,

2966.37 -> focus on those first

2967.51 -> before going on to the roles

2969.34 -> that are used in development accounts by your developers.

2971.98 -> So identify what's the sensitive information

2974.32 -> in your account,

2975.153 -> target that first and then iterate over to the next ones.

2980.08 -> So these are the key strategies that we have for you today.

2982.9 -> I'll pass it over to Josh to talk about the key takeaways.

2987.25 -> - Thank you.

2988.84 -> So we covered a lot this morning

2991.15 -> for an 8:00 AM session as well.

2993.76 -> So just to kind of recap,

2995.26 -> I'll leave you with one last mental model.

2997.6 -> That the map is not the territory, right?

3000.84 -> We keep talking about least privilege as a journey.

3003.12 -> And I think that a confident journey needs a map.

3008.1 -> But it's important to realize that maps are not

3009.84 -> a perfect representation of the territory.

3012.36 -> They have a similar structure, which can be useful,

3015.39 -> you know, again, to kind of rationalize about the territory.

3019.86 -> And this is just an attempt to kind of summarize everything

3022.98 -> that we talked about today into a cause and effect diagram

3027.09 -> in order to show, you know,

3028.65 -> set, verify, and refine with a feedback loop as well

3032.85 -> with the individual controls

3034.119 -> and capabilities layered in there.

3037.89 -> But remember,

3038.82 -> you'll want to actually go walk the territory

3041.46 -> and get your hands dirty to understand

3043.05 -> how these things work together and empower

3045.42 -> your builders and your decentralized teams

3047.67 -> to do that as well.

3050.37 -> So we talked about nine different mental models,

3052.89 -> but the ones I really wanna highlight here

3054.24 -> are the feedback loops and that, you know,

3056.79 -> it adds up through continuous improvement

3059.01 -> to that journey, as well as the 80-20 rule, right?

3062.85 -> Maddie mentioned that if you put in 20% of the effort,

3066.57 -> you can get 80% of the results.

3068.28 -> And then where you want to hyper focus that last 20%,

3071.58 -> which does take more effort

3073.41 -> and focus on the right kind of sensitive areas

3076.44 -> or perhaps environments in order to make sure

3079.92 -> you're using your time more pragmatically,

3083.01 -> or to get the most bang for your buck, so to speak.

3087.84 -> We also talked about nine different strategies

3089.682 -> for least privilege.

3091.2 -> I don't have a favorite here, I'm gonna highlight

3093.63 -> I think they're all relevant.

3095.82 -> They're all important.

3096.99 -> They kind of all add up on top of each other.

3099.86 -> And so, yeah.

3104.01 -> And lastly, I also wanna mention some notable projects.

3109.74 -> We didn't feel we had time to cover them well

3111.87 -> or to compare and contrast between them.

3114.18 -> So I do just want to highlight them here.

3116.873 -> AWS created some of these and then customers

3119.88 -> like Netflix and Salesforce created these as well,

3122.55 -> just for some custom tooling that, you know,

3125.79 -> might help you in order to craft good IAM policies

3130.5 -> or to manage your identity and access more effectively.

3134.19 -> And we're including these,

3135.15 -> just kind of for reference for you to either look up later

3138.42 -> if you watch the recording as well.

3140.74 -> And so if you're looking for some key takeaways

3143.34 -> or next steps, we got you covered.

3145.86 -> If it wasn't obvious,

3146.76 -> we're biased towards IAM Access Analyzer.

3149.25 -> We think it's a great service and does have

3151.8 -> essentially three components to it.

3154.05 -> So I encourage you to, you know, turn it on,

3156.24 -> use it to find some unintended access to

3159.36 -> or resources or data that's being externally shared

3162.9 -> and go remove that unintended access.

3164.86 -> You can also use that policy validation function and feed in

3168.96 -> some preexisting policies and see if you can improve those.

3172.38 -> And then lastly, the policy generation capability.

3176.01 -> If we didn't mention it before, IAM Access Analyzer is free.

3180.39 -> The policy generation piece,

3181.8 -> I wanna call out that it does use CloudTrail,

3184.11 -> which if you're turning on CloudTrail,

3186 -> it's storing those logs as objects in S3.

3188.52 -> So there is a charge for that.

3189.99 -> But the IAM Access Analyzer service itself is free.

3194.58 -> All right, and so with that,

3196.5 -> I just wanna thank you again for coming to re:Inforce,

3199.53 -> for getting up early and attending this session.

3202.29 -> Please complete the survey so we can, you know,

3204.87 -> hear your feedback and improve for next year.

3207.81 -> Thank you.

3209.16 -> (audience applauding)

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