Amazon Web Services (AWS) dominates in public cloud adoption; 54 per cent of survey respondents reported running applications in the AWS cloud, more than four times the adoption rate of second-place Rackspace Public Cloud. The vast array of services offered by AWS is clearly compelling, but customers must understand that security remains mostly their own responsibility.
As the largest and perhaps most mature public cloud provider, AWS positions security as an area of shared responsibility:
“Under the AWS shared responsibility model, AWS provides a global secure infrastructure and foundation compute, storage, networking and database services, as well as higher level services. AWS provides a range of security services and features that AWS customers can use to secure their assets. AWS customers are responsible for protecting the confidentiality, integrity, and availability of their data in the cloud, and for meeting specific business requirements for information protection.”
In other words, AWS provides the infrastructure and tools, but it is up to the customer to use them to meet their security requirements. As a result, companies that make wise security decisions can take advantage of historically unprecedented computing capability, while those who fail to do so risk unprecedented disaster.
Perhaps the most dramatic example to date was 2014’s fatal hacking of Code Spaces. An intruder obtained Code Spaces’ AWS credentials, very likely by hacking Code Spaces itself, and accessed the company’s AWS account. “We finally managed to get our panel access back but not before he had removed all EBS snapshots, S3 buckets, all AMI’s, some EBS instances and several machine instances,” the company posted on its homepage. “In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted.”
“Code Spaces will not be able to operate beyond this point,” the company’s statement read, “The cost of resolving this issue to date and the expected cost of refunding customers who have been left without the service they paid for will put Code Spaces in an irreversible position both financially and in terms of ongoing credibility.”
There are two critical lessons for cloud customers: Credential management and backup strategy.
AWS provides a robust Identity and Access Management (IAM) framework. Upon account creation, customers have a single credential that provides unfettered access to all parts of the AWS console. Using that root account, customers can create additional accounts with passwords (for AWS console access) and/or keys for API access. Multi-factor authentication is available for console access, and granular access control policies can be applied to each account directly or via a group.
Sadly, some AWS customers simply create API access keys associated with the root account and configure those keys into applications. Simply put, they are inviting disaster.
AWS customers should create a root account with a strong, complex password and only use it when absolutely necessary. Adding a hardware authentication token (available from Amazon for US $12.99) and storing both the password and token in a physically secure location is highly recommended. API access keys should never be created for the root account.
Appropriate groups should be created for users and applications, and granular AWS IAM policies attached at the group level to implement least privilege. In addition to simplifying administration, an advantage of using groups is that they can be quickly tested by applying the group to a user account. For example, a group intended to allow an application access to a single S3 bucket can be assigned to a test user account and restrictions verified interactively through the AWS console.
User accounts should also be secured using multi-factor authentication. In addition to low-cost hardware tokens, free applications are available for most tablets and smartphones including Android, Blackberry, iPhone, and Windows Phone.
Each application requiring API access should have its own AWS user account with no password assigned. In other words, each application should have unique access keys associated with a unique AWS account. In addition to facilitating auditing and least privilege, this can limit the damage if an application is compromised and make it easier to update access keys on a regular basis.
Customers of cloud services should also carefully review their backup strategy and the risks involved. While the appropriate use of IAM may reduce the risk of an intruder deleting backups, cloud computing customers should seriously consider copying backups to a separate account or a different cloud provider. In addition to technical risks, it is important to mitigate risks such as contract disputes, unanticipated account closures, and the possibility that a cloud provider could suddenly cease operations.
The author invited AWS to provide comment for this article, but they declined, only providing links to their security documentation.
SAMSUNG GALAXY S8 PLUS
The Samsung Galaxy S8 Plus is a beautifully crafted smartphone with nearly no bezel, curvaceous in design and reflects a…
How to: Connect to Exchange Online Using Multi-Factor Authentication
Using PowerShell to manage your Microsoft cloud services like Exchange Online and using multi-factor authentication (MFA) separately is awesome. Using…