Database di audit presso The Grid Parte 2: Osservazioni post-distribuzione

Nel post precedente di questa serie, ho parlato di come abbiamo raccolto i requisiti per questo progetto, di come abbiamo deciso quale strumento utilizzare e di come abbiamo pianificato l'implementazione per evitare interruzioni del servizio. Come promesso, questo post di follow-up si concentra sulle osservazioni post-distribuzione e sui fattori che hanno reso questa storia di successo per noi.

Dichiarazioni preparate e filtraggio della classe di comando

Il nostro progetto iniziale per questo progetto intendeva sfruttare una funzionalità nel plug-in percona che consente di filtrare gli eventi emessi per utilizzare un elenco di comandi inclusi o comandi esclusi come un modo per limitare l'ambito a ciò di cui abbiamo effettivamente bisogno per controllare.

La funzionalità si basa sul plug-in che contrassegna ogni comando sql rilevato con una classe basata su un elenco inerente a mysql e da lì decide nel livello di output se la classe di comando rilevata deve essere soppressa o emessa.

Quindi abbiamo scritto il progetto iniziale per sfruttare la funzionalità audit_log_exclude_commands per escludere tutti i comandi sql che non hanno causato scritture o modifiche ai dati di riga. Abbiamo scelto un elenco di esclusione perché ritenevamo che un elenco di inclusione comportasse il rischio di perdere qualsiasi classe di comando nell'ambito e potesse diventare un motivo per avere lacune nei nostri registri di controllo.

Tuttavia, sul primo cluster che abbiamo testato, abbiamo visto che tutti i comandi controllati venivano classificati come errori anche se era chiaro che queste istruzioni venivano eseguite correttamente e anche in caso di modifica dei dati lo stavano facendo. Abbiamo anche visto che tutte le query venivano inviate al server syslog centralizzato indipendentemente dall'elenco di esclusione che sembra correlato a quella classificazione di errore.

Ciò significava che stavamo archiviando in elasticsearch molti più eventi di quelli di cui avevamo effettivamente bisogno, il che avrà sicuramente un impatto sulla nostra capacità di analizzare e rilevare comportamenti errati in modo tempestivo. In collaborazione con il team di sicurezza, abbiamo deciso di informare Percona del problema tramite il loro bug tracker, ma anche di spostare il filtraggio basato sui comandi al livello syslog centrale.

Come tutto in ingegneria, il compromesso qui era inviare più dati attraverso il livello di rete DB e rendere più complesso il filtraggio nel livello syslog centralizzato e in cambio ciò ha reso le nostre esigenze di ridimensionamento elastico della ricerca più gestibili e la configurazione sul lato database più semplice.

Prestazione

Una delle decisioni più cruciali in questo progetto che ci ha risparmiato molte sofferenze è decidere di utilizzare la funzione rsyslog per intercettare e spedire questi log off a un server syslog centralizzato.

Ma niente è senza pro e contro.

Questa decisione ha significato che il tempo di attività di un sistema separato e l'affidabilità dello stack di rete intermedio sono diventati cruciali per fornire lo SLA di cui avevamo bisogno per dare al nostro team di audit la fiducia in questa soluzione di audit.

Per coloro che non sono disposti a fare quel compromesso e hanno bisogno di mantenere la responsabilità della persistenza dei log di controllo all'interno dello stack DB, consiglio di utilizzare il gestore FILE nel plug-in di controllo, quindi di utilizzare logstash locale per prendere i log e inoltrarli al loro sistema di analisi di scelta.

Quest'ultima scelta significa che molti più IOP del disco consumati dal processo del database e occupati dal plug-in di audit e dal logstash e significa che devi bilanciare attentamente lo spazio su disco sulle tue istanze tra i file della tabella del database, i log operativi e l'audit log dei plugin. La ponderazione delle tue opzioni dipende esclusivamente da ciò che è più facile da usare/accettabile dall'azienda, ma hai comunque delle scelte.

Nel nostro caso, la scelta di rsyslog si è rivelata la meno impattante per i nostri database più impegnati, con un picco di circa 5400 transazioni/sec, durante le normali operazioni non abbiamo riscontrato alcun impatto sulle prestazioni. Il plug-in di audit si trascinava, inviando i suoi eventi senza alcun impatto sulle prestazioni del database. Tutto perché avevamo scelto un'architettura che evitasse di consumare operazioni basate su disco lato database.

Le decisioni passate stanno dando i loro frutti

Una delle prime preoccupazioni che abbiamo avuto quando abbiamo intrapreso questo progetto è stato il suo impatto sulle prestazioni. Uno dei cluster di database nell'ambito ha visto tempi molto impegnativi e le sue applicazioni sono sensibili al ritardo, quindi dovevamo assicurarci di tenere traccia delle metriche delle prestazioni come le transazioni al secondo, l'utilizzo del disco e della CPU per confrontare i numeri dopo aver distribuito il plug-in e guarda qual è la sanzione.

È stata una felice sorpresa vedere che non abbiamo subito molte penalità nelle normali operazioni. Come accennato in precedenza, poiché abbiamo deciso di utilizzare il gestore SYSLOG, significava che normalmente non era necessario utilizzare alcuna capacità del disco locale per tenere traccia di questi eventi di controllo.

Ma non volevamo nemmeno pianificare in base ai soli tempi di "normale funzionamento".

Dovevamo anche sapere che quando rsyslog deve eseguire il fallback sui file di spool locali, questi eventi non si sommano in interruzioni del servizio che influiscono sulle interruzioni dei cluster di database più critici. Testando il comportamento dello spooling di rsyslog sotto stretta osservazione in produzione, ci siamo resi conto che gli ultimi anni di lavoro per eseguire lo shard funzionale dei nostri database ci hanno procurato il vantaggio non pianificato di molte capacità di IOP del disco di assorbire eventi come lo spooling di rsyslog su disco, quindi necessario per il nuovo invio tutti questi eventi.

Abbiamo sicuramente notato l'aumento dell'utilizzo del disco durante questi eventi, ma non ha mai portato le istanze db a uno stato critico o ha influenzato l'attività rivolta ai clienti.

Compromessi

Come tutto nell'ingegneria del software, ci sono sempre dei compromessi. In questo progetto, abbiamo considerato un metodo di consegna dei registri più affidabile e con meno possibilità di perdita di registri. Ciò comporterebbe la scrittura dei registri su disco, quindi l'utilizzo di qualcosa come logstash per importarli e inviarli alle destinazioni di analisi che il team di sicurezza può utilizzare.

Ma ciò avrebbe significato un consumo significativo di IOP del disco sul lato database che sapevamo avrebbe potuto potenzialmente influire sulla qualità del servizio delle chiamate rivolte ai clienti a questi database.

Abbiamo deciso che le nostre esigenze aziendali sarebbero state soddisfatte a sufficienza utilizzando la registrazione resiliente in rsyslog, utilizzando uno spool di dimensioni ragionevoli e utilizzando TCP per inviare gli eventi al nostro stack di monitoraggio dei log. Come tutto nella vita, niente è per sempre. E siamo consapevoli che questa decisione potrebbe dover essere rivista in futuro.

Finalmente

Questo progetto, pur comprendendo una mezza dozzina di cluster e un gran numero di istanze, è stato completato in un solo trimestre mentre il team operativo DB continuava a mantenere le luci accese in un'attività ancora in rapida crescita. Ciò non sarebbe potuto accadere senza una stretta collaborazione tra il DBE e il team di sicurezza e non senza una forte gestione del prodotto che mantenesse l'ambito limitato e noto per assicurarsi che tutti noi tenessimo gli occhi sull'obiettivo finale di rendere più sicura la nostra attività.