Amazon EBS provides flexibility to manage the system environment and associated data for VMs, but one of its features…
* remove unnecessary class from ul
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);
* Replace “errorMessageInput” class with “sign-up-error-msg” class
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
function validateThis(v, form)
var validateReturn = urValidation.validate(v, form);
* DoC pop-up window js – included in moScripts.js which is not included in responsive page
window.open(this.href, “Consent”, “width=500,height=600,scrollbars=1”);
can expose users to significant security risks if they’re not careful.
Elastic Block Store, a virtual disk volume for EC2 instances, includes a snapshot feature that creates a bit-for-bit replica of the data on a volume at a set point in time. It’s a straightforward way to preserve EC2 state, clone a machine for testing and share EBS volumes with unmodified content. However, snapshot sharing can create problems if users allow open access to the general public. For that reason, it’s critical to be mindful of snapshot access controls for overall Amazon EBS security.
Amazon EBS security risks and snapshot basics
EBS snapshots are copies of virtual volumes that provide incremental backups of all blocks that have changed since the previous snapshot. They have the necessary block-level data and metadata to clone a new EBS volume for backup, disaster recovery or nondisruptive testing of an EC2 instance. That makes snapshots a useful tool, as well as a serious Amazon EBS security risk if it falls into the wrong hands.
Snapshots are an effective way to replicate data and applications, so AWS made them easy to share across accounts through either controlled or open access. There are legitimate reasons to make a snapshot publicly available, such as to use EC2 to verify bugs in open source software. Unfortunately, AWS makes it a single-click option, so it’s easy to unintentionally use this feature.
A Croatian cloud consulting company first highlighted the dangers — and surprising prevalence — of public EBS snapshots. One of its clients shared snapshots of Jenkins systems for remote use, which seemed like a risky idea, so the consulting company investigated the pervasiveness of such uncontrolled snapshot access. In short order, the consultants found more than 30 Jenkins EBS snapshots available in various AWS regions. It later automated and expanded the snapshot search and quickly found publicly available disk volumes containing genome sequences, web server Secure Sockets Layer certificates, AWS security credentials, API keys and proprietary source code.
AWS warns of these potential risks in its EBS documentation on snapshot sharing, which states that, when users publicly share snapshots, they give others access to all the data those snapshots contain, including previously deleted information. As such, users should only share snapshots with those who are authorized to see all snapshot data. Additionally, users can create a new volume, from an existing volume, that contains only the data they want to share.
Monitor and manage snapshot security
To avoid Amazon EBS security risks, limit snapshot access to particular AWS users. View the shared status of each EBS snapshot in AWS Management Console, and choose the Public Snapshots filter to see those that are public. Just navigate to the snapshots section of the console, and filter the public snapshots from the drop-down list. The following screenshot illustrates the UI.
Do not openly share EBS snapshots if they have held sensitive or nonpublic information at any time. Instead, configure access restriction based on AWS Identity and Access Management (IAM) credentials.
It only takes a couple steps to restrict EBS access:
- Select Private from the snapshot permissions UI.
- Type in the AWS account ID for the user you are sharing with.
- Repeat to share with multiple accounts.
It’s slightly more complicated to share encrypted snapshots. In the IAM console, add all shared AWS account IDs authorized to access the custom key used to encrypt the volume. This lets those users access the key to decrypt the volume. Encrypted snapshots are wise, since the owner can re-encrypt the volume with new keys and then revoke the original keys to block access even after a snapshot has been copied.
Dig Deeper on AWS security