AWS Identity and Access Management (IAM) policies are at the core of access control on AWS. They enable the bundling of permissions, helping to provide effective and modular access control for AWS services. Service control policies (SCPs) complement IAM policies by helping organizations enforce permission guardrails at scale across their AWS accounts.

   <p>The use of access control policies isn’t limited to AWS resources. Customer applications running on AWS infrastructure can also use policies to help control user access. This often involves implementing custom authorization logic in the program code itself, which can complicate audits and policy changes.</p> 
   <p>To address this, AWS developed <a href="https://aws.amazon.com/verified-permissions/" target="_blank" rel="noopener">Amazon Verified Permissions</a>, which helps implement fine-grained authorizations and permissions management for customer applications. This service uses <a href="https://www.cedarpolicy.com/en" target="_blank" rel="noopener">Cedar</a>, an open-source policy language, to define permissions separately from application code.</p> 
   <p>In addition to access control, you can also use policies to help monitor your organization’s individual governance rules for security, operations and compliance. One example of such a rule is the regular rotation of cryptographic keys to help reduce the impact in the event of a key leak.</p> 
   <p>However, manually checking and enforcing such rules is complex and doesn’t scale, particularly in fast-growing IT organizations. Therefore, organizations should aim for an automated implementation of such rules. In this blog post, I will show you how to use policy as code to help you govern your AWS landscape.</p> 
   <h2>Policy as code</h2> 
   <p>Similar to infrastructure as code (IaC), policy as code is an approach in which you treat policies like regular program code. You define policies in the form of structured text files (<em>policy documents</em>), which policy engines can automatically evaluate.</p> 
   <p>The main advantage of this approach is the ability to automate key governance tasks, such as policy deployment, enforcement, and auditing. By storing policy documents in a central repository, you can use versioning, simplify audits, and track policy changes. Furthermore, you can subject new policies to automated testing through integration into a continuous integration and continuous delivery (CI/CD) pipeline. Policy as code thus forms one of the key pillars of a modern automated IT governance strategy.</p> 
   <p>The following sections describe how you can combine different AWS services and functions to integrate policy as code into existing IT governance processes.</p> 
   <h2>Access control – AWS resources</h2> 
   <p>Every request to AWS control plane resources (specifically, AWS APIs)—whether through the <a href="https://aws.amazon.com/console/" target="_blank" rel="noopener">AWS Management Console</a>, <a href="https://aws.amazon.com/cli/" target="_blank" rel="noopener">AWS Command Line Interface (AWS CLI)</a>, or SDK — is authenticated and authorized by IAM. To determine whether to approve or deny a specific request, IAM evaluates both the applicable policies associated with the requesting principal (human user or workload) and the respective request context. These policies come in the form of JSON documents and follow a specific schema that allows for automated evaluation.</p> 
   <p>IAM supports a range of different policy types that you can use to help protect your AWS resources and implement a least privilege approach. For an overview of the individual policy types and their purpose, see <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html" target="_blank" rel="noopener">Policies and permissions in IAM</a>. For some practical guidance on how and when to use them, see <a href="https://aws.amazon.com/blogs/security/iam-policy-types-how-and-when-to-use-them/" target="_blank" rel="noopener">IAM policy types: How and when to use them</a>. To learn more about the IAM policy evaluation process and the order in which IAM reviews individual policy types, see <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html" target="_blank" rel="noopener">Policy evaluation logic</a>.</p> 
   <p>Traditionally, IAM relied on <a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/access-control-types.html" target="_blank" rel="noopener">role-based access control (RBAC)</a> for authorization. With RBAC, principals are assigned predefined roles that grant only the minimum permissions needed to perform their duties (also known as a <em>least privilege approach</em>). RBAC can seem intuitive initially, but it can become cumbersome at scale. Every new resource that you add to AWS requires the IAM administrator to manually update each role’s permissions – a tedious process that can hamper agility in dynamic environments.</p> 
   <p>In contrast, <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html" target="_blank" rel="noopener">attribute-based access control (ABAC)</a> bases permissions on the attributes assigned to users and resources. IAM administrators define a policy that allows access when certain tags match. ABAC is especially advantageous for dynamic, fast-growing organizations that have outgrown the RBAC model. To learn more about how to implement ABAC in an AWS environment, see <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html" target="_blank" rel="noopener">Define permissions to access AWS resources based on tags</a>.</p> 
   <p>For a list of AWS services that IAM supports and whether each service supports ABAC, see <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html" target="_blank" rel="noopener">AWS services that work with IAM</a>.</p> 
   <h2>Access control – Customer applications</h2> 
   <p>Customer applications that run on AWS resources often require an authorization mechanism that can control access to the application itself and its individual functions in a fine-grained manner.</p> 
   <p>Many customer applications come with custom authorization mechanisms in the application code itself, making it challenging to implement policy changes. This approach can also hinder monitoring and auditing because the implementation of authorization logic often differs between applications, and there is no uniform standard.</p> 
   <p>To address this challenge, AWS developed <a href="https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/what-is-avp.html" target="_blank" rel="noopener">Amazon Verified Permissions</a> and the associated open-source policy language <a href="https://www.cedarpolicy.com/en" target="_blank" rel="noopener">Cedar</a>. Amazon Verified Permissions replaces the custom authorization logic in the application code with a simple <span>IsAuthorized</span> API call, so that you can control and monitor authorization logic centrally by using Cedar-based policies. To learn how to integrate Amazon Verified Permissions into your applications and define custom access control policies with Cedar, see <a href="https://aws.amazon.com/blogs/security/how-to-use-amazon-verified-permissions-for-authorization/" target="_blank" rel="noopener">How to use Amazon Verified Permissions for authorization</a>.</p> 
   <h2>Compliance</h2> 
   <p>In addition to access control, you can also use policies to help monitor and enforce your organization’s individual governance rules for security, operations and compliance. <a href="https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html" target="_blank" rel="noopener">AWS Config</a> and <a href="https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html" target="_blank" rel="noopener">AWS Security Hub</a> play a central role in compliance because they enable the setup of multi-account environments that follow best practices (known as <a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html" target="_blank" rel="noopener">landing zones</a>). AWS Config continuously tracks resource configurations and changes, while Security Hub aggregates and prioritizes security findings. With these services, you can create controls that enable automated audits and conformity checks. Alternatively, you can also choose from ready-to-use controls that cover individual compliance objectives such as encryption at rest, or entire frameworks, such as PCI-DSS and NIST 800-53.</p> 
   <p><a href="https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html" target="_blank" rel="noopener">AWS Control Tower</a> builds on top of AWS Config and Security Hub to help simplify governance and compliance for multi-account environments. AWS Control Tower incorporates additional controls with the existing ones from AWS Config and Security Hub, presenting them together through a unified interface. These controls apply at different resource life cycle stages, as shown in Figure 1, and you define them through policies.</p> 
   <div id="attachment_32675" class="wp-caption aligncenter"> 
    <img aria-describedby="caption-attachment-32675" src="https://infracom.com.sg/wp-content/uploads/2023/12/img1-1.png" alt="Figure 1: Resource life cycle" width="780" class="size-full wp-image-32675"> 
    <p id="caption-attachment-32675" class="wp-caption-text">Figure 1: Resource life cycle</p> 
   </div> 
   <p>The controls can be categorized according to their behavior:</p> 
   <ul> 
    <li><strong>Proactive controls</strong> scan IaC templates before deployment to help identify noncompliance issues early.</li> 
    <li><strong>Preventative controls</strong> restrict actions within an AWS environment to help prevent noncompliant actions. For example, these controls can help prevent deployment of large<a href="https://aws.amazon.com/ec2/" target="_blank" rel="noopener"> Amazon Elastic Compute Cloud (Amazon EC2)</a> instances or restrict the available AWS Regions for some users.</li> 
    <li><strong>Detective controls</strong> monitor deployed resources to help identify noncompliant resources that proactive and preventative controls might have missed. They also detect when deployed resources are changed or drift out of compliance over time.</li> 
   </ul> 
   <p>Categorizing controls this way allows for a more comprehensive compliance framework that encompasses the entire resource life cycle. The stage at which each control applies determines how it may help enforce policies and governance rules.</p> 
   <p>With AWS Control Tower, you can enable hundreds of preconfigured security, compliance, and operational controls through the console with a single click, without needing to write code. You can also implement your own custom controls beyond what AWS Control Tower provides out of the box. The process for implementing custom controls varies depending on the type of control. In the following sections, I will explain how to set up custom controls for each type.</p> 
   <h3>Proactive controls</h3> 
   <p>Proactive controls are mechanisms that scan resources and their configuration to confirm that they adhere to compliance requirements before they are deployed. AWS provides a range of tools and services that you can use, both in isolation and in combination with each other, to implement proactive controls. The following diagram provides an overview of the available mechanisms and an example of their integration into a CI/CD pipeline for <a href="https://aws.amazon.com/cdk/" target="_blank" rel="noopener">AWS Cloud Development Kit (CDK)</a> projects.</p> 
   <div id="attachment_32676" class="wp-caption aligncenter"> 
    <img aria-describedby="caption-attachment-32676" loading="lazy" src="https://infracom.com.sg/wp-content/uploads/2023/12/img2-1.png" alt="Figure 2: CI/CD pipeline in AWS CDK projects" width="1458" height="731" class="size-full wp-image-32676"> 
    <p id="caption-attachment-32676" class="wp-caption-text">Figure 2: CI/CD pipeline in AWS CDK projects</p> 
   </div> 
   <p>As shown in Figure 2, you can use the following mechanisms as proactive controls:</p> 
   <ol> 
    <li>You can validate artifacts such as IaC templates locally on your machine by using the <a href="https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html" target="_blank" rel="noopener">AWS CloudFormation Guard CLI</a>, which facilitates a <a href="https://en.wikipedia.org/wiki/Shift-left_testing" target="_blank" rel="noopener">shift-left testing</a> strategy. The advantage of this approach is the relatively early testing in the deployment cycle. This supports rapid iterative development and thus reduces waiting times. <p>Alternatively, you can use the <a href="https://github.com/cdklabs/cdk-validator-cfnguard" target="_blank" rel="noopener">CfnGuardValidator</a> plugin for AWS CDK, which integrates CloudFormation Guard rules into the AWS CDK CLI. This streamlines local development by applying policies and best practices directly within the CDK project.</p> </li> 
    <li>To centrally enforce validation checks, integrate the CfnGuardValidator plugin into a CDK CI/CD pipeline.</li> 
    <li>You can also invoke the CloudFormation Guard CLI from within <a href="https://aws.amazon.com/codebuild/" target="_blank" rel="noopener">AWS CodeBuild</a> <a href="https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html" target="_blank" rel="noopener">buildspecs</a> to embed CloudFormation Guard scans in a CI/CD pipeline.</li> 
    <li>With <a href="https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks.html" target="_blank" rel="noopener">CloudFormation hooks</a>, you can impose policies on resources before CloudFormation deploys them.</li> 
   </ol> 
   <p>AWS CloudFormation Guard uses a policy-as-code approach to evaluate IaC documents such as <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="noopener">AWS CloudFormation</a> templates and <a href="https://www.terraform.io/" target="_blank" rel="noopener">Terraform</a> configuration files. The tool defines validation rules in the Guard language to check that these JSON or YAML documents align with best practices and organizational policies around provisioning cloud resources. By codifying rules and scanning infrastructure definitions programmatically, CloudFormation Guard automates policy enforcement and helps promote consistency and security across infrastructure deployments.</p> 
   <p>In the following example, you will use CloudFormation Guard to validate the name of an <a href="https://aws.amazon.com/s3/" target="_blank" rel="noopener">Amazon Simple Storage Service (Amazon S3)</a> bucket in a CloudFormation template through a simple Guard rule:</p> 
   <h4>To validate the S3 bucket</h4> 
   <ol> 
    <li>Install CloudFormation Guard locally. For instructions, see <a href="https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html" target="_blank" rel="noopener">Setting up AWS CloudFormation Guard</a>.</li> 
    <li>Create a YAML file named <span>template.yaml</span> with the following content and replace <span></span> with a bucket name of your choice (this file is a CloudFormation template, which creates an S3 bucket): 
     <div class="hide-language"> 
      <pre class="unlimited-height-code"><code class="lang-text">Resources:

S3Bucket:
Type: ‘AWS::S3::Bucket’
Properties:
BucketName: ‘‘

    <li>Create a text file named <span>rules.guard</span> with the following content: 
     <div class="hide-language"> 
      <pre class="unlimited-height-code"><code class="lang-text">rule checkBucketName {
Resources.S3Bucket.Properties.BucketName == '<span></span>'

}