AWS re:Inforce 2019: The Fundamentals of AWS Cloud Security (FND209-R)

everybody welcome to AWS his first ever security conference reinforced I hope we're having a great time here in Boston now so I took this snapshot I took the snapshot a couple months ago of our AWS management console this is the list of services that you can navigate to in our console this is not a short list it grows all in fact it has grown since I took this screenshot two months ago and you're here at our first ever security conference for security minded builders here at AWS and I wouldn't blame you if you looked at a list like this and your job is to you know help your organization use the cloud securely if you look at a list like this and think this is a really daunting task you know this is this is a lot of surface area to secure isn't it well I'm here with good news for you because it's true this list is really long and it's gonna keep growing but there's really if you wanted to see if you want to secure in a an AWS cloud environment which is presumably why are all here there's really only although there's a triple digit number of AWS services now there's only a small handful of what I'm going to call fundamental patterns that repeat over and over and over again across all of our services that if you know how to do them if you know how to recognize them if you know what to look for you can actually be very effective at securing all of these services so you learn a few patterns and you're able to secure all of them you can see up here what we're going to talk about here we're going to talk about permissions I'm gonna talk about encrypting your data we're going to talk about securing your network connectivity and we are going to put the fun in cloud security fundamentals there you go okay well so what this is here this is a talk this talk here is for builders this talk is gonna be all practice and almost no theory we're gonna focus very directly on these three fundamental patterns and what you need to know in order to secure your cloud environment with them for each of them I'm going to give you a quick 400 on one and what they are and why you care about it and then we're gonna go right into right into the right into the details of how you use them and my goal is when you walk away from here when you go when you go back home when you leave this beautiful city of Boston in June and you go back to wherever it isn't you came from the goal here is to accelerate yourself as you go back and help your organization use the cloud securely because you know we're not going to talk about every single service that you use rather we're going to talk about the patterns you're gonna come away from here knowing what to look for and the rest will be details that you can fill in all right we're ready to get started all right I am really like of these three patterns if you know nothing else this is what you need to know to secure your environment I am identity and access management in AWS okay so the four one one on this is this is authentication and authorization in AWS the I stands for authentication and the a M stands for authorization identity access management and why do you care about this you care about no matter what you're doing an AWS you care about this because the WS an AWS stands for Web Services you reach all of our services via API and these api's are authenticated and authorized this is how you grant entities permission to make API calls on behalf of yourself in AWS so we're gonna give you sort of the we're gonna give you sort of the quick primer on what you need to know here to be effective and I'm not gonna lie a lot of I am is a lot of I am is just knowing how to look at the documentation knowing what the patterns are to apply and knowing what to look for in the service that you're using so that's what we're gonna that's what we're gonna go after today so we're gonna learn how to read and write these policies okay so first of all let's talk about the identity half of this if you've ever logged into AWS using a username and a password you know you did something like this you are an I am user that is one kind of identity for humans that we have in AWS these are long-term credentials you also have you know long-term programmatic credentials and I'm sure many of you have interacted with this is one possible identity for humans in AWS you might hear me use the word I am principal and I am principal is an identity in a I am it's somebody who can make calls so an I am user is a principal you might hear me use the word principal and other way human beings can get into AWS I'm not going to cover this topic in depth here but you might have if you're at a large enterprise organization you might have seen this mode of getting into AWS you got your own corporate corporate directory like an active Microsoft Active Directory or something like that and you are signing in to that and then and then being federated is the word into AWS landing in not in I am user but in I am role it's a different kind of principle and a federated role is another way that a human being could have an identity in AWS against from which to make calls and then there are I am also I am roles for this I mean this is I just put five things up here but a large number of AWS services especially our various compute environments ec2 lambda ECS whole lot of others can themselves have I am identities because if you think about it you're running a server list application on lambda you're running an application on ec2 instances nearly everything you do is going to be making API calls against AWS services and is gonna need an identity you know to be authenticated as to make these calls so that's another that's another kind of identity in AWS also an I am role also an I am principal but an identity for non-human applications so all of these environments they have the ability to they have the ability to have roles and the nice thing about iam roles and again this is all mostly taken care of for you under the hood they operate with short term credentials the security people you should like to hear those words short term credentials so this is who you can be in in in I am and in fact like you know on this role topic if you were gonna walk into the AWS console the I am console and go to create a role this is the first thing you would see here the first the first choice you would have is what is this role for and you see there's four options up top this first one is for your application and you see there's a whole long list below of the various kinds of the various kinds of environments your application might be running on ec2 and lambda being the most common choices so you know so those are up top roles are also we're going to talk about this in a moment in a little bit later but roles are also how you grant access into your account from outside your account we'll talk about that a little bit later you also use iam roles for that and then finally Federation like we'd like to showed you before for human identities from various kinds of identity providers web identity providers and sam'l identity providers so that's how you make a role those are the options for what a role can be and I just want to say a couple of words on how authentication works in AWS again I promised practice more than theory but just so you understand how this works the fact of the matter is you don't need to know because almost like in only except in very exceptional use cases you're going to be accessing AWS you go through the console through one of our many languages programming language SDKs or through our command-line interface all the authentication stuffs going to be done under the hood for you but the way this works is you have a pair of credentials a non secret part called the access key ID a secret part called the secret access key and your API call is going to be authenticated by signing the request an H Mac signature of the request with the secret key when you submit it to the service then the service is able to authenticate it actually if you're curious about this what I would do is just look at you know look at the look at the actual HTTP request that gets sent to an AWS service when you make the API call if you're curious how that looks and you'll sort of figure it out but who you are is only half the story right the other half of it is authorization now that we know who you are and that actually you making this API call to say s3 what can you what are you allowed to do and now that's where policies come in in order to be allowed to do something to make any kind of request in AWS you have to have a permission policy that gives you permission to do so well so we have a number of pre-canned this is in the policies pane of the IAM console we have a number of pre-canned policies they have you know human readable names they sort of self they're sort of self describing what they do and I would actually these are really useful for setting up permissions for human roles that have like common sets of fairly coarse grained coarse grained actions that they want to do it's actually probably worth your while if you're trying to learn and if you're someone who likes to sort of learn by looking at the details it's how I like to learn I would actually you can look at how these policies are written to sort of get an idea of what these services do I actually find that to be very a very useful way to learn about what a service does is to go look at its you know look at its managed permission policy and get an idea of what kinds of permissions it needs but a lot of the time and especially for especially for writing your own applications you're gonna want to go finer grain than that and that means you're gonna need to learn how to read and write in iam policy now the fundamentals of reading and writing I am policy are fairly straightforward again repeatable patterns and whereas each service has different you know different kinds of conditions and actions that they support really the patterns here if you learn them you're gonna be able to take our Docs and write a good policy so here was about aside from a policy that just grants all access to everything this was the simplest policy I could think of okay so what's going on here in this policy alright well all statements and the policy has one or more statements all the ones I'm going to show you here have one statement but they could have multiple alright so first off all of these statements are gonna have an effective the effect is either gonna be a lower deny it you know that means what you think actions you're gonna have one or more actions and these actions can be wildcard and so what this means here is this means all actions in dynamo DB and then finally over here what canon can't you take that action against and here at wildcard that and what this means is that whoever has this policy attached whoever has this policy attached can do anything in dynamo DB so this will be an appropriate role for spur up maybe like a this would be an appropriate permission for you know say a human whose job it is to you know look after all of the DynamoDB tables in an account okay well your security people you probably want to get a little bit more granular than that well let's say it's gonna be writing a I am policy for a an application that I'm writing maybe this is going to be an application I'm going to run a server list application I'm gonna run a lambda that needs to you know read a bunch of things out of a dynamodb table as part of doing its job this is going to be this is going to be the permission for policy attached to the role for the lambda function okay so you know I know a couple of specific actions that I wanted to do batch get item get item query that's how you pretty much how you read things out of DynamoDB there are a couple of other actions that also do that but if I know these are the actions I'm taking then can make it a little more specific hey you know what I can make this even more specific what I could do here is you notice here now I'm being specific about the resource so what's going on here what's different here is first of all this notation here this notation here is called an Amazon resource name in a RN and you see it's it's got the service name the region the it's a fully qualified name and I'm being very specific I'm saying this application I know it's trying to read my table name I might have other tables in my account the applications not going to read them so I'm giving it specific access to this table you'll notice I actually have two resources here now why is that well that's because if you go and look and I'll show you the documentation page in a couple of a couple of minutes if you go and look at the documentation for how dynamodb does policy there'll be a big table we have a big table like this for every service and you'll see that for a query dynamo DB query queries involves both the table and the index that you're querying so I'm saying both the table and any index under the table is queryable by my application so that's how one of these fine-grained policies works I want to see more policies alright here's another one this one has something new okay so this is a different service that we're talking about here secrets manager you've been a familiar with secrets manager it's it's you know it's a way to securely store your secret data and protect it with you know with with permissions in AWS you know a way that you no longer need your developers handling the secret material themselves okay so get secret value that's how you get the value underneath the secret so this is giving someone permission to look at the secret saying star for the resource any secrets in the account but I'm adding this new thing which is a condition in this condition and you look at this for a second you can kind of figure out what it is saying here what it means here is secrets have tags on them tags are a way of attaching attributes to items across AWS the secrets manager supports tags so if I tag my secrets with the project it needs to match the prot you can also tag iam principles like users and roles with tags so the project of the collar has to match the project of the secret so that's what this policy means and so that's what it means and in fact it's attribute based access control right what this means is that people working on the read people tagged with the read project can read the read secrets and people tagged with the blue project can read the blue secrets and so this is a really useful way to segment groups of things in your account so that different groups of people have access to different groups of things attribute based access control okay so how did I write how did I figure out how to write all those policies we got a lot of services they do a lot of things you know there's a lot of conditions available across these different services well this is my this is my favorite page of the AWS documentation actions resources and condition the keys for AWS services because along the left rail here is a full list of all of our services and for each of these there's going to be a table a table that has a row for every action tells you what kinds of resources you might put you would put in the resource field and then tells you what kinds of conditions you can specify against those resources so you take the pattern you just saw go look at the documentation page for the service that you're using and you can apply this and you can write a fine-grained permissions policy for anything that you're doing now in an AWS enterprise environment it's often the case that we everything we've talked about so far is about is for permissions within a given AWS account now those of you who work at enterprises even those of you who work at smaller businesses you're probably aware of the fact that in reality you're often working across multiple AWS accounts sometimes a small number sometimes a very large number in your organization and you're trying to secure the cloud across all of these accounts and you got different groups of people with different permitted permission levels to different accounts some of these accounts that you know these accounts will have different security posture than others some accounts are for people science experiments some some are for your you know extra secure customer data these accounts are all different and yet you need to secure all of them and you'll often find that it's the case when you're working across accounts that you're in situations where somebody some principal from one account needs to get at some resource like an s3 bucket in another account okay so how do I do this well we just talked about how to write an ion policy right so okay let me write a policy like this allow s3 get object and I'll put the s3 object say RN in there this is gonna work what we think should this work no because think about it right why should I over in that red account over in the account on the left why should I be able to write a policy that grants me access to somebody else's thing like if I can do that then I could just grant myself access to your bucket right and that's obviously not okay so when you have two accounts involved in an authorization you actually need it allowed from both sides so this caller does need this does need this permission because they're gonna be calling get object and so they need permission to call get object on this resource but you also need something over on the bucket owner side that says that this account can come in so that's where something called resource based policies comes in s3 bucket policies are an example of resource based policies but a double digit number of our services support these on their resources and what they are is they are there I am policy they look like all of the patterns that we've been seeing before but they're attached to the resource like to the s3 bucket and not to the principle making the call alright so you see over here we have a snippet of iam policy over here it's got one new thing in here principle we weren't looking at that before because all of the policies we had before were attached to a principle so you knew who the principle was but this bucket you can kind of see what it's saying it's saying I will let anybody from account 1 1 1 1 2 2 2 2 3 3 3 3 call get object on you know any object underneath this bucket now you might be wondering if you're looking as you're looking at this s3 bucket you might be wondering what that root thing is right maybe you've read somewhere that root is not something you should do in AWS you should get rid of your root credentials you should always be an I in principle that's correct that's true what root means here what it means precisely and again I told you this is more practice than theory I can give you a little bit of theory right now you don't understand the next part it's okay what this means this resource policy the principle in this resource policy it's actually what it's doing is it's trusting this role this account to issue policies that give access so that's very technically what it's doing but in practice back in reality what a policy like this means is that okay I trust that other account and anybody in that other account who has permission to call to call this bucket they should be able to so that's what this does that's what this accomplishes in practice so now we have two accounts involved the principal says they can make the call the resource says the principal can make the call as it says that they trust the account to issue a principal for the resource to make for the principal to make the call and now this call is allowed so that's what it takes when you're working across account both sides need to say yes when you're getting an access denied when working across accounts when you're troubleshooting the first thing to look for is both sides okay now a lot of our AWS services support resource based policies but some of them don't for example a dynamodb table what happens when a principal in this account needs to call a dynamodb table in this account well DynamoDB tables don't have resource based policies so there's another pattern you can use for cross account access if you're going to do that the way it works create a role create a role right next to the resource in that same account and like any other iam role we'll put a policy on it and that policy you know will look the way you expect it'll allow let's say we're trying to allow getitem on this particular table so now you know that anybody who's in this role can make getitem requests against this table now of course how do you get into this role from over here well let's do I am calls it's a trust policy but really it's another resource based policy like the one you just saw an s3 what does this say well this one over here says assume role that's the action you take when you assume a role I'm going to trust the root of this account again I'm going to trust this account to say who can get into this role so I'm gonna trust this other account now the third leg of this is of course so this account seems to say that they can get in but this account needs to as well so we'll put a policy on this caller principle here not saying anything about DynamoDB but instead saying that they can get this role can get into this role so now with all of those things together the way the access is done is this role assumes the other role gets back some temporary credentials because now it can be that role and then using those temporary credentials it makes the call to DynamoDB so those are your two patterns for cross account access if you ever need to do that but still on this topic of multiple accounts in AWS when you're working across multiple accounts in AWS the service to look for the service to help you to help you with governance to help you with control to help you with security and variance across these accounts is AWS organizations now at its most basic level what AWS organizations lets you do is it lets you organize your accounts into a hierarchy of organizational units you've got it's not pictured here but you've got a an administrative account that we call the master account that's in charge of the organization you don't actually run any of your workloads in there that account is just there for administration of the rest of the organization and you can do a lot of really useful things now this talk is not really focused on organizations but I just wanted to point out a couple of a couple of really useful things that you can do here one thing you can do here and this is especially relevant if you don't already have your own directory and Federation provider and you're trying to manage human identities and ADA in into an AWS organization I would look at AWS SSO our single sign-on product SSO lets you create users directly in NASA so it can also integrate with a managed Microsoft Active Directory in your V PC if you have one of those and what it lets you do is it lets you map users to access into access levels into AWS accounts which gives you a nice way for your users to from one place into multiple accounts rather than having them juggle a lot of passwords or assuming a lot of roles all over the place so it's it's a nice simplifier for that but another thing that if you are another thing that if you are and if you are working across multiple accounts working with an organization once you you know get to really understand these patterns of I am you're gonna start to identify some what will call security invariance across your organization things you just want to hold true everywhere and if they're expressible in iam policy you can use something called a service control policy in your organization now what that is it's a policy that applies for any principle anywhere under the organization making an API call that policy is going to become part of the authorization so if it has denies statements if you just want to deny anybody from using certain regions you would put that in your service control policy and in every authorization that policy would come into play and you know a deny if we encounter a deny anywhere in your policies the action gets denied so it's a good thing to know about as you start moving up a level if your job is to secure an entire organization you know go look at service control policies and as a matter of fact we just launched we just launched the ability to to look at your historical usage of various services across your organization that's in the IAM console you look at the left rail organizations it's a good thing to look at is you're trying to figure out what service control policies - right okay so that's what you need to know to do permissions on your cloud environment let's talk about your data right because you know because your security people you know that you should be encrypting your data and our service for doing that is called KMS key management service kms for own one on that it encrypts and decrypts that's what it does all day long and as a matter of fact what you need to know you don't even need to know how to do that because about I just counted this morning I think it was like 50 ish AWS services have integrations with kms where you can use kms to encrypt your data and the service takes care of all of the Mechanics for you so this is actually pretty simple and I'm just gonna go through kind of what your is so really what you need to know is what you're looking for is you're using a service that's going to hold some of your data look for the kms integration I'll show you an example oh yeah a little bit about how kms works you can tune out the next slide if you don't want a bunch of fiddly crypto stuff but the thing is kms has these two AP is encrypt and decrypt they can be used to encrypt up to 4k now you know now you might be thinking okay 4k for encryption and unless you're kind of I don't know unless you're kind of building the next Twitter or something you might have chunks of data that are bigger than 4k right and the pattern that kms uses for it and again we offer like client SDKs if you're doing this yourself you often don't have to do the heavy lifting we'll help you with that it's called envelope encryption kms will generate a data key for you a symmetric key that you can use to encrypt your data you can store the encrypted symmetric key along with your data and then when it's time to do time to decrypt it you decrypt the symmetric key so now you have the symmetric key and then you can decrypt sort of the bulk of your data that's how this works the nice thing is that you don't didn't actually need to understand any of this because the service does it for you so let me show you an example I'm creating an s3 bucket over here and you'll notice as I create the s3 bucket I get asked a couple of questions about how to do the encryption so default encryption I'm like yeah I want my data encrypted an s3 there's a couple of options here the first option here SS e s3 that is encrypted with an encryption key that's managed by s3 that means I don't see it I don't interact with it hardly even know it's there except s3 is using their own keys to encrypt my data at rest that's what SS s3 SS es 3 means I'm going to talk though about SSE kms the kms integration because that's the pattern that you know that's that's the pattern you'll see repeated across many of our services and you'll notice that I actually if you if you do this you'll notice you actually get two options here you get a this AWS slash service name key over here that's the that's the default that's what these service is called the default kms key that's a key that just automatically gets created in your account it's got a policy on it that unilaterally grants access to all principals in the account because the assumption is if you're using this key that you want everybody inside the account to be able to decrypt it it's keys that are specifically to your account and then you have this other option called a customer managed key a cmk there's another acronym that you might see and a cmk you give it the gooood the identifier of a kms key in your account and if you want sort of fine-grained control over encryption you might use that you would tell kms use that key and then all of your by default all of your put objects will just automatically get encrypted by that key and your get objects will automatically decrypt it on the way back so you don't need to think about the mechanics you assign the key and s3 or any of these other services that integrates with s3 takes care of the rest okay so really it all comes back to I am policy so I over here I've got a principal in my account I've got a role I got permission to call get object against this bucket all right and the bucket the objects in the bucket are encrypted we're encrypted with a customer managed key so what happens here what happens is this gonna work raise your hand if you think it's gonna work raise your everything it's not gonna work raise your hand if you knew that the only reason I would be asking such a question is if it wasn't going to work and that's why you said no you guys are great test takers and I'm so proud of you it is not going to work why won't it work well okay so when I make this API call to s3 to get object well you know s3's first job is to authenticate the request good it's me calling looks up my policies actual get of the wry encrypted bits from s3 I got permission to do that good now s3 also is going to try to do a decrypt operation under my identity in fact if you look at your cloud trail if you look at your audit log of calls you'll see that that call was actually made by you even though you never directly initiated it we're gonna try to make that call against that's three guess what this policy says nothing at all about us about kms right and you know the rules of I am is that if I have a deny anywhere it's denied if there are no denies and I have a low-low anywhere it's allowed and if nobody says anything about it it's denied well nobody said anything about kms I don't have permission to decrypt it my get object is going to fail how do I fix this well the color also needs to have permission to the specific key being used here and now both of these calls are going to succeed and again s3 takes care of the decryption mechanics for us the nice thing about that default key that AWS / s3 key is that you wouldn't actually need that because the key is unilaterally granting you access but if you're using a customer manage key just remember that for anybody who's going to read the data it needs permission not only to the original service but also to the key to decrypt the data that's really all you need to know to encrypt your data in AWS finally we'll go into a slightly different topic networking VPC virtual private cloud for one one on this is whenever you are running infrastructure in AWS like your own applications databases other sorts of other sorts of processes your own infrastructure in AWS is gonna run in this network called a V PC and from a security standpoint your concern is you know least privileged for connectivity essentially you want you you want the connectivity that your applications need that your infrastructure needs and you don't want any other kind of connectivity because although you're also doing your also you also have good security practices at your application level and all of your you know all of your services are you know all of your services use T in order to talk to even though you're doing everything else right you also want to have least privilege at multiple layers so that includes your network connectivity so what builders need to know here actually networking I found with my customers that networking is can be sort of a daunting can feel sort of like a daunting thing it feels like a domain unto itself the nice thing about VPC is it makes these concepts very accessible especially the security parts of VPC they're quite straightforward and not that hard to wrap your head around so let's do the builders 401 1 on V PC AWS many regions around the world adding regions all the time and you know if you work with AWS for a while you know that we take our regional isolation very seriously so you know you're talking to a service like ec2 in the US one region our Dublin region and you're talking to ec2 and say our ap southeast to Sydney region sure it's running the same software it's the same ec2 but it's totally separate instances of that ec2 service so we have these regions they're isolated from one another and the end these regions within each region we have further levels of isolate of isolation called availability zones you may have heard us talk about that it's basically a showing you a showing you kind of our fault domains within our region separate separate data centers separate powers separate networking etc we show you this so that you can spread your eggs across multiple baskets as you deploy into our network so you can use this information to build for high availability so what's your V PC your V PC is your network in a particular region and you have control over a lot of things in the V PC most notably the IP address range that your V PC sits on so a very common IP address range to choose for V PC which we have done here is 10.000 slash 16 that's networking ease classless inter-domain routing notation for 10.0 dots on thing that's something that's what this that's what this IP range is and as you can see my V PC spans all of the availability zones because this is how I can run in structure in my network using all of these availability zones in the region now further subdividing my VP see I subdivide my VP C into sub Network subnets sub ranges of this IP address space you'll notice that called some of them private and some of them public I'll explain what those words mean in a little while but you'll see that these sub networks they exist each of them exists within an availability zone I have multiple of them multiple within an availability zone and they're each carve out a space in my in inside my V PC IP address range and now once I have subnets I can deploy infrastructure in there and I'll tell you what I'm showing you over here I'm showing you a service that has a network load balancer a layer for a load balancer that's publicly accessible because I'm going to have I'm gonna have my customers out and out on the internet calling my service and they and they get load balance to my application running on AC to instances and these ec2 instances to serve requests they're querying a database also in my network that's that's what you're seeing here ok so that's what goes in a V PC all this stuff is my infrastructure so it goes in my VP see it has IP address ranges in my V PC if you understand nothing else about V PC networking as a security person I want you to come away understanding security groups and how to do them it's a very straightforward concept so what is a security group a security group for those of you with a little bit of network background and don't worry if you don't have it for the their stateful firewalls that's what they are they have ingress rules they have egress rules they're stateful so they connect they track connections if that didn't mean anything to you it's fine I'll give you an example so here is my application that I just described to you and there's actually you know from a security standpoint from a connectivity standpoint there's really sort of three classes of things in here three groups I've got the load balancers I've got the application running on ec2 and I've got the database and each of these groups like in English I can kind of describe to you what connectivity I expect on for each of these groups right the network load balancer I want HTTP traffic from everywhere because my customers are everywhere so I want you know I want their traffic on that specific port these ec2 instances well you know I probably want access you know certainly need access on whatever port the application is running here from the load balancer and you know what it probably also have some other rules like if I'm going to be allowing SSH access from Bastian's maybe not in this picture I have a set of SSH bastions there in a security group with a you know that I'm allowing traffic in their databases well the databases are expecting traffic on you know let's say they're running my sequel so port 3306 they're expecting traffic from the application and maybe for many other processes that are running in my network or elsewhere that need to get into the database okay so what I just described in words those are your security groups and that's how you do least privilege you write groups about the ingress traffic that you're expecting and that's pretty much it so over here for this first security group I would write a rule that looks like this and each of these groups just for simplicity's sake I'm gonna give them only one rule but you're you can have multiple rules you can too many rules on a security group and I'm showing you only ingress inbound rules but there's also outbound rules are also available if you're trying to limit what kinds of outbound connections things can initiate these are stateful and what that means is that if the connection was allowed in it's tracking the connection so the replied traffic like the you know the act to the syn is allowed to is allowed to go back because the connections already been established okay so HTTP for for port 443 I have this open to the world 0 dot 0 dot 0 / 0 that's exactly my intention I don't have other ports open but I am how I do have it open to the world so the groups at my load balancers and that's how it looks okay what about these these instances on which my application is running I'm expecting traffic on my application port let's say it's eight four four three I'm expecting traffic only from the group that the load balancers are in so I can refer to this other security group by reference I'm not trying to juggle a list of IP addresses here so one security group can let in another security group and then finally the database the same exact story except they're letting in the ec2 instances so always whenever you're launching so the pattern would look for is whenever you're launching something that's going to go into your V PC the AWS service that you're working with is going to ask you about security groups and that's a time for you to ask the question okay what traffic am I expecting in and on what port and to write a specific security group for that and launch whatever infrastructure that is into that group so that's the pattern to look for here okay so that was if you understood one thing it was gonna be security groups big you want to understand two things about networking all right we'll do routing okay routing honestly like honestly if you get your security groups right your network is secure because security groups work right if you don't have an inbound rule for a connection and someone tries to initiate a connection to you it's not going it's it's not going to succeed but it is often the case that you want parts of your network to be what we call public and parts to be private now don't get the wrong idea from the word public the word public doesn't mean that it is exposed to the Internet it doesn't it's not exposed to the Internet unless you wrote a security group that exposes it to the Internet rather it has precisely it has a route to the to an Internet gateway so but let's start with these private subnets well private means in this terminology is does not have a route to the Internet and you know and the infrastructure down here does not have publicly routable IP addresses it only has IP addresses that are routable within the VPC so in VPC we have this construct called a route table a route table is simply a list of rules that packets match as they're getting routed and you'll notice that this route table for my private subnet it has only one rule here and this rule is present on every this rule is present on every subnet everywhere it says ten dot 0 dot 0 slash 6070 traffic bound for my V PC local anything that happens in my V PC stays in my V PC you'll notice that there are no other routes in this route table which means that anybody tries to send a packet to anywhere else and it'll be black hold because there's no route for it if there's no route for it it has nowhere to go ok so what that means is that you know I don't expect anything down here to initiate a connection to the world or to even receive a connection from the world and if they do that traffic will be black hold so that's a good sort of second layer of network security protection now for my public subnets I actually do want that second route because my network load balancers I intend for them to be on the internet so I have second route a second route here 1000 0/0 that means everything and that traffic is going to go to an IG W Internet gateway internet gateway gateway to the internet with a route like that anything in my public subnets that has a publicly routable IP address on it the network load balancers do can get back and forth to the internet now there's actually a third option I'm not going to talk about in detail here but one you should know about if you're doing this setting up public and private subnets if the private subnets need outbound internet access just you don't want in about inbound internet access there's a third option here called a NAT gateway you can look this up in our documentation it's very easy to set up we manage network address translation NAT for you if you know what that means you can you know go and set that up but you know what there's a lot of AWS resources a lot of AWS services that you're gonna find aren't running in your V PC I have a couple of examples up here but actually lots and lots of AWS services this endpoint that you call like if you if you go and resolve the DNS name like over here I've resolved the DNS name for cloud watch logs so that's where anytime I make a request through our SDK through our command-line interface that's where the request is going you'll notice that that IP address is not in your V PC it doesn't start with 10.0 okay so how we're gonna get connectivity to that from right we just got through talking about how in our private subnets there's no route to the internet right now you can make a route to a NAT gateway and that'll work but you know you might reasonably ask the question why do I need a route ability to the internet just to talk to my own my own stuff in AWS services so and you know this comes up all the time for example here on this picture I'm running an application on ec2 cloud watch offers this great agent that you can run on your ec2 agents that will just take slurp up your logs from a location on disk and send it to cloud watch logs where you can do all kinds of advanced analytics to it it's it's really a great way to do your application logging but of course that agent is gonna be making API calls to cloud watch logs so without internet access how is it going to get there well the answer to that is VPC endpoint a long list of our AWS services support this mode of connectivity and the way it works for the way it works for nearly all of them s3 and DynamoDB work a little bit differently than what you're seeing in this picture but the effect is the same and you'll quickly get the hang of how those work as well but you know cloud watch logs and all of our other VPC endpoint services except for s3 and DynamoDB support what they'll do is they'll plant endpoints which sit at IP addresses in your V PC so therefore now your local only route is going to work it's going to get the packet there and in fact it even overrides the DNS name for cloud watch logs so that it resolves to these addresses and so now when your cloud watch log agents is trying to slurp your logs into cloud wash logs it's going to work and like everything else that launches in your interior VP so you get asked about security groups and subnets so typically when I'm launching my V PC endpoints I create a security group for them that allows typical the whole VPC access to port 443 right because I want my whole VPC able to talk to cloud watch log so that's that's the single rule I would write and for for a growing set currently 13 of our V PC endpoint services there's actually even an integration with iam that works here what it lets what this integration lets you do is it lets you use your network as a security perimeter it's called V PC endpoint policies so what I've done here which is what you're looking at here is yet another iam policy except it's not attached to a principal and it's not attached to a resource and it's not attached to an organization it's attached to a network this is network as security perimeter here and what you see here now one thing you should know about this policy I'm not granting access to anybody to do anything this is a this is a boundary this is a Mac what I'm saying is the maximum permissions that can be obtained by anybody who calls cloud wash logs through this endpoint is this so what is this doing here well this got a new condition that you haven't seen yet principal org ID that means the principal must belong to this organization and what this policy means that in this network in this network the only cloud watch logs calls that are gonna get made our principals in my organization calling you know log groups that are calling log groups that are in this particular account and you can hang all kinds of security invariants off of your network like this it helps to keep them simple but this is a very common one you know where you limit where you say like I'm gonna make sure that in this network it's only the set of colors that I expect to be using my network alright so this kind of brings us to the end so what do we talk about here we talked about how you can learn a few patterns and secure everything in AWS we talked about I am what that's for how identities make AWS calls and how to read and write their policies over here we talked about how you protect your data and how kind of how easy it is like what you look for in these AWS services that are integrated with kms and then finally we talked about if you know nothing else about networking you know about security groups and routing now so what I want you to do is go back go back home use these patterns apply these patterns to secure your environment I hope you come away from here able to move a little bit faster on security than you were before thank you so much for coming out here today I hope you have a great rest of the conference here thank you so much

Channel: Amazon Web Services

Views: 45,015

Rating: 4.9346733 out of 5

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS re:Inforce, AWS re:Inforce 2019, security, identity, compliance, cloud security, AWS security, cloud security community, learning conference, Detective Controls, Infrastructure Security, Data Protection, Incident Response, Governance, Risk, Compliance, security best practices, The Foundation, AWS re:Inforce 2019 Sessions, Session, FND209-R, Becky Weiss, 200 - Intermediate

Id: -ObImxw1PmI

Length: 48min 4sec (2884 seconds)

Published: Wed Jun 26 2019