Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Cos'è una Azure Landing Zone? Le 8 aree di progettazione spiegate: governance invece del caos nel cloud (Doppiaggio IA)

Transcript

Cos'è una Azure Landing Zone? Le 8 aree di progettazione spiegate: governance invece del caos nel cloud (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Benvenuti ad un altro episodio delle Microsoft Knowledge Nuggets qui
0:02
Speaker 2: su M365FM. Sono il vostro host Mirko Piter. In questa
0:05
Speaker 2: serie prendiamo la tecnologia Microsoft e la spieghiamo in parole semplici.
0:09
Speaker 2: L'argomento di oggi è qualcosa di cui quasi tutti hanno
0:11
Speaker 2: sentito parlare ma che pochi sanno spiegare davvero. Le azzure
0:13
Speaker 2: landing zone. Ecco la situazione. Immaginate di ereditare un tenante
0:16
Speaker 2: giorno in cui ogni team ha fatto di testa propria.
0:19
Speaker 2: Nessuna convenzione di nomenclatura, nessuna policy, nessun piano di rete,
0:21
Speaker 2: sottoscrizioni ovunque. Alcune per produzione e altre per i test
0:24
Speaker 2: e non si capisce cos'è. Nessuno sa chi possiede cosa,
0:27
Speaker 2: la fattura è un mistero e quando qualcosa si rompe.
0:29
Speaker 2: Trovare il problema richiede ore. Questo è il problema del
0:31
Speaker 2: caos nel cloud ed è sorprendentemente comune. Più comune di
0:34
Speaker 2: quanto si pensi. Le Azure Landing Zone servono a prevenire
0:37
Speaker 2: questo disastro prima che niente. Alla fine di questo episodio
0:40
Speaker 2: capirete cos'è davvero una Landing Zone, perché le otto aree
0:42
Speaker 2: di progettazione contano e come evitare gli errori più comuni.
0:46
Speaker 2: Prendete il vostro caffè e iniziamo. Cos'è in realtà un
0:49
Speaker 2: Azure Landing Zone? Molti pensano che un Azure Landing Zone
0:52
Speaker 2: sia un prodotto da cliccare per distribuire, ma non è così.
0:55
Speaker 2: Non c'è un pulsante nel portale con scritto Crea Landing Zone.
0:57
Speaker 2: Non funziona così. Una landing zone è un ambiente preconfigurato
1:00
Speaker 2: con dei binari di sicurezza già pronti. Networking, identità, monitoraggio, policy,
1:04
Speaker 2: tutto collegato prima ancora dell'arrivo di qualsiasi carico di lavoro.
1:07
Speaker 2: Pensatela come l'acquisto di una casa che ha già elettricità,
1:09
Speaker 2: idraulica e sistema di sicurezza. Vi trasferite e iniziate a
1:13
Speaker 2: lavorare senza dover installare gli impianti da solo. L'idea principale
1:16
Speaker 2: è che la sottoscrizione sia l'unità di isolamento, non il
1:18
Speaker 2: resource group. Una sottoscrizione è il confine del vostro raggio d'azione.
1:22
Speaker 2: Date una sottoscrizione a un team perché le sottoscrizioni hanno
1:24
Speaker 2: i propri limiti di quota, assegnazione di policy, fatturazione, etc.
1:27
Speaker 2: La landing zone avvolge quella sottoscrizione con tutto ciò che
1:29
Speaker 2: viene deciso centralmente. Quali regioni sono consentite, a quale rete connettersi,
1:33
Speaker 2: quali tag sono obbligatori e cosa è vietato fare. Quindi
1:37
Speaker 2: cosa applica effettivamente le regole? Azure Policy, non la documentazione,
1:40
Speaker 2: non le buone intenzioni, viene assegnata a livello di management
1:42
Speaker 2: group e svolge tre compiti. Deny e blocca elementi come
1:45
Speaker 2: regioni non consentite o indirizzi più pubblici. Audit segnala le
1:48
Speaker 2: risorse non conformi senza bloccarle. Deploy if not exist correggia
1:52
Speaker 2: automaticamente distribuendo elementi come le impostazioni di diagnostica per log
1:55
Speaker 2: analytics o i piani di Microsoft Defender. Questa è la
1:57
Speaker 2: differenza tra una governance che è una pagina wiki e
1:59
Speaker 2: una governance che è codice. I team si muovono velocemente
2:02
Speaker 2: dentro la loro scatola, ma il team di piattaforma controlla
2:04
Speaker 2: la scatola, non il contenuto. Il grande cambiamento è permettere
2:07
Speaker 2: ai team di avere le proprie sottoscrizioni, mentre il team
2:08
Speaker 2: centrale stabilisce le regole. Identità e governance. La porta d'ingresso
2:12
Speaker 2: al regolamento. Il punto è questo. Una landing zone non
2:15
Speaker 2: è un elemento singolo, è composta da otto aree di progettazione.
2:18
Speaker 2: Analizziamo le prime tre. La prima riguarda la fatturazione azzurra
2:21
Speaker 2: e il tenant entra. Si tratta di configurare correttamente il
2:24
Speaker 2: tenant e la sottoscrizione fin dall'inizio. Sembra semplice, ma ti
2:27
Speaker 2: stupiresti di quante organizzazioni sbagliano. Devi pensare alla struttura di fatturazione,
2:31
Speaker 2: all'enrollment e a come tutto si collega al tuo tenant.
2:33
Speaker 2: Entra prima di distribuire qualsiasi cosa. Il tuo principale confine
2:37
Speaker 2: di sicurezza è la gestione dell'identità e degli accessi. Pensa
2:39
Speaker 2: a EntryD come alla reception di un edificio per uffici.
2:42
Speaker 2: Decide chi può entrare e cosa è autorizzato a fare.
2:44
Speaker 2: Dovresti usare il Privileged Identity Management, o PIM, e imporre
2:48
Speaker 2: a ruoli airbag con privilegi minimi. Non dare a tutti
2:51
Speaker 2: l'accesso proprietario è la ricetta per un disastro. Usa invece
2:54
Speaker 2: il PIN per concedere un accesso temporaneo just in time
2:56
Speaker 2: quando serve e imposta revisioni periodiche per rinnovare i permessi
2:59
Speaker 2: non più necessari. La terza area di progettazione è l'organizzazione
3:02
Speaker 2: delle risorse. Gruppi di gestione, sottoscrizioni e gruppi di risorse.
3:06
Speaker 2: I gruppi di gestione stanno sopra le sottoscrizioni e le
3:09
Speaker 2: policy e le assegnazioni dei ruoli vengono ereditate verso il
3:11
Speaker 2: basso nell'anno. La gerarchia di riferimento del Cloud Adoption Framework
3:14
Speaker 2: parte dalla radice del tenant, poi un gruppo intermedio per
3:17
Speaker 2: la tua organizzazione. Sotto di esso hai piattaforma, landing zone,
3:20
Speaker 2: dismiss e sandboxer. La piattaforma contiene le tue sottoscrizioni condivise,
3:24
Speaker 2: la gestione dell'identità e la connettività. Le landing zone si
3:28
Speaker 2: dividono in corp, per i carichi che necessitano di connettività
3:30
Speaker 2: on- premise e online, per le app esposte su internet, perché
3:33
Speaker 2: la struttura è importante. Se in una volta in alto
3:35
Speaker 2: nell'albero e tutto ciò che sta sotto diventa conforme automaticamente.
3:38
Speaker 2: Un esempio reale, una policy di negazione al vertice, blocca
3:41
Speaker 2: le regioni, non consentite per ogni sottoscrizione sottostante. Non devi
3:44
Speaker 2: configurarla 50 volte. Impostala una volta e viene reeditata, questo
3:47
Speaker 2: è il vero potere della gerarchia dei gruppi di gestione.
3:50
Speaker 2: Networking e sicurezza, le mure e le serrature? Identità e
3:53
Speaker 2: governance stabiliscono le regole. Ma nulla funziona se la rete
3:56
Speaker 2: è un disastro. La topologia di rete e la connettività
3:59
Speaker 2: sono la quarta area di progettazione, come sono strutturate le
4:01
Speaker 2: tue reti virtuali. Esistono due pattern principali, hub and spoke,
4:04
Speaker 2: dove hai una rete virtuale centrale come hub e più
4:07
Speaker 2: reti spoke che si collegano ad essa, oppure Azure Virtual One,
4:11
Speaker 2: la versione gestita da Microsoft su scala maggiore. L'hub contiene
4:14
Speaker 2: tutti i tuoi servizi condivisi. Azure Firewall per l'ispezione del traffico,
4:18
Speaker 2: ExpressRoute o Gateway VPN per la connettività on- premise, risoluzione DNS,
4:21
Speaker 2: cose di cui ogni carico di lavoro ha bisogno. Gli
4:23
Speaker 2: Spock sono dove vengono effettivamente eseguiti i tuoi carichi di roba.
4:26
Speaker 2: Si collegano all'hub, così il traffico passa attraverso i servizi centrali,
4:29
Speaker 2: ma ogni Spock rimane isolato dagli altri. Ecco un errore comune.
4:33
Speaker 2: I team creano una gigantesca mesh di peering invece di
4:35
Speaker 2: usare un hub, collegando ogni rete virtuale direttamente alle altre.
4:39
Speaker 2: Funziona per un po', ma diventa presto un caos. Si
4:42
Speaker 2: finisce con una ragnatela di connessioni che nessuno riesce a tracciare.
4:45
Speaker 2: Un hub semplifica tutto. Un unico punto da gestire, un
4:48
Speaker 2: unico punto da proteggere. Pianificate gli intervalli di indirizzo in anticipo.
4:51
Speaker 2: È più importante di quanto pensiate. Una volta che gli
4:53
Speaker 2: SPOC sono in peering con un hub, correggere gli spazi
4:55
Speaker 2: e gli indirizzi sovrapposti è complicato. Non si possono sempre cambiare.
4:58
Speaker 2: Bisogna eliminare il peering, aggiornare l'intervallo e riconnettere tutto. Se
5:02
Speaker 2: avete carichi di lavoro in produzione, significa downtime, quindi scedete
5:04
Speaker 2: presto agli intervalli CDR e assicuratevi che non si sovrappongano.
5:07
Speaker 2: L'area di progettazione 5 riguarda i consigli sulla sicurezza, inclusi criptografia,
5:10
Speaker 2: protezione dell'identità, rilevamento delle minacce, gestione delle minacce, gestione del meraviglio.
5:14
Speaker 2: Abilitate Microsoft Defender for Cloud su tutte le sottoscrizioni come
5:16
Speaker 2: base di riferimento. Fornisce consigli sulla gestione della postura, avvisi
5:20
Speaker 2: e indicazioni di risoluzione per tutto ciò che è nel
5:22
Speaker 2: vostro ambiente. Usate endpoint vati per tenere i servizi fuori
5:25
Speaker 2: da internet pubblico. Invece di accedere a un account di
5:28
Speaker 2: archiviazione tramite un IP pubblico, gli assegnate un IP privato
5:31
Speaker 2: all'interno della vostra rete virtuale. Il traffico non lascia mai
5:33
Speaker 2: la dorsa del Microsoft. È più sicuro e più semplice
5:35
Speaker 2: da gestire. Inserite gruppi di sicurezza di rete su ogni
5:38
Speaker 2: subnet e bloccate l'RDP d'ingresso da internet per impostazione predefinita.
5:41
Speaker 2: Dovrebbe essere lo stesso. Se qualcuno necessita di accesso remoto
5:44
Speaker 2: usa Azure Bastion o Unjumpbox, non una regola RDP diretta.
5:48
Speaker 2: Un esempio reale è una policy di negazione che blocca
5:50
Speaker 2: gli indirizzi più pubblici sugli account di archiviazione. Assegnate la
5:53
Speaker 2: policy a livello di management group e, nel momento in
5:55
Speaker 2: cui qualcuno prova a distribuire un account di archiviazione con
5:57
Speaker 2: endpoint pubblico, il deployment fallisce. Il messaggio di errore spiega
6:00
Speaker 2: il motivo e l'utente è costretto ad usare un endpoint privato.
6:03
Speaker 2: Questo è una governance che funziona davvero, non un semplice
6:05
Speaker 2: suggerimento scritto in un documento. Gestione, governance e automazione per
6:09
Speaker 2: mantenere tutto operativo. Dunque, avete il vostro edificio con muri
6:11
Speaker 2: e serrature, ma cosa sta succedendo all'interno? Avete delle d'occhio tutto.
6:15
Speaker 2: L'area di progettazione si riguarda la gestione. Include monitoraggio, backup,
6:18
Speaker 2: log e l'aspetto operativo. Volete un'area di lavoro log analytics
6:21
Speaker 2: centrale in cui ogni sottoscrizione invii i propri log. Un
6:24
Speaker 2: unico posto per interrogare tutto, impostare avvisi e risolvere problemi.
6:27
Speaker 2: Questo è l'obiettivo. Ora, come assicuratevi che ogni singola risorsa
6:30
Speaker 2: invii i propri log di diagnostica? Non si fa a mano.
6:32
Speaker 2: Create una policy che dice« ogni risorse ad inviare log
6:35
Speaker 2: di diagnostica a quest'area di lavoro log analytics». e impostate
6:38
Speaker 2: quella policy per l'esecuzione in modalità deploy if not exist.
6:41
Speaker 2: Il risultato è che ogni nuova risorsa viene configurata automaticamente.
6:43
Speaker 2: Nessuno deve ricordarsene. Succede e basta. L'area di progettazione 7
6:47
Speaker 2: è la governance che usa Azure Policy per imporre la conformità.
6:49
Speaker 2: Si raggruppano le regole correlate in quella che viene chiamata
6:52
Speaker 2: iniziativa di policy o set di policy. Un'iniziativa per la sicurezza,
6:55
Speaker 2: un'altra per la gestione dei costi. Ognuna contiene molteplici policy
6:59
Speaker 2: che lavorano insieme. Ecco un esempio. Un set di policy
7:02
Speaker 2: che impone crittografia, tagging e dimensioni consentite per le macchine virtuali.
7:06
Speaker 2: Si applica a livello di gruppo di gestione. Ogni sottoscrizione
7:08
Speaker 2: sottostante eredita tali regole. Quando uno sviluppatore prova a distribuire
7:12
Speaker 2: una VM, la policy verifica che usi una dimensione approvata,
7:15
Speaker 2: abbia i tag richiesti e usi dischi criptografati. Se un
7:18
Speaker 2: controllo fallisce, la distribuzione viene bloccata o segnalata all'istante. Facciamo
7:22
Speaker 2: chiarezza sulla differenza tra una governance che vive su una
7:24
Speaker 2: pagina Wiki e una che è codice vero e proprio.
7:26
Speaker 2: Una pagina Wiki dice per favore aggiungi tag alle tue risorse.
7:29
Speaker 2: La policy dice non puoi distribuire una risorsa senza i
7:31
Speaker 2: tag richiesti. Una è un suggerimento, l'altra è applicata automaticamente.
7:36
Speaker 2: L'area di progettazione 8 è l'automazione della piattaforma e DevOps.
7:39
Speaker 2: Infrastruttura come codice e pipeline CISCD. Tratta la landing zone
7:43
Speaker 2: stessa come codice. Ciò significa BCHEP, modelli ARM o terraform
7:46
Speaker 2: archiviati nel controllo del codice sorgente. Ogni modifica passa attraverso
7:49
Speaker 2: una pure request. Ogni distribuzione viene eseguita tramite una pipeline.
7:52
Speaker 2: Niente click nel portale di Azure. Qui entra in gioco
7:54
Speaker 2: il subscription bending. Una pipeline ripetibile che crea nuove sottoscrizioni
7:57
Speaker 2: su richiesta. Un team invia una richiesta con parametri come
8:00
Speaker 2: centro di costo, dimensioni della rete e tipo di ambiente.
8:03
Speaker 2: La pipeline crea la sottoscrizione, la inserisce nel gruppo di
8:06
Speaker 2: gestione corretto, assegna i budget, configura la rete Spoke e
8:09
Speaker 2: la connette all'hub. Tutto matizzato. Perché è importante? Perché la
8:14
Speaker 2: nuova sottoscrizione è conforme dal momento in cui esiste. Le
8:17
Speaker 2: policy sono già sul gruppo di gestione e la sottoscrizione
8:19
Speaker 2: eredita tutto automaticamente. Non c'è un intervallo in cui non
8:22
Speaker 2: si è regolamentato. Nessun essere umano deve ricordarsi di applicare
8:24
Speaker 2: le regole. Sono già lì. Questo permette a un team
8:27
Speaker 2: di piattaforma di supportare centinaia di sottoscrizioni senza diventare un
8:30
Speaker 2: collo di bottiglia. L'automazione fa lavoro pesante e il team
8:33
Speaker 2: si concentra sul miglioramento della piattaforma invece di cliccare nel
8:35
Speaker 2: portale per ogni singola richiesta. La distinzione tra piattaforma e
8:39
Speaker 2: applicazione è la confusione più comune. Quindi queste sono le
8:42
Speaker 2: otto aree di progettazione, ma ecco dove molti sbagliano. Ci
8:45
Speaker 2: sono due tipi di landing zone e confonderle è l'errore
8:48
Speaker 2: più comune che vedo. Landing zone di piattaforma e landing
8:50
Speaker 2: zone di applicazione. Servono scopi completamente diversi. Le landing zone
8:53
Speaker 2: di piattaforma sono le fondamenta condivise, gestite dal team di piattaforme.
8:56
Speaker 2: Hai una sottoscrizione di identità che contiene i servizi di dominio,
8:59
Speaker 2: una sottoscrizione di gestione con log analytics e account di automazione,
9:02
Speaker 2: una sottoscrizione di connettività che ospita la rete virtuale Hub,
9:05
Speaker 2: Azure Firewall e Gateway Express Route o VPN. Questi sono
9:09
Speaker 2: i servizi condivisi da cui dipende ogni carico di lavoro.
9:11
Speaker 2: Le zone di destinazione dell'applicazione sono dove vengono effettivamente eseguiti
9:14
Speaker 2: i carichi di log. Queste sono le sottoscrizioni che vengono
9:16
Speaker 2: assegnate ai team applicativi. Sono numerose. Sono usa e getta.
9:19
Speaker 2: E seguono sempre lo stesso schema. Un team ottiene una sottoscrizione,
9:22
Speaker 2: viene inserita nel gruppo di gestione corretto, eredita le policy,
9:25
Speaker 2: si collega alla rete hub e inizia il deployment. La
9:28
Speaker 2: differenza di proprietà è importante. Le zone di piattaforma sono poche,
9:31
Speaker 2: forse da 3 a 5 sottoscrizioni in totale. Sono a
9:33
Speaker 2: lungo termine gestite centralmente dal team di piattaforma. Le zone
9:36
Speaker 2: applicative sono molte. Potresti averne decine o centinaia. Sono temporanee.
9:39
Speaker 2: Un carico di lavoro viene distribuito e eseguito per un
9:42
Speaker 2: pop e dismesso. La sottoscrizione viene ripulita e il modello
9:45
Speaker 2: si ripete. Ecco il classico antipattern. Qualcuno inserisce un firewall
9:48
Speaker 2: condiviso in una sottoscrizione applicativa o distribuisce il Gateway Express
9:51
Speaker 2: Route in una sottoscrizione di carico di lavoro anziché in
9:54
Speaker 2: quella di connettività. Ora i servizi condivisi sono sparsi in
9:56
Speaker 2: tutto l'ambiente? Nessuno sa dove si trovi cosa. Il team
9:59
Speaker 2: di piattaforma non può gestire il firewall perché è nella
10:01
Speaker 2: sottoscrizione di qualcun altro. E il team applicativo non vuole occuparsene.
10:05
Speaker 2: È un disastro. Mantieni i servizi condivisi nel livello di piattaforma.
10:08
Speaker 2: La sottoscrizione di connettività contiene la rete virtuale Hub, Azure
10:11
Speaker 2: Firewall e il Gateway Express Route. Le sottoscrizioni applicative si
10:14
Speaker 2: collegano a EIS. Non possiedono nulla di tutto ciò. Lo
10:17
Speaker 2: usano semplicemente. Ciò che questo significa per te è una
10:19
Speaker 2: chiara separazione delle responsabilità. Il team di piattaforma controlla il sistema,
10:23
Speaker 2: le protezioni, i servizi condivisi e le policy. I team
10:26
Speaker 2: applicativi si muovono rapidamente al suo interno. Ottengono una sottoscrizione
10:29
Speaker 2: già conforme, già connessa, già monitorata. Non devono pensare alle fondamenta.
10:33
Speaker 2: Devono solo costruirsi. Come si collegano i pezzi. Il momento
10:36
Speaker 2: della rivelazione. Quindi ora conosci i singoli blocchi costitutivi. Ma
10:39
Speaker 2: ecco cosa conta davvero. Non funzionano in isolamento. Lavorano insieme
10:42
Speaker 2: come un sistema connesso ed è qui che tutto prende forma.
10:45
Speaker 2: Pensalo in questo modo. L'identità decide chi può avarcare la
10:48
Speaker 2: porta principale. La governance indica poi in quali stanze possono
10:51
Speaker 2: entrare una volta avarcata la soglia. Il networking controlla come
10:54
Speaker 2: si spostano tra quelle stanze. La sicurezza sorveglia le minacce
10:57
Speaker 2: dietro ogni angolo. La gestione mantiene l'edificio in funzione senza intoppi.
11:01
Speaker 2: E l'automazione rende ogni singolo passaggio ripetibile così nulla viene dimenticato.
11:05
Speaker 2: Ogni pezzo dipende dagli altri e insieme creano qualcosa di
11:07
Speaker 2: molto più grande di ogni singola parte. Lasciatemi fare un
11:10
Speaker 2: esempio concreto di come funziona realmente questa interazione. Immaginate che
11:12
Speaker 2: un nuovo team debba distribuire un carico di lavoro. Inoltre
11:15
Speaker 2: hanno una richiesta tramite la pipeline di fornitura degli abbonamenti
11:17
Speaker 2: che ne crea automaticamente uno nuovo di zecca. Inserisce quell'abbonamento
11:22
Speaker 2: nel gruppo di gestione corretto, così eredita immediatamente tutte le
11:25
Speaker 2: policy presenti in quel gruppo. Requisiti di criptografia, regioni consentite,
11:29
Speaker 2: tag obbligatori, configurazioni di log, tutto ciò di cui ha bisogno.
11:34
Speaker 2: La pipeline configura anche la rete SPO che la collega alla.
11:37
Speaker 2: Le impostazioni di diagnostica inviano i log direttamente all'area di
11:40
Speaker 2: lavoro Log Analytics centralizzata, mentre Defender for Cloud attiva la protezione.
11:44
Speaker 2: L'intero abbonamento risulta conforme, connesso e monitorato in pochi minuti
11:47
Speaker 2: senza alcun intervento umano. Questa è la vera differenza tra
11:51
Speaker 2: caos nel cloud e controllo del cloud. Nell'ambiente disordinato che
11:54
Speaker 2: ho descritto all'inizio, ogni singolo passaggio dipende dal fatto che
11:57
Speaker 2: qualcuno se ne ricordi e le persone dimenticano. Oppure lo
12:00
Speaker 2: fanno a un livello diverso, o non lo fanno affatto.
12:02
Speaker 2: Ma con una landing zone adeguata, tutto è automatico. Il
12:05
Speaker 2: sistema si autoimpone e il team può muoversi velocemente senza
12:08
Speaker 2: rompere nulla. Ecco dove inciampano la maggior parte delle organizzazioni.
12:11
Speaker 2: Trattano la landing zone come un progetto natantum. La distribuiscono,
12:14
Speaker 2: spuntano la casella e passano oltre. Una landing zone è
12:16
Speaker 2: una piattaforma viva. Rilascia costantemente nuove funzionalità. I vostri requisiti
12:20
Speaker 2: di conformità cambiano. La vostra attività cresce. La landing zone
12:23
Speaker 2: deve crescere insieme ad essa, altrimenti inizierà a lavorare contro
12:25
Speaker 2: di voi. Il modello operativo contiene in realtà più dei
12:27
Speaker 2: template tecnici. Chi è il proprietario della landing zone? Come
12:29
Speaker 2: si evolve? Come vengono gestite le eccezioni? Se la vostra
12:32
Speaker 2: unica risposta è la gestisce il team della piattaforma, non
12:34
Speaker 2: è abbastanza. Avete bisogno di processi reali. Avete bisogno di backlog.
12:38
Speaker 2: Dovete trattare la landing zone come un prodotto, non come
12:39
Speaker 2: un progetto. Ecco un esempio reale. Un team di piattaforma
12:42
Speaker 2: supporta 200 abbonamenti senza diventare un collo di bottiglia. E
12:45
Speaker 2: si è creata la fornitura automatizzata degli abbonamenti, combinata con
12:48
Speaker 2: la rediettare 3. Il team non deve cliccare nel portale
12:50
Speaker 2: per creare ogni abbonamento. La pipeline lo gestisce automaticamente. Non
12:54
Speaker 2: devono configurare manualmente i logo per ogni carico di lavoro.
12:56
Speaker 2: Le policy lo impongono in modo coerente. Non devono rivedere
12:59
Speaker 2: ogni distribuzione per sostenere il metodo. La dashboard di conformità
13:01
Speaker 2: mostra loro solo le eccezioni. Si concentrano sui casi anomali
13:04
Speaker 2: anziché sul lavoro di routine. Questa è la differenza tra
13:06
Speaker 2: una piattaforma che scala e una che soffoca l'azienda. Consigli pratici.
13:11
Speaker 2: Iniziati in piccolo, crescete in modo intelligente. Quindi, cosa farete
13:14
Speaker 2: concretamente lunedì mattina? Ecco la risposta onesta. Non cercate di
13:17
Speaker 2: costruire l'intera gerarchia enterprise scale fin dal primo giorno. È
13:20
Speaker 2: una trappola che volete evitare. Passerai mesi a progettare scenari
13:23
Speaker 2: che potrebbero non verificarsi mai e non riuscirai mai a
13:25
Speaker 2: distribuire nulla di concreto. Inizia invece con una landing zone
13:28
Speaker 2: minima vitale o MVLZ. I componenti principali sono semplici. Una
13:33
Speaker 2: gerarchia di gruppi di gestione. Alcune policy fondamentali come restrizioni
13:36
Speaker 2: di area, criptografie e tag obbligatori. Una rete di base
13:39
Speaker 2: con un singolo hub virtuale e uno SPOC. e la
13:41
Speaker 2: centralizzazione dei log in un'area di lavoro log analytics. Questo
13:45
Speaker 2: è sufficiente. Non serve Azure Virtual One dal primo giorno,
13:48
Speaker 2: né una complessa iniziativa di policy con 200 regole. Ti
13:51
Speaker 2: servono solo le protezioni necessarie per essere assicuri niente di più.
13:54
Speaker 2: Quindi implementa il tuo primo carico di lavoro reale nella MVAZ,
13:57
Speaker 2: non una VM di test o un carico di lavoro
13:59
Speaker 2: a cui il tuo team tiene davvero. Osserva il comportamento
14:01
Speaker 2: delle policy e vedi cosa non funziona. Impara dalle difficoltà
14:04
Speaker 2: e poi procedi per iterazioni. Aggiungi policy quando servono. espandi
14:07
Speaker 2: la rete quando necessario e lascia che la landing zone
14:09
Speaker 2: cresca naturalmente con la tua organizzazione. Ti darò tre consigli
14:12
Speaker 2: concreti che puoi mettere in pratica subito. Primo consiglio. Distribuisci
14:17
Speaker 2: l'acceleratore per Azure Landing Zones dal portale in un tenant
14:19
Speaker 2: di test. Non costa nulla, richiede circa un'ora e ti
14:22
Speaker 2: insegna più su come funzionano realmente i gruppi di gestione,
14:25
Speaker 2: policy ed ereditarietà di qualsiasi diagramma o documentazione. Puoi vedere
14:29
Speaker 2: la gerarchia, guardare le policy, applicarsi in tempo reale e
14:33
Speaker 2: fare esperimenti senza rompere nulla di importante. Secondo consiglio, attiva
14:37
Speaker 2: le policy prime in modalità audit, non in modalità deny.
14:40
Speaker 2: La modalità audit ti permette di vedere esattamente cosa non
14:42
Speaker 2: è conforme nel tuo ambiente senza bloccare nessuno. Controlla la
14:45
Speaker 2: dashboard di conformità e ti prometto che rimarrai sorpreso da
14:47
Speaker 2: quante risorse stanno violando silenziosamente regole che sembravano. Una volta
14:51
Speaker 2: compreso il panorama, potrai impostare le policy importanti in modalità deny.
14:55
Speaker 2: Ma inizia con l'audit, così non bloccherai i tuoi team
14:57
Speaker 2: prima di sapere con cosa hai a che fare. Terzo consiglio,
15:01
Speaker 2: pianifica gli intervalli di indirizzi per la gerarchia dei gruppi
15:03
Speaker 2: di gestione prima di distribuire qualsiasi cosa. So che sembra noioso,
15:06
Speaker 2: ma modificarli in seguito è davvero doloroso. Intervalli IP sovrapposti
15:10
Speaker 2: significano smantellare il peering di rete, mentre ristrutturare i gruppi
15:13
Speaker 2: di gestione comporta spostare sottoscrizioni e rivalutare le assegnazioni delle policy.
15:16
Speaker 2: Fai queste due cose correttamente fin dall'inizio e risparmierai settimane
15:19
Speaker 2: di lavoro in futuro. Le insidie comuni sono piuttosto semplici.
15:22
Speaker 2: L'eccesso di progettazione porta a una paralisi d'analisi che ti
15:24
Speaker 2: impedisce di distribuire qualsiasi cosa. Una progettazione insufficiente ti lascia
15:28
Speaker 2: senza alcuna protezione, il che è solo Chaos Cloud, con
15:30
Speaker 2: un nome diverso. E trattare la landing zone come un
15:32
Speaker 2: progetto natanto, invece che come una piattaforma viva, ti farà
15:34
Speaker 2: inevitabilmente restare indietro. Evita queste tre trappole e sarai già
15:37
Speaker 2: davanti alla maggior parte dell'organizzazione. Ricorda, l'obiettivo non è una
15:40
Speaker 2: landing zone perfetta. L'obiettivo è una base governata che consenta
15:42
Speaker 2: ai team di muoversi velocemente senza creare caos. Inizia in piccolo,
15:45
Speaker 2: iterà e lascia che sia la policy a fare il
15:47
Speaker 2: lavoro pesante per te. Quindi queste sono le Azure Landing
15:50
Speaker 2: Zone a parole semplici. Non sono un concetto aziendale complicato.
15:53
Speaker 2: Pensare come una sottoscrizione governata con protezioni integrate. Le otto
15:57
Speaker 2: aree di progettazione sono solo le domande a cui rispondere
15:59
Speaker 2: prima di iniziare il deployment. Identità, networking, sicurezza, gestione, governance, automazione.
16:04
Speaker 2: Rispondi una volta, costruiscila nella base e ogni carico di
16:07
Speaker 2: lavoro successivo ne trarrà beneficio. Ecco la cosa migliore che
16:09
Speaker 2: puoi fare in questo momento. Distribuisci l'acceleratore in un ternante
16:12
Speaker 2: di test e osserva come vengono ereditate le policy. Quell'ora
16:15
Speaker 2: ti insegnerà più di quanto qualsiasi diagramma potrebbe mai fare.
16:17
Speaker 2: Iscriviti per altre spiegazioni semplici come questa e lascia un
16:19
Speaker 2: commento se qualcosa ti è chiaro. Li leggo tutti.