AWS re:Invent 2022 - JIT privileged access management for cloud infrastructure (PRT015)

Aug 16, 2023

AWS re:Invent 2022 - JIT privileged access management for cloud infrastructure (PRT015)

While cloud infrastructure is generally spun up and maintained by DevOps and development teams through CI/CD pipelines, they occasionally need direct, highly privileged access for specific activities. These all-encompassing entitlements can introduce significant risk if not revoked when no longer needed. As part of a holistic cloud security solution, Ermetic’s JIT access provides policy definition, self-service workflows, automated access control, and auditing and governance. Join this talk to find out how to automate the creation, enforcement, and governance of developer access to AWS while gaining complete risk visibility into identity risk throughout your AWS environment. This presentation is brought to you by Ermetic, an AWS Partner.

Learn more about AWS re:Invent at https://go.aws/3ikK4dD.

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.

#reInvent2022 #AWSreInvent2022 #AWSEvents

Content

0 -> - Thank you so much.

2.22 -> So, hi, my name is Lior,

3.72 -> and I'm a senior cloud security architect

5.55 -> for a company called Ermetic.

8.04 -> Now, in case you haven't heard of Ermetic,

10.47 -> Ermetic is a comprehensive cloud security solution.

14.22 -> So, what this means is that we provide security

17.79 -> in multilayers relevant to cybersecurity in the cloud.

22.08 -> Now, just to give you a little bit of orientation

24.18 -> what we're gonna talk about today

25.35 -> is a new feature that we recently released

27.57 -> called Just In Time access.

29.88 -> So, the talk is here, right?

32.19 -> We do a lot of layers.

33.18 -> One of them is identity,

34.65 -> and one of the abilities that we provide for identities

38.22 -> is the just in time access

39.99 -> that we're gonna talk about today.

41.67 -> So, the first thing that we wanna do

44.106 -> is we wanna understand why this feature is important,

47.73 -> and in order to get to that,

49.53 -> we first need to understand

51 -> that there's a significant difference,

53.07 -> between service identities,

54.66 -> that is identities that are used by workloads

57 -> and human identities,

58.59 -> that is identities that are used by people.

61.59 -> Now, when it comes to service identities, right?

64.11 -> They're consistent.

65.55 -> Usually they're predictable, right?

67.47 -> Hopefully we know what the code

69.3 -> that the running is supposed to be doing,

71.46 -> what it's supposed to reach,

73.17 -> and that's how we can somewhat right size

76.65 -> or even significantly right size

78.78 -> the permissions that they get, right?

81.48 -> Now, this is of course not an easy thing to do

83.34 -> unless you're using Ermetic but it's within reach.

86.88 -> So, when it comes to people, by definition almost,

90.81 -> they're very less predictable, right?

93.87 -> It's hard for us to know what it is exactly

95.88 -> that they're supposed to do

96.78 -> and that's the reason why we have people

99.33 -> on our payroll, right?

100.71 -> Because if we could predict what they're gonna do,

103.32 -> we would automate this and then let go of the people.

107.22 -> Now, this creates a situation

109.83 -> where we need to provide them with broad access, right?

113.58 -> It's very hard for us to rightsize them,

115.86 -> to rightsize their permissions significantly,

117.78 -> and also when they find new things that they need to do,

120.81 -> they ask for more permissions, we give it to them,

123.84 -> and unfortunately these permissions just stay on.

127.77 -> So, this creates a situation

129.87 -> where people have very, very broad access,

133.86 -> and sometimes this access

135.24 -> is for very, very, very sensitive resources.

138 -> Now, this in combination with the fact

140.91 -> that people are also very, very vulnerable,

144.66 -> can create a very, very bad situation, right?

146.67 -> I mean, if for example you provide

148.92 -> the people with access keys for some reason,

150.96 -> which you probably shouldn't do,

152.67 -> but if you do then they sometimes post them on Slack

155.76 -> or they put them in a public S3 bucket, they leak,

158.7 -> that's a big problem,

159.84 -> and of course people are prone to social engineering

162.72 -> not to mention that their endpoints can get hacked.

165.36 -> So, together this creates a situation

168.81 -> where they have sometimes very, very broad access

171.6 -> to sensitive resources and they are in fact a sensitive

175.83 -> and weak link in your security chain.

179.61 -> However, you have to give them

181.29 -> these kinds of permissions, right?

182.58 -> Because otherwise they will tell you,

183.78 -> look, it's hard for me to do the job, right?

186.27 -> So, not anymore.

187.8 -> This is exactly why we recently released a feature,

190.71 -> called Just In Time Access.

192.6 -> So, it provides you the ability to give people the access,

197.187 -> the sensitive resources, just when they need it.

200.55 -> So, these permissions don't exist permanently,

204.6 -> which makes them much more and more secure.

207.48 -> So, what we wanna reach

209.55 -> with this feature for your environment

212.16 -> is something we call zero standing trust.

214.95 -> That means that people have minimal

217.29 -> or even no permanent permissions

220.17 -> to those sensitive resources.

222.12 -> Now, a user,

223.62 -> if they need in some situations access

227.19 -> to those sensitive resources,

228.57 -> may be eligible to ask for those permissions

231.72 -> when they need them and when they need them

234.21 -> they make request that needs to be approved

237.45 -> and once they approve they get the access temporarily

241.08 -> for just a specific duration of time

243.63 -> and after which they're gone, right?

246.6 -> So, there are no standing permissions all the time

251.28 -> for those sensitive resources.

253.41 -> So, if there's some kind of a breach

255.93 -> the fallout from it is significantly lower.

259.29 -> So, the way it works is let's say that we have a user,

265.26 -> let's say it's a developer,

266.52 -> and it has a development environment

268.71 -> so it has permanent access

270.6 -> to a role in that development environment.

273.51 -> Now, let's say that there's a production environment, right?

277.05 -> Which obviously has a lot more sensitivity to it

280.32 -> and there is some kind of production issue, right?

283.32 -> And that developer needs access

285.42 -> to that production environment, right?

288.54 -> Now, if you don't have the ability

290.49 -> to give the access just in time,

291.93 -> you will permanently give them access.

294 -> So, just in case, right?

295.38 -> So, they have the access

296.28 -> so if they're on call and they need to do something,

298.74 -> they're gonna use it,

299.82 -> but if you have Ermetic,

301.32 -> what you can do is have the developer request for access

305.25 -> just when they need it.

306.84 -> Ermetic will manage just in time permissions

309.93 -> in AWS IAM identity center,

312.3 -> and then they will get approved just in time access

316.23 -> for that production environment,

318.24 -> for a specific duration of time,

320.34 -> and once that duration is over they're gone, right?

324.57 -> So, there are no permanent access

326.85 -> to the sensitive production environment.

328.98 -> So, the way the flow would work is there's the requester.

332.58 -> They of course sign in an SSO into your AWS environment

337.62 -> via their identity provider

339.45 -> and there is Ermetic on the side.

342.03 -> Now, when the requester need the access

344.34 -> to the production environment,

346.05 -> they request it via Ermetic,

348.81 -> the approver gets notified of it,

351.39 -> they approve it of course if the request makes sense,

354.96 -> and then Ermetic takes care of everything

358.41 -> in front of AWS.

359.88 -> Now, another cool thing in this architecture

362.58 -> is that Ermetic can interface with third parties

365.79 -> in order to make this flow seamless

369.12 -> within the working environment of the developer.

372.21 -> So, we can integrate with stuff

373.71 -> like Slack or PagerDuty or emails,

376.02 -> and we will see how that happens.

377.46 -> So, requests can go from these other third parties

381.03 -> that developers and security professionals are already using

385.08 -> and they can also get notifications via them, right?

388.14 -> So, this is the overall architecture.

390.12 -> Now, without further ado,

391.41 -> let's see how this looks in the Ermetic console.

394.86 -> So, in Ermetic you have the ability

398.31 -> to provide eligibilities.

400.59 -> Eligibilities are not actual permissions,

402.9 -> they're just the ability to request for permission.

406.17 -> So, the way it works is I add an eligibility to a user,

410.55 -> to AWS accounts, to specific rules,

414.48 -> and then I can determine

416.22 -> that when they ask for this specific permission

419.37 -> the maximum duration that they can get

421.53 -> is within hours, right?

422.363 -> So, in this case, it's six hours.

424.47 -> Now, I can also define

426.21 -> that their request require explicit approval,

429.45 -> and who is the approving user, right?

433.98 -> So, the way this would work is let's say I have a developer,

439.86 -> this is what he sees normally, right?

441.69 -> When he logs in via the identity provider to AWS

445.38 -> they see access to their development account, right?

449.13 -> They don't have permanent access to the production account

452.34 -> but let's say they're on call

454.11 -> and there's a problem with the production environment

456.54 -> that for some reason only they can solve

458.25 -> and they need access to that production environment.

460.53 -> So, what they would do

461.363 -> is they would go to the Ermetic console,

463.65 -> they would request access

465 -> because they have an eligibility to do that,

467.43 -> they would choose the production account,

469.83 -> they would choose the role that they want,

471.69 -> they would ask for a specific amount of time,

474.27 -> in this case one hour,

475.74 -> and they would specify the reason why they need it.

479.16 -> Now, the approver is notified of that.

484.14 -> They see the request,

485.52 -> they decide whether to approve it or not,

487.74 -> and once they approve it

490.92 -> the developer now has access to both environments,

494.46 -> and of course when the time goes by,

497.97 -> the permission to access

500.28 -> the production environment goes away.

503.16 -> Now, another very cool thing about this feature

507.45 -> is because the access is just granted

510.06 -> for a specific duration,

512.13 -> Ermetic is able to show you

513.87 -> everything that happened during this session.

516.57 -> So, when you audit you don't just audit the eligibilities

519.75 -> or the request that happened,

521.79 -> but for each request you can go and view user activity,

526.92 -> and you get a log in a very, very approachable

530.37 -> and readable format that allows you to see

533.73 -> all the CloudTrail events that happened

536.19 -> during that specific session.

538.08 -> So, when the session is over

539.76 -> you don't just remove the permissions,

543.03 -> but you can make sure that the permissions that were granted

545.58 -> during the specific sessions weren't abused.

548.7 -> That is a very powerful thing.

551.34 -> Now, we mentioned that we can use third party integrations

555.15 -> to make this even seamless, right?

557.37 -> Because what we don't wanna do or we prefer not to do

560.76 -> is give another console for people to use, right?

563.43 -> So, we want people to be able to use

565.38 -> the current tools that they have

567.15 -> in order to make this process work.

569.49 -> So, let's demonstrate how an integration

571.74 -> with Slack and PagerDuty would look like.

574.26 -> So, let's say we have a developer

575.58 -> in the same situation, the same scenario,

578.25 -> and they want to request access.

580.44 -> So, instead of going to a separate console,

582.87 -> what they would do is just do slash jet request.

586.77 -> When they do that, they get access to the same dialogue

590.04 -> that we saw before.

591.96 -> They can choose, again, the environment,

593.64 -> they can choose the role,

594.84 -> they can specify the duration and the reason

598.11 -> and once they do that they can submit a request, right?

601.92 -> Now, Slack also enables us

603.78 -> to build a nice functional chat, right?

606.63 -> It's not just text that goes.

608.4 -> So, you can see all the requests that you made in the past,

610.95 -> you can even edit them and once you submit them

614.37 -> then the approver can actually go and see the request

617.91 -> and approve them straight from their Slack console.

621.72 -> Now, another interesting thing

623.61 -> is the ability to integrate with PagerDuty, right?

627.06 -> We mentioned that in the scenario that we talked about,

629.97 -> the developer would request the access

632.04 -> because they're on call, right?

634.14 -> They don't just wanna go into the production environment,

637.29 -> they go into the production environment

638.88 -> because there's an issue that arose

641.61 -> and they are the ones

642.96 -> that's supposed to deal with it, right?

644.31 -> This is the edge case

646.05 -> that for which we want to give them specific access

649.89 -> for that specific amount of time.

651.81 -> Now, what a PagerDuty integration would allow us to do

655.89 -> is to show the approver

658.41 -> that the person requesting the access

660.84 -> is actually on call, right?

663.09 -> So, let's say that a person, the developer,

666.54 -> is phished, right?

667.62 -> So, they're hacked.

669.69 -> Now, in order to make that work,

672.3 -> the attacker would not only have to phish them

674.88 -> and make a request,

675.93 -> they would have to do it when they're on call

677.76 -> or they would have to somehow fool PagerDuty

680.01 -> to make them think that they're on call,

681.21 -> which makes it another hurdle for them

683.67 -> to fool the approver

685.08 -> in order to give them those permissions.

687.66 -> So, to sum up the benefits of this approach

691.53 -> is that if you only give those permissions

694.68 -> just when they're actually needed,

696.96 -> you limit drastically the impact that security events

702 -> would have on your infrastructure.

704.46 -> But not only security events by the way,

706.53 -> also operational mistakes, right?

708.45 -> If developers or anyone

710.4 -> has any kind of redundant permissions,

713.37 -> they might use them by mistake and make damage.

717.33 -> Now, another thing that it enables session monitoring.

721.41 -> As we mentioned before,

722.52 -> you can go over exactly what happened

725.01 -> and make sure that even the permissions granted temporarily

728.67 -> weren't abused during the session, right?

731.01 -> You can do it after each session.

733.14 -> And finally, even if something bad happens

736.05 -> or you need to go through an audit

738.39 -> and you need to make sure

739.44 -> that access to these sensitive environments

742.23 -> wasn't abused in the past

744.66 -> or you need to find out why something bad actually happens

747.57 -> and you wanna do this kind of auditing and investigation

750.66 -> you do it in a much more focused way, right?

753.24 -> You don't have to go through months of logs

756.54 -> but you have a list of the specific times

758.46 -> when access was actually granted,

760.53 -> and then you can go over these specific logs

763.89 -> which are much, much, much more focused.

766.47 -> So, I wanna thank you all for coming

769.98 -> and if you want to see more about what we do

773.37 -> or if you have any kind of questions,

775.32 -> first of all I'm gonna stick around,

776.94 -> and second of all you can go by our booth, which is 10 20.

782.13 -> If you take a right here and you get to the thousand banner,

786.6 -> the aisle thousand banner,

787.53 -> and you take a left, walk right past the bathrooms,

790.89 -> look to your right, you should see our booth.

793.59 -> So, again, thank you all so much

795.69 -> for your attention and your time and I appreciate it.

798.99 -> Thank you.

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