# Segurança no AWS Lambda A segurança da nuvem na AWS é a nossa maior prioridade. Como cliente da AWS, você contará com um data center e uma arquitetura de rede criados para atender aos requisitos das organizações com as maiores exigências de segurança. A segurança é uma responsabilidade compartilhada entre a AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isto como segurança *da* nuvem e segurança *na* nuvem: + **Segurança da nuvem:** a AWS é responsável pela proteção da infraestrutura que executa Serviços da AWS na Nuvem AWS. A AWS também fornece serviços que podem ser usados com segurança. Auditores de terceiros testam e verificam regularmente a eficácia da nossa segurança como parte dos [programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). Para saber mais sobre os programas de conformidade que se aplicam ao AWS Lambda, consulte [Serviços da AWS no escopo pelo programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/). + **Segurança na nuvem**: sua responsabilidade é determinada pelo serviço da AWS que você usa. Você também é responsável por outros fatores, incluindo a confidencialidade de seus dados, os requisitos da empresa e as leis e regulamentos aplicáveis. Esta documentação ajuda a entender como aplicar o modelo de responsabilidade compartilhada ao usar o Lambda. Os tópicos a seguir mostram como configurar o Lambda para atender aos seus objetivos de segurança e conformidade. Saiba também como usar outros Serviços da AWS que ajudam você a monitorar e proteger os recursos do Lambda. Para obter mais informações sobre como colocar os princípios de segurança em prática para aplicações do Lambda, consulte [Security](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops) no Serverless Land. **Topics** + [ # Proteção de dados no AWS Lambda ](security-dataprotection.md) + [ # Uso de perfis vinculados ao serviço para o Lambda ](using-service-linked-roles.md) + [ # Gerenciamento de identidade e acesso para AWS Lambda ](security-iam.md) + [ # Criar uma estratégia de governança para funções e camadas do Lambda ](governance-concepts.md) + [ # Validação de conformidade do AWS Lambda ](security-compliance.md) + [ # Resiliência no AWS Lambda ](security-resilience.md) + [ # Segurança da infraestrutura no AWS Lambda ](security-infrastructure.md) + [ # Proteção de workloads com endpoints públicos ](security-public-endpoints.md) + [ # Usar a assinatura de código para verificar integridade de código com o Lambda ](configuration-codesigning.md) # Proteção de dados no AWS Lambda O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) da AWS se aplica à proteção de dados no AWS Lambda. Conforme descrito nesse modelo, AWS é responsável por proteger a infraestrutura global que executa todas as Nuvem AWS. Você é responsável por manter o controle sobre seu conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para obter mais informações sobre a privacidade de dados, consulte as [Perguntas Frequentes sobre Privacidade de Dados.](https://aws.amazon.com/compliance/data-privacy-faq/). Para obter mais informações sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS*. Para fins de proteção de dados, recomendamos que você proteja as credenciais da Conta da AWS e configure as contas de usuário individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas: + Use uma autenticação multifator (MFA) com cada conta. + Use SSL/TLS para se comunicar com os recursos da AWS. Exigimos TLS 1.2 e recomendamos TLS 1.3. + Configure a API e atividade do usuário logando com AWS CloudTrail. Para obter mais informações sobre como usar as trilhas do CloudTrail para capturar atividades da AWS, consulte [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia do Usuário do AWS CloudTrail*. + Use as soluções de criptografia AWS, juntamente com todos os controles de segurança padrão em Serviços da AWS. + Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sigilosos armazenados no Amazon S3. + Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar a AWS por meio de uma interface de linha de comando ou uma API, use um endpoint do FIPS. Para obter mais informações sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). É altamente recomendável que nunca sejam colocadas informações de identificação confidenciais, como endereços de e-mail dos seus clientes, em marcações ou campos de formato livre, como um campo **Nome**. Isso inclui usar o console, a API, a AWS CLI ou os SDKs da AWS ao trabalhar com o Lambda ou outros Serviços da AWS. Quaisquer dados inseridos em tags ou campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, recomendemos fortemente que não sejam incluídas informações de credenciais no URL para validar a solicitação a esse servidor. **Topics** + [ ## Criptografia em trânsito ](#security-privacy-intransit) + [ # Criptografia de dados em repouso no AWS Lambda ](security-encryption-at-rest.md) ## Criptografia em trânsito Os endpoints da API do Lambda oferecem suporte a conexões seguras somente em HTTPS. Ao gerenciar recursos do Lambda com o Console de gerenciamento da AWS, o AWS SDK ou a API do Lambda, toda a comunicação é criptografada com Transport Layer Security (TLS). Para obter uma lista completa de endpoints de API, consulte [Regiões e endpoints da AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) no Referência geral da AWS. Quando você [conecta a função a um sistema de arquivos](configuration-filesystem.md), o Lambda usa a Criptografia em trânsito para todas as conexões. Para obter mais informações, consulte [Criptografia de dados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) no *Manual do usuário do Amazon Elastic File System*. Quando você usa[variáveis de ambiente](configuration-envvars.md), é possível habilitar os ajudantes de criptografia de console para usar a criptografia no lado do cliente para proteger as variáveis de ambiente em trânsito. Para ter mais informações, consulte [Proteger variáveis ​​de ambiente no Lambda](configuration-envvars-encryption.md). # Criptografia de dados em repouso no AWS Lambda O Lambda sempre fornece criptografia em repouso para os seguintes recursos usando uma [Chave pertencente à AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) ou uma [Chave gerenciada pela AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk): + Variáveis de ambiente + Os arquivos dos quais você faz upload no Lambda, incluindo pacotes de implantação e arquivos de camada + Objetos de critérios do filtro do mapeamento da origem de eventos Você também pode configurar o Lambda para usar uma chave gerenciada pelo cliente para criptografar suas [variáveis de ambiente](configuration-envvars-encryption.md), [pacotes de implantação .zip](encrypt-zip-package.md) e [objetos de critérios de filtro](invocation-eventfiltering.md#filter-criteria-encryption). O Amazon CloudWatch Logs e o AWS X-Ray também criptografam dados por padrão, e podem ser configurados para usarem uma chave gerenciada pelo cliente. Para obter mais detalhes, consulte [Criptografar dados de log no CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) e [Proteção de dados no AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html). ## Monitorar suas chaves de criptografia para o Lambda Quando você usa uma chave do AWS KMS gerenciada pelo cliente com o Lambda, também pode usar o [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Os exemplos a seguir são eventos do CloudTrail para chamadas `Decrypt`, `DescribeKey` e `GenerateDataKey` feitas pelo Lambda para acessar dados criptografados por sua chave gerenciada pelo cliente. ------ #### [ Decrypt ] Se você usou uma chave do AWS KMS gerenciada pelo cliente para criptografar seu objeto de [critérios de filtro](invocation-eventfiltering.md#filter-criteria-encryption), o Lambda envia uma solicitação `Decrypt` em seu nome quando você tenta acessá-la em texto simples (por exemplo, de uma chamada `ListEventSourceMappings`). O evento de exemplo a seguir registra a operação `Decrypt`: ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:45:23Z", "mfaAuthenticated": "false" } }, "invokedBy": "lambda.amazonaws.com" }, "eventTime": "2024-05-30T01:05:46Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "eu-west-1", "sourceIPAddress": "lambda.amazonaws.com", "userAgent": "lambda.amazonaws.com", "requestParameters": { "keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==", "aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source", "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function" }, "encryptionAlgorithm": "SYMMETRIC_DEFAULT" }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ``` ------ #### [ DescribeKey ] Se você usou uma chave do AWS KMS gerenciada pelo cliente para criptografar seu objeto de [critérios de filtro](invocation-eventfiltering.md#filter-criteria-encryption), o Lambda envia uma solicitação `DescribeKey` em seu nome quando você tenta acessá-la (por exemplo, de uma chamada `GetEventSourceMapping`). O evento de exemplo a seguir registra a operação `DescribeKey`: ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:45:23Z", "mfaAuthenticated": "false" } } }, "eventTime": "2024-05-30T01:09:40Z", "eventSource": "kms.amazonaws.com", "eventName": "DescribeKey", "awsRegion": "eu-west-1", "sourceIPAddress": "54.240.197.238", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { "keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_256_GCM_SHA384", "clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com" }, "sessionCredentialFromConsole": "true" } ``` ------ #### [ GenerateDataKey ] Quando você usa uma chave do AWS KMS gerenciada pelo cliente para criptografar seu objeto de [critérios de filtro](invocation-eventfiltering.md#filter-criteria-encryption) em uma chamada `CreateEventSourceMapping` ou `UpdateEventSourceMapping`, o Lambda envia uma solicitação `GenerateDataKey` em seu nome para gerar uma chave de dados para criptografar os critérios de filtro ([criptografia envelopada](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). O evento de exemplo a seguir registra a operação `GenerateDataKey`: ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:06:07Z", "mfaAuthenticated": "false" } }, "invokedBy": "lambda.amazonaws.com" }, "eventTime": "2024-05-30T01:04:18Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKey", "awsRegion": "eu-west-1", "sourceIPAddress": "lambda.amazonaws.com", "userAgent": "lambda.amazonaws.com", "requestParameters": { "numberOfBytes": 32, "keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==", "aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source", "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function" }, }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management" } ``` ------ # Uso de perfis vinculados ao serviço para o Lambda O Lambda usa [perfis vinculados a serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). O perfil vinculado ao serviço é um tipo exclusivo de perfil do IAM vinculado diretamente ao Lambda. Os perfis vinculados ao serviço são definidos previamente pelo Lambda e incluem as permissões necessárias para o serviço chamar outros serviços da AWS em seu nome. O Lambda define as permissões dos perfis vinculados a serviços e somente o Lambda pode assumir seus perfis. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM. Um perfil vinculado ao serviço poderá ser excluído somente após excluir seus atributos relacionados. Isso protege seus recursos do Lambda, pois não é possível remover por engano as permissões para acessar os recursos. Para obter informações sobre outros serviços compatíveis com perfis vinculados ao serviço, consulte [serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que apresentam **Sim** na coluna **Perfis vinculados aos serviços**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado a esse serviço. ## Permissões de perfil vinculado ao serviço para o Lambda O Lambda usa o perfil vinculado a serviço chamado **AWSServiceRoleForLambda**. O perfil vinculado ao serviço confia nos seguintes serviços para aceitar o perfil: + `lambda.amazonaws.com` A política de permissões de perfil chamada AWSLambdaServiceRolePolicy permite que o Lambda conclua as ações a seguir nos recursos especificados: + Ação: `ec2:TerminateInstances` em `arn:aws:ec2:*:*:instance/*` com a condição que `ec2:ManagedResourceOperator` seja igual a `scaler.lambda.amazonaws.com` + Ação: `ec2:DescribeInstanceStatus` e `ec2:DescribeInstances` em `*`. Você deve configurar permissões para permitir que seus usuários, grupos ou perfis criem, editem ou excluam um perfil vinculado ao serviço. Para obter mais informações, consulte [Permissões do perfil vinculado a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do usuário do IAM*. Para atualizações de políticas gerenciadas, consulte [Políticas gerenciadas do Lambda](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates). ## Criação de u perfil vinculado a serviço para o Lambda Não é necessário criar manualmente um perfil vinculado ao serviço. Quando você cria um provedor de capacidade do Lambda no Console de gerenciamento da AWS, na AWS CLI ou com a API da AWS, o Lambda cria o perfil vinculado ao serviço para você. Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você cria um provedor de capacidade do Lambda, o Lambda cria o perfil vinculado ao serviço para você novamente. Também é possível usar o console do IAM para criar um perfil vinculado ao serviço com o caso de uso **AWSServiceRoleForLambda**. Na AWS CLI ou na API do AWS, crie um perfil vinculado a serviço com o nome de serviço `lambda.amazonaws.com`. Para obter mais informações, consulte [Criar uma função vinculada ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) no *Manual do usuário do IAM*. Se você excluir essa função vinculada ao serviço, será possível usar esse mesmo processo para criar a função novamente. ## Edição de perfil vinculado ao serviço para o Lambda O Lambda não permite que você edite o perfil vinculado ao serviço AWSServiceRoleForLambda. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para saber mais, consulte [Editar um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*. ## Exclusão de um perfil vinculado a serviço para o Lambda Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar os recursos de seu perfil vinculado ao serviço antes de excluí-lo manualmente. **nota** Se o serviço do Lambda estiver usando o perfil quando você tenta excluir os recursos, a exclusão poderá falhar. Se isso acontecer, espere alguns minutos e tente a operação novamente. **Para excluir os recursos do Lambda utilizados por AWSServiceRoleForLambda** 1. Remova todos os provedores de capacidade do Lambda da sua conta. É possível fazer isso usando o console, a CLI ou a API do Lambda. 1. Verifique se nenhum provedor de capacidade do Lambda permanece em sua conta antes de tentar excluir o perfil vinculado ao serviço. **Como excluir manualmente o perfil vinculado ao serviço usando o IAM** Use o console do IAM, a AWS CLI ou a API da AWS para excluir o perfil vinculado ao serviço AWSServiceRoleForLambda. Para saber mais, consulte [Excluir um perfil vinculado ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*. ## Regiões com suporte a perfis vinculados a serviço do Lambda O Lambda não oferece suporte ao uso de perfis vinculados ao serviço em todas as regiões onde o serviço está disponível. Há suporte para o AWSServiceRoleForLambda nas regiões a seguir. | Nome da região | Identidade da região | Suporte no Lambda | | --- | --- | --- | | Leste dos EUA (Norte da Virgínia) | us-east-1 | Sim | | Leste dos EUA (Ohio) | us-east-2 | Sim | | Oeste dos EUA (N. da Califórnia) | us-west-1 | Sim | | Oeste dos EUA (Oregon) | us-west-2 | Sim | | África (Cidade do Cabo) | af-south-1 | Não | | Ásia-Pacífico (Hong Kong) | ap-east-1 | Sim | | Ásia-Pacífico (Jacarta) | ap-southeast-3 | Sim | | Ásia-Pacífico (Bangkok) | ap-southeast-7 | Sim | | Ásia-Pacífico (Mumbai) | ap-south-1 | Sim | | Ásia Pacifico (Osaka) | ap-northeast-3 | Não | | Ásia-Pacífico (Seul) | ap-northeast-2 | Não | | Ásia-Pacífico (Singapura) | ap-southeast-1 | Sim | | Ásia-Pacífico (Sydney) | ap-southeast-2 | Sim | | Ásia-Pacífico (Tóquio) | ap-northeast-1 | Sim | | Canadá (Central) | ca-central-1 | Não | | Europa (Frankfurt) | eu-central-1 | Sim | | Europa (Irlanda) | eu-west-1 | Sim | | Europa (Londres) | eu-west-2 | Sim | | Europa (Milão) | eu-south-1 | Não | | Europa (Paris) | eu-west-3 | Não | | Europa (Estocolmo) | eu-north-1 | Não | | Oriente Médio (Barém) | me-south-1 | Não | | Oriente Médio (Emirados Árabes Unidos) | me-central-1 | Não | | América do Sul (São Paulo) | sa-east-1 | Não | | AWS GovCloud (Leste dos EUA) | us-gov-east-1 | Não | | AWS GovCloud (Oeste dos EUA) | us-gov-west-1 | Não | # Gerenciamento de identidade e acesso para AWS Lambda O AWS Identity and Access Management (IAM) é um serviço da AWS service (Serviço da AWS) que ajuda um administrador a controlar com segurança o acesso aos recursos da AWS. Os administradores do IAM controlam quem pode ser *autenticado* (conectado) e *autorizado* (ter permissões) para usar os recursos do Lambda. O IAM é um AWS service (Serviço da AWS) que pode ser usado sem custo adicional. **Topics** + [ ## Público ](#security_iam_audience) + [ ## Autenticação com identidades ](#security_iam_authentication) + [ ## Gerenciar o acesso usando políticas ](#security_iam_access-manage) + [ # Como o AWS Lambda funciona com o IAM ](security_iam_service-with-iam.md) + [ # Exemplos de políticas baseadas em identidade para o AWS Lambda ](security_iam_id-based-policy-examples.md) + [ # AWS Políticas gerenciadas pela do AWS Lambda ](security-iam-awsmanpol.md) + [ # Solução de problemas de identidade e acesso do AWS Lambda ](security_iam_troubleshoot.md) ## Público A forma como você usa o AWS Identity and Access Management (IAM) difere com base em seu perfil: + **Usuário do serviço**: solicite permissões ao seu administrador se você não conseguir acessar os atributos (consulte [Solução de problemas de identidade e acesso do AWS Lambda](security_iam_troubleshoot.md)). + **Administrador do serviço**: determine o acesso do usuário e envie solicitações de permissão (consulte [Como o AWS Lambda funciona com o IAM](security_iam_service-with-iam.md)) + **Administrador do IAM**: escreva políticas para gerenciar o acesso (consulte [Exemplos de políticas baseadas em identidade para o AWS Lambda](security_iam_id-based-policy-examples.md)) ## Autenticação com identidades A autenticação é a forma como fazer login na AWS usando suas credenciais de identidade. Você precisa se autenticar como o Usuário raiz da conta da AWS, como um usuário do IAM ou assumindo um perfil do IAM. Você pode fazer login como uma identidade federada usando credenciais de uma fonte de identidade, como o Centro de Identidade do AWS IAM (Centro de Identidade do IAM), autenticação única ou credenciais do Google/Facebook. Para ter mais informações sobre como fazer login, consulte [Como fazer login em sua Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS*. Para acesso programático, a AWS oferece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*. ### Usuário-raiz Conta da AWS Ao criar uma Conta da AWS, você começa com uma identidade de login única chamada *usuário-raiz* da Conta da AWS, que tem acesso total a todos os recursos e Serviços da AWS. É altamente recomendável não usar o usuário-raiz em tarefas diárias. Consulte as tarefas que exigem credenciais de usuário-raiz em [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*. ### Identidade federada Como prática recomendada, exija que os usuários humanos usem a federação com um provedor de identidades para acessar a Serviços da AWS usando credenciais temporárias. Uma *identidade federada* é um usuário do seu diretório empresarial, de um provedor de identidades da web ou do Directory Service que acessa Serviços da AWS usando credenciais de uma fonte de identidade. As identidades federadas assumem funções que oferecem credenciais temporárias. Para o gerenciamento de acesso centralizado, recomendamos Centro de Identidade do AWS IAM. Para saber mais, consulte [O que é o IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) no *Guia do usuário do Centro de Identidade do AWS IAM*. ### Usuários e grupos do IAM Um *[usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas para uma única pessoa ou aplicação. É recomendável usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para saber mais, consulte [Exigir que os usuários humanos usem a federação com um provedor de identidade para acessar a AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*. Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*. ### Perfis do IAM Uma *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade com permissões específicas que oferece credenciais temporárias. É possível assumir um perfil [alternando de um usuário para um perfil do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou chamando uma operação de API AWS CLI ou AWS. Para saber mais, consulte [Métodos para assumir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) no *Manual do usuário do IAM*. Os perfis do IAM são úteis para acesso de usuário federado, permissões de usuário do IAM temporárias, acesso entre contas, acesso entre serviços e aplicações em execução no Amazon EC2. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. ## Gerenciar o acesso usando políticas Você controla o acesso na AWS criando políticas e anexando-as a identidades ou recursos da AWS. Uma política define permissões quando associada a uma identidade ou a um recurso. A AWS avalia essas políticas quando a entidade principal faz uma solicitação. A maioria das políticas é armazenada na AWS como documentos JSON. Para ter mais informações sobre documentos de política JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*. Por meio de políticas, os administradores especificam quem tem acesso a que, definindo qual **entidade principal** pode realizar **ações** em quais **recursos** e sob quais **condições**. Por padrão, usuários e perfis não têm permissões. Um administrador do IAM cria políticas do IAM e as adiciona aos perfis, os quais os usuários podem então assumir. As políticas do IAM definem permissões, independentemente do método usado para realizar a operação. ### Políticas baseadas em identidade As políticas baseadas em identidade são documentos de políticas de permissão JSON que você anexa a uma identidade (usuário, grupo ou perfil). Essas políticas controlam quais ações as identidades podem realizar, em quais recursos e sob quais condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*. As políticas baseadas em identidade podem ser políticas *em linha* (incorporadas diretamente em uma única identidade) ou *políticas gerenciadas* (políticas autônomas anexadas a várias identidades). Para saber como escolher entre uma política gerenciada e políticas em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) no *Guia do usuário do IAM*. ### Políticas baseadas em recursos Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. Entre os exemplos estão *políticas de confiança de perfil* do IAM e *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. Políticas baseadas em recursos são políticas em linha localizadas nesse serviço. Não é possível usar as políticas gerenciadas pela AWS do IAM em uma política baseada em atributos. ### Outros tipos de política A AWS permite outros tipos de política capazes de definir o máximo de permissões concedidas por tipos de política mais comuns: + **Limites de permissões**: definem o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*. + **Políticas de Controle de Serviços (SCPs)**: as SCPs especificam o número máximo de permissões para uma organização ou uma unidade organizacional no AWS Organizations. Para saber mais, consulte [Políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia do usuário do AWS Organizations*. + **Políticas de controle de recursos (RCPs)**: definem o número máximo de permissões disponíveis para recursos em suas contas. Consulte mais informações em [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) no *Guia do usuário do AWS Organizations*. + **Políticas de sessão**: políticas avançadas transmitidas como um parâmetro durante a criação de uma sessão temporária para um perfil ou um usuário federado. Para saber mais, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*. ### Vários tipos de política Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como a AWS determina permitir ou não uma solicitação quando há vários tipos de política envolvidos, consulte [Lógica da avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do Usuário do IAM*. # Como o AWS Lambda funciona com o IAM Antes de usar o IAM para gerenciar o acesso ao Lambda, saiba quais recursos do IAM estão disponíveis para uso com o Lambda. | Recurso do IAM | Compatibilidade com o Lambda | | --- | --- | | [Políticas baseadas em identidade](#security_iam_service-with-iam-id-based-policies) | Sim | | [Políticas baseadas em atributos](#security_iam_service-with-iam-resource-based-policies) | Sim | | [Ações de políticas](#security_iam_service-with-iam-id-based-policies-actions) | Sim | | [Recursos de políticas](#security_iam_service-with-iam-id-based-policies-resources) | Sim | | [Chaves de condição de política (específicas do serviço)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sim | | [ACLs](#security_iam_service-with-iam-acls) | Não | | [ABAC (tags em políticas)](#security_iam_service-with-iam-tags) | Parcial | | [Credenciais temporárias](#security_iam_service-with-iam-roles-tempcreds) | Sim | | [Sessões de acesso direto (FAS)](#security_iam_service-with-iam-principal-permissions) | Não | | [Perfis de serviço](#security_iam_service-with-iam-roles-service) | Sim | | [Perfis vinculados a serviço](#security_iam_service-with-iam-roles-service-linked) | Parcial | Para obter uma visão geral de como o Lambda e outros serviços da AWS funcionam com a maioria dos recursos do IAM, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*. ## Políticas baseadas em identidades para o Lambda **Compatível com políticas baseadas em identidade:** sim As políticas baseadas em identidade são documentos de políticas de permissões JSON que podem ser anexados a uma identidade, como usuário do IAM, grupo de usuários ou perfil. Essas políticas controlam quais ações os usuários e perfis podem realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*. Com as políticas baseadas em identidade do IAM, é possível especificar ações e recursos permitidos ou negados, assim como as condições sob as quais as ações são permitidas ou negadas. Para saber mais sobre todos os elementos que podem ser usados em uma política JSON, consulte [Referência de elemento de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*. ### Exemplos de políticas baseadas em identidades para o Lambda Para visualizar exemplos de políticas baseadas em identidades do Lambda, consulte [Exemplos de políticas baseadas em identidade para o AWS Lambda](security_iam_id-based-policy-examples.md). ## Políticas baseadas em recursos no Lambda **Compatível com políticas baseadas em recursos:** sim Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. São exemplos de políticas baseadas em recursos as *políticas de confiança de perfil* do IAM e as *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. Para o atributo ao qual a política está anexada, a política define quais ações uma entidade principal especificado pode executar nesse atributo e em que condições. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. As entidades principais podem incluir contas, usuários, perfis, usuários federados ou Serviços da AWS. Para permitir o acesso entre contas, é possível especificar uma conta inteira ou as entidades do IAM em outra conta como a entidade principal em uma política baseada em recursos. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. Você pode associar uma política baseada em recursos a uma camada ou a uma função do Lambda. Essa política define quais entidades principais podem realizar ações na função ou na camada. Para saber como anexar uma política baseada em recursos a uma função ou a uma camada, consulte [Visualizar políticas do IAM baseadas em recurso no Lambda](access-control-resource-based.md). ## Ações de políticas para o Lambda **Compatível com ações de políticas:** sim Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada. Para ver uma lista das ações do Lambda, consulte [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) na *Service Authorization Reference*. As ações de políticas no Lambda usam o seguinte prefixo antes da ação: ``` lambda ``` Para especificar várias ações em uma única declaração, separe-as com vírgulas. ``` "Action": [ "lambda:action1", "lambda:action2" ] ``` Para visualizar exemplos de políticas baseadas em identidades do Lambda, consulte [Exemplos de políticas baseadas em identidade para o AWS Lambda](security_iam_id-based-policy-examples.md). ## Recursos de políticas para o Lambda **Compatível com recursos de políticas:** sim Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos. ``` "Resource": "*" ``` Para ver uma lista dos tipos de recurso do Lambda e seus ARNs, consulte [Resource types defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) na *Service Authorization Reference*. Para saber com quais ações é possível especificar o ARN de cada atributo, consulte [Ações definidas pelo AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions). Para visualizar exemplos de políticas baseadas em identidades do Lambda, consulte [Exemplos de políticas baseadas em identidade para o AWS Lambda](security_iam_id-based-policy-examples.md). ## Chaves de condição de políticas para o Lambda **Compatível com chaves de condição de política específicas de serviço:** sim Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**. O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição globais da AWS, consulte [Chaves de contexto de condição globais da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*. Para ver uma lista de chaves de condição do Lambda, consulte [Condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) na *Service Authorization Reference*. Para saber com quais ações e recursos é possível usar uma chave de condição, consulte [Ações definidas pelo AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions). Para visualizar exemplos de políticas baseadas em identidades do Lambda, consulte [Exemplos de políticas baseadas em identidade para o AWS Lambda](security_iam_id-based-policy-examples.md). ## ACLs no Lambda **Compatível com ACLs:** não As listas de controle de acesso (ACLs) controlam quais entidades principais (membros, usuários ou perfis da conta) têm permissões para acessar um recurso. As ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON. ## ABAC com o Lambda **Compatível com ABAC (tags em políticas):** parcial O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos chamados de tags. Você pode anexar tags a entidades do IAM e recursos da AWS e, em seguida, projetar políticas de ABAC para permitir operações quando a tag da entidade principal corresponder à tag no recurso. Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`. Se um serviço for compatível com as três chaves de condição para cada tipo de recurso, o valor será **Sim** para o serviço. Se um serviço for compatível com as três chaves de condição somente para alguns tipos de recursos, o valor será **Parcial** Para saber mais sobre o ABAC, consulte [Definir permissões com autorização do ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) no *Guia do usuário do IAM*. Para visualizar um tutorial com etapas para configurar o ABAC, consulte [Usar controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) no *Guia do usuário do IAM*. Para obter mais informações sobre marcação de recursos do Lambda, consulte [Usar controle de acesso baseado em atributos no Lambda](attribute-based-access-control.md). ## Usar credenciais temporárias com o Lambda **Compatível com credenciais temporárias:** sim As credenciais temporárias dão acesso de curto prazo aos recursos da AWS e são criadas automaticamente quando você usa a federação ou alterna os perfis. A AWS recomenda a você gerar credenciais temporárias dinamicamente, em vez de usar chaves de acesso de longo prazo. Para ter mais informações, consulte [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Serviços da Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*. ## Sessões de acesso direto para o Lambda **Compatível com sessões de acesso direto (FAS):** não As Sessões de Acesso Direto (FAS) usam as permissões da entidade principal chamando um AWS service (Serviço da AWS), bem como o AWS service (Serviço da AWS) solicitante, para fazer solicitações a serviços downstream. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Perfis de serviço do Lambda **Compatível com perfis de serviço:** sim O perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir um perfil de serviço do IAM. Para saber mais, consulte [Criar um perfil para delegar permissões a um AWS service (Serviço da AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do Usuário do IAM*. No Lambda, um perfil de serviço é chamado de [perfil de execução](lambda-intro-execution-role.md). **Atenção** Alterar as permissões de um perfil de serviço pode interromper a funcionalidade do Lambda. ## Perfis vinculados ao serviço para o Lambda **Compatível com perfis vinculados ao serviço:** parcialmente Um perfil vinculado a serviço é um tipo de perfil de serviço vinculado a um AWS service (Serviço da AWS). O serviço pode presumir o perfil de executar uma ação em seu nome. Perfis vinculados ao serviço aparecem em sua Conta da AWS e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não editar as permissões para perfis vinculados ao serviço. O Lambda não tem perfis vinculados a serviços, mas o Lambda@Edge tem. Para obter mais informações, consulte [Perfis vinculados ao serviço para o Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) no *Guia do desenvolvedor do Amazon CloudFront*. Para obter detalhes sobre como criar ou gerenciar perfis vinculados a serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Encontre um serviço na tabela que inclua um `Yes` na coluna **Perfil vinculado ao serviço**. Escolha o link **Sim** para visualizar a documentação do perfil vinculado a esse serviço . # Exemplos de políticas baseadas em identidade para o AWS Lambda Por padrão, os usuários e os perfis não têm permissões para criar ou modificar os recursos do Lambda. Para conceder permissão aos usuários para executar ações nos recursos que eles precisam, um administrador do IAM pode criar políticas do IAM. Para saber como criar uma política baseada em identidade do IAM ao usar esses documentos de política em JSON de exemplo, consulte [Criar políticas do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) no *Guia do usuário do IAM*. Para obter detalhes sobre as ações e os tipos de recurso definidos pelo Lambda, incluindo o formato dos ARNs para cada tipo de recurso, consulte [Actions, resources, and condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) na *Service Authorization Reference*. **Topics** + [ ## Práticas recomendadas de política ](#security_iam_service-with-iam-policy-best-practices) + [ ## Usar o console do Lambda ](#security_iam_id-based-policy-examples-console) + [ ## Permitir que os usuários visualizem suas próprias permissões ](#security_iam_id-based-policy-examples-view-own-permissions) ## Práticas recomendadas de política As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Lambda da sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações: + **Comece com as políticas gerenciadas pela AWS e avance para as permissões de privilégio mínimo**: para começar a conceder permissões a seus usuários e workloads, use as *políticas gerenciadas pela AWS*, que concedem permissões para muitos casos de uso comuns. Elas estão disponíveis em seus Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo cliente da AWS que são específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*. + **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*. + **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Também pode usar condições para conceder acesso a ações de serviço, se elas forem usadas por meio de um AWS service (Serviço da AWS) específico, como o CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*. + **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*. + **Exigir autenticação multifator (MFA)**: se houver um cenário que exija usuários do IAM ou um usuário raiz em sua Conta da AWS, ative a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*. Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*. ## Usar o console do Lambda Para acessar o console do AWS Lambda, é necessário ter um conjunto mínimo de permissões. Essas permissões devem autorizar você a listar e visualizar detalhes sobre os recursos do Lambda na sua Conta da AWS. Caso crie uma política baseada em identidade mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política. Não é necessário conceder permissões mínimas do console para usuários que fazem chamadas somente à AWS CLI ou à API do AWS. Em vez disso, permita o acesso somente a ações que correspondam à operação de API que estiverem tentando executar. Para obter um exemplo de política que concede acesso mínimo ao desenvolvimento de funções, consulte [Conceder aos usuários acesso a uma função do Lambda](permissions-user-function.md). Além das APIs do Lambda, o console do Lambda usa outros serviços para exibir a configuração do acionador e permite que você adicione novos acionadores. Se os usuários utilizam o Lambda com outros serviços, eles também precisam de acesso a esses serviços. Para obter mais detalhes sobre como configurar outros serviços do Lambda, consulte [Invocando o Lambda com eventos de outros serviços da AWS](lambda-services.md). ## Permitir que os usuários visualizem suas próprias permissões Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou de forma programática usando a AWS CLI ou a API da AWS. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` # AWS Políticas gerenciadas pela do AWS Lambda Uma política gerenciada pela AWS é uma política autônoma criada e administrada pela AWS. As políticas gerenciadas pela AWS são criadas para fornecer permissões a vários casos de uso comuns e permitir a atribuição de permissões a usuários, grupos e perfis. Lembre-se de que as políticas gerenciadas pela AWS podem não conceder permissões de privilégio mínimo para casos de uso específicos, por estarem disponíveis para uso por todos os clientes da AWS. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso. Não é possível alterar as permissões definidas em políticas gerenciadas pela AWS. Se a AWS atualiza as permissões definidas em um política gerenciada por AWS, a atualização afeta todas as identidades de entidades principais (usuários, grupos e perfis) às quais a política estiver vinculada. É provável que a AWS atualize uma política gerenciada por AWS quando um novo AWS service (Serviço da AWS) for lançado, ou novas operações de API forem disponibilizadas para os serviços existentes. Para saber mais, consulte [AWSPolíticas gerenciadas pela ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*. **Topics** + [ ## Política gerenciada pela AWS: AWSLambda\$1FullAccess ](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess) + [ ## Política gerenciada pela AWS: AWSLambda\$1ReadOnlyAccess ](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess) + [ ## Política gerenciada pela AWS: AWSLambdaBasicExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole) + [ ## Política gerenciada pela AWS: AWSLambdaBasicDurableExecutionRolePolicy ](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy) + [ ## Política gerenciada pela AWS: AWSLambdaDynamoDBExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole) + [ ## Política gerenciada pela AWS: AWSLambdaENIManagementAccess ](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess) + [ ## Política gerenciada pela AWS: AWSLambdaInvocation-DynamoDB ](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB) + [ ## Política gerenciada pela AWS: AWSLambdaKinesisExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole) + [ ## Política gerenciada pela AWS: AWSLambdaMSKExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole) + [ ## Política gerenciada pela AWS: AWSLambdaRole ](#lambda-security-iam-awsmanpol-AWSLambdaRole) + [ ## Política gerenciada pela AWS: AWSLambdaSQSQueueExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole) + [ ## Política gerenciada pela AWS: AWSLambdaVPCAccessExecutionRole ](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole) + [ ## Política gerenciada pela AWS: AWSLambdaManagedEC2ResourceOperator ](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator) + [ ## Política gerenciada pela AWS: AWSLambdaServiceRolePolicy ](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy) + [ ## Atualizações do Lambda para políticas gerenciadas pela AWS ](#lambda-security-iam-awsmanpol-updates) ## Política gerenciada pela AWS: AWSLambda\$1FullAccess Esta política concede acesso total às ações do Lambda. Também concede permissões a outros serviços da AWS usados para desenvolver e manter recursos do Lambda. É possível associar a política `AWSLambda_FullAccess` aos seus usuários, grupos e perfis. **Detalhes de permissões** Esta política inclui as seguintes permissões: + `lambda`: concede às entidades principais acesso total ao Lambda. + `cloudformation`: permite que as entidades principais descrevam as pilhas do AWS CloudFormation e listem os recursos nessas pilhas. + `cloudwatch`: permite que as entidades principais listem métricas do Amazon CloudWatch e obtenham dados de métricas. + `ec2`: permite que as entidades principais descrevam grupos de segurança, sub-redes e VPCs. + `iam`: permite que as entidades principais obtenham políticas, versões de políticas, funções, políticas de funções, políticas de funções anexadas e a lista de funções. Essa política também permite que as entidades principais passem perfis para o Lambda. A permissão `PassRole` é usada quando você atribui uma função de execução a uma função. A permissão `CreateServiceLinkedRole` é usada ao criar um perfil vinculado ao serviço. + `kms`: permite que as entidades principais listem aliases e descrevam chaves para a criptografia de volumes. + `logs`: permite que os as entidades principais descrevam fluxos de log, obtenham eventos de log, filtrem eventos de log e iniciem e interrompam sessões do Live Tail. + `states`: permite que as entidades principais descrevam e listem máquinas de estado do AWS Step Functions. + `tag`: permite que as entidades principais obtenham recursos com base em suas tags. + `xray`: permite que as entidades principais obtenham resumos de rastreamento de AWS X-Ray e recuperem uma lista de rastreamentos especificados por ID. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambda\$1ReadOnlyAccess Essa política concede acesso somente para leitura aos recursos do Lambda e a outros serviços da AWS usados para desenvolver e manter recursos do Lambda. É possível associar a política `AWSLambda_ReadOnlyAccess` aos seus usuários, grupos e perfis. **Detalhes de permissões** Esta política inclui as seguintes permissões: + `lambda`: permite que as entidades principais obtenham e listem todos os recursos. + `cloudformation`: permite que as entidades principais descrevam e listem pilhas do AWS CloudFormation e listem os recursos nessas pilhas. + `cloudwatch`: permite que as entidades principais listem métricas do Amazon CloudWatch e obtenham dados de métricas. + `ec2`: permite que as entidades principais descrevam grupos de segurança, sub-redes e VPCs. + `iam`: permite que as entidades principais obtenham políticas, versões de políticas, funções, políticas de funções, políticas de funções anexadas e a lista de funções. + `kms`: permite que as entidades principais listem aliases. + `logs`: permite que os as entidades principais descrevam fluxos de log, obtenham eventos de log, filtrem eventos de log e iniciem e interrompam sessões do Live Tail. + `states`: permite que as entidades principais descrevam e listem máquinas de estado do AWS Step Functions. + `tag`: permite que as entidades principais obtenham recursos com base em suas tags. + `xray`: permite que as entidades principais obtenham resumos de rastreamento de AWS X-Ray e recuperem uma lista de rastreamentos especificados por ID. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaBasicExecutionRole Esta política concede permissões para fazer o upload de logs para o CloudWatch Logs. É possível associar a política `AWSLambdaBasicExecutionRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaBasicDurableExecutionRolePolicy Essa política fornece permissões de gravação para o CloudWatch Logs e permissões de leitura/gravação para APIs de execução durável usadas pelas funções duráveis do Lambda. Essa política fornece as permissões essenciais necessárias para as funções duráveis do Lambda, que usam APIs de execução duráveis para persistir o progresso e manter o estado em todas as invocações de funções. É possível associar a política `AWSLambdaBasicDurableExecutionRolePolicy` aos seus usuários, grupos e perfis. **Detalhes de permissões** Esta política inclui as seguintes permissões: + `logs`: permite que as entidades principais criem grupos de logs e fluxos de logs e gravem eventos de log no CloudWatch Logs. + `lambda`: permite que as entidades principais verifiquem o estado de execução durável e recuperem o estado de execução durável das funções duráveis do Lambda. Para visualizar mais detalhes sobre a política, incluindo a versão mais recente do documento de política JSON, consulte [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) no *Guia de referência de políticas gerenciadas da AWS*. ## Política gerenciada pela AWS: AWSLambdaDynamoDBExecutionRole Esta política concede permissões para ler registros de um fluxo do Amazon DynamoDB e gravar no CloudWatch Logs. É possível associar a política `AWSLambdaDynamoDBExecutionRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaENIManagementAccess Essa política concede permissões para criar, descrever e excluir interfaces de rede elásticas usadas por uma função do Lambda habilitada para VPC. É possível associar a política `AWSLambdaENIManagementAccess` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaInvocation-DynamoDB Essa política concede acesso de leitura ao Amazon DynamoDB Streams. É possível associar a política `AWSLambdaInvocation-DynamoDB` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html) no *AWS Managed Policy Reference Guide*. ## Política gerenciada pela AWS: AWSLambdaKinesisExecutionRole Esta política concede permissões para ler eventos de um fluxo de dados do Amazon Kinesis e gravar no CloudWatch Logs. É possível associar a política `AWSLambdaKinesisExecutionRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaMSKExecutionRole Esta política concede permissões para ler e acessar registros de um cluster do Amazon Managed Streaming for Apache Kafka, para gerenciar interfaces de rede elástica e para gravar no CloudWatch Logs. É possível associar a política `AWSLambdaMSKExecutionRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaRole Esta política concede permissões para invocar as funções do Lambda. É possível associar a política `AWSLambdaRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaSQSQueueExecutionRole Essa política concede permissões para ler e excluir mensagens de uma fila do Amazon Simple Queue Service e para gravar no CloudWatch Logs. É possível associar a política `AWSLambdaSQSQueueExecutionRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo  o documento e as versões da política JSON, consulte [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaVPCAccessExecutionRole Essa política concede permissões para gerenciar interfaces de rede elástica em uma Amazon Virtual Private Cloud e gravar no CloudWatch Logs. É possível associar a política `AWSLambdaVPCAccessExecutionRole` aos seus usuários, grupos e perfis. Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) no *Guia de referência de políticas gerenciadas pela AWS*. ## Política gerenciada pela AWS: AWSLambdaManagedEC2ResourceOperator Essa política permite o gerenciamento automatizado de instâncias do Amazon Elastic Compute Cloud para provedores de capacidade do Lambda. Ele concede permissões ao serviço de escalonamento do Lambda para realizar operações de ciclo de vida da instância em seu nome. É possível associar a política `AWSLambdaManagedEC2ResourceOperator` aos seus usuários, grupos e perfis. **Detalhes de permissões** Esta política inclui as seguintes permissões: + `ec2:RunInstances`: permite que o Lambda execute novas instâncias do Amazon EC2 com a condição de que ec2:ManagedResourceOperator seja igual a scaler.lambda.amazonaws.com e restrinja o uso da AMI somente às imagens de propriedade da Amazon. + `ec2:DescribeInstances` e `ec2:DescribeInstanceStatus`: permite que o Lambda monitore o status da instância e recupere as informações da instância. + `ec2:CreateTags`: permite que o Lambda aplique tags em recursos do Amazon EC2 para fins de gerenciamento e identificação. + `ec2:DescribeAvailabilityZones`: permite que o Lambda visualize as zonas disponíveis, por exemplo, decisões de posicionamento. + `ec2:DescribeCapacityReservations`: permite que o Lambda verifique as reservas de capacidade para o posicionamento ideal da instância. + `ec2:DescribeInstanceTypes` e `ec2:DescribeInstanceTypeOfferings`: permite que o Lambda revise os tipos de instância disponíveis e suas ofertas. + `ec2:DescribeSubnets`: permite que o Lambda examine as configurações de sub-rede para planejamento de rede. + `ec2:DescribeSecurityGroups`: permite que o Lambda recupere informações do grupo de segurança para configuração da interface de rede. + `ec2:CreateNetworkInterface`: permite que o Lambda crie interfaces de rede e gerencie associações de sub-redes e grupos de segurança. + `ec2:AttachNetworkInterface`: permite que o Lambda conecte interfaces de rede às instâncias do Amazon EC2 com a condição que `ec2:ManagedResourceOperator` seja igual a [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/). Para obter mais informações sobre essa política, incluindo o documento e as versões da política JSON, consulte [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) no *Guia de referência de políticas gerenciadas da AWS*. ## Política gerenciada pela AWS: AWSLambdaServiceRolePolicy Esta política é anexada ao perfil vinculado ao serviço chamado AWSServiceRoleForLambda para permitir que o Lambda encerre instâncias gerenciadas como parte dos provedores de capacidade do Lambda. **Detalhes de permissões** Esta política inclui as seguintes permissões: + `ec2:TerminateInstances`: permite que o Lambda encerre instâncias do EC2 com a condição de que ec2:ManagedResourceOperator seja igual a scaler.lambda.amazonaws.com. + `ec2:DescribeInstanceStatus` e `ec2:DescribeInstances`: permite que o Lambda descreva instâncias do EC2. Para obter mais informações sobre essa política, consulte [Uso de perfis vinculados ao serviço para o Lambda](using-service-linked-roles.md). ## Atualizações do Lambda para políticas gerenciadas pela AWS | Alteração | Descrição | Data | | --- | --- | --- | | [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html): nova política | O Lambda adicionou uma nova política gerenciada para permitir o gerenciamento automatizado de instâncias do Amazon EC2 para provedores de capacidade do Lambda, permitindo que o serviço escalador realize operações de ciclo de vida da instância. | 30 de novembro de 2025 | | [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html): nova política | O Lambda adicionou uma nova política gerenciada para o perfil vinculado ao serviço para permitir que o Lambda encerre instâncias gerenciadas como parte dos provedores de capacidade do Lambda. | 30 de novembro de 2025 | | [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html): alterar | O Lambda atualizou a política `AWSLambda_FullAccess` para permitir as ações `kms:DescribeKey` e `iam:CreateServiceLinkedRole`. | 30 de novembro de 2025 | | [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html): nova política gerenciada | O Lambda lançou uma nova política gerenciada `AWSLambdaBasicDurableExecutionRolePolicy` que fornece permissões de gravação no CloudWatch Logs e permissões de leitura/gravação para APIs de execução durável usadas pelas funções duráveis do Lambda. | 1 de dezembro de 2025 | | [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) e [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – Alteração | O Lambda atualizou as políticas `AWSLambda_ReadOnlyAccess` e `AWSLambda_FullAccess` para permitir as ações `logs:StartLiveTail` e `logs:StopLiveTail`. | 17 de março de 2025 | | [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html): alteração | O Lambda atualizou a política `AWSLambdaVPCAccessExecutionRole` para permitir a ação `ec2:DescribeSubnets`. | 5 de janeiro de 2024 | | [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html): mudança | O Lambda atualizou a política `AWSLambda_ReadOnlyAccess` para permitir que as entidades principais listem as pilhas do CloudFormation. | 27 de julho de 2023 | | AWS LambdaO iniciou o rastreamento das alterações | O AWS Lambda começou a monitorar as alterações para as políticas gerenciadas pela AWS. | 27 de julho de 2023 | # Solução de problemas de identidade e acesso do AWS Lambda Use as informações a seguir para ajudar a diagnosticar e corrigir problemas comuns que você possa encontrar ao trabalhar com o Lambda e o IAM. **Topics** + [ ## Não tenho autorização para executar uma ação no Lambda ](#security_iam_troubleshoot-no-permissions) + [ ## Não estou autorizado a executar iam:PassRole ](#security_iam_troubleshoot-passrole) + [ ## Quero permitir que pessoas fora da minha Conta da AWS acessem meus recursos do Lambda ](#security_iam_troubleshoot-cross-account-access) ## Não tenho autorização para executar uma ação no Lambda Se você receber uma mensagem de erro informando que não tem autorização para executar uma ação, suas políticas deverão ser atualizadas para permitir que você realize a ação. O erro do exemplo a seguir ocorre quando o usuário do IAM `mateojackson` tenta usar o console para visualizar detalhes sobre um atributo `my-example-widget` fictício, mas não tem as permissões `lambda:GetWidget` fictícias. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget ``` Nesse caso, a política do usuário `mateojackson` deve ser atualizada para permitir o acesso ao recurso `my-example-widget` usando a ação `lambda:GetWidget`. Se você precisar de ajuda, entre em contato com seu administrador AWS. Seu administrador é a pessoa que forneceu suas credenciais de login. ## Não estou autorizado a executar iam:PassRole Se você receber uma mensagem de erro informando que não tem autorização para executar a ação `iam:PassRole`, as políticas deverão ser atualizadas para permitir que você passe uma função para o Lambda. Alguns Serviços da AWS permitem que você passe um perfil existente para o serviço, em vez de criar um perfil de serviço ou perfil vinculado ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço. O erro de exemplo a seguir ocorre quando uma usuária do IAM chamada `marymajor` tenta usar o console para executar uma ação no Lambda. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`. Se você precisar de ajuda, entre em contato com seu administrador AWS. Seu administrador é a pessoa que forneceu suas credenciais de login. ## Quero permitir que pessoas fora da minha Conta da AWS acessem meus recursos do Lambda É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem compatibilidade com políticas baseadas em recursos ou listas de controle de acesso (ACLs), é possível usar essas políticas para conceder às pessoas acesso aos seus recursos. Para saber mais, consulte: + Para saber se o Lambda oferece suporte a esses recursos, consulte [Como o AWS Lambda funciona com o IAM](security_iam_service-with-iam.md). + Para saber como conceder acesso a seus recursos em todas as Contas da AWS pertencentes a você, consulte [Fornecimento de acesso a um usuário do IAM em outra Conta da AWS pertencente a você](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia de usuário do IAM*. + Para saber como conceder acesso a seus recursos para Contas da AWS de terceiros, consulte [Fornecimento de acesso a Contas da AWS pertencentes a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*. + Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*. + Para conhecer a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*. # 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. # Validação de conformidade do AWS Lambda Auditores de terceiros avaliam a segurança e a conformidade do AWS Lambda como parte de vários programas de conformidade da AWS. Isso inclui SOC, PCI, FedRAMP, HIPAA e outros. Para obter uma lista dos serviços da AWS no escopo de programas de conformidade específicos, consulte [Serviços da AWS no escopo por programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/). Para obter informações gerais, consulte [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). É possível baixar relatórios de auditoria de terceiros usando o AWS Artifact. Para obter mais informações, consulte [Downloading reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Sua responsabilidade de conformidade ao usar o Lambda é determinada pela confidencialidade dos seus dados, pelos objetivos de conformidade da sua empresa e pelas leis e regulamentos aplicáveis. Você pode implementar controles de governança para garantir que as funções do Lambda da sua empresa atendam aos seus requisitos de conformidade. Para ter mais informações, consulte [Criar uma estratégia de governança para funções e camadas do Lambda](governance-concepts.md). # Resiliência no AWS Lambda A infraestrutura global da AWS é criada com base em AWS Regiões e Zonas de Disponibilidade. AWS As regiões fornecem várias zonas de disponibilidade separadas e isoladas fisicamente, as quais são conectadas com baixa latência, alto throughput e redes altamente redundantes. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que executam o failover automaticamente entre as zonas de disponibilidade sem interrupção. As zonas de disponibilidade são mais altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais. Para obter mais informações sobre AWS Regiões e Zonas de Disponibilidade, consulte [AWS global infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). Além da infraestrutura global da AWS, o Lambda oferece vários recursos para ajudar a oferecer suporte às suas necessidades de resiliência de dados e backup. + **Versionamento**: você pode usar o versionamento no Lambda para salvar a configuração e o código da sua função à medida que os desenvolve. Junto com aliases, você pode usar o versionamento para executar implantações azul/verde e contínuas. Para obter detalhes, consulte [Gerenciar versões da função do Lambda](configuration-versions.md). + **Escalabilidade**— quando a função recebe uma solicitação enquanto está processando uma solicitação anterior, o Lambda executa outra instância da função para lidar com o aumento de carga. O Lambda é dimensionado automaticamente para lidar com 1.000 execuções simultâneas por região, um[quota](gettingstarted-limits.md)que pode ser aumentada, se necessário. Para obter detalhes, consulte [Como entender a escalabilidade da função do Lambda](lambda-concurrency.md). + **Alta disponibilidade**: o Lambda executa sua função em várias zonas de disponibilidade para garantir que ela esteja disponível para processar eventos no caso de uma interrupção do serviço em uma única zona. Se você configurar a função para se conectar a uma nuvem privada virtual (VPC) na sua conta, especifique sub-redes em várias zonas de disponibilidade para garantir uma alta disponibilidade. Para obter detalhes, consulte [Conceder acesso a funções do Lambda para recursos em uma Amazon VPC](configuration-vpc.md). + **Simultaneidade reservada**: para garantir que sua função sempre pode se dimensionar para manipular solicitações adicionais, você pode reservar simultaneidade para ela. Configurar a simultaneidade reservada para uma função garante que ela pode se dimensionar, mas não exceder, um número especificado de invocações simultâneas. Isso garante que você não perderá solicitações por causa de outras funções que estejam consumindo toda a simultaneidade disponível. Para obter detalhes, consulte [Configurar a simultaneidade reservada para uma função](configuration-concurrency.md). + **Tentativas**: para invocações assíncronas e um subconjunto de invocações acionadas por outros serviços, o Lambda faz novas tentativas automaticamente sobre um erro com um atraso entre as tentativas. Outros clientes e Serviços da AWS que invocam funções de forma síncrona são responsáveis por realizar novas tentativas. Para obter detalhes, consulte [Compreender o comportamento de novas tentativas no Lambda](invocation-retries.md). + **Fila de mensagens mortas**: para invocações assíncronas, você pode configurar o Lambda para enviar solicitações para uma fila de mensagens mortas caso todas as tentativas falhem. Uma fila de mensagens mortas é um tópico do Amazon SNS ou uma fila do Amazon SQS que recebe eventos para solução de problemas ou reprocessamento. Para obter mais detalhes, consulte [Adicionar uma fila de mensagens não entregues](invocation-async-retain-records.md#invocation-dlq). # Segurança da infraestrutura no AWS Lambda Por ser um serviço gerenciado, o AWS Lambda é protegido pela segurança da rede global da AWS. Para obter informações sobre serviços de segurança da AWS e como a AWS protege a infraestrutura, consulte [Segurança na Nuvem AWS](https://aws.amazon.com/security/). Para projetar seu ambiente da AWS usando as práticas recomendadas de segurança de infraestrutura, consulte [Proteção de infraestrutura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) em *Pilar segurança: AWS Well‐Architected Framework*. Você usa chamadas de API publicadas pela AWS para acessar o Lambda por meio da rede. Os clientes devem oferecer compatibilidade com: + Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3. + Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos. # Proteção de workloads com endpoints públicos Para workloads acessíveis publicamente, a AWS fornece vários recursos e serviços que podem ajudar a mitigar certos riscos. Esta seção aborda a autenticação e a autorização de usuários de aplicações e a proteção de endpoints da API. ## Autenticação e autorização A autenticação está relacionada à identidade, e a autorização se refere às ações. Use a autenticação para controlar quem pode invocar uma função do Lambda e, em seguida, use a autorização para controlar o que elas podem fazer. Para muitas aplicações, o IAM é suficiente para gerenciar os dois mecanismos de controle. Para aplicações com usuários externos, como aplicações Web ou móveis, é comum usar [JSON Web Tokens](https://jwt.io/introduction/) (JWTs) para gerenciar a autenticação e a autorização. Diferentemente do gerenciamento tradicional de senhas baseado em servidor, os JWTs são transmitidos pelo cliente em cada solicitação. Eles são uma forma criptograficamente segura de verificar a identidade e as declarações usando dados transmitidos pelo cliente. Para aplicações baseadas no Lambda, isso permite proteger todas as chamadas para cada endpoint de API sem depender de um servidor central para autenticação. Você pode [implementar JWTs com o Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), um serviço de diretório de usuários que lida com registro, autenticação, recuperação de contas e outras operações comuns do gerenciamento de contas. O [Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) fornece bibliotecas para simplificar a integração desse serviço em sua aplicação de frontend. Você também pode considerar serviços de parceiros terceiros, como o [Auth0](https://auth0.com/). Devido ao papel essencial em termos de segurança de um serviço de provedor de identidade, é importante usar ferramentas profissionais para proteger sua aplicação. Não é recomendável que você escreva seus próprios serviços para lidar com a autenticação ou a autorização. Qualquer vulnerabilidade em bibliotecas personalizadas pode ter implicações significativas na segurança da sua workload e dos seus dados. ## Proteção de endpoints de API Para aplicações com tecnologia sem servidor, a forma preferida para servir publicamente uma aplicação de backend é usar o Amazon API Gateway. Isso pode ajudar você a proteger uma API contra usuários mal-intencionados ou picos de tráfego. O API Gateway oferece dois tipos de endpoints para desenvolvedores que usam tecnologia sem servidor: [APIs REST](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) e [APIs HTTP](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). Ambas oferecem suporte à [autorização usando o AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), o IAM ou o Amazon Cognito. Ao usar o IAM ou o Amazon Cognito, as solicitações recebidas são avaliadas e, se faltar um token necessário ou se elas contiverem autenticação inválida, a solicitação será rejeitada. Você não receberá uma cobrança por essas solicitações e elas não contam para nenhuma cota de controle de utilização. As rotas de API não autenticadas podem ser acessadas por qualquer pessoa na Internet pública; portanto, é recomendável limitar o uso de APIs não autenticadas. Se você precisar usar APIs não autenticadas, é importante protegê-las contra riscos comuns, como ataques de [negação de serviço](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS).[ Aplicar o AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) a essas APIs pode ajudar a proteger sua aplicação contra a injeção de SQL e ataques de cross-site scripting (XSS). O API Gateway também implementa o [controle de utilização](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) no nível da conta da AWS e por cliente quando as chaves de API são usadas. Em muitos casos, a funcionalidade fornecida pela API não autenticada pode ser alcançada com uma abordagem alternativa. Por exemplo, uma aplicação Web pode fornecer uma lista de lojas de varejo de clientes com base em uma tabela do DynamoDB para usuários que não estão conectados. Essa solicitação pode se originar de uma aplicação Web de frontend ou de qualquer outra origem que chame o endpoint do URL. Este diagrama compara três soluções: ![\[operações de segurança figura 5\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/security-ops-figure-5.png) 1. Essa API não autenticada pode ser chamada por qualquer pessoa na Internet. Em um ataque de negação de serviço, é possível esgotar os limites do controle de utilização da API, a simultaneidade do Lambda ou a capacidade de leitura provisionada do DynamoDB em uma tabela subjacente. 1. Uma distribuição do CloudFront na frente do endpoint da API com uma configuração apropriada de [tempo de vida](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) absorveria a maior parte do tráfego em um ataque de DoS, sem alterar a solução subjacente para buscar os dados. 1. Como alternativa, para dados estáticos que raramente mudam, a distribuição do CloudFront poderia servir os dados de um bucket do Amazon S3. # Usar a assinatura de código para verificar integridade de código com o Lambda A assinatura de código ajuda a garantir que apenas código confiável seja implantado nas funções do Lambda. Usando AWS Signer, você pode criar pacotes de código assinados digitalmente para as funções. Quando você [adiciona uma configuração de assinatura de código a uma função](configuration-codesigning-create.md), o Lambda verifica se todas as novas implantações de código estão assinadas por uma fonte confiável. Como as verificações de validação de assinatura de código são executadas na implantação, elas não afetam a performance da execução da função. **Importante** As configurações de assinatura de código evitam apenas novas implantações de código não assinado. Se você adicionar uma configuração de assinatura de código a uma função existente que tenha código não assinado, esse código continuará em execução até que um novo pacote de código seja implantado. Quando você habilita a assinatura de código para uma função, todas as [camadas](chapter-layers.md) adicionadas à função também devem ser assinadas por um perfil de assinatura permitido. Não há custo adicional pelo uso de AWS Signer ou assinatura de código no AWS Lambda. ## Validação de assinatura O Lambda executa as seguintes verificações de validação ao implantar um pacote de código assinado na sua função: 1. **Integridade**: valida que o pacote de código não foi modificado depois de assinado. O Lambda compara o hash do pacote com o hash da assinatura. 1. **Expiração**: valida que a assinatura do pacote de código não expirou. 1. **Incompatibilidade**: valida que o pacote de código está assinado com um dos perfis de assinatura permitidos 1. **Revogação**: valida que a assinatura do pacote de código não foi revogada. Ao criar uma configuração de assinatura de código, você pode usar o parâmetro [UntrustedArtifactonDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) para especificar como o Lambda deve responder se as verificações de expiração, incompatibilidade ou revogação falharem. Você pode escolher uma destas ações: + `Warn`: essa é a configuração padrão. O Lambda permite a implantação do pacote de código, mas emite um aviso. O Lambda emite uma nova métrica do Amazon CloudWatch (`SignatureValidationErrors`) e também armazena o aviso no log do CloudTrail. + `Enforce`: o Lambda emite um aviso (o mesmo que para a ação `Warn`) e bloqueia a implantação do pacote de código. **Topics** + [ ## Validação de assinatura ](#config-codesigning-valid) + [ # Criar configurações de assinatura de código para o Lambda ](configuration-codesigning-create.md) + [ # Configurar políticas do IAM para configurações de assinatura de código do Lambda ](config-codesigning-policies.md) + [ # Uso de tags nas configurações de assinatura de código ](tags-csc.md) # Criar configurações de assinatura de código para o Lambda Para ativar a assinatura de código para uma função, crie uma *configuração de assinatura de código* e associe-a à função. Uma configuração de assinatura de código define uma lista de perfis de assinatura permitidos e a ação de política a ser executada se alguma das verificações de validação falhar. **nota** Funções definidas como imagens de contêiner não são compatíveis com assinatura de código. **Topics** + [ ## Pré-requisitos de configuração ](#config-codesigning-prereqs) + [ ## Criar configurações de assinatura de código ](#config-codesigning-config-console) + [ ## Habilitar a assinatura de código para uma função ](#config-codesigning-function-console) ## Pré-requisitos de configuração Antes de configurar a assinatura de código para uma função do Lambda, use o AWS Signer para fazer o seguinte: + Crie um ou mais [perfis de assinatura](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html). + Use um perfil de assinatura para [criar um pacote de código assinado para a função](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html). ## Criar configurações de assinatura de código Uma configuração de assinatura de código define uma lista dos perfis de assinatura permitidos e a política de validação de assinatura. **Para criar uma configuração de assinatura de código (console)** 1. Abra a página [Code signing configurations](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) (Configurações de assinatura de código) do console do Lambda. 1. Escolha **Criar configuração**. 1. Em **Description (Descrição)**, insira um nome descritivo para a configuração. 1. Em **Signing profiles (Perfis de assinatura)**, adicione até 20 perfis de assinatura à configuração. 1. Para **Signing profile version ARN (ARN da versão do perfil de assinatura)**, escolha o nome de recurso da Amazon (ARN) de uma versão de perfil ou insira o ARN. 1. Para adicionar um perfil de assinatura adicional, escolha **Add signing profiles (Adicionar perfis de assinatura)**. 1. Em **Signature validation policy (Política de validação de assinatura)**, escolha **Warn (Avisar)** ou **Enforce (Impor)**. 1. Escolha **Criar configuração**. ## Habilitar a assinatura de código para uma função Para habilitar assinatura de código para uma função, adicione a ela uma configuração de assinatura de código. **Importante** As configurações de assinatura de código evitam apenas novas implantações de código não assinado. Se você adicionar uma configuração de assinatura de código a uma função existente que tenha código não assinado, esse código continuará em execução até que um novo pacote de código seja implantado. **Para associar uma configuração de assinatura de código a uma função (console)** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha a função para a qual deseja ativar a assinatura de código. 1. Abra a guia **Configuration** (Configuração). 1. Role para baixo e escolha **Assinatura de código**. 1. Escolha **Editar**. 1. Em **Edit code signing (Editar assinatura de código)**, escolha uma configuração de assinatura de código para esta função. 1. Escolha **Salvar**. # Configurar políticas do IAM para configurações de assinatura de código do Lambda Para conceder a um usuário permissão para acessar as operações de API de assinatura de código do Lambda, anexe uma ou mais instruções de política à política do usuário. Para obter mais informações sobre políticas de usuário, consulte [Políticas do IAM baseadas em identidade para o Lambda](access-control-identity-based.md). A instrução da política de exemplo a seguir concede permissão para criar, atualizar e recuperar configurações de assinatura de código. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:CreateCodeSigningConfig", "lambda:UpdateCodeSigningConfig", "lambda:GetCodeSigningConfig" ], "Resource": "*" } ] } ``` ------ Os administradores podem usar a chave de condição `CodeSigningConfigArn` para especificar as configurações de assinatura de código que os desenvolvedores devem usar para criar ou atualizar suas funções. O exemplo de declaração de política a seguir concede permissão para criar uma função. A declaração de política inclui um`lambda:CodeSigningConfigArn`para especificar a configuração de assinatura de código permitida. O Lambda bloqueará as solicitações de API `CreateFunction` se o parâmetro [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) estiver faltando ou não corresponder ao valor da condição. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowReferencingCodeSigningConfig", "Effect": "Allow", "Action": [ "lambda:CreateFunction" ], "Resource": "*", "Condition": { "StringEquals": { "lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6" } } } ] } ``` ------ # Uso de tags nas configurações de assinatura de código Você pode marcar as configurações de assinatura de código para organizar e gerenciar os recursos. Tags são pares de chave-valor de formato livre associados aos recursos compatíveis com todos os Serviços da AWS. Para obter mais informações sobre casos de uso de tags, consulte [Common tagging strategies](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) no *Guia do editor de tags e recursos de marcação da AWS*. Você pode usar a API do AWS Lambda para visualizar e atualizar tags. Você também pode visualizar e atualizar tags enquanto gerencia uma configuração específica de assinatura de código no console do Lambda. **Topics** + [ ## Permissões necessárias para trabalhar com tags ](#csc-tags-required-permissions) + [ ## Uso de tags usando o console do Lambda ](#tags-csc-console) + [ ## Uso de tags com a AWS CLI ](#tags-csc-cli) ## Permissões necessárias para trabalhar com tags Para permitir que uma identidade do AWS Identity and Access Management (IAM) (usuário, grupo ou perfil) leia ou defina tags em um recurso, conceda a ela as permissões correspondentes: + **lambda:ListTags**: quando um recurso tiver tags, conceda essa permissão a qualquer usuário que precise chamar `ListTags` nele. Para funções marcadas, essa permissão também será necessária para `GetFunction`. + **lambda:TagResource**: conceda essa permissão a qualquer pessoa que precise chamar `TagResource` ou executar uma tag na criação. Opcionalmente, considere conceder também a permissão **lambda:UntagResource** para permitir chamadas `UntagResource` ao recurso. Para obter mais informações, consulte [Políticas do IAM baseadas em identidade para o Lambda](access-control-identity-based.md). ## Uso de tags usando o console do Lambda Você pode usar o console do Lambda para criar configurações de assinatura de código que tenham tags, adicionar tags a configurações de assinatura de código existentes e filtrar configurações de assinatura de código por tag. **Para adicionar uma tag ao criar uma configuração de assinatura de código** 1. Abra [Configurações de assinatura de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) no console do Lambda. 1. No cabeçalho do painel de conteúdo, escolha **Criar configuração**. 1. Na seção na parte superior do painel de conteúdo, defina a configuração de assinatura de código. Para obter mais informações sobre como definir as configurações de assinatura de código, consulte [Usar a assinatura de código para verificar integridade de código com o Lambda](configuration-codesigning.md). 1. Na seção **Tags**, escolha **Adicionar nova tag**. 1. No campo **Chave**, insira sua chave de tag. Para obter informações sobre restrições de marcação, consulte [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) no *Guia do editor de tags e recursos de marcação da AWS*. 1. Escolha **Criar configuração**. **Para adicionar uma tag a uma configuração de assinatura de código existente** 1. Abra [Configurações de assinatura de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) no console do Lambda. 1. Escolha o nome da configuração de assinatura de código. 1. Nas guias abaixo do painel **Detalhes**, escolha **Tags**. 1. Selecione **Gerenciar tags**. 1. Selecione **Adicionar nova tag**. 1. No campo **Chave**, insira sua chave de tag. Para obter informações sobre restrições de marcação, consulte [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) no *Guia do editor de tags e recursos de marcação da AWS*. 1. Escolha **Salvar**. **Para filtrar as configurações de assinatura de código por tag** 1. Abra [Configurações de assinatura de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) no console do Lambda. 1. Escolha a caixa Pesquisar. 1. Na lista suspensa, selecione sua tag abaixo do subtítulo **Tags**. 1. Selecione **Usar: “tag-name”** para ver todas as configurações de assinatura de código marcadas com essa chave, ou escolha um **operador** para filtrar ainda mais por valor. 1. Selecione o valor da tag para filtrar por uma combinação de chave e valor da tag. A barra de pesquisa também é compatível com a pesquisa de chaves de tag. Insira o nome de uma chave para encontrá-la na lista. ## Uso de tags com a AWS CLI Você pode adicionar e remover tags em recursos existentes do Lambda, incluindo configurações de assinatura de código, com a API do Lambda. Você também pode adicionar tags ao criar uma configuração de assinatura de código, o que permite manter um recurso marcado durante todo o ciclo de vida. ### Atualização de tags usando as APIs de tag do Lambda Você pode adicionar e remover tags dos recursos compatíveis do Lambda por meio das operações da API [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) e [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html). Você também pode chamar essas operações usando a AWS CLI. Para adicionar tags a um recurso existente, use o comando `tag-resource`. Este exemplo adiciona duas tags, uma com a chave *Department* e outra com a chave *CostCenter*. ``` aws lambda tag-resource \ --resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \ --tags Department=Marketing,CostCenter=1234ABCD ``` Para remover tags, use o comando `untag-resource`. Este exemplo remove a tag com a chave *Department*. ``` aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \ --tag-keys Department ``` ### Adição de tags ao criar uma configuração de assinatura de código Para criar uma nova configuração de assinatura de código do Lambda com tags, use a operação da API [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html). Especifique o parâmetro `Tags`. Você pode chamar essa operação com o comando `create-code-signing-config` da AWS CLI e a opção `--tags`. Para obter mais informações sobre o comando da CLI, consulte [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html) na *referência de comandos da AWS CLI*. Antes de usar o parâmetro `Tags` com `CreateCodeSigningConfig`, certifique-se de que seu perfil tenha permissão para marcar recursos junto com as permissões usuais necessárias para essa operação. Para obter mais informações sobre permissões para marcação, consulte [Permissões necessárias para trabalhar com tags](#csc-tags-required-permissions). ### Visualização de tags usando as APIs de tag do Lambda Para visualizar as tags que são aplicadas à um recurso específico do Lambda, use a operação da API `ListTags`. Para obter mais informações, consulte [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html). Você pode chamar essa operação com o comando `list-tags` da AWS CLI fornecendo um ARN (nome do recurso da Amazon). ``` aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier ``` ### Filtragem de recursos por tag Você pode usar a operação de API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) do AWS Resource Groups Tagging API para filtrar seus recursos por etiquetas. A operação `GetResources` aceita até 10 filtros, cada um contendo uma chave de etiquetas e até 10 valores de etiquetas. Você fornece a `GetResources` um `ResourceType` para filtrar por tipos de recursos específicos. Você pode chamar essa operação usando o comando `get-resources` da AWS CLI. Para ver exemplos de uso de `get-resources`, consulte [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) na *referência de comandos da AWS CLI*.