Access Logging Guardrails

Overview

Access logging guardrails allow administrators to enable and store access logging information for cloud resources. Access logs are great to help understand the nature of requests to a particular resource, though it must be noted that they are often not guaranteed delivery. From a best practices security standpoint, it is almost always recommended to have access logging configured if there is an option to do so.

Guardrails Access Logging policies can be found directly under the service in the hierarchy:

• {Provider} > {service} > {resource} > Access Logging

Below is the list of allowed values for a generic Access Logging policy. This is not comprehensive as different resource types might have slightly different verbage:

    Skip
    Check: Disabled
    Check: Enabled
    Check: Enabled to Access Logging > Bucket
    Enforce: Disabled
    Enforce: Enabled to Access Logging > Bucket

The Access Logging guardrail has a number of policy sub-settings to determine what Guardrails is checking for. The format of these policy types is {Provider} > {service} > {resource} > Access Logging > {Items}. For example:

    {Provider} > {service} > {resource} > Access Logging > Bucket
    {Provider} > {service} > {resource} > Access Logging > Key Prefix

Policy Types Description

Notes:

• The AWS > S3 > Bucket > Access Logging control will skip any buckets that are created as part of the AWS > Turbot > Logging > Bucket stack.
• For S3 access logs, the target bucket must be in the same region as the source bucket.
• Server access logs are delivered to the target bucket by a delivery account called the Log Delivery group. The S3 log delivery group must have access to write objects and read bucket ACL.
• Similarly for EC2 load balancers, the bucket must have proper access granted. AWS provides documentation for Application Load Balancers (ALB), Network Load Balancers (NLB), and Classic Load Balancers for prerequisite steps prior to enabling Access Logging.
• For more details refer Enabling Amazon S3 server access logging.
• Access log requests are delivered on a best-effort basis. AWS recommends that you use access logs to understand the nature of the requests, not as a complete accounting of all requests. It is good to keep this in mind when dealing with access logging in other cloud providers, too.

Access Logging for Guardrails Managed Buckets

Guardrails provides policies to allow the automatic creation of logging buckets for use in services that require them. Guardrails logging bucket creation is managed by a stack, AWS > Turbot > Logging > Bucket, and is targeted at AWS regions. For more information, refer Stacks and Configured guardrail.

The Guardrails Access Logging guardrail has a number of policy sub-settings to determine the attributes of the access logging check. The format of these policy types is {Provider} > Turbot > Logging > Bucket > Access Logging > {Items}:

    {Provider} > Turbot > Logging > Bucket > Access Logging
    {Provider} > Turbot > Logging > Bucket > Access Logging > Bucket
    {Provider} > Turbot > Logging > Bucket > Access Logging > Key Prefix

Example family of policies:

Example policy values:

# AWS > Turbot > Logging > Bucket > Access Logging - Disabled - Enabled

Note:

• Server access logs are delivered to the target bucket by a delivery account called the Log Delivery group. The S3 log delivery group must have access to write objects and read bucket ACL.