Datasikkerhed er afgørende i tider med GDPR, PCI DSS eller HIPPA. For at overholde reglerne skal man udvise ekstrem forsigtighed med hensyn til, hvordan dataene skal opbevares og beskyttes. Data kan typisk være i hvile eller under transport. Data i transit er de data, der overføres fra eller til databasen. Forespørgselsresultater sendt til klienten eller applikationen eller replikerede data mellem noder i klyngen er eksempler på tilfælde, hvor data er i transit. Vi har en tendens til at sikre data i den tilstand ved hjælp af SSL eller TLS - krypterede forbindelser mellem databasenoderne eller databasen og klienten.
På den anden side af spektret har vi data i hvile - vi vil sige, at de fleste data på det givne tidspunkt er i hvile. Vi taler her om data gemt på disk i tablespaces, forskellige datastrukturer (gcache buffer, redo logs) og logs (binære og relæ logs). Lad os tage et kig på overvejelserne omkring dette emne i MariaDB.
Hvad skal man kryptere i MariaDB?
Ideelt set skal du kryptere alt. Databaser gemmer data forskellige steder og på forskellige måder, som nævnt ovenfor. Det største sæt data er gemt i tablespaces - dette er den "endelige" placering, hvor dataene er gemt. Det er klart, at det er muligt at kryptere tablespaces - ellers ville hele funktionen være meningsløs. MariaDB kan gemme dataene i et delt tablespace, flere af dem eller hver tabel kan gemmes i et separat tablespace - alle disse scenarier er understøttet. Brugere har en vis grad af fleksibilitet, når de vælger, hvad der skal krypteres. Du kan kryptere alt, individuelle tabeller eller alt undtagen nogle individuelle tabeller.
MariaDB InnoDB fortryd log
En anden struktur, der gemmer dataene, er InnoDB redo log. InnoDB redo log er et sted, hvor data skrives efter en given række er blevet opgraderet. Data fra redo-log vil til sidst blive overført til tablespacet, men for en tid indeholder InnoDB redo-log alle de ændringer, der er sket for nylig. Som du kan forestille dig, er disse data også kritiske og bør beskyttes - MariaDB giver dig mulighed for at kryptere InnoDB redo-log.
MariaDB binære logfiler
Binære logfiler (såvel som relælogfiler) gemmer information om udførte forespørgsler, der ændrer dataene. Da de inkluderede oplysninger giver os mulighed for at rekonstruere den aktuelle tilstand af en række, der har undergået modifikation, er dette en anden form for data, der bør beskyttes og krypteres. Både binære og relælogfiler kan krypteres i MariaDB.
Galera-cache
Galera-cache (gcache) er en buffer på disken i Galera Cluster, der gemmer information om udførte ændringer. Det bruges i tilfælde af knudefejl eller midlertidige netværksproblemer for at tillade knudepunkter, der slutter sig til klyngen, at indhente ved kun at bruge de data, de mangler, og undgå at overføre hele datasættet. I lighed med binære logfiler eller redo-logfiler indeholder gcache listen over ændringer, og som sådan kan den bruges til at gendanne og sammensætte datastykker. I fællesskabsversionen af MariaDB Galera Cluster kan gcache ikke krypteres. En sådan mulighed bliver tilgængelig i Enterprise-versionen af MariaDB Galera Cluster.
Hvad kan ikke krypteres i MariaDB?
Der er stadig nogle steder, hvor stykker data kan dukke op, som ikke kan krypteres, i det mindste nu, i MariaDB. For det første kan fejllogfiler indeholde eksempler på forespørgsler, der potentielt kan afsløre nogle data. Det er umuligt at kryptere fejllogfiler, men det er muligt at omdirigere fejlloggen til sysloggen og implementere en beskyttelsesmekanisme uden for MariaDB.
Logfiler fra Audit Plugin
Audit Plugin genererer også log - denne log kan indeholde følsomme oplysninger, inklusive de nøjagtige forespørgsler, der er blevet udført på databasen. Det er ikke muligt at kryptere denne log, men den kan omdirigeres til syslog og kryptere der.
Forespørgselslogfiler
Generelle og langsomme forespørgselslogfiler - disse logfiler vil indeholde forespørgsler (eller i det mindste eksempler på dem), der blev udført af MariaDB. Lige nu er det ikke muligt at kryptere disse logfiler.
InnoDB-bufferpulje
Hukommelse - MariaDB udfører kun kryptering for de sider, der er gemt på disken. Alle data, der er gemt i InnoDB-bufferpuljen, vil være ukrypteret. InnoDB-bufferpuljen er beregnet til at holde rækkerne ændret for nylig eller tilgået af SELECT-forespørgsel - disse rækker vil naturligvis indeholde dataeksempler. Lige nu er der ingen mulighed for at kryptere InnoDB-bufferpuljen i MariaDB. Husk, at man vil kræve adgang til systemet for at læse live-hukommelsen. Det er ikke en triviel opgave, selvom den heller ikke er umulig at klare.
Husk venligst, at vi dækkede krypteringsmuligheder inkluderet i MariaDB. Der er altid mulighed for at bruge et andet lag af kryptering. For eksempel vil kryptering af hele lageret gøre logfiler ulæselige for alle, der ville have fysisk adgang til disken. På den anden side beskytter det ikke dataene fra nogen, der er i stand til at logge ind på systemet.
Kompatibilitet med eksterne værktøjer
En anden ting at overveje er kompatibilitet. Hvis du beslutter dig for at kryptere din MariaDB, skal du huske på, at dette kan påvirke den måde, du opererer på. Det er ikke muligt at bruge eksterne værktøjer som XtraBackup eller mysqlbinlog til at behandle dataene og lave en backup eller til at håndtere binære logfiler. Du bliver nødt til at holde dig til værktøjerne oprettet af MariaDB (som Mariabackup), som er skrevet med krypteringsmekanismen i tankerne. De kan håndtere data i hvile kryptering er implementeret i MariaDB.
Planlægning af krypteringsproces
Dette afsnit vil ikke diskutere processen i detaljer, men det ser på, hvad du bør overveje, når du planlægger for kryptering, såsom ressourcer og tid. CPU-udnyttelsen vil stige såvel som I/O-aktiviteten i hele processens varighed. Fra brugerens synspunkt kommer det hele ned til konfigurationsindstillingerne og derefter at udføre ALTER-kommandoer for at genopbygge og kryptere eksisterende tabeller. For store databaser kan dette alene være en væsentlig udfordring, som ville kræve planlægning. Skemaændringer kan være en alvorlig byrde, og det anbefales at bruge værktøjer som pt-online-schema-change for at reducere deres indvirkning på produktionssystemerne og få bedre kontrol over processen.
Sidste tanker
Som vi nævnte, er data afgørende for alle organisationer, og det er afgørende at sikre, at dataene er sikre og beskyttede. Kryptering af data i hvile er et af de vigtige elementer i hele billedet. Vi vil meget gerne høre fra dig om din oplevelse med data i hvile kryptering i MariaDB. Hvis du gerne vil dele dine tanker, er du velkommen til at efterlade en kommentar nedenfor.