Shared Security Responsibility Model of AWS
Download as PPTX, PDF3 likes1,695 views
The document discusses the AWS Shared Responsibility Model for security, emphasizing the division of responsibilities between AWS and customers regarding cloud security. It highlights AWS’s role in managing physical infrastructure and security tools, while customers are responsible for securing their software, data, and access. Best practices for security, including the use of IAM, encryption, and DDoS prevention techniques, are also outlined to ensure applications remain secure in the cloud environment.
Shared Security Responsibility Model of AWS
- 1. AWS Shared Responsibility Model for Security Akshay Mathur @akshaymathu of @appcito
- 2. Let’s Know Each Other • Do you work with AWS? • Do you manage applications? • What are your goals while managing application? • Happy Users, Happy You (DevOps), Happy Servers 2@akshaymathu
- 3. Akshay Mathur • 16+ years in IT industry • Currently Product Manager at Appcito • Mostly worked with Startups • From Conceptualization to Stabilization • At different functions i.e. development, testing, release, marketing, devops • With multiple technologies • Founding Team Member of • ShopSocially (Enabling “social” for retailers) • AirTight Neworks (Global leader of WIPS) @akshaymathu 3
- 4. Ground Rules • Tweet now: #AWS @akshaymathu @appcito @AWSStartups • Disturb Everyone later • Not by phone rings • Not by local talks • By more information @akshaymathu 4
- 5. When an Application is Secure • Controlled Access to Application • Legitimate users are able to use the application • Illegitimate users are not able to use the application • No disruption of the service • Resilient infrastructure • Prevention from attacks • Secure Data • Secure communication • Secure storage @akshaymathu 5
- 7. Shared Responsibility of Security in Cloud @akshaymathu 7 Don’t worry! AWS is there We need to take care of this Not to worry! AWS is providing tools
- 8. Share Responsibility of Security in Cloud @akshaymathu 8 Don’t worry! AWS is there Understand the worries and manage with the help of partners Not to worry! AWS is providing tools
- 9. Don’t Worry! AWS is There
- 10. Security ‘of’ Cloud @akshaymathu 10 Don’t worry! AWS is there
- 12. What AWS takes care • AWS manages the security of the following assets: • Global facilities (regions, availability zones, edge locations) • Access to data centres • Physical security of hardware (compute and storage) • Network infrastructure • Attacks at layer 2 • Virtualization infrastructure @akshaymathu 12
- 13. @akshaymathu 13
- 15. @akshaymathu 15
- 16. Not to Worry! AWS is Providing Tools
- 17. Security ‘in’ Cloud with AWS Help @akshaymathu 17 Use tools provided by AWS to takes care of this
- 18. What AWS provides • Tools • IP firewall (Security groups) • Subnet management (Virtual Private Cloud) • Access to virtual resources (Identity and Access Management) • Elastic infrastructure (Auto Scale Groups) • Resources • So many best practices • AWS partner network @akshaymathu 18
- 20. Security Groups • Security groups are like IP firewall • Configure and attach proper security group at every level (VPC, Subnet, Instance etc.) • Create both inbound as outbound rules • Close all not-in-use ports • Use Bastion Host for managing infrastructure @akshaymathu 20
- 22. Top 10 AWS Security Best Practices • Disable root API access key and secret key • Enable MFA tokens everywhere • Reduce number of IAM users with Admin rights • Use Roles for EC2 • Least privilege: limit what IAM entities can do with strong/explicit policies • Rotate all the keys regularly • Use AWS Key Management System and store keys in CloudHSM • Use IAM roles with STS Assume Role where possible • Use Auto Scaling to dampen DDoS effects • Do not allow 0.0.0.0/0 in any EC2/ELB security group unless you mean it • Watch world-readable/listable S3 bucket policies @akshaymathu 22
- 23. Think before you Do • Do not share access and secret keys with anyone • Watch if the access credentials are part of the code you are sharing @akshaymathu 23
- 24. AWS Shared Responsibility Model @akshaymathu 24
- 25. Understand & Offload the Worries! AWS has Great Partners
- 26. Share Responsibility of Security in Cloud @akshaymathu 26 Understand the worries and manage with the help of partners
- 27. Our Responsibility in AWS • Customer are responsible for the security of the following assets: • Software • Operating systems • Applications (servers, frameworks, tools) • Data and Access • Data (in transit as well as at rest) • Credentials • Policies and configuration • Application layer attacks • OWASP top 10 (XSS, SQL injection etc.) • DoS and DDoS • Malware • BOTs and BOTNets @akshaymathu 27
- 28. Securing Software • Start with known good base AMI • Pick LTS OS versions • Select a reliable provider • Pay attention to the software you install • Web/App Servers • Runtime environments • Libraries • Avoid installing development environment • Apply patches regularly • Write good code • Do not introduce vulnerability • Scan and Fix regularly @akshaymathu 28
- 29. Securing Data and Policies • Data in transit • Implement SSL for all communication • Over the internet • Within AWS network • Implement access policies • For users • For applications • For resources • Data at rest • Store encrypted data everywhere • S3 • EBS @akshaymathu 29
- 30. Avoiding BOT Traffic • Traffic from bad BOTs is about 30% • Amounts to 30% wastage of server resources • Various fingerprinting techniques are there for identifying the BOTs • IP reputation • UA analysis • Pattern analysis • JS insertion • Advance algorithms @akshaymathu 30
- 31. Preventing Data Theft • Typical ways are: • SQL/object injection • Cross Site Scripting (XSS) • File include • Malware inclusion • Exploiting vulnerabilities of coding, framework, language, platform • Scan the deployment regularly • Fix any vulnerability by applying patches • Use elastic Web Application Firewall (WAF) @akshaymathu 31
- 32. Preventing DDoS Attack • Volumetric attack • Many clients make connections with server • Clients send huge traffic to the server • Traffic is typically bogus • Prevention • Rapidly increase scale to consume connections/traffic • Rate limit connections/requests • Delay/Deny bogus traffic • Blacklist BAD clients • Protocol exploits • Attacker crafts traffic knowing the timeouts and limits of protocol • Slow moving bogus traffic hogs resources of server • Prevention • Setup policy to apply aggressive limits and timeouts in case of heavy load • Terminate connection when unusual behavior is observed • Blacklist BAD client @akshaymathu 32
- 33. @akshaymathu 33
- 34. 34@akshaymathu
- 36. Application Compliance in AWS @akshaymathu 36
- 37. Application Front-End Architecture CDN Custom Scripts, Rules, Alert Management Aggregation across instances • Spaghetti of point solutions • Multiple points of failure, redundancy difficult to setup • Not elastic and cloud native @akshaymathu 37
- 38. Application Front-End Architecture with CAFE CDN • All services for application under one consolidated product • Easy Activation of capabilities closer to application • Application policy is coordinated across services and policy enforced @akshaymathu 38 Availability Security Performance Continuous Deployment Appcito Cloud Application Front-End (CAFE)
- 39. Cloud Application Front End (CAFE) Taking Cloud Applications from Good to Great
- 40. Appcito CAFE Service Insights & Analytics Content Optimization Application Security & DDoS Prevention Unified Functionality Available As SaaS Delivery Simple Activation No Code Change For Dev /Ops Cloud-agnostic App Owner Elastic Continuous Delivery Availability & Elasticity
- 41. Typical Deployment Customer’s Cloud Customer’s End Users app server app server Load Balancer app server DNS Network Subnet Availability Zone
- 42. Deployment with CAFE Customer’s Cloud Customer’s End Users app server app server Load Balancer app server Appcito Cloud CAFE Barista Management, Control, Analytics DNS CAFE PEP Network Subnet Availability Zone
- 43. Purpose-Built Cloud Native Architecture • Scalable architecture decouples control plane (BARISTA) and data plane (PEP) • BARISTA provides centralized policy control, visibility and analytics. • PEP (Policy Execution Proxy) provides full proxy services for applications • Traffic Management / Load balancing • Application Visibility & Analytics • Application Security • System is DevOps Friendly • API Driven & Programmable • Integrates with DevOps tools & Processes @akshaymathu 43
- 44. CAFE Configuration Model • Think Out of the box (literally) • Think in terms of • Applications • Traffic flow • Request patterns • Forget about • Box provisioning • Box configuration • Networking flow • L2/L3 access control @akshaymathu 44
- 45. Application-Level Security Web Application Firewall (WAF) • Protects against common attack vectors • SQL Injection • Cross-Site Scripting (XSS) • Local and Remote File Includes • One-click protection for popular web applications • WordPress • Joomla • Drupal DDoS & BOT Mitigation • Maximize availability, even during attacks • Minimize impact on cloud computing resources • Analyze attack events with comprehensive metrics • osCommerce • vBulletin • Microsoft SharePoint
- 46. App & Traffic Metrics Appcito CAFE Service Capabilities 46 Availability Performance Security DevOps Advanced Load Balancing Content Switching Application Fluency Elastic & Self- Scaling Continuous Deployment Request Mirroring Request Replay Programmable Policies Per Application Control Front-End Optimization Optimization for client Caching & compression Predictive caching Application & Server offloading Application Firewall Elastic SSL Anomaly Detection DDoS BOT Protection Trends & Correlations Anomalies Detection Policy Recommendation Analytics & Insights
Editor's Notes
- #41: (RGB) R=1 G=66 B=135 (RGB) R=132 G=194 B=37