Den viktige guiden til MongoDB-sikkerhet

David Murphy fungerer som praksisleder for MongoDB hos Percona, en leverandør av MySQL- og MongoDB-løsninger og tjenester i bedriftsklasse.

MongoDB-sikkerhet er i nyheten igjen. En nylig historie med historier avslører hvordan hackere har tatt beslag på MongoDB-databaser og løst inn data for bitcoins. Titusenvis av MongoDB-installasjoner er kompromittert, ifølge Rapid7.

Vi er alle bekymret for sikkerhet. Hvis du kjører applikasjoner, nettverk eller databaser, er sikkerhet alltid et førsteklasses problem. Med flere selskaper som henvender seg til programvare med åpen kildekode som MongoDB for å lagre viktige bedriftsdata, blir sikkerhet et enda større spørsmål. Avhengig av virksomheten din, kan det hende du også har flere myndigheter (for eksempel Health Insurance Portability and Accountability Act, eller HIPAA) eller virksomhet (Payment Card Industry Data Security Standard eller PCI DSS) nettverkssikkerhetsreguleringsstandarder som du må overholde.

Er MongoDB-databaseprogramvare sikker? Oppfyller det disse standardene? Det korte svaret: Ja det er det, og ja det gjør det! Det handler bare om å vite hvordan du konfigurerer, konfigurerer og jobber med din spesielle installasjon.

I denne artikkelen skal jeg ta for meg MongoDB-sikkerhet. MongoDB er trygt å bruke - hvis du vet hva du skal se etter og hvordan du konfigurerer den.

Først og fremst, hvordan går folk galt med MongoDB-sikkerhet? Det er flere viktige områder som trekker brukere opp når det gjelder MongoDB-sikkerhet:

• Bruker standardporter
• Aktiverer ikke autentisering umiddelbart (det største problemet!)
• Når du bruker autentisering, gir alle bred tilgang
• Bruker ikke LDAP til å tvinge passordrotasjoner
• Tvinger ikke SSL-bruk i databasen
• Ikke begrenser databasetilgang til kjente nettverksenheter (applikasjonsverter, belastningsbalansere og så videre)
• Begrenser ikke hvilket nettverk som lytter (men dette påvirker ikke lenger versjoner som støttes)

MongoDB har fem kjerne sikkerhetsområder:

• Godkjenning. LDAP Authentication sentraliserer elementer i firmakatalogen.
• Autorisasjon. Autorisasjon definerer hvilke rollebaserte tilgangskontroller databasen gir.
• Kryptering. Kryptering kan deles inn i At-Rest og In-Transit. Kryptering er avgjørende for å sikre MongoDB.
• Revisjon. Revisjon refererer til evnen til å se hvem som gjorde hva i databasen.
• Styresett. Styring refererer til dokumentvalidering og kontroll av sensitive data (for eksempel et kontonummer, passord, personnummer eller fødselsdato). Dette refererer til både å vite hvor sensitive data er lagret og å forhindre at sensitive data blir introdusert i systemet.

LDAP-autentisering

MongoDB har innebygde brukerroller og slår dem av som standard. Imidlertid savner det elementer som passordkompleksitet, aldersbasert rotasjon og sentralisering og identifisering av brukerroller kontra tjenestefunksjoner. Disse er avgjørende for å overholde forskrifter som PCI DSS-samsvar. For eksempel forbyr PCI DSS bruk av gamle passord og passord som er enkle å bryte, og krever endringer i brukertilgang når status endres (for eksempel når brukeren forlater en avdeling eller selskapet).

Heldigvis kan LDAP brukes til å fylle mange av disse hullene. Mange kontakter tillater bruk av Windows Active Directory (AD) -systemer for å snakke med LDAP.

Merk: LDAP-støtte er bare tilgjengelig i MongoDB Enterprise. Det er ikke i fellesskapsversjonen. Den er tilgjengelig i andre open source-versjoner av MongoDB, for eksempel Percona Server for MongoDB.

MongoDB 3.2 lagrer brukere i LDAP, men ikke roller (disse er for øyeblikket lagret på de enkelte maskinene). MongoDB 3.4 Enterprise bør introdusere muligheten til å lagre roller i LDAP for sentralisert tilgang. (Vi diskuterer roller senere.)

Percona

Ved å bruke LDAP og AD kan du knytte brukere inn i bedriftskatalogen. Når de bytter rolle eller forlater selskapet, kan de fjernes med menneskelige ressurser fra databasegruppen din. Dermed har du et automatisert system på plass for å sikre at bare de du vil ha tilgang til dataene manuelt kan gjøre det, uten at du ved et uhell savner noe.

LDAP i Mongo er faktisk enkelt. MongoDB har en spesiell kommando for å be den sjekke den eksterne LDAP-databasen: $ ekstern.

Noen andre advarsler for bruk av LDAP:

• Opprett en bruker med .Opprett bruker som du normalt ville gjort, men vær sikker på at du følger med db / collection resource tags.
• I tillegg krever LDAP-autentisering to felt til:
  • mekanisme: “PLAIN”
  • digestPassword: false

Egendefinerte roller

Rollebasert tilgangskontroll (RBAC) er kjernen i MongoDB. Innebygde roller har vært tilgjengelige i MongoDB siden versjon 2.6. Du kan til og med lage dine egne, helt ned til de spesifikke handlingene en bestemt bruker kan få lov til å gjøre. Dette lar deg definere hva en bestemt bruker kan gjøre eller se med barberhøvelpresisjon. Dette er en sentral MongoDB-funksjon at den er tilgjengelig i nesten alle leverandørversjoner av programvaren med åpen kildekode.

De fem viktigste innebygde MongoDB-rollene du bør være oppmerksom på:

• lese:
  • Skrivebeskyttet tilgang, vanligvis gitt til de fleste brukere
• Les Skriv:
  • Les Skriv tilgang tillater redigering av data
  • Les Skriv inkluderer lese
• dbEier:
  • Inkluderer Les Skriv, dbAdmin, userAdmin (for databasen). userAdmin betyr å legge til eller fjerne brukere, gi brukere rettigheter og opprette roller. Disse rettighetene tildeles bare den spesifikke databaseserveren.
• dbAdminAnyDatabase:
  • Skaper dbAdmin på alle databaser, men tillater ikke brukeradministrasjon (for eksempel å opprette eller fjerne brukere). Du kan opprette indekser, ringe komprimeringer og mer. Dette gir ikke tilgang til skjæring.
• rot:
  • Dette er en superbruker, men med grenser
  • Det kan gjøre det meste, men ikke alt:
    • Kan ikke endre systeminnsamlingen
    • Noen kommandoer er fortsatt ikke tilgjengelig for denne rollen, avhengig av versjonen. For eksempel tillater ikke MongoDB 3.2-rotrollen deg å endre oplog- eller profilstørrelsen, og MongoDB 3.4-rotrollen lar deg ikke lese gjeldende visninger.

Jokertegn databaser og samlinger

Jokertegn betyr å gi tillatelser til store grupper av databaser eller samlinger (eller alle) på en server. Med en nullverdi kan du spesifisere alle databaser eller samlinger og unngå dbAdminAnyDatabase rolle. Dette tillater spesifikke brukere å ha alle privilegiene, inkludert administrasjonsfunksjoner.

Dette er farlig.

Når du bruker jokertegn, gir du mange spesielle privilegier, og du bør være klar over at du åpner mulige muligheter for angrep:

• readWriteAnyDatabase er ekstremt bredt og utsetter brukernavn og roller for et potensielt angrep via applikasjonsbrukeren
• Ved å bruke jokertegn betyr det at du ikke begrenser spesifikke applikasjoner til spesifikke databaser
• Jokertegn forhindrer deg i å bruke multitenancy med flere databaser
• Nye databaser får ikke automatisk tilgang

Opprette en tilpasset rolle

Kraften til MongoDB-roller kommer fra å lage tilpassede roller. I en egendefinert rolle kan du spesifisere at enhver handling på en hvilken som helst ressurs kan spesifiseres for en bestemt bruker. Med dette granularitetsnivået kan du dypt kontrollere hvem som kan gjøre hva i MongoDB-miljøet ditt.

Når det gjelder å spesifisere en tilpasset rolle, er det fire forskjellige typer ressurser:

• db. Spesifiserer en database. Du kan bruke en streng for et navn, eller "" for "hvilken som helst" (ingen jokertegn).
• samling. Spesifiserer en samling dokumenter. Du kan bruke en streng for et navn eller “” for “hvilken som helst” (ingen jokertegn).
• klynge. Spesifiserer en splittet klynge eller andre metadataressurser. Det er en boolsk verdi av true / false.
• anyResource. Spesifiserer tilgang til hva som helst, hvor som helst. Det er en boolsk verdi av true / false.

Enhver rolle kan arve egenskapene til en annen rolle. Det er en matrise kalt "roller", og du kan slippe en ny rolle i matrisen. Det vil arve egenskapene til den angitte rollen.

Bruk createRole for å legge til en rolle i matrisen.

Du kan legge til nye eller eksisterende databaser til en bruker eller en rolle. For eksempel kan du legge til lese- og skrivetilgang til en database ved å legge databasen til en rolle.

Bruke grantPrivilegesToRole kommando for å legge til nye ressurser i en eksisterende rolle.

Nedenfor er et eksempel på å opprette en ny Super-brukerrolle. Hensikten med denne rollen er igjen å ha en bruker som på ingen måte er begrenset i MongoDB-miljøet (for nødssituasjoner).

db = db.geSiblingDB (“admin”);

db.createRole ({

rolle: “superRoot”,

privilegier: [{

ressurs: {anyResource: true},

handlinger: [‘anyAction’]

     }]     

roller:[]

});

db.createUser ({

bruker: “comanyDBA”,

pwd: “EWqeeFpUt9 * 8zq”,

roller: [“superRoot”]

})

Disse kommandoene skaper en ny rolle i databasen geSiblingDB kalt superRoot og tilordne den rollen enhver ressurs og handling. Deretter oppretter vi en ny bruker på den samme databasen som heter selskapDBA (med passord) og tilordne det nye superRoot rolle.

Bruker SSL for alle ting

SSL hjelper deg med å sikre dataene dine over usikrede nettverk. Hvis du bruker en database som samhandler med internett, bør du bruke SSL.

Det er to veldig gode grunner til å bruke SSL for å sikre MongoDB: personvern og autentisering. Uten SSL kan du få tilgang til, kopiere og bruke dataene dine til ulovlige eller skadelige formål. Med autentisering har du et sekundært sikkerhetsnivå. SSLs private nøkkelinfrastruktur (PKI) garanterer at bare brukere med riktig CA-sertifikat har tilgang til MongoDB.

MongoDB har hatt SSL-støtte i lang tid, men har dramatisk forbedret SSL-støtte de siste versjonene. Tidligere, hvis du ønsket å bruke SSL, måtte du laste den ned og kompilere den manuelt med MongoDB Community-versjonen. Fra og med MongoDB 3.0 er SSL kompilert med programvaren som standard.

Eldre versjoner av MongoDB manglet også gyldig vertskontroll; vertsvalidering var bare et flagg som du kunne sjekke i konfigurasjonsfilen som tilfredsstilte en SSL-forespørsel fra en tilkobling.

De siste versjonene av SSL i MongoDB inkluderer følgende viktige funksjoner:

• Sjekker for gyldige verter (valgfritt)
• Evne til å peke på et spesifikt oppsett .key-fil som skal brukes
• Custom Certificate Authority (CA) for selvsignerte certs eller alternative underskrivere
• allowSSL, foretrekkerSSL, kreverSSL moduser, som lar deg velge en granularitet for SSL-bruk (fra mindre sikker til sikrere)

SSL: Bruker en tilpasset CA

De nyere versjonene av SSL i MongoDB lar deg bruke en tilpasset CA. Selv om dette gir deg fleksibilitet i å spesifisere hvordan du vil jobbe med SSL, kommer det med forbehold. Hvis du bare prøver å sikre forbindelsen, kan du bli fristet til å velge sslAllowInvalidCertficates. Dette er imidlertid generelt en dårlig idé av noen grunner:

• Tillater enhver tilkobling fra utløpt til tilbakekalte sertifikater
• Du sørger ikke for begrensninger for et bestemt vertsnavn
• Du er ikke så sikker som du tror du er

For å fikse dette, bare sett net.ssl.CAFile, og MongoDB vil bruke både nøkkelen og CA-filen (du må gjøre dette på klienten).

Å bruke SSL har imidlertid en kjent ulempe: ytelse. Du vil definitivt miste ytelse når du bruker SSL.

Disk kryptering

Data er enten "under transport" eller "i ro." Du kan kryptere en eller begge i MongoDB. Vi har diskutert datakryptering under transitt (SSL). La oss nå se på data i ro.

Restdata er data som er lagret på disken. Data-at-rest-kryptering refererer vanligvis til data lagret på et kryptert lagringssted. Dette er for å forhindre tyveri på fysisk måte og lage sikkerhetskopier som er lagret på en måte som ikke lett kan leses av noen tredjepart. Det er praktiske grenser for dette. Det største er å stole på systemadministratorene dine - og anta at en hacker ikke har fått administrativ tilgang til systemet.

Dette er ikke et problem som er unikt for MongoDB. Forebyggende tiltak som brukes i andre systemer fungerer også her. De kan inneholde krypteringsverktøy som LUKS og cryptfs eller enda sikrere metoder som signering av krypteringsnøkler med LDAP, smartkort og RSA-type tokens.

Når du utfører dette krypteringsnivået, må du ta hensyn til faktorer som automatisk montering og dekryptering av stasjoner. Men dette er ikke nytt for systemadministratorene dine. De kan håndtere dette kravet på samme måte som de klarer det i andre deler av nettverket. Den ekstra fordelen er en enkelt prosedyre for lagringskryptering, ikke en av hvilken teknologi en bestemt funksjon bruker.

Data-at-rest-kryptering kan løses med noe av eller alt av følgende:

• Krypter hele volumet
• Krypter bare databasefilene
• Krypter i applikasjonen

Det første elementet kan løses med diskkryptering på filsystemet. Det er enkelt å sette opp ved hjelp av LUKS og dm-crypt. Bare det første og andre alternativet kreves for PCI DSS-samsvar og andre sertifiseringskrav.

Revisjon

Sentralt i enhver god sikkerhetsdesign er å kunne spore hvilken bruker som gjorde hva som ble gjort i databasen (ligner på hvordan du skal kontrollere dine faktiske servere). Med revisjon kan du filtrere utdataene til en bestemt bruker, database, samling eller kildeplassering. Dette genererer en logg for gjennomgang av sikkerhetshendelser. Enda viktigere, det viser enhver sikkerhetsrevisor at du har tatt de riktige trinnene for å beskytte databasen din mot inntrenging og for å forstå dybden av innbrudd hvis en skulle oppstå.

Med revisjon kan du fullt ut spore handlinger fra en inntrenger i miljøet ditt.

Merk: Revisjon er bare tilgjengelig i MongoDB Enterprise. Det er ikke i fellesskapsversjonen. Den er tilgjengelig i noen andre open source-versjoner av MongoDB, for eksempel Percona Server for MongoDB.