Encryption and Key Management in AWS

ladies and gentlemen please welcome principal solutions architect Bill Shin hi hello we came back I think or you didn't see the last session and you came from the other one and hopefully there's some repeat attendees so this talk is about encryption and key management it's a much more detailed talk to provide you a really good overview of kind of an encryption primer as well as the features and services you can use within AWS to encrypt your data we take encryption very seriously obviously it's sensitive data there's legal requirements in some cases contractual requirements sometimes data privacy laws the require encryption so we've innovated very very heavily around the crypto space in the last probably two two-plus years to provide a spectrum of options to customers who want to encrypt their data so depending on where you are in the journey to the cloud you you may have certain requirements whether that's just a comfort level or an actual requirement to manage the keys yourself and so you can do that and you can not give us anything but encrypted data or and you can do all the encryption outside of AWS and put that data in the cloud or we'll talk about features you can use to encrypt the data basically with a check box using features that are built into the platform so we'll put this in three sections we'll start with client-side encryption and how you can encrypt your data and manage your own keys will talk about server-side encryption where we encrypt that data for you and we manage the keys for you and we'll talk about key management where you can do it on your own you can use AWS key management service you can use partner solutions or you can use Cloud HSM which is a hardware security module built for the cloud or provision to the cloud here's the key questions to answer or to consider so as you're planning a strategy for encryption in AWS there's the really three three questions to consider where are the keys stored on a system in your data center or in AWS what are the durability and availability implications of where your keys are stored where are the keys used is it happening code you control is it happening on behalf encoder host at AWS controls and who has direct access to the keys who has the authorization to use the keys even if they don't have direct access to the keys so we'll start with a little encryption primer because this makes up kind of the fundamental building blocks of how we approach encryption in AWS and with the scale do we operate you know they're their multi trillion objects believed to over two perhaps trillion objects in s3 I think and there many of those are using server-side encryption so when you start thinking about the scale of the number of keys that are actually provisioned it becomes a pretty staggering number and given that we have you know over a million active customers the the number of customers using EBS encryption has gone up dramatically since last March and and you know that's that's been using key management system so the number of keys we have to take an envelope encryption or key hierarchy approach to how we do crypto so we'll talk about that a little bit so you generally have hardware software generating a symmetric data key so that's a key where you know the it's just one key there's not a public and private key pair you take that symmetric key and you encrypt your plaintext data with that key and you get encrypted data then you take that encrypted data and you put it in storage and it's encrypted at rest so what do you do with the data symmetric the symmetric data key well you have a master key and this is this build the hierarchy so you take that key and how do you secure it well one thing you can do is is encrypt it with a master key that's stored somewhere else so you send your data encryption key to a service or something that has the master key encrypts that data encryption key that encrypted your object with the master key and you can have separate authorizations on who can use the master key to decrypt the symmetric data key and now you have an encrypted data key and you can store that encrypted data key with the encrypted object which means that even though the object is there and it's in ciphertext and you have the key that's next to it which seems like why would I store my key with my data but that key is encrypted to a key that's elsewhere with different authorization in a different place so it allows you to keep the encryption key encrypted to another key with your encrypted cipher text so what do you do with the master key how do you protect that well you have a red key and maybe you encrypt that with a with a blue key and how do you encrypt the blue key well use an orange key how do you cook your orange key well maybe a green key or a blue key right so it's just a key hierarchy and so in some cases you do this you know maybe per per row or per column or per item in a database or a no sequel database and then you maybe have the encryption keys that are per row or per item or per column or user encrypted too and you store that with the encrypted data but you encrypt that to an application key which might have a server key which might have a region key or an availability zone key and you can store all those in kms or you can store them in your software but basically it's about reducing the blast radius of the loss of a single key so if someone gets a plaintext copy of one of your encryption keys for a user or a row or an item that's a very small impact it's one record and as you move up the hierarchy you know the blast radius increases but also you allow for different access models so you can say I only want you know certain people to access a subset of the data and only other certain people or under certain conditions can access all the data and you can again it's important too because when you're using those keys and taking key operation or crypto operations against those keys you have another opportunity to audit and to get visibility into who's using those keys so basically when you want to get back to the data you've got to unwrap it right you have to take the you take the data you figure out what key was associated with the encrypted data you find the key that wasn't used to encrypt the data key and you send it to that service and you can create all kinds of architectures this way that that limit and partition data I'm using things like like a crypto proxy or a proxy architecture where you know some services can decrypt sensitive data other ones have to go through a proxy to do that where you have an additional enforcement point an additional audit point so we'll move into the client-side encryption basically this is where you encrypt your data and you send it to AWS so let's talk about you know the way you would do this so your applications in your data center and your applications in ec2 you can encrypt that data wherever you want if you're in your application on ec2 or encrypt it entirely in your data center and store that on s3 and lots of customers do that they use they use s3 as a dumb data store where we don't you know they never send us anything you know that's in plain text they just use it as a backup and that's a fine model and then you can roll that into glacier using life cycle policies to get a a life cycle around your data to get a lot of durability and resiliency of the benefits of s3 the low cost storage global scale but you're not ever sending sensitive data to us it's encrypted to keys you completely manage on premises you can store it on EBS so if you attach EBS volumes to an instance and you encrypt your data entirely in your application or even outside of AWS and you can still store on EBS to be accessed by applications and when needed those applications going to access keys store elsewhere right or you're doing it in applications on ec2 so this is where you manage the keys client side but that doesn't necessarily mean outside of AWS the client might be on an ec2 instance running an application where you completely control the keys and maybe even the software architecture for key management also runs an ec2 right and you still completely control that we don't it's just bits and packets we wouldn't see whether you're you know hosting cat pictures or hosting a key management infrastructure it's still going to be encrypted with your client-side keys your algorithms your key lengths and cypress suites and whatever you want to do in your application redshift and RDS the use cases there would be you encrypt your data outside those services in this case with client-side encryption you might do it at a field level inside an application so you know sensitive personal information identifiable information you might store that in redshift but not not put it in plain text and have us do it but in your K in this case do it client-side DynamoDB you know you have basically a an item you're putting in dynamo and most applications when they use dynamo they I mean there's they're searches and indexing but a lot of the data that's stored in dynamo is individual you know bits of information that are processed by an application it's kind of the benefit of the no sequel model and so fields in those items can be or individual items in that in that item can be encrypted outside of our server-side encryption the clients that encryption with s3 so in order to help simplify the process we provide a solution for client-side encryption for data bound to s3 so the s3 encryption client is integrated into the AWS SDKs so that you can minimize the number of times you make you know there are calls you make to encrypt data so basically the S that when you put object on s3 you're doing an HTTP put but if you're doing client-side encryption using our s3 client libraries the client library will automatically generate that data key used to encrypt that object you select the master key that you want to encrypt that data key to whether that's in your own key management infrastructure or not ideally not ideally you know a local file with a different key and anything that's you know from from unsophisticated to sophisticated you control that master key but the s3 client library is the one that's generating the data encryption key encrypting the object to it and then storing both of them on s3 you can do this from your own infrastructure you could also use the AWS SDKs or s3 to do client-side encryption using an application in ec2 again though you have to keep track of which key was used to encrypt the object right so you get the object back you have to have some identifier to know what the master key was the server-side encryption is where we encrypt the data for you your source data comes from either systems in your data center or from an ec2 instance again and you can upload that data to over over TLS to in a secure connection to any of the AWS services that support automatic server-side encryption so s3 you have several options there that will dive into but basically you can say I want this object encrypted and will encrypt it for you will create a unique data key for that individual object so if you're storing millions and millions of objects in s3 using server-side encryption we're creating a unique data key for each one of those objects and increasing encrypting that to a service key of the belongs to s3 glacier is the same way it's encrypted by default each archive or object you're putting in glaciers encrypted oops EBS volume encryption is is a checkbox or a parameter you pass when you create an encrypted volume that you're attaching to any c2 instance and that uses on the backend key management service before we launch key management service last year at reinvent at the prior to that we launched EBS encryption and behind the scenes it was using key management service so we would create a default key for you per region for each service and EBS was one of those if you check the box it said I want the CBS volume encryption or encrypted volume we created a service key for EBS in that in that region and use that as the master key so for EBS each volume you create has a separate key and you're allowing the service and an ec2 to basically take that key and send it to the commit key management service for you for decryption but it makes it seamless and under the hood so it's basically at rest and Christian encryption but it's happening in kind of the storage fabric beneath the instance you can also do that you know up in ec2 and encrypt your EBS volumes but this is server side encryption for EBS redshift does you know data at rest encryption Oracle and Ms sequel have TD support there's also at depending on the licensing version and there's also at rest encryption for this for the RDS engines now to because they they're using underlying services to encrypt data at rest for the RDS instant engines so server-side encryption is basically you know you're creating a your you know you upload that you say I want server-side encryption that can be done through the console which is unlikely but you can do it through CLI api's you know for applications as well so how does this work with AWS manage keys the customer data is sent to the s3 web server we generate a symmetric data key and use that symmetric data key to encrypt of the plaintext and then like we talked about before with key hierarchies you take we take that symmetric key encryption master key and you end up with an encrypted data key and that's stored with the data in the s3 storage fleet the master key is managed by AWS the s3 service and is protected by systems internal to AWS so this is server side encryption for s3 it's been around for a very long time now how does it work with customer provided keys this is a little bit of a different model this is still not using kms or it's using server side encryption but you're basically handing us a key so you take your key and your object and you hand it up to us and say encrypt my encrypt my object with my key we basically take your key encrypt your data and make encrypted data with it and store it in s3 but we throw away the key so you you keep track of the key and then in order to decrypt the data you have to you actually have to provide the same key when you don't when you do the get and then we decrypt the object for you and give it back to you an authorization to do that is perform using you know a combination of I am and s3 bucket policies but the key is kept on Europe on your premises but you're taking advantage of s3s you know speed and and and the ability to do the encryption in the cloud but that's that's a different model so it's it's just client side there's customer provided keys with server side encryption server side encryption where we do it and then there's some additional models with kms a server-side encryption if you see the console when you're actually launching an instance and you attach a volume to that instance you can select to or you create that volume you can encrypt it and that happens again under the hood i'm using KMS and a default service key for EBS per account per region so what about key management infrastructure so you can see that I mean many many enterprise companies have a key management structure they may have the talent to keep that up to date they may have the talent to evolve and version that key management infrastructure and it's important in some cases to keep those keys where you want them on premises so you can use your encryption and get a client applications or you can run it on ec2 you can run a key management structure a vendor product in ec2 just like you would on premises using Linux and Windows instances and then storing your encrypted data in the services we provided but the key management structure can run anywhere so we introduced key management service because this is a I think a lot of customers were saying key management is hard it's not my core competency if I get it wrong I lose access to my data and we have a proven track record of encrypting data keeping it safe and building things for scale so traditionally you know enterprise key management systems are not built at for cloud scale we had to build one ourselves it's a service that enables you to provision and use encryption keys to protect your data allows you to create use and manage encryption keys from within your own applications via the kms SDK or supported AWS services like s3 EBS RDS glacier redshift rather it's available in all commercial regions that launched it was available so how does it work so you have a client that authenticates between the the authorization layer so you allow identity and access management access to a key to create a key to delete a key or to take operations on a key for example it reaches back to a crypto module that we built and run and keeps keys in an encrypted data store and then we vent out a data key so you can make an API call to say you know create key and you would encrypt that key to a master key that never leaves that crypto module and then you use that that plaintext symmetric key that you generated in a in a crypto module to encrypt your data so you use a the client essentially so you would use this as if you're using the API for kms right not using an embedded service or a server-side function you're actually using this as your key management infrastructure so you can create a bunch of different keys for different purposes and then make API calls to create keys and when you want to decrypt those keys so you create a key we hand back a plaintext copy of that key that you have a member you can encrypt your object with it and then throw it away and when you want to decrypt you make the same you take the encrypted copy of the key that we gave back to you send it back to kms for decryption from the master key and then decrypt your data so how do these integrate with with with AWS services so there's again this tiered or envelope encryption hierarchy where there's master keys stored in kms and there's different data keys for defaults or default data keys for each service so if you if you look in kms and you've done anything with encryption if you've done s3 key management service or kms encryption for on server side you'd see as three key in your account for that if you do EBS volume encryption you'll see an EBS service key in your account and one for each service per region as well so it limits the blast radius of compromised resources in their keys it partitions access you know based on who has access to those keys by service and allows it to scale horizontally effectively so it's easy to manager a small number of master keys then billions of resource keys right the billions of resource keys get stored with the data and then the encryption decryption operations happen against the master keys which means you're really managing access to the master keys in most cases so creating and managing keys and kms is simple it's part of the identity and access management console you can create again you see that just like the inline and a emit rather the manage policies I showed in the last talk these these ones with the AWS icon on the bottom are ones that we create for you per service and you can't change those but then you can create your own customer manage keys too so like I talked about tagging instances you can also have different keys through different classifications of data which means you have a hierarchy of who's authorized to access that data so that data is encrypted in your in your applications you can provision access to different keys so you know one group can take action against a critical data key whereas other groups cannot and can only take action against you know say confidential data or something or application foo or bar then it also gives you that fine-grained audit trail as well so as three servers set encryption with kms we talked about server-side encryption where we manage the keys and everything on the backend not kms we talked about client-side encryption with s3 and we talked about s3 encryption with customer supplied keys but this is s3 encryption with kms keys so when you when you want to do server side encryption on s3 you saw that checkbox before for the object now you can actually use a kms master key and select which key you want to use same thing when you do the API operations as well EBS is the same thing so instead of just saying encrypt this volume you now have the choice to encrypt it with a different key which means that not only do you need access to the ec2 instance to the API to be able to attach the volume you also need access to be able to you know you have to authorize a shinto actually use the key to master key that the volume is encrypted to provides a different level of isolation and boundaries within an account RDS very similar so RDS encryption um just pick the different master key that you want kind of familiar right redshift so you select the master key that you want to use the benefit of this right is that you've you've now been able to integrate a shared key management infrastructure with with new services that we've launched which means that until you can you can have that pace of innovation that as we you know continue to innovate and invest in crypto and making it a core part of our products you're able to leverage those things very very quickly with minimal investment so it gives you control it gives you control of who can create a master key who can use the master key you know create an export data our data key that was encrypted by a master key and all these things are different every single API operation can be individually authorized not only against the kms infrastructure itself because there's there's identity access management policies that apply to the API actions against kms but like s3 buckets or like resource based permissions for example you how you can also put a policy on the key itself so it's not just who can take operations against kms it's you actually have a key policy attached to that key that stays with it who can you can separate access them between who can take it you know keep kms administrators and perhaps different people who can use the key and the authorization stays with the key you also are auditing the use of the master key in cloud trail so the integration between those two services I think is a one of the defining parts of kms that every time someone sends a data key to kms for decryption from a master key that event is logged into cloud trail so you can alert on you know thresholds that are exceeded and every time someone decrypt you know too much data for example you'd be able to quickly detect bulk data decryption or inappropriate access beyond known thresholds which is a great pattern you'd also have from an audit perspective who access my data so if you need to prove who accessed a certain set of data you're able to do that based on the who's taking operations against the actual against the master key we secure your keys so similar to how you might do this on premises we we never store plaintext keys um we plaint excuse or never stored in persistent memory on runtime system so we never seen ever take a plain customer masterkey and persisted to disk there only dare only managed in memory there's separation of duties between the service teams who may need access to kms on your behalf to decrypt objects so like volume for example if you attach a volume and EBS volume to an ec2 instance the EBS service has to be able to decrypt and ec2 has to be able to attach that volume so on your behalf you know the service itself is actually a you know getting access to that key but the service teams and the operators do not access kms anywhere that anywhere master keys are stored or processed and kms operators can't access service team hosts that use the data keys so that separation of duty exists behind the scenes at AWS there's multi-party controls for kms normal operations require signatures from two or more KMS operators and any IPA get on any API call so they have signing keys for the API calls when the operators are taking action against kms for upgrades or replacement of the modules for example there's a very long white paper probably 50 pages describing all the use and operations of kms but a very significant section of that white paper describes the internal controls around how the crypto modules are provisioned and managed I mean there's additional detail in there if you're if you're curious the verified claims of our controls on kms are included in our sock 1 report I'm and validated and audited by a third party alternate key management and encryption solutions so part of the in mus ecosystem its benefits whether you have the marketplace so if you already have investments in folks like you know you all your security products you've got on-premise this isn't specific to just keep management but the you know partners like Trend Micro or alert logic or Sophos or others you know you can allow marketplace allows you to browse and and buy the best security software that's available so traditional enterprise security software is is widely available in marketplace now we have lots of partners so you bring your own license in some cases and in many cases you pay by the instance our just like you would for ec2 so you know buying security when you need it and scaling down the security purchases as well is kind of powerful part on market in marketplace users there's great partners turn micro safe net ver metric cyber cloud voltage others provide encryption solutions that either integrate with our services or run an ec2 so if you have these investments on-premises which many people do you're able to bring those to the cloud so finally we'll talk about encryption and key management with with Cloud HSM so this came out before key management service did and it was designed because people wanted to have close proximity between their applications running in the cloud and the hardware security modules that are needed to decrypt you know data encryption keys so an HSM is a tamper evident tamper resistant hardware security module often if it's validated by you know standards that are required for for HSMs to be certified the the need was you didn't want to have to go all the way back over direct connector VPN or you didn't want to have to go back over the Internet to your key management for structure on premises but you needed access to your data in the cloud and you wanted that to be low latency connections right or the other use case was I don't want to have a data center anymore and last thing standing is this hardware security module that any of us didn't have so we launched key management service or cloud HSM rather it's a hardware device for crypto operations in key storage so it not like kms kms is a key management system it keeps track of authorizations and which keys were used to encrypt other keys that it's a full-blown key management system hardware security modules are just the module so you need a key management system in software running an ec2 most likely or you can use the api's directly and kind of do that yourself but most of these most the deployments have associated with them some kind of a software you know solution like SafeNet or trend strong protection of private keys so the physical device does not grant access to the keys so if I log in if I have access to the physical box um I can beat it up all day and if I do too many operations or attempts to get at those keys that they will destroy the keys essentially it's a purpose-built device it's it's certified by third parties to comply with security standards and basically we provision it and put it into your V PC for you so there's a there's a request you make we stand up hsm instance we provision it in into your V PC and then the the access to the device so the network configuration of putting an IP on it and getting getting it built up does not the same thing as access into the crypto modules so you receive a dedicated instance our dedicated access to this HSM it's it's an appliance just for you it's located in AWS data centers and it's managed and monitored by us so for availability and for making sure it's up and running we take care of that and we replaced it if it fails the the actual hardware and only you have access to the crypto modules so when we hand over the device you create partitions within the HSM that we don't have access to so if you need absolute control of the keys but you still want to do that in the cloud and you're not willing to use kms Cloud HSM is sort of that bridge on the spectrum of trust so rather you don't want to do it completely outside of AWS you want to be able to have things close but you still don't don't you're can't for some reason use kms so it's it's the interim it today this is the SafeNet luna SI appliance so it's a vendor supplied appliance and in system that's we may add other ones at some point but today that's the the VSA appliance that we provide into your V PC and you can use the Signet libraries or different applications that integrate with SafeNet HSMs so it's available in five regions around the world so it's kind of the where you are and more regions are on the way it's provided through a cloud formation template so the provisioning and deployment and getting it set up is done through cloud formation again it's back to automation and repeatability and not necessarily having humans do this there's notes in soft and and you know SDKs and all kinds of things to help you integrate your own applications with it or their software that goes and with it as well so I include it's included in our DSS controls as well as the stock compliance packages as well so it's audited the way we provision it and deploy it is audited by third parties using for database encryption so using it as a crypto provider for sequel TDE Oracle TDE you can set them up to use the cloud HSM as the crypto provider for the key that's like the database key and then it when the database is at rest it boots up you authenticate to the cloud HSM it decrypts the database key and then launches the database so both of those integrate with with Oracle and sequel and the master key is an HSM SafeNet provides an ecosystem and a suite of software that goes on top of their HSM device it provides protect v and virtual key store and cloud HSM stores the master keys for these so this is what you would use to encrypt files or block devices so if you want to do at rest storage encryption but you want to do that within your ec2 instance for example you would do that I'm using a solution like this where you're not using the underlying storage fabric from EBS you're using something in your application like an agent redshift also supports using HSM as a back-end for the keystore so instead of using KMS you can actually have the each each block of data in redshift i think it's a 1 or 4 Meg block in redshift is encrypted with its own block key and that block key is encrypted to a key higher up in the hierarchy I believe it's a cluster key and you encrypt that key to a key that's managed in Cloud HSM so it's again it's that key hierarchy you don't need any software to do that so datin redshift you know it's a cloud scale database or data warehouse and allows you to encrypt your data at rest using a key that you control you can also build custom software applications so SafeNet provides pkcs 11 or the Java frameworks or Microsoft you know they you can use it as a crypto provider for those native api's there's code examples and things online and as well as from the safe 9 architecture and safe net documentation so instead of using our SDKs with kms that have you know client-side encryption or API calls built into the SDK you would use a safe net library so by comparison right what's the difference when would you use Cloud HSM versus when you use kms so code HSM you it's dedicated to you it's not a shared service it meets sips validation whereas kms is not there yet you control your keys and the application software that uses them completely we don't have access to the encrypted modules we don't manage any of that for you so there's trade-offs you still have to manage your own can you know key store and you have to manage your own key management infrastructure around it as well by comparison kms builds on the strong foundations of an ancient HSM foundation so the crypto modules behind the scenes are built in like HSMs or hardened security appliances we call them highly available and durable right so it's it's in every single region it's not an single AZ service as a regional service so it exists at an individual AWS region it allows you to easily encrypt your data across data us services and natively integrate with those behind the scenes so different models and depending on the level of control you want and the visibility that you need we have options so what are the different in comparison of a difference these are a lot of detail on the slide but really the the trade-offs here if you go from the left to the right of the spectrum right on premesis HSM where you control everything completely tends to cost a lot more money doesn't integrate with AWS services directly but it's completely yours right you're the only one who has access to that device or those keys somewhere in the middle it's got HSM so if you're willing to put it in the cloud and you want your data close to the HSM you have access if you know it's still an hourly price for the small upfront fee there's safety an API is in customer code the keys are used close to your workload and still you'll you are the only one who has access to those keys kms all the way on the right you know we manage the keys we generate them and store them and it's accessible through our SDKs but it's incredibly cheap so each master key that you create the service default keys are free so EBS s3 the ones that you would encrypt your data to by default if you didn't create your own customer manage key those come for free but beyond that if you create customer manage keys say the example I gave with critical and confidential and high class data for example or different different keys per application for example or per customer in some cases if you're running a SAS application you might want a different customer key for each of your customers those each cost a dollar per month and then you pay only for the crypto operations against them and it's an incredibly bunch of zeros behind a dot so it's a per you know tens of thousands of crypto operations like encrypting decrypting generating keys you pay a fraction of a cent per operation so more resources you know take a look at the key Management Service web page there's a very extensive white paper again highlighting the security controls and the engineering behind kms to provide you security assurances on how the keys are managed how the crypto modules are on our side are updated and secured from an organizational perspective as well as technology all the details on the partner network s3 client encryption libraries and then the security blog - I think between these these two talks a lot of the information that we've been talking about today regard to security will be announced on the security blog there's a lot of very helpful articles a lot of design patterns and architecture patterns as well as announcements like if we add a new compliance framework or if we you know launch a feature or service that has a security implication to it thank you very much

Channel: Amazon Web Services

Views: 75,676

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, Key, Key Management, Software, Technology, Data, System, Office, Security, Business, Information, Customer, Design, Computer, Solutions, Access

Id: uhXalpNzPU4

Length: 35min 15sec (2115 seconds)

Published: Fri Apr 10 2015