AWS re:Invent 2020: Using AWS WAF and AWS Secrets Manager to enforce Amazon CloudFront origins
AWS re:Invent 2020: Using AWS WAF and AWS Secrets Manager to enforce Amazon CloudFront origins
When delivering web applications through Amazon CloudFront, a common objective is to prevent viewer requests from directly accessing origin resources. Preventing viewer requests from bypassing CloudFront helps ensure all traffic is handled by global edge locations and is processed according to your AWS WAF rule set prior to being forwarded to your origin endpoint. This session covers common origin enforcement approaches with a deeper focus on how to use CloudFront, AWS WAF, and AWS Secrets Manager to prevent viewer requests from directly accessing your origin resources.
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
0.48 -> hey folks i am cameron wuerl and i am a
3.28 -> principal solutions architect with aws
6.24 -> and today we're going to be covering how
8.24 -> to enforce
9.36 -> your cloudfront origins using aws laugh
12.559 -> and secrets manager and so what that
14.719 -> means is we're going to be looking at
15.839 -> how you can
17.039 -> prevent viewer requests from directly
20.16 -> accessing your origin resources behind
22.48 -> cloudfront distributions
24.72 -> so as we go through our discussion today
27.599 -> we're going to be covering a number of
29.439 -> areas we're going to start off by
30.72 -> thinking about how you can
32.32 -> really expand your security out to the
35.04 -> perimeter edge
36.239 -> without having to re-architect your
38.8 -> applications
40 -> we're also going to of course dive into
42 -> the the main focus of the talk today
44.239 -> which is
44.879 -> the specific pattern using aws laugh and
47.84 -> secrets manager
49.28 -> to enforce origins we're going to have a
51.039 -> demo around that
52.879 -> we're going to take a look at some of
54.32 -> the other patterns that you should be
56 -> familiar with when you think about
57.52 -> origin enforcement with cloudfront just
60.399 -> to kind of round this topic out
62.8 -> and then we're gonna at the end we're
64.479 -> gonna give you some resources that you
66.08 -> can take advantage of to quickly get
68.08 -> started and
68.88 -> start testing and running this type of
70.56 -> pattern in your own environments
73.119 -> so if we start off thinking about you
75.36 -> know kind of a basic
76.799 -> web application on aws here we have a
79.52 -> very standard app
80.88 -> we've got you know an application load
82.64 -> balancer we have
84.24 -> ec2 instances behind that and we have an
87.439 -> s3 bucket and so
88.96 -> there's some basic security mechanisms
91.119 -> built into this that
92.799 -> are pretty good so we've got like
94.4 -> security groups for example
96 -> we have private and public subnets and
99.28 -> not you know not a bad start but what do
101.759 -> you think we can do
102.64 -> better what what other things can we add
105.04 -> to really
105.92 -> enhance and improve the security posture
107.92 -> here so the first thing we can think
110 -> about for our website is
111.68 -> adding cloudfront so cloudfront is a
115.2 -> basically a cdn service that we provide
117.68 -> and it allows you to
119.2 -> take advantage of you know more than 200
121.84 -> edge locations globally
123.92 -> and that gives you not just you know
126.56 -> acceleration of dynamic
128.239 -> and static content back to your site and
131.12 -> speeding up access for your users
133.52 -> but it also provides a protective layer
136.16 -> in front of your origins
137.76 -> so by that we can do things like
139.84 -> offloading the requests from your
141.68 -> origins
142.72 -> collapsing simultaneous requests and
145.52 -> then
145.92 -> more security specific things like
148 -> terminating the
149.2 -> encryption the tls encryption at the
152.16 -> edge
152.8 -> and so you can set things like tls
155.04 -> versions that you want to support
156.8 -> we recently added tls support for 1.3
160.56 -> and that gives you for example fewer
162.8 -> round trips to establish that tls
164.959 -> session
165.76 -> as well as it gives you support for
169.04 -> cypher suites that only support perfect
171.84 -> forward secrecy
173.599 -> in addition to those things we also
175.84 -> integrate with cloudfront
177.519 -> to services like aws web application
180.48 -> firewall
181.28 -> and aws shield and so aws shield
184.64 -> is our managed ddos protection service
187.84 -> and this helps with a lot of the
189.76 -> malicious requesters out there if you
191.519 -> think about
193.599 -> if you think about you know bots
195.84 -> scrapers
197.04 -> nuisance requests or you know some type
199.44 -> of
200.159 -> threat that might be out there you can
202.159 -> integrate using
203.36 -> waff with cloudfront so as our next
206.72 -> layer of protection let's go ahead and
208.879 -> add
209.84 -> aws waff to our cloudfront distribution
213.44 -> and this is going to help us really
215.76 -> mitigate those requests before
218.08 -> they get close to our origins okay so
221.2 -> when you dive
222 -> into aws web application firewall
225.2 -> we have a number of services that you
227.28 -> can integrate it with
228.4 -> and what it gives you is a highly
230.48 -> configurable flexible
232.08 -> rules engine that you can integrate with
234.799 -> services like cloudfront which we just
236.72 -> touched on
237.76 -> as well as application load balancer
241.2 -> api gateway and most recently
243.519 -> integration
244.4 -> with appsync and the way you can
247.36 -> integrate
248.159 -> the aws laugh with these services makes
250.48 -> it seamless for you so you don't have to
252.319 -> re-architect your application
254 -> you don't have to think about you know
255.439 -> re-terminating your tls or anything
257.759 -> complicated like that
259.199 -> it seamlessly integrates and makes it
260.959 -> easier for easy for you to get up and
262.72 -> running
264.56 -> so diving a little deeper into the waf
266.56 -> capabilities
267.759 -> so again waff provides a very
271.04 -> robust rules engine that you can
272.88 -> configure and so you can look at
274.4 -> incoming requests
275.759 -> and make decisions on different
277.919 -> conditions
279.04 -> to match on so for example you can look
281.68 -> at the uri
283.199 -> or you can look in the query string of a
284.96 -> request coming in
286.24 -> you can look for matching based on
288.639 -> things like sql injection or cross-site
290.72 -> scripting
291.84 -> and then you can dial in a condition to
294 -> match that and decide whether you want
296 -> to block allow or you know log which is
299.04 -> count those requests
300.639 -> and the pattern that we're going to be
302.72 -> looking deeply at deeper at today
304.8 -> is around looking at the http header and
307.84 -> matching on a value for
309.36 -> origin enforcement in addition to that
312.56 -> waff integrates with cloudwatch so that
315.28 -> you can
316.08 -> you know basically get logging and
318.4 -> metrics off of the waff service
320.8 -> and you can get not only sampled
322.639 -> requests but full logs so you can get
324.32 -> the full
324.88 -> json delivered header information
328.4 -> as well as you know the actions that
330.24 -> were taken and the rules and things like
331.759 -> that with the waf
332.72 -> so you can merge that into your sim or
335.28 -> into
335.84 -> a logging destination where you can do
337.6 -> further analysis
338.96 -> of those requests coming in
342.4 -> we also have you know api driven
345.12 -> capabilities for the aws flaf so it's
347.52 -> integrated with cloud formation
349.84 -> you can take advantage and run
351.6 -> automations this way
352.88 -> so we provide a number of automations
355.52 -> for the waff that you can get started
357.12 -> with
357.6 -> and then you can customize your own we
360.479 -> also have managed rules for
362.319 -> the aws laughs so this is where you can
364.88 -> either by
365.759 -> taking advantage of marketplace using
367.84 -> partner rule sets that are available
369.919 -> or you can also use managed rules that
372.72 -> are provided by aws
375.199 -> and again just want to reiterate the
377.44 -> automation
378.24 -> aspect of laugh allows you to really
381.12 -> implement
381.919 -> you know and design patterns that allow
384.08 -> you to put the laugh
385.52 -> throughout your development life cycle
387.199 -> working into your code pipelines
389.039 -> so that you can test and and automate
391.6 -> all of that functionality
393.199 -> you can also quickly push changes out if
395.759 -> you need to respond for threats
397.68 -> or other things that you need to to
399.36 -> change your rule sets on
402.24 -> so now that we've added aws waff for our
404.4 -> web application
405.68 -> we need to prevent those malicious
407.52 -> requesters from going directly to
409.84 -> our origin resources so let's dive
412.8 -> deeper into that aspect now
415.28 -> so there's a couple of patterns that we
417.599 -> see here so
418.479 -> first of all for s3 origins we
421.599 -> the most common pattern that you're
422.96 -> going to see that you're probably
423.919 -> already familiar with
424.8 -> is origin access identities and this is
427.52 -> essentially where you have
429.12 -> a you know a user that gets created the
432.56 -> special user that cloudfront uses
434.8 -> to access your s3 resources
438.56 -> and you then then define a bucket policy
441.44 -> on your s3 resources
443.52 -> to give them the approp to give that
445.68 -> access the appropriate permissions to
447.44 -> read the objects
448.639 -> and interact with that and any other
450.319 -> requests coming in will be
452.319 -> blocked by that policy then you have
456 -> essentially the other different types of
458.08 -> origins so this is where
459.68 -> you know you think about elastic load
461.44 -> balancing or
462.8 -> you know direct ec2 access for your
465.68 -> origin or maybe
466.96 -> you know an application running in your
468.479 -> on-premise data center even
470 -> behind cloud front this is where we see
472.72 -> using
473.199 -> a verification header is the pattern
475.12 -> which we're going to dive deeper into
476.639 -> here
477.52 -> and then also using ip allow list so
480.24 -> this gives you the ability to
482.08 -> you know basically limit access by ip so
484.879 -> we're going to cover both of those but i
486.24 -> want to dive into
487.68 -> this pattern with the http header
490.24 -> verification
491.199 -> first so when you think about header
494.56 -> verification this ties into a feature
497.84 -> within cloudfront
499.28 -> so when you're using cloudfront you have
501.199 -> the ability to define
502.72 -> a custom header and when you configure
505.68 -> the custom header
506.879 -> cloudfront is going to add that header
508.72 -> to each request
509.919 -> that goes back to your origin
512.959 -> so in this case we've added a header x
515.36 -> origin verify
516.88 -> with a value in it which is basically a
519.839 -> secret string value that we have that's
521.919 -> out there
522.64 -> that gets used and then once it's added
525.519 -> you're essentially going to perform a
527.279 -> verification back at your origin and
530.08 -> that verification can happen in a number
532 -> of places so you might do it at the host
534 -> layer in the application or you might
536.72 -> look at using an alb
538.8 -> listener rule or you could do it in the
541.44 -> laf
542.48 -> with a regional laugh deployment and
545.04 -> that's really what we want to dive into
546.64 -> here more deeply
548.48 -> so this is essentially a pattern where
551.839 -> you're going to deploy a regional waff
553.68 -> with your application load balancer in
556.32 -> that regional waff you're going to set
557.92 -> up
558.16 -> a web acl that web acl has a default
561.76 -> action of block
563.279 -> then you configure a statement so then
566.64 -> i'm going to configure that acl to look
568.72 -> for my header
570.24 -> and then match based on the specific
573.04 -> string that cloudfront
574.64 -> has added to that request and this is
577.92 -> basically something that you can
579.12 -> implement with
580.16 -> application load balancer api gateway or
583.12 -> appsync
584.48 -> if it does not match that particular
587.12 -> condition
588.24 -> with the header then we're going to
589.92 -> basically block that request
593.12 -> so once you have the header configured
596.08 -> there
596.959 -> you need to rotate and secure that
599.44 -> secret value for the header
601.279 -> that's where secrets manager comes in so
603.76 -> secrets manager
604.8 -> is a service that allows you to securely
608.64 -> and centrally store secrets for your
611.279 -> workload so this could be database
612.959 -> credentials could be api keys
615.2 -> and other types of secrets in this case
616.8 -> we're using it for
618.32 -> that verification header value
621.36 -> it gives you central storage it gives
623.36 -> you fine grain control
625.44 -> so you can set im policies around how
628.959 -> who can access these secrets and
632.079 -> manage that at scale the other thing
634.64 -> secrets
635.2 -> manager provides is the ability to
637.519 -> rotate
638.48 -> those secret values over time and this
640.959 -> is an important aspect because you know
642.8 -> in the well architected framework we
644.48 -> encourage you it's best practice to go
647.2 -> ahead and
648.24 -> secure and rotate these secrets over
650.56 -> time
652.399 -> then finally you have this auditing and
654.56 -> monitoring so you're going to be able to
655.76 -> have a trail
656.72 -> of how that secret value how it's been
659.44 -> accessed
660.24 -> and used over time historically
664.079 -> so this gives you that sort of
665.519 -> end-to-end life cycle capability
668 -> when you're managing your secrets at
669.6 -> scale so that rotation piece is very
672.56 -> important to our pattern that we're
674.079 -> diving into today
675.44 -> i want to cover that a little bit here
677.36 -> so the the idea is when secrets manager
679.68 -> needs to rotate
680.8 -> that value it's going to basically
683.6 -> trigger
684.079 -> a rotation lambda with an event
687.2 -> and there's four steps that occur inside
689.519 -> of that event
690.56 -> you have a create secret where we
692.8 -> generate that random string
695.12 -> then the lambda has a set secret so in
698.16 -> the case of our verification header
700.16 -> we're setting the secret value both in
702.48 -> the cloudfront distribution
703.839 -> configuration
705.04 -> and in the origin regional waff
708.8 -> deployment
710.24 -> once that's done we test it to make sure
712.24 -> it's working and the behavior matches
714 -> what we're expecting
715.44 -> and then finally if that's successful we
718.399 -> finish the secret
719.6 -> and what secrets manager does throughout
721.44 -> this process is
722.639 -> use uses version labels uh to
725.68 -> control and help bring you know
728.24 -> consistent
729.12 -> uh continuity to how we go ahead and
731.2 -> manage these secrets at scale
732.959 -> so that if one of these steps fails it's
734.959 -> gonna stop
736 -> and we maintain the integrity of that
738.16 -> secret out there
739.44 -> uh in our application environments
742.88 -> so now that we've put some of these
744.399 -> pieces together let's take a look at the
746.88 -> end-to-end flow
748.079 -> for our for our specific you know waff
751.279 -> secrets manager origin enforcement so
754.24 -> the way this works is the first step is
756.24 -> you have a viewer request that's
758.079 -> generated
759.36 -> for your web application maybe it's a
761.839 -> unicorn
762.639 -> writing application in that case we're
765.76 -> going to resolve that it's going to
768 -> go to the nearest cloudfront edge
770.16 -> location
771.2 -> and from there you'll have a edge waff
774.079 -> that does some inspection
775.76 -> and if it is not blocked by that laugh
779.2 -> acl it's going to be passed back to
782 -> cloudfront
783.519 -> if it goes to the origin from there
785.12 -> cloudfront is going to
786.639 -> add that custom header the x origin
789.44 -> verify header
790.88 -> and then it's that header is going to be
793.12 -> verified
794.16 -> back at the regional alb at your origin
797.76 -> and so once that is verified if it
800.16 -> doesn't you know if it gets through
801.68 -> there
802.16 -> it's going to be passed back to your
803.68 -> backend web servers and
805.36 -> the response will be processed
806.88 -> accordingly and then finally you have
809.68 -> this rotation this critical piece where
811.76 -> we're rotating and managing
813.519 -> this secret value over time
816.959 -> so that gives us kind of the end-to-end
819.36 -> high-level flow now that you've seen the
820.959 -> high-level flow
822.32 -> let's do a demo and see how this works
825.04 -> in action
826.48 -> and you can see here that i have a
829.12 -> pre-deployed
830.56 -> cloud formation stack this
832.24 -> cloudformation stack has all of the
834.24 -> necessary components for the solution we
836.24 -> just ran through
837.92 -> the first thing i want to showcase and
840.56 -> go through is we have our cloudfront
843.519 -> endpoint so if i access that endpoint i
845.76 -> have our
847.12 -> wild rides unicorn site here and it
850.079 -> actually successfully pulls up our site
852.48 -> and we're able to access that resource
855.279 -> you can see that this this came back
857.12 -> successfully
858.079 -> this was processed by that edge waff and
861.04 -> was
861.92 -> made it had made it through that web acl
865.199 -> successfully and this is the behavior
867.199 -> we're looking for
868.56 -> however if i go and do a
871.76 -> request to the origin resource you'll
874.72 -> see that i get back
875.92 -> a 403 forbidden so what's happened here
879.12 -> is that our request
880.639 -> does not have the verification header
883.279 -> that we're looking
884 -> for inside of that regional laugh and
887.12 -> and that's the behavior again that we're
888.88 -> looking for here we want to make sure
890.639 -> we're blocking those
891.839 -> direct origin requests so let's see how
894.88 -> this works so the first thing you'll see
896.639 -> in the cloud
897.68 -> front configuration is that we have our
900.639 -> domain name
902.079 -> that we went to we also have an origin
904.24 -> configured with our application load
906.24 -> balancer back in the region
908.48 -> if i go in you can see that we have the
910.959 -> custom header configuration here
913.6 -> this provides essentially that header
916.16 -> field name
917.12 -> and the secret value so these are the
920.24 -> the fields that are going to be managed
922.079 -> by our secrets manager
923.839 -> uh process that i just ran through so
926.88 -> you can see that value there
929.04 -> now that you've seen the cloud front
930.56 -> configuration let's kind of move back to
933.199 -> the origin and take a look at the
935.839 -> regional laugh configuration behind this
938.72 -> so in the regional waff configuration uh
941.36 -> you can see that we have our alb
943.199 -> association that alb is is configured
946.959 -> for this web acl
948.959 -> and in the web acl we can see there's
953.199 -> already been some blocked requests here
955.279 -> that are that are present
956.88 -> and the reason for that if i drill into
959.279 -> one you'll see that we have
961.279 -> a action of block and that's because of
963.68 -> course
964.399 -> the header for the verification is not
967.44 -> present again this is
968.88 -> of course the behavior we're expecting
970.48 -> here let's take a look at the rules that
973.12 -> enable this
973.839 -> this configuration so in the rules
977.279 -> you'll see that we have
978.8 -> one condition one rule and the
982 -> action is set to allow and then the
984.24 -> default action for this webacl
986.399 -> is actually set to block so anything
989.12 -> that doesn't match this rule is going to
990.72 -> be blocked
992.32 -> and let's now go into the rule itself so
995.519 -> in the rule
996.079 -> we have a statement here again this
998.8 -> statement gives us
1000.8 -> the configuration we're looking for
1002.56 -> which is we're going to look at the
1003.839 -> header
1005.12 -> x origin verify and we're going to match
1007.44 -> on that string
1009.519 -> and we're going to do an exact match so
1011.199 -> this is the string value that's
1013.12 -> applied by cloudfront you'll notice
1016.32 -> there's actually two statements in this
1018.079 -> rule the second statement
1019.839 -> actually is the same but it looks at the
1022.32 -> previous version
1023.44 -> of the secret and the reason for this is
1025.76 -> is we want to maintain some overlap
1028.4 -> of the current and the previous secret
1030.319 -> versions in secrets manager
1032 -> so that when we do a cloudfront
1033.76 -> distribution update
1035.52 -> we don't have a gap where there's
1037.439 -> propagation time where we're going to
1039.28 -> block traffic that we actually want to
1041.36 -> allow you'll see here that the
1043.28 -> action is to allow if it if it meets the
1046.079 -> conditions
1046.72 -> in that rule and that's how the waff
1049.44 -> piece works
1050.72 -> the next piece of this solution is of
1052.88 -> course secrets manager so let's take a
1054.64 -> look at that
1055.52 -> you see here in the console this is the
1058.4 -> secrets manager console for this
1060 -> particular secret
1061.44 -> uh in the rotation configuration let's
1063.679 -> go ahead and
1064.799 -> do a manual rotation immediately so i'll
1067.679 -> go ahead and trigger that
1069.039 -> you can see we successfully scheduled
1070.88 -> the rotation
1072.08 -> um in the rotation you'll see that it's
1074.4 -> set for
1075.12 -> seven day interval that means that it
1078 -> will take 14 days for a
1080.72 -> secret value to completely rotate out
1083.919 -> because we're using both the current and
1085.76 -> the previous
1087.28 -> the other thing you'll see here is you
1088.64 -> can retrieve the current value here
1090.88 -> it's simply a key value pair that gets
1093.919 -> basically stored by secrets manager for
1095.84 -> this use case
1097.679 -> and in the configuration for the
1100.4 -> rotation you'll also
1101.84 -> note that we have a pointer to our
1104.559 -> lambda function
1106 -> so let's take a look at our rotation
1108.559 -> lambda
1109.12 -> and and see how that works for us in
1110.96 -> this solution
1112.96 -> so here we are in the rotation lambda
1115.2 -> now and you'll see that you know there's
1117.679 -> some code here
1118.64 -> to enable this the steps that i went
1120.72 -> through and we provide
1122.799 -> sample code that gives you a scaffolding
1124.64 -> to get this going for any custom secrets
1126.88 -> that you want to run
1128.08 -> this code will is available on github as
1130.799 -> well
1131.679 -> um and then if you take a look at the
1134 -> monitoring
1134.96 -> for this rotation lambda you'll see that
1137.52 -> it's actually already been
1139.28 -> invoked multiple times successfully but
1142 -> i'd like to highlight
1143.28 -> here in the logs that you'll see
1146.64 -> when we rotate this lambda we're going
1148.32 -> to log those
1149.76 -> four steps that i mentioned earlier
1151.919 -> which is
1152.88 -> again we have the create secret step
1155.84 -> right
1156.96 -> then we have the test the set secret
1159.679 -> step
1160.88 -> we have the test secret step and the
1163.679 -> finish
1164.16 -> secret and of course you're not logging
1166.16 -> the secret itself here but you are
1168 -> logging
1168.72 -> information about the process that would
1170.96 -> be useful if you need to debug this
1173.52 -> um this gives us the functionality of
1176.88 -> the solution end to end and you can see
1178.799 -> since we've triggered the rotation we're
1181.12 -> already doing
1182.08 -> a cloud front propagation we're actually
1184.88 -> updating that distribution now
1187.919 -> and now we have sort of our wild rides
1190.32 -> unicorn site up and running
1192 -> with our origin enforcement in place
1196.559 -> all right so that was the demo now let's
1198.32 -> take a look at some of the additional
1199.76 -> patterns that i wanted to cover
1201.52 -> in the talk today the next one is
1204.64 -> if you are using alb and waff is not
1207.52 -> necessarily an easy option for you to
1209.36 -> implement
1210.08 -> for some reason you may want to look at
1212.159 -> using listener rules
1213.52 -> so a listener rule is basically a layer
1215.44 -> 7 rule that you can implement
1217.2 -> with application load balancer and
1220.559 -> you can essentially what we're going to
1222.48 -> do here is you can look at layer 7
1224.4 -> properties of the request
1225.76 -> and then route that request to target
1228.24 -> servers behind it based on that
1230.4 -> so in this case we have a layer 7
1232.799 -> listener role that looks for the header
1234.96 -> with the values of the secret if it
1237.919 -> meets that
1238.64 -> criteria it's going to route it back to
1240.799 -> our target
1241.84 -> servers in the back end if it does not
1244.88 -> we have a fixed response rule that is
1247.679 -> going
1248 -> to do essentially just send a 403 fixed
1250.72 -> response back
1252.32 -> and so this could be an option for you
1254.72 -> to look at i would say
1256 -> i would look to the waff option first
1258.32 -> but if for some reason that's not an
1259.84 -> option
1260.72 -> you might want to take a look at this
1262.32 -> pattern it could be complex if you have
1264.96 -> to
1265.44 -> manage the origin enforcement listener
1267.919 -> rules with other application listener
1269.679 -> rules
1270.48 -> but it is something that's out there
1272 -> that is worth kind of including here
1274.84 -> today
1276.4 -> another way is for the origin
1278.48 -> enforcement might be to perform that
1280.64 -> verification
1281.6 -> back at your ec2 instance either at the
1284.08 -> host layer
1285.12 -> or in your application so this would be
1287.6 -> implementing
1288.96 -> some type of verification maybe using
1291.52 -> apache
1292.48 -> with you know mod security or something
1294.72 -> like that where you're doing
1296.4 -> the verification inside of the web
1298.32 -> server software
1299.679 -> or you could do it in your application
1301.919 -> code so again of course this this
1304.08 -> is not the optimal approach it does
1307.6 -> it is something that you may want to
1309.679 -> look at but
1310.64 -> you would have to figure out you know
1312.159 -> the pattern for managing this at scale
1314.799 -> run you know configuration management to
1317.84 -> push this out across your fleet or
1320.24 -> merge the functionality of verification
1322.24 -> into your code
1323.36 -> into your deployment pipelines
1327.6 -> and then the last origin enforcement
1330 -> pattern i want to cover here is using an
1332.08 -> ip
1332.799 -> allow list so this is a kind of a layer
1336.4 -> three type of approach where we use
1338.96 -> ipsider ranges so we have ip ranges that
1342.08 -> we publish
1343.2 -> that are listed out for cloud front edge
1345.679 -> locations
1346.72 -> once you have that we we can basically
1349.44 -> provide this json
1350.96 -> document if it changes you get an sns
1354.72 -> push and you subscribe to that topic
1357.52 -> that way you can update your automation
1359.36 -> but what happens is
1360.88 -> you're going to take those ip ranges and
1363.52 -> then propagate them
1364.72 -> into a type of rule set
1368.08 -> inside of your origin configuration so
1370 -> that could be a waf ip
1371.44 -> set most commonly i see this with
1374.159 -> security groups
1375.52 -> or you know you might do it even in the
1377.2 -> host layer as well or an on-premise
1379.2 -> firewall
1380 -> possibly i have seen customers use this
1382.4 -> in conjunction with header
1384.08 -> verification approaches as well so
1386.96 -> another one that
1388.08 -> is worth mentioning today all right so
1391.36 -> now that we've added our origin
1393.2 -> protection and enforcement now we want
1396.24 -> to think about what if we want to
1397.6 -> protect our site from
1399.12 -> ddos threats that's when aws shield and
1402.48 -> shield advance comes in so
1404.72 -> shield comes in two tiers
1407.919 -> you have standard as well as advanced
1410.159 -> and standard is
1411.2 -> is included with the aws platform it's
1414 -> designed to
1415.6 -> protect against common layer 3 and 4
1418.4 -> attacks
1419.28 -> however for more sophisticated
1421.52 -> protection and if you want you know
1423.2 -> visibility into
1424.48 -> cloud watch metrics and better sort of
1427.679 -> more sophisticated
1429.52 -> monitoring this is where we really
1431.84 -> encourage you to look at shield advanced
1434.08 -> so shield advance essentially is going
1435.84 -> to do things like give you
1437.36 -> additional metrics baseline your
1440.159 -> application
1441.039 -> traffic over time and then be able to
1442.72 -> look for anomalous activity that's
1444.799 -> consistent with ddos
1446.32 -> attacks you have access to our shield
1449.6 -> response team to help you
1451.36 -> you know prepare or respond to ddos
1454 -> threats
1454.96 -> and you also have with shield advanced
1457.84 -> it will include
1459.2 -> aws waff and aws firewall manager at no
1463.12 -> additional cost for protected resources
1465.44 -> and that can be important for a solution
1467.279 -> like this where you have you know two
1470.08 -> wafts if you're using the
1471.679 -> last secrets manager solution you have
1473.279 -> two instances of laugh deployed
1477.6 -> so the next thing is once we've added
1480.4 -> all of the security layers how do we
1482.24 -> manage this at scale
1484.24 -> and that's where firewall manager can
1486.4 -> help so aws firewall manager
1488.96 -> essentially helps you to centralize
1491.52 -> management across
1493.279 -> aws waff policies and acls
1496.4 -> aws shield as well as vpc security
1499.36 -> groups
1500.159 -> and so it allows you to centralize the
1503.2 -> control and administration of these
1505.36 -> policies
1506.72 -> using integration with aws organizations
1510.48 -> and so once you have this it's going to
1512.24 -> be easy for you as a
1514 -> team to really set baselines
1517.6 -> and centralize the preferred policies
1520.4 -> the preferred
1521.76 -> waff web acls and security group
1524.08 -> patterns things like that
1525.919 -> throughout your accounts and through
1527.919 -> across your teams
1530.159 -> from there you can audit and wrap
1533.279 -> guardrails around that process to make
1535.52 -> sure that the policies deployed aren't
1537.919 -> deviating from those baselines
1540.08 -> that you've set when when you have an
1543.039 -> event where there's a configuration
1545.12 -> drift or if you have you know
1547.44 -> a resource that is not in line with the
1549.76 -> policy
1550.72 -> then you can decide do you want to just
1552.32 -> notify on that or do you want to go
1554.48 -> ahead and automate
1555.76 -> some type of remediation to bring that
1558.24 -> resource
1558.88 -> in line with the particular policy that
1561.039 -> you're after
1562.32 -> so see the the firewall manager can
1564.559 -> really help with that with that aspect
1566.32 -> of management at scale
1568.799 -> all right so let's go back and look at
1571.2 -> our basic application so we started off
1573.44 -> with some
1574.4 -> you know very kind of starter level
1576.96 -> security in it
1578.159 -> but we added quite a bit i mean think
1580.08 -> about the things that we added
1581.84 -> as part of the process we went through
1584.4 -> we went ahead and we started off by
1586.72 -> putting cloudfront in front of our
1588.4 -> application then we took
1590.72 -> and secured our origin and put in an
1593.679 -> origin enforcement using waf and secrets
1595.919 -> manager
1597.2 -> we also turned on shield and shield
1600.4 -> advance potentially
1601.84 -> for protection against ddos threats
1605.039 -> and then we implemented firewall manager
1607.52 -> to really help us
1608.64 -> manage this at scale so this is really
1611.44 -> kind of
1611.919 -> the complete picture of the solution we
1614.08 -> put in place
1615.2 -> and now we're off and running with our
1617.12 -> wild rides unicorns
1618.799 -> and everything's working as we intend so
1621.6 -> that wraps up this
1622.72 -> talk today i appreciate your time again
1625.6 -> there is a
1626.4 -> demo solution deployment you can take
1628.88 -> advantage of
1629.6 -> all this code is available for you
1631.76 -> there's a step-by-step walkthrough
1633.6 -> you can go through to quickly get
1635.679 -> started in your own environment
1638.559 -> a few other resources you might want to
1640.24 -> be familiar with and take advantage of
1642.48 -> here
1642.88 -> and some other sessions as well and i
1645.52 -> thank you for your time today
1647.84 -> and appreciate again if you have
1649.919 -> feedback we would love to hear that
1651.679 -> and uh there's going to be a link for
1653.919 -> that as well
1654.96 -> thank you
Source: https://www.youtube.com/watch?v=32jU3lVumAk