Cloud Security Compliance
Implement and automate compliance frameworks like SOC 2, HIPAA, and PCI DSS using policy-as-code.
What You'll Learn
- How to translate abstract compliance controls into concrete policy rules.
- Writing policies for common SOC 2, HIPAA, and PCI DSS requirements.
- Popular tools for implementing compliance-as-code.
- Techniques for continuous control monitoring and evidence collection.
- Building a compliance-as-code workflow that satisfies auditors.
🏷️ Topics Covered
📋 Prerequisites
- In-depth knowledge of at least one compliance framework (SOC 2, HIPAA, PCI DSS, etc.).
- Proficiency in a policy-as-code language (Rego or Sentinel).
- Strong understanding of cloud security concepts (IAM, networking, encryption).
- Experience with cloud provider logging and monitoring services.
💡 From Manual Checklists to Automated Enforcement
Traditional compliance involves tedious, point-in-time manual audits. Compliance-as-code transforms this by making compliance an automated, continuous part of your development lifecycle. This not only reduces audit fatigue but also provides a much stronger, verifiable security posture.
Sox Compliance Automation: Translating Controls to Policy Code
The core of compliance-as-code is the translation of high-level controls from frameworks like PCI DSS into specific, testable policy rules. This process bridges the gap between human-readable legal requirements and machine-executable logic.
Traditional Audit
- Periodic (quarterly/annual)
- Manual evidence gathering
- High-stress, time-consuming
- Reactive findings
- Snapshot-in-time view
Compliance-as-Code
- Continuous (real-time)
- Automated evidence collection
- Integrated into daily workflow
- Proactive prevention
- Always-on visibility
The Translation Process
Let's walk through a tangible example of translating a control into code.
The Control
PCI DSS Req 1.2.1: "Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment..."
Technical Interpretation
This means firewalls (Security Groups, NSGs) should not have wide-open inbound rules (like `0.0.0.0/0`) especially for management ports like SSH (22) or RDP (3389).
Identify Target Data
The policy needs to inspect the `ingress` rules of `aws_security_group` resources, looking at `cidr_blocks` and `from_port`/`to_port` fields.
Write the Policy
Implement a policy that denies any security group rule where `cidr_blocks` contains `0.0.0.0/0` and the port range includes 22 or 3389.
Hipaa Compliance Policy Automation: Real-World Examples
Let's examine how to write policies for controls found in major compliance frameworks using specific policy languages.
SOC 2: Access Control (CC6.1)
This control requires that access to systems is logically restricted. A common policy is to ensure Multi-Factor Authentication (MFA) is enabled for all IAM users with console access.
📋 Rego Policy for IAM MFA
package soc2.cc6_1
# Check each IAM user
deny[msg] {
some user in input.aws_iam_users
# Check if the user has a password and does NOT have MFA enabled
user.has_console_password == true
user.mfa_enabled == false
msg := sprintf("IAM User '%s' has console access but does not have MFA enabled.", [user.name])
}HIPAA: Audit Controls (§ 164.312(b))
This rule requires logging and auditing of access to systems containing electronic Protected Health Information (ePHI). A key policy is to ensure database logging is enabled on RDS instances.
🛡️ Sentinel Policy for RDS Logging
This policy checks a Terraform plan to ensure all new RDS instances have logging enabled.
import "tfplan/v2" as tfplan
# List of logs required for HIPAA auditing
required_logs = ["audit", "error", "general", "slowquery"]
# Find all RDS instances being created
rds_instances = filter tfplan.resource_changes as _, rc {
rc.type is "aws_db_instance" and rc.change.actions is ["create"]
}
# Main rule: check if all required logs are enabled
main = rule {
all rds_instances as _, rds {
all required_logs as _, log_type {
log_type in rds.change.after.enabled_cloudwatch_logs_exports
}
}
}Compliance Automation Tools and Frameworks
Several tools can help you implement a robust compliance-as-code strategy. These tools often specialize in different phases of the lifecycle, from CI/CD checks to live environment scanning.
Open Policy Agent (OPA)
A general-purpose, open-source policy engine. Use it with its native language Rego to enforce policies on JSON/YAML, making it ideal for checking Terraform plans, Kubernetes manifests, and API requests.
HashiCorp Sentinel
A policy-as-code framework embedded into HashiCorp's Enterprise products, including Terraform Cloud. It's excellent for enforcing fine-grained controls during the `terraform plan` phase.
Cloud Custodian
An open-source, stateless rules engine for managing public cloud accounts. It uses simple YAML policies to scan live environments, detect violations, and perform automated remediation.
Steampipe
An open-source tool that uses SQL to query cloud APIs. You can write compliance checks as SQL queries, making it accessible for those familiar with database querying to perform stateless scans.
PCI DSS Automated Compliance: Evidence Collection Best Practices
A major benefit of compliance-as-code is the ability to automatically generate evidence for auditors. Your policy tooling should be your primary source of compliance artifacts, providing an immutable and verifiable record of your control effectiveness.
Policy Evaluation Logs
The logs from your policy engine are direct evidence. A log showing a `deny` for a non-compliant resource, followed by a `pass` after the developer fixed it, is a perfect audit trail of a control operating effectively.
Continuous Monitoring Dashboards
Use tools like OPA's decision log exporters to feed compliance data into a monitoring system (like Prometheus/Grafana or Splunk). A dashboard showing "100% compliance for Control PCI 1.2.1 over the last 90 days" is powerful evidence.
Version-Controlled Policies
The policies themselves, stored in Git, are evidence of your *intended* state. The commit history shows auditors how your controls have evolved, who approved the changes, and when they were implemented.
💡 Regulatory Compliance as Code: Implementation Best Practices
Key Takeaways
- Map Each Policy to a Control: In your policy code (e.g., in a comment or metadata), explicitly reference the compliance control it enforces (e.g., `// Enforces PCI DSS Req 3.4`). This makes it easy for auditors to connect your code to their requirements.
- Focus on Prevention, then Detection: Prioritize integrating compliance policies into your CI/CD pipeline to *prevent* non-compliant infrastructure. Use periodic scans of your live environment to *detect* any drift.
- Automate Evidence, Don't Just Log: Don't just store logs. Build systems that can automatically generate a report showing the status of all policies mapped to a specific framework (e.g., "Show me the status of all HIPAA security rule policies").
- Treat Your Compliance Framework as a Test Suite: Think of a framework like SOC 2 as a set of tests. Your goal is to have a policy for each applicable control and ensure they are all passing continuously.
- Engage Auditors Early: Show your auditors your compliance-as-code setup. Walk them through how a policy prevents a violation. This builds trust and can significantly streamline the audit process.