Het groeiende aantal cyberaanvallen op open source database-implementaties benadrukt de slechte administratieve en operationele praktijken van de sector.
Als 2016 ons iets heeft geleerd, dan was het het belang van goede operationele praktijken en veiligheidsmaatregelen bij open source database-implementaties. Jarenlang hadden onderzoekers gewaarschuwd voor openbaar toegankelijke databases - met schattingen variërend in de tienduizenden servers. Als de omvang van het probleem niet duidelijk of beangstigend was geweest, dan is het dat nu zeker wel.
Onlangs hebben ransomware-groepen binnen een paar dagen meer dan 10.000 MongoDB-databases verwijderd. Andere open source databases (ElasticSearch, Hadoop, CouchDB) werden ook getroffen. Ondertussen is het aantal blootgestelde databases gestegen tot ongeveer 100.000 exemplaren.
Wat heeft hiertoe geleid? Open source databases, en open source software in het algemeen, vormen de basis voor een aanzienlijk deel van de huidige online diensten. Dankzij het toegenomen gebruik van agile ontwikkelingslevenscycli, is de cloud de thuisbasis geworden van een verscheidenheid aan applicaties die snel kunnen worden geïmplementeerd. Veel bedrijven zijn ook verder gegaan dan het gebruik van de cloud voor niet-kritieke functies en vertrouwen nu op de cloud voor het opslaan van waardevolle gegevens. Dit betekent dat er meer databases worden ingezet in openbare clouds, in omgevingen die direct zijn blootgesteld aan internet.
Vooral MongoDB is erg populair onder ontwikkelaars vanwege het gemak en de doelmatigheid. Maar hier is het probleem:het snel opzetten van een omgeving voor ontwikkeling is niet hetzelfde als het opzetten voor live-productie. Ze vereisen allebei een heel ander expertiseniveau. Duizenden database-instances waren niet beveiligd en iedereen kon lees- en schrijftoegang krijgen tot de databases (inclusief eventuele gevoelige gegevens) zonder speciale tools of zonder beveiligingsmaatregelen te hoeven omzeilen. Dit is niet een gebrek aan concentratie van een paar individuen die ons hier hebben gebracht, we worden geconfronteerd met een probleem dat meer wijdverbreid is dan iemand zich kan voorstellen. We moeten erkennen dat het moeilijk te vinden is om een middenweg te vinden tussen gebruiksgemak, implementatiesnelheid en operationele/beveiligingsgereedheid. Dit roept dus de vraag op:hoe kunnen we collectief dit soort problemen te boven komen?
Als we elke persoon die MongoDB implementeert zouden kunnen opleiden tot een implementatie-engineer, zou dat misschien helpen. Er zal in ieder geval een zekere mate van bescherming zijn, zodat niet zomaar iedereen door een open deur naar binnen kan lopen.
Operations is geen rocket science, maar het is misschien niet redelijk om van alle ontwikkelaars, die de primaire gebruikers van MongoDB zijn, te verwachten dat ze volwaardige systeem-/implementatie-ingenieurs worden. De IT-industrie evolueert naar snellere, slankere implementaties en implementatie van services. De middenweg tussen gebruiksgemak, inzetsnelheid en gedegen operationele praktijken lijkt misschien nog verder weg. Automatisering is misschien wel het ding dat ons helpt die middenweg te vinden.
Multiplenines Word een MongoDB DBA - MongoDB naar productie brengenLeer over wat u moet weten om MongoDB gratis te implementeren, bewaken, beheren en schalenDatabaseconfiguraties die geschikt zijn voor productie zijn meestal wat complexer, maar als ze eenmaal zijn ontworpen, kunnen ze vele malen worden gedupliceerd met minimale variatie.
Automatisering kan worden toegepast op de initiële inrichting en configuratie, maar ook op doorlopende patching, back-ups, anomaliedetectie en andere onderhoudsactiviteiten. Dit is de basis voor ons eigen automatiseringsplatform voor MongoDB, ClusterControl. Een goed geïmplementeerd en beheerd systeem kan het operationele risico verkleinen en zou zeker hebben voorkomen dat deze duizenden databases werden gehackt.