Osnovni vodič za sigurnost MongoDB-a

David Murphy služi kao voditelj prakse za MongoDB u tvrtki Percona, pružatelju MySQL i MongoDB rješenja i usluga u poslovnoj klasi.

Sigurnost MongoDB-a ponovno je u vijestima. Nedavna bujica priča otkriva kako su hakeri plijenili baze podataka MongoDB i otkupljivali podatke za bitcoin. Desetci tisuća MongoDB instalacija ugroženi su, prema Rapid7.

Svi se brinemo zbog sigurnosti. Ako pokrećete aplikacije, mreže ili baze podataka, sigurnost je uvijek glavni problem. Kako se sve više tvrtki okreće softveru otvorenog koda kao što je MongoDB za pohranu važnih podataka poduzeća, sigurnost postaje još veće pitanje. Ovisno o vašem poslovanju, možda imate i više državnih (kao što je Zakon o prenosivosti i odgovornosti zdravstvenog osiguranja ili HIPAA) ili poslovnih (Standard za sigurnost podataka industrije platnih kartica ili PCI DSS) regulatornih standarda sigurnosti s kojima se morate pridržavati.

Je li softver baze podataka MongoDB siguran? Udovoljava li tim standardima? Kratki odgovor: Da, i da! Samo je stvar znanja kako postaviti, konfigurirati i raditi s određenom instalacijom.

U ovom članku obratit ću se zaštiti MongoDB. MongoDB je siguran za upotrebu - ako znate na što treba paziti i kako ga konfigurirati.

Prije svega, kako ljudi griješe s MongoDB sigurnošću? Nekoliko je ključnih područja koja potiču korisnike kada je u pitanju sigurnost MongoDB:

  • Korištenje zadanih priključaka
  • Ne omogućavanje autentifikacije odmah (najveći problem!)
  • Kada upotrebljavate provjeru autentičnosti, pružanje svima širokog pristupa
  • Ne koristi LDAP za forsiranje rotacije lozinke
  • Ne forsira upotrebu SSL-a u bazi podataka
  • Ne ograničavajući pristup bazi podataka poznatim mrežnim uređajima (hostovi aplikacija, uravnoteživači opterećenja itd.)
  • Ne ograničavajući mrežu koja sluša (međutim, to više ne utječe na podržane verzije)

MongoDB ima pet temeljnih sigurnosnih područja:

  • Ovjera. LDAP provjera autentičnosti centralizira stavke u direktoriju vaše tvrtke.
  • Odobrenje. Ovlašćenje definira koje kontrole pristupa zasnovane na ulogama pruža baza podataka.
  • Šifriranje. Šifriranje se može podijeliti na At-Rest i In-Transit. Šifriranje je presudno za zaštitu MongoDB-a.
  • Revizija. Revizija se odnosi na sposobnost da se vidi tko je što radio u bazi podataka.
  • Upravljanje. Upravljanje se odnosi na provjeru valjanosti dokumenata i provjeru osjetljivih podataka (poput broja računa, lozinke, broja socijalnog osiguranja ili datuma rođenja). To se odnosi kako na to gdje se čuvaju osjetljivi podaci, tako i na sprečavanje unošenja osjetljivih podataka u sustav.

LDAP provjera autentičnosti

MongoDB ima ugrađene korisničke uloge i isključuje ih prema zadanim postavkama. Međutim, propuštaju stavke poput složenosti lozinke, rotacije na temelju dobi i centralizacije i identifikacije korisničkih uloga nasuprot uslužnih funkcija. To su ključne za donošenje propisa poput usklađenosti s PCI DSS-om. Na primjer, PCI DSS zabranjuje upotrebu starih lozinki i lozinki koje se lako lome i zahtijeva promjene korisničkog pristupa kad god se status promijeni (na primjer, kada korisnik napusti odjel ili tvrtku).

Srećom, LDAP se može koristiti za popunjavanje mnogih od ovih praznina. Mnogi konektori omogućuju upotrebu sustava Windows Active Directory (AD) za razgovor s LDAP-om.

Napomena: LDAP podrška dostupna je samo u MongoDB Enterprise. Nije u verziji Zajednice. Dostupan je u drugim verzijama otvorenog koda MongoDB, poput Percona poslužitelja za MongoDB. 

MongoDB 3.2 pohranjuje korisnike u LDAP, ali ne i uloge (one su trenutno pohranjene na pojedinačnim računalima). MongoDB 3.4 Enterprise trebao bi uvesti mogućnost spremanja uloga u LDAP za centralizirani pristup. (O ulogama ćemo razgovarati kasnije.)

Percona

Koristeći LDAP i AD, možete povezati korisnike s vašim korporativnim direktorijom. Kad promijene ulogu ili napuste tvrtku, ljudski resursi mogu ih ukloniti iz grupe baza podataka. Stoga imate uspostavljen automatizirani sustav koji osigurava da to mogu učiniti samo oni kojima želite pristupiti ručno, a da slučajno nešto ne propuste.

LDAP u Mongu zapravo je jednostavan. MongoDB ima posebnu zapovijed da ga reći da provjerite vanjski LDAP baze podataka: $external.

Neka druga upozorenja za upotrebu LDAP-a:

  • Stvorite korisnika s .createUseronim kako biste to obično učinili, ali svakako pođite s db / collection oznakama resursa.
  • Uz to, LDAP provjera autentičnosti zahtijeva još dva polja:
    • mehanizam: “RAVNI”
    • digestPassword: netočno

Prilagođene uloge

Kontrola pristupa zasnovana na ulogama (RBAC) srž je MongoDB-a. Ugrađene uloge dostupne su u MongoDB-u od verzije 2.6. Možete izrađivati ​​i vlastite, sve do određenih radnji koje određeni korisnik može imati. To vam omogućuje da precizno odredite što određeni korisnik može učiniti ili vidjeti. Ovo je osnovna značajka MongoDB koja je dostupna u verziji softvera otvorenog koda gotovo svakog dobavljača.

Pet glavnih ugrađenih MongoDB uloga kojih biste trebali biti svjesni:

  • read:
    • Pristup samo za čitanje, koji se obično daje većini korisnika
  • readWrite:
    • readWrite pristup omogućuje uređivanje podataka
    • readWrite uključuje čitanje
  • dbOwner:
    • Uključuje readWrite, dbAdmin, userAdmin(za bazu podataka). userAdminznači dodavanje ili uklanjanje korisnika, dodjeljivanje privilegija korisnicima i stvaranje uloga. Te su privilegije dodijeljene samo određenom poslužitelju baze podataka.
  • dbAdminAnyDatabase:
    • Stvara dbAdminu svim bazama podataka, ali ne dopušta administriranje korisnika (na primjer, za stvaranje ili uklanjanje korisnika). Možete stvoriti indekse, sažimanja poziva i još mnogo toga. Ovo ne omogućuje pristup oštrini.
  • root:
    • Ovo je superkorisnik, ali s ograničenjima
    • Može učiniti većinu stvari, ali ne sve:
      • Nije moguće promijeniti zbirku sustava
      • Neke naredbe još uvijek nisu dostupne za ovu ulogu, ovisno o verziji. Na primjer, uloga korijena MongoDB 3.2 ne dopušta vam promjenu veličine oploga ili profila, a uloga korijena MongoDB 3.4 ne omogućuje vam čitanje trenutnih prikaza.

Podatkovne baze podataka i zbirke

Zamjenski znak znači davanje dozvola velikim skupinama baza podataka ili zbirki (ili svim njima) na poslužitelju. Nulom vrijednosti možete odrediti sve baze podataka ili zbirke i izbjeći dbAdminAnyDatabaseulogu. To omogućuje određenim korisnicima da imaju sve privilegije, uključujući administracijske funkcije.

Ovo je opasno.

Kada upotrebljavate zamjenske znakove, dodjeljujete puno posebnih privilegija i trebali biste biti svjesni da otvarate moguće putove napada:

  • readWriteAnyDatabaseje izuzetno širok i izlaže korisnička imena i uloge potencijalnom napadu putem korisnika aplikacije
  • Upotreba zamjenskih znakova znači da nećete ograničiti određene aplikacije na određene baze podataka
  • Zamjenski znak sprečava vas da koristite multitenanciju s više baza podataka
  • Novim bazama podataka nije automatski odobren pristup

Stvaranje prilagođene uloge

Snaga MongoDB uloga dolazi iz stvaranja prilagođenih uloga. U prilagođenoj ulozi možete odrediti da bilo koja radnja na bilo kojem resursu može biti navedena za određenog korisnika. S ovom razinom granulacije možete duboko kontrolirati tko što može raditi u vašem MongoDB okruženju.

Kad je riječ o određivanju prilagođene uloge, postoje četiri različite vrste resursa:

  • db. Određuje bazu podataka. Možete koristiti niz za ime ili "" za "bilo koji" (bez zamjenskog znaka).
  • collection. Određuje zbirku dokumenata. Možete koristiti niz za ime ili "" za "bilo koji" (bez zamjenskog znaka).
  • cluster. Određuje izoštreni klaster ili druge resurse metapodataka. To je logička vrijednost true / false.
  • anyResource. Određuje pristup bilo čemu, bilo gdje. To je logička vrijednost true / false.

Svaka uloga može naslijediti svojstva druge uloge. Postoji niz koji se naziva "uloge", a u njega možete ispustiti novu ulogu. Naslijedit će svojstva navedene uloge.

Koristite createRoleza dodavanje uloge u niz.

Korisniku ili ulozi možete dodati nove ili postojeće baze podataka. Na primjer, možete dodati pristup za čitanje i pisanje u bazu podataka dodavanjem baze podataka ulozi.

Upotrijebite grantPrivilegesToRolenaredbu za dodavanje novih resursa postojećoj ulozi.

Ispod je primjer stvaranja nove Super korisničke uloge. Svrha ove uloge je opet imati jednog korisnika koji ni na koji način nije ograničen u MongoDB okruženju (za izvanredne situacije).

db = db.geSiblingDB(“admin”);

db.createRole({     

     role: “superRoot”,     

     privileges:[{          

          resource: {anyResource:true},          

          actions: [‘anyAction’]     

     }]     

     roles:[]

});

db.createUser({     

     user: “comanyDBA”,     

     pwd: “EWqeeFpUt9*8zq”,     

     roles: [“superRoot”]

})

Te naredbe stvaraju novu ulogu u bazi podataka koja se geSiblingDBzove superRooti dodijeljuju toj ulozi bilo koji resurs i bilo koju akciju. Zatim stvaramo novog korisnika na istoj bazi podataka koja se zove companyDBA(s lozinkom) i dodijeljujemo joj novu superRootulogu.

Korištenje SSL-a za sve stvari

SSL pomaže u osiguranju sigurnosti vaših podataka preko nezaštićenih mreža. Ako koristite bazu podataka koja komunicira s internetom, trebali biste koristiti SSL.

Dva su vrlo dobra razloga za korištenje SSL-a za zaštitu MongoDB-a: privatnost i provjera autentičnosti. Bez SSL-a, vašim se podacima može pristupiti, kopirati ih i koristiti u nezakonite ili štetne svrhe. S autentifikacijom imate sekundarnu razinu sigurnosti. SSL-ova infrastruktura privatnih ključeva (PKI) jamči da samo korisnici s ispravnim CA certifikatom mogu pristupiti MongoDB-u.

MongoDB već dugo ima SSL podršku, ali je dramatično poboljšao SSL podršku u posljednjih nekoliko verzija. Prije toga, ako ste željeli koristiti SSL, morali ste ga preuzeti i ručno sastaviti s verzijom MongoDB Community. Od MongoDB 3.0, SSL se po defaultu kompajlira sa softverom. 

Stare verzije MongoDB-a također nisu imale valjanu provjeru hosta; provjera valjanosti hosta bila je samo zastava koju možete provjeriti u konfiguracijskoj datoteci koja zadovoljava SSL zahtjev iz veze.

Najnovije verzije SSL-a u MongoDB uključuju sljedeće ključne značajke:

  • Provjere valjanosti hostova (nije obavezno)
  • Sposobnost usmjeravanja na određenu .key datoteku za korištenje
  • Prilagođeno tijelo za izdavanje certifikata (CA) za samopotpisane certifikate ili alternativne potpisnike
  • allowSSL, preferSSL, requireSSLNačini, koji omogućuju vam da odaberete granularnost za svoj SSL uporabu (od manje siguran da više siguran)

SSL: Korištenje prilagođenog CA

Novije verzije SSL-a u MongoDB-u omogućuju vam upotrebu prilagođenog CA. Iako vam ovo daje fleksibilnost u određivanju načina na koji želite raditi sa SSL-om, on dolazi s upozorenjima. Ako jednostavno pokušavate osigurati vezu, možda ćete biti u iskušenju da se odlučite sslAllowInvalidCertficates. Međutim, ovo je općenito loša ideja iz nekoliko razloga:

  • Omogućuje bilo kakvu vezu od isteka do opozvanih certifikata
  • Ne osiguravate ograničenja za određeno ime hosta
  • Nisi ni približno toliko siguran koliko misliš da jesi

Da biste to popravili, jednostavno postavite net.ssl.CAFile, a MongoDB će koristiti i ključ i CA datoteku (to morate učiniti na klijentu).

Međutim, upotreba SSL-a ima poznati nedostatak: performanse. Svakako ćete izgubiti neke performanse kada koristite SSL.

Šifriranje diska

Podaci su ili „u prijenosu“ ili „u mirovanju“. Možete šifrirati jedno ili oboje u MongoDB. Razgovarali smo o šifriranju podataka u prijenosu (SSL). Pogledajmo sada podatke u mirovanju.

Podaci u stanju mirovanja su podaci pohranjeni na disku. Šifriranje podataka u mirovanju obično se odnosi na podatke spremljene na šifrirano mjesto za pohranu. Na ovaj se način sprječava fizička krađa i stvaraju sigurnosne kopije koje se pohranjuju na način koji nije lako pročitati od strane treće strane. Postoje praktična ograničenja za to. Najveće je povjerenje administratorima vašeg sustava - i pod pretpostavkom da haker nije dobio administrativni pristup sustavu.

Ovo nije problem svojstven MongoDB-u. Preventivne mjere koje se koriste u drugim sustavima djeluju i ovdje. Oni mogu uključivati ​​alate za šifriranje kao što su LUKS i cryptfs ili još sigurnije metode kao što je potpisivanje ključeva za šifriranje LDAP-om, pametnim karticama i RSA tokenima.

Kada izvodite ovu razinu šifriranja, morate uzeti u obzir čimbenike poput automatskog montiranja i dešifriranja pogona. Ali to nije novo za vaše administratore sustava. Ovim zahtjevom mogu upravljati na isti način kao i ostalim dijelovima mreže. Dodatna pogodnost je jedan postupak za šifriranje pohrane, a ne jedan za bilo koju tehnologiju koju određena funkcija koristi.

Šifriranje podataka u stanju mirovanja može se riješiti bilo kojim od sljedećih:

  • Šifriraj cijeli volumen
  • Šifrirajte samo datoteke baze podataka
  • Šifriranje u aplikaciji

Prva se stavka može riješiti šifriranjem diska na datotečnom sustavu. Jednostavno je postaviti pomoću LUKS-a i dm-crypta. Samo su prva i druga opcija potrebne za usklađenost s PCI DSS-om i ostale zahtjeve za certificiranjem.

Revizija

Za svaki dobar sigurnosni dizajn najvažnije je biti u mogućnosti pratiti koji je korisnik učinio koju radnju u bazi podataka (slično onome kako biste trebali kontrolirati svoje stvarne poslužitelje). Revizija vam omogućuje filtriranje rezultata određenog korisnika, baze podataka, zbirke ili izvora. Ovo generira zapisnik za pregled svih sigurnosnih incidenata. Što je još važnije, svakom revizoru sigurnosti pokazuje da ste poduzeli ispravne korake da zaštitite svoju bazu podataka od upada i da razumije dubinu svakog upada u slučaju da se dogodi.

Revizija vam omogućuje potpuno praćenje radnji uljeza u vašem okruženju.

Napomena: Revizija je dostupna samo u MongoDB Enterprise. Nije u verziji Zajednice. Dostupan je u nekim drugim verzijama MongoDB-a otvorenog koda, poput Percona Server za MongoDB.