Hur MongoDB Databas Automation förbättrar säkerheten

Det växande antalet cyberattacker mot databaser med öppen källkod framhäver branschens dåliga administrativa och operativa rutiner.

Om 2016 lärde oss något så var det vikten av sunda operativa rutiner och säkerhetsåtgärder i databaser med öppen källkod. Under flera år hade forskare varnat för offentligt exponerade databaser – med uppskattningar som sträckte sig i tiotusentals servrar. Om omfattningen av problemet inte hade varit uppenbar eller skrämmande, ja det är det säkert nu.

Nyligen raderade ransomware-grupper över 10 000 MongoDB-databaser inom bara några dagar. Andra databaser med öppen källkod (ElasticSearch, Hadoop, CouchDB) drabbades också. Under tiden har antalet exponerade databaser ökat till cirka 100 000 instanser.

Vad har lett till detta? Databaser med öppen källkod, och programvara med öppen källkod i allmänhet, driver en betydande del av dagens onlinetjänster. Tack vare den ökade användningen av agila utvecklingslivscykler har molnet blivit hem för en mängd olika applikationer som snabbt implementeras. Många företag har också gått längre än att använda molnet för icke-kritiska funktioner och förlitar sig nu på molnet för att lagra värdefull data. Detta innebär att fler databaser distribueras i offentliga moln, i miljöer som är direkt exponerade för Internet.

MongoDB i synnerhet är mycket populär bland utvecklare på grund av dess bekvämlighet och ändamålsenlighet. Men här är problemet - att snabbt skapa en miljö för utveckling är inte samma sak som att ställa upp för liveproduktion. De kräver båda väldigt olika kompetensnivåer. Tusentals databasinstanser säkrades inte och vem som helst kunde få läs- och skrivåtkomst till databaserna (inklusive eventuell känslig data) utan några speciella verktyg eller utan att behöva kringgå några säkerhetsåtgärder. Detta är inte en koncentrationsförlust från ett fåtal individer som fick oss hit, vi står inför ett problem som är mer utbrett än någon kunde föreställa sig. Vi måste inse att det är svårt att hitta mellanvägen mellan användarvänlighet, utbyggnadshastighet och operativ/säkerhetsberedskap. Så detta väcker frågan - hur kan vi kollektivt komma bortom denna typ av problem?

Om vi ​​kunde utbilda varje enskild individ som distribuerar MongoDB till en driftsättningsingenjör, kan det hjälpa. Åtminstone kommer det att finnas en viss nivå av skydd så att inte vem som helst kan gå in genom en öppen dörr.

Operations är ingen raketvetenskap, men det kanske inte är rimligt att förvänta sig att alla utvecklare, som är de primära användarna av MongoDB, ska förvandlas till fullfjädrade system-/distributionsingenjörer. IT-branschen går mot snabbare, smidigare implementeringar och distribution av tjänster. Mellanvägen mellan användarvänlighet, implementeringshastighet och sunda operativa rutiner kan tyckas ännu längre bort. Automatisering kanske bara är det som hjälper oss att hitta den mellanvägen.

Databaskonfigurationer som är lämpliga för produktion tenderar att vara lite mer komplexa, men när de väl är designade kan de dupliceras många gånger med minimal variation.

Automatisering kan tillämpas på initial provisionering och konfiguration, såväl som pågående patchning, säkerhetskopiering, avvikelsedetektering och andra underhållsaktiviteter. Detta är grunden för vår egen automationsplattform för MongoDB, ClusterControl. Ett väldisponerat och hanterat system kan minska operativa risker och skulle säkert ha förhindrat att dessa tusentals databaser hackades.