Removing AWS Applications that access AMI's

I will be performing tests on AWS, but I'd like to remove as many programs that allow AWS to access their own AMI's as possible.  I am open to suggestions and lessons learned.
awakeningsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
I am thinking of reducing the attack surface or exposure. Hence you probably already know these.

A) Basic hardening of AMI - establish baseline first by removing/disabling the "unnecessary" e.g.
> Disable Password-Based Logins for Root,
> Disable Root Access,
> Remove SSH Host Key Pairs, Install Public Key Credentials
> Disabling sshd DNS Checks (can be Optional as w/o disabling, DNS resolution failures prevent all logins).

Other practices in avoiding common overlooks if one starts into bundling of AMI for further sharing.

-Threat: More than one bundle upload attempt in the same AMI, the shell history contains your secret access key.
 > Always delete the shell history before bundling.

-Threat: Bundling a running instance requires your private key and X.509 certificate.
 >Put these and other credentials in a location that is not bundled (such as the instance store).
 >Skip any directories and subdirectories (containing secret information to exclude in bundle).

-Threat: AMIs store the public key used to launch an instance with its SSH authorized keys file.
> Exclude the SSH authorized keys when bundling the image.

Ref - http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/building-shared-amis.html

B) Basic Access Control - via IAM policy to customise and restrict the access (who?), permission (what action?) and action (what resource limit esp in instance(s) launched?) to govern around your AMI ... I would not be most savvy but looks like tagging AMI is way to go to further granular control the access

Ref - https://blogs.aws.amazon.com/security/post/Tx2KPWZJJ4S26H6/Demystifying-EC2-Resource-Level-Permissions
awakeningsAuthor Commented:
These are good procedures.  Some are standard hardening for any environment.  I'm just looking for ways of getting AWS out of their own AMI.  These kinds of controls are not usually listed in hardening guides (that I have read).  I'll see if anyone else provides comments.  Thank you!  You will get points!
btanExec ConsultantCommented:
Noted with thanks. But pardon, I am thinking also,

C) Specific to tagging, though it is (viewed by most as) more of easier management to find and filter the multiple AMI one may have, it is useful likewise when applying consistent IAM policy into each running instance. Complexity is Security enemy, easier mgmt help in response when time breach really does happens.

D) Neglecting awareness of "holes"  is also a "no-no" esp prevalent for admin whom abides by the "if aint broken, don't fix it" mindset, not wrong but also not good practices. Keeping abreast and monitoring security feeds from AWS security bulletin (https://alas.aws.amazon.com/) for those obnoxious CVE "hole" are potential avenues that adversary can exploit to penetrate account or instance flawed platform (we want to keep it patched to latest where poss so new instance running is "fresh and clean") ...no matter how much ACL restriction we can put in (but we avoided typically otherwise it become totally unusable). Unfriendliness is (in fact) security perceived negative outcome (lose-lose). User will just go blanket for access control add any users into security group so as to lessen the operational aspects but open up a can of worms..

E) Review the storage of AMI and limit what can be snapshot. I foresee any form of access (after those hardening), the key is launching that instance and grab the data chunked out from it. If we make it harder, and maybe drilling into limiting each creation of snapshot with smaller root device storage/footprint, lesser volume attached and have encrypted volume to each AMI running (on top of those ACL stuffs)... it may help to reduce exposure.
With Amazon EC2 instance store-backed AMIs, each time you customize an AMI and create a new one, all of the parts are stored in Amazon S3 for each AMI. So, the storage footprint for each customized AMI is the full size of the AMI. For Amazon EBS-backed AMIs, each time you customize an AMI and create a new one, only the changes are stored. So the storage footprint for subsequent AMIs you customize after the first is much smaller, resulting in lower AMI storage charges.

During the AMI creation process, Amazon EC2 creates snapshots of your instance's root volume and any other Amazon EBS volumes attached to your instance. If any volumes attached to the instance are encrypted, the new AMI will only launch successfully on instances that support Amazon EBS encryption.....AMIs with encrypted volumes cannot be copied using the AWS Management Console. Instead, you must copy each volume's snapshot to the target region and create a new AMI in that region using the copied snapshots in the block device mappings.
Worst off is that if really any AWS apps does bypass and reach the AMI image, due to any insider, exploit holes of engine or base image left open, ACL misconfiguration, migrate data from encrypted volume out to unencrypted one mistakenly, the battle is lost but we can minimally shrink it to log and audit to trace back and contain the damages to measurable and expected outcomes. the isolation helps and also limit the cost incurred unnecessarily with multiple running long lived instances and growing storage.
When you launch an instance using the new AMI, we create a new Amazon EBS volume for its root volume using the snapshot. Both the AMI and the snapshot incur charges to your account until you delete them

Snapshots that are taken from encrypted volumes are automatically encrypted with the same volume encryption key used to encrypt the volume. Volumes that are created from encrypted snapshots are also automatically encrypted with the same volume encryption key used to create the snapshot. There is no way to directly create an unencrypted volume from an encrypted snapshot or vice versa. Public or shared snapshots of encrypted volumes are not supported, because other accounts would not be able to decrypt your data.

Just a few cents

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
awakeningsAuthor Commented:
Sorry about the slow response!  I thought this was in place!
btanExec ConsultantCommented:
no worries, it is the sharing that counts. thanks for sharing!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Security

From novice to tech pro — start learning today.