Gegevensbeveiliging is cruciaal in tijden van AVG, PCI DSS of HIPPA. Om aan de regelgeving te voldoen, moet men uiterst voorzichtig zijn met hoe de gegevens moeten worden opgeslagen en beschermd. Gegevens kunnen doorgaans in rust of onderweg zijn. Data in transit is de data die wordt overgedragen van of naar de database. Queryresultaten die naar de client of toepassing worden verzonden of gerepliceerde gegevens tussen knooppunten van het cluster zijn voorbeelden van gevallen waarin gegevens onderweg zijn. We hebben de neiging om gegevens in die staat te beveiligen met behulp van de SSL- of TLS-versleutelde verbindingen tussen de databaseknooppunten of de database en de client.
Aan de andere kant van het spectrum hebben we data in rust - we zouden zeggen dat de meeste data op het gegeven moment in rust zijn. We hebben het hier over gegevens die op schijf zijn opgeslagen in tabelruimten, verschillende gegevensstructuren (gcache-buffer, redo-logs) en logs (binaire en relay-logs). Laten we eens kijken naar de overwegingen rond dit onderwerp in MariaDB.
Wat te versleutelen in MariaDB?
Idealiter moet je alles versleutelen. Databases slaan gegevens op verschillende plaatsen en verschillende manieren op, zoals hierboven vermeld. De grootste set gegevens wordt opgeslagen in tablespaces - dit is de "laatste" locatie waar de gegevens worden opgeslagen. Het is duidelijk mogelijk om tabelruimten te versleutelen - anders zou de hele functie zinloos zijn. MariaDB kan de gegevens in één gedeelde tablespace opslaan, meerdere of elke tabel kan in een aparte tablespace worden opgeslagen - al deze scenario's worden ondersteund. Gebruikers hebben een zekere mate van flexibiliteit bij het kiezen van wat ze willen versleutelen. Je kunt alles versleutelen, individuele tabellen of alles behalve enkele individuele tabellen.
MariaDB InnoDB opnieuw logboek
Een andere structuur die de gegevens opslaat, is de InnoDB redo log. InnoDB redo log is een plaats waar gegevens worden geschreven nadat een bepaalde rij is geüpgraded. Gegevens van het redo-log zullen uiteindelijk worden overgebracht naar de tablespace, maar voorlopig bevat het InnoDB redo-log alle wijzigingen die recentelijk zijn doorgevoerd. Zoals je je kunt voorstellen, zijn deze gegevens ook van cruciaal belang en moeten ze worden beschermd - met MariaDB kun je het InnoDB-logboek opnieuw versleutelen.
MariaDB binaire logboeken
Binaire logboeken (evenals relaislogboeken) slaan informatie op over uitgevoerde zoekopdrachten die de gegevens wijzigen. Omdat de opgenomen informatie ons in staat stelt om de huidige staat van een rij die is gewijzigd te reconstrueren, is dit een andere vorm van gegevens die moet worden beschermd en versleuteld. Zowel binaire als relay-logboeken kunnen worden versleuteld in MariaDB.
Galera-cache
Galera-cache (gcache) is een buffer op de schijf in Galera Cluster die de informatie over uitgevoerde wijzigingen opslaat. Het wordt gebruikt in het geval van knooppuntstoringen of tijdelijke netwerkproblemen, zodat knooppunten die zich bij het cluster aansluiten, alleen de ontbrekende gegevens kunnen inhalen, zodat de overdracht van de hele gegevensset wordt vermeden. Net als bij binaire logs of redo logs, bevat gcache de lijst met wijzigingen en als zodanig kan het worden gebruikt om stukjes gegevens te herstellen en samen te stellen. In de communityversie van MariaDB Galera Cluster kan gcache niet worden versleuteld. Een dergelijke optie wordt beschikbaar in de Enterprise-versie van MariaDB Galera Cluster.
Wat kan niet worden versleuteld in MariaDB?
Er zijn nog steeds enkele plaatsen waar gegevens kunnen verschijnen die niet kunnen worden versleuteld, althans vanaf nu, in MariaDB. Ten eerste kunnen foutenlogboeken voorbeelden van zoekopdrachten bevatten die mogelijk bepaalde gegevens blootleggen. Het is onmogelijk om foutenlogboeken te versleutelen, maar het is mogelijk om het foutenlogboek om te leiden naar de syslog en een beveiligingsmechanisme buiten MariaDB te implementeren.
Logboeken van Audit Plugin
Audit Plugin genereert ook log - dit log kan gevoelige informatie bevatten, inclusief de exacte zoekopdrachten die zijn uitgevoerd op de database. Het is niet mogelijk om dit logboek te versleutelen, maar het kan worden doorgestuurd naar de syslog en daar versleutelen.
Zoeklogboeken
Algemene en langzame query-logboeken - die logs bevatten query's (of in ieder geval voorbeelden daarvan) die zijn uitgevoerd door MariaDB. Vanaf nu is het niet mogelijk om die logs te versleutelen.
InnoDB-bufferpool
Geheugen - MariaDB voert alleen codering uit voor de pagina's die op schijf zijn opgeslagen. Alle gegevens die in de InnoDB-bufferpool zijn opgeslagen, worden niet versleuteld. InnoDB-bufferpool is bedoeld om de rijen te bewaren die recentelijk zijn gewijzigd of toegankelijk zijn gemaakt door een SELECT-query - die rijen zullen uiteraard gegevensvoorbeelden bevatten. Vanaf nu is er geen optie om de InnoDB-bufferpool in MariaDB te versleutelen. Houd er rekening mee dat men toegang tot het systeem nodig heeft om het live-geheugen te lezen. Het is geen triviale taak, ook al is het ook niet onmogelijk om te volbrengen.
Houd er rekening mee dat we de coderingsopties in MariaDB hebben behandeld. Er is altijd de mogelijkheid om een andere encryptielaag te gebruiken. Als u bijvoorbeeld de hele opslag versleutelt, worden logboeken niet leesbaar voor iedereen die fysieke toegang tot de schijf zou hebben. Aan de andere kant beschermt het de gegevens niet van iemand die kan inloggen op het systeem.
Compatibiliteit met externe tools
Een ander ding om te overwegen is compatibiliteit. Als u besluit uw MariaDB te versleutelen, moet u er rekening mee houden dat dit van invloed kan zijn op uw manier van werken. Het is niet mogelijk om externe tools zoals XtraBackup of mysqlbinlog te gebruiken om de gegevens te verwerken en een back-up te maken of om met binaire logs om te gaan. U zult zich moeten houden aan de tools die door MariaDB zijn gemaakt (zoals Mariabackup), die zijn geschreven met het coderingsmechanisme in gedachten. Ze kunnen omgaan met de data-at-rest-encryptie is geïmplementeerd in MariaDB.
Planning voor versleutelingsproces
In dit gedeelte wordt het proces niet in detail besproken, maar wordt bekeken waar u rekening mee moet houden bij het plannen van versleuteling, zoals resources en tijd. Het CPU-gebruik zal toenemen, evenals de I/O-activiteit voor de duur van het proces. Vanuit het oogpunt van de gebruiker komt het allemaal neer op de configuratie-instellingen en het uitvoeren van ALTER-opdrachten om bestaande tabellen opnieuw op te bouwen en te versleutelen. Voor grote databases kan dit alleen al een grote uitdaging zijn die planning vereist. Schemawijzigingen kunnen een zware last zijn en het wordt aanbevolen om tools zoals pt-online-schema-change te gebruiken om de impact ervan op de productiesystemen te verminderen en een betere controle over het proces te krijgen.
Laatste gedachten
Zoals we al zeiden, gegevens zijn van cruciaal belang voor alle organisaties en het is cruciaal om ervoor te zorgen dat de gegevens veilig en beschermd zijn. Versleuteling van de gegevens in rust is een van de belangrijke elementen in het hele plaatje. We horen graag van u over uw ervaring met data-at-rest-versleuteling in MariaDB. Als u uw mening wilt delen, kunt u hieronder een reactie achterlaten.