In questo articolo, esamineremo le considerazioni architettoniche di Azure relative all'analisi e all'implementazione di un set di classificazione dei livelli ad alto rischio comune dei controlli di gestione dei rischi per la sicurezza delle informazioni (ISRM).
Architettura
L'architettura è illustrata nel diagramma seguente e si basa sul principio delle zone di destinazione con scalabilità aziendale, in particolare sulle analytics con scalabilità aziendale di riferimento basata sull'analisi e sull'intelligenza artificiale.
Scaricare un file di Visio di questa architettura.
Workflow
L'architettura è costituita dal flusso di lavoro descritto nelle sezioni seguenti. Ogni componente dell'architettura ha un numero corrispondente nel diagramma. Vengono descritti lo scopo principale del componente, il modo in cui si inserisce nell'architettura e qualsiasi altro aspetto importante da valutare quando lo si adotta:
- Sottoscrizioni della piattaforma: sottoscrizioni Azure di base che forniscono gestione, connettività e identità tramite Microsoft Entra ID. Tali piattaforme non vengono descritte in modo più dettagliato e si presuppone che siano pronte e disponibili nell'ambito della configurazione della scalabilità aziendale di base.
Gestione dei dati
- Zona di gestione dei dati: responsabile della governance dei dati in tutta la piattaforma che applica protezioni per offrire maggiore flessibilità a valle nelle zone di destinazione dei dati. Dispone di una propria sottoscrizione e ospita servizi centralizzati, ad esempio catalogazione, monitoraggio, controlli dei dati e così via. Tale ambiente è soggetto a verifiche stringenti e risulta estremamente controllato. Tutti i tipi di classificazione dei dati vengono archiviati nel catalogo dati centrale (Microsoft Purview). In base ai metadati, vengono applicati criteri e modelli di accesso diversi. È presente una sola sottoscrizione di zona di gestione dei dati per l'intero tenant. La zona di gestione dati è associata (tramite rete virtuale) a tutte le altre zone di destinazione dei dati. Gli endpoint privati vengono usati ogniqualvolta possibile per garantire che i servizi distribuiti non siano accessibili tramite rete Internet pubblica.
- Gruppo di risorse di rete: le reti virtuali di Azure, i gruppi di sicurezza di rete e tutte le altre risorse correlate alla rete necessarie per la zona di gestione dei dati vengono sottoposte a provisioning con questo gruppo di risorse.
- Gruppo di risorse di distribuzione: un gruppo di risorse di distribuzione ospita agenti CI/CD privati di Azure DevOps (macchine virtuali) necessari per la zona di gestione dei dati e un archivio di chiavi per l'archiviazione di eventuali segreti correlati alla distribuzione.
- Gruppo di risorse per la governance dei dati: Microsoft Purview viene usato come soluzione di governance e catalogo dei dati e consente di applicare le protezioni necessarie per i set di dati al fine di rispettare i requisiti e le normative sui dati imposti dalla legge o da altre entità. Microsoft Purview è ospitato centralmente in questo gruppo di risorse insieme con un'istanza di Key Vault per l'archiviazione di segreti.
- Risorse centralizzate: le risorse centralizzate ospitano risorse importanti e preziose centrali per la piattaforma, ad esempio:
- Registri Azure Container che ospitano immagini essenziali usate in prodotti dati basati su Azure ML (immagini analizzate e prive di vulnerabilità).
- Modelli di Machine Learning/intelligenza artificiale pubblicati e resi disponibili agli utenti nella piattaforma in modo che possano essere distribuiti in una o più zone di destinazione dei dati, se necessario.
- Servizi aggiuntivi: tutti gli altri servizi da centralizzare possono essere ospitati in uno di questi gruppi di risorse, che possono includere istanze di Gestione API centralizzate Azure, software di terze parti e così via.
- Gruppo di risorse di visualizzazione dati: questo gruppo di risorse ospita soluzioni di visualizzazione dei dati condivise tra zone di destinazione dei dati. Le soluzioni possono essere Power BI, Tableau o qualsiasi altra soluzione di visualizzazione.
- Controlli e governance dell'infrastruttura aggiuntivi: Microsoft Defender for Cloud e Monitoraggio di Azure vengono usati come soluzioni di sicurezza e monitoraggio di base.
Zona di destinazione dei dati
Zona di destinazione dei dati 001: una zona di destinazion dei dati è una sottoscrizione che rappresenta un'unità di scala all'interno della piattaforma dati. Le zone di destinazione dei dati vengono distribuite in base all'architettura della zona di destinazione dei dati principale (progetto), incluse tutte le funzionalità chiave necessarie per ospitare una piattaforma di analisi e di intelligenza artificiale. All'interno dell'ambiente possono essere presenti una o più zone di destinazione dei dati. Il criterio di Azure vengono applicati per proteggere l'accesso e le configurazioni di diversi servizi di Azure. La zona di destinazione dei dati è associata (tramite rete virtuale) a tutte le altre zone di destinazione e alla zona di gestione dei dati. Gli endpoint privati vengono usati ogniqualvolta possibile per garantire che i servizi distribuiti non siano accessibili tramite rete Internet pubblica.
Gruppo di risorse di rete: le reti virtuali di Azure, i gruppi di sicurezza di rete e tutte le altre risorse correlate alla rete necessarie per la zona di destinazione dei dati vengono sottoposte a provisioning con questo gruppo di risorse.
Gruppo di risorse di distribuzione: un gruppo di risorse di distribuzione ospita agenti CI/CD privati di Azure DevOps (macchine virtuali) necessari per la zona di destinazione dei dati e un archivio di chiavi per l'archiviazione di eventuali segreti correlati alla distribuzione.
Gruppo di risorse di archiviazione dei dati: un gruppo di risorse di archiviazione dei dati contiene gli account di archiviazione dati principali per questa zona di destinazione dei dati, distribuiti come Azure Data Lake Storage Gen2, con spazio dei nomi gerarchico. Gli account sono distribuiti in tre aree principali:
- Dati non elaborati (area in cui i dati vengono inseriti dall'origine dati nello stato originale)
- Dati curati e arricchiti (area in cui i dati vengono puliti, convalidati e aggregati)
- Area di lavoro (area specifica in cui prodotti dati specifici possono archiviare i set di dati o gli output dei modelli di Machine Learning e così via).
Le frecce nei diagrammi mostrano il flusso di dati previsto, dai dati non elaborati ai dati curati e arricchiti (attendibili) e oltre, fino all'area di lavoro per l'esplorazione, l'analisi e l'offerta di un valore aggiuntivo dal prodotto dati.
Gruppo di risorse di integrazione dei dati: il gruppo di risorse di integrazione dati ospita una data factory di Azure che condivide la connettività con il runtime di integrazione self-hosted locale (SHIR). Il suo scopo principale è stabilire la connettività. Altre istanze di Data Factory lo riutilizzano in modo che la connettività venga mantenuta solo in un'unica posizione. Un altro scopo è quello di ospitare il runtime di integrazione self-hosted per il servizio Microsoft Purview in modo che possa accedere alle origini dati in questa zona di destinazione dei dati (a scopo di analisi).
Gruppo di risorse di gestione dei metadati: il gruppo di risorse di gestione dei metadati ospita i metadati per Azure Databricks (meta store Hive) e le pipeline di inserimento ed elaborazione di Azure Data Factory. Ospita anche un insieme di credenziali delle chiavi per archiviare i segreti per l'accesso a questi dati. Per archiviare i metadati, viene usato il database SQL di Azure.
Gruppo di risorse di inserimento dati: il gruppo di risorse di inserimento dati ospita un'istanza di Azure Data Factory in cui vengono distribuite tutte le pipeline di inserimento dati specifiche per un dominio dati. Azure Databricks viene usato come motore di elaborazione per caricare e trasformare i dati e archiviarli in account data lake.
Gruppo di risorse di analisi: il gruppo di risorse di analisi include due servizi condivisi per ulteriori analisi ed esplorazioni dei dati: Azure Synapse e Azure Databricks. Entrambi i servizi offrono una vasta gamma di risorse di calcolo e scalabilità per l'esplorazione e l'analisi di dati di grandi dimensioni.
Gruppo di risorse del prodotto dati: il gruppo di risorse del prodotto dati è un modello per un prodotto dati, con un gruppo di risorse contenente risorse di base di Azure di cui un prodotto dati potrebbe aver bisogno. La distribuzione deve essere configurabile tramite una pipeline Azure DevOps in base alle esigenze specifiche dell'azienda. I servizi principali di Azure distribuiti sono i seguenti:
- Area di lavoro di Azure Machine Learning come base per qualsiasi progetto di apprendimento automatico aziendale con servizi correlati, ad esempio Key Vault (per l'archiviazione di segreti)
- Application Insights (per il monitoraggio dei modelli)
- Archiviazione di Azure (per l'archiviazione di set di dati)
- Registro Azure Container per l'archiviazione di immagini del modello durante lo sviluppo
I servizi di intelligenza artificiale di Azure vengono distribuiti come bundle per fornire l'accesso API a più servizi supportati da intelligenza artificiale, mentre le istanze di elaborazione e i cluster di elaborazione di Azure Machine Learning vengono utilizzati per scopi di sviluppo, creazione di modelli e test. Azure Data Factory viene usato per orchestrare l'assegnazione in batch dei punteggi dei modelli (se necessario). Il servizio app e Cosmos DB Azure offrono un livello aggiuntivo per la distribuzione del prodotto dati, in cui un'applicazione o un'API personalizzata può essere ospitata con il proprio archivio dati interno.
Per i settori regolamentati, in genere, sono previste restrizioni rigorose per l'accesso ai dati e l'hosting dei dati di produzione è consentito solo all'interno dell'ambiente di produzione stesso. Per questo motivo, il ciclo di vita di sviluppo dei prodotti dati viene attuato solo nella zona di destinazione dei dati di produzione e viene effettuato il provisioning di un ambiente separato (gruppo di risorse) a scopo di sviluppo, test e distribuzione.
Prodotti dati aggiuntivi: questi gruppi di risorse ospitano altri prodotti dati poiché una zona di destinazione dei dati può ospitare uno o più di tali prodotti.
Gruppo di risorse di elaborazione condivise: tutte le risorse di elaborazione condivise necessarie per l'hosting e la distribuzione di prodotti dati vengono sottoposte a provisioning in questo gruppo. Un cluster del servizio Azure Kubernetes è un esempio.
Controlli e governance dell'infrastruttura aggiuntivi: Microsoft Defender for Cloud e Monitoraggio di Azure vengono usati come soluzioni di sicurezza e monitoraggio di base.
Zone di destinazione dei dati 002: questa landing zone è un segnaposto per sottoscrizioni Azure aggiuntive che verrebbero utilizzate per ospitare nuove landing zone dati. Tali zone si basano su criteri indicati in precedenza, ad esempio i requisiti di residenza dei dati o una Business Unit diversa con un proprio team interfunzionale e un set di casi d'uso da associare.
Componenti
- Microsoft Entra ID
- Azure Purview
- Rete virtuale di Azure
- Azure DevOps
- Registro Azure Container
- Azure Machine Learning
- Microsoft Defender per il cloud
- Monitoraggio di Azure
- Criteri di Azure
- Archiviazione di Azure Data Lake
- Azure Data Factory
- Database SQL di Azure
- Azure Databricks
- Azure Synapse Analytics
- Servizio Azure Kubernetes
Alternative
Nelle organizzazioni distribuite i gruppi aziendali operano in modo indipendente e con livelli elevati di autonomia. Di conseguenza, si potrebbe prendere in considerazione una progettazione alternativa della soluzione, con isolamento completo dei casi d'uso nelle zone di destinazione di Azure, condividendo un set minimo di servizi comuni. Sebbene consenta un avvio rapido, questa progettazione richiede un impegno elevato da parte delle organizzazioni IT e ISRM, poiché la progettazione di singoli casi d'uso si discosta rapidamente dalla definizione dei progetti. Sono richiesti anche processi e controlli ISRM per ogni "prodotto" di intelligenza artificiale/ML ospitato in Azure.
Dettagli dello scenario
Il ridimensionamento delle iniziative di intelligenza artificiale e apprendimento automatico in ambienti regolamentati pone sfide significative alle organizzazioni, indipendentemente dalle dimensioni e dalla maturità in ambito digitale. Questo articolo illustra le decisioni architetturali chiave da prendere in considerazione quando si adottano i servizi di ingegneria dei dati e di apprendimento automatico di Azure nei settori regolamentati. Tali decisioni si basano su quanto appreso da una recente implementazione in un'azienda globale nel settore sanitario e delle scienze biologiche di Fortune 500.
L'architettura presentata in questo articolo segue la progettazione dell'architettura di riferimento basata sull'analisi della scalabilità aziendale e sull'intelligenza artificiale ed è stata una delle sue prime implementazioni.
La configurazione dei progetti di data science e lo sviluppo di modelli di Machine Learning negli ambienti sanitari e delle scienze biologiche richiederanno in quasi tutti i casi l'accesso a origini dati ad alto impatto aziendale, Ad esempio, queste fonti possono essere informazioni sui protocolli di sperimentazione clinica senza dati sui pazienti, formule chimiche delle molecole o segreti sui processi di produzione.
Nei settori regolamentati, i sistemi IT sono catalogati in base alla classificazione delle origini dati a cui accedono. Gli ambienti di intelligenza artificiale e apprendimento automatico in esecuzione su Azure sono classificati come HBI e devono rispettare un ampio set di criteri e controlli ISRM.
Principi di progettazione
Questa architettura si basa sui principi seguenti:
- L'approccio architettonico su scala aziendale e l'implementazione di riferimento sono allineati alla roadmap di Azure e fanno parte del Microsoft Cloud Adoption Framework. Consente di costruire le zone di destinazione in Azure e di operarvi in modo efficace, su larga scala. La zona di destinazione del nome viene usata come limite in cui le applicazioni nuove o migrate vengono spostate in Azure. In questo scenario si riferisce anche a parti della piattaforma dati usate per ospitare i dati e i modelli di Intelligenza artificiale e Machine Learning.
- Le architetture tradizionali della piattaforma dati monolitica presentano una limitazione intrinseca che rallenta la distribuzione di funzionalità e valori. L'architettura qui descritta consente alle organizzazioni di ridimensionare il proprio ambiente di dati e di affrontare le sfide di un data lake monolitico centralizzato tramite un approccio decentralizzato con separazione della proprietà (mesh di dati). L'approccio consente alle organizzazioni di ridimensionare fino a migliaia di pipeline di inserimento e prodotti dati, mantenendo la piattaforma dati sicura e gestibile grazie alla separazione della piattaforma dati principale e dei servizi di gestione dati (distribuiti in una zona di destinazione dei dati distinta denominata zona di gestione dati) dai domini e dai prodotti dati (distribuiti in una o più zone di destinazione dei dati).
- Le sottoscrizioni vengono usate come unità di gestione e scalabilità allineate alle esigenze e alle priorità aziendali. Il ridimensionamento si ottiene definendo nuove sottoscrizioni (zone di destinazione dei dati) alle Business Unit, in base a criteri come stakeholder, obiettivi e requisiti aziendali diversi e requisiti di residenza dei dati (in base ai quali i dati devono essere ospitati in un'area geografica specifica).
- Il criterio di Azure vengono usati per offrire protezioni e garantire la conformità continua all'interno del panorama IT aziendale.
- Un unico piano di controllo e gestione (tramite il portale di Azure) offre un'esperienza coerente in tutte le risorse e i canali di provisioning di Azure soggetti ad accesso basato sui ruoli e a controlli basati su criteri. I servizi e le funzionalità della piattaforma nativa di Azure vengono usati quando possibile.
- I team interfunzionali assumono la proprietà della progettazione, dello sviluppo e delle operazioni per ridurre il time-to-market e l'agilità nella piattaforma. I principi di base come DevOps, l'infrastruttura come codice (IaC, Infrastructure as Code) e le progettazioni resilienti vengono usati per evitare errori umani e singoli punti di guasto.
- I domini dati possono essere usati dagli esperti di dominio e di origini dati (SME) per eseguire il pull delle risorse dati da Azure o da ambienti locali o di terze parti. Un dominio dati è un gruppo di risorse all'interno di una zona di destinazione dei dati che consente ai team interfunzionali di inserire dati in modo personalizzato. In una zona di destinazione dei dati possono essere presenti uno o più domini dati. I domini dati possono essere visualizzati in modo analogo ai domini in ambito di progettazione basata su domini in cui sono auto-sufficienti e isolati e in cui è previsto un limite di contesto. Un esempio di dominio dati è costituito da dati di studi clinici o dati della supply chain.
Potenziali casi d'uso
Le considerazioni sull'architettura descritte in questo articolo hanno origine nel settore delle scienze biologiche e della sanità, ma sono rilevanti anche per le organizzazioni di altri settori regolamentati, tra cui:
- Servizi finanziari
- Operatori di servizi sanitari
- Petrolio e gas
L'implementazione dell'architettura di riferimento basata sull'analisi della scalabilità aziendale e sull'intelligenza artificiale in ambienti regolamentati segue modelli di progettazione simili.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Questa sezione illustra le lezioni apprese dall'implementazione dell'architettura descritta in precedenza in un ambiente regolamentato per il settore sanitario e delle scienze biologiche. Vengono anche descritte considerazioni generali sulla progettazione per soddisfare i controlli e i criteri ISRM comuni.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.
Ambienti
Negli ambienti regolamentati per i sistemi IT classificati come ad alto impatto aziendale devono essere presenti più ambienti separati, ad esempio ambienti di sviluppo, qualità e produzione (o simili). L'accesso alle origini dati protette è autorizzato solo in ambienti certificati per la produzione.
Poiché lo sviluppo di intelligenza artificiale e apprendimento automatico richiede l'accesso a set di dati sensibili, le diverse fasi del processo MLOps, ad esempio compilazione, training e inferenza del modello (o simili), si svolgeranno tutte nell'ambiente di produzione. Gli ambienti di sviluppo e qualità saranno in genere limitati all'infrastruttura, alle operazioni e al tipo di lavoro di ingegneria dei dati, per garantire continui miglioramenti ogni volta che vengono resi disponibili nuovi servizi e funzionalità di Azure.
Le attività di sviluppo di intelligenza artificiale e data science devono essere svolte in ambienti di produzione, ad eccezione dell'ambiente sandbox o dei primi lavori esplorativi.
Crittografia
I sistemi IT che accedono, archiviano ed elaborano dati aziendali sensibili sono necessari per implementare requisiti specifici per la gestione delle chiavi di crittografia, ad esempio criteri FIPS 140-2 di livello 2 o 3, con l'integrazione di chiavi gestite dal cliente. I dati protetti devono essere sempre crittografati quando sono inattivi e in transito, tramite protocolli TLS 1.2 o versione successiva.
Durante la progettazione dell'architettura, è necessario eseguire un'attenta analisi del supporto e dell'integrazione dei servizi di Azure nell'infrastruttura di chiavi gestite dal cliente di un'organizzazione. Eventuali eccezioni alla crittografia dei dati devono essere documentate. Il supporto per i fornitori del modulo di protezione hardware viene sempre esteso e altre informazioni sono disponibili nel modulo di protezione hardware gestito in Azure Key Vault.
Progettazione della rete e limitazione ad anello
Gli ambienti di intelligenza artificiale/ML devono disporre di una limitazione ad anello, con la segmentazione di rete e i controlli di accesso alla rete implementati. La comunicazione di rete tra i componenti dell'architettura è limitata ai flussi di dati necessari e all'infrastruttura sottostante per funzionare (in un approccio con elenco elementi consentiti). È consigliabile applicare l'analisi basata su firma e quella basata sul comportamento.
Applicare i controlli di accesso alla rete su diversi livelli dell'architettura, tra cui Firewall di Azure, controllo della connettività di rete in ingresso e in uscita, gruppi di sicurezza di rete (NSG) e accesso all'endpoint delle applicazioni Web protetto con WAF (Web Application Firewall).
Gestione delle autorizzazioni
Gli ambienti di intelligenza artificiale e apprendimento automatico in esecuzione in Azure devono essere integrati con il sistema di provisioning dell'account principale dell'organizzazione, in cui le richieste per concedere l'accesso alle applicazioni aziendali critiche vengono inviate, approvate e controllate.
È previsto che i sistemi di provisioning degli account si connettano alle istanze di Active Directory e Microsoft Entra ID di un'organizzazione, in modo che i ruoli di autorizzazione aziendali vengano mappati ai gruppi di sicurezza Active Directory e Microsoft Entra ID corrispondenti.
Gli ambienti di intelligenza artificiale e machine learning seguono un modello di controllo degli accessi basato sui ruoli. Le autorizzazioni di controllo del livello di accesso garantiscono che gli utenti possano eseguire solo le attività e le azioni per il loro ruolo lavorativo e requisito aziendale. Si prevede che i casi d'uso di apprendimento automatico siano effettivamente separati poiché gli scienziati dei dati che lavorano su un particolare caso d'uso sono autorizzati ad accedere solo alle risorse che ne fanno parte, in base a un principio di privilegio minimo. Tali risorse possono includere:
- Account di archiviazione
- Aree di lavoro di Azure Machine Learning
- Istanze di calcolo
Il controllo degli accessi in base al ruolo usa i gruppi di sicurezza in Microsoft Entra ID.
Autenticazione a più fattori
L'autenticazione a più fattori (MFA) deve essere implementata per l'accesso a tutti gli ambienti in esecuzione in Azure e classificati come ambienti ad alto impatto aziendale. L'autenticazione a più fattori può essere applicata usando i servizi di autenticazione a più fattori Di Microsoft Entra. Gli endpoint dell'applicazione, tra cui Azure DevOps, Azure Management Portal, Azure Machine Learning, Azure Databricks e Azure Kubernetes Service, devono essere configurati in criteri di controllo degli accessi con autenticazione a più fattori.
L'autenticazione a più fattori deve essere applicata a tutti gli utenti, inclusi i responsabili dei servizi di Azure, gli ingegneri dei dati e i data scientist.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
La gestione dei costi è una parte importante della progettazione nell'implementazione di piattaforme scalabili di intelligenza artificiale/ML, poiché i costi di esecuzione non seguono modelli semplici e prevedibili. I costi si basano principalmente sul numero e sulle dimensioni degli esperimenti di intelligenza artificiale/ML eseguiti nella piattaforma e, più in particolare, sul numero e sugli SKU delle risorse di calcolo usate nel training e nell'inferenza del modello.
Di seguito sono riportate alcune procedure consigliate:
- Assegnare ogni caso d'uso e intelligenza artificiale e prodotto di Machine Learning il proprio budget per i servizi di Azure, che è una buona procedura di gestione dei costi.
- Definire un modello di costo trasparente per i servizi condivisi della piattaforma.
- Usare i tag in modo coerente per associare le risorse del caso d'uso e del "prodotto" ai centri di costo.
- Usare Azure Advisor e il servizio di budget di Azure per individuare il punto in cui le risorse non vengono usate in modo ottimale ed esaminare regolarmente le configurazioni.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.
Registrazione e monitoraggio
Tutti i servizi di Azure devono inserire gli eventi di sicurezza nella piattaforma del centro operazioni per la sicurezza (SOC, Security Operations Center) di un'organizzazione e devono essere registrati gli eventi di sicurezza seguenti:
- Tentativi di autenticazione riusciti e non riusciti
- Accesso ai dati sensibili
- Modifiche ai criteri di sicurezza
- Modifiche a gruppi di utenti, utenti o ruoli amministratori
- Trasferimenti di dati sensibili a posizioni esterne, se applicabile
- Attivazione e disattivazione di sistemi di protezione, come i controlli ABAC (Attribute-Based Access Control)
- Accesso aggiornato ai log e interruzione della registrazione
I log di sicurezza di Azure possono essere inseriti nel centro operazioni per la sicurezza tramite schemi diversi:
- Area di lavoro Azure Log Analytics centrale
- Hub eventi connesso ai sistemi della piattaforma del centro operazioni per la sicurezza, ad esempio Splunk
- Macchina virtuale Windows e altre risorse di calcolo distribuite con agenti del centro operazioni per la sicurezza
DevOps
Negli ambienti regolamentati i sistemi IT devono seguire rigidi processi di controllo di qualità a cascata, con approvazioni formali (o attività di controllo) tra le fasi del processo, ad esempio specifiche dei requisiti utente, funzionali, di progettazione e di test (o simili), con documentazione di supporto ampia e dispendiosa in termini di tempo.
Lo sviluppo di ambienti di Azure e di data science seguono processi iterativi, basati sulla cultura DevOps. Per ridimensionare le iniziative di intelligenza artificiale/ML è necessario un impegno significativo per comunicare le basi di un'organizzazione DevOps e creare un mapping di tracciabilità end-to-end automatizzato tra epiche di Azure DevOps, funzionalità, storie utente, piani di test e pipeline CI/CD, oltre a entità ed evidenze necessarie per il controllo qualità.
Efficienza delle prestazioni
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.
Per dimensionare l'intelligenza artificiale e l'apprendimento automatico in ambienti regolamentati e favorire l'adozione rapida tra le aree aziendali dell'organizzazione, è consigliabile progettare e mettere in atto un framework di adozione per misurare, monitorare e valutare il valore creato dai servizi di Azure. Nell'esempio del settore sanitario e delle scienze biologiche sono state valutate le leve di valore aziendale e gli indicatori KPI indicati di seguito.
Scalabilità - Per garantire che l'architettura di Azure possa essere dimensionata sulla base dei requisiti aziendali, indipendentemente dal punto di scalabilità, sono consigliati gli indicatori KPI seguenti:
- Numero di istanze di ambiente di calcolo e spazio di archiviazione e memoria totali usati
- Numero di esperimenti eseguiti
- Numero di modelli distribuiti
Accelerazione dello sviluppo dell'intelligenza artificiale - Per accelerare lo sviluppo delle soluzioni di intelligenza artificiale/ML, sono consigliati gli indicatori KPI seguenti:
- Numero di business unit diverse che usano i servizi di Machine Learning e intelligenza artificiale di Azure
- Numero di utenti di cui è stato eseguito l'onboarding per categoria, ad esempio ingegneri e scienziati dei dati, citizen data scientist e utenti aziendali
- Numero di esperimenti eseguiti
- Tempo tra l'onboarding degli utenti e l'uso attivo
- Tempo necessario per effettuare il provisioning dei servizi, dalla richiesta di modifica della configurazione al completamento del provisioning del servizio
Conformità - Per garantire la conformità continua delle soluzioni di intelligenza artificiale/ML distribuite, sono consigliati gli indicatori KPI seguenti:
- Conformità generale con i controlli ISRM applicabili
- Numero di avvisi di vulnerabilità per la sicurezza
- Numero di eventi imprevisti della sicurezza nell'ultimo periodo
Esperienza utente - Per garantire esperienze utente di alta qualità e coerenti, sono consigliati gli indicatori KPI seguenti:
- Numero di richieste all’help desk da parte degli utenti
- Net Promoter Score (NPS)
Basi sicure - Per garantire la sicurezza delle basi, sono consigliati gli indicatori KPI seguenti:
- Tempo di attività dei servizi critici
- Numero di eventi imprevisti segnalati e correlati alla disponibilità delle prestazioni
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Eran Sagi | Progettista di soluzioni di intelligenza artificiale
Passaggi successivi
Informazioni su come eseguire il training e la distribuzione di modelli e su come gestire il ciclo di vita di ML (MLOps) con Azure Machine Learning. Esercitazioni, esempi di codice, riferimenti alle API e altre risorse sono disponibili qui:
Informazioni su come implementare una zona di destinazione con scalabilità aziendale per l'analisi dei dati e l'intelligenza artificiale in Azure:
Documentazione sui prodotti:
- Azure Machine Learning
- MLOps (Machine Learning Operations)
- Azure Databricks
- Azure Data Lake Storage Gen2
Risorse correlate
Articoli di panoramica del Centro architetture di Azure: