Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure Policy vs RBAC: chi può fare cosa e quali configurazioni sono consentite – la governance di Azure spiegata semplice (Doppiaggio IA)

Transcript

Azure Policy vs RBAC: chi può fare cosa e quali configurazioni sono consentite – la governance di Azure spiegata semplice (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:03
Speaker 2: Oggi parleremo di una funzionalità di Azure di cui probabilmente
0:06
Speaker 2: hai sentito parlare ma che potresti non comprare. Azure Policy
0:08
Speaker 2: è uno degli strumenti di governance più potenti dell'intera piattaforma.
0:11
Speaker 2: Eppure la maggior parte delle persone lo ignora o pensa
0:13
Speaker 2: che sia riservato solo agli amministratori. Alla fine di questo
0:16
Speaker 2: episodio saprai cos'è Azure Policy, come funziona come un regolamento
0:20
Speaker 2: invisibile e perché è essenziale per mantenere il tuo ambiente
0:22
Speaker 2: Azure sicuro e sotto controllo. Lo suddivideremo in elementi costitutivi
0:27
Speaker 2: chiari a partire dal problema che risolve. Prendi un caffè
0:29
Speaker 2: e tuffiamoci dentro. Problema. Perché il cloud ha bisogno di protezione.
0:34
Speaker 2: Pensa al vecchio modo di fare le cose. In locale,
0:37
Speaker 2: quando avevi bisogno di un server, inviavi una richiesta al
0:39
Speaker 2: team operativo. Loro controllavano le regole, i criteri aziendali, gli
0:43
Speaker 2: standard di sicurezza, forse alcuni requisiti normativi. Poi seguivano i
0:46
Speaker 2: provisioni del server per te. Custode umano si frapponeva tra
0:49
Speaker 2: te e l'infrastruttura. Quella persona conosceva le regole e si
0:51
Speaker 2: assicurava che nulla sfuggisse. Cloud capovolge completamente le cose. Ora
0:54
Speaker 2: il proprietario dell'app ha accesso diretto senza alcun essere umano
0:57
Speaker 2: in mezzo. Fai clic su Crea nel portale di Azure
0:59
Speaker 2: e tutto avviene all'istante. Puoi anche usare la riga di comando,
1:02
Speaker 2: un API o strumenti di infrastruttura come codice e come terraform.
1:06
Speaker 2: Il punto è che nessuno controlla il tuo lavoro prima
1:08
Speaker 2: che la risorsa venga creata. Ed è qui che inizia
1:09
Speaker 2: il problema. La maggior parte dei platari di app non
1:11
Speaker 2: conosce tutto. Forse non si rendono conto che i criteri
1:13
Speaker 2: aziendali richiedono che tutti i dati rimangano in euro. O
1:16
Speaker 2: che gli account di archiviazione devono bloccare l'accesso pubblico. O
1:18
Speaker 2: che determinate dimensioni di VM sono costose e dovrebbero essere
1:21
Speaker 2: usate solo in produzione. Quindi vanno avanti creando risorse e
1:23
Speaker 2: a volte si verificano errori. Una macchina virtuale viene distribuita
1:27
Speaker 2: con un IP pubblico e porte aperte su internet. Un
1:29
Speaker 2: account di archiviazione viene creato con l'accesso a un blog
1:31
Speaker 2: pubblico che espone dati sensibili. Qualcuno avvia un'istanza GPU costosa
1:35
Speaker 2: per un test rapido e dimentica di eliminarla. Queste cose
1:38
Speaker 2: succedono di continuo. Ciò di cui abbiamo bisogno è un
1:40
Speaker 2: sistema di applicazione automatico che funzioni sempre indipendentemente da chi
1:43
Speaker 2: crea la risorsa o da come la fa. Che si
1:45
Speaker 2: tratti del portale, dell'interfaccia, della riga di comando, di una
1:47
Speaker 2: chiamata API o di una distribuzione di terra, formule regole
1:49
Speaker 2: dovrebbero essere verificate automaticamente. Ed è esattamente ciò per cui
1:52
Speaker 2: è stato creato Azure Policy. Cos'è Azure Policy? Il regolamento invisibile.
1:56
Speaker 2: Cos'è Azure Policy? Ecco la definizione più semplice. Azure Policy
2:00
Speaker 2: è un servizio che consente di definire regole per le
2:02
Speaker 2: risorse di Azure e di applicarle automaticamente. Immaginalo come regolamento
2:05
Speaker 2: di un gioco da tavolo. Il gioco prevede molte mosse possibili,
2:08
Speaker 2: ma il regolamento indica quali sono effettivamente consentite. Non puoi
2:11
Speaker 2: semplicemente spostare la topedina dove vuoi. Le regole indicano cosa
2:13
Speaker 2: è consentito e cosa no. Ecco una distinzione fondamentale. Azure
2:16
Speaker 2: Policy non è la stessa cosa di un controllo degli
2:18
Speaker 2: accessi in base al ruolo Erb. Erb ha controllo a
2:20
Speaker 2: chi può fare qualcosa. Risponde alla domanda chi è autorizzato
2:23
Speaker 2: a creare risorse in questa sottoscrizione. Azure Policy controlla cosa
2:26
Speaker 2: può essere fatto. o più precisamente quali configurazioni sono consentite.
2:29
Speaker 2: Risponde alla domanda che tipo di risorse possono essere create
2:32
Speaker 2: e come devono essere configurate. Quindi RBH afferma che Mirko
2:35
Speaker 2: può creare account di archiviazione. Azure Policy afferma che gli
2:37
Speaker 2: account di archiviazione devono avere HTTPS abilitato. Due cose diverse
2:41
Speaker 2: sono necessarie. Ecco la cosa fondamentale. Azure Policy è sempre
2:43
Speaker 2: attivo e sempre applicato. Ogni singola richiesta di creazione, aggiornamento
2:47
Speaker 2: o eliminazione di una risorsa passa attraverso Azure Policy e
2:50
Speaker 2: non c'è modo di aggirarla. Si trova tra te e
2:52
Speaker 2: Azure Resource Manager il piano di controllo di Azure. Consideralo
2:55
Speaker 2: come un filtro automatico. Ogni richiesta passa attraverso questo filtro
2:58
Speaker 2: e se non corrisponde alle regole, la richiesta viene bloccata
3:01
Speaker 2: o contrassegnata e non funziona solo per le nuove risorse.
3:03
Speaker 2: Azure Policy valuta anche le risorse esistenti, quindi rileva eventuali
3:06
Speaker 2: deviazioni di configurazione nel tempo. Se qualcuno modifica un'impostazione su
3:10
Speaker 2: una risorsa che è già distribuito e tale modifica viola
3:12
Speaker 2: un criterio, Azure Policy la contrassegnerà. Quindi come si scrivono
3:16
Speaker 2: effettivamente queste regole? È qui che entrano in gioco le
3:18
Speaker 2: definizioni dei criteri. Definizioni dei criteri? Scrittura delle regole? Quindi
3:22
Speaker 2: come si scrivono queste regole? È qui che entrano in
3:24
Speaker 2: gioco le definizioni dei criteri. Una definizione dei criteri e
3:26
Speaker 2: la regola stessa è descritta come documento JSON. JSON potrebbe
3:29
Speaker 2: sembrare tecnico, ma la struttura è in realtà piuttosto semplice.
3:32
Speaker 2: Segue uno schema di base. Se questa condizione è vera,
3:35
Speaker 2: applica questo effetto. Lascio che ti faccio un esempio reale.
3:38
Speaker 2: Esiste una policy integrata che stabilisce che se un account
3:40
Speaker 2: di archiviazione non ha HTTPS abilitato, deve essere negato. Tutto qui.
3:44
Speaker 2: Quando la condizione è vera, l'effetto si attiva e blocca
3:46
Speaker 2: la distribuzione. Ogni definizione di policy è composta da tre
3:48
Speaker 2: parti fondamentali. Innanzitutto le condizioni. Questa è la parte if.
3:51
Speaker 2: Cosa stai verificando? Il tipo di risorsa, la posizione specifica.
3:55
Speaker 2: Secondo luogo, gli effetti. Questa è la parte bene. Cosa
3:57
Speaker 2: succede quando la condizione è soddisfatta? Blocchi la distribuzione o
4:00
Speaker 2: la contrassegna e basta. In terzo luogo, i parametri. Questi
4:03
Speaker 2: sono gli spazi vuoti da compilare che rendono una policy risale.
4:06
Speaker 2: I parametri sono il vero punto di forza. Immagina di
4:08
Speaker 2: voler scrivere una policy che consenta risorse solo in determinate regioni.
4:12
Speaker 2: Non vuoi scrivere una policy separata per ogni possibile combinazione
4:15
Speaker 2: di regioni. Invece scrivi una definizione denominata posizioni consentite. E
4:19
Speaker 2: aggiungi un parametro per le regioni consentite. Quando assegni la policy,
4:22
Speaker 2: compili lo spazio vuoto. Magari dici Europa occidentale ed Europa
4:25
Speaker 2: settentrionale per un abbonamento, Stati Uniti orientali, Stati Uniti occidentali
4:27
Speaker 2: per un altro. Stessa definizione, parametri diversi. Ecco come mantenere
4:30
Speaker 2: cose gestibili. Ecco la buona notizia. Non devi scrivere tutto
4:33
Speaker 2: da zero. Microsoft fornisce centinaia di definizioni di criteri integrate
4:37
Speaker 2: che puoi iniziare a utilizzare immediatamente. Coprono categorie come elaborazione, archiviazione, rete,
4:41
Speaker 2: centro sicurezza, tag, gestione dei costi e altro ancora. Puoi
4:44
Speaker 2: trovarle nel portale di Azure, cercare ciò di cui hai
4:46
Speaker 2: bisogno e assegnarle subito. Non è richiesto alcun JSON se
4:49
Speaker 2: non vuoi scriverlo. Ma la definizione memorizzata in un file
4:52
Speaker 2: non fa nulla. devi assegnarla per farla funzionare. Assegnazione di criteri,
4:55
Speaker 2: attuazione delle regole. Un'assegnazione di criteri è quando prendi la
4:58
Speaker 2: tua definizione e la indirizzi ad un ambito specifico. È
5:01
Speaker 2: semplicemente il confine in cui si applica quella regola. Hai
5:03
Speaker 2: tre scelte, dalla più ampia alla più ristretta. Assegnala a
5:06
Speaker 2: livello di gruppo di gestione e copre un intero set
5:08
Speaker 2: di sottoscrizioni. Rilasciala a livello di sottoscrizione e copre tutto
5:11
Speaker 2: ciò che si trova all'interno di tale sottoscrizione. Oppure assegnala
5:14
Speaker 2: a livello di gruppo di risorse e copre solo le
5:16
Speaker 2: risorse all'interno di tale gruppo. Ora parliamo di irritarietà. Questo
5:19
Speaker 2: è un concetto chiave. Quando assegni una policy a livello
5:21
Speaker 2: di gruppo di gestione, Questa si estende automaticamente a ogni
5:24
Speaker 2: sottoscrizione e gruppo di risorse sottostanti. Non devi assegnarla più
5:27
Speaker 2: o più volte. È come pubblicare una regola sulla bacheca
5:30
Speaker 2: principale all'ingresso di un edificio per uffici. Chiunque passi deve seguirla.
5:34
Speaker 2: Non pubblicheresti la stessa regola su ogni piano? Sarebbe uno
5:37
Speaker 2: spreco di tempo. La regola si estende semplicemente verso lui.
5:39
Speaker 2: Ma cosa succede quando hai bisogno di un eccezionale? Forse
5:41
Speaker 2: la tua azienda afferma che tutti i dati devono rimanere
5:43
Speaker 2: in Europa, ma un progetto ha una ragione legittima per
5:45
Speaker 2: utilizzare un data center in Asia. Non vuoi rimuovere l'intera
5:47
Speaker 2: policy altrimenti lasceresti tutto esposto. Quindi crei un'esenzione. Le esenzioni
5:52
Speaker 2: ti consentono di effettuare eccezioni per risorse o gruppi di
5:54
Speaker 2: risorse specifici senza eliminare la policy ovunque. È un modo
5:57
Speaker 2: pulito per gestire i casi lì. Ecco una guida pratica.
6:01
Speaker 2: Assegna le tue policy di base generali a livello di
6:03
Speaker 2: gruppo di gestione. Elementi come posizioni consentite o tag obbligatori
6:07
Speaker 2: dovrebbero essere applicati a tutto. Quindi assegna policy più specifiche
6:09
Speaker 2: a livello di sottoscrizione o gruppo di risorse. Forse il
6:12
Speaker 2: tuo abbonamento di sviluppo ha regole più flessibili rispetto al
6:14
Speaker 2: tuo abbonamento di produzione. Va benissimo. Le policy specifiche si
6:17
Speaker 2: aggiungono a quelle generali. Però parliamo di cosa succede effettivamente
6:20
Speaker 2: quando qualcuno infrange un Che entra in gioco gli effetti. Effetti.
6:24
Speaker 2: Cosa succede quando le regole vengono infrante? Quindi è scritto
6:26
Speaker 2: una regola e assegnata. Cosa succede quando qualcuno è infrante?
6:29
Speaker 2: Qui che entra in gioco gli effetti. Gli effetti sono
6:31
Speaker 2: la parte successiva della policy. Decidono cosa succede quando una
6:35
Speaker 2: risorsa non soddisfa la regola. Ne vedrai quattro principali. Innanzitutto, nega.
6:39
Speaker 2: Questo è l'effetto più comune per le regole critiche. Quando
6:42
Speaker 2: viene attivata una policy di negazione, la distribuzione viene bloccata completamente.
6:45
Speaker 2: L'utente riceve un messaggio di errore chiaro che indica che
6:47
Speaker 2: la convalida non è riuscita e spiega quale policy l'ha interrotta.
6:50
Speaker 2: Non viene creata alcuna risorsa, non viene fatto alcun danno.
6:53
Speaker 2: Utilizza questa opzione per le regole che non devono mai
6:54
Speaker 2: essere infratte. Ad esempio, nessun accesso a blob pubblici sugli
6:57
Speaker 2: account di archiviazione o nessuna distribuzione al di fuori delle
6:59
Speaker 2: regioni approvate. Secondo luogo, verifica. Questa funziona in modo diverso.
7:03
Speaker 2: La distribuzione viene eseguita, ma la risorsa viene contrassegnata, come
7:06
Speaker 2: non conforme nella dashboard di conformità. La verifica è incredibilmente
7:09
Speaker 2: utile quando non si è certi di come una nuova
7:10
Speaker 2: regola influirà sul proprio ambiente. È possibile vedere cosa sta
7:13
Speaker 2: succedendo senza compromettere nulla. È come effettuare una misurazione prima
7:16
Speaker 2: di applicare una modifica. Terzo, modifica e aggiungi. Questi effetti
7:20
Speaker 2: risolvono automaticamente il problema anziché bloccarlo. Modifica le impostazioni esistenti
7:24
Speaker 2: durante la distribuzione. Aggiunge qualcosa a un campo esistente? Ad
7:27
Speaker 2: esempio è possibile creare un criterio che aggiunge automaticamente un
7:29
Speaker 2: tag obbligatorio con un valore predefinito. Se qualcuno dimentica di
7:32
Speaker 2: aggiungere un tag del centro di costo, il criterio lo
7:34
Speaker 2: aggiunge per lui, la distribuzione viene completata e la risorsa
7:37
Speaker 2: è conforme senza ulteriore lavoro. Quarto, distribuisce se non esiste.
7:41
Speaker 2: Questo gestisce le situazioni in cui manca una risorsa di supporto.
7:44
Speaker 2: Supponiamo che si desideri abilitare la registrazione diagnostica su un'ecagnostica
7:47
Speaker 2: su un account. Se qualcuno crea un account di archiviazione
7:49
Speaker 2: senza impostazioni diagnostica, la distribuzione se non esiste si attiva
7:52
Speaker 2: e distribuisce automaticamente la configurazione mancata. È vero un aiutante
7:54
Speaker 2: che fa pulizia dietro di te. Ecco la best practice.
7:57
Speaker 2: Inizia con la verifica. Guarda, prima cosa sta effettivamente accadendo
7:59
Speaker 2: nel tuo ambiente. Scopri quante risorse sarebbero interessate da una
8:02
Speaker 2: nuova regola. Quindi passa a nega quando sei sicuro che
8:05
Speaker 2: la regola è corretta e non interromperà le distribuzioni illegittime.
8:08
Speaker 2: Gestire una policy è semplice. Ma cosa succede se ne
8:10
Speaker 2: servono 50 tutte relative alla sicurezza e alla conformità? Ecco
8:13
Speaker 2: dove entra in gioco l'iniziativa. iniziative che raggruppano le regole
8:17
Speaker 2: quindi cos'è un'iniziativa? considerala come una raccolta di polisi raggruppate
8:20
Speaker 2: attorno all'obiettivo comune invece di assegnare 50 polisi singole una
8:24
Speaker 2: per una assegni un'unica iniziativa che le contenga tutte te
8:28
Speaker 2: è come un kit di strumenti preconfezionato per un lavoro
8:30
Speaker 2: specifico non prendi separatamente un martello, un cacciavite e una
8:32
Speaker 2: chiave inglese prendi semplicemente l'intero kit strumento tutto ciò di
8:35
Speaker 2: cui hai bisogno è in un unico posto vero vantaggio
8:36
Speaker 2: in questo caso è la reportistica sulla comune quando assegni
8:38
Speaker 2: un'iniziativa ottieni una singola visualizzazione sulla conformità per l'intero gruppo
8:42
Speaker 2: puoi vedere a colpo d'occhio se il tuo ambiente soddisfa
8:44
Speaker 2: lo standard generale Se qualcosa non è conforme puoi analizzare
8:47
Speaker 2: direttamente la polisi specifica che non funziona. È molto più
8:50
Speaker 2: chiaro rispetto al monitoraggio di 50 polisi separate. Microsoft fornisce
8:53
Speaker 2: iniziative integrate che coprono i principali framework di conformità. Elementi
8:57
Speaker 2: come Azure Security Benchmark, CI, SNIST, PCI DSS, IPA ISO 27.1
9:02
Speaker 2: e altri. Questi sono già creati e pronti per assegnazione.
9:05
Speaker 2: Non devi capire quali criteri sono associati a quale requisito
9:08
Speaker 2: di conformità. Microsoft ha fatto questo lavoro per te. Alcune
9:11
Speaker 2: di queste iniziative contengono centinaia di singoli criteri. Immagina di
9:14
Speaker 2: provare ad assegnarli tutti uno per uno. Utilizzeresti l'iniziativa. Puoi
9:18
Speaker 2: anche creare iniziative personalizzate per i tuoi standard. Magari una
9:21
Speaker 2: baseline di produzione che include criteri per crittografia, registrazione e
9:24
Speaker 2: sicurezza di rete. Oppure un'iniziativa di standard di controllo di
9:27
Speaker 2: costi che limita le dimensioni delle VM e richiede tag
9:29
Speaker 2: di centri di conto. Stessa idea. Raggruppa i criteri, assegna
9:32
Speaker 2: il bundle e monitora la conformità come un'unica unità. Rendiamolo
9:35
Speaker 2: concreto con esempi concreti di come le persone usano effettivamente
9:38
Speaker 2: Azure Policy. Esempi concreti. Criteri in azione. Rendiamolo reale. Ecco
9:44
Speaker 2: 5 scenari comuni in cui Azure Policy risolve problemi reali.
9:47
Speaker 2: Innanzitutto restrizioni regionali per la conformità dei dati. Immagina che
9:50
Speaker 2: la tua azienda abbia una policy per cui tutti i
9:52
Speaker 2: dati dei clienti devono rimanere in Europa. Puoi assegnare le
9:55
Speaker 2: posizioni consentite tramite policy integrate a livello di gruppo di
9:57
Speaker 2: gestione radice e consentire solo le regioni UE. come Europa
10:00
Speaker 2: occidentale e Europa settentrionale. Ora, quando qualcuno crea un nuovo abbonamento,
10:03
Speaker 2: eredita automaticamente tale regola. Non può distribuire risorse negli Stati
10:07
Speaker 2: Uniti o in Asia anche se ci prova. La policy
10:09
Speaker 2: lo blocca. Nessun controllo manuale, nessuna richiesta di autorizzazione. La
10:12
Speaker 2: regola viene semplicemente applicata. In secondo luogo, applicazione dei tag
10:14
Speaker 2: per allocazione V. Il tuo team finanziario deve tenere traccia
10:17
Speaker 2: della spesa per reparto, ma non può farlo se le
10:19
Speaker 2: risorse non hanno i tag corretti. Quindi crei una policy
10:22
Speaker 2: che richiede un tag del centro di costo, un tag
10:24
Speaker 2: di ambiente su ogni risorsa... Ma ecco la parte interessante.
10:28
Speaker 2: Utilizzi l'effetto modifica. Se qualcuno dimentica di aggiungere il tag,
10:31
Speaker 2: la policy lo aggiunge automaticamente con un valore predefinito. La
10:34
Speaker 2: distribuzione viene completata e la risorsa è conforme. Il reparto
10:36
Speaker 2: finanziario tiene dati sui costi accurati e gli sviluppatori non
10:38
Speaker 2: vengono bloccati da un tag mancato. In terzo luogo, controllo
10:41
Speaker 2: dei costi nello sviluppo. I team di sviluppo hanno a sperimentare,
10:43
Speaker 2: ma gli esperimenti possono diventare costosi rapidamente. Qualcuno potrebbe creare
10:46
Speaker 2: un'istanza GPU con 24 core solo per testare uno script semplice.
10:49
Speaker 2: Quindi crei una policy che limita le dimensioni delle VM
10:51
Speaker 2: negli abbonamenti di sviluppo a scopi piccoli. Cose come serie
10:54
Speaker 2: B o serie D con core limitati. Se qualcuno prova
10:57
Speaker 2: a distribuire una GPU costosa a una VM con molta memoria,
11:00
Speaker 2: l'effetto di negazione si attiva e la blocca. Gli sviluppatori
11:02
Speaker 2: possono comunque sperimentare ma non possono sforare il budget. Quarto,
11:05
Speaker 2: baseline di sicurezza per l'archiviazione. Gli account di archiviazione sono
11:08
Speaker 2: uno dei luoghi più comuni in cui si verificano errori
11:10
Speaker 2: di sicurezza. Qualcuno crea un account di archiviazione con accesso
11:13
Speaker 2: blob pubblico e improvvisamente i dati sensibili vengono esposti a internet.
11:16
Speaker 2: Quindi crea una policy che richiede solo traffico HTTPS e
11:19
Speaker 2: blocca l'accesso blob pubblico e usi deploy if not exist
11:22
Speaker 2: per abilitare automaticamente la registrazione diagnostica su ogni account di
11:25
Speaker 2: archiviazione che ne è sprovvisto. La policy risolve il problema
11:28
Speaker 2: prima che diventi un problema. 5. Convenzioni di denominazione Il
11:32
Speaker 2: tuo team desidera che tutte le risorse inizino con prod
11:34
Speaker 2: o dev in modo da poter facilmente stabilire a quale
11:36
Speaker 2: ambiente appartiene qualcosa. Crea un criterio che verifica il nome
11:40
Speaker 2: della risorsa rispetto al modello, ma invece di bloccare la distribuzione,
11:43
Speaker 2: utilizzi l'effetto di controllo. La risorsa viene creata, ma viene
11:46
Speaker 2: contrassegnata come non conforme. Quindi esegui un rapporto di conformità
11:49
Speaker 2: mensile e chiedi al team di correggere la dominazione. È
11:51
Speaker 2: un modo delicato per applicare gli standard senza interrompere i
11:53
Speaker 2: flussi di lavoro. Ognuno di questi esempi segue lo stesso modello.
11:56
Speaker 2: Identifica il problema. Sceglie o crea il criterio. Decidi l'effetto.
12:00
Speaker 2: Assegna l'ambito giusto. Monitora la conformità. Questo è Playbook. Allontaniamoci
12:05
Speaker 2: e vediamo come tutti questi elementi si inseriscono nel quadro
12:07
Speaker 2: più ampio della governance di Agile. quadro generale, come tutto
12:10
Speaker 2: si collega. Quindi dove si inserisce il criterio di Azure
12:13
Speaker 2: nel quadro più ampio? Pensiamoci in questo modo. Il criterio
12:16
Speaker 2: di Azure funziona a livello di piano di controllo, direttamente
12:18
Speaker 2: sopra Azure Resource Manager, e valuta ogni singola richiesta in arrivo.
12:23
Speaker 2: Ogni volta che qualcuno crea, aggiorna o elimina una risorsa,
12:25
Speaker 2: il criterio di Azure verifica le regole. È il custode all'ingresso. Ora,
12:29
Speaker 2: non è l'unico strumento nella cassetta di attrezze da governare.
12:32
Speaker 2: I criteri di Azure sono solo un elemento di un
12:33
Speaker 2: sistema più ampio. I gruppi di gestione forniscono la gerarchia
12:36
Speaker 2: per organizzare le sottoscrizioni e applicare regole su larga scala.
12:39
Speaker 2: Il controllo degli accessi in base al ruolo stabilisce chi
12:41
Speaker 2: ha accesso a cosa, mentre i criteri di Azure controllano
12:43
Speaker 2: quali configurazioni sono consentite. Insieme costituiscono la base della governance
12:47
Speaker 2: del cloud. Ecco il punto. I criteri di Azure sono
12:50
Speaker 2: anche il motore e la base di altri servizi che
12:51
Speaker 2: potresti già utilizzare. Microsoft Defender for Cloud utilizza i criteri
12:54
Speaker 2: di Azure per generare le raccomandazioni di conformità. Quando Defender
12:57
Speaker 2: ti comunica che un account di archiviazione non è conforme,
13:00
Speaker 2: in realtà sta eseguendo una valutazione dei criteri. Azure Advisor
13:03
Speaker 2: ricava molte delle raccomandazioni su costi e affidabilità dalle stesse
13:06
Speaker 2: valutazioni dei criteri. E il dashboard di conformità nel portale
13:09
Speaker 2: di Azure è tutto basato sui dati dei criteri. Quindi
13:11
Speaker 2: anche se non hai mai creato personalmente dei criteri, probabilmente
13:14
Speaker 2: li hai utilizzati senza saperlo. Esiste un'altra pratica denominata criteri
13:17
Speaker 2: come codice. Invece di creare criteri tramite il portale, li
13:20
Speaker 2: archivi come file JSON in un repository Git e li
13:22
Speaker 2: distribuisci tramite pipeline CICD proprio come il codice dell'applicazione. Ciò
13:26
Speaker 2: ti offre controllo della versione revisione del codice test automatizzati
13:29
Speaker 2: per le tue regole di governance. È un modo più
13:31
Speaker 2: scalabile per gestire i criteri nelle grandi organizzazioni. Ecco la
13:34
Speaker 2: cosa più importante da ricordare. Una volta configurati correttamente, i
13:37
Speaker 2: criteri di Azure vengono eseguiti in background in modo invisibile.
13:40
Speaker 2: È la barriera di sicurezza automatica che previene i problemi
13:42
Speaker 2: prima che si verifichino. Gli utenti potrebbero non accorgersene mai,
13:45
Speaker 2: ma ne traggono vantaggio ogni volta che distribuiscono una risorsa.
13:48
Speaker 2: Ottieni un'applicazione coerente ogni volta, senza controlli manuali, ticket di
13:51
Speaker 2: approvazione o errori umani. Ecco come funziona Azure Policy in
13:55
Speaker 2: parole povere. È un regolamento invisibile che applica gli standard
13:58
Speaker 2: della tua organizzazione a ogni risorsa, ogni volta. Se vuoi
14:02
Speaker 2: un'unica azione da questo episodio, eccola. Accedi al portale di Azure,
14:06
Speaker 2: trova i criteri e assegni i criteri predefiniti sulle posizioni
14:08
Speaker 2: consentite a una sottoscrizione di prova. Inizia con l'audit e
14:11
Speaker 2: guarda cosa succede. Questo è il modo più rapido per
14:13
Speaker 2: capire come funziona. Iscriviti per ricevere altri spunti di conoscenza
14:16
Speaker 2: Microsoft e condividili con qualcuno che sta iniziando il suo
14:18
Speaker 2: percorso con Azure. Lascia un commento con la spiegazione successiva
14:20
Speaker 2: che vorresti che ti spiega.