Architecture for Security on AWS

Transcript

2. ARCHITECTURE FOR SECURITY ON AWS_
3. Empowering you to deliver more with the AWS Cloud Consultancy Engineering Support Training
4. THE TEAM_
6. Security Reliability Performance Efficiency Cost Optimization Operational Excellence https:/ /aws.amazon.com/architecture/well-architected/
7. Book your review with us after this event Funding of up to $5,000 per workload available.
8. WHO'S RESPONSIBLE FOR SECURITY IN YOUR ORGANISATION?_
9. WHO'S RESPONSIBLE FOR SECURITY IN YOUR ORGANISATION?_ YOU ARE
10. WHO'S RESPONSIBLE FOR SECURITY IN YOUR ORGANISATION?_ YOU ARE EVERYONE IS
11. ARCHITECTURE FOR SECURITY ON AWS_
12. 2018 STATE OF DEVOPS REPORT_ DORA "Low performers take weeks to conduct security reviews and complete the changes identified. In contrast, elite performers build security in and can conduct security reviews and complete changes in just days."
13. THE SCALE FACTORY WAY_ People First Match solution to workload Leverage the AWS platform Automate Iterate
14. LEVERAGE THE AWS PLATFORM_
15. 5 AREAS OF SECURITY_ Identity and access management Detective controls Infrastructure protection Data protection Incident response
16. IDENTITY & ACCESS MANAGEMENT_
17. GOOD IAM PRACTICE_ No access to the root account Unique credentials per person Create least-privilege policies
18. USE MFA_
19. FEDERATED IDENTITY_
20. Root Account OU: Developers Jon's Sandbox Salma's Sandbox SSO Security DeveloperRole SecurityAdminRole OperatorRole OU: Services Live Staging Trust Relationship Policy DeveloperRole Security Log Bucket Service Control Policy AWS ORGANIZATIONS_
21. CASE STUDY_
22. TEACH YOUR TEAMS AWS IAM
23. Instance App Instance Metadata Service 1 2 3 INSTANCE PROFILES_
24. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteObject", "s3:Put*", "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::*" ] } ] } LEAST PRIVILEGE?_
25. TEACH YOUR TEAMS AWS IAM
26. YOUR IAM MIGHT NEED WORK IF YOU_ Log in with the root account Have >1 identity for a single person Don't use roles for compute services Don’t enforce MFA Hard-code secrets in app config (or code!) Have IAM policies with *s in (too permissive) Use a lot of AWS managed IAM policies
27. DETECTIVE CONTROLS_
28. LOG EVERYTHING_ CloudWatch Logs CloudTrail VPC Flow Logs DNS Query Logs
29. USE THE LOGS_ ELK Stack / Vendor tools Queries with Athena Kinesis streams
30. AWS GUARDDUTY_
31. YOUR CONTROLS MAY NEED WORK IF..._ You're not logging anything / enough You're not alerting on important log conditions Alerts/notifications are noisy or ignored You're only using logs when debugging
32. INFRASTRUCTURE PROTECTION_
34. SECURITY GROUPS_ Default App1 App2
35. FINE GRAINED POLICIES_ KMS key policies S3 bucket policies SNS access control
36. DIRECT CONNECT_
37. AWS Shield DDoS Protection AWS WAF Web Application Firewall
38. AWS INSPECTOR_ Scans for network reachability Checks hosts against known CVEs Checks against CIS benchmarks Checks other security best practice Analyses app runtime behaviour
40. CASE STUDY_
41. WHAT ABOUT SERVERLESS?_
42. YOUR PROTECTION MAY NEED WORK IF..._ You have anything other than LB or NAT in public networks Your security groups are too permissive You mainly use CIDR network ranges in your SGs You're not protecting your application with WAF You're not actively scanning for vulnerabilities You're not checking your application dependencies' security
43. DATA PROTECTION_
44. CLASSIFY DATA_ Identify different data classification levels Use tagging of resources Use KMS keys per classification level Control principal access to keys & resources Consider tokenisation Use AWS Macie to look for sensitive data in S3
45. DATA AT REST_ Use service features to encrypt at rest Limit personnel access to data (IAM) Copy base AMIs with encryption
46. PROTECT SECRETS_ AWS Secrets Manager Temporary RDS tokens Parameter Store Control principal access with IAM (Vendor solutions)
47. DATA IN TRANSIT_ Use HTTPS listeners on load balancers Use HTTPS on CloudFront Use ACM for certificate management Use VPNs where necessary*
48. DATA BACKUPS_ Use per-service backup features Replicate to other regions Limit personnel access to backups
49. DATA PROTECTION MAY NEED WORK IF..._ Too many people have access to too much data You haven't thought about data classification You're not encrypting at rest You're not encrypting in transit You store secrets anywhere other than in AWS services You don't have complete backups You haven't tried restoring your backups recently
50. INCIDENT RESPONSE_
51. AUTOMATE RESPONSE_ Use CloudWatch events Send notifications with SNS Trigger actions (Lambda, Step Functions)
52. CLEAN ROOM_ Pre-install forensic tools Ensure security team shell access Automatically quarantine suspect nodes
53. RUNBOOK/ PLAYBOOK_ Document incident response for your team Ensure team members are on call Run regular incident drills
54. INCIDENT RESPONSE MAY NEED WORK IF..._ You can't remediate common incidents automatically You can't quarantine bad nodes for later forensics You don't have engineers on-call for security incidents Engineers don't know how to respond to on-call alerts You don't regularly practice incident response
55. TOO MUCH TO THINK ABOUT!_
56. LANDING ZONE_
57. LANDING ZONE_
58. LANDING ZONE_
59. LANDING ZONE_
60. CASE STUDY_
61. EVEN LANDING ZONE IS TOO MUCH TO THINK ABOUT!_
62. CONTROL TOWER_
63. WHAT'S NEXT?_
64. TODAY: ASK AN ARCHITECT_
65. TALK TO US ABOUT: CONSULTANCY TRAINING WELL-ARCHITECTED