AWS re:Invent 2019: Using AWS KMS for data protection, access control, and audit (SEC340-R1)

my name is Peter O'Donnell I'm a Solutions Architect with AWS I've been with our company for about three and a half four and a half years and I've had the privilege and frankly personal thrill of working with some of our largest most challenging customers we're here today today to talk about kms and how kms can be used to not just kind of manage your keys because of course it's key management service managing encryption keys and being secure is not enough you have to be able to raise the bar on providing attestation and that's really what we're gonna get into today so we do a quick encryption primer hopefully everybody's familiar with kms broadly but I want to make sure that you understand the dynamics of how kms really operates what it means to have envelope encryption we're gonna then talk about how kms can be used to promote these critical outcomes protecting your data improving audit ability in providing overall operational assurance I'll say a little bit more about what we mean by operational assurance as we get through this so as it turns out encrypting is the simple part we're gonna start with a data key this is some of this as complex and the language doesn't help I'm gonna be talking about data keys and master keys in this overall pattern is something called envelope encryption so let's start with the data cave and would generate this securely inside of a validated module and our HSM fleet we're gonna combine this data key with your data and then we're gonna get encrypted data super simple stuff the hard part is what do we do with this data key where do we keep it how do we protect it how do we authorize its use and so the right pattern is that we are going to encrypt the key with yet another key this is also known as wrapping we're going to wrap that data key with the master key and then we're gonna hold the encrypted data key right next to your encrypted data so we've got a key that protects your data we have another key that protects the key that protects your data so then the question is well what are we going to do with the master key and again the right answer is that we're going to wrap them Araki and this is a little bit of a turtles all the way down problems right because you're gonna ask me what are we gonna do with the key that we're using to protect the master key well we're gonna encrypt that one too with yet another key and the good news is that we are gonna do the really hard ugly part of this for you it's what we do here at Amazon we call it undifferentiated heavy lifting so this idea of keys protecting he's protecting Keys is a concept in cryptography known as a key hierarchy so let's talk about the key hierarchy where kms fits in and where you can really get some powerful enforcement some powerful policy control about how these keys are used so again we've got a data key that protects your data we've got a master key that protects the data key and this is your part we are gonna hold your master key material for you your master key material is only in the clear inside of the memory inside of the validated module inside of our HSM fleet and AWS operators do not have access to that key material so it's not almost the questions sometimes they say well how do you protect that master key material from an AWS operator getting access to it and the way we design this system is that there's no such thing as how to secure our ability to access your keys because we have no ability to access your keys so it's very thoughtfully designed kms is a very serious service built by very serious people for very serious customers and it's this point here where we can protect the authorization of the use of the master key that's at the heart of what we're talking about today this is the policy enforcement point the master key takes a policy document and if you're familiar with our platform this idea of a resource policy uses the same json IM language that you would find elsewhere in the platform but when we authorize the use of a master key it's extremely powerful because it authorizes access to the data Keys an access to the data Keys gives you access to the data so this idea of protecting it here again is the policy enforcement point the master key is wrapped by other keys above that this is something that we take care of there's a domain key and a region key this really detailed in a really nice white paper this part you don't have to really think hard about if your cryptography nerd if you're a chief risk person so again really good white paper but the critical part is the access to use the master key in that access to the master key gives us the rest of what we're gonna talk about this morning what else can you do with kms besides managing the keys the answer is that kms gives customers some really powerful tools here because there's policy control on the use of the master key so let's talk about that it's an additional mechanism for access control that accessing the encrypted data is not enough you must also be able to decrypt the data it integrates with all the rest of our services so if you're familiar with cloud trail and I hope you are the audit records the cloud trail contains a journal of not only what's happening in terms of accessing the data attach volume launch instance get object but cloud trail also includes records of using the master key and you can take and tie those we're going to talk about that in a minute and then finally this idea of operational assurance what does this really mean this means that again it's not enough to be secure you have to be able to demonstrate it to somebody whether that's internal audit your boss a third party maybe your customers want to come ask you hard questions about it and those questions are not the kind of thing that you should consider as well give me a day and I'll come back to you because those questions are important those questions are things like how do you know this is set up right are you sure all of our data is protected how do we know that everything in here is have properly encrypted those are important questions and you should have snappy answers for them the good news is we're going to show you how you can provide those question answers to those questions this idea of operational assurance so let's start with protecting your data kms promotes protecting your data of course it's encrypted and really it's also again about access control the customers we see are smo sophisticated customers using separate master keys to partition access inside of even individual environments so it may be that all of your operators can use EBS that's an elastic block store it's our virtual disk service that pairs with a virtual computer so attach volume detach volume create snapshot terrific but you've probably got some disks in your environment that are holding super sensitive data you can use a separate master key for them and by using a separate master key you can have explicit assurance that even if you have ec2 star you should not be writing policies with star in them but even if you have attached volume create snapshot copy snapshot they're snapshots can take ACLs that can be shared even if you have all those permissions it's not enough you must also be authorized to use the master key and for your most sensitive data volumes you can create a separate cmk customer master key and manage the access in a more discreet deliberate and intentional fashion this policy that again goes with the cm case defines this access beginning these are the same policy language that you're accustomed to in even if you have access to the services RDS create snapshot again copy snapshot all these things even if you have access to the services you must have the ability to be authorized to use the master key this is a really powerful way of also separating roles and responsibilities separation of duties on the key you may have a security officer persona who's responsible for setting up the access to the key that's great call that in management actions those actions can be complete defined completely separately from the cryptographic operations encrypt decrypt generate data kiri encrypt things like that so you can be very deliberate that just because your security officers are managing the keys she can't use the key and the developers who might need the key the software components that might need to use the key or of course not permission to manage that key to give away access and again this idea of intentionality you want to be very deliberate if you're operating at scale and large environments you might have thousands of EBS volumes tens of thousands of EBS volumes billions of s3 objects but you can be very deliberate about protecting those objects about protecting those volumes about protecting AWS resources with discrete individual SI MKS that have discrete access to find directly on the key because AWS is an additional or kms is an additional plane of access control it means that when you access these resources it requires this additional authorization to use the key so again even if you have something like s3 star which you shouldn't have you must also have the ability to use the key so in your billion object bucket if you know that a certain prefix slash tax documents needs to be encrypted you can use a separate master key for just those objects and folks in the account who might otherwise have access to that bucket are part of their identity policy maybe the policy directly on the bucket giving them that access it's simply not enough to have the access to s3 that they must also be authorized to use the master key you get again this idea of really sensitive data it may be appropriate for your operators to manage the EBS volumes for all the operating system may be for the installations of the application but the log disk the disk that actually contains the database files the disks that contain PII pH I PCI data whatever you can be more discreet and authorize those volumes separately to give you not only additional access control but additional audit visibility something like RDS RDS is gonna contain a lot of a sensitive data right it's our relational database service the keys necessary to launch the instance are probably something that the operators need to be able to use but the keys that back the secrets to log into the database can be a completely separate key they probably should be a completely separate key again intentionality partitioning access separation of duties really simple stuff because you can just create that's exciting so you could just create a new master keys they cost a dollar a month I'm just gonna let me know if it gets worse let's talk about audit outcomes so again this idea of kms is journaling its activity into Cloud trail and so are the rest of our services and so when we think about your audit outcomes I always like to tell customers we all want the same things so when you think about what an auditor wants it's really what a security engineer wants and what is that so we can use something called encryption context to provide visibility and detail to the use of the master keys and that journaling of the use of the key that's in cloud trail if you're a cryptography nerd encryption context is our implementation of something called a ad additional authenticated data it's a little bit like a tamper-evident seal it's not a secret it's part of improving the integrity of the cypher data when we write our services to integrate with kms this idea of encryption context we use it to reference why the key was being used so when you attack when you create a volume with kms the encryption context is the volume ID when you create a back of the object in s3 the encryption context is the key space in s3 so when we see actions in kms as cloud trail for decrypt we're also seeing this encryption context and you can use that to tick and tie what you see from say RDS is journaling of create snapshot 2kms is journaling of using the key to protect that snapshot this is a detective control but it's also again a really great audit record it proves what was happening and it ensures something called non-repudiation which means that you can't deny that it happened you can't say well I never attached that volume yeah you did it says right here that you did it's really important to have that kind of altered ability to provide that test ation to again internal stakeholders external stakeholders the Risk Committee on the board really really important stuff you can use AWS config now with kms config is our visibility and config management service on the platform and if you've ever pasted a screenshot into a Word document on December 31st you know how flimsy providing attestation of correctness can be well config tracks the changes to your resources over time and config now supports kms and so when we talk about the kms key policy as being the policy enforcement point that is so critical it's again not enough to say that you've dialed it in properly you have to be able to provide attestation that it stayed proper over time and so when you set up access and key policy config journals whether or not that key policy ever changes again because it's not enough to say no I haven't changed it since we deployed config can help prove that so let's talk about as an example s3 so I've talked about cloud trail and cloud trail is really about capturing management events what at Amazon we would call control plain events and so s3 out-of-the-box in cloud trail is going to have create bucket put bucket policy put bucket default encryption management events but the gets and the puts for s3 are not there but you can't enable that it's called the data trail now you need to be a little bit mindful if it's a super public bucket that is backing a really popular website this is a big body of log data and there is a cost there's a fee associated with this and like a lot of things that we sell it's relatively low cost but the hyper scale you should be thinking about the cost for cloud trail there but ultimately it's a minimal operational overhead to get critical visibility who access this data so you get a records of the gets and the puts who place data into the bucket who got data out of the bucket as you can imagine that's an important record to have particularly was sensitive data particularly was regulated data includes the art of the user getting it so you can not only see the gets the puts of course you can see who is getting the doing the work there and again you can be ticked and tied against the kms events and cloud trail because every get out of s3 for a kms protected object you'll not only see the get record in s3's data trail you'll see the decrypt event in KMS is cloud trail when you place an object into s3 you'll see the event in s3's data trail you'll see the event of generate data key for kms in the kms Cloud trail in this idea of being able to have these parallel records that can be ticked and tied together answer some really critical questions questions that are the kind of thing again as I mentioned earlier that you don't want to be able to be like well gosh Dave I'll look into that you should know these things at all times who access this data did accessing this data always require encryption was everything stored here always properly encrypted yes this is the bucket in which we keep our patient records show me that every time the data was placed there it was properly encrypted show me that everyone whoever accessed this had proper authorization to do so kms and cloud trail and the s three-day betrayal can answer those questions and when it comes to answering hard questions this goes back to the idea of operational assurance being able to know that you can in fact sleep well at night that when your CIO calls you and says well what happens if somebody miss configures a bucket what happens if it's open to the world you can say you know what I have a good answer for you that even if you miss configure this bucket you can't do that with kms so even if we set a public object ACL on a really sensitive file you can't do that if it's back with kms because getting that object is not possible without authorization on the master key what if somebody shares an EBS snapshot if you're unfamiliar with this phenomena you should go home tonight and look at the status of your shared snapshots again somebody could share a snapshot call the API great doesn't matter that person does not have the ability to update the key policy document so your data is never actually usable because somebody even who has access to a share DB a snapshot will not have access to use the master key how could I prove who has access over time lots of folks have had identity policies many different people have been able to federate to a bunch of different roles who could have access to this data that was placed here well no matter what they had to have been authorized to use the master key you can answer this hard question in conversely how can I prove who did not have access show me that nobody could have seen our tax documents except for the controller's office kms can answer that question this idea of operational assurance you can broaden that we're moving towards default encryption on the platform so when we think about default encryption for s3 it's not a way by the way to prevent your developers or relieve your developers from reasoning about encryption default bucket encryption can do is let you get the encryption outcomes from software that doesn't otherwise support it that's really the thing to think about when you think about default bucket encryption but what it does mean that you can configure the bucket such that even if somebody places the object without encrypting it that it'll automatically be encrypted anyway and you can configure the entire bucket to always encrypt everything under a cmk same with TBS so you can configure EBS to always encrypt the Williams when they are created really powerful catch-all and you'll see this coming to the rest of the platform over time dynamo is always encrypted there's no such thing as unencrypted dinamo anymore last year we spent several months percolating we encrypted the entire data plain of dynamo which is as large as it sounds so again this idea of default encryption can help promote these same outcomes that I've been speaking about this idea of data protection this idea of auditability this idea of operational assurance kms also of course integrates with our certificate manager so customers when they come to the platform they want to use a load balancer maybe they already have really nice fancy saying extended validation certificates it's a big deal to give us the key material the private key mat of those certificates how do you know that we're doing the right thing well as it turns out the integration between a cm and lb and kms that's the certificate manager of the load balancer and the key management service provides really discreet visibility and auditability in the exact same way so yes you are giving your private key mat to us but there's a really good story about how we're protecting it and you can show that to other stakeholders so from here I'm really excited to introduce my colleague Raj Kapoor one of the product managers for kms to tell you about what's coming to kms that's new to kms in extended capabilities to help promote these same outcomes my friend hello everyone good morning thank you Peter my name is Raj Kapoor I'm a product manager on the key management service team here to talk to you about what is new in kms all right for the next 20 minutes here's what we're gonna do one I'm gonna tell you what is the new feature that we introduced in the service to we'll see what the differences are between what we already talked about so the Cask customer master keys that Peter talked about are all symmetric keys we'll see what this new feature is and what the different data types will be going forward and then we will talk about some common use cases that I've heard customers ask me to introduce as far as asymmetric keys are concerned so asymmetric keys are the new feature if you didn't already figure it out that's what I'm gonna be talking about for the next 20 minutes and also as you all know but shared responsibilities within AWS I'm gonna talk to you about what you can expect from the AWS kms team as far as this particular feature is concerned and then finally wrap it up with asking you for your share of responsibility to keep the keys secure and also be able to use them effectively right so these are some of the things that we'll be talking about in the next 20 minutes so the first thing I mean as somebody in the audience if I were to be sitting there I'll be thinking okay for the last five years you guys have been operating with symmetric keys and you've been telling us that you're encrypting the data securing it so what is with this new set of keys right so the way that I look at it is symmetric keys as you think of um were a secret that you use to encrypt a piece of data and now it turns into ciphertext and unless you have the same secret key to be able to decrypt that data you will not be able to get to the plaintext right so now asymmetric keys are not Keys anymore there are key pairs how many of you in the audience know what asymmetric keys are so all right okay good good good amount of people all right for those who might not know I will still be very basic about what those are so please bear with me people who already know about this so to illustrate what asymmetric is here's what I thought of doing right so have this t-shirt here if you look at the back of it it's plain if you imagine a white line in between or if you tear the shirt up I didn't want to but if you think of it and if you put them back together they are symmetric so the left half and the right half are exactly the same that's what I mean by symmetric when two pieces two equal pieces come together to make one whole right on the other side I have this logo on the left and nothing on the right so if you do the same thing on the front side now you have two unequal pieces coming together and that's what I mean by asymmetric so it's pretty simple example but I wanted to at least illustrate to you what that means so what that gives you is this public key pair and private key pair right so if it's symmetric I told you there's just a secret key you use the same key to encrypt and decrypt now asymmetry gives you this option of saying all right I'm gonna give you a public key and a private key and both of them will be used for opposite actions the encryption average action and the decryption option right so we'll see what that will actually give you in this particular well when you have a symmetric keys to work with right so there are two main things that you can do with them one is digital signing right so what you will be able to do is take a public a public key and a private key for this for this and for digital signing what you do is you take a piece of data and you take a hash of it so you put that data through a hashing algorithm and you get a message digest you encrypt that message digest and the message digest can only be decrypted with public-key associated with that key that you used to encrypt it right so what that gives you is you can produce a signature on top of any data and you give that signature and the data to somebody and they will be able to look at that signature and know that it has been signed but by a private key that is owned by whoever gave you that signature so that's what a asymmetric key used for digital signing can be used for the second thing is public key cryptography right where you take the public key you give it to anybody you would like you would like that to be shared with they take the public key and crypt information they pass it on to you and now you have the private key of that particular key that you the corresponding private key and you take that and you decrypt that information and only you can decrypt it because you have access to the private key right so that's what we were gonna be talked about so let's look at what the signing workflow looks like so the digital signature workflow looks like this the first thing you would do is you create a key a master key as Peter pointed out we will say you will create a signing master key and then what you do is you generate a signature so you take that key and you have some data that you would like to get signed you pass it on to kms you say this is the key that I would like to get produced a signature with and then you take that signature and you take that data and you send it to somebody whoever the recipient is the recipient will be able to take the public portion of the key and be able to verify that that signature was indeed produced by the private key that you own right so that is what the workflow for a digital signature looked like and here's the screenshot of kms today after we launched this feature last week so initially there was only one option for you to be able to create a symmetric cmk but now you have this option to say I would like to use kms to also create what is an asymmetric master key and then you choose whether it is a encryption key or a and then you have multiple key specs for signing right so RSA and ECC are the two signing key specs that we provide and there are multiple key lengths that we also give you based on your requirements right so what do you do first you come create a key and now you have a sign API that we also launched last week and what you will be able to do is you have this data that you want to sign so either you send us a message digest so as I told you you pass that data through a hashing algorithm if you have a large amount of data that you would like to get signed you don't want to pass all of that data over to care mass so you take a hash of it and you send that digest over the kms to get it signed or you can also send me send us the data itself if it is less than 4 kilobytes for us to generate the message digest and give you the signature back to you right and then you also use the get public key API that we launched also so you pass in the key ID you get the public key back now you get that take that public key and you share it with your recipients for them to be able to verify the signature right so that's what you would do use this particular API for and then finally you will also for completeness what we did was we launched the verify API so what that does is now if you have customers your customers that are also AWS customers you can choose to write key policies to be able to say for this particular key I would like these entities to be able to call verify API as well so that they don't have to deal with verification outside of kms although that is a primary case for you to be able to use a symmetric keys in the first place but if you have two entities that are part of the AWS ecosystem you should be able to use the verify API to do that also now we've looked at what the signing workflow is let's see what the encryption workflow looks like right in very similarly you start out by creating an encryption key you say I want kms to create a master key that is encryption that is used for encryption then you download the public portion of the key again using the get public key API and you provide that public key over the recipients whoever you want data to be encrypted with and shared with you they take that they encrypt the information and then they send it back to you and you have the private portion of the key within kms you take that ciphertext send it to kms to get a decrypted write and what does the flow look like again the screenshot here tells you now if you choose an encryption key you have this key spec that is RSA based only for encryption right and then the get public key API again you will be able to call get get public key to be able to download the public portion of the key share it with whoever you would like to give that key to to encrypt data and you would use the decrypt API now and the big difference so you all all all are already familiar with the decrypt API because kms has been you've been using kms to decrypt information also that is encrypted with symmetric keys so far but now the big difference is because data is encrypted outside of kms you have to also pass in the key ID for kms to know what he used key to be used to actually decrypt that information so today when you pass an information over the kms you just pass the ciphertext and that's all that's all you do but with asymmetric keys you also have to pass in the key ID going forward just for a symmetric keys and nothing changes with symmetric and again for complete completeness purposes if you have AWS customers also that you were sharing with sharing this public key with they can call the encrypt API also that is already available and what that does is it gives you an audit trail right so if you have somebody calling your encrypt API you will also know that there is an audit record for somebody doing that pretty operation within kms all right so now we've looked at what the signing workflow and the encryption workflow is let's see what the other feature that we also launched was so we talked about what key hierarchy is an envelope encryption which means that now you have data keys that you can encrypt data with right so similarly what we've done is we've introduced this generate data key pair star and star is not an asterisks to tell you that there is something specific that you have to keep in mind it is just that there are two api's that we launched the generate data key pair and the generate data key pair without plain text API so you might be familiar with generate data key and generate data key without plain text it's very similar now what kms provides you is the capability for you to also generate these symmetric asymmetric data key pairs that can actually be given outside of the care outside of the system for you to be able to use the private key also outside kms if you want so that's the big distinction right so I've talked about how you can create master keys where the private portion of the master key does not leave kms in plain text ever so all of the operations happen within HSMs but in this particular case we will give you both the public and private key pairs outside for you to be able to do any operations outside of canvas as well and now let's look at what the difference is all right so now talked about what symmetric keys are what asymmetric keys are how you can create them in kms let's look at what the fundamental differences are between both of them right so the first thing is that now again as I said there is the symmetric key there's only a secret so it's one thing that you can do for encryption and decryption the other thing that you can do with asymmetric keys is now you have public and private key pairs and that's what we've been talking about so far operations inside and outside of kms so far you've been used using kms to encrypt information and crypt and store it within AWS services or outside in your applications right so every time you had to do an encrypt operation or a decrypt operation you had to call kms but here now with asymmetric keys what you will be able to do is do encryption and verification outside of cameras if you choose to that's the big difference that I want to point out right and then interoperability one of the biggest things why we even started to launch a symmetric key pair asymmetric key functionality within kms is to give you this option to do interoperability with other systems right so as I mentioned if as long as you have to rely on kms for both encryption and decryption there's no interoperable interoperability that you have to think about but now you have other external systems that you have to inter in integrate with or work with you need a way for you to be able to share this key pairs with them and that is where the big difference comes in and then another thing to keep in mind is the biggest also value add for kms is that you have integration with us several AWS services right so that native integration doesn't exist with a symmetry keepers or a symmetric keys today but again the biggest thing with symmetric keys was for protecting data that is stored and you will be able to do that all the time even with symmetric keys today so the big value add was that data that is stored in AWS services you'll be able to you rely on kms to be able to store that and protect that information that you will still be able to do so but asymmetric keys are a little bit different and we will look at what those use cases are and why native integration with AWS services was not a big criteria for us to bake this launch right so let's look at some use cases for why we even launched in the first place right so we talked about how use cases the first thing is I told you asymmetric keys can be used for public key cryptography what that means is customers want to be able to create or generate a data key outside or you can use the generate key data key api of KMS you get a J data key out and you abuse that to encrypt a bunch of data outside and now you take a public portion of the master key the asymmetric key that you created and you encrypt that data key right so you have a bunch of data that is encrypted using a symmetric data key and now you have encrypted that data key again this concept of envelope encryption but now you've taken the public key of the master key that you created in kms and you encrypted the data key and you got rid of the plaintext data key there and now unless you have the capability of being able to take this encrypted data key call kms and be able to decrypt that all of that data is secure and stored and encrypted even in an offline system right so that's the big use case for you to think about why you would want to consider using asymmetric keys for encryption purposes the other use case is again as I mentioned for integrity purposes the fact that you want to be able to sign a piece of data and send it to somebody so I've seen situations of customers telling me that in a microservices architecture for instance if you have service to service communication they want to be able to use JSON web tokens to be able to have that integration happen within those services and to be able to verify that a token has been signed by a microt service that is used for authentication and authorization that is a use case where a symmetric keys can come into play and also in case of sam'l where you have sam'l to connect to sign that's another use case for using asymmetric keys as well right so now we've looked at the use cases we've understood what the symmetric keys are asymmetric keys are what the differences are let's also look at what kms is responsible the years right so in this whole feature launch we also have to look at what we as AWS kms will have to do to protect these keys that we create for you so the thing is we will still generate these keys inside a chisaem's that we've already been using for the last five years right so all of the generation of the asymmetric master keys and the generator and data key pairs will still happen inside of AWS kms as HSMs the thing again with as with symmetric keys nobody including it abuse service operators or employees will be able to use any of these keys or see any of these keys in plain text ever all access and operations are recorded and we've talked about how AWS cloud trail is a source of your record for telling you when a particular key was used by who and when and that is still going to be applicable for a symmetric Keys as well and then availability and durability again we have SLA that we published for AWS kms and as long as we don't maintain 99.9 percent or higher availability there's a guarantee that we give you and that agreement you can find it online and durability we have 11 nines of durability for the keys that we also protect within camera so that still applies to a symmetric keys as well and then a symmetric and AWS kms will continue to scale to your needs right so one of the big things that you rely on AWS kms is to be able to give you access to hundreds and millions and billions of keys to be able to protect all of your information in s3 or other integrated services similarly depending on your needs depending on how your applications would like to use these asymmetric keys we will scale the service to be able to meet your needs so those are all our responsibilities so now I've given you a bunch of AWS kms or responsibilities will tell you also talk about what your part of the responsibility is as well right and I'll tell you your responsibilities are fewer than what ours are right the first thing is because now you have this distinction between encryption keys and signing keys you have to keep in mind that a key can only be used for either encryption or signing so once you've created a key you've designated it for signing or encryption so it's on you to be able to share the right public key over to your constants whoever your other third parties are that you're talking to to be able to encrypt information properly with the right key because if you encrypt data using a signing key then you will not be able to decrypt it and that's not something that you want to be in a state with second thing is again as I mentioned there's no integration native integration yet with any of the AWS services that we have so it's on you again to not pass in a key ID that is a symmetric keys when you have integrated services when you have a service that accepts a key ID in the first place it's not that something terrible is gonna happen it's just that you're gonna get an error back that I would don't want you to get so before you ever encounter an error you want to make sure that you've not passed in a key ID that is an asymmetric key to an AWS integrated service then with asymmetric keys the big thing is there are certificates involved so if I give you a public key you have to know that it actually belongs to me because there could be somebody else that might give you another public key that doesn't belong to me and if you encrypt information with that public key then all of that data is accessible to them so here is where certificates are involved where you have to be able to give them a public key and you say this public key has been certified by a certificate authority to tell you that this actually belongs to me that's something that I would we want for you to be able to do yourself it's not kms that will do it for you it's a primitive that we give you but the certificate for the public keys is something that you have to get it outside of kms and then setting the right policies right as with other customer master keys that we have it's a big deal for somebody who has access and authorization to be able to use a master key so setting the right key policies is something that you have to also take very seriously because whoever has access to those keys will be able to encrypt data decrypt data and also be able to sign data also now going forward which people will now associate the fact that something is signed with a private key that you have access to that private key and that's a very powerful tool that you have to restrict access to only certain identities that you want access to that and so finally I would like to give you a few things before we leave this session or end the session one is today after we launch the service this particular feature it's only available in five of the regions that I mentioned on the slide and more regions to come it's just that we've chosen to go with these first five to launch the feature and then different limits for asymmetric so when kms started out we had hundred transactions per second as a limit five years ago guess what we have customers calling kms at quarter million transactions per second today that's how we were able to scale the service starting from a hundred to two hundred fifty thousand today and similarly for asymmetric keys we are starting out low but we would like to hear from you guys for how you want to use this service for asymmetric needs and we will certainly scale the system to be able to meet your needs as we go along and then the thing to also keep in mind is generate data key pairs as I mentioned you can use kms to be able to generate these asymmetric key pairs to be able to use outside the system and the only way to protect these data key pairs is using symmetric keys so I don't want you to use an asymmetric master key to protect asymmetric key pairs so that's something that you have to keep in mind because again for data protection of data at rest symmetric keys are the logical choice and this is what we've determined that symmetric master keys are the right type of keys to be able to protect key pairs as well and then pricing is also different for asymmetric versus symmetric keys and we have a free tier 4 kms but asymmetric key pairs will not be part of that free tier and that's something to keep in mind as well and finally I would also just want to highlight the fact that at AWS security is our top priority and that's something that we always take seriously and as far as resources are concerned I've written a blog post recently after the launch I would highly encourage you to look at it to understand what the nuances of these API is that I talked about and to be able to understand how these uses use cases can be used in your particular environments and pricing again you can see how the asymmetric customer master keys are priced and as well as well as well as the data key pairs when you generate them you should be able to generate RSA key pairs and ECC key pairs of different key lengths and depending on how many you would like to create and what sort of specification you would like to create there's a different price and those pricing details are also on this page and then as far as documentation is concerned here's the link that'll give you information about that goes into much more detail about the differences between symmetric and asymmetric and how you can be able to use them within AWS kms right and I also want to point out some of the related breakout sessions that might be interesting to you as far as data protection is concerned so I'll pause for a second for you to take a screenshot of it if you would like and then learning security is also important and as imagine assuming that people in this audience are interested in learning more about what you can do with AWS in general and security overall we have a bunch of different trainings and certifications that are available here's information about where you can get those free courses for you to learn more and there's lots of documentation about different date of your security services that we offer as well and finally thank you very much I appreciate you coming to this session on an early morning and I had a good time telling you about what we have to offer and I'm very excited for you to be able to do something with these asymmetric keys that we just launched I also want to point out that so far you've been able to use kms with 55 plus integrated services to be able to protect your data and as Peter also pointed out you have the security assurances you have performance you have availability and the low cost benefits of kms for symmetric keys and going forward for asymmetric as well we have these primitives that we're giving you and we look at kms as a very foundational service and I'm very excited for you to do things great things with asymmetric keys as well I'm very open to any feedback that you have for the service I'd love to talk to you about what more you would like to see in the service as far as a roadmap is concerned thank you very much guys [Applause]

Channel: AWS Events

Views: 22,797

Keywords: re:Invent 2019, Amazon, AWS re:Invent, SEC340-R1, Security, Compliance, and Identity

Id: hxWvbNvj2lg

Length: 50min 25sec (3025 seconds)

Published: Fri Dec 06 2019