Can Amazon administrators make an AMI clone of my EC2, and then create a new pair of keys to access the clone of my EC2?
For technical discussion purpose only, not hinting that will actually happen due to Amazon in-house security/compliance processes are in force.
3 Answers
Can or will are 2 different options.
Imagine they were approached by the the highest security level of Govt regarding National Security.
What do you think would happen.
You need to use KMS EBS encryption. That is the requirement for HIPP, PCI complince and many other security best practices. And YES. It will be secure if you will apply encryption at rest, encryption in transit, VPC endpoints etc best security practices. If this is GOV related project you need to consider using AWS GOV cloud. they have 2 regions in US.
Please check AWS Artifact for SOC, Compliance information https://aws.amazon.com/artifact/
Recommend you this link where you can find certified services by compliance type https://aws.amazon.com/compliance/services-in-scope/
And definitely check this whitepaper https://aws.amazon.com/whitepapers/aws-security-best-practices/
Thanks for the compliance links.
Hi Richard,
The basic answer is ‘NO’ AWS staff could not ‘normally’ do this. Not without breaking all sorts of internal controls and policies (and possibly commercial contracts which could sink the company). The ‘Keys’ are strictly under your control. Even if they cloned the machine they couldn’t access it by "legitimate" means without the owners collusion.
However the BlackHats are very smart and well funded. And I think that is really what you are concerned about.
Also remember that Risk can never be discussed in absolutes. It is always RELATIVE to some other Option.
e.g.
NOT: Are your servers at risk in AWS ? That is a nonsense question.
The correct question is.
_Are your servers at more or less risk that if they were housed xxxxx ?_NOT: They need to be 100% protected from attack !
the correct statement is.
_The risk to the company is $########.
I am willing to spend X% of that a year to ensure that we are not compromised._(The $$ then define the range of achievable options. )
<span>So in the spirit of Relative risk....</span>
<font face="-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif">If you deploy a standard un-protected, un-hardened instance you can leave yourself **MORE** open to attack than if you take extra steps. From a technical perspective you want to make the Hardware / OS secure enough that a</font> brute <font face="-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif">force attack will be **less likely** to succeed that an infiltration attack or a social engineering attack.</font>
<font face="-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif">An approach is to discuss data security in terms of level of</font> **Compliance** <font face="-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif">they are looking for. Then follow AWS guidelines on how to achieve that. The use of a Compliance Framework take a lot of the fuzzy "my opinion vs. your opinion" out of it. If</font> they <font face="-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif">are super paranoid suggest that they</font> aim <font face="-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif">to achieve a PCI or HIPAA etc.</font> compliance. That will provide real goals, measurements, configuration, and testing requirements. (Then when they see the cost you can discuss a more reasonable target.)
https://aws.amazon.com/compliance/
From a technical perspective (and some are often stipulated in the compliance docs) you have a large range of approaches available:
* Encrypted EBS volumes with your generic account keys (quite secure)
* Encrypted EBS volumes with a range of key management option including privately managed keys.
* Generic AWs AMI
* Custom hardened AMI for the MarketPlace
* Custom hardened AMI by a private security consultant (and how do you know how trustworthy or safe from leverage they are)
* WAF & IDPS system to defend against infiltration attacks
* Strong access controls backed by monitoring and alerting for social engineering attacks
* .... and the list goes on. it all depends on the $$ value to the client ;-)
Rusty
Moderator & CoachThanks for the concept of relative risk.
As a coach, I might recommend first congratulating your client for adopting a security mindset. Then explore their scenario of Insider Risk as it applies more likely to their own environment first. What steps have they taken to address this? Possibly recommend a pentest to alert them to security as a journey not a silver bullet via encryption or anything else. Rusty’s suggestions to identify a compliance standard goal is great, and can be viewed as part of the risk education value add to your client. As AWS puts front and center, it is a SHARED responsibility model. Help your client adjust to a changed risk reality, and heads-up about clients who look at you as superman. Humility and kindness as we all face challenging times. The scenario your client described is not in the top hundreds of things to actually be concerned about. So, that’s the good news.
My customer would like the data to be absolutely secure (they are not outside US). If we use Imported key to encrypt everything, technically will that be secure (even when the highest security wants to see it)?