From eced58472238f5cc27c71439b85da58dfb8dd4d4 Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 21 Mar 2025 09:24:09 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA --- .../aws-basic-information/README.md | 64 +++++++++---------- .../azure-security/az-services/az-sql.md | 16 ++--- 2 files changed, 40 insertions(+), 40 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index a361f9ef0..6322ca2dd 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -24,7 +24,7 @@ Pertanto, ci sono **due tipi di account in un'organizzazione** (stiamo parlando - Abilitare l'integrazione con i servizi AWS supportati per fornire funzionalità di servizio a tutti gli account nell'organizzazione. - È possibile accedere come utente root utilizzando l'email e la password utilizzate per creare questo account/organizzazione root. -L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile del pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione. +L'account di gestione ha le **responsabilità di un account pagatore** ed è responsabile per il pagamento di tutte le spese accumulate dagli account membri. Non puoi cambiare l'account di gestione di un'organizzazione. - Gli **account membri** costituiscono tutti gli altri account in un'organizzazione. Un account può essere membro di una sola organizzazione alla volta. Puoi allegare una politica a un account per applicare controlli solo a quell'account. - Gli account membri **devono utilizzare un indirizzo email valido** e possono avere un **nome**, in generale non saranno in grado di gestire la fatturazione (ma potrebbero ricevere accesso ad essa). @@ -46,7 +46,7 @@ Questo è l'UNICO modo in cui **anche l'utente root può essere fermato** dal fa L'unico modo per bypassare questo è compromettere anche l'**account master** che configura le SCP (l'account master non può essere bloccato). > [!WARNING] -> Nota che **le SCP limitano solo i principi nell'account**, quindi altri account non sono influenzati. Ciò significa che avere una SCP che nega `s3:GetObject` non fermerà le persone dall'**accedere a un bucket S3 pubblico** nel tuo account. +> Nota che **le SCP limitano solo i principi nell'account**, quindi altri account non sono influenzati. Questo significa che avere una SCP che nega `s3:GetObject` non fermerà le persone dall'**accedere a un bucket S3 pubblico** nel tuo account. Esempi di SCP: @@ -68,12 +68,12 @@ Trova **esempi JSON** in [https://docs.aws.amazon.com/organizations/latest/userg ### Resource Control Policy (RCP) -Una **resource control policy (RCP)** è una politica che definisce le **autorizzazioni massime per le risorse all'interno della tua organizzazione AWS**. Le RCP sono simili alle politiche IAM nella sintassi ma **non concedono autorizzazioni**—limitano solo le autorizzazioni che possono essere applicate alle risorse da altre politiche. Quando si allega un RCP alla radice dell'organizzazione, a un'unità organizzativa (OU) o a un account, l'RCP limita le autorizzazioni delle risorse su tutte le risorse nell'ambito interessato. +Una **resource control policy (RCP)** è una politica che definisce le **autorizzazioni massime per le risorse all'interno della tua organizzazione AWS**. Le RCP sono simili alle politiche IAM nella sintassi ma **non concedono autorizzazioni**—limitano solo le autorizzazioni che possono essere applicate alle risorse da altre politiche. Quando si allega una RCP alla radice dell'organizzazione, a un'unità organizzativa (OU) o a un account, la RCP limita le autorizzazioni delle risorse su tutte le risorse nell'ambito interessato. -Questo è l'UNICO modo per garantire che **le risorse non possano superare i livelli di accesso predefiniti**—anche se una politica basata su identità o risorsa è troppo permissiva. L'unico modo per bypassare questi limiti è modificare anche l'RCP configurato dall'account di gestione della tua organizzazione. +Questo è l'UNICO modo per garantire che **le risorse non possano superare i livelli di accesso predefiniti**—anche se una politica basata su identità o risorsa è troppo permissiva. L'unico modo per bypassare questi limiti è modificare anche la RCP configurata dall'account di gestione della tua organizzazione. > [!WARNING] -> Le RCP limitano solo le autorizzazioni che le risorse possono avere. Non controllano direttamente cosa possono fare i principi. Ad esempio, se un RCP nega l'accesso esterno a un bucket S3, garantisce che le autorizzazioni del bucket non consentano mai azioni oltre il limite impostato—anche se una politica basata su risorse è configurata in modo errato. +> Le RCP limitano solo le autorizzazioni che le risorse possono avere. Non controllano direttamente cosa possono fare i principi. Ad esempio, se una RCP nega l'accesso esterno a un bucket S3, garantisce che le autorizzazioni del bucket non consentano mai azioni oltre il limite impostato—anche se una politica basata su risorsa è configurata in modo errato. Esempi di RCP: @@ -82,7 +82,7 @@ Esempi di RCP: - Limitare le autorizzazioni sulle code SQS per prevenire modifiche non autorizzate - Applicare confini di accesso sui segreti di Secrets Manager per proteggere dati sensibili -Trova esempi nella [documentazione delle Resource Control Policies di AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) +Trova esempi in [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) ### ARN @@ -110,7 +110,7 @@ IAM può essere definito dalla sua capacità di gestire, controllare e governare ### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'identità di accesso singolo che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'_**utente root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**. +Quando crei per la prima volta un account Amazon Web Services (AWS), inizi con un'unica identità di accesso che ha **accesso completo a tutti** i servizi e le risorse AWS nell'account. Questo è l'_**utente root**_ dell'account AWS e viene accesso effettuando il login con **l'indirizzo email e la password che hai usato per creare l'account**. Nota che un nuovo **utente admin** avrà **meno permessi dell'utente root**. @@ -130,7 +130,7 @@ Gli utenti possono avere **MFA abilitato per il login** attraverso la console. I - **Secret access key ID**: 40 caratteri casuali in maiuscolo e minuscolo: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Non è possibile recuperare gli ID delle chiavi di accesso segrete perse). Ogni volta che hai bisogno di **cambiare la Access Key**, questo è il processo che dovresti seguire:\ -_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> segna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_ +_Crea una nuova chiave di accesso -> Applica la nuova chiave al sistema/applicazione -> contrassegna quella originale come inattiva -> Testa e verifica che la nuova chiave di accesso funzioni -> Elimina la vecchia chiave di accesso_ ### MFA - Multi Factor Authentication @@ -150,44 +150,44 @@ aws sts get-session-token --serial-number --token-code ``` Come [**indicato qui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), ci sono molti casi diversi in cui **MFA non può essere utilizzato**. -### [Gruppi di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) +### [Gruppi utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) -Un [gruppo di utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può semplificare la gestione delle autorizzazioni per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**. +Un [gruppo utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) è un modo per **allegare politiche a più utenti** contemporaneamente, il che può rendere più facile gestire i permessi per quegli utenti. **I ruoli e i gruppi non possono far parte di un gruppo**. -Puoi allegare una **politica basata sull'identità a un gruppo di utenti** in modo che tutti gli **utenti** nel gruppo di utenti **ricevano le autorizzazioni della politica**. Non puoi identificare un **gruppo di utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono alle autorizzazioni, non all'autenticazione, e i principal sono entità IAM autenticate. +Puoi allegare una **politica basata sull'identità a un gruppo utenti** in modo che tutti gli **utenti** nel gruppo utenti **ricevano i permessi della politica**. Non puoi identificare un **gruppo utenti** come un **`Principal`** in una **politica** (come una politica basata sulle risorse) perché i gruppi si riferiscono ai permessi, non all'autenticazione, e i principali sono entità IAM autenticate. -Ecco alcune caratteristiche importanti dei gruppi di utenti: +Ecco alcune caratteristiche importanti dei gruppi utenti: -- Un **gruppo** di utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**. -- **I gruppi di utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi di utenti. -- Non esiste **un gruppo di utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo di utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso. -- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [IAM e AWS STS quote](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). +- Un **gruppo** utenti può **contenere molti utenti**, e un **utente** può **appartenere a più gruppi**. +- **I gruppi utenti non possono essere annidati**; possono contenere solo utenti, non altri gruppi utenti. +- Non esiste **un gruppo utenti predefinito che include automaticamente tutti gli utenti nell'account AWS**. Se desideri avere un gruppo utenti di questo tipo, devi crearlo e assegnare ogni nuovo utente ad esso. +- Il numero e la dimensione delle risorse IAM in un account AWS, come il numero di gruppi e il numero di gruppi di cui un utente può essere membro, sono limitati. Per ulteriori informazioni, vedere [quote IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). ### [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -Un **ruolo IAM** è molto **simile** a un **utente**, in quanto è un **identità con politiche di autorizzazione che determinano cosa** può e non può fare in AWS. Tuttavia, un ruolo **non ha alcuna credenziale** (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere **assunto da chiunque ne abbia bisogno (e abbia abbastanza permessi)**. Un **utente IAM può assumere un ruolo per temporaneamente** acquisire autorizzazioni diverse per un compito specifico. Un ruolo può essere **assegnato a un** [**utente federato**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) che accede utilizzando un provider di identità esterno invece di IAM. +Un **ruolo IAM** è molto **simile** a un **utente**, in quanto è un **identità con politiche di permesso che determinano cosa** può e non può fare in AWS. Tuttavia, un ruolo **non ha alcuna credenziale** (password o chiavi di accesso) associata. Invece di essere associato in modo univoco a una persona, un ruolo è destinato a essere **assumibile da chiunque ne abbia bisogno (e abbia abbastanza permessi)**. Un **utente IAM può assumere un ruolo per temporaneamente** acquisire permessi diversi per un compito specifico. Un ruolo può essere **assegnato a un** [**utente federato**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) che accede utilizzando un provider di identità esterno invece di IAM. -Un ruolo IAM consiste in **due tipi di politiche**: una **politica di fiducia**, che non può essere vuota, che definisce **chi può assumere** il ruolo, e una **politica di autorizzazione**, che non può essere vuota, che definisce **cosa può accedere**. +Un ruolo IAM consiste in **due tipi di politiche**: una **politica di fiducia**, che non può essere vuota, che definisce **chi può assumere** il ruolo, e una **politica di permessi**, che non può essere vuota, che definisce **cosa può accedere**. #### Servizio di Token di Sicurezza AWS (STS) -Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'**emissione di credenziali temporanee e con privilegi limitati**. È specificamente progettato per: +Il Servizio di Token di Sicurezza AWS (STS) è un servizio web che facilita l'**emissione di credenziali temporanee con privilegi limitati**. È specificamente progettato per: ### [Credenziali temporanee in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -Le **credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di autorizzazioni più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide. +**Le credenziali temporanee sono utilizzate principalmente con i ruoli IAM**, ma ci sono anche altri usi. Puoi richiedere credenziali temporanee che hanno un insieme di permessi più ristretto rispetto al tuo utente IAM standard. Questo **previene** che tu **esegua accidentalmente compiti non consentiti** dalle credenziali più ristrette. Un vantaggio delle credenziali temporanee è che scadono automaticamente dopo un periodo di tempo stabilito. Hai il controllo sulla durata per cui le credenziali sono valide. ### Politiche #### Permessi delle Politiche -Vengono utilizzati per assegnare autorizzazioni. Ci sono 2 tipi: +Vengono utilizzati per assegnare permessi. Ci sono 2 tipi: - Politiche gestite da AWS (preconfigurate da AWS) -- Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare autorizzazioni) o scrivendo le tue. +- Politiche gestite dai clienti: configurate da te. Puoi creare politiche basate su politiche gestite da AWS (modificando una di esse e creando la tua), utilizzando il generatore di politiche (una vista GUI che ti aiuta a concedere e negare permessi) o scrivendo le tue. Per **default l'accesso** è **negato**, l'accesso sarà concesso se è stato specificato un ruolo esplicito.\ -Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per impostazione predefinita). +Se **esiste un singolo "Deny", sovrascriverà il "Allow"**, tranne per le richieste che utilizzano le credenziali di sicurezza root dell'account AWS (che sono consentite per default). ```javascript { "Version": "2012-10-17", //Version of the policy @@ -234,7 +234,7 @@ Un limite è semplicemente una politica allegata a un utente che **indica il liv ### Politiche di Sessione -Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che il ruolo ha). +Una politica di sessione è una **politica impostata quando un ruolo viene assunto** in qualche modo. Questo sarà come un **limite IAM per quella sessione**: Questo significa che la politica di sessione non concede permessi ma **li restringe a quelli indicati nella politica** (essendo i permessi massimi quelli che ha il ruolo). Questo è utile per **misure di sicurezza**: Quando un amministratore sta per assumere un ruolo molto privilegiato, potrebbe restringere il permesso solo a quelli indicati nella politica di sessione nel caso in cui la sessione venga compromessa. ```bash @@ -251,9 +251,9 @@ Pertanto, se a un certo punto ti trovi di fronte all'errore "... perché nessuna ### Federazione dell'Identità La federazione dell'identità **consente agli utenti di provider di identità che sono esterni** ad AWS di accedere alle risorse AWS in modo sicuro senza dover fornire le credenziali di un utente AWS da un account IAM valido.\ -Un esempio di un provider di identità può essere il tuo **Microsoft Active Directory** aziendale (tramite **SAML**) o i servizi **OpenID** (come **Google**). L'accesso federato consentirà quindi agli utenti al suo interno di accedere ad AWS. +Un esempio di provider di identità può essere il tuo **Microsoft Active Directory** aziendale (tramite **SAML**) o i servizi **OpenID** (come **Google**). L'accesso federato consentirà quindi agli utenti al suo interno di accedere ad AWS. -Per configurare questa fiducia, viene generato un **Provider di Identità IAM (SAML o OAuth)** che **fiducia** nella **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Provider di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato. +Per configurare questa fiducia, viene generato un **Provider di Identità IAM (SAML o OAuth)** che **fiducia** la **altra piattaforma**. Poi, almeno un **ruolo IAM è assegnato (fiducioso) al Provider di Identità**. Se un utente della piattaforma fidata accede ad AWS, accederà come il ruolo menzionato. Tuttavia, di solito vorrai dare un **ruolo diverso a seconda del gruppo dell'utente** nella piattaforma di terze parti. Quindi, diversi **ruoli IAM possono fidarsi** del Provider di Identità di terze parti e la piattaforma di terze parti sarà quella che consentirà agli utenti di assumere un ruolo o l'altro. @@ -275,11 +275,11 @@ Per accedere agli utenti, ci sono 3 fonti di identità che possono essere utiliz Nel caso più semplice della directory del Centro Identità, il **Centro Identità avrà un elenco di utenti e gruppi** e sarà in grado di **assegnare politiche** a loro per **uno qualsiasi degli account** dell'organizzazione. -Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida nel Centro Identità**, e verrà creato un **ruolo che fida nel Provider di Identità con le politiche indicate** nell'account di destinazione. +Per dare accesso a un utente/gruppo del Centro Identità a un account, verrà creato un **Provider di Identità SAML che fida il Centro Identità**, e verrà creato un **ruolo che fida il Provider di Identità con le politiche indicate** nell'account di destinazione. #### AwsSSOInlinePolicy -È possibile **dare permessi tramite politiche inline ai ruoli creati tramite IAM Identity Center**. I ruoli creati negli account che ricevono **politiche inline in AWS Identity Center** avranno questi permessi in una politica inline chiamata **`AwsSSOInlinePolicy`**. +È possibile **dare permessi tramite politiche inline ai ruoli creati tramite IAM Identity Center**. I ruoli creati negli account a cui vengono date **politiche inline in AWS Identity Center** avranno questi permessi in una politica inline chiamata **`AwsSSOInlinePolicy`**. Pertanto, anche se vedi 2 ruoli con una politica inline chiamata **`AwsSSOInlinePolicy`**, **non significa che abbia gli stessi permessi**. @@ -329,7 +329,7 @@ In [**questa pagina**](https://docs.aws.amazon.com/IAM/latest/UserGuide/referenc | APKA | Chiave pubblica | | AROA | Ruolo | | ASCA | Certificato | -| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilizzano questo prefisso, ma sono uniche solo in combinazione con la chiave di accesso segreta e il token di sessione. | +| ASIA | [ID chiavi di accesso temporanee (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) usano questo prefisso, ma sono unici solo in combinazione con la chiave di accesso segreta e il token di sessione. | ### Permessi raccomandati per audit degli account @@ -348,9 +348,9 @@ I seguenti privilegi concedono vari accessi in lettura ai metadati: ### Autenticazione CLI -Affinché un utente normale si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\ -In quel file puoi avere più di un profilo, se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\ -Esempio di file di credenziali con più di 1 profilo: +Affinché un utente regolare si autentichi ad AWS tramite CLI, è necessario avere **credenziali locali**. Per impostazione predefinita, puoi configurarle **manualmente** in `~/.aws/credentials` o **eseguendo** `aws configure`.\ +In quel file puoi avere più di un profilo; se **nessun profilo** è specificato utilizzando il **aws cli**, verrà utilizzato quello chiamato **`[default]`** in quel file.\ +Esempio di file delle credenziali con più di 1 profilo: ``` [default] aws_access_key_id = AKIA5ZDCUJHF83HDTYUT diff --git a/src/pentesting-cloud/azure-security/az-services/az-sql.md b/src/pentesting-cloud/azure-security/az-services/az-sql.md index 1b2607573..cebe084b5 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-sql.md +++ b/src/pentesting-cloud/azure-security/az-services/az-sql.md @@ -8,10 +8,10 @@ Azure SQL è una famiglia di prodotti gestiti, sicuri e intelligenti che utilizz Azure SQL consiste in quattro offerte principali: -1. **Azure SQL Server**: Un server è necessario per il **deployment e la gestione** dei database SQL Server. +1. **Azure SQL Server**: È necessario un server per il **deployment e la gestione** dei database SQL Server. 2. **Azure SQL Database**: Questo è un **servizio di database completamente gestito**, che ti consente di ospitare database individuali nel cloud Azure. -3. **Azure SQL Managed Instance**: Questo è per deployment su larga scala, a livello di intera istanza SQL Server. -4. **Azure SQL Server su Azure VMs**: Questo è migliore per architetture in cui desideri **controllo sul sistema operativo** e sull'istanza SQL Server. +3. **Azure SQL Managed Instance**: Questo è per implementazioni su larga scala, a livello di intera istanza SQL Server. +4. **Azure SQL Server su Azure VMs**: Questo è il migliore per architetture in cui desideri **controllo sul sistema operativo** e sull'istanza SQL Server. ### Caratteristiche di Sicurezza di SQL Server @@ -101,21 +101,21 @@ Un database SQL potrebbe far parte di un **elastic Pool**. Gli elastic pool sono #### Sicurezza a Livello di Colonna (Mascheramento) e Sicurezza a Livello di Riga di Azure SQL -Il **mascheramento dei dati dinamico** di Azure SQL è una funzionalità che aiuta a **proteggere informazioni sensibili nascondendole** agli utenti non autorizzati. Invece di alterare i dati reali, maschera dinamicamente i dati visualizzati, assicurando che dettagli sensibili come i numeri di carta di credito siano oscurati. +Il **mascheramento dei dati dinamico** di Azure SQL è una funzionalità che aiuta a **proteggere le informazioni sensibili nascondendole** agli utenti non autorizzati. Invece di alterare i dati reali, maschera dinamicamente i dati visualizzati, assicurando che dettagli sensibili come i numeri di carta di credito siano oscurati. -Il **Mascheramento dei Dati Dinamico** influisce su tutti gli utenti tranne quelli che sono non mascherati (questi utenti devono essere indicati) e sugli amministratori. Ha l'opzione di configurazione che specifica quali utenti SQL sono esenti dal mascheramento dei dati dinamico, con **amministratori sempre esclusi**. +Il **Mascheramento dei Dati Dinamico** influisce su tutti gli utenti tranne quelli che sono non mascherati (questi utenti devono essere indicati) e sugli amministratori. Ha l'opzione di configurazione che specifica quali utenti SQL sono esenti dal mascheramento dinamico dei dati, con **amministratori sempre esclusi**. -La **Sicurezza a Livello di Riga di Azure SQL (RLS)** è una funzionalità che **controlla quali righe un utente può visualizzare o modificare**, assicurando che ogni utente veda solo i dati a lui pertinenti. Creando politiche di sicurezza con predicati di filtro o blocco, le organizzazioni possono applicare un accesso dettagliato a livello di database. +La **Sicurezza a Livello di Riga di Azure SQL (RLS)** è una funzionalità che **controlla quali righe un utente può visualizzare o modificare**, assicurando che ogni utente veda solo i dati rilevanti per lui. Creando politiche di sicurezza con predicati di filtro o blocco, le organizzazioni possono applicare un accesso dettagliato a livello di database. ### Azure SQL Managed Instance -Le **Azure SQL Managed Instances** sono per distribuzioni su larga scala, a livello di intera istanza di SQL Server. Forniscono quasi il 100% di compatibilità con l'ultima versione del motore di database SQL Server on-premises (Enterprise Edition), che offre un'implementazione nativa di rete virtuale (VNet) che affronta comuni preoccupazioni di sicurezza, e un modello di business favorevole per i clienti di SQL Server on-premises. +Le **Azure SQL Managed Instances** sono per distribuzioni su larga scala, a livello di intera istanza di SQL Server. Forniscono quasi il 100% di compatibilità con l'ultima versione del motore di database SQL Server on-premises (Enterprise Edition), che offre un'implementazione nativa della rete virtuale (VNet) che affronta le comuni preoccupazioni di sicurezza, e un modello di business favorevole per i clienti di SQL Server on-premises. ### Azure SQL Virtual Machines Le **Azure SQL Virtual Machines** consentono di **controllare il sistema operativo** e l'istanza di SQL Server, poiché una VM verrà avviata nel servizio VM che esegue il server SQL. -Quando viene creata una SQL Virtual Machine è possibile **selezionare tutte le impostazioni della VM** (come mostrato nella lezione sulla VM) che ospiterà il server SQL. +Quando viene creata una SQL Virtual Machine, è possibile **selezionare tutte le impostazioni della VM** (come mostrato nella lezione sulla VM) che ospiterà il server SQL. - Questo significa che la VM accederà a alcune VNet, potrebbe avere **Identità Gestite collegate** ad essa, potrebbe avere condivisioni di file montate… rendendo un **pivoting dal SQL** alla VM molto interessante. - Inoltre, è possibile configurare un ID app e un segreto per **consentire al SQL di accedere a un specifico key vault**, che potrebbe contenere informazioni sensibili.