Hur man använder kryptering för att skydda dina MongoDB-data

Databassäkerhet är en nyckelfaktor att överväga för alla applikationer som involverar mycket känsliga uppgifter som ekonomi- och hälsorapporter. Dataskydd kan uppnås genom kryptering på olika nivåer från själva applikationen till filer som innehåller data.

Eftersom MongoDB är en icke-relationell databas, behöver man inte definiera kolumner innan man infogar data; och därför kan dokument i samma samling ha olika fält från varandra.

Å andra sidan, för SQL DBMS, måste man definiera kolumner för data, därför har alla rader samma kolumner. Man kan bestämma sig för att kryptera enskilda kolumner, hela databasfilen eller data från applikationen innan man involveras i databasprocessen.

Kryptering av enskilda kolumner är mest att föredra eftersom det är billigare och mindre data krypteras vilket förbättrar latensen. Generellt sett påverkar den övergripande prestandan som ett resultat av krypteringen.

För NoSQL DBMS kommer detta tillvägagångssätt dock inte att vara det bästa. Med tanke på att inte alla dokument kanske har alla fält du vill använda i din kryptering, kan kryptering på kolumnnivå inte utföras.

Att kryptera data på applikationsnivå är ganska kostsamt och svårt att implementera. Vi har därför kvar en möjlighet att kryptera data på databasnivå.

MongoDB tillhandahåller inbyggd kryptering som inte kräver att man betalar en extra kostnad för att säkra dina känsliga data.

Kryptera data i MongoDB

Alla databasoperationer involverar någon av dessa två dataformer, data i vila eller data i rörelse.

Data i rörelse är en ström av data som rör sig genom alla typer av nätverk medan data i vila är statisk och därför inte rör sig någonstans.

Båda dessa två datatyper är utsatta för extern störning av anonyma användare, om inte kryptering är inblandad. Krypteringsprocessen innefattar:

Genererar en huvudnyckel för hela databasen
Genererar unika nycklar för varje databas
Kryptera dina data med de databasnycklar du skapade
Kryptering av hela databasen med huvudnyckeln

Kryptering av data under transport

Data överförs mellan MongoDB och serverapplikationen på två sätt, det vill säga genom Transport Layer Security (TLS) och Secure Socket Layer (SSL).

Dessa två är de mest använda krypteringsprotokollen för att säkra skickade och mottagna data mellan två system. I grund och botten är konceptet att kryptera anslutningar till mongod- och mongos-instanserna så att nätverkstrafiken endast kan läsas av den avsedda klienten.

TLS/SSL används i MongoDB med vissa certifikat som PEM-filer som är utfärdade av certifikatutfärdaren eller kan vara ett självsignerat certifikat. Den senare har en begränsning i det att hur kommunikationskanalen än är krypterad, finns det alltid ingen validering mot serveridentiteten och är därför sårbar för externa attacker halvvägs. Det är därför tillrådligt att använda betrodda auktoritetscertifikat som tillåter MongoDB-drivrutiner att också verifiera serveridentiteten.

Förutom kryptering kan TLS/SSL användas i autentiseringen av klienten och interna autentiseringar av medlemmar av replikuppsättningar och fragmenterade kluster genom certifikaten.

TLS/SSL-konfiguration för klienter

Det finns olika TLS/SSL-alternativinställningar som kan användas i konfigurationen av dessa protokoll.

Om du till exempel vill ansluta till en Mongod-instans med kryptering, skulle du starta din instans som,

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

--ssl aktiverar TLS/SSL-anslutningen.

--sslCAFile anger certifikatmyndighetens (CA) pem-fil för verifiering av certifikatet som presenteras av mongoden eller mongonerna. Mongo-skalet kommer därför att verifiera certifikatet som utfärdats av mongod-instansen mot den angivna CA-filen och värdnamnet.

Du kanske också vill ansluta MongoDB-instans som kräver ett klientcertifikat. Vi använder kodexemplet nedan

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

Alternativet --sslPEMKeyFile anger .pem-filen som innehåller mongo-skalcertifikatet och en nyckel som ska presenteras för mongod- eller mongos-instansen. Under anslutningsprocessen:

Mongo-skalet kommer att verifiera om certifikatet är från den angivna certifikatutfärdaren som är (--sslCAFile) och om inte kommer skalet att misslyckas med att ansluta.

För det andra kommer skalet också att verifiera om värdnamnet som anges i --host-alternativet matchar SAN/CN i certifikatet som presenteras av mongoden eller mongonerna. Om detta värdnamn inte matchar någon av de två, kommer anslutningen att misslyckas.

Om du inte vill använda självsignerade certifikat måste du se till att anslutningsnätverket är pålitligt.

Dessutom måste du minska exponeringen av privata nyckel, särskilt där replikuppsättningar/delad kluster är inblandat. Detta kan uppnås genom att använda olika certifikat på olika servrar.

Ytterligare alternativ som kan användas i anslutningarna är:

kräverSSL:detta begränsar varje server att endast använda TLS/SSL-krypterade anslutningar.

--sslAllowConnectionsWithoutCertificates:Detta tillåter validering om bara klienten presenterar ett certifikat, annars om det inte finns något certifikat kommer klienten fortfarande att vara ansluten i ett krypterat läge. Till exempel:

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

sslDisabledProtocols:detta alternativ förhindrar servrar från att acceptera inkommande anslutningar som använder specifika protokoll. Detta kan göras med:

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

Kryptering av data i vila

Från version 3.2 introducerade MongoDB ett inbyggt krypteringsalternativ för WiredTiger-lagringsmotorn. Åtkomst till data i denna lagring av en tredje part kan endast uppnås genom en dekrypteringsnyckel för att avkoda data till ett läsbart format.

Den vanligaste krypteringsalgoritmen i MongoDB är AES256-GCM. Den använder samma hemliga nyckel för att kryptera och dekryptera data. Krypteringsburken aktiveras med FIPS-läget vilket säkerställer att krypteringen uppfyller högsta standard och efterlevnad.

Hela databasfilerna krypteras med Transparent data Encryption (TDE) på lagringsnivå.

Närhelst en fil krypteras genereras en unik privat krypteringsnyckel som är bra för att förstå hur dessa nycklar hanteras och lagras. Alla databasnycklar som genereras krypteras därefter med en huvudnyckel.

Skillnaden mellan databasnycklarna och huvudnyckeln är att databasnycklarna kan lagras vid sidan av den krypterade datan i sig, men för huvudnyckeln rekommenderar MongoDB att den lagras på en annan server än den krypterade informationen, såsom tredje parts företagsnyckel. hanteringslösningar.

Med replikerad data delas inte krypteringskriterierna med de andra noderna eftersom data inte är inbyggt krypterad över tråden. Man kan återanvända samma nyckel för noderna, men bästa praxis är att använda unika individuella nycklar för varje nod.

Roterande krypteringsnycklar

Hanterad nyckel som används för att dekryptera känslig data bör roteras eller bytas ut minst en gång om året. Det finns två alternativ i MongoDB för att uppnå rotationen.

KMIP Master Rotation

I det här fallet ändras endast huvudnyckeln eftersom den hanteras externt. Processen för att vrida nyckeln är som beskrivs nedan.

Huvudnyckeln för de sekundära delarna i replikuppsättningen roteras en i taget. Dvs

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

När processen är klar kommer mongod att avslutas och du måste starta om den sekundära utan parametern kmipRotateMasterKey

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

Den primära replikuppsättningen avvecklas:
Med rs.stepDown()-metoden avaktiveras primärvalet, vilket tvingar fram ett val av ett nytt primärval.
Kontrollera statusen för noderna med metoden rs.status() och om den primära indikerar att den har trappats ned, rotera dess huvudnyckel. Starta om den avvecklade medlemmen inklusive alternativet kmipRotateMasterKey.
```
mongod --enableEncryption --kmipRotateMasterKey \
  --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```

Loggning

MongoDB arbetar alltid med en loggfil för att registrera viss status eller specificerad information vid olika intervall.

Loggfilen är dock inte krypterad som en del av lagringsmotorn. Detta utgör en risk genom att en mongod-instans som körs med loggning kan mata ut potentiellt känslig data till loggfilerna precis som en del av den normala loggningen.

Från MongoDB version 3.4 finns inställningen security.redactClientLogData som förhindrar att potentiellt känslig data loggas i mongod processloggen. Det här alternativet kan dock komplicera loggdiagnostiken.

Severalnines Become a MongoDB DBA - Bringing MongoDB to ProductionLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala MongoDBDownload gratis

Krypteringsprestanda i MongoDB

Kryptering vid något tillfälle resulterar i ökad latens, vilket försämrar prestandan hos en databas. Detta är vanligtvis fallet när en stor mängd dokument är inblandade.

Kryptering och dekryptering kräver mer resurser och är därför viktigt för att förstå detta förhållande för att kunna anpassa kapacitetsplaneringen därefter.

När det gäller MongoDB-testerna kommer en krypterad lagringsmotor att uppleva en latens på mellan 10 % till 20 % vid högsta belastning. Detta är ofta fallet när en användare skriver en stor mängd data till databasen vilket resulterar i minskad prestanda. För läsoperationer är prestandaförsämringen försumbar, cirka 5 - 10 %.

För en bättre krypteringspraxis i MongoDB är WiredTiger-lagringsmotorn mest föredragen på grund av dess höga prestanda, säkerhet och skalbarhet. Vidare optimerar den kryptering av databasfiler till sidnivå, vilket har stor förtjänst genom att om en användare läser eller skriver data till den krypterade databasen, kommer genomströmningsoperationen endast att tillämpas på sidan där data lagras snarare än hela databas.

Detta kommer att minska mängden data som behöver krypteras och dekrypteras för att bearbeta en enskild databit.

Sammanfattning

Datasäkerhet för känslig information är ett måste och det finns ett behov av att skydda den utan att försämra databassystemets prestanda.

MongoDB tillhandahåller en robust inbyggd krypteringsprocedurer som kan hjälpa oss att säkra vår data både i vila och i rörelse. Dessutom bör krypteringsprocedurerna följa uppställda standarder av olika organisationer.

Den avancerade WiredTiger-lagringsmotorn ger ett bättre alternativ på grund av dess tillhörande fördelar som hög prestanda, skalbarhet och säkerhet. När du krypterar data i replikuppsättningar är det en god praxis att använda olika huvudnycklar för var och en förutom att ändra dem minst en gång om året.

Men tillgången på krypteringsalternativ från tredje part, det finns ingen garanti för att din distribution kommer att matcha dem när det gäller skalbarhet. Det är därför mycket hänsynsfullt att använda kryptering på databasnivå.