Your SlideShare is downloading. ×
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

AWS Shared Responsibility Model - AWS Symposium 2014 - Washington D.C.

774

Published on

The AWS Shared Responsibility Model (SRM) varies somewhat according to the type of AWS service involved, from infrastructure to container to abstracted services. In this session we will move beyond …

The AWS Shared Responsibility Model (SRM) varies somewhat according to the type of AWS service involved, from infrastructure to container to abstracted services. In this session we will move beyond the “hypervisor up/down” summary of the SRM and explore how the SRM works for services beyond EC2.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
774
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
36
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 AWS Shared Responsibility Model Deep Dive Mark Ryland Chief Solutions Architect / Worldwide Public Sector Team markry@amazon.com Garret Grajek ggrajek@secureauth.com Rishi Bhargava rishi@mcafee.com
  • 2. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Shared Responsibility Model • SRM key to understanding and operationalizing security in the cloud • Traditional “hypervisor up/down” division of responsibilities: a good starting place • Today let’s add additional concepts and nuances
  • 3. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Service Types • Infrastructure services • Container services • Abstracted services – Source: “AWS Security Best Practices,” Nov 2013, p7
  • 4. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Infrastructure services • Rich control of an “on-prem-like” capability • Separate control plane and data plane – Caveat: in some sense all services are “container” services: API driven external configuration and control • E.g.: Amazon Elastic Cloud Compute (EC2), Amazon Elastic Block Store (EBS), Amazon Virtual Private Cloud (VPC), etc.
  • 5. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Container services • Joint control with service layer over an on-prem- like capability • Separate control plane and data plane – Typically services deployed on EC2 • E.g.: Amazon Relational Database Service (RDS), Elastic mapReduce (EMR), Redshift, Elastic Beanstalk, OpsWorks, Elastic Load Balancing, etc. – Level and type of co-administration vary from service to service
  • 6. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Abstracted services • Network endpoints that responds to commands • Typically: unified control plane and data plane (although logically distinct operations) • E.g.: – Simple Storage Service (S3), Glacier, DynamoDB, SQS/SNS, CloudWatch, CloudFormation (unified control/data planes) – Route 53, CloudFront (distinct control/data planes)
  • 7. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Varying Responsibility Surface Area Infrastructure services Container services Abstracted services Configuration plus operation Configuration
  • 8. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Three More Dimensions of the SRM • Type of service – Infrastructure, container, abstracted • Security configurability – How many relevant knobs and dials? • Breadth of cross-service security impact – Will configuration impact be broad, or primarily local? • Potential for integration with on-prem security systems – Greater versus lesser potential for integration
  • 9. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Four Dimensions: Matrix Service type Abstract Container Infra Security configurability Low Medium High X-service impact Low Medium High Integration potential Low Medium High Increasing responsibility
  • 10. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Example #1: EC2 • Foundational infrastructure service • Lots and lots of security-related features; configuration and operation requirements • Major impact across services • Rich integration possible with on- prem security/management at OS and/or app level Service type Infra Security config High X-service impact High Integration potential High
  • 11. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #2: S3 • Powerful abstract service • Lots and lots of security-related features • Very foundational, used by many other services and apps • Some indirect integration via IAM; logs can be integrated with security tools Service type Abstract Security config High X-service impact High Integration potential Medium
  • 12. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #3: RDS • Popular service managing relational database engines – AWS is the OS and engine admin, customer is the database admin • Significant number of security- related features • Cross-service impact typically low • Can be integrated with broader database security tools Service type Container Security config Medium X-service impact Low ? Integration potential High
  • 13. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #4: DynamoDB • NoSQL database increasingly used across AWS solutions • Richly integrated with IAM – Row and column-level access control via IAM policies, policy variables • Some integration with security- related solutions via IAM – E.g., SAML, Web Identity Federation Service type Abstract Security config High X-service impact Low Integration potential Medium
  • 14. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #5: Elastic MapReduce • Managed Hadoop offering • Customer and EMR service are co-administrators of instances • Significant number of security knobs/dials • Generally, low cross-service impact – Unless utilized within Data Pipeline Service type Container Security config Medium X-service impact Low ? Integration potential Low
  • 15. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #6: CloudWatch • Foundational service, but… • Primarily read-only data (not counting alerts) • Not a lot of security knobs/dials • Low integration with security- related solutions – High integration potential with management solutions Service type Abstract Security config Low X-service impact Low Integration potential Low
  • 16. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #7: CloudTrail • Critical security-related service • Primarily read-only data • Not a lot of security knobs/dials • High degree of important integration with security-related solutions Service type Abstract Security config Low X-service impact High Integration potential High
  • 17. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 #8: IAM • Most critical security-related “service” • Operationally easy; config options rich, powerful, complex • High degree of important integration with security-related solutions Service type Abstract Security config High X-service impact High Integration potential High
  • 18. AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 AWS Government, Education, and Nonprofits Symposium Washington, DC | June 24, 2014 - June 26, 2014 Thank you! Mark Ryland Chief Solutions Architect / Worldwide Public Sector Team markry@amazon.com Garret Grajek ggrajek@secureauth.com

×