AWS re:Invent 2020: How Goldman Sachs administers temporary elevated AWS access
AWS re:Invent 2020: How Goldman Sachs administers temporary elevated AWS access
Goldman Sachs takes security and access to AWS accounts seriously. While empowering teams with the freedom to build applications autonomously is critical for scaling cloud usage across the firm, guardrails and controls need to be set in place to enable secure administrative access. In this session, learn how the company built its credential brokering workflow and administrator access for its users. Learn how, with its simple application that uses proprietary and AWS services, including Amazon DynamoDB, AWS Lambda, AWS CloudTrail, Amazon S3, and Amazon Athena, Goldman Sachs is able to control administrator credentials and monitor and report on actions taken for audits and compliance.
Learn more about re:Invent 2020 at http://bit.ly/3c4NSdY
Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4
#AWS #AWSEvents
Content
1.599 -> this is harsha sharma
3.12 -> i'm a solutions architect at aws i
6 -> welcome you all to this session
7.6 -> where we'll be talking about how goldman
9.28 -> sachs administers
10.639 -> temporary elevated aws access
13.759 -> joining me today presenting this session
16.08 -> are two key members of the goldman sachs
17.76 -> engineering team
18.96 -> hana anjul who are software engineers at
21.68 -> goldman sachs
23.92 -> we are seeing customers build
25.199 -> sophisticated automation
26.96 -> to perform actions are they on their aws
29.039 -> environments
30 -> but there are certain use cases that may
31.92 -> result in an unavoidable human access of
33.76 -> the environment itself
35.84 -> customers often ask us two questions
38.559 -> what are the patterns
39.68 -> to ensure that human access granted is
42 -> done so in a secure manner with least
44.48 -> privileges
45.92 -> and how do you order this privileged
48.079 -> access to see what type of activities
50.239 -> were performed by this human user
52.8 -> this session showcases one such pattern
55.36 -> that you can consider
58.8 -> on the agenda today we'll briefly
60.96 -> discuss who goldman sachs is
63.039 -> and the team hana and jude represent
65.68 -> we'll then look at goldman sachs's
67.2 -> enterprise environment
68.4 -> where we'll see how their aws
70 -> organization is set up
71.6 -> what are the different predefined roles
73.76 -> that exist in each account
75.6 -> and how each developer gets read or
77.52 -> write access to an aws account
79.68 -> using their customer identity provider
82.88 -> then we'll go into the core of this talk
85.119 -> which is to discuss
86.159 -> elevated or break glass access we will
88.799 -> see what are the four break glass
90.24 -> fundamentals that goldman sachs used
92.4 -> to build their workflows we'll walk
94.88 -> through one such workflow
96.32 -> through an end-to-end user story before
99.2 -> we conclude this
100 -> talk we will look at a critical aspect
102 -> of these workflows
103.36 -> which is that of auditing and reporting
105.92 -> this is extremely important for the
107.439 -> industry
108.159 -> that goldman sachs belongs to we will
111.04 -> see how goldman sachs has implemented
112.64 -> post access review to be able to satisfy
114.96 -> their security requirements at scale
118 -> i will now pass it on to hana and joule
120.079 -> to take you all through the rest of this
121.52 -> talk
122.64 -> awesome thanks harsha for that
124 -> introduction goldman sachs is a leading
126.719 -> global investment bank
128.64 -> even though we're a financial
129.84 -> institution engineering and innovation
132.239 -> are at the heart of our culture
134.239 -> in fact over a quarter of goldman sachs
136.239 -> employees are engineers
138.56 -> joule and i are in the public cloud
140.239 -> engineering team where we focus on
142 -> governance and security
143.92 -> at goldman sachs we manage private and
146 -> confidential data and transactions
148.239 -> so we need to critically think about the
149.92 -> best ways to secure our aws environment
153.44 -> so let's take a look at what that
154.48 -> environment looks like
156.48 -> now last year we did a deep dive into
159.12 -> our environment setup
160.64 -> at re event titled architect governance
163.2 -> at enterprise scale with goldman sachs
165.36 -> so feel free to check out that talk as
168.84 -> well
170.4 -> so within the firm we have a goldman
172.239 -> sachs organization that houses our
174.239 -> application accounts
176.08 -> we have over 500 accounts within this
178.4 -> organization
179.44 -> ranging from global investment research
181.599 -> transaction banking
182.959 -> consumer lending and other business
184.959 -> units
186.239 -> now we also have a completely isolated
188.48 -> and separate organization for our
190.08 -> sandbox accounts
191.599 -> but the processes that we're going to be
193.04 -> talking about today are really focused
195.04 -> on our production
196.319 -> and application accounts and so because
199.28 -> we have
199.92 -> hundreds of accounts in this
201.84 -> organization we need a way to manage and
204 -> scale our environment
205.84 -> and so we do a few things the first is
208.799 -> that we have centralized management
210.56 -> accounts
211.36 -> such as the primary account billing
214.319 -> identity
215.12 -> logging and all these accounts help us
217.68 -> manage the environment
220.08 -> another thing that we do is we have a
221.84 -> bootstrapping process
223.36 -> that runs on every account when it's
225.44 -> created
227.12 -> part of that bootstrapping process
229.04 -> deploys a number of roles
231.12 -> including a read-only role an operator
233.76 -> role which is limited read write access
236.239 -> and a break last role which is what
237.68 -> we're going to talk about today so
240 -> having these predefined roles already
242.48 -> deployed onto our accounts
244.239 -> enables us to utilize federated aws
247.04 -> access
247.599 -> to get into our accounts so let's take
250.72 -> an example of how we actually access our
252.799 -> aws account
254.72 -> so here's an example of alice she's a
257.04 -> developer on the payroll engineering
258.88 -> team
259.919 -> and she wants to access her aws account
263.199 -> so in order to do that alice is going to
265.36 -> make a request
266.479 -> to an internal portal and that's going
269.199 -> to route her request
270.32 -> to a custom identity provider this
273.199 -> identity provider is first going to
275.199 -> check
275.919 -> if alice is authorized to access this
278.24 -> payroll account
280.479 -> if she's authorized then the custom
282.72 -> identity provider
283.759 -> is going to make a request to aws sts
287.12 -> on alice's behalf and assume in to the
290.479 -> operator role which is the role that she
292 -> requested access to
294.96 -> this is going to generate temporary aws
297.36 -> credentials that will automatically
298.96 -> expire within 60 minutes
301.12 -> we never want to return long live
302.88 -> credentials to our users
304.56 -> so these temporary credentials are going
306.4 -> to be returned back to the identity
307.919 -> provider
309.12 -> back to alice and alice is going to be
311.28 -> able to use these credentials to access
312.96 -> her aws account
315.28 -> and so this is the process that we use
317.28 -> to enable developers to build
319.039 -> autonomously within the firm
322.08 -> but let's say we need to access
323.52 -> credentials with elevated access
327.199 -> so what we have is a break glass rule
329.199 -> that as we mentioned is also
330.56 -> pre-deployed
331.44 -> to every account and this has elevated
334.08 -> permissions
335.919 -> for for the for that role and so
339.039 -> why do we have this role what's the use
341.44 -> case for it
342.639 -> well at goldman sachs we automate our
344.72 -> deployment of resources
346.08 -> using infrastructure as code so this
348.4 -> role is not for the deployment of
350.08 -> resources
351.759 -> however as we know sometimes our
354.32 -> infrastructure as code pipelines break
356.88 -> and if that happens then the resources
358.96 -> that are deployed in our aws account
361.6 -> and our pipeline might be out of sync
363.759 -> and so in that case someone will need to
365.68 -> manually go into the account
367.44 -> and remediate the resources that were
369.68 -> corrupted
371.6 -> another example of when we might need
373.12 -> brake last roll is let's say alice our
375.6 -> developer
376.4 -> is deploying an s3 bucket and she wants
379.199 -> to secure her bucket with an s3 bucket
381.199 -> policy
382.479 -> now she ends up creating a bucket policy
384.479 -> that's too restrictive
386 -> and has locked herself out of her own
387.919 -> bucket
389.12 -> well in that case someone needs to go in
391.36 -> and edit the bucket policy
393.12 -> so that alice can regain access
396.16 -> so it's times like these where we need
397.68 -> to be able to access credentials with an
399.6 -> ele with elevated permissions
401.84 -> but because these credentials have a lot
403.68 -> more permissions than
404.96 -> the operator role and definitely the
406.479 -> read-only rule we need to critically
408.319 -> think about how we're going to broker
409.84 -> these credentials
411.759 -> and so there were four key fundamentals
413.599 -> that guided our solution for how we were
415.44 -> going to give out these credentials
417.68 -> governance the principle of least
419.68 -> privilege time-bound approval
421.68 -> and review and audit so let's take a
424.08 -> look at each of these
427.039 -> the first is governance and this is the
429.28 -> idea that although we want developers to
431.36 -> be able to build
432 -> autonomously when it comes to the brake
434.16 -> glass roll we pull in the rains and
436.24 -> pull in the rains and set up guard rails
438.4 -> and so one of those guardrails is that
440.24 -> only a select number of people within
442.8 -> the firm
443.52 -> can access break glass into any account
446 -> we have a select number of
447.68 -> admins within the firm that can break
449.68 -> glass into the into our aws accounts
452 -> but not every developer can access the
454.16 -> break glass roll
455.68 -> and so that's our first our first
457.28 -> guardrail we're setting we're limiting
459.039 -> the number of people
460.24 -> that can access this break last roll to
462.08 -> only admins
465.919 -> next is the principle of least privilege
468.639 -> and that's even though we need
470.08 -> elevated access into our aws account we
472.96 -> don't need unlimited access
475.36 -> and so if you'll see here on the right
476.879 -> there's an example of an assume role
478.879 -> where we're passing in
480.08 -> the pre-deployed break glass roll into
481.919 -> the account that we're trying to access
484 -> we're setting the duration to 60 minutes
486.319 -> so the credentials generated here are
488.16 -> automatically going to expire after 60
490 -> minutes
491.12 -> but what we can also do is pass in a
493.52 -> policy
494.72 -> and what this is doing is it's altering
496.56 -> the permissions of the break last
498.24 -> credentials
498.96 -> at runtime so what's happening here is
501.599 -> we have that pre-deployed
503.28 -> break glass roll already in the account
505.039 -> and that already has a policy associated
507.039 -> to it
508.24 -> but when we pass in the policy here the
510.639 -> effective permissions
511.84 -> of the credentials are going to be the
513.519 -> intersection between the policy that's
515.68 -> deployed
516.399 -> and the policy that we're passing in so
519.279 -> if we go back to the example where alice
521.279 -> created an s3 bucket policy that was too
523.599 -> restrictive
524.72 -> well in that case the admin that's going
526.56 -> to go in and edit the bucket policy
528.88 -> only need needs access to s3 resources
531.839 -> within the account
533.44 -> they don't need any access to secrets
535.6 -> within secrets manager
537.04 -> or ec2 instances within the account and
539.92 -> so by sending in this s3 policy profile
543.04 -> we're ensuring that the credentials
544.48 -> generated are scoped down to
546.48 -> only have permissions for the resources
549.2 -> that are needed to be actioned on for
551.2 -> that session
555.44 -> now not only are we limiting the number
557.92 -> of people that can access the brake
559.36 -> class role
560.08 -> and we're limiting the scope of the
561.519 -> credentials generated
563.2 -> but we want to make sure that no one
565.36 -> individual can access these credentials
567.44 -> on their own
568.72 -> and so what we've built is an internal
570.88 -> time-bound approval workflow
572.959 -> where before an admin can gain access to
575.2 -> the break last credentials
576.8 -> they have to have a valid reason to
578.64 -> access those credentials
580.32 -> raise a request and that request and
582.64 -> reason have to be
583.839 -> reviewed by a second admin only after
586.88 -> that second admin has approved the
588.8 -> request does the first
590 -> admin gain access to the break last
592.399 -> credentials
593.839 -> and so by having this approval workflow
595.92 -> we're always ensuring that there's a
597.279 -> valid reason
598.399 -> for accessing these break class
599.92 -> credentials and that
601.44 -> two people are always involved in
603.12 -> ensuring that that's happening
605.68 -> and so with that i'm going to pass it
607.44 -> off to joule who's going to take us
609.2 -> through what it looks like to break
610.56 -> glass at goldman sachs
612.8 -> thanks hannah so now we're going to
614.399 -> continue with the example that you
615.68 -> mentioned earlier of having to go into
617.44 -> the console
618 -> to fix an s3 bucket policy that is too
620.24 -> restrictive
622.8 -> so here we have a demo ui representing
625.04 -> our production payroll aws account
627.839 -> now as we mentioned earlier we have
629.36 -> predefined roles that are bootstrapped
631.04 -> into all of our accounts
632.56 -> so with the console buttons on screen
634.399 -> accessing them will allow developers to
636.32 -> assume into one of those predefined
637.839 -> roles
638.32 -> to access the aws management console
641.519 -> but for the breakglass console only
643.2 -> admins can access this
645.04 -> and then for the read-only and the
646.399 -> operator console developers on the
648.24 -> payroll engineering team
649.519 -> use those to develop in the aws account
653.2 -> so we have alice who is a developer on
655.04 -> the payroll engineering team
656.399 -> and she was requested that mary and
658.64 -> admin on the cloud team go in on her
660.56 -> behalf
661.12 -> so she can fix the s3 bucket policy she
663.36 -> placed on her bucket
664.48 -> that was too restrictive so here at
667.519 -> goldman sachs we track our break glass
669.44 -> sessions
669.92 -> utilizing a leasing system so if mary
672.64 -> were to try to get into this account
674.079 -> without elise
675.44 -> she's gonna see a 401 unauthorized error
678 -> stating she has no active lease
680.64 -> so in order to get one she must first
682.399 -> request it and just like the break glass
684.399 -> console button
685.2 -> only admins can request a lease so here
688.56 -> we have the different fields
689.76 -> that an admin needs to fill out in order
692 -> to get a lease request
694.32 -> so first we have the reason now here at
697.279 -> goldman sachs we also have
698.72 -> as a requirement that in order to have a
701.2 -> admin go in and break glass on a
702.88 -> developer's behalf
704 -> they must first fill out a support
705.519 -> ticket so alice has filled this out
707.839 -> explaining what happened and why brake
709.6 -> glass is needed in order to unblock her
712.24 -> so mary has included this ticket in the
714.079 -> reason and also has provided a short
716.24 -> description
716.88 -> so that the second party who's going to
718.48 -> review this request has some context
720.399 -> into the ticket
721.279 -> and can see that it's an acceptable use
722.959 -> case
724.399 -> next we have the policy profile so we
726.72 -> have predefined policies
728.24 -> that include common resources needed in
730.399 -> conjunction for support tickets
732.56 -> so the s3 profile is going to include
734.48 -> resources like kms
736.16 -> s3 and iam so mary has selected this
739.44 -> profile since she only needs to go in
741.2 -> and get this access
742.16 -> to fix an s3 bucket policy
745.2 -> then lastly we have the duration so this
747.92 -> is how long our internal identity
749.6 -> provider has
750.48 -> to make the assume roll request on
752.32 -> mary's behalf
753.6 -> now this duration is going to be the
754.959 -> duration of the lease which is separate
756.8 -> from our credentialing durations
758.72 -> we have credentials that always will
760.24 -> expire after one hour
762.56 -> so because mary has requested for her
764.399 -> lease to be two hours
765.76 -> if she's not done working alongside
767.279 -> alice within the first hour of receiving
769.44 -> her credentials
770.48 -> our internal identity provider can go
772.24 -> back in see that her lisa is still
774.24 -> active so she can request new temporary
776.399 -> credentials to continue developing
778.24 -> alongside alice
780.959 -> so now once mary submits this request
783.519 -> it's going to email the admin team so
786 -> here we have the inbox of daniel
787.68 -> another admin on the team and he has
789.76 -> received all the details of her request
792.24 -> so now he can go in and review the
794.24 -> details ensure that this is an
795.839 -> acceptable use case
797.04 -> and he can go in and approve it on
798.56 -> mary's behalf
800.88 -> so he has approved this request and now
803.04 -> our internal identity provider is going
804.72 -> to email mary back
806.16 -> letting her know that her request has
807.92 -> been approved and her lease is now
809.68 -> activated
811.68 -> so all of these details are easily
813.279 -> viewable inside of our inbox
815.12 -> but we are also keeping track of it in
816.8 -> our lease inventory
818.48 -> and so for our lease inventory we're
820.16 -> utilizing amazon dynamodb
822.88 -> so inside of our dynamodb table we're
825.04 -> keeping track of all the fields related
826.72 -> to the lease request
828.32 -> so these fields are something like the
829.92 -> lease id which is going to be a unique
831.92 -> id
832.32 -> associated with each lease request and
834.72 -> even more fields such as the approval
836.639 -> time
837.12 -> the user that requested it the policy
839.12 -> profile the duration
840.8 -> and even more such as who approved and
843.36 -> the status of the lease
845.92 -> so when mary requested this access it's
848.24 -> going to add in a new entry to the table
850.56 -> utilizing aws lambda so that new request
854.32 -> that comes into the new entry that comes
856.16 -> into the table is going to have a status
858 -> of
858.24 -> pending so once it is approved by our
860.32 -> second party it's going to update the
862.079 -> status of that lease to be
863.36 -> approved therefore activating the lease
866.48 -> so now that mary's request has been
867.92 -> approved let's continue on with her user
869.839 -> story
872.399 -> so it's been approved so now when she
874.8 -> goes back to our
875.76 -> demo ui and clicks on the break glass
878.079 -> console she's actually going to get
879.839 -> access into the account
881.12 -> because our internal identity provider
882.72 -> has seen that she has an active lease
885.44 -> so now that we've walked through how an
886.88 -> admin break classes here at goldman
888.48 -> sachs
889.04 -> we can go in and look at our full
890.88 -> architecture for this break glass
892.56 -> pre-approval workflow
894.32 -> so here we have mary who needs access
896.56 -> into the payroll account
898.16 -> in order to get that access she's going
899.839 -> to hit our internal identity provider
901.76 -> which is going to make the same check as
903.279 -> it does for all developers within
904.88 -> goldman sachs
905.76 -> it's going to check in our corporate
907.279 -> directory does she have access
909.44 -> to this account is she authorized for it
912.24 -> and because she's an admin she is
914.639 -> but because she's going in for break
916.079 -> glass access it's going to have that
917.519 -> added step of inputting an entry into
919.6 -> our dynamodb
920.72 -> lease inventory now this dynamodb table
923.6 -> is stored in our management identity
925.6 -> account
926.8 -> so utilizing amazon api gateway aws
930.24 -> lambda
930.88 -> and dynamodb our internal identity
933.199 -> provider can input that entry into the
935.12 -> table
936.72 -> next our identity provider is going to
938.959 -> email the team of admins
940.399 -> to let them know that mary has requested
942.16 -> this access
943.44 -> our second party is going to review the
945.04 -> request and approve it
946.56 -> and once it's approved it's going to
947.759 -> update her entry in the dynamodb table
950.48 -> activating her lease so now when mary
953.759 -> goes
954 -> to hit our break last console button
955.519 -> which is going to trigger our internal
956.959 -> identity provider
958.079 -> it's going to check in the table does
959.6 -> she have an active lease
961.12 -> it's going to see that it is activated
962.959 -> and therefore it can continue on to make
964.88 -> the aws
966.32 -> sts call to assume roll into the account
969.04 -> and assume into the break last roll
971.519 -> so now mary will be administered a
973.36 -> temporary aws credential
975.279 -> and she can actually access the
976.8 -> management console
979.44 -> so this is our full pre-approval
981.36 -> workflow that we use to get break glass
983.44 -> access
983.92 -> here at goldman sachs now that we've
986.24 -> seen this it can bring us
987.759 -> it brings us to our final break glass
989.68 -> fundamental which is going to be review
992 -> and audit so here at goldman sachs we
995.44 -> have over
996 -> 500 application accounts and with that
998.72 -> we had to build out a centralized system
1000.88 -> to be able to review these break last
1002.639 -> sessions
1003.36 -> after they have been completed so just
1005.92 -> like how we have a second party who
1007.44 -> approves the request before getting the
1009.04 -> access
1009.68 -> we're also going to have a second party
1011.199 -> that reviews the actions that were taken
1013.04 -> by the admin within the account
1015.68 -> now we listed this as a fundamental not
1017.839 -> only because it's an audit requirement
1019.36 -> for us here
1020.399 -> as a bank security is of the utmost
1022.399 -> importance to us
1023.44 -> but also we wanted it to be a best
1025.199 -> practice for us here at the firm
1026.799 -> we're never giving out these elevated
1028.319 -> credentials we want to make sure that
1030 -> with this elevated access
1031.439 -> we have a second party that's going to
1032.799 -> review it so that we ensure that the
1034.959 -> admin did not misuse
1036.4 -> this elevated access and with that i'm
1039.6 -> going to pass it back to hana to walk us
1041.28 -> through this post
1042.079 -> access review workflow so we have all
1045.439 -> this aws activity happening within our
1047.76 -> accounts in the organization
1049.6 -> we have developers accessing the
1051.679 -> read-only and
1052.72 -> the operator role we have them deploying
1055.039 -> infrastructure using infrastructure as
1056.88 -> code
1057.44 -> and we have admins accessing the brake
1059.28 -> last role and so all of this activity is
1061.919 -> generating cloud trail logs
1063.919 -> and so what we have is an organization
1065.52 -> cloud trail that persists
1067.039 -> all of these activities now because for
1069.679 -> the review and audit we only care about
1071.52 -> the brake glass activity
1073.12 -> what we have is a subscription filter
1075.44 -> that's going to filter out
1076.799 -> all the cloud trail logs related to
1079.28 -> break break
1080.08 -> glass and it's going to pipe those logs
1082.799 -> into kinesis fire hose
1084.559 -> where the data is going to be formatted
1086.4 -> and partitioned and put into our s3
1088.64 -> bucket within the identity account
1091.12 -> now once it's in our s3 bucket we can
1093.12 -> use athena
1094.16 -> to query back all the session logs that
1096.24 -> we need for our review process
1099.28 -> now remember we keep a lit keep
1101.679 -> inventory of all the leases in our
1103.44 -> dynamodb table
1104.96 -> so we know all the break last sessions
1106.799 -> that should have taken place within our
1108.32 -> organization
1109.679 -> and so we can use this data to guide our
1112.08 -> queries
1112.96 -> and pull back all the related session
1114.96 -> logs that we need
1116.32 -> and so we take that data and we pipe it
1118.32 -> into our internal workflow review
1120.88 -> and this is where a second admin is
1122.559 -> going to come in and review the session
1124.559 -> logs for a specific lease to ensure
1126.96 -> that the actions taken are appropriate
1129.919 -> so this is our workflow process that we
1131.679 -> use to get the data into a consumable
1133.6 -> format so that we can use it
1135.36 -> for review let's dive a little deeper
1137.44 -> into how we actually implemented this
1141.12 -> so remember that assume rule that we
1142.96 -> showed earlier we're passing in the role
1145.039 -> the duration the policy well the one
1147.84 -> thing that we left out
1148.88 -> earlier is that the session name is not
1151.44 -> only going to be the user id
1153.28 -> in this case but it's going to be the
1155.28 -> user id
1156.48 -> and the lease id and so all that data
1159.44 -> that we're storing in the dynamodb table
1161.6 -> such as who approved it why the request
1163.919 -> was raised how long it should be valid
1165.52 -> for
1166.24 -> is we can associate back to these
1167.919 -> credentials because we have the lease id
1170.16 -> being passed in as the session name also
1173.44 -> as joule mentioned
1174.72 -> we can raise multiple sessions against
1177.12 -> one lease
1178.64 -> and so as we raise multiple sessions all
1181.52 -> those
1182.08 -> that session activity can still be
1183.76 -> aggregated together
1185.28 -> because we're passing in the lease id
1187.36 -> and so we know all the actions that were
1189.44 -> taken
1190.08 -> against one lease and so if we look at
1193.6 -> an example of a cloud trail log
1195.6 -> here's an abbreviated version of what a
1197.76 -> cloudtrail log might look like
1199.919 -> you'll see at the bottom there's event
1201.76 -> source and event name
1203.6 -> which corresponds to the resource and
1206.159 -> the action taken
1207.28 -> on that resource and so these are the
1210.08 -> actions that mary took during her
1212.159 -> maybe multiple sessions and what you'll
1214.799 -> also see
1215.76 -> is that the user identity arn is also
1219.12 -> tagged with the session name that we
1220.96 -> passed in so that
1222.32 -> lease id is going to be associated to
1224.72 -> all the actions taken
1226.48 -> taken against multiple sessions
1230.08 -> like we mentioned earlier we we are
1232.24 -> filtering out all the break glass
1234 -> cloudtrail logs piping them into kinesis
1236.48 -> firehose into our s3 bucket
1238.48 -> and once they're in our s3 bucket we can
1240.32 -> use athena to write a sql statement and
1242.96 -> pull back
1243.6 -> all the session logs that we need for
1245.679 -> our review
1246.799 -> and again because we have the lease id
1249.36 -> associated to all the cloud trail logs
1251.52 -> we can use that as a filter parameter to
1254.159 -> pull back
1254.799 -> all of the cloud trail logs for this one
1256.88 -> lease
1258.4 -> and so we take those logs and we
1260.4 -> populate a custom ui
1262.159 -> where we're going to present all the
1264.08 -> lease details including the reason why
1266.08 -> the lease was created
1267.679 -> and all the actions that the admin took
1270.48 -> for that lease
1271.919 -> and so the another admin is going to
1273.36 -> come and ensure that those actions make
1275.28 -> sense with the reason
1277.6 -> and so but having this review process is
1280.08 -> really ensuring that we're utilizing the
1281.76 -> break glass credentials appropriately at
1283.919 -> for these sessions but because we're
1286.72 -> also
1287.76 -> pulling together all of this data for
1289.44 -> the break glass roll we're able to also
1291.6 -> answer
1292 -> macro questions such as how often are we
1294.799 -> breaking glass
1295.76 -> what are the main reasons we're breaking
1297.12 -> glass how long do these sessions usually
1299.36 -> last
1300.4 -> and when we can start to answer those
1301.919 -> questions we can start thinking about
1303.679 -> ways
1304 -> to automate these processes and improve
1306.08 -> our environment even further
1308.48 -> also we can identify trends that might
1310.72 -> point to abuse of the break glass role
1313.039 -> and being able to identify these trends
1315.2 -> and answer these macro questions
1317.039 -> enables us to iterate over our
1318.48 -> environment and secure and improve it
1324.159 -> and so with that i just want to
1325.52 -> summarize a little bit of what we talked
1326.96 -> about today
1328.08 -> we went through the fundamentals that
1329.84 -> guided our solution to brokering break
1331.679 -> glass credentials within the firm
1333.76 -> we're limiting the number of people that
1335.6 -> can access the brake class roll to only
1337.44 -> admins
1338.64 -> and rather than having some star star
1340.64 -> role that's deployed in
1342 -> all the accounts that maybe even only
1343.76 -> the admins can access
1345.6 -> we're limiting when they can access this
1347.919 -> break glass roll
1349.039 -> and we're scoping down the credentials
1350.96 -> to ensure that they only have access to
1353.12 -> the resources that are relevant for
1354.64 -> those sessions
1356 -> on the flip side we're reviewing
1357.919 -> everything that we're doing with our
1359.12 -> break glass rolls to ensure that they're
1360.559 -> being used appropriately
1362.32 -> and so these processes that we've
1363.919 -> implemented enable
1365.44 -> us to ensure that we're brokering the
1367.039 -> credentials in a secure fashion
1370.32 -> thank you so much for listening today we
1372 -> really hope you enjoyed our talk
Source: https://www.youtube.com/watch?v=gRK1U5HKa6o