3 ms·

Isn't the statement "Amazon doesn't have access to the data on the instance" totally wrong? How can you 'not have access' to the data on a VM you're personally

Isn't the statement "Amazon doesn't have access to the data on the instance" totally wrong? How can you 'not have access' to the data on a VM you're personally running? Your answer (3) makes sense, but wouldn't these people opt in to lift this limit? I can think of few such applications that someone would elect to run on Amazon without knowing it in advance. do people really do (4) on amazon's hardware? (instead of their own). In (5) are you saying that this, combined with (2) is not really possible for them technically? Why not? It just seems trivial to me. If there are false positives you could lift the restriction out-of-band (not with your normal credentials, like the 'atm card/pin' combination.) I know I would prefer to keep that protection in place, just as I keep my ATM daily limit in place.

dalke 12y ago
Amazon EC2 is HIPAA compliant. As such, it has specific restrictions in place. Quoting from http://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Final.pdf http://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Fi... : > For Amazon EC2, AWS employees do not look at customer data, do not have access to customer EC2 instances, and cannot log into the guest operating system. AWS internal security controls limit data access. Yes, since they have physical access to the machines, it's possible to get access. However, it's not designed with that in mind. Adding that capability would make it harder to be HIPPA compliant, which is something they want to do. Also, there's AWS GovCloud http://aws.amazon.com/govcloud-us/ http://aws.amazon.com/govcloud-us/ for government computing which has its own level of confidentiality. It's more expensive to have 3 different infrastructures than one. There are many whitepapers about running #3 on EC2. I think your lack of knowledge isn't a useful guide. As for (4), my own data system does about 40 million SHA2s during a database update.
- logicallee 12y ago
  Thanks (upvoted.) This was the answer to my question, thank you. It is interesting though that per the original write-up at https://news.ycombinator.com/item?id=8817299 https://news.ycombinator.com/item?id=8817299 "When I woke up the next morning, I had four emails from Amazon AWS and a missed phone call from Amazon AWS." So Amazon clearly did have some very clear fraud signals. I agree with you that my lack of knowledge isn't a guide, which is why I phrased it in the form of a question and asked HN. Your current comment is in fact the only actual (and perfectly sufficient) answer. --- EDIT: regarding 4), out of curiosity, if they could legally and were allowed to tell programmatically if miner proceses were running and stop these for you, would you want them to? [preauthorize them to check and not allow it unless/until you lift this]. I would do so personally, as an added measure of security simply due to the incentive people have to steal my keys for this reason, and the fact that as a practical matter it does happen - as in the write-up, in which a .gitignore was ignored. >so I installed the Figaro gem (a rails API key security gem), and trusted it to keep my API key off of git when I pushed. I opened the console and git push origin master to send the new version of my app, Shriek to Heroku. >Figaro pops up on the command line as usual, but this time instead of saying “created application.yml, created .gitignore” It just said “created application.yml”. It certainly sounds like something that could happen to me, or anyone, and does every day. but it sounds like you would not opt in to this? just curious.
  - dalke 12y ago
    Accounting signature changes - eg, starting a large number of machines - is different than inspecting the VM. That alone could be the source of the fraud signals. My software works with proprietary chemical structures. I would not want Amazon's scanners looking at it. I want to be able to tell potential customers/clients that it's secure. A signal for unexpected charges (based on past history), combined with a generous waiver policy, which seems to be the case now, is all I need.

dalke 12y ago

Amazon EC2 is HIPAA compliant. As such, it has specific restrictions in place. Quoting from http://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Final.pdf http://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Fi... : > For Amazon EC2, AWS employees do not look at customer data, do not have access to customer EC2 instances, and cannot log into the guest operating system. AWS internal security controls limit data access. Yes, since they have physical access to the machines, it's possible to get access. However, it's not designed with that in mind. Adding that capability would make it harder to be HIPPA compliant, which is something they want to do. Also, there's AWS GovCloud http://aws.amazon.com/govcloud-us/ http://aws.amazon.com/govcloud-us/ for government computing which has its own level of confidentiality. It's more expensive to have 3 different infrastructures than one. There are many whitepapers about running #3 on EC2. I think your lack of knowledge isn't a useful guide. As for (4), my own data system does about 40 million SHA2s during a database update.

logicallee 12y ago
Thanks (upvoted.) This was the answer to my question, thank you. It is interesting though that per the original write-up at https://news.ycombinator.com/item?id=8817299 https://news.ycombinator.com/item?id=8817299 "When I woke up the next morning, I had four emails from Amazon AWS and a missed phone call from Amazon AWS." So Amazon clearly did have some very clear fraud signals. I agree with you that my lack of knowledge isn't a guide, which is why I phrased it in the form of a question and asked HN. Your current comment is in fact the only actual (and perfectly sufficient) answer. --- EDIT: regarding 4), out of curiosity, if they could legally and were allowed to tell programmatically if miner proceses were running and stop these for you, would you want them to? [preauthorize them to check and not allow it unless/until you lift this]. I would do so personally, as an added measure of security simply due to the incentive people have to steal my keys for this reason, and the fact that as a practical matter it does happen - as in the write-up, in which a .gitignore was ignored. >so I installed the Figaro gem (a rails API key security gem), and trusted it to keep my API key off of git when I pushed. I opened the console and git push origin master to send the new version of my app, Shriek to Heroku. >Figaro pops up on the command line as usual, but this time instead of saying “created application.yml, created .gitignore” It just said “created application.yml”. It certainly sounds like something that could happen to me, or anyone, and does every day. but it sounds like you would not opt in to this? just curious.
- dalke 12y ago
  Accounting signature changes - eg, starting a large number of machines - is different than inspecting the VM. That alone could be the source of the fraud signals. My software works with proprietary chemical structures. I would not want Amazon's scanners looking at it. I want to be able to tell potential customers/clients that it's secure. A signal for unexpected charges (based on past history), combined with a generous waiver policy, which seems to be the case now, is all I need.