Condividi tramite

Processo di gestione delle patch

Fase 3 - Stima e pianificazione

Aggiornato: 1 giugno 2007

In questa pagina

Argomenti del modulo Obiettivi Ambito di applicazione Utilizzo del modulo Panoramica Stabilire la risposta appropriata Pianificazione del rilascio Generazione del rilascio Test di accettabilità Riepilogo Passaggio alla fase di distribuzione

Argomenti del modulo

In questo modulo viene descritta la terza fase, stima e pianificazione, del processo di gestione in quattro fasi degli aggiornamenti. La fase di stima e pianificazione riguarda la decisione sulla distribuzione di un aggiornamento, su quanto è necessario per la distribuzione e il test dell'aggiornamento software in un ambiente simile a quello di produzione per controllare che non comprometta le applicazioni e i sistemi critici per l'attività dell'azienda.

Lo scopo di questo modulo è descrivere i principi della fase di stima e pianificazione del processo di gestione degli aggiornamenti e introdurre i tipi di attività che consentono di eseguire la stima e la pianificazione con Microsoft Windows Server Update Service (WSUS) e Microsoft Systems Management Server (SMS).

Nota: la versione di valutazione del successivo rilascio di SMS, chiamata System Center Configuration Manager 2007, è ora disponibile per il download all'indirizzo http://www.microsoft.com/technet/sms/2007/evaluate/download.mspx (in inglese). Grazie ai notevoli investimenti in semplificazione, configurazione, distribuzione e protezione, Configuration Manager 2007 rende radicalmente più facile la distribuzione dei sistemi, l'automazione delle attività, la gestione della conformità e la gestione della protezione basata su criteri, aumentando l'agilità dell'azienda.

Senza un processo di stima e di pianificazione non si disporrà di una serie chiara di criteri utili per stabilire se distribuire un aggiornamento, non si saprà cosa è necessario per distribuirlo e non si potrà contare su procedure per generare un software di rilascio affidabile e ben collaudato.

Inizio pagina

Obiettivi

Il modulo consente di:

  • Stabilire se la distribuzione di un aggiornamento è effettivamente necessaria.

  • Pianificare il rilascio dell'aggiornamento software.

  • Generare il rilascio.

  • Condurre test di accettazione dell'aggiornamento.

Inizio pagina

Ambito di applicazione

Questo modulo si applica a tutti i prodotti e a tutte le tecnologie Microsoft.

Inizio pagina

Utilizzo del modulo

In questo modulo sono descritte le attività di base necessarie per effettuare una stima e una pianificazione utilizzando WSUS e SMS. Informazioni più dettagliate sono fornite nelle Technical Library elencate di seguito.

Per trarre il massimo vantaggio dal modulo:

Inizio pagina

Panoramica

La stima e pianificazione è la terza fase del processo di gestione degli aggiornamenti illustrato nella Figura 1.

Figura 1. Il processo di gestione degli aggiornamenti

In questa fase viene valutato l'aggiornamento software e se ne pianifica la distribuzione nell'ambiente di produzione, presumendo che sia stata approvata.

La prima azione della fase di stima e pianificazione riguarda una richiesta di modifica (RFC, Request For Change) per un aggiornamento software identificato come pertinente per l'ambiente di produzione.

Entro la fine della fase di stima e pianificazione, si sarà dovuto stabilire se la richiesta di modifica deve essere classificata come un'emergenza, si sarà dovuto provvedere a esaminare e approvare la richiesta e si sarà dovuto stabilire le attività richieste per la distribuzione delle modifiche approvate nella produzione. Inoltre sarà necessario aver eseguito il test dell'aggiornamento software in un ambiente simile a quello di produzione per controllare che non comprometta le applicazioni e i sistemi critici per l'attività dell'azienda.

Questo modulo è dedicato ai requisiti per la stima e la pianificazione:

  • Stabilire la risposta appropriata.

  • Pianificare il rilascio dell'aggiornamento software.

  • Generare il rilascio.

  • Condurre test di accettazione dell'aggiornamento.

Inizio pagina

Stabilire la risposta appropriata

L'RFC stabilisce il tipo di modifica richiesto nell'ambiente di produzione, ad esempio la distribuzione di un aggiornamento software, l'applicazione di contromisure per attenuare la vulnerabilità o entrambe le cose, e descrive la modifica richiesta per permettere che altri agiscano di conseguenza.

Il primo passaggio della fase di stima e pianificazione consiste nell'esaminare l'RFC e nel decidere quale sia la risposta più appropriata a una vulnerabilità software o a un pericolo. Azioni richieste:

  • Definizione della priorità e classificazione della richiesta.

  • Ottenimento dell'autorizzazione per la distribuzione dell'aggiornamento software.

Definizione della priorità e classificazione di una richiesta di aggiornamento software

Prima di poter autorizzare una richiesta di aggiornamento software, è necessario stabilirne la priorità e la categoria. Anche se priorità e categoria vengono inizialmente assegnate da colui che ha dato inizio alla modifica e sono incluse nell'RFC, perché sia possibile autorizzare la richiesta di modifica è prima necessario esaminare queste assegnazioni e confermarle o modificarle.

Assegnazione della priorità a un aggiornamento software

Il livello di priorità è particolarmente importante perché stabilisce la rapidità del processo di modifica di un aggiornamento software. Le seguenti considerazioni possono aiutare a stabilire il livello di priorità di un aggiornamento software:

  • Quali sono le risorse aziendali critiche? Saranno esposte a una potenziale violazione della protezione o instabilità del sistema fino all'installazione dell'aggiornamento software? L'assegnazione della priorità alle richieste di modifica deve basarsi sull'impatto dell'aggiornamento o del mancato aggiornamento di risorse ad alto valore.

  • L'aggiornamento software si applicherà a un sistema con un servizio vitale per l'attività dell'azienda, quale un'applicazione line-of-business (LOB), che è stato oggetto di attacchi in passato? Questa potrebbe essere una valida ragione per aumentare la priorità di una richiesta di modifica.

  • Sono state applicate le contromisure che dovrebbero ridurre al minimo l'esposizione di una particolare vulnerabilità della protezione? Queste misure potrebbero diminuire la priorità della richiesta di modifica, anche se potrebbe essere comunque appropriato distribuire l'aggiornamento software per eliminare la vulnerabilità.

  • Quale pericolo comporta per l'ambiente di produzione la vulnerabilità in questione? Molti bollettini sulla sicurezza e relativi aggiornamenti software potrebbero applicarsi solo a pochi computer dell'ambiente. Se il pericolo della vulnerabilità è basso, questo potrebbe abbassare la priorità della richiesta.

Le seguenti tabelle possono aiutare a valutare la priorità della richiesta in relazione ad altre richieste. Nella Tabella 1, i livelli di priorità sono correlati a intervalli di tempo consigliati e a intervalli di tempo minimi consigliati.

Tabella 1: Priorità dell'aggiornamento e intervalli di tempo di distribuzione consigliati

Priorità Intervallo di tempo consigliato Intervallo di tempo minimo consigliato
Emergenza Entro 24 ore Entro due settimane
Elevata Entro un mese Entro due mesi
Media A seconda della disponibilità, distribuire un nuovo service pack o un rollup di aggiornamento che includa la correzione di questa vulnerabilità entro quattro mesi. Distribuire l'aggiornamento software entro sei mesi
Bassa A seconda della disponibilità, distribuire un nuovo service pack o un rollup di aggiornamento che includa la correzione di questa vulnerabilità entro 1 anno. Distribuire l'aggiornamento software entro 1 anno oppure scegliere di non procedere alla distribuzione.
Nella Tabella 2 sono riportati degli esempi di fattori che potrebbero innalzare o abbassare il livello di priorità. **Tabella 2: Fattori che influenzano le priorità di aggiornamento**
Fattore ambientale/organizzativo Correzione della priorità
Impatto su risorse di alto valore o alta esposizione. Innalzare
Risorse storicamente prese di mira dai pirati informatici. Innalzare
Esistono fattori di attenuazione, quali contromisure che riducono al minimo il pericolo. Abbassare
Impatto su risorse di poco valore o scarsa esposizione. Abbassare
**Richiesta di modifica di emergenza** Se la vulnerabilità risolta dall'aggiornamento per la protezione viene già sfruttata o sta per esserlo, o se l'aggiornamento corregge un'instabilità del sistema riscontrata nell'ambiente di produzione, potrebbe essere necessario classificare la richiesta come "emergenza", assegnandole la priorità su tutte le altre modifiche che hanno luogo all'interno dell'ambiente di produzione. ##### Classificazione di un aggiornamento software La categoria di un aggiornamento software è importante, perché aiuta chi si occupa dell'esame della modifica a capire l'impatto che avrà sui sistemi e sui servizi all'interno dell'ambiente di produzione. Per stabilire la categoria (o l'impatto) della richiesta di modifica, è necessario individuare: - Su quali macchine deve essere installato l'aggiornamento software e i ruoli che esse svolgono (criticità per l'azienda). Un aggiornamento software che richiede il riavvio di un computer critico per l'attività dell'azienda, ad esempio, avrà un impatto maggiore di uno che non richiede il riavvio. - Se saranno necessarie ulteriori modifiche per supportare la distribuzione dell'aggiornamento software. Se, ad esempio, l'aggiornamento software si applica solo al service pack corrente e quest'ultimo non è installato in certi sistemi di produzione, potrebbe non essere possibile proteggere quei sistemi da una particolare vulnerabilità della protezione. In questo caso, l'impatto e di conseguenza la categoria della richiesta di modifica sarebbero maggiori, in quanto sia il service pack che l'aggiornamento software dovrebbero essere distribuiti. - Se l'aggiornamento software può essere disinstallato, dopo essere stato installato. In caso negativo, presenta un rischio maggiore per l'ambiente di produzione rispetto a uno che può essere disinstallato senza problemi. Anche se potrebbe essere necessario distribuire questi aggiornamenti software per fornire una protezione da una particolare vulnerabilità o per risolvere una particolare instabilità del sistema, la categoria della richiesta deve riflettere questa eventualità. - L'impatto probabile sull'infrastruttura di rete. La distribuzione di un aggiornamento software di grandi dimensioni in molti computer contemporaneamente potrebbe deteriorare le prestazioni della rete e influire negativamente sul corretto funzionamento dell'intero ambiente. Esaminare attentamente tutta la documentazione sull'aggiornamento software ed essere sempre al corrente della dimensione dell'aggiornamento e del numero di computer che saranno interessati. Queste informazioni possono essere utili per pianificare correttamente il rilascio. - Se, durante l'installazione, è necessario interrompere, sospendere o chiudere determinati servizi. Questo potrebbe influire sui servizi critici di un'organizzazione o impedire a un utente finale di lavorare al computer mentre è in corso l'installazione. Ulteriori informazioni sull'impostazione della priorità e della categoria di una richiesta di modifica sono reperibili nella funzione di gestione del servizio (SMF, Service Management Function) Gestione dei cambiamenti all'indirizzo