Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo offre procedure consigliate per mantenere l'affidabilità e la sicurezza del cloud estate di Azure. L'affidabilità garantisce che i servizi cloud rimangano operativi con tempi di inattività minimi. La sicurezza protegge la riservatezza, l'integrità e la disponibilità delle risorse. L'affidabilità e la sicurezza sono fondamentali per le operazioni cloud riuscite.
Gestire l'affidabilità
La gestione dell'affidabilità prevede l'uso di ridondanza, replica e strategie di ripristino definite per ridurre al minimo i tempi di inattività e proteggere l'azienda. La tabella 1 fornisce un esempio di tre priorità del carico di lavoro, requisiti di affidabilità (tempo di attività SLO, tempo di inattività massimo, ridondanza, bilanciamento del carico, replica) e scenari di esempio allineati agli obiettivi a livello di servizio (SLO)
Tabella 1. Esempio di requisiti di priorità e affidabilità del carico di lavoro.
Priorità | Impatto aziendale | SLO con tempo di attività minimo | Tempo di inattività massimo al mese | Ridondanza dell'architettura | Bilanciamento del carico | Replica e backup dei dati | Scenario di esempio |
---|---|---|---|---|---|---|---|
Alta importanza (missione critica) | Effetti immediati e gravi sulla reputazione o sui ricavi aziendali. | 99,99% | 4,32 minuti | Più aree & più zone di disponibilità in ogni area | Modalità attiva-attiva | Replica dei dati sincrona tra regioni & backup per il ripristino | Baseline mission-criticale |
Intermedio | Effetti misurabili sulla reputazione o sui ricavi aziendali. | 99,9% | 43,20 minuti | Più regioni & più zone di disponibilità in ciascuna regione | Modalità attiva-passiva | Replica asincrona dei dati tra regioni e backup & per il ripristino | Modello di app Web affidabile |
Basso | Nessun effetto sulla reputazione, sui processi o sui profitti dell'azienda. | 99% | 7 ore e 20 minuti | Singola area & più zone di disponibilità | Ridondanza della zona di disponibilità | Replica sincrona dei dati tra zone di disponibilità & backup per il ripristino |
Baseline di App Service Baseline della macchina virtuale |
Identificare le responsabilità di affidabilità
Le responsabilità di affidabilità variano in base al modello di distribuzione. Usare la tabella seguente per identificare le responsabilità di gestione per l'infrastruttura (IaaS), la piattaforma (PaaS), il software (SaaS) e le distribuzioni locali.
Responsabilità | In sede | IaaS (Azure) | PaaS (Azure) | SaaS |
---|---|---|---|---|
Dati | ✔️ | ✔️ | ✔️ | ✔️ |
Codice e runtime | ✔️ | ✔️ | ✔️ | |
Risorse cloud | ✔️ | ✔️ | ✔️ | |
Hardware fisico | ✔️ |
Per altre informazioni, vedere Responsabilità condivisa per l'affidabilità.
Definire i requisiti di affidabilità
I requisiti di affidabilità chiaramente definiti sono fondamentali per gli obiettivi di tempo di attività, il ripristino e la tolleranza alla perdita di dati. Per definire i requisiti di affidabilità, seguire questa procedura:
Assegnare priorità ai carichi di lavoro. Assegnare priorità elevate, medie (predefinite) o basse ai carichi di lavoro in base alla criticità aziendale e ai livelli di investimento finanziari. Esaminare regolarmente le priorità per mantenere l'allineamento con gli obiettivi aziendali.
Assegnare l'obiettivo del livello di servizio (SLO) di uptime a tutti i carichi di lavoro. Lo SLO influenza l'architettura, le strategie di gestione dei dati, i processi di ripristino e i costi. Stabilire obiettivi di tempo di operatività in base alla priorità del carico di lavoro. I carichi di lavoro con priorità più alta richiedono obiettivi di tempo di attività più rigorosi.
Identificare gli indicatori del livello di servizio (SLI). Usare gli SLI per misurare le prestazioni del tempo di attività rispetto allo SLO. Gli esempi includono il monitoraggio dell'integrità dei servizi e le percentuali di errore.
Assegnare un obiettivo del tempo di ripristino (RTO) a tutti i carichi di lavoro. L'obiettivo RTO definisce il tempo di inattività massimo accettabile per il carico di lavoro. RTO deve essere più breve rispetto alla quantità di tempo di inattività annuale. Ad esempio, un tempo di attività SLO 99,99% richiede meno di 52 minuti di tempo di inattività annuale (4,32 minuti al mese). Per assegnare un RTO, seguire questa procedura:
Stimare il numero di errori all'anno. Per i carichi di lavoro con cronologia operativa, utilizzare i vostri indicatori di livello di servizio. Per i nuovi carichi di lavoro, eseguire un'analisi della modalità di errore per ottenere una stima accurata.
Stimare il RTO. Dividere il tempo di inattività consentito annuale per il numero stimato di guasti. Se si stimano quattro errori all'anno, l'obiettivo RTO deve essere di 13 minuti o inferiore (52 minuti / 4 errori = 13 minuti RTO).
Testare il tempo di ripristino. Tenere traccia del tempo medio necessario per il ripristino durante i test di failover e gli errori in tempo reale. Il tempo necessario per riprendersi da un fallimento deve essere minore dell'RTO.
Definire gli obiettivi del punto di ripristino (RPO) per tutti i carichi di lavoro. Il rpo influisce sulla frequenza con cui si esegue la replica e il backup dei dati. Determinare la quantità di perdita di dati che l'azienda può tollerare.
Definire le destinazioni di affidabilità del carico di lavoro. Per le destinazioni di affidabilità del carico di lavoro, vedere le raccomandazioni di Well-Architected Framework per la definizione degli obiettivi di affidabilità.
Gestire l'affidabilità dei dati
L'affidabilità dei dati implica la replica dei dati (repliche) e i backup (copie temporizzate) per mantenere la disponibilità e la coerenza. Vedere la tabella 2 per esempi di priorità del carico di lavoro allineata alle destinazioni di affidabilità dei dati.
Tabella 2. Priorità del carico di lavoro con configurazioni di affidabilità dei dati di esempio.
Priorità del carico di lavoro | SLO del tempo di attività | Replica dei dati | Backup di dati | Scenario di esempio |
---|---|---|---|---|
Alto | 99,99% | Replica sincrona dei dati tra aree Replica sincrona dei dati tra zone di disponibilità |
Backup interregionali ad alta frequenza. La frequenza deve supportare RTO e RPO. | Piattaforma di dati cruciali |
Intermedio | 99,9% | Replica sincrona dei dati tra aree Replica sincrona dei dati tra zone di disponibilità |
Backup multiregione. La frequenza deve supportare RTO e RPO. | Soluzione di database e archiviazione nel modello Reliable Web App |
Basso | 99% | Replica sincrona dei dati tra zone di disponibilità | Backup multiregione. La frequenza deve supportare RTO e RPO. | Resilienza dei dati nell'applicazione web di base con ridondanza di zona |
È necessario allineare le configurazioni di affidabilità dei dati ai requisiti RTO e RPO dei carichi di lavoro. Per eseguire l'allineamento, seguire questa procedura:
Gestire la replica dei dati. Replicare i dati in modo sincrono o asincrono in base ai requisiti RTO e RPO del carico di lavoro.
Distribuzione dati Replica dei dati Configurazione del bilanciamento del carico Tra zone di disponibilità Sincrono (quasi in tempo reale) La maggior parte dei servizi PaaS gestisce il bilanciamento del carico tra zone in modo nativo Tra regioni (attivo-attivo) Sincrono Bilanciamento del carico attivo-attivo Tra regioni (attivo-passivo) Asincrono (periodico) Configurazione attiva-passiva Per altre informazioni, vedere Replicazione: Ridondanza sui dati.
Gestire i backup dei dati. I backup sono destinati al ripristino di emergenza (errore del servizio), al ripristino dei dati (eliminazione o danneggiamento) e alla risposta agli eventi imprevisti (sicurezza). I backup devono supportare i requisiti RTO e RPO per ogni carico di lavoro. Preferire soluzioni di backup predefinite al servizio di Azure, ad esempio le funzionalità di backup native in Azure Cosmos DB e nel database SQL di Azure. Se i backup nativi non sono disponibili, inclusi i dati locali, usare Backup di Azure. Per altre informazioni, vedere Backup e Centro continuità aziendale di Azure.
Progettare l'affidabilità dei dati del carico di lavoro. Per la progettazione dell'affidabilità dei dati del carico di lavoro, vedere la guida al partizionamento dei dati di Well-Architected Framework e le guide ai servizi di Azure (iniziare con la sezione Affidabilità).
Gestire l'affidabilità del codice e del runtime
L'affidabilità del codice e del runtime è una responsabilità del carico di lavoro. Segui la guida di auto-guarigione e conservazione automatica del Well-Architected Framework .
Gestire l'affidabilità delle risorse cloud
La gestione dell'affidabilità delle risorse cloud spesso richiede ridondanza dell'architettura (istanze del servizio duplicate) e una strategia efficace di bilanciamento del carico. Vedere la tabella 3 per esempi di ridondanza dell'architettura allineata alla priorità del carico di lavoro.
Tabella 3. Esempi di ridondanza dell'architettura e priorità del carico di lavoro.
Priorità del carico di lavoro | Ridondanza dell'architettura | Approccio di bilanciamento del carico | Soluzione di bilanciamento del carico di Azure | Scenario di esempio |
---|---|---|---|---|
Alto | Due regioni & zone di disponibilità | Modalità attiva-attiva | Frontdoor di Azure (HTTP) Gestione traffico di Azure (non HTTP) |
Piattaforma di base per applicazioni mission-critical |
Intermedio | Due regioni & zone di disponibilità | Modalità attiva-passiva | Frontdoor di Azure (HTTP) Gestione traffico di Azure (non HTTP) |
Linee guida per l'architettura dei modelli di app Web affidabili |
Basso | Regione singola & zone di disponibilità | Tra zone di disponibilità | Gateway applicativo di Azure Aggiungere Azure Load Balancer per le macchine virtuali |
Baseline di App Service Baseline della macchina virtuale |
L'approccio deve implementare la ridondanza dell'architettura per soddisfare i requisiti di affidabilità dei carichi di lavoro. Seguire questa procedura:
Stimare la disponibilità delle architetture. Per ogni carico di lavoro, calcolare lo SLA composito. Includere solo i servizi che potrebbero causare l'esito negativo del carico di lavoro (percorso critico).
Elencare ogni servizio nel percorso critico del carico di lavoro. Raccogliere gli SLA del tempo di attività di Microsoft di ciascun servizio dal documento ufficiale.
Decidere se il carico di lavoro include percorsi critici indipendenti. Un percorso indipendente può avere esito negativo e il carico di lavoro rimane disponibile.
Se si dispone di un percorso critico, usare la formula a singola area: N = S1 × S2 × S3 × ... × Sn.
Se sono presenti due o più percorsi critici, usare la formula independent-path: N = S1 x 1 - [(1 - S2) × (1 - S3)].
I carichi di lavoro complessi spesso combinano entrambi i tipi di formula. Esempio: N = S1 × S2 × S3 × (S4 x 1 - [(1 - S5) × (1 - S6)]).
Per le applicazioni in più aree, usare la formula per la formula in più aree: M = 1 - (1 - N)^R
Confronta il tempo di attività calcolato con il tuo SLO di disponibilità. Un deficit richiede SLA di livello superiore o una ridondanza aggiuntiva. Ricalcolare dopo ogni modifica. Interrompere dopo che il tempo di attività calcolato supera lo SLO.
Caso d'uso Formula Variabili Esempio Spiegazione Area singola N = S1 × S2 × S3 × ... × Sn N = Contratto di servizio composito.
S = Contratto di servizio del servizio di Azure.
n = numero di servizi nel percorso critico.N = 99,99% (app) × 99,95% (database) × 99,9% (cache) Carico di lavoro semplice con app (99,99%), database (99,95%) e cache (99,9%) in un singolo percorso critico. Percorsi indipendenti S1 x 1 - [(1 - S2) × (1 - S3)] S = Contratto di servizio del servizio di Azure. 99,99% (app) × (1 - [(1 - 99,95% database) × (1 - 99,9% cache)]) Nell'app il database (99.95%) o la cache (99.9%) può avere esito negativo senza causare tempi di inattività. Più aree M = 1 - (1 - N)^R M = Contratto di servizio in più aree.
N = Contratto di servizio a area singola.
R = Numero di aree.Se N = 99,95% e R = 2, M = 1 - (1 - 99,95%)^2 Carico di lavoro distribuito in due aree. Modificare i livelli di servizio. Prima di modificare le architetture, valutare se diversi livelli di servizio di Azure (SKU) possono soddisfare i requisiti di affidabilità. Alcuni livelli di servizio di Azure possono avere SLA di disponibilità diversi, ad esempio Azure Managed Disks.
Aggiungi la ridondanza dell'architettura. Se la stima del tempo di attività corrente non rientra nell'SLO, aumenta la ridondanza:
Usare più zone di disponibilità. Configurare i carichi di lavoro per l'uso di più zone di disponibilità. Il modo in cui le zone di disponibilità migliorano il tempo di attività può essere difficile da stimare. Solo alcuni servizi selezionati hanno SLA di uptime che includono le zone di disponibilità. Dove gli accordi sul livello di servizio tengono conto delle zone di disponibilità, usali per le stime del tempo di attività. Vedi la tabella seguente per alcuni esempi.
Tipo di servizio di Azure Servizi di Azure con contratti di servizio della zona di disponibilità Piattaforma di calcolo Servizio app
Servizio Azure Kubernetes
Macchine virtualiArchivio dati Bus di servizio di Azure
Account di archiviazione di Azure
Cache di Azure per Redis
Livello Premium di File di AzureBanca dati Azure Cosmos DB, un servizio di database distribuito globale di Microsoft
Database SQL di Microsoft Azure
Database di Azure per MySQL
Database di Azure per PostgreSQL
Istanza gestita di Azure per Apache CassandraBilanciatore di carico Gateway di applicazione Sicurezza Firewall di Azure Usare più regioni. Spesso sono necessarie più regioni per soddisfare gli SLO di uptime. Usare i servizi di bilanciamento del carico globale (Frontdoor di Azure o Gestione traffico) per la distribuzione del traffico. Le architetture in più aree richiedono un'attenta gestione della coerenza dei dati.
Gestire la ridondanza dell'architettura. Decidere come usare la ridondanza: è possibile usare la ridondanza dell'architettura come parte delle operazioni quotidiane (attive). In alternativa, è possibile usare la ridondanza dell'architettura negli scenari di ripristino di emergenza (passivo). Per esempi, vedere Tabella 3.
Bilanciare il carico tra zone di disponibilità. Usare attivamente tutta la disponibilità. Molti servizi PaaS di Azure gestiscono automaticamente il bilanciamento del carico tra le zone di disponibilità. I carichi di lavoro IaaS devono usare un servizio di bilanciamento del carico interno per bilanciare il carico tra le zone di disponibilità.
Bilanciamento del carico tra regioni. Determinare se i carichi di lavoro in più regioni devono essere eseguiti active-active o active-passive in base alle esigenze di affidabilità.
Gestire le configurazioni del servizio. Applicare in modo coerente le configurazioni tra istanze ridondanti delle risorse di Azure, in modo che le risorse si comportino nello stesso modo. Usare l'infrastruttura come codice per mantenere la coerenza. Per altre informazioni, vedere Duplicare la configurazione delle risorse.
Progettare l'affidabilità del carico di lavoro. Per la progettazione dell'affidabilità del carico di lavoro, vedere Well-Architected Framework:
Affidabilità del carico di lavoro Indicazioni Pilastro dell'affidabilità Progettazione multiregione ad alta disponibilità
Progettazione per la ridondanza
Uso di zone e aree di disponibilitàGuida al servizio Guide al servizio di Azure (iniziare con la sezione Affidabilità)
Per altre informazioni, vedere Ridondanza.
Gestire la continuità aziendale
Il ripristino da un errore richiede una strategia chiara per ripristinare rapidamente i servizi e ridurre al minimo le interruzioni per mantenere la soddisfazione degli utenti. Seguire questa procedura:
Prepararsi per gli errori. Creare procedure di ripristino separate per i carichi di lavoro in base a priorità elevate, medie e basse. L'affidabilità dei dati, l'affidabilità del codice e del runtime e l'affidabilità delle risorse cloud sono le basi per prepararsi per l'errore. Selezionare altri strumenti di ripristino per facilitare la preparazione della continuità aziendale. Ad esempio, usare di Azure Site Recovery per carichi di lavoro server locali e basati su macchine virtuali.
Testare e documentare il piano di ripristino. Testare regolarmente i processi di failover e failback per verificare che i carichi di lavoro soddisfino gli obiettivi del tempo di ripristino (RTO) e gli obiettivi del punto di ripristino (RPO). Documentare chiaramente ogni passaggio del piano di ripristino per un semplice riferimento durante gli eventi imprevisti. Verificare che gli strumenti di ripristino, ad esempio Azure Site Recovery, soddisfino in modo coerente l'obiettivo RTO specificato.
Rilevare gli errori. Adottare un approccio proattivo per identificare rapidamente le interruzioni, anche se questo metodo aumenta i falsi positivi. Classificare in ordine di priorità l'esperienza dei clienti riducendo al minimo i tempi di inattività e mantenendo l'attendibilità degli utenti.
Monitorare gli errori. Monitorare i carichi di lavoro per rilevare interruzioni entro un minuto. Usare Integrità dei servizi di Azure e Integrità risorse di Azure e usare gli avvisi di Monitoraggio di Azure per notificare ai team pertinenti. Integrare questi avvisi con gli strumenti di Gestione dei servizi IT (ITM) o Azure DevOps.
Raccogliere gli indicatori del livello di servizio (SLI). Tenere traccia delle prestazioni definendo e raccogliendo le metriche che servono come indicatori del livello di servizio. Assicurarsi che i team usino queste metriche per misurare le prestazioni del carico di lavoro rispetto agli obiettivi del livello di servizio.
Rispondere agli errori. Allineare la risposta di ripristino alla priorità del carico di lavoro. Implementare le procedure di failover per reindirizzare immediatamente le richieste all'infrastruttura ridondante e alle repliche di dati. Dopo che i sistemi si stabilizzano, risolvere la causa principale, sincronizzare i dati ed eseguire le procedure di ripristino. Per ulteriori informazioni, consultare Failover e failback.
Analizzare gli errori. Identificare le cause radice dei problemi e quindi risolvere il problema. Documentare le lezioni e apportare le modifiche necessarie.
Gestire gli errori del carico di lavoro. Per il ripristino di emergenza del carico di lavoro, vedere la guida al ripristino di emergenza di Well-Architected Framework e le guide ai servizi di Azure (iniziare con la sezione Affidabilità).
Strumenti di affidabilità di Azure
Caso d'uso | Soluzione |
---|---|
Replica dei dati, backup e continuità aziendale |
Guide al servizio di Azure (iniziare con la sezione Affidabilità) Riferimento rapido: Azure Cosmos DB Database SQL di Azure Archiviazione BLOB di Azure File di Azure |
Backup dei dati | Azure Backup |
Continuità aziendale (IaaS) | Azure Site Recovery |
Servizio di bilanciamento del carico in più aree |
Frontdoor di Azure (HTTP) Gestione traffico di Azure (non HTTP) |
Bilanciatore del carico a multi-zona di disponibilità |
Gateway applicativo di Azure (HTTP) Azure Load Balancer (non HTTP) |
Gestione della sicurezza
Usare un processo di sicurezza iterativo per identificare e mitigare le minacce nell'ambiente cloud. Seguire questa procedura:
Gestire le operazioni di sicurezza
Gestire i controlli di sicurezza per rilevare le minacce per il cloud estate. Seguire questa procedura:
Standardizzare gli strumenti di sicurezza. Usare gli strumenti standardizzati per rilevare le minacce, correggere le vulnerabilità, analizzare i problemi, proteggere i dati, rafforzare le risorse e applicare la conformità su larga scala. Vedere Strumenti di sicurezza di Azure.
Stabilire il riferimento dell'ambiente. Documentare lo stato normale della vostra infrastruttura cloud. Monitorare la sicurezza e documentare i modelli di traffico di rete e i comportamenti degli utenti. Usare le baseline di sicurezza di Azure e le guide ai servizi di Azure per sviluppare configurazioni di base per i servizi. Questa baseline semplifica il rilevamento di anomalie e potenziali punti deboli della sicurezza.
Applicare i controlli di sicurezza. Implementare misure di sicurezza, ad esempio controlli di accesso, crittografia e autenticazione a più fattori, rafforza l'ambiente e riduce la probabilità di compromissione. Per altre informazioni, vedere Gestire la sicurezza.
Assegnare le responsabilità di sicurezza. Designare la responsabilità del monitoraggio della sicurezza nell'ambiente cloud. Il monitoraggio e i confronti regolari con la baseline consentono di identificare rapidamente gli eventi imprevisti, ad esempio l'accesso non autorizzato o i trasferimenti di dati insoliti. Gli aggiornamenti e i controlli regolari mantengono la baseline di sicurezza efficace contro le minacce in continua evoluzione.
Per altre informazioni, vedere CAF Secure.
Gestire gli eventi imprevisti della sicurezza
Adottare un processo e strumenti per il ripristino da eventi imprevisti di sicurezza, ad esempio ransomware, denial of service o intrusioni degli attori di minacce. Seguire questa procedura:
Prepararsi per gli eventi imprevisti. Sviluppare un piano di risposta agli eventi imprevisti che definisce chiaramente i ruoli per l'analisi, la mitigazione e la comunicazione. Testare regolarmente l'efficacia del piano. Valutare e implementare strumenti di gestione delle vulnerabilità, sistemi di rilevamento delle minacce e soluzioni di monitoraggio dell'infrastruttura. Ridurre la superficie di attacco tramite la protezione avanzata dell'infrastruttura e creare strategie di ripristino specifiche del carico di lavoro. Consultare la panoramica della risposta agli incidenti e i playbook di risposta agli incidenti.
Rilevare gli eventi imprevisti. Usare lo strumento SIEM (Security Information and Event Management), ad esempio Microsoft Sentinel, per centralizzare i dati di sicurezza. Usare le funzionalità di orchestrazione, automazione e risposta della sicurezza di Microsoft Sentinel per automatizzare le attività di sicurezza di routine. Integra i feed di threat intelligence nel tuo SIEM per ottenere una visione sulle tattiche avversarie rilevanti per il tuo ambiente cloud. Usare Microsoft Defender for Cloud per analizzare regolarmente Azure per individuare le vulnerabilità. Microsoft Defender si integra con Microsoft Sentinel per offrire una visualizzazione unificata degli eventi di sicurezza.
Rispondere agli eventi imprevisti. Attivare immediatamente il piano di risposta agli eventi imprevisti al rilevamento di un evento imprevisto. Avviare rapidamente le procedure di analisi e mitigazione. Attivare il piano di ripristino di emergenza per ripristinare i sistemi interessati e comunicare chiaramente i dettagli degli eventi imprevisti al team.
Analizzare gli eventi imprevisti di sicurezza. Dopo ogni evento imprevisto, esaminare l'intelligence sulle minacce e aggiornare il piano di risposta agli eventi imprevisti in base alle lezioni apprese e alle informazioni dettagliate provenienti dalle risorse pubbliche, ad esempio la knowledge base MITRE ATT&CK . Valutare l'efficacia degli strumenti di gestione e rilevamento delle vulnerabilità e perfezionare le strategie in base all'analisi post-evento imprevisto.
Per altre informazioni, vedere Gestire la risposta agli eventi imprevisti (CAF Secure).
Strumenti di sicurezza di Azure
Funzionalità di sicurezza | Soluzione Microsoft |
---|---|
Gestione delle identità e degli accessi | Microsoft Entra ID |
Controllo degli accessi in base al ruolo | Controllo degli accessi in base al ruolo di Azure |
Rilevamento delle minacce | Microsoft Defender for Cloud |
Gestione delle informazioni di sicurezza | Microsoft Sentinel |
Sicurezza e governance dei dati | Microsoft Purview |
Sicurezza delle risorse cloud | Baseline di sicurezza di Azure |
Governance del cloud | Criteri di Azure |
Sicurezza degli endpoint | Microsoft Defender per Endpoint |
Sicurezza della rete | Azure Network Watcher |
Sicurezza industriale | Microsoft Defender per IoT |
Sicurezza del backup dei dati | Sicurezza di Backup di Azure |