The Shared Responsibility Model for Security
A free video tutorial from Rick Crisci
VMware Certified Instructor, Virtualization Consultant
4.5 instructor rating • 29 courses • 114,094 students
Learn more from the full courseAWS Solutions Architect Associate 2020 with Practice Test
Everything You Need to Pass your AWS Solutions Architect - Associate Exam: Lectures, Labs, and a complete practice test!
13:35:31 of on-demand video • Updated September 2020
- Become an AWS Certified Solutions Architect with this course
- Use the included practice test with over 200 questions to pass the exam on your first try!
English [Auto] In this video we'll learn about the AWB W.S. shared responsibility model and we'll learn about how when you create an account in NWS you have certain responsibilities related to security and a W.S. has responsibilities as well so we're gonna break down the shared responsibility model that a W US utilizes to define those responsibilities. This means that certain aspects of security are going to fall under Amazon's umbrella of responsibility while others are up to you the customer so AWOL provides what's called security of the cloud. This relates to the physical security of Amazon's data centers to the secure retirement of old hardware the border firewall and other similar concerns whereas you have to provide security in the cloud the customer needs to ensure that their guest operating systems are patched and updated and hardened that you've created security groups to control what types of traffic are permitted and which are not. And that you're properly managing your identity and access management credentials also known as I am what you can also use to configure multi factor authentication a W.S. is also responsible for updates and antivirus on managed services. Now what a managed services is something that a W.S. has the administrative role on they're going to do things like patch the operating system. They're going to do things like minimizing the attack surface and you don't have to worry about those things. Some services that are managed services include already yes dynamo TB and redshift there are many others as well but you're still responsible for user access and account management and multi factor authentication is always recommended. AWB will also handle destruction of data on any decommissioned storage systems as well as the customer you'll be responsible to create your own virtual private cloud. When you sign up for an AWB account there is a default VPC or virtual private cloud that is automatically created for you but you don't want to use this for production workloads. So you'll create your own VPC and the purpose of the VPC is to isolate you from other AWB resources and give you controls like security groups and access lists if you use an unmanaged service like easy to that's a service where we are going to have full control of the operating system and as such it's up to us to keep it patched. It's up to us to install antivirus or maybe an operating system level firewall and even on managed services such as Amazon's S3 service for storage while it may be a managed service we're still responsible for securing that content. We can make an S3 bucket public or private. We can set up roles and permissions to control who can access the contents of that S3 bucket so that still falls under your responsibility from a network perspective will actually learn a lot in the VPC lesson woollen how you can establish a VPN from your on premise data center into a W S or establish a dedicated physical connection as well and a W.S. will provide you with protection against common attacks like distributed denial of service men in the middle attacks or IP spoofing so the starting point for any discussion on security within NWS is I am or identity and access management. So think about a security guard for example when you walk into an office building you have credentials that get you in. Maybe you present a driver's license or something like that once you present those credentials you're not given 100 percent uninhibited access to that building. You can't go and rewire the electrical closet or do things like that. That's kind of like I am. It's going to handle authentication which basically ensures that you have the appropriate credentials to access a W.S. resources. But once you're in we'll use I am the control users and the roles that those users are assigned that defines what permissions you actually have within that a account and this is a core concept of the certification exam. So I am provide you with user names passwords and permissions. It gives you the ability to establish multi factor authentication. You can even establish an identity federation with your on premise Active Directory installation as well. And it can also provide temporary access as well. So think about things like smartphone applications. We don't want to include I am credentials within those applications so this gives us a way to temporarily assign credentials as they are needed for those applications and then revoke those credentials after a defined period of time multi factor authentication is always recommended by a W.S.. So what we're going to do with MFA is we are going to ensure that anybody attempting to authenticate no one has something that they know a username and a password and also something that they physically have. That's the second factor of multi factor authentication. That's something that they physically have could be a dedicated physical MFA device. Here we see them call the hardware MFA device or it could simply be an application on their smartphone such as Google Authenticator and you'll see this all in the demonstration in the next video when we establish that account. We'll need to pair a virtual MFA device with our AWOL account. So again assume we're using Google Authenticator on our smartphone you'll launch Google Authenticator and you'll scan a QR code from your W.S. console and this will associate that smartphone with your AWOL account as an MFA device and it'll start presenting authentication codes within that Google Authenticator app. So now I can only get into my NWS account if I have my credentials and if I have physical possession of that smartphone so I am controls who what and where the users and groups defined who these are the people or the objects within a W.S. that can perform some sort of actions. The roles define where they can perform these actions we might want to give a user permissions on an S3 bucket but not give them permission to certain easy two instances. So we can define the scope of these permissions with an I am and the policy is defined what they can do. Can you create an easy to instance. Can you delete an easy to instance. What can you actually do. Once you're successfully authenticated and so here we see the configuration steps for I am that you'll see broken down in the next demo you'll go in you'll create your account and then the recommendation is to delete those root account access keys and actually NWS recommends that once you create an AWOL account that you never use that root account ever again the first thing you're going to want to do is lock up those credentials somewhere secure and create yourself and I am account and use that moving forward and then the next step will activate multi factor authentication on that route account and then we'll go ahead and start creating some I am users and using groups to manage those permissions. It's much easier to manage permissions at a group level than it is on an individual user by user basis.