MongoDB-usikkerhedsniveauer og hvordan man undgår dem

De fleste databasestyringssystemer har flere teknikker til at sikre deres data fra en udefrakommende eller en uautoriseret person eller applikation. Teknikkerne forhindrer dine data i at blive læst eller kopieret uden brugerens tilladelse.

MongoDB er ikke anderledes, da den har nogle usikkerhedsniveauer. I dette blogindlæg vil vi diskutere usikkerhedsniveauerne i MongoDB, og hvordan du undgår dem, så du kan beskytte din MongoDB-installation.

Af hensyn til sikkerheden og sikkerheden for din MongoDB er følgende nogle af de vigtigste sikkerhedsforanstaltninger, du bør overveje nøje:
 

1. Godkendelse af brugerforbindelser.

2. Autorisation/rollebaseret adgangskontrol.

3. Netværkskryptering/transportkryptering.

4. Storage Encryption/ Encryption-at-rest.

5. Revision.

I denne artikel vil vi se på ovenstående sikkerhedsforanstaltninger i detaljer med meget fokus på godkendelse og autorisation.

Godkendelse og godkendelse

Godkendelse og godkendelse skal aktiveres i forening. De kan dog bruges uafhængigt af hinanden. Godkendelse forhindrer adgang til en ukendt person, som har netværksadgang til databaseserveren, i at kopiere eller beskadige databasedataene. Godkendelse kræver, at alle klienter og servere angiver gyldige legitimationsoplysninger, før de kan oprette forbindelse til systemet. Autorisation forhindrer på den anden side en applikation eller en bruger i at læse, ændre eller slette andre data end hvad de skulle.

For at konfigurere rollebaseret adgangskontrol;

1. Opret en brugeradministrator først.

2. Opret yderligere brugere.

3. Opret derefter en unik MongoDB-bruger for hver person/applikation, der får adgang til systemet.

4. Ved at følge princippet om mindste privilegium bør du oprette roller, der definerer de nøjagtige adgangsrettigheder, der kræves af et sæt af brugere.

5. Tildel derefter brugerne kun de roller, de skal udføre i deres operationer. En bruger kan være en klientapplikation eller en person.

Du skal bemærke, at en bruger kan have privilegier på tværs af forskellige eller flere databaser. I det scenarie, i stedet for at oprette en bruger flere gange i forskellige databaser, skal du oprette en enkelt bruger med roller, der giver relevante databaserettigheder.

Ofte kan disse to sikkerhedsforanstaltninger forveksles til at betyde det samme. I nogle scenarier ligner de hinanden, men de er også forskellige.

Ligheder mellem godkendelse og autorisation

• Begge er noget af en enkelt enhed, fordi når du aktiverer godkendelse, aktiveres autorisation automatisk. Autorisation er aktiveret i samklang med godkendelse, hvorfor forbindelser fra ukendte brugere ikke har rettigheder til at få adgang til databasedata. Godkendelse kræver også, at brugernavnet skal verificeres af godkendelse for at vide, hvilke privilegier der gælder for en forbindelses anmodninger. Derfor kan den heller ikke aktiveres uafhængigt af den anden.

• De er også begge ens i uheldig, ældre navngivning af konfigurationsmuligheder. Konfigurationsfilmuligheden for godkendelse er security.authorization i stedet for sikkerhedsgodkendelse, som det ville forventes. Når du bruger kommandoen, er godkendelse den første, der aktiveres, og autorisation er kun aktiveret som en eftervirkning. "-auth" er kommandolinjeargumentet for at aktivere godkendelse, som automatisk tvinger autorisation til også at være aktiveret.

Forskelle mellem godkendelse og autorisation

• Disse to er forskellige, fordi de er to dele af softwaren, der har forskellige funktioner.

Godkendelse ==Brugeridentitet ved hjælp af legitimationskontrol.

Autorisation ==Tildeling og håndhævelse af DB-objekt- og DB-kommandotilladelser.

• Under den indledende opsætning er godkendelse deaktiveret for lokale værtsforbindelser. Dette er dog kort, da du får én mulighed for at oprette den første bruger, så er undtagelsesprivilegiet (fra reglen om godkendelse og autorisation på sammen) slettet.

Sådan kontrollerer du, om godkendelse og godkendelse er aktiveret eller ej

De første versioner af MongoDB havde "- auth" indstillet som standard, og dette betragtes bredt som et dårligt træk. Selv i version 4.0 var den stadig slået fra som standard. Tom konfiguration svarer stadig til, at autorisation er slået fra på trods af opstartsadvarsler og forskellige eksponeringsreduktioner såsom localhost bliver den eneste standardbundne netværksenhed i MongoDB v3.6.

Du bruger ikke godkendelse, eller rettere sagt, du har ikke godkendelse aktiveret, hvis mongod-konfigurationsfilerne ikke gør det:

1. Få security.authorization sat til 'enabled'.

2. Inkluder en security.key-fil.

3. Inkluder en security.clusterAuthMode-indstilling, som tvinger godkendelse til at være aktiveret.

For at dobbelttjekke, om du har autentificering og autorisation aktiveret eller ej, kan du prøve denne hurtige mongo shell one-liner (uden brugerlegitimationsargumenter indstillet):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

Det svar, du skulle få, er en "uautoriseret" fejl. Men på den anden side, hvis du får en liste over databasenavne, betyder det automatisk, at du har en nøgen MongoDB-implementering.

Ekstern godkendelse

Som navnet antyder, handler ekstern autentificering om at tillade brugere at blive autentificeret i en ekstern tjeneste. Som en undtagelse kan den ikke bruges til den interne mongodb __-systembruger, men at bruge den til enhver ægte menneskelig bruger eller klientapplikationstjenestekonto er perfekt egnet.

Simpelthen vil den eksterne godkendelsestjeneste være en Kerberos KDC eller en ActiveDirectory- eller OpenLDAP-server. Du skal bemærke, at brug af ekstern godkendelse ikke forhindrer dig i at have almindelige MongoDB-brugerkonti på samme tid.

Intern godkendelse

Tværtimod betyder MongoDB intern godkendelse ikke det modsatte af ekstern godkendelse. Dette skyldes, at en mongod-knude, der kører med autentificering aktiveret, ikke vil stole på, at nogen TCP-peer er en anden er en anden mongod- eller mongos-knude, bare fordi den kommunikerer som en. Det kræver snarere, at peeren autentificerer ved bevis for delt hemmelighed.

Der er to typer interne godkendelsesmekanismer i MongoDB:

1. Intern nøglefilsgodkendelse.

2. SCRAM eller x.509 intern godkendelse.

Nøglefil intern godkendelse

Dette er den interne standardgodkendelsesmekanisme i MongoDB. Udtrykket "Nøgle" angiver en asymmetrisk krypteringsnøgle, men i reel forstand er det bare et kodeord, uanset hvordan du genererede det. Nøglefilen gemmes i en identisk fil distribueret til hver mongod og mongos node i klyngen. I scenariet bruges adgangskoden med succes, en mongod node vil tillade kommandoer, der kommer fra den godkendte peer, at køre som "_ _ system" superbruger.

Hvis nogen har en kopi af nøglefilen, kan de blot fjerne kontrol- og ikke-udskrivende tegn fra nøglefilen for at lave den adgangskodestreng, der tillader dem at oprette forbindelse som "_ _ system"-brugeren.

Men hvis det sker, og du kører kommandoen nedenfor som mongod (eller root) bruger på en af ​​dine MongoDB-servere og lykkes, bør du ikke bekymre dig, da der ikke vil være nogen utilsigtet lækage af læserettigheder . Dette skyldes, at mongod vil afbryde ved opstart, hvis nøglefilen er i noget andet end 400 (eller 600) filtilladelsestilstand.

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Men, hvis du ved et uheld gemmer nøglefilen i din verdenslæsbare kildekontrol, kan brugere, der ikke er DBA'er (eller serveradministratorer med root) læse en kopi af nøglefilen. Dette betragtes som en sikkerhedsfejl.

En ekstrem risiko øges, når nøglefilen distribueres med mongos-noder, der ejes og køres som en af ​​applikationsteamets unix-brugere i stedet for "mongod" eller en anden DBA-teamejet unix-bruger.

SCRAM eller x.509 intern godkendelse

Den x.509 interne godkendelsesmekanisme bruger faktisk asymmetriske private eller offentlige nøgler og skal bruges sammen med TLS/SSL. Denne mekanisme kan bruges til klientforbindelser såvel som intern godkendelse.

x.509- eller SCRAM-mekanismen har en fordel i forhold til Keyfile-mekanismen, fordi det i x.509-mekanismen er mindre sandsynligt, at en af ​​nøglerne, der er installeret med mongod- og mongos-noder, kan blive misbrugt af en ubuden gæst, der får en kopi af det. Dette afhænger dog af, hvor strengt x.509-certifikaterne er sat op. For at nyde maksimal sikkerhed fra denne mekanisme bør du have et dedikeret sikkerhedsteam, der forstår x.509-koncepterne og bedste praksis. Disse bedste praksisser omfatter stramning af, hvilke værter det vil arbejde på, og at kunne tilbagekalde og rulle certifikater.

Netværkskryptering/transportkryptering

Netværkskryptering forhindrer nogen i at kopiere de data, der overføres via et netværkslink et sted mellem to servere. Netværkskryptering kræver lidt eller ingen tanke, når det kommer til at beslutte, om det skal bruges, da det er afgørende. Men hvis for eksempel din MongoDB-klynge og alle dens klienter er inde i et virtuelt privat netværk, som du mener ikke har nogen huller i sin firewall og ingen risiko for eskalering af privilegier fra andre apps, så behøver du ikke netværkskryptering.

For netværkskryptering bør du konfigurere MongoDB til at bruge TLS/SSL til alle udgående og indgående forbindelser. Krypter kommunikation mellem mongod- og mongos-komponenter i en MOngoDB-implementering samt mellem alle applikationer og MongoDB ved hjælp af TLS/SSL.

Starter i version 4.0; MongoDB deaktiverer understøttelse af TLS 1.0-kryptering på systemer, hvor TLS 1.1+ er tilgængelig, og den bruger også følgende indbyggede TLS/SSL-biblioteker:

1. Windows - Sikker kanal (Schannel).

2. Linux/BSD - OpenSSL.

3. macOS - Sikker transport.

Begræns netværkseksponering

Du bør sikre, at MongoDB kører i et betroet netværksmiljø og også konfigurere firewall eller sikkerhedsgrupper til at kontrollere indgående og udgående trafik for dine MongoDB-forekomster. Mere så, konfigurer til kun at tillade betroede klienter at få adgang til netværksgrænseflader og porte, som MongoDB-instanser er tilgængelige på. Brug f.eks. IP-hvidliste til at tillade adgang fra betroede IP-adresser.

Kør MongoDB med Secure Configuration Options

MongoDB understøtter udførelses-JavaScript-koden til følgende operationer på serversiden:

1. kortReducer.

2. $hvor.

3. $akkumulator.

4. $funktion.

Brug -- noscripting-indstillingen på kommandolinjen for at deaktivere server-side scripting, hvis du ikke bruger ovenstående operationer. Hold inputvalidering aktiveret, selvom MongoDB aktiverer inputvalidering som standard via net.wireObjectCheck-indstillingen. Dette sikrer, at alle dokumenter gemt af mongod intsance er gyldige BSON.

MongoDB Storage Encryption/ Encryption-at-rest

Lagringskryptering forhindrer nogen i at få en kopi af de underliggende databasefiler. Dette kan ske, når nogen bryder ind i dit datacenter og stjæler din servers harddisk. MongoDB-data inkluderer datafiler, konfigurationsfiler, revisionslogfiler og nøglefiler.

Startende med MongoDB Enterprise 3.2 kan du kryptere data i lagringslaget med WiredTiger-lagringsmotorens native Encryption-at-rest. MongoDB-data skal krypteres på hver vært ved hjælp af filsystem, enhed eller fysisk kryptering, når der ikke bruges WiredTigers kryptering-at-rest. Du bør også indsamle logfiler til et centralt loglager, da disse logfiler indeholder DB-godkendelsesforsøg inklusive kildens IP-adresse. Lagerkryptering har dog en lille ydelsesomkostning.

Revision

Revision hjælper med at spore en databasebruger, der ved, hvordan de skal skjule deres spor efter at have ændret eller ændret databasedata. Grundlæggende sporer revision adgang og ændringer til databasekonfigurationer og data. MongoDB Enterprise har en revisionssystemfacilitet, der kan registrere systemhændelser såsom brugerhandlinger og forbindelseshændelser på en MongoDB-instans.

Disse revisionsregistreringer hjælper med retsmedicinske analyser og giver administratorer mulighed for at verificere korrekte kontroller. Revision er af høj værdi for nogle brugere, men kan kun være det, når visse andre risici er elimineret. For eksempel kan en angriber ikke få Unix root-adgang på serverne, mens han kører de levende mongod noder.

Gå fremad

Du kan konfigurere filtre til at optage specifikke hændelser såsom godkendelsesbegivenheder. Men vær forsigtig, for når revisionsfiltrene gøres for brede, vil dens ydeevne hurtigt kvæles, hvilket medfører høje ydeevneomkostninger. Selvom revision bruges korrekt, vil der ikke være mange præstationsomkostninger.