Securing The AWS Cloud, Steve Riley, AWS Events, April 2010
•
7 likes•5,646 views
Steve Riley, AWS Evangelist presents on Securing the AWS Cloud at the Enterprise event - San Francisco and Start-up event - Sunnyvale in April 2010.
![Securing the AWS Cloud Steve Riley [email_address] @steveriley @awscloud http://stvrly.wordpress.com](https://image.slidesharecdn.com/securingawscloudrileyapril2010-100421124349-phpapp02/85/Securing-The-AWS-Cloud-Steve-Riley-AWS-Events-April-2010-1-320.jpg)
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Securing The AWS Cloud, Steve Riley, AWS Events, April 2010
Similar to Securing The AWS Cloud, Steve Riley, AWS Events, April 2010 (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Securing The AWS Cloud, Steve Riley, AWS Events, April 2010
- 1. Securing the AWS Cloud Steve Riley [email_address] @steveriley @awscloud http://stvrly.wordpress.com
- 2. Amazon EC2 Amazon S3 Amazon CloudFront
- 5. Amazon EC2 Amazon S3 Amazon CloudFront
- 11. Amazon S3 Amazon SimpleDB Amazon EBS Amazon RDS Amazon EC2 ++ ++ ++
- 12. … … … AWS admins only SSH via bastions Audits reviewed Customer only Inbound flows Default deny Customer only SSH, ID/pw, X.509 Root/admin control Hypervisor layer Physical interfaces AWS firewall Customer 1 security groups Customer 2 security groups Customer n security groups Customer 1 virtual interfaces Customer 2 virtual interfaces Customer n virtual interfaces Customer 1 Customer 2 Customer n
- 13. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 / / / / / / / / / / / / / / / /
- 14. Web tier Application tier Database tier HTTP/HTTPS from Internet SSH/RDP management from corpnet SSH/RDP management from corpnet, vendor
- 15. ec2-authorize WebSG -P tcp -p 80 -s 0.0.0.0/0 ec2-authorize WebSG -P tcp -p 443 -s 0.0.0.0/0 ec2-authorize AppSG -P tcp -p AppPort -o WebSG ec2-authorize AppSG -P tcp -p 22|3389 -s CorpNet ec2-authorize DBSG -P tcp -p DBPort -o AppSG ec2-authorize DBSG -P tcp -p 22|3389 -s CorpNet ec2-authorize DBSG -P tcp -p 22|3389 -s Vendor
- 16. Your corporate network Amazon Web Services Cloud Your VPC
- 23. Thank you very much! Steve Riley [email_address] @steveriley @awscloud http://stvrly.wordpress.com
Editor's Notes
- 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. For additional protection… [click ] …you can also encrypt your data, if you wish. You’re free to choose whatever encryption tools you prefer. Remember, though, that key management is not a trivial task; if you lose your keys, there’s no way to recover your data.
- It’s possible to build virtual three-tier architectures in AWS with creative use of security groups. Conceptually, each tier’s group allows the required traffic from its higher tier and also any necessary management traffic.
- These seven API calls create the three security groups that define the three-tier architecture.
- 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.
- Permissions on buckets and objects are distinct—they don’t inherit. And remember that in some S3 documentation, the term “key” is used to refer to the name of an object inside a bucket.
- 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.
- 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.