Sådan bruger du kryptering til at beskytte dine MongoDB-data

Databasesikkerhed er en nøglefaktor at overveje for enhver applikation, der involverer meget følsomme data, såsom økonomiske og sundhedsmæssige rapporter. Databeskyttelse kan opnås gennem kryptering på forskellige niveauer fra selve applikationen til filer, der indeholder dataene.

Da MongoDB er en ikke-relationel database, behøver man ikke at definere kolonner før indsættelse af data; og derfor kunne dokumenter i samme samling have forskellige felter fra hinanden.

På den anden side, for SQL DBMS, skal man definere kolonner for dataene, derfor har alle rækkerne de samme kolonner. Man kan beslutte at kryptere individuelle kolonner, hele databasefilen eller data fra applikationen, før man bliver involveret i databaseprocessen.

Kryptering af individuelle kolonner er mest foretrukket, da det er billigere og færre data krypteres, hvilket forbedrer latenstiden. Generelt påvirker den overordnede ydeevne som et resultat af krypteringen.

For NoSQL DBMS vil denne tilgang dog ikke være den bedste. I betragtning af, at ikke alle dokumenter har alle de felter, du vil bruge i din kryptering, kan kryptering på kolonneniveau ikke udføres.

Kryptering af data på applikationsniveau er ret dyrt og vanskeligt at implementere. Vi har derfor fortsat muligheden for at kryptere data på databaseniveau.

MongoDB leverer indbygget kryptering, som ikke kræver, at man betaler en ekstra omkostning for at sikre dine følsomme data.

Kryptering af data i MongoDB

Enhver databaseoperation involverer en af ​​disse to dataformer, data i hvile eller data i bevægelse.

Data i bevægelse er en strøm af data, der bevæger sig gennem enhver form for netværk, hvorimod hvilende data er statiske og derfor ikke bevæger sig nogen steder.

Begge disse to datatyper er tilbøjelige til ekstern interferens fra anonyme brugere, medmindre kryptering er involveret. Krypteringsprocessen involverer:

• Generering af en hovednøgle til hele databasen
• Generering af unikke nøgler til hver database
• Kryptering af dine data med de databasenøgler, du genererede
• Kryptering af hele databasen med hovednøglen

Kryptering af data under transport

Data overføres mellem MongoDB og serverapplikationen på to måder, det vil sige gennem Transport Layer Security (TLS) og Secure Socket Layer (SSL).

Disse to er de mest brugte krypteringsprotokoller til sikring af sendte og modtagne data mellem to systemer. Grundlæggende er konceptet at kryptere forbindelser til mongod- og mongo-forekomsterne, således at netværkstrafikken kun kan læses af den tilsigtede klient.

TLS/SSL bruges i MongoDB med nogle certifikater som PEM-filer, der er udstedt af certifikatmyndigheden eller kan være et selvsigneret certifikat. Sidstnævnte har en begrænsning ved, at uanset hvor kommunikationskanalen er krypteret, er der altid ingen validering mod serveridentiteten og er derfor sårbar over for eksterne angreb midtvejs. Det er derfor tilrådeligt at bruge betroede myndighedscertifikater, som tillader MongoDB-drivere også at verificere serverens identitet.

Udover kryptering kan TLS/SSL bruges til godkendelse af klienten og interne godkendelser af medlemmer af replikasæt og sharded clusters gennem certifikaterne.

TLS/SSL-konfiguration for klienter

Der er forskellige TLS/SSL-indstillinger, der kan bruges i konfigurationen af ​​disse protokoller.

For eksempel, hvis du vil oprette forbindelse til en Mongod-instans ved hjælp af kryptering, vil du starte din instans som,

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

--ssl aktiverer TLS/SSL-forbindelsen.

--sslCAFile specificerer certifikatmyndighedens (CA) pem-fil til verifikation af certifikatet præsenteret af mongoden eller mongoerne. Mongo-skallen vil derfor verificere certifikatet udstedt af mongod-instansen mod den angivne CA-fil og værtsnavnet.

Du vil måske også forbinde MongoDB-instans, der kræver et klientcertifikat. Vi bruger kodeeksemplet nedenfor

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

Valgmuligheden --sslPEMKeyFile angiver .pem-filen, der indeholder mongo shell-certifikatet og en nøgle, der skal præsenteres for mongod- eller mongos-instansen. Under forbindelsesprocessen:

Mongo-skallen vil bekræfte, om certifikatet er fra den specificerede certifikatmyndighed, som er (--sslCAFile), og hvis ikke, vil shellen ikke kunne oprette forbindelse.

For det andet vil skallen også verificere, om værtsnavnet angivet i --host-indstillingen matcher SAN/CN i certifikatet præsenteret af mongoden eller mongoerne. Hvis dette værtsnavn ikke matcher nogen af ​​de to, vil forbindelsen mislykkes.

Hvis du ikke vil bruge selvsignerede certifikater, skal du sikre dig, at forbindelsesnetværket er tillid til.

Desuden er du nødt til at reducere eksponeringen af ​​private nøgler, især hvor replikasæt/sharded cluster er involveret. Dette kan opnås ved at bruge forskellige certifikater på forskellige servere.

Yderligere muligheder, der kan bruges i forbindelserne er:

requireSSL:dette vil begrænse hver server til kun at bruge TLS/SSL-krypterede forbindelser.

--sslAllowConnectionsWithoutCertificates:Dette tillader validering, hvis kun klienten præsenterer et certifikat ellers, hvis der ikke er noget certifikat, vil klienten stadig være forbundet i en krypteret tilstand. For eksempel:

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

sslDisabledProtocols:denne indstilling forhindrer servere i at acceptere indgående forbindelser, der bruger specifikke protokoller. Dette kan gøres med:

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

Kryptering af data i hvile

Fra version 3.2 introducerede MongoDB en indbygget krypteringsmulighed for WiredTiger-lagringsmotoren. Adgang til data i dette lager af en tredjepart kan kun opnås gennem en dekrypteringsnøgle til afkodning af data til et læsbart format.

Den almindeligt anvendte krypteringsalgoritme i MongoDB er AES256-GCM. Den bruger den samme hemmelige nøgle til at kryptere og dekryptere data. Krypteringsdåse er slået til ved hjælp af FIPS-tilstand, hvilket sikrer, at krypteringen opfylder den højeste standard og overholdelse.

Hele databasefilerne krypteres ved hjælp af Transparent data-kryptering (TDE) på lagerniveau.

Når en fil krypteres, genereres en unik privat krypteringsnøgle, som er god til at forstå, hvordan disse nøgler administreres og opbevares. Alle de genererede databasenøgler krypteres derefter med en hovednøgle.

Forskellen mellem databasenøglerne og hovednøglen er, at databasenøglerne kan gemmes sammen med selve de krypterede data, men for hovednøglen anbefaler MongoDB, at den gemmes på en anden server end de krypterede data, såsom tredjeparts virksomhedsnøgle ledelsesløsninger.

Med replikerede data deles krypteringskriterierne ikke med de andre noder, da dataene ikke er indbygget krypteret over ledningen. Man kan genbruge den samme nøgle til noderne, men den bedste praksis er at bruge unikke individuelle nøgler for hver node.

Roterende krypteringsnøgler

Administreret nøgle, der bruges til at dekryptere følsomme data, bør roteres eller udskiftes mindst én gang om året. Der er to muligheder i MongoDB for at opnå rotationen.

KMIP Master Rotation

I dette tilfælde er det kun hovednøglen, der ændres, da den styres eksternt. Processen til at dreje nøglen er som beskrevet nedenfor.

1. Hovednøglen til de sekundære elementer i replikasættet roteres én ad gangen. Dvs.

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

   Når processen er afsluttet, vil mongod afslutte, og du bliver nødt til at genstarte den sekundære uden parameteren kmipRotateMasterKey

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

2. Det primære replikasæt trappes ned:
   Ved at bruge rs.stepDown()-metoden deaktiveres det primære, hvilket tvinger et valg af et nyt primærvalg.

3. Kontroller status for noderne ved hjælp af rs.status() metoden, og hvis den primære indikerer at være blevet trappet ned, roter dens hovednøgle. Genstart det nedtrappede medlem inklusive muligheden kmipRotateMasterKey.

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

Logføring

MongoDB arbejder altid med en logfil til registrering af status eller specificeret information med forskellige intervaller.

Logfilen er dog ikke krypteret som en del af lagermotoren. Dette udgør en risiko ved, at en mongod-instans, der kører med logning, kan udsende potentielt følsomme data til logfilerne ligesom en del af den normale logning.

Fra MongoDB version 3.4 er der indstillingen security.redactClientLogData, som forhindrer potentielt følsomme data i at blive logget i mongod procesloggen. Denne mulighed kan dog komplicere logdiagnostikken.

Krypteringsydelse i MongoDB

Kryptering resulterer på et tidspunkt i øget latenstid og forringer dermed ydeevnen af ​​en database. Dette er normalt tilfældet, når der er tale om en stor mængde dokumenter.

Kryptering og dekryptering kræver flere ressourcer, og det er derfor vigtigt at forstå dette forhold for at tilpasse kapacitetsplanlægningen i overensstemmelse hermed.

Med hensyn til MongoDB-testene vil en krypteret lagermotor opleve en latenstid på mellem 10% til 20% ved den højeste belastning. Dette er ofte tilfældet, når en bruger skriver en stor mængde data til databasen, hvilket resulterer i reduceret ydeevne. For læseoperationer er ydeevneforringelsen ubetydelig, omkring 5 - 10 %.

For en bedre krypteringspraksis i MongoDB er WiredTiger-lagringsmotoren mest foretrukket på grund af dens høje ydeevne, sikkerhed og skalerbarhed. Ydermere optimerer det kryptering af databasefiler til sideniveau, hvilket har stor fordel ved, at hvis en bruger læser eller skriver data til den krypterede database, vil gennemløbsoperationen kun blive anvendt på den side, hvor dataene er lagret, i stedet for hele database.

Dette vil reducere mængden af ​​data, der skal krypteres og dekrypteres for at behandle et enkelt stykke data.

Oversigt

Datasikkerhed for følsomme oplysninger er et must, og der er behov for at beskytte dem uden at forringe databasesystemets ydeevne.

MongoDB leverer en robust indbygget krypteringsprocedure, der kan hjælpe os med at sikre vores data både i hvile og i bevægelse. Desuden bør krypteringsprocedurerne overholde de fastsatte standarder af forskellige organisationer.

Den avancerede WiredTiger-lagringsmotor giver en bedre mulighed på grund af dens tilknyttede fordele såsom høj ydeevne, skalerbarhed og sikkerhed. Når du krypterer data i replikasæt, er det en god praksis at bruge forskellige hovednøgler for hver udover at ændre dem mindst en gang om året.

Men tilgængeligheden af ​​tredjepartskrypteringsmuligheder, er der ingen garanti for, at din implementering vil matche sammen med dem med hensyn til skalerbarhed. Det er derfor ret hensynsfuldt at anvende kryptering på databaseniveau.