AWS Cloud Operations & Migrations Blog
Identity Guide – Preventive controls with AWS Identity – SCPs
AWS Identity offers a set of features that let customers apply preventive controls to their AWS environment. This includes AWS Organizations service control policies (SCPs). For you to achieve common preventive controls, SCPs provide preventative enforcement by offering central control over the maximum available permissions for all accounts in your organization. SCPs affect all users and roles in attached accounts, and they can be used to prevent principals from creating resources that do not conform with your requirements. In this blog we will describe how to get started with SCPs, describe common use cases, and describe how to write your own SCPs.
- Overview
- Prerequisites
- Strategies
- Deny List
- Allow List
- Applying an SCP Strategy to an Organization
- Common Use Cases
- Use Case: Limiting Geographic Regions
- Use Case: Prevent Change to Security Controls
- Use Case: Prevent destructive actions against compute, network, or storage
- Use Case: Preventing an account from leaving an organization
- Prevent resource instantiation
- Use Case: Prevent Unencrypted RDS
- Use Case: Prevent VPCs without internet from obtaining internet
- Developing SCPs
- Conclusion
Overview
AWS offers a wide variety of services and features to help you secure your environment. Detective services include Amazon GuardDuty, which is a threat detection service that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation. Features, such as AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. IAM lets you specify who can access which services and resources, and under which conditions. AWS Organizations service control policies (SCPs) can ensure that your accounts stay within the access control guidelines of your organization. For example, you can allow the creation of encrypted RDS instances while preventing unencrypted RDS instances from being launched.
AWS recommends a defense-in-depth approach to securing your environment. This includes a combination of both preventive and detective controls applied at all layers. In this post, we’ll focus on preventive controls with SCPs, which is a feature of AWS Organizations. SCPs let controls be applied at scale across your entire organization. This makes them a powerful tool in helping you meet the security guidelines of your organization. SCPs are identity-based policies that control the actions that an IAM principal can perform.
Prerequisites
SCPs and preventive controls help enforce a standard configuration for all of your resources. Enforcing these standards works best when your organization has a uniform structure and your developers use a consistent development practice. This will help you understand the impact that new SCPs will have on your environment, as well as establish a safe framework to test out policy changes before applying them throughout your organization.
Otherwise, broadly designed preventive controls may slow down developers. You should evaluate the need for legitimate exceptions to preventive controls and adjust your SCP strategy to accommodate developer needs. For example, if you prevent developers from launching unencrypted RDS instances, and that requirement isn’t communicated clearly across the organization, then developers will spend unnecessary time troubleshooting why they can’t launch an RDS unencrypted instance.
Service Control Policies requires AWS Organizations with all features enabled. If you do not use Organizations today, then review the documentation, prescriptive guidance, and whitepaper on how to enable Organizations and organize your AWS environment.
Strategies
It is critical to understand how IAM policy evaluation logic occurs to understand how to apply SCPs. At its most basic level, all IAM evaluations are implicitly denied by default, except for the root user. This is to make sure that customers are in control and can define which permissions are granted to principals in their account. In order to understand if an action is allowed or not, IAM evaluates all applicable policies. If there is an explicit deny, then the action is always denied. If there is an allow and no explicit deny, then the action is permitted as long as it’s not overridden with an implicit deny from a permissions boundary, SCP, or session policy. If there is neither an explicit deny or allow, then the action is denied because of the implicit deny. The exact evaluation logic can be found here.
Start by deciding upon a policy strategy for SCPs. The two strategies available are Deny List and Allow List. By default, the SCP examples here are configured to be applied using a Deny List strategy, and all of the policies in this document have been written for Deny List environments.
Deny List
A deny list strategy starts from a single policy that defines all of the services that you use in your environment. Then, you create a list of configurations that you want to deny and implement SCPs to achieve that. By default, there is a FullAWSAccess policy applied to every Account and OU in the organization. The FullAWSAccess policy allows all services and actions. Since SCPs don’t grant access, this policy allows for any Allow action in an Identity entitlement to grant access. This lets customers apply SCPs in an existing environment in a safe fashion, as by default nothing is denied, and Deny statements must be explicitly written.
Allow List
Note: Do not remove the FullAWSAccess SCP without applying Allow policies first.
An allow list strategy is when you apply SCPs that explicitly permit the services you allow. Start by creating an SCP listing that the services allowed, then remove the AWS managed FullAWSAccess SCP. This strategy blocks any activity that is not specifically listed in your policies. Allow list SCPs do not allow for conditionals, resource elements, or not action statements. Applying this strategy in an existing organization could have unintended consequences, as policies are applied immediately upon change and all services in use will have to be accounted for. Removal of the FullAWSAccess without replacing it with Allow policies will block all access to AWS services.
Deny vs Allow List
The default configuration of AWS Organizations supports using SCPs as deny lists. The example SCPs provided by AWS are developed as deny lists. Deny list SCPs provide greater flexibility and customization, as they allow for conditionals and for specific resources to be specified. Additionally, Deny statements do not need updates as AWS launches new services, as new services aren’t explicitly denied. This makes deny lists easier to maintain. Allow list SCPs are rigid and will not allow for exceptions through the use of conditions. Allow lists provide the ability to define the specific services allowed in an account. This allows you create policy for accounts with well-defined use cases. If you are getting started with SCPs, then starting with a deny list strategy will let you use AWS examples and build exceptions for when an SCP should not apply.
Applying an SCP Strategy to an Organization
After you decide between a deny or allow list strategy, you will identify actions that you want to control in a preventive manner, and where you want to apply them. Determining the actions you wish to control will depend on your control requirements. The examples here will get you started with common control use cases. To determine where to apply these SCPs, you will evaluate where you want the controls enforced, the structure of your Organization, the available policy size, and the attachment quota for SCPs themselves.
Deny statements in SCPs are inherited based on where they are placed in the Organization. Allow statements must be applied at every level in which they should apply. If you apply a deny list SCP to the Organization’s management root, then it will be inherited by all accounts in the organization. Allow statements must be applied at every level in which they apply. The exception to both allow list and deny list SCPs is that SCPs do not affect users or roles in the management account. They only affect the users and roles in the member accounts in your organization, including the member account root.
If you find yourself requiring more SCPs or SCP statements than the allowed quota, then there are several strategies you can use, such as removing SID statements or using wildcards (*) for actions with the same prefix.
Common SCP Use Cases
In the following section we will describe common use cases. This list is not the complete list of example SCPs that AWS makes available, but they do solve common scenarios that our customers work backward from. You can evaluate these examples to work backward from your use cases to develop your policies.
Use Case: Limiting Geographic Regions
You can use SCPs to limit what regions’ resources can be launched and deployed into. If you operate your business in a specific set of AWS regions, and you have a requirement to restrict AWS usage to those regions, then you can employ an SCP to ensure conformance with this requirement.
Start by using an OU to contain the accounts and workloads that have this requirement. This lets you apply (for example) a Europe-only SCP only to the accounts that have this requirement, without impacting other accounts outside of that OU. Once the organization structure has been defined, then the SCP can be developed and applied at the top-most OU that has this requirement. We have an example scp to support the development of blocking regions while providing exemptions for operations in approved global services that can be found here. The following code snippet shows the key components of using a Condition String Not Equals on aws:RequestedRegion.
Use Case: Prevent Change to Security Controls
You can use SCPs to prevent modification to security controls, and to make sure that controls aren’t tampered with or disabled. You can implement these controls to both improve your organization’s defense in-depth strategy and make sure that your security logging and monitoring functions remain enabled.
You can apply these SCPs at the Root OU level to make sure the policy applies to all accounts in your organization. The actions that you apply to this type of policy depend on the controls that you have enabled, and how those controls are configured. For example, if you rely on VPC Flow Logs, Amazon GuardDuty, and AWS Config as a part of your security logging and monitoring strategy, then these example SCPs can be combined to make one policy. The following code snippet shows how multiple examples can be combined into a single policy document:
Use Case: Prevent delete actions against compute, network, or storage
You can use SCPs to prevent delete actions in their AWS accounts to ensure data integrity or assist in incident response.
If you have a non-elastic database deployed in EC2, then you can apply an account level SCP to deny Stop or Terminate actions in the account.
If you are encrypting data with KMS, then you can apply defense in-depth and prevent KMS API calls that would delete KMS keys. This will make sure that your KMS keys are protected from deletion.
If you are performing incident response, then you can use SCPs to block destructive data events. This is a temporary measure to respond to an incident response event and is applied to the level of the organization appropriate for the incident that is being responded to. In this use case, evaluate the services you use that store persistent data and the API Calls that are used to delete data. You can block S3 actions that are associated with deleting objects.
The following code snippet shows how you can combine different services into one policy.
Use Case: Preventing an account from leaving an organization
You can use SCPs to prevent accounts from leaving your organization. This makes sure that member accounts remain within the organization for billing and governance.
Preventive resource instantiation controls
Use Case: Prevent Unencrypted RDS
You can restrict the ability of users from creating unencrypted RDS instances through the use of conditionals in SCPs.
If you have the requirement that all RDS databases are created with encryption, then you can achieve this with an SCP. To do this, create an SCP that uses rds:CreateDBInstance with a boolean of “rds:StorageEncrypted”: “false”. This lets you ensure the at rest data encryption of new RDS instances.
Use Case: Prevent VPCs without internet from obtaining internet
You can restrict VPCs without internet from obtaining internet access to make sure that network controls aren’t bypassed.
If you have an account where networking configuration is established and confirmed to be accurate, then you can attach an SCP to make sure that actions that let VPCs obtain direct internet access are not taken. This example can be found here. The following code snippet shows how several services create the same outcome.
Developing SCPs
AWS provides helpful documentation to help you author your own SCPs. To get started, the Service Authorization Reference provides the information necessary for you to build the Action and Resource sections of a SCP.
The Service Authorization Reference provides the list of Condition keys that are available in the authorization context. These can be used to provide fine-grained authorization controls. The AWS global condition key documentation describes all of the conditions available in the request context used for authorization. The IAM JSON documentation describes how to use conditionals. Combined, you can choose the service condition key and pair it with the global conditional used to specify it.
Let’s walk through an example of how you might use the AWS documentation to help author your preventive controls. For example, you want to prevent unencrypted Amazon Elastic File Systems (EFS) from being created.
Start by reviewing the EFS Service Authorization Reference page. Identify the action used by the service to create a file system, CreateFileSystem. For the resource element, you can save policy space by using a * to have the SCP apply to all EFS resources. Next, review the list of Condition keys available to determine which key, and its type that is used for encryption. The elasticfilesystem:Encrypted key is a Boolean type key. After reviewing the Boolean condition operator, we’re now ready to create our policy:
Conclusion
We have discussed how SCPs work, how to apply SCPs at scale within your organization, common SCPs, and how to build an SCP. This will enable you to raise the security bar of your organization by building preventive controls. This is just the beginning of your journey with AWS Identity and security on AWS. Resources for continuing your journey with Identity include Choosing the right mix of AWS IAM policies for scale, Next-generation permission management, and Use IAM Access Analyzer to preview access before deploying permissions changes
To continue learning more about preventive, detective, and reactive controls on AWS, resources on Control Tower, Guard Duty & Security Hub, and Config are a great place to start.