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à. # 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.