alex_aldo - Fotolia
The AWS cloud comes with a wide range of features and capabilities, but from the very beginning, security has been a constant worry for users.
AWS' shared responsibility model clearly defines the responsibilities of cloud users and AWS for the protection of data in the cloud. Users are responsible for the security of any application, data or OS they run in the cloud, while AWS is responsible for the security of the underlying compute, storage and other infrastructure services. However, even with these roles defined, many enterprises still have a false sense of security.
Public clouds offer plenty of entry points for an outside attack, but often, the greatest dangers are human mistakes made within the environment. There are many ways to protect an AWS deployment -- both from malicious attacks and the ignorance of your own employees -- including AWS Config and its managed rules.
Overview of AWS Config managed rules
Admins use AWS Config to audit and monitor configuration changes in their cloud environment. But, most importantly, Config enables IT teams to set defined AWS resource configurations and then alerts them via Simple Notification Service to any modifications that don't match their predefined configuration rules. When admins activate these rules, Config will continually monitor resources and compare them to the set conditions.
Admins can choose to create custom rules or use Config managed rules, which are predefined based on compliance best practices, yet customizable. The AWS Config console provides a list of all available managed rules -- there are over 84 of them, currently -- with brief explanations of their functions. Managed rules require admins to enter a few configuration parameters, such as a specific instance type to monitor, but are managed by AWS.
Get started with these 6 managed rules
Here's a look at 6 common Config managed rules to help secure an AWS environment.
S3 bucket public read and write prohibited
With these two rules in place, AWS Config will scan for S3 buckets that allow for public read and write access. If buckets are publicly available, then an outside party can gain unwanted access to a business's critical data -- a potentially costly risk. These two rules are musts for any S3 users, unless they require publicly accessible buckets.
These managed rules are listed in the AWS console as s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited.
RDS instance public access check
Similarly to the S3 bucket rule for public access, Relational Database Service (RDS) instances should only be accessible from within a private environment to prevent against potentially harmful actors. This managed rule checks if the publiclyAccessible field in the RDS instance configuration is set to true -- if it is, the rule will not be compliant.
The identifier for this managed rule is rds-instance-public-access-check.
VPC default security group closed
If an admin does not specify a security group for an Amazon Virtual Private Cloud, it is assigned to a default group, which can open up the VPC to inbound or outbound traffic. This can become a security issue in certain situations, as it might provide unwanted access. This Config rule protects from these VPC security vulnerabilities.
This managed rule is listed as vpc-default-security-group-closed.
Access keys rotated
It's critical to follow Identity and Access Management (IAM) best practices, which include access key rotation. Without regularly rotating keys, they are more prone to become compromised. This AWS Config managed rule checks if there are any active access keys that haven't been rotated within the number of days specified so admins can ensure both security and that they comply with their business's requirements.
To use this rule, look for the access-keys-rotated identifier.
IAM root access key check
It's a bad security practice to have an active access key for an AWS account root user, as it leads to the risk of the key falling into the wrong hands. Instead, rely on admin users to perform any task that requires elevated privileges.
This managed rule checks for the existence of the root user access key and only returns a compliant result if Config doesn't find one. The identifier in the console is iam-root-access-key-check.
AWS Config pricing
AWS has changed the pricing model for AWS Config, which takes effect Aug. 1, 2019. Config will follow a monthly pay-per-use model based on the number of rule evaluations users run each month. In the older pricing model, users were charged a flat rate for the active Config rules they ran.