Az - Informazioni di Base

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Gerarchia dell’Organizzazione

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

Gruppi di Gestione

  • Può contenere altri gruppi di gestione o sottoscrizioni.
  • Questo consente di applicare controlli di governance come RBAC e Azure Policy una sola volta a livello di gruppo di gestione e farli ereditar da tutte le sottoscrizioni nel gruppo.
  • Possono essere supportati 10.000 gruppi di gestione in una singola directory.
  • Un albero di gruppi di gestione può supportare fino a sei livelli di profonditĂ . Questo limite non include il livello radice o il livello di sottoscrizione.
  • Ogni gruppo di gestione e sottoscrizione può supportare solo un genitore.
  • Anche se possono essere creati diversi gruppi di gestione, c’è solo 1 gruppo di gestione radice.
  • Il gruppo di gestione radice contiene tutti gli altri gruppi di gestione e sottoscrizioni e non può essere spostato o eliminato.
  • Tutte le sottoscrizioni all’interno di un singolo gruppo di gestione devono fidarsi dello stesso tenant Entra ID.

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

Sottoscrizioni Azure

  • È un altro contenitore logico in cui possono essere eseguite risorse (VM, DB…) e verrĂ  fatturato.
  • Il suo genitore è sempre un gruppo di gestione (e può essere il gruppo di gestione radice) poichĂŠ le sottoscrizioni non possono contenere altre sottoscrizioni.
  • Fiducia solo in un directory Entra ID
  • Le autorizzazioni applicate a livello di sottoscrizione (o a qualsiasi dei suoi genitori) sono ereditarie a tutte le risorse all’interno della sottoscrizione.

Gruppi di Risorse

Dal documento: Un gruppo di risorse è un contenitore che contiene risorse correlate per una soluzione Azure. Il gruppo di risorse può includere tutte le risorse per la soluzione, o solo quelle risorse che desideri gestire come un gruppo. In generale, aggiungi risorse che condividono il stesso ciclo di vita allo stesso gruppo di risorse in modo da poterle facilmente distribuire, aggiornare ed eliminare come un gruppo.

Tutte le risorse devono essere all’interno di un gruppo di risorse e possono appartenere solo a un gruppo e se un gruppo di risorse viene eliminato, tutte le risorse al suo interno vengono anch’esse eliminate.

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

ID Risorsa Azure

Ogni risorsa in Azure ha un ID Risorsa Azure che la identifica.

Il formato di un ID Risorsa Azure è il seguente:

  • /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

Per una macchina virtuale chiamata myVM in un gruppo di risorse myResourceGroup sotto l’ID di sottoscrizione 12345678-1234-1234-1234-123456789012, l’ID Risorsa Azure appare così:

  • /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Servizi di Dominio Azure AD

Azure

Azure è la piattaforma di cloud computing completa di Microsoft, che offre una vasta gamma di servizi, tra cui macchine virtuali, database, intelligenza artificiale e archiviazione. Funziona come base per l’hosting e la gestione delle applicazioni, la costruzione di infrastrutture scalabili e l’esecuzione di carichi di lavoro moderni nel cloud. Azure fornisce strumenti per sviluppatori e professionisti IT per creare, distribuire e gestire applicazioni e servizi senza soluzione di continuità, soddisfacendo una varietà di esigenze, dalle startup alle grandi imprese.

Entra ID (precedentemente Azure Active Directory)

Entra ID è un servizio di gestione dell’identità e degli accessi basato su cloud progettato per gestire autenticazione, autorizzazione e controllo degli accessi degli utenti. Potenzia l’accesso sicuro ai servizi Microsoft come Office 365, Azure e molte applicazioni SaaS di terze parti. Con funzionalità come l’accesso single sign-on (SSO), l’autenticazione a più fattori (MFA) e le politiche di accesso condizionale, tra le altre.

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 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 di Entra ID

Utenti

  • Nuovi utenti
  • Indica il nome e il dominio dell’email dal tenant selezionato
  • Indica il nome visualizzato
  • Indica la password
  • Indica le proprietĂ  (nome, titolo di lavoro, informazioni di contatto…)
  • Il tipo di utente predefinito è “membro”
  • Utenti esterni
  • Indica l’email per invitare e il nome visualizzato (può essere un’email non Microsoft)
  • Indica le proprietĂ 
  • Il tipo di utente predefinito è “Ospite”

Permessi Predefiniti per Membri e Ospiti

Puoi controllarli in https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions ma tra le altre azioni un membro sarĂ  in grado di:

  • Leggere tutti gli utenti, Gruppi, Applicazioni, Dispositivi, Ruoli, Sottoscrizioni e le loro proprietĂ  pubbliche
  • Invitare Ospiti (può essere disattivato)
  • Creare gruppi di sicurezza
  • Leggere le appartenenze ai gruppi non nascoste
  • Aggiungere ospiti ai gruppi di proprietĂ 
  • Creare una nuova applicazione (può essere disattivato)
  • Aggiungere fino a 50 dispositivi ad Azure (può essere disattivato)

Note

Ricorda che per enumerare le risorse Azure l’utente ha bisogno di un’esplicita concessione del permesso.

Permessi Configurabili Predefiniti per Utenti

  • Membri (docs)
  • 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 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ĂŹ
  • Limitare gli utenti dal recuperare la chiave BitLocker per i loro dispositivi di proprietĂ : Predefinito No (controlla nelle Impostazioni Dispositivo)
  • Leggere altri utenti: Predefinito SĂŹ (tramite Microsoft Graph)
  • Ospiti
  • Restrizioni di accesso per utenti ospiti opzioni:
  • Gli utenti ospiti hanno lo stesso accesso dei membri.
  • 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, 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, inclusi gli amministratori (la piĂš restrittiva)
  • Uscita degli utenti esterni: Predefinito Vero
  • Consentire agli utenti esterni di lasciare l’organizzazione

Tip

Anche se limitati per impostazione predefinita, gli utenti (membri e ospiti) con permessi concessi potrebbero eseguire le azioni precedenti.

Gruppi

Ci sono 2 tipi di gruppi:

  • Sicurezza: Questo tipo di gruppo è utilizzato per dare accesso ai membri ad applicazioni, risorse e assegnare licenze. Gli utenti, i dispositivi, i principi di servizio e altri gruppi possono essere membri.
  • Microsoft 365: Questo tipo di gruppo è utilizzato per la collaborazione, dando accesso ai membri a una casella di posta condivisa, calendario, file, sito SharePoint, e cosĂŹ via. I membri del gruppo possono essere solo utenti.
  • Questo avrĂ  un indirizzo email con il dominio del tenant EntraID.

Ci sono 2 tipi di appartenenze:

  • Assegnato: Consente di aggiungere manualmente membri specifici a un gruppo.
  • Appartenenza dinamica: Gestisce automaticamente l’appartenenza utilizzando regole, aggiornando l’inclusione del gruppo quando cambiano gli attributi dei membri.

Principi di Servizio

Un Principio di Servizio è un identità creata per uso con applicazioni, servizi ospitati e strumenti automatizzati per accedere alle risorse Azure. Questo accesso è ristretto dai ruoli assegnati al principio di servizio, dandoti il controllo su quali risorse possono essere accessibili e a quale livello. Per motivi di sicurezza, è sempre consigliato utilizzare principi di servizio con strumenti automatizzati piuttosto che consentire loro di accedere con un’identità utente.

È possibile accedere direttamente come un principio di servizio generando un segreto (password), un certificato, o concedendo accesso federato a piattaforme di terze parti (ad es. Github Actions) su di esso.

  • Se scegli l’autenticazione password (per impostazione predefinita), salva la password generata poichĂŠ non potrai accedervi di nuovo.
  • Se scegli l’autenticazione con certificato, assicurati che l’applicazione avrĂ  accesso alla chiave privata.

Registrazioni App

Una Registrazione App è una configurazione che consente a un’applicazione di integrarsi con Entra ID e di eseguire azioni.

Componenti Chiave:

  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).
  4. 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).
  5. Permessi API: Specifica quali risorse o API l’app può accedere.
  6. Impostazioni di Autenticazione: Definisce i flussi di autenticazione supportati dall’app (ad es., OAuth2, OpenID Connect).
  7. 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.
  8. Il principio di servizio otterrà tutti i permessi richiesti con cui è stato configurato.

Permessi di Consenso Predefiniti

Consenso dell’utente per le applicazioni

  • Non consentire il consenso dell’utente
  • SarĂ  richiesto un amministratore per tutte le app.
  • 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 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 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)

Le identità gestite in Azure Active Directory offrono una soluzione per gestire automaticamente l’identità delle applicazioni. Queste identità sono utilizzate dalle applicazioni per connettersi a risorse compatibili con l’autenticazione di Azure Active Directory (Azure AD). Questo consente di eliminare la necessità di codificare le credenziali cloud nel codice poiché l’applicazione sarà in grado di contattare il servizio di metadati per ottenere un token valido per eseguire azioni come l’identità gestita indicata in Azure.

Ci sono due tipi di identitĂ  gestite:

  • 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 essa associato.

Applicazioni Aziendali

È 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.

UnitĂ  Amministrative

Le unità amministrative consentono di dare permessi da un ruolo su una specifica porzione di un’organizzazione.

Esempio:

  • Scenario: Un’azienda vuole che gli amministratori IT regionali gestiscano solo gli utenti nella propria regione.
  • Implementazione:
  • Crea UnitĂ  Amministrative per ogni regione (ad es., “AU Nord America”, “AU Europa”).
  • Popola le AU con utenti delle rispettive regioni.
  • Le AU possono contenere utenti, gruppi o dispositivi
  • Le AU supportano appartenenze dinamiche
  • Le AU non possono contenere AU
  • Assegna Ruoli Amministrativi:
  • 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 di 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
  • I ruoli contrassegnati come PRIVILEGIATI da EntraID dovrebbero essere assegnati con cautela perchĂŠ, come spiega Microsoft nei documenti: 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 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 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.
  • A seconda dell’ambito a cui è stato assegnato il ruolo, il ruolo potrebbe essere ereditato da altre risorse all’interno del contenitore dell’ambito. Ad esempio, se un utente A ha un ruolo sulla sottoscrizione, avrĂ  quel ruolo su tutti i gruppi di risorse all’interno della sottoscrizione e su tutte le risorse all’interno del gruppo di risorse.

Ruoli Predefiniti

Dal documento: Il controllo degli accessi basato sui ruoli di Azure (Azure RBAC) ha diversi ruoli predefiniti di Azure che puoi assegnare a utenti, gruppi, principi di servizio e identità gestite. Le assegnazioni di ruolo sono il modo in cui controlli l’accesso alle risorse Azure. Se i ruoli predefiniti non soddisfano le esigenze specifiche della tua organizzazione, puoi creare i tuoi ruoli personalizzati di Azure.

I ruoli predefiniti si applicano solo alle risorse per cui sono destinati, ad esempio controlla questi 2 esempi di ruoli predefiniti su risorse Compute:

Disk Backup ReaderFornisce permesso al vault di backup per eseguire il backup del disco.3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
Virtual Machine User LoginVisualizza le Macchine Virtuali nel portale e accedi come utente normale.fb879df8-f326-4884-b1cf-06f3ad86be52

Questi ruoli possono essere assegnati anche su contenitori logici (come gruppi di gestione, sottoscrizioni e gruppi di risorse) e i principi interessati li avranno sulle risorse all’interno di quei contenitori.

Ruoli Personalizzati

  • È anche possibile creare ruoli personalizzati
  • Vengono creati all’interno di un ambito, anche se un ruolo può essere in piĂš ambiti (gruppi di gestione, sottoscrizioni e gruppi di risorse)
  • È possibile configurare tutti i permessi granulari che il ruolo personalizzato avrĂ 
  • È possibile escludere permessi
  • Un principio con un permesso escluso non sarĂ  in grado di utilizzarlo anche se il permesso viene concesso altrove
  • È possibile utilizzare caratteri jolly
  • Il formato utilizzato è un JSON
  • actions si riferisce ai permessi per operazioni di gestione sulle risorse, come creare, aggiornare o eliminare definizioni e impostazioni delle risorse.
  • dataActions sono permessi per operazioni sui dati all’interno della risorsa, consentendo di leggere, scrivere o eliminare i dati effettivi contenuti nella risorsa.
  • notActions e notDataActions vengono utilizzati per escludere permessi specifici dal ruolo. Tuttavia, non li negano, se un ruolo diverso li concede, il principio li avrĂ .
  • assignableScopes è un array di ambiti in cui il ruolo può essere assegnato (come gruppi di gestione, sottoscrizioni o gruppi di risorse).

Esempio di JSON di permessi per un ruolo personalizzato:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

Permessi ordine

  • AffinchĂŠ un principale abbia accesso a una risorsa, deve avere un ruolo esplicito assegnato (in qualche modo) che gli conceda quel permesso.
  • Un’esplicita assegnazione di negazione ha la precedenza sul ruolo che concede il permesso.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

Amministratore Globale

L’Amministratore Globale è un ruolo di Entra ID che concede controllo completo sul tenant di Entra ID. Tuttavia, di default non concede alcun permesso sulle risorse di Azure.

Gli utenti con il ruolo di Amministratore Globale hanno la possibilità di ‘elevare’ al ruolo di Amministratore Accesso Utente di Azure nel Gruppo di Gestione Radice. Quindi, gli Amministratori Globali possono gestire l’accesso in tutte le sottoscrizioni e i gruppi di gestione di Azure.
Questa elevazione può essere effettuata alla fine della pagina: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Condizioni delle Assegnazioni & MFA

Secondo la documentazione: Attualmente, le condizioni possono essere aggiunte alle assegnazioni di ruolo integrate o personalizzate che hanno azioni sui dati di archiviazione blob o azioni sui dati di archiviazione delle code.

Assegnazioni di Negazione

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

Concetti Chiave

  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”).

Alcuni esempi:

  1. Garantire la Conformità con Regioni Azure Specifiche: Questa politica garantisce che tutte le risorse siano distribuite in regioni Azure specifiche. Ad esempio, un’azienda potrebbe voler garantire che tutti i suoi dati siano archiviati in Europa per la conformità al GDPR.
  2. Applicare Standard di Nominazione: Le politiche possono applicare convenzioni di denominazione per le risorse di Azure. Questo aiuta a organizzare e identificare facilmente le risorse in base ai loro nomi, il che è utile in ambienti grandi.
  3. Limitare Certi Tipi di Risorse: Questa politica può limitare la creazione di certi tipi di risorse. Ad esempio, una politica potrebbe essere impostata per impedire la creazione di tipi di risorse costosi, come alcune dimensioni di VM, per controllare i costi.
  4. Applicare Politiche di Tagging: I tag sono coppie chiave-valore associate alle risorse di Azure utilizzate per la gestione delle risorse. Le politiche possono imporre che determinati tag debbano essere presenti o avere valori specifici per tutte le risorse. Questo è utile per il tracciamento dei costi, la proprietà o la categorizzazione delle risorse.
  5. Limitare l’Accesso Pubblico alle Risorse: Le politiche possono imporre che determinate risorse, come account di archiviazione o database, non abbiano endpoint pubblici, garantendo che siano accessibili solo all’interno della rete dell’organizzazione.
  6. Applicare Automaticamente Impostazioni di Sicurezza: Le politiche possono essere utilizzate per applicare automaticamente impostazioni di sicurezza alle risorse, come applicare un gruppo di sicurezza di rete specifico a tutte le VM o garantire che tutti gli account di archiviazione utilizzino la crittografia.

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 di politica di Azure:

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

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.

Questa struttura gerarchica consente una gestione efficiente e scalabile dei permessi di accesso.

Azure RBAC vs ABAC

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 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

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks