Säkerhet är av största vikt idag inom hela IT. Då och då hör vi om ransomware-attacker eller dataläckor som har sitt ursprung i osäkra databaser eller IT-infrastruktur. Du kanske undrar:vilka är de bästa metoderna för att utforma MySQL-miljöer så att du kan känna dig säker på dina data? I så fall är den här bloggen för dig. Tänk på att vi inte kommer att täcka ämnet fullt ut - detta skulle passa mer in i ett whitepaper än en blogg. Vi kommer att göra vårt bästa för att nämna de viktigaste aspekterna av att säkra din MySQL-databas. Tanken bakom denna blogg är att läsaren ska veta vad hon eller han inte vet och hjälpa till att identifiera ämnen och nyckelord för vidare forskning. Vi kommer att illustrera det med skärmdumpar från vår produkt, ClusterControl, som kommer med en stor uppsättning funktioner, inklusive några kring databassäkerhet.
Nätverk
Först och främst måste vi distribuera MySQL någonstans. Oavsett om det är en fristående instans, primär - replik asynkron replikering eller en av de mer avancerade, synkrona replikeringstopologierna som Galera eller InnoDB Cluster. Oavsett vad det är, måste det skyddas på nätverksnivå. Databasen innehåller data, som, ganska vanligt, är den mest värdefulla tillgången för en hel organisation.
Säker åtkomst
Databasinstanser bör aldrig finnas på det offentliga nätverket. Nätverkssegment där databaser är konfigurerade bör endast vara tillgängliga från ett begränsat antal andra nätverk. Tumregeln är – ska en given nod kunna komma åt databasnätverket? Om svaret är nej bör nätverken separeras.
Självklart beror allt på den exakta inställningen men i de vanligaste fallen, där du har applikations-, proxy-, cache- och databaslager, skulle den vanligaste inställningen vara att endast proxyn ska kunna för att komma åt databasen. Alla andra enheter bör konfigureras på ett sätt så att de endast kommer åt databasen via proxylager. Denna design är bra på många sätt. Utöver den ökade säkerheten hjälper det också till att dölja komplexiteten i databasnivån från applikationen.
Proxylagret bör följa databastopologin och bör hantera databasnodfel och topologiändringar. Applikationen, som ansluter till proxylagret, ska alltid kunna nå ut till en fungerande databasnod som är relevant för typen av begäran. Detsamma är med cachelagret. Det kan implementeras i proxylagret, vissa proxyservrar som ProxySQL tillåter cacheförfrågningar inom proxyn men om det är ett separat lager byggt kring till exempel memcache eller Redis, bör det alltid nå ut till databasen via proxylager.
Den ytterligare typen av noder som kan behöva ha direkt åtkomst till databaslagret är hanteringsnoder - de som används av de operativa teamen för att hantera databaserna. Anledningen är enkel:vissa av underhållsuppgifterna kan kräva direktåtkomst till databaserna. Det kan vara uppgiftsautomatiseringsskript, rullande Ansible-spelböcker över hela databasflottan eller andra uppgifter. I så fall bör självklart säkerhetsåtgärder vara på plats för att säkerställa att endast de personer som har åtkomst kan logga in på en sådan hanteringsnod.
En annan möjlig typ av noder (även om hanteringsnoder också kan användas för det) som kan kräva tillgång till databasen är noder som är involverade i att samla in mätvärden och presentera dem för användarna - vi pratar här om övervakning och varningsaktiviteter.
VPN
För alla typer av databasnivåer som spänner över flera datacenter bör du överväga att använda VPN för att ansluta dem. Öppna, okrypterade anslutningar över WAN-nätverk är något som aldrig bör hända. Även att ställa in SSL-krypteringen är inte det bästa alternativet eftersom det skulle kräva öppning av åtkomst mellan databasnivån och WAN - SSL-anslutningar mellan databasnoder kräver att de kan ansluta direkt. VPN löser detta problem genom att lägga till en mellanhand som skapar ett säkert sätt att ansluta segment av databasnätverket.
VPN bör också vara obligatoriskt för alla typer av användaråtkomst till organisationens nätverk eftersom det implementerar säker anslutning mellan en arbetsstation och produktionsnätverket.
Brandvägg
När vi säkrar nätverket bör vi naturligtvis överväga att använda brandväggen. Generellt sett bör varje databasnod endast ta emot anslutningar från en definierad uppsättning källor - värdnamn och portar. Även de "krävda" nätverkssegmenten bör inte ha full tillgång till databasnätverket utan endast till de portar som krävs. Om proxyn bara behöver ansluta till databasporten så finns det ingen anledning att den ska kunna komma åt någon annan port på databasnoderna. Observera också att du inte bör använda standardportarna. Det är, uppenbarligen, säkerhet i dunkel - trots allt är porten öppen någonstans, men det hjälper till att hantera åtminstone några av de säkerhetsintrång som använder automatiserade skript. Det kommer inte att hindra någon som är fast besluten att få åtkomst men kan sakta ner honom (i kombination med portskanningsdetektering och antiskanningsåtgärder) samtidigt som det förhindrar att automatiserade attacker lyckas.
Databassäkerhet
Nätverk är den första försvarslinjen, det finns andra säkerhetsåtgärder och god praxis som du kan använda för att förbättra din säkerhet ytterligare. Vissa av dem kan implementeras på själva databasen.
Användare och värdar
Databaserna i sig kan användas för att implementera åtkomstkontroll och begränsningar. Till att börja med kan du implementera värdbaserad åtkomstkontroll, vilket förhindrar att andra värdar än den korta listan med noder loggar in i databasen. Naturligtvis, om du använde en brandvägg för att begränsa åtkomsten kan detta låta som en dubblett, men det är fortfarande en bra idé att begränsa åtkomsten till själva databasen - du vet aldrig när, av en slump, en brandvägg kommer att stängas av. I ett sådant fall har du fortfarande ett andra lager av skydd.
Vad du vill implementera här är en lista över databasanvändare och värdar som får åtkomst till databasen. Det du troligtvis borde ha är en eller flera användarbeviljade åtkomster från värdar som finns i proxylagret. Hur detaljerad åtkomstkontroll du kan ha beror på vilket databassystem du har. MySQL, till exempel, tillåter inte detaljerad kontroll över nätverksmaskerna - den använder bara /32, /24, /16 eller /8. I PostgreSQL, å andra sidan, kan du använda vilken typ av nätverksmask som helst.
Bidrag
Om detta är vad din databas tillåter, bör var och en av användarna ha en definierad uppsättning anslag - vilket säkerställer att de privilegier som tilldelats dem är de minimala som krävs för att användaren ska kunna utföra de åtgärder han måste göra . Databassystem kan ha olika uppsättning privilegier och olika nivåer av dem. Vanligtvis har vi flera nivåer av privilegier - globala, som påverkar hela databasservern, schemanivå - en given användare kan ha olika privilegier tilldelade olika scheman. Du kan ha privilegier på tabell- eller till och med kolumnnivå. Som vi nämnde tidigare är målet att skapa den minimala uppsättningen privilegier för varje användare. Du kommer förmodligen att vilja ha minst en användare med höga privilegier - den skulle användas för att hantera databasen. Sådana användare bör vara strikt begränsade när det gäller anslutning. Det bör inte (och i själva verket inte heller någon av användarna) tillåtas att ansluta från vilken plats som helst - det bör antingen vara en lokal värd, eller någon speciell hanteringsnod, dedikerad till att utföra operationer på databasen.
Lösenordshantering
Varje användare i databasen bör ha ett lösenord definierat. Detta är en no-brainer. Lösenordet bör lagras i form av en hash. Du bör se till att för att lagra lösenorden använder du den säkraste hashalgoritmen som din databas har att erbjuda. Lösenord ska inte vara lätta att gissa och de ska inte vara sårbara för ordboksattacken. Vissa databassystem, som MySQL, tillåter dig att exakt definiera de krav som dina lösenord måste uppfylla för att de ska kunna användas. Små och stora bokstäver, siffror, specialtecken, längden på lösenordet - allt är viktigt och om du kan tillämpa vissa policyer kring lösenordsstyrkan bör du göra det. En annan viktig bit är lösenordsrotation. Lösenord bör inte skapas en gång för alla databasens livslängd, du bör ha en policy för lösenordsrotation. Återigen, några av databassystemen kan genomdriva detta åt dig. Administrativ användare kanske kan skapa nya användarkonton med lösenordsrotation påtvingad. Han kanske också kan tvinga fram lösenordsrotation för en given användare.
Revisionsloggar
En del av databassystemen erbjuder revisionsloggar - tanken är att samla in så mycket information om aktiviteten i databasen som möjligt. Vem och när gjorde vad? Vilken fråga har utförts, av vem? Vem försökte logga in men misslyckades? Från vilken värd? Helst skulle loggar som innehåller sådan information lagras utanför databasnoderna. Du kan strömma dem till din centrala loggserver för förvaring, vidare bearbetning och bättre sökmöjligheter.
SQL-säkerhet
Vi nämnde användare och värdar men attacken kan också ske från en annan källa. Om din applikation inte är ordentligt säkrad och inmatningen inte är korrekt validerad, kan du utsättas för attacker som kommer från din webbplats. Vi pratar här om SQL-injektion. I sådana fall är brandväggar inte riktigt användbara med tanke på att frågan kommer från en giltig källa (din webbserver och sedan proxynod). Att tilldela bidrag kan faktiskt hjälpa till att förhindra en del av denna typ av attack, men det är inte en idealisk lösning - trots allt kommer din ansökan, i de flesta fall, att behöva en användare som kan ta bort eller ändra innehållet i databasen. En sådan användare kan, när den utnyttjas, användas för att göra skada. Det finns flera sätt på vilka du kan försöka motverka godbiten.
SQL-brandvägg
Det enklaste sättet att göra det är att implementera SQL-brandväggen. Det kan utföras på olika nivåer och på olika platser. Ett av alternativen är att använda lastbalanserare för det. Vissa av dem kommer med denna funktionalitet åtminstone lätt att uppnå om de inte redan implementerats. Tanken bakom det är att bygga en lista med frågor som din applikation kör och sedan konfigurera din proxy för att bara passera denna typ av trafik. Det är inte idealiskt eftersom du måste underhålla det i tid, lägga till nya frågor och ta bort gamla som inte används längre. Å andra sidan kommer en sådan uppsättning regler att förhindra alla frågor som inte är auktoriserade från att nå databasen.
SQL-injektionsdetektering
Ett annat möjligt alternativ skulle vara att implementera SQL-injektionsdetektering i proxylagret. Det finns ett par lösningar, ProxySQL bland annat, som kan konfigureras för att försöka upptäcka SQL-injektion i trafiken som passerar genom dem. Naturligtvis är allt baserat på heuristik så det kan resultera i falska positiva resultat, men det kan vara ett bra tillägg till SQL-brandväggen.
Tidigare har vi diskuterat hur du kan implementera SQL-brandvägg och SQL-injektionsdetektering med ProxySQL, en lastbalanserare som kan distribueras från 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
Datasäkerhet
Äntligen datasäkerhet. Vi har hittills diskuterat hur man kan hårdna databasen, hur man begränsar åtkomsten till den och hur man förhindrar olika typer av attacker från själva applikationen. Vi bör fortfarande överväga att skydda själva uppgifterna. Detta kan ha flera lager. Fysisk säkerhet - om du äger datacentret, se till att det är ordentligt låst. Om du använder externa internetleverantörer eller molnleverantörer, se till att de har korrekta säkerhetsprotokoll på plats när det gäller åtkomst till hårdvaran. Då har vi en server, VM eller hur du än använder. Data sitter på disken, lagrad lokalt på servern. Data överförs mellan applikationen, proxyn och databasen. Data överförs mellan databasnoder med hjälp av replikering. Data lagras utanför platsen som säkerhetskopior. Dessa data bör skyddas.
Säkerhetskopiering
Säkerhetskopieringar ska alltid krypteras. Krypteringsnyckeln bör underhållas noggrant och roteras regelbundet.
Data på väg
Data som överförs bör vara krypterad. Se till att du har konfigurerat din applikation, ditt proxylager och din databas för att använda SSL eller TSL. Alla sätt att överföra data mellan databasnoderna bör också vara säkrade och krypterade. Målet är att göra någon form av nätverkssnuffande meningslöst.
Data i vila
Slutligen, själva data, lagrad på databasnoden. Det bör också krypteras. Det finns ett par metoder du kan använda när du närmar dig detta ämne. Först, kryptering på värdnivå. Volymen som databasen har sin datakatalog på kan krypteras (och dekrypteras vid uppstart). Databaser tenderar också att komma med krypteringsmöjligheter. Vad som kan krypteras beror på den exakta lösningen och typen och versionen av databasen, men i vissa fall är alternativen ganska omfattande. Tablespace-kryptering, loggkryptering, ibland till och med kryptering av strukturerna i minnet. Om du gör det på rätt sätt räcker det inte med åtkomst till databasnoden för att komma åt data.
Slutsats
Som vi nämnde tidigare är den här bloggen inte avsedd att vara en praktisk guide till databassäkerhet men vi har berört de flesta aspekter som du bör tänka på när du skapar din databasmiljö och vi hoppas du kommer att finna den här guiden användbar.