Condividi tramite

Proteggi il tuo patrimonio cloud

  • Articolo

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.

Diagramma che mostra il processo di gestione del CAF: preparare, amministrare, monitorare e proteggere.

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. tabella 1 fornisce un esempio di tre priorità del carico di lavoro, requisiti di affidabilità (SLO del tempo di attività, tempo di inattività massimo, ridondanza, bilanciamento del carico, replica) e scenari di esempio allineati agli obiettivi del 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
Alto (critico per la missione) Effetti immediati e gravi sulla reputazione o sui ricavi aziendali. 99,99% 4,32 minuti Più regioni & più zone di disponibilità in ogni regione Configurazione attiva-attiva Replica sincrona e interregionale dei dati & per il ripristino dei backup Linea di base mission-critical
Intermedio Effetti misurabili sulla reputazione o sui ricavi aziendali. 99,9% 43,20 minuti Più regioni &, più zone di disponibilità in ciascuna regione Attivo-passivo Replica asincrona dei dati tra regioni per backup e ripristino & Modello affidabile di app web
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 del servizio app
configurazione di base 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 tempo di esecuzione ✔️ ✔️ ✔️
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:

  1. 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.

  2. Assegnare l'obiettivo del livello di servizio di uptime (SLO) a tutti i carichi di lavoro. Stabilire obiettivi di uptime in base alla priorità dei carichi di lavoro. I carichi di lavoro con priorità più alta richiedono obiettivi di tempo di attività più rigorosi. Lo SLO influenza l'architettura, le strategie di gestione dei dati, i processi di ripristino e i costi.

  3. Identificare gli indicatori del livello di servizio (SLI). Utilizzare gli SLI per misurare le prestazioni di disponibilità rispetto al tuo SLO. Gli esempi includono monitoraggio dell'integrità del servizio e tassi di errore.

  4. 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. L'obiettivo del tempo di ripristino deve essere inferiore al tempo di inattività annuale consentito. Ad esempio, un tempo di attività SLO 99,99% richiede meno di 52 minuti di tempo di inattività annuale (4,32 minuti al mese). Seguire questa procedura:

    1. Stimare il numero di errori. Stimare la frequenza con cui ogni carico di lavoro potrebbe avere esito negativo all'anno. Per i carichi di lavoro con cronologia operativa, usare i vostri Indicatori di Livello di Servizio. Per i nuovi carichi di lavoro, eseguire un'analisi modalità di errore per ottenere una stima accurata.

    2. Stima l'RTO. Dividi il tempo di inattività annuale consentito per il numero stimato di errori. Se si stimano quattro errori all'anno, l'obiettivo RTO deve essere di 13 minuti o inferiore (52 minuti / 4 errori = 13 minuti RTO).

    3. 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 il recupero da un errore deve essere minore del tuo RTO. Se la tua soluzione di continuità aziendale richiede ore per funzionare

  5. Definire gli obiettivi del punto di ripristino (RPO) per tutti i carichi di lavoro. Determinare la quantità di perdita di dati che l'azienda può tollerare. Questo obiettivo influenza la frequenza con cui si esegue la replica e il backup dei dati.

  6. 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. Consultare Tabella 2 per esempi di priorità del carico di lavoro allineate agli obiettivi 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 ad alta frequenza tra regioni. La frequenza deve supportare RTO e RPO. piattaforma dati mission-critical
Intermedio 99,9% Replica sincrona dei dati tra aree

Replica sincrona dei dati tra zone di disponibilità		 Backup interregionale. La frequenza deve supportare RTO e RPO. soluzione di archiviazione e database nel modello Reliable Web App
Basso 99% Replica sincrona dei dati tra zone di disponibilità Backup tra regioni. La frequenza deve supportare RTO e RPO. Resilienza dei dati nell'applicazione web di base con ridondanza di zona

L'approccio deve allineare le configurazioni di affidabilità dei dati ai requisiti RTO e RPO dei carichi di lavoro. Seguire questa procedura:

  1. 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
    Attraverso le regioni (attivo-passivo) Asincrono (periodico) Configurazione attiva-passiva

    Per altre informazioni, vedere Replica di : Ridondanza per i dati.

  2. Gestire i backup dei dati. 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. Scegliere soluzioni di backup allineate agli obiettivi RTO e RPO. Preferisce le soluzioni predefinite di Azure, ad esempio Azure Cosmos DB e i backup nativi del database SQL di Azure. Per altri casi, inclusi i dati locali, usare Backup di Azure. Per altre informazioni, vedere Backup.

  3. 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 del Well-Architected Framework e le guide ai servizi di Azure (iniziare con la sezione Affidabilità).

Gestire l'affidabilità del codice e del runtime

Il codice e il runtime sono responsabilità del carico di lavoro. Seguire la guida all'auto-guarigione e auto-conservazione del Framework Well-Architected .

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 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 aree & zone di disponibilità Modalità attiva-attiva Frontdoor di Azure (HTTP)

Gestione traffico di Azure (non HTTP)		 piattaforma di base dell'applicazione 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 di modelli affidabili di app Web
Basso Area singola & zone di disponibilità Tra zone di disponibilità Gateway applicativo di Azure

Aggiungere Azure Load Balancer per le macchine virtuali		 Baseline del Servizio App
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:

  1. Stimare la disponibilità delle vostre 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). Seguire questa procedura:

    1. Raccogliere i contratti di servizio tempo di attività Microsoft per ogni servizio nel percorso critico del carico di lavoro.

    2. Se non si dispone di percorsi critici indipendenti, calcolare il contratto di servizio composito a singola area moltiplicando le percentuali di tempo di attività di ogni servizio pertinente. Se sono presenti percorsi critici indipendenti, passare al passaggio 3 prima di calcolare.

    3. Quando due servizi di Azure forniscono percorsi critici indipendenti, applicare la formula indipendente dei percorsi critici a tali servizi.

    4. Per le applicazioni in più aree, immettere il contratto di servizio composito a singola area (N) nella formula relativa al tempo di attività in più aree.

    5. Confronta il tempo di attività calcolato con il tuo SLO del tempo di attività. Se necessario, modificare i livelli di servizio o la ridondanza dell'architettura.

    Caso d'uso Formula Variabili Esempio Spiegazione
    Stima del tempo di attività di una singola regione N = S1 × S2 × S3 × ... × Un N: contratto di servizio composito dei servizi di Azure in un percorso critico a singola area.
    S: percentuale di operatività del contratto di servizio di ogni servizio di Azure.
    n: numero totale di servizi di Azure 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.
    Stima dei percorsi critici indipendenti S1 x 1 - [(1 - S2) × (1 - S3)] S: percentuale di uptime del contratto di servizio nei servizi di Azure che forniscono percorsi critici indipendenti. 99.99% (app) × (1 - [(1 - 99,95% database) × (1 - 99,9% cache)]) Due percorsi critici indipendenti. Sia il database (99.95%) che la cache (99.9%) possono fallire senza causare tempi di inattività.
    Stima dell'operatività su più regioni M = 1 - (1 - N)^R M: stima del tempo di attività in più aree.
    N: contratto di servizio composito a singola area.
    R: numero di aree usate.    		 Se N = 99,95% e R = 2, M = 1 - (1 - 99,95%)^2 Carico di lavoro distribuito in due aree.

  2. Regolare 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.

  3. Aggiungere ridondanza dell'architettura. Se la stima corrente del tempo di attività non è in linea con l'SLO, aumentare la ridondanza:

    1. 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 un numero limitato di servizi ha accordi sul livello di servizio (SLA) relativi al tempo di attività che tengono conto delle zone di disponibilità. Dove i contratti di servizio (SLAs) considerano le zone di disponibilità, usale nelle tue 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 virtuali
      Archivio dati Bus di servizio di Azure
      Account di archiviazione di Azure
      Cache di Azure per Redis
      Livello Premium di File di Azure
      Banca dati Azure Cosmos DB
      Azure SQL Database
      Database di Azure per MySQL
      Database di Azure per PostgreSQL
      Istanza gestita di Azure per Apache Cassandra
      Bilanciatore di carico Gateway di applicazione
      Sicurezza Firewall di Azure

    2. Usare più regioni. Più regioni sono spesso necessarie per soddisfare gli obiettivi di livello di servizio relativi all'operatività. 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.

  4. 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.

    1. bilanciamento del carico tra le 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à.

    2. bilanciamento del carico tra aree. Determinare se i carichi di lavoro in più aree devono essere eseguiti attivo-attivo o attivo-passivo in base alle esigenze di affidabilità.

  5. 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 'infrastruttura come codice per mantenere la coerenza. Per altre informazioni, vedere Configurazione delle risorse duplicate.

  6. 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 multi-regione a Disponibilità Elevata
    Progettazione per la ridondanza
    Uso di zone di disponibilità e regioni
    Guida al servizio guide ai servizi 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:

  1. Preparatevi ai fallimenti. Create procedure di ripristino separate per i carichi di lavoro basati su priorità elevate, medie e basse. Affidabilità dei dati, affidabilità del codice e del runtimee affidabilità delle risorse cloud sono la base della preparazione al fallimento. 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.

  2. Piano di recupero, test e documentazione. Testare regolarmente i processi di failover e failback per verificare che i carichi di lavoro soddisfino gli obiettivi dei tempi di ripristino (RTO) e degli obiettivi dei punti 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.

  3. 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.

    1. Monitorare gli errori. Monitorare i carichi di lavoro per rilevare interruzioni entro un minuto. Usare Azure Service Health e Azure Resources Health e usare avvisi di Azure Monitor per inviare una notifica ai team pertinenti. Integrare questi avvisi con gli strumenti di Gestione dei servizi IT (ITM) o Azure DevOps.

    2. Raccogliere gli indicatori del livello di servizio (SLI). Tenere traccia delle prestazioni definendo e raccogliendo metriche che fungono da indicatori del livello di servizio (SLI). Assicurarsi che i team usino queste metriche per misurare le prestazioni del carico di lavoro rispetto agli obiettivi del livello di servizio.

  4. 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 dati. Una volta stabiliti i sistemi, risolvere la causa principale, sincronizzare i dati ed eseguire le procedure di failback. Per maggiori dettagli, vedere Failover e failback.

  5. Analizzare gli errori. Identificare le cause radice dei problemi e quindi risolvere il problema. Documentare le lezioni e apportare le modifiche necessarie.

  6. Gestire gli errori del carico di lavoro. Per il ripristino di emergenza del carico di lavoro, vedere la guida di ripristino di emergenza di Well-Architected Framework e guide al servizio di Azure (iniziare con la sezione Affidabilità).

Strumenti di affidabilità di Azure

Caso d'uso Soluzione
Replica dei dati, backup e continuità aziendale guide ai servizi 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 Backup di Azure
Continuità aziendale (IaaS) Azure Site Recovery
Servizio di bilanciamento del carico in più aree Azure Front Door (HTTP)
Gestione traffico di Azure (non HTTP)
Servizio di bilanciamento del carico della zona a disponibilità multipla Azure Application Gateway (HTTP)
Bilanciatore del carico di Azure (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:

  1. standardizzare gli strumenti di sicurezza. Usare strumenti standardizzati per rilevare minacce, correggere le vulnerabilità, analizzare i problemi, proteggere i dati, rafforzare le risorse e applicare la conformità su larga scala. Fare riferimento a strumenti di sicurezza di Azure.

  2. Stabilisci un punto di riferimento per il tuo ambiente. Documenta lo stato normale della tua infrastruttura cloud. Monitorare i di sicurezza e documentare i modelli di traffico di rete e i comportamenti degli utenti. Usare baseline di sicurezza Azure e guide ai servizi Azure per sviluppare configurazioni di base per i servizi. Questa baseline semplifica il rilevamento di anomalie e potenziali punti deboli della sicurezza.

  3. 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 Manage security.

  4. Assegnare le responsabilità di sicurezza. Designare la responsabilità per il 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:

  1. 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. Vedere Panoramica della risposta agli eventi imprevisti e playbook di risposta agli eventi imprevisti .

  2. 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. Integrare feed di intelligence per le minacce nel sistema SIEM per ottenere informazioni dettagliate sulle tattiche antagoniste rilevanti per l'ambiente cloud. Usare Microsoft Defender for Cloud per analizzare regolarmente Le vulnerabilità di Azure. Microsoft Defender integra con Microsoft Sentinel per offrire una visualizzazione unificata degli eventi di sicurezza.

  3. 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.

  4. 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 delle 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

Passaggi successivi

CAF Gestire la lista di controllo