Controls with External Policies
This example demonstrates a Control that references an external Policy instead of embedding the policy logic directly within the Control. This approach is beneficial when you need to reuse the same policy logic across multiple Controls.
Control
Explanation of Control Fields
Required:
id: A unique identifier for the Control (e.g.,
aws_access_keys_rotated_x_days
).integration_type: Specifies the environment or platform (e.g.,
aws_cloud_account
) to which this Control applies.policy: References the ID of an external Policy (e.g.,
aws_iam_access_keys_policy
).severity: Indicates the impact level if the Control fails (e.g.,
Critical
,High
,Medium
,Low
,None
).
Recommended:
title: A concise and descriptive name for the Control (e.g., "Access Keys Rotated X Days").
description: A brief explanation of what the Control checks (e.g., "Ensures AWS IAM keys are rotated within a set number of days.").
parameters: Key-value pairs that provide input to the external Policy (required if the Policy uses parameters).
tags: Optional metadata for categorizing or grouping the Control (e.g., relevant AWS services or risk categories).
Policy
Explanation of Policy Fields
Required:
id: The unique identifier for this Policy (e.g.,
aws_iam_access_keys_policy
).language: Specifies the type of logic or query used in the Policy (e.g.,
sql
,rego
).primary_resource: Identifies the primary data source used for the query (e.g.,
aws_iam_access_key
).definition: The query or code block that evaluates compliance.
Recommended:
title: A brief summary of what the Policy checks (e.g., "maximum IAM Access Key age").
description: A brief description of the Policy.
How It All Works Together
Control: Defines the specific compliance requirement (e.g., "IAM keys rotated every 180 days") and references the ID of the corresponding external Policy.
External Policy: Contains the actual query or logic used to evaluate compliance. It can dynamically use the parameters provided by the Control.
Reusability: This external Policy (
aws_iam_access_keys_policy
) can be reused by multiple Controls, each with potentially different parameter values (e.g., 90 days vs. 180 days).
Benefits
By separating the Control (what is being checked) from the Policy (how it is checked), this approach promotes:
Improved Maintainability: Centralized policy definitions make it easier to update and maintain policy logic.
Increased Reusability: Reusing Policies across multiple Controls reduces redundancy and improves efficiency.
Enhanced Scalability: Enables easier management of complex compliance requirements within a growing environment.
This approach facilitates a more robust and scalable "compliance-as-code" strategy within Opencomply.
Last updated