Hybrid Cloud kann eine großartige Möglichkeit sein, Ihre bestehenden On-Prem-Bereitstellungen flexibler zu gestalten. Wie wir in mehreren Blogs besprochen haben, kann die Public Cloud eine großartige Ergänzung zu Ihrem eigenen Rechenzentrum sein und sicherstellen, dass Sie problemlos skalieren können, um die Last zu bewältigen, Ihre Investitionen zu reduzieren und zur Implementierung von Disaster-Recovery-Verfahren verwendet werden können. Sicherheit ist ein weiterer Aspekt, den Sie berücksichtigen müssen, wenn Sie planen, solche Systeme zu bauen. In diesem Blogbeitrag sprechen wir über einige der Sicherheitsüberlegungen für MariaDB-Bereitstellungen in der Hybrid Cloud.
Konnektivität
VPN
Der größte Teil jeder hybriden Infrastruktur ist das Netzwerk. Schließlich sprechen wir von zwei Umgebungen, lokal, On-Premises und einer Public Cloud, die verbunden werden müssen und eine Einheit bilden. Die Verbindung muss verschlüsselt werden. Wie man es angeht, es gibt zahlreiche Möglichkeiten, dies zu tun.
Eine davon wäre die Verwendung einer Lösung, die vom Cloud-Anbieter zur Verfügung gestellt wird - die meisten von ihnen verfügen über eine Art Konnektivitätsoption. Es kann AWS Direct Connect sein, wenn Sie eine Integration mit Amazon Web Services vornehmen. Wenn Sie Google Cloud verwenden möchten, werden Lösungen auf der folgenden Website diskutiert:https://cloud.google.com/hybrid-connectivity. Kurz gesagt, es gibt eine beträchtliche Anzahl verschiedener Optionen, die von der Hardware-VPN-Integration bis zur Einrichtung von BGP-Peering reichen.
Auf der anderen Seite des Spektrums haben wir Software-VPN-Lösungen. OpenVPN oder ähnliche Software kann verwendet werden, um eine sichere, verschlüsselte Netzwerkverbindung zwischen Ihrem eigenen Rechenzentrum und der öffentlichen Cloud einzurichten. In einem solchen Fall benötigen Sie eine separate Instanz, die in der Public Cloud ausgeführt wird und für den VPN-Server verwendet wird. Durch die Verwendung von Software-VPNs können Sie die Lösung auswählen, die Ihren Anforderungen und Ihrer Umgebung am besten entspricht.
Firewall
Datenbanken sollten niemals von externen Netzwerken aus zugänglich sein. Es ist von größter Bedeutung, Ihre Umgebung so aufzubauen, dass die Datenbankschicht nur von der begrenzten Anzahl von Hosts aus erreichbar ist. Was genau benötigt wird und wie das geht, entscheiden Sie selbst. Ein typisches Setup würde aus einer gesicherten Datenbankebene bestehen, auf die nur über die Proxyebene zugegriffen werden kann, und bei Bedarf sollte eine Art Jump-Host für Automatisierungs- und Verwaltungsaufgaben implementiert werden.
Anwendungsserver sollten keinen direkten Zugriff auf die Datenbank haben - das müssen sie auch nicht. Alles, was die Anwendung tun muss, ist, sich mit dem Load Balancer zu verbinden. Load Balancer sollten sich mit der Datenbank verbinden können. Ein Load Balancer wie ProxySQL ist perfekt in der Lage, die Lese-/Schreibaufteilung durchzuführen und die Lese- und Schreibvorgänge an die richtigen Datenbankknoten zu senden. Die Anwendung sollte in der Lage sein, eine Verbindung zu ProxySQL herzustellen, und der Rest wird vom Proxy erledigt – Datenbankauthentifizierung, Traffic-Shaping, Verteilung des Datenverkehrs auf zahlreiche Replikate, die Sie möglicherweise haben. Alle unnötigen Zugriffe sollten eingeschränkt werden. Sicherheitsgruppen, Firewalls – das sind die Tools, mit denen Sie Ihre Umgebung sichern möchten.
Kurz gesagt, der Zugriff auf die Datenbankhosts sollte nur auf den erforderlichen Ports erlaubt sein. Für MariaDB wird es natürlich ein Port sein, der für die Datenbank verwendet wird, aber bei Bedarf auch andere Ports - möglicherweise haben Sie eine Art Exporter oder Agenten installiert. Für Galera müssten Sie Ports für die Intra-Cluster-Kommunikation öffnen. Möglicherweise möchten Sie auch einen offenen Port für SSH-Verbindungen haben. Beschränken Sie idealerweise den Zugriff pro Host; nur eine begrenzte Anzahl von Hosts kann auf einen bestimmten Port zugreifen. Auf den Datenbankport kann beispielsweise von den anderen Datenbankknoten, dem lokalen Host und der Proxy-Schicht aus zugegriffen werden. Es besteht keine Notwendigkeit, es für andere Knoten offen zu halten. Ihre Datenbankknoten können sich sogar in einem separaten Subnetz befinden, wodurch die Sicherheit noch strenger ist.
Was Ports betrifft, wäre es am besten, sie von den Standardeinstellungen auf etwas anderes zu ändern. Idealerweise etwas Zufälliges. Das Ändern des SSH-Ports von 22 auf 2222 oder des MariaDB-Ports von 3306 auf 33306 kann helfen, einige der automatisierten Angriffe zu vermeiden, aber es kann immer noch herausgefunden werden, ob jemand aktiv versucht, in Ihr Netzwerk einzudringen. Wenn Sie mehr Sicherheit wünschen, können Sie einfach mit einigen zufälligen Werten fortfahren. Setzen Sie SSH auf 5762 und MariaDB auf 24359. Es ist sehr wahrscheinlich, dass niemand diese erraten kann. Stellen Sie Ihre TCP-Timeouts so ein, dass die Port-Scans sehr langwierig und teuer wären, und dies wird sicherlich Ihre Chancen erhöhen.
SSL
Zusätzlich zu VPN und Firewall sollten Sie sicherstellen, dass Ihr Datenbankverkehr mit SSL verschlüsselt ist.
Idealerweise schützen Sie beide Frontend-Verbindungen (von den Load Balancern) und die Kommunikation zwischen Ihren Datenbankknoten (sei es die Replikation oder der Intra-Cluster-Transfer in Galera-Clustern). ClusterControl kann Ihnen helfen, diese Optionen mit nur wenigen Klicks zu aktivieren.
Alles, was Sie tun müssen, ist, ClusterControl neue Zertifikate erstellen zu lassen oder eines der vorhandenen zu verwenden - Sie können Ihr eigenes Zertifikat importieren, wenn Sie möchten. Durch die Aktivierung von SSL wird sichergestellt, dass der Datenbankverkehr nicht einmal von jemandem gelesen werden kann, der sich Zugriff auf Ihr Netzwerk verschafft hat.
Datenbanksicherheit
Natürlich ist das Netzwerk nicht der einzige wichtige Sicherheitsaspekt. Ja, es ist kritisch, insbesondere im Hybrid-Cloud-Umfeld, aber es gibt auch andere sehr wichtige Aspekte. Eine davon ist die in MariaDB eingebettete Zugriffskontrolle.
Rollenbasierte Zugriffskontrolle für MariaDB
MariaDB wird mit einer Reihe von Instrumenten geliefert, um sicherzustellen, dass der Datenbankzugriff ordnungsgemäß verwaltet und eingeschränkt wird, wo immer dies erforderlich ist. Die erste Authentifizierungslinie sind Benutzer. Jeder und alles, das auf MariaDB zugreifen darf, sollte einen zugewiesenen Benutzer verwenden, um sich mit der Datenbank zu verbinden. Solche Benutzer haben ein korrektes Passwort – Sie können die Passwortvalidierung in MariaDB aktivieren, um sicherzustellen, dass die Passwörter stark genug sind. Idealerweise würden Sie den Zugriffshost des Benutzers nur auf Hostnamen oder IPs von Load Balancern beschränken – auf diese Weise sollten sich Benutzer immer mit der Datenbank verbinden. Für einige Benutzer mit Administratorrechten möchten Sie möglicherweise den Localhost-Zugriff beibehalten, falls erforderlich. Zusätzlich zur Durchsetzung der richtigen Passwortstärke können Sie das Passwort so konfigurieren, dass es innerhalb eines bestimmten Zeitraums abläuft, oder die Passwortrotation für die Benutzer erzwingen. Wie Sie sich vorstellen können, sollten Sie eine angemessene Richtlinie zur Passwortrotation implementiert haben.
Jedem Benutzer in MariaDB können mehrere Berechtigungen zugewiesen werden. Berechtigungen können auf mehreren Ebenen vergeben werden – globale Ebene, Datenbankebene, Tabellenebene oder sogar Spaltenebene. Die bewährte Methode besteht darin, den Benutzern möglichst wenige Berechtigungen zu erteilen. Wenn der Benutzer nur Zugriff auf eine bestimmte Tabelle benötigt, gewähren Sie ihm diesen einfach. Es ist nicht erforderlich, dass dieser Benutzer auf andere Tabellen zugreift, ganz zu schweigen von anderen Schemas. Sie können ziemlich detaillierte Zugriffsrechte definieren, indem Sie eine große Menge an Privilegien verwenden, die Sie Benutzern erteilen können. Es reicht von Rechten zum Lesen, Aktualisieren oder Löschen von Daten über Datenbankverwaltungsrechte bis hin zum „Super“-Recht, das es dem Benutzer ermöglicht, Aktionen wie das Verwalten der Replikationsthreads und das Umgehen der Read_only-Einstellung durchzuführen.
Darüber hinaus enthält MariaDB Rollen - um die Benutzerverwaltung zu vereinfachen, ist es möglich, Rollen mit einem bestimmten Satz gewährter Berechtigungen zu definieren und diese Rollen dann den Benutzern zuzuweisen. Solche Benutzer erben Berechtigungen in Bezug auf die Rolle, der sie zugewiesen wurden, was die Verwaltung von Berechtigungen im großen Maßstab viel einfacher macht:Anstatt die Berechtigungen für mehrere Benutzer zu ändern, können Sie sie einer bestimmten Rolle zuweisen und dann alle ihre Berechtigungen verwalten Ändern der Privilegien, die der ihnen zugewiesenen Rolle gewährt wurden.
Sie sollten auch sicherstellen, dass Sie keine bereits bestehenden Benutzer ohne zugewiesenes Passwort oder mit zu vielen Berechtigungen haben. Eine solche Sicherheitsüberprüfung sollte von Zeit zu Zeit durchgeführt werden, um sicherzustellen, dass Sie sich potenzieller Sicherheitsrisiken bewusst sind und planen können, darauf zu reagieren.
Prüfprotokoll
Wenn Ihre Datenbank mit einem Prüfprotokoll ausgestattet ist, genau wie MariaDB, sollten Sie in Betracht ziehen, es zu verwenden, um die Aktionen zu verfolgen, die in der Datenbank stattfinden. Das Prüfprotokoll hilft Ihnen dabei. Wenn es aktiviert ist, können Sie sogar die Details nachverfolgen, z. B. welcher Benutzer welche Abfrage ausgeführt hat. Wenn Sie ClusterControl verwenden, können Sie das Audit-Protokoll mit ein paar Klicks aktivieren:
Um diesen Blog zusammenzufassen, gibt es ein paar Dinge, die Sie berücksichtigen sollten, wenn Sie eine MariaDB-Bereitstellung in der Hybrid-Cloud-Umgebung entwerfen. Einige von ihnen hängen eng mit der Art und Weise zusammen, wie die Umgebung gestaltet ist, andere hängen ziemlich stark mit dem Datenbanktyp zusammen, den Sie verwenden, und die Tatsache, dass Sie Hybrid Cloud verwenden, ändert nicht wirklich viel. Was wirklich wichtig ist, ist sicherzustellen, dass Ihre Datenbank richtig geschützt ist – das ist das ultimative Ziel, egal in welcher Umgebung.
