When we consider cloud security we still focus on the same tenets of defense in depth and defense in breadth as in any traditional infrastructure. What this really means is that we consider holistically:
When we evaluate the security posture and define and manage risk we have to consider all these things. In terms of cloud adoption, security is still considered a major barrier.
This blog gives a high-level overview of the way AWS approaches cloud security, in particular the data at rest and data in transit; identity management; and availability features of your data stored in the AWS Cloud. Together these cover the traditional Confidentiality, Integrity, Availability (CIA) triad; as well as the privacy of your data, which is an overlapping principle that includes all aspects of the CIA triad. A good starting point for better understanding of cloud security and privacy is National Institute of Standards and Technology (NIST) Special Publication (SP) 800-144 and the Department of Defense Cloud Security Model (DoD CSM). From the AWS perspective, security of the Cloud is Amazon’s responsibility and security in the Cloud is the customer’s responsibility.
Data at Rest
Data in AWS is stored at block or object level. What you need to understand is that your data resides on virtual partitions/disks that tie back to the physical devices stored and maintained within AWS data centers. Storage you newly provision arrives to you sanitized per NIST 800-88 and DOD 5220.22-M. AWS provides customers reduced privilege access to disks above the Hypervisor and uses data firewalling– thus preventing access to other tenant’s data and eliminating the possibility of data leakage or extrusion from the logical VMs to underlying physical disks.
EBS volumes are block level storage (network attached storage) stored within an availability zone (think multiple highly available data centers) level of durability and resiliency. Simple Storage Service (S3) buckets are object level storage that span multiple availability zones, thus providing higher levels of data resiliency and durability. Glacier is AWS’s offering for long term storage and archiving. RedShift is a petabyte-scale data warehouse for doing massive data storage or utilizing data analytics such as Hadoop frameworks. All of these storage options support Advanced Encryption Standard-AES for data disk encryption; Glacier also supports storing checksums with data for verifying integrity.
Data in Transit
Here is where things can get a little more complicated. Within AWS, many services such as Relational Database Service (RDS), CloudFront, and S3 support Secure Sockets Layer (SSL) for Hypertext Transfer Protocol Secure (HTTPS) access- including using your own custom SSL certificates. If you have a hybrid cloud in which you are tying your on premise data center into an AWS Cloud then you have to consider data in motion from end to end – not just within the AWS Virtual Private Cloud (VPC) but also back to endpoints within your physical data center. This could involve compliance with secure tunnels (end to end encryption) or the ability to decrypt, evaluate, and re-encrypt packets traffic (e.g. packet inspection provisions of the Health and Human Services (HHS) Trusted Internet Connectivity (TIC)).
As mentioned, the customer’s responsibility includes security in the cloud and within their own on premise tenet data centers. This means you have to consider 3rd party solutions that protect your data while it is in transit within the cloud when not encrypted using SSL; or from the exterior of the cloud to within the cloud. Possible solutions include using dedicated Virtual Private Networks (VPNs) (either customer deployed or using AWS’s VPN), or an identity-based solution such as vCider, Certes Network, or Unisys Stealth Solution. When evaluating these solutions consider the ease of deployment, integration with identity management systems, and flexibility in deployment of components within or outside the AWS Cloud.
AWS Identity and Access Management (IAM) enables customers to use traditional user, group, and role definitions and security policies to control access to AWS services and customer deployed assets within the AWS Cloud. The policies permit fairly granular levels of access control. The use of roles and Security Token Service (STS) tokens allows for shorter duration access and implementing a Federation service. AWS also supports Active Directory through a connector or Simple Active Directory (AD) service. This allows you to consolidate your X.500 identity management infrastructure so that you manage users, groups, and roles through one common platform. You can also integrate your directory with an on-premise or cloud deployed X.509 infrastructure – including using on premise or AWS provisioned Cloud Hardware Security Modules (HSMs).
Availability from the AWS perspective is clearly differentiated between highly available, meaning no single point of failure but still unplanned downtime; and fault tolerant, meaning no unplanned downtime. AWS also distinguishes between the data durability, or what percentage of your data can you expect to lose over a given year; and data resiliency, or how effectively you have deployed redundancy and adequately scaled your environment for surges. S3, for example has a durability of 99.999999999% meaning you can expect to lose 0.000000001% of objects over a given year. You are more likely to win the lottery or get struck by lightning than to lose an S3 object.
As you grow your AWS infrastructure you need to think about the best ways to deploy services to support whatever Service Level Agreements (SLAs) you have in place governing availability. Think from the top down, in other words from the most available (AWS regions) and working down to availability zones. Some services are availability zone specific (e.g. subnets and Elastic Block Store (EBS) volumes); some are regional, such as S3; and others are global, such as Route53 and IAM.
In most cases an AWS Cloud deployment will involve integrating both on premise (traditional mixed environment data center(s)) and cloud-based AWS services and infrastructure. We have found the most effective security strategy is to adopt an identity-based approach to protecting the data in addition to maintaining a focus on protecting the surrounding infrastructure. The traditional viewpoints of, for example, signature-based malware protection; point to point IPsec-based encryption; and Layer 3 network rules/ACL-based lack the flexibility, administrative ease of management, and effective use of limited and shrinking budgets (both CAPEX and OPEX) to truly embed security in the full system lifecycle.
By instead focusing on reducing attack surfaces; deploying cryptographic keys based on in-place identity stores; and creating secure communities of people, processes, and systems you create a dynamic and rapid response infrastructure designed to evolve as new and unknown threats emerge.
This is admittedly an extremely rapid fire overview of considerations in securing your AWS workloads. The key takeaway is to think of security in the same way you always have, whether you are using a traditional datacenter or an AWS Cloud. You still need to secure your data and observe the same best practices and governance whether you are operating in a completely physical world or a completely virtualized world.