AWS Summit Stockholm 2014 – T2 – Understanding AWS security
•
1 recomendación•1,593 vistas
The AWS cloud infrastructure has been architected to be one of the most flexible and secure cloud computing environments available today. In this session, we’ll provide a practical understanding of the assurance programs that AWS provides; such as PCI DSS Level 1, MPAA, ISO27001 and many others. We’ll also address the types of business solutions that these certifications enable you to deploy on the AWS Cloud, as well as the tools and services AWS makes available to customers to secure and manage their resources, and best practices on how to use them. The second part of the presentation features security best practices on how F-Secure built "Younited", a secure file-sharing service, on top of AWS.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a AWS Summit Stockholm 2014 – T2 – Understanding AWS security
Similar a AWS Summit Stockholm 2014 – T2 – Understanding AWS security (20)
Más de Amazon Web Services
Más de Amazon Web Services (20)
Último
Último (20)
AWS Summit Stockholm 2014 – T2 – Understanding AWS security
- 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Understanding AWS Security Carlos Conde, Head of EMEA Evangelism
- 2. Different customer viewpoints on security PR exec keep out of the news CEO protect shareholder value CI{S}O preserve the confidentiality, integrity and availability of data
- 3. Security is Our No.1 Priority Comprehensive Security Capabilities to Support Virtually Any Workload PEOPLE & PROCEDURES NETWORK SECURITY PHYSICAL SECURITY PLATFORM SECURITY
- 5. WHAT NEEDS TO BE DONE TO KEEP THE SYSTEM SAFE
- 6. WHAT WE DO WHAT YOU HAVE TO DO
- 7. SOC CONTROL OBJECTIVES 1. SECURITY ORGANIZATION 2. AMAZON USER ACCESS 3. LOGICAL SECURITY 4. SECURE DATA HANDLING 5. PHYSICAL SECURITY AND ENV. SAFEGUARDS 6. CHANGE MANAGEMENT 7. DATA INTEGRITY, AVAILABILITY AND REDUNDANCY 8. INCIDENT HANDLING
- 8. YOUR DATA IS YOUR MOST IMPORTANT ASSET IF YOUR DATA IS NOT SECURE, YOU’RE NOT SECURE
- 10. NETWORK SECURITY
- 11. “GAME DAYS” INSERT ARTIFICIAL SECURITY INCIDENTS. MEASURE SPEED OF DETECTION AND EXECUTION.
- 13. EVERY CUSTOMER HAS ACCESS TO THE SAME SECURITY CAPABILITIES CHOOSE WHAT’S RIGHT FOR YOUR BUSINESS
- 14. AWS SECURITY OFFERS MORE VISIBILITY AUDITABILITY CONTROL
- 15. MORE VISIBILITY
- 16. CAN YOU MAP YOUR NETWORK? WHAT IS IN YOUR ENVIRONMENT RIGHT NOW?
- 19. TRUSTED ADVISOR
- 26. AWS CLOUDTRAIL
- 27. You are making API calls... On a growing set of services around the world… CloudTrail is continuously recording API calls… And delivering log files to you
- 28. Security Analysis Use log files as an input into log management and analysis solutions to perform security analysis and to detect user behavior patterns. Track Changes to AWS Resources Track creation, modification, and deletion of AWS resources such as Amazon EC2 instances, Amazon VPC security groups and Amazon EBS volumes. Troubleshoot Operational Issues Quickly identify the most recent changes made to resources in your environment. Compliance Aid Easier to demonstrate compliance with internal policies and regulatory standards.
- 29. ‣ CloudTrail records API calls and delivers a log file to your S3 bucket. ‣ Typically, delivers an event within 15 minutes of the API call. ‣ Log files are delivered approximately every 5 minutes. ‣ Multiple partners offer integrated solutions to analyze log files.
- 33. PROTECT YOUR LOGS WITH IAM ARCHIVE YOUR LOGS
- 38. MORE CONTROL
- 39. AWS STAFF ACCESS ‣ Staff vetting ‣ Staff has no logical access to customer instances ‣ Staff control-plane access limited & monitored Bastion hosts, Least privileged model, Zoned data center access ‣ Business needs ‣ Separate PAMS
- 46. LEAST PRIVILEGE PRINCIPLE CONFINE ROLES ONLY TO THE MATERIAL REQUIRED TO DO A SPECIFIC WORK
- 47. USE AWS IAM IDENTITY & ACCESS MANAGEMENT
- 48. CONTROL WHO CAN DO WHAT IN YOUR AWS ACCOUNT
- 53. Amazon DynamoDB Fine Grained Access Control Directly and securely access application data in Amazon DynamoDB Specify access permissions at table, item and attribute levels With Web Identity Federation, completely remove the need for proxy servers to perform authorization
- 54. MORE CONTROL ON YOUR DATA
- 57. YOUR DATA STAYS WHERE YOU PUT IT
- 58. USE MULTIPLE AZs AMAZON S3 AMAZON DYNAMODB AMAZON RDS MULTI-AZ AMAZON EBS SNAPSHOTS
- 59. DATA ENCRYPTION CHOOSE WHAT’S RIGHT FOR YOU: Automated – AWS manages encryption Enabled – user manages encryption using AWS Client-side – user manages encryption using their own mean
- 60. ENCRYPT YOUR DATA AWS CLOUDHSM AMAZON S3 SSE AMAZON GLACIER AMAZON REDSHIFT AMAZON RDS …
- 61. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Younited by F-Secure The Social Cloud you can trust Santeri Kangas, F-Secure, CTO Content Cloud
- 62. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. F-SECURE OVER 25 YEARS OF DIDITAL SECURITY EXPERIENCE
- 63. WE ARE #1 IN SECURITY 155.1 Revenues MEUR Operating Profit MEUR Personnel 27.1 R&D Investments of Revenues 27 % 939 Pioneering technology year after year BLACKLIGHT DEEPGUARD ORSP LISTED ON NASDAQ OMX Consistently ranked among the best by AV-Test, AV comparatives and numerous 3rd parties
- 64. Operators Service partners and IT resellers Direct Consumers and Small & Medium-sized Businesses WE WORK WITH 200+ OPERATORS AND 6,000+ SERVICE PARTNERS Serving tens of millions of people in 40+ countries.
- 65. Security built in We defend your content 24/7 You are in control of your content Younited The Personal Cloud You Can Trust Safe and Private
- 66. Connects you’re data from all your favorite devices ..
- 67. .. and Other Clouds
- 68. • We are compatible with the European Union privacy framework • We operate under the Finnish implementation of the EU Data Protection directive • We do not perform profiling or marketing based on customer data • We give consumers the control over their data WE PROTECT YOUR PRIVACY
- 69. SECURITY = DESIGN PRINCIPLE • built by organization with high coding standards and process (BSIMM4) • is continuously audited and penetration tested by external security auditors • has defense model that is based on multiple layers and isolation • treats all incoming user data content as contaminated (malicious) • does not inherently trust infrastructure • does not employ an implicit trust relationship between services • is designed to fail securely and not disclose information when doing so • run’s processes with least privilege • security counter measures are designed to be easily verifiable
- 70. Younited Backend - Security Design • Principle: Invalid user input and its (mis)handling does not provide an attack vector • Data isolation: – Safe: Any data that is generated by the Younited platform – Sanitizable: Standard API are validated on input, and sanitized into safe formats – Exploitable: Any other user input must be parsed only in an sandbox environment. • Segregation: limits the scope of operations allowed for connecting systems: – API segregation – Network segregation – DAC segregation
- 71. Younited Deployment in AWS • F-Secure has VPCs in US, EU, APAC, and Sydney • All F-Secure services in AWS are deployed to VPCs • VPCs connected to F-Secure infrastructure through hardware VPN • Segregation of network through Public and Private Subnets • All Subnets deployed on all available Availability Zones • F-Secure services not exposed to internet all connections through ELB , (only long poll notification channel is exposed due to ELB limitation) • Each F-Secure service has its own Security Groups • Each node type deployed with leased privileges in IAM – Instance Profiles • Encrypt all file objects with file specific encryption keys prior storing to S3
- 72. Subnet Design Principle Public Network Facing Subnet Internal Network Subnet Stateless Nodes ELB Outbound HTTP-Proxy Notification Service S3 access nodes API frontends Workers Cloud Agregation Statefull Nodes NA DDS Monitoring
- 73. The Nicest Security Feature in AWS IAM Instance Profiles • Controls what AWS API can be made from the machine with automatically provided short lifetime tokens. Removes need for storing API tokens on the nodes. • Each node type has its own least privileges instance profile = Combination of leased privileged role policies required by the node to do its duties. • Bound to virtual machine. Avoid system user account hustle with its security issues • Use cases example – Described instances for Service discovery to find other services in the deployment – Stop instance of same type for failover situation – Only data front end can access the encrypted data content on S3 (put/get/list permissions) • (CON) Since each node has profile for certain node we can only run one node per VM => over spending of nodes $$$
- 74. Younited Built In Security • All end-user content is processed in a secure sandbox • All files are scanned, regardless of the file type to prevent the malware spreading through the system • Malicious files are quarantined and user access to these contaminated files is limited • Platform access auditrail - monitored by Infosec department • Host based firewall (for extra protection inside Security Groups) • HIDS running on all nodes • VM images build by F-Secure • Network based Vulnerability Scanning
- 75. Secure Content Processing Architecture User content include unintentionally malicious files. Touching these files is dangerous without proper safety mechanism. Files are touched only after known anti-malware and anti-spyware detection heuristics is executed. All content file operations are run in a secure sandbox. Hardening by F- Secure Anti-Malware Laboratories Without this attacker could get straight to the core of the content platform.
- 76. The social cloud you can trust Thank you Santeri Kangas
- 77. MORE AUDITABILITY MORE VISIBILITY MORE CONTROL
- 78. “Based on our experience, I believe that we can be even more secure in the AWS cloud than in our own data centers” Tom Soderstrom – CTO – NASA JPL
- 80. AWS SECURITY WHITEPAPERS RISK & COMPLIANCE AUDITING SECURITY CHECKLIST SECURITY PROCESSES SECURITY BEST PRACTICES
- 81. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Understanding AWS Security Carlos Conde, Head of EMEA Evangelism Thanks!
Notas del editor
- You can run practices too on separate environments that you create from CloudFormation scripts. Put new sysadmins on the practice environment you temporarily created on AWS while you simulate all kinds of failures … and see how quickly they react.
- On AWS, small developer has same security as big company. No price change for security. You get the same access for security. Financial sector Pharmaceuticals Entertainment Start-ups Social media Home users Retail
- Security for us is all about these three elements – visibility, auditability and control. Everything we talk about today will fall into those major categories, and as you can guess, they build on each other. Without knowing what you have, where, etc., you can’t audit your environment against best practices, your own internal standards, or any of the multitude of certifications that our customers require us to adhere to. Controls are all about enabling you to place precise, well-understood limits on the access to your information. These controls may take the form of traditional perimeter, network, or virtual machine firewalls or ACLs, or they may be newer, more finely-grained controls that focus on constraining access to individual data elements. Did you know, for example, that you can define a rule that says that “Tom is the only person who can access this data object that I store with Amazon, and he can only do so from his corporate desktop on the corporate network, from Monday-Friday 9-5 and when he uses MFA?” That’s the level of granularity you can choose to implement if you wish.
- you can’t protect what you don’t know about. You can’t protect what you do know about without knowing the specifics of their exposure, network rules, OS running, users, who did this. Basic questions: what do you have? What do you know is in your environment right now? Some folks get nervous because they have no idea, others come up with outdated visio diagrams, or complex inventory tools they run once a year. With AWS, you can tell about every thing you have running in your environment: every instance, volume, snapshot, firewall rule … and with APIs, you can run that as often you want. Every minute if needed.
- AWS allows you to see your ENTIRE infrastructure at the click of a mouse Can you map your current network? Also, you can do that automatically via the API, as many times as you need.
- Even better than the ability to know at any time what you have and what is your current setup, we also have a tool that makes recommendations based on your current configuration on AWS
- Going back to our classic 3-tier web application example …
- … security groups can help me define which components of my architecture can talk to which ones. Here, even the end user can’t access the web servers. The security group of the web servers only allow incoming traffic from the load-balancer. Also, the web application server only allows incoming traffic from the web servers and the database only allows incoming traffic from the application server.
- Any tentative of direct access other than what we defined is rejected.
- It’s also a good practice to restrict SSH access, even from sysops.
- To allow maintenance access, a sysop can connect to the production system via a bastion host, which logs all the actions made by the operator. The security groups of the web servers and application server only allow incoming SSH traffic from the security group of the bastion host…
- … which means that when the EC2 instance of the bastion host is stopped, no one can access the production environment. You can require MFA device to access the console and start a bastion host.
- the premise is leave the least access consistent with a job. so if you think this we, in many companies the "sys admin" as rights to access every single system in the company. in fact their almost ways one of the largest vulnerability points, from an human attack prespective. if I got after your credentials, I compromise that individual that means I got access to every box in the company. we we believe in limiting the blast radius that any particular human is accessible to.
- We give you the tools to do the same: USE IAM (otherwise it’s like logging as root)
- Here’s a screenshot of the IAM console, showing the users.
- Data isolation All user input including file names, MIME types, date fields and of course the actual file contents may be processed only in execution environments that are explicitly designed to be safe, secure and isolated. (More of these below) Isolation levels All data can be classified into three categories: 1. Safe: Any data that is generated by FSIO, for example internal timestamps, file identifiers etc. 2. LRW (Low Radio active Waste): must be validated on input, and sanitized into safe formats if used in logging, for example. All LRW paths must be easily identifiable and auditable in code. 3. HRW (High Radio active Waste): can be opened (contents parsed) only in isolation environments. Everywhere else it must be handled as binary data stored in a container with warning Isolation sandbox environment HRW can be opened and its contents processed only in isolation environments. Any code running in isolation environment must be considered as exploitable. Any information coming out from an isolation environment must be considered as LRW or HRW. Thus, a video transcode itself is HRW. AV scan results are LRW. And so on. For specification of an actual isolation environment, see Worker Design document and its Worker Unit design. Segregation The system has “segregation” features, which limit the scope of operations allowed for various systems connecting to FSIO. Channel segregation refers to the network configuration, whereby different service types (Data, API, Provisioning, Ticketing) have different channels, in practice IP addresses. Technically, this is handled by load balancers (F5 in production, pound + varnish in development). API segregation means that each service type has unique URL namespace that is part of the service URL. For instance, Data service URLs start with /1_0_0/data/... etc. and that wrong name space cannot be used to access the various services. DAC segregation means that each service type has a unique DAC, and for all service calls this DAC may be used for that service type. The only exception is the provisioning DAC, which may be used to access any service type.
- Gaffer is a single instance per worker node that polls for new jobs, manages the worker processes and coordinates the tasks. This design allows reduced number of connections to the backend database. Workers communicate with Gaffer over Python multiprocessing.Queue:s. Worker Unit consists of a Head Worker and a Tail Worker. Head Worker is responsible for message reception, decoding, work setup and publishing work results. It communicates with the Gaffer and the tail worker. Head Worker does not process any file content from external, untrusted sources. Tail Worker is running in a Linux Container (lxc) sandbox, isolated from network and other processes, running on a read-only file system. The sandboxed tail worker is responsible for processing untrusted user files. Pool Directory is a common directory where all incoming and outgoing files are stored until they are fully processed. There is a pair of them, one on disk and one in tmpfs to alleviate SAN I/O load.
- You can find more details on everything I talked about on our security portal…