An individual-use computer, one without connections to any other computer, is the next most secure type. A computer whose connections exist only within a workgroup comes in next, and so on. The least secure computer is the one with outside connections. To use AWS, you must risk the security of your computer in a major way. Developers can quickly drive themselves crazy trying to keep these interconnected computers safe, but that’s part of the job description.
Getting the Amazon view of security
Given that even the best efforts on the part of any vendor will likely provide only moderate security, the vendor should maintain a proactive stance on security. Although Amazon spends a good deal of time trying to track and fix known security issues with its APIs, it also realizes that some vulnerabilities are likely to escape notice, which is where you come into play. Amazon has a stated policy of encouraging your input on any vulnerabilities you find.Be sure to read Amazon’s evaluation process. The process leaves room for Amazon to pass the blame for an issue onto a third party, or do nothing at all. Even though Amazon is proactive, you need to realize that you may still find vulnerabilities that Amazon does nothing to fix. As a result, security for AWS will always prove less than perfect, which means you also need to maintain a strong, proactive security stance and not depend on Amazon to do it all.
The most important thing you can do when working with a cloud service vendor such as Amazon is to continue monitoring your own systems for any sign of unexpected activity.Getting the expert view of security
As you work through your plan for using AWS to support your organization’s IT needs, you need to read more than the Amazon view of issues such as security. Expecting Amazon to tell you about every potential security issue isn’t unreasonable — it’s just that Amazon requires proof before it deals with an issue. To get the full security story, you must rely on third-party experts, which means that you have to spend time locating this information online. (A visit to this blog will help in this regard because updates for security issues are discussed).A recent story serves to illustrate that Amazon is less than forthcoming about every security issue. In this case, white-hat hackers (security testers) have managed to hack into a third party’s EC2 instance from another instance. After gaining access to the third-party instance, the researchers were able to steal the security keys for that instance. Amazon is unlikely to tell you about this sort of research, so you need discover it yourself.
The problem with many of these stories is that the trade press tends to sensationalize them, making them appear worse than they really are. You need to balance what you know about your organization’s setup, what Amazon has actually reported about known security issues, and what the trade press has published about suspected security issues when determining the security risks of using AWS as your cloud solution. As part of your planning process, you also need to consider what other cloud vendors provide in the way of security. The bottom line is that using the cloud will never be as secure as keeping your IT in house because more connections always spell more opportunities for someone to hack your setup.
The reality of Amazon security
What Amazon is willing to admit when it comes to security and what researchers are trying to convince you is the actual state of security for AWS are two views that are critical to your planning process. You also need to consider real-world experiences as part of the mix. The security researchers at Worcester Polytechnic Institute created a condition under which AWS could fail. However, it hasn’t actually failed in this way in the real world. The way in which AWS has actually failed is with its backup solutions.This story tells of a company that is no longer operational. It failed when someone compromised its EC2 instance. This isn’t a contrived experiment; it actually happened, and the hackers involved did real damage. So this is the sort of story to give greater credence to when you plan your use of AWS.
Another story relates how unexpected data dumps on AWS made third-party information available. In this case, the data included personal information garnered from police injury reports, drug tests, detailed doctor visit notes, and social security numbers. Given the implications of this data breach, the organizations involved could be liable for both criminal and civil charges. When working with AWS, you must temper the need to save money now with the need to spend more money later defending yourself against a lawsuit.
Employing AWS security best practices
Amazon provides you with a set of security best practices, and it’s a good idea for you to read the associated white paper as part of your security-planning process. The information you get will help you understand how to configure your setup to maximize security from the Amazon perspective, but even a great configuration may not be enough to protect your data. Yes, you should ensure that your setup follows Amazon’s best practices, but you also need to have plans in place for the inevitable data breach. This statement may seem negative, but when it comes to security, you must always assume the worst-case scenario and prepare strategies for handling it.Using the IAM Policy Simulator to check access
There is a wealth of tools you can use as a developer to reduce your risk when working with AWS. (Accessing most of these tools will require that you log into your AWS account.) However, one of the more interesting tools you need to know about now is the IAM Policy Simulator, which can tell you about the rights that a user, group, or role has to AWS resources. Knowing these rights can help you create better applications as well as lock down security so that users can rely on your applications to work, but within a safe environment.
Use the IAM Policy Simulator to discover how AWS security works.To use this simulator, select a user, group, or role in the left pane. You can select one or more of the policies for that user, group, or role and even see the JavaScript Object Notation (JSON) code for that policy. For example, the AdministratorAccess policy looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Essentially, this policy states that the user is allowed to perform any action using any resource. The Effect field can contain Allow or Deny to allow or deny an action. The Action field contains an asterisk (*) to show that all the actions come into play. Finally, the Resource field contains * to show that this policy affects every AWS resource.
To run a simulation against a particular user, group, role, or policy, you need to choose a service, such as Amazon Elastic File System. You can then select the actions you want to check or click Select All to select all the actions associated with the service. Click Run Simulation to complete the test.
Administrators naturally have full access to every resource.