Būtiskais MongoDB drošības ceļvedis

Deivids Mērfijs ir MongoDB prakses vadītājs Perkonā, kas ir uzņēmuma klases MySQL un MongoDB risinājumu un pakalpojumu sniedzējs.

MongoDB drošība atkal ir ziņās. Nesenais stāstu pārklājums atklāj, kā hakeri ir izmantojuši MongoDB datu bāzes un izpirkuši datus bitkoiniem. Saskaņā ar Rapid7 datiem ir apdraudēti desmitiem tūkstošu MongoDB instalāciju.

Mēs visi uztraucamies par drošību. Ja palaižat lietojumprogrammas, tīklus vai datu bāzes, drošība vienmēr ir aktuāla problēma. Vairākiem uzņēmumiem pievēršoties atvērtā pirmkoda programmatūrai, piemēram, MongoDB, lai saglabātu svarīgus uzņēmuma datus, drošība kļūst par vēl lielāku jautājumu. Atkarībā no jūsu uzņēmējdarbības jums var būt arī vairāki valdības (piemēram, Veselības apdrošināšanas pārnesamības un atbildības likums vai HIPAA) vai uzņēmējdarbības (Maksājumu karšu nozares datu drošības standarts vai PCI DSS) tīkla drošības normatīvie standarti, kas jums jāievēro.

Vai MongoDB datu bāzes programmatūra ir droša? Vai tas atbilst šiem standartiem? Īsā atbilde: Jā, tā ir, un jā! Vienkārši ir jāzina, kā iestatīt, konfigurēt un strādāt ar konkrēto instalāciju.

Šajā rakstā es pievērsīšos MongoDB drošībai. MongoDB lietošana ir droša - ja jūs zināt, ko meklēt un kā to konfigurēt.

Pirmkārt, kā cilvēki kļūdās ar MongoDB drošību? Ir vairākas galvenās jomas, kas palielina lietotāju uzmanību MongoDB drošībai:

• Izmantojot noklusējuma porti
• Netiek nekavējoties iespējota autentifikācija (lielākā problēma!)
• Izmantojot autentifikāciju, nodrošinot visiem plašu piekļuvi
• Neizmantojot LDAP, lai piespiestu paroles pagriešanu
• Netiek piespiests SSL lietojums datu bāzē
• Neierobežo piekļuvi datu bāzei zināmām tīkla ierīcēm (lietojumprogrammu saimniekiem, slodzes līdzsvarotājiem utt.)
• Neierobežojot to, kurš tīkls klausās (tomēr tas vairs neietekmē nevienu atbalstīto versiju)

MongoDB ir piecas galvenās drošības jomas:

• Autentifikācija. LDAP autentifikācija centralizē vienumus jūsu uzņēmuma direktorijā.
• Atļauja. Autorizācija nosaka, kādas lomas balstītas piekļuves kontroles nodrošina datu bāze.
• Šifrēšana. Šifrēšanu var sadalīt miera stāvoklī un tranzītā. Šifrēšana ir kritiska, lai nodrošinātu MongoDB.
• Revīzija. Revīzija attiecas uz iespēju datu bāzē redzēt, kas ko ir darījis.
• Valdīšana. Pārvaldība attiecas uz dokumentu apstiprināšanu un sensitīvu datu pārbaudi (piemēram, konta numuru, paroli, sociālās apdrošināšanas numuru vai dzimšanas datumu). Tas attiecas gan uz to, lai uzzinātu, kur tiek glabāti sensitīvi dati, gan arī uz to, lai novērstu sensitīvu datu ievadīšanu sistēmā.

LDAP autentifikācija

MongoDB ir iebūvētas lietotāju lomas un pēc noklusējuma tās izslēdz. Tomēr tai pietrūkst tādu elementu kā paroles sarežģītība, vecumu rotācija, kā arī lietotāju lomu un pakalpojumu funkciju centralizācija un identificēšana. Tie ir būtiski, lai pieņemtu tādus noteikumus kā PCI DSS atbilstība. Piemēram, PCI DSS aizliedz veco paroļu un viegli sadalāmo paroļu izmantošanu un prasa mainīt lietotāja piekļuvi ikreiz, kad mainās statuss (piemēram, kad lietotājs atstāj nodaļu vai uzņēmumu).

Par laimi, LDAP var izmantot, lai aizpildītu daudzas no šīm nepilnībām. Daudzi savienotāji ļauj izmantot Windows Active Directory (AD) sistēmas, lai runātu ar LDAP.

Piezīme: LDAP atbalsts ir pieejams tikai MongoDB Enterprise. Tas nav kopienas versijā. Tas ir pieejams citās MongoDB atvērtā pirmkoda versijās, piemēram, Percona Server for MongoDB.

MongoDB 3.2 glabā lietotājus LDAP, bet ne lomas (tās pašlaik tiek glabātas atsevišķās mašīnās). MongoDB 3.4 Enterprise būtu jāievieš spēja uzglabāt lomas LDAP centralizētai piekļuvei. (Lomas mēs apspriedīsim vēlāk.)

Perkona

Izmantojot LDAP un AD, jūs varat piesaistīt lietotājus sava uzņēmuma direktorijai. Kad viņi maina lomas vai pamet uzņēmumu, tos var noņemt ar personāla resursiem no jūsu datu bāzes grupas. Tādējādi jums ir izveidota automatizēta sistēma, lai nodrošinātu, ka to var izdarīt tikai tie, kuriem vēlaties manuāli piekļūt datiem, kaut ko nejauši nepalaidot garām.

LDAP Mongo valodā faktiski ir viegli. MongoDB ir īpaša komanda, kas liek tai pārbaudīt ārējo LDAP datu bāzi: $ external.

Daži citi brīdinājumi par LDAP lietošanu:

• Izveidojiet lietotāju ar .createUser kā parasti, bet noteikti izmantojiet db / collection resursu tagus.
• Turklāt LDAP autentifikācijai ir nepieciešami vēl divi lauki:
  • mehānisms: “PLAIN”
  • digestPassword: nepatiesa

Pielāgotas lomas

Uz lomām balstīta piekļuves kontrole (RBAC) ir MongoDB pamatā. Iebūvētās lomas MongoDB ir pieejamas kopš 2.6 versijas. Jūs pat varat izveidot pats, līdz konkrētām darbībām, kuras konkrētam lietotājam var atļaut. Tas ļauj precīzi noteikt, ko konkrēts lietotājs var darīt vai redzēt. Šī ir galvenā MongoDB funkcija, ka tā ir pieejama gandrīz katra atvērtā koda programmatūras pārdevēja versijā.

Piecas galvenās iebūvētās MongoDB lomas, kas jums jāzina:

• lasīt:
  • Tikai lasīšanas piekļuve, kas parasti tiek piešķirta lielākajai daļai lietotāju
• Lasīt rakstīt:
  • Lasīt rakstīt piekļuve ļauj rediģēt datus
  • Lasīt rakstīt ietver lasīt
• dbĪpašnieks:
  • Ietilpst Lasīt rakstīt, dbAdmin, userAdmin (datu bāzei). userAdmin nozīmē lietotāju pievienošanu vai noņemšanu, privilēģiju piešķiršanu lietotājiem un lomu izveidi. Šīs privilēģijas tiek piešķirtas tikai konkrētajam datu bāzes serverim.
• dbAdminAnyDatabase:
  • Izveido dbAdmin visās datu bāzēs, taču neatļauj lietotāju administrēšanu (piemēram, izveidot vai noņemt lietotājus). Varat izveidot indeksus, zvanu blīvēšanu un daudz ko citu. Tas nenodrošina šķembu piekļuvi.
• sakne:
  • Tas ir superlietotājs, taču ar ierobežojumiem
  • Tas var darīt lielāko daļu lietu, bet ne visas:
    • Nevar mainīt sistēmas kolekciju
    • Dažas komandas šai lomai joprojām nav pieejamas, atkarībā no versijas. Piemēram, saknes loma MongoDB 3.2 neļauj mainīt oplog vai profilētāja lielumu, un MongoDB 3.4 saknes loma neļauj lasīt pašreizējos skatus.

Aizstājējzīmes datubāzes un kolekcijas

Aizstājējzīme nozīmē atļauju piešķiršanu lielām datu bāzu vai kolekciju grupām (vai visām) serverī. Izmantojot nulles vērtību, varat norādīt visas datu bāzes vai kolekcijas un izvairīties no dbAdminAnyDatabase lomu. Tas ļauj konkrētiem lietotājiem izmantot visas privilēģijas, ieskaitot administrēšanas funkcijas.

Tas ir bīstami.

Izmantojot aizstājējzīmes, jūs piešķirat daudz īpašu privilēģiju, un jums jāapzinās, ka paverat iespējamos uzbrukuma veidus:

• readWriteAnyDatabase ir ārkārtīgi un pakļauj lietotāju vārdus un lomas iespējamam uzbrukumam, izmantojot lietojumprogrammas lietotāju
• Izmantojot aizstājējzīmes, jūs neierobežosiet konkrētas lietojumprogrammas tikai noteiktās datu bāzēs
• Aizstājējzīmju izmantošana neļauj jums izmantot multiziņu ar vairākām datu bāzēm
• Jaunām datu bāzēm netiek automātiski piešķirta piekļuve

Pielāgotas lomas izveide

MongoDB lomu spēks rodas, izveidojot pielāgotas lomas. Pielāgotajā lomā varat norādīt, ka konkrētam lietotājam var norādīt jebkuru darbību ar jebkuru resursu. Izmantojot šo detalizācijas pakāpi, jūs varat dziļi kontrolēt, kas var darīt jūsu MongoDB vidē.

Kad jānorāda pielāgota loma, ir četri atšķirīgi resursu veidi:

• db. Norāda datu bāzi. Vārdam var izmantot virkni vai “jebkuram” (bez aizstājējzīmes).
• kolekcija. Norāda dokumentu kolekciju. Vārdam var izmantot virkni vai “jebkuram” (bez aizstājējzīmes).
• kopa. Norāda sadalītu kopu vai citus metadatu resursus. Tā ir patiesā / nepatiesā Būla vērtība.
• anyResource. Norāda piekļuvi jebkuram un jebkur. Tā ir patiesā / nepatiesā Būla vērtība.

Jebkura loma var pārmantot citas lomas īpašības. Ir masīvs, ko sauc par “lomām”, un masīvā varat nomest jaunu lomu. Tas mantos norādītās lomas īpašības.

Izmantot createRole lai pievienotu masīvam lomu.

Lietotājam vai lomai varat pievienot jaunas vai esošas datu bāzes. Piemēram, varat pievienot lasīšanas un rakstīšanas piekļuvi datu bāzei, pievienojot datu bāzi lomai.

Izmantojiet grantPrivilegesToRole komandu pievienot jaunus resursus esošai lomai.

Tālāk ir sniegts jaunas Super lietotāja lomas izveides piemērs. Šīs lomas mērķis atkal ir viens lietotājs, kurš MongoDB vidē nekādā veidā nav ierobežots (ārkārtas situācijām).

db = db.geSiblingDB (“administrators”);

db.createRole ({

loma: “superRoot”,

privilēģijas: [{

resurss: {anyResource: true},

darbības: [’anyAction’]

     }]     

lomas: []

});

db.createUser ({

lietotājs: “comanyDBA”,

pwd: “EWqeeFpUt9 * 8zq”,

lomas: [“superRoot”]

})

Šīs komandas izveido jaunu lomu datu bāzē geSiblingDB sauca superRoot un piešķiriet šai lomai jebkuru resursu un darbību. Tad tajā pašā datu bāzē mēs izveidojam jaunu lietotāju uzņēmumsDBA (ar paroli) un piešķiriet tai jauno superRoot lomu.

SSL izmantošana visām lietām

SSL palīdz nodrošināt jūsu datu drošību, izmantojot nenodrošinātus tīklus. Ja izmantojat datu bāzi, kas mijiedarbojas ar internetu, jums jāizmanto SSL.

MongoDB aizsardzībai SSL izmantošanai ir divi ļoti labi iemesli: privātums un autentifikācija. Bez SSL jūsu datiem var piekļūt, tos kopēt un izmantot nelegāliem vai kaitīgiem mērķiem. Izmantojot autentifikāciju, jums ir sekundārs drošības līmenis. SSL privātās atslēgas infrastruktūra (PKI) garantē, ka tikai MongoDB var piekļūt tikai lietotāji ar pareizu CA sertifikātu.

MongoDB jau ilgu laiku ir bijis SSL atbalsts, taču pēdējās versijās tas ir dramatiski uzlabojis SSL atbalstu. Iepriekš, ja vēlaties izmantot SSL, jums tas bija jālejupielādē un jāapkopo manuāli ar MongoDB kopienas versiju. Sākot ar MongoDB 3.0, pēc noklusējuma SSL tiek kompilēts ar programmatūru.

MongoDB mantotajām versijām trūka arī derīgas resursdatora pārbaudes; resursdatora validācija bija tikai karodziņš, kuru varat pārbaudīt konfigurācijas failā, kas apmierināja SSL pieprasījumu no savienojuma.

Jaunākās SSL versijas MongoDB ietver šādas galvenās funkcijas:

• Derīgu saimnieku pārbaudes (pēc izvēles)
• Spēja norādīt uz noteiktu iestatāmo .key failu, kuru izmantot
• Pielāgota sertifikātu iestāde (CA) pašparakstītiem sertifikātiem vai alternatīviem parakstītājiem
• allowSSL, dod priekšrokuSSL, pieprasīt SSL režīmi, kas ļauj izvēlēties SSL izmantošanas precizitāti (no mazāk droša līdz drošākam)

SSL: izmantojot pielāgotu CA

Jaunākās SSL versijas MongoDB ļauj izmantot pielāgotu CA. Lai gan tas dod jums elastību, norādot, kā vēlaties strādāt ar SSL, tas nāk ar brīdinājumiem. Ja jūs vienkārši mēģināt nodrošināt savienojumu, jums varētu rasties kārdinājums izvēlēties sslAllowInvalidCertficates. Tomēr tā parasti ir slikta ideja dažu iemeslu dēļ:

• Atļauj jebkuru savienojumu no sertifikātiem, kuru derīguma termiņš ir beidzies, līdz atsauktiem
• Jūs nenodrošināt ierobežojumus noteiktam resursdatora nosaukumam
• Jūs ne tuvu neesat tik drošs, kā jūs domājat

Lai to novērstu, vienkārši iestatiet net.ssl.CAFile, un MongoDB izmantos gan atslēgu un CA failu (tas jādara klientā).

SSL izmantošanai tomēr ir zināms trūkums: veiktspēja. Izmantojot SSL, jūs noteikti zaudēsit kādu veiktspēju.

Diska šifrēšana

Dati ir vai nu “tranzītā”, vai “miera stāvoklī”. MongoDB varat šifrēt vienu vai abus. Mēs esam apsprieduši datu šifrēšanu tranzītā (SSL). Tagad apskatīsim datus miera stāvoklī.

Atpūtas dati ir dati, kas saglabāti diskā. Datu mierā šifrēšana parasti attiecas uz datiem, kas saglabāti šifrētā krātuves vietā. Tas ir paredzēts, lai novērstu zādzības ar fiziskiem līdzekļiem un izveidotu dublējumkopijas, kas tiek glabātas tādā veidā, ko trešā persona nevar viegli nolasīt. Tam ir praktiskas robežas. Vislielākais ir uzticēšanās jūsu sistēmas administratoriem - un pieņemot, ka hakeris nav ieguvis administratīvo piekļuvi sistēmai.

Tas nav MongoDB unikāls jautājums. Arī citās sistēmās izmantotie preventīvie pasākumi darbojas šeit. Tie var ietvert šifrēšanas rīkus, piemēram, LUKS un cryptfs, vai pat drošākas metodes, piemēram, šifrēšanas atslēgu parakstīšanu ar LDAP, viedkartēm un RSA tipa marķieriem.

Veicot šāda līmeņa šifrēšanu, jāņem vērā tādi faktori kā disku automātiska uzstādīšana un atšifrēšana. Bet tas nav jauns jūsu sistēmas administratoriem. Viņi var pārvaldīt šo prasību tāpat, kā to pārvalda citās tīkla daļās. Papildu ieguvums ir viena glabāšanas šifrēšanas procedūra, nevis viena katrai tehnoloģijai, kuru izmanto konkrētā funkcija.

Datu mierā šifrēšanu var atrisināt, izmantojot jebkuru no šiem vai visiem šiem veidiem:

• Šifrējiet visu sējumu
• Šifrēt tikai datu bāzes failus
• Šifrēt lietojumprogrammā

Pirmo vienumu var atrisināt ar diska šifrēšanu failu sistēmā. To ir viegli iestatīt, izmantojot LUKS un dm-crypt. PCI DSS atbilstībai un citām sertifikācijas prasībām ir nepieciešamas tikai pirmās un otrās iespējas.

Revīzija

Jebkura laba drošības dizaina centrā ir spēja izsekot, kurš lietotājs veicis kādas darbības datu bāzē (līdzīgi tam, kā jums vajadzētu kontrolēt savus faktiskos serverus). Audits ļauj filtrēt konkrēta lietotāja, datu bāzes, kolekcijas vai avota atrašanās vietas izvadi. Tas ģenerē žurnālu, lai pārskatītu visus drošības incidentus. Vēl svarīgāk ir tas, ka ikvienam drošības auditoram tiek parādīts, ka esat veicis pareizās darbības, lai aizsargātu savu datu bāzi no ielaušanās un izprastu iespējamo ielaušanās dziļumu.

Audits ļauj pilnībā izsekot iebrucēja darbībām jūsu vidē.

Piezīme. Audits ir pieejams tikai MongoDB Enterprise. Tas nav kopienas versijā. Tas ir pieejams dažās citās MongoDB atvērtā pirmkoda versijās, piemēram, Percona Server for MongoDB.