AWS Cloud Operations Blog
Codify your best practices using service control policies: Part 2
I introduced the fundamental concepts of service control policies (SCPs) in the previous post. We discussed what SCPs are, why you should create SCPs, the two approaches you can use to implement SCPs, and how to iterate and improve SCPs as your workload and business needs change.
In this post, I will discuss how you can think of creating SCPs using constructs from AWS Well-Architected. I will use Organizational Units (OUs) names throughout this blog following the best practices of setting up Organizational Units (OUs) on AWS Organizations.
Creating SCPs based on AWS Well-Architected constructs
Let’s go through some of the key constructs of AWS Well-Architected pillars and see how you can think of creating SCPs. This is by no means an exhaustive list of SCPs covering all of the constructs of AWS Well-Architected.
What operational excellence pillar related SCPs can I apply to my OUs?
The operational excellence pillar focuses on running and monitoring systems to deliver business value, and to continually improve operational processes. Key objectives of the Operational Excellence pillar are:
- Improved observability, including monitoring, log management, and workload telemetry
- Rapid identification and remediation of issues introduced during deployment activities
- Understanding workload health and detect deviation from established patterns of workload usage on production
To adhere to operational excellence principles, protecting resources that monitor your accounts for anomalies or configuration drift is essential.
One such resource is CloudWatch anomaly detection. You may want to prevent member accounts from altering anomaly monitors, alarms, or dashboards, which are issued by administrators (example, where names start with Admin-issued-) at the same time giving flexibility to your developers to create, update, or delete monitors, alarms, or dashboards that they own. You can assign this SCP to your organization’s root , or to your foundational OUs (OU: Infrastructure, OU: Security, and OU: Workloads). Administrators with role name Admin-role- will be able to bypass this SCP and perform changes to monitors, alarms, or dashboards they issue.
SCP: Deny Changes to CloudWatch monitors
Where to attach: At organization root, or infrastructure, security, and workloads OU
In addition, AWS recommends that you create a guardrail to disallow changes to CloudWatch Logs log groups and prevent modifying retention policy. You can do that by attaching the following SCP in your root OU. Extending this SCP to AWS Control Tower created log groups is one of the mandatory guardrails available through AWS Control Tower.
SCP: Deny Changes to CloudWatch Logs
Where to attach: At organization root
AWS Config is a service that assesses, audits, and evaluates configurations of your AWS resources. AWS Config is used by customers as a compliance-as-code framework, and as a detective rules engine. You can attach the following SCP at the root OU to disallow AWS Config changes by member accounts across AWS Config Rules, Conformance Packs, and Multi-Account Multi-Region data aggregation.
SCP: Deny Changes to Config
Where to attach: At organization root
What security pillar related SCPs can I apply to my OUs?
The security pillar focuses on principles that strengthen your cloud security posture by
- implementing least privilege access
- separation of duties
- defense in depth
- data protection in transit and at rest
- incident response
AWS recommends that you define security governance as a multi-layered strategy to manage risk at each level (i.e., foundational features that you inherit from AWS, platform features that you build on AWS, and application/business features that run on your platform).
Each of these layers should define security constants or security invariants. Security invariants are statements that will always hold true for your business and applications. An example of a security invariant is: “only authenticated and authorized users will have access to our API endpoints” or “security canaries will be always running on our CI/CD pipelines”. Each such security invariant defines a control that must be put in place to make that invariant achievable. These controls should form the basis of your desired security SCPs.
Note that determining security invariants and subsequent controls are not a one-time activity. You must stay up-to-date with AWS and industry recommendations and threat intelligence to evolve your threat model and control objectives.
For example, you should easily prevent the accidental removal of accounts from your organization. You can attach the following SCP at your organization root:
SCP: Deny accounts from leaving the organization
Where to attach: At organization root
Make sure that you retire accounts that are unused, such as those from former employees, and then move them to OU: Suspended to protect your business from unwanted changes. Attach an SCP that denies *:* to this OU.
SCP: Deny all actions
Where to attach: Suspended OU (for unused accounts)
For accounts with OU: Sandbox, which your employees may use to learn and do proof of concepts on AWS services, turn off permissions such that users stay within your security guardrails. You can scope these SCPs to apply to all IAM roles except for administrator roles (denoted by name-of-admin-role-to-allow) and to not apply to roles that you as an administrator create. .
SCP: Deny access to IAM with role exception
Where to apply: Sandbox OU
As this OU is used for experimentation and learning purposes, you may also want to restrict accounts within this OU to operations to only particular regions. The following example SCP denies operations outside of eu-central-1 [Europe (Frankfurt)] and eu-west-1 (Europe (Ireland)] regions. You can replace this with any regions of your choosing. This SCP uses the NotAction statement to exempt global services or services with endpoints in us-east-1 [US East (N. Virginia)] so that these global services can be used, but any other requests to services in us-east-1 are denied. When using this SCP, make sure that you verify the list of services and include other global services in the NotAction statement as needed.
SCP: Deny actions outside approved regions
Where to apply: Sandbox OU, or any accounts/OUs where you have regulations that require region restrictions for your resources.
You can protect secrets that you use for your database or applications by using AWS Secrets Manager. Secrets Manager helps you protect database credentials, API keys, OAuth tokens, and other secrets throughout their lifecycle. You can deny member accounts access to delete administrator issued secrets (denoted by secret id: admin-secret-id) except if you are an administrator (denoted by admin-role role which an administrator can assume). You can attach this to OUs where administrator issued resources will make use of the secrets.
SCP: Deny ability to pass IAM roles
Where to attach: Wherever secrets are used (e.g. Workloads OU)
Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, workloads, and data stored in Amazon Simple Storage Service (S3). As an owner of an administrator or delegated administrator GuardDuty account, you can enable and manage GuardDuty for any account in the organization.
You can use the following SCP to prevent changes to GuardDuty configurations by member accounts. You can use detector ID with wildcard as in the following example SCP admin-detector-* to protect administrator issued GuardDuty resources.
SCP: Deny changes to GuardDuty
Where to attach: the organization root
What Cost Management pillar related SCPs can I apply to my OUs?
The cost management pillar focuses on principles of cost optimization and cost awareness. You can implement a culture of cost optimization by treating the cloud as a differentiator and not as you would your on-premises resource fleet. Among the many advantages of AWS, the most important are the ability to pay only for what you use, match your supply (of resources) exactly with the demand (of your business), and its elasticity that helps you pre-plan or over-provision for peak capacity. Accordingly, when thinking about SCPs related to this pillar, you can build a cost control foundation by implementing cost aware policies.
Using AWS Budgets Actions, you can define the action that you want to take in your account when a budget exceeds its threshold (actual or forecasted amounts). This level of control will let you reduce unintentional overspending in your accounts. You can attach the following SCP to your root OU which prevents member accounts from updating Budget actions.
SCP: Deny changes to AWS Budget Actions
Where to apply: the organization root
In addition to the SCP above, you can review “How to manage cost overruns in your AWS multi-account environment,” a blog series that uses an AWS Budget action to set a restrictive SCP on accounts that surpass a budget threshold. This is another use-case that can be applied to your Sandbox OU to ensure you maintain cost controls for your experimental accounts.
AWS Cost Anomaly Detection leverages advanced machine learning (ML) technologies to identify anomalous spend and root causes, so that you can quickly take action. Cost anomaly detection saves you time by vending automated root cause analysis, pin-pointing potential cost drivers, such as usage type (e.g., data transfer cost), specific AWS service, Region, and member account(s). You can attach the following SCP to your root, which prevents member accounts from updating cost anomaly monitors. costmgmtadmin is the only allowed specific IAM role that administrators can use to create and update cost anomaly monitors.
SCP: Limit changes to Cost Anomaly Detection, except when using a specific IAM Role
Where to apply: the organization root
Conclusion
As you have seen above, SCPs provide a centralized mechanism to codify best practices and let your builders innovate while staying within your security guidelines. We have reviewed common constructs from AWS Well-Architected and provided you with some examples that you can further expand for your needs. You should spend time in creating acceptable patterns of permissions based on your business needs, team skills, and security invariants. Iterate often and improve/expand on these patterns as your cloud adoption matures. This will help you build a secure cloud foundation.
To get started with building your own organization, refer to the AWS Organizations Getting Started Guide and create your first SCP.