Hybride cloud kan een geweldige manier zijn om flexibiliteit toe te voegen aan uw bestaande on-premises implementaties. Zoals we in verschillende blogs hebben besproken, kan public cloud een geweldige aanvulling zijn op uw eigen datacenter, zodat u gemakkelijk kunt uitschalen om de belasting aan te kunnen, uw capex kunt verminderen en kunt worden gebruikt om noodherstelprocedures te implementeren. Beveiliging is een ander aspect waar u over moet nadenken wanneer u van plan bent dergelijke systemen te bouwen. In deze blogpost zullen we het hebben over enkele van de beveiligingsoverwegingen voor hybride cloud MariaDB-implementaties.
Connectiviteit
VPN
Het grootste deel van elke hybride infrastructuur is het netwerk. We hebben het immers over twee omgevingen, lokaal, on-premise en een public cloud, die met elkaar verbonden moeten zijn en één geheel moeten vormen. De verbinding moet versleuteld zijn. Hoe je het aanpakt, er zijn talloze manieren om dit te doen.
Een daarvan zou zijn om een oplossing te gebruiken die beschikbaar is gesteld door de cloudprovider - de meeste hebben een of andere connectiviteitsoptie. Het kan AWS Direct Connect zijn als u toevallig integreert met Amazon Web Services. Als u van plan bent om Google Cloud te gebruiken, worden oplossingen besproken op de volgende website:https://cloud.google.com/hybrid-connectivity. Kortom, er zijn een aanzienlijk aantal verschillende opties die variëren van hardware VPN-integratie tot het instellen van BGP-peering.
Aan de andere kant van het spectrum hebben we software-VPN-oplossingen. OpenVPN of vergelijkbare software kan worden gebruikt om een veilige, versleutelde netwerkverbinding op te zetten tussen uw eigen datacenter en de public cloud. In een dergelijk geval zou u een aparte instantie nodig hebben die in de openbare cloud wordt uitgevoerd en die voor de VPN-server wordt gebruikt. Door software-VPN's te gebruiken, kunt u de oplossing kiezen die het beste bij uw vereisten past en het beste bij uw omgeving past.
Firewall
Databases mogen nooit toegankelijk zijn vanaf externe netwerken. Het is van het grootste belang om uw omgeving zo te bouwen dat de databaselaag alleen bereikbaar is vanaf een beperkt aantal hosts. Wat er precies nodig is en hoe je dat doet, bepaal je zelf. Een typische opstelling zou bestaan uit een beveiligde databaselaag die alleen toegankelijk is vanaf de proxylaag en, indien nodig, zou een soort jumphost moeten worden geïmplementeerd indien nodig voor automatiserings- en beheertaken.
Applicatieservers zouden geen directe toegang tot de database moeten hebben - dat is ook niet nodig. Het enige dat de toepassing hoeft te doen, is verbinding maken met de load balancer. Load balancers moeten verbinding kunnen maken met de database. Een load balancer zoals ProxySQL is perfect in staat om de lees/schrijf-splitsing uit te voeren en de lees- en schrijfbewerkingen naar de juiste databaseknooppunten te sturen. De toepassing moet verbinding kunnen maken met de ProxySQL en de rest wordt afgehandeld door de proxy - database-authenticatie, verkeersvorming, het distribueren van het verkeer over talloze replica's die u mogelijk hebt. Alle onnodige toegang moet worden beperkt. Beveiligingsgroepen, firewalls - dit zijn de tools die u wilt gebruiken om uw omgeving te beveiligen.
Kortom, toegang tot de database-hosts zou alleen op de vereiste poorten moeten worden toegestaan. Voor MariaDB zal het natuurlijk een poort zijn die voor de database wordt gebruikt, maar indien nodig ook andere poorten - je hebt misschien een soort van exporteurs of agenten geïnstalleerd. Voor Galera zou u poorten moeten openen voor intra-clustercommunicatie. Mogelijk wilt u ook een open poort hebben voor SSH-verbindingen. Beperk in het ideale geval de toegang per host; slechts een beperkt aantal hosts heeft toegang tot een bepaalde poort. De databasepoort kan bijvoorbeeld toegankelijk zijn vanuit de andere databaseknooppunten, localhost en proxylaag. Het is niet nodig om het open te houden voor andere knooppunten. Uw databaseknooppunten kunnen zich zelfs op een apart subnet bevinden, waardoor de beveiliging nog strenger is.
Wat betreft poorten, zou het beste zijn om ze van de standaardinstellingen naar iets anders te wijzigen. Idealiter iets willekeurigs. Het wijzigen van de SSH-poort van 22 naar 2222 of de MariaDB-poort van 3306 naar 33306 kan helpen om enkele van de geautomatiseerde aanvallen te voorkomen, maar het kan nog steeds worden uitgezocht of iemand actief op zoek is naar toegang tot uw netwerk. Als u een betere beveiliging wilt, kunt u gewoon doorgaan met enkele willekeurige waarden. Zet SSH op 5762 en MariaDB op 24359. Het is vrij waarschijnlijk dat niemand die kan raden. Stel uw TCP-time-outs zo in dat de poortscans erg lang en duur zouden zijn en dit zal uw kansen zeker vergroten.
SSL
Naast VPN en firewall, moet u ervoor zorgen dat uw databaseverkeer wordt versleuteld met SSL.
Idealiter beschermt u zowel frontend-verbindingen (tegen de load balancers) als de communicatie tussen uw databaseknooppunten (of het nu gaat om replicatie of de intra-clusteroverdracht in Galera-clusters). ClusterControl kan u helpen om deze opties met slechts een paar klikken in te schakelen.
Het enige wat u hoeft te doen is ClusterControl nieuwe certificaten te laten maken of een van de bestaande te laten gebruiken - u kunt uw eigen certificaat importeren als u dat wilt. Als SSL is ingeschakeld, is het databaseverkeer zelfs niet leesbaar voor iemand die toegang heeft gekregen tot uw netwerk.
Databasebeveiliging
Natuurlijk is het netwerk niet het enige belangrijke aspect van beveiliging. Ja, het is van cruciaal belang, vooral in de hybride cloudomgeving, maar er zijn ook andere zeer belangrijke aspecten. Een daarvan is de toegangscontrole die is ingebed in MariaDB.
Op rollen gebaseerde toegangscontrole voor MariaDB
MariaDB wordt geleverd met een set instrumenten om ervoor te zorgen dat de toegang tot de database goed wordt beheerd en beperkt waar dat nodig is. De eerste regel van authenticatie zijn gebruikers. Iedereen en alles dat toegang heeft tot MariaDB, moet een toegewezen gebruiker gebruiken om verbinding te maken met de database. Dergelijke gebruikers hebben een correct wachtwoord - u kunt de wachtwoordvalidatie inschakelen in MariaDB om ervoor te zorgen dat de wachtwoorden sterk genoeg zijn. In het ideale geval zou u de toegangshost van de gebruiker alleen beperken tot hostnamen of IP's van load balancers - dit zou altijd de manier moeten zijn waarop gebruikers verbinding maken met de database. Voor sommige gebruikers met beheerdersrechten wilt u desgewenst de toegang tot localhost behouden. Naast het afdwingen van de juiste wachtwoordsterkte, kunt u het wachtwoord zo configureren dat het binnen een bepaalde periode verloopt of wachtwoordrotatie op de gebruikers afdwingen. Zoals u zich kunt voorstellen, is een goed beleid voor wachtwoordrotatie iets dat u wilt implementeren.
Aan elke gebruiker in MariaDB kunnen meerdere rechten worden toegewezen. Privileges kunnen op verschillende niveaus worden toegekend:globaal, databaseniveau, tabelniveau of zelfs kolomniveau. Het beste is om een zo beperkt mogelijke set rechten aan de gebruikers te verlenen. Als de gebruiker alleen toegang tot een bepaalde tabel nodig heeft, geef hem dat dan. Het is voor die gebruiker niet nodig om toegang te krijgen tot andere tabellen, om nog maar te zwijgen van andere schema's. U kunt vrij gedetailleerde toegangsrechten definiëren met behulp van een groot aantal privileges die u aan gebruikers kunt verlenen. Het varieert van rechten om gegevens te lezen, bij te werken of te verwijderen via databasebeheerprivileges tot het "super"-privilege waarmee de gebruiker acties kan uitvoeren zoals het beheren van de replicatiethreads en het omzeilen van de read_only-instelling.
Bovendien wordt MariaDB geleverd met rollen - om het gebruikersbeheer gemakkelijker te maken, is het mogelijk om rollen te definiëren met een bepaalde set verleende privileges en deze rollen vervolgens toe te wijzen aan de gebruikers. Dergelijke gebruikers zullen subsidies erven die verband houden met de rol waaraan het is toegewezen, waardoor het veel gemakkelijker wordt om subsidies op grote schaal te beheren:in plaats van de subsidies voor meerdere gebruikers te wijzigen, kunt u ze aan één specifieke rol toewijzen en vervolgens al hun rechten beheren door de privileges wijzigen die zijn toegekend aan de rol waaraan ze zijn toegewezen.
Je moet er ook voor zorgen dat je geen bestaande gebruikers hebt zonder een toegewezen wachtwoord of met een te grote set rechten. Een dergelijke beveiligingsaudit moet van tijd tot tijd worden uitgevoerd om ervoor te zorgen dat u op de hoogte bent van mogelijke beveiligingsrisico's en dat u kunt plannen om ernaar te handelen.
Auditlogboek
Als je database wordt geleverd met een audit log, zoals MariaDB doet, zou je moeten overwegen om het te gebruiken om de acties die in de database plaatsvinden te volgen. Het auditlogboek helpt u daarbij. Als het is ingeschakeld, kunt u zelfs de details volgen, zoals welke gebruiker welke zoekopdracht heeft uitgevoerd. Als u ClusterControl gebruikt, kunt u het auditlogboek met slechts een paar klikken inschakelen:
Om deze blog samen te vatten, zijn er een aantal dingen waar u rekening mee moet houden bij het ontwerpen van een MariaDB-implementatie in de hybride cloudomgeving. Sommige zijn strikt gerelateerd aan de manier waarop de omgeving is ontworpen, sommige zijn vrijwel gerelateerd aan het databasetype dat u gebruikt en het feit dat u hybride cloud gebruikt, verandert niet echt veel. Wat echt belangrijk is, is ervoor te zorgen dat uw database goed wordt beschermd - dat is het uiteindelijke doel, ongeacht de omgeving.