Det stigende antal cyberangreb på open source-databaseimplementeringer fremhæver industriens dårlige administrative og operationelle praksis.
Hvis 2016 lærte os noget, var det vigtigheden af sund operationel praksis og sikkerhedsforanstaltninger i open source-databaseimplementeringer. I flere år havde forskere advaret om offentligt eksponerede databaser - med skøn, der spænder i titusindvis af servere. Hvis omfanget af problemet ikke havde været tydeligt eller skræmmende, jamen det er det helt sikkert nu.
For nylig slettede ransomware-grupper over 10.000 MongoDB-databaser inden for blot et par dage. Andre open source-databaser (ElasticSearch, Hadoop, CouchDB) blev også ramt. I mellemtiden er antallet af eksponerede databaser steget til omkring 100.000 forekomster.
Hvad har ført til dette? Open source-databaser og open source-software generelt driver en betydelig del af nutidens onlinetjenester. Takket være den øgede brug af agile udviklingslivscyklusser er skyen blevet hjemsted for en række applikationer, der hurtigt implementeres. Mange virksomheder har også bevæget sig ud over at bruge skyen til ikke-kritiske funktioner og er nu afhængige af skyen til lagring af værdifulde data. Det betyder, at flere databaser bliver implementeret i offentlige skyer, i miljøer, der er direkte udsat for internettet.
Især MongoDB er meget populær blandt udviklere på grund af dets bekvemmelighed og hensigtsmæssighed. Men her er problemet - at hurtigt opbygge et miljø til udvikling er ikke det samme som at sætte op til levende produktion. De kræver begge meget forskellige niveauer af ekspertise. Tusindvis af databaseforekomster var ikke sikret, og enhver kunne få læse- og skriveadgang til databaserne (inklusive eventuelle følsomme data) uden særlige værktøjer eller uden at skulle omgå sikkerhedsforanstaltninger. Dette er ikke et koncentrationsfald fra nogle få personer, der fik os hertil, vi står over for et problem, som er mere udbredt, end nogen kunne forestille sig. Vi er nødt til at erkende, at det er svært at finde mellemvejen mellem brugervenlighed, implementeringshastighed og operationelt/sikkerhedsberedskab. Så dette rejser spørgsmålet - hvordan kan vi i fællesskab komme ud over denne type problemer?
Hvis vi kunne træne hver enkelt person, der implementerer MongoDB, til en implementeringsingeniør, kunne det hjælpe. Der vil i det mindste være et niveau af beskyttelse, så ikke hvem som helst kan gå ind gennem en åben dør.
Operations er ikke raketvidenskab, men det er måske ikke rimeligt at forvente, at alle udviklere, som er de primære brugere af MongoDB, bliver til fuldgyldige system-/implementeringsingeniører. It-branchen bevæger sig i retning af hurtigere, mere slanke implementeringer og udrulning af tjenester. Mellemvejen mellem brugervenlighed, implementeringshastighed og sunde operationelle metoder kan virke endnu længere væk. Automatisering er måske netop den ting, der hjælper os med at finde den mellemting.
Severalnines Bliv en MongoDB DBA - Bring MongoDB to ProductionFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere MongoDBDownload gratisDatabasekonfigurationer, der er egnede til produktion, har en tendens til at være lidt mere komplekse, men når de først er designet, kan de duplikeres mange gange med minimal variation.
Automatisering kan anvendes til indledende klargøring og konfiguration, såvel som løbende patching, sikkerhedskopiering, registrering af anomalier og andre vedligeholdelsesaktiviteter. Dette er grundlaget for vores egen automatiseringsplatform for MongoDB, ClusterControl. Et godt installeret og administreret system kan mindske operationelle risici og ville helt sikkert have forhindret disse tusindvis af databaser i at blive hacket.