mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-10 23:00:49 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -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) <a href="#id_root" id="id_root"></a>
|
||||
|
||||
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 <arn_device> --token-code <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) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
### [Gruppi utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
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) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
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) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user