2. 2
What’s new at AWS?
Cloud Consumers / Cloud Adoption
Building Bulletproof Infrastructure
Q&A
Introduction to 2nd Watch
Lunch with 2W Insight Billing Application Demo
1
Agenda
2
3
4
5
6
3. 3
Our Mission
“The mission of 2nd Watch is to bring enterprise Cloud
technology to organizations of all sizes to enable cost and
technology efficiencies and power innovation.”
‣ Cloud Enablement
‣ Services (strategy, architecture,
build, migration and support) to
enable Cloud adoption
‣ Software to optimize
‣ Billing and Usage
‣ Demand Management
4. 4
2nd Watch Overview
2nd Watch Associates
‣ Microsoft Certified
‣ Virtualization
‣ Remote Desktop Services
‣ ITIL Certified
‣ CISSP
‣ Enterprise Experience
‣ Microsoft – Toshiba - IBM
‣ Continental Airlines
‣ Iron Mountain
‣ Ambassadors Group
‣ Production Hosting
‣ Security and Compliance
‣ Technical Competency & Reseller
‣ Excellence in Operations
‣ Customer Testimonials
‣ Technical Competency
‣ Office 365
5. 5
Microsoft and 2nd Watch
‣ Recognized for expertise in implementing Office 365
‣ # of seats, # of deals, customer references, etc.
‣ SharePoint Online
‣ Implementing complex O365
‣ Hybrid Environment (Part on-premise, part cloud)
‣ Single Sign on with existing Active Directory
‣ Advance archiving, legal compliance
6. 6
Strategy &
Roadmaps
Support
Services
Cloud
Assessments
Cloud
Architecture
Build &
Migrations
‣ Identify Need
‣ Formulate the Strategy
‣ Identify goals
‣ Identify all considerations
‣ Get team buy in
‣ TCO
‣ Hardware
‣ Applications
‣ Customer experience
‣ Personnel needs
‣ Contract negotiations
‣ Security
‣ Deep dive
‣ Operational toolsets
‣ High level diagrams
‣ POC
‣ Cost analysis
‣ Enterprise designs
‣ Architect for failure
‣ Build HA
‣ Seamless migrations
‣ Testing
‣ As Built detailed doc
‣ Performance optimization
‣ Cost optimization
‣ Managed services
‣ Account management
Core Offering: Full Lifecycle
Examples of starting points‣ Web Applications
‣ Batch Processing systems
‣ Content Management Systems
‣ Digital Asset Management Systems
‣ Log Processing Systems
‣ Collaborative Tools
‣ Big Data Analytics Platforms
7. 7
2nd Watch Cloud Migration Process
Deep
Dives
High Level
Design
(HLD)
Detailed
Design
(DLD)
Build
(Dev)
Data
Migration
User
Acceptanc
e Testing
(UAT)
Go-Live Optimize
Business
Requirements
1) Mockups
2) Environment
Designs
3) Data Flow
1) Wireframes
2) As Built
3) AWS Run-IT
Analysis
Project Builds Production
Data
User Sign/off Go Live! Start
maximizing
savings
Project Deliverables
10. Amazon Glacier for Long Term Archive
10
‣ Secure and Cost effective
Offsite data archiving
‣ Tape Replacement for backup
and recovery
‣ Long term digital preservation
for historical and digital
information
11. 11
2.9 Billion
Q4 2006
14 Billion
Q4 2007
40 Billion
Q4 2008 Q4 2009
102 Billion
262 Billion
Q4 2010
762 Billion
Q4 2011
905 Billion
1 Trillion
Peak Requests:
750,000+
per second
Total Number of Objects Stored in Amazon S3
The Scale of AWS: Amazon S3 Growth
12. 12
Other Recent “IT” Items
‣ Elastic Load Balancing – Internal to VPN
‣ Support for Static Routes for VPC VPN
• Enables non BGP Based AWS Supported VPN connection
‣ Provisioned IOPs
• Enables High Performance Databases
‣ Reserved Instance Marketplace
14. AWS Global Infrastructure
14
AWS Regions
AWS Edge Locations
GovCloud
(US ITAR Region)
US West
(Northern California)
US West
(Oregon)
US East
(Northern Virginia)
South America
(Sao Paulo)
EU
(Ireland)
Asia Pacific
(Singapore)
Asia Pacific
(Tokyo)
20. 20
Concern: How we address:
‣ AWS is a mystery
‣ Security
‣ Accessibility
‣ Control
‣ Cost
‣ All or nothing?
‣ Training and Certifications
‣ Shared Responsibility
‣ IAM, ACL’s, Logging, etc.
‣ You own the app!
‣ TCO support
‣ Hybrid Models
Common Concerns
26. 26
1. Infrastructure Security
SAS 70 Type II Audit
ISO 27001/2 Certification
PCI DSS 2.0 Level 1-5
HIPAA/SOX Compliance
FISMA Moderate
FEDRamp / GSA ATO
2. Application Security
Encrypt data in transit
Encrypt data at rest
Protect your AWS Credentials
Rotate your keys
Secure your OS and applications
3. Services Security
Enforce IAM policies
Use MFA, VPC, Leverage S3 bucket
policies,
EC2 Security groups, EFS in EC2 Etc..
1
2
3
In the Cloud, Security is a Shared Responsibility
How we secure our
infrastructure
How can you secure your
application and what is
your responsibility?
What security options and
features are available to you?
27. 27
Certifications
‣ SOC 1 Type 2 (Formerly SAS-
70)
‣ ISO 27001
‣ PCI DSS for EC2, S3, EBS,
VPC, RDS, ELB, IAM
‣ FISMA Moderate Compliant
Controls
‣ HIPAA & ITAR Compliant
Architecture
Physical Security
‣ Datacenters in nondescript
facilities
‣ Physical access strictly
controlled
‣ Must pass two-floor
authentication at least twice
for floor access
‣ Physical access logged and
audited
HW, SW, Network
‣ Systematic change
management
‣ Phased updates
deployment
‣ Safe storage decommission
‣ Automated monitoring and
self-audit
‣ Advanced network
protection
Built for Enterprise Security Standards
28. 28
Physical Security of Data Centers
‣ Amazon has been building large-scale data centers for many years
‣ Important attributes
• Non-Descript facilities
• Robust perimeter controls
• Strictly controlled physical access
• 2 or more levels of two-factor auth
‣ Controlled, need-based access
‣ All access is logged and reviewed
‣ Separation of Duties
• Employees with physical access don’t have logical privileges
29. 29
EC2 Security
‣ Host operating system
• Individual SSH keyed logins via bastion host
for AWS admins
• All accesses logged and audited
‣ Guest (a.k.a. Instance) operating system
• Customer controlled (customer owns
root/admin)
• AWS admins cannot log in
• Customer- generated keypairs
‣ Stateful firewall
• Mandatory inbound firewall, default
deny mode
• Customer controls configuration via
Security Groups
‣ Signed API calls
• Require X.509 certificate or customer’s
secret AWS key
30. 30
Amazon EC2 Instance Isolation
Physical Interfaces
Customer 1
Hypervisor
Customer 2 Customer n…
…
Virtual Interfaces
Firewall
Customer 1
Security Groups
Customer 2
Security Groups
Customer n
Security Groups
31. Network Traffic Flow Security
31
OSFirewall
AmazonSecurityGroups
Inbound Traffic
Headline: Always use VPC!
Encrypted
File System
Encrypted
Swap File
‣ Security Groups
• Inbound traffic must be explicitly specified by protocol,
port, and security group
• VPC adds outbound filters
‣ VPC also adds Network Access Control Lists
(ACLs): inbound and outbound stateless filters
‣ OS Firewall (e.g., iptables) may be
implemented
• Completely user controlled security layer
• Granular access control of discrete hosts
• Logging network events
32. Network Security Considerations
32
‣ Distributed Denial of Service (DDoS):
• Standard mitigation techniques in effect
‣ Man in the Middle (MITM):
• All endpoints protected by SSL
• Fresh EC2 host keys generated at boot
‣ IP Spoofing:
• Prohibited at host OS level
‣ Unauthorized Port Scanning:
• Violation of AWS TOS
• Detected, stopped, and blocked
• Inbound ports blocked by default
‣ Packet Sniffing:
• Promiscuous mode is ineffective
• Protection at hypervisor level
33. 33
AWS Customer Data on AWS
Data Security Example
‣ All storage devices follow process
• DoD 5220.22-M (“National Industrial
Security Program Operating Manual”)
• NIST 800-88 (“Guidelines for Media
Sanitization”)
‣ Upon decommission
• Degaussed
• Physically destroyed
‣ S3 data encrypted at rest
‣ No public interface to servers/data
‣ All Datacenter traffic is encrypted
‣ File System and/or database encryption
available as needed
34. Network Security Considerations
34
‣ Users and Groups within Accounts
‣ Unique security credentials
• Access keys
• Login/Password
• Optional MFA device
‣ Policies control access to AWS APIs
‣ API calls must be signed by either:
• X.509 certificate
• Secret key
‣ Deep integration into some Services
• S3: policies on objects and buckets
• Simple DB: domains
‣ AWS Management Console Supports User
log on
‣ Not for Operating Systems or Applications
• Use LDAP, Active Directory/ADFS, etc….
35. AWS Multi-Factor Authentication
35
‣ Helps prevent anyone with unauthorized knowledge of your e-mail address and password from
impersonating you
‣ Additional protection for account information
‣ Works with
• Master Account
• IAM Users
‣ Integrated into
• AWS Management Console
• Key pages on the AWS Portal
• S3 (secure Delete)
A recommended opt-in security feature!
36. AWS Security and Compliance Center
(http://aws.amazon.com/security/)
36
‣ Answers to many security & privacy questions
• Security whitepaper
• Risk and Compliance whitepaper
‣ Security bulletins
‣ Customer penetration testing
‣ Security best practices
‣ More information on:
• AWS Identity & Access Management (AWS IAM)
• AWS Multi-Factor Authentication (AWS MFA)
38. High Availability on AWS
38
‣ Plan for failure at any level
‣ Services within a Datacenter (AZs) can fail
‣ Regions are N+2 (minimum)
‣ Reserve capacity (the other side of Reserved Instances)
‣ Use AWS Services that scale across AZs
• -VPC, S3, ELB, RDS, etc.
‣ Chaos Monkey- now available
42. AWS Virtual Private Cloud
42
‣ Virtual Private Cloud (VPC) enables two important things:
• Local Subnet addressing
• Virtual Private Network (VPN) connections
‣ There are 4 possible VPC scenarios:
• Public Subnet Only
• Public and Private Subnets
• Public and Private Subnets with VPN
• Private Subnet Only with VPN
43. 43
Use VPC to add Capacity
Use AWS VPC to connect via IPSec VPN to your existing Datacenter
Users or
Customers
Customer Datacenter
VPN
EC2 Instances
EC2 Instances
Availability Zone 1
44. 44
Use VPC to host customer facing applications
Users or
Customers
Availability Zone 1
EC2 Instances
EC2 Instances
Availability Zone 2
VPN
Use AWS as a production hosting platform
Customer Datacenter
45. VPC = Additional Security
45
‣ Create an Access Control List (ACL) for EC2 Instances
‣ Create groups to manage types of servers
• Example:
- Website Tier
- Database Tier
‣ Use Network Security Groups to secure subnet traffic
• Example:
- Trusted
- Untrusted
46. 46
Connect your VPC via VPN
Corporate
Data Center
Corporate
Headquarters
Branch Offices
VPN Gateway
Internet Gateway
Availability Zone 1
Availability Zone 2
S3 SQS/SNS/SES SWF Elastic
Beanstalk
SimpleDB Dynamo
DB
Now
supports
static
routes!
47. VPC + Cloud Formation =
47
‣ Build your VPC, Security Groups, Instances, etc., and use
Cloud Formation to build out a template once you reach
Gold State
‣ Run Cloud Formation Template to replicate environment for
Dev, Test, Staging or other environments
‣ Makes your infrastructure build repeatable
‣ Use source control to track changes
49. Disaster Recovery on AWS
49
Classes of RTOs AWS Solution
‣ Critical-Real-time availability or near real-
time (minutes) – Tier 0 infrastructure,
critical apps
‣ Major- Applications to run the business
(hours) – Tier 1 infrastructure and apps
‣ Minor- Applications that can withstand a
longer downtime (hours- days)
‣ High Availability or Warm
Standby
‣ Pilot Light DR in AWS
‣ Backup and Recovery in
AWS
50. Other DR Considerations on AWS
50
‣ “SAN like snapshots” of EBS storage allow recovery to a
point in time within seconds – replicated across the entire
region (3+ datacenters)
‣ Autoscaling and scripting allow backup server to be fully
cost optimized
• Example: 2W Backup Server < $1 per month
‣ Pilot Light scenarios
51. HA Example
51
‣ HA at each tier
‣ Autoscaling at web and API tier to
suport dynamic site load
‣ High Data security requirements –
HA at IDS, Log Mgmt and auditing
tiers
‣ Can lose entire datacenter and
maintain production load
Notes:
53. Brian L Whitt
Senior Cloud Executive
Contact Us
2nd Watch, Inc.
Brian@2ndwatch.com
602-690-3880
www.2ndwatch.com
Product List
TCO
TCO.2ndwatch.com
tcosupport@2ndwatch.com
2W Insight
2WInsight.com
insight.support@2ndwatch.com
2W SharePoint
2WSharePoint.com
2wsharepoint@2ndwatch.com
SPOKANE AREA OFFICE
2310 N Molter
Suite 103
Liberty Lake, WA 99019
SEATTLE OFFICE
603 Stewart Street
Seattle, WA 98101
NEW YORK OFFICE
1350 Ave of the Americas
2nd Floor
New York, NY 10019
SAN FRANCISCO OFFICE
505 Montgomery Street
Suite 1037
San Francisco, CA 94111
Editor's Notes
South America, Sao Paulo region – Dec 2011 New Cache Edge Locations added
Security and Operational Excellence is the Top most priority. Its Priority 0. No exceptions allowed. We understand that Security and governance are often the top issues identified when we talk to our customers. Instead of tossing this over the fence, we really advice and highly recommend our customers to invest in security review early in the process. Get your security folks talk to our security folks and understand security and compliance. Security is really not on or off. It’s a spectrum of options that you can choose from that is right for your application.
Examining AWS, you’ll see that the same security isolations are employed as would be found in a traditional datacenter. These include physical datacentre security, separation of the network, isolation of the server hardware, and isolation of storage. AWS customers have control over their data: they own the data, not us; they can encrypt their data at rest and in motion, just as they would in their own datacenter. Amazon Web Services provides the same, familiar approaches to security that companies have been using for decades. Importantly, it does this while also allowing the flexibility and low cost of cloud computing. There is nothing inherently at odds about providing on-demand infrastructure while also providing the security isolation companies have become accustomed to in their existing, privately-owned environments.AWS is a secure, durable technology platform with industry-recognized certifications and audits: PCI DSS Level 1, ISO 27001, FISMA Moderate, HIPAA, SAS 70 Type II. Our services and data centers have multiple layers of operational and physical security designed to protect the integrity and safety of your data. Visit our Security Center to learn more http://aws.amazon.com/security/.Certifications and Accreditations: AWS has successfully completed a SAS70 Type II Audit, and will continue to obtain the appropriate security certifications and accreditations to demonstrate the security of our infrastructure and services. PCI DSS: We finalized our 2011 PCI compliance audit, publishing our extensive Report on Controls (ROC) with an expanded scope. Our new November 30, 2011 PCI Attestation of Compliance, a document from our auditor stating we are compliant with all 12 PCI security standard domains, is available now for customers considering or working on moving PCI systems to AWS. The new Attestation of Compliance document includes some key changes this year: This year we’ve added RDS, ELB, and IAM as in-scope services. The addition of these services is fantastic news for PCI customers since they can now leverage RDS to store cardholder and transaction data, use ELB to manage card transaction traffic, and rely on IAM features as validated control mechanisms that satisfy PCI security standard requirements. Consistent with last year, EC2, S3, EBS, and VPC continue to be in scope. Physical Security: Amazon has many years of experience in designing, constructing, and operating large scale data centers. AWS infrastructure is housed in Amazon-controlled data centers throughout the world. Only those within Amazon who have a legitimate business need to have such information know the actual location of these data centers, and the data centers themselves are secured with a variety of physical barriers to prevent unauthorized access.Secure Services: Each of the services within the AWS cloud is architected to be secure and contains a number of capabilities that restrict unauthorized access or usage without sacrificing the flexibility that customers demand. Data Privacy: AWS enables users to encrypt their personal or business data within the AWS cloud and publishes backup and redundancy procedures for services so that customers can gain greater understanding of how their data flows throughout AWS.“In essence, the security system of AWS’s platform has been added to our existing security systems. We now have a security posture consistent with that of a multi-billion dollar company.” - Jim Warren, CIO, Recovery Accountability and Transparency Board (RATB)
Physical SecurityAmazon has many years of experience in designing, constructing, and operating large-scale datacenters. This experience has been applied to the AWS platform and infrastructure. AWS datacenters are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access datacenter floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff. AWS only provides datacenter access and information to employees and contractors who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical access to datacenters by AWS employees is logged and audited routinely.
Amazon Elastic Compute Cloud (Amazon EC2) SecuritySecurity within Amazon EC2 is provided on multiple levels: the operating system (OS) of the host system, the virtual instance operating system or guest OS, a firewall, and signed API calls. Each of these items builds on the capabilities of the others. The goal is to protect against data contained within Amazon EC2 from being intercepted by unauthorized systems or users and to provide Amazon EC2 instances themselves that are as secure as possible without sacrificing the flexibility in configuration that customers demand. Multiple Levels of SecurityHost Operating System: Administrators with a business need to access the management plane are required to use multi-factor authentication to gain access to purpose-built administration hosts. These administrative hosts are systems that are specifically designed, built, configured, and hardened to protect the management plane of the cloud. All such access is logged and audited. When an employee no longer has a business need to access the management plane, the privileges and access to these hosts and relevant systems are revoked. Guest Operating System: Virtual instances are completely controlled by the customer. Customers have full root access or administrative control over accounts, services, and applications. AWS does not have any access rights to customer instances and cannot log into the guest OS. AWS recommends a base set of security best practices to include disabling password-only access to their hosts, and utilizing some form of multi-factor authentication to gain access to their instances (or at a minimum certificate-based SSH Version 2 access). Additionally, customers should employ a privilege escalation mechanism with logging on a per-user basis. For example, if the guest OS is Linux, after hardening their instance, they should utilize certificate-based SSHv2 to access the virtual instance, disable remote root login, use command-line logging, and use ‘sudo’ for privilege escalation. Customers should generate their own key pairs in order to guarantee that they are unique, and not shared with other customers or with AWS. Firewall: Amazon EC2 provides a complete firewall solution; this mandatory inbound firewall is configured in a default deny-all mode and Amazon EC2 customers must explicitly open the ports needed to allow inbound traffic. The traffic may be restricted by protocol, by service port, as well as by source IP address (individual IP or Classless Inter-Domain Routing (CIDR) block).
The HypervisorAmazon EC2 currently utilizes a highly customized version of the Xen hypervisor, taking advantage of paravirtualization (in the case of Linux guests). Because paravirtualized guests rely on the hypervisor to provide support for operations that normally require privileged access, the guest OS has no elevated access to the CPU. The CPU provides four separate privilege modes: 0-3, called rings. Ring 0 is the most privileged and 3 the least. The host OS executes in Ring 0. However, rather than executing in Ring 0 as most operating systems do, the guest OS runs in a lesser-privileged Ring 1 and applications in the least privileged Ring 3. This explicit virtualization of the physical resources leads to a clear separation between guest and hypervisor, resulting in additional security separation between the two. Instance IsolationDifferent instances running on the same physical machine are isolated from each other via the Xen hypervisor. Amazon is active in the Xen community, which provides awareness of the latest developments. In addition, the AWS firewall resides within the hypervisor layer, between the physical network interface and the instance's virtual interface. All packets must pass through this layer, thus an instance’s neighbors have no more access to that instance than any other host on the Internet and can be treated as if they are on separate physical hosts. The physical RAM is separated using similar mechanisms.
The addition of a host based firewall, such as iptables provides an additional customer implemented security which provides both ingress and egress filtering as well as allows for host based logging.
Network SecurityThe AWS network provides significant protection against traditional network security issues and the customer can implement further protection. The following are a few examples: Distributed Denial Of Service (DDoS) AttacksAWS Application Programming Interface (API) endpoints are hosted on large, Internet-scale, world-class infrastructure that benefits from the same engineering expertise that has built Amazon into the world’s largest online retailer. Proprietary DDoS mitigation techniques are used. Additionally, AWS’s networks are multi-homed across a number of providers to achieve Internet access diversity. Man In the Middle (MITM) Attacks All of the AWS APIs are available via SSL-protected endpoints which provide server authentication. Amazon EC2 AMIs automatically generate new SSH host certificates on first boot and log them to the instance’s console. Customers can then use the secure APIs to call the console and access the host certificates before logging into the instance for the first time. Customers are encouraged to use SSL for all of their interactions with AWS. IP SpoofingAmazon EC2 instances cannot send spoofed network traffic. The AWS-controlled, host-based firewall infrastructure will not permit an instance to send traffic with a source IP or MAC address other than its own. Port Scanning Unauthorized port scans by Amazon EC2 customers are a violation of the AWS Acceptable Use Policy. Violations of the AWS Acceptable Use Policy are taken seriously, and every reported violation is investigated. Customers can report suspected abuse via the contacts available on our website at: http://aws.amazon.com/contact-us/report-abuse/ When unauthorized port scanning is detected it is stopped and blocked. Port scans of Amazon EC2 instances are generally ineffective because, by default, all inbound ports on Amazon EC2 instances are closed and are only opened by the customer. The customer’s strict management of security groups can further mitigate the threat of port scans. If the customer configures the security group to allow traffic from any source to a specific port, then that specific port will be vulnerable to a port scan. In these cases, the customer must use appropriate security measures to protect listening services that may be essential to their application from being discovered by an unauthorized port scan. For example, a web server must clearly have port 80 (HTTP) open to the world, and the administrator of this server is responsible for the security of the HTTP server software, such as Apache. Customers may request permission to conduct vulnerability scans as required to meet their specific compliance requirements. These scans must be limited to the customer’s own instances and must not violate the AWS Acceptable Use Policy. Advanced approval for these types of scans can be initiated by submitting a request via the website at: https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/AWSSecurityPenTestRequest Packet sniffing by other tenantsIt is not possible for a virtual instance running in promiscuous mode to receive or “sniff” traffic that is intended for a different virtual instance. While customers can place their interfaces into promiscuous mode, the hypervisor will not deliver any traffic to them that is not addressed to them. Even two virtual instances that are owned by the same customer located on the same physical host cannot listen to each other’s traffic. Attacks such as ARP cache poisoning do not work within Amazon EC2 and Amazon VPC. While Amazon EC2 does provide ample protection against one customer inadvertently or maliciously attempting to view another’s data, as a standard practice customers should encrypt sensitive traffic.Configuration Management Emergency, non-routine, and other configuration changes to existing AWS infrastructure are authorized, logged, tested, approved, and documented in accordance with industry norms for similar systems. Updates to AWS’ infrastructure are done to minimize any impact on the customer and their use of the services. AWS will communicate with customers, either via email, or through the AWS Service Health Dashboard (http://status.aws.amazon.com/) when service use is likely to be adversely affected. SoftwareAWS applies a systematic approach to managing change so that changes to customer impacting services are thoroughly reviewed, tested, approved and well communicated. AWS’ change management process is designed avoid unintended service disruptions and to maintain the integrity of service to the customer. Changes deployed into production environments are: Reviewed: Peer reviews of the technical aspects of a changeTested: being applied will behave as expected and not adversely impact performanceApproved: to provide appropriate oversight and understanding of business impact Changes are typically pushed into production in a phased deployment starting with lowest impact areas. Deployments are tested on a single system and closely monitored so impact can be evaluated. Service owners have a number of configurable metrics that measure the health of the service’s upstream dependencies. These metrics are closely monitored with thresholds and alarming in place. Rollback procedures are documented in the Change Management (CM) ticket. When possible, changes are scheduled during regular change windows. Emergency changes to production systems that require deviations from standard change management procedures are associated with an incident and are logged and approved as appropriate. Periodically, AWS performs self-audits of changes to key services to monitor quality, maintain high standards and to facilitate continuous improvement of the change management process. Any exceptions are analyzed to determine the root cause and appropriate actions are taken to bring the change into compliance or roll back the change if necessary. Actions are then taken to address and remediate the process or people issue. InfrastructureAmazon’s Corporate Applications team develops and manages software to automate IT processes for UNIX/Linux hosts in the areas of third-party software delivery, internally developed software and configuration management. The Infrastructure team maintains and operates a UNIX/Linux configuration management framework to address hardware scalability, availability, auditing, and security management. By centrally managing hosts through the use of automated processes that manage change, the Company is able to achieve its goals of high availability, repeatability, scalability, robust security and disaster recovery. Systems and Network Engineers monitor the status of these automated tools on a daily basis, reviewing reports to respond to hosts that fail to obtain or update their configuration and software. Internally developed configuration management software is installed when new hardware is provisioned. These tools are run on all UNIX hosts to validate that they are configured and that software is installed in compliance with standards determined by the role assigned to the host. This configuration management software also helps to regularly update packages that are already installed on the host. Only approved personnel enabled through the permissions service may log in to the central configuration management servers.
AWS Identity and Access Management (AWS IAM)AWS Identity and Access Management (AWS IAM) enables a customer to create multiple users and manage the permissions for each of these users within their AWS Account. A user is an identity (within a customer AWS Account) with unique security credentials that can be used to access AWS Services. AWS IAM eliminates the need to share passwords or access keys, and makes it easy to enable or disable a user’s access as appropriate. AWS IAM enables customers to implement security best practices, such as least privilege, by granting unique credentials to every user within their AWS Account and only granting permission to access the AWS Services and resources required for the users to perform their job. AWS IAM is secure by default; new users have no access to AWS until permissions are explicitly granted. AWS IAM enables customers to minimize the use of their AWS Account credentials. Instead all interactions with AWS Services and resources should be with AWS IAM user security credentials. More information about AWS Identity and Access Management (AWS IAM) is available on the AWS website: http://aws.amazon.com/iam/
Amazon Account Security FeaturesAWS provides a number of ways for customers to identify themselves and securely access their AWS Account. A complete list of credentials supported by AWS can be found on the Security Credentials page under Your Account. AWS also provides additional security options that enable customers to further protect their AWS Account and control access: AWS Identity and Access Management (AWS IAM), Multi-Factor Authentication (MFA) and Key Rotation.AWS Multi-Factor Authentication (AWS MFA)AWS Multi-Factor Authentication (AWS MFA) is an additional layer of security that offers enhanced control over AWS Account settings and the management of the AWS Services and resources for which the account is subscribed. When customers enable this opt-in feature, they will need to provide a six-digit single-use code in addition to their standard username and password credentials before access is granted to their AWS Account settings or AWS Services and resources. Customers get this single use code from an authentication device that they keep in their physical possession. This is called Multi-Factor Authentication because two factors are checked before access is granted: customers need to provide both their username (Amazon e-mail in the case of the AWS Account) and password (the first “factor”: something you know) and the precise code from their authentication device (the second “factor”: something you have). Customers can enable MFA devices for their AWS Account as well as for the users they have created under their AWS Account with AWS IAM. It is easy to obtain an authentication device from a participating third party provider and to set it up for use via the AWS website. More information about Multi-Factor Authentication is available on the AWS website: http://aws.amazon.com/mfa/ Key RotationFor the same reasons as it is important to change passwords frequently, AWS recommends that customers rotate their access keys and certificates on a regular basis. To let customers do this without potential impact to their applications’ availability, AWS supports multiple concurrent access keys and certificates. With this feature, customers can rotate keys and certificates into and out of operation on a regular basis without any downtime to their application. This can help to mitigate risk from lost or compromised access keys or certificates. The AWS IAM APIs enables a customer to rotate the access keys of their AWS Account as well as for users created under their AWS Account using AWS IAM.
Amazon Web Services (AWS) delivers a scalable cloud computing platform with high availability and dependability, offering the flexibility to enable customers to build a wide range of applications. Helping to protect the confidentiality, integrity, and availability of our customers’ systems and data is of the utmost importance to AWS, as is maintaining customer trust and confidence. This document is intended to answer questions such as, “How does AWS help me protect my data?” Specifically, AWS physical and operational security processes are described for network and server infrastructure under AWS’ management, as well as service-specific security implementations. This document provides an overview of security as it pertains to the following areas relevant to AWS: Shared Responsibility EnvironmentControl Environment SummarySecure Design PrinciplesBackupMonitoringInformation and CommunicationEmployee LifecyclePhysical SecurityEnvironmental SafeguardsConfiguration Management Business Continuity ManagementBackupsFault Separation Amazon Account Security FeaturesNetwork SecurityAWS Service Specific Security Amazon Elastic Compute Cloud (Amazon EC2) SecurityAmazon Virtual Private Cloud (Amazon VPC)Amazon Simple Storage Service (Amazon S3) SecurityAmazon SimpleDB SecurityAmazon Relational Database Service (Amazon RDS) SecurityAmazon Simple Queue Service (Amazon SQS) SecurityAmazon Simple Notification Service (SNS) SecurityAmazon CloudWatch SecurityAuto Scaling SecurityAmazon CloudFront SecurityAmazon Elastic MapReduce Security
Multiple DNS TargetsLoad Balanced across Availability ZonesAuto-scaled web-cache servers with health checksAuto-scaled web-servers with health checksComprehensive config, data, and AMI backupMonitoring, alarming and logging