Programmering

Den vigtige guide til MongoDB-sikkerhed

David Murphy fungerer som praksismanager for MongoDB hos Percona, en leverandør af MySQL- og MongoDB-løsninger og -tjenester i virksomhedsklasse.

MongoDB-sikkerhed er i nyhederne igen. En nylig historie med historier afslører, hvordan hackere har beslaglagt MongoDB-databaser og løses data for bitcoins. Titusinder af MongoDB-installationer er kompromitteret, ifølge Rapid7.

Vi bekymrer os alle om sikkerhed. Hvis du kører applikationer, netværk eller databaser, er sikkerhed altid et topproblem. Da flere virksomheder henvender sig til open source-software som MongoDB for at gemme vigtige virksomhedsdata, bliver sikkerhed et endnu større spørgsmål. Afhængigt af din virksomhed har du muligvis også flere offentlige myndigheder (såsom Health Insurance Portability and Accountability Act eller HIPAA) eller forretningsmæssige (Payment Card Industry Data Security Standard eller PCI DSS) netværkssikkerhedsreguleringsstandarder, som du skal overholde.

Er MongoDB-databasesoftware sikker? Opfylder den disse standarder? Det korte svar: Ja det er det, og ja det gør det! Det er simpelthen et spørgsmål om at vide, hvordan du konfigurerer, konfigurerer og arbejder med din specifikke installation.

I denne artikel vil jeg adressere MongoDB-sikkerhed. MongoDB er sikkert at bruge - hvis du ved, hvad du skal kigge efter, og hvordan du konfigurerer det.

Først og fremmest, hvordan går folk galt med MongoDB-sikkerhed? Der er flere nøgleområder, der får brugere op, når det kommer til MongoDB-sikkerhed:

  • Brug af standardporte
  • Aktivering af godkendelse straks ikke (det største problem!)
  • Når du bruger godkendelse, giver alle bred adgang
  • Brug ikke LDAP til at tvinge adgangskodedrejninger
  • Tvinger ikke SSL-brug i databasen
  • Begrænser ikke databaseadgang til kendte netværksenheder (applikationsværter, load balancere osv.)
  • Begrænser ikke, hvilket netværk der lytter (men dette påvirker ikke længere nogen understøttede versioner)

MongoDB har fem centrale sikkerhedsområder:

  • Godkendelse. LDAP-godkendelse centraliserer elementer i din virksomhedsmappe.
  • Bemyndigelse. Autorisation definerer, hvilken rollebaseret adgangskontrol databasen giver.
  • Kryptering. Kryptering kan opdeles i At-Rest og In-Transit. Kryptering er afgørende for at sikre MongoDB.
  • Revision. Auditing henviser til evnen til at se, hvem der gjorde hvad i databasen.
  • Styring. Styring henviser til dokumentvalidering og kontrol af følsomme data (såsom et kontonummer, en adgangskode, et socialsikringsnummer eller en fødselsdato). Dette refererer til både at vide, hvor følsomme data er lagret, og forhindre, at følsomme data introduceres i systemet.

LDAP-godkendelse

MongoDB har indbyggede brugerroller og slukker dem som standard. Det går imidlertid glip af emner som adgangskodekompleksitet, aldersbaseret rotation og centralisering og identifikation af brugerroller versus servicefunktioner. Disse er vigtige for at overholde regler som PCI DSS-overholdelse. For eksempel forbyder PCI DSS brug af gamle adgangskoder og adgangskoder, der er lette at bryde, og kræver ændringer i brugeradgang, når status ændres (for eksempel når brugeren forlader en afdeling eller virksomheden).

Heldigvis kan LDAP bruges til at udfylde mange af disse huller. Mange stik tillader brug af Windows Active Directory (AD) -systemer til at tale med LDAP.

Bemærk: LDAP-support er kun tilgængelig i MongoDB Enterprise. Det er ikke i fællesskabsversionen. Den er tilgængelig i andre open source-versioner af MongoDB, såsom Percona Server til MongoDB.

MongoDB 3.2 gemmer brugere i LDAP, men ikke roller (disse er i øjeblikket gemt på de enkelte maskiner). MongoDB 3.4 Enterprise bør introducere muligheden for at gemme roller i LDAP til central adgang. (Vi diskuterer roller senere.)

Percona

Ved hjælp af LDAP og AD kan du binde brugere ind i din virksomhedsmappe. Når de skifter roller eller forlader virksomheden, kan de fjernes med menneskelige ressourcer fra din databasegruppe. Således har du et automatiseret system på plads for at sikre, at kun dem, du ønsker at få adgang til dataene manuelt, kan gøre uden at skulle gå glip af noget ved et uheld.

LDAP i Mongo er faktisk let. MongoDB har en speciel kommando, der fortæller den at kontrollere den eksterne LDAP-database: $ ekstern.

Nogle andre forbehold for brug af LDAP:

  • Opret en bruger med .createUser som du normalt ville, men sørg for at gå med db / collection-ressourcemærker.
  • Derudover kræver LDAP-godkendelse to yderligere felter:
    • mekanisme: “PLAIN”
    • digestPassword: falsk

Brugerdefinerede roller

Rollebaseret adgangskontrol (RBAC) er kernen i MongoDB. Indbyggede roller har været tilgængelige i MongoDB siden version 2.6. Du kan endda lave dine egne helt ned til de specifikke handlinger, som en bestemt bruger muligvis har lov til at udføre. Dette giver dig mulighed for at definere, hvad en bestemt bruger kan gøre eller se med barberknivpræcision. Dette er en central MongoDB-funktion, at den er tilgængelig i næsten enhver leverandørs version af open source-softwaren.

De fem hovedindbyggede MongoDB-roller, du skal være opmærksom på:

  • Læs:
    • Skrivebeskyttet adgang, typisk givet til de fleste brugere
  • læse skrive:
    • læse skrive adgang tillader redigering af data
    • læse skrive inkluderer læsning
  • dbEjer:
    • Inkluderer læse skrive, dbAdmin, userAdmin (til databasen). userAdmin betyder tilføjelse eller fjernelse af brugere, tildeling af rettigheder til brugere og oprettelse af roller. Disse rettigheder tildeles kun den specifikke databaseserver.
  • dbAdminAnyDatabase:
    • Opretter dbAdmin på alle databaser, men tillader ikke brugeradministration (for eksempel at oprette eller fjerne brugere). Du kan oprette indekser, opkaldskomprimeringer og mere. Dette giver ikke sharding-adgang.
  • rod:
    • Dette er en superbruger, men med begrænsninger
    • Det kan gøre de fleste ting, men ikke alle:
      • Kunne ikke ændre systemopsamlingen
      • Nogle kommandoer er stadig ikke tilgængelige for denne rolle, afhængigt af versionen. For eksempel tillader MongoDB 3.2-rodrollen dig ikke at ændre oplog- eller profilstørrelsen, og MongoDB 3.4-rodrollen giver dig ikke mulighed for at læse de aktuelle visninger.

Jokertegn databaser og samlinger

Wildcarding betyder tildeling af tilladelser til store grupper af databaser eller samlinger (eller dem alle) på en server. Med en nulværdi kan du angive alle databaser eller samlinger og undgå dbAdminAnyDatabase rolle. Dette giver specifikke brugere mulighed for at have alle privilegier, herunder administrationsfunktioner.

Dette er farligt.

Når du bruger jokertegn, giver du mange specielle privilegier, og du skal være opmærksom på, at du åbner mulige muligheder for angreb:

  • readWriteAnyDatabase er ekstremt bredt og udsætter brugernavne og roller for et potentielt angreb via applikationsbrugeren
  • Brug af jokertegn betyder, at du ikke begrænser specifikke applikationer til specifikke databaser
  • Wildcarding forhindrer dig i at bruge multitenancy med flere databaser
  • Nye databaser får ikke automatisk adgang

Oprettelse af en brugerdefineret rolle

Kraften i MongoDB-roller kommer fra oprettelse af brugerdefinerede roller. I en brugerdefineret rolle kan du angive, at enhver handling på en hvilken som helst ressource kan specificeres for en bestemt bruger. Med dette granularitetsniveau kan du dybt kontrollere, hvem der kan gøre hvad i dit MongoDB-miljø.

Når det kommer til at specificere en brugerdefineret rolle, er der fire forskellige typer ressourcer:

  • db. Angiver en database. Du kan bruge en streng til et navn eller "" til "enhver" (ingen jokertegn).
  • kollektion. Angiver en samling dokumenter. Du kan bruge en streng til et navn eller "" til "enhver" (ingen jokertegn).
  • klynge. Angiver en splittet klynge eller andre metadataressourcer. Det er en boolsk værdi af sand / falsk.
  • anyResource. Angiver adgang til alt, hvor som helst. Det er en boolsk værdi af sand / falsk.

Enhver rolle kan arve egenskaberne for en anden rolle. Der er en matrix kaldet "roller", og du kan droppe en ny rolle i arrayet. Det arver egenskaberne for den angivne rolle.

Brug createRole for at tilføje en rolle til arrayet.

Du kan tilføje nye eller eksisterende databaser til en bruger eller en rolle. For eksempel kan du tilføje læse- og skriveadgang til en database ved at føje databasen til en rolle.

Brug grantPrivilegesToRole kommando for at tilføje nye ressourcer til en eksisterende rolle.

Nedenfor er et eksempel på oprettelse af en ny superbrugerrolle. Formålet med denne rolle er igen at have en bruger, der på ingen måde er begrænset i MongoDB-miljøet (til nødsituationer).

db = db.geSiblingDB (“admin”);

db.createRole ({

rolle: “superRoot”,

privilegier: [{

ressource: {anyResource: true},

handlinger: ['anyAction']

     }]     

roller: []

});

db.createUser ({

bruger: “comanyDBA”,

pwd: “EWqeeFpUt9 * 8zq”,

roller: [“superRoot”]

})

Disse kommandoer skaber en ny rolle i databasen geSiblingDB hedder superRoot og tildel denne rolle enhver ressource og enhver handling. Derefter opretter vi en ny bruger i den samme database kaldet firmaDBA (med et kodeord) og tildel det nye superRoot rolle.

Brug af SSL til alle ting

SSL hjælper med at sikre sikkerheden af ​​dine data over usikrede netværk. Hvis du bruger en database, der interagerer med internettet, skal du bruge SSL.

Der er to meget gode grunde til at bruge SSL til at sikre MongoDB: privatliv og godkendelse. Uden SSL kan dine data tilgås, kopieres og bruges til ulovlige eller skadelige formål. Med godkendelse har du et sekundært sikkerhedsniveau. SSLs private nøgleinfrastruktur (PKI) garanterer, at kun brugere med det korrekte CA-certifikat har adgang til MongoDB.

MongoDB har haft SSL-support i lang tid, men har dramatisk forbedret SSL-support i de sidste par versioner. Tidligere, hvis du ville bruge SSL, var du nødt til at downloade det og kompilere det manuelt med MongoDB Community-versionen. Fra og med MongoDB 3.0 kompileres SSL som standard med softwaren.

Ældre versioner af MongoDB manglede også gyldig værtkontrol; værtsvalidering var blot et flag, som du kunne kontrollere i konfigurationsfilen, der opfyldte en SSL-anmodning fra en forbindelse.

De nyeste versioner af SSL i MongoDB inkluderer følgende nøglefunktioner:

  • Kontrol af gyldige værter (valgfrit)
  • Evne til at pege på en bestemt nøglefil, der skal bruges
  • Custom Certificate Authority (CA) til selvsignerede certifikater eller alternative underskrivere
  • tilladSSL, foretrækkerSSL, kræveSSL tilstande, som giver dig mulighed for at vælge en granularitet til din SSL-brug (fra mindre sikker til mere sikker)

SSL: Brug af en brugerdefineret CA

De nyere versioner af SSL i MongoDB giver dig mulighed for at bruge en brugerdefineret CA. Selvom dette giver dig fleksibilitet i at specificere, hvordan du vil arbejde med SSL, kommer det med advarsler. Hvis du bare prøver at sikre forbindelsen, kan du blive fristet til at vælge sslAllowInvalidCertficates. Dette er dog generelt en dårlig idé af nogle få grunde:

  • Tillader enhver forbindelse fra udløbet til tilbagekaldte certifikater
  • Du sikrer ikke begrænsninger for et bestemt værtsnavn
  • Du er ikke nær så sikker som du tror du er

For at løse dette skal du blot indstille net.ssl.CAFile, og MongoDB vil bruge begge nøglen og CA-filen (du skal gøre dette på klienten).

Brug af SSL har dog en kendt ulempe: ydeevne. Du vil helt sikkert miste ydeevne, når du bruger SSL.

Disk kryptering

Data er enten "i transit" eller "i ro." Du kan kryptere den ene eller begge dele i MongoDB. Vi har diskuteret datakryptering under forsendelse (SSL). Lad os nu se på data i hvile.

Hvile-data er data, der er gemt på disken. Data-at-rest-kryptering refererer typisk til data, der er gemt på en krypteret lagerplacering. Dette er for at forhindre tyveri med fysiske midler og skabe sikkerhedskopier, der er gemt på en måde, der ikke er let at læse af nogen tredjepart. Der er praktiske grænser for dette. Den største er tillid til dine systemadministratorer - og forudsat at en hacker ikke har fået administrativ adgang til systemet.

Dette er ikke et unikt emne for MongoDB. Forebyggende foranstaltninger, der anvendes i andre systemer, fungerer også her. De kan omfatte krypteringsværktøjer som LUKS og cryptfs eller endnu mere sikre metoder såsom signering af krypteringsnøgler med LDAP, chipkort og RSA-type tokens.

Når du udfører dette niveau af kryptering, skal du overveje faktorer som automatisk montering og dekryptering af drev. Men dette er ikke nyt for dine systemadministratorer. De kan håndtere dette krav på samme måde som de administrerer det i andre dele af netværket. Den ekstra fordel er en enkelt procedure til lagringskryptering, ikke en per den teknologi, en bestemt funktion bruger.

Kryptering af data i hvile kan løses med et eller flere af følgende:

  • Krypter hele diskenheden
  • Krypter kun databasefilerne
  • Krypter i applikationen

Det første element kan løses med diskkryptering på filsystemet. Det er let at konfigurere ved hjælp af LUKS og dm-crypt. Kun den første og anden mulighed kræves for PCI DSS-overholdelse og andre certificeringskrav.

Revision

Centralt for ethvert godt sikkerhedsdesign er det at kunne spore, hvilken bruger der gjorde, hvad der var i databasen (svarende til hvordan du skal kontrollere dine faktiske servere). Auditing giver dig mulighed for at filtrere output fra en bestemt bruger, database, samling eller kildeplacering. Dette genererer en log til gennemgang af sikkerhedshændelser. Mere vigtigt, det viser enhver sikkerhedsrevisor, at du har taget de rigtige skridt til at beskytte din database mod en indtrængen og at forstå dybden af ​​enhver indtrængen, hvis en sådan skulle forekomme.

Auditing giver dig mulighed for fuldt ud at spore handlinger fra en ubuden gæst i dit miljø.

Bemærk: Revision er kun tilgængelig i MongoDB Enterprise. Det er ikke i fællesskabsversionen. Den er tilgængelig i nogle andre open source-versioner af MongoDB, såsom Percona Server til MongoDB.

$config[zx-auto] not found$config[zx-overlay] not found