In AWS' HIPAA compliance docs they recommend not relying on their managed encryption services as they currently protect you from a legal standpoint but may not in the future (at least for RDS). Is AWS altering those guidelines and now going to say their encryption is good enough?
Isn't this true in general? This protects against someone walking into the datacenter and stealing a harddrive (which is Amazon's responsibility anyway).
If you want to be sure the data is encrypted, store encrypted values/blobs/files/etc is generally Amazon's stance (for instance, for S3). For S3 they call this "client side encryption".
So much cloud encryption is a total checkbox. As a security professional I sometimes don't have a clear threat model that the magic crypto is meant for.
With encryption at rest, you can basically make sure data can only be accessed from the main interface. Otherwise there are multiple ways to let data leak, e.g., sys admins, decommissioned disks, or other tools.
It's entirely feasible to mitigate a lot of that insider risk. You have to pick the convenience/risk reduction trade off, though. For example, it may make sense to disallow any unilateral access, and only allow signed, reviewed code to run. There doesn't have to be a single entity with universal root.
In such an environment, encryption at rest can come in handy because it mitigates some of the physical attack vectors.
In theory yes. In practice most of the tasks including key/password management is left on sysadmins anyway, because management don't bother and not even interested how this stuff works. They're just not technical people, their priorities are elsewhere. And that's ok.
Or enabling full-drive encryption without a password ... as long as you are using the default AWS-managed keys.
I don't make any real adjustments to my risk models until I enable customer-managed keys. At this point, the encryption is really facilitating a secondary access control mechanism audit mechanism. That said, these additional mechanisms can be quite effective when you know how to use them.
The problem for us is the mystery of everything that underpins the service. For managers, auditors, regulators, the tickbox allows us to get on with our jobs.
Thank you. I’m amazed so many here don’t get it. How are you guys building robust things? Maybe I’m too far along to see from the eyes of a novice, but why would anyone poo-poo default encryption at rest?! And as-a-service to boot!
The European public sector is moving into the cloud and we’re picking either Amazon or Azure.
Azure is really far ahead on security compliance with EU regulation, perhaps mostly on the image side of things though. But that’s important too, because when I ask our data protection officer and our lawyers which way to go, they point to Azure.
Which is great and bad. I really, really like Microsoft and Azure is awesome for .Net. Only we’re doing less and less .Net, and more and more of the development pool I have to chose from in hiring situations live in AWS.
Our main cloud will continue to run in Azure, because that’s where our 365 platform is, it’s where our IT crew is certified and Microsoft has been a good partner for decades. But I do want the option for us to use smaller software houses that are AWS only to develop minor systems that we operate in AWS ourselves as well. I think this will help AWS in that regard.
It's a bit of a concern that the only alternative Europeans really have are all american at a time where those are seen not so much as friendly by the public at large but the lesser of two evil when compared with what Alibaba is offering.
Almost everything they are doing could be lifted and shifted to generic VPS hosts, but no... everything has to be "cloud based", meaning they have to be rearchitected to accomodate the fragility and inherent flaws of that paradigm; namely that you have no control over your physical comms or who is accessing your hosts.
at large enough scale, VPS hosts are just as fragile. physical comms or access is really about the same on a cloud host as anywhere else. good luck getting something like IAM on a VPS provider. you can totally run off a VPS. as long as you have a server reliability team as good as a cloud service provider. and a management console as good as a cloud vm manager. and a way to grant access, and monitor, and grow on demand, and etc.
Indeed, which is why this CV padding "cloud migration" nonsense in various sectors I've seen is antithetical to the benefit of the business and entirely pushed by a need to transform for no particular reason, for the most part.
We killed the local datacenter a decade ago when we started renting iron to house our own cloud. The majority of our systems still operate on VMs in that setup, but even that is more expensive than going full Azure/aws. We don’t, because a lot of our legacy systems wouldn’t run in the full cloud and if we need a SQL cluster on our own internal network anyway, then we might as well use it. Though, we’re nearing the point where a DB cluster in Azure will be considered our own network.
Then there’s the stuff we can’t do, like spin up 5000 servers on demand. Say we train some ML to find something specific missing from millions and documents. With Azure we can call Microsoft and plan to execute this, and they’ll give us exactly the resources we need for exactly how long we need it, and you just can’t beat that.
So it’s a cost-benefit thing. By going Azure and AWS, we get to spend more money on our primary function, which isn’t IT.
It's not the ML itself, it's the ability to quickly store large amounts of data and troll through them in a few hours and then shut everything down and never use it again.
One example is the case files I told you about. It's basic image recognition really, but it's millions of poorly scanned pages. 10 years ago, we would've gone through it by hand, and it would've taken 8-12 full time employees 3 months to do it.
Now we can have one PHD student do a 2-3 month training project that he/she uses for their research, and we have an algorithm that can go through the case files in 5 hours, provided we rent enough iron to do so. With AWS or Azure that's not a big problem, depending on size you can do it on-demand, but we had to call Microsoft and prepare 5000 server instances when we did it. That was some years ago by the way, so maybe it's on-demand now. Anyway, they went through the case files in 5 hours, and had a lower error margin than our employees would have had.
After those 5 hours, you shut everything down. There is really nothing comparable to that. You can certainly do that without moving other things to AWS or Azure, like I said, but it's often the financially solid decision.
And what's the problem with it exactly? Our own internal network has been breeched more than once, our Azure instances have never been hacked.
If all you’re doing is hosting stuff on VMs, then yes you can do it on VPS hosts. But if you take advantage of the managed services and you do it correctly, you can save money on managing infrastructure and you can develop a lot faster.
The data is kept in Europe, Microsoft is especially accommodating in that regard, but with both AWS and Azure there are special plans that open up when your sector spend billions.
So not only is the data kept in Europe, it’s also kept on instances that are separated from the rest of AWS and Azure and we can physically visit our specific hardware in their data enters. Hardware which only runs our stuff.
This is one of the reasons we don’t use google, because they don’t offer this. I’d love to use firebase for instance, but not if I can’t be sure citizen data is absolutely safe.
The only threat in the room that makes sense is the rogue, disgruntled amazon employee.
One might hypothesize government auditors and warrants compelling raw disk contents to be turned over for criminal prosecution, but that scenario supposes that a government entity would lack the creativity to imagine options like arresting the root login user, and jailing them until they enter the root account password to offer access to the encrypted data at rest.
True and even this assumes a specific limited threat vector: eg. employee has access to storage volume but not encryption key, employee does not have ability to dump guest memory, employee has no backdoor mechanism to elevate permissions within account. We have no cast iron guarantees (other than trust) that these limiting controls are in place.
Encrypted storage protects a layer from every layer below it. It simplifies your defense model. It's pretty much always a good idea to do, but rarely something worth bragging about.
well, the term is at rest. so an index in memory is probably not encrypted, just as they decrypt the data to be send over the wire (also encrypted, e.g. via HTTPS, which I think the SDK uses under the hood).
this isn't a big deal since sensitive/user data usually is a terrible choice for a key. (you get hot spots.) but i'm sure there's someone out there using SSNs as a key...
They don't; DynamoDB is a partitioned document store. You can query for a range of a sorted key but it just gives you the documents in that range. And I'm a little fuzzy on KMS but I believe the entire table is encrypted with one key, so if they could do SUM(x) GROUP BY y if they wanted to take the scaling hit.
"You should ensure you have configured the SDK to reuse connections. Otherwise you will experience latencies from DynamoDB having to re-establish new KMS cache entries for each DynamoDB operation, and potentially have to face higher KMS and Cloudtrail costs. For example, to do this using the Node.js SDK, you can create a new https agent with keepAlive turned on. "
43 comments
[ 3.6 ms ] story [ 90.6 ms ] threadIf you want to be sure the data is encrypted, store encrypted values/blobs/files/etc is generally Amazon's stance (for instance, for S3). For S3 they call this "client side encryption".
It is like taping the key above the door lock. Access control to the door is the important part.
In such an environment, encryption at rest can come in handy because it mitigates some of the physical attack vectors.
I don't make any real adjustments to my risk models until I enable customer-managed keys. At this point, the encryption is really facilitating a secondary access control mechanism audit mechanism. That said, these additional mechanisms can be quite effective when you know how to use them.
Azure is really far ahead on security compliance with EU regulation, perhaps mostly on the image side of things though. But that’s important too, because when I ask our data protection officer and our lawyers which way to go, they point to Azure.
Which is great and bad. I really, really like Microsoft and Azure is awesome for .Net. Only we’re doing less and less .Net, and more and more of the development pool I have to chose from in hiring situations live in AWS.
Our main cloud will continue to run in Azure, because that’s where our 365 platform is, it’s where our IT crew is certified and Microsoft has been a good partner for decades. But I do want the option for us to use smaller software houses that are AWS only to develop minor systems that we operate in AWS ourselves as well. I think this will help AWS in that regard.
We killed the local datacenter a decade ago when we started renting iron to house our own cloud. The majority of our systems still operate on VMs in that setup, but even that is more expensive than going full Azure/aws. We don’t, because a lot of our legacy systems wouldn’t run in the full cloud and if we need a SQL cluster on our own internal network anyway, then we might as well use it. Though, we’re nearing the point where a DB cluster in Azure will be considered our own network.
Then there’s the stuff we can’t do, like spin up 5000 servers on demand. Say we train some ML to find something specific missing from millions and documents. With Azure we can call Microsoft and plan to execute this, and they’ll give us exactly the resources we need for exactly how long we need it, and you just can’t beat that.
So it’s a cost-benefit thing. By going Azure and AWS, we get to spend more money on our primary function, which isn’t IT.
One example is the case files I told you about. It's basic image recognition really, but it's millions of poorly scanned pages. 10 years ago, we would've gone through it by hand, and it would've taken 8-12 full time employees 3 months to do it.
Now we can have one PHD student do a 2-3 month training project that he/she uses for their research, and we have an algorithm that can go through the case files in 5 hours, provided we rent enough iron to do so. With AWS or Azure that's not a big problem, depending on size you can do it on-demand, but we had to call Microsoft and prepare 5000 server instances when we did it. That was some years ago by the way, so maybe it's on-demand now. Anyway, they went through the case files in 5 hours, and had a lower error margin than our employees would have had.
After those 5 hours, you shut everything down. There is really nothing comparable to that. You can certainly do that without moving other things to AWS or Azure, like I said, but it's often the financially solid decision.
And what's the problem with it exactly? Our own internal network has been breeched more than once, our Azure instances have never been hacked.
So not only is the data kept in Europe, it’s also kept on instances that are separated from the rest of AWS and Azure and we can physically visit our specific hardware in their data enters. Hardware which only runs our stuff.
This is one of the reasons we don’t use google, because they don’t offer this. I’d love to use firebase for instance, but not if I can’t be sure citizen data is absolutely safe.
I have built quite a few Azure services, most of which are written in Python or Java and running on Linux.
I also have plenty of .NET Core code running, but the non-.Net experience is just as good as the .NET one.
Is this supposed to be a differentiator?
Now .Net Framework on AWS is a completely different beast.
One might hypothesize government auditors and warrants compelling raw disk contents to be turned over for criminal prosecution, but that scenario supposes that a government entity would lack the creativity to imagine options like arresting the root login user, and jailing them until they enter the root account password to offer access to the encrypted data at rest.
Just because there are complex vectors doesn’t mean you give up on the basic ones.
This is a valuable thing, and for now, a differentiator.
That's a silly threat model, but it takes a long time for rules and regulations to catch up with realities.
https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...
this isn't a big deal since sensitive/user data usually is a terrible choice for a key. (you get hot spots.) but i'm sure there's someone out there using SSNs as a key...
Also, the cautionary note, as given https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
"You should ensure you have configured the SDK to reuse connections. Otherwise you will experience latencies from DynamoDB having to re-establish new KMS cache entries for each DynamoDB operation, and potentially have to face higher KMS and Cloudtrail costs. For example, to do this using the Node.js SDK, you can create a new https agent with keepAlive turned on. "
at-rest, in-transit, in-use
https://cloud.google.com/security/encryption-at-rest/default...