Bistveno vodilo za varnost MongoDB

David Murphy je vodja prakse za MongoDB pri podjetju Percona, ki ponuja rešitve in storitve MySQL in MongoDB v poslovnem razredu.

Varnost MongoDB je spet v novicah. Nedavni nabor zgodb razkriva, kako hekerji zasedajo zbirke podatkov MongoDB in odkupujejo podatke za bitcoin. Po mnenju Rapid7 je na desettisoče naprav MongoDB ogroženih.

Vsi skrbimo za varnost. Če zaženete aplikacije, omrežja ali zbirke podatkov, je varnost vedno glavna težava. Ker se več podjetij za shranjevanje pomembnih poslovnih podatkov obrača na odprtokodno programsko opremo, kot je MongoDB, postaja varnost še večje vprašanje. Odvisno od vašega podjetja imate morda tudi več državnih (na primer Zakon o prenosljivosti in odgovornosti zdravstvenega zavarovanja ali HIPAA) ali poslovnih (Standard za varnost podatkov o plačilnih karticah za industrijo podatkov ali PCI DSS) regulativnih standardov za varnost omrežij, ki jih morate upoštevati.

Je programska oprema za zbirke podatkov MongoDB varna? Ali ustreza tem standardom? Kratek odgovor: Da, in ja! Preprosto je treba vedeti, kako nastaviti, konfigurirati in delati z določeno namestitvijo.

V tem članku bom obravnaval varnost MongoDB. MongoDB je varen za uporabo - če veste, kaj iskati in kako ga konfigurirati.

Najprej, kako se ljudje zmotijo ​​z varnostjo MongoDB? Ko gre za varnost MongoDB, je uporabnikov več ključnih področij:

• Uporaba privzetih vrat
• Preverjanje pristnosti ni mogoče takoj (največja težava!)
• Ko uporabljate preverjanje pristnosti, omogočite vsem širok dostop
• Ne uporablja LDAP za vsiljevanje vrtenja gesla
• Ne vsiljuje uporabe SSL v zbirki podatkov
• Ne omejuje dostopa do baze podatkov do znanih omrežnih naprav (gostitelji aplikacij, izravnalniki obremenitve itd.)
• Ne omejuje, katero omrežje posluša (vendar to ne vpliva več na podprte različice)

MongoDB ima pet temeljnih varnostnih področij:

• Preverjanje pristnosti. LDAP Authentication centralizira elemente v imeniku vašega podjetja.
• Pooblastilo. Pooblastilo določa, katere kontrole dostopa na osnovi vlog zagotavlja baza podatkov.
• Šifriranje. Šifriranje lahko razdelimo na At-Rest in In-Transit. Šifriranje je ključnega pomena za zaščito MongoDB.
• Revizija. Revizija se nanaša na zmožnost videti, kdo je kaj naredil v zbirki podatkov.
• Upravljanje. Upravljanje se nanaša na preverjanje veljavnosti dokumentov in preverjanje občutljivih podatkov (kot so številka računa, geslo, številka socialne varnosti ali datum rojstva). To se nanaša tako na vedenje, kje so shranjeni občutljivi podatki, kot tudi na preprečevanje vnosa občutljivih podatkov v sistem.

Preverjanje LDAP

MongoDB ima vgrajene uporabniške vloge in jih privzeto izklopi. Pogreša pa elemente, kot so zapletenost gesla, rotacija na podlagi starosti ter centralizacija in identifikacija uporabniških vlog v primerjavi s storitvenimi funkcijami. Te so bistvene za sprejemanje predpisov, kot je skladnost s PCI DSS. Na primer, PCI DSS prepoveduje uporabo starih gesel in gesla, ki jih je mogoče zlahka zlomiti, in zahteva spremembe dostopa uporabnika, kadar koli se stanje spremeni (na primer, ko uporabnik zapusti oddelek ali podjetje).

Na srečo lahko LDAP uporabimo za zapolnitev mnogih teh vrzeli. Številni konektorji omogočajo uporabo sistemov Windows Active Directory (AD) za pogovor z LDAP.

Opomba: Podpora za LDAP je na voljo samo v podjetju MongoDB Enterprise. Ni v različici Skupnosti. Na voljo je v drugih odprtokodnih različicah MongoDB, kot je Percona Server za MongoDB.

MongoDB 3.2 shranjuje uporabnike v LDAP, ne pa tudi vlog (te so trenutno shranjene na posameznih strojih). MongoDB 3.4 Enterprise bi moral uvesti možnost shranjevanja vlog v LDAP za centraliziran dostop. (O vlogah bomo razpravljali kasneje.)

Percona

Z uporabo LDAP in AD lahko uporabnike povežete s svojim imenikom podjetja. Ko zamenjajo vlogo ali zapustijo podjetje, jih lahko človeški viri odstranijo iz vaše zbirke podatkov. Tako imate vzpostavljen avtomatiziran sistem, ki zagotavlja, da lahko to storijo samo tisti, do katerih želite ročno dostopati, ne da bi kaj po naključju zamudili.

LDAP v Mongu je pravzaprav enostaven. MongoDB ima poseben ukaz, ki mu naroči, naj preveri zunanjo bazo podatkov LDAP: $ zunanji.

Nekatera druga opozorila za uporabo LDAP:

• Ustvari uporabnika z .createUser kot običajno, vendar se prepričajte, da uporabljate oznake virov db / collection.
• Poleg tega preverjanje pristnosti LDAP zahteva še dve polji:
  • mehanizem: “PLAIN”
  • digestPassword: false

Vloge po meri

Nadzor dostopa na osnovi vlog (RBAC) je jedro MongoDB. Vgrajene vloge so na voljo v MongoDB od različice 2.6. Lahko celo izdelate svoje, vse do določenih dejanj, ki jih lahko določen uporabnik dovoli. To vam omogoča, da določite, kaj lahko določen uporabnik naredi ali vidi z natančnostjo britvice. To je bistvena funkcija MongoDB, ki je na voljo v skoraj vseh ponudnikovih različicah odprtokodne programske opreme.

Pet glavnih vgrajenih vlog MongoDB, ki se jih morate zavedati:

• preberite:
  • Dostop samo za branje, ki ga običajno dobi večina uporabnikov
• brati, pisati:
  • brati, pisati dostop omogoča urejanje podatkov
  • brati, pisati vključuje branje
• dbOwner:
  • Vključuje brati, pisati, dbAdmin, userAdmin (za zbirko podatkov). userAdmin pomeni dodajanje ali odstranjevanje uporabnikov, dodelitev pravic uporabnikom in ustvarjanje vlog. Te privilegije so dodeljene samo določenemu strežniku baz podatkov.
• dbAdminAnyDatabase:
  • Ustvari dbAdmin v vseh zbirkah podatkov, vendar ne dovoljuje skrbništva uporabnikov (na primer za ustvarjanje ali odstranjevanje uporabnikov). Ustvarite lahko indekse, stiskanje klicev in še več. To ne omogoča dostopa do ostrenja.
• koren:
  • To je super uporabnik, vendar z omejitvami
  • Zmore večino stvari, vendar ne vseh:
    • Zbirke sistema ni mogoče spremeniti
    • Nekateri ukazi za to vlogo še vedno niso na voljo, odvisno od različice. Koreninska vloga MongoDB 3.2 na primer ne omogoča spreminjanja velikosti oploga ali profilerja, korenska vloga MongoDB 3.4 pa ne omogoča branja trenutnih pogledov.

Zbirke podatkovnih zbirk in zbirk

Nadomestni znak pomeni dodelitev dovoljenj velikim skupinam baz podatkov ali zbirk (ali vsem) na strežniku. Z ničelno vrednostjo lahko določite vse zbirke podatkov ali zbirke in se izognete dbAdminAnyDatabase vlogo. To določenim uporabnikom omogoča, da imajo vse privilegije, vključno s skrbniškimi funkcijami.

To je nevarno.

Ko uporabljate nadomestne znake, podelite veliko posebnih privilegijev in zavedajte se, da odpirate možne načine napada:

• readWriteAnyDatabase je zelo širok in izpostavlja uporabniška imena in vloge potencialnemu napadu prek uporabnika aplikacije
• Uporaba nadomestnih znakov pomeni, da določenih aplikacij ne boste omejili na določene zbirke podatkov
• Nadomestni znak vam preprečuje uporabo večnamenskih storitev z več baz podatkov
• Do novih baz podatkov se dostop samodejno ne odobri

Ustvarjanje vloge po meri

Moč vlog MongoDB izhaja iz ustvarjanja vlog po meri. V vlogi po meri lahko določite, da je mogoče določeno dejanje v katerem koli viru določiti za določenega uporabnika. S to stopnjo razdrobljenosti lahko globoko nadzirate, kdo lahko kaj počne v vašem okolju MongoDB.

Pri določanju vloge po meri obstajajo štiri različne vrste virov:

• db. Določa bazo podatkov. Za ime lahko uporabite niz ali "" za "katero koli" (brez nadomestnih znakov).
• zbiranje. Določa zbirko dokumentov. Za ime lahko uporabite niz ali "" za "katero koli" (brez nadomestnih znakov).
• grozd. Določa ostreno gručo ali druge vire metapodatkov. To je logična vrednost true / false.
• anyResource. Določa dostop do česar koli in kjer koli. To je logična vrednost true / false.

Vsaka vloga lahko podeduje lastnosti druge vloge. Obstaja polje, imenovano »vloge«, v njem pa lahko spustite novo vlogo. Podedoval bo lastnosti določene vloge.

Uporaba createRole da v matriko dodate vlogo.

Uporabniku ali vlogi lahko dodate nove ali obstoječe zbirke podatkov. Na primer, lahko dodate dostop za branje in pisanje do baze podatkov, tako da jo dodate vlogi.

Uporabi grantPrivilegesToRole ukaz za dodajanje novih virov obstoječi vlogi.

Spodaj je primer ustvarjanja nove uporabniške vloge Super. Namen te vloge je ponovno imeti enega uporabnika, ki v okolju MongoDB nikakor ni omejen (v izrednih razmerah).

db = db.geSiblingDB (“skrbnik”);

db.createRole ({

vloga: “superRoot”,

privilegiji: [{

vir: {anyResource: true},

dejanja: [‘anyAction’]

     }]     

vloge: []

});

db.createUser ({

uporabnik: “comanyDBA”,

pwd: “EWqeeFpUt9 * 8zq”,

vloge: [“superRoot”]

})

Ti ukazi ustvarijo novo vlogo v bazi podatkov geSiblingDB poklical superRoot in tej vlogi dodelite kateri koli vir in kakršno koli dejanje. Nato v isti imenovani bazi podatkov ustvarimo novega uporabnika companyDBA (z geslom) in mu dodelite novo superRoot vlogo.

Uporaba SSL za vse stvari

SSL pomaga zagotoviti varnost vaših podatkov v nezavarovanih omrežjih. Če uporabljate bazo podatkov, ki komunicira z internetom, uporabite SSL.

Obstajata dva zelo dobra razloga za uporabo SSL za zaščito MongoDB: zasebnost in preverjanje pristnosti. Brez SSL lahko do vaših podatkov dostopate, jih kopirate in uporabljate za nezakonite ali škodljive namene. Z avtentikacijo imate sekundarno raven varnosti. SSL-jeva infrastruktura zasebnih ključev (PKI) zagotavlja, da lahko samo uporabniki s pravilnim potrdilom CA dostopajo do MongoDB.

MongoDB ima podporo SSL že dolgo, vendar je v zadnjih nekaj različicah močno izboljšal podporo SSL. Prej, če ste želeli uporabljati SSL, ste ga morali prenesti in ročno sestaviti z različico MongoDB Community. Od MongoDB 3.0 je SSL privzeto sestavljen s programsko opremo.

V starejših različicah MongoDB tudi ni bilo veljavnega preverjanja gostitelja; potrditev gostitelja je bila zgolj zastavica, ki jo lahko preverite v konfiguracijski datoteki, ki izpolnjuje zahtevo SSL iz povezave.

Najnovejše različice SSL v MongoDB vključujejo naslednje ključne lastnosti:

• Preverjanje veljavnih gostiteljev (neobvezno)
• Sposobnost usmerjanja na določeno nastavitveno datoteko .key za uporabo
• Potrjevalni organ po meri (CA) za samopodpisana potrdila ali druge podpisnike
• allowSSL, preferSSL, requireSSL načini, ki omogočajo izbiro razdrobljenosti za uporabo SSL (od manj varne do bolj varne)

SSL: Uporaba CA po meri

Novejše različice SSL v MongoDB omogočajo uporabo CA po meri. Čeprav vam to omogoča prilagodljivost pri določanju, kako želite delati s protokolom SSL, prihaja z opozorili. Če preprosto poskušate zaščititi povezavo, boste morda v skušnjavi, da se odločite za sslAllowInvalidCertficates. Vendar je to na splošno slaba ideja iz nekaj razlogov:

• Omogoča vsako povezavo s potekom na preklicana potrdila
• Ne zagotavljate omejitev za določeno ime gostitelja
• Niste niti približno tako varni, kot mislite, da ste

Če želite to popraviti, preprosto nastavite net.ssl.CAFile, in MongoDB bo uporabil oboje ključ in datoteko CA (to morate storiti na odjemalcu).

Uporaba SSL pa ima znano pomanjkljivost: zmogljivost. Pri uporabi SSL boste zagotovo izgubili nekaj zmogljivosti.

Šifriranje diska

Podatki so bodisi v prenosu bodisi v mirovanju. V MongoDB lahko šifrirate enega ali oba. Razpravljali smo o šifriranju podatkov med prenosom (SSL). Zdaj pa poglejmo podatke v mirovanju.

Podatki v mirovanju so podatki, shranjeni na disku. Šifriranje podatkov v mirovanju se običajno nanaša na podatke, shranjene na šifriranem mestu za shranjevanje. To je namenjeno preprečevanju kraje s fizičnimi sredstvi in ​​ustvarjanju varnostnih kopij, ki so shranjene na način, ki ga tretja oseba ne more zlahka prebrati. Za to obstajajo praktične omejitve. Največ je zaupanje sistemskim skrbnikom - in če domnevamo, da heker ni dobil skrbniškega dostopa do sistema.

To ni vprašanje, ki je značilno samo za MongoDB. Preventivni ukrepi, ki se uporabljajo v drugih sistemih, delujejo tudi tukaj. Vključujejo lahko orodja za šifriranje, kot so LUKS in cryptfs, ali celo bolj varne metode, kot je podpisovanje šifrirnih ključev z LDAP, pametnimi karticami in žetoni tipa RSA.

Pri izvajanju te ravni šifriranja morate upoštevati dejavnike, kot sta samodejno sestavljanje in dešifriranje pogonov. Toda to za vaše sistemske skrbnike ni novo. To zahtevo lahko upravljajo na enak način kot v drugih delih omrežja. Dodatna prednost je en sam postopek za šifriranje pomnilnika, ne en za katero koli tehnologijo, ki jo določena funkcija uporablja.

Šifriranje podatkov v mirovanju je mogoče rešiti s katerim koli ali z vsem naslednjim:

• Šifriraj celoten zvezek
• Šifrirajte samo datoteke zbirke podatkov
• Šifriraj v aplikaciji

Prvi element je mogoče rešiti s šifriranjem diska v datotečnem sistemu. Z uporabo LUKS in dm-crypt je enostavno nastaviti. Za skladnost s PCI DSS in druge zahteve za certificiranje sta potrebni samo prva in druga možnost.

Revizija

Za vsako dobro varnostno zasnovo je bistveno, da lahko sledite, kateri uporabnik je kaj storil v zbirki podatkov (podobno kot bi morali nadzorovati svoje dejanske strežnike). Revizija vam omogoča filtriranje rezultatov določenega uporabnika, baze podatkov, zbirke ali izvorne lokacije. To ustvari dnevnik za pregled morebitnih varnostnih incidentov. Še pomembneje je, da vsakemu revizorju varnosti pokažete, da ste pravilno ukrepali, da zaščitite svojo bazo podatkov pred vdorom in razumete globino kakršnega koli vdora.

Revizija vam omogoča, da v celoti sledite dejanjem vsiljivca v vašem okolju.

Opomba: Revizija je na voljo samo v podjetju MongoDB Enterprise. Ni v različici Skupnosti. Na voljo je v nekaterih drugih odprtokodnih različicah MongoDB, kot je Percona Server za MongoDB.