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à.
# Sicurezza in AWS Lambda
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di un data center e di un'architettura di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra AWS te e te. Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo come sicurezza *del* cloud e sicurezza *nel* cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che funziona Servizi AWS nel AWS cloud. AWS ti fornisce anche servizi che puoi utilizzare in modo sicuro. I revisori di terze parti testano e verificano regolarmente l'efficacia della sicurezza come parte dei [programmi di conformitàAWS](https://aws.amazon.com/compliance/programs/). Per maggiori informazioni sui programmi di conformità applicabili AWS Lambda, consulta Servizi AWS la sezione [Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicurezza nel cloud**: la responsabilità dell’utente è determinata dal servizio AWS utilizzato. L’utente è anche responsabile di altri fattori, tra cui la riservatezza dei dati, i requisiti della propria azienda e le leggi e normative vigenti.
Questa documentazione consente di comprendere come applicare il modello di responsabilità condivisa quando si usa Lambda. I seguenti argomenti illustrano come configurare Lambda per soddisfare gli obiettivi di sicurezza e conformità. Imparerai anche a usarne altri Servizi AWS che ti aiutano a monitorare e proteggere le tue risorse Lambda.
Per maggiori informazioni sull'applicazione dei principi di sicurezza alle applicazioni Lambda, consulta [Sicurezza](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops) in Serverless Land.
**Topics**
+ [
# Protezione dei dati in AWS Lambda
](security-dataprotection.md)
+ [
# Utilizzo di ruoli collegati ai servizi per Lambda
](using-service-linked-roles.md)
+ [
# Identity and Access Management per AWS Lambda
](security-iam.md)
+ [
# Creare una strategia di governance per le funzioni e i livelli Lambda
](governance-concepts.md)
+ [
# Convalida della conformità per AWS Lambda
](security-compliance.md)
+ [
# Resilienza nell' AWS Lambda
](security-resilience.md)
+ [
# Sicurezza dell'infrastruttura in AWS Lambda
](security-infrastructure.md)
+ [
# Protezione dei carichi di lavoro con endpoint pubblici
](security-public-endpoints.md)
+ [
# Utilizzo della firma del codice per verificare l'integrità del codice con Lambda
](configuration-codesigning.md)
# Protezione dei dati in AWS Lambda
Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) di AWS si applica alla protezione dei dati in AWS Lambda. Come descritto in questo modello, AWSè responsabile della protezione dell'infrastruttura globale che esegue tutto l'Cloud AWS. L’utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. L’utente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i Servizi AWS utilizzati. Per maggiori informazioni sulla privacy dei dati, consultare le [Domande frequenti sulla privacy dei dati](https://aws.amazon.com/compliance/data-privacy-faq/). Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al [Modello di responsabilità condivisa AWSe GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *Blog sulla sicurezza AWS*.
Per garantire la protezione dei dati, ti suggeriamo di proteggere le credenziali Account AWSe di configurare i singoli utenti con AWS IAM Identity Centero AWS Identity and Access Management(IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l’autenticazione a più fattori (MFA) con ogni account.
+ Utilizza SSL/TLS per comunicare con le risorse AWS. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configurare l’API e la registrazione dei log delle attività degli utenti con AWS CloudTrail. Per informazioni sull'utilizzo dei percorsi CloudTrail per acquisire le attività AWS, consulta [Utilizzo dei percorsi CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l'utente di AWS CloudTrail*.
+ Utilizza le soluzioni di crittografia AWS, insieme a tutti i controlli di sicurezza di default all'interno dei Servizi AWS.
+ Utilizzare i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.
+ Se necessiti di moduli crittografici convalidati FIPS 140-3 quando accedi ad AWS attraverso un'interfaccia a riga di comando o un'API, utilizza un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Ti consigliamo di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo **Nome**. Ciò include quando si lavora con Lambda o altri Servizi AWS utilizzando la console, l'API, la AWS CLI o gli SDK AWS. I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando si fornisce un URL a un server esterno, suggeriamo vivamente di non includere informazioni sulle credenziali nell’URL per convalidare la richiesta al server.
**Topics**
+ [
## Crittografia in transito
](#security-privacy-intransit)
+ [
# Crittografia dei dati a riposo per AWS Lambda
](security-encryption-at-rest.md)
## Crittografia in transito
Gli endpoint API di Lambda supportano solo connessioni protette tramite HTTPS. Quando si gestiscono le risorse Lambda attraverso la Console di gestione AWS, l'SDK AWS o l'API Lambda, tutte le comunicazioni sono crittografate con Transport Layer Security (TLS). Per un elenco completo degli endpoint API, consultare [Regioni ed endpoint AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) in Riferimenti generali di AWS.
Quando si [connette la funzione a un file system](configuration-filesystem.md), Lambda utilizza Crittografia in transito per tutte le connessioni. Per ulteriori informazioni, consulta [Crittografia dati in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) nella *Amazon Elastic File System User Guide*.
Quando si utilizzano le [variabili di ambiente](configuration-envvars.md), è possibile abilitare gli helper della crittografia della console per utilizzare il file crittografato lato client per proteggere le variabili di ambiente in transito. Per ulteriori informazioni, consulta [Protezione delle variabili di ambiente Lambda](configuration-envvars-encryption.md).
# Crittografia dei dati a riposo per AWS Lambda
Lambda fornisce sempre la crittografia a riposo per le seguenti risorse utilizzando un [Chiave di proprietà di AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) o un [Chiave gestita da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk):
+ Variabili di ambiente
+ I file che vengono caricati in Lambda, inclusi i pacchetti di implementazione e gli archivi dei livelli
+ Oggetti dei criteri del filtro dello strumento di mappatura dell'origine degli eventi
Facoltativamente, puoi configurare Lambda per utilizzare una chiave gestita dal cliente per crittografare le [variabili di ambiente,](configuration-envvars-encryption.md) [pacchetti di implementazione .zip](encrypt-zip-package.md) e gli [oggetti dei criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption).
Amazon CloudWatch Logs e AWS X-Ray, inoltre, crittografano i dati per impostazione predefinita e possono essere configurati per l'utilizzo di una chiave gestita dal cliente. Per ulteriori informazioni, consulta [Crittografare i dati di log in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) e [Protezione dei dati in AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html).
## Monitoraggio delle chiavi di crittografia per Lambda
Quando utilizzi una chiave gestita dal cliente AWS KMS con Lambda, puoi usare [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Di seguito sono riportati eventi CloudTrail per chiamate `Decrypt`, `DescribeKey` e `GenerateDataKey` effettuate da Lambda per accedere ai dati crittografati dalla chiave gestita dal cliente.
------
#### [ Decrypt ]
Se hai utilizzato una chiave gestita dal cliente AWS KMS per crittografare l'oggetto dei [criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption), Lambda invia una richiesta `Decrypt` per tuo conto quando provi ad accedervi in testo semplice (ad esempio, da una chiamata `ListEventSourceMappings`). L'evento di esempio seguente registra l'operazione `Decrypt`:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
Se hai utilizzato una chiave gestita dal cliente AWS KMS per crittografare l'oggetto dei [criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption), Lambda invia una richiesta `DescribeKey` per tuo conto quando provi ad accedervi (ad esempio, da una chiamata `GetEventSourceMapping`). L'evento di esempio seguente registra l'operazione `DescribeKey`:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
Quando utilizzi una chiave gestita dal cliente AWS KMS per crittografare l'oggetto dei [criteri di filtro](invocation-eventfiltering.md#filter-criteria-encryption) in una chiamata `CreateEventSourceMapping` o `UpdateEventSourceMapping`, Lambda invia una richiesta `GenerateDataKey` per tuo conto per generare una chiave di dati per crittografare i criteri di filtro ([crittografia a busta](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). L'evento di esempio seguente registra l'operazione `GenerateDataKey`:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# Utilizzo di ruoli collegati ai servizi per Lambda
Lambda utilizza ruoli collegati ai [servizi AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un ruolo collegato ai servizi è un tipo unico di ruolo IAM collegato direttamente a Lambda. I ruoli collegati ai servizi sono predefiniti da Lambda e includono le autorizzazioni richieste dal servizio per chiamare altri servizi per tuo conto. AWS
Lambda definisce le autorizzazioni dei suoi ruoli collegati ai servizi e solo Lambda può assumerne i ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni che non può essere allegata a nessun’altra entità IAM.
È possibile eliminare un ruolo collegato al servizio solo dopo avere eliminato le risorse correlate. Questo protegge le tue risorse Lambda perché non puoi rimuovere inavvertitamente l'autorizzazione ad accedere alle risorse.
**Per informazioni su altri servizi che supportano i ruoli collegati ai servizi, consulta i [AWS servizi che funzionano con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cerca i servizi con **Sì** nella colonna Ruoli collegati ai servizi.** Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato al servizio per tale servizio.
## Autorizzazioni di ruolo collegate ai servizi per Lambda
Lambda utilizza il ruolo collegato al servizio denominato. **AWSServiceRoleForLambda** Ai fini dell’assunzione del ruolo, il ruolo collegato al servizio considera attendibili i seguenti servizi:
+ `lambda.amazonaws.com`
La politica di autorizzazione dei ruoli denominata AWSLambda ServiceRolePolicy consente a Lambda di completare le seguenti azioni sulle risorse specificate:
+ Azione: `ec2:TerminateInstances` attiva `arn:aws:ec2:*:*:instance/*` con la condizione che è uguale `ec2:ManagedResourceOperator` `scaler.lambda.amazonaws.com`
+ Azione: `ec2:DescribeInstanceStatus` e `ec2:DescribeInstances` su `*`
Per consentire a utenti, gruppi o ruoli di creare, modificare o eliminare un ruolo orientato ai servizi, devi configurare le autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente IAM*.
Per gli aggiornamenti delle policy gestite, consulta Politiche [gestite da Lambda](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates).
## Creazione di un ruolo collegato ai servizi per Lambda
Non hai bisogno di creare manualmente un ruolo collegato ai servizi. Quando crei un provider di capacità Lambda nella Console di gestione AWS, o nell' AWS API AWS CLI, Lambda crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato al servizio, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell’account. Quando crei un provider di capacità Lambda, Lambda crea nuovamente il ruolo collegato ai servizi per te.
Puoi anche utilizzare la console IAM per creare un ruolo collegato al servizio con lo use case. **AWSServiceRoleForLambda** Nella AWS CLI o nell' AWS API, crea un ruolo collegato al servizio con il nome del servizio. `lambda.amazonaws.com` Per ulteriori informazioni, consulta [Creazione di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) nella *Guida per l’utente IAM*. Se elimini il ruolo collegato ai servizi, è possibile utilizzare lo stesso processo per crearlo nuovamente.
## Modifica di un ruolo collegato al servizio per Lambda
Lambda non consente di modificare il ruolo collegato al AWSService RoleForLambda servizio. Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta [Modifica di un ruolo collegato al servizio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l’utente di IAM*.
## Eliminazione di un ruolo collegato al servizio per Lambda
Se non è più necessario utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare il ruolo. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato al servizio prima di poterlo eliminare manualmente.
**Nota**
Se il servizio Lambda utilizza il ruolo quando si tenta di eliminare le risorse, l'eliminazione potrebbe non riuscire. In questo caso, attendi alcuni minuti e quindi ripeti l’operazione.
**Per eliminare le risorse Lambda utilizzate da AWSService RoleForLambda**
1. Rimuovi tutti i provider di capacità Lambda dal tuo account. Puoi farlo utilizzando la console Lambda, la CLI o l'API.
1. Verifica che nessun provider di capacità Lambda rimanga nel tuo account prima di tentare di eliminare il ruolo collegato al servizio.
**Per eliminare manualmente il ruolo collegato ai servizi mediante IAM**
Utilizza la console IAM AWS CLI, l'o l' AWS API per eliminare il ruolo collegato al servizio. AWSService RoleForLambda Per ulteriori informazioni, consulta [Eliminazione del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) nella *Guida per l'utente IAM*.
## Regioni supportate per i ruoli collegati ai servizi Lambda
Lambda non supporta l'utilizzo di ruoli collegati ai servizi in tutte le regioni in cui il servizio è disponibile. AWSServiceRoleForLambda è supportato nelle seguenti regioni.
| Nome della Regione | Identità della Regione | Support in Lambda |
| --- | --- | --- |
| Stati Uniti orientali (Virginia settentrionale) | us-east-1 | Sì |
| Stati Uniti orientali (Ohio) | us-east-2 | Sì |
| Stati Uniti occidentali (California settentrionale) | us-west-1 | Sì |
| Stati Uniti occidentali (Oregon) | us-west-2 | Sì |
| Africa (Città del Capo) | af-south-1 | No |
| Asia Pacific (Hong Kong) | ap-east-1 | Sì |
| Asia Pacifico (Giacarta) | ap-southeast-3 | Sì |
| Asia Pacifico (Bangkok) | ap-southeast-7 | Sì |
| Asia Pacifico (Mumbai) | ap-south-1 | Sì |
| Asia Pacifico (Osaka) | ap-northeast-3 | No |
| Asia Pacific (Seoul) | ap-northeast-2 | No |
| Asia Pacifico (Singapore) | ap-southeast-1 | Sì |
| Asia Pacifico (Sydney) | ap-southeast-2 | Sì |
| Asia Pacifico (Tokyo) | ap-northeast-1 | Sì |
| Canada (Centrale) | ca-central-1 | No |
| Europa (Francoforte) | eu-central-1 | Sì |
| Europa (Irlanda) | eu-west-1 | Sì |
| Europa (Londra) | eu-west-2 | Sì |
| Europe (Milan) | eu-south-1 | No |
| Europa (Parigi) | eu-west-3 | No |
| Europa (Stoccolma) | eu-north-1 | No |
| Medio Oriente (Bahrein) | me-south-1 | No |
| Medio Oriente (Emirati Arabi Uniti) | me-central-1 | No |
| Sud America (San Paolo) | sa-east-1 | No |
| AWS GovCloud (Stati Uniti orientali) | us-gov-east-1 | No |
| AWS GovCloud (Stati Uniti occidentali) | us-gov-west-1 | No |
# Identity and Access Management per AWS Lambda
AWS Identity and Access Management (IAM) è uno strumento Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle AWS risorse. Gli amministratori IAM controllano chi può essere *autenticato* (connesso) e *autorizzato* (avere le autorizzazioni) a utilizzare le risorse Lambda. IAM è un software Servizio AWS che puoi utilizzare senza costi aggiuntivi.
**Topics**
+ [
## Destinatari
](#security_iam_audience)
+ [
## Autenticazione con identità
](#security_iam_authentication)
+ [
## Gestione dell’accesso tramite policy
](#security_iam_access-manage)
+ [
# Come AWS Lambda funziona con IAM
](security_iam_service-with-iam.md)
+ [
# Esempi di policy basate sull'identità per AWS Lambda
](security_iam_id-based-policy-examples.md)
+ [
# AWS politiche gestite per AWS Lambda
](security-iam-awsmanpol.md)
+ [
# Risoluzione dei problemi AWS Lambda di identità e accesso
](security_iam_troubleshoot.md)
## Destinatari
Il modo in cui utilizzi AWS Identity and Access Management (IAM) varia in base al tuo ruolo:
+ **Utente del servizio**: richiedi le autorizzazioni all’amministratore se non riesci ad accedere alle funzionalità (consulta [Risoluzione dei problemi AWS Lambda di identità e accesso](security_iam_troubleshoot.md))
+ **Amministratore del servizio**: determina l’accesso degli utenti e invia le richieste di autorizzazione (consulta [Come AWS Lambda funziona con IAM](security_iam_service-with-iam.md))
+ **Amministratore IAM**: scrivi policy per gestire l’accesso (consulta [Esempi di policy basate sull'identità per AWS Lambda](security_iam_id-based-policy-examples.md))
## Autenticazione con identità
L'autenticazione è il modo in cui accedi AWS utilizzando le tue credenziali di identità. Devi autenticarti come utente IAM o assumendo un ruolo IAM. Utente root dell'account AWS
Puoi accedere come identità federata utilizzando credenziali provenienti da una fonte di identità come AWS IAM Identity Center (IAM Identity Center), autenticazione Single Sign-On o credenziali. Google/Facebook Per ulteriori informazioni sull’accesso, consulta [Come accedere all’ Account AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) nella *Guida per l’utente di Accedi ad AWS *.
Per l'accesso programmatico, AWS fornisce un SDK e una CLI per firmare crittograficamente le richieste. Per ulteriori informazioni, consulta [AWS Signature Version 4 per le richieste API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) nella *Guida per l’utente di IAM*.
### Account AWS utente root
Quando si crea un Account AWS, si inizia con un'identità di accesso denominata *utente Account AWS root* che ha accesso completo a tutte Servizi AWS le risorse. Consigliamo vivamente di non utilizzare l’utente root per le attività quotidiane. Per le attività che richiedono le credenziali dell’utente root, consulta [Attività che richiedono le credenziali dell’utente root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) nella *Guida per l’utente IAM*.
### Identità federata
Come procedura ottimale, richiedi agli utenti umani di utilizzare la federazione con un provider di identità per accedere Servizi AWS utilizzando credenziali temporanee.
Un'*identità federata* è un utente della directory aziendale, del provider di identità Web o Directory Service che accede Servizi AWS utilizzando le credenziali di una fonte di identità. Le identità federate assumono ruoli che forniscono credenziali temporanee.
Per la gestione centralizzata degli accessi, si consiglia di utilizzare AWS IAM Identity Center. Per ulteriori informazioni, consulta [Che cos’è il Centro identità IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) nella *Guida per l’utente di AWS IAM Identity Center *.
### Utenti e gruppi IAM
Un *[utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* è una identità che dispone di autorizzazioni specifiche per una singola persona o applicazione. Ti consigliamo di utilizzare credenziali temporanee invece di utenti IAM con credenziali a lungo termine. *Per ulteriori informazioni, consulta [Richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) nella Guida per l'utente IAM.*
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifica una raccolta di utenti IAM e semplifica la gestione delle autorizzazioni per gestire gruppi di utenti di grandi dimensioni. Per ulteriori informazioni, consulta [Casi d’uso per utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) nella *Guida per l’utente di IAM*.
### Ruoli IAM
Un *[ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* è un’identità con autorizzazioni specifiche che fornisce credenziali temporanee. Puoi assumere un ruolo [passando da un ruolo utente a un ruolo IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o chiamando un'operazione AWS CLI o AWS API. Per ulteriori informazioni, consulta [Metodi per assumere un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) nella *Guida per l’utente di IAM*.
I ruoli IAM sono utili per l’accesso degli utenti federati, le autorizzazioni utente IAM temporanee, l’accesso multi-account, l’accesso multi-servizio e le applicazioni in esecuzione su Amazon EC2. Per maggiori informazioni, consultare [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
## Gestione dell’accesso tramite policy
Puoi controllare l'accesso AWS creando policy e associandole a AWS identità o risorse. Una policy definisce le autorizzazioni quando è associata a un'identità o a una risorsa. AWS valuta queste politiche quando un preside effettua una richiesta. La maggior parte delle politiche viene archiviata AWS come documenti JSON. Per maggiori informazioni sui documenti delle policy JSON, consulta [Panoramica delle policy JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) nella *Guida per l’utente IAM*.
Utilizzando le policy, gli amministratori specificano chi ha accesso a cosa definendo quale **principale** può eseguire **azioni** su quali **risorse** e in quali **condizioni**.
Per impostazione predefinita, utenti e ruoli non dispongono di autorizzazioni. Un amministratore IAM crea le policy IAM e le aggiunge ai ruoli, che gli utenti possono quindi assumere. Le policy IAM definiscono le autorizzazioni indipendentemente dal metodo utilizzato per eseguirle.
### Policy basate sull’identità
Le policy basate su identità sono documenti di policy di autorizzazione JSON che è possibile collegare a un’identità (utente, gruppo o ruolo). Tali policy controllano le operazioni autorizzate per l’identità, nonché le risorse e le condizioni in cui possono essere eseguite. Per informazioni su come creare una policy basata su identità, consultare [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente IAM*.
Le policy basate su identità possono essere *policy in linea* (con embedding direttamente in una singola identità) o *policy gestite* (policy autonome collegate a più identità). Per informazioni su come scegliere tra una policy gestita o una policy inline, consulta [Scegliere tra policy gestite e policy in linea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) nella *Guida per l’utente di IAM*.
### Policy basate sulle risorse
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Gli esempi includono le *policy di trust dei ruoli* IAM e le *policy dei bucket* di Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
Le policy basate sulle risorse sono policy inline che si trovano in tale servizio. Non è possibile utilizzare le policy AWS gestite di IAM in una policy basata sulle risorse.
### Altri tipi di policy
AWS supporta tipi di policy aggiuntivi che possono impostare le autorizzazioni massime concesse dai tipi di policy più comuni:
+ **Limiti delle autorizzazioni**: imposta il numero massimo di autorizzazioni che una policy basata su identità ha la possibilità di concedere a un’entità IAM. Per ulteriori informazioni, consulta [Limiti delle autorizzazioni per le entità IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) nella *Guida per l’utente di IAM*.
+ **Politiche di controllo del servizio (SCPs)**: specificano le autorizzazioni massime per un'organizzazione o un'unità organizzativa in. AWS Organizations Per ulteriori informazioni, consultare [Policy di controllo dei servizi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) nella *Guida per l’utente di AWS Organizations *.
+ **Politiche di controllo delle risorse (RCPs)**: imposta le autorizzazioni massime disponibili per le risorse nei tuoi account. Per ulteriori informazioni, consulta [Politiche di controllo delle risorse (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) nella *Guida per l'AWS Organizations utente*.
+ **Policy di sessione**: policy avanzate passate come parametro quando si crea una sessione temporanea per un ruolo o un utente federato. Per maggiori informazioni, consultare [Policy di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) nella *Guida per l’utente IAM*.
### Più tipi di policy
Quando a una richiesta si applicano più tipi di policy, le autorizzazioni risultanti sono più complicate da comprendere. Per scoprire come si AWS determina se consentire o meno una richiesta quando sono coinvolti più tipi di policy, consulta [Logica di valutazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) nella *IAM User Guide*.
# Come AWS Lambda funziona con IAM
Prima di utilizzare IAM per gestire l'accesso a Lambda, scopri quali funzionalità di IAM sono disponibili per l'uso con .
| Funzionalità IAM | Supporto Lambda |
| --- | --- |
| [Policy basate sull’identità](#security_iam_service-with-iam-id-based-policies) | Sì |
| [Policy basate su risorse](#security_iam_service-with-iam-resource-based-policies) | Sì |
| [Operazioni di policy](#security_iam_service-with-iam-id-based-policies-actions) | Sì |
| [Risorse relative alle policy](#security_iam_service-with-iam-id-based-policies-resources) | Sì |
| [Chiavi di condizione della policy (specifica del servizio)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sì |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [ABAC (tag nelle policy)](#security_iam_service-with-iam-tags) | Parziale |
| [Credenziali temporanee](#security_iam_service-with-iam-roles-tempcreds) | Sì |
| [Inoltro delle sessioni di accesso (FAS)](#security_iam_service-with-iam-principal-permissions) | No |
| [Ruoli di servizio](#security_iam_service-with-iam-roles-service) | Sì |
| [Ruoli collegati al servizio](#security_iam_service-with-iam-roles-service-linked) | Parziale |
Per avere una visione di alto livello di come Lambda e AWS altri servizi funzionano con la maggior parte delle funzionalità IAM, [AWS consulta i servizi che funzionano con](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM nella IAM User *Guide*.
## Policy basate sulle identità per Lambda
**Supporta le policy basate sull’identità:** sì
Le policy basate sull'identità sono documenti di policy di autorizzazione JSON che è possibile allegare a un'identità (utente, gruppo di utenti o ruolo IAM). Tali policy definiscono le operazioni che utenti e ruoli possono eseguire, su quali risorse e in quali condizioni. Per informazioni su come creare una policy basata su identità, consulta [Definizione di autorizzazioni personalizzate IAM con policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) nella *Guida per l’utente di IAM*.
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Per informazioni su tutti gli elementi utilizzabili in una policy JSON, consulta [Guida di riferimento agli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l’utente IAM*.
### Esempi di policy basate su identità per Lambda
Per visualizzare esempi di policy basate su identità Lambda, consulta [Esempi di policy basate sull'identità per AWS Lambda](security_iam_id-based-policy-examples.md).
## Policy basate sulle risorse all'interno di Lambda
**Supporta le policy basate sulle risorse**: sì
Le policy basate su risorse sono documenti di policy JSON che è possibile collegare a una risorsa. Esempi di policy basate sulle risorse sono le *policy di attendibilità dei ruoli* IAM e le *policy di bucket* Amazon S3. Nei servizi che supportano policy basate sulle risorse, gli amministratori dei servizi possono utilizzarli per controllare l’accesso a una risorsa specifica. Quando è collegata a una risorsa, una policy definisce le operazioni che un principale può eseguire su tale risorsa e a quali condizioni. In una policy basata sulle risorse è obbligatorio [specificare un’entità principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). I principali possono includere account, utenti, ruoli, utenti federati o. Servizi AWS
Per consentire l’accesso multi-account, è possibile specificare un intero account o entità IAM in un altro account come entità principale in una policy basata sulle risorse. Per ulteriori informazioni, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
È possibile associare una policy basata su risorse a una funzione o a un livello Lambda. Questa policy definisce quali principali possono eseguire azioni sulla funzione o il livello.
Per informazioni su come collegare una policy basata su risorse a una funzione o un livello, consulta [Visualizzazione delle policy IAM basate sulle risorse in Lambda](access-control-resource-based.md).
## Operazioni di policy per Lambda
**Supporta le operazioni di policy:** si
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Includere le operazioni in una policy per concedere le autorizzazioni a eseguire l’operazione associata.
Per visualizzare un elenco di operazioni Lambda, consulta [Operazioni definite da AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) nella *Service Authorization Reference*.
Le operazioni delle policy in Lambda utilizzano il seguente prefisso prima dell'operazione:
```
lambda
```
Per specificare più operazioni in una sola istruzione, occorre separarle con la virgola.
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Per visualizzare esempi di policy basate su identità Lambda, consulta [Esempi di policy basate sull'identità per AWS Lambda](security_iam_id-based-policy-examples.md).
## Risorse di policy per Lambda
**Supporta le risorse relative alle policy:** sì
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Per le azioni che non supportano le autorizzazioni a livello di risorsa, si utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
Per visualizzare un elenco dei tipi di risorse Lambda e relativi ARNs, consulta Tipi di [risorse definiti da AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) nel *Service Authorization* Reference. Per informazioni sulle operazioni con cui è possibile specificare l'ARN di ogni risorsa, consulta la sezione [Operazioni definite da AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Per visualizzare esempi di policy basate su identità Lambda, consulta [Esempi di policy basate sull'identità per AWS Lambda](security_iam_id-based-policy-examples.md).
## Chiavi di condizione delle policy per Lambda
**Supporta le chiavi di condizione delle policy specifiche del servizio:** sì
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento `Condition` specifica quando le istruzioni vengono eseguite in base a criteri definiti. È possibile compilare espressioni condizionali che utilizzano [operatori di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), ad esempio uguale a o minore di, per soddisfare la condizione nella policy con i valori nella richiesta. Per visualizzare tutte le chiavi di condizione AWS globali, consulta le chiavi di [contesto delle condizioni AWS globali nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per l'*utente IAM*.
Per visualizzare un elenco di chiavi di condizione Lambda, consulta [Chiavi di condizione per AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) in *Service Authorization Reference*. Per sapere con quali azioni e risorse puoi utilizzare una chiave di condizione, consulta [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Per visualizzare esempi di policy basate su identità Lambda, consulta [Esempi di policy basate sull'identità per AWS Lambda](security_iam_id-based-policy-examples.md).
## ACLs a Lambda
**Supporti ACLs: no**
Le liste di controllo degli accessi (ACLs) controllano quali principali (membri dell'account, utenti o ruoli) dispongono delle autorizzazioni per accedere a una risorsa. ACLs sono simili alle politiche basate sulle risorse, sebbene non utilizzino il formato del documento di policy JSON.
## ABAC con Lambda
**Supporta ABAC (tag nelle policy):** parzialmente
Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi, chiamati tag. È possibile allegare tag a entità e AWS risorse IAM, quindi progettare politiche ABAC per consentire operazioni quando il tag del principale corrisponde al tag sulla risorsa.
Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Se un servizio supporta tutte e tre le chiavi di condizione per ogni tipo di risorsa, il valore per il servizio è **Sì**. Se un servizio supporta tutte e tre le chiavi di condizione solo per alcuni tipi di risorsa, allora il valore sarà **Parziale**.
Per maggiori informazioni su ABAC, consulta [Definizione delle autorizzazioni con autorizzazione ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) nella *Guida per l’utente di IAM*. Per visualizzare un tutorial con i passaggi per l’impostazione di ABAC, consulta [Utilizzo del controllo degli accessi basato su attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) nella *Guida per l’utente di IAM*.
Per ulteriori informazioni sul tagging delle risorse Lambda, consulta [Utilizzo del controllo degli accessi basato sugli attributi in Lambda](attribute-based-access-control.md).
## Utilizzo di credenziali temporanee con Lambda
**Supporta le credenziali temporanee:** sì
Le credenziali temporanee forniscono l'accesso a breve termine alle AWS risorse e vengono create automaticamente quando si utilizza la federazione o si cambia ruolo. AWS consiglia di generare dinamicamente credenziali temporanee anziché utilizzare chiavi di accesso a lungo termine. Per ulteriori informazioni, consulta [Credenziali di sicurezza temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Servizi AWS compatibili con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) nella *Guida per l’utente IAM*.
## Inoltro delle sessioni di accesso per Lambda
**Supporta l'inoltro delle sessioni di accesso (FAS):** no
Le sessioni di accesso inoltrato (FAS) utilizzano le autorizzazioni del principale che chiama e, in combinazione con la richiesta Servizio AWS, Servizio AWS per effettuare richieste ai servizi downstream. Per i dettagli delle policy relative alle richieste FAS, consulta [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Ruoli di servizio per Lambda
**Supporta i ruoli di servizio:** sì
Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta [Create a role to delegate permissions to an Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente IAM*.
In Lambda, un ruolo di servizio è noto come [ruolo di esecuzione](lambda-intro-execution-role.md).
**avvertimento**
La modifica delle autorizzazioni per un ruolo di servizio potrebbe compromettere la funzionalità di Lambda.
## Ruoli collegati ai servizi per Lambda
**Supporta i ruoli legati ai servizi:** Parziale
Un ruolo collegato al servizio è un tipo di ruolo di servizio collegato a un. Servizio AWS Il servizio può assumere il ruolo per eseguire un’operazione per tuo conto. I ruoli collegati al servizio vengono visualizzati nel tuo account Account AWS e sono di proprietà del servizio. Un amministratore IAM può visualizzare le autorizzazioni per i ruoli collegati al servizio, ma non modificarle.
Lambda non dispone di ruoli collegati al servizio, a differenza di Lambda@Edge. *Per ulteriori informazioni, consulta [Service-Linked Roles for Lambda @Edge nella](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) Amazon Developer Guide. CloudFront *
Per ulteriori informazioni su come creare e gestire i ruoli collegati ai servizi, consulta [Servizi AWS supportati da IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Trova un servizio nella tabella che include un `Yes` nella colonna **Service-linked role (Ruolo collegato ai servizi)**. Scegli il collegamento **Sì** per visualizzare la documentazione relativa al ruolo collegato ai servizi per tale servizio.
# Esempi di policy basate sull'identità per AWS Lambda
Per impostazione predefinita, gli utenti e i ruoli non sono autorizzati a creare o modificare le risorse Lambda. Per concedere agli utenti l’autorizzazione a eseguire azioni sulle risorse di cui hanno bisogno, un amministratore IAM può creare policy IAM.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consulta [Creazione di policy IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) nella *Guida per l’utente di IAM*.
Per informazioni dettagliate sulle azioni e sui tipi di risorse definiti da Lambda, incluso il formato di ARNs per ogni tipo di risorsa, consulta [Azioni, risorse e chiavi di condizione AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) nel *Service Authorization* Reference.
**Topics**
+ [
## Best practice per le policy
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Uso della console Lambda
](#security_iam_id-based-policy-examples-console)
+ [
## Consentire agli utenti di visualizzare le loro autorizzazioni
](#security_iam_id-based-policy-examples-view-own-permissions)
## Best practice per le policy
Le policy basate su identità determinano se qualcuno può creare, accedere o eliminare risorse Lambda nel tuo account. Queste azioni possono comportare costi aggiuntivi per l’ Account AWS. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** a utenti e carichi di lavoro, utilizza le *policy AWS gestite* che concedono le autorizzazioni per molti casi d'uso comuni. Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. Lo strumento di analisi degli accessi IAM offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per maggiori informazioni, consultare [Convalida delle policy per il Sistema di analisi degli accessi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l’utente di IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungere le condizioni MFA alle policy. Per maggiori informazioni, consultare [Protezione dell’accesso API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l’utente di IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l’utente di IAM*.
## Uso della console Lambda
Per accedere alla AWS Lambda console, devi disporre di un set minimo di autorizzazioni. Queste autorizzazioni devono consentirti di elencare e visualizzare i dettagli sulle risorse Lambda presenti nel tuo. Account AWS Se crei una policy basata sull’identità più restrittiva rispetto alle autorizzazioni minime richieste, la console non funzionerà nel modo previsto per le entità (utenti o ruoli) associate a tale policy.
Non è necessario consentire autorizzazioni minime per la console per gli utenti che effettuano chiamate solo verso AWS CLI o l'API. AWS Al contrario, è opportuno concedere l’accesso solo alle azioni che corrispondono all’operazione API che stanno cercando di eseguire.
Per una policy di esempio che consente l'accesso minimo per lo sviluppo di funzioni, vedere [Concedere agli utenti l'accesso a una funzione Lambda](permissions-user-function.md). Oltre a Lambda APIs, la console Lambda utilizza altri servizi per visualizzare la configurazione dei trigger e consentire di aggiungere nuovi trigger. Se gli utenti utilizzano Lambda con altri servizi, devono anche accedere a tali servizi. Per informazioni dettagliate sulla configurazione di altri servizi con Lambda, consultare [Richiamare Lambda con eventi di altri servizi AWS](lambda-services.md).
## Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa politica include le autorizzazioni per completare questa azione sulla console o utilizzando l'API o a livello di codice. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS politiche gestite per AWS Lambda
Una policy AWS gestita è una policy autonoma creata e amministrata da. AWS AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando ne Servizio AWS viene lanciata una nuova o quando diventano disponibili nuove operazioni API per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
**Topics**
+ [
## AWS politica gestita: AWSLambda\$1FullAccess
](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [
## AWS politica gestita: AWSLambda\$1ReadOnlyAccess
](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [
## AWS politica gestita: AWSLambda BasicExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [
## AWS politica gestita: AWSLambda BasicDurableExecutionRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [
## AWS politica gestita: Dynamo Role AWSLambda DBExecution
](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [
## AWS politica gestita: accesso AWSLambda ENIManagement
](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [
## AWS politica gestita: AWSLambdaInvocation-DynamoDB
](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [
## AWS politica gestita: AWSLambda KinesisExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [
## AWS politica gestita: ruolo AWSLambda MSKExecution
](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [
## AWS politica gestita: ruolo AWSLambda
](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [
## AWS politica gestita: AWSLambda SQSQueue ExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [
## AWS politica gestita: AWSLambda VPCAccess ExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [
## AWS politica gestita: AWSLambda gestita EC2 ResourceOperator
](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [
## AWS politica gestita: AWSLambda ServiceRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [
## Aggiornamenti Lambda alle AWS politiche gestite
](#lambda-security-iam-awsmanpol-updates)
## AWS politica gestita: AWSLambda\$1FullAccess
Questa policy concede l'accesso completo a tutte le operazioni di Lambda. Concede inoltre le autorizzazioni ad altri AWS servizi utilizzati per sviluppare e gestire le risorse Lambda.
Puoi associare la policy `AWSLambda_FullAccess` ai tuoi utenti, gruppi e ruoli.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `lambda`: consente ai principali l'accesso completo a Lambda.
+ `cloudformation`— Consente ai responsabili di descrivere gli AWS CloudFormation stack ed elencare le risorse in essi contenuti.
+ `cloudwatch`— Consente ai responsabili di elencare i CloudWatch parametri di Amazon e ottenere dati sui parametri.
+ `ec2`— Consente ai responsabili di descrivere gruppi di sicurezza, sottoreti e. VPCs
+ `iam`: consente ai principali di ottenere policy, versioni delle policy, ruoli, policy dei ruoli, policy di ruolo allegate e l'elenco dei ruoli. Questa policy consente inoltre ai principali di trasferire ruoli a Lambda. L'autorizzazione `PassRole` è necessaria quando si assegna un ruolo di esecuzione a una funzione. L'`CreateServiceLinkedRole`autorizzazione viene utilizzata durante la creazione di un ruolo collegato al servizio.
+ `kms`— Consente ai responsabili di elencare gli alias e descrivere la chiave per la crittografia dei volumi.
+ `logs`— Consente ai responsabili di descrivere i flussi di log, ottenere eventi di registro, filtrare gli eventi di registro e avviare e interrompere le sessioni di Live Tail.
+ `states`— Consente ai responsabili di descrivere ed AWS Step Functions elencare le macchine a stati.
+ `tag`: consente ai principali di ottenere risorse in base ai loro tag.
+ `xray`— Consente ai responsabili di ottenere riepiloghi delle AWS X-Ray tracce e recuperare un elenco di tracce specificato dall'ID.
Per ulteriori informazioni su questa politica, inclusi il documento sulla policy JSON e le versioni delle policy, consulta la *AWS Managed* Policy [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)Reference Guide.
## AWS politica gestita: AWSLambda\$1ReadOnlyAccess
Questa policy garantisce l'accesso in sola lettura alle risorse Lambda e ad altri AWS servizi utilizzati per sviluppare e gestire le risorse Lambda.
Puoi associare la policy `AWSLambda_ReadOnlyAccess` ai tuoi utenti, gruppi e ruoli.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `lambda`: consente ai principali di ottenere ed elencare tutte le risorse.
+ `cloudformation`— Consente ai responsabili di descrivere ed elencare gli AWS CloudFormation stack e di elencare le risorse in essi contenuti.
+ `cloudwatch`— Consente ai responsabili di elencare i CloudWatch parametri di Amazon e ottenere dati sui parametri.
+ `ec2`— Consente ai responsabili di descrivere gruppi di sicurezza, sottoreti e. VPCs
+ `iam`: consente ai principali di ottenere policy, versioni delle policy, ruoli, policy dei ruoli, policy di ruolo allegate e l'elenco dei ruoli.
+ `kms`: consente ai principali di elencare gli alias.
+ `logs`— Consente ai responsabili di descrivere i flussi di registro, ottenere eventi di registro, filtrare gli eventi di registro e avviare e interrompere le sessioni di Live Tail.
+ `states`— Consente ai responsabili di descrivere ed AWS Step Functions elencare le macchine a stati.
+ `tag`: consente ai principali di ottenere risorse in base ai loro tag.
+ `xray`— Consente ai responsabili di ottenere riepiloghi delle AWS X-Ray tracce e recuperare un elenco di tracce specificato dall'ID.
Per ulteriori informazioni su questa politica, inclusi il documento sulla policy JSON e le versioni delle policy, consulta la *AWS Managed* Policy [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)Reference Guide.
## AWS politica gestita: AWSLambda BasicExecutionRole
Questa politica concede le autorizzazioni per caricare i log in Logs. CloudWatch
Puoi associare la policy `AWSLambdaBasicExecutionRole` ai tuoi utenti, gruppi e ruoli.
*Per ulteriori informazioni su questa politica, inclusi il documento sulla policy JSON e le versioni delle politiche, consulta la Managed Policy Reference [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)Guide.AWS *
## AWS politica gestita: AWSLambda BasicDurableExecutionRolePolicy
Questa policy fornisce autorizzazioni di scrittura per CloudWatch i log e read/write autorizzazioni per l'esecuzione durevole utilizzate dalle funzioni durevoli APIs di Lambda. Questa policy fornisce le autorizzazioni essenziali richieste per le funzioni durevoli Lambda, che utilizzano un' APIs esecuzione duratura per mantenere l'avanzamento e mantenere lo stato tra le chiamate di funzione.
Puoi associare la policy `AWSLambdaBasicDurableExecutionRolePolicy` ai tuoi utenti, gruppi e ruoli.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `logs`— Consente ai responsabili di creare gruppi di log e flussi di log e di scrivere eventi di log in Logs. CloudWatch
+ `lambda`— Consente ai responsabili di controllare lo stato di esecuzione durevole e recuperare lo stato di esecuzione durevole per le funzioni durevoli Lambda.
Per visualizzare ulteriori dettagli sulla policy, inclusa la versione più recente del documento di policy JSON, consulta [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) nella *Guida di riferimento alle policy gestite da AWS *.
## AWS politica gestita: Dynamo Role AWSLambda DBExecution
Questa policy concede le autorizzazioni per leggere i record da uno stream Amazon DynamoDB e scrivere su Logs. CloudWatch
Puoi associare la policy `AWSLambdaDynamoDBExecutionRole` ai tuoi utenti, gruppi e ruoli.
*Per ulteriori informazioni su questa politica, inclusi il documento e le versioni della policy JSON, consulta [AWSLambdaDynamo DBExecution](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) Role nella Managed Policy Reference Guide.AWS *
## AWS politica gestita: accesso AWSLambda ENIManagement
Questa policy concede le autorizzazioni per creare, descrivere ed eliminare interfacce di rete elastiche utilizzate da una funzione Lambda abilitata per VPC.
Puoi associare la policy `AWSLambdaENIManagementAccess` ai tuoi utenti, gruppi e ruoli.
Per ulteriori informazioni su questa politica, inclusi il documento sulla policy JSON e le versioni delle policy, consulta [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: AWSLambdaInvocation-DynamoDB
Questa policy concede l'accesso in lettura ai flussi Amazon DynamoDB.
Puoi associare la policy `AWSLambdaInvocation-DynamoDB` ai tuoi utenti, gruppi e ruoli.
Per ulteriori informazioni su questa politica, inclusi il documento sulla policy JSON e le versioni delle policy, consulta [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)la *AWS Managed Policy Reference Guide*.
## AWS politica gestita: AWSLambda KinesisExecutionRole
Questa policy concede le autorizzazioni per leggere gli eventi da un flusso di dati di Amazon Kinesis e scriverli nei log. CloudWatch
Puoi associare la policy `AWSLambdaKinesisExecutionRole` ai tuoi utenti, gruppi e ruoli.
*Per ulteriori informazioni su questa politica, incluso il documento e le versioni della policy JSON, consulta la Managed Policy Reference [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)Guide.AWS *
## AWS politica gestita: ruolo AWSLambda MSKExecution
Questa policy concede le autorizzazioni per leggere e accedere ai record da un cluster Amazon Managed Streaming for Apache Kafka, gestire interfacce di rete elastiche e scrivere su Logs. CloudWatch
Puoi associare la policy `AWSLambdaMSKExecutionRole` ai tuoi utenti, gruppi e ruoli.
[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)
## AWS politica gestita: ruolo AWSLambda
Questa policy concede le autorizzazioni per invocare le funzioni Lambda.
Puoi associare la policy `AWSLambdaRole` ai tuoi utenti, gruppi e ruoli.
Per ulteriori informazioni su questa politica, inclusi il documento sulla policy JSON e le versioni della policy, consulta [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) nella *AWS Managed Policy Reference Guide*.
## AWS politica gestita: AWSLambda SQSQueue ExecutionRole
Questa politica concede le autorizzazioni per leggere ed eliminare i messaggi da una coda di Amazon Simple Queue Service e concede le autorizzazioni di scrittura ai log. CloudWatch
Puoi associare la policy `AWSLambdaSQSQueueExecutionRole` ai tuoi utenti, gruppi e ruoli.
*Per ulteriori informazioni su questa politica, inclusi il documento e le versioni della policy JSON, consulta la Managed Policy Reference Guide. [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)AWS *
## AWS politica gestita: AWSLambda VPCAccess ExecutionRole
Questa politica concede le autorizzazioni per gestire interfacce di rete elastiche all'interno di un Amazon Virtual Private Cloud e scrivere su Logs. CloudWatch
Puoi associare la policy `AWSLambdaVPCAccessExecutionRole` ai tuoi utenti, gruppi e ruoli.
*Per ulteriori informazioni su questa politica, inclusi il documento e le versioni della policy JSON, consulta la Managed Policy Reference [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)Guide.AWS *
## AWS politica gestita: AWSLambda gestita EC2 ResourceOperator
Questa policy consente la gestione automatizzata delle istanze di Amazon Elastic Compute Cloud per i provider di capacità Lambda. Concede le autorizzazioni al servizio scaler Lambda per eseguire operazioni sul ciclo di vita delle istanze per tuo conto.
Puoi associare la policy `AWSLambdaManagedEC2ResourceOperator` ai tuoi utenti, gruppi e ruoli.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `ec2:RunInstances`— Consente a Lambda di lanciare nuove istanze Amazon EC2 a condizione che ec2: sia ManagedResourceOperator uguale a scaler.lambda.amazonaws.com e limiti l'utilizzo dell'AMI alle sole immagini di proprietà di Amazon.
+ `ec2:DescribeInstances`e `ec2:DescribeInstanceStatus` — Consente a Lambda di monitorare lo stato dell'istanza e recuperare le informazioni sull'istanza.
+ `ec2:CreateTags`— Consente a Lambda di etichettare le risorse Amazon EC2 per scopi di gestione e identificazione.
+ `ec2:DescribeAvailabilityZones`— Consente a Lambda di visualizzare le zone disponibili, ad esempio le decisioni di posizionamento.
+ `ec2:DescribeCapacityReservations`— Consente a Lambda di verificare le prenotazioni di capacità per un posizionamento ottimale delle istanze.
+ `ec2:DescribeInstanceTypes`e`ec2:DescribeInstanceTypeOfferings`: consente a Lambda di esaminare i tipi di istanze disponibili e le relative offerte.
+ `ec2:DescribeSubnets`— Consente a Lambda di esaminare le configurazioni delle sottoreti per la pianificazione della rete.
+ `ec2:DescribeSecurityGroups`— Consente a Lambda di recuperare le informazioni sul gruppo di sicurezza per la configurazione dell'interfaccia di rete.
+ `ec2:CreateNetworkInterface`— Consente a Lambda di creare interfacce di rete e gestire associazioni di sottoreti e gruppi di sicurezza.
+ `ec2:AttachNetworkInterface`[— Consente a Lambda di collegare interfacce di rete alle istanze Amazon EC2 a condizione che sia uguale a scaler.lambda.amazonaws.com. `ec2:ManagedResourceOperator`](http://scaler.lambda.amazonaws.com/)
[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)
## AWS politica gestita: AWSLambda ServiceRolePolicy
Questa policy è associata al ruolo collegato ai servizi denominato per consentire AWSService RoleForLambda a Lambda di terminare le istanze gestite come parte dei provider di capacità Lambda.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `ec2:TerminateInstances`— Consente a Lambda di terminare le istanze EC2 a condizione che ec2: sia uguale a scaler.lambda.amazonaws.com. ManagedResourceOperator
+ `ec2:DescribeInstanceStatus`e `ec2:DescribeInstances` — Consente a Lambda di descrivere le istanze EC2.
Per ulteriori informazioni su questa politica, consulta [Using service-linked roles for Lambda](using-service-linked-roles.md).
## Aggiornamenti Lambda alle AWS politiche gestite
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [AWSLambdaGestito EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html): nuova politica | Lambda ha aggiunto una nuova policy gestita per abilitare la gestione automatizzata delle istanze Amazon EC2 per i provider di capacità Lambda, consentendo al servizio scaler di eseguire operazioni sul ciclo di vita delle istanze. | 30 novembre 2025 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html): nuova policy | Lambda ha aggiunto una nuova policy gestita per il ruolo collegato ai servizi per consentire a Lambda di terminare le istanze gestite come parte dei provider di capacità Lambda. | 30 novembre 2025 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Cambia | Lambda ha aggiornato la `AWSLambda_FullAccess` policy per consentire le azioni `kms:DescribeKey` e`iam:CreateServiceLinkedRole`. | 30 novembre 2025 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)— Nuova politica gestita | Lambda ha rilasciato una nuova policy gestita `AWSLambdaBasicDurableExecutionRolePolicy` che fornisce autorizzazioni di scrittura per CloudWatch i log e read/write autorizzazioni per l'esecuzione durevole utilizzate APIs dalle funzioni durevoli di Lambda. | 1 dicembre 2025 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)e [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Cambia | Lambda ha aggiornato le policy `AWSLambda_ReadOnlyAccess` e `AWSLambda_FullAccess` per consentire le azioni `logs:StartLiveTail` e `logs:StopLiveTail`. | 17 marzo 2025 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)— Cambia | Lambda ha aggiornato la policy `AWSLambdaVPCAccessExecutionRole` per consentire l'azione `ec2:DescribeSubnets`. | 5 gennaio 2024 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Cambiare | Lambda ha aggiornato la `AWSLambda_ReadOnlyAccess` policy per consentire ai principali di elencare gli stack. CloudFormation | 27 luglio 2023 |
| AWS Lambda ha iniziato a tenere traccia delle modifiche | AWS Lambda ha iniziato a tenere traccia delle modifiche per le sue politiche AWS gestite. | 27 luglio 2023 |
# Risoluzione dei problemi AWS Lambda di identità e accesso
Utilizza le seguenti informazioni per diagnosticare e risolvere i problemi comuni che possono verificarsi durante l'uso di Lambda e IAM.
**Topics**
+ [
## Non sono autorizzato/a a eseguire un'operazione in Lambda
](#security_iam_troubleshoot-no-permissions)
+ [
## Non sono autorizzato a eseguire iam: PassRole
](#security_iam_troubleshoot-passrole)
+ [
## Voglio consentire a persone esterne a me di accedere Account AWS alle mie risorse Lambda
](#security_iam_troubleshoot-cross-account-access)
## Non sono autorizzato/a a eseguire un'operazione in Lambda
Se ricevi un errore che indica che non sei autorizzato a eseguire un’operazione, le tue policy devono essere aggiornate per poter eseguire l’operazione.
L’errore di esempio seguente si verifica quando l’utente IAM `mateojackson` prova a utilizzare la console per visualizzare i dettagli relativi a una risorsa `my-example-widget` fittizia ma non dispone di autorizzazioni `lambda:GetWidget` fittizie.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
In questo caso, la policy per l’utente `mateojackson` deve essere aggiornata per consentire l’accesso alla risorsa `my-example-widget` utilizzando l’azione `lambda:GetWidget`.
Se hai bisogno di assistenza, contatta il tuo AWS amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Non sono autorizzato a eseguire iam: PassRole
Se ricevi un errore che indica che non sei autorizzato a eseguire l'operazione `iam:PassRole`, devi aggiornare le policy per poter passare un ruolo a Lambda.
Alcuni Servizi AWS consentono di passare un ruolo esistente a quel servizio invece di creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per passare il ruolo al servizio.
L'errore di esempio riportato di seguito si verifica quando un utente IAM denominato `marymajor` tenta di utilizzare la console per eseguire un'operazione in Lambda. Tuttavia, l’azione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone delle autorizzazioni per trasmettere il ruolo al servizio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In questo caso, le policy di Mary devono essere aggiornate per poter eseguire l’operazione `iam:PassRole`.
Se hai bisogno di aiuto, contatta il tuo AWS amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Voglio consentire a persone esterne a me di accedere Account AWS alle mie risorse Lambda
È possibile creare un ruolo con il quale utenti in altri account o persone esterne all’organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l’assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali politiche per concedere alle persone l'accesso alle tue risorse.
Per ulteriori informazioni, consultare gli argomenti seguenti:
+ Per sapere se Lambda supporta queste funzionalità, consultare [Come AWS Lambda funziona con IAM](security_iam_service-with-iam.md).
+ Per scoprire come fornire l'accesso alle tue risorse attraverso Account AWS le risorse di tua proprietà, consulta [Fornire l'accesso a un utente IAM in un altro Account AWS di tua proprietà](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) nella *IAM* User Guide.
+ Per scoprire come fornire l'accesso alle tue risorse a terze parti Account AWS, consulta [Fornire l'accesso a soggetti Account AWS di proprietà di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) nella *Guida per l'utente IAM*.
+ Per informazioni su come fornire l'accesso tramite la federazione delle identità, consulta [Fornire l'accesso a utenti autenticati esternamente (federazione delle identità)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) nella *Guida per l'utente IAM*.
+ Per informazioni sulle differenze di utilizzo tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente IAM*.
# Creare una strategia di governance per le funzioni e i livelli Lambda
Per creare e implementare applicazioni serverless native del cloud, è necessario garantire agilità e velocità di immissione sul mercato con una governance e guardrail adeguati. Devi stabilire le priorità a livello aziendale, magari enfatizzando l'agilità come priorità assoluta o, in alternativa, sottolineando l'avversione al rischio attraverso governance, guardrail e controlli. Realisticamente, non adotterai una strategia "o/o", ma una strategia "e" che bilanci agilità e guardrail nel ciclo di vita dello sviluppo software. A prescindere dal punto del ciclo di vita dell'azienda in cui tali requisiti rientrano, è probabile che le funzionalità di governance diventino un requisito di implementazione nei processi e nelle toolchain.
Di seguito sono riportati alcuni esempi di controlli di governance che un'organizzazione potrebbe implementare per Lambda:
+ Le funzioni Lambda non devono essere accessibili pubblicamente.
+ Le funzioni Lambda devono essere associate a un VPC.
+ Le funzioni Lambda non dovrebbero utilizzare runtime ritirati.
+ Le funzioni Lambda devono essere etichettate con un set di tag obbligatori.
+ I livelli Lambda non devono essere accessibili all'esterno dell'organizzazione.
+ Le funzioni Lambda con un gruppo di sicurezza associato devono disporre di corrispondenti tra la funzione e il gruppo di sicurezza.
+ Le funzioni Lambda con un livello associato devono utilizzare una versione approvata.
+ Le variabili di ambiente Lambda devono essere crittografate a riposo con una chiave gestita dal cliente.
Il diagramma seguente è un esempio di una strategia di governance approfondita che implementa controlli e policy durante tutto il processo di sviluppo e implementazione del software:
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-concepts.png)
I seguenti argomenti spiegano come implementare i controlli per lo sviluppo e l'implementazione di funzioni Lambda nell'organizzazione, sia per le startup che per le imprese. L'organizzazione potrebbe già disporre di alcuni strumenti. Gli argomenti seguenti adottano un approccio modulare a tali controlli, affinché si possano scegliere i componenti effettivamente necessari.
**Topics**
+ [
# Controlli proattivi per Lambda con AWS CloudFormation Guard
](governance-cloudformation-guard.md)
+ [
# Implementa controlli preventivi per Lambda con AWS Config
](governance-config.md)
+ [
# Rileva implementazioni e configurazioni Lambda non conformi con AWS Config
](governance-config-detection.md)
+ [
# Firma del codice Lambda con AWS Signer
](governance-code-signing.md)
+ [
# Automatizzare le valutazioni di sicurezza per Lambda con Amazon Inspector
](governance-code-scanning.md)
+ [
# Implementazione dell'osservabilità per la sicurezza e la conformità Lambda
](governance-observability.md)
# Controlli proattivi per Lambda con AWS CloudFormation Guard
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) è uno strumento di valutazione policy as code open source per uso generico. Può essere utilizzato per la governance preventiva e la conformità attraverso la convalida dei modelli di infrastructure as code (IaC) e le composizioni dei servizi rispetto alle regole delle policy. Queste regole possono essere personalizzate in base ai requisiti del team o dell'organizzazione. Per le funzioni Lambda, è possibile utilizzare le regole Guard per controllare la creazione di risorse e gli aggiornamenti della configurazione definendo le impostazioni di proprietà richieste necessarie durante la creazione o l'aggiornamento di una funzione Lambda.
Gli amministratori addetti alla conformità definiscono l'elenco dei controlli e delle policy di governance necessari per l'implementazione e l'aggiornamento delle funzioni Lambda. Gli amministratori della piattaforma implementano i controlli nelle pipeline CI/CD, come webhook di convalida pre-commit con repository di codice, e forniscono agli sviluppatori strumenti a riga di comando per la convalida di modelli e codice nelle postazioni di lavoro locali. Gli sviluppatori creano codice, convalidano i modelli con strumenti a riga di comando e quindi eseguono il commit del codice nei repository, che vengono poi convalidati in automatico attraverso le pipeline CI/CD prima dell'implementazione in un ambiente AWS.
Guard ti consente di [scrivere le regole](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) e di implementare i controlli con un linguaggio specifico per il dominio come riportato di seguito.
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-cloudformation-guard.png)
Ad esempio, supponi di volerti assicurare che gli sviluppatori scelgano solo i runtime più recenti. Potresti specificare due policy diverse, una per identificare i [runtime](lambda-runtimes.md) già ritirati e l'altra per identificare i runtime che verranno ritirati a breve. A tale scopo, potresti scrivere il file `etc/rules.guard` seguente:
```
let lambda_functions = Resources.*[
Type == "AWS::Lambda::Function"
]
rule lambda_already_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <>
}
}
}
}
rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <>
}
}
}
}
```
Supponiamo ora di scrivere il seguente modello CloudFormation `iac/lambda.yaml`, che definisce una funzione Lambda:
```
Fn:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
CodeUri: src
Handler: fn.handler
Role: !GetAtt FnRole.Arn
Layers:
- arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35
```
Dopo aver eseguito l'[installazione](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) della funzionalità Guard, convalida il modello:
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
L'output sarà il seguente:
```
lambda.yaml Status = FAIL
FAILED rules
rules.guard/lambda_soon_to_be_deprecated_runtime
---
Evaluating data lambda.yaml against rules rules.guard
Number of non-compliant resources 1
Resource = Fn {
Type = AWS::Lambda::Function
Rule = lambda_soon_to_be_deprecated_runtime {
ALL {
Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] {
ComparisonError {
Message = Lambda function is using a runtime that is targeted for deprecation.
Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])]
}
PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15]
Operator = NOT IN
Value = "python3.7"
ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]]
Code:
86. Fn:
87. Type: AWS::Lambda::Function
88. Properties:
89. Runtime: python3.7
90. CodeUri: src
91. Handler: fn.handler
}
}
}
}
```
Guard consente agli sviluppatori di vedere dalle loro postazioni di lavoro locali che devono aggiornare il modello per utilizzare un runtime consentito dall'organizzazione. Ciò avviene prima di effettuare il commit in un repository di codice e quindi di non superare i controlli all'interno di una pipeline CI/CD. Di conseguenza, gli sviluppatori ricevono questo feedback su come sviluppare modelli conformi e dedicare più tempo alla scrittura di codice che offra valore aziendale. Questo controllo può essere applicato alla postazione di lavoro locale degli sviluppatori, a un webhook di convalida pre-commit e/o alla pipeline CI/CD prima dell'implementazione.
## Avvertenze
Se utilizzi modelli AWS Serverless Application Model (AWS SAM) per definire le funzioni Lambda, tieni presente che devi aggiornare la regola Guard per cercare il tipo di risorsa `AWS::Serverless::Function` come riportato di seguito.
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
Guard si aspetta inoltre che le proprietà vengano incluse nella definizione della risorsa. Nel frattempo, i modelli AWS SAM consentono di specificare le proprietà in una sezione [Globali](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) separata. Le proprietà definite nella sezione Globali non vengono convalidate con le regole Guard.
Come indicato nella [documentazione](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) per la risoluzione dei problemi di Guard, tieni presente che Guard non supporta funzioni intrinseche in formato breve come `!GetAtt` o `!Sub` e richiede invece l'utilizzo dei formati espansi: `Fn::GetAtt` e `Fn::Sub`. (L'[esempio precedente](#guard-iac-yaml) non valuta la proprietà Ruolo, quindi per semplicità è stata utilizzata la funzione intrinseca in formato breve.)
# Implementa controlli preventivi per Lambda con AWS Config
È essenziale garantire la conformità delle applicazioni serverless il più presto possibile nel processo di sviluppo. In questo argomento, spieghiamo come implementare controlli preventivi utilizzando [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). Ciò consente di implementare i controlli di conformità nelle fasi iniziali del processo di sviluppo e di implementare gli stessi controlli nelle pipeline. CI/CD Ciò standardizza anche i controlli in un archivio di regole gestito centralmente in modo da poter applicare i controlli in modo uniforme su tutti gli account. AWS
Ad esempio, supponiamo che gli amministratori della conformità abbiano definito un requisito per garantire che tutte le funzioni Lambda includano il tracciamento. AWS X-Ray Con AWS Config la modalità proattiva, puoi eseguire controlli di conformità sulle risorse delle funzioni Lambda prima dell'implementazione, riducendo il rischio di implementare funzioni Lambda configurate in modo errato e facendo risparmiare tempo agli sviluppatori fornendo loro un feedback più rapido sull'infrastruttura sotto forma di modelli di codice. Di seguito è riportata una visualizzazione del flusso per i controlli preventivi con: AWS Config
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-1.png)
Immagina che vi sia un requisito per cui il tracciamento deve essere abilitato in tutte le funzioni Lambda. In risposta, il team della piattaforma identifica la necessità di una AWS Config regola specifica da applicare in modo proattivo su tutti gli account. Questa regola contrassegna come risorsa non conforme ogni funzione Lambda priva di una configurazione di tracciamento X-Ray configurata. Il team sviluppa una regola, la racchiude in un pacchetto di [conformità e distribuisce il pacchetto](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) di conformità su tutti gli AWS account per garantire che tutti gli account dell'organizzazione applichino questi controlli in modo uniforme. Puoi scrivere la regola nella sintassi 2.x.x di AWS CloudFormation Guard , che assume la forma seguente:
```
rule name when condition { assertion }
```
Di seguito è riportato un esempio di regola Guard che verifica l'abilitazione del tracciamento nelle funzioni Lambda:
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
[Il team della piattaforma intraprende ulteriori azioni imponendo che ogni implementazione richiami un hook di pre-creazione/aggiornamento. AWS CloudFormation](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html) Il team si assume la piena responsabilità dello sviluppo di tale hook e di configurare la pipeline, rafforzando il controllo centralizzato delle regole di conformità e sostenendo l'applicazione coerente in tutte le implementazioni. Per sviluppare, impacchettare e registrare un hook, consulta Developing [AWS CloudFormation Hooks nella documentazione](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html) dell'interfaccia a riga di CloudFormation comando (CFN-CLI). Puoi usare la [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) per creare il progetto hook:
```
cfn init
```
Questo comando richiede alcune informazioni di base sul progetto hook e crea un progetto contenente i file seguenti:
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
Come sviluppatore di hook, devi aggiungere il tipo di risorsa di destinazione desiderato nel file di configurazione `.json`. Nella configurazione seguente, un hook è configurato per l'esecuzione prima di creare qualsiasi funzione Lambda utilizzando. CloudFormation Puoi anche aggiungere gestori simili per le azioni `preUpdate` e `preDelete`.
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
È inoltre necessario assicurarsi che l' CloudFormation hook disponga delle autorizzazioni appropriate per chiamare il. AWS Config APIs Puoi farlo aggiornando il file di definizione del ruolo denominato `hook-role.yaml`. Per impostazione predefinita, il file di definizione del ruolo ha la seguente politica di fiducia, che consente di CloudFormation assumere il ruolo.
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
Per consentire a questo hook di chiamare config APIs, è necessario aggiungere le seguenti autorizzazioni all'istruzione Policy. Quindi invii il progetto hook utilizzando il `cfn submit` comando, dove CloudFormation crea un ruolo per te con le autorizzazioni richieste.
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
Successivamente, devi scrivere una funzione Lambda in un file `src/handler.py`. All'interno di tale file, troverai i metodi denominati `preCreate`, `preUpdate` e `preDelete` già creati all'avvio del progetto. Il tuo obiettivo è scrivere una funzione comune e riutilizzabile che richiami l' AWS Config `StartResourceEvaluation`API in modalità proattiva utilizzando il. AWS SDK per Python (Boto3) Questa chiamata API accetta le proprietà della risorsa come input e valuta la risorsa rispetto alla definizione della regola.
```
def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
LOG.info("Fetching proactive data")
config_client = boto3.client('config')
resource_specs = {
'ResourceId': 'MyFunction',
'ResourceType': resource_type,
'ResourceConfiguration': json.dumps(function_properties),
'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
}
LOG.info("Resource Specifications:", resource_specs)
eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
ResourceEvaluationId = eval_response.ResourceEvaluationId
compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
else:
return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")
```
Ora puoi effettuare la chiamata alla funzione comune dal gestore per l'hook di pre-creazione. Di seguito è riportato un esempio del gestore:
```
@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
session: Optional[SessionProxy],
request: HookHandlerRequest,
callback_context: MutableMapping[str, Any],
type_configuration: TypeConfigurationModel
) -> ProgressEvent:
LOG.info("Starting execution of the hook")
target_name = request.hookContext.targetName
LOG.info("Target Name:", target_name)
if "AWS::Lambda::Function" == target_name:
return validate_lambda_tracing_config(target_name,
request.hookContext.targetModel.get("resourceProperties")
)
else:
raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")
```
Dopo questo passaggio è possibile registrare l'hook e configurarlo per ascoltare tutti gli eventi di creazione delle AWS Lambda funzioni.
Uno sviluppatore prepara il modello di infrastructure as code (IaC) per un microservizio serverless utilizzando Lambda. La preparazione prevede il rispetto degli standard interni, a cui seguono il test e il commit locale del modello nel repository. Ecco un esempio di modello IaC:
```
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
FunctionName: MyLambdaFunction
Code:
ZipFile: |
import json
def handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}
Runtime: python3.14
TracingConfig:
Mode: PassThrough
MemorySize: 256
Timeout: 10
```
Come parte del CI/CD processo, quando il CloudFormation modello viene distribuito, il CloudFormation servizio richiama l'hook di pre-creazione/aggiornamento subito prima del provisioning del tipo di risorsa. `AWS::Lambda::Function` L'hook utilizza AWS Config regole eseguite in modalità proattiva per verificare che la configurazione della funzione Lambda includa la configurazione di tracciamento obbligatoria. La risposta dell'hook determina la fase successiva. Se conforme, l'hook segnala l'esito positivo e procede alla fornitura delle risorse. CloudFormation In caso contrario, l'implementazione CloudFormation dello stack fallisce, la pipeline si arresta immediatamente e il sistema registra i dettagli per la successiva revisione. Le notifiche di conformità vengono inviate ai soggetti interessati.
Puoi trovare le success/fail informazioni sull'hook nella console: CloudFormation
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-2.png)
Se hai abilitato i log per il tuo CloudFormation hook, puoi acquisire il risultato della valutazione dell'hook. Di seguito è riportato un log di esempio relativo a un hook con stato non riuscito, che indica il fatto che nella funzione Lambda non è abilitato X-Ray:
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-3.png)
Se lo sviluppatore sceglie di modificare l'IaC per aggiornare il valore `TracingConfig Mode` in `Active` ed eseguire nuovamente l'implementazione, l'hook viene eseguito correttamente e lo stack procede alla creazione della risorsa Lambda.
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-4.png)
In questo modo, puoi implementare controlli preventivi AWS Config in modalità proattiva durante lo sviluppo e la distribuzione di risorse serverless nei tuoi account. AWS Integrando AWS Config le regole nella CI/CD pipeline, puoi identificare e, facoltativamente, bloccare le distribuzioni di risorse non conformi, come le funzioni Lambda prive di una configurazione di tracciamento attiva. Ciò garantisce che negli ambienti vengano implementate solo le risorse conformi alle più recenti politiche di governance. AWS
# Rileva implementazioni e configurazioni Lambda non conformi con AWS Config
Oltre alla [valutazione proattiva](governance-config.md), AWS Config puoi anche rilevare in modo reattivo le implementazioni e le configurazioni delle risorse che non sono conformi alle politiche di governance. Si tratta di una funzione importante, perché le policy di governance si evolvono man mano che l'organizzazione apprende e implementa nuove best practice.
Immagina uno scenario in cui imposti una nuova policy durante l'implementazione o l'aggiornamento delle funzioni Lambda: tutte le funzioni Lambda devono sempre utilizzare una versione di livello Lambda specifica e approvata. Puoi configurare AWS Config per monitorare le funzioni nuove o aggiornate per le configurazioni di livello. Se AWS Config rileva una funzione che non utilizza una versione di livello approvata, contrassegna la funzione come risorsa non conforme. Facoltativamente, è possibile AWS Config configurare la riparazione automatica della risorsa specificando un'azione di riparazione utilizzando un documento di automazione. AWS Systems Manager Ad esempio, è possibile scrivere un documento di automazione in Python utilizzando AWS SDK per Python (Boto3), che aggiorna la funzione non conforme in modo che punti alla versione del livello approvata. Pertanto, AWS Config funge sia da controllo investigativo che correttivo, automatizzando la gestione della conformità.
Suddividiamo questo processo in tre importanti fasi di implementazione:
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-detective-1.png)
## Fase 1: identificazione delle risorse di accesso
Inizia eseguendo l'attivazione AWS Config su tutti i tuoi account e configurandola per registrare le funzioni Lambda AWS . Ciò consente di AWS Config osservare quando le funzioni Lambda vengono create o aggiornate. Puoi quindi configurare [regole di policy personalizzate](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) per verificare la presenza di eventuali violazioni di policy specifiche, che utilizzano la sintassi AWS CloudFormation Guard . Le regole di Guard assumono la seguente forma generale:
```
rule name when condition { assertion }
```
Di seguito è riportato un esempio di regola che verifica che un livello non sia impostato su una versione di livello vecchia:
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
Analizziamo la sintassi e la struttura della regola:
+ **Nome della regola:** il nome della regola nell'esempio presentato è `desiredlayer`.
+ **Condizione:** questa clausola specifica la condizione in base alla quale la regola deve essere verificata. Nell'esempio fornito, la condizione è `configuration.layers !empty`. Ciò significa che la risorsa deve essere valutata solo quando la proprietà `layers` nella configurazione non è vuota.
+ **Asserzione:** dopo la clausola `when`, un'asserzione determina che cosa verifica la regola. L'asserzione `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` verifica se uno qualsiasi dei ARNs livelli Lambda non corrisponde al `OldLayerArn` valore. Se non corrispondono, l'asserzione è vera e la regola viene rispettata; in caso contrario, ha esito negativo.
`CONFIG_RULE_PARAMETERS`è un set speciale di parametri configurato con la AWS Config regola. In questo caso, `OldLayerArn` è un parametro all'interno di `CONFIG_RULE_PARAMETERS`. Ciò consente agli utenti di fornire un valore di ARN specifico che ritengono vecchio o ritirato, quindi la regola verifica se alcune funzioni Lambda utilizzano l'ARN vecchio in questione.
## Fase 2: visualizzazione e progettazione
AWS Config raccoglie i dati di configurazione e li archivia in bucket Amazon Simple Storage Service (Amazon S3). Puoi utilizzare [Amazon Athena](https://aws.amazon.com/athena/) per inviare query a tali dati direttamente dai bucket S3. Con Athena, puoi aggregare questi dati a livello dell'organizzazione, generando una visione onnicomprensiva delle configurazioni delle risorse in tutti gli account. Per configurare l'aggregazione dei dati di configurazione delle risorse, consulta [Visualizing data AWS Config using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) sul blog AWS Cloud Operations and Management.
Di seguito è riportato un esempio di query Athena per identificare tutte le funzioni Lambda che utilizzano un particolare ARN di livello:
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.version') AS version
FROM
unnested
WHERE
lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%'
```
Ecco i risultati della query:
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-detective-2.png)
Con i AWS Config dati aggregati in tutta l'organizzazione, puoi quindi creare una dashboard utilizzando [Amazon Quick](https://aws.amazon.com/quicksight/). Importando i risultati di Athena in Quick, puoi visualizzare in che misura le tue funzioni Lambda aderiscono alla regola della versione del layer. Questa dashboard può evidenziare le risorse conformi e non conformi. Ciò ti aiuta a determinare la policy di applicazione, come indicato nella [sezione successiva](#governance-config-detective-implement). L'immagine seguente è un esempio di dashboard che riporta la distribuzione delle versioni di livello applicate alle funzioni all'interno dell'organizzazione.
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-config-detective-3.png)
## Fase 3: implementazione e applicazione
Ora, come opzione, puoi abbinare la regola della versione di livello che hai creato nella [fase 1](#governance-config-detective-identify) con un'azione di correzione attraverso un documento di automazione Systems Manager, creato come script Python scritto con AWS SDK per Python (Boto3). Lo script richiama l'azione [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)API per ogni funzione Lambda, aggiornando la configurazione della funzione con il nuovo livello ARN. In alternativa, potresti fare in modo che lo script invii una richiesta pull al repository del codice per aggiornare l'ARN del livello. In questo modo anche le future implementazioni di codice vengono aggiornate con l'ARN di livello corretto.
# Firma del codice Lambda con AWS Signer
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) è un servizio di firma del codice completamente gestito che consente di convalidare il codice rispetto a una firma digitale per confermare che il codice sia inalterato e provenga da un editore affidabile. AWS Signer può essere utilizzato insieme a AWS Lambda per verificare che le funzioni e i livelli siano inalterati prima dell'implementazione negli ambienti AWS. Ciò protegge l'organizzazione da malintenzionati che potrebbero aver ottenuto credenziali per creare nuove funzioni o aggiornare quelle esistenti.
Per impostare la firma del codice per le funzioni Lambda, comincia creando un bucket S3 con il controllo delle versioni abilitato. Dopodiché, crea un profilo di firma con AWS Signer, specifica Lambda come piattaforma e quindi specifica un periodo di giorni in cui il profilo di firma sarà valido. Esempio:
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
Quindi utilizza il profilo di firma e crea una configurazione di firma con Lambda. Devi specificare che cosa fare quando la configurazione di firma rileva un artefatto che non corrisponde alla firma digitale prevista: avvisare (ma consentire l'implementazione) o imporre (e bloccare l'implementazione). L'esempio seguente è configurato per imporre e bloccare le implementazioni.
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
Ora ha configurato AWS Signer con Lambda per bloccare le implementazioni non attendibili. Supponiamo che tu abbia finito di codificare una richiesta di funzionalità e che ora stia aspettando di implementare la funzione. La prima fase consiste nel comprimere in formato zip il codice con le dipendenze appropriate e quindi nel firmare l'artefatto utilizzando il profilo di firma che hai creato. Puoi farlo caricando l'artefatto zip nel bucket S3 e quindi avviando un processo di firma.
```
aws signer start-signing-job \
--source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \
--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \
--profile-name your-signer-id
```
Otterrai un output come il seguente, dove `jobId` è l'oggetto creato nel bucket e nel prefisso di destinazione e `jobOwner` è l'ID dell'Account AWS a 12 cifre in cui il processo è stato eseguito.
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
Ora puoi implementare la funzione utilizzando l'oggetto S3 firmato e la configurazione di firma del codice che hai creato.
```
Fn:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip
Handler: fn.handler
Role: !GetAtt FnRole.Arn
CodeSigningConfigArn: !Ref pSigningConfigArn
```
In alternativa, puoi testare l'implementazione di una funzione con l'artefatto zip di origine non firmato autentico. L'implementazione dovrebbe avere esito negativo con il seguente messaggio di errore:
```
Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.
```
Se stai creando e implementando le funzioni con AWS Serverless Application Model (AWS SAM), il comando del pacchetto gestisce il caricamento dell'artefatto zip in S3, avvia anche il processo di firma e ottiene l'artefatto firmato. Puoi eseguire questa operazione con il comando e i parametri riportati di seguito:
```
sam package -t your-template.yaml \
--output-template-file your-output.yaml \
--s3-bucket your-versioned-bucket \
--s3-prefix your-prefix \
--signing-profiles your-signer-id
```
AWS Signer ti aiuta a verificare che gli artefatti zip implementati negli account siano affidabili per l'implementazione. Puoi includere il processo di cui sopra nelle pipeline CI/CD e richiedere che tutte le funzioni abbiano una configurazione di firma del codice associata utilizzando le tecniche descritte negli argomenti precedenti. Utilizzando la firma del codice con le implementazioni delle funzioni Lambda, impedisci a malintenzionati che potrebbero aver ottenuto le credenziali per creare o aggiornare le funzioni di iniettare codice dannoso nelle funzioni.
# Automatizzare le valutazioni di sicurezza per Lambda con Amazon Inspector
[Amazon Inspector](https://aws.amazon.com/inspector/) è un servizio di gestione delle vulnerabilità che scansiona continuamente i carichi di lavoro alla ricerca di vulnerabilità del software ed esposizione alla rete non intenzionale. Amazon Inspector crea un esito che descrive la vulnerabilità, identifica la risorsa interessata, valuta la gravità della vulnerabilità e fornisce indicazioni per la correzione.
Il supporto di Amazon Inspector fornisce valutazioni continue e automatizzate delle vulnerabilità di sicurezza per le funzioni e i livelli Lambda. Amazon Inspector offre due tipi di scansione per Lambda:
+ **Scansione standard Lambda (impostazione predefinita):** esegue la scansione delle dipendenze dell'applicazione all'interno di una funzione Lambda e dei relativi livelli alla ricerca di [vulnerabilità dei pacchetti](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package).
+ **Scansione del codice Lambda**: esegue la scansione del codice dell'applicazione personalizzato nelle funzioni e nei livelli alla ricerca di [vulnerabilità del codice](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code). Puoi attivare la scansione standard Lambda da sola o insieme alla scansione del codice Lambda.
Per abilitare Amazon Inspector, accedi alla console [Amazon Inspector](https://console.aws.amazon.com/inspector/), espandi la sezione **Impostazioni** e scegli **Gestione dell'account**. Nella scheda **Account**, scegli **Attiva**, quindi seleziona una delle opzioni di scansione.
Puoi abilitare Amazon Inspector per più account e delegare le autorizzazioni a gestire Amazon Inspector per l'organizzazione ad account specifici durante la configurazione di Amazon Inspector. Durante l'abilitazione, devi concedere le autorizzazioni ad Amazon Inspector creando il ruolo: `AWSServiceRoleForAmazonInspector2`. La console Amazon Inspector ti consente di creare questo ruolo utilizzando un'opzione con un solo clic.
Per la scansione standard Lambda, Amazon Inspector avvia scansioni di vulnerabilità delle funzioni Lambda nelle situazioni seguenti:
+ Non appena Amazon Inspector rileva una funzione Lambda esistente.
+ Quando si implementa una nuova funzione Lambda.
+ Quando si implementa un aggiornamento al codice dell'applicazione o alle dipendenze di una funzione Lambda esistente o dei relativi livelli.
+ Ogni volta che Amazon Inspector aggiunge un nuovo elemento di vulnerabilità ed esposizioni comuni (common vulnerabilities and exposures, CVE) al suo database e tale CVE è pertinente alla funzione.
Per la scansione del codice Lambda, Amazon Inspector valuta il codice dell'applicazione della funzione Lambda utilizzando ragionamento automatico e machine learning che analizzano il codice dell'applicazione per quanto riguarda la conformità di sicurezza generale. Se rileva una vulnerabilità nel codice dell'applicazione della funzione Lambda, Amazon Inspector produce un esito di **Vulnerabilità del codice** dettagliato. Per un elenco di possibili rilevamenti, consulta [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/).
Per visualizzare gli esiti, accedi alla [console Amazon Inspector](https://console.aws.amazon.com/inspector/). Nel menu **Esiti**, seleziona **Per funzione Lambda** per visualizzare i risultati della scansione di sicurezza eseguita sulle funzioni Lambda.
Per escludere una funzione Lambda dalla scansione standard, etichetta la funzione con la seguente coppia chiave-valore:
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
Per escludere una funzione Lambda dalle scansioni del codice, etichetta la funzione con la seguente coppia chiave-valore:
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
Ad esempio, come mostrato nell'immagine seguente, Amazon Inspector rileva in automatico le vulnerabilità e classifica gli esiti di tipo **Vulnerabilità del codice**, il che indica che la vulnerabilità si trova nel codice della funzione e non in una delle librerie dipendenti dal codice. Puoi controllare questi dettagli per una funzione specifica o per più funzioni contemporaneamente.
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-code-scanning-1.png)
Puoi approfondire ciascuno degli esiti e scoprire come risolvere il problema.
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-code-scanning-2.png)
Mentre lavori con le funzioni Lambda, assicurati di rispettare le convenzioni di denominazione delle funzioni Lambda. Per ulteriori informazioni, consulta [Utilizzo delle variabili di ambiente Lambda](configuration-envvars.md).
La responsabilità sui suggerimenti di riparazione che accetti è tua. Esamina sempre i suggerimenti di riparazione prima di accettarli. Per garantire che il codice funzioni come previsto, potrebbe essere necessario apportare modifiche ai suggerimenti di riparazione.
# Implementazione dell'osservabilità per la sicurezza e la conformità Lambda
AWS Config è uno strumento utile per trovare e correggere risorse Serverless non conformi AWS . Ogni modifica apportata alle risorse serverless viene registrata in. AWS Config Inoltre, AWS Config consente di archiviare i dati delle istantanee di configurazione su S3. Puoi usare Amazon Athena e Amazon Quick per creare dashboard e visualizzare i dati. AWS Config In [Rileva implementazioni e configurazioni Lambda non conformi con AWS Config](governance-config-detection.md), abbiamo discusso come visualizzare una determinata configurazione quali i livelli Lambda. Il presente argomento approfondisce tali concetti.
## Visibilità sulle configurazioni Lambda
Puoi utilizzare le query per richiamare configurazioni importanti come Account AWS ID, regione, configurazione di AWS X-Ray tracciamento, configurazione VPC, dimensione della memoria, runtime e tag. Di seguito è riportato un esempio di query che puoi utilizzare per ottenere queste informazioni da Athena:
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
account_id,
tags,
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.runtime') AS version
json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig
json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig
FROM
unnested
```
È possibile utilizzare la query per creare una dashboard rapida e visualizzare i dati. Per aggregare i dati di configurazione AWS delle risorse, creare tabelle in Athena e creare dashboard Quick sui dati di Athena, consulta [Visualizing AWS Config data using Athena and Amazon Quick on the Cloud Operations and Management blog](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/). AWS In particolare, questa query recupera anche le informazioni dei tag per le funzioni. Ciò consente di ottenere maggiori approfondimenti sui carichi di lavoro e sugli ambienti, soprattutto se impieghi tag personalizzati.
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-observability-1.png)
Per ulteriori informazioni sulle azioni che puoi intraprendere, consulta la sezione [Risoluzione degli esiti di osservabilità](#governance-observability-addressing) più avanti in questo argomento.
## Visibilità sulla conformità Lambda
Con i dati generati da AWS Config, puoi creare dashboard a livello di organizzazione per monitorare la conformità. Ciò consente il tracciamento e il monitoraggio coerenti di:
+ Pacchetti di conformità per punteggio di conformità
+ Regole per risorse non conformi
+ Compliance status (Stato di conformità)
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-observability-2.png)
Controlla ogni regola per identificare le risorse non conformi alla stessa. Ad esempio, se l'organizzazione impone che tutte le funzioni Lambda siano associate a un VPC e se è stata implementata AWS Config una regola per identificare la conformità, è possibile selezionare `lambda-inside-vpc` la regola nell'elenco precedente.
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-observability-3.png)
Per ulteriori informazioni sulle azioni che puoi intraprendere, consulta la sezione [Risoluzione degli esiti di osservabilità](#governance-observability-addressing) di seguito.
## Visibilità nei limiti delle funzioni Lambda utilizzando Security Hub CSPM
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-observability-4.png)
Per garantire che AWS i servizi, tra cui Lambda, vengano utilizzati in modo sicuro, sono state AWS introdotte le Foundational Security Best Practices v1.0.0. Questo insieme di best practice fornisce linee guida chiare per proteggere risorse e dati nell' AWS ambiente, sottolineando l'importanza di mantenere un solido livello di sicurezza. A ciò AWS Security Hub CSPM si aggiunge l'offerta di un centro unificato per la sicurezza e la conformità. Aggrega, organizza e dà priorità ai risultati di sicurezza provenienti da più servizi come AWS Amazon Inspector e Amazon. AWS Identity and Access Management Access Analyzer GuardDuty
Se hai Security Hub CSPM, Amazon Inspector, IAM Access Analyzer GuardDuty e sei abilitato all'interno della tua organizzazione AWS , Security Hub CSPM aggrega automaticamente i risultati di questi servizi. Prendiamo ad esempio Amazon Inspector. Utilizzando Security Hub CSPM, puoi identificare in modo efficiente le vulnerabilità del codice e dei pacchetti nelle funzioni Lambda. Nella console Security Hub CSPM, vai alla sezione inferiore denominata **Ultimi risultati** delle integrazioni. AWS Qui puoi visualizzare e analizzare i risultati provenienti da vari servizi integrati. AWS
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-observability-5.png)
Per visualizzare i dettagli, scegli il link **Vedi risultati** nella seconda colonna. Viene visualizzato un elenco di risultati filtrati per prodotto, ad esempio Amazon Inspector. Per limitare la ricerca alle funzioni Lambda, imposta `ResourceType` su `AwsLambdaFunction`. Vengono visualizzati gli esiti di Amazon Inspector relativi alle funzioni Lambda.
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/governance-observability-6.png)
Infatti GuardDuty, è possibile identificare modelli di traffico di rete sospetti. Tali anomalie potrebbero suggerire l'esistenza di codice potenzialmente dannoso all'interno della funzione Lambda.
Con Sistema di analisi degli accessi IAM, puoi controllare le policy, in particolare quelle con istruzioni condizionali che concedono l'accesso alle funzioni a entità esterne. Inoltre, IAM Access Analyzer valuta le autorizzazioni impostate quando si utilizza l'[AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)operazione nell'API Lambda insieme a un. `EventSourceToken`
## Risoluzione degli esiti di osservabilità
Data l'ampia gamma di configurazioni possibili per le funzioni Lambda e i relativi requisiti distinti, una soluzione di automazione standardizzata per la riparazione potrebbe non essere adatta a ogni situazione. Inoltre, le modifiche vengono implementate in modo diverso nei vari ambienti. Se riscontri una configurazione che sembra non conforme, tieni presente le seguenti linee guida:
1. **Strategia di assegnazione tag**
Consigliamo di implementare una strategia di assegnazione tag completa. A ogni funzione Lambda si dovrebbero assegnare tag con informazioni chiave come le seguenti:
+ **Proprietario:** la persona o il team responsabile della funzione.
+ **Ambiente:** produzione, staging, sviluppo o ambiente di sperimentazione (sandbox).
+ **Applicazione:** il contesto più ampio a cui appartiene la funzione, se applicabile.
1. **Contatto del proprietario**
Anziché automatizzare le modifiche sostanziali (come la regolazione della configurazione del VPC), contatta in modo proattivo i proprietari delle funzioni non conformi (identificati dal tag del proprietario) fornendo loro il tempo sufficiente per adottare una delle misure seguenti:
+ Regolare le configurazioni non conformi sulle funzioni Lambda.
+ Fornire una spiegazione e richiedere un'eccezione oppure perfezionare gli standard di conformità.
1. **Mantenimento di un database di gestione della configurazione (CMDB)**
Sebbene i tag possano fornire un contesto immediato, mantenere un CMDB centralizzato può fornire maggiori approfondimenti. Il database può contenere informazioni più granulari in merito a ogni funzione Lambda, alle relative dipendenze e altri metadati critici. Un CMDB è una risorsa di valore inestimabile per l'audit, i controlli di conformità e l'identificazione dei proprietari delle funzioni.
Poiché il panorama dell'infrastruttura serverless è in continua evoluzione, è essenziale adottare un atteggiamento proattivo nei confronti del monitoraggio. Con strumenti come AWS Config Security Hub CSPM e Amazon Inspector, è possibile identificare rapidamente potenziali anomalie o configurazioni non conformi. Tuttavia, gli strumenti da soli non possono garantire la conformità totale o configurazioni ottimali. È fondamentale abbinare tali strumenti a processi e best practice ben documentati.
+ **Ciclo di feedback:** una volta intraprese le misure correttive, assicurati che vi sia un ciclo di feedback. Ciò significa riesaminare su base periodica le risorse non conformi per confermare se sono state aggiornate o se presentano ancora gli stessi problemi.
+ **Documentazione:** documenta sempre le osservazioni, le azioni intraprese e le eventuali eccezioni concesse. Una documentazione adeguata non solo aiuta durante gli audit, ma contribuisce anche a migliorare il processo per ottenere una maggiore conformità e sicurezza in futuro.
+ **Formazione e consapevolezza:** assicurati che tutte le parti interessate, in particolare i responsabili delle funzioni Lambda, ricevano una formazione periodica e siano informate su best practice, policy dell'organizzazione e obblighi di conformità. Workshop, webinar o sessioni di formazione regolari possono dare un contributo notevole per garantire che tutti siano sulla stessa lunghezza d'onda in materia di sicurezza e conformità.
In conclusione, mentre gli strumenti e le tecnologie forniscono funzionalità solide per rilevare e segnalare potenziali problemi, l'elemento umano (comprensione, comunicazione, formazione e documentazione) rimane di cruciale importanza. Insieme, questi aspetti formano una combinazione molto efficace per garantire che le funzioni Lambda e l'infrastruttura in senso lato rimangano conformi, sicure e ottimizzate per le esigenze aziendali.
# Convalida della conformità per AWS Lambda
Revisori di terze parti valutano la sicurezza e la conformità di AWS Lambda all'interno di molteplici programmi di conformità di AWS. Questi includono SOC, PCI, FedRAMP, HIPAA e altri.
Per un elenco di servizi AWS che rientrano nell'ambito di programmi di conformità specifici, consultare [Servizi AWS coperti dal programma di compliance](https://aws.amazon.com/compliance/services-in-scope/). Per informazioni generali, consultare [Programmi per la conformità di AWS](https://aws.amazon.com/compliance/programs/).
Puoi scaricare i report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Download dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
La tua responsabilità di conformità durante l'utilizzo di Lambda è determinata dalla riservatezza dei dati, dagli obiettivi dell'azienda e dalle leggi e normative vigenti in materia. Puoi implementare controlli di governance per garantire che le funzioni Lambda della tua azienda soddisfino i requisiti di conformità. Per ulteriori informazioni, consulta [Creare una strategia di governance per le funzioni e i livelli Lambda](governance-concepts.md).
# Resilienza nell' AWS Lambda
L'infrastruttura globale di AWSè basata su Regioni e zone di disponibilità AWS. AWS forniscono più zone di disponibilità fisicamente separate e isolate che sono connesse tramite reti altamente ridondanti, a bassa latenza e con throughput elevato. Con le zone di disponibilità, è possibile progettare e gestire applicazioni e database che eseguono il failover automatico tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture tradizionali a data center singolo o multiplo.
Per ulteriori informazioni sulle Regioni e le Zone di disponibilità AWS, consulta [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Oltre all'infrastruttura globale di AWS, Lambda offre numerose funzionalità per supportare la resilienza dei dati e le esigenze di backup.
+ **Gestione delle versioni** – È possibile usare la gestione delle versioni in Lambda per salvare il codice e la configurazione in fase di sviluppo. Insieme all'utilizzo delgi alias, è possibile utilizzare la gestione delle versioni per eseguire distribuzioni blue/green e progressive. Per informazioni dettagliate, vedi [Gestire le versioni delle funzioni Lambda](configuration-versions.md).
+ **Dimensionamento** – Quando la funzione riceve una richiesta durante l'elaborazione di una richiesta precedente, Lambda avvia un'altra istanza della funzione per gestire l'aumento del carico. Lambda dimensiona automaticamente per gestire 1.000 esecuzioni simultanee per regione, un [quota](gettingstarted-limits.md) che può essere aumentata se necessario. Per informazioni dettagliate, vedi [Informazioni sulla scalabilità della funzione Lambda](lambda-concurrency.md).
+ **Elevata disponibilità** – Lambda esegue la funzione in più zone di disponibilità per assicurare che sia disponibile per elaborare eventi in caso di interruzione del servizio in una specifica zona. Se si configura la tua funzione affinché si connetta a un cloud privato virtuale (VPC) nel proprio account, specificare le sottoreti in più zone di disponibilità per garantire un'elevata disponibilità. Per informazioni dettagliate, vedi [Consentire alle funzioni Lambda l'accesso alle risorse in un Amazon VPC](configuration-vpc.md).
+ **Simultaneità riservata** – Per garantire che la funzione sia sempre in grado di ridimensionare le risorse per gestire le richieste aggiuntive, è possibile riservare la simultaneità. Impostare la simultaneità riservata per una funzione garantisce che questa possa ridimensionarsi fino a un dato numero di chiamate simultanee, senza tuttavia superarlo. In questo modo non andranno perse delle richieste a causa di altre funzioni onerose in termini di disponibilità simultanea. Per informazioni dettagliate, vedi [Configurazione della simultaneità riservata per una funzione](configuration-concurrency.md).
+ **Tentativi ripetuti** – Per le invocazioni asincrone e un sottoinsieme di invocazioni attivate da altri servizi, Lambda esegue automaticamente dei nuovi tentativi in caso di errore con specifici ritardi tra i tentativi successivi. Altri client e Servizi AWS che invocano le funzioni in modo sincrono sono responsabili dell'esecuzione di tentativi ripetuti. Per informazioni dettagliate, vedi [Informazioni sul comportamento relativo ai nuovi tentativi in Lambda](invocation-retries.md).
+ **Coda DLQ** – In caso di invocazioni asincrone, è possibile configurare Lambda affinché invii le richieste a una dead-letter queue se tutti i tentativi ripetuti non vanno a buon fine. Una coda DLQ è un argomento Amazon SNS o una coda Amazon SQS che riceve gli eventi a scopo di risoluzione dei problemi o rielaborazione. Per informazioni dettagliate, vedi [Aggiunta di una coda DLQ](invocation-async-retain-records.md#invocation-dlq).
# Sicurezza dell'infrastruttura in AWS Lambda
Come servizio gestito, AWS Lambda è protetto dalla sicurezza di rete globale AWS. Per informazioni sui servizi di sicurezza AWS e su come AWS protegge l'infrastruttura, consulta la pagina [Sicurezza del cloud AWS](https://aws.amazon.com/security/). Per progettare l'ambiente AWS utilizzando le best practice per la sicurezza dell'infrastruttura, consulta la pagina [Protezione dell'infrastruttura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) nel *Pilastro della sicurezza di AWS Well‐Architected Framework*.
Utilizza le chiamate API pubblicate da AWS per accedere a Lambda tramite la rete. I client devono supportare quanto segue:
+ Transport Layer Security (TLS). È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Suite di cifratura con Perfect Forward Secrecy (PFS), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
# Protezione dei carichi di lavoro con endpoint pubblici
Per i carichi di lavoro accessibili pubblicamente, AWS offre una serie di funzionalità e servizi che possono aiutare a mitigare determinati rischi. In questa sezione viene trattata l'autenticazione e l'autorizzazione degli utenti delle applicazioni e la protezione degli endpoint delle API.
## Autenticazione e autorizzazione
L'autenticazione si riferisce all'identità mentre l'autorizzazione si riferisce alle operazioni. Usa l'autenticazione per controllare chi può richiamare una funzione Lambda, quindi usa l'autorizzazione per controllare cosa può fare. Per molte applicazioni, IAM è sufficiente per gestire entrambi i meccanismi di controllo.
Per le applicazioni con utenti esterni, come le applicazioni Web o per dispositivi mobili, è comune utilizzare [JSON Web Tokens](https://jwt.io/introduction/) (JWT) per gestire l'autenticazione e l'autorizzazione. A differenza della tradizionale gestione delle password basata su server, i JWT vengono trasmessi dal client a ogni richiesta. Sono un modo sicuro dal punto di vista della crittografia per verificare l'identità e le affermazioni utilizzando i dati trasmessi dal client. Per le applicazioni basate su Lambda, ciò consente di proteggere ogni chiamata a ciascun endpoint API senza fare affidamento su un server centrale per l'autenticazione.
Puoi [implementare JWTS con Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), un servizio di directory utente in grado di gestire la registrazione, l'autenticazione, il ripristino dell'account e altre operazioni comuni di gestione degli account. [Framework Amplify](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) fornisce librerie per semplificare l'integrazione di questo servizio nell'applicazione frontend. Puoi anche utilizzare servizi di partner di terze parti come [Auth0](https://auth0.com/).
Dato il ruolo fondamentale di sicurezza di un servizio di provider di identità, è importante utilizzare strumenti professionali per salvaguardare l'applicazione. Non è consigliabile creare servizi personalizzati per gestire l'autenticazione o l'autorizzazione. Qualsiasi vulnerabilità nelle librerie personalizzate può avere implicazioni significative per la sicurezza del carico di lavoro e dei relativi dati.
## Protezione degli endpoint API
Per le applicazioni serverless, il modo preferito per servire pubblicamente un'applicazione di backend consiste nell'utilizzare Gateway Amazon API. Ciò può aiutarti a proteggere un'API da utenti malintenzionati o da picchi di traffico.
API Gateway offre due tipi di endpoint per gli sviluppatori serverless: [REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) e [API HTTP](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). Entrambi supportano [l'autorizzazione tramite Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), IAM o Amazon Cognito. Quando si utilizza IAM o Amazon Cognito, le richieste in entrata vengono valutate e se mancano di un token richiesto o contengono un'autenticazione non valida, la richiesta viene rifiutata. Queste richieste non ti vengono addebitate e non vengono conteggiate ai fini delle quote di limitazione.
Le route API non autenticate sono accessibili da chiunque sulla rete Internet pubblica, quindi si consiglia di limitare l'uso di API non autenticate. Se è necessario utilizzare API non autenticate, è importante proteggerle da rischi comuni, come gli attacchi [denial-of-service](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS). L'applicazione di WAF a queste API può aiutare a proteggere l'applicazione da attacchi di iniezione SQL e cross-site scripting (XSS). API Gateway implementa anche la [limitazione](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) a livello di account AWS e per client quando vengono utilizzate le chiavi API.
In molti casi, la funzionalità fornita da un'API non autenticata può essere ottenuta con un approccio alternativo. Ad esempio, un'applicazione Web può fornire un elenco di negozi al dettaglio dei clienti da una tabella DynamoDB agli utenti che non hanno effettuato l'accesso. Questa richiesta può provenire da un'applicazione Web frontend o da qualsiasi altra fonte che richiama l'endpoint URL. Questo diagramma mette a confronto tre soluzioni:
![\[operazioni di sicurezza (figura 5)\]](http://docs.aws.amazon.com/it_it/lambda/latest/dg/images/security-ops-figure-5.png)
1. Questa API non autenticata può essere chiamata da chiunque su Internet. In un attacco Denial of Service, è possibile esaurire i limiti di limitazione delle API, la simultaneità di Lambda o la capacità di lettura fornita da DynamoDB su una tabella sottostante.
1. Una distribuzione CloudFront davanti all'endpoint dell'API con una configurazione [time-to-live (TTL)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) appropriata assorbirebbe la maggior parte del traffico in un attacco DoS, senza modificare la soluzione sottostante per il recupero dei dati.
1. In alternativa, per i dati statici che cambiano raramente, la distribuzione CloudFront potrebbe servire i dati da un bucket Amazon S3.
# Utilizzo della firma del codice per verificare l'integrità del codice con Lambda
La firma del codice consente di garantire che solo il codice attendibile venga eseguito nelle funzioni Lambda. Utilizzando AWS Signer, puoi creare pacchetti di codice con firma digitale per le tue funzioni. Quando [aggiungi una configurazione di firma del codice a una funzione](configuration-codesigning-create.md), Lambda verifica che tutte le nuove implementazioni di codice siano firmate da una fonte attendibile. Poiché i controlli di convalida della firma del codice vengono eseguiti al momento dell’implementazione, non vi è alcun impatto sull'esecuzione delle funzioni.
**Importante**
Le configurazioni di firma del codice impediscono solo nuove implementazioni di codice non firmato. Se aggiungi una configurazione di firma del codice a una funzione esistente con codice non firmato, tale codice continua a funzionare finché non distribuisci un nuovo pacchetto di codice.
Quando attivi la firma del codice per una funzione, tutti i [livelli](chapter-layers.md) aggiunti alla funzione devono essere firmati anche da uno dei profili di firma consentiti.
Non sono previsti costi aggiuntivi per l'utilizzo AWS Signer o la firma del codice. AWS Lambda
## Convalida della firma
Lambda esegue i seguenti controlli di convalida quando si distribuisce un pacchetto di codice firmato alla funzione:
1. **Integrità**: convalida che il pacchetto di codice non sia stato modificato dopo la firma. Lambda confronta l'hash del pacchetto con l'hash della firma.
1. **Scadenza**: convalida che la firma del pacchetto di codice non sia scaduta.
1. **Mancata corrispondenza**: convalida che il pacchetto di codice sia firmato con un profilo di firma consentiti.
1. **Revoca**: convalida che la firma del pacchetto di codice non sia stata revocata.
Quando crei una configurazione di firma del codice, puoi utilizzare il [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment)parametro per specificare come Lambda deve rispondere se i controlli di scadenza, mancata corrispondenza o revoca falliscono. Puoi scegliere una di queste azioni:
+ `Warn`: è l'impostazione predefinita. Lambda consente l’implementazione del pacchetto di codice, ma emette un avviso. Lambda emette un nuovo CloudWatch parametro Amazon (`SignatureValidationErrors`) e memorizza anche l'avviso nel registro. CloudTrail
+ `Enforce`: Lambda emette un avviso (lo stesso dell'azione `Warn`) e blocca l’implementazione del pacchetto di codice.
**Topics**
+ [
## Convalida della firma
](#config-codesigning-valid)
+ [
# Creazione di configurazioni di firma del codice per Lambda
](configuration-codesigning-create.md)
+ [
# Configurazione delle policy IAM per le configurazioni di firma del codice Lambda
](config-codesigning-policies.md)
+ [
# Utilizzo di tag nelle configurazioni di firma del codice
](tags-csc.md)
# Creazione di configurazioni di firma del codice per Lambda
Per abilitare la firma del codice per una funzione, creare una *configurazione di firma del codice* e collegarla alla funzione. Una configurazione di firma del codice definisce un elenco di profili di firma consentiti e le operazioni delle policy da eseguire in caso di esito negativo dei controlli di convalida.
**Nota**
Le funzioni definite come immagini di container non supportano la firma del codice.
**Topics**
+ [
## Prerequisiti di configurazione
](#config-codesigning-prereqs)
+ [
## Creazione delle configurazioni di firma del codice
](#config-codesigning-config-console)
+ [
## Abilitazione della firma del codice per una funzione
](#config-codesigning-function-console)
## Prerequisiti di configurazione
Prima di configurare la firma del codice per una funzione Lambda, utilizzare AWS Signer per effettuare le seguenti operazioni:
+ Creare uno o più [profili di firma](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html).
+ Utilizzare un profilo di firma per [creare un pacchetto di codice firmato per la funzione](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html).
## Creazione delle configurazioni di firma del codice
Una configurazione di firma del codice definisce un elenco di profili di firma consentiti e la policy di convalida della firma.
**Per creare una configurazione di firma del codice (console)**
1. Aprire la pagina [Configurazioni di firma del codice](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) della console Lambda.
1. Scegli **Crea configurazione**.
1. In **Description (Descrizione)**, immettere un nome descrittivo per la configurazione.
1. In **Signing profiles (Profili di firma)** aggiungere fino a 20 profili di firma alla configurazione.
1. Per **l'ARN della versione del profilo di firma**, scegliere l'ARN (Amazon Resource Name) di una versione del profilo oppure inserire l'ARN.
1. Per aggiungere un profilo di firma aggiuntivo, scegliere **Add signing profiles (Aggiungi profili di firma)**.
1. In **Signature validation policy (Policy di convalida della firma)**, scegliere **Warn (Avvisa)** o **Enforce (Applica)**.
1. Scegli **Crea configurazione**.
## Abilitazione della firma del codice per una funzione
Per abilitare la firma del codice per una funzione, aggiungi una configurazione di firma del codice alla funzione.
**Importante**
Le configurazioni di firma del codice impediscono solo nuove implementazioni di codice non firmato. Se aggiungi una configurazione di firma del codice a una funzione esistente con codice non firmato, tale codice continua a funzionare finché non distribuisci un nuovo pacchetto di codice.
**Per associare una configurazione di firma del codice a una funzione (console)**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere la funzione per la quale si desidera abilitare la firma del codice.
1. Apri la scheda **Configurazione**.
1. Scorri verso il basso e scegli **Firma del codice**.
1. Scegli **Modifica**.
1. In **Edit code signing (Modifica della firma del codice)**, scegliere una configurazione di firma del codice per questa funzione.
1. Selezionare **Salva**.
# Configurazione delle policy IAM per le configurazioni di firma del codice Lambda
Per concedere l'autorizzazione a un utente di accedere alle operazioni dell'API di firma del codice Lambda, allegare una o più istruzioni delle policy alla policy dell'utente. Per ulteriori informazioni sulle policy utente, consulta [Policy IAM basate sull'identità per Lambda](access-control-identity-based.md).
La seguente istruzione di policy di esempio concede l'autorizzazione per creare, aggiornare e recuperare le configurazioni di firma del codice.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
Gli amministratori possono utilizzare la chiave di condizione `CodeSigningConfigArn` per specificare le configurazioni di firma del codice che gli sviluppatori devono utilizzare per creare o aggiornare le funzioni.
La seguente istruzione di policy di esempio concede l'autorizzazione per creare una funzione. La dichiarazione di policy include una condizione `lambda:CodeSigningConfigArn` per specificare la configurazione di firma del codice consentita. Lambda blocca le richieste `CreateFunction` API se il [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn)parametro manca o non corrisponde al valore nella condizione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# Utilizzo di tag nelle configurazioni di firma del codice
Puoi contrassegnare le configurazioni di firma del codice per organizzare e gestire le risorse. I tag sono coppie chiave-valore a forma libera associate alle risorse supportate su Servizi AWS. Per ulteriori informazioni sui casi d'uso dei tag, consulta [Strategie di tagging comuni nella Guida AWS](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) *alle risorse di etichettatura e all'editor di tag*.
Puoi utilizzare l' AWS Lambda API per visualizzare e aggiornare i tag. Puoi anche visualizzare e aggiornare i tag mentre gestisci una configurazione specifica di firma del codice nella console Lambda.
**Topics**
+ [
## Autorizzazioni necessarie per lavorare con i tag
](#csc-tags-required-permissions)
+ [
## Utilizzo di tag con la console Lambda
](#tags-csc-console)
+ [
## Usare i tag con AWS CLI
](#tags-csc-cli)
## Autorizzazioni necessarie per lavorare con i tag
Per consentire a un'identità AWS Identity and Access Management (IAM) (utente, gruppo o ruolo) di leggere o impostare tag su una risorsa, concedile le autorizzazioni corrispondenti:
+ **lambda: ListTags** —Quando una risorsa ha dei tag, concedi questa autorizzazione a chiunque debba richiamarla`ListTags`. Per le funzioni con tag, questa autorizzazione è necessaria anche per `GetFunction`.
+ **lambda: TagResource** —Concedi questa autorizzazione a chiunque abbia bisogno di chiamare `TagResource` o eseguire un tag durante la creazione.
Facoltativamente, valuta la possibilità di concedere anche l'UntagResourceautorizzazione **lambda:** per consentire `UntagResource` le chiamate alla risorsa.
Per ulteriori informazioni, consulta [Policy IAM basate sull'identità per Lambda](access-control-identity-based.md).
## Utilizzo di tag con la console Lambda
Puoi utilizzare la console Lambda per creare configurazioni di firma del codice che hanno tag, aggiungere tag a configurazioni di firma del codice esistenti e filtrare le configurazioni di firma del codice per tag.
**Per aggiungere un tag durante la creazione di una configurazione di firma del codice**
1. Apri la pagina [Configurazioni di firma del codice](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) della console Lambda.
1. Dall'intestazione del riquadro dei contenuti, scegli **Crea configurazione**.
1. Nella sezione nella parte superiore del riquadro dei contenuti, configura la configurazione di firma del codice. Per ulteriori informazioni sull'impostazione delle configurazione di firma del codice, consulta [Utilizzo della firma del codice per verificare l'integrità del codice con Lambda](configuration-codesigning.md).
1. Nella sezione **Tag**, seleziona **Aggiungi nuovo tag**.
1. Nel campo **Chiave**, inserisci la chiave del tag. Per informazioni sulle restrizioni relative ai tag, consulta [Limiti e requisiti di denominazione dei tag nella Guida alle risorse di etichettatura e](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) all'editor di *tag AWS *.
1. Scegli **Crea configurazione**.
**Per aggiungere un tag a una configurazione di firma del codice esistente**
1. Apri la pagina [Configurazioni di firma del codice](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) della console Lambda.
1. Scegli il nome della configurazione di firma del codice.
1. Nelle schede sotto il riquadro **Dettagli**, scegli **Tag**.
1. Scegliere **Gestisci tag**.
1. Scegliere **Aggiungi nuovo tag**.
1. Nel campo **Chiave**, inserisci la chiave del tag. Per informazioni sulle restrizioni relative ai tag, consulta [Limiti e requisiti di denominazione dei tag nella Guida alle risorse di etichettatura e](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) all'editor di *tag AWS *.
1. Scegli **Save** (Salva).
**Per filtrare le configurazioni di firma del codice per tag**
1. Apri la pagina [Configurazioni di firma del codice](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) della console Lambda.
1. Scegli la barra di ricerca.
1. Dall'elenco a discesa, seleziona il tag sotto il sottotitolo **Tag**.
1. Seleziona **Usa: "nome-tag"** per vedere tutte le configurazioni di firma del codice etichettate con questa chiave, oppure scegli un **operatore** per filtrare ulteriormente in base al valore.
1. Seleziona il valore del tag da filtrare in base a una combinazione di chiave e valore del tag.
La barra di ricerca supporta anche la ricerca di chiavi di tag. Immetti il nome di una chiave per trovarla nell'elenco.
## Usare i tag con AWS CLI
Puoi aggiungere e rimuovere tag sulle risorse Lambda esistenti, incluse le configurazioni di firma del codice, con l'API Lambda. Puoi aggiungere i tag anche quando crei una configurazione di firma del codice, che ti consente di mantenere etichettata una risorsa per tutto il suo ciclo di vita.
### Aggiornamento dei tag con il tag Lambda APIs
Puoi aggiungere e rimuovere tag per le risorse Lambda supportate tramite le operazioni [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)e [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API.
Puoi chiamare queste operazioni tramite la AWS CLI. Per aggiungere i tag a una risorsa esistente, utilizza il comando `tag-resource`. Questo esempio aggiunge due tag, uno con la chiave *Department* e uno con la chiave*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Pr rimuovere i tag, utilizza il comando `untag-resource`. Questo esempio rimuove il tag con la chiave*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Aggiunta di tag durante la creazione di una configurazione di firma del codice
Per creare una nuova configurazione di firma del codice Lambda con tag, usa l'operazione [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html)API. Specifica il parametro `Tags`. È possibile richiamare questa operazione con il `create-code-signing-config` AWS CLI comando e l'`--tags`opzione. *Per ulteriori informazioni sul comando CLI, vedere [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)nel Command Reference AWS CLI .*
Prima di utilizzare il parametro `Tags` con `CreateCodeSigningConfig`, assicurati che il tuo ruolo disponga dell'autorizzazione per etichettare le risorse oltre alle normali autorizzazioni necessarie per questa operazione. Per ulteriori informazioni sulle autorizzazioni per il tagging, consulta [Autorizzazioni necessarie per lavorare con i tag](#csc-tags-required-permissions).
### Visualizzazione dei tag con il tag Lambda APIs
Per visualizzare i tag applicati a una risorsa Lambda specifica, utilizza l'operazione API `ListTags`. Per ulteriori informazioni, consulta [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Puoi richiamare questa operazione con il `list-tags` AWS CLI comando fornendo un ARN (Amazon Resource Name).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtro delle risorse per tag
Puoi utilizzare l'operazione AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API per filtrare le tue risorse in base ai tag. L'operazione `GetResources` riceve fino a 10 filtri, ognuno dei quali contenente una chiave di tag e un massimo di 10 valori di tag. Fornisci `GetResources` con un `ResourceType` per filtrare in base a tipi di risorse specifiche.
È possibile richiamare questa operazione utilizzando il `get-resources` AWS CLI comando. Per esempi di utilizzo di `get-resources`, consulta [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) nella *Riferimento ai comandi CLI di AWS *.