Understanding Security Best Practices on AWS Cloud

We often talk about Security on Cloud as a new and uncharted phenomenon but if we look closely “Cloud Security’ is no different than “On-Premise IT Security”. There are some differences though and one of the most important security aspect which changes from your “On-Premise IT” to “Cloud” is that “the Security on the Cloud is a Shared Responsibility“. Hence it becomes imperative for us to understand the responsibilities of both the provider and consumer,  eg: Web application security, SQL injections, phishing etc. are common for on-premise or cloud hosted applications.

1. Physical Security on AWS – AWS has a global infrastructure facility with a high level of physical security. This infrastructure is distributed in multiple Regions with Availability Zones (AZs). These AZs are physically separated and are designed as independent failure zones. Facilities are Controlled and Non-descript, access to which is need-based with two factor authentication. Developers can leverage this infrastructure to create fault tolerant and self healing applications.
2. Network Security – AWS network provides significant protection against traditional network security issues and the developers can implement further protection. Some of the network security features which AWS has are Distributed Denial of Service (DDoS) mitigation, 
   IP spoofing prohibited.
   IP scanning prohibited,
   Packet sniffing prevented,
   All API endpoints are protected by SSL. Please refer “AWS – Overview of Security Processes” for further details.
3. Security for Data – AWS offers accessibility of data stored on S3 via SSL encrypted endpoints, which helps developers to protect data in transit as well as at rest. AWS also takes certain steps while decommissioning of storage devices to ensure maximum data security, for example storage devices are Degaussed or Physically Destroyed (based on the type of device) before it’s moved out of any AWS region. So one can be assured that data even on a end of life hardware would not be exposed to unauthorized usage.
4. Operating System –  Multiple levels of security on Amazon EC2 is provided to ensure that data within EC2 cannot be intercepted by non-authorized systems or users.
   • Host operating system
     • Individual SSH keyed logins via bastion host for AWS admins
     • All access logged and audited
   • Guest operating system
     • User controlled at root level
     • AWS admins cannot log in
     • User-generated key pairs
     • Users still need to patch the operating system

• Patching works in the same way as in traditional operating systems
• EC2 Instance Isolation
  • Instances on same machine are isolated from each other via Xen Hypervisor
  • AWS firewall resides at the hypervisor layer

• Instance’s neighbors have no more access to that instance than any other host on the Internet
• Disk storage is virtualized
• Disk virtualization layer automatically resets every block of storage used by the user

• One user’s data is never unintentionally exposed to another

• Users can encrypt data on virtualized disks

• Maintain OS-level firewalls for additional monitoring and control 

• Keep operating systems and application libraries patched and up-to-date

• Actively manage your AWS environment to leverage all of the capabilities available
• Security Credential Management – AWS Indentity and Access Management (IAM) enables users to control and isolate resources. One can isolate resources by Environment (Dev / Prod / Test etc.), Line of Business, Customer etc. IAM allows to create, Identity and Access Management (IAM)
  • Users – Create users and provide permissions to access AWS services and resources. Assign individual security credentials (passwords, access keys and Multi-factor Authentication)
  • Groups – Are a collection of IAM users and can be granted permissions to access AWS services and resources
  • Roles – Defines a set of permissions for making AWS service requests, it allows to delegate access, to trusted entities (IAM Users across accounts, services like EC2) without having to share long term access keys
  • Temporary Security Credentials – is used with Mobile and browser-based applications, Consumer applications with unlimited users and Identity Federation to AWS APIs
  • Resource-Level Permissions for EC2 and RDS Resources – AWS has recently launched this, with this one can allow access to limited set of resources within a larger, multi-use EC2 environment.
• Logging – Operate host-based IDS/IPS (intrusion detection / prevention system) and regular auditing and monitoring,

• Extend your current management and logging tools to AWS environment
• Install logging tools and log to a separate, central location (e.g.S3)

Users can explore the following additional options to achieve a high level of security based on their application needs,

1. Use Appropriate Security Groups and
   Audit the state of entire environment using API calls – Regular calls via command line or API to determine which web-based infrastructure services are being used at any time, Store and compare over time and Track anomalies or non-governed usage
2. Virtual Private Cloud (VPC) – lets you provision a logically isolated section of the AWS Cloud, allowing the user complete control over virtual networking environment including selection of your own IP address range, creation of subnets, configuration of route tables and network gateways.
3. Regulatory Compliance Requirements – Users can also use materials and certifications provided by AWS, these security compliance come in handy to build on your own compliance requirement. Ex- PCI DSS compliance might be useful for you if you are working in the area eCommerce.

You might also want to read “6 Things you should know about Security on AWS Cloud“.

References

1. Security Best Practices on AWS
2. AWS Webinar Series: Security Best Practices on AWS
3. AWS Security Center