O blog da AWS

Implementando chaves gerenciadas pelo cliente para funções duráveis do AWS Lambda com Terraform

Por Rajdeep Banerjee, Brian Krygsman e Ramesh Mathikumar, na Amazon Web Services.

Se você executa workloads regulamentados, precisa controlar como os dados persistidos são criptografados e quem pode acessá-los. Você precisa gerenciar cronogramas de rotação de chaves de criptografia, restringir a descriptografia a principais autorizados e produzir evidências de auditoria que comprovem que os controles de criptografia estão operando conforme projetado.

As funções duráveis do AWS Lambda criam fluxos de trabalho resilientes e de múltiplas etapas que sobrevivem a falhas por meio de checkpoint automático. O mecanismo de checkpoint persiste o estado de execução, incluindo resultados de etapas, payloads e respostas de callback, em armazenamento durável. Para workloads de processamento de pagamentos, esses dados persistidos são sensíveis. As funções duráveis do AWS Lambda oferecem suporte a chaves gerenciadas pelo cliente do AWS Key Management Service (AWS KMS). Uma chave gerenciada pelo cliente oferece três controles: você define o cronograma de rotação da chave, restringe o acesso à descriptografia por meio da política da chave e gera trilhas de auditoria por função no AWS CloudTrail. Uma execução durável usa a mesma chave de criptografia com a qual foi iniciada durante todo o seu ciclo de vida. Alterar ou remover a chave afeta apenas as execuções que começam após a alteração.

Atualizar a política da chave gerenciada pelo cliente para remover permissões de descriptografia, ou desativar a chave, impede que o serviço Lambda acesse o estado previamente registrado em checkpoint. A exclusão de uma chave gerenciada pelo cliente é uma ação permanente, e todas as execuções duráveis criptografadas com essa chave se tornam irrecuperáveis, pois o serviço Lambda não tem nenhum mecanismo para restaurar os dados. Antes de agendar a exclusão da chave, use o período de espera do AWS KMS (7 a 30 dias) e monitore o AWS CloudTrail para chamadas Decrypt para confirmar que a chave não está mais em uso ativo.

Nesta publicação, você aprenderá a configurar uma chave gerenciada pelo cliente para criptografar dados de execução durável em um fluxo de trabalho de processamento de pagamentos orientado por eventos. Você criará uma chave de criptografia simétrica no AWS KMS e definirá uma política de chave que concede ao serviço Lambda, à função de execução da função, ao autor da função e aos operadores de execução durável apenas as ações do AWS KMS que cada principal requer. Em seguida, você configurará a função para usar a chave na criptografia de execução durável e verificará as operações de criptografia por meio de logs do AWS CloudTrail. Ao final, você terá uma arquitetura de referência implantável que pode adaptar para workloads regulamentados em execução nas funções duráveis do Lambda.

Para saber mais sobre como o AWS Lambda criptografa dados de execução durável, consulte Encrypting AWS Lambda durable execution data no Guia do Desenvolvedor do AWS Lambda.

Visão geral da solução

A aplicação de exemplo implementa um pipeline de processamento de pagamentos orientado por eventos usando Amazon DynamoDB, Amazon EventBridge, Amazon EventBridge Pipes, AWS Lambda e Amazon SQS. O pipeline recebe transações de pagamento autorizadas, valida-as e as enriquece. Uma função durável do Lambda aplica regras de negócio às transações enriquecidas. As transações aprovadas são enviadas para um sistema de liquidação downstream para postagem.

A seção a seguir aborda as principais etapas arquiteturais.

Etapas da arquitetura

  1. O sistema de autorização upstream grava registros de pagamento autorizados em uma tabela do DynamoDB.
  2. O DynamoDB Streams captura cada novo registro como um evento de alteração ordenado.
  3. O Amazon EventBridge Pipes consulta o registro do stream do DynamoDB. O pipe aciona uma função Lambda como parte da etapa de enriquecimento para verificação de duplicidade.
  4. A função Lambda de deduplicação usa uma tabela do DynamoDB com gravações condicionais para identificar transações duplicadas de entrada com base nas propriedades da transação e na janela de tempo.
  5. Quando a deduplicação é bem-sucedida, o pipe publica um evento no barramento de eventos personalizado do Amazon EventBridge.
  6. Uma regra do Amazon EventBridge invoca uma função Lambda para eventos correspondentes. A função adiciona contexto de negócio, como tipo de conta, detalhes de roteamento bancário e códigos de categoria de comerciante. A função publica um novo evento enriquecido no barramento de eventos personalizado.
  7. Outra regra do Amazon EventBridge corresponde os eventos enriquecidos a uma função durável do Lambda. A função durável aplica regras de negócio ao evento recebido. Quando o evento passa por todas as regras de negócio, a função publica um novo evento no barramento de eventos.
  8. Uma regra do Amazon EventBridge roteia o evento aprovado para uma fila do Amazon SQS, preservando a ordenação para liquidação e criando um buffer contra limites de throughput downstream.
  9. A função Lambda de postagem lê do Amazon SQS e invoca o subsistema de postagem downstream para postar a transação. Por fim, a função publica um evento de conclusão no barramento de eventos, finalizando o ciclo de vida da transação.

Com chaves gerenciadas pelo cliente configuradas no DynamoDB, Amazon EventBridge, SQS e na função durável do AWS Lambda, cada parte dos dados persistidos neste pipeline é criptografada com chaves que você possui e controla. O passo a passo a seguir mostra como implantar essa configuração com o Terraform.

A Figura 1 mostra a arquitetura de referência para esta solução.

Arquitetura de referência

Reference architecture for payment processing using Lambda durable functions

Figura 1: Processamento de pagamentos usando funções duráveis do Lambda

Pré-requisitos

Para implantar esta solução, você precisa dos seguintes pré-requisitos:

  1. Conta AWS e CLI: Uma conta AWS ativa com a AWS CLI instalada e configurada com as credenciais apropriadas.
  2. Terraform: Terraform instalado (versão 1.0 ou posterior) para provisionamento de infraestrutura.
  3. Ambiente Python: Python 3.11 ou posterior, com pytest para executar testes de unidade. O pacote aws-durable-execution-sdk-python requer Python 3.11 ou posterior.
  4. Permissões do AWS Identity and Access Management (IAM): As permissões do IAM para criar os recursos. Siga o repositório de exemplo para a política de exemplo.
  5. Compreensão básica e familiaridade com serviços Serverless da AWS.

Passo a passo da solução

A seguir, um guia passo a passo para implantar e testar a solução de processamento de pagamentos.

Etapa 1: Clone o repositório

git clone https://github.com/aws-samples/sample-payment-processing-with-lambda-durable-functions.git
cd sample-payment-processing-with-lambda-durable-functions/source

Etapa 2: Execute os testes de unidade

Valide a lógica de processamento de pagamentos localmente antes de implantar:

cd lambda-src/business_rules
pip3 install -r requirements-test.txt
pytest test_app.py -v

Isso executa testes de unidade que abrangem a validação de transações, verificações de regras de negócio (detecção de transações estrangeiras, conversão de moeda, tipo de comerciante), validação de esquema de eventos e tratamento de configurações incorretas. Os testes usam o AWS Durable Execution Testing SDK para executar o handler localmente sem implantar recursos da AWS.

A Figura 2 mostra um exemplo dos resultados de testes executados localmente.

Test run results of the business rules

Figura 2: Resultados da execução de testes das regras de negócio

Etapa 3: Inspecione a construção das funções duráveis do Lambda

Abra a função Lambda payments-business-rules em source/lambda-src/business_rules/business-rules-app.py para ver um exemplo de função durável do Lambda. Consulte a Figura 3 para o passo a passo do código.

Principais recursos utilizados
  1. Decorador @durable_execution: Transforma um handler Lambda padrão em um handler de função durável. O SDK de execução durável gerencia o checkpoint automaticamente. Nenhuma alteração de infraestrutura é necessária.
  2. context.step("validate-transaction"): Valida que a transação tem um issuingCountryCode não vazio. A execução durável registra em checkpoint o resultado (True ou False) no armazenamento durável. A execução durável restaura os resultados do checkpoint em vez de reexecutar as etapas durante a fase de replay. Essa fase ocorre sempre que a função é reinvocada após uma interrupção, como a conclusão de um período de espera, uma falha ou uma suspensão. Esse resultado registrado em checkpoint faz parte dos dados de execução durável criptografados pela sua chave gerenciada pelo cliente.
  3. context.step("publish-posting-failure"): Publica o envelope completo do Amazon EventBridge para o Amazon SNS quando a validação falha. Essa etapa é executada apenas no caminho de falha. O runtime registra em checkpoint a resposta de publicação do Amazon SNS no armazenamento durável.
  4. context.parallel("run-business-rules"): Executa três verificações de regras independentes simultaneamente: detecção de transações estrangeiras, conversão de moeda e validação do tipo de comerciante. Cada ramificação registra em checkpoint de forma independente. Se uma ramificação falhar, as outras não serão reproduzidas ao retomar. O resultado de cada ramificação é persistido no armazenamento durável e criptografado pela chave gerenciada pelo cliente.
  5. ctx.step("trigger-foreign-transaction-rule") (dentro do paralelo): Compara billingAmount com transactionAmount. Se forem diferentes, emite um evento ForeignTransactionFound para o Amazon EventBridge. Essa etapa é registrada em checkpoint de forma independente dentro do grupo paralelo.
  6. ctx.step("trigger-conversion-rate-rule") (dentro do paralelo): Verifica se conversionRate é igual a 1. Se for, emite um evento CurrencyConversionTransactionFound para o Amazon EventBridge. Essa etapa é registrada em checkpoint de forma independente dentro do grupo paralelo.
  7. ctx.step("trigger-merchant-rule") (dentro do paralelo): Verifica se merchantType é igual a AAFF. Se for, emite um evento WarningMerchantTypeTransactionFound para o Amazon EventBridge. Essa etapa é registrada em checkpoint de forma independente dentro do grupo paralelo.
  8. context.step("post-transaction-processed"): Emite o evento final TransactionPostingApproved para o Amazon EventBridge. Essa etapa só é alcançada quando a validação é aprovada e todas as regras de negócio são concluídas. O runtime registra em checkpoint a resposta do Amazon EventBridge. No replay, se essa etapa já foi bem-sucedida, o evento não é republicado, o que garante semântica de aprovação exatamente uma vez.
  9. context.logger: Fornece registro em log com reconhecimento de replay em todo o handler. Durante o replay de etapas já concluídas, as instruções de log são suprimidas para evitar entradas de log duplicadas no Amazon CloudWatch.
Lambda durable functions code walkthrough

Figura 3: Código de exemplo das funções duráveis do Lambda

Etapa 4: Implante a infraestrutura com o Terraform

Atualmente, o Terraform não oferece suporte à associação de uma chave gerenciada pelo cliente diretamente à função durável. Você cria a chave simétrica no Terraform e depois associa a chave à função durável no AWS Management Console. Consulte source/durable_kms.tf para a configuração da chave.

Inicialize e implante os recursos da AWS que compõem a solução:

cd ../../
terraform init
terraform plan -var="region=us-east-2"

Revise a saída do plano e, em seguida, aplique:

terraform apply -var="region=us-east-2" --auto-approve

Observação: Substitua us-east-2 pela sua região da AWS preferida.

Após a conclusão bem-sucedida, o Terraform gera o alias da chave do AWS KMS, o ARN da chave e o ARN do DynamoDB Streams usados pelo pipeline orientado por eventos:

Apply complete! Resources: N added, 0 changed, 0 destroyed.

Outputs:

durable_kms_key_alias = "durable-function-encryption"
durable_kms_key_arn = "arn:aws:kms:us-east-2:xxxxxxxxxxxx:key/4e87d4c2-1190-4db4-8b97-46657f83ee00"
stream_arn = "arn:aws:dynamodb:us-east-2:xxxxxxxxxxxx:table/visa/stream/2026-03-16T14:25:47.847"

Etapa 5: Verifique a configuração das funções duráveis do Lambda

No console do AWS Lambda, navegue até a função payments-business-rules. Confirme que o Tipo da função exibe Durável, o que indica que o mecanismo de checkpoint e replay está ativo. A Figura 4 mostra a configuração esperada da função.

The durable function in the AWS Lambda console

Figura 4: A função durável do Lambda no console do AWS Lambda

Etapa 6: Adicione a chave do AWS KMS à função durável do Lambda

  1. A função durável não está criptografada com uma chave gerenciada pelo cliente. A Figura 5 mostra a configuração de criptografia da função como vazia.
    The Lambda durable function missing an AWS KMS key in the AWS Lambda console

    Figura 5: A função durável do Lambda sem uma chave gerenciada pelo cliente no console do AWS Lambda

  2. Escolha Editar e, em seguida, ative Personalizar configurações de criptografia, como mostrado na Figura 6.
    The Lambda durable function encryption settings in the AWS Lambda console

    Figura 6: Verificação da criptografia da função durável do Lambda no console do AWS Lambda

  3. Selecione o ARN da chave do AWS KMS criada para a função durável. O ARN da chave está disponível na saída do Terraform da Etapa 4. A Figura 7 mostra a seleção da chave.
    Selecting the AWS KMS key for the durable function in the AWS Lambda console

    Figura 7: Seleção do ARN da chave do AWS KMS para a função durável no console do AWS Lambda

  4. Escolha Salvar e confirme que a função durável agora está criptografada com uma chave gerenciada pelo cliente, como mostrado na Figura 8.
    The Lambda durable function with the AWS KMS key in the AWS Lambda console

    Figura 8: Função durável do AWS Lambda com a chave gerenciada pelo cliente no console do AWS Lambda

Etapa 7: Execute um pagamento de teste

Invoque a função Lambda payments-visa-mock para simular um fluxo de autorização de ponta a ponta. A função mock lê mensagens de exemplo de autorização Visa a partir de um arquivo CSV e as grava no DynamoDB, o que aciona o pipeline orientado por eventos. A Figura 9 mostra uma invocação de teste de exemplo.

Invoking the payments-visa-mock function to trigger the workflow

Figura 9: Invocar a função payments-visa-mock para acionar o fluxo de trabalho

A Figura 10 mostra uma resposta de exemplo após a invocação.

Test results from the payments-visa-mock function

Figura 10: Resultados de teste da função payments-visa-mock para acionar o fluxo de trabalho

A invocação da função Lambda mock cria registros que seguem o processo descrito nas etapas de arquitetura anteriores.

Etapa 8: Verifique os resultados

Abra o Amazon CloudWatch Logs e inspecione o grupo de logs /aws/lambda/payments-business_rules. Esse grupo de logs pertence à função durável do Lambda para este caso de uso. A Figura 11 mostra o grupo de logs do CloudWatch no console.

Search in CloudWatch Logs for the durable function log group

Figura 11: Pesquisa no CloudWatch

Você verá o ciclo de vida completo das regras de negócio para cada transação, conforme mostrado na Figura 12. As seções destacadas mostram todas as regras de negócio executadas pela função durável. Cada etapa é registrada em checkpoint pelo runtime e criptografada pela chave gerenciada pelo cliente.

Search Results in lambda durable functions console

Figura 12: Resultados da pesquisa no console de funções duráveis do Lambda

Você também pode verificar os outros grupos de logs para rastrear o pipeline completo:

  • /aws/lambda/payments-enrich: Logs de enriquecimento de transações.
  • /aws/lambda/payments-posting: Logs de postagem de liquidação.

Etapa 9: Verifique a configuração da chave gerenciada pelo cliente

Você pode verificar a configuração da chave usando a AWS CLI:

aws lambda get-function-configuration \
    --function-name payments-business-rules \
    --query "DurableConfig" \
    --region us-east-2

Resposta esperada:

{
    "KMSKeyArn": "arn:aws:kms:us-east-2:xxxxxxxxxxxx:key/4e87d4c2-1190-4db4-8b97-46657f83ee00",
    "RetentionPeriodInDays": 7,
    "ExecutionTimeout": 180
}

Você pode pesquisar no AWS CloudTrail para rastrear as chamadas do AWS KMS. Quando você configura ou atualiza a chave gerenciada pelo cliente em uma função durável, o Lambda valida a política da chave com chamadas de teste (dry-run) GenerateDataKey e Decrypt. Essas chamadas aparecem no CloudTrail com um código de erro DryRunOperationException, o que confirma que as permissões da política da chave estão corretas e não indica um erro real. Para mais detalhes, consulte Encrypting AWS Lambda durable execution data.

Limpeza

Para evitar cobranças contínuas, destrua todos os recursos implantados usando o seguinte comando:

terraform destroy -var="region=us-east-2" --auto-approve

Saída esperada:

Destroy complete! Resources: N destroyed.

Conclusão

Nesta publicação, você configurou uma chave gerenciada pelo cliente para criptografar dados de execução durável em uma função durável do Lambda. Com uma chave gerenciada pelo cliente, você controla o cronograma de rotação da chave, restringe o acesso à descriptografia por meio da política da chave e gera trilhas de auditoria por função no AWS CloudTrail. Você pode revogar o acesso aos dados de execução durável em qualquer momento atualizando a política da chave, dando a você controle total sobre quem pode ler o estado da execução. As execuções em andamento são interrompidas na próxima chamada de checkpoint, e novas execuções devem ser iniciadas após a restauração do acesso. Para detalhes, consulte When the customer managed key is unavailable.

Para processadores de pagamento e instituições financeiras, criptografar dados de execução durável com uma chave gerenciada pelo cliente satisfaz obrigações de conformidade para criptografia de dados em repouso, governança de chaves e auditabilidade de acesso em fluxos de trabalho de transações de múltiplas etapas.

Para começar, clone o repositório de exemplo e siga o passo a passo anterior. Para saber mais sobre as funções duráveis do Lambda, consulte o Guia do Desenvolvedor do AWS Lambda.

Recursos relacionados

Este conteúdo foi traduzido a partir da publicação original do blog, que pode ser encontrada aqui.

Biografia do Autores

Rajdeep Banerjee é Partner Solutions Architect na Amazon Web Services.
Brian Krygsman é Worldwide Serverless Specialist Solutions Architect na Amazon Web Services.

Ramesh Mathikumar é Principal Delivery Consultant na Amazon Web Services.

 

 

Biografia do tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.
https://www.linkedin.com/in/danielabib/
Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless.
https://www.linkedin.com/in/nicolastarzia