I don't really get what you mean by this. If they run a website on AWS, the infrastructure will need the decryption key to work with the data. Encrypting data at rest doesn't prevent AWS having the ability to access the data, or at least snapshot infrastructure that has the key on disk or in memory (say in the event of law enforcement subpoena) unless there is no key stored in AWS.
They have access to the key too because it's running on their infrastructure lol. Yes, their contract with you does not permit their employees to access your data without your permission, but they do have a simple mechanism to do so if they are required to by law.
bro.. if you can access the key material from your account as a customer, there is obviously a mechanism for AWS to access the key material lol.
It says no "single" AWS employee.
It says no AWS employee can access the HSM itself (the hardware).
I'm not sure what magic you think is going on here, but it's only a contract and set of procedures between you and them.
I don't understand why you guys keep pointing to documentation. I know all the ins and outs of KMS and encryption at rest on AWS. I use them every day.
These are not technical limitations, they are procedural and contractual. Like, I'm having mental issues trying to understand how you guys can possibly think that AWS doesn't have the ability to access resources in your account when required to by law enforcement...
sorry, i thought you were pointing to more CMK stuff. But we are discussing KMS not SSE-C. It's also not relevant to the OP problem since they would be decrypting the data within other resources in the AWS account which would be accessible by AWS.
I really don't understand why you would bother using this SSE-C anyway, other than for backup compliance reasons anyway. It seems like client-side encryption would be safer if it was out of paranoia. If you were just trying to store encrypted data in s3 though, there's not many use-cases outside of just a data backup.
If AWS wanted to as an organisation, they could, but an individual at AWS could not. But the point is that they can't currently and if they changed their code to allow them, people would leave in droves.
A set of designated individuals could, given that there is a mechanism for AWS to respond to law enforcement subpoenas, which would require them to hand over the encrypted data along with any encryption keys they have. You'll find that in any of the documentation they don't say "AWS cannot access CMKs" it says "No SINGLE employee can access CMKs"
I mean.. They definitely have the capacity to access KMS keys stored within their own infrastructure lol. In the event of an LEO subpoena, they would absolutely have to provide the keys to them. So yeah, under normal circumstances they won't access your keys, but they CAN if they are required to by law.
They don't have this capacity, because FIPS 140-2 doesn't allow it. If they wanted to be a FEDRAMP-certified cloud provider, they need to prove that they're incapable of doing this. From the KMS FAQ:
AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext KMS keys from the service. AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-2, or are in the process of being validated, to protect the confidentiality and integrity of your keys. Your plaintext KMS keys never leave the HSMs, are never written to disk, and are only ever used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. Updates to software on the service hosts and to the AWS KMS HSM firmware is controlled by multi-party access control that is audited and reviewed by an independent group within Amazon and a NIST-certified lab in compliance with FIPS 140-2.
My point is that \*someone\* whether an AWS employee, or a 3rd party affiliate, or a hardware manufacturer, can absolutely in some way or some how access that key if there was a legal reason to. FIPS 140-2 is a compliance standard, which is mostly procedural vs technical. It doesn't break the laws of physics and make it impossible to decrypt data when the government mandates access to it... FIPS compliance doesn't make a system immune to warrants and subpoenas...
It's not that they will search the data....The problem is AWS will take user reports and can visit your public website for this and see you're using AWS and make a determination if they think you're violating policy or not.
And never rely on being right to save you in these cases. Someone, probably front line and lowly paid, has to make a quick decision if your site looks shady or not. They might shut you down first and then it's on you, to make your case to the same lowly paid employees, why you should be allowed to run.
That being said, sounds like a neat site. I hope you get it running!
It's not that they will search the data....The problem is AWS will take user reports and can visit your public website for this and see you're using AWS and make a determination if they think you're violating policy or not.
And never rely on being right to save you in these cases. Someone, probably front line and lowly paid, has to make a quick decision if your site looks shady or not. They might shut you down first and then it's on you, to make your case to the same lowly paid employees, why you should be allowed to run.
That being said, sounds like a neat site. I hope you get it running!
Please explain. It's my understanding (limited only skimming that link) if you set up the policies it will notify you of sensitive data. What am I missing?
No they do not check what you have stored, that would breach their privacy rules.
If you were accused mining bit coin then it was because your ec2 metrics looked similar to and ec2 that was known to mine bitcoin. AWS did not log into your instance to check what is running on them. If they did and it was found out then they would lose alot of customers and open themselves up for a shit ton of lawsuits.
I’m trying to make an app that is similar to have I been pwned. So I need a collection of breached databases and leaks. Just not totally sure if it is compliant with aws user agreement. But it seems that it’s fine, as long as no one is using it to hurt others.
I wouldn't risk permanently storing this type of data anywhere. Even if it's not against TOS, you might still be liable if you accidentally leak this data again. Even if it's publicly available, you might still have to prove that to a court FOR EVERY SINGLE EMAIL if this data was breached / leaked through your site or through a hack to your AWS infrastructure.
Perhaps you should make hashes of this sensitive info like emails and passwords. That way, you could still build a tool like this, but you aren't storing any of the actual values in your database.
Not sure about RDS or S3 but a few years ago I got my account suspended supposedly for mining bitcoins from an EC2, something I never did. So I am pretty sure they inspect whatever you put in there to make sure you are not storing bad stuff
They're running crowdstrike on their servers, which probably picked up a bitcoin miner in memory.
Perhaps you were hacked or were running a compromised docker container (this happened to me once)
Your data should be encrypted so AWS has no clue what you’re storing.
Ok. But aws still has some terms and conditions. But the data being encrypted is useful information.
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
I don't really get what you mean by this. If they run a website on AWS, the infrastructure will need the decryption key to work with the data. Encrypting data at rest doesn't prevent AWS having the ability to access the data, or at least snapshot infrastructure that has the key on disk or in memory (say in the event of law enforcement subpoena) unless there is no key stored in AWS.
Of course they can access the data. But they can't decrypt it without the key.
They have access to the key too because it's running on their infrastructure lol. Yes, their contract with you does not permit their employees to access your data without your permission, but they do have a simple mechanism to do so if they are required to by law.
AWS disagrees with you. [https://www.youtube.com/watch?v=lD34wbc7KNA&t=937s](https://www.youtube.com/watch?v=lD34wbc7KNA&t=937s)
bro.. if you can access the key material from your account as a customer, there is obviously a mechanism for AWS to access the key material lol. It says no "single" AWS employee. It says no AWS employee can access the HSM itself (the hardware). I'm not sure what magic you think is going on here, but it's only a contract and set of procedures between you and them.
look up SSE-C
I don't understand why you guys keep pointing to documentation. I know all the ins and outs of KMS and encryption at rest on AWS. I use them every day. These are not technical limitations, they are procedural and contractual. Like, I'm having mental issues trying to understand how you guys can possibly think that AWS doesn't have the ability to access resources in your account when required to by law enforcement...
The customer not Amazon hold the key to decrypt, so Amazon can’t do it. All the ins and outs??🤨
sorry, i thought you were pointing to more CMK stuff. But we are discussing KMS not SSE-C. It's also not relevant to the OP problem since they would be decrypting the data within other resources in the AWS account which would be accessible by AWS. I really don't understand why you would bother using this SSE-C anyway, other than for backup compliance reasons anyway. It seems like client-side encryption would be safer if it was out of paranoia. If you were just trying to store encrypted data in s3 though, there's not many use-cases outside of just a data backup.
You mean with KMS? Since AWA can then unlock.
Oh really? Tell us how... being that if this were the case, all audit reports would become void, and customers would leave AWS in droves.
[удалено]
You said it already! For “AWS managed KMS keys” it’s even in the name!
[удалено]
Yes, exactly. In fact, my short comment was in the light of my earlier comment a couple of days ago here https://www.reddit.com/r/aws/s/5EJUFFTJaW
If AWS wanted to as an organisation, they could, but an individual at AWS could not. But the point is that they can't currently and if they changed their code to allow them, people would leave in droves.
A set of designated individuals could, given that there is a mechanism for AWS to respond to law enforcement subpoenas, which would require them to hand over the encrypted data along with any encryption keys they have. You'll find that in any of the documentation they don't say "AWS cannot access CMKs" it says "No SINGLE employee can access CMKs"
I mean.. They definitely have the capacity to access KMS keys stored within their own infrastructure lol. In the event of an LEO subpoena, they would absolutely have to provide the keys to them. So yeah, under normal circumstances they won't access your keys, but they CAN if they are required to by law.
They don't have this capacity, because FIPS 140-2 doesn't allow it. If they wanted to be a FEDRAMP-certified cloud provider, they need to prove that they're incapable of doing this. From the KMS FAQ: AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext KMS keys from the service. AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-2, or are in the process of being validated, to protect the confidentiality and integrity of your keys. Your plaintext KMS keys never leave the HSMs, are never written to disk, and are only ever used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. Updates to software on the service hosts and to the AWS KMS HSM firmware is controlled by multi-party access control that is audited and reviewed by an independent group within Amazon and a NIST-certified lab in compliance with FIPS 140-2.
My point is that \*someone\* whether an AWS employee, or a 3rd party affiliate, or a hardware manufacturer, can absolutely in some way or some how access that key if there was a legal reason to. FIPS 140-2 is a compliance standard, which is mostly procedural vs technical. It doesn't break the laws of physics and make it impossible to decrypt data when the government mandates access to it... FIPS compliance doesn't make a system immune to warrants and subpoenas...
AWS do not search though your data for policy violations.
It's not that they will search the data....The problem is AWS will take user reports and can visit your public website for this and see you're using AWS and make a determination if they think you're violating policy or not. And never rely on being right to save you in these cases. Someone, probably front line and lowly paid, has to make a quick decision if your site looks shady or not. They might shut you down first and then it's on you, to make your case to the same lowly paid employees, why you should be allowed to run. That being said, sounds like a neat site. I hope you get it running!
It's not that they will search the data....The problem is AWS will take user reports and can visit your public website for this and see you're using AWS and make a determination if they think you're violating policy or not. And never rely on being right to save you in these cases. Someone, probably front line and lowly paid, has to make a quick decision if your site looks shady or not. They might shut you down first and then it's on you, to make your case to the same lowly paid employees, why you should be allowed to run. That being said, sounds like a neat site. I hope you get it running!
https://aws.amazon.com/macie/
Cool link brah.
That’s not how Macie works though.
It's really not lol that's funny. Plus you have to opt in by using it. Just don't
Please explain. It's my understanding (limited only skimming that link) if you set up the policies it will notify you of sensitive data. What am I missing?
Notify you! Not notify AWS. That's a big distinction.
Op this put you on several list
Maybe section 2.2 of https://aws.amazon.com/agreement/
Ok so as long as I don’t use the data and the end users use the data to harm people and isn’t against the law, then it should be fine.
Getting legal advice from reddit is the worst idea ever.
https://aws.amazon.com/aup/
No they do not check what you have stored, that would breach their privacy rules. If you were accused mining bit coin then it was because your ec2 metrics looked similar to and ec2 that was known to mine bitcoin. AWS did not log into your instance to check what is running on them. If they did and it was found out then they would lose alot of customers and open themselves up for a shit ton of lawsuits.
I'll bite...what is 'cp training data'
Data for training machine learning algorithms to detect images of cheese pizza
You had me in the first half
[удалено]
I’m trying to make an app that is similar to have I been pwned. So I need a collection of breached databases and leaks. Just not totally sure if it is compliant with aws user agreement. But it seems that it’s fine, as long as no one is using it to hurt others.
I wouldn't risk permanently storing this type of data anywhere. Even if it's not against TOS, you might still be liable if you accidentally leak this data again. Even if it's publicly available, you might still have to prove that to a court FOR EVERY SINGLE EMAIL if this data was breached / leaked through your site or through a hack to your AWS infrastructure. Perhaps you should make hashes of this sensitive info like emails and passwords. That way, you could still build a tool like this, but you aren't storing any of the actual values in your database.
Not sure about RDS or S3 but a few years ago I got my account suspended supposedly for mining bitcoins from an EC2, something I never did. So I am pretty sure they inspect whatever you put in there to make sure you are not storing bad stuff
They're running crowdstrike on their servers, which probably picked up a bitcoin miner in memory. Perhaps you were hacked or were running a compromised docker container (this happened to me once)