Sikkerhed er altafgørende i dag på tværs af hele IT. Fra tid til anden hører vi om ransomware-angreb eller datalæk, der har deres oprindelse i ikke-sikrede databaser eller it-infrastruktur. Du spekulerer måske på:hvad er den bedste praksis i at bygge MySQL-miljøer, så du kan føle dig sikker på dine data? Hvis ja, er denne blog for dig. Husk, at vi ikke dækker emnet fuldt ud - dette ville passe mere ind i en whitepaper end en blog. Vi vil gøre vores bedste for at nævne de vigtigste aspekter af sikring af din MySQL-database. Ideen bag denne blog er, at læseren skal vide, hvad hun eller han ikke ved, og hjælpe med at identificere emner og nøgleord til videre forskning. Vi vil illustrere det med skærmbilleder fra vores produkt, ClusterControl, som kommer med et stort sæt funktioner, herunder nogle omkring databasesikkerhed.
Netværk
Først og fremmest skal vi implementere MySQL et eller andet sted. Det være sig en selvstændig instans, primær - replika asynkron replikering eller en af de mere avancerede, synkrone replikeringstopologier som Galera eller InnoDB Cluster. Uanset hvad det er, skal det beskyttes på netværksniveau. Databasen indeholder dataene, som ganske almindeligt er det mest værdifulde aktiv for en hel organisation.
Sikring af adgangen
Databaseforekomster bør aldrig være placeret på det offentlige netværk. Netværkssegmenter, hvori databaser er konfigureret, bør kun være tilgængelige fra et begrænset antal andre netværk. Tommelfingerreglen er - skal en given node kunne tilgå databasenetværket? Hvis svaret er nej, bør netværkene adskilles.
Selvfølgelig afhænger det hele af den nøjagtige opsætning, men i de mest almindelige tilfælde, hvor du har applikations-, proxy-, cache- og databaselag, vil den mest typiske opsætning være, at kun proxyen skal kunne for at få adgang til databasen. Alle andre enheder skal konfigureres på en måde, så de kun får adgang til databasen via proxy-lag. Dette design er godt på mange måder. Ud over den øgede sikkerhed hjælper det også med at skjule kompleksiteten af databaselaget fra applikationen.
Proxylaget bør følge databasetopologien og skal håndtere databasenodefejl og topologiændringer. Applikation, der forbinder til proxy-laget, bør altid være i stand til at nå ud til en fungerende databaseknude, der er relevant for typen af anmodningen. Det samme er med cachelaget. Det kan implementeres i proxy-laget, nogle proxyer som ProxySQL tillader cache-anmodninger i proxyen, men hvis det er et separat lag bygget op omkring for eksempel memcache eller Redis, skal det altid nå ud til databasen via proxy-lag.
Den anden type knudepunkter, der muligvis skal have direkte adgang til databaselaget, er styringsknuder - dem som bruges af de operationelle teams til at administrere databaserne. Årsagen er enkel:Nogle af vedligeholdelsesopgaverne kan kræve direkte adgang til databaserne. Det kan være opgaveautomatiseringsscripts, rullende Ansible-spillebøger på tværs af hele databaseflåden eller andre opgaver. I så fald bør der naturligvis være sikkerhedsforanstaltninger på plads for at sikre, at kun de personer, der har adgang, kan logge på en sådan administrationsknude.
En anden mulig type knudepunkter (selv om styringsknudepunkter også kan bruges til det), der kan kræve adgang til databasen, er knudepunkter, der er involveret i at indsamle metrics og præsentere dem for brugerne - vi taler her om overvågning og alarmeringsaktiviteter.
VPN
For enhver form for databaselag, der spænder over flere datacentre, bør du overveje at bruge VPN til at forbinde dem. Åbne, ukrypterede forbindelser over WAN-netværk er noget, der aldrig bør ske. Selv opsætning af SSL-krypteringen er ikke den bedste mulighed, da det ville kræve åbning af adgang mellem databaseniveauet og WAN - SSL-forbindelser mellem databasenoder kræver, at de kan oprette forbindelse direkte. VPN løser dette problem ved at tilføje en mellemmand, der skaber en sikker måde at forbinde segmenter af databaselagnetværket på.
VPN bør også være obligatorisk for enhver form for brugeradgang til organisationens netværk, da det implementerer sikker forbindelse mellem en arbejdsstation og produktionsnetværket.
Firewall
Selvfølgelig, mens vi sikrer netværket, bør vi overveje at bruge firewallen. Generelt set bør hver databaseknude kun modtage forbindelser fra et defineret sæt kilder - værtsnavne og porte. Selv de "påkrævede" netværkssegmenter bør ikke have fuld adgang til databasenetværket, men kun til de nødvendige porte. Hvis proxyen kun skal oprette forbindelse til databaseporten, så er der ingen grund til, at den kan få adgang til en hvilken som helst anden port på databasenoderne. Bemærk også, at du ikke bør bruge standardportene. Det er naturligvis sikkerhed ved uklarhed - porten er trods alt åben et sted, men det hjælper med at håndtere i det mindste nogle af de sikkerhedsindtrængen, der bruger automatiserede scripts. Det forhindrer ikke nogen, der er fast besluttet på at få adgangen, men kan bremse ham (når det kombineres med portscanningsdetektion og anti-scanningsforanstaltninger), mens det forhindrer automatiserede angreb i at lykkes.
Databasesikkerhed
Netværk er den første forsvarslinje, der er andre sikkerhedsforanstaltninger og god praksis, du kan bruge til at forbedre din sikkerhed yderligere. Nogle af dem kan implementeres på selve databasen.
Brugere og værter
Databaserne selv kan bruges til at implementere adgangskontrol og begrænsninger. For det første kan du implementere værtsbaseret adgangskontrol, hvilket forhindrer andre værter end den korte liste over noder i at logge ind i databasen. Selvfølgelig, hvis du brugte en firewall til at begrænse adgangen, kan dette lyde som en duplikat, men det er stadig en god idé at begrænse adgangen til selve databasen - du ved aldrig, hvornår en firewall ved et uheld bliver deaktiveret. I et sådant tilfælde har du stadig et ekstra beskyttelseslag.
Det, du vil implementere her, er en liste over databasebrugere og værter, der har tilladelse til at få adgang til databasen. Det, du højst sandsynligt skulle ende med, er en eller flere brugerbevilget adgang fra værter placeret i proxy-laget. Hvor detaljeret adgangskontrol du måtte have afhænger af det databasesystem du har. MySQL, for eksempel, tillader ikke detaljeret kontrol over netværksmaskerne - den bruger bare /32, /24, /16 eller /8. I PostgreSQL kan du derimod bruge enhver form for netværksmaske.
Tilskud
Hvis dette er, hvad din database tillader, bør hver af brugerne have et defineret sæt af bevillinger - hvilket sikrer, at de privilegier, der er tildelt dem, er de minimale nødvendige for, at brugeren kan udføre de handlinger, han skal gøre . Databasesystemer kan have forskellige sæt privilegier og forskellige niveauer af dem. Typisk har vi flere niveauer af privilegier - globale, som påvirker hele databaseserveren, skemaniveau - en given bruger kan have forskellige privilegier tildelt forskellige skemaer. Du kan have privilegier på tabel- eller endda kolonneniveau. Som vi nævnte før, er målet at skabe det minimale sæt privilegier for hver bruger. Du vil sandsynligvis gerne have mindst én bruger med høje privilegier - den vil blive brugt til at administrere databasen. Sådanne brugere bør være strengt begrænset, når det kommer til tilslutning. Det bør ikke (og faktisk bør ingen af brugerne) have tilladelse til at oprette forbindelse fra et hvilket som helst sted - det bør enten være en lokal vært eller en bestemt administrationsknude, dedikeret til at udføre operationer på databasen.
Adgangskodeadministration
Alle brugere i databasen bør have en adgangskode defineret. Dette er en no-brainer. Adgangskoden skal gemmes i form af en hash. Du bør sikre dig, at du bruger den sikreste hash-algoritme, som din database har at tilbyde til lagring af adgangskoder. Adgangskoder bør ikke være lette at gætte, og de bør ikke være sårbare over for ordbogsangrebet. Nogle databasesystemer, som MySQL, giver dig mulighed for præcist at definere de krav, dine adgangskoder skal opfylde, for at de kan bruges. Små og store bogstaver, tal, specialtegn, længden af adgangskoden - alt sammen er vigtigt, og hvis du kan håndhæve nogle politikker omkring adgangskodens styrke, bør du gøre det. En anden vigtig bit er adgangskoderotation. Adgangskoder bør ikke oprettes én gang for alle databasens levetid, du bør have en politik for rotation af adgangskode. Igen, nogle af databasesystemerne kan håndhæve dette for dig. Administrativ bruger kan muligvis oprette nye brugerkonti med adgangskoderotation påtvunget. Han er muligvis også i stand til at gennemtvinge adgangskoderotation for en given bruger.
Revisionslogfiler
Nogle af databasesystemerne tilbyder revisionslogs - ideen er at indsamle så meget information om aktiviteten i databasen som muligt. Hvem og hvornår gjorde hvad? Hvilken forespørgsel er blevet udført, af hvem? Hvem forsøgte at logge ind, men mislykkedes? Fra hvilken vært? Ideelt set ville logfiler indeholdende sådanne oplysninger blive gemt uden for databasenoderne. Du kan streame dem til din centrale logserver for opbevaring, yderligere behandling og bedre søgemuligheder.
SQL-sikkerhed
Vi nævnte brugere og værter, men angrebet kan også ske fra en anden kilde. Hvis din applikation ikke er korrekt sikret, og inputtet ikke er korrekt valideret, kan du blive udsat for angreb, der stammer fra dit websted. Vi taler her om SQL-injektion. I sådanne tilfælde er firewalls ikke rigtig nyttige, da forespørgslen stammer fra en gyldig kilde (din webserver og derefter proxy node). Tildeling af bevillinger kan faktisk være med til at forhindre nogle af denne form for angreb, men det er ikke en ideel løsning - trods alt vil din ansøgning i de fleste tilfælde have brug for en bruger, der kan fjerne eller ændre indholdet af databasen. En sådan bruger kan, når den udnyttes, bruges til at gøre skade. Der er flere måder, hvorpå du kan forsøge at imødegå godbidden.
SQL firewall
Den enkleste måde at gøre det på er ved at implementere SQL firewall. Det kan udføres på forskellige niveauer og forskellige steder. En af mulighederne er at bruge belastningsbalancere til det. Nogle af dem kommer med denne funktionalitet i det mindste let opnåelige, hvis de ikke allerede er implementeret. Ideen bag det er at bygge en liste over forespørgsler, som din applikation udfører, og derefter konfigurere din proxy til kun at passere gennem denne form for trafik. Det er ikke ideelt, da du bliver nødt til at vedligeholde det i tide, tilføje nye forespørgsler og fjerne gamle, der ikke bruges længere. På den anden side vil et sådant regelsæt forhindre enhver forespørgsel, der ikke er autoriseret, i at nå databasen.
SQL-injektionsdetektion
En anden mulig mulighed ville være at implementere SQL-injektionsdetektion i proxylaget. Der er et par løsninger, ProxySQL blandt andre, der kan konfigureres til at forsøge at detektere SQL-injektion i den trafik, der passerer gennem dem. Selvfølgelig er det hele baseret på heuristik, så det kan resultere i falske positiver, men det kan være en god tilføjelse til SQL-firewall'en.
Tidligere har vi diskuteret, hvordan du kan implementere SQL firewall og SQL-injektionsdetektion ved hjælp af ProxySQL, en loadbalancer, der kan implementeres fra 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
Datasikkerhed
Endelig datasikkerhed. Vi har hidtil diskuteret, hvordan man kan hærde databasen, hvordan man begrænser adgangen til den, og hvordan man forhindrer forskellige former for angreb, der kommer fra selve applikationen. Vi bør stadig overveje beskyttelse af selve dataene. Dette kan have flere lag. Fysisk sikkerhed - hvis du ejer datacenteret, skal du sikre dig, at det er korrekt låst. Hvis du bruger eksterne internetudbydere eller cloud-udbydere, skal du sikre dig, at de har ordentlige sikkerhedsprotokoller på plads, når det kommer til at få adgang til hardwaren. Så har vi en server, VM eller hvordan du bruger det. Data sidder på disken, gemt lokalt på serveren. Data overføres mellem applikationen, proxy og databasen. Data overføres mellem databasenoder ved hjælp af replikering. Data gemmes offsite som sikkerhedskopier. Disse data bør beskyttes.
Sikkerhedskopier
Sikkerhedskopier skal altid være krypteret. Krypteringsnøglen skal vedligeholdes omhyggeligt og roteres regelmæssigt.
Data i transit
Data, der overføres, skal være krypteret. Sørg for, at du har konfigureret din applikation, proxy-lag og database til at bruge SSL eller TSL. Ethvert middel til at overføre data mellem databasenoderne bør også være sikret og krypteret. Målet er at gøre enhver form for netværkssniffing meningsløs.
Data i hvile
Til sidst, selve dataene, gemt på databasenoden. Det skal også være krypteret. Der er et par metoder, du kan bruge, når du nærmer dig dette emne. Først kryptering på værtsniveau. Den diskenhed, som databasen har sin datamappe på, kan krypteres (og dekrypteres ved opstart). Databaser har også en tendens til at komme med krypteringsfunktioner. Hvad der kan krypteres afhænger af den præcise løsning og typen og versionen af databasen, men i nogle tilfælde er mulighederne ret omfattende. Tablespace-kryptering, log-kryptering, nogle gange endda kryptering af strukturerne i hukommelsen. Hvis du gør det korrekt, vil adgang til databasenoden ikke være nok til at få adgang til dataene.
Konklusion
Som vi nævnte før, er denne blog ikke beregnet til at være en praktisk guide til databasesikkerhed, men vi har berørt størstedelen af de aspekter, som du bør overveje, når du opbygger dit databasemiljø, og vi håber du vil finde denne vejledning nyttig.