# Criar uma estratégia de governança para funções e camadas do Lambda Para criar e implantar aplicações nativas de nuvem e com tecnologia sem servidor, você deve permitir agilidade e velocidade de comercialização com governança e barreiras de proteção adequadas. Você pode definir as prioridades em nível de negócios enfatizando a agilidade como a principal prioridade ou enfatizando a aversão ao risco por meio de governança, barreiras de proteção e controles. De uma maneira realista, você não terá uma estratégia de “uma ou outra”, mas uma estratégia de “e” que equilibre a agilidade e as barreiras de proteção no seu ciclo de vida de desenvolvimento do software. Não importa onde esses requisitos se enquadram no ciclo de vida da sua empresa. Provavelmente os recursos de governança se tornarão um requisito de implementação nos seus processos e conjuntos de ferramentas. Veja alguns exemplos de controles de governança que uma organização pode implementar para o Lambda: + As funções do Lambda não devem ser acessíveis ao público. + As funções do Lambda devem ser anexadas a uma VPC. + As funções do Lambda não devem usar runtimes obsoletos. + As funções do Lambda devem ser marcadas com um conjunto de tags obrigatórias. + As camadas do Lambda não devem ser acessíveis fora da organização. + As funções do Lambda com um grupo de segurança anexado devem ter tags correspondentes entre a função e o grupo de segurança. + As funções do Lambda com uma camada anexada devem usar uma versão aprovada + As variáveis de ambiente do Lambda devem ser criptografadas em repouso com uma chave gerenciada pelo cliente. O seguinte diagrama é um exemplo de estratégia de governança detalhada que implementa controles e políticas em todo o processo de desenvolvimento e implantação de software: ![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-concepts.png) Os tópicos a seguir explicam como implementar controles para desenvolver e implantar funções do Lambda na sua organização, tanto para a startup quanto para a empresa. Sua organização talvez já tenha ferramentas implementadas. Os tópicos a seguir adotam uma abordagem modular para esses controles para que você possa escolher os componentes de que realmente precisa. **Topics** + [Controles proativos para Lambda com AWS CloudFormation Guard](governance-cloudformation-guard.md) + [Implementar controles preventivos para Lambda com o AWS Config](governance-config.md) + [Detectar implantações e configurações do Lambda não compatíveis com o AWS Config](governance-config-detection.md) + [Assinatura de código do Lambda com AWS Signer](governance-code-signing.md) + [Automatizar as avaliações de segurança para o Lambda com o Amazon Inspector](governance-code-scanning.md) + [Implementar a observabilidade para segurança e conformidade do Lambda](governance-observability.md) # Controles proativos para Lambda com AWS CloudFormation Guard O [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) é uma ferramenta de avaliação de política como código de código aberto e de uso geral. Ele pode ser usado para governança e conformidade preventivas, ao validar modelos de Infraestrutura como Código (IaC) e composições de serviços em relação às regras de política. Essas regras podem ser personalizadas com base nos requisitos da equipe ou da organização. Para funções do Lambda, as regras do Guard podem ser usadas para controlar a criação de recursos e as atualizações de configuração, ao definir as configurações de propriedade necessárias durante a criação ou a atualização de uma função do Lambda. Os administradores de conformidade definem a lista de controles e políticas de governança que são necessários para implantar e atualizar as funções do Lambda. Os administradores da plataforma implementam os controles em pipelines de CI/CD, como webhooks de validação pré-confirmação com repositórios de código, e fornecem aos desenvolvedores ferramentas de linha de comando para validar modelos e códigos em estações de trabalho locais. Os desenvolvedores criam código, validam modelos com ferramentas de linha de comando e, em seguida, confirmam o código nos repositórios, que são validados automaticamente por meio dos pipelines de CI/CD antes da implantação em um ambiente da AWS. O Guard permite que você [crie suas regras](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) e implemente seus controles com uma linguagem específica de domínio como a seguir. ![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-cloudformation-guard.png) Por exemplo, suponha que você deseje garantir que os desenvolvedores escolham somente os runtimes mais recentes. Você pode especificar duas políticas diferentes, uma para identificar os [runtimes](lambda-runtimes.md) que já estão descontinuados e outra para identificar os runtimes que serão descontinuados em breve. Para fazer isso, você pode criar o seguinte arquivo `etc/rules.guard`: ``` let lambda_functions = Resources.*[ Type == "AWS::Lambda::Function" ] rule lambda_already_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <> } } } } rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <> } } } } ``` Agora, suponha que você crie o seguinte modelo `iac/lambda.yaml` do CloudFormation que define uma função do Lambda: ``` Fn: Type: AWS::Lambda::Function Properties: Runtime: python3.7 CodeUri: src Handler: fn.handler Role: !GetAtt FnRole.Arn Layers: - arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35 ``` Depois de [instalar](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) o utilitário Guard, valide o modelo: ``` cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml ``` O resultado se parece com: ``` lambda.yaml Status = FAIL FAILED rules rules.guard/lambda_soon_to_be_deprecated_runtime --- Evaluating data lambda.yaml against rules rules.guard Number of non-compliant resources 1 Resource = Fn { Type = AWS::Lambda::Function Rule = lambda_soon_to_be_deprecated_runtime { ALL { Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] { ComparisonError { Message = Lambda function is using a runtime that is targeted for deprecation. Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])] } PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15] Operator = NOT IN Value = "python3.7" ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]] Code: 86. Fn: 87. Type: AWS::Lambda::Function 88. Properties: 89. Runtime: python3.7 90. CodeUri: src 91. Handler: fn.handler } } } } ``` O Guard permite que os desenvolvedores vejam em suas estações de trabalho locais que precisam atualizar o modelo para usar um runtime permitido pela organização. Isso acontece antes da confirmação em um repositório de código e, posteriormente, apresentar falha nas verificações em um pipeline de CI/CD. Como resultado, os desenvolvedores recebem esse feedback sobre como desenvolver modelos em conformidade e dedicar o tempo à criação de códigos que agreguem valor comercial. Esse controle pode ser aplicado na estação de trabalho local do desenvolvedor, em um webhook de validação pré-confirmação e/ou no pipeline de CI/CD antes da implantação. ## Advertências Se você estiver usando modelos do AWS Serverless Application Model (AWS SAM) para definir funções do Lambda, saiba que precisa atualizar a regra do Guard para pesquisar o tipo de recurso `AWS::Serverless::Function` como a seguir. ``` let lambda_functions = Resources.*[ Type == "AWS::Serverless::Function" ] ``` O Guard também espera que as propriedades sejam incluídas na definição do recurso. Enquanto isso, os modelos do AWS SAM permitem que as propriedades sejam especificadas em uma seção [Globals](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) separada. As propriedades definidas na seção Globals não são validadas com suas regras do Guard. Conforme descrito na [documentação](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) de solução de problemas do Guard, saiba que o Guard não é compatível com funções intrínsecas de forma abreviada, como `!GetAtt` ou `!Sub`. Em vez disso, ele requer o uso de formas expandidas: `Fn::GetAtt` e `Fn::Sub`. (O [exemplo anterior](#guard-iac-yaml) não avalia a propriedade Role. Portanto, a função intrínseca de forma abreviada foi usada para simplificar.) # Implementar controles preventivos para Lambda com o AWS Config É essencial garantir a conformidade nas aplicações com tecnologia sem servidor o mais cedo possível no processo de desenvolvimento. Neste tópico, abordaremos como implementar controles preventivos usando o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). Isso permite que você implemente verificações de conformidade mais cedo no processo de desenvolvimento e implemente os mesmos controles nos seus pipelines de CI/CD. Isso também padroniza os controles em um repositório de regras gerenciado de forma centralizada para que você possa aplicar os controles de forma consistente em todas as suas contas da AWS. Por exemplo, suponha que os administradores de conformidade tenham definido um requisito para garantir que todas as funções do Lambda incluam rastreamento do AWS X-Ray. Com o modo proativo do AWS Config, você pode executar verificações de conformidade nos recursos da função do Lambda antes da implantação, reduzindo o risco de implantar funções do Lambda configuradas incorretamente e economizando o tempo dos desenvolvedores ao fornecer feedback mais rápido sobre a infraestrutura como modelos de código. A seguir, é apresentada uma visualização do fluxo de controles preventivos com o AWS Config: ![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-1.png) Considere a exigência de que todas as funções do Lambda tenham o rastreamento ativado. Em resposta, a equipe da plataforma identifica a necessidade de uma regra do AWS Config específica ser executada de forma proativa em todas as contas. Essa regra sinaliza qualquer função do Lambda que não tenha uma configuração de rastreamento do X-Ray configurada como um recurso fora de conformidade. A equipe desenvolve uma regra, coloca-a em um [pacote de conformidade](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) e implanta o pacote de conformidade em todas as contas da AWS para garantir que todas as contas da organização apliquem uniformemente esses controles. Você pode criar a regra na sintaxe AWS CloudFormation Guard 2.x.x, que assume o seguinte formato: ``` rule name when condition { assertion } ``` Veja a seguir um exemplo de regra do Guard que verifica se as funções do Lambda têm o rastreamento habilitado: ``` rule lambda_tracing_check { when configuration.tracingConfig exists { configuration.tracingConfig.mode == "Active" } } ``` A equipe da plataforma toma medidas adicionais ao exigir que cada implantação do AWS CloudFormation invoque um [hook](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html) pré-criação/atualização. A equipe assume total responsabilidade pelo desenvolvimento desse hook e pela configuração do pipeline, fortalecendo o controle centralizado das regras de conformidade e sustentando a aplicação consistente delas em todas as implantações. Para desenvolver, empacotar e registrar um hook, consulte [Desenvolver hooks do AWS CloudFormation](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html) na documentação da interface de linha de comando do CloudFormation (CFN-CLI). Você pode usar a [CLI do CloudFormation](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) para criar o projeto do hook: ``` cfn init ``` Esse comando solicita a você algumas informações básicas sobre o projeto do hook e cria um projeto com os seguintes arquivos: ``` README.md .json rpdk.log src/handler.py template.yml hook-role.yaml ``` Como desenvolvedor de hooks, você precisa adicionar o tipo de recurso de destino desejado no arquivo de configuração `.json`. Na configuração abaixo, um hook é configurado para ser executado antes que qualquer função do Lambda seja criada usando o CloudFormation. Você também pode adicionar manipuladores semelhantes para ações de `preUpdate` e `preDelete`. ``` "handlers": { "preCreate": { "targetNames": [ "AWS::Lambda::Function" ], "permissions": [] } } ``` Você também precisa garantir que o hook do CloudFormation tenha as permissões apropriadas para chamar as APIs do AWS Config. Você pode fazer isso atualizando o arquivo de definição de perfil denominado `hook-role.yaml`. Por padrão, o arquivo de definição de perfil tem a política de confiança a seguir, que permite que o CloudFormation assuma o perfil. ``` AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - hooks.cloudformation.amazonaws.com - resources.cloudformation.amazonaws.com ``` Para permitir que esse hook chame APIs de configuração, você deve adicionar as permissões a seguir à declaração da política. Em seguida, você envia o projeto do hook usando o comando `cfn submit`, em que o CloudFormation cria um perfil para você com as permissões necessárias. ``` Policies: - PolicyName: HookTypePolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - "config:Describe*" - "config:Get*" - "config:List*" - "config:SelectResourceConfig" Resource: "* ``` Em seguida, você precisa criar uma função do Lambda em um arquivo `src/handler.py`. Nesse arquivo, você encontra métodos denominados `preCreate`, `preUpdate` e `preDelete` já criados quando você iniciou o projeto. Seu objetivo é criar uma função comum e reutilizável que chame a API `StartResourceEvaluation` do AWS Config no modo proativo usando o AWS SDK para Python (Boto3). Essa chamada de API usa as propriedades do recurso como entrada e avalia o recurso em relação à definição da regra. ``` def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent: LOG.info("Fetching proactive data") config_client = boto3.client('config') resource_specs = { 'ResourceId': 'MyFunction', 'ResourceType': resource_type, 'ResourceConfiguration': json.dumps(function_properties), 'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA' } LOG.info("Resource Specifications:", resource_specs) eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60) ResourceEvaluationId = eval_response.ResourceEvaluationId compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId) LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType) if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType: return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant) else: return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.") ``` Agora, você pode chamar a função comum do manipulador para o hook de pré-criação. Veja um exemplo do manipulador: ``` @hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION) def pre_create_handler( session: Optional[SessionProxy], request: HookHandlerRequest, callback_context: MutableMapping[str, Any], type_configuration: TypeConfigurationModel ) -> ProgressEvent: LOG.info("Starting execution of the hook") target_name = request.hookContext.targetName LOG.info("Target Name:", target_name) if "AWS::Lambda::Function" == target_name: return validate_lambda_tracing_config(target_name, request.hookContext.targetModel.get("resourceProperties") ) else: raise exceptions.InvalidRequest(f"Unknown target type: {target_name}") ``` Após essa etapa, você poderá registrar o hook e configurá-lo para ouvir todos os eventos de criação de funções do AWS Lambda. Um desenvolvedor prepara o modelo de infraestrutura como código (IaC) para um microsserviço com tecnologia sem servidor usando o Lambda. Essa preparação inclui a adesão aos padrões internos, seguida pelo teste local e pela confirmação do modelo para o repositório. Veja um exemplo de modelo de IaC: ``` MyLambdaFunction: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: MyLambdaFunction Code: ZipFile: | import json def handler(event, context): return { 'statusCode': 200, 'body': json.dumps('Hello World!') } Runtime: python3.14 TracingConfig: Mode: PassThrough MemorySize: 256 Timeout: 10 ``` Como parte do processo de CI/CD, quando o modelo do CloudFormation é implantado, o serviço do CloudFormation invoca o hook de pré-criação/atualização logo antes de provisionar o tipo de recurso da `AWS::Lambda::Function`. O hook utiliza regras do AWS Config executadas no modo proativo para verificar se a configuração da função do Lambda inclui a configuração de rastreamento obrigatória. A resposta do hook determina a próxima etapa. Se estiver em conformidade, o hook indicará êxito e o CloudFormation continuará a provisionar os recursos. Caso contrário, a implantação da pilha do CloudFormation apresentará falha, o pipeline será interrompido imediatamente e o sistema registrará os detalhes para análise posterior. As notificações de conformidade são enviadas aos investidores relevantes. Você pode encontrar as informações de êxito/falha do hook no console do CloudFormation: ![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-2.png) Se você tiver logs habilitados para o hook do CloudFormation, poderá capturar o resultado da avaliação do hook. Veja um exemplo de log de um hook com status de falha, indicando que a função do Lambda não tem o X-Ray ativado: ![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-3.png) Se o desenvolvedor optar por alterar a IaC para atualizar o valor de `TracingConfig Mode` para `Active` e reimplantar, o hook será executado com êxito e a pilha prosseguirá com a criação do recurso do Lambda. ![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-4.png) Dessa forma, você pode implementar controles preventivos com o AWS Config em modo proativo ao desenvolver e implantar recursos com tecnologia sem servidor nas suas contas da AWS. Ao integrar regras do AWS Config ao pipeline de CI/CD, você pode identificar e, opcionalmente, bloquear implantações de recursos fora de conformidade, como funções do Lambda que não possuem uma configuração de rastreamento ativa. Isso garante que somente recursos em conformidade com as políticas de governança mais recentes sejam implantados nos ambientes da AWS. # Detectar implantações e configurações do Lambda não compatíveis com o AWS Config Além da [avaliação proativa](governance-config.md), o AWS Config também pode detectar de forma reativa implantações e configurações de recursos que não estejam em conformidade com suas políticas de governança. Isso é importante porque as políticas de governança evoluem à medida que a organização aprende e implementa novas melhores práticas. Considere um cenário em que você define uma política totalmente nova ao implantar ou atualizar as funções do Lambda: todas as funções do Lambda devem sempre usar uma versão específica e aprovada da camada do Lambda. Você pode configurar o AWS Config para monitorar funções novas ou atualizadas para configurações de camadas. Se o AWS Config detectar uma função que não está usando uma versão de camada aprovada, ele sinalizará a função como um recurso fora de conformidade. Opcionalmente, você pode configurar o AWS Config para remediar automaticamente o recurso ao especificar uma ação de remediação usando um documento de automação do AWS Systems Manager. Por exemplo, você pode criar um documento de automação em Python usando o AWS SDK para Python (Boto3), que atualiza a função fora de conformidade para apontar para a versão da camada aprovada. Portanto, o AWS Config funciona como um controle de detecção e correção, automatizando o gerenciamento da conformidade. Vamos detalhar esse processo em três fases importantes de implementação: ![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-detective-1.png) ## Fase 1: identificar os recursos de acesso Comece ativando o AWS Config em todas as contas e configurando-o para registrar as funções do AWS Lambda. Isso permite que o AWS Config observe quando as funções do Lambda são criadas ou atualizadas. Em seguida, você pode configurar [regras de política personalizadas](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) para verificar violações de políticas específicas, que usam a sintaxe AWS CloudFormation Guard. As regras de proteção assumem a seguinte forma geral: ``` rule name when condition { assertion } ``` A seguir, é mostrado um exemplo de regra que verifica se uma camada não está configurada para uma versão antiga da camada: ``` rule desiredlayer when configuration.layers !empty { some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn } ``` Vamos entender a sintaxe e a estrutura da regra: + **Nome da regra:** o nome da regra no exemplo fornecido é `desiredlayer`. + **Condição:** essa cláusula especifica a condição segundo a qual a regra deve ser verificada. No exemplo fornecido, a condição é `configuration.layers !empty`. Isso significa que o recurso deve ser avaliado somente quando a propriedade `layers` na configuração não está vazia. + **Afirmação:** após a cláusula `when`, uma declaração determina o que a regra verifica. A declaração `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` verifica se algum dos ARNs de camada do Lambda não corresponde ao valor `OldLayerArn`. Se não houver correspondência, a declaração será verdadeira e a regra será aprovada; caso contrário, ela será reprovada. `CONFIG_RULE_PARAMETERS` é um conjunto especial de parâmetros configurado com a regra AWS Config. Nesse caso, `OldLayerArn` é um parâmetro dentro de `CONFIG_RULE_PARAMETERS`. Isso permite que os usuários forneçam um ARN específico que considerem antigo ou desativado e, em seguida, a regra verifica se alguma função do Lambda está usando este ARN antigo. ## Fase 2: visualizar e projetar O AWS Config reúne os dados de configuração e os armazena em buckets do Amazon Simple Storage Service (Amazon S3). Você pode usar o [Amazon Athena](https://aws.amazon.com/athena/) para consultar esses dados diretamente nos buckets do S3. Com o Athena, você pode agregar esses dados no nível da organização, gerando uma visão holística das configurações dos recursos em todas as suas contas. Para definir a agregação de dados de configuração de recursos, consulte [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) no AWS Cloud Operations and Management Blog. Veja a seguir um exemplo de consulta do Athena para identificar todas as funções do Lambda que usam um ARN de camada específico: ``` WITH unnested AS ( SELECT item.awsaccountid AS account_id, item.awsregion AS region, item.configuration AS lambda_configuration, item.resourceid AS resourceid, item.resourcename AS resourcename, item.configuration AS configuration, json_parse(item.configuration) AS lambda_json FROM default.aws_config_configuration_snapshot, UNNEST(configurationitems) as t(item) WHERE "dt" = 'latest' AND item.resourcetype = 'AWS::Lambda::Function' ) SELECT DISTINCT region as Region, resourcename as FunctionName, json_extract_scalar(lambda_json, '$.memorySize') AS memory_size, json_extract_scalar(lambda_json, '$.timeout') AS timeout, json_extract_scalar(lambda_json, '$.version') AS version FROM unnested WHERE lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%' ``` Veja os resultados da consulta: ![\[Query results in Athena console.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-detective-2.png) Com os dados do AWS Config agregados em toda a organização, você pode criar um painel usando o [Amazon Quick](https://aws.amazon.com/quicksight/). Importando os resultados do Athena para o Quick, você pode visualizar em que medida as funções do Lambda seguem a regra de versão da camada. Esse painel pode destacar recursos em conformidade e fora de conformidade, o que ajuda você a determinar sua política de aplicação, conforme descrito na [próxima seção.](#governance-config-detective-implement) A imagem a seguir é um exemplo de painel que relata a distribuição das versões de camadas aplicadas às funções dentro da organização. ![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-config-detective-3.png) ## Fase 3: implementar e aplicar Agora você pode, opcionalmente, emparelhar sua regra de versão de camada criada na [fase 1](#governance-config-detective-identify) com uma ação de remediação por meio de um documento de automação do Systems Manager, que você cria como um script em Python escrito com o AWS SDK para Python (Boto3). O script chama a ação de API [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) para cada função do Lambda, atualizando a configuração da função com o novo ARN da camada. Como alternativa, você pode fazer com que o script envie uma solicitação pull para o repositório do código para atualizar o ARN da camada. Dessa forma, futuras implantações de código também serão atualizadas com o ARN correto da camada. # Assinatura de código do Lambda com AWS Signer O [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) é um serviço de assinatura de código totalmente gerenciado que permite que você valide o código em uma assinatura digital para confirmar que o código está inalterado e é de um publicador confiável. O AWS Signer pode ser usado com o AWS Lambda para verificar se as funções e as camadas permanecem inalteradas antes da implantação nos ambientes da AWS. Isso protege sua organização contra agentes mal-intencionados que possam ter obtido credenciais para criar novas funções ou atualizar as existentes. Para configurar a assinatura de código para suas funções do Lambda, comece criando um bucket do S3 com versionamento habilitado. Depois disso, crie um perfil de assinatura com AWS Signer, especifique Lambda como plataforma e, em seguida, especifique um período em dias em que o perfil de assinatura será válido. Exemplo: ``` Signer: Type: AWS::Signer::SigningProfile Properties: PlatformId: AWSLambda-SHA384-ECDSA SignatureValidityPeriod: Type: DAYS Value: !Ref pValidDays ``` Em seguida, use o perfil de assinatura e crie uma configuração de assinatura com o Lambda. Você precisa especificar o que fazer quando a configuração de assinatura vir um artefato que não corresponda à assinatura digital esperada: avisar (mas permitir a implantação) ou aplicar (e bloquear a implantação). O exemplo abaixo está configurado para aplicar e bloquear implantações. ``` SigningConfig: Type: AWS::Lambda::CodeSigningConfig Properties: AllowedPublishers: SigningProfileVersionArns: - !GetAtt Signer.ProfileVersionArn CodeSigningPolicies: UntrustedArtifactOnDeployment: Enforce ``` Agora, o AWS Signer está configurado com o Lambda para bloquear implantações não confiáveis. Suponhamos que você tenha concluído a codificação de uma solicitação de atributo e agora esteja prestes a implantar a função. A primeira etapa é compactar o código com as dependências apropriadas e depois assinar o artefato usando o perfil de assinatura que você criou. Você pode fazer isso carregando o artefato zip no bucket do S3 e iniciando um trabalho de assinatura. ``` aws signer start-signing-job \ --source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \ --destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \ --profile-name your-signer-id ``` Você obtém uma saída como mostrado a seguir, em que o `jobId` é o objeto criado no bucket e no prefixo de destino e `jobOwner` é a Conta da AWS ID de 12 dígitos em que o trabalho foi executado. ``` { "jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388", "jobOwner": "111122223333" } ``` E, agora, você pode implantar a função usando o objeto S3 assinado e a configuração de assinatura de código que você criou. ``` Fn: Type: AWS::Serverless::Function Properties: CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip Handler: fn.handler Role: !GetAtt FnRole.Arn CodeSigningConfigArn: !Ref pSigningConfigArn ``` Como alternativa, você pode testar a implantação de uma função com o artefato zip original não assinado. A implantação deverá apresenta falha com a seguinte mensagem de erro: ``` Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned. ``` Se você estiver criando e implantando funções usando o AWS Serverless Application Model (AWS SAM), o comando de pacote manipulará o upload do artefato zip no S3, também iniciará o trabalho de assinatura e o artefato será assinado. Você pode fazer isso usando os seguintes parâmetros e comando: ``` sam package -t your-template.yaml \ --output-template-file your-output.yaml \ --s3-bucket your-versioned-bucket \ --s3-prefix your-prefix \ --signing-profiles your-signer-id ``` O AWS Signer ajuda você a verificar se os artefatos zip implantados nas contas são confiáveis para implantação. Você pode incluir o processo acima em pipelines de CI/CD e exigir que todas as funções tenham uma configuração de assinatura de código anexada usando as técnicas descritas nos tópicos anteriores. Ao usar a assinatura de código com implantações de funções do Lambda, você evita que agentes mal-intencionados, que possam ter obtido credenciais para criar ou atualizar funções, injetem código malicioso nas funções. # Automatizar as avaliações de segurança para o Lambda com o Amazon Inspector O [Amazon Inspector](https://aws.amazon.com/inspector/) é um serviço de gerenciamento de vulnerabilidades que verifica continuamente as workloads em busca de vulnerabilidades de software conhecidas e exposições não intencionais da rede. O Amazon Inspector cria uma descoberta que descreve a vulnerabilidade, identifica o recurso afetado, classifica a gravidade da vulnerabilidade e fornece orientações para correção. O suporte do Amazon Inspector fornece avaliações de vulnerabilidade de segurança contínuas e automatizadas para funções do Lambda e camadas. O Amazon Inspector fornece dois tipos de verificação para o Lambda: + **Verificação padrão do Lambda:** verifica as dependências das aplicações dentro de uma função do Lambda e suas camadas em busca de [vulnerabilidades de pacotes](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package). + **Verificação de código do Lambda**: verifica o código da aplicação personalizada nas funções e camadas em busca de [vulnerabilidades de código](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code). Ative o escaneamento padrão do Lambda ou ative o escaneamento padrão do Lambda junto com o escaneamento de código do Lambda. Para habilitar o Amazon Inspector, navegue até o [console do Amazon Inspector](https://console.aws.amazon.com/inspector/), expanda a seção **Configurações** e escolha **Gerenciamento de contas**. Na guia **Contas**, escolha **Ativar** e selecione uma das opções de verificação. Você pode habilitar o Amazon Inspector para várias contas e delegar permissões para gerenciar o Amazon Inspector para a organização em contas específicas enquanto configura o Amazon Inspector. Durante a habilitação, você precisa conceder permissões ao Amazon Inspector ao criar a função: `AWSServiceRoleForAmazonInspector2`. O console do Amazon Inspector permite que você crie essa função usando uma opção de um clique. Para a verificação padrão do Lambda, o Amazon Inspector inicia verificações de vulnerabilidade das funções do Lambda nas seguintes situações: + Assim que o Amazon Inspector descobre uma função do Lambda existente. + Quando você implanta uma nova função do Lambda. + Ao implantar uma atualização no código do aplicativo ou nas dependências de uma função do Lambda existente ou de suas camadas. + Sempre que o Amazon Inspector adiciona um novo item de CVEs (vulnerabilidades e exposições comuns) ao seu banco de dados, e esse CVE é relevante para sua função. Para a verificação do código do Lambda, o Amazon Inspector avalia o código da aplicação da função do Lambda usando raciocínio automatizado e machine learning que analisam o código da aplicação para verificar a conformidade geral com a segurança. Se o Amazon Inspector detectar uma vulnerabilidade no código da aplicação da função do Lambda, o Amazon Inspector produzirá uma descoberta detalhada de **Vulnerabilidade de código**. Para obter uma lista de detecções possíveis, consulte a [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/). Para visualizar as descobertas, acesse o [console do Amazon Inspector](https://console.aws.amazon.com/inspector/). No menu **Descobertas**, escolha **Por função do Lambda** para exibir os resultados da verificação de segurança que foi executada nas funções do Lambda. Para excluir uma função do Lambda da verificação padrão, marque a função com o seguinte par de chave/valor: + `Key:InspectorExclusion` + `Value:LambdaStandardScanning` Para excluir uma função do Lambda das verificações de código, marque a função com o seguinte par de chave/valor: + `Key:InspectorCodeExclusion` + `Value:``LambdaCodeScanning` Por exemplo, conforme mostrado na imagem a seguir, o Amazon Inspector detecta automaticamente vulnerabilidades e categoriza as descobertas do tipo **Vulnerabilidade de código**, o que indica que a vulnerabilidade está no código da função e não em uma das bibliotecas dependentes do código. Você pode verificar esses detalhes para uma função específica ou várias funções ao mesmo tempo. ![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-code-scanning-1.png) Você pode se aprofundar em cada uma dessas descobertas e saber como corrigir o problema. ![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-code-scanning-2.png) Ao trabalhar com suas funções do Lambda, certifique-se de cumprir as convenções de nomenclatura para as funções do Lambda. Para ter mais informações, consulte [Trabalhar com variáveis de ambiente no Lambda](configuration-envvars.md). Você é responsável pelas sugestões de remediação que aceita. Sempre analise as sugestões de remediação antes de aceitá-las. Talvez seja necessário fazer edições nas sugestões de correção para garantir que o código faça o que você pretende. # Implementar a observabilidade para segurança e conformidade do Lambda O AWS Config é uma ferramenta útil para encontrar e corrigir recursos da AWS com tecnologia sem servidor que não estão em conformidade. Cada alteração que você faz nos seus recursos com tecnologia sem servidor é registrada no AWS Config. Além disso, o AWS Config permite o armazenamento de dados de snapshot de configuração no S3. Você pode usar o Amazon Athena e o Amazon Quick para criar painéis e ver dados do AWS Config. Em [Detectar implantações e configurações do Lambda não compatíveis com o AWS Config](governance-config-detection.md), discutimos como podemos visualizar uma determinada configuração, como camadas do Lambda. Este tópico expande esses conceitos. ## Visibilidade das configurações do Lambda É possível usar consultas para obter configurações importantes, como ID da Conta da AWS, região, configuração de rastreamento do AWS X-Ray, configuração da VPC, tamanho de memória, runtime e tags. Veja um exemplo de consulta que você pode usar para obter essas informações do Athena: ``` WITH unnested AS ( SELECT item.awsaccountid AS account_id, item.awsregion AS region, item.configuration AS lambda_configuration, item.resourceid AS resourceid, item.resourcename AS resourcename, item.configuration AS configuration, json_parse(item.configuration) AS lambda_json FROM default.aws_config_configuration_snapshot, UNNEST(configurationitems) as t(item) WHERE "dt" = 'latest' AND item.resourcetype = 'AWS::Lambda::Function' ) SELECT DISTINCT account_id, tags, region as Region, resourcename as FunctionName, json_extract_scalar(lambda_json, '$.memorySize') AS memory_size, json_extract_scalar(lambda_json, '$.timeout') AS timeout, json_extract_scalar(lambda_json, '$.runtime') AS version json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig FROM unnested ``` Você pode usar a consulta para criar um painel do Quick e visualizar os dados. Para agregar dados de configuração de recursos da AWS, criar tabelas no Athena e criar painéis do Quick com base nos dados do Athena, consulte [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) no blog AWS Cloud Operations and Management. Sobretudo, essa consulta também recupera informações de tags para as funções. Isso permite insights mais profundos das workloads e ambientes, especialmente se forem empregadas tags personalizadas. ![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-observability-1.png) Para obter mais informações sobre as ações que você pode executar, consulte a seção [Abordar as descobertas de observabilidade](#governance-observability-addressing) mais adiante neste tópico. ## Visibilidade da conformidade do Lambda Com os dados gerados pelo AWS Config você pode criar painéis em nível organizacional para monitorar a conformidade. Isso permite o rastreamento e o monitoramento consistentes de: + Pacotes de conformidade por pontuação de conformidade + Regras por recursos fora de conformidade + Compliance status (Status de conformidade) ![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-observability-2.png) Verifique cada regra para identificar recursos fora de conformidade com esta regra. Por exemplo, se sua organização exigir que todas as funções do Lambda estejam associadas a uma VPC e se você tiver implantado uma regra do AWS Config para identificar conformidade, você poderá selecionar a regra `lambda-inside-vpc` na lista acima. ![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-observability-3.png) Para obter mais informações sobre as ações que você pode executar, consulte a seção [Abordar as descobertas de observabilidade](#governance-observability-addressing) a seguir. ## Visibilidade dos limites da função do Lambda usando o CSPM do Security Hub ![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-observability-4.png) Para garantir que os serviços da AWS, incluindo o Lambda, sejam usados com segurança, a AWS introduziu as Práticas Recomendadas de Segurança Básica v1.0.0. Esse conjunto de melhores práticas fornece diretrizes claras para proteger recursos e dados no ambiente da AWS, enfatizando a importância de manter uma postura de segurança forte. O AWS Security Hub CSPM complementa isso ao oferecer um centro unificado de segurança e conformidade. Ele agrega, organiza e prioriza as descobertas de segurança de vários serviços da AWS, como o Amazon Inspector, o AWS Identity and Access Management Access Analyzer e o Amazon GuardDuty. Se você tiver o CSPM do Security Hub, o Amazon Inspector, o IAM Access Analyzer e o GuardDuty habilitados na sua organização da AWS, o CSPM do Security Hub agregará automaticamente as descobertas desses serviços. Por exemplo, vamos considerar o Amazon Inspector. Usando o CSPM do Security Hub, é possível identificar com eficiência as vulnerabilidades do código e do pacote nas funções do Lambda. No console do CSPM do Security Hub, navegue até a seção inferior denominada **Últimas descobertas das integrações da AWS**. Aqui, você pode visualizar e analisar descobertas provenientes de vários serviços da AWS integrados. ![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-observability-5.png) Para ver os detalhes, escolha o link **Ver descobertas** na segunda coluna. É exibida uma lista de descobertas filtradas por produto, como o Amazon Inspector. Para limitar sua pesquisa às funções do Lambda, defina `ResourceType` como `AwsLambdaFunction`. Isso exibe descobertas do Amazon Inspector relacionadas às funções do Lambda. ![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/governance-observability-6.png) No GuardDuty, você pode identificar padrões de tráfego de rede suspeitos. Essas anomalias podem sugerir a existência de código potencialmente malicioso na função do Lambda. Com o IAM Access Analyzer, você pode verificar as políticas, especialmente aquelas com instruções de condição que concedem à função acesso a entidades externas. Além disso, o IAM Access Analyzer avalia as permissões definidas ao ser usada a operação [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) na API do Lambda junto com um `EventSourceToken`. ## Abordar as descobertas de observabilidade Dadas as amplas configurações possíveis para as funções do Lambda e seus requisitos distintos, uma solução de automação padronizada para remediação talvez não seja adequada para todas as situações. Além disso, as mudanças são implementadas de forma diferente em vários ambientes. Se você encontrar alguma configuração que pareça fora de conformidade, considere as seguintes diretrizes: 1. **Estratégia de marcação** Recomendamos a implementação de uma estratégia abrangente de marcação. Cada função do Lambda deve ser marcada com informações essenciais, como: + **Proprietário:** a pessoa ou equipe responsável pela função. + **Ambiente:** produção, preparação, desenvolvimento ou sandbox. + **Aplicação:** o contexto mais amplo ao qual essa função pertence, se aplicável. 1. **Alcance do proprietário** Em vez de automatizar as alterações significativas (como o ajuste da configuração da VPC), entre em contato proativamente com os proprietários das funções fora de conformidade (identificadas pela tag do proprietário), fornecendo a elas tempo suficiente para: + Ajustar configurações fora de conformidade nas funções do Lambda. + Fornecer uma explicação e solicitar uma exceção ou refinar os padrões de conformidade. 1. **Manter um banco de dados de gerenciamento de configuração (CMDB)** Embora as tags possam fornecer contexto imediato, manter um CMDB centralizado pode fornecer insights mais profundos. Ele pode conter informações mais granulares sobre cada função do Lambda, suas dependências e outros metadados essenciais. Um CMDB é um recurso inestimável para auditoria, verificações de conformidade e identificação de proprietários de funções. À medida que o cenário da infraestrutura com tecnologia sem servidor evolui continuamente, é essencial adotar uma postura proativa em relação ao monitoramento. Com ferramentas, como o AWS Config, o CSPM do Security Hub e o Amazon Inspector, possíveis anomalias ou configurações fora de conformidade podem ser rapidamente identificadas. No entanto, as ferramentas não podem, isoladamente, garantir total conformidade ou configurações ideais. É fundamental combinar essas ferramentas com processos e melhores práticas bem documentados. + **Ciclo de feedback:** depois que as etapas de remediação forem executadas, certifique-se de que haja um ciclo de feedback. Isso significa revisitar periodicamente os recursos fora de conformidade para confirmar se eles foram atualizados ou se ainda estão em execução com os mesmos problemas. + **Documentação:** sempre documente as observações, as ações executadas e quaisquer exceções concedidas. A documentação adequada não só ajuda durante as auditorias, mas também ajuda a aprimorar o processo para melhorar a conformidade e a segurança no futuro. + **Treinamento e reconhecimento:** garanta que todos os investidores, especialmente os proprietários de funções do Lambda, sejam regularmente treinados e informados sobre as melhores práticas, políticas organizacionais e exigências de conformidade. Workshops, webinars ou sessões de treinamento regulares podem ajudar muito a garantir que todos estejam na mesma página quando se trata de segurança e conformidade. Para concluir, embora ferramentas e tecnologias forneçam recursos consistentes para detectar e identificar possíveis problemas, o elemento humano, incluindo compreensão, comunicação, treinamento e documentação, continua sendo fundamental. Esses aspectos, juntos, formam uma combinação poderosa para garantir que as funções do Lambda e uma infraestrutura mais ampla permaneçam em conformidade, seguras e otimizadas para suas necessidades de negócios.