Hello and welcome to this lecture which will dive into Service Control Policies to understand how they can be used to secure your AWS Organization. SCPs are different from both identity-based and resource-based policies, which grant permissions to users, groups, and roles. However, SCPs do not actually grant permission themselves. Restrictions made within an SCP set a boundary of permissions for AWS accounts.

For example, let's say a user within an AWS account had full access to S3, RDS, and EC2 via an identity-based policy. If the SCP associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2, despite having full access to S3. The SCP would serve to prevent that service from being used within the AWS account and so have the overriding precedence and determine the maximum level of permissions allowed.

So to be clear, an SCP does not grant access. They add a guardrail to define what is allowed. You will still need to configure your identity-based or resource-based policies to identities, granting permission to carry out actions within your accounts. If you want to use Service Control Policies to help you manage your security at an account level, then you need to ensure that you deploy AWS Organizations using the enable all features setting.

Before you start using SCPs, you first need to enable them from the root account of your organization. However, you need to ensure that you have the following permissions. From within your AWS Organizations console, navigate to the Policies tab and select the Service Control Policies option that will show the status of Disabled. Then, select the option to enable the SCPs as shown. At this point, SCPs will now be enabled at the root level of your organization and you can now begin to use Service Control Policies within your organization.

I now want to perform a demonstration showing you how to create a Service Control Policy and attach it to an account. In this demonstration, I will have two accounts; my master account called Stuart and another account called CA-Demo. In the CA-Demo account, I have a user, Alice, who has an IAM policy attached that allows full access to S3. From within my master account, I will create a new Service Control Policy denying access to the Amazon S3 service. I will then attach this new SCP to the CA-Demo account. I will then log in as Alice and try to access Amazon S3 to see the result. Let's take a look.

Okay, so to start this demonstration, I'm logged in as the user Alice in this CA-Demo account which is my member account to my organization. And as I said previously, Alice only has access to Amazon S3. So if we take a look at S3, we should be able to get into the service without any issues. So we can get into the service which is great and also create a bucket as well, so a bucket for Alice. And there we have it. So this user Alice is able to access S3 and also create buckets as well.

Now what I want to do is swap back over to my master account of my AWS Organization, create a Service Control Policy to block access to Amazon S3 and then apply it to this account. So let's do that next. Okay, so I'm now back in my master account and what I want to do is to create a new Service Control Policy. So from the AWS Organizations dashboard, if I click on Policies, now I already have my Service Control Policies enabled, if yours says disabled, simply select it and then you'll have the option to enable it.

Once your Service Control Policies are enabled, if you select them, now we can create a policy. We have a default policy here which is FullAWSAccess which allows access to every operation and this is the default Service Control Policy that's applied to the root of my AWS Organization. However, what I want to do is deny access to one of those services. So if I select create policy, I'll just call this Deny S3, give it a description of deny access to S3, and then down here is where we can build our policy. So there's different options.

Firstly, the statement and then the resource and any conditions. So to start with, we can see that over here our policy is in a deny state. Now if we wanted to allow access to a service, we'll change that to allow. But I'm gonna leave that as deny and over here I wanna select my service that I want to deny so let me scroll down to S3, if I can just find it in the list, there we go, and I want to prevent all actions of S3. Now as we can see, it's now updated this policy with the action of all actions to S3, but we don't have the resource yet. So let's now scroll down to add resource. So our service is S3 and our resource type would be all resources. So if I select add resource, we can now see that the policy has been updated again. So at the moment, it's denying any action in S3 for all resources.

Now if I wanted to add a condition, then I could add any conditions in here with the condition key and qualifier, et cetera. For this demonstration, I'm not going to add any conditions.

Now I just need to create the policy. Okay, so that's our policy created. Now although the policy has been created, it's not actually attached to any organization unit or account thus yet. So let me go back to my accounts. Now if you remember from a previous demonstration, we had our member account, the CA-Demo account, within the Test OU. So I'm going to select that account, go across the Service Control Policies, and then we can see that we have this policy here that we just created and I want to attach that to this specific account. So if I select attach, we can now see that this account has two Service Control Policies, the FullAWSAccess which is filtered down from the root which allows access to all S3 resources, but we also have a Service Control Policy here that denies access to one of those services and the deny will always overrule an allow.

So now we've attached that Service Control Policy to the CA-Demo account which is the account that Alice is a part of. Let me now log back in as Alice into this account to see if I can now access S3 or if the Service Control Policy has been applied. So let's take a look.

Okay, so I'm back in my CA-Demo account which is the member account. I'm logged in as Alice. So now if I go to S3, let's see what happens. We have an error of access denied and we can't see any buckets. So it looks as though that Service Control Policy has taken effect because I can't access S3 at all. So let me see if I can create a bucket, if I just add in any name, and try to create, again we get an error of access denied. So we can see that the Service Control Policy has in fact now blocked access for Alice despite her having IAM permissions allowing her full access to S3. You would have noticed that in my list of SCPs from the demonstration I just carried out there was a pre-existing SCP there called FullAWSAccess and this was associated with the root object of my Organization, so how does the inheritance of SCPs work? Well, let's take a look at an example.

Let's suppose we had the following AWS Organization layout, with the FullAWSAccess SCP at the root. The objects within an Organization follow a parent-child relationship, with the Root being the parent to all other child objects. As you can see at the root level, we have an SCP that allows full access to AWS. I now want to establish what SCPs each of the five AWS accounts, highlighted in orange, is governed by. So looking at Account 1, looking from the root, we have the FullAWSAccess SCP. The next level down to Account 1 is the Dev OU. Now, this has four SCPs associated. However, these are number 2, 3, 5 and 6. So at this stage, only the services and features within these SCPs are allowed at this level.

Now if we go down further to Account #1, we have another OU, the Test OU, which again is governed by a list of SCPs, 3, 5 and 6. We can see at this level of the tree, SCP 2 has been dropped so this OU is now restricted to SCP 3, 5 and 6. Therefore, Account 1 which is a child of the Test OU is restricted and governed by the details set out in these three SCPs. Using this methodology, we can now look at the other accounts. So Account #2 is governed by SCP 2, 3, 5 and 6. Account #3 is governed by 1 and 6. And Accounts 4 and 5 are governed by SCP 4.

Let me now look at a different example, this time I'm going to remove the default SCP of FullAWSAccess at the root and replace it with custom SCPs as shown here. Now I'm going to assume in this scenario that every SCP shown has different service restrictions. So as you can see, at the root level this time we have four SCPs, number 1 through to 4, so let's see how this affects the results this time for each account. So Account #1, looking from the root, we have SCPs 1 through to 4, the next level down to Account #1 is the Dev OU. Now, this also has four SCPs associated. However, these are number 2, 3, 5 and 6. As a result, this Dev OU is only controlled by SCPs 2 and 3. SCPs 5 and 6 are discarded as they are not a part of the parent relationship with the Root object, and 5 and 6 do not exist at any parent level.

Now if we go down further to Account 1, we have another OU, the Test OU, which again is governed by a list of SCPs, 3, 5 and 6. We already know that 5 and 6 are not allowed as they are not in the parent chain. However, SCP number 3 is. So SCP 3 exists from the root downwards in this OU. Therefore, Account #1 is restricted and governed by the details set out in SCP 3. Using this methodology, we can now look at the other accounts. So Account #2 is governed by SCP 2 and 3. Account #3 is governed by SCP 1. And Account #4 and #5 are governed by SCP 4.

Finally, before I end this lecture, please be aware of some of the characteristics of Service Control Policies. SCPs do not affect resource-based policies. They only affect principals managed by your accounts in your organization. SCPs affect all users and roles, in addition to the root user. However, the root user will still be able to change its own password including MFA settings, manage root access keys, and manage x.509 keys for the root user. If you disable SCPs in your organization, all SCPs are deleted and removed. Re-enabling SCPs again in the same organization will revert to the default SCP allowing FullAWSAccess. The following elements are not affected by SCPs: any actions performed by the master account, SCPs do not affect service-linked roles, and managing Amazon CloudFront keys.

That now brings me to the end of this lecture and to the end of this course. You should now have a greater understanding of how Service Control Policies can be used within your AWS Organization to help you centrally control the different levels of access between multiple accounts. If you have any feedback on this course, positive or negative, please do contact us at support@cloudacademy.com. Your feedback is greatly appreciated. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.