Versleuteling gebruiken om uw MongoDB-gegevens te beschermen

Databasebeveiliging is een belangrijke factor om te overwegen voor elke toepassing waarbij zeer gevoelige gegevens zoals financiële en gezondheidsrapporten worden gebruikt. Gegevensbescherming kan worden bereikt door middel van codering op verschillende niveaus, van de applicatie zelf tot bestanden die de gegevens bevatten.

Aangezien MongoDB een niet-relationele database is, hoeft u geen kolommen te definiëren voordat u gegevens invoegt; en daarom kunnen documenten in dezelfde collectie verschillende velden van elkaar hebben.

Aan de andere kant moet men voor SQL DBMS kolommen voor de gegevens definiëren, vandaar dat alle rijen dezelfde kolommen hebben. Men kan besluiten om individuele kolommen, het volledige databasebestand of gegevens uit de applicatie te versleutelen voordat het betrokken wordt bij het databaseproces.

Versleuteling van afzonderlijke kolommen heeft de meeste voorkeur, omdat dit goedkoper is en er minder gegevens worden versleuteld, waardoor de latentie wordt verbeterd. Over het algemeen zijn de algehele prestaties van invloed als gevolg van de codering.

Voor NoSQL DBMS zal deze aanpak echter niet de beste zijn. Aangezien niet alle documenten alle velden bevatten die u in uw codering wilt gebruiken, kan codering op kolomniveau niet worden uitgevoerd.

Het versleutelen van gegevens op applicatieniveau is vrij kostbaar en moeilijk te implementeren. We behouden daarom de mogelijkheid om gegevens op databaseniveau te versleutelen.

MongoDB biedt native encryptie waarvoor u geen extra kosten hoeft te betalen voor het beveiligen van uw gevoelige gegevens.

Gegevens versleutelen in MongoDB

Elke databasebewerking omvat een van deze twee gegevensvormen, gegevens in rust of gegevens in beweging.

Gegevens in beweging zijn een gegevensstroom die door elk soort netwerk beweegt, terwijl gegevens in rust statisch zijn en dus nergens heen gaan.

Beide gegevenstypen zijn gevoelig voor externe interferentie door anonieme gebruikers, tenzij er sprake is van versleuteling. Het coderingsproces omvat:

• Een hoofdsleutel genereren voor de hele database
• Unieke sleutels genereren voor elke database
• Uw gegevens versleutelen met de databasesleutels die u heeft gegenereerd
• De hele database versleutelen met de hoofdsleutel

Gegevens versleutelen tijdens het transport

Gegevens worden op twee manieren tussen MongoDB en de servertoepassing uitgewisseld, namelijk via Transport Layer Security (TLS) en Secure Socket Layer (SSL).

Deze twee zijn de meest gebruikte coderingsprotocollen voor het beveiligen van verzonden en ontvangen gegevens tussen twee systemen. In principe is het concept om verbindingen met de mongod- en mongos-instanties te versleutelen, zodat het netwerkverkeer alleen kan worden gelezen door de beoogde client.

TLS/SSL worden gebruikt in MongoDB met sommige certificaten als PEM-bestanden die zijn uitgegeven door de certificeringsinstantie of een zelfondertekend certificaat kunnen zijn. Dit laatste heeft een beperking in die zin dat, hoewel het communicatiekanaal gecodeerd is, er altijd geen validatie is tegen de serveridentiteit en daarom halverwege kwetsbaar is voor externe aanvallen. Het is dus raadzaam om certificaten van vertrouwde autoriteit te gebruiken waarmee MongoDB-stuurprogramma's ook de serveridentiteit kunnen verifiëren.

Naast encryptie kan TLS/SSL worden gebruikt bij de authenticatie van de client en interne authenticatie van leden van replicasets en shard-clusters via de certificaten.

TLS/SSL-configuratie voor clients

Er zijn verschillende TLS/SSL-optie-instellingen die kunnen worden gebruikt bij de configuratie van deze protocollen.

Als u bijvoorbeeld verbinding wilt maken met een Mongod-instantie met behulp van codering, start u uw instantie als,

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl schakelt de TLS/SSL-verbinding in.

--sslCAFile specificeert het pem-bestand van de certificeringsinstantie (CA) voor verificatie van het certificaat gepresenteerd door de mongod of de mongo's. De Mongo-shell verifieert daarom het certificaat dat is uitgegeven door de mongod-instantie aan de hand van het opgegeven CA-bestand en de hostnaam.

Mogelijk wilt u ook een MongoDB-instantie verbinden waarvoor een clientcertificaat vereist is. We gebruiken het onderstaande codevoorbeeld

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

De optie --sslPEMKeyFile specificeert het .pem-bestand dat het mongo-shellcertificaat en een sleutel bevat om aan de mongod- of mongos-instantie te presenteren. Tijdens het verbindingsproces:

De mongo-shell zal verifiëren of het certificaat afkomstig is van de gespecificeerde certificeringsinstantie (--sslCAFile) en zo niet, zal de shell geen verbinding maken.

Ten tweede zal de shell ook verifiëren of de hostnaam gespecificeerd in de --host optie overeenkomt met de SAN/CN in het certificaat gepresenteerd door de mongod of mongo's. Als deze hostnaam niet overeenkomt met een van de twee, zal de verbinding mislukken.

Als u geen zelfondertekende certificaten wilt gebruiken, moet u ervoor zorgen dat het verbindingsnetwerk wordt vertrouwd.

Bovendien moet u de blootstelling van de persoonlijke sleutel verminderen, vooral als het gaat om replicasets/sharded clusters. Dit kan worden bereikt door verschillende certificaten op verschillende servers te gebruiken.

Extra opties die kunnen worden gebruikt in de verbindingen zijn:

requiredSSL:dit zal elke server beperken om alleen TLS/SSL-gecodeerde verbindingen te gebruiken.

--sslAllowConnectionsWithoutCertificates:dit maakt validatie mogelijk als alleen de client een certificaat presenteert, anders is de client nog steeds verbonden in een gecodeerde modus als er geen certificaat is. Bijvoorbeeld:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:deze optie voorkomt dat servers inkomende verbindingen accepteren die gebruikmaken van specifieke protocollen. Dit kan met:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Gegevens in rust versleutelen

Vanaf versie 3.2 introduceerde MongoDB een native coderingsoptie voor de WiredTiger-opslagengine. Toegang tot gegevens in deze opslag door een derde partij kan alleen worden bereikt door middel van een decoderingssleutel voor het decoderen van de gegevens in een leesbaar formaat.

Het veelgebruikte coderingsalgoritme in MongoDB is de AES256-GCM. Het gebruikt dezelfde geheime sleutel om gegevens te coderen en te decoderen. Versleuteling kan worden ingeschakeld met behulp van de FIPS-modus, waardoor de versleuteling voldoet aan de hoogste standaard en naleving.

De hele databasebestanden worden versleuteld met behulp van de transparante gegevensversleuteling (TDE) op opslagniveau.

Telkens wanneer een bestand wordt gecodeerd, wordt een unieke privécoderingssleutel gegenereerd en het is goed om te begrijpen hoe deze sleutels worden beheerd en opgeslagen. Alle gegenereerde databasesleutels worden daarna versleuteld met een hoofdsleutel.

Het verschil tussen de databasesleutels en de hoofdsleutel is dat de databasesleutels naast de versleutelde gegevens zelf kunnen worden opgeslagen, maar voor de hoofdsleutel adviseert MongoDB om deze op een andere server op te slaan dan de versleutelde gegevens, zoals een bedrijfssleutel van derden beheeroplossingen.

Bij gerepliceerde gegevens worden de versleutelingscriteria niet gedeeld met de andere knooppunten, aangezien de gegevens niet native over de draad worden versleuteld. Men kan dezelfde sleutel opnieuw gebruiken voor de knooppunten, maar het beste is om voor elk knooppunt unieke individuele sleutels te gebruiken.

Roterende coderingssleutels

De beheerde sleutel die wordt gebruikt voor het ontsleutelen van gevoelige gegevens, moet ten minste eenmaal per jaar worden gerouleerd of vervangen. Er zijn twee opties in MongoDB om de rotatie te bereiken.

KMIP-masterrotatie

In dit geval wordt alleen de hoofdsleutel gewijzigd, aangezien deze extern wordt beheerd. Het proces voor het draaien van de sleutel is zoals hieronder beschreven.

1. De hoofdsleutel voor de secundaire leden in de replicaset wordt één voor één geroteerd. Dwz

   mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

   Nadat het proces is voltooid, wordt mongod afgesloten en moet u de secundaire opnieuw starten zonder de kmipRotateMasterKey-parameter

   mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

2. De primaire replicaset wordt verlaagd:
   Met behulp van de rs.stepDown()-methode wordt de primaire gedeactiveerd, waardoor een verkiezing van een nieuwe primaire wordt geforceerd.

3. Controleer de status van de knooppunten met behulp van de methode rs.status() en als de primaire aangeeft dat deze is teruggetreden, roteert u de hoofdsleutel ervan. Herstart het afgetreden lid inclusief de kmipRotateMasterKey-optie.

   mongod --enableEncryption --kmipRotateMasterKey \
     --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Logboekregistratie

MongoDB werkt altijd met een logbestand voor het vastleggen van bepaalde status of gespecificeerde informatie met verschillende tussenpozen.

Het logbestand is echter niet versleuteld als onderdeel van de opslagengine. Dit brengt het risico met zich mee dat een mongod-instantie die met logboekregistratie wordt uitgevoerd, potentieel gevoelige gegevens naar de logbestanden kan sturen, net als onderdeel van de normale logboekregistratie.

Vanaf de MongoDB-versie 3.4 is er de security.redactClientLogData-instelling die voorkomt dat mogelijk gevoelige gegevens worden vastgelegd in het mongod-proceslogboek. Deze optie kan de logdiagnose echter bemoeilijken.

Encryptieprestaties in MongoDB

Versleuteling resulteert op een gegeven moment in een verhoogde latentie, waardoor de prestaties van een database afnemen. Dit is meestal het geval als het om een ​​grote hoeveelheid documenten gaat.

Coderen en decoderen vereisen meer middelen en daarom is het belangrijk om deze relatie te begrijpen om de capaciteitsplanning dienovereenkomstig aan te passen.

Wat betreft de MongoDB-tests, zal een versleutelde opslagengine een latentie ervaren van tussen de 10% en 20% bij de hoogste belasting. Dit is vaak het geval wanneer een gebruiker een grote hoeveelheid gegevens naar de database schrijft, wat resulteert in verminderde prestaties. Voor leesbewerkingen is de prestatievermindering verwaarloosbaar, ongeveer 5 - 10%.

Voor een betere coderingspraktijk in MongoDB heeft de WiredTiger-opslagengine de meeste voorkeur vanwege de hoge prestaties, beveiliging en schaalbaarheid. Verder optimaliseert het de codering van databasebestanden tot op paginaniveau, wat een grote verdienste is dat, als een gebruiker gegevens leest of schrijft naar de gecodeerde database, de doorvoerbewerking alleen wordt toegepast op de pagina waarop de gegevens zijn opgeslagen in plaats van op de hele database.

Dit vermindert de hoeveelheid gegevens die moet worden versleuteld en ontsleuteld voor het verwerken van een enkel stuk gegevens.

Samenvatting

Gegevensbeveiliging voor gevoelige informatie is een must en het is nodig om deze te beschermen zonder de prestaties van het databasesysteem te verminderen.

MongoDB biedt robuuste native coderingsprocedures die ons kunnen helpen onze gegevens zowel in rust als in beweging te beveiligen. Daarnaast dienen de encryptie procedures te voldoen aan de gestelde standaarden door verschillende organisaties.

De geavanceerde WiredTiger-opslagengine biedt een betere optie vanwege de bijbehorende voordelen, zoals hoge prestaties, schaalbaarheid en beveiliging. Bij het versleutelen van gegevens in replicasets is het een goede gewoonte om voor elk verschillende hoofdsleutels te gebruiken, naast deze minstens één keer per jaar te wijzigen.

Ondanks de beschikbaarheid van versleutelingsopties van derden, is er geen garantie dat uw implementatie ook qua schaalbaarheid met hen zal overeenkomen. Het is dus heel verstandig om codering op databaseniveau te gebruiken.