Le best practice per la gestione delle patch

In qualità di Solution Architect, mi viene spesso chiesto quali sono le best practice di Red Hat per la gestione delle patch. In questo articolo intendo affrontare l'argomento e con l'ausilio di opere e materiali pertinenti definire cos'è una best practice e individuare gli strumenti da introdurre nel proprio toolkit per la gestione delle patch.

Dopo aver letto questo articolo, avrai un'idea più chiara sugli strumenti e sugli approcci a tua disposizione per la distribuzione delle patch e sulle procedure consigliate per la definizione di tale processo.

Definire una procedura "best practice", letteralmente "la miglior pratica", è effettivamente un po' presuntuoso. D'altronde ciò che è meglio per un'organizzazione, non è detto che lo sia per un'altra. Quindi, invece di etichettare un approccio come "il migliore", ritengo che sia più corretto parlare in termini di il processo più appropriato per un determinato livello di rischio. Infatti, quando si parla di gestione delle patch, si parla anche e soprattutto di gestione del rischio e di gestione delle modifiche.

Ogni organizzazione deve stabilire un approccio per far fronte ai rischi che sia specifico in base a ciò che individua come rischio, ai suoi obiettivi e all'importanza che dà ai diversi vincoli, impatti e risultati aziendali.

Io preferisco il termine "good practice", letteralmente "buona pratica", in linea con la scelta ad esempio dell'Automation Community of Practice, che ha pubblicato un documento di Automation Good Practices basato sull'esperienza maturata sul campo.

Quali sono gli strumenti e gli approcci a nostra disposizione per la gestione delle patch?

Esistono diversi strumenti e metodologie per definire una strategia di gestione delle patch nell'infrastruttura.

1. Distingui le correzioni per tipologia

Red Hat suddivide le modifiche al codice o ai contenuti (correzioni) in tre categorie. Ogni categoria ha uno scopo e un livello di gravità diversi. A seconda degli obiettivi e della tolleranza al cambiamento dell'organizzazione, un'opzione potrebbe rivelarsi più in linea con le esigenze aziendali rispetto a un'altra.

• Red Hat Security Advisory (RHSA): sono disponibili modifiche urgenti per proteggere i sistemi
• Red Hat Bug Advisory (RHBA): sono disponibili correzioni di bug che potrebbero interessare i sistemi aziendali
• Red Hat Enhancement Advisory (RHEA): sono state aggiunte nuove funzionalità

Per ulteriori informazioni, consulta la pagina di Red Hat dedicata alla procedura per il backporting di sicurezza e leggi l'articolo What is backporting, and how does it apply to RHEL and other Red Hat products?

Questo approccio consente di suddividere le correzioni in base al tipo e al rischio, e poi scegliere quali patch si reputano necessarie e quali invece facoltative. 

Ad esempio, se si dispone di un'infrastruttura collegata a Internet o una DMZ (zona demilitarizzata) con un profilo di sicurezza elevato, è possibile scegliere di applicare unicamente le correzioni Red Hat Security Advisory via via che vengono rilasciate in quell'ambiente. In questo modo si suddividono le modifiche in batch piccoli e facili da applicare e si soddisfano le esigenze di un'infrastruttura ad alto rischio. 

Di seguito due esempi di come applicare solo le correzioni di sicurezza in un processo di patching:

• È possibile limitare yum in modo che elenchi e installi solo gli aggiornamenti di sicurezza?
• Come si applicano le correzioni di sicurezza con Red Hat Satellite?

Un altro approccio interessante è l'applicazione di patch in sottoinsiemi di pacchetti per ridurre ulteriormente il rischio legato all'introduzione di modifiche. Una tecnica che offre la possibilità di eseguire il rollback qualora la patch dovesse interagire con il sistema in modo imprevisto. Come per qualsiasi altro approccio, non è detto che questa soluzione risponda alle esigenze di tutti. Per alcune organizzazioni infatti potrebbe risultare un processo troppo granulare, mentre per altre la strategia ideale.

2. Dieci passaggi per creare un ambiente operativo standard (SOE)

Questo articolo offre una guida completa sull'utilizzo di Red Hat Satellite per abilitare e gestire un ambiente operativo standard. Tratta ogni argomento in modo dettagliato e vuole essere un punto di riferimento per rispondere alle domande più frequenti sulle best practice. Sebbene l'articolo sia stato scritto diversi anni fa, cioè quando è stato introdotto per la prima volta Red Hat Satellite 6, i suoi concetti di base sono ancora validi oggi.

La gestione e lo staging dei contenuti giocano un ruolo chiave nel processo di applicazione delle patch. Servono per definire il modo in cui il contenuto delle patch viene presentato all'infrastruttura e sono essenziali per la gestione e la riduzione del rischio.

Su Satellite presta particolare attenzione a strumenti come Lifecycle Environments e Content Views. Si tratta di concetti fondamentali per lo staging dei contenuti e la loro promozione (o rollback) nell'infrastruttura.

Ma non limitarti a quelli, sfrutta anche Organizations, Locations e Host Groups per classificare l'infrastruttura e l'inventario. Troppo spesso mi accorgo che le persone adottano un approccio molto granulare con Lifecycle Environments o Content Views, e cercano di utilizzare queste strutture per classificare posizioni geografiche, ambienti cloud, infrastrutture simili o team diversi all'interno dell'organizzazione.

3. Applicazione live delle patch al kernel

L'applicazione live delle patch al kernel è una funzionalità ormai disponibile da diversi anni ed è inclusa in molte delle versioni principali di RHEL. Consente di applicare le patch a un kernel in esecuzione senza bisogno di riavvio per risolvere le vulnerabilità più rapidamente. Grazie a questa funzionalità gli amministratori possono affrontare i rischi in maniera tempestiva e programmare il riavvio del sistema in un periodo di manutenzione successivo. 

Anche questa funzionalità si può orchestrare con Red Hat Satellite.

4. Identifica i pacchetti che richiedono il riavvio del sistema dopo un aggiornamento

Non sempre è necessario riavviare il sistema dopo l'applicazione di una patch, dipende dall'aggiornamento e dal contenuto della correzione. A volte per utilizzare un file binario aggiornato è sufficiente il riavvio di un servizio. 

A partire da RHEL 7, yum-utils include un plugin chiamato needs-restarting che segnala se è necessario riavviare il sistema dopo aver applicato le patch. Questa utilità aiuta a sapere quando occorre apportare modifiche a un sistema e a ridurre il numero di riavvii durante l'applicazione delle patch.

Satellite include anche una funzionalità chiamata Tracer che aiuta gli amministratori a identificare le applicazioni da riavviare dopo l'applicazione di patch al sistema.

5. Valuta se inviare una richiesta di supporto proattiva a Red Hat

Avere una conoscenza approfondita su una determinata attività di manutenzione e l'opportunità di raccogliere informazioni e dati in anticipo permette di ridurre i tempi di fermo e alcuni dei rischi associati all'applicazione delle patch.

Una richiesta di supporto proattiva consente di ridurre notevolmente i tempi per la risoluzione dei problemi e il ripristino dei servizi, oltre a offrire l'opportunità di verificare le procedure e gli approcci in anticipo. Tutto questo ha un impatto misurabile sul numero di interruzioni e sul tempo medio di ripristino (MTTR).

6. Punta sull'automazione

Non è un segreto che sostituire i passaggi manuali con un approccio automatizzato contribuisce a ridurre l'errore umano, aumenta l'affidabilità e accelera il processo di applicazione delle patch. L'automazione è un elemento chiave di molte best practice in contesti aziendali.

Red Hat Satellite è in grado di eseguire in maniera remota le funzionalità di Ansible. Ciò significa che Red Hat Satellite può eseguire Ansible Playbook e Role sull'inventario RHEL per automatizzare e programmare l'applicazione delle patch.

La raccolta ufficiale redhat.satellite inclusa in Red Hat Ansible Automation Platform permette di automatizzare e orchestrare l'intera gestione dei contenuti di Satellite e applicare il contenuto delle patch dopo lo staging.

Ansible mette a disposizione anche gli Ansible Module che si possono utilizzare per eseguire test funzionali per i servizi web o per la verifica dei servizi dopo aver applicato una patch.

Riepilogo

Red Hat ha pubblicato An Open Approach to Vulnerability Management, una metodologia concisa ma completa sull'approccio alla gestione delle vulnerabilità. La gestione del rischio è una decisione da prendere dopo aver considerato e valutato i vincoli, gli impatti e i risultati aziendali.

La vera domanda è: ma le vulnerabilità hanno tutte la stessa importanza? Questo articolo mette in evidenza alcuni dei compromessi a cui occorre scendere per trovare il giusto equilibrio tra vincoli, impatti, risultati, vantaggi e costi. Se è vero che occorre valutare attentamente ogni rischio, è pur vero che non hanno tutti lo stesso grado di urgenza e rilevanza e che nessuna organizzazione ha le risorse per affrontarli tutti. È essenziale assegnare delle priorità e pianificare una strategia che consenta di individuare i rischi su cui è necessario intervenire e quelli con cui si può convivere.

In poche parole, occorrono iterazione e impegno. Nessuno degli esempi citati in questo articolo è stato il primo tentativo nello sviluppo di una strategia. Ci abbiamo lavorato modificandoli e perfezionandoli più e più volte fino a quando non abbiamo trovato un equilibrio adatto a Red Hat. E continueremo a perfezionare queste metodologie man mano che apprenderemo nuove informazioni e il settore evolverà. Solo così, con impegno, personalizzazione e perfezionamento continui, si può sperare di avvicinarsi a quella perfezione che il temine "best practice" sembra sottintendere.