AWS re:Invent 2019: [REPEAT 2] The fundamentals of AWS cloud security (SEC205-R2)

this talk here is for the people who implement build troubleshoot deploy monitor DevOps sec UPS dev check out sec DevOps it how many of you fit descriptions like that great you've come to the right place we're gonna put the fun in cloud security fundamentals I'm not continuing until I get a few more laughs yeah I could wait here all day yeah well you know I could be talking about I could be putting the mental in AWS cloud security fundamentals I don't think I'm allowed to give that talk but here's a cuz here's you know here's here's what you might be facing you know particularly even if someone who's been using the cloud for a while but you know particularly if you're kind of new to the cloud you might be looking at the amazingly diverse and broad and deep array of offerings from AWS a hundred and seventy something I think services now and this is a screenshot I took of the AWS console I took that a couple weeks ago it's already out of date right this this set is growing all the time and you'd be well within your rights as you know somebody who's trying to build security into your applications be well within your rights to look at a list like this and wonder how you're going to do that tasks right look at all of these services you've probably never even heard of all of these there are probably some services on this list that you will never use and the question is if your organization is using AWS do you have to learn different security techniques do you have to study each of these services in and out in order to understand like its particular the particular ways in which you need to secure that service the good news is no you don't yes we do have you know we do have a triple digit number of services across so many different domains you know IOT networking databases storage machine learning all of these very very different domains that you're probably not an expert in all of them and yet when it comes to securing what you're doing with these services there's really only a very small number of fundamental that is a builder in AWS you're gonna see them repeated over and over and over again so that's what this talk is we're gonna take these three and I think there are kind of three categories of things that if you understand them sort of from first principles in AWS you're gonna see them everywhere you go in AWS and you're gonna be able to take advantage of him there just patterns that repeat over and over again so that's what we're doing this is a very builder focused session we are going to be high on the practice low on the theory you're gonna come out of here with some real skills you can use hopefully you come out of here and you go you go back and look at workloads you may already have in the cloud or workloads you're thinking of building in the clouds and you're gonna see these concepts everywhere you're gonna see applications of these concepts everywhere so that's what we're gonna do we're gonna this is kind of a play in three acts we're gonna start by talking about permissions which is you know these are all important topics but that one's the most important or talk about data encryption and then finally we'll talk about network security and like I said when you go home you're gonna be able to apply what you learned here very directly we're gonna do this from first principles this is a nuts-and-bolts session you're gonna be looking at real things here all right so let's get started so the first topic I said this wasn't most the most important identity and access management all right why did I say it's the most important because it's the service in AWS that if you are a customer of AWS a hundred percent of you are using this service this is our authentication and authorization service now the WS and AWS stands for Web Services and that's the you know the whole reason why the cloud is so elastic and agile and all of that is at you know at its core the cloud is allowing you to provision your infrastructure by calling api's right now if you're gonna call ApS you've got to be somebody and you got to have permission to call those api's and that's true across all of AWS so as a builder in AWS you do need to know your way around I am and the better you understand that the more secure your applications are going to be it's although this sounds like kind of a deep domain topic authentic patient authorization it's it's very approachable when you sort of break it down to first principles and so that's what we're gonna do here and then I'll tell you a little bit about how you go get the specifics for each service as you're writing these policies okay but first of all when you're gonna call one of these api's in AWS you're gonna need to be somebody you're gonna need to be authenticated well there's a number of ways you could be coming into AWS I'm going to show you just to give you a flavor of just a couple of them and you know whether you are the person at your organization deciding how people get into AWS or whether somebody's already set this up for you hopefully this will help you recognize the way in which you're getting to a table this is kind of map it to the rest of this so you might be coming into AWS is something called an iam user an I am user has long term it's an identity that is in an AWS account you may have created one if you showed up to AWS on your first day with a credit card and created an AWS account you probably wouldn't created an iam user that has a username and password logging into it might look something like that if you're using our command line interface you'd have like a different pair of long term credentials these are long term credentials it's an identity an account in an account it's very simple works the way you think if you're in a larger enterprise though you're your source of truth about who's who tends to be in a directory like for example in Active Directory you'll have users in the Active Directory you'll have groups and you know it could be an Active Directory it could be G suite could be an you know for other things and an administrator and someone in your organization may have set up kind of a mapping wherein you authenticate your directory and then get mapped into a set of iam roles in your organization no that's a different word for an identity in AWS said I am users before these are I am roles they pretty much do the same things except the key differences the role has the role doesn't have long-term security credentials of its own it's always it you're always coming in from some other identity and you have temporary security credentials now you know those of you who you know are listening to this with you security ears on you know that temporary credentials are bet are better than long-term credentials so here your long-term credentials you know they live in the corporate directory you get mapped into one of these roles in an AWS account as a human the way you're getting into AWS is probably a variant of one one or the other of these now not everybody who does something in AWS is a human maybe some of you aren't human I'm not here to judge but if you are running applications in AWS like processes in AWS they probably need to access your AWS resources your AWS things your AWS data as well like imagine running a server 'less application on lambda so you write your function code it's doing some stuff it's probably reading data from other services in AWS and how is it gonna do that it does that with API calls and those API calls guess what they're authenticated and authorized with I am so I am comes into play there as well I have just a couple of examples of various compute environ this this comes up a lot across AWS our various compute environments where you provide some code or some logic or some implementation of something and it runs it runs on one of these environments or any of many many more and these environments will all make a veil I'll give you the option of associating an I am role with the environment for example you'll see as you're launching an ec2 instance or creating a lambda function you're asked to associate an I am role with it that's an identity for your application the cool thing about that it's a role so it uses temporary security credentials that you never have to handle these compute environments are all really good of taking care of the muck of getting those credentials and delivering them up to the application for you if you're using one of our SDKs you almost don't think about this at all because it's just made available to you the great thing is you're never handling any security credentials so for our non-human applications that need to access AWS they get identities to their iam roles and in fact I'll even show you what that looks like when you're creating an iam role cuz you'll you will see this screen at some point if you ever go to the console to create a role and you notice there's actually four options across top the first option is what I just talked about roles for different compute environments with ec2 and lamda given as the given as the first choices cuz they're by far the most common so you would do you know you would do this if you had a non human process that was gonna run on some AWS service you can also get into an iam role from another AWS account hold that thought we're going to talk about that later and then the final two are for human identities human identities that have their credentials that have their identity sitting either in a web identity or or a directory that supports sam'l so these are all the sources from which your identities can be getting into roles okay so you're either a rollover user whenever you're making an API call to to AWS and I just wanted to tell you just wanted to mention just kind of at a high level what's going on like how you get authenticated to AWS so you're coming through any one of any number of doors either in the in a service in AWS services console or command-line interface and SDK you're effectively calling these api's and what happens and this is all done for you by the console CLI or SDK what happens is they take those credentials be they short term or long term credentials and they sign your request it's an HM X signature done with the secret part of the key the request gets sent to whatever service you're gonna call so up here you know we might be calling s3 perhaps to get some data out of a bucket and s3 receives this request and it authenticates it it makes sure that the suit the H max signature on it is you know correct visa V who claims they're making the call but of course that's not enough so now we know who you are making the call we know this was a valid call made by whoever's claiming to be making this call but that's not it that's not all right that was the authentication part we still need to do the authorization part we need to know whether this caller actually had permission to read this data from this bucket and the way that works in AWS is called policies if you go again this is this is a screen you'll see as well if you go to the iam console down the left rail policy you'll see that there's a long long list of what we call managed policies these are policies written by AWS for various purposes the one at the top is administrator access guess what that does that lets you do everything what these policies are for is therefore common sets of permissions that go together they're particularly useful for assigning to human beings because human beings often need complex sets of permissions to you to carry out human tasks and you'll if you look at this list you know the search bar works very well if you look at this list you'll notice that each service has a few managed policies that are defined to help you use both that service and the adjacent services that you need in order for it to work you'll also notice there are some that are named after job functions like network administrator database administrator if you go and look at the permissions of for example database administrator you'll see the you know there'll be lots of permissions for the relational database service RDS but there will also be a number of permissions in adjacent services like ec2 that are typically needed in order to do things in in RDS these complex sets of permissions are pretty useful for humans who do complex sets of things but for your applications for your applications you can get more lease privilege than this you know if you think about you write some code for an application you know you know exactly what this code is going to do the API is that this code is going to call are the api's that you are calling in the code and so we can write a permissions policy that is exactly for that and so I'm going to show you a little bit about you know how to kind of least privileged eyes one of these policies which will also give you a taste of how to read and write these policies I'll tell you it's at the fundamental level it's a really simple matter of string matching there's a bit there's there's a lot of pattern there there's a bit of a pattern to it and I'll tell you if if you want to do a lot of this with me here at reinvent I'm also giving another talk SEK 209 getting started with AWS identity we do a lot with poly you'll come out of that really really knowing how to interpret policy at very literal level but okay let's let's write a policy here and let's write a policy here and see if we can figure out what it's doing so policy so a principle and role or user will have associated with it zero zero or more policies and each of these policies is getting one or more statements these statements all look like this they all have an effect am I allowed to do this thing that I'm talking about or am I not allowed to do this thing I'm talking about so I'll say either allow or deny it'll say what you are allowed or denied to do and you'll notice that wildcards are supported and then resource what can or can't you do it - what's the object of this statement and your API calls are matched against the policies that are attached to you and if somebody says a lot if somebody says allow and nobody says denied it's allowed nobody says anything it's denied okay so what does this mean in English this means that if if I had this policy by for example attached this policy to the role that my application was gonna run on on on ec2 if I attach that role to that ec2 instance my application would be able to take all actions in DynamoDB that's what it means now if you think about that your application a typical application is probably gonna be like reading and writing some data maybe this this is a read-only application so I'll be reading some data from a table and DynamoDB or no sequel database so this policy you might think this is not quite least privileged right for example dynamodb has API is like delete table and my application is probably not gonna be trying to delete a table and if it does try to leave the table something's wrong and I don't want that to work right okay so I can get a little bit better at this I can be very specific about the actions I can look at my code and see what API is I'm calling and dynamodb it turns out I'm calling these api's you know batch good item and get Adam are forgetting Adam by key you know either in a group or one time and query is you know to query against an index okay all right I've been specific about action this is much better right now I can't delete tables I didn't need permission to delete tables so I shouldn't have permission to delete tables all right but I can do even better right I might have lots of tables in my account and I know exactly what table my application is written to read so I'd like to be specific about that as well and so that's how I do that I'm specific about the resource now in case you're wondering what that long string is that I just wrote and how I put it together well that's called an Amazon resource name an AR n you'll see this all across AWS it's how we full equality it's a fully qualified name to a resource to a thing in AWS now you can just to give you a taste of what what you can do with the level of flexibility and power of these policies give you this is a different kind of policy you might be using some things you haven't seen before you'll notice that I have a condition here I didn't have one before so secrets manager gets secret value secrets manager is a great service of ours that well it does what you think it holds your secrets and then lets you control access to them via iam so this get secret values how you reveal the value of a secret and you'll notice that I have this condition here and I'll sort of the I'll explain in words what the condition does you'll see that there's a it's talking about the tag on the secrets manager resource it's saying that I've tacked tags in AWS or how you attach metadata to items so if I have a tag on the secret that says what project it belongs to and then over on the right-hand side of that string equals it's a variable substitution the project tag on the principle they've got to match visually what that's doing over here is a picture like this a picture like this where I have let's say I have different projects in my account I got a red project in a blue project so let me tag the secrets that are to the red project I'll tag the secrets for the blue project I'll tag the role that's that's supposed to do things with the red project I'll tell you the roles to the to the principal who's suppose I'll tag the role for the project for the blue project and each of these should respectively have access to the right secrets like red guy shouldn't go in there and get access to the blue secrets so this thing works the cool thing about this so this is called attribute based access control the cool thing with this policy is I didn't say anything about red or blue all I said is that if you have this policy the projects need to match you can access secrets that are tagged to the same project as you are now you might be wondering where did I pull all of these policies up out of how do I pull how do I pull policies out of my hat in order to put on my project this is how you do it all of these policies for all of these services all follow the same pattern and we document it this is my favorite page of the AWS documentation Bar None actions resources and condition keys for AWS services it's a super exciting name but it is the it is actually I think probably the most useful page of our documentation down the left rail you can see that we have a list of every service that we have and if you go visit that service page it will tell you it'll give you a big table with a list of each action that the service supports for each action how do you talk about the resource like what parameters have a resource that we authorized and for each of those resources what conditions can you write policies against and you go and look at for the service you're using you want to write a lease privilege policy for the application that you're running you go look at the actions you take and then figure out how you can tighten it down based on and we'll show you how to write the AR n for the resource and all of that this is a very useful page of documentation you'll be consulting it often if you're in the game of lease privilege so all that having been said we just talked about how to do some nice granular lease privilege policy within and AWS account but if you're using AWS for really almost any kind of enterprise use case and I'm talking small businesses I'm talking large businesses you're probably gonna find yourself working with a number of AWS accounts in AWS account the best way to think about what that is it is a container small C container for identities and things in AWS it's a box you can put around a set of resources and identities that go together so if you're kind of a small business a start up getting started you're probably gonna want an AWS account like one for your production environment and one for your test environment and one for your development environment you're gonna want these different environments because you know you're gonna want actually hard walls of isolation between them so they don't get mixed up with each other so that you can give your developers lots of access to the development environment and not a lot of access to the production environment at a much larger organization an organization with many business units and with you with many different divisions you might have lots and lots of accounts hundreds maybe thousands each with its own workload again it's it's a unit of blast radius containment and ownership that's how to think about it so in an organization you're gonna tend to have a number of accounts and so since it's much easier to draw four accounts than 400 accounts let's draw four you might say that you have like the yellow group of users with access to the accounts that contain yellow workloads the blue the blue or green or whatever color that renders as with access to the blue counts and then you know and you know maybe they don't know each other and maybe they don't like each other and then you have this administrator who is you know highly trusted who's gonna have access to all your environments and highly try the way you know he's highly trusted is wearing a tie and we trust people who wear ties right ok well so if you're operating across multiple accounts you're gonna get into a situation like this sooner or later where we have one account let's call it account one one one with an identity in it because remember these I am roles and users they two are resources and they'll they to live in an account so you have an identity an account one one one needs to access some resource and account for for for like this s3 bucket an example situation in which that might arise is that s3 bucket might contain sort of business wide config for your applications and so they all need to read it across all of these accounts so cool I got this I know how to write a good lease privilege policy and I am let's write a policy like this this role is gonna need permission to talk to this s3 bucket so let's let's write a policy for that allow s3 get object that's how you do a an AR n for an s3 object which is the object of s3 get object cool we're done let's go work no right well they ask them the question if the answer was yes and also actually it shouldn't it shouldn't work right if that were to work then I could sit there in Becky's AWS account and write myself a policy that gives me access to your bucket and you better believe that's not what we do right so I know this doesn't work because account 444 owns this bucket owns this data they have to have a say in whether these other accounts can get to them so that's where a concept called resource based policies comes in and for many of our services particularly those like s3 that really anticipate having a lot of cross account use cases they offer resource based policies s3 will call them bucket policies different services will call them you know different kind will call them different kinds of names they're all known as resource based policies and all of them are an I am policy that is attached not to an I am principle not to an identity but to a resource that says who can access this resource great so account for for for does actually intend for account one one one to get access so they'll write a resource based policy that's like this and you'll notice here this policy we recognize everything in it though the one thing that's new here is it says has a part about principle that's saying who can take this action you know when we when we attached a policy to a principle we knew exactly who was talking but I was talking about whoever's trying to make the call for the resource we have to you know be specific who it's talking about this notation AWS is how you allow access to another account so does this mean that the entire account 1 1 1 has permission to the bucket know what it means very specifically is that I'm trusting whoever's in charge of account 1 1 1 2 right like if if whoever's in charge of account 1 1 1 allows their callers to get to this bucket I allow that access as well so that's specifically what it means so when this call is authorized there's two accounts involved 1 1 1 making the call in 444 that has the resource they both need to say yes so now they both do say yes and that's why this access is allowed so this is a pattern you're gonna see a lot another pattern you're gonna see for accessing resources across accounts is this one see because not all of our resources support resource based policies for example DynamoDB tables don't and so this is a pattern you're also going to see in your multi account environments when you need to start in one account and get to a resource in another account you know so uh we've already established that no amount of policy I can put on that role in account 1 1 1 it's gonna get me to that DynamoDB table and account 4 4 4 and that's as it should be right but I do know that if I if there were a role in account for 4 4 I could definitely write a good policy to let them get access to the table here I'm giving it access to read specific items by key in this table so if I had that role I could definitely do this but that cross account role that that's not who I am I'm still an account 1 1 1 so how do I get there well this is where remember we said that I am roles can be assumed from another account well this is where we're gonna do that so I am roles just like s3 buckets support resource based policies and I am we call those role trusts policies or assume role policy documents again a snippet of I am now this doesn't say what the role can do that great policy says what the role can do the role can read dynamodb this says who can assume this role who can become this role you'll notice that the action here is STS security token service assume role and again there's a principle here saying I'm gonna trust account 1 1 1 what assume role means if you look at what STS assume role does it's an API STS assume role when you call it the result of that request when it's successful is a set of temporary credentials and if you use those temporary credentials to make requests you are then that role it allows you to assume that role by giving you some temporary credentials to it so this role is saying account account one someone from account one one one provided they have permission to do so can become me and then you know as me they can go and access that dynamodb table so the final part of this is of course like I said that doesn't automatically allow everybody from account one one one back in account one one one this role remember we're not saying anything about dynamo D because we can't do that but we can say I'm going to assume that other role so the access pattern looks like this this I am role assumes the other I am role gets back some temporary credentials and then as that role is accessing the dynamodb table if you see assume role policy documents around your accounts that are allowing other accounts that's the pattern that they have set up and often you don't need to do this mechanics by yourself our SDKs off for various kinds of their called role credential providers to allow you to make it easy so you're not often engaging directly with these mechanics but that's what's happening a little bit more on multi account environments to manage a multi account environment you'll use an AWS service called AWS organizations AWS organizations has a number of really useful integrations around AWS to help you get visibility into one of these multi account environments the organization itself is owned by a special account one that I'm not showing on this picture called the master account that they pay the bill for this organization and they you know they hold a lot of the kind of security and governance levers for the organization but organizations give you kind of a nice hierarchical view of these accounts these are organizational units I have up on the screen and also give you kind of a number of other really useful capabilities here remember these green users with access to maybe the accounts and the green öyou these yellow users with access yellow you so you know create some roles for the blue users and roles for the yellow users bring back my highly trusted tie-wearing administrator and one really nice way to you know a nice sort of facet of organizations a service that's integrated with organizations that'll let you simply set up something like this the service called AWS single sign-on that allows you to make these mappings single sign-on allows there's a couple of ways to get users into single sign-on one is you can create them directly in single sign-on which if you're a smaller organization and you don't have your own separate directory of record you want to create these identities in AWS once and then map them around that's a good and map them around that's a good way to do it we announced just last week that you can also use office 365 identities here if you have them in an azure active directory you can kind of bring those identities into SSO and then map those identities and then your users are signing in with their office 365 credentials and being mapped you know the blue people into the blue accounts and the yellow people into the yellow accounts and so on but one really powerful thing if you are in charge of an AWS organization at a large organization or in a small organization one feature you should definitely familiarize yourself with is service control policies and now that you understand - I am service control policies are a way to create sort of an outer bound on I am permissions across this whole organization or across you know an organization unit a part of it and I'll give you an example of something that's really really useful to do with service control policies we got 22 regions around the world for on the way this number is always going up I'll make a pretty strong bet that either either almost nobody or actually nobody in this room is using all of those regions you're probably using one or two or maybe a very small number of regions in AWS and so you may want to simply prevent anybody from creating any resources in the regions you have no intention of using if you have no intention of using say the Singapore region you probably want to make it so that if anybody tries to spin up something in Singapore either either accidentally or because they don't understand which regions you use you probably want that to just get blocked you know so you don't to pay for it service control policies offer a great way to do this our documentation shows an example of how to do exactly what I just said with a couple of other examples of common use cases they look like I am policies but they're attached to the organization they don't grant anybody permission to do anything rather they're expressed mostly in terms of denies they say what people can't do and that's authoritative across the whole organization so if you're in charge of an organization now that you understand I am this is definitely something to look at because it will make your life a lot easier it will reduce your audit surface okay so now you're pretty good at Identity and Access Management we're gonna move on to sort of our second topic key management service data encryption because if you're doing anything even halfway interesting in the cloud there's some data associated with it and it's probably data you care about and want tight controls over key management service is our encryption service that lets you tightly and specifically and visibly control access to that data now this is actually the shortest part of this talk because it's the easiest part these integrations tend to be pretty simple so what we're gonna talk about here is how to look for those integrations and then kind of what their what their implications are on your iam policies which you know you know our experts in so that's what we're gonna talk about here I am gonna tell you just a little since this is a talk about nuts and bolts and I imagine most of you in this room like to actually understand at a concrete level what's going on I'm gonna explain a little bit about what's going on with our kms integration with our services if you don't understand you don't follow it's okay I'll explain why you don't need to understand this but the mechanics of kms is an AWS service it's got api's encrypt and decrypt these do exactly what you think they take chunks of 4k for 4 kilobytes of data at a time and you might be thinking like okay well if I'm using kms to encrypt my data in s3 then my objects I'm not just storing tweets in s3 I'm storing bigger things than that they're more than 4 kilobytes long and so I don't want to you know keep making a billion round trips to kms in order to get my data encrypted and decrypted so the way we the way we encrypt our data in many of our services that hold the day is something called envelope encryption what that means is that when encrypting the data we'll go and have kms generated data a symmetric key that will then use that that will then use locally to chew through all of the data get it all encrypted store the encrypted symmetric key along with the data so then when it's time to decrypt the only thing we need KMS to decrypt is the symmetric key so we can then go back and chew through all the data and decrypt it the reason you didn't need to understand that is because AWS services are doing this for you so you just need to know how to look for these integrations however if you are ever in a situation where you're needing to needing to do these these crypto dances we offer a crypto SDK and AWS that makes us a lot easier but generally don't need to do even that I'll show you how this integration looks in s3 this pattern repeats around AWS so if you see it once you'll be able to look for it and recognize it and use it everywhere but you know this is what it looks like when I'm creating an s3 bucket and you know you'll notice it as I'm going through the bucket properties it's asking me about encryption and I get a couple of choices with encryption this choice here is you know s3 just encrypt my data it's called SSE es3 server-side encryption s/3 s/3 encrypts the data with a key controlled by s3 I don't have to think about or worry about anything that's all s3's problem the other option is when you want to have a specific key that you use and the you know the thing about having a specific key is then you can specifically control access to the key which you may wish to do the way you would do that is with the sse KMS option here now if you choose this you get a you choose which KMS key in your account if you look at what's in your account you'll see that there's one that's named there's one that's named s3 this is your default key for s3 it's configured to have permissions so that everybody in your account automatically has permissions to it you can choose that or you can choose a KMS key that you want to create specific that you want to use specifically for this bucket so let's let's choose that option so let's choose a KMS key KMS keys they are referred to by gooood that's those are their identifier Zin KMS so let's choose that great s3 is going to by default be encrypting all of my data in this bucket let's think about what that means from a permissions perspective okay so I have this bucket it's full of data that I have encrypted with a specific kms key and now I have this roll and I want this roll to be able to read this encrypted data great I know how to read data from s3 this is how I do it allow s3 get object and the correct AR n for the buckets objects so what do you think I think I'm gonna be able to read this data no you're getting good at answering my questions with no right I can't I can't read it why can't I read this data in s3 yeah there's another resource involved now it's true that when I called get object I wasn't specifically talking about the key I was talking about the object but there's another resource sitting there in the wings and that's the KMS key that was used to encrypt the object now authorization in AWS is done very literally and that's the way you want it done so if you're going to access an AWS resource you better have permission to access that AWS resource so I have permission to get to the data in the bucket so that part works but there's a second part here in order to decrypt the data actually give me something that isn't totally useless I'm gonna need permission to the key as well and right now I don't write because nobody said anything about access to this key and if nobody says anything about a permission you don't have it all right how do I fix it well I fix it like this by adding a second part of this policy so I'm accessing the object I already had permission to this now I'm accessing the key that's an AR n for a key you'll see it's going over there and now I have access to this object so these encryption integrations they're very simple now you know how to look for them to turn them on but just be aware that as you're accessing these items you will now need permission to both the you know both the data with both the data and the key in order to be able to get read access and this gives you sort of two points of control all right we're at the final part of this which is network security now it's actually not necessarily true that a hundred percent of you will have a virtual private cloud your own network in AWS but probably the vast majority of you will you know it's possible to get through AWS without ever managing a network yourself that would be in a like an entirely serverless kind of application api gateway lamda dynamodb in all of those in all of those services no infrastructure is being provisioned specifically for you in a network somewhere so you don't actually have to manage a network but VPC does since since it's almost inevitable that at some point you will need some kind of infrastructure running in a network VPC virtual private cloud this is your network that you control and that you control the connectivity into and out of and those are your security controls at the network level so networking is a whole domain unto itself but as far as getting network security right in AWS there's really only a couple of concepts you need to know and even if you don't have a deep networking domain or even any networking domain background at all these are all very approachable software level visible concepts that it's easy to understand from first principles that's what we're gonna do here okay so what savvy PC stands for virtual private cloud we also Pinos also could think of this as your virtual data center in the cloud and it lives in one of our regions around the world if you learn anything about our how AWS does global infrastructure we have these regions all around the world and for practically all of our services except for those for which it actually doesn't make sense a service in a particular region is a completely isolated instance of that service from a service in some other region so V PC and ec2 are like that certainly so when I have a virtual private cloud in AWS it's going to be in a particular region over here I've chosen arbitrarily our Ireland region as an example us one so this is the EU s one region it's divided into multiple availability zones and these are you know these are a great way to build your highly available applications because we show you the basket where the baskets are so you can spread your eggs among multiple baskets so I don't you have a network that kind of spans this in the Ireland region so that's what I do I create a VPC a virtual private cloud that notation there 10.0.0.0 slash 16 that's site or domain that that's that's a cider notation classless inter-domain routing basically means these at the addresses in the VPC you choose this the addresses and the VPC are going to start with 10.0 that's something got something ok so I've got a network inside my network I'm going to create some sub Network some sub spaces of that IP address space you'll notice that some of these subnets are called public and some of them are called private I'm going to explain in detail what I mean by those words in just a little while but a subnet lives in an availability zone and it gives you somewhere in which you could launch infrastructure so the private subnet on the lower right hand side here you know would have IP addresses ten dot zero dot fifty dot something so that's what that notation means all right so let's deploy something let's deploy some infrastructure into this network let's build a really simple web service and with this web service my intention you know it's gonna be fronted by an application load balancer I'll have only one instance of that but you know I create it to span the different availability zone so when I set it up I'm telling it about subnets I have an application load balancer my external customer is my customer I want my customers from all around the internet to be able to talk to my service to be able to reach the IP address of this load balancer these load balancers are backed by a fleet of web servers ec2 instances hopefully in an auto scaling group sitting behind these these load balancers they're running my application cut my application code on it and they'll turn around and you know maybe get some data out of a relational database that I have that's also in my network it's a very typical architecture you've probably seen something like this before but let's talk about the network security part here well if you understand nothing else come away from here to the understanding nothing else about networking understand this concept of security groups security groups think of these as firewalls in your network they say they specify exactly what kind of connectivity you're expecting so this sounds like a tool of least privilege doesn't it right allow the traffic you want don't allow the traffic you're not expecting and if you heard me kind of describe what this what this application does the infrastructure that I provision in here is really in three groups three security groups and each of these security groups has slightly different rules about what kinds of connectivity I'm expecting and you do that with security groups I'll show you what these rules look like I'll seize our screenshots of the VPC console everything here you know you can also do it via API you'll often find yourself being doing it with infrastructure is code through cloud formation but you know at its core it looks kind of like this okay remember I said my load balancers they're public facing so I though it's an HTTP service so they're gonna listen on they're gonna listen on port 443 and I really do want them to allow everybody and that's my intention so that's what zero does zero to zero slash zero means now these security groups they support you know you can have many rules on them but I'm just gonna have one here because they don't have rules about I don't expect anybody to connect to any other ports on my load balancer so I don't have a rule for that and if I don't have a rule for that I'm not getting that traffic you'll notice also that there's outbound rules I'm not going to talk about those here they're less commonly used but if you wanted to limit if you wanted to limit the outbound connections that could be initiated from here that's how you would do that for those of you with the networking background these are stateful firewalls and what that means is you know what that means is that they really govern the initiation of this connection it's really kind of a simple thing of the syn packet for the TCP connection it's who can initiate action with me and there's stateful which means they track the connection which means once the connections been allowed the replied traffic on the connections automatically allowed that's why I didn't need to make a rule in the opposite direction in case you're wondering okay that's my application load balancer I'm allowing everybody in on port 443 because that was my intention now these web servers that are behind the load balancer they're certainly expecting traffic to be forwarded by the load balancer say on port 8 4 4 3 kind of a private port but what I but I don't expect that from the internet generally and in fact the I'm expecting that traffic specifically from the group from the security the other security group that was containing the load balancer so you notice here I'm listening on put I'm listening on port 80 443 and I'm allowing not an IP address range but another security group so this is kind of allowing the load balancers by reference right if I look at the security now the databases are in a separate security group that rule looks similar it's allowing the security group at the web servers cuz I'm expecting queries from those but this one's on port 3306 you know the my sequel / Aurora port so that's how this works you build your application for anything that has an iam role associated with it you write a nice least privileged I am role that does exactly the takes exactly allows exactly the actions that your applications gonna take and then you think about where the packets are gonna flow on what ports and your right security group rules that allow exactly that and nothing more now you know in practice I mean I I made a very simple example here in practice you may have other other sources of connections to this database so you have other rules for that for my web servers if you needed operators to have SSH access to it maybe you have a second rule about port 22 with specific IP addresses that are allowed to connect into that or maybe a bastion or something like that but then you know it's fundamental this is how you do network security in AWS if you get that you're building secure you're building secure networks in AWS that's really it but there's a second concept that you know in an enterprise environment you'll probably encounter this and it's worth knowing too because it's a second layer of security that you can apply and it's routing and again routing sounds like you know sound like a hairy networking topic and it can be but in in the in the world of AWS again it's straightforward it's visible it's really comprehensible to anybody just break it down to first principles here so I promised I would explain what public and private subnets meant let's look at this problem called the private subnet and you'll notice the kind of things I put in this private subnet are actually what you would think of as private I don't want the world connecting to my web servers I don't want the world connecting to my database I do want the world connecting to the load balancers so you can kind of understand sort of on a conceptual level why I put each of these where I did but very specifically in in AWS what we call a private subnet is a subnet that has no direct route to the internet so subnets in VPC have route tables this is the route table for my private subnet this is the most simple route table that exists it's got the one route that every VPC route table has by default that route says that the destination 10.0.0.0 slash 16 so that's packets that are destined for my V PC I'm gonna route them local to my V PC I have no routes for any other kind of packet so if a packet is trying to leave the V PC it will have no route it will have nowhere to go it gets black cold as far as the subnet that is concerned everything that happens in this V PC stays in this V PC right that's kind of what I want here I know I don't need these I don't need these instances in this database communicating with the outside world now if I go look at the public subnet though though you know those load balancers they're gonna have publicly routable IP addresses on them which means they're gonna need a route to and from the internet so that's done by an abstraction called an Internet gateway that you would attach to your V PC the Internet gateway is a router of any kind isn't a single point of failure of any kind it's it's really just an abstraction that you attach to your V PC to denote that you're gonna be routing traffic to the Internet and in your route table you notice I now have a second route here 0/0 so what you would call a default route it matches everything that doesn't match a more specific route so the packets trying to leave the V PC I say okay I'm gonna send it to the Internet gateway so that it can make its way to the internet so that the internet can reach my load balancers and my load balancers can send replies to the internet so that's how this works now there's actually an intermediate option in here I'm not gonna go into detail about it but I'll just mention it so if you see it in your environment you'll know what it is private if that it's often the case that those private subnets you don't want everything in that you don't want things in that private subnet to be individual to individually have publicly routable IP addresses you don't want anybody connecting to them sometimes you want them initiating connections out to the world like if you think about like access to a young repo in order to download software that kind of thing the option for that is something called it for those of you the networking background you know that the word for that the technique for that is called network address translation that so we offer a NAT gateway so if you are looking at a private subnet you see a 0/0 route to a NAT gateway that's what's going on your infrastructure in there cannot be reached from the Internet but it can send outbound traffic and get replies okay so let's stick with this private subnet idea for a little while and if you use AWS and you look at thee specifically at the endpoints that you talk to AWS services that you'll notice that many maybe even most AWS services that you're talked to talking to are not in your V PC right if I take cloud watch logs a great service for aggregating and analyzing and troubleshooting logs I take its DNS name logs dot-eu s1 data Amazon AWS com I resolve that DNS name and that is definitely not an IP address in my V PC but cloud watch logs and many other services are very useful for example you know a very useful thing you can do if you're running an application on your ec2 instance you can run our cloud watch logs agent on your ec2 instance and you know with a very simple config file you can just tell it the logs are at vara log whatever and it will just the agent will just send your data right off into cloud watch logs so your logs will be in one place there's an encryption integration you'll be able to use great tools like watch logs in sight the only problem is this service is not in your VPC by the way one thing one way to think of these services that aren't in your V PC is their server list before server list was serverless like the thing about these services is they're not provisioning infrastructure in your network and that's why they don't appear in your network but remember my private subnets had no route you know to that 54 dress so how are my agents gonna work the solution to this is something called a V PC endpoint many of our services offer one the V PC endpoint serves a couple of purposes from a security standpoint it's a really great security tool one reason why it's a great security tools that lets you do connectivity least privilege here so a V PC endpoint lets me plant cloud watch logs and it IP addresses in my V PC so now I do have a route to cloud watch logs and it in fact it does some things with the DNS name so that log is that a u.s. one that Amazon AWS will resolve to these addresses in your near V PC so now your cloud watch logs agents can send traffic to cloud watch logs that goes through the V PC endpoints so the route is the routes working fine and get into cloud watch logs and you get all the benefits of you know centralized logging in the cloud but there's actually a couple more things that you can do with cloud watch with V PC endpoints a bunch of our V PC endpoint services such as cloud wash logs support support something called V PC endpoint policy now we looked at I am policies before and this is indeed an iam policy but it's not attached to an identity and it's not attached to a resource and it's not attached to an organization this time it's attached to a network of EPC this is kind of how you use your network as a security perimeter now this policy that you're looking at grant does not grant access to anybody to do anything again it's an outer bound on what can occur from with what kinds of calls to cloud watch logs can be initiated from this V PC through this V PC endpoint I'll kind of translate for you what this policy means it's a new condition that you that you haven't seen yet here principal org ID what this policy asserts is it says ok anybody using cloud watch logs from within this net work the collar better be from my organization actually we just launched last week you could even talk about us require that they be from a specific organizational unit I'm not doing it here but I could have written a very specific policy if I know exactly what cloud watch log groups I expect logs to go to I could have been specific about that again this policy doesn't let anybody do anything it takes away privilege it creates an outer bound it creates a guardrail that's not all you can do with these because the VPC endpoint is part of the network path that actually becomes something you couldn't you could refer to in your authorization policy so imagine this role here this role here I want it I want to give it access to s3 via a VP C endpoint and and you know of course I could put a VP C endpoint policy on that vbc we looked at that before but if I attach a policy like this to this role you'll notice I added a okay so this is giving me s3 get object to the things in this bucket but I'm asserting that if this role is accessing this s3 bucket the network path better include the VP C at this particular VPC endpoint now if you think about what that means that effectively is locking my role inside this network if somebody went and tried to you know launch this role on an ec2 instance and some other network it wouldn't work because this condition wouldn't be satisfied so this means that this role can access this data in s3 but it I have a particular network I expect it to exist in and it better exist in there and in fact you know you can use this condition down here on identity policies and anything can do it at any policies you can also do in the resource based policy so if we write this on the s3 bucket here I'm writing it as a deny policy this is a way to make a nice kind of bucket wide assertion of who can who can get into this bucket and I said okay if they're going to be if they're going to be accessing this bucket I'm a bucket I'll let people access me except they had I'm going to deny it unless they're coming through a network path that a specific network path that I'm expecting and if they're a specific prin so if they're specific from a specific organization that I'm expecting this is my collars my networks on this bucket so you really can do a lot of powerful things with these network path control so it's worth looking at if you're using V PC endpoints in your environment you'll now kind of understand how all of this is put together this kind of brings us to the end here alright so hopefully hopefully you've come away with a kind of a nuts and bolts a fundamental foundational level understanding of these three I think most important patterns that repeat all across AWS so we talked about permissions management we talked about who you are when you're talking to AWS and how you get permission to do the things that you need to do talked a little bit about encryption basically you know if you're gonna be storing data in an AWS service look for that integration you can turn it on you understand what to do with the policy if you have a kms key involved and finally if you know when you're gonna be provisioning infrastructure in your network how you take good control of how you take good control of the security levers available to you in that network you're not done you guys are builders you know how to learn things you learn things by doing so hopefully you're going home here armed with sort of the fundamentals so that you can go and recognize these patterns in your environment I would say go home and build something try to make use of these patterns experiment with them get your hands on them they repeat all around AWS so you learn them once and you use them everywhere in the cloud thank you so much for being here have a great time at the rest of reinvent thank you so much

Channel: AWS Events

Views: 3,727

Rating: 5 out of 5

Keywords: re:Invent 2019, Amazon, AWS re:Invent, SEC205-R2, Security, Compliance, and Identity, AWS Identity, Access Management, Amazon VPC, AWS KMS

Id: QMBkq6MrT2w

Length: 57min 15sec (3435 seconds)

Published: Sun Dec 08 2019