Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Gestione delle autorizzazioni in AWS Lambda
Puoi usare AWS Identity and Access Management (IAM) per gestire le autorizzazioni in. AWS Lambda Esistono due categorie principali di autorizzazioni da considerare quando si lavora con le funzioni Lambda:
+ Autorizzazioni necessarie alle funzioni Lambda per eseguire azioni API e accedere ad altre risorse AWS
+ Autorizzazioni necessarie ad altri AWS utenti ed entità per accedere alle tue funzioni Lambda
Le funzioni Lambda spesso devono accedere ad altre AWS risorse ed eseguire varie operazioni API su tali risorse. Ad esempio, è possibile che tu disponga di una funzione Lambda che risponde a un evento aggiornando le voci in un database Amazon DynamoDB. In questo caso, la funzione necessita delle autorizzazioni per accedere al database, nonché delle autorizzazioni per inserire o aggiornare elementi in quel database.
Definisci le autorizzazioni di cui ha bisogno la tua funzione Lambda in un ruolo IAM speciale chiamato [ruolo di esecuzione](lambda-intro-execution-role.md). In questo ruolo, puoi allegare una policy che definisce tutte le autorizzazioni necessarie alla tua funzione per accedere ad altre AWS risorse e leggere le fonti degli eventi. Ogni funzione Lambda deve avere un ruolo di esecuzione. Come minimo, il ruolo di esecuzione deve avere accesso ad Amazon CloudWatch perché le funzioni Lambda accedono ai CloudWatch log per impostazione predefinita. Puoi collegare la [policy gestita da `AWSLambdaBasicExecutionRole`](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html) al tuo ruolo di esecuzione per soddisfare questo requisito.
Per concedere Account AWS ad altre organizzazioni e servizi le autorizzazioni per accedere alle tue risorse Lambda, hai alcune opzioni:
+ È possibile utilizzare le [policy basate sull'identità](access-control-identity-based.md) per concedere agli utenti l'accesso alle risorse Lambda. Le policy basate su identità possono essere applicate direttamente agli utenti o ai gruppi e ruoli associati a un utente.
+ Puoi utilizzare [policy basate sulle risorse](access-control-resource-based.md) per concedere ad altri account e Servizi AWS autorizzazioni per accedere alle tue risorse Lambda. Quando un utente prova ad accedere a una risorsa Lambda, Lambda considera sia le policy basate su identità dell'utente che la policy basata sulla risorsa della risorsa. Quando un AWS servizio come Amazon Simple Storage Service (Amazon S3) richiama la funzione Lambda, Lambda considera solo la politica basata sulle risorse.
+ Puoi utilizzare un modello [controllo degli accessi basato su attributi (ABAC)](attribute-based-access-control.md), per controllare l'accesso alle funzioni Lambda. Con ABAC, puoi collegare i tag a una funzione Lambda, inviarli in determinate richieste API o collegarli al principale IAM da cui proviene la richiesta. Per controllare gli accessi alla funzione, puoi invece specificare gli stessi tag nell'elemento di condizione di una policy IAM.
[In generale AWS, è consigliabile concedere solo le autorizzazioni necessarie per eseguire un'attività (autorizzazioni con privilegi minimi).](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) Per implementarlo in Lambda, consigliamo di iniziare con una [policy gestita da AWS](permissions-managed-policies.md). Puoi utilizzare queste policy gestite così come sono o come punto di partenza per scrivere le tue policy più restrittive.
Per aiutarti a ottimizzare le autorizzazioni per l'accesso con privilegi minimi, Lambda fornisce alcune condizioni aggiuntive che puoi includere nelle tue policy. Per ulteriori informazioni, consulta [Ottimizzazione delle sezioni Risorse e Condizioni delle policy](lambda-api-permissions-ref.md).
Per ulteriori informazioni su IAM, consulta la *[Guida per l'utente di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)*.
# Definizione delle autorizzazioni della funzione Lambda con un ruolo di esecuzione
Il ruolo di esecuzione di una funzione Lambda è un ruolo AWS Identity and Access Management (IAM) che concede alla funzione l'autorizzazione all'accesso Servizi AWS e alle risorse. Ad esempio, potresti creare un ruolo di esecuzione con l'autorizzazione a inviare log ad Amazon CloudWatch e caricare AWS X-Ray dati di traccia su. Questa pagina fornisce informazioni su come creare, visualizzare e gestire il ruolo di esecuzione di una funzione Lambda.
Lambda assume automaticamente il tuo ruolo di esecuzione quando richiami la tua funzione. Dovresti evitare di chiamare `sts:AssumeRole` manualmente per assumere il ruolo di esecuzione nel codice della funzione. Se il tuo caso d'uso richiede che il ruolo venga assunto autonomamente, dovrai includere il ruolo stesso come principale attendibile nella policy di attendibilità del ruolo. Per ulteriori informazioni su come modificare una policy di attendibilità del ruolo, consulta [Modifica di una policy di attendibilità del ruolo (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-managingrole_edit-trust-policy) nella Guida per l'utente di IAM.
Affinché Lambda possa assumere correttamente il ruolo di esecuzione, la [policy di attendibilità](#permissions-executionrole-api) del ruolo deve specificare il principale del servizio Lambda (`lambda.amazonaws.com`) come servizio attendibile.
**Topics**
+ [
## Creazione di un ruolo di esecuzione nella console di IAM
](#permissions-executionrole-console)
+ [
## Creazione e gestione dei ruoli con AWS CLI
](#permissions-executionrole-api)
+ [
## Garantisci l'accesso minimo ai privilegi per il tuo ruolo di esecuzione Lambda
](#permissions-executionrole-least-privilege)
+ [
# Visualizzazione e aggiornamento delle autorizzazioni nel ruolo di esecuzione
](permissions-executionrole-update.md)
+ [
# Utilizzo delle politiche AWS gestite nel ruolo di esecuzione
](permissions-managed-policies.md)
+ [
# Utilizzo dell'ARN della funzione di origine per controllare il comportamento di accesso alla funzione
](permissions-source-function-arn.md)
## Creazione di un ruolo di esecuzione nella console di IAM
Per impostazione predefinita, Lambda crea un ruolo di esecuzione con autorizzazioni minime quando si [crea una funzione nella console Lambda](getting-started.md#getting-started-create-function). In particolare, questo ruolo di esecuzione include la [policy `AWSLambdaBasicExecutionRole` gestita](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html), che fornisce alla tua funzione le autorizzazioni di base per registrare gli eventi su Amazon CloudWatch Logs. Puoi selezionare **Crea ruolo predefinito nella sezione** **Autorizzazioni**.
Puoi scegliere un ruolo esistente selezionando **Usa un altro ruolo nella sezione** **Autorizzazioni**. Se la tua funzione Lambda necessita di autorizzazioni aggiuntive per eseguire attività come l'aggiornamento delle voci in un database Amazon DynamoDB in risposta agli eventi, puoi creare un ruolo di esecuzione personalizzato con le autorizzazioni necessarie. Per fare ciò, seleziona **Usa un altro ruolo** nella sezione **Autorizzazioni, che apre un cassetto in cui puoi personalizzare le tue autorizzazioni**.
**Per configurare un ruolo di esecuzione dalla console**
1. Inserisci **il nome del ruolo** nella sezione Dettagli del ruolo.
1. Nella sezione **Politica**, seleziona **Usa politica esistente**.
1. Seleziona le politiche AWS gestite che desideri allegare al tuo ruolo. Ad esempio, se la tua funzione deve accedere a DynamoDB, seleziona la policy gestita da **DBExecutionDynamo AWSLambda Role**.
1. Scegli **Crea ruolo**.
In alternativa, quando [crei una funzione nella console Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function), puoi allegare qualsiasi ruolo di esecuzione creato in precedenza alla funzione. Se desideri associare un nuovo ruolo di esecuzione a una funzione esistente, segui i passaggi in [Aggiornamento del ruolo di esecuzione di una funzione](permissions-executionrole-update.md).
## Creazione e gestione dei ruoli con AWS CLI
Per creare un ruolo di esecuzione con AWS Command Line Interface (AWS CLI), utilizzate il **create-role** comando. Quando utilizzi questo comando, puoi specificare la policy di attendibilità in linea. La policy di attendibilità di un ruolo garantisce ai principali specificati l'autorizzazione per assumere tale ruolo. Nell'esempio seguente concedi al principale del servizio Lambda l'autorizzazione per assumere il ruolo. I requisiti per l'escape delle virgolette nella stringa JSON variano in base alla 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"}]}'
```
Puoi inoltre definire la policy di attendibilità per il ruolo utilizzando un file JSON separato. Nell'esempio seguente, `trust-policy.json` è un file che si trova nella directory attuale.
**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
```
Utilizza il comando **attach-policy-to-role** per aggiungere le autorizzazioni al ruolo. Il seguente comando aggiunge la policy gestita da `AWSLambdaBasicExecutionRole` al ruolo di esecuzione `lambda-ex`.
```
aws iam attach-role-policy --role-name lambda-ex --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Dopo aver creato il ruolo di esecuzione, collegalo alla funzione. Quando si [crea una funzione nella console Lambda](getting-started.md#getting-started-create-function), potrai collegare alla funzione qualsiasi ruolo di esecuzione creato in precedenza. Se desideri associare un nuovo ruolo di esecuzione a una funzione esistente, segui i passaggi indicati in [Aggiornamento del ruolo di esecuzione di una funzione](permissions-executionrole-update.md#update-execution-role).
## Garantisci l'accesso minimo ai privilegi per il tuo ruolo di esecuzione Lambda
Quando si crea per la prima volta un ruolo IAM per la funzione Lambda durante la fase di sviluppo, a volte è possibile concedere altre autorizzazioni oltre a quanto richiesto. Prima di pubblicare la funzione nell'ambiente di produzione, una best practice consiste nel modificare la policy in modo da includere solo le autorizzazioni richieste. Per ulteriori informazioni, consulta [Applicazione delle autorizzazioni del privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) nella *Guida per l'utente di IAM*.
Utilizzare IAM Access Analyzer per identificare le autorizzazioni necessarie per la policy del ruolo di esecuzione IAM. IAM Access Analyzer esamina i tuoi AWS CloudTrail log nell'intervallo di date specificato e genera un modello di policy con solo le autorizzazioni utilizzate dalla funzione in quel periodo. È possibile utilizzare il modello per creare una policy gestita con autorizzazioni granulari e quindi collegarla al ruolo IAM. In questo modo, concedi solo le autorizzazioni necessarie al ruolo per interagire con le AWS risorse per il tuo caso d'uso specifico.
Per ulteriori informazioni, consulta [Generazione di policy basate sull'attività di accesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_generate-policy.html) nella *Guida per l'utente di IAM*.
# Visualizzazione e aggiornamento delle autorizzazioni nel ruolo di esecuzione
Questo argomento spiega come visualizzare e aggiornare il [ruolo di esecuzione](lambda-intro-execution-role.md) della funzione.
**Topics**
+ [
## Visualizzazione del ruolo di esecuzione di una funzione
](#view-execution-role)
+ [
## Aggiornamento del ruolo di esecuzione di una funzione
](#update-execution-role)
## Visualizzazione del ruolo di esecuzione di una funzione
Per visualizzare il ruolo di esecuzione di una funzione, usa la console Lambda.
**Per visualizzare il ruolo di esecuzione di una funzione (console)**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Scegli **Configuration** (Configurazione), quindi **Permissions** (Autorizzazioni).
1. In **Ruolo di esecuzione**, puoi visualizzare il ruolo attualmente utilizzato come ruolo di esecuzione della funzione. Per comodità, puoi visualizzare tutte le risorse e le azioni a cui la funzione può accedere nella sezione **Riepilogo delle risorse**. Puoi anche scegliere un servizio dal menu a discesa per visualizzare tutte le autorizzazioni relative a tale servizio.
## Aggiornamento del ruolo di esecuzione di una funzione
È possibile aggiungere o rimuovere le autorizzazioni da un ruolo di esecuzione della funzione in qualsiasi momento, oppure configurare la funzione per l'utilizzo di un altro ruolo. Se la funzione richiede l'accesso a qualsiasi altro servizio o risorsa, è necessario aggiungere le autorizzazioni necessarie al ruolo di esecuzione.
Quando aggiungi le autorizzazioni alla funzione, aggiorni anche il relativo codice o la configurazione. Questa operazione forza l'arresto e la sostituzione delle istanze della funzione in esecuzione che hanno credenziali obsolete.
Per aggiornare il ruolo di esecuzione di una funzione, usa la console Lambda.
**Per aggiornare il ruolo di esecuzione della funzione (console)**
1. Aprire la pagina [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funzioni) della console Lambda.
1. Scegliere il nome della funzione.
1. Scegli **Configuration** (Configurazione), quindi **Permissions** (Autorizzazioni).
1. In **Ruolo di esecuzione**, scegli **Modifica**.
1. Se desideri aggiornare la tua funzione in modo da utilizzare un ruolo diverso come ruolo di esecuzione, scegli il nuovo ruolo nel menu a discesa sotto **Ruolo esistente**.
**Nota**
Se desideri aggiornare le autorizzazioni all'interno di un ruolo di esecuzione esistente, puoi farlo solo nella console AWS Identity and Access Management (IAM).
Se desideri creare un nuovo ruolo da utilizzare come ruolo di esecuzione, scegli **Crea un nuovo ruolo dai modelli di AWS policy** in **Ruolo di esecuzione**. Quindi, inserisci un nome per il tuo nuovo ruolo in **Nome ruolo** e specifica le politicy che desideri collegare al nuovo ruolo in **Modelli di policy**.
1. Seleziona **Salva**.
# Utilizzo delle politiche AWS gestite nel ruolo di esecuzione
Le seguenti politiche AWS gestite forniscono le autorizzazioni necessarie per utilizzare le funzionalità Lambda.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| **[ AWSLambdaMSKExecutionRuolo](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)**: Lambda ha aggiunto l'autorizzazione [kafka: DescribeCluster V2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#v2-clusters-clusterarnget) a questa policy. | `AWSLambdaMSKExecutionRole`concede le autorizzazioni per leggere e accedere ai record da un cluster Amazon Managed Streaming for Apache Kafka (Amazon MSK), gestire interfacce di ENIs rete elastiche () e scrivere nei log. CloudWatch | 17 giugno 2022 |
| **[ AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole)**— Lambda ha iniziato a tracciare le modifiche a questa politica. | `AWSLambdaBasicExecutionRole` concede le autorizzazioni per caricare i log su CloudWatch. | 14 febbraio 2022 |
| **[ AWSLambdaDynamo DBExecution Role](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole)** — Lambda ha iniziato a tenere traccia delle modifiche a questa politica. | `AWSLambdaDynamoDBExecutionRole`concede le autorizzazioni per leggere i record da un flusso Amazon DynamoDB e scrivere nei log. CloudWatch | 14 febbraio 2022 |
| **[ AWSLambdaKinesisExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaKinesisExecutionRole)**— Lambda ha iniziato a tracciare le modifiche a questa politica. | `AWSLambdaKinesisExecutionRole`concede le autorizzazioni per leggere eventi da un flusso di dati Amazon Kinesis e scrivere su Logs. CloudWatch | 14 febbraio 2022 |
| **[ AWSLambdaMSKExecutionRuolo](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaMSKExecutionRole)**: Lambda ha iniziato a tenere traccia delle modifiche a questa politica. | `AWSLambdaMSKExecutionRole`concede le autorizzazioni per leggere e accedere ai record da un cluster Amazon Managed Streaming for Apache Kafka (Amazon MSK), gestire interfacce di ENIs rete elastiche () e scrivere nei log. CloudWatch | 14 febbraio 2022 |
| **[ AWSLambdaSQSQueueExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaSQSQueueExecutionRole)**— Lambda ha iniziato a tracciare le modifiche a questa politica. | `AWSLambdaSQSQueueExecutionRole`concede le autorizzazioni per leggere un messaggio da una coda Amazon Simple Queue Service (Amazon SQS) e scrivere nei log. CloudWatch | 14 febbraio 2022 |
| **[ AWSLambdaVPCAccessExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole)**— Lambda ha iniziato a tracciare le modifiche a questa politica. | `AWSLambdaVPCAccessExecutionRole`concede le autorizzazioni per la gestione all' ENIs interno di un Amazon VPC e la scrittura nei log. CloudWatch | 14 febbraio 2022 |
| **[ AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)**— Lambda ha iniziato a tracciare le modifiche a questa politica. | `AWSXRayDaemonWriteAccess` concede le autorizzazioni per caricare i dati non elaborati su X-Ray. | 14 febbraio 2022 |
| **[ CloudWatchLambdaInsightsExecutionRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy)**— Lambda ha iniziato a tracciare le modifiche a questa politica. | `CloudWatchLambdaInsightsExecutionRolePolicy`concede le autorizzazioni per scrivere metriche di runtime a CloudWatch Lambda Insights. | 14 febbraio 2022 |
| **[AmazonS3 — ObjectLambdaExecutionRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonS3ObjectLambdaExecutionRolePolicy)** Lambda ha iniziato a tracciare le modifiche a questa politica. | `AmazonS3ObjectLambdaExecutionRolePolicy`concede le autorizzazioni per interagire con l'oggetto Lambda di Amazon Simple Storage Service (Amazon S3) e per scrivere su Logs. CloudWatch | 14 febbraio 2022 |
Per alcune funzionalità, la console Lambda tenta di aggiungere autorizzazioni mancanti al ruolo di esecuzione in una policy gestita dal cliente. Queste policy possono diventare numerose. Aggiungere le policy gestite AWS pertinenti al ruolo di esecuzione prima di abilitare le funzionalità per evitare la creazione di policy aggiuntive.
Quando si utilizza una [mappatura origine eventi](invocation-eventsourcemapping.md) per invocare la funzione, Lambda utilizza il ruolo di esecuzione per leggere i dati dell'evento. Ad esempio, la mappatura dell'origine eventi per Kinesis legge gli eventi provenienti da un flusso di dati e li invia alla funzione in batch.
Quando un servizio assume un ruolo nel tuo account, puoi includere le chiavi di contesto delle condizioni globali `aws:SourceAccount` e `aws:SourceArn` nella policy di attendibilità del ruolo per limitare l'accesso al ruolo solo alle richieste generate dalle risorse previste. Per ulteriori informazioni consulta [Prevenzione del problema "confused deputy" tra servizi per AWS Security Token Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention).
Oltre alle policy AWS gestite, la console Lambda fornisce modelli per la creazione di policy personalizzate con autorizzazioni per casi d'uso aggiuntivi. Quando si crea una funzione nella console Lambda, è possibile scegliere di creare un nuovo ruolo di esecuzione con le autorizzazioni da uno o più modelli. Questi modelli vengono applicati automaticamente al momento della creazione di una funzione da un blueprint, oppure quando si configurano le opzioni che richiedono l'accesso ad altri servizi. [Modelli di esempio sono disponibili nell'archivio di questa guida. GitHub](https://github.com/awsdocs/aws-lambda-developer-guide/tree/master/iam-policies)
# Utilizzo dell'ARN della funzione di origine per controllare il comportamento di accesso alla funzione
È normale che il codice della funzione Lambda effettui richieste API ad altri Servizi AWS. Per effettuare queste richieste, Lambda genera un insieme effimero di credenziali assumendo il ruolo di esecuzione della tua funzione. Queste credenziali sono disponibili come variabili d'ambiente durante l'invocazione della funzione. Quando si lavora con AWS SDKs, non è necessario fornire le credenziali per l'SDK direttamente nel codice. Per impostazione predefinita, la catena di fornitori di credenziali controlla in sequenza ogni punto in cui è possibile impostare le credenziali e seleziona la prima disponibile, in genere le variabili d'ambiente (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` e `AWS_SESSION_TOKEN`).
Lambda inserisce la funzione di origine ARN nel contesto delle credenziali se la richiesta è una richiesta AWS API proveniente dall'ambiente di esecuzione. Lambda inserisce anche l'ARN della funzione di origine per le seguenti richieste API AWS che Lambda effettua per tuo conto al di fuori dell'ambiente di esecuzione:
| Servizio | Azione | Motivo |
| --- | --- | --- |
| CloudWatch Registri | CreateLogGroup, CreateLogStream, PutLogEvents | Per archiviare i log in un gruppo di CloudWatch log Logs |
| X-Ray | PutTraceSegments | Invio dei dati di traccia a X-Ray |
| Amazon EFS | ClientMount | Connessione di una funzione a un file system Amazon Elastic File System (Amazon EFS) |
Le altre chiamate AWS API che Lambda effettua al di fuori dell'ambiente di esecuzione per tuo conto utilizzando lo stesso ruolo di esecuzione non contengono la funzione di origine ARN. Esempi di tali chiamate API al di fuori dell'ambiente di esecuzione includono:
+ Chiama a AWS Key Management Service (AWS KMS) per crittografare e decrittografare automaticamente le variabili di ambiente.
+ Chiamate ad Amazon Elastic Compute Cloud (Amazon EC2) per creare interfacce ENIs di rete elastiche () per una funzione abilitata al VPC.
+ [Chiamate a Servizi AWS, come Amazon Simple Queue Service (Amazon SQS), per la lettura da un'origine di eventi configurata come mappatura delle sorgenti di eventi.](invocation-eventsourcemapping.md)
Con l'ARN della funzione di origine nel contesto delle credenziali puoi verificare se una chiamata alla tua risorsa proviene dal codice di una funzione Lambda specifica. Per verificarlo, usa la chiave di condizione `lambda:SourceFunctionArn` in una policy basata sulle identità IAM o una [policy di controllo dei servizi (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
**Nota**
Non puoi utilizzare la chiave di condizione `lambda:SourceFunctionArn` nelle policy basate sulle risorse.
Implementando questa condizione nelle tue policy basate sull'identità SCPs, puoi oppure implementare controlli di sicurezza per le azioni API che il tuo codice funzionale esegue su altri. Servizi AWS Questo ha alcune funzioni di sicurezza chiave, come aiutarti a identificare l'origine di una perdita di credenziali.
**Nota**
La chiave di condizione `lambda:SourceFunctionArn` è diversa dalle chiavi di condizione `lambda:FunctionArn` e `aws:SourceArn`. La chiave di condizione `lambda:FunctionArn` si applica solo a [mappature di origine eventi](invocation-eventsourcemapping.md) e aiuta a definire quali funzioni può richiamare l'origine eventi. La chiave di `aws:SourceArn` condizione si applica solo alle politiche in cui la funzione Lambda è la risorsa di destinazione e aiuta a definire quali altre Servizi AWS risorse possono richiamare quella funzione. La chiave di `lambda:SourceFunctionArn` condizione può essere applicata a qualsiasi policy o SCP basata sull'identità per definire le funzioni Lambda specifiche che dispongono delle autorizzazioni per effettuare chiamate API specifiche ad altre risorse. AWS
Per utilizzare `lambda:SourceFunctionArn` nella tua policy, includila come condizione con uno qualsiasi degli [operatori di condizione ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_ARN). Il valore della chiave deve essere un ARN valido.
Ad esempio, supponiamo che il codice della funzione Lambda effettui una chiamata `s3:PutObject` che si rivolge a un determinato bucket Amazon S3. Potresti volere che solo una funzione Lambda specifica abbia accesso `s3:PutObject` a quel bucket. In questo caso, il ruolo di esecuzione della funzione deve avere una policy collegata simile alla seguente:
**Example policy che concede l'accesso a una funzione Lambda specifica a una risorsa 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"
}
}
}
]
}
```
Questa policy consente l'accesso `s3:PutObject` solo se l'origine è la funzione Lambda con ARN `arn:aws:lambda:us-east-1:123456789012:function:source_lambda`. La policy non consente l'accesso `s3:PutObject` ad alcun'altra identità chiamante. Ciò è vero anche se una funzione o entità diversa effettua una chiamata `s3:PutObject` con lo stesso ruolo di esecuzione.
**Nota**
La chiave di condizione `lambda:SourceFunctionARN` non supporta gli alias delle funzioni o le versioni delle funzioni Lambda. Se utilizzi l'ARN per una particolare versione o alias di una funzione, la tua funzione non avrà l'autorizzazione per eseguire l'azione specificata. Assicurarsi di utilizzare l'ARN non completo per la funzione senza un suffisso di versione o alias.
Puoi anche usare in. `lambda:SourceFunctionArn` SCPs Ad esempio, supponiamo di voler limitare l'accesso al bucket al codice di una singola funzione Lambda o a chiamate da un cloud privato virtuale (VPC) Amazon specifico. L'SCP seguente illustra questo scenario.
**Example politica che nega l'accesso ad Amazon S3 in condizioni specifiche**
****
```
{
"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"
}
}
}
]
}
```
Questa policy nega tutte le azioni S3 a meno che non provengano da una specifica funzione Lambda con ARN `arn:aws:lambda:*:123456789012:function:source_lambda` o a meno che non provengano dal VPC specificato. L'operatore `StringNotEqualsIfExists` dice a IAM di elaborare questa condizione solo se la chiave `aws:SourceVpc` è presente nella richiesta. Allo stesso modo, IAM considera l'operatore `ArnNotEqualsIfExists` solo se esiste `lambda:SourceFunctionArn`.
# Concedere ad altre AWS entità l'accesso alle tue funzioni Lambda
Per concedere Account AWS ad altre organizzazioni e servizi le autorizzazioni per accedere alle tue risorse Lambda, hai alcune opzioni:
+ È possibile utilizzare le [policy basate sull'identità](access-control-identity-based.md) per concedere agli utenti l'accesso alle risorse Lambda. Le policy basate su identità possono essere applicate direttamente agli utenti o ai gruppi e ruoli associati a un utente.
+ Puoi utilizzare [policy basate sulle risorse](access-control-resource-based.md) per concedere ad altri account e Servizi AWS autorizzazioni per accedere alle tue risorse Lambda. Quando un utente prova ad accedere a una risorsa Lambda, Lambda considera sia le policy basate su identità dell'utente che la policy basata sulla risorsa della risorsa. Quando un AWS servizio come Amazon Simple Storage Service (Amazon S3) richiama la funzione Lambda, Lambda considera solo la politica basata sulle risorse.
+ Puoi utilizzare un modello [controllo degli accessi basato su attributi (ABAC)](attribute-based-access-control.md), per controllare l'accesso alle funzioni Lambda. Con ABAC, puoi collegare i tag a una funzione Lambda, inviarli in determinate richieste API o collegarli al principale IAM da cui proviene la richiesta. Per controllare gli accessi alla funzione, puoi invece specificare gli stessi tag nell'elemento di condizione di una policy IAM.
Per aiutarti a ottimizzare le autorizzazioni per l'accesso con privilegi minimi, Lambda fornisce alcune condizioni aggiuntive che puoi includere nelle tue policy. Per ulteriori informazioni, consulta [Ottimizzazione delle sezioni Risorse e Condizioni delle policy](lambda-api-permissions-ref.md).
# Policy IAM basate sull'identità per Lambda
Puoi utilizzare le policy basate sull'identità in AWS Identity and Access Management (IAM) per concedere agli utenti del tuo account l'accesso a Lambda. Le policy basate sulle identità possono essere applicate a utenti, gruppi di utenti o ruoli. È inoltre possibile concedere le autorizzazioni a utenti in un altro account in modo che assumano un ruolo nel proprio account ed eseguano l'accesso alle risorse Lambda.
Lambda fornisce policy AWS gestite che garantiscono l'accesso alle azioni dell'API Lambda e, in alcuni casi, l'accesso ad altri AWS servizi utilizzati per sviluppare e gestire le risorse Lambda. Lambda aggiorna le policy gestite in base alle necessità, per assicurare che gli utenti possano accedere a nuove caratteristiche quando queste vengono rilasciate.
+ [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Garantisce l'accesso completo alle azioni Lambda e AWS ad altri servizi utilizzati per sviluppare e gestire le risorse Lambda.
+ [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Garantisce l'accesso in sola lettura alle risorse Lambda.
+ [AWSLambdaRuolo](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html): concede le autorizzazioni per richiamare le funzioni Lambda.
AWS le politiche gestite concedono l'autorizzazione alle azioni API senza limitare le funzioni o i livelli Lambda che un utente può modificare. Per un controllo ancora più accurato, è possibile creare le proprie policy che limitano l'ambito di applicazione delle autorizzazioni di un utente.
**Topics**
+ [
# Concedere agli utenti l'accesso a una funzione Lambda
](permissions-user-function.md)
+ [
# Concedere agli utenti l'accesso a un livello Lambda
](permissions-user-layer.md)
# Concedere agli utenti l'accesso a una funzione Lambda
Utilizza le [policy basate sull'identità](access-control-identity-based.md) per consentire a utenti, gruppi di utenti o ruoli di eseguire operazioni sulle funzioni Lambda.
**Nota**
Per una funzione definita come immagine di container, l'autorizzazione utente per accedere all'immagine deve essere configurata in Amazon Elastic Container Registry (Amazon ECR). Per un esempio, consulta le [policy del repository di Amazon ECR](images-create.md#configuration-images-permissions).
Di seguito viene illustrato un esempio di policy di autorizzazione con ambito di applicazione limitato. Ciò consente a un utente di creare e gestire le funzioni Lambda denominate con un prefisso designato (`intern-`) e configurate con un ruolo di esecuzione designato.
**Example Policy di sviluppo delle funzioni**
****
```
{
"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-*"
}
]
}
```
Le autorizzazioni nella policy sono organizzate in dichiarazioni in base alle [risorse e le condizioni](lambda-api-permissions-ref.md) che supportano.
+ `ReadOnlyPermissions` – La console Lambda utilizza queste autorizzazioni quando l'utente sfoglia e visualizza le funzioni. Esse non supportano i modelli di risorse o condizioni.
```
"Action": [
"lambda:GetAccountSettings",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetFunctionCodeSigningConfig",
"lambda:GetFunctionConcurrency",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"iam:ListRoles"
],
"Resource": "*"
```
+ `DevelopFunctions`: utilizza qualsiasi operazione che opera su funzioni con prefisso `intern-`, eccetto `AddPermission` e `PutFunctionConcurrency`. `AddPermission` modifica la [policy basata sulle risorse](access-control-resource-based.md) sulla funzione e può avere implicazioni in termini di sicurezza. `PutFunctionConcurrency` riserva la capacità di dimensionamento per una funzione e può prendere la capacità da altre funzioni.
```
"NotAction": [
"lambda:AddPermission",
"lambda:PutFunctionConcurrency"
],
"Resource": "arn:aws:lambda:*:*:function:intern-*"
```
+ `DevelopEventSourceMappings`: gestisci le mappature di origine eventi sulle funzioni con prefisso `intern-`. Queste operazioni operano su mappature di origine eventi, ma è possibile limitarle per funzione con una *condizione*.
```
"Action": [
"lambda:DeleteEventSourceMapping",
"lambda:UpdateEventSourceMapping",
"lambda:CreateEventSourceMapping"
],
"Resource": "*",
"Condition": {
"StringLike": {
"lambda:FunctionArn": "arn:aws:lambda:*:*:function:intern-*"
}
}
```
+ `PassExecutionRole` – Visualizzare e trasferire solo un ruolo denominato `intern-lambda-execution-role`, che deve essere creato e gestito da un utente con le autorizzazioni IAM. `PassRole` viene utilizzato quando si assegna un ruolo di esecuzione a una funzione.
```
"Action": [
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:PassRole",
"iam:SimulatePrincipalPolicy"
],
"Resource": "arn:aws:iam::*:role/intern-lambda-execution-role"
```
+ `ViewLogs`— Utilizzare CloudWatch Logs per visualizzare i log delle funzioni il cui prefisso è. `intern-`
```
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/intern-*"
```
Questa policy consente a un utente di iniziare con Lambda, senza mettere le risorse di altri utenti a rischio. Non consente a un utente di configurare una funzione da attivare o chiamare altri AWS servizi, il che richiede autorizzazioni IAM più ampie. Inoltre, non include l'autorizzazione a servizi che non supportano politiche ad ambito limitato, come CloudWatch X-Ray. Utilizzare le policy di sola lettura per questi servizi per fornire all'utente l'accesso ai parametri e ai dati di traccia.
Quando configuri i trigger per la tua funzione, devi accedere per utilizzare il AWS servizio che richiama la tua funzione. Ad esempio, per configurare un trigger Amazon S3, è necessario disporre dell'autorizzazione per utilizzare le operazioni Amazon S3 che gestiscono le notifiche dei bucket. Molte di queste autorizzazioni sono incluse nella politica gestita. [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)
# Concedere agli utenti l'accesso a un livello Lambda
Utilizza le [policy basate sull'identità](access-control-identity-based.md) per consentire a utenti, gruppi di utenti o ruoli di eseguire operazioni sui livelli Lambda. La seguente policy concede un'autorizzazione utente per creare i livelli e utilizzarli con le funzioni. I modelli di risorse consentono all'utente di lavorare in qualsiasi Regione AWS versione del livello, purché il nome del livello inizi con`test-`.
**Example Policy per lo sviluppo dei livelli**
****
```
{
"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-*:*"
}
]
}
```
È anche possibile implementare l'utilizzo di livelli durante la creazione e la configurazione della funzione con la condizione `lambda:Layer`. Ad esempio, è possibile evitare che gli utenti utilizzino livelli pubblicati da altri account. La policy seguente aggiunge una condizione per le operazioni `CreateFunction` e `UpdateFunctionConfiguration` per richiedere che i livelli specificati provengano dall'account `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:*:*"
]
}
}
}
]
}
```
------
Per garantire che la condizione venga applicata, verificare che nessun'altra dichiarazioni conceda l'autorizzazione all'utente per tali azioni.
# Visualizzazione delle policy IAM basate sulle risorse in Lambda
Lambda supporta le policy di autorizzazioni basate sulle risorse per le funzioni e i livelli Lambda. Puoi utilizzare le policy basate sulle risorse per concedere l'accesso ad altri [account AWS](permissions-function-cross-account.md), [organizzazioni](permissions-function-organization.md) o [servizi](permissions-function-services.md). Le policy basate sulle risorse si applicano a una singola funzione, versione, alias o versione del livello.
------
#### [ Console ]
**Per visualizzare le policy basate sulle risorse di una funzione**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere una funzione.
1. Scegliere **Configuration (Configurazione)**, quindi **Permissions (Autorizzazioni)**.
1. Scorrere verso il basso fino a **Policy basata su risorse**, quindi scegliere **View Policy Document (Visualizza documento policy)**. La politica basata sulle risorse mostra le autorizzazioni applicate quando un altro account o servizio tenta di accedere alla funzione. AWS L'esempio seguente mostra un'istruzione che consente ad Amazon S3 di richiamare una funzione denominata `my-function` per un bucket denominato `amzn-s3-demo-bucket` nell'account `123456789012`.
**Example policy basata su risorse**
****
```
{
"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 ]
Per visualizzare una policy basata sulle risorse di una funzione, utilizzare il comando `get-policy`.
```
aws lambda get-policy \
--function-name my-function \
--output text
```
Verrà visualizzato l’output seguente:
****
```
{"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*"}}}]}
```
Per le versioni e gli alias, aggiungere il numero di versione o un alias al nome della funzione.
```
aws lambda get-policy --function-name my-function:PROD
```
Per rimuovere le autorizzazioni dalla funzione, utilizzare `remove-permission`.
```
aws lambda remove-permission \
--function-name example \
--statement-id sns
```
Utilizzare il comando `get-layer-version-policy` per visualizzare le autorizzazioni su un layer.
```
aws lambda get-layer-version-policy \
--layer-name my-layer \
--version-number 3 \
--output text
```
Verrà visualizzato l’output seguente:
```
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"}}}"
```
Utilizzare `remove-layer-version-permission` per rimuovere le istruzioni dalla policy.
```
aws lambda remove-layer-version-permission --layer-name my-layer --version-number 3 --statement-id engineering-org
```
------
## Operazioni API supportate
Le seguenti operazioni dell'API Lambda supportano le policy basate sulle risorse:
+ [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)
+ [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)
+ [InvokeFunctionUrl](urls-auth.md)(solo autorizzazione)
+ [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)
# Concessione dell'accesso alla funzione Lambda a Servizi AWS
Quando [utilizzi un AWS servizio per richiamare la tua funzione](lambda-services.md), concedi l'autorizzazione in una dichiarazione su una politica basata sulle risorse. È possibile applicare l'istruzione all'intera funzione oppure limitare l'istruzione a una singola versione o alias.
**Nota**
Quando si aggiunge un trigger a una funzione con la console Lambda, la console aggiorna la policy basata sulle risorse della funzione per consentire al servizio di invocarla. Per concedere le autorizzazioni ad altri account o servizi che non sono disponibili nella console Lambda, puoi utilizzare l'interfaccia a riga di comando di AWS CLI.
Aggiungi una istruzione con il comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html). La dichiarazione più semplice della policy basata sulla risorsa consente a un servizio di invocare una funzione. Il comando seguente concede ad Amazon Simple Notification Service l'autorizzazione per richiamare una funzione denominata `my-function`.
```
aws lambda add-permission \
--function-name my-function \
--action lambda:InvokeFunction \
--statement-id sns \
--principal sns.amazonaws.com \
--output text
```
Verrà visualizzato l'output seguente:
```
{"Sid":"sns","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"lambda:InvokeFunction","Resource":"arn:aws:lambda:us-east-2:123456789012:function:my-function"}
```
In questo modo Amazon SNS richiama l'operazione API [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) per la funzione, ma non limita l'argomento Amazon SNS che attiva la chiamata. Per garantire che la tua funzione venga richiamata solo da una risorsa specifica, specificare l'Amazon Resource Name (ARN) della risorsa con l'opzione `source-arn`. Il comando seguente consente solo a Amazon SNS di richiamare la funzione per gli abbonamenti a un argomento denominato `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
```
Alcuni servizi possono invocare le funzioni in altri account. Se si specifica un ARN origine che ha il proprio ID account, non è un problema. Per Amazon S3, tuttavia, l'origine è un bucket il cui ARN non dispone di un ID account. È possibile eliminare il bucket e un altro account può creare un bucket con lo stesso nome. Utilizza l'opzione `source-account` con il tuo ID account per avere la certezza che solo le risorse nel proprio account possano richiamare la funzione.
```
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
```
# Concedere l'accesso alle funzioni a un'organizzazione
Per concedere un'autorizzazione a un'organizzazione in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), specifica l'ID dell'organizzazione come `principal-org-id`. Il seguente comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) garantisce l'accesso all'invocazione a tutti gli utenti dell'organizzazione `o-a1b2c3d4e5f`.
```
aws lambda add-permission \
--function-name example \
--statement-id PrincipalOrgIDExample \
--action lambda:InvokeFunction \
--principal * \
--principal-org-id o-a1b2c3d4e5f
```
**Nota**
In questo comando, `Principal` è `*`. Ciò significa che tutti gli utenti dell'organizzazione `o-a1b2c3d4e5f` ottengono le autorizzazioni di invocazione delle funzioni. Se specifichi un ruolo Account AWS o come`Principal`, solo quel principale ottiene i permessi di invocazione della funzione, ma solo se fa anche parte dell'organizzazione. `o-a1b2c3d4e5f`
Questo comando crea una policy basata sulle risorse simile alla seguente:
------
#### [ 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"
}
}
}
]
}
```
------
Per ulteriori informazioni, consulta [aws: PrincipalOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) nella guida per l'utente *IAM*.
# Concessione dell'accesso alla funziona Lambda ad altri account
[Per condividere una funzione con un'altra Account AWS, aggiungi una dichiarazione di autorizzazione per più account alla politica basata sulle risorse della funzione.](access-control-resource-based.md) Esegui il comando [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) e specifica l'ID account come `principal`. L'esempio seguente concede l'autorizzazione `111122223333` a un account per invocare `my-function` con l'alias `prod`.
```
aws lambda add-permission \
--function-name my-function:prod \
--statement-id xaccount \
--action lambda:InvokeFunction \
--principal 111122223333 \
--output text
```
Verrà visualizzato l'output seguente:
```
{"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"}
```
La policy basata sulle risorse concede l'autorizzazione all'altro account per accedere alla funzione, ma non consente agli utenti in tale account di superare le autorizzazioni. Gli utenti nell'altro account devono disporre delle [autorizzazioni utente](access-control-identity-based.md) corrispondenti per utilizzare l'API Lambda.
Per limitare l'accesso a un utente, un gruppo o un ruolo in un altro account, specificare l'ARN completo dell'identità come principale. Ad esempio `arn:aws:iam::123456789012:user/developer`.
L'[alias](configuration-aliases.md) limita quale versione l'altro account può invocare. Richiede che l'altro account includa l'alias nell'ARN della funzione.
```
aws lambda invoke \
--function-name arn:aws:lambda:us-east-2:123456789012:function:my-function:prod out
```
Verrà visualizzato l'output seguente:
```
{
"StatusCode": 200,
"ExecutedVersion": "1"
}
```
Il proprietario della funzione può quindi aggiornare l'alias per puntare a una nuova versione senza che il chiamante debba cambiare il modo in cui invoca la funzione. In questo modo l'altro account non deve modificare il codice per utilizzare la nuova versione e dispone solo dell'autorizzazione per richiamare la versione della funzione associata all'alias.
È possibile concedere l'accesso tra account per qualsiasi operazione API che opera su una funzione esistente. Ad esempio, è possibile concedere l'accesso a un account `lambda:ListAliases` per ottenere un elenco di alias, oppure `lambda:GetFunction` per scaricare il codice funzione. Aggiungere ogni autorizzazione separatamente oppure utilizzare `lambda:*` per concedere l'accesso a tutte le azioni per la funzione specificata.
Per concedere ad altri account l'autorizzazione per più funzioni o per operazioni che non operano su una funzione, utilizzare [ruoli IAM](access-control-identity-based.md).
# Concessione dell'accesso ai livelli Lambda ad altri account
[Per condividere un layer con un altro Account AWS, aggiungi una dichiarazione di autorizzazione per più account alla policy basata sulle risorse del layer.](access-control-resource-based.md) Esegui il [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html)comando e specifica l'ID dell'account come. `principal` In ogni istruzione, puoi concedere l'autorizzazione a un singolo account, a tutti gli account o a un'organizzazione in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
L'esempio seguente concede all'account 111122223333 l'accesso alla versione 2 del livello `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
```
Verrà visualizzato un output simile al seguente:
```
{"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"}
```
Le autorizzazioni si applicano solo a un'unica versione di un livello. Ripeti la procedura ogni volta che crei la nuova versione di un livello.
Per concedere le autorizzazioni a tutti gli account in un'organizzazione [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), è possibile utilizzare l'opzione `organization-id`. L'esempio seguente concede a tutti gli account dell'organizzazione l'autorizzazione `o-t194hfs8cz` per utilizzare la versione 3 di `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
```
Verrà visualizzato l'output seguente:
```
{"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"}}}"
```
Per concedere l'autorizzazione a più account o organizzazioni, devi aggiungere più istruzioni.
# Utilizzo del controllo degli accessi basato sugli attributi in Lambda
Con il [controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html), puoi usare i tag per controllare l'accesso alle risorse Lambda. Puoi allegare tag a determinate risorse Lambda, allegarli a determinate richieste API o collegarli al principale AWS Identity and Access Management (IAM) che effettua la richiesta. *Per ulteriori informazioni su come AWS concedere l'accesso basato sugli attributi, consulta [Controlling access to AWS resources using tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) nella IAM User Guide.*
Puoi utilizzare ABAC per [concedere il privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) senza specificare un nome della risorsa Amazon (ARN) o uno schema ARN nella policy IAM. Per controllare gli accessi puoi invece specificare un tag nell'[elemento di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy IAM. La scalabilità è più facile con ABAC perché non è necessario aggiornare le policy IAM quando vengono create nuove risorse. Invece, per controllare l'accesso aggiungi i tag alle nuove risorse.
In Lambda, i tag funzionano sulle seguenti risorse:
+ Funzioni: per ulteriori informazioni sul tagging delle funzioni, consulta [Uso dei tag sulle funzioni Lambda](configuration-tags.md).
+ Configurazioni di firma del codice: per ulteriori informazioni sul tagging delle configurazioni di firma del codice, consulta [Utilizzo di tag nelle configurazioni di firma del codice](tags-csc.md).
+ Strumenti di mappatura dell'origine degli eventi: per ulteriori informazioni sul tagging degli strumenti di mappatura dell'origine degli eventi, consulta [Utilizzo di tag negli strumenti di mappatura dell'origine degli eventi](tags-esm.md).
I tag non sono supportati per i livelli.
È possibile utilizzare le seguenti chiavi di condizione per scrivere regole di policy IAM basate sui tag:
+ [aws: ResourceTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag): controlla l'accesso in base ai tag allegati a una risorsa Lambda.
+ [aws: RequestTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag): richiede che i tag siano presenti in una richiesta, ad esempio quando si crea una nuova funzione.
+ [aws: PrincipalTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags_users.html)
+ [aws:TagKeys:](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) Controlla se è possibile utilizzare chiavi di tag specifiche in una richiesta.
Puoi specificare solo le condizioni per le azioni che le supportano. Per un elenco delle operazioni supportate da ogni operazione Lambda, consulta [Operazioni, risorse e chiavi di condizione per AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) in Service Authorization Reference. Per il supporto di **aws: ResourceTag /tag-key**, consulta «Tipi di risorse definiti da». AWS Lambda Per **aws: RequestTag /tag-key** e **aws: TagKeys** support, consulta «Azioni definite da». AWS Lambda
**Topics**
+ [
# Proteggere le funzioni con un tag
](attribute-based-access-control-example.md)
# Proteggere le funzioni con un tag
La seguente procedura mostra un modo per impostare le autorizzazioni per le funzioni tramite ABAC. In questo scenario di esempio, creerai quattro policy di autorizzazione IAM. Quindi, collegherai queste policy a un nuovo ruolo IAM. Infine, creerai un utente IAM e gli assegnerai l'autorizzazione per assumere il nuovo ruolo.
**Topics**
+ [
## Prerequisiti
](#abac-prerequisites)
+ [
## Fase 1: richiesta di tag sulle nuove funzioni
](#require-tag-on-create)
+ [
## Fase 2: Consentire azioni basate su tag collegati a una funzione Lambda e al principale IAM
](#restrict-actions-function-tags)
+ [
## Fase 3: Concessione delle autorizzazioni di elenco
](#abac-list-permissions)
+ [
## Fase 4: Concessione delle autorizzazioni IAM
](#abac-iam-permissions)
+ [
## Fase 5: Creazione del ruolo IAM
](#abac-create-role)
+ [
## Fase 6: Creazione dell'utente IAM
](#abac-create-user)
+ [
## Fase 7: Test delle autorizzazioni
](#abac-test)
+ [
## Fase 8: eliminare le risorse
](#abac-clean-up)
## Prerequisiti
Assicurati di avere un [ruolo di esecuzione Lambda](lambda-intro-execution-role.md). Userai questo ruolo quando concedi le autorizzazioni IAM e crei una funzione Lambda.
## Fase 1: richiesta di tag sulle nuove funzioni
Quando utilizzi ABAC con Lambda, è consigliabile richiedere che tutte le funzioni abbiano i tag. Questo aiuta a garantire che le policy di autorizzazione ABAC funzionino come previsto.
[Crea una policy IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor) simile a quella del seguente esempio. Questa policy utilizza le chiavi [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) condition per richiedere che le nuove funzioni e il principale IAM che le crea abbiano entrambi il tag. `project` Il modificatore `ForAllValues` assicura che `project` sia l'unico tag consentito. Se non includi il modificatore `ForAllValues`, gli utenti potranno aggiungere altri tag alla funzione purché passino anche loro `project`.
**Example : richiesta di tag sulle nuove funzioni**
****
```
{
"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"
}
}
}
}
```
## Fase 2: Consentire azioni basate su tag collegati a una funzione Lambda e al principale IAM
Crea una seconda policy IAM utilizzando la chiave di condizione [aws: ResourceTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) per richiedere che il tag del principale corrisponda al tag associato alla funzione. La seguente policy di esempio consente ai principali con tag `project` di richiamare le funzioni con il tag `project`. Se una funzione ha altri tag, l'azione è negata.
**Example : Richiesta di tag corrispondenti sulla funzione e sul principale 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}"
}
}
}
]
}
```
## Fase 3: Concessione delle autorizzazioni di elenco
Crea una policy che consenta al principale di elencare le funzioni Lambda e i ruoli IAM. Ciò consente al principale di vedere tutte le funzioni Lambda e i ruoli IAM sulla console e quando si chiamano le operazioni API.
**Example : Concessione delle autorizzazioni di elenco per Lambda e IAM**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllResourcesLambdaNoTags",
"Effect": "Allow",
"Action": [
"lambda:GetAccountSettings",
"lambda:ListFunctions",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
## Fase 4: Concessione delle autorizzazioni IAM
**Crea una policy che consenta iam:. PassRole** Questa autorizzazione è necessaria quando si assegna un ruolo di esecuzione a una funzione. Nella seguente policy di esempio, sostituisci l'ARN di esempio con l'ARN del tuo ruolo di esecuzione Lambda.
**Nota**
Non utilizzare la chiave di condizione `ResourceTag` in una policy con l'operazione `iam:PassRole`. Non puoi utilizzare il tag su un ruolo IAM per controllare l'accesso a chi può passare tale ruolo. Per ulteriori informazioni sulle autorizzazioni necessarie per passare un ruolo a un servizio, vedere [Concessione a un utente delle autorizzazioni per passare un ruolo a un](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) servizio. AWS
**Example : Concessione dell'autorizzazione per inviare il ruolo di esecuzione**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/lambda-ex"
}
]
}
```
## Fase 5: Creazione del ruolo IAM
Una best practice consiste nell'[utilizzare i ruoli per delegare le autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate-using-roles). [Crea un ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html#roles-creatingrole-user-console) chiamato `abac-project-role`:
+ In **Fase 1: Selezione dell'entità attendibile**, scegli **Account AWS **, quindi **Questo account**.
+ In **Fase 2: Aggiunta delle autorizzazioni**, collega le quattro policy IAM create nei passaggi precedenti.
+ In **Fase 3: Assegnazione di un nome, revisione e creazione**, scegli **Add tag** (Aggiungi tag). In **Chiave**, inserire `project`. Non immettere un **valore**.
## Fase 6: Creazione dell'utente IAM
[Crea un utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) chiamato `abac-test-user`. Nella sezione **Set permissions** (Imposta autorizzazioni), seleziona **Attach existing policies directly** (Collega direttamente le policy esistenti), quindi **Create policy** (Crea policy). Immetti la seguente definizione di policy. Sostituisci *111122223333* con il tuo [ID account AWS](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingYourAccountIdentifiers). Questa policy consente a `abac-test-user` di assumere il ruolo `abac-project-role`.
**Example : Consentire all'utente IAM di assumere il ruolo ABAC**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/abac-project-role"
}
}
```
------
## Fase 7: Test delle autorizzazioni
1. Accedi alla console come. AWS `abac-test-user` Per ulteriori informazioni, consulta [Accesso come utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html#user-sign-in-page).
1. Passare al ruolo `abac-project-role`. Per ulteriori informazioni, consulta [Cambio di un ruolo (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html).
1. [Crea una funzione Lambda](configuration-tags.md#using-tags-with-the-console):
+ In **Permissions** (Autorizzazioni), scegli **Change default execution role** (Modifica ruolo di esecuzione predefinito), quindi per **Execution role** (Ruolo di esecuzione), scegli **Use an existing role** (Utilizza un ruolo esistente). Scegli lo stesso ruolo di esecuzione che hai usato in [Fase 4: Concessione delle autorizzazioni IAM](#abac-iam-permissions).
+ In **Advanced settings** (Impostazioni avanzate), seleziona **Enable tags** (Abilita tag) quindi scegli **Add new tag** (Aggiungi nuovo tag). In **Chiave**, inserire `project`. Non immettere un **valore**.
1. [Esegui il test della funzione](testing-functions.md).
1. Crea una seconda funzione Lambda e aggiungi un tag diverso, ad esempio `environment`. Questa operazione dovrebbe non riuscire perché la policy ABAC creata in [Fase 1: richiesta di tag sulle nuove funzioni](#require-tag-on-create) consente al principale di creare solo funzioni con tag `project`.
1. Crea una terza funzione senza tag. Questa operazione dovrebbe non riuscire perché la policy ABAC creata in [Fase 1: richiesta di tag sulle nuove funzioni](#require-tag-on-create) non consente al principale di creare funzioni senza tag.
Questa strategia di autorizzazione consente di controllare l'accesso senza creare nuove policy per ogni nuovo utente. Per concedere l'accesso a nuovi utenti, è sufficiente concedere loro l'autorizzazione per assumere il ruolo che corrisponde al progetto assegnato.
## Fase 8: eliminare le risorse
**Per eliminare il ruolo IAM**
1. Aprire la pagina [Ruoli](https://console.aws.amazon.com/iam/home#/roles) della console IAM.
1. Seleziona il ruolo creato nella [fase 5](#abac-create-role).
1. Scegli **Elimina**.
1. Per confermare l'eliminazione, inserisci il nome del ruolo nel campo di immissione del testo.
1. Scegli **Elimina**.
**Per eliminare l'utente IAM**
1. Apri la pagina [Utenti](https://console.aws.amazon.com/iam/home#/users) nella console IAM.
1. Seleziona l'utente IAM creato nella [fase 6](#abac-create-user).
1. Scegli **Elimina**.
1. Per confermare l'eliminazione, inserisci il nome utente nel campo di immissione del testo.
1. Scegli **Elimina utente**.
**Per eliminare la funzione Lambda**
1. Aprire la pagina [Functions (Funzioni)](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Selezionare la funzione creata.
1. Scegliere **Operazioni**, **Elimina**.
1. Digita **confirm** nel campo di immissione testo e scegli **Delete** (Elimina).
# Ottimizzazione delle sezioni Risorse e Condizioni delle policy
Puoi limitare l'ambito delle autorizzazioni di un utente specificando le risorse e le condizioni in una policy AWS Identity and Access Management (IAM). Ogni operazione in una policy supporta una combinazione di tipi di risorse e condizioni che varia a seconda del comportamento dell'operazione.
Ogni dichiarazione di policy IAM concede l'autorizzazione a un'operazione eseguita su una risorsa. Quando l'operazione non agisce su una risorsa designata oppure quando concedi l'autorizzazione per eseguire l'operazione su tutte le risorse, il valore della risorsa nella policy è un carattere jolly (`*`). Per molte operazioni, puoi limitare le risorse che un utente può modificare specificando il nome della risorsa Amazon (ARN) di una risorsa o uno schema ARN che corrisponde a più risorse.
Per tipo di risorsa, la struttura generale di come limitare l'ambito di un'azione è la seguente:
+ Funzioni: le operazioni alla base di una funzione possono essere limitate a una funzione specifica in base alla funzione, alla versione o all'ARN dell'alias.
+ Strumenti di mappatura dell'origine degli eventi: le azioni possono essere limitate a risorse specifiche dello strumento di mappatura dell'origine degli eventi tramite ARN. Gli strumenti di mappatura dell'origine degli eventi sono sempre associati a una funzione. È inoltre possibile utilizzare la condizione `lambda:FunctionArn` per limitare le operazioni in base alla funzione associata.
+ Livelli: le operazioni che riguardano l'utilizzo e le autorizzazioni relative ai livelli agiscono su una versione di un livello.
+ Configurazione della firma del codice: le azioni possono essere limitate a risorse di configurazione di firma del codice specifiche tramite ARN.
+ Tag: utilizza condizioni standard per i tag. Per ulteriori informazioni, consulta [Utilizzo del controllo degli accessi basato sugli attributi in Lambda](attribute-based-access-control.md).
Per limitare le autorizzazioni in base alla risorsa, specifica la risorsa in base all'ARN.
**Formato ARN della risorsa Lambda**
+ Funzione – `arn:aws:lambda:us-west-2:123456789012:function:my-function`
+ Versione funzione – `arn:aws:lambda:us-west-2:123456789012:function:my-function:1`
+ Alias funzione – `arn:aws:lambda:us-west-2:123456789012:function:my-function:TEST`
+ Mappatura delle origini eventi – `arn:aws:lambda:us-west-2:123456789012:event-source-mapping:fa123456-14a1-4fd2-9fec-83de64ad683de6d47`
+ Livello – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer`
+ Versione livello – `arn:aws:lambda:us-west-2:123456789012:layer:my-layer:1`
+ Configurazione della firma del codice: `arn:aws:lambda:us-west-2:123456789012:code-signing-config:my-csc`
Ad esempio, la seguente politica consente a un utente di Account AWS `123456789012` richiamare una funzione denominata `my-function` nella regione Stati Uniti occidentali (Oregon) AWS .
**Example Invocare la policy di una funzione**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Invoke",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:my-function"
}
]
}
```
Questo è un caso speciale in cui l'identificatore dell'operazione (`lambda:InvokeFunction`) differisce dall'operazione API ([Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)). Per altre operazioni, l'identificatore dell'operazione è il nome dell'operazione preceduto dal prefisso `lambda:`.
**Topics**
+ [
## Informazioni sulla sezione Condizione nelle policy
](#authorization-conditions)
+ [
## Funzioni di riferimento nella sezione Risorse delle policy
](#function-resources)
+ [
## Comportamenti di azioni e funzioni IAM supportati
](#permissions-resources)
## Informazioni sulla sezione Condizione nelle policy
Le condizioni sono un elemento opzionale della policy che applica una logica aggiuntiva per stabilire se è consentita un'operazione. Oltre alle [condizioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) comuni supportate da tutte le operazioni, Lambda definisce i tipi di condizione che è possibile utilizzare per limitare i valori dei parametri aggiuntivi su alcune operazioni.
Ad esempio, la condizione `lambda:Principal` consente di limitare il servizio o un account al quale un utente può concedere l'accesso a una chiamata su una [policy basata sulle risorse](access-control-resource-based.md) della funzione. La policy seguente consente a un utente di concedere l'autorizzazione agli argomenti di Amazon Simple Notification Service (Amazon SNS) per richiamare una funzione denominata `test`.
**Example Gestione delle autorizzazioni di una policy della funzione**
****
```
{
"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"
}
}
}
]
}
```
La condizione richiede che il principale sia Amazon SNS e non un altro servizio o account. Il modello di risorsa richiede che il nome della funzione sia `test` e includa un numero di versione o un alias. Ad esempio, `test:v1`.
Per ulteriori informazioni sulle risorse e le condizioni per Lambda e altri AWS servizi, consulta [Azioni, risorse e chiavi di condizione per AWS i servizi](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html) nel *Service Authorization* Reference.
## Funzioni di riferimento nella sezione Risorse delle policy
Puoi fare riferimento a una funzione Lambda in un rendiconto sulla policy utilizzando un Amazon Resource Name (ARN). Il formato dell'ARN di una funzione dipende dal fatto che si stia facendo riferimento all'intera funzione (non qualificato) o a una [versione](configuration-versions.md) di funzione o a un [alias](configuration-aliases.md) (qualificato).
Quando effettuano chiamate API Lambda, gli utenti possono specificare una versione o un alias passando una versione ARN o un alias ARN nel parametro o impostando un valore [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)`FunctionName`nel parametro. [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)`Qualifier` Lambda prende decisioni di autorizzazione confrontando l'elemento risorsa nella policy IAM con `FunctionName` e `Qualifier` passati nelle chiamate API. Se c'è un errore, Lambda nega la richiesta.
Sia che si stia consentendo o negando un'operazione sulla funzione, è necessario utilizzare i tipi ARN della funzione corretti nell'istruzione di policy per ottenere i risultati previsti. Ad esempio, se la policy fa riferimento all'ARN non qualificato, Lambda accetta le richieste che fanno riferimento all'ARN non qualificato ma nega le richieste che fanno riferimento a un ARN qualificato.
**Nota**
Non puoi utilizzare un carattere jolly (\$1) per la corrispondenza con l'ID account. Per informazioni sulla sintassi accettata, consulta [Documentazione di riferimento sulle policy JSON per IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) nella *Guida per l'utente di IAM*.
**Example permettere la chiamata di un ARN non qualificato**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction"
}
]
}
```
Se la policy fa riferimento a uno specifico ARN qualificato, Lambda accetta le richieste che fanno riferimento a quell'ARN ma nega le richieste che fanno riferimento all'ARN non qualificato o a un ARN qualificato diverso, ad esempio `myFunction:2`.
**Example permettere la chiamata di un ARN qualificato specifico**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:1"
}
]
}
```
Se tua policy fa riferimento a un ARN qualificato utilizzando `:*`, Lambda accetta qualsiasi ARN qualificato ma nega le richieste che fanno riferimento all'ARN non qualificato.
**Example permettere la chiamata di un ARN qualificato**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
}
]
}
```
Se la tua policy fa riferimento a qualsiasi ARN che utilizza `*`, Lambda accetta qualsiasi ARN qualificato o non qualificato.
**Example permettere la chiamata di un ARN qualificato o non qualificato**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:123456789012:function:myFunction*"
}
]
}
```
## Comportamenti di azioni e funzioni IAM supportati
Le azioni definiscono cosa può essere consentito tramite le policy IAM. Per un elenco delle operazioni supportate in Lambda, consulta [Operazioni, risorse e chiavi di condizione per AWS Lambda](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awslambda.html) in Service Authorization Reference. Nella maggior parte dei casi, quando un'azione IAM consente un'operazione API Lambda, il nome dell'azione IAM è lo stesso dell'operazione API Lambda, con le seguenti eccezioni:
| Azione API | Azione IAM |
| --- | --- |
| [Invoke](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 |
Oltre alle risorse e alle condizioni definite in [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html), Lambda supporta le seguenti risorse e condizioni per determinate azioni. Molte di queste sono correlate alle funzioni di riferimento nella sezione delle risorse delle policy. Le operazioni alla base di una funzione possono essere limitate a una funzione specifica in base alla funzione, alla versione o all'ARN dell'alias, come descritto nella tabella riportata di seguito.
| Azione | Risorsa | Condizione |
| --- | --- | --- |
| [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) [https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) `lambda:InvokeFunction` | Versione funzione Alias funzione | 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 funzione | N/D |