Il numero crescente di attacchi informatici alle implementazioni di database open source mette in evidenza le pratiche amministrative e operative scadenti del settore.
Se il 2016 ci ha insegnato qualcosa, è stata l'importanza di solide pratiche operative e misure di sicurezza nelle implementazioni di database open source. Per diversi anni, i ricercatori avevano messo in guardia sui database pubblicamente esposti, con stime che variavano in decine di migliaia di server. Se l'entità del problema non era stata evidente o spaventosa, allora lo è sicuramente adesso.
Di recente, i gruppi di ransomware hanno eliminato oltre 10.000 database MongoDB in pochi giorni. Sono stati colpiti anche altri database open source (ElasticSearch, Hadoop, CouchDB). Nel frattempo, il numero di database esposti è salito a circa 100.000 istanze.
Cosa ha portato a questo? I database open source e il software open source in generale alimentano una parte significativa degli odierni servizi online. Grazie al maggiore utilizzo di cicli di vita di sviluppo agili, il cloud è diventato la sede di una varietà di applicazioni che vengono rapidamente implementate. Molte aziende sono andate oltre l'utilizzo del cloud per funzioni non critiche e ora si affidano al cloud per l'archiviazione di dati preziosi. Ciò significa che più database vengono distribuiti nei cloud pubblici, in ambienti direttamente esposti a Internet.
MongoDB in particolare è molto popolare tra gli sviluppatori, per la sua praticità e convenienza. Ma ecco il problema:creare rapidamente un ambiente per lo sviluppo non è la stessa cosa che impostare per la produzione dal vivo. Entrambi richiedono livelli di competenza molto diversi. Migliaia di istanze di database non erano protette e chiunque poteva ottenere l'accesso in lettura e scrittura ai database (inclusi i dati sensibili) senza strumenti speciali o senza dover eludere alcuna misura di sicurezza. Questo non è un abbandono di concentrazione di pochi che ci ha portato qui, siamo di fronte a un problema più diffuso di quanto chiunque possa immaginare. Dobbiamo riconoscere che è difficile trovare una via di mezzo tra facilità d'uso, velocità di implementazione e prontezza operativa/di sicurezza. Quindi questo pone la domanda:come possiamo collettivamente superare questo tipo di problema?
Se potessimo formare ogni singolo individuo che distribuisce MongoDB in un ingegnere di distribuzione, potrebbe essere d'aiuto. Almeno, ci sarà un certo livello di protezione in modo che non tutti possano entrare da una porta aperta.
Le operazioni non sono scienza missilistica, ma potrebbe non essere ragionevole aspettarsi che tutti gli sviluppatori, che sono gli utenti principali di MongoDB, si trasformino in veri e propri ingegneri di sistemi/deployment. Il settore IT si sta muovendo verso implementazioni e implementazioni di servizi più veloci e snelle. La via di mezzo tra facilità d'uso, velocità di implementazione e buone pratiche operative potrebbe sembrare ancora più lontana. L'automazione potrebbe essere proprio ciò che ci aiuta a trovare quella via di mezzo.
Multiplenines Diventa un DBA MongoDB - Portare MongoDB in produzioneScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare MongoDBScarica gratuitamenteLe configurazioni del database adatte alla produzione tendono ad essere un po' più complesse, ma una volta progettate possono essere duplicate molte volte con variazioni minime.
L'automazione può essere applicata al provisioning e alla configurazione iniziali, nonché all'applicazione continua di patch, backup, rilevamento delle anomalie e altre attività di manutenzione. Questa è la base per la nostra piattaforma di automazione per MongoDB, ClusterControl. Un sistema ben distribuito e gestito può mitigare il rischio operativo e avrebbe sicuramente impedito che queste migliaia di database venissero violati.
