Era of public cloud services like AWS came with numerous beneficial features for companies. Easy and fast infrastructure deployment, scaling business in few clicks, paying for what you use and as you use it, focusing efforts on actual products as managing services is taken care by your provider etc. However, public cloud service came with its own challenges, one of the main issues being inventory and compliance management This is where AWS Config comes into picture. Provided the need for increased interest in security and compliance with standards, it is significant to understand AWS Config which can help any organization to audit these aspects of your business.

AWS Config provides a remarkable way to document the resources and keeps track of changes in configuration. The tool is designed such that it simplifies resource tracking and management. This allows you to organize configurations based on predetermined parameters without complex resource monitoring or without a dedicated database for your configs.

An AWS Config Rule is the representation of the required configuration settings for a specific AWS account or for an AWS resources. If any of the resource violates a rule then AWS Config will flag the rule and associated resource and as non-compliant, and AWS Config will notify you through Amazon SNS.

AWS Config does the following:

• Retrieves configurations of resources in your account
• Retrieves historical configurations resources
• Snapshot of the current configurations of the resources that are in your AWS account
• Evaluates AWS resource configurations for desired settings
• Sends notifications when a resource is created, modified, or deleted
• Shows relationships between resources

There are two types of Config Rules

• AWS Managed Config Rules – These are the customizable, predefined rules provided by AWS by default. There are Config Rules for most of the services such as EC2, VPC, EBS volumes. There are 120 AWS managed Config Rules.
• AWS Config Custom Rules – These allows you to create custom rules that are specific to your team and/or organization. Each of the custom rule is associated with an AWS Lambda function, that contains the instructions that evaluate if your AWS resources comply with the rule.

1. We should enable AWS Config in all regions and accounts.
2. Record the configuration changes to ALL the resource types.
3. Record global resources only in one Region (like IAM).
4. Ensure that we have a secure Amazon S3 bucket for collecting the configuration history and snapshots.
5. Use an AWS S3 bucket from a different account for centralized management of snapshots and history files.
6. Specify an Amazon Simple Notification Service (AWS SNS) topic from another account for centralized management of compliance notifications and configuration.
7. Use Amazon CloudWatch Events to filter the AWS Config notifications and act.
8. Allow Config to record resource configuration changes using AWS Config service linked roles.
9. If you are creating a new IAM role for AWS Config, attach the AWS managed policy AWS_ConfigRole to your IAM role.
10. Set the required permissions for the IAM role assigned to the AWS Config.
11. Limit SNS topic permissions to only allow AWS Config to publish messages to it.
12. Turn on periodic snapshots with a frequency of once per day.
13. Using the AWS CloudTrail Lookup API action, find the API events that occurred in the given timeframe when the configuration change happens.
14. Use the AWS Service Management connector to feed Config data into your own third party ITSM or CMDB solution like ServiceNow or Jira Service desk.
15. Identify resources that are going through most configuration changes on a routine basis to control costs.

There are quite a lot of pre-defined rules within AWS Config, let us have a look at some of the rules which are crucial in most AWS environments. Consider enabling these rules within AWS Config, in case you are just new with the AWS cloud environment or are already utilizing it.

One of the very first things that one should be considering doing when creating a new AWS account is creating an admin user. This Admin user is further used to create everything else needed in the given account. The root user should be locked, and password safely kept away. The root user should never have the AWS access keys, for programmatic access generated. Since root user has unlimited control over the account, losing that user can have very serious consequences. This is the reason why “iam-root-access-key-check” rule is very important.

The rule is very simple; it checks if access keys have been generated for the root user. If access key is generated the rule will be non-compliant. If access key is not generated rule will be compliant. Even if this rule might seem obvious, it is most overlooked. Add this rule as the first step, as soon as the AWS account is up and running.

The “root-account-mfa-enabled” rule is closely related to the “iam-root-access-key-check” rule. This rule is used to ensure that the multi factor authentication is enabled for the root user. Storing the root password safely is still required. This additional step of securing your root password will add a layer of security in protecting the entire AWS environment from an intrusion.

Even if you have a secure storage mechanism in place for the root user information, you will still have numerous users with varying levels of access to your AWS environment. This includes the admins users who probably will have almost complete access like a root account, over the AWS infrastructure and services.

To ensure that your environment and resources are properly protected, best practices mandate that these programmatic access keys, should be strong and undergo a regular rotation in place. This rule will check if the access keys follow certain conditions that make it strong. Along with this if there is a password rotation enabled, we provide an additional layer of security enforced.

One of the most common mistakes that we all make when working in with AWS Cloud Environment is having our S3 buckets publicly accessible. Irrespective of whether we need or not our data to be kept private and secure, ensuring that our buckets are only accessible to those who really need access is of utmost importance. After all, data is the new oil.

There can be exceptions in this aspect as one might need to serve content or data that to be available publicly, or one might use the buckets as a shared platform for others to upload the data. Either way, one should understand the use case, and make sure to run the AWS environment as secure as possible.

This AWS config rule is like the previous one that handles public access to our cloud environment and resources. AWS resources are configured on top of a VPC which in fact is an AWS service that deploys and controls the entire network. Any misconfigurations on the same can easily expose your EC2 instances which are running with a public IP address. Unless this is an explicit business requirement, it is advised to make sure that the EC2 instances are only running with an attached private IP address. AWS config provides a turnkey solution to do this for you rather than checking everything by hand.

Enabling detailed monitoring provides us with data points about our EC2 instance every 1 minute compared to 5 minutes when it is disabled. This feature comes with an additional cost added to you AWS bill. Unless your company is looking to use this feature, we can stick to normal monitoring of the EC2 instances. This rule can be very helpful for cost optimization by ensuring that monitoring is not adding unnecessary costs. This rule can also be helpful to ensure that our AWS environment is only using the optimal monitoring required for the product.