Datasäkerhet är avgörande i tider av GDPR, PCI DSS eller HIPPA. För att följa regelverket måste man iaktta extrem försiktighet med hur uppgifterna ska lagras och skyddas. Data kan vanligtvis vara i vila eller på väg. Data under överföring är data som överförs från eller till databasen. Frågeresultat som skickas till klienten eller applikationen eller replikerad data mellan noder i klustret är exempel på fall då data är på väg. Vi tenderar att säkra data i det tillståndet med hjälp av SSL eller TLS - krypterade anslutningar mellan databasnoderna eller databasen och klienten.
På andra sidan av spektrumet har vi data i vila - vi skulle säga att de flesta data är i vila vid det givna ögonblicket. Vi pratar här om data lagrad på disk i tabellutrymmen, olika datastrukturer (gcache-buffert, redo-loggar) och loggar (binära och reläloggar). Låt oss ta en titt på övervägandena kring detta ämne i MariaDB.
Vad ska man kryptera i MariaDB?
Helst måste du kryptera allt. Databaser lagrar data på olika platser och olika sätt, som nämnts ovan. Den största uppsättningen data lagras i tabellutrymmen - detta är den "slutliga" platsen där data lagras. Uppenbarligen är det möjligt att kryptera tabellutrymmen - annars skulle hela funktionen vara meningslös. MariaDB kan lagra data i en delad tabellyta, flera av dem eller varje tabell kan lagras i ett separat tabellutrymme - alla dessa scenarier stöds. Användare har en viss grad av flexibilitet när de väljer vad de ska kryptera. Du kan kryptera allt, enskilda tabeller eller allt utom några enskilda tabeller.
MariaDB InnoDB gör om logg
En annan struktur som lagrar data är InnoDB redo log. InnoDB redo log är en plats där data skrivs efter att en given rad har uppgraderats. Data från redo-logg kommer så småningom att överföras till tabellutrymmet men tills vidare innehåller InnoDB redo-logg alla ändringar som hände nyligen. Som du kan föreställa dig är denna data också kritisk och bör skyddas - MariaDB låter dig kryptera InnoDB redo log.
MariaDB binära loggar
Binära loggar (liksom reläloggar) lagrar information om körda frågor som ändrar data. Eftersom den inkluderade informationen tillåter oss att rekonstruera det aktuella tillståndet för en rad som har genomgått modifiering, är detta en annan form av data som bör skyddas och krypteras. Både binära och reläloggar kan krypteras i MariaDB.
Galeras cache
Galera cache (gcache) är en buffert på disken i Galera Cluster som lagrar information om utförda ändringar. Den används vid nodfel eller tillfälliga nätverksproblem för att tillåta noder som ansluter sig till klustret att komma ikapp med bara den data de saknar, för att undvika att överföra hela datasetet. I likhet med binära loggar eller redo-loggar innehåller gcache listan över ändringar och som sådan kan den användas för att återställa och sätta ihop bitar av data. I communityversionen av MariaDB Galera Cluster kan inte gcache krypteras. Ett sådant alternativ blir tillgängligt i Enterprise-versionen av MariaDB Galera Cluster.
Vad kan inte krypteras i MariaDB?
Det finns fortfarande vissa ställen där databitar kan dyka upp som inte kan krypteras, åtminstone för närvarande, i MariaDB. För det första kan felloggar innehålla exempel på frågor som potentiellt kan exponera vissa data. Det är omöjligt att kryptera felloggar, men det är möjligt att omdirigera felloggen till sysloggen och implementera någon skyddsmekanism utanför MariaDB.
Loggar från Audit Plugin
Audit Plugin genererar också logg - den här loggen kan innehålla känslig information, inklusive de exakta frågorna som har körts på databasen. Det är inte möjligt att kryptera den här loggen, men den kan omdirigeras till sysloggen och kryptera där.
Frågeloggar
Allmänna och långsamma frågeloggar - dessa loggar kommer att innehålla frågor (eller åtminstone exempel på dem) som kördes av MariaDB. För närvarande är det inte möjligt att kryptera dessa loggar.
InnoDB buffertpool
Minne - MariaDB utför kryptering endast för de sidor som är lagrade på disken. All data som lagras i InnoDB buffertpool kommer att vara okrypterad. InnoDB buffertpool är avsedd att behålla raderna som nyligen modifierats eller nås av SELECT-frågan - dessa rader kommer uppenbarligen att innehålla dataprover. Från och med nu finns det inget alternativ att kryptera InnoDB-buffertpoolen i MariaDB. Tänk på att man skulle behöva tillgång till systemet för att läsa liveminnet. Det är ingen trivial uppgift, även om den inte heller är omöjlig att utföra.
Tänk på att vi täckte krypteringsalternativ som ingår i MariaDB. Det finns alltid möjlighet att använda ett annat lager av kryptering. Till exempel kommer kryptera hela lagringsutrymmet att göra loggar oläsbara för alla som skulle ha fysisk åtkomst till disken. Å andra sidan kommer det inte att skydda data från någon som kan logga in i systemet.
Kompatibilitet med externa verktyg
En annan sak att tänka på är kompatibilitet. Om du bestämmer dig för att kryptera din MariaDB måste du komma ihåg att detta kan påverka ditt sätt att arbeta. Det är inte möjligt att använda externa verktyg som XtraBackup eller mysqlbinlog för att bearbeta data och skapa en säkerhetskopia eller för att hantera binära loggar. Du måste hålla dig till verktygen skapade av MariaDB (som Mariabackup), som är skrivna med krypteringsmekanismen i åtanke. De kan hantera data i vila kryptering är implementerad i MariaDB.
Planera för krypteringsprocessen
Det här avsnittet kommer inte att diskutera processen i detalj, men det tittar på vad du bör tänka på när du planerar för kryptering, som resurser och tid. CPU-användningen kommer att öka liksom I/O-aktiviteten under hela processen. Ur användarens synvinkel handlar allt om konfigurationsinställningarna och att sedan köra ALTER-kommandon för att bygga om och kryptera befintliga tabeller. Enbart för stora databaser kan detta vara en betydande utmaning som skulle kräva planering. Schemaändringar kan vara en allvarlig börda, och det rekommenderas att använda verktyg som pt-online-schema-change för att minska deras påverkan på produktionssystemen och få bättre kontroll över processen.
Sluta tankar
Som vi nämnde är data avgörande för alla organisationer, och det är avgörande att se till att data är säker och skyddad. Kryptering av data i vila är en av de viktiga elementen i hela bilden. Vi vill gärna höra från dig om din erfarenhet av data at rest-kryptering i MariaDB. Om du vill dela med dig av dina tankar är du välkommen att lämna en kommentar nedan.