En oversigt over feltniveaukryptering på klientsiden i MongoDB

Data kræver ofte avanceret sikkerhed på næsten alle niveauer af datatransaktionen for at overholde sikkerhedspolitikker, overholdelse og regeringsbestemmelser. Organisationens omdømme kan blive ødelagt, hvis der er uautoriseret adgang til følsomme data, og dermed manglende overholdelse af det skitserede mandat.

I denne blog vil vi diskutere nogle af de sikkerhedsforanstaltninger, du kan anvende i forhold til MongoDB, især med fokus på klientsiden af ​​tingene.

Scenarier, hvor data kan tilgås

Der er flere måder, nogen kan få adgang til dine MongoDB-data, her er nogle af dem...

1. Optagelse af data over et usikkert netværk. Nogen kan få adgang til dine data gennem en API med et VPN-netværk, og det vil være svært at spore dem. Data i hvile er ofte synderen i denne sag.
2. En superbruger, såsom en administrator, der har direkte adgang. Dette sker, når du undlader at definere brugerroller og begrænsninger.
3. At have adgang til data på disken, mens du læser databaser med backupfiler.
4. Læser serverhukommelsen og loggede data.
5. Medarbejderens utilsigtede videregivelse af data.

MongoDB-datakategorier og hvordan de er sikret

Generelt involverer ethvert databasesystem to typer data: 

1. Data-at-rest :En, der er gemt i databasefilerne
2. Data-in-transit:En, der udføres mellem en klient, server og databasen.

MongoDB har en Encryption at Rest-funktion, der krypterer databasefiler på disken og dermed forhindrer adgang til databasefiler på disken.

Data-in-transit over et netværk kan sikres i MongoDB gennem Transport Encryption ved hjælp af TLS/SSL ved at kryptere dataene.

I tilfælde af, at data ved et uheld bliver afsløret af en medarbejder, f.eks. en receptionist på skrivebordsskærmen, integrerer MongoDB den rollebaserede adgangskontrol, der giver administratorer mulighed for at give og begrænse tilladelse på samlingsniveau for brugere.

Data, der udføres over serveren, kan forblive i hukommelsen, og disse tilgange løser ikke på noget tidspunkt sikkerhedsproblemet mod dataadgang i serverhukommelsen. MongoDB introducerede derfor Client-Side Field Level Encryption til kryptering af specifikke felter i et dokument, der involverer fortrolige data.

Kryptering på feltniveau

MongoDB arbejder med dokumenter, der har definerede felter. Nogle felter kan være påkrævet for at opbevare fortrolige oplysninger såsom kreditkortnummer, personnummer, tålmodighedsdiagnosedata og meget mere.

Kryptering på feltniveau gør det muligt for os at sikre felterne, og de kan kun tilgås af autoriseret personale med dekrypteringsnøglerne.

Kryptering kan udføres på to måder

1. Brug af en hemmelig nøgle. En enkelt nøgle bruges til både kryptering og dekryptering, og den skal derfor præsenteres ved kilde- og destinationstransmission, men holdes hemmelig af alle parter.
2. Brug af en offentlig nøgle. Bruger et par nøgler, hvorved den ene bruges til at kryptere og den anden bruges til at dekryptere

Når du anvender feltniveaukryptering, skal du overveje at bruge en ny databaseopsætning i stedet for en eksisterende.

Client-Side Field Level Encryption (CSFLE)

Introduceret i MongoDB version 4.2 Enterprise for at tilbyde databaseadministratorer en justering for at kryptere felter, der involverer værdier, der skal sikres. Det vil sige, at de følsomme data krypteres eller dekrypteres af klienten og kun kommunikeres til og fra serveren i en krypteret form. Desuden vil selv superbrugere, der ikke har krypteringsnøglerne, ikke have kontrol over disse krypterede datafelter.

Sådan implementeres CSFLE

For at du kan implementere feltniveaukryptering på klientsiden, skal du have følgende:

1. MongoDB Server 4.2 Enterprise
2. MongoDB  Kompatibel med CSFLE
3. Filsystemtilladelser
4. Specifikke sprogdrivere. (I vores blog skal vi bruge Node.js)

Implementeringsproceduren involverer:

• Et lokalt udviklingsmiljø med en software til at køre klient og server
• Generering og validering af krypteringsnøglerne.
• Konfiguration af klienten til automatisk kryptering på feltniveau
• Gennemgående operationer i form af forespørgsler i de krypterede felter.

CSFLE-implementering

CSFLE bruger konvolutkrypteringsstrategien, hvor datakrypteringsnøgler krypteres med en anden nøgle kendt som hovednøglen. Klientapplikationen opretter en hovednøgle, der er lagret i den lokale nøgleudbyder, i det væsentlige det lokale filsystem. Denne lagringstilgang er imidlertid usikker, og derfor anbefales det i produktionen at konfigurere nøglen i et nøglestyringssystem (KMS), der gemmer og fjerndekrypterer datakrypteringsnøgler.

Efter at datakrypteringsnøglerne er genereret, gemmes de i vault-samlingen i det samme MongoDB-replikasæt som de krypterede data.

Opret hovednøgle

I node js skal vi generere en 96-byte lokalt administreret hovednøgle og skrive den til en fil i den mappe, hvor hovedscriptet udføres fra: 

$npm installer fs &&npm installer krypto 

Så i scriptet:

const crypto =require(“crypto”)const fs =require(“fs”)try{fs.writeFileSync('masterKey.txt', crypto.randomBytes(96))}catch(err){throw fejl; 

Opret datakrypteringsnøgle

Denne nøgle er gemt i en nøglebokssamling, hvor CSFLE-aktiverede klienter kan få adgang til nøglen til kryptering/dekryptering. For at generere en, skal du bruge følgende:

• Lokalt administreret hovednøgle
• Forbindelse til din database, dvs. MongoDB-forbindelsesstrengen
• Nøgleboksnavneområde (database og samling)

Trin til at generere datakrypteringsnøglen

1. Læs den lokale hovednøgle generere før

const localMasterKey =fs.readFileSync(‘./masterKey.txt’); 

2. Specificer de KMS-udbyderindstillinger, der skal bruges af klienten til at finde hovednøglen.

const kmsProvider ={local:{key:localMasterKey}} 

3. Oprettelse af datakrypteringsnøglen. Vi er nødt til at oprette en klient med MongoDB-forbindelsesstrengen og nøglehvælvings-navneområdekonfigurationen. Lad os sige, at vi vil have en database kaldet brugere og inde i den en keyVault-samling. Du skal først installere uuid-base64 ved at køre kommandoen

$ npm installer uuid-base64 

Så i dit script

const base64 =require('uuid-base64');const keyVaultNamespace ='users.keyVaul';const client =new MongoClient('mongodb://localhost:27017', { useNewUrlParser:true, useUnifiedTopology:true,});async-funktion createKey() { prøv { await client.connect(); const encryption =new ClientEncryption(client, { keyVaultNamespace, kmsProvider, }); const nøgle =afvent encryption.createDataKey('local'); const base64DataKeyId =key.toString('base64'); const uuidDataKeyId =base64.decode(base64DataKeyId); console.log('DataKeyId [UUID]:', uuidDataKeyId); console.log('DataKeyId [base64]:', base64DataKeyId); } endelig { await client.close(); }}createKey(); 

Du vil derefter blive præsenteret for et resultat, der ligner

DataKeyId [UUID]:ad4d735a-44789-48bc-bb93-3c81c3c90824DataKeyId [base64]:4K13FkSZSLy7kwABP4HQyD== 

Klienten skal have ReadWrite-tilladelser på det angivne nøgleboksnavneområde

4. For at bekræfte, at datakrypteringsnøglen blev oprettet

const client =new MongoClient('mongodb://localhost:27017', { useNewUrlParser:true, useUnifiedTopology:true,});async function checkClient() { try { await client.connect(); const nøgleDB =klient.db(brugere); const keyColl =keyDB.collection(keyVault); const forespørgsel ={ _id:‘4K13FkSZSLy7kwaABP4HQyD==’, }; const dataKey =afvent keyColl.findOne(query); console.log(datanøgle); } endelig { await client.close(); }}checkClient(); 

Du burde modtage et eller andet resultat af den slags

{ "bsonType" :"object", "encryptMetadata" :{ "keyId" :// keyId generated here }, "properties":{// field schemas here }} 

"bankAccountNumber":{ "encrypt":{ "bsonType":"int", "algorithm":"AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic" }} 

{…"bankAccountNumber":"Ac+ZbPM+sk7gl7CJCcIzlRAQUJ+uo/0WhqX+KbTNdhqCszHucqXNiwqEUjkGlh7gK8pm2JhIs/P3//nkVP0dWu8pSsfU0Tjpc=NWP3//nkVP0dWu8pSsfU0Tjn… 

{…"bankAccountNumber":43265436456456456756,...}