How IAM is used to securely manage access
Managing user identities with long term credentials in IAM
Managing access using IAM user groups & roles
Using IAM policies to define and manage permissions
AWS Web Application Firewall
AWS Firewall Manager
AWS Security Hub Overview
Other AWS Security Services
The course is part of this learning path
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!
- 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
In this lecture I want to dive into the configuration of AWS Firewall Manager so you can see how to create policies that are used to manage and secure your resources across multiple accounts. Before we look at some of this configurations in detail, let me talk a little more about these policies. For each type of resource that you want to protect, there is a different policy, each with a slightly different configuration. Also, note that you can create more than one policy for the same resource type which might be useful depending on your use case.
At the time of writing this course, Firewall Manager allows you to create policies protecting the following resources. An AWS WAF Policy, AWS WAF is a service that helps to prevent websites or web applications from being maliciously attacked by common web attack patterns, and it uses Web ACL's as the main building block of the service to determine which web requests are considered safe and which ones are not. So by using this WAF policy you can create a set of Firewall Manager Rule Groups to run at the beginning and the end of your Web ACLs that you have configured.
The rules or rule groups that run in between these two can be configured as required from within WAF itself. Shield Advanced Policy, the AWS Shield services is designed to help protect your infrastructure against distributed denial of service attacks, commonly known as DDoS. This policy allows you to apply Shield advanced protection across your accounts and resources. Network Firewall Policy, AWS Network Firewalls allow you to protect your VPCs from common network threats by implementing fine-grained firewall rules enabling you to control which traffic is permitted and which should be blocked. Using this policy allows you to manage these firewall rules across your VPCs running in multiple AWS accounts.
Amazon VPC Security Group Policy, security groups are used to control traffic at the instance level based upon port and protocol types. By using this policy, it allows you to manage all of your security groups across your entire AWS organization, giving you centralized control. An Amazon Route 53 Resolver DNS Firewall Policy. This resolver DNS Firewall is a managed firewall that allows you to block DNS queries made against known malicious domains, in addition to allowing queries for your trusted domains. As a result, this Policy enables you to control these Route 53 resolver DNS Firewall protections across all the VPCs in your AWS organization.
So now we have more of an understanding on what each of the policies are being used for, let's examine some of them in a bit more detail as to their configuration. The creation of each policy type is generally a five step process, apart from the Network Firewall Policy which contains an extra step.
So step one, you must choose your policy and region. In this step you must select which policy you'd like in addition to the region. Step two, describe Policy. So here you need to define the details of the policy, which is dependent on which policy you selected. Step three, define the policy scope. So this step defines which resources and accounts are covered by the policy that you're creating. Step four, configure policy tags. This is an optional step allowing you to associate a resource tag to the policy. Step five, review and create policy. So this is the final step allowing you to review the configuration you made in the previous four steps before creating the policy. However, do bear in mind that generally the costs of Firewall Manager policies are charged at $100 per policy for each region. For the latest information on Firewall Manager pricing, please see the AWS documentation here to avoid any unexpected costs.
Also, another point when it comes to charges for Firewall Manager policies is that, for each policy you create it will also create AWS Config rules, and in turn these rules will also incur additional charges. For more information on AWS Config pricing, please see the following URL. Okay, so let's quickly review a couple of these policies to see how they differ, starting with the AWS WAF Policy. So to create a policy from within the AWS Management Console you need to select "Security policies" from the AWS Firewall Manager dashboard and then choose "Create Policy".
So step one, this is where you choose policy and region. From here you must select which policy you'd like in addition to the region. For this walkthrough, I'm going to select AWS WAF and the Global region. When you have selected the options you require, click next. So step two, describe the policy. In this step we need to define the policy name, policy rules and policy action. But firstly we need to name our policy something appropriate for the use case.
Next we need to configure the Rule Groups of the Web ACL that will be associated with all resources defined in the policy scope. So effectively, at this stage, the Web ACL that you create in this policy will contain a list of Rule groups that will appear at the beginning, in addition to a list of Rule groups that will appear at the end. This Web ACL will then be replicated to all accounts and resources in scope. And the administrator of each of those accounts can then add their own rules and rule groups between the start and end rule groups already defined by this policy. Also as a part of configuring the policy rules, we must select the default action of the Web ACL, either Allow or Block, and if we want to enable the capture of logging information to Kinesis Firehose.
Lastly, we need to indicate a policy action. So we can either use the policy to detect resources that don't comply with the policy rules without any remediation, or use the policy to automatically remediate any noncompliant resources. Step three, define the policy scope. As we move into the 3rd step, we are able to drill down into the scope, defining which resources and accounts are covered by the policy. At the account level we can apply the policy to all accounts in the AWS organization. We can include selected accounts and organization units or we can exclude selected accounts and organization units, including all others.
From a resource perspective, in the WAF policy you can select a CloudFront Distribution as the resource and you can choose if you want the policy to include all resources that match the resource type, and in this instance that will be CloudFront Distributions. Include only resources that have a specific tag assigned to them. Or exclude resources that have a specific tag, and include all others. Additionally when defining the policy scope, we can choose if we want Firewall Manager to clean up resources by removing protections from resources if they leave the scope of the policy.
For example, you might have selected to include resources that have a resource tag of TeamA, if that resource then had it's tag changed from TeamA to TeamB, then Firewall Manager could remove the protection offered on that resource automatically as it no longer aligned with the required resource tags. Step four, configure policy tags. This step simply allows you to assign a resource tag to the policy itself using a key value pair and this is an optional step. And then step five, review and create policy.
This final step allows you to review all of your options from steps one to four, before confirming you want to create the policy. However, do bear in mind the associated cost before creating your policy, which I will reiterate are generally charged at $100 per policy for each region. Now before we look at the other policies, step one, step four and step five are generally all the same for every policy. So for the remaining policies, I shall just be looking at step two and three.
So let's jump straight to step two for the AWS Shield advanced policy, which allows you to manage Distributed Denial of Service, DDoS protections for your applications. So step two for describing the policy. When compared to the AWS WAF policy that we just looked at, there aren't really many options here for AWS Shield. All we need to do here is to give the policy a name and then define a policy action. Either use the policy to detect resources that don't comply with the policy rules without any remediation, or use the policy to automatically remediate any noncompliant resources.
And then step three, defining the policy scope. This step is exactly the same as what we covered previously when we looked at AWS WAF. We configure which accounts and resources that this policy applies to by selecting the appropriate options. Again, this relates to CloudFront distributions as Firewall Manager doesn't currently support Amazon Route 53 or the AWS Global Accelerator. So if you want to protect either of resources with this service, then you will need to manage this directly from within AWS Shield.
Okay, let's take a look at one more policy before we move on, so the next policy I want to show is the Security Group Policy. Now interestingly, this option has an additional step of configuration options during step one. In addition to selecting the policy detail of Security Group and the Region, you will also be asked to specify the Security Group Policy Type. As you can see, there are three options for this. Common security groups, auditing and enforcement of security group rules. And auditing and clean up unused and redundant security groups.
So your selection will depend on the use case in which you would like Firewall Manager to manage your security groups. If you want to add new security groups to your Organization, select common security groups. If you want to enforce specific rules in existing security groups, choose the 2nd option and lastly, if you want to remove redundant security groups then select the last option. So let's look at the configuration of adding new Security Groups to your organization. So with that in mind, let's move onto step two.
Now in this step there are three elements we need to configure. Policy name, policy rules and policy action. As with any policy, we need to issue the policy with a relevant name. When it comes to configuring the Policy Rules, you will need to ensure that you have already created a security group within your VPC. Once you have created the security group that you want to apply across your organization, you can then add it to the policy rule. In this example, you can see that I have created a security group called, MyFirewallSG, which I have now added to this policy.
Finally, select your option for the Policy Action. Again, this is where we can define the scope of which accounts and resources this policy is associated. The main difference on this screen from previous policies we've looked at is the Resource Type. Here you can specify which type of resource, whether that be an EC2 instance, an ENI, an ALB or a Classic load balancer, all of which can be associated with a security group. So again, it depends on what you are using your Security Groups for and for which resource you want to protect.
Also, at the bottom of this screen shot, you can also see that by enabling the checkbox, you can apply the policy to resources against shared VPCs too. So compared with the WAF and Shield policies, there is a wider variety of options when it comes to resource type, and its simply because security groups have the capability of being associated with a variety of different resources within your organization. So we've looked at some of the policies that Firewall Manager can create for you, allowing you to govern and manage access for a number of different resources across your organization.
It really helps if you have a working knowledge of these resources and services before you begin trying to create policies to offer protection for them. As we've seen, in some circumstances you need to have created certain resources and elements prior to creating a firewall manager policy. Once you have created the policies that you need, AWS Firewall Manager will deploy these within the accounts and against the scope of resources we have identified.
Any new resources that are created from this point will automatically fall under the protection of these same policies as long as they fit within the scope outlined of the policy. This automatic protection reduces the amount of administration required in configuring and setting up protection on an individual basis.
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.