[{"data":1,"prerenderedAt":87},["ShallowReactive",2],{"content-svc-lambda-guides-governance-4-detective-config":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":10,"menu":11,"menuType":81,"isCollapseableMenu":14,"nextDocItem":51,"previousDocItem":38,"contributorPaths":82,"contentName":86,"slug":50,"readingTime":25},"\u003Cp>In addition to proactive evaluation, AWS Config can also reactively detect resource deployments and configurations that do not comply with your governance policies. This is important as governance policies are always evolving as your organization learns and implements new best practices.\u003C\u002Fp>\n\u003Cp>Consider a scenario where you set a brand new policy when deploying or updating Lambda functions: All Lambda functions must always use a specific, approved Lambda layer version. You can configure AWS Config to monitor new or updated functions for layer configurations. If it detects a function that is not using an approved layer version, it flags the function as a non-compliant resource. You can optionally configure AWS Config to auto-remediate the resource by specifying a remediation action using an AWS Systems Manager Automation document. For example, you could write an automation document in Python using the AWS SDK for Python (boto3), which updates the non-compliant function to point to the approved layer version. Thus, AWS Config serves as both a detective and corrective control, automating compliance management.\u003C\u002Fp>\n\u003Cp>Let us break down this entire process in 3 important phases to implement:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F4-detective-config-phases.png\" alt=\"4-detective-config-phases\">\u003C\u002Fp>\n\u003Ch3>Phase 1: Identify Access Resources\u003C\u002Fh3>\n\u003Cp>You start by first activating AWS Config across your accounts and configuring it to record AWS Lambda functions. This allows AWS Config to observe when Lambda functions are created or updated. You can then configure \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fconfig\u002Flatest\u002Fdeveloperguide\u002Fevaluate-config_develop-rules_cfn-guard.html\">custom policy rules\u003C\u002Fa> to check for specific policy violations, which use CloudFormation Guard syntax. CloudFormation Guard rules take the following general form:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>rule name when condition { assertion }\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Below is a sample rule that checks to ensure that a layer is not set to an old layer version:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>rule desiredlayer when configuration.layers !empty {\n    some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Lets understand the rule syntax and structure:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Rule name\u003C\u002Fstrong>: The name of the rule in the provided example is \u003Ccode>desiredlayer\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Condition\u003C\u002Fstrong>: This clause specifies the condition under which the rule should be checked. In the provided example, the condition is \u003Ccode>configuration.layers !empty\u003C\u002Fcode>. This means the resource should be evaluated only when the \u003Ccode>layers\u003C\u002Fcode> property in the configuration isn't empty.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Assertion\u003C\u002Fstrong>: After the when clause, an assertion determines what the rule checks. The assertion \u003Ccode>some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn\u003C\u002Fcode> checks if any of the Lambda layer ARNs do not match the \u003Ccode>OldLayerArn\u003C\u002Fcode> value. If they do not match, the assertion is true and the rule passes; otherwise, it fails.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Ccode>CONFIG_RULE_PARAMETERS\u003C\u002Fcode> is a special set of parameters that is configured with the AWS Config rule. In this case, \u003Ccode>OldLayerArn\u003C\u002Fcode> is a parameter inside \u003Ccode>CONFIG_RULE_PARAMETERS\u003C\u002Fcode>. This allows users to provide a specific ARN value that they consider old or deprecated, and then the rule checks if any Lambda functions are using this old ARN.\u003C\u002Fp>\n\u003Ch3>Phase 2: Visualize and Design\u003C\u002Fh3>\n\u003Cp>Since AWS Config is now activated and configured to record Lambda functions, it gathers configuration data and stores that data in S3 buckets. You can use \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fathena\u002F\">Amazon Athena\u003C\u002Fa> to query this data directly from your S3 buckets. With Athena, you can aggregate this data at the organizational level, generating a holistic view of your resource configurations across all your accounts. To set up aggregation of resource configuration data, refer to this Cloud Operations and Management \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmt\u002Fvisualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight\u002F\">blog post\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Below is a sample Athena query to identify all Lambda functions using a particular layer ARN:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>WITH unnested AS (\n  SELECT\n    item.awsaccountid AS account_id,\n    item.awsregion AS region,\n    item.configuration AS lambda_configuration,\n    item.resourceid AS resourceid,\n    item.resourcename AS resourcename,\n    item.configuration AS configuration,\n    json_parse(item.configuration) AS lambda_json\n  FROM\n    default.aws_config_configuration_snapshot,\n    UNNEST(configurationitems) as t(item)\n  WHERE\n    "dt" = 'latest'\n    AND item.resourcetype = 'AWS::Lambda::Function'\n)\n\nSELECT DISTINCT\n  region as Region,\n  resourcename as FunctionName,\n  json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,\n  json_extract_scalar(lambda_json, '$.timeout') AS timeout,\n  json_extract_scalar(lambda_json, '$.version') AS version\nFROM\n  unnested\nWHERE\n  lambda_configuration LIKE '%arn:aws:lambda:us-east-1:01234567890:layer:AnyGovernanceLayer:24%'\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Below are results from the query:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F4-detective-config-result.png\" alt=\"4-detective-config-result\">\u003C\u002Fp>\n\u003Cp>With the AWS Config data aggregated across the organization, you can then create a dashboard using \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fquicksight\u002F\">Amazon QuickSight\u003C\u002Fa>. By importing your Athena results into QuickSight, you can visualize how well your Lambda functions adhere to the layer version rule. This dashboard can highlight compliant and non-compliant resources, which helps you to determine your enforcement policy, as outlined in the next phase. The following image is an example dashboard that reports on the distribution of layer versions applied to functions within the organization.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F4-detective-config-dashboard.png\" alt=\"4-detective-config-dashboard\">\u003C\u002Fp>\n\u003Ch3>Phase 3: Implement and Enforce\u003C\u002Fh3>\n\u003Cp>You can now optionally pair your layer version rule that you created in phase 1 with a remediation action via an AWS Systems Manager Automation document, which you author as a Python script written with AWS SDK for Python (boto3). The script calls the \u003Ccode>UpdateFunctionConfiguration\u003C\u002Fcode> API for each AWS Lambda function, updating the function configuration with the new layer ARN. Alternatively, you could have the script instead submit a pull request to the code repository to update the layer ARN. This way future code deployments are also updated with the correct layer ARN.\u003C\u002Fp>\n\u003Cp>These controls can also be packaged into an AWS Config Conformance Pack and deployed across your AWS Organization. AWS Config now enforces layer usage rules across all accounts, identifying and correcting non-compliant resources automatically. By implementing these phases at an organizational level, AWS Config allows you to maintain centralized detective control over your AWS environment, ensuring that your resources are continuously monitored and compliant with your organization's policies and guidelines.\u003C\u002Fp>\n",{"title":6,"order":7,"authors":8},"4. Detective Controls with AWS Config",4,[9],"Debasis Rath","In addition to proactive evaluation, AWS Config can also reactively detect resource deployments and configurations that do not comply with your governance policies. This is important as governance policies are always evolving as your organization learns and implements new best practices.\n\nConsider a scenario where you set a brand new policy when deploying or updating Lambda functions: All Lambda functions must always use a specific, approved Lambda layer version. You can configure AWS Config to monitor new or updated functions for layer configurations. If it detects a function that is not using an approved layer version, it flags the function as a non-compliant resource. You can optionally configure AWS Config to auto-remediate the resource by specifying a remediation action using an AWS Systems Manager Automation document. For example, you could write an automation document in Python using the AWS SDK for Python (boto3), which updates the non-compliant function to point to the approved layer version. Thus, AWS Config serves as both a detective and corrective control, automating compliance management.\n\nLet us break down this entire process in 3 important phases to implement:\n\n![4-detective-config-phases](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F4-detective-config-phases.png)\n\n### Phase 1: Identify Access Resources\n\nYou start by first activating AWS Config across your accounts and configuring it to record AWS Lambda functions. This allows AWS Config to observe when Lambda functions are created or updated. You can then configure [custom policy rules](https:\u002F\u002Fdocs.aws.amazon.com\u002Fconfig\u002Flatest\u002Fdeveloperguide\u002Fevaluate-config_develop-rules_cfn-guard.html) to check for specific policy violations, which use CloudFormation Guard syntax. CloudFormation Guard rules take the following general form:\n\n```\nrule name when condition { assertion }\n```\n\nBelow is a sample rule that checks to ensure that a layer is not set to an old layer version:\n\n```\nrule desiredlayer when configuration.layers !empty {\n    some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn\n}\n```\n\nLets understand the rule syntax and structure:\n\n1. **Rule name**: The name of the rule in the provided example is `desiredlayer`.\n2. **Condition**: This clause specifies the condition under which the rule should be checked. In the provided example, the condition is `configuration.layers !empty`. This means the resource should be evaluated only when the `layers` property in the configuration isn't empty.\n3. **Assertion**: After the when clause, an assertion determines what the rule checks. The assertion `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` checks if any of the Lambda layer ARNs do not match the `OldLayerArn` value. If they do not match, the assertion is true and the rule passes; otherwise, it fails.\n\n`CONFIG_RULE_PARAMETERS` is a special set of parameters that is configured with the AWS Config rule. In this case, `OldLayerArn` is a parameter inside `CONFIG_RULE_PARAMETERS`. This allows users to provide a specific ARN value that they consider old or deprecated, and then the rule checks if any Lambda functions are using this old ARN.\n\n### Phase 2: Visualize and Design\n\nSince AWS Config is now activated and configured to record Lambda functions, it gathers configuration data and stores that data in S3 buckets. You can use [Amazon Athena](https:\u002F\u002Faws.amazon.com\u002Fathena\u002F) to query this data directly from your S3 buckets. With Athena, you can aggregate this data at the organizational level, generating a holistic view of your resource configurations across all your accounts. To set up aggregation of resource configuration data, refer to this Cloud Operations and Management [blog post](https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fmt\u002Fvisualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight\u002F).\n\nBelow is a sample Athena query to identify all Lambda functions using a particular layer ARN:\n\n```\nWITH unnested AS (\n  SELECT\n    item.awsaccountid AS account_id,\n    item.awsregion AS region,\n    item.configuration AS lambda_configuration,\n    item.resourceid AS resourceid,\n    item.resourcename AS resourcename,\n    item.configuration AS configuration,\n    json_parse(item.configuration) AS lambda_json\n  FROM\n    default.aws_config_configuration_snapshot,\n    UNNEST(configurationitems) as t(item)\n  WHERE\n    \"dt\" = 'latest'\n    AND item.resourcetype = 'AWS::Lambda::Function'\n)\n\nSELECT DISTINCT\n  region as Region,\n  resourcename as FunctionName,\n  json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,\n  json_extract_scalar(lambda_json, '$.timeout') AS timeout,\n  json_extract_scalar(lambda_json, '$.version') AS version\nFROM\n  unnested\nWHERE\n  lambda_configuration LIKE '%arn:aws:lambda:us-east-1:01234567890:layer:AnyGovernanceLayer:24%'\n```\n\nBelow are results from the query:\n\n![4-detective-config-result](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F4-detective-config-result.png)\n\nWith the AWS Config data aggregated across the organization, you can then create a dashboard using [Amazon QuickSight](https:\u002F\u002Faws.amazon.com\u002Fquicksight\u002F). By importing your Athena results into QuickSight, you can visualize how well your Lambda functions adhere to the layer version rule. This dashboard can highlight compliant and non-compliant resources, which helps you to determine your enforcement policy, as outlined in the next phase. The following image is an example dashboard that reports on the distribution of layer versions applied to functions within the organization.\n\n![4-detective-config-dashboard](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F4-detective-config-dashboard.png)\n\n### Phase 3: Implement and Enforce\n\nYou can now optionally pair your layer version rule that you created in phase 1 with a remediation action via an AWS Systems Manager Automation document, which you author as a Python script written with AWS SDK for Python (boto3). The script calls the `UpdateFunctionConfiguration` API for each AWS Lambda function, updating the function configuration with the new layer ARN. Alternatively, you could have the script instead submit a pull request to the code repository to update the layer ARN. This way future code deployments are also updated with the correct layer ARN.\n\nThese controls can also be packaged into an AWS Config Conformance Pack and deployed across your AWS Organization. AWS Config now enforces layer usage rules across all accounts, identifying and correcting non-compliant resources automatically. By implementing these phases at an organizational level, AWS Config allows you to maintain centralized detective control over your AWS environment, ensuring that your resources are continuously monitored and compliant with your organization's policies and guidelines.\n",[12],{"title":13,"collapsible":14,"isCollapsed":14,"content":15},"Governance in Depth",false,[16,29,38,46,51,59,66,73],{"title":17,"order":18,"authors":19,"callout":21,"time":25,"path":26,"id":27,"link":28},"1. Introduction",1,[20],"Heeki Park",{"title":22,"description":23,"link":24},"Watch this video","This reinvent 2023 video covers the topics of this guide in further detail.","https:\u002F\u002Fyoutu.be\u002Fqlz15v-gHFI","5 min","1-introduction","1-introduction.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F1-introduction",{"title":30,"order":31,"authors":32,"time":34,"path":35,"id":36,"link":37},"2. Proactive Controls with AWS CloudFormation Guard",2,[20,33],"Pallavi Srivastava","4 min","2-proactive-guard","2-proactive-guard.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F2-proactive-guard",{"title":39,"order":40,"authors":41,"time":42,"path":43,"id":44,"link":45},"3. Proactive Controls with AWS Config",3,[9],"6 min","3-proactive-config","3-proactive-config.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F3-proactive-config",{"title":6,"order":7,"authors":47,"time":25,"path":48,"id":49,"link":50},[9],"4-detective-config","4-detective-config.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F4-detective-config",{"title":52,"order":53,"authors":54,"time":55,"path":56,"id":57,"link":58},"5. Code Signing with AWS Signer",5,[20],"3 min","5-code-signing","5-code-signing.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F5-code-signing",{"title":60,"order":61,"authors":62,"time":55,"path":63,"id":64,"link":65},"6. Code Scanning with Amazon Inspector",6,[33],"6-code-scanning","6-code-scanning.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F6-code-scanning",{"title":67,"order":68,"authors":69,"time":42,"path":70,"id":71,"link":72},"7. Observability for Security and Compliance",7,[9],"7-observability","7-observability.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F7-observability",{"title":74,"order":75,"authors":76,"time":77,"path":78,"id":79,"link":80},"8. Discussion of Open Source and other AWS tools",8,[20],"1 min","8-open-source-and-other-tools","8-open-source-and-other-tools.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F8-open-source-and-other-tools","LIST",[83,84,85],"content\u002Fcontributors\u002Fheeki-park.json","content\u002Fcontributors\u002Fdebasis-rath.json","content\u002Fcontributors\u002Fpallavi-srivastava.json","Implementing governance in depth for serverless applications",1790418903465]