Az - Basic Information
Gerarchia dell'Organizzazione
Gruppi di Gestione
Se la tua organizzazione ha molte sottoscrizioni Azure, potresti aver bisogno di un modo per gestire in modo efficiente l'accesso, le politiche e la conformità per quelle sottoscrizioni. I gruppi di gestione forniscono un ambito di governance sopra le sottoscrizioni.
Nota che possono essere supportati 10.000 gruppi di gestione in una singola directory e un albero di gruppi di gestione può supportare fino a sei livelli di profondità.
Da documentazione: Ogni directory riceve un singolo gruppo di gestione di livello superiore chiamato gruppo di gestione radice. Il gruppo di gestione radice è integrato nella gerarchia per avere tutti i gruppi di gestione e le sottoscrizioni che si uniscono ad esso. Questo gruppo di gestione radice consente di applicare politiche globali e assegnazioni di ruoli Azure a livello di directory. L'Amministratore Globale di Azure AD deve elevare se stesso al ruolo di Amministratore Accesso Utente di questo gruppo radice inizialmente. Dopo aver elevato l'accesso, l'amministratore può assegnare qualsiasi ruolo Azure ad altri utenti o gruppi della directory per gestire la gerarchia. Come amministratore, puoi assegnare il tuo stesso account come proprietario del gruppo di gestione radice.
Il gruppo di gestione radice non può essere spostato o eliminato, a differenza degli altri gruppi di gestione.
I gruppi di gestione ti offrono una gestione di livello enterprise su larga scala, indipendentemente dal tipo di sottoscrizioni che potresti avere. Tuttavia, tutte le sottoscrizioni all'interno di un singolo gruppo di gestione devono fidarsi dello stesso tenant di Azure Active Directory (Azure AD).
Sottoscrizioni Azure
In Azure, una sottoscrizione funge da contenitore logico per il provisioning di risorse aziendali o tecniche. Questo contenitore mantiene i dettagli delle risorse come macchine virtuali (VM), database, tra gli altri. Al momento della creazione di una risorsa Azure, come una VM, viene specificata la sottoscrizione associata. Questa struttura facilita la delega dell'accesso, utilizzando meccanismi di controllo degli accessi basati sui ruoli.
Gruppi di Risorse
Da documentazione: 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.
Unità Amministrative
Da documentazione: Le unità amministrative ti consentono di suddividere la tua organizzazione in qualsiasi unità che desideri, e poi assegnare amministratori specifici che possono gestire solo i membri di quell'unità. Ad esempio, potresti utilizzare le unità amministrative per delegare permessi agli amministratori di ciascuna scuola in una grande università, in modo che possano controllare l'accesso, gestire gli utenti e impostare politiche solo nella Scuola di Ingegneria.
Solo utenti, gruppi e dispositivi possono essere membri di un'unità amministrativa.
Pertanto, un'unità amministrativa conterrà alcuni membri e altri principali saranno **assegnati permessi su quell'unità amministrativa che possono utilizzare per gestire i membri dell'unità amministrativa.
Azure vs Azure AD vs Azure AD Domain Services
È importante notare che Azure AD è un servizio all'interno di Azure. Azure è la piattaforma cloud di Microsoft mentre Azure AD è il servizio di identità aziendale in Azure. Inoltre, Azure AD non è come Windows Active Directory, è un servizio di identità che funziona in un modo completamente diverso. Se desideri eseguire un Domain Controller in Azure per il tuo ambiente Windows Active Directory, devi utilizzare Azure AD Domain Services.
Principali
Azure supporta diversi tipi di principali:
Utente: Una persona normale con credenziali per accedere.
Gruppo: Un gruppo di principali gestiti insieme. I permessi concessi ai gruppi sono ereditati dai suoi membri.
Service Principal/Applicazioni Aziendali: È un'identità creata per l'uso con applicazioni, servizi ospitati e strumenti automatizzati per accedere alle risorse Azure. Questo accesso è ristretto dai ruoli assegnati al service principal, dandoti il controllo su quali risorse possono essere accessibili e a quale livello. Per motivi di sicurezza, è sempre consigliato utilizzare i service principal con strumenti automatizzati piuttosto che consentire loro di accedere con un'identità utente.
Quando crei un service principal puoi scegliere tra autenticazione a password o autenticazione a certificato.
Se scegli l'autenticazione a password (per impostazione predefinita), salva la password generata poiché non potrai accedervi di nuovo.
Se scegli l'autenticazione a certificato, assicurati che l'applicazione avrà accesso alla chiave privata.
Identità Gestita (Credenziali Metadata): 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). Utilizzando le identità gestite, le applicazioni possono proteggere i token Azure AD eliminando la necessità di gestire direttamente le credenziali. Ci sono due tipi di identità gestite:
Assegnata 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, un'identità viene creata in Azure AD. L'identità è legata al ciclo di vita di quell'istanza di servizio. Quando la risorsa viene eliminata, Azure elimina automaticamente l'identità per te. Per design, solo quella risorsa Azure può utilizzare questa identità per richiedere token da Azure AD.
Assegnata dall'utente. Puoi anche creare un'identità gestita come risorsa Azure autonoma. Puoi creare un'identità gestita assegnata dall'utente e assegnarla 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.
Ruoli e Permessi
I ruoli sono assegnati ai principali su un ambito: principal -[HAS ROLE]->(scope)
I ruoli assegnati ai 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 di 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 Classici
Proprietario |
| Tutti i tipi di risorsa |
Collaboratore |
| Tutti i tipi di risorsa |
Lettore | • Visualizza tutte le risorse | Tutti i tipi di risorsa |
Amministratore Accesso Utente |
| Tutti i tipi di risorsa |
Ruoli Integrati
Da documentazione: Il controllo degli accessi basato sui ruoli di Azure (Azure RBAC) ha diversi ruoli integrati di Azure che puoi assegnare a utenti, gruppi, service principal e identità gestite. Le assegnazioni di ruolo sono il modo in cui controlli l'accesso alle risorse Azure. Se i ruoli integrati non soddisfano le esigenze specifiche della tua organizzazione, puoi creare i tuoi ruoli personalizzati di Azure.
I ruoli integrati si applicano solo alle risorse per cui sono destinati, ad esempio controlla questi 2 esempi di ruoli integrati su risorse Compute:
Fornisce il permesso al vault di backup per eseguire il backup del disco. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Visualizza le Macchine Virtuali nel portale e accede 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 principali interessati li avranno sulle risorse all'interno di quei contenitori.
Trova qui un elenco con tutti i ruoli integrati di Azure.
Trova qui un elenco con tutti i ruoli integrati di Azure AD.
Ruoli Personalizzati
Azure consente anche di creare ruoli personalizzati con i permessi di cui l'utente ha bisogno.
Permesso Negato
Affinché un principale abbia accesso a una risorsa, ha bisogno di un ruolo esplicito che gli venga concesso (in qualsiasi modo) concedendogli quel permesso.
Un'assegnazione di ruolo di negazione esplicita ha la precedenza sul ruolo che concede il permesso.
Amministratore Globale
Gli utenti con il ruolo di Amministratore Globale hanno la possibilità di 'elevare' a Amministratore Accesso Utente Azure al gruppo di gestione radice. Ciò significa che un Amministratore Globale sarà in grado di gestire l'accesso a tutte le sottoscrizioni Azure e ai gruppi di gestione. Questa elevazione può essere effettuata alla fine della pagina: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Politiche Azure
Le politiche Azure sono un insieme di regole e regolamenti in Microsoft Azure, un servizio di cloud computing, che aiutano a gestire e far rispettare gli standard organizzativi e a valutare la conformità su larga scala. Queste politiche applicano diverse regole sulle tue risorse Azure, assicurando che quelle risorse rimangano conformi agli standard aziendali e agli accordi di livello di servizio.
Le politiche Azure sono cruciali per la governance e la sicurezza del cloud, aiutando a garantire che le risorse siano utilizzate in modo appropriato ed efficiente, e che siano conformi a regolamenti esterni e politiche interne. Alcuni esempi:
Garantire la Conformità con Specifiche Aree Azure: Questa politica garantisce che tutte le risorse siano distribuite in specifiche aree Azure. Ad esempio, un'azienda potrebbe voler garantire che tutti i suoi dati siano archiviati in Europa per la conformità al GDPR.
Imporre Standard di Nominazione: Le politiche possono imporre convenzioni di denominazione per le risorse Azure. Questo aiuta a organizzare e identificare facilmente le risorse in base ai loro nomi, il che è utile in ambienti grandi.
Limitare Certi Tipi di Risorse: Questa politica può limitare la creazione di certi tipi di risorse. Ad esempio, una politica potrebbe essere impostata per prevenire la creazione di tipi di risorse costosi, come alcune dimensioni di VM, per controllare i costi.
Imporre Politiche di Tagging: I tag sono coppie chiave-valore associate alle risorse 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 monitoraggio dei costi, la proprietà o la categorizzazione delle risorse.
Limitare l'Accesso Pubblico alle Risorse: Le politiche possono imporre che determinate risorse, come account di archiviazione o database, non abbiano endpoint pubblici, assicurando che siano accessibili solo all'interno della rete dell'organizzazione.
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 Azure possono essere collegate a qualsiasi livello della gerarchia Azure, ma sono comunemente utilizzate nel gruppo di gestione radice o in altri gruppi di gestione.
Ambito dei Permessi
In Azure i permessi possono essere assegnati a qualsiasi parte della gerarchia. Ciò include gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse individuali. I permessi sono ereditati dalle risorse contenute dell'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 negare esplicitamente l'accesso a risorse specifiche utilizzando condizioni.
Permessi Utente Predefiniti
Un utente di base avrà alcuni permessi predefiniti per enumerare alcune parti di AzureAD:
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)
Puoi vedere l'elenco completo dei permessi predefiniti degli utenti nella documentazione. Inoltre, nota che in quell'elenco puoi vedere anche l'elenco dei permessi predefiniti per gli ospiti.
Ricorda che per enumerare le risorse Azure l'utente ha bisogno di una concessione esplicita del permesso.
Gestione delle Identità Privilegiate (PIM)
La Gestione delle Identità Privilegiate (PIM) in Azure è uno strumento che gestisce, controlla e monitora l'accesso privilegiato in Azure Active Directory e Azure. Migliora la sicurezza fornendo accesso privilegiato giust-in-time e limitato nel tempo, imponendo flussi di approvazione e richiedendo autenticazione aggiuntiva. Questo approccio riduce al minimo il rischio di accesso non autorizzato garantendo che i permessi elevati siano concessi solo quando necessario e per una durata specifica.
Token di Autenticazione
Ci sono tre tipi di token utilizzati in OIDC:
Token di Accesso: Il client presenta questo token al server delle risorse per accedere alle risorse. Può essere utilizzato solo per una specifica combinazione di utente, client e risorsa e non può essere revocato fino alla scadenza - che è di 1 ora per impostazione predefinita. La rilevazione è bassa utilizzando questo.
Token ID: Il client riceve questo token dal server di autorizzazione. Contiene informazioni di base sull'utente. È legato a una specifica combinazione di utente e client.
Token di Aggiornamento: Fornito al client con il token di accesso. Utilizzato per ottenere nuovi token di accesso e ID. È legato a una specifica combinazione di utente e client e può essere revocato. La scadenza predefinita è di 90 giorni per i token di aggiornamento inattivi e nessuna scadenza per i token attivi.
Le informazioni per il accesso condizionale sono memorizzate all'interno del JWT. Quindi, se richiedi il token da un indirizzo IP consentito, quell'IP sarà memorizzato nel token e poi puoi utilizzare quel token da un IP non consentito per accedere alle risorse.
Controlla la seguente pagina per apprendere diversi modi per richiedere token di accesso e accedere con essi:
Az - AzureAD (AAD)I punti di accesso API più comuni sono:
Azure Resource Manager (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, che è deprecato, è graph.windows.net)
Riferimenti
Last updated
