Amazon S3 security and access management best practices - AWS Online Tech Talks
Amazon S3 security and access management best practices - AWS Online Tech Talks
Amazon S3 provides a number of security features to consider as you develop and expand your workloads in the cloud. In this Tech Talk, learn about the security features that help simplify security management for your data stored in S3. We dive deep into some of the recent launches such as Object ownership enhancements and Policy validation that help you manage access control to your data in S3.
Learning Objectives:
* Objective 1: Understand how Amazon S3 secures all your data by default.
* Objective 2: Hear about Amazon S3 security features to ensure your data meets security access management requirements.
* Objective 3: Learn best practices that you can implement today to keep your data protected against security risks.
***To learn more about the services featured in this talk, please visit: https://aws.amazon.com/s3/security/ Subscribe to AWS Online Tech Talks On AWS:
https://www.youtube.com/@AWSOnlineTec…
Follow Amazon Web Services:
Official Website: https://aws.amazon.com/what-is-aws
Twitch: https://twitch.tv/aws
Twitter: https://twitter.com/awsdevelopers
Facebook: https://facebook.com/amazonwebservices
Instagram: https://instagram.com/amazonwebservices
☁️ AWS Online Tech Talks cover a wide range of topics and expertise levels through technical deep dives, demos, customer examples, and live Q\u0026A with AWS experts. Builders can choose from bite-sized 15-minute sessions, insightful fireside chats, immersive virtual workshops, interactive office hours, or watch on-demand tech talks at your own pace. Join us to fuel your learning journey with AWS.
#AWS
Content
2.12 -> [Music]
7.919 -> hello and welcome everyone if you are
10.08 -> here you are using s3 or interested in
12.88 -> using s3
14.24 -> you are putting your data in cloud it's
16.4 -> important to secure the data and ensure
18.96 -> right people have access and nobody else
22.16 -> i am kavita and later you will hear from
24.48 -> shawwick and we both would be speaking
26.4 -> about ways to secure your data in s3
28.96 -> bucket and provide write access
33.68 -> increasingly customers are transitioning
36.079 -> all their applications to the cloud
38.079 -> while many are starting ground up in the
40.16 -> cloud
41.36 -> as a result of this shift more and more
43.6 -> customer workloads are moving to amazon
45.92 -> s3
46.96 -> customers choose amazon s3 for a lot of
49.52 -> different reasons for some it's about
52.079 -> high availability high throughput the
54.719 -> scale they can reach with amazon s3 the
57.44 -> love and lines of durability and the
59.6 -> ability to store data across multiple
62 -> regions with cross region applications
64.72 -> for some its wide range of cost
67.119 -> optimization capabilities we provide to
69.52 -> store millions and billions of objects
71.6 -> within s3
73.119 -> for some customers it's about security
75.52 -> and management features that we offer
78 -> giving you the ability to control access
80.159 -> at the object
81.6 -> bucket and account level
83.84 -> s3 is a powerful service for storing
86 -> your data but there are situations where
88.24 -> you want to automate the management of
90.72 -> your data to achieve business goals
93.119 -> typical business goals are to understand
95.119 -> usage verify security increase
97.84 -> efficiency drive down cost or migrate
100.96 -> data to other environments selectively
104.399 -> s3 provides you with tools and
106.24 -> capabilities to manage your data at
108.159 -> scale while you continue to expand your
110.32 -> storage in the cloud
112.56 -> in this session today we will use a
114.799 -> case-based approach to learn about these
116.88 -> tools and capabilities that will help
119.28 -> you manage your data at scale
124.24 -> so the first scenario we are going to
125.759 -> see is that your organization is hosting
129.44 -> thousands of s3 buckets across hundreds
131.68 -> of accounts
132.8 -> these buckets have data that is often
135.04 -> accessed by multiple users
137.2 -> you know you as a security engineer or
140.16 -> and developer would need to
142.8 -> mandate some complaints guidelines so
145.2 -> that the objects are not available
146.8 -> publicly and all the objects are
148.56 -> encrypted in your buckets
150.4 -> how can we achieve this
153.04 -> let's review some s3 features that will
155.28 -> help you simplify security management at
157.68 -> scale
158.64 -> the first one is s3 block public access
160.879 -> and the second is s3 default encryption
163.519 -> we would go into detail about each of
165.44 -> these sections
167.84 -> so the very first thing the main concept
170.08 -> for today is block public access
172.64 -> if you take nothing else away from the
174.64 -> stock take this
176.48 -> go after the stock turn on the block
178.72 -> public access for all your aws accounts
181.68 -> what is block public access
183.68 -> amazon s3 block public access is a
185.519 -> feature that applies a blanket
187.519 -> protection against public access it
189.92 -> guards you against accidental public
191.92 -> access
192.879 -> this feature can be set at the bucket
194.879 -> level or at the account level
198.319 -> it provides protection against
199.76 -> permissions from accounts bucket
201.76 -> policies or both
207.04 -> when you enable block public access to
209.04 -> your bucket entities outside the account
211.84 -> does not have access unless you
214.159 -> explicitly provide access you can
216.4 -> provide this access in number of ways
218.799 -> one being using the bucket policy or
222.08 -> using iam policies
224.159 -> or
225.12 -> if you have aws organizations you can
227.04 -> also do it with
228.4 -> scp service control policies as well
232 -> as well
235.519 -> uh we will now go through some examples
237.76 -> to see how you can prevent public access
239.92 -> to s3 buckets here we can see that there
242.64 -> are two buckets one is
246.08 -> a really public website and the other is
248.4 -> cross account testing and these both
250.64 -> have either the object or the bucket
252.959 -> itself has access to entities outside
256.079 -> your aws account
260.16 -> now you can go on to block public access
262.639 -> at the account level
264.24 -> turn the setting on
266.16 -> you can turn on the setting for all the
268 -> four different features that we provide
270.8 -> and once you enable this setting
273.199 -> it gives you overarching protection
275.12 -> across all your buckets and overrides
277.36 -> your individual bucket setting so now
280 -> you have turned on the this and let's
281.919 -> see what happens
286 -> so you can see that none of the buckets
287.84 -> are public anymore after i turn on block
290.479 -> public access at the account level all
292.8 -> of the buckets are protected the two
294.88 -> buckets that were flagged before or now
297.12 -> secured and are not publicly accessible
299.44 -> anymore
303.039 -> apart from block public access s3 also
305.6 -> provides you some ways on how you can
307.68 -> effectively manage
309.36 -> public access
311.68 -> the first one is
313.52 -> i am called iem access analyzer you can
316.16 -> use access analyzer to understand how
318.479 -> your buckets are being shared
322.72 -> the second one is like if you do have
325.28 -> public buckets there are very less
327.12 -> scenarios
328.24 -> for why you need to have public buckets
330.32 -> but if you do have one
332.24 -> keep those public buckets in a dedicated
334.4 -> aws account so you can ensure that all
337.039 -> the other aws accounts that you have you
339.039 -> can turn on the bpa block public access
341.68 -> at the account level
344.16 -> and always use bucket policies or
346.639 -> rackets when you need to provide
348.72 -> permissions to your account
353.6 -> the second feature that we're going to
354.88 -> speak about is amazon s3 encryption
358.319 -> by encryption what do we mean
362.319 -> the very first is that we encrypt on the
364.56 -> client side we can do this using aws sdk
367.84 -> or you can use your own application to
370.16 -> provide client-side encryption
372.4 -> the second is that the data is encrypted
374.479 -> during transit
377.039 -> and finally we provide several modes to
379.52 -> encrypt data at rest at s3 some of the
382.56 -> options are amazon s3 managed keys aws
385.6 -> key management
386.96 -> service and customer provided keys
393.28 -> today we have organization wide
395.44 -> visibility into your encryption metrics
397.84 -> in storage lens
399.52 -> while we have this you should also
401.28 -> consider setting up default encryption
403.28 -> setting for your s3 buckets with default
406.319 -> encryption you have the ability to setup
408.479 -> s3 packets
409.84 -> where the data is automatically
411.759 -> encrypted by default it is a one-time
414.319 -> bucket level setting where you define
416.639 -> your encryption key by the s3 managed
419.199 -> key or customer managed kms key and all
422.24 -> your subsequent uploads to your bucket
424.08 -> are automatically encrypted
427.36 -> we also launched bucket key
429.039 -> configuration last year that will help
431.12 -> you reduce your kms cost up to 99
433.919 -> percent
438.16 -> now we are moving on to our second
439.759 -> scenario
441.199 -> your organization is hosting tens of
443.44 -> thousands of s3 buckets across hundreds
445.919 -> of accounts
447.039 -> these buckets have shared data that is
449.36 -> often accessed by multiple users
451.759 -> you are looking for ways to simplify
453.84 -> policy management for cross account
455.84 -> users across the organization
458.319 -> so how do you achieve this
462 -> we can do that using s3 object ownership
464.72 -> s3 access points and im access analyzer
468.56 -> before i dive deep into each one of
470.8 -> these things i want to go into multiple
472.96 -> mechanisms for access management
476.72 -> there are multiple
478.479 -> ways to provide access to your buckets
482 -> today we will be seeing about iam policy
484.8 -> bucket policy and access control list
488 -> so for im policies or where you define
491.44 -> what resources
493.52 -> the im rules in your account can access
496.16 -> for bucket policy you define what
499.039 -> different who different users or
502.4 -> roles can access your particular bucket
505.36 -> and finally we have ackles or access
507.919 -> control list which predates iam and was
510.72 -> the original way that s3 used to grant
513.039 -> access to bucket object
515.2 -> we will dive deep into each one of these
517.279 -> in the upcoming slides
521.599 -> so i am policy
523.519 -> i am policy
525.12 -> defines what actions can this iam user
529.04 -> perform you attach this iem policy to an
531.68 -> iam user or an iem rule and it has three
535.68 -> mandatory elements they are
538.48 -> effect which is either allow or delay
541.68 -> and then its actions you define what
544.24 -> actions can be performed by this user
546.72 -> and finally where those actions can be
550 -> performed on which resource in this
552.399 -> example we have an iem policy that
555.2 -> allows an iem user to read and write
557.92 -> objects to the bucket called sample
559.68 -> bucket
562.48 -> who can apply these im policies if you
565.2 -> are the iam administrator for your aws
567.36 -> account you define the iam policy and
570.32 -> attach it to an iem user or iem rule
573.12 -> within your account
574.959 -> you can further allow an iem user to
577.68 -> assume an iem rule with this role
580.16 -> assumption the iem user inherits the
582.959 -> permission of that iem rule
588.64 -> and the next is s3 bucket policy bucket
591.279 -> policy is something that you attach to a
593.519 -> bucket to a resource
596.72 -> in aws there are different types of
598.56 -> there are different resource policies
600.24 -> that's different from the iem policy
602.56 -> that we saw before we have bucket
604.48 -> policies we have vpce policies and we
607.279 -> have kms policies and different policies
609.519 -> that you can attach it's
611.519 -> it's it's a policy that can be attached
613.44 -> to a resource so the bucket policy is
615.92 -> very similar to iam policy such that it
618.56 -> uses the same json format the bucket
621.36 -> policy defines who can access my bucket
624.32 -> and what actions can that user perform
629.44 -> the
630.399 -> the bucket policy requires one
633.12 -> additional statement apart from effect
635.519 -> action and resource and that is called
638 -> as principle
639.36 -> this is where you specify
641.2 -> who this policy is applicable to here in
644.16 -> this example the bucket policy allows
646.399 -> the aws account id with the 12 ones
649.6 -> to read and write objects to the
651.519 -> resource sample bucket
655.839 -> and finally we have access control list
659.519 -> access control risks are one of the
661.2 -> resource-based options that we have
663.6 -> available to manage buckets and objects
666.399 -> you can use accounts to grant basic read
669.12 -> or write permissions to other aws
671.12 -> accounts
672.16 -> a majority of modern use cases in amazon
674.64 -> s3 no longer requires the use of fackles
677.36 -> and we recommend that you disable accurs
679.6 -> except in unusual circumstances where
682.16 -> you need to control access for each
684.079 -> object individually i just want to
686.079 -> repeat this again try not to use acculs
689.68 -> and prefer using bucket policies when
692.32 -> needed
693.44 -> salvik will be discussing more about
695.279 -> this in the upcoming slides i'm going to
697.36 -> hand it over to shopwick now to speak
699.44 -> further about cross account management
702.56 -> thank you kavita
704 -> so i want to start with the concept of
707.2 -> cross account rights
708.959 -> so cross account right is a really
711.44 -> common situation for many of our
713.68 -> customers with multiple accounts
716.56 -> let's use an example to show how cross
719.2 -> account rights are done today
721.839 -> so you can imagine
724.16 -> that you own account a and have a bucket
727.6 -> that serves as your data lake data lake
730.56 -> meaning multiple shared data sets act
733.519 -> being accessed by a variety of your
736.079 -> users
737.12 -> account b for example in that data lake
740.56 -> wants to write data to your bucket
742.88 -> now there are three complexities that
745.2 -> you need to pay attention to in a
747.36 -> cross-account right situation
749.68 -> whenever account b writes data to your
752.72 -> bucket
754.24 -> objects are owned by account b now
758.56 -> account b needs to give you permission
761.44 -> to read via acco or access control list
766 -> third because you don't own these
768.56 -> objects because remember account b wrote
771.279 -> these objects to your bucket you cannot
774 -> use bucket policies or im policies to
777.68 -> give other accounts access
780 -> you have to do that through access
782.24 -> control lists or acco
785.839 -> this used to be the old-school way of
788.48 -> managing granular
790.639 -> object level permission way before
793.68 -> amazon or aws started its own central
797.36 -> iam or access management policies
800.399 -> now this can present a lot of challenges
802.72 -> such as enforcing bucket policy to
805.44 -> objects owned by the bucket owner in
808.32 -> account a
810.8 -> and using a bucket policy is a modern
814.639 -> best practice approach to sharing your
817.519 -> data with other users
820 -> you use bucket policies to share data
822.88 -> with other aws accounts and then create
826.399 -> a security perimeter to deny access
830.88 -> so as you can see here
833.36 -> ackle assigns ownership that that
835.92 -> affects bucket policy applications so
839.68 -> objects written by external account are
842.72 -> owned by that specific account the
845.36 -> result is that the bucket owner cannot
848.16 -> further share that object via a bucket
851.36 -> policy
852.48 -> so we wanted to take a look at this
854.48 -> problem long and hard and solve this
857.12 -> issue for our customers so i want to
860.56 -> talk through one of our recent launch
862.88 -> that that that we made just a couple of
865.519 -> months ago
867.44 -> we want to help customers in that use
870.32 -> case and are adding the capability to s3
873.68 -> object ownership a bucket setting then
876.959 -> that you can apply to all of your
879.04 -> buckets in your account
881.199 -> so what is object ownership
884.72 -> object ownership is a new feature which
887.519 -> is now an enforced setting as a bucket
890.72 -> owner
891.76 -> we launched it to give customers the
894.959 -> right answer for all of them today it
898.24 -> does two things
899.839 -> first it makes sure that apples or
903.279 -> access control lists are disabled and
906.8 -> second it makes sure that you as the
910.32 -> bucket owner own every single object in
914.24 -> your bucket and we have made it as a
916.88 -> setting across your bucket level it
919.68 -> means that bucket policies from here on
922.959 -> out will be the sole and the only means
926.56 -> of sharing data
928.399 -> and access control lists are completely
931.12 -> out of picture
933.6 -> now as a result of bucket ownership
936.24 -> setting bucket owner enforced you as now
940.399 -> will own every single object in your
943.279 -> bucket
944.24 -> so now let's look at our previous
946.56 -> example when you have a data lake in
948.8 -> your in a bucket in account a and there
951.839 -> are multiple writers of data and objects
955.839 -> into that bucket so let's take a closer
959.04 -> look at how this works
961.04 -> so as a part of account a if you have
963.92 -> bucket owner enforced as an ownership
966.8 -> setting for your bucket
968.48 -> regardless of whichever account wrote to
971.519 -> that bucket for example that object
974 -> could be written by account a or by
976.56 -> account b they will always be owned by
979.759 -> account a and as a result account a will
983.199 -> continue to reserve the right of sharing
986.639 -> access to this shared data sets shared
989.04 -> objects with just using bucket policies
994.56 -> so how does this compare to the setup
997.12 -> before
998.24 -> now compared to before you wouldn't have
1001.04 -> to deal with accol at all
1003.68 -> for example
1005.199 -> when account b
1006.959 -> writes to your bucket
1008.88 -> the write doesn't need to specify an
1012.32 -> access control list
1014.24 -> you own all of the objects you can now
1017.68 -> use bucket policies to control access
1021.839 -> for all of these objects regardless of
1025.28 -> where those objects came from from
1027.839 -> account b account c account d or account
1031.6 -> e or hundreds of other accounts
1035.6 -> you can use bucket policy to give other
1038.64 -> iam roles or users
1040.799 -> specific access and granular permissions
1044.4 -> to all of your objects
1047.199 -> now so you you might be ask asking
1050 -> yourself so how do i turn on
1052.799 -> um this disabling accol and bucket owner
1055.6 -> enforced we have made it as simple as
1058.24 -> possible it's a simple bucket level
1060.64 -> setting and we are adding this as the
1063.28 -> third option to s3 object ownership
1066.799 -> called bucket owner enforced now you can
1070.4 -> apply it to a new bucket or any of your
1073.52 -> existing buckets in your account and if
1075.84 -> you want to turn it off you can simply
1078 -> do it at any time and when you do that
1081.12 -> it will automatically restore the
1083.76 -> previous echo so you can go back to
1086.16 -> status quo with just a click of a button
1091.76 -> now we talked about object ownership
1094.48 -> kavita talked to you about different
1096.48 -> kinds of policies bucket policies im
1099.36 -> roles and block public access
1101.919 -> i want to finish off with a specific
1104.48 -> feature
1105.679 -> that is called s3 access points which
1108.799 -> becomes really important as your shared
1111.919 -> data sets grow
1113.919 -> as you grow your data sets and add
1116.559 -> multiple shared data sets to your
1118.559 -> buckets with multiple client access your
1122.32 -> bucket policies get more and more
1125.36 -> complex
1127.84 -> amazon s3 access points helps you
1131.039 -> simplify access management that contain
1134.32 -> shared data sets as you can see from the
1137.28 -> illustration in the diagram here
1139.84 -> access points help you divide access to
1142.24 -> your bucket into multiple groups of
1145.36 -> users each with its own access policies
1149.52 -> in the same bucket
1151.2 -> for instance you can divide
1153.2 -> cross-account users into three specific
1156.24 -> groups finance sales and developers
1160.32 -> each group can read data from a
1163.039 -> designated access point that has its own
1166.24 -> access point policy
1168.32 -> so you can think of your entire bucket
1171.039 -> as a house and access points being
1174 -> specific small doors that can only
1177.36 -> access
1178.4 -> specific parts of your house with its
1181.12 -> own unique key
1183.36 -> as a result of this you don't have to
1185.679 -> create each bucket for each of your
1188.88 -> shared data set you can just use access
1191.44 -> points to make sure you give granular
1194.24 -> permissions to different teams within
1196.72 -> your organization to have specific
1199.76 -> access to parts of your data sets or
1203.039 -> parts of your bucket
1206.48 -> now
1207.84 -> we have made multiple improvements since
1211.039 -> launching access point
1214.32 -> last year we launched s3 access point
1217.679 -> aliases that makes accessing your access
1221.039 -> point from other clients significantly
1224.24 -> easier
1226.08 -> with access points alias each access
1228.96 -> point receives its own unique
1232.08 -> bucket based alias that can be used to
1235.6 -> replace bucket name uris for data access
1239.52 -> now you might be thinking why did we
1241.76 -> build this so when we first launched
1244.24 -> access points customers told us that
1246.32 -> they love the ability to have granular
1249.44 -> access for parts of their data sets to
1252.32 -> specific users but they also wanted to
1255.52 -> use access points with other
1257.36 -> applications across aws and third-party
1261.12 -> apps so we added access point alias so
1264.72 -> your applications can talk to access
1267.36 -> points
1268.4 -> just like they would talk to your bucket
1271.44 -> this means that you can use these same
1275.12 -> access point aliases for all of your s3
1278.559 -> api requests to talk to services like
1281.52 -> emr and they will automatically connect
1284.88 -> to the access point not requiring any
1288.159 -> code changes
1291.12 -> now while we are in the topic of access
1294.08 -> points and granular permissions and
1296.4 -> policy
1297.6 -> i want to talk about policy validation
1300.72 -> with access analyzer now access analyzer
1305.039 -> guides you to author and validate
1308.24 -> secure and functional policies with more
1311.679 -> than 100 policy checks with automated
1314.96 -> reasoning you can use these checks while
1318 -> creating new policies or to validate
1321.6 -> existing policies
1323.6 -> you can use the policy validation to
1326.08 -> confidently check that your policies
1328.799 -> provide intended access
1331.28 -> before they're attached to iam
1333.44 -> principles or at your s3 buckets
1337.6 -> now this saves you time and gives you a
1341.039 -> preview of your security posture while
1344.559 -> at the same time simplifying permission
1347.28 -> management at scale now this becomes
1350.559 -> especially important for our customers
1352.96 -> as kavita mentioned earlier that are
1355.36 -> using s3 buckets for their data lake use
1357.84 -> cases with hundreds or thousands of data
1360.64 -> sets with hundreds of thousands of users
1363.52 -> with one click with policy validation
1366.24 -> you would be able to check your entire
1368.32 -> security posture across your different
1370.799 -> data sets
1373.2 -> now policy validation
1376.24 -> this is a feature that contains over 100
1379.52 -> encoded validation
1381.6 -> based on aws policy writing best
1384.88 -> practices
1386.159 -> it analyzes the policy to dynamically
1389.44 -> generate findings that help developers
1392.48 -> and storage administrators identify
1395.36 -> issues during authoring
1399.76 -> findings are categorized into errors
1402.96 -> warnings and suggestions based on their
1406.559 -> impact
1407.84 -> error findings are generated when a
1410.559 -> policy statement is non-functional
1413.52 -> for example it will generate an error
1416.559 -> when developers wrongly use
1419.28 -> s3 list buckets which is an invalid
1422.159 -> action here
1423.44 -> instead of s3 list all my buckets which
1427.52 -> is the correct action
1430.48 -> now warnings are also generated when a
1433.44 -> statement contains constructs that may
1437.12 -> make the policy susceptible to security
1440.64 -> risks
1442.48 -> for example the policy validation
1444.96 -> generates a warning when a policy
1448 -> construct allows an iam principle to
1451.12 -> pass any role to any service which may
1454.48 -> result in an escalation of privileges
1457.76 -> finally suggestions are generated to
1460.88 -> recommend stylistic improvements that
1463.919 -> don't impact the access
1466.4 -> allowed by the policy for example as you
1469.279 -> can see here
1470.88 -> it generates a suggestion to remove
1473.6 -> redundant actions and help author
1477.12 -> well-structured policies within the
1479.919 -> policy size limits that are easy to
1482.64 -> understand and simple to maintain
1487.679 -> policy validation is turned on by
1490.4 -> default in the json policy editor in the
1494.08 -> iam and s3 console
1496.72 -> in the im console you can view findings
1499.919 -> generated by the policy validation
1502.72 -> when creating a managed or inline policy
1506.72 -> for your im principles meaning your
1509.919 -> roles and your users
1512.64 -> in the s3 console
1514.559 -> you can view findings generated by the
1517.2 -> policy validation in the s3 policy
1519.679 -> editor or when creating a bucket or an
1523.76 -> access point policy the policy
1526.32 -> validation dynamically generates and
1529.2 -> updates its findings as you edit your
1532.64 -> policy
1533.84 -> these findings guide you by providing
1536.799 -> actionable steps to fix the issue in a
1540.24 -> policy statement along with links to aws
1543.76 -> documentation for easy reference and
1546.64 -> user guides you can click on a specific
1549.679 -> finding to identify the location of the
1552.72 -> associated statement within that policy
1556.08 -> these findings get resolved one the once
1559.039 -> the policy is fixed automatically
1563.52 -> now to wrap up we looked at two specific
1566.88 -> scenarios today
1568.559 -> we talked about how to meet compliance
1571.44 -> requirements and improve your security
1574.08 -> posture with features like s3 default
1576.96 -> encryption
1578.159 -> and s3 block public access kavita also
1582 -> walked you through how different
1583.6 -> policies work within s3 for you to be
1586.72 -> confident about the permissions that
1589.44 -> you're generating and granting to
1591.919 -> different users in your organization
1595.2 -> we also discussed how to simplify access
1598.24 -> control even further how you can remove
1601.6 -> access control lists from your bucket by
1604.4 -> turning on bucket owner enforced setting
1607.679 -> in s3 object ownership as a result your
1611.2 -> permission
1612.559 -> models become exceedingly simple so that
1615.919 -> regardless of whichever accounts are
1618.159 -> writing to your different data sets and
1620.32 -> creating new objects as an as the bucket
1623.36 -> owner you have automatic ownership to
1626.08 -> all of those objects we also discussed
1628.96 -> s3 access points which
1631.279 -> opens a specific secure window to your
1634.799 -> bucket that you can assign permissions
1637.2 -> to to different users and then finally
1640.32 -> we discussed policy validations and
1642.88 -> access analyzer to audit all of your
1646 -> permission controls and make sure that
1649.039 -> you are doing the right things by your
1652.32 -> security posture i am so excited to
1655.84 -> finish this tech talk with you and give
1658.08 -> you more thoughts into how aws and
1661.12 -> amazon s3 are continuing to help you
1663.919 -> improve your security and access
1666.399 -> permissions for your sd buckets and data
1669.44 -> sets
1672.159 -> kavita and i wanted to thank you for
1673.84 -> your time and attention and we can't
1676.559 -> wait to talk to you again
1682.88 -> [Music]
1688.399 -> you
Source: https://www.youtube.com/watch?v=1mwHx64JVTk