Die wachsende Zahl von Cyberangriffen auf Open-Source-Datenbankbereitstellungen unterstreicht die schlechten Verwaltungs- und Betriebspraktiken der Branche.
Wenn uns 2016 etwas gelehrt hat, dann die Bedeutung solider Betriebspraktiken und Sicherheitsmaßnahmen bei der Bereitstellung von Open-Source-Datenbanken. Seit einigen Jahren warnen Forscher vor öffentlich zugänglichen Datenbanken – mit Schätzungen von mehreren zehntausend Servern. Wenn das Ausmaß des Problems nicht offensichtlich oder beängstigend war, dann ist es das jetzt sicherlich.
Kürzlich haben Ransomware-Gruppen innerhalb weniger Tage über 10.000 MongoDB-Datenbanken gelöscht. Auch andere Open-Source-Datenbanken (ElasticSearch, Hadoop, CouchDB) waren betroffen. Inzwischen ist die Zahl der exponierten Datenbanken auf etwa 100.000 Instanzen gestiegen.
Was hat dazu geführt? Open-Source-Datenbanken und Open-Source-Software im Allgemeinen machen einen erheblichen Teil der heutigen Online-Dienste aus. Dank der zunehmenden Nutzung agiler Entwicklungslebenszyklen ist die Cloud zur Heimat einer Vielzahl von Anwendungen geworden, die schnell bereitgestellt werden können. Viele Unternehmen nutzen die Cloud auch nicht mehr für unkritische Funktionen und verlassen sich jetzt auf die Cloud, um wertvolle Daten zu speichern. Das bedeutet, dass mehr Datenbanken in öffentlichen Clouds bereitgestellt werden, in Umgebungen, die direkt dem Internet ausgesetzt sind.
Insbesondere MongoDB ist aufgrund seiner Bequemlichkeit und Zweckmäßigkeit bei Entwicklern sehr beliebt. Aber hier ist das Problem:Das schnelle Hochfahren einer Umgebung für die Entwicklung ist nicht dasselbe wie das Einrichten für die Live-Produktion. Beide erfordern sehr unterschiedliche Fachkenntnisse. Tausende von Datenbankinstanzen waren nicht gesichert, und jeder konnte ohne spezielle Tools oder ohne Umgehung von Sicherheitsmaßnahmen Lese- und Schreibzugriff auf die Datenbanken (einschließlich sensibler Daten) erhalten. Dies ist keine Konzentrationsschwäche einiger weniger Personen, die uns hierher gebracht haben, wir stehen vor einem Problem, das weiter verbreitet ist, als sich irgendjemand vorstellen kann. Wir müssen erkennen, dass es schwierig ist, einen Mittelweg zwischen Benutzerfreundlichkeit, Bereitstellungsgeschwindigkeit und Betriebs-/Sicherheitsbereitschaft zu finden. Das wirft also die Frage auf – wie können wir gemeinsam diese Art von Problem überwinden?
Wenn wir jede einzelne Person, die MongoDB bereitstellt, zu einem Deployment Engineer ausbilden könnten, könnte dies hilfreich sein. Zumindest wird es ein gewisses Maß an Schutz geben, sodass nicht jeder durch eine offene Tür hereinspazieren kann.
Betrieb ist keine Raketenwissenschaft, aber es ist möglicherweise nicht vernünftig, von allen Entwicklern, die die Hauptbenutzer von MongoDB sind, zu erwarten, dass sie sich in vollwertige System-/Bereitstellungsingenieure verwandeln. Die IT-Branche bewegt sich in Richtung schnellerer, schlankerer Implementierungen und Bereitstellung von Services. Der Mittelweg zwischen Benutzerfreundlichkeit, Bereitstellungsgeschwindigkeit und soliden Betriebspraktiken scheint noch weiter entfernt zu sein. Automatisierung könnte genau das sein, was uns hilft, diesen Mittelweg zu finden.
Multiplenines Become a MongoDB DBA – Bringing MongoDB to ProductionErfahren Sie, was Sie wissen müssen, um MongoDBDownload for Free bereitzustellen, zu überwachen, zu verwalten und zu skalierenDatenbankkonfigurationen, die für die Produktion geeignet sind, sind in der Regel etwas komplexer, aber wenn sie einmal entworfen wurden, können sie viele Male mit minimalen Abweichungen dupliziert werden.
Die Automatisierung kann auf die anfängliche Bereitstellung und Konfiguration sowie auf laufendes Patchen, Backups, Anomalieerkennung und andere Wartungsaktivitäten angewendet werden. Dies ist die Basis für unsere eigene Automatisierungsplattform für MongoDB, ClusterControl. Ein gut bereitgestelltes und verwaltetes System kann das Betriebsrisiko mindern und hätte mit Sicherheit verhindert, dass diese Tausende von Datenbanken gehackt werden.
