Hi, everyone, and welcome back.
Now, in today's video, we are going to discuss about strategies for using the service control policies.
Now, at a high level overview, there are two primary strategies that you can use to configure the
steps within your account.
One is the denial list based strategy, and second one is the allowed list based strategy.
So in today's video, we are going to go ahead and discuss about both of them in great detail.
Now, the first primary approach is the deny list, and in deny list, the actions are allowed by default
at the IP level.
And then you specify what are the services and actions that you want to deny.
Now, when we discuss about organizations and service control policies, by default, they make use
of this denial list based strategy, and this is achieved by using the full access CB policy which is
attached to the root.
Now, if we quickly look into what this full access policy looks like, this is the policy statement
where everything is allowed by default.
Now, note that this might be a little confusing because the strategy of denial is actually has allowed.
So this is a little confusing to begin with.
Now, let's also quickly look into this.
Now, currently I am in the organization which does not have the IPS enabled.
So if you look into one of the accounts over here, if you look into the policies, there are no policies
that are associated now at this stage.
Whenever we enable the service control policies, at this stage we see that there is one primary policy
that is created which is full access.
The kind is a managed policy.
And if you look into this, policies targets, it is associated with the root and all of the accounts
that are part now in this base approach.
If you look into the overall policy statement, it is allowing everything.
So by default everything will be allowed at the SP level and then you explicitly deny any services that
you want to prohibit.
For example, if you do not want anyone to connect with the service, you add a deny statement explicitly.
Now note that since this is a managed policy, there are certain restrictions, so you can go ahead
and create a new set of policies.
You will not be able to perform various operations.
For example, if you want to delete it, let's try it out as a full access.
And if you see in the description it states you cannot modify and manage policy.
They are read only great.
Now with this basic understood, let's look into some of the benefits that this type of strategy provides.
As we already know that using the denial strategy, the account administrator can delegate all services
and actions until you create an attach CFP that denies a specific service.
So by default everything will be allowed.
And then you add the explicit deny policy to deny a specific service or action.
So here we need to note that the deny statements require less maintenance because you don't need to
update the policy when it adds new services.
So a has hundreds of services now since you have explicitly allowed all of the services at the ACP level,
you do not really need to worry because even if a new service is launched, the users will have the
access to it.
Considering that they have the appropriate permissions.
Apart from that, one of the other benefit is that the deny statements usually use less space, thus
making it easier to stay within the maximum size of the service control policies.
Now, if you look into the sample deny list based policy, so it might look something like this where
you have a loud statement and then you have a explicit deny statement on the action and the service.
So in here the action is Dynamo DB star with this basic, let's also look into the strategy number two,
which is allow list.
Now in order to make use of allow list, what you can do, you must replace the a managed full access
ACP with a new ACP that explicitly permits only those services and actions that you want to allow.
Now you have to remember that by removing the default full access ACP, all the actions for all the
services are now implicitly denied.
This is very important part to remember.
And then, since all actions and services are implicitly denied, you add a custom ACP that overrides
this implicit deny with the explicit allow for only the actions that you want to permit.
So if you look into this sample allow list based policy, this is how it looks like.
So here it is assumed that this full access ACP is not associated with the accounts.
And then you add this specific policy which is allowing certain services like EC two star cloud watch
star.
So apart from these set of services, the users will not be able to perform operations on any of them.
Now, before we proceed further, let's also have a quick demo associated with this.
Now, let me also quickly show you a demo.
Now at this stage, note that we are just looking into it from demo perspective to ensure that our concepts
are understood better.
So for today's demo I have one more policy college allow list policy.
So if you look into the allow list policy, it is associated with the root and it is also associated
with a sandbox account.
Now at this stage for this allow list policy to come into effect, you have to ensure that your full
access is not associated with the accounts.
So if you look into the targets, it is just associated with the management account here.
It is not associated with any other accounts.
So if I have to show you.
So in root we have the management account and the sandbox account.
So this specific policy that we have, the allow list policy, this is associated if you look into the
sandbox account and there is no full access policy here.
So let's go ahead and quickly try it out.
So if you look into the content, it is allowing EC two star and cloud watch star now to test things
out.
I am logged in as a root user to one of the member accounts.
Now within since we know only EC two and cloud watcher allowed, let's try to explore other services
like SES immediately.
You see we got an error stating that there is a deny in the ACP.
Let's also try one more service.
I'll say API gateway again, we are getting an error.
Similarly, let's try e c to this time and ec two is working perfectly well.
You will be able to launch instances etc..
All right.
So I hope with this you understood the basics of allow list and deny list.
Now again, one thing I wanted to show you, let's quickly look here.
If you look into this sandbox account policies that is only allow list policy.
There is no full access policy over here.
And this is the reason why things are taking into effect.
Now before we conclude certain important pointers that we need to note.
First one is that every root or you and account must have at least one service control policies attached.
And this is the reason why, if you want to replace the default full access policy with an ACP that
limits the permission, then you must attach the replacement SFP before you remove the default.
So for example, at this stage you will see that the sandbox account has a allow list policy.
So at the instance of time, one policy must be attached.
So if you want to switch from a list to deny list, then what you have to do, you have to associate
a deny list policy and then you can remove the allow list.
Great.
So that's the high level overview about the strategies that you can use.
Again, from what I have seen in organizations, most of them, they use their default denial list based
strategy.
They do not opt for allow list in case if you are using a low list, although this looks good, but
it also requires a lot of efforts.
And in most of the organizations, the security team or the team that is managing all of the ssps,
they are quite small and they do not have the required amount of time and resources to manage the allow
list policy, apart from other security related configurations that they have to work on as part of
the overall infrastructure.
So with this will conclude today's video.