Cloud Governance is the process of defining and creating policies to control costs, minimize security risks, and improve efficiency. One tool for securing AWS is preventative guardrails. Preventive guardrails in AWS are accomplished using AWS Service Control Policies (SCPs). There are limitations of preventive guardrails that limit you from implementing certain rules. We will explore some of those here and describe why they cannot be accomplished.
Types of Rules that are not Possible to Enforce
This list is not inclusive, but here are some examples of different types of rules that are hard or impossible to enforce with SCPs:
- technically hard to enforce from the service side
- depends on timing
- requires multiple API calls to accomplish
- requires a function not controlled by AWS
- controlled by a method other than API call
The Rule is Technically Hard to Enforce
An example rule that is technically hard to enforce is “encryption in-transit must be enabled by selecting ‘In-Transit encryption option’ in EMR Security Configuration.” Even if you do not know anything about EMR, you can probably understand why this would be hard to enforce. EMR is a platform that simplifies running big data frameworks, such as Apache Hadoop and Apache Spark, on AWS. This rule is difficult to implement because the AWS EMR service is based on open source frameworks and different versions have different encryption options. In other words, AWS does not have a single control to enforce encryption in transit.
The Rule depends on timing
“Access Key rotation must be less than 90 days” is a rule that depends on timing. Rules that depend on timing are difficult to implement as preventive guardrails because it is hard to prevent something that requires a future action. SCPs are designed to prevent the user from taking a certain action that is prohibited by policy. An action must be required in the future for a timing-based rule.
The Rule Requires Multiple API Calls
SCPs work on individual API calls. A SCP may list multiple calls and multiple conditions, but if a specific function requires multiple API calls to accomplish then an SCP probably is not the right tool. Here is an example: “Kinesis data stream must use SSE encryption”. The Kinesis API requires you to do first create the stream, then a second API call to enable SSE encryption.
The Rule Requires a Function not Controlled by AWS
“RDS database engines must enforce encryption in transit” is an example of a rule that is outside of the control of AWS. Each database engine (i.e. MySQL, MariaDB, SQL Server, Oracle, PostgreSQL) have different ways to enforce encryption in transit. AWS does have mechanisms in place to enforce this in most cases, such as RDS Parameter Groups. The API does not control it.
The Rule is Controlled by a Method Other than API Call
Amazon Simple Notification Service (SNS) is one such service. SNS has its own access policy language, similar to S3. “‘Everyone’ must not be allowed to publish” and “‘Everyone’ must not be allowed to subscribe” are examples of rules that are controlled by the SNS access policy. Because they are controlled by the SNS access policy, the API does not control them and SCP does not have a condition to test for them.
Final Thoughts on Limitations of Preventive Guardrails in AWS
AWs offers many tools for Cloud Governance. Sometimes, SCPs are not the right tool for the job. In a future blog post, we will explore detective guardrails in more detail.
