Security Summary


SAA-C03 Introduction
How IAM is used to securely manage access
IAM Features
PREVIEW10m 39s
Managing user identities with long term credentials in IAM
Creating IAM Users
Using IAM policies to define and manage permissions
Cross-account access
AWS Web Application Firewall
AWS Firewall Manager
12m 16s
AWS Shield
SAA-C03 Review
Security Summary
PREVIEW12m 46s
Security Summary
3h 43m

This course looks at the key Security services within AWS relevant to the Solution Architect associate exam. Core to security is Identity & Access Management, commonly referred to as IAM. This service manages identities and their permissions that are able to access your AWS resources and so understanding how this service works and what you can do with it will help you to maintain a secure AWS environment. IAM is an important service in ensuring your resources are secure.

Want more? Try a lab playground or do a Lab Challenge

Learning Objectives

  • Learn about identity and access management on AWS including users, groups & roles, IAM policies, MFA, identity federation, and cross-account access
  • Learn the fundamentals of AWS Web Application Firewall (WAF) including what it is, when to use it, how it works, and why use it
  • Understand how to configure and monitor AWS WAF
  • Learn about AWS Firewall Manager and its components
  • Learn how to configure AWS Shield
  • Learn the fundamentals of AWS Cognito

So you've now completed the theory stage of probably my favorite topic of AWS, that being security. As you've probably realized by now, security is interwoven in so many parts of AWS and its services. For example, we touched on Compute Security with key pairs. We mentioned security during our storage section referencing encryption of data. We even touched on encryption during networking with network ACLs and security groups. So security is everywhere. 

So it's no surprise that AWS has a focus on specific security services, but the ones that will primarily show up in the exam are AWS IAM, WAF, Shield, and Cognito. So in this summary, I want to rinse and repeat some of the key elements that are essential in helping you prepare to answer questions that come up relating to these services. Okay, so let's get started. First off, AWS Identity and Access Management, also known as IAM. So first and foremost, you're going to need to know the difference between users, groups, and roles, and the best practices when configuring each of them. For example, generally, you should add users to groups and then apply permissions to those groups. 

Another example would be to ensure you configure multi-factor authentication to any users that have enhanced and privileged permissions to reduce the blast radius should the credentials become compromised. Let me quickly mention a few points over each that you definitely should know about before sitting the exam. So from a user perspective, this is where you can configure and assign multi-factor authentication settings, also known as MFA. Also, this is where you can configure a user for programmatic access, as well as access to the management console. Can you remember what a user needs if they want programmatic access to your resources? Well, they need their access key ID and secret access key which are associated with their user and applied to the configuration of the AWS CLI.

So next we have IAM groups, and these are simply objects that your users can be a part of and any users in that group inherit permissions associated with that group. Now, when it comes to permissions, and I can't emphasize this enough, it's imperative that you have a basic awareness and understanding of IAM policies. You need to be able to look at a policy to determine what access it is allowing or denying. And this will help you breeze through a couple of questions on the exam, at least. Now, remember when it comes to permissions, a deny always overwrite any allow.

So I mentioned roles just a moment ago. So roles and policy permissions is always a hot topic in the AWS Solutions Architect Associate. So let me just run through a few points in relation to these. So roles allow users and other AWS services to adopt a set of temporary IAM permissions to access AWS resources. And the keyword here is temporary. Remember that for any questions that come up relating to temporary access, if you see temporary then look out for roles, but to adopt a role, you must have the right permissions to do so. Now much like groups, roles have associated permission sets and any user adopting the role will receive those permissions. And roles can also be used by EC2 instances, allowing that instance to access resources on your behalf, which is a great way to allow instances to access other resources, rather than embedding credentials on the EC2 instance itself, which you should never do. 

Now you should also be aware of the different types of roles that are available, which includes service roles, service linked roles, roles for cross-account access. And actually on this point, I recommend that you learn and understand the steps involved in creating cross-account access, as there is usually at least one question on this. And then finally, roles for identity provider access which relates to federated access. But what is federated access, I hear you ask? Well, federated access is when you provide authentication to your applications in AWS Services via an external identity provider, such as your own Microsoft Active Directory or social identity, such as Facebook, Amazon, or Google. Now a great service to help you manage this for your web and mobile applications is Amazon Cognito. And I'll come on to this later.

Now, earlier I mentioned how important it is to understand how to read IAM policies, which are written in a JSON format. Now the main elements of a policy you need to know are the action, and this is the action of the permissions being requested. For example, being able to delete objects in S3 or to create instances for EC2. Also, we have the effect, and this element can either be set to allow or deny the actions that are stipulated. Then we have the resource, and the defines the resource you wish the action and effect to be applied to. For example, the ARN of a specific S3 bucket. And also we have the principal element as well. And this specifies the identity that the permissions apply to. And this is usually used in a resource-based policy instead of an identity-based policy. And then finally, the condition. This is an optional element that allows you to control when the permissions will be effective, based upon set criteria. For example, you could ensure that the permissions are only applied if the user has a specific source IP address.

Okay, so moving on from IAM, which is quite a big topic in itself, I now want to mention a few points relating to the AWS Web Application Firewall Service, Firewall Manager, and Shield. Okay, so firstly, what is WAF? While the main function of the AWS WAF service is to provide protection of your web applications from malicious attacks from a wide variety of attack patterns. It's worth noting as well that it's also used in conjunction with Amazon CloudFront distributions, the Application Load Balancer and the API gateway to analyze requests over HTTP or HTTPS, to help distinguish between harmful and legitimate requests to your applications and site. So AWS WAF will block and restrict access that is detected as forbidden. Now it will help you to understand how WAF fits together and some of its components. Ensure you know the differences between conditions, rules, and Web Access Control List for the exam.

So to use WAF, you need to create a Web Access Control List and this will be associated to a resource, for example, a CloudFront distribution. And in this Web ACL, you will include both conditions and rules. Now the primary function of the condition is to specify what element of the incoming request should be analyzed by WAF, and examples of these include cross-site scripting, geo-match or IP address, et cetera. So it's a condition as to which the incoming request will be assessed upon. Now rules contain the conditions that you want to use to filter the incoming web requests. So using both the rules and conditions, you can specify an action, which will either be allow, block, or count. 

And this will depend on the condition configuration. And these rules are then added to the Web Access Control List. Now it's worth pointing out that WAF rules are executed in the order that they appear within a Web ACL. And as soon as the match is found, no other rules are checked for that request. So ensure you set these rules in the correct order to filter your request properly. So that's an overview of WAF. Now let's see how Firewall Manager fits in. So Firewall Manager closely relates to WAF, but Firewall Manager has been designed to help you manage WAF in a multi-account environment with simplicity and control, with the help of AWS Organizations. So just remember, when it comes to WAF and multi-accounts, you should be using Firewall Manager. 

Now, before you use Firewall Manager, you must ensure that your AWS Account is a part of an AWS Organization with all features enabled. You must also define which AWS Account should act as a Firewall Manager Admin account. And lastly, ensure that you have AWS Config enabled. So that's just some prerequisites of using Firewall Manager to be aware of. Now, Firewall Manager uses rule groups to group together one or more WAF rules that you have, and these will all have the same action applied when the conditions are met within a rule. Now also remember that Firewall Manager policies contain rule groups that you want to assign to your AWS resources. Now, the final service I want to talk about that relates to WAF as well is AWS Shield.

So AWS Shield is designed to help to protect your infrastructure against distributed denial of service attacks, commonly known as DDoS, and these attacks target hosts which might be running a website or web application, and the increase and flood of traffic from a DDoS attack aims to prevent legitimate requests getting through to the host and being processed, and so it hinders the whole performance of the application or website. So if you get any questions relating to DoS attacks or DDoS attacks, then you want to be looking for AWS Shield within your answers. So AWS Shield itself is available at two different levels. We have AWS Shield Standard, which is free and available to everyone, whereas AWS Shield Advanced has a lot more power and protection to offer than Standard. For example, with Advanced you get access to a 24 by 7 specialized DDoS response team at AWS, known as DRT. Now also remember that the protection that Shield offers is integrated both with CloudFront and also Route 53 as well.

Okay, let's move on to Amazon Cognito. And this is the last security service I want to mention. So let's put together some of our key highlights here. So Amazon Cognito is an authentication and user management service, which works great with web and mobile applications. So it integrates with third party identity providers, such as Apple, Facebook, Google, and Amazon, in addition to being able to federate identities from your own Active Directory service. Now I recommend you become familiar with the differences between Amazon Cognito User Pools and Identity Pools. Now these are the two main points of this service. So as long as you understand those, then it should put you in good stead to answer any questions that come up about managing authentication and verification at scale to your web applications or your mobile applications. 

Now just remember that User Pools are used to create and maintain a directory of your users for your mobile or web applications. Now this means dealing with both signing up and signing into your new and returning users. Now you can also offer sign-in for your application by using third party identity providers, such as Facebook, Amazon, et cetera, or by using SAML, for example, using your own Active Directory. Now Cognito Identity Pools help to provide temporary access AWS credentials for your authenticated users or unauthenticated guests that need access to AWS services. Now they can work in tandem with Amazon Cognito User Pools, allowing your users to operate and access whatever specific feature they need from AWS. 

Now, additionally, just like with User Pools, you can federate with public providers, such as Amazon, Facebook and Google as well. So the main difference between User Pools and Identity Pools is that User Pools provide a method of authentication through identity verification, allowing them to sign into your web or mobile applications using an identity provider or Cognito's local directory, whereas Identity Pools are typically used to help control access using temporary credentials to access AWS services on your application's behalf.

Okay, so that brings us to the end of the security summary. Now there's a lot to take in. However, you are going to need to know about IAM, the difference between users, groups, and roles. So have a play with them using our labs, and it will really help you. Also spend some time looking at IAM policies to ensure you understand their layout and what they tell you. Now if you get any questions relating to protecting your web apps or CloudFront distributions from common attack patterns, then think of WAF. If you get any questions about managing WAF between multiple accounts using AWS Organizations, then think Firewall Manager. And if you get anything asking how to protect against DoS or DDoS, then AWS Shield is your go-to answer. Okay, it's time to take a break, rest up, retain what we've covered, and then move on to the next section.

About the Author
Learning Paths

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.