Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -58,9 +58,9 @@ Entra ID è un servizio di **gestione dell'identità e degli accessi basato su c
 
 ### Servizi di Dominio Entra (precedentemente Azure AD DS)
 
-I Servizi di Dominio Entra estendono le capacità di Entra ID offrendo **servizi di dominio gestiti compatibili con ambienti tradizionali di Windows Active Directory**. Supporta protocolli legacy come LDAP, Kerberos e NTLM, consentendo alle organizzazioni di migrare o eseguire applicazioni più vecchie nel cloud senza dover distribuire controller di dominio on-premises. Questo servizio supporta anche le Group Policy per la gestione centralizzata, rendendolo adatto a scenari in cui carichi di lavoro legacy o basati su AD devono coesistere con ambienti cloud moderni.
+I Servizi di Dominio Entra estendono le capacità di Entra ID offrendo **servizi di dominio gestiti compatibili con ambienti tradizionali di Windows Active Directory**. Supporta protocolli legacy come LDAP, Kerberos e NTLM, consentendo alle organizzazioni di migrare o eseguire applicazioni più vecchie nel cloud senza dover implementare controller di dominio on-premises. Questo servizio supporta anche le Group Policy per la gestione centralizzata, rendendolo adatto a scenari in cui carichi di lavoro legacy o basati su AD devono coesistere con ambienti cloud moderni.
 
-## Principali Entra ID
+## Principali di Entra ID
 
 ### Utenti
 
@@ -96,7 +96,7 @@ Puoi controllarli in [https://learn.microsoft.com/en-us/entra/fundamentals/users
 - Registrare Applicazioni: Predefinito **Sì**
 - Limitare gli utenti non amministratori dalla creazione di tenant: Predefinito **No**
 - Creare gruppi di sicurezza: Predefinito **Sì**
-- Limitare l'accesso al portale di amministrazione di Microsoft Entra: Predefinito **No**
+- Limitare l'accesso al portale di amministrazione Microsoft Entra: Predefinito **No**
 - Questo non limita l'accesso API al portale (solo web)
 - Consentire agli utenti di collegare l'account di lavoro o scolastico con LinkedIn: Predefinito **Sì**
 - Mostra mantenere l'utente connesso: Predefinito **Sì**
@@ -108,11 +108,11 @@ Puoi controllarli in [https://learn.microsoft.com/en-us/entra/fundamentals/users
 - **Gli utenti ospiti hanno accesso limitato alle proprietà e alle appartenenze degli oggetti di directory (predefinito)**. Questo limita l'accesso degli ospiti solo al proprio profilo utente per impostazione predefinita. L'accesso ad altre informazioni sugli utenti e sui gruppi non è più consentito.
 - **L'accesso degli utenti ospiti è limitato alle proprietà e alle appartenenze dei propri oggetti di directory** è la più restrittiva.
 - **Opzioni di invito per gli ospiti**:
-- **Chiunque nell'organizzazione può invitare utenti ospiti, compresi ospiti e non amministratori (la più inclusiva) - Predefinito**
-- **Gli utenti membri e gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti, compresi gli ospiti con permessi di membro**
+- **Chiunque nell'organizzazione può invitare utenti ospiti, inclusi ospiti e non amministratori (la più inclusiva) - Predefinito**
+- **Gli utenti membri e gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti, inclusi ospiti con permessi di membro**
 - **Solo gli utenti assegnati a ruoli amministrativi specifici possono invitare utenti ospiti**
-- **Nessuno nell'organizzazione può invitare utenti ospiti, compresi gli amministratori (la più restrittiva)**
-- **Uscita di utenti esterni**: Predefinito **Vero**
+- **Nessuno nell'organizzazione può invitare utenti ospiti, inclusi gli amministratori (la più restrittiva)**
+- **Uscita degli utenti esterni**: Predefinito **Vero**
 - Consentire agli utenti esterni di lasciare l'organizzazione
 
 > [!TIP]
@@ -149,7 +149,7 @@ Una **Registrazione App** è una configurazione che consente a un'applicazione d
 1. **ID Applicazione (Client ID):** Un identificatore unico per la tua app in Azure AD.
 2. **URI di Reindirizzamento:** URL dove Azure AD invia le risposte di autenticazione.
 3. **Certificati, Segreti e Credenziali Federate:** È possibile generare un segreto o un certificato per accedere come il principio di servizio dell'applicazione, o per concedere accesso federato ad essa (ad es. Github Actions).
-1. Se viene generato un **certificato** o un **segreto**, è possibile per una persona **accedere come il principio di servizio** con strumenti CLI conoscendo l'**ID dell'applicazione**, il **segreto** o il **certificato** e il **tenant** (dominio o ID).
+1. Se viene generato un **certificato** o un **segreto**, è possibile che una persona **acceda come il principio di servizio** con strumenti CLI conoscendo l'**ID applicazione**, il **segreto** o il **certificato** e il **tenant** (dominio o ID).
 4. **Permessi API:** Specifica quali risorse o API l'app può accedere.
 5. **Impostazioni di Autenticazione:** Definisce i flussi di autenticazione supportati dall'app (ad es., OAuth2, OpenID Connect).
 6. **Principio di Servizio**: Un principio di servizio viene creato quando viene creata un'App (se fatto dalla console web) o quando viene installata in un nuovo tenant.
@@ -161,21 +161,21 @@ Una **Registrazione App** è una configurazione che consente a un'applicazione d
 
 - **Non consentire il consenso dell'utente**
 - Sarà richiesto un amministratore per tutte le app.
-- **Consentire il consenso dell'utente per le app di editori verificati, per permessi selezionati (Consigliato)**
-- Tutti gli utenti possono dare consenso per permessi classificati come "basso impatto", per app di editori verificati o app registrate in questa organizzazione.
+- **Consentire il consenso dell'utente per app di editori verificati, app interne e app che richiedono solo permessi selezionati (Consigliato)**
+- Tutti gli utenti possono consentire app che richiedono solo permessi classificati come "basso impatto", app di editori verificati e app registrate nel tenant.
 - **Permessi a basso impatto predefiniti** (anche se è necessario accettare per aggiungerli come bassi):
 - User.Read - accedi e leggi il profilo utente
 - offline_access - mantieni l'accesso ai dati a cui gli utenti hanno dato accesso
 - openid - accedi gli utenti
 - profile - visualizza il profilo di base dell'utente
 - email - visualizza l'indirizzo email dell'utente
-- **Consentire il consenso dell'utente per le app (Predefinito)**
-- Tutti gli utenti possono dare consenso per qualsiasi app per accedere ai dati dell'organizzazione.
+- **Consentire il consenso dell'utente per app (Predefinito)**
+- Tutti gli utenti possono consentire a qualsiasi app di accedere ai dati dell'organizzazione.
 
 **Richieste di consenso dell'amministratore**: Predefinito **No**
 
-- Gli utenti possono richiedere il consenso dell'amministratore per app a cui non possono dare consenso
-- Se **Sì**: È possibile indicare Utenti, Gruppi e Ruoli che possono dare consenso alle richieste
+- Gli utenti possono richiedere il consenso dell'amministratore per app a cui non possono consentire
+- Se **Sì**: È possibile indicare Utenti, Gruppi e Ruoli che possono consentire richieste
 - Configura anche se gli utenti riceveranno notifiche via email e promemoria di scadenza
 
 ### **Identità Gestite (Metadati)**
@@ -184,16 +184,16 @@ Le identità gestite in Azure Active Directory offrono una soluzione per **gesti
 
 Ci sono due tipi di identità gestite:
 
-- **Assegnate al sistema**. Alcuni servizi Azure consentono di **abilitare un'identità gestita direttamente su un'istanza di servizio**. Quando abiliti un'identità gestita assegnata al sistema, viene creato un **principio di servizio** nel tenant Entra ID fidato dalla sottoscrizione in cui si trova la risorsa. Quando la **risorsa** viene **eliminata**, Azure elimina automaticamente **l'identità** per te.
+- **Assegnate al sistema**. Alcuni servizi Azure ti consentono di **abilitare un'identità gestita direttamente su un'istanza di servizio**. Quando abiliti un'identità gestita assegnata al sistema, viene creato un **principio di servizio** nel tenant Entra ID fidato dalla sottoscrizione in cui si trova la risorsa. Quando la **risorsa** viene **eliminata**, Azure elimina automaticamente **l'identità** per te.
 - **Assegnate dall'utente**. È anche possibile per gli utenti generare identità gestite. Queste vengono create all'interno di un gruppo di risorse all'interno di una sottoscrizione e verrà creato un principio di servizio nel tenant EntraID fidato dalla sottoscrizione. Poi, puoi assegnare l'identità gestita a una o **più istanze** di un servizio Azure (risorse multiple). Per le identità gestite assegnate dall'utente, **l'identità è gestita separatamente dalle risorse che la utilizzano**.
 
-Le identità gestite **non generano credenziali eterne** (come password o certificati) per accedere come il principio di servizio ad esse collegato.
+Le Identità Gestite **non generano credenziali eterne** (come password o certificati) per accedere come il principio di servizio ad essa associato.
 
 ### Applicazioni Aziendali
 
-È solo un **tabella in Azure per filtrare i principi di servizio** e controllare le applicazioni che sono state assegnate.
+È solo una **tabella in Azure per filtrare i principi di servizio** e controllare le applicazioni che sono state assegnate.
 
-**Non è un altro tipo di “applicazione”,** non c'è alcun oggetto in Azure che sia un “Applicazione Aziendale”, è solo un'astrazione per controllare i Principi di servizio, le Registrazioni App e le identità gestite.
+**Non è un altro tipo di “applicazione”**, non c'è alcun oggetto in Azure che sia un “Applicazione Aziendale”, è solo un'astrazione per controllare i Principi di servizio, le Registrazioni App e le identità gestite.
 
 ### Unità Amministrative
 
@@ -212,18 +212,18 @@ Esempio:
 - Concedi il ruolo di "Amministratore Utente" al personale IT regionale, limitato all'AU della loro regione.
 - Risultato: Gli amministratori IT regionali possono gestire gli account utente all'interno della loro regione senza influenzare altre regioni.
 
-### Ruoli e Permessi Entra ID
+### Ruoli e Permessi di Entra ID
 
-- Per gestire Entra ID ci sono alcuni **ruoli predefiniti** che possono essere assegnati ai principi Entra ID per gestire Entra ID
+- Per gestire Entra ID ci sono alcuni **ruoli predefiniti** che possono essere assegnati ai principi di Entra ID per gestire Entra ID
 - Controlla i ruoli in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
 - I ruoli contrassegnati come **`PRIVILEGIATI`** da EntraID dovrebbero essere assegnati con cautela perché, come spiega Microsoft [nei documenti](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): Le assegnazioni di ruolo privilegiato possono portare a un'elevazione dei privilegi se non utilizzate in modo sicuro e previsto.
 - Il ruolo più privilegiato è **Amministratore Globale**
 - I ruoli raggruppano **permessi granulari** e possono essere trovati nelle loro descrizioni.
 - È possibile **creare ruoli personalizzati** con i permessi desiderati. Anche se per qualche motivo non tutti i permessi granulari sono disponibili per gli amministratori per creare ruoli personalizzati.
-- I ruoli in Entra ID sono completamente **indipendenti** dai ruoli in Azure. L'unica relazione è che i principi con il ruolo di **Amministratore Globale** in Entra ID possono elevare al ruolo di **Amministratore Accesso Utente** in Azure.
-- Non è **possibile utilizzare caratteri jolly** nei ruoli Entra ID.
+- I ruoli in Entra ID sono completamente **indipendenti** dai ruoli in Azure. L'unica relazione è che i principi con il ruolo **Amministratore Globale** in Entra ID possono elevare al ruolo di **Amministratore Accesso Utente** in Azure.
+- Non è **possibile utilizzare caratteri jolly** nei ruoli di Entra ID.
 
-## Ruoli e Permessi Azure
+## Ruoli e Permessi di Azure
 
 - **Ruoli** sono **assegnati** ai **principi** su un **ambito**: `principle -[HAS ROLE]->(scope)`
 - **Ruoli** assegnati a **gruppi** sono **ereditati** da tutti i **membri** del gruppo.
@@ -310,13 +310,13 @@ Secondo **[la documentazione](https://learn.microsoft.com/en-us/azure/role-based
 
 ### Assegnazioni di Negazione
 
-Proprio come le assegnazioni di ruolo, le **assegnazioni di negazione** vengono utilizzate per **controllare l'accesso alle risorse di Azure**. Tuttavia, le **assegnazioni di negazione** vengono utilizzate per **negare esplicitamente l'accesso** a una risorsa, anche se a un utente è stato concesso l'accesso tramite un'assegnazione di ruolo. Le **assegnazioni di negazione** hanno la precedenza sulle **assegnazioni di ruolo**, il che significa che se a un utente è concesso l'accesso tramite un'assegnazione di ruolo ma gli viene anche negato esplicitamente l'accesso tramite un'assegnazione di negazione, l'assegnazione di negazione avrà la precedenza.
+Proprio come le assegnazioni di ruolo, le **assegnazioni di negazione** sono utilizzate per **controllare l'accesso alle risorse di Azure**. Tuttavia, le **assegnazioni di negazione** sono utilizzate per **negare esplicitamente l'accesso** a una risorsa, anche se a un utente è stato concesso l'accesso tramite un'assegnazione di ruolo. Le **assegnazioni di negazione** hanno la precedenza sulle **assegnazioni di ruolo**, il che significa che se a un utente è concesso l'accesso tramite un'assegnazione di ruolo ma viene anche esplicitamente negato l'accesso tramite un'assegnazione di negazione, l'assegnazione di negazione avrà la precedenza.
 
 Proprio come le assegnazioni di ruolo, le **assegnazioni di negazione** vengono applicate su un certo ambito che indica i principali interessati e i permessi che vengono negati. Inoltre, nel caso delle assegnazioni di negazione, è possibile **prevenire che la negazione venga ereditata** dalle risorse figlie.
 
 ### Politiche di Azure
 
-Le **Politiche di Azure** sono regole che aiutano le organizzazioni a garantire che le loro risorse soddisfino standard specifici e requisiti di conformità. Consentono di **applicare o auditare impostazioni sulle risorse in Azure**. Ad esempio, puoi impedire la creazione di macchine virtuali in una regione non autorizzata o garantire che tutte le risorse abbiano tag specifici per il tracciamento.
+Le **Politiche di Azure** sono regole che aiutano le organizzazioni a garantire che le loro risorse soddisfino standard specifici e requisiti di conformità. Consentono di **applicare o auditare le impostazioni sulle risorse in Azure**. Ad esempio, puoi impedire la creazione di macchine virtuali in una regione non autorizzata o garantire che tutte le risorse abbiano tag specifici per il tracciamento.
 
 Le Politiche di Azure sono **proattive**: possono impedire la creazione o la modifica di risorse non conformi. Sono anche **reattive**, consentendo di trovare e correggere risorse non conformi esistenti.
 
@@ -325,7 +325,7 @@ Le Politiche di Azure sono **proattive**: possono impedire la creazione o la mod
 1. **Definizione della Politica**: Una regola, scritta in JSON, che specifica cosa è consentito o richiesto.
 2. **Assegnazione della Politica**: L'applicazione di una politica a un ambito specifico (ad es., sottoscrizione, gruppo di risorse).
 3. **Iniziative**: Una raccolta di politiche raggruppate per un'applicazione più ampia.
-4. **Effetto**: Specifica cosa succede quando la politica viene attivata (ad es., "Negare", "Audit" o "Aggiungere").
+4. **Effetto**: Specifica cosa succede quando la politica viene attivata (ad es., "Negare", "Audit", o "Aggiungere").
 
 **Alcuni esempi:**
 
@@ -338,7 +338,7 @@ Le Politiche di Azure sono **proattive**: possono impedire la creazione o la mod
 
 Nota che le Politiche di Azure possono essere collegate a qualsiasi livello della gerarchia di Azure, ma sono **comunemente utilizzate nel gruppo di gestione radice** o in altri gruppi di gestione.
 
-Esempio di json della politica di Azure:
+Esempio di json di politica di Azure:
 ```json
 {
 "policyRule": {
@@ -356,7 +356,7 @@ Esempio di json della politica di Azure:
 "mode": "All"
 }
 ```
-### Ereditarietà dei Permessi
+### Ereditarietà dei permessi
 
 In Azure **i permessi possono essere assegnati a qualsiasi parte della gerarchia**. Questo include gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse individuali. I permessi sono **ereditati** dalle **risorse** contenute nell'entità a cui sono stati assegnati.
 
@@ -366,10 +366,10 @@ Questa struttura gerarchica consente una gestione efficiente e scalabile dei per
 
 ### Azure RBAC vs ABAC
 
-**RBAC** (controllo accessi basato su ruoli) è ciò che abbiamo già visto nelle sezioni precedenti: **Assegnare un ruolo a un principale per concedergli accesso** a una risorsa.\
+**RBAC** (controllo degli accessi basato sui ruoli) è ciò che abbiamo già visto nelle sezioni precedenti: **Assegnare un ruolo a un principale per concedergli accesso** a una risorsa.\
 Tuttavia, in alcuni casi potresti voler fornire una **gestione degli accessi più dettagliata** o **semplificare** la gestione di **centinaia** di **assegnazioni** di ruolo.
 
-Azure **ABAC** (controllo accessi basato su attributi) si basa su Azure RBAC aggiungendo **condizioni di assegnazione del ruolo basate su attributi** nel contesto di azioni specifiche. Una _condizione di assegnazione del ruolo_ è un **controllo aggiuntivo che puoi opzionalmente aggiungere alla tua assegnazione di ruolo** per fornire un controllo degli accessi più dettagliato. Una condizione filtra i permessi concessi come parte della definizione del ruolo e dell'assegnazione del ruolo. Ad esempio, puoi **aggiungere una condizione che richiede a un oggetto di avere un tag specifico per leggere l'oggetto**.\
+Azure **ABAC** (controllo degli accessi basato sugli attributi) si basa su Azure RBAC aggiungendo **condizioni di assegnazione del ruolo basate su attributi** nel contesto di azioni specifiche. Una _condizione di assegnazione del ruolo_ è un **controllo aggiuntivo che puoi opzionalmente aggiungere alla tua assegnazione di ruolo** per fornire un controllo degli accessi più dettagliato. Una condizione filtra i permessi concessi come parte della definizione del ruolo e dell'assegnazione del ruolo. Ad esempio, puoi **aggiungere una condizione che richiede a un oggetto di avere un tag specifico per leggere l'oggetto**.\
 Non **puoi** esplicitamente **negare** **l'accesso** a risorse specifiche **utilizzando condizioni**.
 
 ## Riferimenti