Service Control Policies applied through GuardRail

Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines. SCPs are available only in an organization that has all features enabled. SCPs aren't available if your organization has enabled only the consolidated billing features.

SCPs alone are not sufficient to granting permissions to the accounts in your organization. No permissions are granted by an SCP. An SCP defines a guardrail, or sets limits, on the actions that the account's administrator can delegate to the IAM users and roles in the affected accounts

SCPs do not grant permissions to IAM entities such as Users or Roles, they only offer themselves as extra protection against performing any actions. As an example, you might want to prohibit the deletion of any RDS Instance, because losing a Database through accidental deletion by misclicking in the console could be disastrous. You made your team IAM users with Full Admin access? Well, the SCP in place will give them full AWS permissions but still the SCP will block them from deleting an RDS Instance.

It's added protection for when you have potentially given too much permission to your users or roles.

To locate your AWS Account's Service Control Policies, head within your AWS Account to AWS Organizations > Policies > Service Control Policies. Click Service Control Policies and you are then taken into a screen which will list all available policies. From here you can Disable all Service Control Policies, or you can Attach/Delete the listed policies.

Note: SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization.

To an attach an SCP to an OU in the AWS Console, head on over to the AWS Organizations > Policies > Service Control Policies. From your list of Policies, you can select one and then use the actions drop down menu to select Attach Policy

After choosing this policy we can select an OU or singular AWS Account to attach this Service Control Policy to.

This SCP restricts access to any operations for the root user in an AWS account from taking any action, either directly as a command or through the console. Also denies disabling CloudTrail, AWS Config, GuardDuty and leave the Organization or modify Billing Settings.

We also deny the deletion of the StackZone Lambda Log Groups and streams within thereof. Also prevented is the deletion of any S3 Glacier or Vault.

Another action denied by this SCP is the disabling of EBS Encryption by default.

For CloudFormation, we are also blocking a lot of interaction with StackZone stacks and stacksets for all users and roles with the exception of the AWSCloudFormationStackSetExecutionRole. This role also cannot be managed or changed by any AWS Account user, or root user not designated as Automation by StackZone.

There are also restrictions on deletion of Access Analyzer and Macie, along with the creation of RDS Instances and Clusters unless they have encrypted storage.

Deny All Networking actions (Attach VPN, Create VPN, Create NAT Gateway, Amazon VPC Peering, Internet Gateway, AWS Direct Connect, AWS Global Accelerator). You can select what Organizational Units are included in this GuardRail.

This GuardRail will prevent anyone creating, deleting and managing networking resources within your AWS Account.

Deny access to non-HIPAA compliant cloud services. If you are in the process of certifying HIPAA, you can select the Organizational Units where your services are running HIPAA compliant workloads.

The HIPAA Preventive GuardRails will deny all operations with services which do not appear on AWS' approved list of services for HIPAA Compliance. For an up to date run down of what these services are, head to this AWS Page and find the drop down selection for 'HIPAA'

Deny access to non-SOC compliant cloud services. If you are in the process of certifying SOC, you can select the Organizational Units where your services are running SOC compliant workloads.

The SOC Preventive GuardRails will deny all operations with services which do not appear on AWS' approved list of services for SOC Compliance. For an up to date run down of what these services are, head to this AWS Page and find the drop down selection for 'SOC'

Deny access to non PCI-DSS compliant cloud services. If you are in the process of certifying PCI-DSS, you can select the Organizational Units where your services are running PCI-DSS compliant workloads.

The PCI Preventive GuardRails will deny all operations with services which do not appear on AWS' approved list of services for PCI Compliance. For an up to date run down of what these services are, head to this AWS Page and find the drop down selection for 'PCI'

This Service Control Policy restricts access to any operations outside of the specified AWS Region. This relates to your StackZone enabled regions, so if your primary region is eu-west-2 and you have additionally enabled eu-west-1 and us-east-1 regions, these are the only 3 regions you are allowed to create within. By design, Resource Explorer is exempt from this GuardRail.

You can select what Organizational Units are included in this GuardRail

This Service Control Policy restricts Amazon SageMaker deployments if not using a VPC. Your SageMaker deployment must satisfy VPCSubnets and VPCSecurityGroupId attributes or the deployment will be blocked.

This can be applied to a single account, or a full AWS Organization's OU.

This Service Control Policy restricts services usage except IAM & Resource Explorer in the target account. This is an extremely restrictive GuardRail meant to be applied only under certain circumstances. Useful if you want to quarantine or lock off an account to ensure that no new services or resources are created or modified with the exception of IAM & Resource Explorer

This can be applied to a single target AWS account or a full AWS Organization's OU. This could bring rather disruptive changes in the account however so use this with caution.

Status: Experimental

Data Perimeter Governance is split between 2 GuardRail Policies due to size constraints. You will need to attach both to your target OU in order to gain full effect. This GuardRail will deny actions towards S3, EC2, Route53, RDS Snapshots, SSM Documents, DS, Redshift Data Share, Lakeformation, Appstream, Lambda, CloudShell, Sagemaker & RAM unless there is a tag excepting a resource from said action.

The AWS Resource Tag needed to bypass this Data Perimeter Governance will be "identity-perimeter-exception = true"

Status: Experimental

This SCP implements controls that protect your sensitive data, that should not be made publicly accessible or deleted intentionally or unintentionally.

With this GuardRail from StackZone, we prevent S3 Delete actions for Glacier, Backup actions and S3 Public Account Public Access Block actions for all resources, with the exception of the StackZone Execution Role - so our own automation is not blocked when constructing or removing resources as intended by adding features to your deployment.

Status: Experimental

This SCP enforces a network perimeter to prevent any actions (with the exception of ES & Dax api calls) to any AWS resource you have tagged with the following resource tag;

Tag Key: data-perimeter-include

Tag Value: true

With the above tag you can ensure that no networking related actions are taken on your protected resources unless originating from a select source IP. You can also ignore the above tag if your source AWS VPC is within the allowed vpc list supplied via the StackZone Console on the GuardRails section along with a specific resource tag;

Tag Key: network-perimeter-exception

Tag Value: true

Status: Experimental

This SCP enforces a network perimeter to prevent any actions (with the exception of ES & Dax api calls) to any EC2 Role.

These actions can be accepted however if your source AWS VPC is within the allowed vpc list supplied via the StackZone Console on the GuardRails section along with a specific resource tag;

Tag Key: network-perimeter-exception

Tag Value: true

This Service Control Policy restricts purchasing instance reservations, capacity reservations, savings plans for AWS Services like EC2, RDS, DynamoDB, ElastiCache, CloudFront and Redshift.

Also denies registering a Domain Name using Route53 or accept Marketplace Agreements.

We recommend to apply this to all OUs of the AWS Organization if you require to control and limit purchase options on the Primary AWS Account.

Deny Amazon Elastic Compute Cloud (Amazon EC2) Running Instances if not tagged as indicated (up to 10 tags). For instance, you can indicate Owner, Tier, BusinessUnit, Project as your required tags. You can select what Organizational Units are included in this GuardRail.

For example, you can declare the following tag key/value pair in your configuration;

This means that your EC2 Instance will need 2 tags applied to the resource. If it does not comply with your Service Control Policies, this GuardRail will restrict you from creating an EC2 Volume, along with running the EC2 Instance.

This does mean, that the EC2 Instance and EBS Volume must be tagged accordingly.

The Value's can be anything you want in this example, but each resource must have the Company and Environment tag keys applied. This could be particularly useful if you are creating resources through IAC methods, and you want to ensure creation is compliant with standards you are setting yourselves with tags.

How do I check where my Service Control Policies (SCP) are?

First you will need to ensure that you are logged into your AWS Organization's Management Account, or StackZone Primary account. From here, click on Organizations.

On the left hand side panel within AWS Organizations in the AWS Console, click on Policies

Of the supported policy types, the one we want to focus on are held within Service Control Policies

How do I know what SCP's are enabled?

Within the Policies section of the AWS Organizations dashboard within your Org's Primary Account, you will be able to check if the Service Control Policies are showing an Enabled status or Disabled status. If it is showing Enabled, you will be able to view all currently active SCP's inside by clicking on Service Control Policies

How do I delete an SCP?

When you are viewing the current list of attached Service Control Policies from within the AWS Organizations / Policies / Service Control Policies section, you can delete a policy from the list of currently enabled policies.

To do this, simply click on an available policy from the list by selecting the tickbox, and go to Actions > Delete Policy

How do I attach an SCP?

In a similar method to deleting an SCP from your Service Control Policies list, by choosing the Attach Policy option from the Actions list, you are able to then attach a policy to either a specific AWS Account, or Organizational Unit which can house many AWS Accounts.

Optionally, you can attach an SCP directly to "root" which will mean all AWS Accounts within your Organization will inherit this selected policy.

Want to know more about StackZone and how to make your cloud management simple and secure?

Check our how it works section with easy to follow videos or just create your own StackZone Account here