Application Security in the Cloud - Best Practices


Published on

RightScale Webinar: May 20, 2010 – This webinar presents security implementation for applications running in the Amazon Web Services (AWS) environment with the RightScale management platform, using best practices developed by HyperStratus. See the archived video at

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Betsy, transition to Ed
  • Control of information flows directly from ownership of the underlying platform.
  • Ubiquitous connectivity and mobility have broken location-centric security models and traditional perimeter strategies.
  • Ubiquitous connectivity and mobility have broken location-centric security models and traditional perimeter strategies.
  • Control of information is not dependent upon total ownership or fixed locations.Can exert control with combination of encryption/signatures, service level agreements, auditable security standards.
  • New model already understood for data links—VPNs outnumber dedicated lines.Can apply same logic to compute and storage resources: customers don’t need to own assets to assert security.
  • Effective security includes good processes and technologies to protect confidentiality, integrity, and availability. AWS ensures availability by providing multiple independent geographic locations for compute and storage. Amazon EC2 and Amazon S3 exist in three (soon four) geographic Regions; Amazon CloudFront offers 15 global distribution points.[click] In the US-East Region…
  • …there are four Availability Zones. Think of an AZ as a distinct data center, with its own set of power supplies and network connections. Multiple AZs provide for compute and storage redundancy within each geographic Region.
  • As much as geographically possible, we separate the AZs in distinct seismological areas and flood plains. We don’t want weather to be a concern.
  • In the US-West and the EU Regions
  • …there are two availability zones. This is our minimum requirement for any Region.
  • Depending on the service, we may move data between AZs within a Region…
  • …however we don’t automatically move any data between Regions to help you satisfy any local or national regulatory requirements. You must initiate inter-Region data transfer yourself, and this will flow over the public Internet.
  • Our facilities are nondescript, we don’t indicate what they are; this is one example where “security by obscurity” actually makes sense.
  • We require multiple levels of physical access control before approved personnel can enter any of our facilities, they receive time-limited tokens to access only the required equipment, and all actions are logged.
  • Depending on which service you use to store information, AWS will automatically replicate it. Amazon S3 and Amazon SimpleDB create multiple replicas of each object, stored in multiple AZs. Amazon EBS and Amazon RDS make multiple replicas in only one AZ. The ephemeral storage of an instance has no replicas—so don’t rely on it for durability.
  • We use the Xen hypervisor with some custom modifications. Most importantly, the code we add to the hypervisor implements the security group functionality. Every Amazon EC2 instance must be associated with a security group, which defines the traffic allowed into the instance by destination port number and source IP address. AWS manages the physical machines and the host operating systems. Each customer manages his or own instances (virtual machines).
  • Each service has a specific disk virtualization technology. For most of them, like Amazon S3, SimpleDB, and instance storage, a logical-to-physical block mapping is created across unused physical disk space. The virtualization technology permits you to read only the information you’ve written and nothing else.[click] For EBS, we zero out the disk blocks when you allocate a volume—this explains the delay between when you allocate the volume and it becomes available for use.Your data belongs to you, not to us. We have a specific policy prohibiting routine access of customer data by AWS administrators.In other services, the disk virtualization technology prevents you from accessing any data that you haven’t written. Plus, it immediately deletes the logical-to-physical block mapping when you terminate an instance or process, thus ensuring that the data stored there is irretrievable.
  • Amazon VPC allows you define compute instances that essentially live within your corporate network. You assign the IP addresses, and all traffic flows not directly over the Internet but through an IPsec tunnel mode security association defined between a gateway on your network and a gateway on our network. No one outside your corporate network has access to the instances. Your own security policies and technologies direct which traffic is allowed in and out.
  • Multifactor authentication helps protect your AWS account credentials and provides an additional level of security before services can be started or stopped or modified. Eventually you’ll be able to incorporate MFA into AWS-hosted applications.
  • The AWS Security Center is your one-stop shop for all things related to security and privacy information. Here you can find the most recent version of our security whitepaper and subscribe to our security bulletin feed.
  • It’s fashionable to bash encryption now, not sure why? It’s the best tool we have to protect confidentiality. AWS supports your use of encryption if you need it to satisfy regulatory or compliance requirements.
  • Extends credential-management best practices up to the application layer.Contrast to all-or-nothing situation otherwise
  • Get one of the Service guys to take a screenshot of running a script across all instances in an array.Bullet #2 – Tony’s notesSteve Riley was talking about key management in his portion of the webinar: specifically, about how key management is (and always has been) the hard part of crypto.It occurs to me that this is another area where RightScale's automation features facilitate good security. You can use the dashboard to inject key material into instances at boot time, making use of it without ever storing it on disk.For example, I might have a RightScript that mounts an encrypted EBS volume. One of the inputs would be the encryption passphrase; naturally, I would use a Credential to store this passphrase and I would bind it to the server's input. At boot time the server would phone home, receive the input, mount the volume and the input would then go away. The passphrase would never reside on disk or in user-space memory.
  • Try and update this graph so it’s more security focused
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.