Základný sprievodca po bezpečnosti MongoDB

David Murphy slúži ako praktický manažér pre MongoDB v spoločnosti Percona, poskytovateľa podnikových riešení a služieb MySQL a MongoDB.

Zabezpečenie MongoDB je opäť v správach. Nedávne množstvo príbehov odhaľuje, ako sa hackeri zmocňujú databáz MongoDB a vykupujú údaje za bitcoiny. Podľa Rapid7 boli kompromitované desaťtisíce inštalácií MongoDB.

Všetci sa obávame o bezpečnosť. Ak prevádzkujete aplikácie, siete alebo databázy, zabezpečenie je vždy problémom najvyššej úrovne. Pretože sa viac spoločností na ukladanie dôležitých podnikových údajov obracia na softvér s otvoreným zdrojom, ako je MongoDB, stáva sa bezpečnosť ešte väčšou otázkou. V závislosti na vašom podnikaní môžete mať tiež viac vládnych (napr. Zákon o zdravotnom poistení a zodpovednosti za škodu alebo zákon HIPAA) alebo podnikových (štandard zabezpečenia údajov o platobnej karte alebo PCI DSS), ktoré musíte dodržiavať.

Je databázový softvér MongoDB bezpečný? Spĺňa tieto normy? Krátka odpoveď: Áno je a áno je! Stačí jednoducho vedieť, ako nastaviť, nakonfigurovať a pracovať s konkrétnou inštaláciou.

V tomto článku sa budem venovať bezpečnosti MongoDB. Používanie MongoDB je bezpečné - ak viete, čo treba hľadať a ako ich nakonfigurovať.

V prvom rade, ako sa ľudia mýlia s bezpečnosťou MongoDB? Existuje niekoľko kľúčových oblastí, ktoré narážajú na používateľov, pokiaľ ide o bezpečnosť MongoDB:

• Používajú sa predvolené porty
• Nepovolenie autentifikácie okamžite (najväčší problém!)
• Pri používaní autentifikácie poskytuje všetkým široký prístup
• Nepoužívanie protokolu LDAP na vynútenie rotácie hesiel
• Nevynútiť použitie SSL v databáze
• Neobmedzuje prístup k databáze známym sieťovým zariadeniam (hostitelia aplikácií, nástroje na vyrovnávanie zaťaženia atď.)
• Neobmedzuje sa, ktorá sieť počúva (toto však už nemá vplyv na podporované verzie).

MongoDB má päť základných bezpečnostných oblastí:

• Overenie. Overovanie LDAP centralizuje položky vo vašom firemnom adresári.
• Povolenie. Autorizácia definuje, aké kontroly prístupu na základe rolí poskytuje databáza.
• Šifrovanie. Šifrovanie je možné rozdeliť na At-Rest a In-Transit. Šifrovanie je pre zabezpečenie MongoDB nevyhnutné.
• Auditovanie. Auditovanie sa týka schopnosti zistiť, kto čo v databáze urobil.
• Správa vecí verejných. Správa vecí verejných sa týka overenia dokumentov a kontroly citlivých údajov (napríklad čísla účtu, hesla, rodného čísla alebo dátumu narodenia). Týka sa to jednak vedieť, kde sú citlivé údaje uložené, jednak zabrániť zavedeniu citlivých údajov do systému.

Autentifikácia LDAP

MongoDB má zabudované užívateľské roly a predvolene ich vypína. Chýbajú mu však položky, ako je zložitosť hesla, rotácia podľa veku, centralizácia a identifikácia používateľských rolí oproti službám. Tie sú nevyhnutné na splnenie predpisov, ako napríklad súlad s PCI DSS. Napríklad PCI DSS zakazuje používanie starých hesiel a ľahko prekonateľných hesiel a vyžaduje zmeny prístupu používateľov vždy, keď sa zmení stav (napríklad keď používateľ opustí oddelenie alebo spoločnosť).

Našťastie je možné použiť LDAP na vyplnenie mnohých z týchto medzier. Mnoho konektorov umožňuje na komunikáciu s LDAP používať systémy Windows Active Directory (AD).

Poznámka: Podpora LDAP je k dispozícii iba v serveri MongoDB Enterprise. Nie je vo verzii pre komunitu. Je k dispozícii v iných otvorených verziách servera MongoDB, ako je napríklad server Percona Server pre server MongoDB.

MongoDB 3.2 ukladá používateľov na LDAP, ale nie roly (tieto sú momentálne uložené na jednotlivých počítačoch). MongoDB 3.4 Enterprise by mal zaviesť schopnosť ukladať role v LDAP pre centralizovaný prístup. (O rolách sa ešte zmienime.)

Percona

Pomocou LDAP a AD môžete spojiť používateľov s podnikovým adresárom. Keď zmenia roly alebo opustia spoločnosť, môžu byť odstránení ľudskými prostriedkami z vašej databázovej skupiny. Máte teda zavedený automatizovaný systém, ktorý zaisťuje, že tak môžu urobiť iba tí, ku ktorým chcete získať prístup manuálne, bez toho, aby vám niečo náhodou chýbalo.

LDAP v Mongo je vlastne jednoduchý. MongoDB má špeciálny príkaz, ktorý mu hovorí, aby skontroloval externú databázu LDAP: $ externé.

Niektoré ďalšie upozornenia na používanie protokolu LDAP:

• Vytvorte používateľa pomocou .createUser ako obvykle, ale určite choďte so značkami prostriedkov db / collection.
• Overenie LDAP navyše vyžaduje ďalšie dve polia:
  • mechanizmus: „PLAIN“
  • digestPassword: false

Vlastné roly

Kontrola prístupu na základe rolí (RBAC) je základom MongoDB. Vstavané roly sú v MongoDB dostupné od verzie 2.6. Môžete si dokonca vytvoriť svoj vlastný, a to až po konkrétne akcie, ktoré môže mať konkrétny používateľ povolené. Takto môžete s presnosťou žiletky definovať, čo môže konkrétny používateľ robiť alebo vidieť. Toto je hlavná funkcia MongoDB, ktorá je k dispozícii takmer vo verzii open source softvéru každého dodávateľa.

Mali by ste si uvedomiť päť hlavných vstavaných rolí MongoDB:

• čítať:
  • Prístup iba na čítanie, ktorý sa zvyčajne poskytuje väčšine používateľov
• čítaj píš:
  • čítaj píš prístup umožňuje úpravy údajov
  • čítaj píš obsahuje prečítané
• dbOwner:
  • Zahŕňa čítaj píš, dbAdmin, userAdmin (pre databázu). userAdmin znamená pridávanie alebo odoberanie používateľov, udeľovanie oprávnení používateľom a vytváranie rolí. Tieto privilégiá sú pridelené iba konkrétnemu databázovému serveru.
• dbAdminAnyDatabase:
  • Tvorí dbAdmin vo všetkých databázach, ale neumožňuje správu používateľov (napríklad na vytváranie alebo odstraňovanie používateľov). Môžete vytvárať indexy, zhustenia hovorov a ďalšie. Toto neposkytuje prístup k zdieľaniu.
• koreň:
  • Toto je superužívateľ, ale s obmedzeniami
  • Dokáže väčšinu vecí, ale nie všetky:
    • Zbierku systému nie je možné zmeniť
    • Niektoré príkazy pre túto rolu stále nie sú k dispozícii, v závislosti od verzie. Napríklad koreňová rola MongoDB 3.2 vám neumožňuje zmeniť veľkosť oplog alebo profilovača a koreňová rola MongoDB 3.4 vám neumožňuje čítať aktuálne zobrazenia.

Zástupné databázy a zbierky

Zástupný znak znamená udelenie povolení veľkým skupinám databáz alebo zbierok (alebo všetkým) na serveri. S nulovou hodnotou môžete určiť všetky databázy alebo kolekcie a vyhnúť sa dbAdminAnyDatabase úlohu. Toto umožňuje konkrétnym používateľom mať všetky oprávnenia vrátane funkcií správy.

To je nebezpečné.

Pri použití zástupných znakov udeľujete množstvo zvláštnych privilégií a mali by ste si uvedomiť, že otvárate možné cesty útoku:

• readWriteAnyDatabase je extrémne široký a vystavuje používateľské mená a roly potenciálnemu útoku prostredníctvom používateľa aplikácie
• Použitie zástupných znakov znamená, že nebudete obmedzovať konkrétne aplikácie na konkrétne databázy
• Zástupné znaky vám bránia vo využívaní viacerých zdrojov s viacerými databázami
• K novým databázam nie je automaticky poskytnutý prístup

Vytvorenie vlastnej roly

Sila rolí MongoDB pochádza z vytvárania vlastných rolí. Vo vlastnej role môžete určiť, že pre konkrétneho používateľa je možné zadať ľubovoľnú akciu na ľubovoľnom prostriedku. Vďaka tejto úrovni podrobnosti môžete hlboko ovládať, kto môže čo robiť vo vašom prostredí MongoDB.

Pokiaľ ide o zadanie vlastnej role, existujú štyri odlišné typy zdrojov:

• db. Určuje databázu. Môžete použiť reťazec pre meno alebo „“ pre „akýkoľvek“ (bez zástupných znakov).
• zbierka. Určuje zbierku dokumentov. Môžete použiť reťazec pre meno alebo „“ pre „akýkoľvek“ (bez zástupných znakov).
• zhluk. Určuje zdieľaný klaster alebo iné prostriedky metadát. Je to boolovská hodnota true / false.
• anyResource. Určuje prístup k čomukoľvek a kdekoľvek. Je to boolovská hodnota true / false.

Akákoľvek rola môže dediť vlastnosti inej roly. Existuje pole s názvom „role“ a do poľa môžete umiestniť novú rolu. Dedí vlastnosti zadanej roly.

Použite createRole pridať rolu do poľa.

Používateľovi alebo role môžete pridať nové alebo existujúce databázy. Môžete napríklad pridať prístup na čítanie a zápis do databázy pripojením databázy k role.

Použi grantPrivilegesToRole príkaz na pridanie nových zdrojov k existujúcej role.

Nižšie je uvedený príklad vytvorenia novej roly superužívateľa. Účelom tejto role je opäť mať jedného používateľa, ktorý nie je nijako obmedzený v prostredí MongoDB (pre núdzové situácie).

db = db.geSiblingDB („správca“);

db.createRole ({

rola: „superRoot“,

oprávnenia: [{

zdroj: {anyResource: true},

akcie: [„anyAction“]

     }]     

roly: []

});

db.createUser ({

používateľ: “comanyDBA”,

pwd: „EWqeeFpUt9 * 8zq“,

role: [“superRoot”]

})

Tieto príkazy vytvárajú v databáze novú rolu geSiblingDB zavolal superkoren a priradiť tejto role akýkoľvek zdroj a akúkoľvek akciu. Potom vytvoríme nového používateľa v rovnakej databáze s názvom spoločnosťDBA (s heslom) a priraďte mu nové superkoren úlohu.

Používanie SSL na všetky veci

SSL pomáha zaistiť bezpečnosť vašich údajov v nezabezpečených sieťach. Ak využívate databázu, ktorá interaguje s internetom, mali by ste použiť SSL.

Existujú dva veľmi dobré dôvody, prečo používať SSL na zabezpečenie MongoDB: súkromie a autentifikácia. Bez protokolu SSL môžete k svojim údajom pristupovať, kopírovať ich a používať ich na nezákonné alebo škodlivé účely. S autentifikáciou máte sekundárnu úroveň bezpečnosti. Infraštruktúra súkromného kľúča (PKI) SSL zaručuje, že k MongoDB majú prístup iba používatelia so správnym certifikátom CA.

MongoDB má podporu SSL už dlho, ale v posledných niekoľkých verziách dramaticky vylepšila podporu SSL. Ak ste predtým chceli používať SSL, museli ste si ich stiahnuť a skompilovať ručne s komunitnou verziou MongoDB. Od verzie MongoDB 3.0 je protokol SSL štandardne kompilovaný so softvérom.

V starších verziách MongoDB tiež chýbala platná kontrola hostiteľa; validácia hostiteľa bola iba príznakom, ktorý ste mohli skontrolovať v konfiguračnom súbore a ktorý uspokojil požiadavku SSL z pripojenia.

Najnovšie verzie protokolu SSL v MongoDB obsahujú nasledujúce kľúčové vlastnosti:

• Kontroly platných hostiteľov (voliteľné)
• Možnosť ukázať na konkrétny súbor .key, ktorý sa má použiť
• Vlastná certifikačná autorita (CA) pre certifikáty s vlastným podpisom alebo alternatívne podpisujúce osoby
• allowSSL, preferSSL, requireSSL režimy, ktoré vám umožňujú zvoliť podrobnosti pre vaše použitie SSL (od menej zabezpečeného po bezpečnejšie)

SSL: Používanie vlastnej CA.

Novšie verzie SSL v MongoDB vám umožňujú používať vlastnú CA. Aj keď to dáva flexibilitu pri určovaní toho, ako chcete pracovať s SSL, prichádza s upozorneniami. Ak sa iba snažíte zabezpečiť pripojenie, môže vás lákať rozhodnúť sa sslAllowInvalidCertficates. Toto je však všeobecne zlý nápad z niekoľkých dôvodov:

• Umožňuje každému spojeniu, ktorého platnosť vypršala, a zrušeným certifikátom
• Nezabezpečujete obmedzenia konkrétneho názvu hostiteľa
• Nie ste zďaleka tak zabezpečení, ako si myslíte

Ak to chcete opraviť, jednoducho nastavte net.ssl.CAFilea MongoDB použije oboje kľúč a súbor CA (musíte to urobiť na klientovi).

Používanie SSL má však známu nevýhodu: výkon. Pri používaní SSL určite stratíte určitý výkon.

Šifrovanie disku

Údaje sú „na ceste“ alebo „v pokoji“. Môžete šifrovať jedno alebo obidve v MongoDB. Diskutovali sme o šifrovaní údajov pri prenose (SSL). Teraz sa pozrime na údaje v pokoji.

Údaje v pokoji sú údaje uložené na disku. Šifrovanie údajov v pokoji sa zvyčajne vzťahuje na údaje uložené na šifrovanom mieste úložiska. To nezabráni krádeži fyzickými prostriedkami a vytvára zálohy, ktoré sú uložené spôsobom, ktorý ľahko neprečíta žiadna tretia strana. Existujú pre to praktické obmedzenia. Tou najväčšou je dôvera v správcov systému - a za predpokladu, že hacker nezískal prístup správcu do systému.

Toto nie je problém jedinečný pre MongoDB. Aj tu fungujú preventívne opatrenia použité v iných systémoch. Môžu zahŕňať šifrovacie nástroje ako LUKS a cryptfs alebo ešte bezpečnejšie metódy, ako je podpisovanie šifrovacích kľúčov pomocou protokolu LDAP, čipových kariet a tokenov typu RSA.

Pri vykonávaní tejto úrovne šifrovania musíte brať do úvahy faktory, ako je automatické pripojenie a dešifrovanie jednotiek. To však pre vašich správcov systému nie je nič nové. Túto požiadavku môžu spravovať rovnakým spôsobom ako v ostatných častiach siete. Ďalšou výhodou je jediný postup šifrovania úložiska, nie jeden pre každú technológiu, ktorú konkrétna funkcia používa.

Šifrovanie údajov v pokoji je možné vyriešiť niektorou z týchto možností alebo všetkými týmito spôsobmi:

• Šifrujte celý zväzok
• Šifrujte iba súbory databázy
• Zašifrovať v aplikácii

Prvá položka sa dá vyriešiť šifrovaním disku v súborovom systéme. Nastavovanie je ľahké pomocou LUKS a dm-crypt. Pre splnenie požiadaviek PCI DSS a ďalšie požiadavky na certifikáciu sa vyžaduje iba prvá a druhá možnosť.

Auditovanie

V strede každého dobrého bezpečnostného návrhu je schopnosť sledovať, ktorý používateľ vykonal akú akciu v databáze (podobne ako by ste mali ovládať svoje skutočné servery). Auditovanie umožňuje filtrovať výstup konkrétneho používateľa, databázy, kolekcie alebo umiestnenia zdroja. Takto sa vygeneruje protokol na kontrolu prípadných bezpečnostných incidentov. Dôležitejšie je, že ukazuje každému audítorovi bezpečnosti, že ste podnikli správne kroky na ochranu svojej databázy pred narušením a aby pochopili hĺbku každého narušenia, ak by k nemu došlo.

Auditovanie vám umožňuje plne sledovať akcie narušiteľa vo vašom prostredí.

Poznámka: Audit je k dispozícii iba v MongoDB Enterprise. Nie je vo verzii pre komunitu. Je k dispozícii v niektorých ďalších otvorených verziách servera MongoDB, ako je napríklad Percona Server pre server MongoDB.