This course is focused on the details you need to know for the 20% of the Solutions Architect – Associate for AWS exam that covers data security. You will learn to recognize and explain platform compliance for AWS, and be able to both recognize and implement secure procedures for optimum cloud deployment and maintenance, including understanding the shared responsibility security model, and knowing what that looks like in practice.
- Recognize and explain the AWS shared security responsibility model
- Recognise and implement IAM users, policies and roles
- Recognize and explain how AWS enables you to protect data and rest and in transit
This course is for anyone preparing for the Solutions Architect–Associate for AWS certification exam. We assume you have some existing knowledge and familiarity with AWS, and are specifically looking to get ready to take the certification exam.
Basic knowledge of core AWS functionality. If you haven't already completed it, we recommend our Fundamentals of AWS Learning Path.
This Course Includes:
- 7 Video Lectures
- Everything you need to know about data security to prepare for the Solutions Architect–Associate for AWS certification exam
What You'll Learn
|Lecture||What you'll learn|
|Shared Responsibility Model||What's managed by AWS vs. customers|
|Identity and Access Management||How to use IAM to keep your data secure|
|Platform Compliance||Best practices for platform compliance|
|Data at Rest and in Transit||How to secure your data at rest and in transit|
|Identity Federation||Web identity federation|
|CloudFront Security||How to secure Amazon CloudFront|
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Imagine that you are creating a mobile social media app that's going to use Amazon S3 to store user-posted images and videos and Amazon DynamoDB to store user profiles and their posting history. Now we're going to need to make quite a few requests to Amazon S3 and to Amazon DynamoDB to do this and each one of those requests will need to be signed with AWS Access Key. Now, it's not advisable to store or pass keys and credentials in user requests and API requests so a design option here is to use temporary AWS security credentials using Web Identity Federation. You can do this by setting up a Federated Identity Role inside of IAM.
Here we are back in the IAM Console, under the Roles sub-tab. You'll recall there are three types of Roles. AWS Services Roles, which we use to grant our user access to her S3 Bucket, there's roles for Cross-Account Access where we can have one AWS account access another and there's roles for Identity Provider Access. With roles for Identity Provider Access, we can grant access to a web identity provider or create a single sign-on or grant API access to a SAML provider.
What's SAML, I hear you ask. Well SAML stands for Security Assertion Mark Up Language. And it is essentially an open-standed data format for exchanging authentication and authorization data between an identity provider and a service provider.
For our mobile social media app, we would use Web Identity Federation. Web Identity Federation means you don't need to manage user identities, so users of our app can sign in using a common identity provider such as Amazon, Facebook or Google or any other open ID connect compatible common identity provider.
So how will this Web Federation work? When the user connects to the app, they receive an authentication token. AWS then swaps that token for temporary security credentials that map to an IAM role that we create. That IAM role will have permissions to use the resources that we want in our AWS account. So using a common identity provider helps you keep your AWS account secure because you don't have to embed and distribute long-term security credentials with your application.
Another common use case for Identity Federation is corporate users who may want to manage AWS resources but who don't want to have to create a whole bunch of IAM users or add logging into the AWS console as an additional step every time they want to do something on AWS. So their ideal use case is to log into their corporate directory and then have a seamless access to the AWS console. Now we can do this using Single Sign-On on a SAML-compliant provider like Microsoft Active Directory embedded on their corporate network.
Let's just walk through how this might work. So first, the enterprise user accesses the identity broker application. Then the identity broker application authenticates the user against the corporate identity store. The identity broker application has permissions to access the AWS Security Token Service, or STS, make sure you remember that, to request temporary security credentials. The enterprise users can then get a temporary URL which gives them access to the AWS management console.
About the Author
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.