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. Let's take a look at an example question which looks at some of these features. So the question reads, "A company has contracted you "to move their web application database to the cloud. "They also have on-premises applications that will interact "with their cloud environment in a hybrid solution. "You are working with the IT security engineer "in designing a secure solution. "Specifically, you are reviewing Identity "and Access Management features of AWS. "Which AWS IAM best practice provides an additional layer "of protection for user identity verification? "Choose two answers." So looking at that last sentence there, we're looking at additional security for users with their verification of who they are, and this is all within IAM. So pretty much everything before that last sentence we can kind of ignore. It's just there to confuse the question. All we need to do here is to provide two answers that give an additional layer of protection for users in IAM. So let's look at our answers. We have "A, configure strong password policies." Well, you can definitely configure password policies in IAM and you can make them really strong indeed. So that is certainly one option. "B, EC2 key pair logins." Now you might remember back from our compute course that EC2 key pairs are used to help you to authenticate onto EC2 instances. They're not used to verify your user identity within IAM. So B is incorrect. "C, multi-factor authentication." This is definitely something that can help you make your users more secure 'cause it adds another layer of verification, and that's what we need to do. So definitely C. And then, "D, grant least privilege." Now granting least privilege is a best practice when using IAM and other security controls but it doesn't actually add another layer of protection. So here the answers are A and C. 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. Okay, question time again. "An advertising company is running all of its websites, "databases and file storage in the AWS cloud. "They are hiring hundreds of new employees "to manage regional advertising campaigns "to be launched on multiple continents. "The permissions for each employee will vary "based on the employee's location and job title "within the company "and management is concerned "about consistently applying access to resources "as new users are rapidly added to existing AWS Accounts. "What is the most efficient way to maintain consistency "with a minimal amount of reorganizing "the existing corporate access and policy structure in AWS?" So this question really assesses your understanding of the different components in IAM and the best practices of applying permissions. So reading through the question, what we have is lots of employees in different groups, in different regions that need different access, and what's the best way to manage those groups of permissions for those users? So let's take a look at our answers. So "A, we can attach IAM policies to each IAM user "based on their location and job title." Now that's not a best practice because we really should be using groups when we're talking about multiple users and aligning permissions based on job role and job location. If we go ahead and set permissions on every single user that's gonna take a lot of time. And remember what we're looking for is the most efficient way to maintain consistency. So doing it per user isn't gonna be efficient. So we can rule out A. "B, create IAM groups based on location and job title." Okay. That sounds good. "And attach an IAM role to each group "and assign IAM permissions to their corresponding group." Now, if you think back to the IAM course, you don't actually attach roles to groups. What you attach to groups is permission policies, so that isn't actually possible. And we're gonna talk more about roles in a moment. "C, create IAM groups based on location and job title." Again, it sounds good. "And attach IAM policies to each group "and then assign IAM users to their corresponding group." Now that sounds great 'cause what we'll have is different groups based on job title and location, which is what the question is asking, and then we'll attach specific policies to those groups and then add the relevant users to each individual group. So that would be able to maintain consistency with a minimal amount of reorganizing. So that looks a very promising answer. And then "D, create organizational units for each location "and apply service control policies "for each organizational unit." Now organizational units and service control policies are used with AWS Organizations, but we need to be using IAM here. We're looking at user permissions. We're not looking at restricting permissions at the AWS Account level. So that is definitely not the right answer. So the right answer here is C. 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. So let's take a look at a couple of questions that involve IAM roles. So the first question. "You have been assigned to a new client "that has an existing AWS cloud environment. "They have a web application in a public subnet "and an RDS database in a private subnet. "In addition, they have several applications "which need to interact with their cloud environment. "They have one application that uses an AWS SDK "and they need the application to be able "to be authenticated as a principal to AWS cloud services. "How would you accomplish this authentication?" So here we have an application that needs access to AWS cloud services. 

So how would we go about granting this access? So let's take a look at our answers. We could create an IAM user, and store the username and password in the application. Now this goes against all best practices. You should never embed credentials in the code or on the source host of the application because it could potentially be compromised. So "B, use Direct Connect between the application "and the AWS cloud." Now Direct Connect, as we know, is used to establish a connection between your on-premise corporate data center and AWS, but that's not what we're trying to do here. We just have an application in AWS that's trying to access AWS resources. So Direct Connect isn't appropriate in this situation. "C, create an IAM role for the application "and run it on an instance." So here we can create an IAM role with the relevant permissions to AWS services, attach it to an instance, and then run the application on that instance. And that application will inherit the permissions to allow the application to talk to the relevant services. So that is probably the correct answer. But let's just make sure and read the last one. "D, use an SSL connection between the application "and the AWS cloud." Again, we're not looking to encrypt connections between the application and the cloud, and the application is already residing in AWS. So again, that's not appropriate in this situation. So the answer here is C, create an IAM role for the application and run it on an EC2 instance. 

Okay, let's take a look at one more question here. So "You are configuring cross-account access "for your account. "You have a production account "which contains resources that a development team "in a development account requires access to. "What is the first step in the sequence of steps required "to implement cross-account access "for the development team using AWS IAM." So this is really testing your knowledge and understanding about how to set up trust between two different accounts to allow IAM identities in one account to access resources in another account. So let's go through it and find out which is the first step. So "A, create a role from within the trusted account." So here you really need to understand the difference between the trusted account and the trusting account. So the trusting account is the account that holds the resources that another account needs access to that is going to be trusting another account. Now the trusted account is the account that wants to get access to the other account. So let's look at A again. "Create a role from within the trusted account." So in the question here, that is saying that we need to create a role in the development account. But actually what we need to do is reverse that. We need to create a role in the trusting account that allows the trusted account access to its resources. So it's not A. "B, test the configuration by switching to the new role." 

Well, we haven't actually created a role yet, so that can't be the first step. "C, create a role from within the trusting account. Now, this looks much better, because the trusting account is the production account here. So the production account will create a role allowing the trusted account access to its resources. So C looks good, but let's just read through all of them anyway, like we do all the time. And then "D, specify the permissions attached "to the newly created role, "which the users in the trusted account would assume "to carry out their required actions and tasks." Now, again, this assumes that we've already created the role but the question is asking, what is the first step? So this isn't the right answer. So the right answer in this situation is C, create a role from within the trusting account. 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 let's review an example question that shows a sample IAM policy. Now I'm not going to read out the whole policy there but I just want you to take note of a few different elements, and those being the ones we just spoke about. So the effect, the principal, the action and the resource. So looking at this policy, what will this policy do? So "A, it will result in an error "saying invalid policy statement." Now, if you're aware of the syntax of an IAM policy, you'll be able to establish that there's no problems with this policy at all. So "B, this policy allows the user 'test' "within the AWS Account ID 12112112 "to perform a GetBucketLocation, ListBucket, "and GetObject on the bucket cloudacademy." So let's take a look at the policy here. 

So it's saying this policy allows the user test, so here we need to look at the principal, 'cause that specifies what user identity that this policy applies to. And we can see here that the ARN does point to a user called test in the account 12112112. So that element is right. Now we need to look at the actions to see if the GetBucketLocation, ListBucket, and GetObject is there. And if we look at the policy, we can see that those three S3 actions are listed. And now we need to look at the resource. So we need to make sure that it points to the cloudacademy bucket. So if we look at the resource section, we can see that the ARN points to the S3 bucket of cloudacademy. So that looks correct. Let's just carry on reading through C and D anyway. So "C, it will create an IAM policy for the user test." That is incorrect. An IAM policy won't create a policy, it will just show the permissions. So that is incorrect. "D, it will allow all IAM users "within the account ID 12112112 "to perform GetBucketLocation, ListBucket, "and GetObject on the bucket cloudacademy." Now we can already see from the principal parameter that it doesn't allow all users. It only allows the user test. So here the answer is B. 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, so let's take a look at some questions. The first question. "In AWS Web Application Firewall, something allows you "to specify what elements of the incoming HTTP "or HTTPS request you want WAF to be monitoring for." So this tests your understanding of the different components from within WAF. So what are our options? Well, we have cross-site scripts. 

Now cross-site scripting is one of the attack patterns so that's not going to help us here. "Access control lists?" Well, the Web Access Control List actually contains all the conditions and the rules, and it's what is applied to your resources, such as your CloudFront distribution. So that's not a component that specifies the elements. Then we have rules. Now rules is the component that contains the conditions that you want to filter, but it's the actual condition is what specifies what element of the incoming request should be analyzed by WAF. So the answer here is D. Let's look at another question. "A company discovered that requests to a web application "hosted on AWS are timing out "due to a distributed denial of service attack." Now, straight away, from that alone, we should be thinking of a particular service. "A Solutions Architect needs to restore the service "and configure an automated response to protect the service "from future DDoS attacks over Layer three and four. "Which of the following solutions "should the Solutions Architect implement "to automatically mitigate DDoS attacks in the future?" So let's take a look. So we're looking for a service that protects us against DDoS attacks. So "A, AWS Shield." Now AWS Shield is specifically designed to help with these distributed denial of service attacks. So I would say it's A, but let's just read through the other options that we have. "AWS WAF." Well, the function of WAF is to provide a service to provide protection from malicious attacks from different attack patterns, not specifically DDoS, whereas Shield is. Then we have "C, Firewall Manager." Well, Firewall Manager is used to help to manage WAF across multiple accounts. So it's not that either. And then GuardDuty. Now GuardDuty is a threat detection service that continuously monitors malicious activity, but it's not specifically designed to protect against DDoS attacks. So the correct answer here is A, AWS Shield. 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. So let's take a quick look at a question regarding Cognito. So "What types of identities do Amazon Cognito "identity pools support?" So again, this is where you need to know the difference between Cognito User Pools and Cognito Identity Pools. So let's take a look. "A, they support only unauthenticated identities." So I know that Identity Pools allow federated access from social identity providers, such as Amazon, Facebook, and Google, et cetera. So I know that they support authenticated identities. So A is definitely wrong. "B, they support unauthenticated and authenticated identities." Now, again, I know that they support authenticated identities, as I just explained, but they also support guest users as well, which would be unauthenticated. So that looks like the correct answer. "C, they support only authenticated identities." Well, that's incorrect because I know they support guest identities. And then, "D, they support neither authenticated "nor unauthenticated" and that's just wrong. So the answer here is B, they support both authenticated and unauthenticated identity. 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.