Full Report
In this guest blog post, learn about six commonly missed AWS 'blind spots' that could lead to risk in your cloud infrastructure.
Analysis Summary
# Best Practices: Six Key AWS Security Blind Spots
## Overview
This document outlines practical security recommendations focused on addressing six often-overlooked risks and missing controls within AWS cloud environments. The focus areas expand beyond common misconfigurations, delving into multi-account strategy enforcement via Service Control Policies (SCPs), infrastructure immutability, serverless/container security, and fostering a robust security culture.
## Key Recommendations
### Immediate Actions
1. **Establish a Formal Multi-Account Structure:** Immediately implement an AWS Organization structure segregating workloads using Organizational Units (OUs) such as Management, Production, Development, Sandbox, Infrastructure, and Security.
2. **Restrict Management Account Usage:** Cease running workloads, development activities, or production operations within the AWS Management Account; reserve it strictly for organizational ownership.
3. **Deploy Service Control Policies (SCPs) as Guardrails:** Begin crafting and deploying SCPs at the OU level to set hard permission ceilings, ensuring foundational security standards (e.g., restricting root user actions) are never violated by IAM policies within the OUs.
4. **Enforce Infrastructure Immutability:** Identify current environments where infrastructure changes are made manually ("snowflake servers") and plan to transition these processes to immutable deployments managed via Infrastructure as Code (IaC).
### Short-term Improvements (1-3 months)
1. **Define and Enforce Network Architecture Separation:** Ensure that Development/Sandbox OUs cannot interact with the Production OU. Centralize network control (VPC management, Transit Gateways) in a dedicated Network Account.
2. **Implement Centralized Logging:** Establish a dedicated Security OU and within it, a Logging Account to centrally store and secure all CloudTrail, VPC Flow Logs, and S3 logs, ensuring these logs cannot be modified by standard workload roles.
3. **Mandate Infrastructure as Code (IaC) Use:** Standardize on IaC tooling (e.g., Terraform, CloudFormation) for all deployments and begin integrating security scanning tools within the CI/CD pipeline to check IaC artifacts *before* deployment.
4. **Address Serverless/Container Risks:** Review existing serverless functions (Lambda) and container images for risky permissions and outdated base images. Begin implementing security scanning in the build phase for all container images.
### Long-term Strategy (3+ months)
1. **Mature SCP Strategy:** Audit and refine SCPs regularly to enforce evolving organizational security mandates (e.g., minimum TLS versions, specific region whitelisting) across all OUs.
2. **Establish Robust Security Tooling Plane:** Deploy necessary security tooling (e.g., vulnerability scanners, centralized configuration management) primarily within the dedicated Tooling Account, ensuring these tools have the necessary permissions via cross-account roles.
3. **Cultivate a Security-First Culture:** Implement mandatory security training focused on cloud-native risks specific to serverless and containers for all engineering staff. Integrate security practice into the evaluation criteria for deployments.
4. **Regularly Assess Shared Responsibility:** Conduct periodic gap analyses to confirm that operational security responsibilities (data protection, access policies, function hardening) are being met, acknowledging that the cloud provider secures the underlying infrastructure.
## Implementation Guidance
### For Small Organizations
- **Focus on Core Structure:** Prioritize setting up AWS Organizations with at least three OUs: Management, Workloads (combining Dev/Prod initially), and Security/Logging.
- **Leverage Free Controls:** Heavily rely on free organizational controls like SCPs to set basic safety rules (e.g., deny actions from root principal) before adopting paid security tools.
- **Adopt SaaS Tools:** Where self-hosting tools becomes complex, favor managed or SaaS security solutions to reduce administrative overhead.
### For Medium Organizations
- **Refine Account Granularity:** Implement the detailed OU structure suggested (Prod, Dev, Sandbox, Infrastructure, Security) to clearly isolate blast radius and ownership.
- **Start IaC Adoption:** Mandate IaC for all *new* infrastructure deployments. Begin retrofitting essential, high-risk resources to IaC standards.
- **Delegate SSO:** Move Single Sign-On (SSO) management to a dedicated SSO Account for centralized identity control.
### For Large Enterprises
- **Advanced SCP Policy Crafting:** Develop complex SCPs with denylist and allowlist combinations to enforce nuanced security boundaries between highly segregated OUs (e.g., ensuring development accounts cannot deploy specific risky services).
- **Integrate Mature CI/CD Security Gates:** Fully integrate security testing (SAST/DAST, Infrastructure Scanning) into automated CI/CD pipelines for both infrastructure and application code, especially for serverless/containerized components.
- **Formalize Governance:** Document the account creation, suspension, and closure processes, utilizing the Suspended OU for lifecycle management of inactive accounts.
## Configuration Examples
*Specific technical configurations were not detailed in the provided text beyond the *concept* of SCPs (JSON policies defining permission ceilings). Full JSON examples are outside the scope of this summary.*
**Conceptual SCP Implementation Guidance:**
1. Create the SCP JSON document defining the desired maximum scope of permissions.
2. Attach the SCP document to the appropriate Organizational Unit (OU).
3. **Crucially:** Test the SCP by attempting an action that should be denied (e.g., an IAM user trying to use a restricted service) within an account under that OU to confirm the permission ceiling is active.
## Compliance Alignment
- **NIST Cybersecurity Framework (CSF):** Aligns with the **Identify** function (understanding the environment through multi-account strategy) and **Protect** function (enforcing guardrails via SCPs and immutable infrastructure).
- **ISO 27001/27017:** Supports concepts of access control (granular IAM/SCPs) and operational security management (centralized logging and auditing).
- **Center for Internet Security (CIS) Benchmarks for AWS:** Directly supports principles related to organizational hierarchy, logging centralization, and permission minimization.
- **AWS Well Architected Framework:** Emphasis on adhering to secure-by-design principles in the architecture phase.
## Common Pitfalls to Avoid
- **Ignoring SCPs:** Treating SCPs as optional or only setting them up once and forgetting them; they must be actively managed as the organization evolves.
- **Running Workloads in the Management Account:** Using the root/management account for business or development tasks, massively increasing the blast radius if compromised.
- **Allowing Manual Configuration Drift:** Failing to adopt infrastructure immutability, leading to "snowflake servers" that are difficult to secure, audit, and reproduce safely.
- **Neglecting Serverless/Container-Specific Security:** Applying traditional security models without addressing unique cloud-native risks related to function permissions, image vulnerabilities, and runtime security.
## Resources
- **AWS Organizations Documentation:** For setting up multi-account structures and applying SCPs.
- **AWS Well Architected Framework:** Guidance for building secure-by-design workloads.
- **Cloud Native Application Protection Platforms (CNAPP):** Tools recommended for detecting and prioritizing risks across cloud services, identity, and infrastructure misconfigurations.