Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

src/pentesting-cloud/azure-security/az-services/az-function-apps.md

@@ -9,7 +9,7 @@
 > [!NOTE]
 > Nota che **le Funzioni sono un sottoinsieme dei Servizi App**, quindi molte delle funzionalità discusse qui saranno utilizzate anche dalle applicazioni create come Azure Apps (`webapp` in cli).
 
-### Piani Differenti
+### Piani Diversi
 
 - **Piano di Consumo Flessibile**: Offre **scalabilità dinamica e basata su eventi** con prezzi pay-as-you-go, aggiungendo o rimuovendo istanze di funzione in base alla domanda. Supporta **rete virtuale** e **istanze pre-provisionate** per ridurre i cold start, rendendolo adatto per **carichi di lavoro variabili** che non richiedono supporto per container.
 - **Piano di Consumo Tradizionale**: L'opzione serverless predefinita, dove **si paga solo per le risorse di calcolo quando le funzioni vengono eseguite**. Si scala automaticamente in base agli eventi in arrivo e include **ottimizzazioni per i cold start**, ma non supporta le distribuzioni di container. Ideale per **carichi di lavoro intermittenti** che richiedono scalabilità automatica.
@@ -36,7 +36,7 @@ Nota che le Funzioni consentono anche di memorizzare il codice in una posizione
 
 Utilizzando un trigger HTTP:
 
-- È possibile dare **accesso a una funzione da tutto Internet** senza richiedere alcuna autenticazione o dare accesso basato su IAM. Sebbene sia anche possibile limitare questo accesso.
+- È possibile dare **accesso a una funzione da tutto Internet** senza richiedere alcuna autenticazione o dare accesso basato su IAM. Anche se è possibile limitare questo accesso.
 - È anche possibile **dare o limitare l'accesso** a una Function App da **una rete interna (VPC)**.
 
 > [!CAUTION]
@@ -58,10 +58,10 @@ In una **funzione Windows** che utilizza NodeJS il codice si trovava in **`C:\ho
 
 Proprio come [**VM**](vms/index.html), le Funzioni possono avere **Identità Gestite** di 2 tipi: Assegnate dal sistema e Assegnate dall'utente.
 
-L'**identità assegnata dal sistema** sarà un'identità gestita che **solo la funzione** a cui è assegnata potrà utilizzare, mentre le **identità gestite assegnate dall'utente** sono identità gestite che **qualsiasi altro servizio Azure potrà utilizzare**.
+L'**identità assegnata dal sistema** sarà un'identità gestita che **solo la funzione** che l'ha assegnata potrà utilizzare, mentre le **identità gestite assegnate dall'utente** sono identità gestite che **qualsiasi altro servizio Azure potrà utilizzare**.
 
 > [!NOTE]
-> Proprio come in [**VM**](vms/index.html), le Funzioni possono avere **1 identità gestita assegnata dal sistema** e **diverse identità assegnate dall'utente**, quindi è sempre importante cercare di trovare tutte se comprometti la funzione perché potresti essere in grado di aumentare i privilegi a diverse identità gestite da una sola Funzione.
+> Proprio come in [**VM**](vms/index.html), le Funzioni possono avere **1 identità gestita assegnata dal sistema** e **diverse identità assegnate dall'utente**, quindi è sempre importante cercare di trovare tutte se si compromette la funzione perché si potrebbe essere in grado di aumentare i privilegi a diverse identità gestite da una sola Funzione.
 >
 > Se non viene utilizzata un'identità gestita dal sistema ma una o più identità gestite dall'utente sono collegate a una funzione, per impostazione predefinita non sarà possibile ottenere alcun token.
 
@@ -78,14 +78,14 @@ Nota che devi trovare un modo per **controllare tutte le Identità Gestite a cui
 
 Quando si crea un endpoint all'interno di una funzione utilizzando un **trigger HTTP**, è possibile indicare il **livello di autorizzazione della chiave di accesso** necessario per attivare la funzione. Sono disponibili tre opzioni:
 
-- **ANONYMOUS**: **Tutti** possono accedere alla funzione tramite l'URL.
+- **ANONYMOUS**: **Chiunque** può accedere alla funzione tramite l'URL.
 - **FUNCTION**: L'endpoint è accessibile solo agli utenti che utilizzano una **chiave di funzione, host o master**.
 - **ADMIN**: L'endpoint è accessibile solo agli utenti con una **chiave master**.
 
 **Tipo di chiavi:**
 
-- **Chiavi di Funzione:** Le chiavi di funzione possono essere predefinite o definite dall'utente e sono progettate per concedere accesso esclusivamente a **specifici endpoint di funzione** all'interno di una Function App consentendo un accesso più dettagliato sugli endpoint.
-- **Chiavi Host:** Le chiavi host, che possono essere anch'esse predefinite o definite dall'utente, forniscono accesso a **tutti gli endpoint di funzione all'interno di una Function App con livello di accesso FUNCTION**.
+- **Chiavi di Funzione:** Le chiavi di funzione possono essere predefinite o definite dall'utente e sono progettate per concedere accesso esclusivamente a **endpoint di funzione specifici** all'interno di una Function App consentendo un accesso più dettagliato sugli endpoint.
+- **Chiavi Host:** Le chiavi host, che possono essere predefinite o definite dall'utente, forniscono accesso a **tutti gli endpoint di funzione all'interno di una Function App con livello di accesso FUNCTION**.
 - **Chiave Master:** La chiave master (`_master`) funge da chiave amministrativa che offre permessi elevati, incluso l'accesso a tutti gli endpoint di funzione (incluso il livello di accesso ADMIN). Questa **chiave non può essere revocata.**
 - **Chiavi di Sistema:** Le chiavi di sistema sono **gestite da estensioni specifiche** e sono necessarie per accedere agli endpoint webhook utilizzati dai componenti interni. Esempi includono il trigger Event Grid e le Funzioni Durature, che utilizzano chiavi di sistema per interagire in modo sicuro con le rispettive API.
 
@@ -192,7 +192,7 @@ package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
 ```
 </details>
 
-Inoltre, viene creata un'**Identità Gestita** affinché l'azione di Github del repository possa accedere ad Azure. Questo avviene generando una credenziale Federata sull'**Identità Gestita** che consente all'**Emittente** `https://token.actions.githubusercontent.com` e all'**Identificatore del Soggetto** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
+Inoltre, viene creata un'**Identità Gestita** affinché l'azione di Github del repository possa accedere ad Azure con essa. Questo avviene generando una credenziale Federata sull'**Identità Gestita** che consente all'**Emittente** `https://token.actions.githubusercontent.com` e all'**Identificatore del Soggetto** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
 
 > [!CAUTION]
 > Pertanto, chiunque comprometta quel repository sarà in grado di compromettere la funzione e le Identità Gestite ad essa collegate.