Cloud operations with the control plane leverage a large amount of API’s and permissions behind the scenes abstracted from the end users. To continuously address these changes and states in your environment natively you can use AWS Config. Visually the set up for this in a simple configuration is shown below to illustrate the service and how it operates.
AWS Config Components
From a high level we can infer that events such as activities in our AWS resources that are being monitored are recorded meaning if this deviates from the selected rules or conformance packs we are aware of this. The AWS Config can be broken down to the following Configuration Items and Configuration Recorder and Configuration History. While many other components are abstracted from this such as rules and conformance packs we will cover some of the core areas.
Since we’ve established some of the components its important to have these broken down further visually to briefly describe the components.
For compliance especially on tracking changes to our resources and accounts we should have a audit trail the purpose and use of configuration history is that component. For just about any resource deployed in a virtualized environment its well known to track resources with tags or attributes such as labels, this isn’t just rooted in the management from a security perspective but to financial ops to minimize costs.
AWS Config Rules
When you think of rules in the context of AWS config you can see similarities to Azure Policy these are essentially desired configuration settings for specific resources or the entire AWS account. It’s also to note if AWS Config flags a resource that is non-compliant this will push our evaluation results not necessarily change the setting, outside of a remediate task if its defined. Think of this service in a detective measure with the audit capability of four areas Compliant, Non-Compliant, Error and Not_Applicable. Similar to other hyperscalers this allows the following you can use components that are managed by AWS these are known as AWS Config Managed Rules they are pre-defined and most suited to a large amount of use-cases. While in this blog we won’t get into the full weeds I’ve set up AWS Config in my account with a few parameters to populate like everything in the cloud it has a cost so if you’re following along remember to delete these resources.
If you run through set-up with a S3 bucket and SNS topic defined along with the permissions you can apply the rules to start being evaluated. The visual is to show the outcome of some of the findings notice this is focused on compliance of various controls throughout the organization as a evaluation and let you know directly where the resource is at.
Additionally if we drill into a finding we are greeted with a brief description and timestamp when it was evaluated notice we can also have this re-evaluate if we want to check it again.
To extend the findings the rules you have that are controls that you’re validating conditions on you can select certain remediation based on automatic remediation, manual remediation. So for instance in this check on the actions this can be configured as the following as an example.
So when this rule is evaluated if it meets a certain criteria that fails we can assign remediation as a result of the finding. This feels eerily similar to how we have policies and constraints broadly on control planes of other CSP’s with some conditions if something does occur what do we want to happen.
Its also important to note that the recorder has to be on in the image below I’ve selected to turn the recorder off to avoid the additional costs.
The recorded resource types will state specifically what is being recorded and the frequency you can have this either continuous or daily. The pricing is fairly minimal but at scale with resources this can be broken down simply by the following notice that this is based on US East.
Summary
AWS Config can serve as auditor of your AWS resources while this is just scratching the surface of the use of this tool you can think of conformance packs as larger blueprints of rules based on operational best practices. These used to be called blueprints in Azure but are not broadly defined as standards that work in a similar fashion. Just keep in mind this is to evaluate compliance of resources that are monitored with rules that are defined across the organization and primarily act as a detective system that can be referenced for further investigation. This can work for larger organization with use of security centralized to one account and the use of aggregators its also noted the additional queries is to search for resources across various accounts as your organization expands to other environments.