From the course: AWS Essential Training for Administrators

Service control policies - Amazon Web Services (AWS) Tutorial

From the course: AWS Essential Training for Administrators

Start my 1-month free trial Buy for my team

Service control policies

“

- [Instructor] We've created an AWS Organization that gives us central access and consolidated billing. However, our architecture still has a critical security gap. IAM policies and roles in our member accounts allow users to perform highly-privileged actions, such as stopping CloudTrail logging. We need a security boundary that cannot be taken down by any IAM user role, or even the member account's root user. That is the purpose of Service Control Policies, or SCPs. SCPs define the maximum permissions that any identity in an account can exercise. They act as a permanent Organization-wide filter over all other permissions. An explicit deny in an SCP always wins. If the SCP denies an action, no IAM policy can override it. You will find SCPs under the Policy section of the AWS Organizations console. Here, you will find different types of policies you can enable for the account, such as backup policies, tagging policies, and Service Control Policies. To start using them, you will first need to enable them. When you enable Service Control Policies, AWS creates a policy called FullAWSAccess, and attaches it to the Root. This default policy allows everything. When you go to the Root, and then to the Policies section, you will find the FullAWSAccess policy attached to it. A policy attached to the Root is inherited by other OUs and accounts in the Organization. Let's create an SCP that stops anyone from disabling security services, like CloudTrail, Config, or GuardDuty. Back to Service Control Policies. I'll click Create Policy and provide a name. I'll call this as Security-baseline, and then I'll provide the JSON document. This document denies key actions on critical services, like CloudTrail. I'll create the policy, and attach it to the Root of the Organization. Now, if a user in any member account tries to stop CloudTrail logging, the explicit deny from this SCP blocks the action, regardless of their local IAM permissions. Let's create one more SCP for compliance purposes. Let's say developers in the Organization are creating untagged EC2 instances in many regions. You want to enforce tagging, and allow instance creation only in specific regions. Let's call this policy as EC2-baseline. Here, I'll provide the JSON document. It contains two blocks. The first block denies the ec2RunInstances Action, if it is outside of these allowed regions. The second block denies the action if the project tag is missing from the instances. I'll create the policy, and attach it to the Root. SCPs are powerful, but an incorrect SCP can cause issues by preventing users from performing the required actions. So it is recommended to never apply a new SCP directly to the Root or a production OU. Instead, create a dedicated Policy Staging OU with a single test account. Attach any new SCP here, and test thoroughly before applying to other OUs or accounts. Also, the effective permission is the intersection of all SCPs inherited from the Root, the OU, and any applied directly to the account. Alright, so that's about SCPs. They help to implement preventive guardrails, ensuring consistent Organization-wide governance. In the next video, we'll explore AWS Control Tower, which takes the concepts we just demonstrated and automates the creation of a secure multi-account environment.

Contents