Amazon RDS aggiorna MariaDB con il post-quantum TLS: cosa verificare prima dell’upgrade

Amazon RDS aggiorna MariaDB con il post-quantum TLS: cosa verificare prima dell’upgrade

Amazon RDS per MariaDB supporta cinque nuove minor release della community: 10.6.28, 10.11.19, 11.4.13, 11.8.9 e 12.3.3. L’aggiornamento, annunciato da AWS l’8 settembre 2026, introduce anche il supporto allo scambio di chiavi post-quantum TLS (PQ-TLS) per proteggere i dati in transito. Per le aziende non è però un invito ad aggiornare alla cieca: versione del motore, driver, replica, finestra di manutenzione e possibilità di rollback devono essere controllati prima di intervenire.

La novità è utile soprattutto per applicazioni gestionali, e-commerce, portali clienti e software verticali che usano MariaDB su AWS. Il database gestito riduce molte attività infrastrutturali, ma non elimina la responsabilità di verificare compatibilità e continuità operativa.

Quali versioni MariaDB sono ora supportate su Amazon RDS

AWS ha indicato queste nuove minor release:

  • MariaDB 10.6.28
  • MariaDB 10.11.19
  • MariaDB 11.4.13
  • MariaDB 11.8.9
  • MariaDB 12.3.3

Nel lessico di Amazon RDS, il passaggio che modifica soltanto l’ultima parte del numero di versione è un minor upgrade: per esempio, da 10.11.18 a 10.11.19. Il cambio da 10.6 a 10.11 è invece un major upgrade e può introdurre incompatibilità applicative. Questa distinzione è importante perché procedure, tempi e rischio non sono equivalenti.

AWS raccomanda le nuove release per ricevere correzioni di vulnerabilità note, bug fix, miglioramenti operativi e nuove funzioni della community MariaDB. La disponibilità concreta può comunque dipendere dalla Regione AWS e dal percorso di upgrade valido per l’istanza: va verificata nella console o tramite API/CLI prima di pianificare il change.

Che cosa significa davvero post-quantum TLS

Il TLS protegge la connessione tra applicazione e database. Il nuovo supporto PQ-TLS riguarda lo scambio delle chiavi, cioè la fase con cui client e server stabiliscono il segreto crittografico usato per la sessione. L’obiettivo è ridurre il rischio futuro legato a scenari in cui un avversario conserva oggi traffico cifrato per tentare di decifrarlo quando saranno disponibili computer quantistici sufficientemente potenti.

Supportato non significa già attivo

La presenza della funzione nel motore non prova che ogni connessione utilizzi automaticamente un meccanismo post-quantum. Occorre verificare parametri del database, librerie TLS disponibili, driver e runtime dell’applicazione. Anche proxy, connection pooler, appliance di ispezione e componenti legacy possono limitare le suite negoziabili.

Per questo il controllo corretto non consiste soltanto nel leggere la versione del server: bisogna osservare una connessione reale dall’applicazione e verificare protocollo e cifratura negoziati. L’adozione del PQ-TLS non sostituisce inoltre i controlli fondamentali: TLS obbligatorio, certificati verificati, rotazione delle credenziali, autorizzazioni minime e isolamento di rete.

Perché l’upgrade richiede una finestra di manutenzione

La documentazione AWS chiarisce che gli upgrade del motore richiedono downtime, la cui durata dipende dalla dimensione e dalla configurazione dell’istanza. In una distribuzione Multi-AZ vengono aggiornati writer e standby e può esserci un’interruzione fino al completamento. Se sono presenti read replica, queste devono essere aggiornate prima dell’istanza sorgente.

Amazon RDS esegue snapshot durante il processo quando la retention dei backup è maggiore di zero. Dopo l’upgrade non è possibile effettuare un downgrade diretto del motore: per tornare indietro bisogna ripristinare uno snapshot in una nuova istanza, riallineare gli eventuali dati prodotti nel frattempo e spostare le connessioni. Uno snapshot è quindi una base tecnica, non un piano di rollback completo.

Per ridurre l’impatto si può valutare RDS Blue/Green Deployments: l’ambiente green viene preparato e testato separatamente, quindi promosso con uno switchover controllato. Anche in questo caso vanno collaudati DNS, stringhe di connessione, scritture durante il cambio, integrazioni e monitoraggio.

Checklist prima di aggiornare RDS per MariaDB

  1. Inventaria le istanze: Regione, versione, classe, storage, Multi-AZ, replica e parameter group.
  2. Trova i target validi: verifica nella console o con describe-db-engine-versions, senza presumere che ogni salto sia consentito.
  3. Controlla il ciclo di supporto: chi usa MariaDB 10.6 deve pianificare anche il passaggio a una major release supportata, non limitarsi alla patch.
  4. Clona e prova: ripristina uno snapshot o usa Blue/Green per eseguire test funzionali e di carico.
  5. Verifica client e driver: PHP, Java, .NET, Python, connettori ODBC/JDBC, proxy e pool di connessioni.
  6. Testa il TLS: accerta che la cifratura sia obbligatoria, il certificato sia validato e la modalità negoziata sia quella attesa.
  7. Valuta le query: confronta error log, slow query log, performance, charset, collation e procedure memorizzate.
  8. Prepara il rollback: stabilisci RTO/RPO, snapshot di partenza, procedura di ripristino e gestione delle scritture successive.
  9. Scegli la finestra: comunica il possibile disservizio e monitora applicazione, connessioni, replica, CPU, memoria e storage.
  10. Aggiorna la documentazione: registra versione, esito dei test, parametri modificati e responsabile del change.

Aggiornamento automatico: utile, ma solo con governance

L’opzione Auto minor version upgrade consente a RDS di applicare automaticamente una minor release dopo i test e l’approvazione di AWS. Non equivale necessariamente all’installazione immediata della release appena annunciata. Per ambienti con molte istanze e account, AWS indica anche le Upgrade Rollout Policy di Organizations per scaglionare gli aggiornamenti.

L’automazione ha senso quando esistono ambienti di prova rappresentativi, finestre di manutenzione definite, alert e responsabilità chiare. Senza questi elementi, il rischio è scoprire un’incompatibilità direttamente in produzione. Per i sistemi più critici conviene usare gruppi progressivi: sviluppo, test, un primo ambiente a basso impatto e infine produzione.

MariaDB 10.6: la patch non risolve il tema del ciclo di vita

La documentazione RDS colloca la fine del supporto standard della major 10.6 a novembre 2026. Installare la 10.6.28 può essere una misura necessaria nel breve periodo, ma non sostituisce il progetto di migrazione verso una major più recente. L’azienda deve verificare estensioni, query, procedure, collations e dipendenze prima di scegliere il target.

È lo stesso principio valido per il ritiro dei servizi software aziendali: una scadenza di supporto non si gestisce con un intervento all’ultimo minuto, ma con inventario, test e piano di transizione.

Backup e disponibilità non sono la stessa cosa

Multi-AZ, read replica e snapshot rispondono a esigenze diverse. La replica migliora disponibilità o capacità di lettura, ma replica anche molte modifiche indesiderate. Lo snapshot permette il ripristino, ma richiede tempo e una nuova istanza. Prima dell’upgrade è quindi utile rileggere le domande che verificano se il ripristino aziendale funzionerà davvero e misurare un restore completo, non soltanto controllare che il backup risulti “verde”.

FAQ su Amazon RDS, MariaDB e PQ-TLS

Le nuove versioni attivano automaticamente il post-quantum TLS?

No. AWS annuncia il supporto allo scambio chiavi PQ-TLS, ma l’uso effettivo dipende dalla configurazione e dalla compatibilità dei client. Va verificato su connessioni reali.

Un minor upgrade è sempre senza interruzioni?

No. AWS specifica che gli upgrade del motore richiedono downtime. La durata varia in base a dimensioni e configurazione; Blue/Green può ridurre l’impatto ma richiede comunque test e switchover.

Posso tornare alla versione precedente dopo l’upgrade?

Non con un downgrade diretto. Occorre ripristinare uno snapshot in una nuova istanza e gestire dati, endpoint e riconnessione dell’applicazione.

Conviene abilitare gli aggiornamenti minor automatici?

Può essere utile, soprattutto su molte istanze, se esistono test preventivi, manutenzione pianificata e monitoraggio. Per database critici è prudente adottare un rollout progressivo.

Che cosa deve fare chi usa ancora MariaDB 10.6?

Applicare gli aggiornamenti necessari e, parallelamente, pianificare il passaggio a una major supportata: secondo la documentazione AWS il supporto standard RDS per MariaDB 10.6 termina a novembre 2026.

Conclusione

Le nuove minor release MariaDB su Amazon RDS portano correzioni e una capacità crittografica interessante, ma il risultato dipende dall’intera catena: motore, driver, configurazione TLS, replica, backup e procedure operative. La decisione più solida è trattare l’upgrade come un change applicativo completo, con test ripetibili e rollback provato.

Fonti ufficiali