Veiligheid is tegenwoordig van het grootste belang in de hele IT. Van tijd tot tijd horen we over ransomware-aanvallen of datalekken die hun oorsprong vinden in niet-beveiligde databases of IT-infrastructuur. U vraagt zich misschien af:wat zijn de best practices bij het ontwerpen van een MySQL-omgeving, zodat u zich veilig kunt voelen over uw gegevens? Dan is deze blog iets voor jou. Houd er rekening mee dat we het onderwerp niet volledig zullen behandelen - dit zou meer in een whitepaper passen dan in een blog. We zullen ons best doen om de belangrijkste aspecten van het beveiligen van uw MySQL-database te noemen. Het idee achter deze blog is dat de lezer weet wat hij of zij niet weet en helpt bij het identificeren van de onderwerpen en trefwoorden voor verder onderzoek. We zullen het illustreren met schermafbeeldingen van ons product, ClusterControl, dat wordt geleverd met een uitgebreide reeks functies, waaronder enkele over databasebeveiliging.
Netwerk
Allereerst moeten we MySQL ergens implementeren. Of het nu een standalone instance is, een primaire replica asynchrone replicatie of een van de meer geavanceerde, synchrone replicatietopologieën zoals Galera of InnoDB Cluster. Wat het ook is, het moet op netwerkniveau worden beschermd. Database bevat de gegevens, die vrij algemeen het meest waardevolle bezit van een hele organisatie zijn.
De toegang beveiligen
Database-instanties mogen zich nooit op het openbare netwerk bevinden. Netwerksegmenten waarin databases zijn geconfigureerd, mogen alleen toegankelijk zijn vanuit een beperkt aantal andere netwerken. De vuistregel is:moet een bepaald knooppunt toegang hebben tot het databasenetwerk? Als het antwoord nee is, moeten de netwerken worden gescheiden.
Natuurlijk hangt het allemaal af van de exacte setup, maar in de meest voorkomende gevallen, waar je applicatie-, proxy-, cache- en databaselagen hebt, zou de meest typische setup zijn dat alleen de proxy in staat zou moeten zijn om toegang te krijgen tot de databank. Alle andere entiteiten moeten zo worden geconfigureerd dat ze alleen via de proxylaag toegang krijgen tot de database. Dit ontwerp is in veel opzichten goed. Naast de verhoogde beveiliging helpt het ook om de complexiteit van de databaselaag voor de toepassing te verbergen.
De proxylaag moet de databasetopologie volgen en de fouten in de databaseknooppunten en topologiewijzigingen afhandelen. Toepassing, die verbinding maakt met de proxylaag, moet altijd een werkend databaseknooppunt kunnen bereiken dat relevant is voor het type verzoek. Hetzelfde geldt voor de cachelaag. Het kan worden geïmplementeerd in de proxylaag. Sommige proxy's, zoals ProxySQL, staan cacheverzoeken binnen de proxy toe, maar als het een aparte laag is die is gebouwd rond, bijvoorbeeld memcache of Redis, moet deze altijd via de proxylaag contact opnemen met de database.
Het enige andere type knooppunt dat mogelijk directe toegang tot de databaselaag nodig heeft, zijn beheerknooppunten - die knooppunten worden gebruikt door de operationele teams om de databases te beheren. De reden is simpel:voor sommige onderhoudstaken kan directe toegang tot de databases nodig zijn. Dit kunnen scripts voor taakautomatisering zijn, Ansible-playbooks over de hele databasevloot of andere taken. In dat geval moeten er uiteraard beveiligingsmaatregelen worden getroffen om ervoor te zorgen dat alleen de mensen die toegang hebben, kunnen inloggen op een dergelijk beheerknooppunt.
Een ander mogelijk type knooppunt (hoewel daarvoor ook beheerknooppunten kunnen worden gebruikt) waarvoor toegang tot de database nodig kan zijn, zijn knooppunten die betrokken zijn bij het verzamelen van metrische gegevens en deze aan de gebruikers presenteren - we hebben het hier over monitoring en waarschuwingsactiviteiten.
VPN
Voor elke soort databaselaag die zich over meerdere datacenters uitstrekt, moet u overwegen VPN te gebruiken om ze te verbinden. Open, niet-versleutelde verbindingen via een WAN-netwerk is iets dat nooit zou mogen gebeuren. Zelfs het instellen van de SSL-codering is niet de beste optie, omdat hiervoor toegang moet worden geopend tussen de databaselaag en het WAN - SSL-verbindingen tussen databaseknooppunten vereisen dat ze rechtstreeks verbinding kunnen maken. VPN lost dit probleem op door een tussenpersoon toe te voegen die een veilige manier creëert om segmenten van het databaselaagnetwerk met elkaar te verbinden.
VPN zou ook verplicht moeten zijn voor elke vorm van gebruikerstoegang tot het netwerk van de organisatie, aangezien het een veilige verbinding tussen een werkstation en het productienetwerk implementeert.
Firewall
Natuurlijk moeten we bij het beveiligen van het netwerk overwegen om de firewall te gebruiken. Over het algemeen zou elk databaseknooppunt alleen verbindingen moeten ontvangen van een gedefinieerde set bronnen - hostnamen en poorten. Zelfs de "vereiste" netwerksegmenten zouden geen volledige toegang tot het databasenetwerk moeten hebben, maar alleen tot de vereiste poorten. Als de proxy alleen verbinding hoeft te maken met de databasepoort, is er geen reden om toegang te krijgen tot een andere poort op de databaseknooppunten. Houd er ook rekening mee dat u niet de standaardpoorten moet gebruiken. Het is duidelijk security by obscurity - de poort is tenslotte ergens open, maar het helpt om op zijn minst enkele van de beveiligingsinbreuken die geautomatiseerde scripts gebruiken, aan te pakken. Het zal iemand die vastbesloten is om toegang te krijgen niet voorkomen, maar het kan hem vertragen (in combinatie met poortscandetectie en anti-scanmaatregelen) terwijl geautomatiseerde aanvallen niet slagen.
Databasebeveiliging
Netwerk is de eerste verdedigingslinie, er zijn andere beveiligingsmaatregelen en goede praktijken die u kunt gebruiken om uw beveiliging nog verder te verbeteren. Sommige kunnen in de database zelf worden geïmplementeerd.
Gebruikers en hosts
Databases zelf kunnen worden gebruikt om toegangscontrole en beperkingen te implementeren. Om te beginnen kunt u op host gebaseerde toegangscontrole implementeren, waardoor wordt voorkomen dat andere hosts dan de korte lijst met knooppunten inloggen op de database. Natuurlijk, als je een firewall hebt gebruikt om de toegang te beperken, klinkt dit misschien als een duplicaat, maar het is nog steeds een goed idee om de toegang tot de database zelf te beperken - je weet nooit wanneer een firewall per ongeluk wordt uitgeschakeld. In zo'n geval heb je nog steeds een tweede beschermingslaag.
Wat u hier wilt implementeren is een lijst met databasegebruikers en hosts die toegang hebben tot de database. Hoogstwaarschijnlijk is wat u uiteindelijk zou moeten hebben, een of meer door de gebruiker verleende toegang van hosts die zich in de proxylaag bevinden. Hoe gedetailleerd uw toegangscontrole is, hangt af van het databasesysteem dat u heeft. MySQL staat bijvoorbeeld geen gedetailleerde controle over de netwerkmaskers toe - het gebruikt gewoon /32, /24, /16 of /8. In PostgreSQL daarentegen kunt u elk soort netwerkmasker gebruiken.
Subsidies
Als dit is wat uw database toestaat, moet elk van de gebruikers een gedefinieerde reeks toewijzingen hebben - ervoor zorgend dat de privileges die aan hen zijn toegewezen de minimale zijn die de gebruiker nodig heeft om de acties uit te voeren die hij moet doen . Databasesystemen kunnen verschillende set privileges en verschillende niveaus hebben. Meestal hebben we verschillende niveaus van privileges - globaal, van invloed op de hele databaseserver, schemaniveau - een bepaalde gebruiker kan verschillende privileges hebben die zijn toegewezen aan verschillende schema's. U kunt privileges hebben op tabel- of zelfs kolomniveau. Zoals we eerder vermeldden, is het doel om de minimale set privileges voor elke gebruiker te creëren. U wilt waarschijnlijk ten minste één gebruiker met hoge privileges hebben - deze zou worden gebruikt om de database te beheren. Een dergelijke gebruiker moet strikt worden beperkt als het gaat om connectiviteit. Het mag niet (en in feite geen van beide gebruikers) worden toegestaan om vanaf elke locatie verbinding te maken - het moet een localhost zijn, of een bepaald beheerknooppunt, gewijd aan het uitvoeren van bewerkingen op de database.
Wachtwoordbeheer
Elke gebruiker in de database zou een wachtwoord moeten hebben. Dit is een goed idee. Het wachtwoord moet worden opgeslagen in de vorm van een hash. U moet ervoor zorgen dat u voor het opslaan van de wachtwoorden het veiligste hash-algoritme gebruikt dat uw database te bieden heeft. Wachtwoorden mogen niet gemakkelijk te raden zijn en mogen niet kwetsbaar zijn voor de woordenboekaanval. Sommige databasesystemen, zoals MySQL, stellen u in staat om nauwkeurig te definiëren aan welke vereisten uw wachtwoorden moeten voldoen om ze te kunnen gebruiken. Kleine letters en hoofdletters, cijfers, speciale tekens, lengte van het wachtwoord - het is allemaal belangrijk en als je een bepaald beleid rond de wachtwoordsterkte kunt afdwingen, moet je dat doen. Een ander belangrijk onderdeel is wachtwoordrotatie. Wachtwoorden mogen niet voor eens en voor de hele levensduur van de database worden gemaakt, u moet een beleid voor wachtwoordrotatie hebben. Nogmaals, sommige databasesystemen kunnen dit voor u afdwingen. Gebruikers met beheerdersrechten kunnen mogelijk nieuwe gebruikersaccounts maken waarbij wachtwoordrotatie wordt afgedwongen. Hij kan mogelijk ook wachtwoordrotatie afdwingen voor een bepaalde gebruiker.
Auditlogboeken
Sommige databasesystemen bieden controlelogboeken - het idee is om zoveel mogelijk informatie over de activiteit in de database te verzamelen. Wie en wanneer deed wat? Welke query is uitgevoerd, door wie? Wie heeft geprobeerd in te loggen, maar is niet gelukt? Van welke gastheer? In het ideale geval zouden logboeken met dergelijke informatie buiten de databaseknooppunten worden opgeslagen. U kunt ze streamen naar uw centrale logserver voor bewaring, verdere verwerking en betere zoekmogelijkheden.
SQL-beveiliging
We noemden gebruikers en hosts, maar de aanval kan ook vanuit een andere bron plaatsvinden. Als uw toepassing niet goed is beveiligd en de invoer niet correct is gevalideerd, kunt u te maken krijgen met aanvallen die afkomstig zijn van uw website. We hebben het hier over SQL-injectie. In dergelijke gevallen zijn firewalls niet echt nuttig, aangezien de query afkomstig is van een geldige bron (uw webserver en vervolgens proxy-knooppunt). Het toewijzen van subsidies kan misschien helpen om sommige van dit soort aanvallen te voorkomen, maar het is geen ideale oplossing - in de meeste gevallen heeft uw toepassing immers een gebruiker nodig die de inhoud van de database kan verwijderen of wijzigen. Een dergelijke gebruiker kan, wanneer deze wordt misbruikt, worden gebruikt om schade aan te richten. Er zijn verschillende manieren waarop u kunt proberen de traktatie tegen te gaan.
SQL-firewall
De eenvoudigste manier om dit te doen is door een SQL-firewall te implementeren. Dit kan op verschillende niveaus en op verschillende plaatsen. Een van de mogelijkheden is om daarvoor load balancers te gebruiken. Sommigen van hen hebben deze functionaliteit die op zijn minst gemakkelijk haalbaar is als ze nog niet is geïmplementeerd. Het idee erachter is om een lijst met query's op te bouwen die uw toepassing uitvoert en vervolgens uw proxy te configureren om alleen dit soort verkeer door te geven. Het is niet ideaal omdat je het op tijd moet onderhouden, nieuwe zoekopdrachten moet toevoegen en oude die niet meer worden gebruikt, moet verwijderen. Aan de andere kant zal een dergelijke reeks regels voorkomen dat een zoekopdracht die niet is geautoriseerd, de database bereikt.
SQL-injectiedetectie
Een andere mogelijke optie zou zijn om SQL-injectiedetectie in de proxylaag te implementeren. Er zijn een aantal oplossingen, waaronder ProxySQL, die kunnen worden geconfigureerd om te proberen SQL-injectie te detecteren in het verkeer dat er doorheen gaat. Het is natuurlijk allemaal gebaseerd op heuristieken, dus het kan resulteren in valse positieven, maar het kan een goede aanvulling zijn op de SQL-firewall.
In het verleden hebben we besproken hoe u SQL-firewall en SQL-injectiedetectie kunt implementeren met ProxySQL, een loadbalancer die kan worden geïmplementeerd vanuit ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Gegevensbeveiliging
Tot slot, gegevensbeveiliging. We hebben tot nu toe besproken hoe men de database kan verharden, hoe de toegang ertoe kan worden beperkt en hoe verschillende soorten aanvallen vanuit de applicatie zelf kunnen worden voorkomen. We moeten nog steeds nadenken over de bescherming van de gegevens zelf. Dit kan meerdere lagen hebben. Fysieke beveiliging - als u eigenaar bent van het datacenter, zorg er dan voor dat het goed is vergrendeld. Als u externe ISP's of cloudproviders gebruikt, zorg er dan voor dat ze over de juiste beveiligingsprotocollen beschikken als het gaat om toegang tot de hardware. Dan hebben we een server, VM of wat je ook gebruikt. Gegevens staan op schijf, lokaal opgeslagen op de server. Er worden gegevens uitgewisseld tussen de applicatie, proxy en de database. Gegevens worden overgedragen tussen databaseknooppunten door middel van replicatie. Gegevens worden offsite opgeslagen als back-ups. Deze gegevens moeten worden beschermd.
Back-ups
Back-ups moeten altijd worden versleuteld. De coderingssleutel moet zorgvuldig worden onderhouden en regelmatig worden geroteerd.
Gegevens onderweg
Gegevens die worden overgedragen, moeten worden versleuteld. Zorg ervoor dat u uw applicatie, proxylaag en database hebt geconfigureerd om SSL of TSL te gebruiken. Elke manier om de gegevens tussen de databaseknooppunten over te dragen, moet ook worden beveiligd en versleuteld. Het doel is om elke vorm van netwerksnuiven zinloos te maken.
Gegevens in rust
Eindelijk de gegevens zelf, opgeslagen op het databaseknooppunt. Het moet ook versleuteld zijn. Er zijn een aantal methoden die u kunt gebruiken bij het benaderen van dit onderwerp. Ten eerste codering op hostniveau. Het volume waarop de database zijn gegevensmap heeft, kan worden versleuteld (en ontsleuteld bij het opstarten). Databases worden ook vaak geleverd met coderingsmogelijkheden. Wat versleuteld kan worden hangt af van de exacte oplossing en het type en de versie van de database, maar in sommige gevallen zijn de mogelijkheden vrij uitgebreid. Tablespace-encryptie, log-encryptie, soms zelfs encryptie van de in-memory structuren. Als u het goed doet, is toegang tot het databaseknooppunt niet voldoende om toegang te krijgen tot de gegevens.
Conclusie
Zoals we eerder vermeldden, is deze blog niet bedoeld als een praktische gids voor databasebeveiliging, maar we hebben de meeste aspecten besproken waarmee u rekening moet houden bij het ontwerpen van uw databaseomgeving en we hopen dat u zult deze handleiding nuttig vinden.