- [Instructor] In this lecture we'll introduce the AWS Shared responsibility model. By the end of this lecture you'll have a general understanding of the AWS shared security model. Security is the highest priority of Amazon web services. Amazon web services has provided a secure cloud environment for customers for over 10 years, servicing over a million active customers. AWS manages dozens of compliance programs in its infrastructure. This ensures security best practices and also means that segments of your own compliance may have already been completed. As customers, it's important to understand our responsibilities in the shared responsibility model. These responsibilities are outlined in the AWS terms of use policy and it's important to review these terms before working with the platform to ensure that your data and applications are secure. Let's break the concept down first, so we're clear on the implications of the shared responsibility model. A simple way to think about the shared security model is that AWS manages the security of the cloud while we the customer are responsible for everything we do in the AWS cloud. So looking at the AWS responsibilities first, this covers their global infrastructure elements, regions, availability zones and edge locations. And also the infrastructure elements of their compute, storage, database and network services. AWS owns and controls physical access to their data centers where your data resides. This covers physical access to all hardware and networking components and any additional data center facilities. Essentially, AWS is responsible for the components that make up the cloud. Any data put into the cloud then becomes your responsibility, managed by AWS. So, moving on to your responsibility, and as I just mentioned, securing what goes into the cloud falls upon you. This covers both client and server side encryption and network traffic protection all the way up to the security of the operating system, network and firewall configuration. Followed by application security and identity and access management. Access management is an important distinction. While AWS manages access to the physical resources, access to any virtual services you run in AWS is controlled by you, managed by you. How much of this additional security you wish to implement is entirely your decision. What you choose may depend on the nature of your business or on existing controls you may already have in place, for example, it's up to you if you want to implement a firewall or network access control list, an ACL, to control access to your VPC or to set the encryption if you want to encrypt your data. The important point to remember is that while AWS provides many powerful security controls, how and when to apply them is not AWS's responsibility. Under the shared security model, that responsibility falls on us, the customer. Before going deeper into the responsibilities of each part of this relationship in the shared responsibility model, let's first clarify two concepts about services. There are two main types of services on AWS. Infrastructure services and managed services. Infrastructure services are where AWS provides you with hardware, compute, storage and networking resources that you can use anywhere you wish within the limits specified by AWS. An example of an infrastructure service is Amazon Elastic Computer Cloud, or EC2. You can do anything you want with an EC2 instance. You can deploy applications in multiple platforms. Or use it to configure a software VPN. However in this case, managing the EC2 instance is your responsibility. You're responsible for updating the operating system and an application running on your instance. And also the data that it produces. Another infrastructure service is Amazon Simple Storage Solution or S3 where you choose whether or not to encrypt your data. If and how to back up or archive your files and so on. In short, infrastructure services are completely under your control and require you to perform all the configuration and management tasks. Manage services, on the other hand, are the services that use the AWS infrastructure to deliver a well defined and specific service. You don't need to worry about the underlying system on which your service is running or the configuration details that make it run. A classic example of a managed service is Amazon's relational database service or RDS. We know the type of database engine we want to use. And we know that it's running on EC2 instances. But AWS handles all the management tasks to make it work including point in time backups, fail-over and replication. In fact, we can't even see the DB instances in the EC2 console. Dynamo DB is another example of a managed service. We only need to provision the throughput and we're ready to consume the service. Now that we've defined the difference between infrastructure services and managed services we can talk some more about the AWS security responsibilities. AWS is responsible for the global infrastructure meaning that they will operate to maintain their regions, availability zones and edge locations. They will manage their software and tools, operating system, virtualization software, storage replication, allowing them to deliver the services they promised you. AWS is also responsible for providing physical security for their infrastructure including fire detection, cooling, redundant power. AWS is also responsible for securely decommissioning and disposal of all hardware. The AWS infrastructure is designed and managed according to security best practices. However AWS does not allow customers to visit their facilities to check and audit their systems. Instead, they provide reports from third party auditors who have verified their compliance with many security standards and regulations. You can check for yourself at aws.amazon.com/compliance. These responsibilities apply to both infrastructure and managed services. We discussed AWS responsibilities for the infrastructure services in the previous slide. In that context, your responsibility as a customer is to provide security for the upper layers of the infrastructure which includes things like patching the operating system of your EC2 instances and configuring the security groups and network ACL to ensure that your network is open only for those who have access to it. For example, you're responsible for managing who can access your AWS account. If you need to share your AWS account with multiple users, you need to use the AWS identity and access management service or IAM to set up and provide secure access credentials for your users. Finally, you're the one responsible for all the data that you both produce and transfer to AWS. It's up to you to encrypt your data at rest and also your data in transit using either the tools provided by AWS or your own tools. When it comes to managed services, AWS will take care of a few tasks that normally would be your responsibility. They'll manage and configure the application platform and operating system as well as networking and configuration. It's important to be clear that it's up to you to provide all necessary logical access to the entities that are going to consume the service either via the networking tools like security groups, or through IAM permissions which we're going to explore in the next lecture. Note that for all types of services, you're the only one responsible for your data. Meaning that once you remove your data from AWS it's gone, even when you're working with durable storage services like S3. The AWS acceptable use policy is not part of the shared responsibility model. However it is an important component of AWS security so I'll quickly mention it. As a customer best practice, you need to check the latest versions of AWS terms of use and acceptable use policies on the AWS website. You can find a link to them in the support material for this course. The acceptable use policy states that no illegal, harmful or offensive use or content is allowed. This might include things like providing gambling sites or virus development for example. No security violations means that no unauthorized access, or unauthorized monitoring and data inception are allowed. No abusive email or messaging is allowed. This is self-explanatory. And no networking abuse is allowed, meaning denied of service attacks or intentional interference. But how about penetration testing? Is that allowed? I hear you ask. In other words will AWS allow you to launch simulated attacks against your own web services to test your vulnerabilities? The short answer is yes, however you'll need to request permission of AWS before launching your tests. In addition, testing is only allowed against certain services and they're also restrictions for the instance times that you can test. You'll find a link to the penetration test request form in the course notes. That brings to a close this lecture on the shared responsibility model. Thank you for your attention, I hope you found this useful. If you have any questions or comments please email us at support@cloudacademy.com

Lectures:

• AWS Security Fundamentals
• AWS Shared Responsibility Model
• Identity and Access Management
• Amazon Cloud Directory
• Inspector
• Web Application Firewall
• Security Overview