Governance dell'infrastruttura di Azure DevTest Labs

Questo articolo descrive l'allineamento e la gestione delle risorse di DevTest Labs all'interno dell'organizzazione.

Risorse

Allineare le risorse di DevTest Labs all'interno di una sottoscrizione di Azure

Prima che un'organizzazione inizi a usare Azure per lo sviluppo generico di applicazioni, i responsabili della pianificazione IT devono rivedere la procedura per introdurre la funzionalità nell'ambito del loro portfolio globale di servizi. Le aree per la revisione devono riguardare gli aspetti seguenti:

• Come misurare il costo associato al ciclo di sviluppo dell'applicazione?
• In che modo l'organizzazione allinea l'offerta di servizio proposta ai criteri di sicurezza aziendali?
• È necessaria la segmentazione per separare gli ambienti di sviluppo e produzione?
• Quali controlli vengono introdotti per semplificare a lungo termine la gestione, la stabilità e la crescita?

La prima procedura consigliata consiste nell'esaminare la tassonomia Azure delle organizzazioni, in cui vengono definite le divisioni tra le sottoscrizioni di sviluppo e produzione. Nel diagramma seguente la tassonomia consigliata consente una separazione logica degli ambienti di sviluppo/test e produzione. Con questo approccio, un'organizzazione può introdurre codici di fatturazione per tenere traccia dei costi associati a ogni ambiente separatamente. Per altre informazioni, vedere Governance prescrittiva per le sottoscrizioni. È anche possibile usare tag di Azure per organizzare le risorse ai fini di monitoraggio e fatturazione.

La seconda procedura consigliata consiste nell'abilitare la sottoscrizione di DevTest nel portale di Azure Enterprise. Consente a un'organizzazione di eseguire sistemi operativi client che in genere non sono disponibili in una sottoscrizione aziendale di Azure. Quindi, usare il software aziendale in cui si paga solo per il calcolo e non preoccuparsi delle licenze. In questo modo la fatturazione per i servizi designati, incluse le immagini delle raccolte in IaaS, ad esempio Microsoft SQL Server, è basata esclusivamente sulle risorse consumate. Sono disponibili informazioni dettagliate sulla sottoscrizione di Azure DevTest qui per i clienti Enterprise Agreement (EA) e qui per i clienti con pagamento in base al consumo.

Questo modello conferisce a un'organizzazione la flessibilità per distribuire Azure DevTest Labs su larga scala. Un'organizzazione può supportare centinaia di lab per varie business unit con 100-1000 macchine virtuali in esecuzione in parallelo. Eleva la nozione di una soluzione lab aziendale centralizzata in grado di condividere gli stessi principi di gestione della configurazione e i controlli di sicurezza.

Questo modello garantisce anche che l'organizzazione non esaurisca i limiti delle risorse associati alla sottoscrizione di Azure. Per informazioni dettagliate sui limiti della sottoscrizione e dei servizi, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi. Il processo di provisioning di DevTest Labs può usare un numero elevato di gruppi di risorse. È possibile richiedere l'aumento dei limiti tramite una richiesta di supporto nella sottoscrizione di Azure DevTest. Le risorse all'interno della sottoscrizione di produzione non sono interessate man mano che aumenta l'uso della sottoscrizione di sviluppo. Per altre informazioni sul ridimensionamento di DevTest Labs, vedere Ridimensionare i limiti e le quote in DevTest Labs.

Un limite comune a livello di sottoscrizione che deve essere considerato è la modalità di allocazione dell'assegnazione di intervalli IP di rete per supportare le sottoscrizioni di sviluppo e produzione. Queste assegnazioni devono tenere conto della crescita nel tempo (presupponendo la connettività locale o un'altra topologia di rete che richiede all'azienda di gestire i relativi stack di rete anziché impiegare per impostazione predefinita l'implementazione di Azure). La procedura consigliata è quella di avere poche reti virtuali con un prefisso elevato di indirizzi IP assegnato e diviso tra molte subnet di grandi dimensioni anziché avere più reti virtuali con subnet ridotte. Con 10 sottoscrizioni è ad esempio possibile definire 10 reti virtuali (una per ogni sottoscrizione). Tutti i lab che non richiedono l'isolamento possono condividere la stessa subnet nella rete virtuale della sottoscrizione.

Numero di utenti per lab e lab per organizzazione

Le business unit e i gruppi di sviluppo associati allo stesso progetto di sviluppo devono essere associati allo stesso lab. In questo modo è possibile applicare a entrambi i gruppi gli stessi tipi di criteri, immagini e criteri di arresto.

Potrebbe anche essere necessario considerare i limiti geografici. Gli sviluppatori nell'area degli Stati Uniti nordorientali potrebbero ad esempio usare un lab sottoposto a provisioning nell'area degli Stati Uniti orientali 2. E gli sviluppatori a Dallas, in Texas, e a Denver, in Colorado, potrebbero essere indirizzati all'uso di una risorsa negli Stati Uniti centro-meridionali. Se c'è un impegno collaborativo con una terza parte esterna, possono essere assegnati a un lab che non viene usato dagli sviluppatori interni.

È anche possibile usare un lab per un progetto specifico all'interno di Azure DevOps Projects. Si applica quindi la sicurezza tramite un gruppo Microsoft Entra specificato, che consente l'accesso a entrambi i set di risorse. La rete virtuale assegnata al lab può essere un altro limite al consolidamento degli utenti.

Impedire l'eliminazione delle risorse

Impostare le autorizzazioni a livello di lab in modo che solo gli utenti autorizzati possano eliminare le risorse o modificare i criteri del lab. Gli sviluppatori devono trovarsi all'interno del gruppo di utenti DevTest Labs. Il responsabile degli sviluppatori o dell'infrastruttura deve essere il proprietario di DevTest Labs. È consigliabile avere solo due proprietari di lab. Questi criteri si estendono al repository di codice per evitare il danneggiamento. Gli usi del lab hanno diritti per l'uso delle risorse, ma non possono aggiornare i criteri del lab. Vedere l'articolo seguente che elenca i ruoli e i diritti di ogni gruppo incorporato all'interno di un lab: Aggiungere proprietari e utenti in Azure DevTest Labs.

Gestire i costi e la proprietà

Costi e proprietà sono problemi primari quando si considera la creazione di ambienti di test e sviluppo. In questa sezione sono riportate informazioni che consentono di ottimizzare i costi e allineare la proprietà al proprio ambiente.

Ottimizzare in base ai costi

Diverse funzionalità predefinite di DevTest Labs consentono di ottimizzare i costi. Leggere gli articoli su gestione dei costi, sogliee criteri per limitare le attività degli utenti.

Se si usa DevTest Labs per carichi di lavoro di sviluppo e test, è consigliabile usare il vantaggio Enterprise Dev/Test Subscription che fa parte del Contratto Enterprise. In alternativa, se sei un cliente con pagamento in base al consumo, prendi in considerazione l'offerta DevTest con pagamento in base al consumo.

Questo approccio offre diversi vantaggi:

• Speciali tariffe di Sviluppo/test inferiori per macchine virtuali Windows, Servizi cloud, HDInsight, Servizio app e App per la logica
• Straordinarie tariffe per il Contratto Enterprise (EA) in altri servizi di Azure
• Accesso a immagini di Sviluppo/test esclusive nella raccolta, tra cui Windows 8.1 e Windows 10

Solo i titolari di sottoscrizioni attive di Visual Studio (sottoscrizioni standard, sottoscrizioni cloud annuali e sottoscrizioni cloud mensili) possono usare le risorse di Azure in esecuzione nell'ambito di una sottoscrizione dell'offerta Sviluppo/test Enterprise. Tuttavia, gli utenti finali possono accedere all'applicazione per fornire commenti e suggerimenti o eseguire test di accettazione. È possibile usare le risorse all'interno di questa sottoscrizione solo per lo sviluppo e il test di applicazioni. Non esiste alcuna garanzia di tempo di attività.

Se si decide di usare l'offerta DevTest, usare questo vantaggio esclusivamente per lo sviluppo e il test delle applicazioni. L'utilizzo all'interno della sottoscrizione non prevede un contratto di servizio con supporto finanziario, ad eccezione dell'uso di Azure DevOps e HockeyApp.

Definire l'accesso basato sui ruoli nell'organizzazione

L'IT centrale deve possedere solo ciò che è necessario e consentire ai team del progetto e dell'applicazione di avere il livello di controllo necessario. In genere significa che l'IT centrale possiede la sottoscrizione e gestisce le funzioni IT di base come le configurazioni di rete. Il set di proprietari per una sottoscrizione deve essere di piccole dimensioni. Questi proprietari possono nominare altri proprietari quando è necessaria o applicare criteri a livello di sottoscrizione, ad esempio "Nessun indirizzo IP pubblico".

Potrebbe essere presente un subset di utenti che richiedono l'accesso in una sottoscrizione, ad esempio il supporto di livello 1 o di livello 2. In questo caso, si consiglia di concedere a questi utenti l'accesso collaboratore in modo che possano gestire le risorse, ma non fornire l'accesso utente o modificare i criteri.

I proprietari delle risorse di DevTest Labs devono essere vicini al progetto o al team dell'applicazione. Questi proprietari comprendono i requisiti del computer e del software. Nella maggior parte delle organizzazioni, il proprietario della risorsa DevTest Labs è il responsabile del progetto o dello sviluppo. Questo proprietario può gestire utenti e criteri all'interno dell'ambiente lab e può gestire tutte le macchine virtuali nell'ambiente DevTest Labs.

Aggiungere membri del team del progetto e dell'applicazione al ruolo Utenti di DevTest Labs. Questi utenti possono creare macchine virtuali, in linea con i criteri a livello di lab e sottoscrizione. Gli utenti possono anche gestire le proprie macchine virtuali, ma non possono gestire macchine virtuali appartenenti ad altri utenti.

Per altre informazioni, vedere scaffolding aziendale di Azure- governance della sottoscrizione prescrittiva.

Criteri e conformità aziendali

Questa sezione fornisce indicazioni sulla governance dei criteri aziendali e della conformità per l'infrastruttura di Azure DevTest Labs.

Differenza tra repository di artefatti pubblico e privato

Il repository di artefatti pubblico offre un set iniziale di pacchetti software di uso più frequente. Consente una distribuzione rapida senza dover investire tempo per riprodurre gli strumenti di sviluppo e i componenti aggiuntivi comuni. È possibile scegliere di distribuire il proprio repository privato. È possibile usare parallelamente un repository pubblico e uno privato. È anche possibile scegliere di disabilitare il repository pubblico. I criteri per distribuire un repository privato dovrebbero basarsi sulle domande e le considerazioni seguenti:

• Un requisito dell'organizzazione è la necessità di avere software con licenza aziendale come parte dell'offerta di DevTest Labs? Se la risposta è affermativa, è consigliabile creare un repository privato.
• L'organizzazione sviluppa software personalizzato che prevede un'operazione specifica, che è essenziale nell'ambito dell'intero processo di provisioning? Se la risposta è affermativa, è consigliabile distribuire un repository privato.
• Se i criteri di governance dell'organizzazione richiedono l'isolamento e i repository esterni non rientrano nella gestione della configurazione diretta dell'organizzazione, è consigliabile distribuire un repository di artefatti privato. Nell'ambito di questo processo è possibile creare una copia del repository pubblico e integrarla nel repository privato. Si può successivamente disabilitare il repository pubblico in modo che nessun altro all'interno dell'organizzazione possa accedervi più. Questo approccio fa in modo che tutti gli utenti all'interno dell'organizzazione dispongano di un singolo repository che è approvato dall'organizzazione e che riduce al minimo la deviazione della configurazione.

Repository singolo o più repository

Nell'ambito della strategia di gestione della configurazione della governance complessiva dell'organizzazione è consigliabile usare un repository centralizzato. Quando si usano più repository, questi possono diventare con il tempo sili di software non gestito. Con un repository centrale più team possono usare gli artefatti disponibili nel repository per i propri progetti. L'utilizzo di un repository centrale aumenta la standardizzazione, la sicurezza, la facilità di gestione ed elimina la duplicazione dei lavori richiesti. La centralizzazione prevede le azioni seguenti come procedure consigliate per la gestione a lungo termine e la sostenibilità:

• Associare Azure Repos allo stesso tenant di Microsoft Entra usato dalla sottoscrizione di Azure per l'autenticazione e l'autorizzazione.
• Creare un gruppo denominato All DevTest Labs Developers in Microsoft Entra ID gestito centralmente. È opportuno inserire in questo gruppo tutti gli sviluppatori che contribuiscono allo sviluppo degli artefatti.
• Lo stesso gruppo di Microsoft Entra può essere usato per fornire l'accesso al repository Azure Repos e al lab.
• In Azure Repos è consigliabile usare la funzionalità di branching o di creazione di una copia tramite fork per separare un repository per ambiente di sviluppo dal repository di produzione primario. Il contenuto viene aggiunto al ramo principale solo con una richiesta pull dopo un'adeguata revisione del codice. Dopo che il revisore del codice approva la modifica, un responsabile sviluppatori, che è responsabile della manutenzione del ramo principale, unisce il codice aggiornato.

Criteri di sicurezza aziendali

Un'organizzazione può applicare criteri di sicurezza aziendali in base a:

• Sviluppo e pubblicazione di criteri di sicurezza completi. I criteri enunciano le regole di utilizzo accettabile associate all'uso di software, asset cloud. Definiscono anche le condizioni che violano i criteri.
• Sviluppo di un'immagine personalizzata, di artefatti personalizzati e di un processo di distribuzione che consente l'orchestrazione all'interno dell'area di autenticazione di sicurezza definita con Active Directory. Questo approccio applica limiti aziendali e imposta un set comune di controlli nell'ambiente. Questi sono controlli nell'ambiente che uno sviluppatore può prendere in considerazione mentre sviluppa e segue un ciclo di vita di sviluppo sicuro come parte del processo complessivo. L'obiettivo è anche offrire un ambiente non troppo restrittivo (che rischierebbe di ostacolare lo sviluppo), ma dotato di un set ragionevole di controlli. I criteri di gruppo nell'unità organizzativa che contiene macchine virtuali lab possono essere un sottoinsieme dei criteri di gruppo totali che si trovano nell'ambiente di produzione. In alternativa, possono essere un altro set per attenuare correttamente eventuali rischi identificati.

Integrità dei dati

Un'organizzazione può garantire l'integrità dei dati per garantire che gli sviluppatori remoti non possano rimuovere il codice o introdurre malware o software non approvato. Esistono diversi livelli di controllo per attenuare la minaccia da consulenti esterni, terzisti o dipendenti remoti in per collaborare in DevTest Labs.

Come indicato in precedenza, il primo passaggio deve avere criteri di utilizzo accettabile redatti e definiti che descrivono chiaramente le conseguenze quando un utente li viola.

Il primo livello di controlli per l'accesso remoto consiste nell'applicare criteri di accesso remoto tramite una connessione VPN che non è direttamente connessa al lab.

Il secondo livello di controlli consiste nell'applicare un set di oggetti criteri di gruppo che impediscono le operazioni di copia e incolla tramite un desktop remoto. È possibile implementare criteri di rete per non consentire servizi in uscita dall'ambiente, ad esempio i servizi FTP e RDP esterni all'ambiente. Il routing definito dall'utente può fare in modo che tutto il traffico di rete di Azure venga instradato di nuovo in locale, ma il routing può non considerare tutti gli URL che possono consentire il caricamento di dati a meno che non siano controllati tramite proxy per analizzare il contenuto e le sessioni. Gli indirizzi IP pubblici possono essere limitati all'interno della rete virtuale che supporta DevTest Labs per non consentire il bridging di una risorsa di rete esterna.

Lo stesso tipo di limitazioni infine deve essere applicato in tutta l'organizzazione, che dovrebbe anche considerare tutti i possibili metodi di supporti rimovibili o URL esterni in grado di accettare un post di contenuto. Consultare i propri esperti di sicurezza per esaminare e implementare i criteri di sicurezza. Per altre raccomandazioni, vedere il sito sulla Sicurezza informatica di Microsoft.

Migrazione e integrazione delle applicazioni

Una volta definito l'ambiente lab di sviluppo/test, è opportuno porsi le domande seguenti:

• Come si usa l'ambiente all'interno del team di progetto?
• Come è possibile garantire di seguire tutti i criteri aziendali richiesti e mantenere la flessibilità per aggiungere valore all'applicazione?

Immagini di Azure Marketplace e immagini personalizzate

Azure Marketplace deve essere usato per impostazione predefinita, se non in caso di dubbi specifici o requisiti aziendali. Alcuni esempi comuni sono:

• Configurazione software complessa che richiede di includere un'applicazione nell'immagine di base.
• L'installazione e la configurazione di un'applicazione possono richiedere diverse ore, e questo rappresenta un uso poco efficiente del tempo di calcolo per l'aggiunta a un'immagine di Azure Marketplace.
• Sviluppatori e tester richiedono l'accesso rapido a una macchina virtuale e intendono ridurre al minimo il tempo di configurazione di una nuova macchina virtuale.
• Condizioni normative o di conformità, ad esempio criteri di sicurezza, che devono essere definite per tutti i computer.

Prendere in considerazione l'uso di immagini personalizzate con attenzione. Le immagini personalizzate introducono complessità aggiuntive, perché ora è necessario gestire i file VHD per tali immagini di base sottostanti. È anche necessario applicare periodicamente patch alle immagini di base con aggiornamenti software. Tra questi rientrano i nuovi aggiornamenti del sistema operativo e tutti gli aggiornamenti o le modifiche di configurazione necessarie per il pacchetto software stesso.

Formula o immagine personalizzata

I fattori decisivi in questo scenario sono in genere i costi e il riutilizzo.

È possibile ridurre i costi creando un'immagine personalizzata se:

• Molti utenti o lab richiedono l'immagine.
• L'immagine richiesta ha un sacco di software sopra l'immagine di base.

Questa soluzione significa che si crea l'immagine una sola volta. Un'immagine personalizzata riduce il tempo di configurazione della macchina virtuale. Non si comportano costi per l'esecuzione della macchina virtuale durante l'installazione.

Un altro fattore è la frequenza delle modifiche apportate al pacchetto software. Se si eseguono compilazioni giornaliere e si richiede che il software si trovi nelle macchine virtuali degli utenti, è consigliabile usare una formula anziché un'immagine personalizzata.

Criteri per impostare la configurazione di rete

Quando si garantisce che le macchine virtuali di sviluppo e test non siano in grado di raggiungere la rete Internet pubblica, esistono due aspetti da considerare: traffico in ingresso e in uscita.

Traffico in ingresso : se la macchina virtuale non ha un indirizzo IP pubblico, Internet non riesce a raggiungerlo. Un approccio comune consiste nell'impostare criteri a livello di sottoscrizione che nessun utente può creare un indirizzo IP pubblico.

Traffico in uscita: se si vuole impedire alle macchine virtuali di passare direttamente a Internet pubblico e forzare il traffico attraverso un firewall aziendale, è possibile instradare il traffico locale tramite Azure ExpressRoute o VPN usando il routing forzato.

Nota

In presenza di un server proxy che blocca il traffico senza le impostazioni del proxy, non dimenticare di aggiungere eccezioni all'account di archiviazione dell'artefatto del lab.

È anche possibile usare gruppi di sicurezza di rete per macchine virtuali o subnet. Questo passaggio aggiunge un altro livello di protezione per consentire o bloccare il traffico.

Rete virtuale nuova o esistente

Se le macchine virtuali devono interagire con l'infrastruttura esistente, è consigliabile usare una rete virtuale esistente all'interno dell'ambiente DevTest Labs. Se si usa ExpressRoute, ridurre al minimo il numero di reti virtuali e subnet in modo da non frammentare lo spazio indirizzi IP assegnato alle sottoscrizioni. Prendere in considerazione anche l'uso del modello di peering di rete virtuale qui (modello Hub-Spoke). Questo approccio consente la comunicazione tra reti virtuali e subnet tra sottoscrizioni all'interno di una determinata area.

Ogni ambiente DevTest Labs potrebbe avere una propria rete virtuale, ma esistono limiti per il numero di reti virtuali per ogni sottoscrizione. La quantità predefinita è 50, sebbene questo limite possa essere incrementato a 100.

IP condiviso, pubblico o privato

Se si usa una VPN da sito a sito o ExpressRoute, è consigliabile usare indirizzi IP privati, in modo che i computer siano accessibili tramite la rete interna e inaccessibili sulla rete Internet pubblica.

Nota

I proprietari dei lab possono modificare questi criteri di subnet per garantire che nessuno crei accidentalmente indirizzi IP pubblici per le macchine virtuali. Il proprietario della sottoscrizione deve creare criteri di sottoscrizione che impediscano la creazione di indirizzi IP pubblici.

Quando si usano indirizzi IP pubblici condivisi, le macchine virtuali in un lab condividono un indirizzo IP pubblico. Questo approccio può essere utile se è necessario evitare di superare i limiti sugli indirizzi IP pubblici per una determinata sottoscrizione.

Limiti del lab

Esistono diversi limiti del lab di cui tenere conto. Questi limiti sono descritti nelle sezioni seguenti.

Limiti dei lab per sottoscrizione

Non c'è un limite specifico al numero di lab che è possibile creare per ogni sottoscrizione. È tuttavia previsto un limite per la quantità di risorse usate per ogni sottoscrizione. Sono disponibili informazioni su limiti e quote per le sottoscrizioni di Azure e su come aumentare questi limiti.

Limiti delle macchine virtuali per lab

Non esiste alcun limite specifico per il numero di macchine virtuali che è possibile creare per lab. È tuttavia previsto un limite per le risorse (core delle macchine virtuali, indirizzi IP pubblici e così via) usate per ogni sottoscrizione. Sono disponibili informazioni su limiti e quote per le sottoscrizioni di Azure e su come aumentare questi limiti.

Limiti nel numero di macchine virtuali per utente o lab

Quando si considera il numero di macchine virtuali per utente o per lab, esistono tre problemi principali:

• Il costo complessivo che il team può impiegare per le risorse nel lab. È facile creare rapidamente numerosi computer. Per controllare i costi, un meccanismo consiste nel limitare il numero di macchine virtuali per utente o per lab
• Il numero totale di macchine virtuali in un lab è interessato dalle quote a livello di sottoscrizione disponibili. Uno dei limiti superiori è 800 gruppi di risorse per sottoscrizione. DevTest Labs crea attualmente un nuovo gruppo di risorse per ogni VM (a meno che non vengano usati IP pubblici condivisi). Se sono presenti 10 lab in una sottoscrizione, i lab potrebbero adattarsi a circa 79 macchine virtuali in ogni lab (800 limiti superiori - 10 gruppi di risorse per i 10 lab stessi) = 79 macchine virtuali per lab.
• Se ad esempio il lab è connesso in locale a ExpressRoute, sono disponibili spazi di indirizzi IP definiti per la rete virtuale/subnet. Per garantire la creazione di VM nel lab senza errori (errore: impossibile ottenere l'indirizzo IP), i proprietari dei lab possono specificare il numero massimo di macchine virtuali per lab allineato allo spazio di indirizzi IP disponibile.

Usare i modelli di Resource Manager

Distribuire i modelli di Resource Manager seguendo la procedura descritta in Usare Azure DevTest Labs per gli ambienti di test. In pratica, è possibile controllare i modelli di Resource Manager in un repository Git git di Azure Repos o GitHub e aggiungere un repository privato per i modelli al lab.

Questo scenario potrebbe non essere utile se si usa DevTest Labs per ospitare computer di sviluppo. Usare questo scenario per creare un ambiente di gestione temporanea rappresentativo della produzione.

Il numero di macchine virtuali per lab o per utente limita solo il numero di computer creati in modo nativo nel lab stesso. Questa opzione non limita la creazione da parte di ambienti con modelli di Resource Manager.