Come vengono selezionate le patch di sicurezza

I repository preconfigurati vengono gestiti in modo diverso su Amazon Linux 1 e Amazon Linux 2, rispetto a Amazon Linux 2022 e Amazon Linux 2023.

In Amazon Linux 1 e Amazon Linux 2, il servizio della baseline delle patch di Systems Manager utilizza repository preconfigurati nel nodo gestito. In genere in un nodo sono disponibili due repository (repo) preconfigurati:

Le istanze di Amazon Linux 2023 (AL2023) contengono inizialmente gli aggiornamenti disponibili nella versione di AL2023 e l’AMI scelta. Per impostazione predefinita, l'istanza AL2023 non riceve automaticamente aggiornamenti di sicurezza critici e importanti aggiuntivi al momento dell’avvio. Invece, con la funzionalità degli aggiornamenti deterministici tramite repository con versioni di AL2023, attivata per impostazione predefinita, è possibile applicare gli aggiornamenti in base a una pianificazione che soddisfi le tue esigenze specifiche. Per ulteriori informazioni, consulta Utilizzo di aggiornamenti deterministici tramite repository con versioni di AL2023 nella Guida per l'utente di Amazon Linux 2023.

Su Amazon Linux 2022, i repository preconfigurati sono legati a versioni bloccate degli aggiornamenti dei pacchetti. Quando vengono rilasciate nuove Amazon Machine Images (AMIs) per Amazon Linux 2022, queste vengono bloccate a una versione specifica. Per gli aggiornamenti delle patch, Patch Manager recupera l'ultima versione bloccata del repository degli aggiornamenti delle patch, quindi aggiorna i pacchetti sul nodo gestito in base al contenuto di quella versione bloccata.

Su AL 2023, il repository preconfigurato è il seguente:

Su Amazon Linux 2022 (release precedente), i repository preconfigurati sono legati a versioni bloccate degli aggiornamenti dei pacchetti. Quando vengono rilasciate nuove Amazon Machine Images (AMIs) per Amazon Linux 2022, queste vengono bloccate a una versione specifica. Per gli aggiornamenti delle patch, Patch Manager recupera l'ultima versione bloccata del repository degli aggiornamenti delle patch, quindi aggiorna i pacchetti sul nodo gestito in base al contenuto di quella versione bloccata.

Su Amazon Linux 2022, il repository preconfigurato è il seguente:

I nodi gestiti di Amazon Linux 1 e Amazon Linux 2 utilizzano Yum come gestore di pacchetti. Amazon Linux 2022 e Amazon Linux 2023 utilizzano DNF come gestore di pacchetti.

Entrambi i gestori di pacchetti utilizzano il concetto di avviso di aggiornamento come un file denominato updateinfo.xml. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. Tutti i pacchetti di un avviso di aggiornamento sono considerati di sicurezza da Patch Manager. Ai singoli pacchetti non vengono assegnati classificazioni o livelli di gravità. Per questo motivo, Patch Manager assegna gli attributi di un avviso di aggiornamento ai pacchetti correlati.

In CentOS e CentOS Stream, il servizio della patch di base di Systems Manager utilizza repository pre-configurati (repo) nel nodo gestito. L'elenco seguente fornisce esempi per un fittizio CentOS 8.2Amazon Machine Image(AMI):

I nodi gestiti 6 e 7 usano Yum come gestore di pacchetti. I nodi gestiti CentOS 8 e CentOS Stream utilizzano DNF come gestore di pacchetti. Entrambi i gestori di pacchetti utilizzano il concetto di avviso di aggiornamento. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici.

Tuttavia, i repo predefiniti di CentOS e CentOS Stream non sono configurati con un avviso di aggiornamento. Ciò significa che Patch Manager non è in grado di rilevare i pacchetti in un repo CentOS e CentOS Stream predefinito. Per abilitare Patch Manager all'elaborazione di pacchetti non sono contenuti in un avviso di aggiornamento, dovrai abilitare il flag EnableNonSecurity nelle regole di base di patch.

In Debian Server e Raspberry Pi OS (ex Raspbian) il servizio della patch di base di Systems Manager utilizza repository preconfigurati (repo) nell'istanza. Questi repo preconfigurati vengono utilizzati per estrarre un elenco aggiornato degli aggiornamenti dei pacchetti disponibili. A tale scopo, Systems Manager esegue l'equivalente di un comando sudo apt-get update.

I pacchetti vengono quindi filtrati da repo debian-security codename. Ciò significa che in ogni versione di Debian Server, Patch Manager identifica solo gli aggiornamenti che fanno parte del repository associato a quella versione, come segue:

In Oracle Linux, il servizio della patch di base di Systems Manager utilizza repository preconfigurati (repo) nel nodo gestito. In genere in un nodo sono disponibili due repo preconfigurati:

Oracle Linux 7:

Oracle Linux 8:

Oracle Linux 9:

I nodi gestiti di Oracle Linux utilizzano Yum come programma di gestione dei pacchetti e Yum si avvale del principio dell'avviso di aggiornamento sotto forma di file denominato updateinfo.xml. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. Ai singoli pacchetti non vengono assegnati classificazioni o livelli di gravità. Per questo motivo, Patch Manager assegna gli attributi di un avviso di aggiornamento ai pacchetti correlati e installa i pacchetti in base ai filtri di classificazione specificati nella base di patch.

In AlmaLinux, Red Hat Enterprise Linux e Rocky Linux, il servizio della patch di base di Systems Manager utilizza repository preconfigurati (repo) nel nodo gestito. In genere in un nodo sono disponibili tre repo preconfigurati:

Tutti gli aggiornamenti vengono scaricati dai repo remoti configurati nel nodo. Pertanto, il nodo deve avere un accesso in uscita a Internet per connettersi ai repository in modo che possa essere eseguita l'applicazione di patch.

I nodi gestiti Red Hat Enterprise Linux 7 usano Yum come gestore di pacchetti. I nodi gestiti AlmaLinux, Red Hat Enterprise Linux 8 e Rocky Linux utilizzano DNF come gestore di pacchetti. Entrambi i gestori di pacchetti utilizzano il concetto di avviso di aggiornamento come file denominato updateinfo.xml. Un avviso di aggiornamento è semplicemente una raccolta di pacchetti per la risoluzione di problemi specifici. Ai singoli pacchetti non vengono assegnati classificazioni o livelli di gravità. Per questo motivo, Patch Manager assegna gli attributi di un avviso di aggiornamento ai pacchetti correlati e installa i pacchetti in base ai filtri di classificazione specificati nella base di patch.

Nei nodi gestiti SUSE Linux Enterprise Server (SLES), la libreria ZYPP ottiene l'elenco delle patch disponibili (una raccolta di pacchetti) dai seguenti percorsi:

I nodi gestiti SLES utilizzano Zypper come programma di gestione dei pacchetti e Zypper si avvale del principio di una patch. Una patch è semplicemente una raccolta di pacchetti per la risoluzione di un problema specifico.Patch Manager gestisce tutti i pacchetti a cui fa riferimento in una patch come correlati alla sicurezza. Poiché ai singoli pacchetti non viene attribuita alcuna classificazione o gravità, Patch Manager assegna ai pacchetti gli attributi della patch a cui appartengono.

In Ubuntu Server, il servizio della patch di base di Systems Manager utilizza repository preconfigurati (repo) nel nodo gestito. Questi repo preconfigurati vengono utilizzati per estrarre un elenco aggiornato degli aggiornamenti dei pacchetti disponibili. A tale scopo, Systems Manager esegue l'equivalente di un comando sudo apt-get update.

I pacchetti vengono quindi filtrati da repository codename-security, in cui il nome in codice è univoco per la versione di rilascio, ad esempio trusty per Ubuntu Server 14. Patch Manager identifica esclusivamente gli aggiornamenti che fanno parte di questi repository:

Nei sistemi operativi Microsoft Windows, Patch Manager consente di recuperare l'elenco degli aggiornamenti disponibili pubblicati da Microsoft e sono automaticamente disponibili su Windows Server Update Services (WSUS).

Patch Manager effettua un monitoraggio continuo per nuovi aggiornamenti in ogni Regione AWS. L'elenco degli aggiornamenti disponibili viene aggiornato in ciascuna regione almeno una volta al giorno. Man mano che Microsoft elabora le informazioni sulle patch, Patch Manager rimuove dall'elenco gli aggiornamenti che sono stati sostituiti da quelli successivi. Pertanto, viene visualizzato e può essere installato solo l'aggiornamento più recente. Ad esempio, se KB4012214 sostituisce KB3135456, solo KB4012214 viene reso disponibile come aggiornamento in Patch Manager.

Allo stesso modo, Patch Manager installa solo le patch disponibili sul nodo gestito durante l'operazione di applicazione di patch. Per impostazione predefinita, Windows Server 2019 e Windows Server 2022 rimuovono gli aggiornamenti che vengono sostituiti da quelli successivi. Di conseguenza, quando si utilizza il parametro ApproveUntilDate in una baseline delle patch di Windows Server, ma la data selezionata nel parametro ApproveUntilDate è precedente alla data dell'ultima patch, si verifica lo scenario seguente:

Ciò significa che il nodo gestito è conforme in termini di operazioni di Systems Manager, anche nel caso in cui una patch critica del mese precedente non sia installata. Lo stesso scenario potrebbe verificarsi quando si utilizza il parametro ApproveAfterDays. A causa del comportamento delle patch sostituite da Microsoft, è possibile impostare un numero (in genere superiore a 30 giorni) in modo che le patch per Windows Server non vengano mai installate quando l'ultima patch disponibile di Microsoft viene rilasciata prima che sia trascorso il numero di giorni su ApproveAfterDays. Si noti che questo comportamento del sistema non si applica quando si sono modificate le impostazioni del GPO (Windows Group Policy Object) per rendere disponibile la patch sostituita sui nodi gestiti.