# Gerenciando permissões no AWS Lambda
É possível usar o AWS Identity and Access Management (IAM) para gerenciar permissões no AWS Lambda. Há duas categorias principais de permissões que você precisa considerar ao trabalhar com funções do Lambda:
+ Permissões que suas funções do Lambda precisam para executar ações da API e acessar outros recursos da AWS.
+ Permissões que outros usuários e entidades da AWS precisam para acessar suas funções do Lambda
As funções Lambda do geralmente precisam acessar outros recursos da AWS e realizar várias operações de API nesses recursos. Por exemplo, você pode ter uma função do Lambda que responda a um evento ao atualizar as entradas do banco de dados do Amazon DynamoDB. Nesse caso, sua função precisa de permissões para acessar o banco de dados, bem como permissões para colocar ou atualizar itens nesse banco de dados.
Você define as permissões que sua função do Lambda precisa em um perfil do IAM especial chamado [perfil de execução](lambda-intro-execution-role.md). Nesse perfil, é possível anexar uma política que define cada permissão que sua função precisa para acessar outros recursos da AWS e ler de origens de eventos. Cada função do Lambda deve ter um perfil de execução. No mínimo, sua função de execução deve ter acesso ao Amazon CloudWatch porque as funções do Lambda são registradas no CloudWatch Logs por padrão. É possível anexar a [política gerenciada pela `AWSLambdaBasicExecutionRole`](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html) ao seu perfil de execução para satisfazer esse requisito.
Para conceder a outras Contas da AWS, organizações e serviços permissões para acessar seus recursos do Lambda, você tem algumas opções:
+ É possível usar [políticas baseadas em identidade](access-control-identity-based.md) para conceder a outros usuários acesso aos seus recursos do Lambda. As políticas baseadas em identidade podem se aplicar diretamente aos usuários ou a funções e grupos associados a um usuário.
+ É possível usar [políticas baseadas em recursos](access-control-resource-based.md) para conceder a outras contas e a Serviços da AWS permissões para acessar seus recursos do Lambda. Quando um usuário tenta acessar um recurso do Lambda, o Lambda considera as políticas baseadas em identidade e a política baseada em recursos do usuário. Quando um serviço da AWS, como o Amazon Simple Storage Service (Amazon S3), chama sua função do Lambda, o Lambda considera apenas a política baseada em recursos.
+ É possível usar um modelo de [controle de acesso por atributo (ABAC)](attribute-based-access-control.md) para controlar o acesso às suas funções do Lambda. Com o ABAC, você pode anexar tags a uma função do Lambda, transmiti-las em determinadas solicitações de API ou anexá-las à entidade principal do IAM que está fazendo a solicitação. Especificar as mesmas tags no elemento de condição de uma política do IAM para controlar o acesso à função.
Na AWS, é prática recomendada conceder apenas as permissões necessárias para executar uma tarefa ([permissões de privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)). Para implementar isso no Lambda, recomendamos começar com uma [política gerenciada pela AWS](permissions-managed-policies.md). Use essas políticas gerenciadas no estado em que se encontram ou como um ponto de partida para escrever suas próprias políticas mais restritivas.
Para ajudar você a ajustar suas permissões para acesso com privilégios mínimos, o Lambda fornece algumas condições adicionais que você pode incluir em suas políticas. Para obter mais informações, consulte [Ajustar as seções de Recursos e Condições das políticas](lambda-api-permissions-ref.md).
Para obter mais informações sobre o IAM, consulte o *[Guia do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)*.
# Definir permissões de uma função do Lambda com um perfil de execução
O perfil de execução de uma função do Lambda é um perfil do AWS Identity and Access Management (IAM) que concede à função permissão para acessar recursos e Serviços da AWS. Por exemplo, é possível criar uma função de execução que tenha permissão para enviar logs ao Amazon CloudWatch e carregar os dados de rastreamento no AWS X-Ray. Esta página fornece informações sobre como criar, visualizar e gerenciar o perfil de execução de uma função do Lambda.
O Lambda assume automaticamente seu perfil de execução quando você invoca sua função. Evite chamar `sts:AssumeRole` manualmente para assumir o perfil de execução no código da sua função. Se o caso de uso exigir que o perfil assuma a si mesmo, será necessário incluir o perfil em si como uma entidade principal confiável na política de confiança do perfil. Para obter mais informações sobre como modificar uma política de confiança de perfil, consulte [ Modificar a política de confiança de uma função (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-managingrole_edit-trust-policy) no Guia do usuário do IAM.
Para que o Lambda assuma seu perfil de execução de forma adequada, a [política de confiança](#permissions-executionrole-api) do perfil deve especificar a entidade principal de serviço do Lambda (`lambda.amazonaws.com`) como um serviço confiável.
**Topics**
+ [Criar uma função de execução no console do IAM](#permissions-executionrole-console)
+ [Criar e gerenciar perfis com a AWS CLI](#permissions-executionrole-api)
+ [Conceda acesso de menor privilégio à sua função de execução do Lambda](#permissions-executionrole-least-privilege)
+ [Visualizar e atualizar permissões no perfil de execução](permissions-executionrole-update.md)
+ [Trabalhar com políticas gerenciadas pela AWS no perfil de execução](permissions-managed-policies.md)
+ [Usar o ARN da função de origem para controlar o comportamento de acesso da função](permissions-source-function-arn.md)
## Criar uma função de execução no console do IAM
Por padrão, o Lambda cria uma função de execução com permissões mínimas quando você [cria uma função no console do Lambda](getting-started.md#getting-started-create-function). Especificamente, esse perfil de execução inclui a [política gerenciada `AWSLambdaBasicExecutionRole`](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html), que concede à sua função permissões básicas para registrar eventos no Amazon CloudWatch Logs. Você pode selecionar **Criar perfil padrão** na seção **Permissões**.
É possível escolher um perfil existente selecionando **Usar outro perfil** na seção **Permissões**. Se a sua função do Lambda precisar de permissões adicionais para realizar tarefas como atualizar entradas em um banco de dados Amazon DynamoDB em resposta a eventos, você pode criar um perfil de execução personalizado com as permissões necessárias. Para isso, selecione **Usar outro perfil** na seção **Permissões**, o que abrirá uma janela lateral onde você poderá personalizar suas permissões.
**Para configurar um perfil de execução a partir do Console**
1. Insira um **nome de perfil** na seção Detalhes do perfil.
1. Na seção **Política**, selecione **Usar política existente**.
1. Selecione as políticas gerenciadas pela AWS que deseja anexar ao seu perfil. Por exemplo, se sua função precisar acessar o DynamoDB, selecione a política gerenciada **AWSLambdaDynamoDBExecutionRole**.
1. Selecione **Criar perfil**.
Como alternativa, ao [criar uma função no console do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function), você poderá anexar qualquer perfil de execução criado anteriormente à função. Se você quiser anexar um novo perfil de execução a uma função existente, siga as etapas em [Atualizar o perfil de execução de uma função](permissions-executionrole-update.md).
## Criar e gerenciar perfis com a AWS CLI
Para criar uma função de execução com a AWS Command Line Interface (AWS CLI), use o comando **create-role**. Ao usar esse comando, é possível especificar a política de confiança em linha. A política de confiança de um perfil concede a permissão de entidades principais especificadas para assumir o perfil. No exemplo a seguir, você concede à entidade principal do serviço Lambda permissão para assumir seu perfil. Os requisitos para escapar de aspas na string JSON podem variar dependendo do shell.
```
aws iam create-role \
--role-name lambda-ex \
--assume-role-policy-document '{"Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
```
Também é possível definir a política de confiança para a função usando um arquivo JSON separado. No exemplo a seguir, `trust-policy.json` é um arquivo no diretório atual.
**Example trust-policy.json**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
```
aws iam create-role \
--role-name lambda-ex \
--assume-role-policy-document file://trust-policy.json
```
Para adicionar permissões à função, use o comando **attach-policy-to-role**. Os comandos a seguir adicionam a política gerenciada `AWSLambdaBasicExecutionRole` ao perfil de execução `lambda-ex`.
```
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Depois de criar o perfil de execução, anexe-o à sua função. Ao [criar uma função no console do Lambda](getting-started.md#getting-started-create-function), você poderá anexar qualquer perfil de execução criado anteriormente à função. Se você quiser anexar um novo perfil de execução a uma função existente, siga as etapas em [Atualizar o perfil de execução de uma função](permissions-executionrole-update.md#update-execution-role).
## Conceda acesso de menor privilégio à sua função de execução do Lambda
Quando você cria um perfil do IAM pela primeira vez para sua função do Lambda durante a fase de desenvolvimento, às vezes você pode conceder permissões além do que é necessário. Antes de publicar sua função no ambiente de produção, como prática recomendada, ajuste a política para incluir somente as permissões necessárias. Para obter mais informações, consulte [Aplicar permissões de privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege), no *Guia do usuário do IAM*.
Use o IAM Access Analyzer para ajudar a identificar as permissões necessárias para a política de função de execução do IAM. O IAM Access Analyzer revisa seus logs do AWS CloudTrail para o intervalo de datas especificado e gera um modelo de política com apenas as permissões que a função utilizou durante esse período. Você pode usar o modelo para criar uma política gerenciada com permissões refinadas e anexá-la à função do IAM. Dessa forma, você concede apenas as permissões necessárias à interação com os recursos da AWS, de acordo com a especificidade do caso de uso.
Para obter mais informações, consulte [Generate policies based on access activity](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html) (Gerar políticas com base na atividade de acesso), no *Guia do usuário do IAM*.
# Visualizar e atualizar permissões no perfil de execução
Este tópico aborda como você pode visualizar e atualizar o [perfil de execução](lambda-intro-execution-role.md) da sua função.
**Topics**
+ [Visualizar o perfil de execução de uma função](#view-execution-role)
+ [Atualizar o perfil de execução de uma função](#update-execution-role)
## Visualizar o perfil de execução de uma função
Para visualizar o perfil de execução de uma função, use o console do Lambda.
**Para visualizar o perfil de execução de 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 o nome de uma função.
1. Escolha **Configuration** (Configuração) e depois **Permissions** (Permissões).
1. Em **Perfil de execução**, é possível ver o perfil que está sendo usado atualmente como perfil de execução da função. Por conveniência, você pode visualizar todos os recursos e ações que a função pode acessar na seção **Resumo do recurso**. Você também pode escolher um serviço na lista suspensa para ver as permissões relacionadas a ele.
## Atualizar o perfil de execução de uma função
Adicione ou remova permissões da função de execução de uma função a qualquer momento ou configure a função para usar uma diferente. Se sua função precisar acessar outros serviços ou recursos, você deverá adicionar as permissões necessárias ao perfil de execução.
Ao adicionar permissões à sua função, faça também uma atualização simples em seu código ou configuração. Isso força as instâncias em execução da função, com credenciais desatualizadas, a serem encerradas e substituídas.
Para atualizar o perfil de execução de uma função, use o console do Lambda.
**Para atualizar o perfil de execução de 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 o nome de uma função.
1. Escolha **Configuration** (Configuração) e depois **Permissions** (Permissões).
1. Em **Perfil de execução**, escolha **Editar**.
1. Se você quiser atualizar sua função para usar um perfil diferente como perfil de execução, escolha o novo perfil no menu suspenso em **Perfil existente**.
**nota**
Se desejar atualizar as permissões em um perfil de execução existente, você só poderá fazer isso no console do AWS Identity and Access Management (IAM).
Se você quiser criar um novo perfil para usar como perfil de execução, escolha **Criar um novo perfil baseado em modelos de políticas da AWS** em **Perfil de execução**. Em seguida, insira um nome para seu novo perfil em **Nome do perfil** e especifique as políticas que você deseja anexar ao novo perfil em **Modelos de política**.
1. Escolha **Salvar**.
# Trabalhar com políticas gerenciadas pela AWS no perfil de execução
As seguintes políticas gerenciadas da AWS oferecem permissões obrigatórias para o uso dos recursos do Lambda:
| Alteração | Descrição | Data |
| --- | --- | --- |
| **[ AWSLambdaMSKExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)**: o Lambda adicionou a permissão [kafka:DescribeClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#v2-clusters-clusterarnget) a esta política. | `AWSLambdaMSKExecutionRole` concede permissões para ler e acessar registros de um cluster do Amazon Managed Streaming for Apache Kafka (Amazon MSK), gerenciar interfaces de rede elástica (ENIs) e gravar no CloudWatch Logs. | 17 de junho de 2022 |
| **[AWSLambdaBasicExecutionRole:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSLambdaBasicExecutionRole` concede permissões para carregar registros para o CloudWatch | 14 de fevereiro de 2022 |
| **[AWSLambdaDynamoDBExecutionRole:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSLambdaDynamoDBExecutionRole` concede permissões para ler registros de um fluxo do Amazon DynamoDB Streams e gravar no CloudWatch Logs. | 14 de fevereiro de 2022 |
| **[AWSLambdaKinesisExecutionRole:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSLambdaKinesisExecutionRole` concede permissões para ler eventos de um fluxo de dados do Amazon Kinesis e gravar no CloudWatch Logs. | 14 de fevereiro de 2022 |
| **[AWSLambdaMSKExecutionRole:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSLambdaMSKExecutionRole` concede permissões para ler e acessar registros de um cluster do Amazon Managed Streaming for Apache Kafka (Amazon MSK), gerenciar interfaces de rede elástica (ENIs) e gravar no CloudWatch Logs. | 14 de fevereiro de 2022 |
| **[AWSLambdaSQSQueueExecutionRole:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSLambdaSQSQueueExecutionRole` concede permissões para ler uma mensagem de uma fila do Amazon Simple Queue Service (Amazon SQS) e gravar no CloudWatch Logs. | 14 de fevereiro de 2022 |
| **[AWSLambdaVPCAccessExecutionRole:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSLambdaVPCAccessExecutionRole` concede permissões para gerenciar ENIs em uma Amazon VPC e gravar no CloudWatch Logs. | 14 de fevereiro de 2022 |
| **[AWSXRayDaemonWriteAccess:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)** o Lambda começou a monitorar mudanças feitas a essa política. | `AWSXRayDaemonWriteAccess` concede permissões para carregar dados de rastreamento no X-Ray. | 14 de fevereiro de 2022 |
| **[CloudWatchLambdaInsightsExecutionRolePolicy:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy)** o Lambda começou a monitorar mudanças feitas a essa política. | `CloudWatchLambdaInsightsExecutionRolePolicy` concede permissão para gravar métricas de runtime no CloudWatch Lambda Insights. | 14 de fevereiro de 2022 |
| **[AmazonS3ObjectLambdaExecutionRolePolicy:](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonS3ObjectLambdaExecutionRolePolicy)** o Lambda começou a monitorar mudanças feitas a essa política. | `AmazonS3ObjectLambdaExecutionRolePolicy` concede permissões para interagir com o Lamda de objetos do Amazon Simple Storage Service (Amazon S3) e gravar no CloudWatch Logs. | 14 de fevereiro de 2022 |
Para alguns atributos, o console do Lambda tenta adicionar permissões ausentes à sua função de execução em uma política gerenciada pelo cliente. Essas políticas podem tornar-se numerosas. Para evitar a criação de políticas adicionais, acrescente as políticas gerenciadas da AWS relevantes à função de execução antes de habilitar os atributos.
Quando você usa um [mapeamento de fontes de eventos](invocation-eventsourcemapping.md) para invocar a função, o Lambda usa a função de execução a fim de ler dados de eventos. Por exemplo, um mapeamento da origem do evento para o Kinesis lê eventos de um fluxo de dados e os envia para a sua função em lotes.
Quando um serviço assume uma função em sua conta, você pode incluir as chaves de contexto de condição global `aws:SourceAccount` e `aws:SourceArn` em sua política de confiança de função para limitar o acesso à função apenas a solicitações geradas pelos recursos esperados. Para obter mais informações, consulte [Prevenção de confused deputy entre serviços para o AWS Security Token Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention).
Além das políticas gerenciadas da AWS, o console do Lambda fornece modelos para criar uma política personalizada com as permissões para casos de uso adicionais. Ao criar uma função no console do Lambda, opte por criar uma nova função de execução com permissões de um ou mais modelos. Esses modelos também são aplicados automaticamente quando você cria uma função a partir de um esquema, ou quando configura opções que exijam acesso a outros serviços. Os modelos de exemplo estão disponíveis no [repositório do GitHub](https://github.com/awsdocs/aws-lambda-developer-guide/tree/master/iam-policies) deste guia.
# Usar o ARN da função de origem para controlar o comportamento de acesso da função
É comum que o seu código de função do Lambda faça solicitações de API para outros Serviços da AWS. Para fazer essas solicitações, o Lambda gera um conjunto efêmero de credenciais, assumindo a função de execução da sua função. Essas credenciais estão disponíveis como variáveis de ambiente durante a invocação da sua função. Ao trabalhar com SDKs da AWS, não é necessário fornecer credenciais para o SDK diretamente no código. Por padrão, a cadeia de provedores de credenciais verifica sequencialmente cada local em que você pode definir credenciais e seleciona o primeiro disponível, que geralmente corresponde às variáveis de ambiente (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` e `AWS_SESSION_TOKEN`).
O Lambda injetará o ARN da função de origem no contexto de credenciais se a solicitação for uma solicitação de API da AWS proveniente de seu ambiente de execução. O Lambda também injetará o ARN da função de origem para as seguintes solicitações de API da AWS que o Lambda faz em seu nome de forma externa ao ambiente de execução:
| Serviço | Ação | Motivo |
| --- | --- | --- |
| CloudWatch Logs | CreateLogGroup, CreateLogStream, PutLogEvents | Para armazenar logs em um grupo de logs do CloudWatch Logs. |
| X-Ray | PutTraceSegments | Para enviar dados de rastreamento para o X-Ray. |
| Amazon EFS | ClientMount | Para conectar a função a um sistema de arquivos do Amazon Elastic File System (Amazon EFS). |
Outras chamadas de API da AWS feitas pelo Lambda em seu nome de forma externa ao seu ambiente de execução e que usam o mesmo perfil de execução não contêm o ARN da função de origem. Alguns exemplos dessas chamadas de API fora do ambiente de execução incluem:
+ Chamadas para o AWS Key Management Service (AWS KMS) para criptografar e descriptografar variáveis de ambiente automaticamente.
+ Chamadas para o Amazon Elastic Compute Cloud (Amazon EC2) com a finalidade de criar interfaces de rede elástica (ENIs) para uma função habilitada para VPC.
+ Chamadas para Serviços da AWS, como o Amazon Simple Queue Service (Amazon SQS), para leitura de uma origem de evento configurada como um [mapeamento da origem do evento](invocation-eventsourcemapping.md).
Com o ARN da função de origem no contexto de credenciais, você pode verificar se uma chamada ao seu recurso veio do código de uma função do Lambda específica. Para verificar isso, use a chave de condição `lambda:SourceFunctionArn` em uma política baseada em identidade do IAM ou uma [política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
**nota**
Não é possível usar a chave de condição `lambda:SourceFunctionArn` em políticas baseadas em recursos.
Com essa chave de condição nas políticas baseadas em identidade ou SCPs, você pode implementar controles de segurança para as ações de API que o código da função realiza em outros Serviços da AWS. Isso tem algumas aplicações de segurança importantes, como ajudar a identificar a origem de um vazamento de credenciais.
**nota**
A chave de condição `lambda:SourceFunctionArn` é diferente das chaves de condição `lambda:FunctionArn` e `aws:SourceArn`. A chave de condição `lambda:FunctionArn` aplica-se somente a [mapeamentos da origem do evento](invocation-eventsourcemapping.md) e ajuda a definir quais funções a sua origem de evento pode invocar. A chave de condição `aws:SourceArn` se aplica apenas a políticas nas quais a função do Lambda é o recurso visado e ajuda a definir quais outros recursos e Serviços da AWS podem invocar essa função. A chave de condição `lambda:SourceFunctionArn` pode ser aplicada a qualquer política baseada em identidade ou SCP para definir as funções específicas do Lambda que têm permissões para fazer determinadas chamadas de API da AWS para outros recursos.
Para usar `lambda:SourceFunctionArn` na sua apólice, inclua-a como uma condição com qualquer um dos [operadores de condição de ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_ARN). O valor da chave deve ser um ARN válido.
Por exemplo, suponha que o código da função do Lambda faça uma chamada `s3:PutObject` que se destina a um bucket do Amazon S3 específico. Talvez você queira permitir que somente uma função do Lambda específica tenha acesso `s3:PutObject` a esse bucket. Nesse caso, a função de execução da função deve ter uma política anexada similar a esta:
**Example política que concede acesso para uma função do Lambda específica a um recurso do Amazon S3**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleSourceFunctionArn",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Condition": {
"ArnEquals": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
Essa política apenas permite acesso a `s3:PutObject` se a origem for a função do Lambda com o ARN `arn:aws:lambda:us-east-1:123456789012:function:source_lambda`. Essa política não permite acesso a `s3:PutObject` para qualquer outra identidade de chamada. Isso acontece mesmo que uma função ou entidade diferente faça uma chamada `s3:PutObject` com a mesma função de execução.
**nota**
A chave de condição `lambda:SourceFunctionARN` não é compatível com versões da função do Lambda ou aliases da função. Se você usar o ARN para uma determinada versão ou alias da função, ela não terá permissão para realizar a ação especificada. Certifique-se de usar o ARN não qualificado para sua função sem uma versão ou sufixo de alias.
Você também pode usar `lambda:SourceFunctionArn` em SCPs. Por exemplo, suponha que você queira restringir o acesso ao seu bucket a um único código de função do Lambda ou às chamadas de uma nuvem privada virtual (VPC) da Amazon específica. O SCP a seguir ilustra isso.
**Example política que nega acesso ao Amazon S3 sob condições específicas**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": [
"vpc-12345678"
]
}
}
},
{
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Effect": "Deny",
"Condition": {
"ArnNotEqualsIfExists": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
Essa política nega todas as ações do S3, a menos que sejam provenientes de uma função específica do Lambda com o ARN `arn:aws:lambda:*:123456789012:function:source_lambda` ou que sejam provenientes da VPC especificada. O operador `StringNotEqualsIfExists` instrui o IAM a processar essa condição somente se a chave `aws:SourceVpc` estiver presente na solicitação. Da mesma forma, o IAM apenas considerará o operador`ArnNotEqualsIfExists` somente se o `lambda:SourceFunctionArn` existir.
# Conceder a outras entidades da AWS acesso às suas funções do Lambda
Para conceder a outras Contas da AWS, organizações e serviços permissões para acessar seus recursos do Lambda, você tem algumas opções:
+ É possível usar [políticas baseadas em identidade](access-control-identity-based.md) para conceder a outros usuários acesso aos seus recursos do Lambda. As políticas baseadas em identidade podem se aplicar diretamente aos usuários ou a funções e grupos associados a um usuário.
+ É possível usar [políticas baseadas em recursos](access-control-resource-based.md) para conceder a outras contas e a Serviços da AWS permissões para acessar seus recursos do Lambda. Quando um usuário tenta acessar um recurso do Lambda, o Lambda considera as políticas baseadas em identidade e a política baseada em recursos do usuário. Quando um serviço da AWS, como o Amazon Simple Storage Service (Amazon S3), chama sua função do Lambda, o Lambda considera apenas a política baseada em recursos.
+ É possível usar um modelo de [controle de acesso por atributo (ABAC)](attribute-based-access-control.md) para controlar o acesso às suas funções do Lambda. Com o ABAC, você pode anexar tags a uma função do Lambda, transmiti-las em determinadas solicitações de API ou anexá-las à entidade principal do IAM que está fazendo a solicitação. Especificar as mesmas tags no elemento de condição de uma política do IAM para controlar o acesso à função.
Para ajudar você a ajustar suas permissões para acesso com privilégios mínimos, o Lambda fornece algumas condições adicionais que você pode incluir em suas políticas. Para obter mais informações, consulte [Ajustar as seções de Recursos e Condições das políticas](lambda-api-permissions-ref.md).
# Políticas do IAM baseadas em identidade para o Lambda
Use políticas baseadas em identidade no AWS Identity and Access Management (IAM) para conceder a usuários na conta acesso ao Lambda. As políticas baseadas na identidade podem se aplicar a usuários, grupos de usuários ou perfis. Também é possível conceder a usuários em outra conta permissão para assumir uma função na conta e acessar os recursos do Lambda.
LambdaAWSpolíticas gerenciadas que concedem acesso a ações da API do Lambda e, em alguns casos, acesso a outrasAWSserviços usados para desenvolver e gerenciar recursos do Lambda. Lambda atualiza as políticas gerenciadas conforme necessário para garantir que os usuários tenham acesso a novos recursos quando eles forem lançados.
+ [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html): concede acesso total a ações do Lambda e a outros serviços da AWS usados para desenvolver e manter recursos do Lambda.
+ [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html): concede acesso somente leitura aos recursos do Lambda.
+ [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html): concede permissões para invocar funções do Lambda.
AWSAs políticas gerenciadas do concedem permissão a ações da API sem restringir as funções ou as camadas do Lambda que um usuário pode modificar. Para um controle refinado, crie as próprias políticas que limitam o escopo das permissões de um usuário.
**Topics**
+ [Conceder aos usuários acesso a uma função do Lambda](permissions-user-function.md)
+ [Conceder a usuários acesso a uma camada do Lambda](permissions-user-layer.md)
# Conceder aos usuários acesso a uma função do Lambda
Use [políticas baseadas na identidade](access-control-identity-based.md) para permitir que usuários, grupos de usuário ou perfis realizem operações nas funções do Lambda.
**nota**
Para uma função definida como uma imagem de contêiner, a permissão do usuário para acessar a imagem deve ser configurada no Amazon Elastic Container Registry (Amazon ECR). Pare obter um exemplo, consulte [Amazon ECR repository policies](images-create.md#configuration-images-permissions).
A seguir, um exemplo de uma política de permissões com escopo limitado. Ele permite que um usuário crie e gerencie funções do Lambda com um prefixo designado (`intern-`) e configuradas com uma função de execução designada.
**Example Política de desenvolvimento da função**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Sid": "DevelopFunctions",
"Effect": "Allow",
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
},
{
"Sid": "DevelopEventSourceMappings",
"Effect": "Allow",
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
},
{
"Sid": "PassExecutionRole",
"Effect": "Allow",
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
},
{
"Sid": "ViewLogs",
"Effect": "Allow",
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
}
]
}
```
As permissões na política são organizadas em declarações com base nos [recursos e nas condições](lambda-api-permissions-ref.md) compatíveis.
+ `ReadOnlyPermissions`: o console do Lambda usa essas permissões quando você procura e exibe funções. Elas não oferecem suporte a padrões ou condições de recursos.
```
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
```
+ `DevelopFunctions`: use qualquer ação do Lambda que opere em funções prefixadas com `intern-`, exceto `AddPermission` e `PutFunctionConcurrency`. `AddPermission` modifica a [política baseada no recurso](access-control-resource-based.md) na função e pode ter implicações de segurança. `PutFunctionConcurrency` reserva capacidade de escalação para uma função e pode consumir a capacidade de outras funções.
```
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
```
+ `DevelopEventSourceMappings`: gerencie mapeamentos de origem de eventos em funções prefixadas com `intern-`. Essas ações operam em mapeamentos de origem do evento, mas é possível restringi-las por função com uma *condição*.
```
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"StringLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
```
+ `PassExecutionRole`: exiba e passe apenas uma função chamada `intern-lambda-execution-role`, que deve ser criada e gerenciada por um usuário com permissões do IAM. `PassRole` é usado quando você atribui uma função de execução a uma função.
```
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
```
+ `ViewLogs` – use o CloudWatch Logs para exibir logs de funções prefixadas com `intern-`.
```
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
```
Essa política permite que um usuário começar a usar com o Lambda, sem colocar os recursos de outros usuários em risco. Ela não permite que um usuário configure uma função para ser disparada ou acione outros serviços da AWS, o que exige permissões mais amplas do IAM. Ela também não inclui permissão para serviços que não ofereçam suporte a políticas de escopo limitado, como CloudWatch e X-Ray. Use as políticas somente leitura desses serviços para conceder ao usuário acesso a métricas e dados de rastreamento.
Ao configurar triggers para a sua função, você precisa de acesso para usar o produto da AWS que invoca a sua função. Por exemplo, para configurar um acionador do Amazon S3, é necessária a permissão para ações do Amazon S3 a fim de gerenciar notificações do bucket. Muitas dessas permissões estão incluídas na política gerenciada [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html).
# Conceder a usuários acesso a uma camada do Lambda
Use [políticas baseadas na identidade](access-control-identity-based.md) para permitir que usuários, grupos de usuário ou perfis realizem operações em camadas do Lambda. A política a seguir concede permissões a um usuário para criar camadas e usá-las com funções. Os padrões de recursos permitem que o usuário trabalhe em qualquer Região da AWS e com qualquer versão da camada, desde que o nome da camada comece com `test-`.
**Example política de desenvolvimento da camada**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PublishLayers",
"Effect": "Allow",
"Action": [
"lambda:PublishLayerVersion"
],
"Resource": "arn:aws:lambda:*:*:layer:test-*"
},
{
"Sid": "ManageLayerVersions",
"Effect": "Allow",
"Action": [
"lambda:GetLayerVersion",
"lambda:DeleteLayerVersion"
],
"Resource": "arn:aws:lambda:*:*:layer:test-*:*"
}
]
}
```
Também é possível impor o uso da camada durante a criação da função e a configuração com a condição `lambda:Layer`. Por exemplo, evite que os usuários usem camadas publicadas por outras contas. A política a seguir adiciona uma condição às ações `CreateFunction` e `UpdateFunctionConfiguration` para exigir que todas as camadas especificadas venham da conta `123456789012`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConfigureFunctions",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringLike": {
"lambda:Layer": [
"arn:aws:lambda:*:123456789012:layer:*:*"
]
}
}
}
]
}
```
------
Para garantir que a condição se aplique, verifique se não há outras instruções concedendo ao usuário permissão para essas ações.
# Visualizar políticas do IAM baseadas em recurso no Lambda
O Lambda oferece suporte a políticas de permissões baseadas em recursos para funções e camadas do Lambda. É possível usar políticas baseadas no recurso para conceder acesso a outras [contas](permissions-function-cross-account.md), [organizações](permissions-function-organization.md) ou [serviços](permissions-function-services.md) da AWS. As políticas baseadas em recursos se aplicam a uma única função, versão, alias ou versão da camada.
------
#### [ Console ]
**Como visualizar a política baseada em recursos de uma função**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha uma função.
1. Escolha **Configuração** e, em seguida, escolha **Permissões**.
1. Role para baixo até **Política baseada em recursos** e escolha **Exibir documento de política**. A política baseada em recursos mostra as permissões aplicadas quando outra conta ou serviço da AWS tenta acessar a função. O exemplo a seguir mostra uma instrução que permite ao Amazon S3 invocar uma função chamada `my-function` para um bucket chamado `amzn-s3-demo-bucket` na conta `123456789012`.
**Example política baseada em recurso**
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "lambda-allow-s3-my-function",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "123456789012"
},
"ArnLike": {
"AWS:SourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
}
]
}
```
------
#### [ AWS CLI ]
Para exibir a política baseada em recursos de uma função, use o comando `get-policy`.
```
aws lambda get-policy \
--function-name my-function \
--output text
```
A seguinte saída deverá ser mostrada:
****
```
{"Version":"2012-10-17", "Id":"default","Statement":[{"Sid":"sns","Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function","Condition":{"ArnLike":{"AWS:SourceArn":"arn:aws:sns:us-east-2:123456789012:lambda*"}}}]}
```
Para versões e aliases, acrescente o número da versão ou o alias ao nome da função.
```
aws lambda get-policy --function-name my-function:PROD
```
Para remover permissões da função, use `remove-permission`.
```
aws lambda remove-permission \
--function-name example \
--statement-id sns
```
Use o comando `get-layer-version-policy` para visualizar as permissões em uma camada.
```
aws lambda get-layer-version-policy \
--layer-name my-layer \
--version-number 3 \
--output text
```
A seguinte saída deverá ser mostrada:
```
b0cd9796-d4eb-4564-939f-de7fe0b42236 {"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-west-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
Use `remove-layer-version-permission` para remover instruções da política.
```
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org
```
------
## Ações da API com suporte
As seguintes ações de API do Lambda são compatíveis com as políticas baseadas em recursos:
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
+ [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionEventInvokeConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionEventInvokeConfig.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [Invocar](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)
+ [InvokeFunctionUrl](urls-auth.md) (somente permissão)
+ [ListAliases](https://docs.aws.amazon.com/lambda/latest/api/API_ListAliases.html)
+ [ListFunctionEventInvokeConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionEventInvokeConfigs.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)
+ [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
# Concessão de acesso da função do Lambda a Serviços da AWS
Ao [usar um serviço da AWS para invocar a função](lambda-services.md), você concede permissão em uma instrução em uma política baseada em recursos. Você pode aplicar a instrução à função toda ou limitar a instrução a uma única versão ou alias.
**nota**
Quando você adiciona um acionador à função com o console do Lambda, este atualiza a política baseada em recursos da função para permitir que o serviço a invoque. Para conceder permissões a outras contas ou serviços que não estejam disponíveis no console do Lambda, é possível usar a AWS CLI.
Adicionar uma instrução com o comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html). A instrução de política baseada em recursos mais simples permite que um serviço invoque uma função. O comando a seguir concede ao Amazon SNS permissão para invocar uma função denominada `my-function`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns \
--principal sns.amazonaws.com \
--output text
```
A seguinte saída deverá ser mostrada:
```
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
```
Isso permite que o Amazon SNS chame a ação de API [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) na função, mas não restringe o tópico do Amazon SNS que dispara a invocação. Para garantir que a função só seja invocada por um recurso específico, especifique o Amazon Resource Name (ARN – Nome de recurso da Amazon) do recurso com a opção `source-arn`. O comando a seguir só permite que o Amazon SNS invoque a função para assinaturas de um tópico chamado `my-topic`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns-my-topic \
--principal sns.amazonaws.com \
--source-arn arn:aws:sns:us-east-2:123456789012:my-topic
```
Alguns serviços podem invocar funções em outras contas. Se você especificar um ARN de origem que tenha o ID da conta, isso não será um problema. No entanto, para o Amazon S3 a origem é um bucket cujo ARN não tem um ID da conta. É possível que você consiga excluir o bucket e outra conta consiga criar um bucket com o mesmo nome. Use a opção `source-account` com o ID da sua conta para garantir que apenas os recursos na conta possam invocar a função.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id s3-account \
--principal s3.amazonaws.com \
--source-arn arn:aws:s3:::amzn-s3-demo-bucket \
--source-account 123456789012
```
# Como conceder acesso de função a uma organização
Para conceder permissões a uma organização no [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), especifique o ID da organização como o `principal-org-id`. O comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) a seguir concede acesso de invocação a todos os usuários da organização `o-a1b2c3d4e5f`.
```
aws lambda add-permission \
--function-name example \
--statement-id PrincipalOrgIDExample \
--action lambda:InvokeFunction \
--principal * \
--principal-org-id o-a1b2c3d4e5f
```
**nota**
Nesse comando, `Principal` é `*`. Isso significa que todos os usuários na organização `o-a1b2c3d4e5f` recebem permissões de invocação de função. Se você especificar uma Conta da AWS ou um perfil como `Principal`, somente essa entidade principal receberá permissões de invocação da função, mas apenas se ela também fizer parte organização `o-a1b2c3d4e5f`.
Esse comando cria uma política baseada em recursos semelhante ao exemplo a seguir:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalOrgIDExample",
"Effect": "Allow",
"Principal": "*",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:example",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-a1b2c3d4e5f"
}
}
}
]
}
```
------
Para obter mais informações, consulte [aws:PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) no *Guia do usuário do IAM*.
# Conceder a outras contas acesso à função do Lambda
Para compartilhar uma função com outra Conta da AWS, adicione uma instrução de permissões entre contas à [política baseada no recurso](access-control-resource-based.md) da função. Execute o comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) e especifique o ID da conta como a `principal`. O exemplo a seguir concede permissão à conta `111122223333` para invocar `my-function` com o alias `prod`.
```
aws lambda add-permission \
--function-name my-function:prod \
--statement-id xaccount \
--action lambda:InvokeFunction \
--principal 111122223333 \
--output text
```
A seguinte saída deverá ser mostrada:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-1:123456789012:function:my-function"}
```
A política baseada em recursos concede permissão para a outra conta acessar a função, mas não permite que os usuários nessa conta excedam suas permissões. Os usuários na outra conta devem ter as [permissões de usuário](access-control-identity-based.md) correspondentes para usar a API do Lambda.
Para limitar o acesso a um usuário ou função em outra conta, especifique o ARN completo da identidade como o principal. Por exemplo, `arn:aws:iam::123456789012:user/developer`.
O [alias](configuration-aliases.md) limita qual versão a outra conta pode chamar. Ele exige que a outra conta inclua o alias no ARN da função.
```
aws lambda invoke \
--function-name arn:aws:lambda:us-east-2:123456789012:function:my-function:prod out
```
A seguinte saída deverá ser mostrada:
```
{
"StatusCode": 200,
"ExecutedVersion": "1"
}
```
Depois disso, o proprietário da função pode atualizar o alias para apontar para uma nova versão sem que o chamador precise alterar a maneira como eles invocam sua função. Isso garante que a outra conta não precise alterar o código para usar a nova versão, e ela tem permissão somente para invocar a versão da função associada ao alias.
Conceda acesso entre contas para a maioria das ações de API que operam em uma função existente. Por exemplo, é possível conceder acesso a `lambda:ListAliases` para obter uma lista de aliases ou a `lambda:GetFunction` para permitir que eles façam download do código da função. Adicione cada permissão separadamente ou use `lambda:*` para conceder acesso a todas as ações da função especificada.
Para conceder permissão a outras contas para várias funções ou para ações que não operem em uma função, recomendamos usar as [funções do IAM](access-control-identity-based.md).
# Conceder a outras contas acesso às camadas
Para compartilhar uma camada com outra Conta da AWS, adicione uma instrução de permissões entre contas à [política baseada no recurso](access-control-resource-based.md) da camada. Execute o comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) e especifique o ID da conta como a `principal`. Em cada instrução, você pode conceder permissão apenas a uma conta, a todas as contas ou a uma organização do [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
O exemplo a seguir concede à conta 111122223333 acesso à versão 2 da camada `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
A saída deve ser semelhante a:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
As permissões se aplicam apenas a uma única versão de camada. Repita o processo sempre que criar uma nova versão da camada.
Para conceder permissão a todas as contas de uma organização do [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), use a opção `organization-id`. O exemplo a seguir concede a todas as contas de uma organização a permissão `o-t194hfs8cz` para usar a versão 3 de `my-layer`.
```
aws lambda add-layer-version-permission \
--layer-name my-layer \
--version-number 3 \
--statement-id engineering-org \
--principal '*' \
--action lambda:GetLayerVersion \
--organization-id o-t194hfs8cz \
--output text
```
A seguinte saída deverá ser mostrada:
```
{"Sid":"engineering-org","Effect":"Allow","Principal":"*","Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3","Condition":{"StringEquals":{"aws:PrincipalOrgID":"o-t194hfs8cz"}}}"
```
Para conceder permissão a várias contas ou organizações, é necessário adicionar várias instruções.
# Usar controle de acesso baseado em atributos no Lambda
Com o [controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html), você pode usar tags para controlar o acesso aos recursos do Lambda. É possível anexar tags a determinados recursos do Lambda, anexá-los em determinadas solicitações de API ou anexá-los à entidade principal do AWS Identity and Access Management (IAM) que está fazendo a solicitação. Para obter mais informações sobre como o AWS concede acesso baseado em atributos, consulte [Controlar o acesso aos recursos da AWS usando etiquetas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html), no *Guia do usuário do IAM*.
É possível usar o ABAC para [conceder privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) sem especificar um nome do recurso da Amazon (ARN) ou padrão de ARN na política do IAM. Em vez disso, você pode especificar uma etiqueta no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política do IAM para controlar o acesso. A escalabilidade é mais fácil com o ABAC, pois você não precisa atualizar as políticas do IAM ao criar recursos. Em vez disso, adicione tags aos novos recursos para controlar o acesso.
No Lambda, as tags funcionam nos seguintes recursos:
+ Funções: para obter mais informações sobre funções de marcação, consulte [Utilizar etiquetas em funções do Lambda](configuration-tags.md).
+ Configurações de assinatura de código: para obter mais informações sobre como marcar configurações de assinatura de código, consulte [Uso de tags nas configurações de assinatura de código](tags-csc.md).
+ Mapeamentos da origem do evento: para obter mais informações sobre como marcar mapeamentos da origem do evento, consulte [Uso de tags em mapeamentos da origem do evento](tags-esm.md).
Tags não são compatíveis com camadas.
É possível usar as seguintes chaves de condição para escrever regras de política do IAM com base em tags:
+ [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag): controlar o acesso baseado nas tags anexadas a um recurso do Lambda.
+ [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag): exigir que etiquetas estejam presentes em uma solicitação, como ao criar uma nova função.
+ [aws:PrincipalTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag): controle o que a entidade principal do IAM (a pessoa que está fazendo a solicitação) tem permissão para fazer com base nas etiquetas anexadas ao seu respectivo [usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html) ou [perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_roles.html) do IAM.
+ [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys): controle se chaves de etiquetas específicas podem ser usadas em uma solicitação.
Você só pode especificar condições para ações que sejam compatíveis. Para obter uma lista de condições compatíveis com cada ação do Lambda, consulte [Actions, resources, and condition keys for AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) na Referência de autorização do serviço. Para obter suporte para **aws:ResourceTag/tag-key**, consulte “Resource types defined by AWS Lambda”. Para obter suporte para **aws:RequestTag/tag-key** e **aws:TagKeys**, consulte “Actions defined by AWS Lambda”.
**Topics**
+ [Proteja suas funções por tag](attribute-based-access-control-example.md)
# Proteja suas funções por tag
As etapas a seguir demonstram uma forma de configurar permissões para funções usando o ABAC. Neste cenário de exemplo, você criará quatro políticas de permissões do IAM. Em seguida, anexará essas políticas a um novo perfil do IAM. Por último, você criará um usuário do IAM e concederá a ele permissão para assumir a nova função.
**Topics**
+ [Pré-requisitos](#abac-prerequisites)
+ [Etapa 1: exigir etiquetas em novas funções](#require-tag-on-create)
+ [Etapa 2: permitir ações com base em etiquetas anexadas a uma função do Lambda e a uma entidade principal do IAM](#restrict-actions-function-tags)
+ [Etapa 3: conceder permissões de lista](#abac-list-permissions)
+ [Etapa 4: conceder permissões do IAM](#abac-iam-permissions)
+ [Etapa 5: Criar o perfil do IAM](#abac-create-role)
+ [Etapa 6: criar o usuário do IAM](#abac-create-user)
+ [Etapa 7: Testar as permissões](#abac-test)
+ [Etapa 8: limpar os recursos](#abac-clean-up)
## Pré-requisitos
Verifique se você tem um [perfil de execução do Lambda](lambda-intro-execution-role.md). Você usará esse perfil ao conceder permissões do IAM e ao criar uma função do Lambda.
## Etapa 1: exigir etiquetas em novas funções
Ao usar o ABAC com o Lambda, é uma prática recomendada exigir que todas as funções tenham etiquetas. Isso ajuda a garantir que suas políticas de permissões de ABAC funcionem conforme o esperado.
[Crie uma política do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) semelhante ao exemplo a seguir. Esta política usa as chaves de condição [aws:RequestTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag), [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) e [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) para exigir que novas funções e a entidade principal do IAM que cria essas funções tenham a tag `project`. O modificador `ForAllValues` garante que `project` seja a única etiqueta permitida. Se você não incluir o modificador `ForAllValues`, os usuários poderão adicionar outras etiquetas à função, desde que também transmitam `project`.
**Example – Exigir etiquetas em novas funções**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:TagResource"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/project": "${aws:PrincipalTag/project}",
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": "project"
}
}
}
}
```
## Etapa 2: permitir ações com base em etiquetas anexadas a uma função do Lambda e a uma entidade principal do IAM
Crie uma segunda política do IAM usando a chave de condição [aws:ResourceTag/tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) para exigir que a etiqueta da entidade principal corresponda à etiqueta anexada à função. O exemplo de política a seguir permite que entidades principais com a etiqueta `project` invoquem funções do com a etiqueta `project`. Se uma função tiver outras etiquetas, a ação será negada.
**Example – Exigir etiquetas correspondentes na função e na entidade principal do IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:GetFunction"
],
"Resource": "arn:aws:lambda:*:*:function:*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
}
}
}
]
}
```
## Etapa 3: conceder permissões de lista
Crie uma política que permita que a entidade principal liste funções do Lambda e perfis do IAM. Isso permite que a entidade principal veja todas as funções do Lambda e perfis do IAM no console e ao chamar as ações de API.
**Example – Conceder permissões de lista do Lambda e do IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllResourcesLambdaNoTags",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:ListFunctions",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
## Etapa 4: conceder permissões do IAM
Crie uma política que permita **iam:PassRole**. Essa permissão é necessária quando você atribui um perfil de execução a uma função. No exemplo de política a seguir, substitua o ARN de exemplo pelo ARN do seu perfil de execução do Lambda.
**nota**
Não use a chave de condição `ResourceTag` em uma política com a ação `iam:PassRole`. Não é possível usar a etiqueta em uma função do IAM para controlar o acesso de quem pode transmitir essa função. Para obter mais informações sobre as permissões necessárias para transmitir uma função a um serviço, consulte [Conceder permissões a um usuário para transmitir uma função a um serviço da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html).
**Example – Conceder permissão para transmitir a função de execução**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/lambda-ex"
}
]
}
```
## Etapa 5: Criar o perfil do IAM
É uma prática recomendada [usar funções para delegar permissões](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate-using-roles). [Crie um perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html#roles-creatingrole-user-console) chamada `abac-project-role`:
+ Em **Step 1: Select trusted entity** (Etapa 1: selecionar entidade confiável): escolha a **conta da AWS** e depois **This account** (Esta conta).
+ Em **Step 2: Add permissions** (Etapa 2: adicionar permissões): anexe as quatro políticas do IAM que você criou nas etapas anteriores.
+ Em **Step 3: Name, review, and create** (Etapa 3: nomear, revisar e criar): escolha **Add tag** (Adicionar etiqueta). Em **Chave**, digite `project`. Não insira nada em **Value** (Valor).
## Etapa 6: criar o usuário do IAM
[Crie um usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) chamado `abac-test-user`. Na seção **Set permissions** (Definir permissões), escolha **Attach existing policies directly** (Anexar políticas existentes diretamente) e escolha **Create policy** (Criar política). Insira a seguinte definição de política. Substitua *111122223333* pelo [ID da sua conta da AWS](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingYourAccountIdentifiers). Essa política permite que `abac-test-user` assuma `abac-project-role`.
**Example – Permitir que o usuário do IAM assuma o perfil ABAC**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/abac-project-role"
}
}
```
------
## Etapa 7: Testar as permissões
1. Faça login no console do AWS como `abac-test-user`. Para obter mais informações, consulte [Fazer login como usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html#user-sign-in-page).
1. Alterne para a função `abac-project-role`. Para obter mais informações, consulte [Alternar para uma função (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html).
1. [Crie uma função do Lambda](configuration-tags.md#using-tags-with-the-console):
+ Em **Permissions** (Permissões), escolha **Change default execution role** (Alterar a função de execução padrão) e, em **Execution role** (Função de execução), escolha **Use an existing role** (Usar uma função existente). Escolha o mesmo perfil de execução que você usou em [Etapa 4: conceder permissões do IAM](#abac-iam-permissions).
+ Em **Advanced settings** (Configurações avançadas), escolha **Enable tags** (Habilitar etiquetas) e escolha **Add new tag** (Adicionar nova etiqueta). Em **Chave**, digite `project`. Não insira nada em **Value** (Valor).
1. [Testar a função](testing-functions.md).
1. Crie uma segunda função do Lambda e adicione uma etiqueta diferente, como `environment`. Essa operação deve falhar, pois a política de ABAC que você criou em [Etapa 1: exigir etiquetas em novas funções](#require-tag-on-create) apenas permite que a entidade principal crie funções do com a etiqueta `project`.
1. Crie uma terceira função sem etiquetas. Essa operação deve falhar, pois a política de ABAC que você criou em [Etapa 1: exigir etiquetas em novas funções](#require-tag-on-create) não permite que a entidade principal crie funções sem etiquetas.
Essa estratégia de autorização permite controlar o acesso sem criar novas políticas para cada novo usuário. Para conceder acesso a novos usuários, basta dar a eles permissão para assumir o perfil que corresponde ao projeto atribuído.
## Etapa 8: limpar os recursos
**Para excluir o perfil do IAM**
1. Abra a página [Funções](https://console.aws.amazon.com/iam/home#/roles) no console do IAM.
1. Selecione o perfil criado na [etapa 5](#abac-create-role).
1. Escolha **Excluir**.
1. Para confirmar a exclusão, insira o nome do perfil no campo de entrada de texto.
1. Escolha **Excluir**.
**Para excluir o usuário do IAM**
1. Abra a página [Usuários](https://console.aws.amazon.com/iam/home#/users) no console do IAM.
1. Selecione o usuário do IAM que você criou na [etapa 6](#abac-create-user).
1. Escolha **Excluir**.
1. Para confirmar a exclusão, insira o nome do usuário no campo de entrada de texto.
1. Escolha **Excluir usuário**.
**Como excluir a função do Lambda**
1. Abra a página [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funções) no console do Lambda.
1. Selecione a função que você criou.
1. Selecione **Ações**, **Excluir**.
1. Digite **confirm** no campo de entrada de texto e escolha **Delete** (Excluir).
# Ajustar as seções de Recursos e Condições das políticas
É possível restringir o escopo das permissões de um usuário especificando recursos e condições em uma política do AWS Identity and Access Management (IAM). Cada ação de API oferece suporte a uma combinação de tipos de condição e recurso que varia de acordo com o comportamento da ação.
Cada instrução de política do IAM concede permissão a uma ação realizada em um recurso. Quando a ação não atua em um recurso indicado, ou quando você concede permissão para executar a ação em todos os recursos, o valor do recurso na política é um curinga (`*`). Para muitas ações, restrinja os recursos que um usuário pode modificar especificando o nome do recurso da Amazon (ARN) de um recurso ou um padrão de ARN correspondente a vários recursos.
Por tipo de recurso, o design geral de como restringir o escopo de uma ação é o seguinte:
+ Funções: as ações que operam em uma função podem ser restritas a uma função específica por ARN do alias, função, versão.
+ Mapeamentos da origem do evento: as ações podem ser restritas a recursos específicos de mapeamento da origem do evento pelo ARN. Os mapeamentos da origem do evento estão sempre associados a uma função. Também é possível usar a condição `lambda:FunctionArn` para restringir ações por função associada.
+ Camadas: as ações relacionadas a permissões e uso de camadas atuam em uma versão de uma camada.
+ Configuração de assinatura de código: as ações podem ser restritas a recursos específicos de configuração de assinatura de código pelo ARN.
+ Tags: use condições de tag padrão. Para obter mais informações, consulte [Usar controle de acesso baseado em atributos no Lambda](attribute-based-access-control.md).
Para restringir as permissões por recurso especifique o recurso por ARN.
**Formato do ARN de recurso Lambda**
+ Função: – `arn:aws:lambda:us-west-2:123456789012:function:my-function`
+ Versão da função: – `arn:aws:lambda:us-west-2:123456789012:function:my-function:1`
+ Alias da função: – `arn:aws:lambda:us-west-2:123456789012:function:my-function:TEST`
+ Mapeamento de origem de evento: – `arn:aws:lambda:us-west-2:123456789012:event-source-mapping:fa123456-14a1-4fd2-9fec-83de64ad683de6d47`
+ Camada: – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer`
+ Versão da camada: – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer:1`
+ Configuração de assinatura de código: `arn:aws:lambda:us-west-2:123456789012:code-signing-config:my-csc`
Por exemplo, a política a seguir permite que um usuário na Conta da AWS `123456789012` invoque uma função denominada `my-function` na região da AWS Oeste dos EUA (Oregon).
**Example invocar política de função**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Invoke",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:my-function"
}
]
}
```
Trata-se de um caso especial em que o identificador da ação (`lambda:InvokeFunction`) é diferente da operação da API ([Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)). Para outras ações, o identificador da ação é o nome da operação com o prefixo `lambda:`.
**Topics**
+ [Entender a seção Condição nas políticas](#authorization-conditions)
+ [Referência a funções na seção Recursos das políticas](#function-resources)
+ [Comportamentos de função e ações do IAM compatíveis](#permissions-resources)
## Entender a seção Condição nas políticas
As condições são um elemento opcional da política que aplica lógica adicional para determinar se uma ação é permitida. Além de [condições](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) comuns compatíveis com todas as ações, o Lambda define os tipos de condição que você pode usar para restringir os valores de parâmetros adicionais em algumas ações.
Por exemplo, a condição `lambda:Principal` permite restringir o serviço ou a conta, para que um usuário possa conceder acesso de invocação em uma [política baseada em recursos](access-control-resource-based.md) de uma função. A política a seguir permite que um usuário conceda permissão para que tópicos do Amazon Simple Notification Service (Amazon SNS) invoquem uma função chamada `test`.
**Example gerenciar permissões de política de função**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ManageFunctionPolicy",
"Effect": "Allow",
"Action": [
"lambda:AddPermission",
"lambda:RemovePermission"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:test:*",
"Condition": {
"StringEquals": {
"lambda:Principal": "sns.amazonaws.com"
}
}
}
]
}
```
A condição requer que o principal seja o Amazon SNS e não outro serviço ou outra conta. O padrão do recurso exige que o nome da função seja `test` e inclua um número de versão ou alias. Por exemplo, `test:v1`.
Para obter mais informações sobre recursos e condições do Lambda e outros serviços da AWS, consulte [Ações, recursos e chaves de condição para serviços da AWS](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). na *Referência a autorizações de serviços*.
## Referência a funções na seção Recursos das políticas
Você referencia uma função do Lambda em uma instrução de política usando um nome do recurso da Amazon (ARN). O formato de um ARN de função depende se você estiver referenciando toda a função (não qualificado), a [versão](configuration-versions.md) de uma função ou um [alias](configuration-aliases.md) (qualificado).
Ao fazer chamadas de API do Lambda, os usuários podem especificar uma versão ou alias passando um ARN de versão ou um ARN de alias no parâmtro [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) do `FunctionName` ou definindo um valor no parâmetro [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) do `Qualifier`. O Lambda toma decisões de autorização comparando o elemento de recurso na política do IAM com o `FunctionName` e `Qualifier` transmitido nas chamadas de API. Se houver incompatibilidade, o Lambda negará a solicitação.
Para permitir ou negar uma ação em sua função, é necessário usar os tipos de ARN de função corretos na declaração de política para obter os resultados esperados. Por exemplo, se sua política referenciar o ARN não qualificado, o Lambda aceitará solicitações que referenciam o ARN não qualificado, mas negará solicitações que referenciam um ARN qualificado.
**nota**
Não é possível usar um caractere curinga (\$1) para encontrar o valor correspondente ao ID da conta. Para obter mais informações sobre a sintaxe aceita, consulte [Referência a políticas JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html), no *Guia do usuário do IAM*.
**Example permitir invocação de um ARN não qualificado**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction"
}
]
}
```
Se sua política referenciar um ARN qualificado específico, o Lambda aceitará solicitações que referenciam esse ARN, mas negará solicitações que referenciam o ARN não qualificado ou outro ARN qualificado, por exemplo, `myFunction:2`.
**Example permitir invocação de um ARN qualificado específico**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:1"
}
]
}
```
Se sua política referenciar qualquer ARN qualificado usando `:*`, o Lambda aceitará qualquer ARN qualificado, mas negará solicitações que referenciem o ARN não qualificado.
**Example permitir invocação de qualquer ARN qualificado**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
}
]
}
```
Se sua política referenciar qualquer ARN usando `*`, o Lambda aceitará qualquer ARN qualificado ou não qualificado.
**Example permitir invocação de qualquer ARN qualificado ou não qualificado**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction*"
}
]
}
```
## Comportamentos de função e ações do IAM compatíveis
As ações definem o que pode ser permitido por meio das políticas do IAM. Para obter uma lista de ações compatíveis no Lambda, consulte [Actions, resources, and condition keys for AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) na Referência de autorização do serviço. Na maioria dos casos, quando uma ação do IAM permite uma ação da API do Lambda, o nome da ação do IAM é igual ao nome da ação da API do Lambda, com as seguintes exceções:
| Ação da API | Ação do IAM |
| --- | --- |
| [Invocar](https://docs.aws.amazon.com//lambda/latest/api/API_Invoke.html) | lambda:InvokeFunction |
| [GetLayerVersion](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersion.html) [GetLayerVersionByArn](https://docs.aws.amazon.com//lambda/latest/api/API_GetLayerVersionByArn.html) | lambda:GetLayerVersion |
Além dos recursos e das condições definidos na [Referência de autorização do serviço](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html), o Lambda é compatível com os seguintes recursos e condições para determinadas ações: Muitos deles estão relacionados às funções de referência na seção de recursos das políticas. As ações que operam em uma função podem ser restritas a uma função específica pelo ARN da função, da versão ou do alias, conforme descrito na tabela a seguir.
| Ação | Recurso | Condição |
| --- | --- | --- |
| [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) [Invocar](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) (**Permissões:** `lambda:InvokeFunction`) | Versão da função Alias da função | N/D |
| [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) | N/D | `lambda:CodeSigningConfigArn` |
| [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html) [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html) [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html) | Alias da função | N/D |