2. Access Controls: Organization-Wide Policy Enforcement

Access controls prevent issues through organization-level policies that block risky actions at the API level. These policies enforce across all cloud accounts, regions, and users. They create boundaries on what's possible regardless of how resources get created-whether through IaC, console, CLI, SDK, or third-party tools.

AWS Service Control Policies, Azure Policy, and GCP Organization Policies are the primary access control mechanisms. These policies attach to organizational units, subscriptions, or folders and enforce on all child accounts. A policy preventing public S3 bucket creation applies to every account in the organization. No one can bypass it. The cloud platform enforces it automatically before any resource creation succeeds.

Access controls operate at the API level. When a user or service attempts an API call, the cloud platform evaluates organization policies before allowing the action. Policies can deny specific actions entirely, require certain parameters be present, or enforce conditions that must be met. Denied actions fail immediately with clear error messages about why the policy blocked them.

The power of access controls comes from their universality and enforceability. Build controls only scan IaC templates. Access controls enforce on every API call regardless of source. A developer using the console gets blocked the same as an IaC deployment or an automated script. There's no way around them. The only path is exception policies or removing the restriction entirely.

Access controls excel at preventing clearly risky actions that should rarely or never happen. Disabling CloudTrail logging, making S3 buckets fully public, deploying to unauthorized regions, creating root access keys, or deleting security resources are examples of actions access controls prevent effectively. The organization policy itself becomes the preventive control. Its existence proves enforcement.

Writing effective access control policies requires understanding cloud APIs and policy evaluation logic. Policies that are too restrictive block legitimate work and generate exception requests. Policies that are too permissive fail to prevent the targeted risks. Finding the right balance requires iteration, simulation against historical audit logs, and collaboration with teams to understand their legitimate needs.

Organizations deploying access controls typically follow a maturity progression. Initial policies prevent the most critical, rarely-legitimate risks-disabling security logging, making data fully public, or deploying to completely unauthorized regions. As maturity grows, policies expand to enforce encryption requirements, mandate specific security configurations, and prevent broader categories of risky behavior. Exception processes become systematic with documented justifications and expiration dates.

Access controls create organizational-level boundaries that build controls can't provide. Even if IaC scanning misses an issue, even if a developer bypasses build controls by deploying manually, access controls enforce at the API level. This makes access controls the most powerful layer of preventive controls as they're the hardest to bypass and enforce most comprehensively.