Ohjelmointi

Olennainen opas MongoDB-tietoturvaan

David Murphy toimii MongoDB: n käytännön johtajana Perconassa, joka tarjoaa yritystason MySQL- ja MongoDB-ratkaisuja ja -palveluja.

MongoDB-turvallisuus on jälleen uutisissa. Äskettäinen tarinankerros paljastaa, kuinka hakkerit ovat takavarikoineet MongoDB-tietokantoja ja lunastaneet datan bitcoineille. Kymmenet tuhannet MongoDB-asennukset ovat vaarantuneet Rapid7: n mukaan.

Olemme kaikki huolissamme turvallisuudesta. Jos suoritat sovelluksia, verkkoja tai tietokantoja, tietoturva on aina ylin asia. Kun useammat yritykset siirtyvät avoimen lähdekoodin ohjelmistoihin, kuten MongoDB, tärkeiden yritystietojen tallentamiseen, tietoturvasta tulee entistäkin suurempi kysymys. Yrityksestäsi riippuen sinulla voi olla myös useita valtionhallinnon (kuten sairausvakuutuksen siirrettävyys- ja vastuuvelvollisuuslaki tai HIPAA) tai yritys- (Payment Card Industry Data Security Standard tai PCI DSS) -verkkoturvallisuuden sääntelystandardeja, joita sinun on noudatettava.

Onko MongoDB-tietokantaohjelmisto turvallinen? Täyttääkö se nämä standardit? Lyhyt vastaus: Kyllä se on, ja kyllä ​​se on! Kyse on yksinkertaisesti tietämyksestä, kuinka asennat, määrität ja työskentelet tietyn asennuksen kanssa.

Tässä artikkelissa käsittelen MongoDB: n tietoturvaa. MongoDB on turvallinen käyttää - jos tiedät mitä etsiä ja miten se määritetään.

Ensinnäkin, miten ihmiset menevät pieleen MongoDB-tietoturvassa? On olemassa useita avainalueita, jotka nostavat käyttäjiä MongoDB-tietoturvan suhteen:

  • Oletusporttien käyttäminen
  • Todennusta ei oteta käyttöön heti (suurin ongelma!)
  • Kun käytetään todennusta, annetaan kaikille laaja käyttöoikeus
  • Ei käytä LDAP: tä pakottaaksesi salasanan kierrot
  • Ei pakota SSL-käyttöä tietokantaan
  • Ei rajoita tietokannan käyttöä tunnetuille verkkolaitteille (sovelluksen isännät, kuormituksen tasapainottimet jne.)
  • Ei rajoita kuunneltavaa verkkoa (tämä ei kuitenkaan vaikuta mihinkään tuettuihin versioihin)

MongoDB: llä on viisi keskeistä turvallisuusaluetta:

  • Todennus. LDAP-todennus keskittää yrityksesi hakemiston kohteet.
  • Valtuutus. Valtuutus määrittää, mitä roolipohjaisia ​​käyttöoikeuksia tietokanta tarjoaa.
  • Salaus. Salaus voidaan jakaa lepotilaan ja kuljetukseen. Salaus on kriittinen MongoDB: n suojaamiseksi.
  • Tarkastus. Tarkastuksella tarkoitetaan kykyä nähdä kuka mitä teki tietokannassa.
  • Hallinto. Hallinnointi tarkoittaa asiakirjojen vahvistamista ja arkaluontoisten tietojen (kuten tilinumeron, salasanan, sosiaaliturvatunnuksen tai syntymäpäivän) tarkistamista. Tämä viittaa sekä arkaluontoisten tietojen tallentamisen tietoon että arkaluonteisten tietojen tuomiseen järjestelmään.

LDAP-todennus

MongoDB: llä on sisäänrakennetut käyttäjäroolit ja poistaa ne oletusarvoisesti käytöstä. Se kaipaa kuitenkin sellaisia ​​asioita kuin salasanan monimutkaisuus, ikäpohjainen kierto sekä keskittäminen ja käyttäjien roolien tunnistaminen palvelutoiminnoista. Nämä ovat välttämättömiä PCI DSS -vaatimusten kaltaisten sääntöjen hyväksymiselle. Esimerkiksi PCI DSS kieltää vanhojen salasanojen ja helposti hajoavien salasanojen käytön ja vaatii muutoksia käyttöoikeuksiin aina, kun tila muuttuu (esimerkiksi kun käyttäjä poistuu osastolta tai yrityksestä).

Onneksi LDAP: tä voidaan käyttää täyttämään monet näistä aukoista. Monet liittimet sallivat Windows Active Directory (AD) -järjestelmien käytön puhuakseen LDAP: n kanssa.

Huomautus: LDAP-tuki on käytettävissä vain MongoDB Enterprise -yrityksessä. Se ei ole yhteisöversiossa. Se on saatavana muissa avoimen lähdekoodin MongoDB-versioissa, kuten Percona Server for MongoDB.

MongoDB 3.2 tallentaa käyttäjät LDAP: hen, mutta ei rooleja (nämä tallennetaan tällä hetkellä yksittäisille koneille). MongoDB 3.4 Enterprise -ohjelman tulisi ottaa käyttöön kyky tallentaa roolit LDAP: hen keskitettyä pääsyä varten. (Keskustelemme rooleista myöhemmin.)

Percona

LDAP: n ja AD: n avulla voit sitoa käyttäjät yrityshakemistoon. Kun he vaihtavat rooleja tai poistuvat yrityksestä, henkilöt voivat poistaa ne tietokantaryhmästäsi. Sinulla on siis automaattinen järjestelmä, jolla varmistetaan, että vain ne, jotka haluat käyttää tietoja manuaalisesti, voivat tehdä niin, vahingossa puuttumatta.

LDAP Mongossa on todella helppoa. MongoDB: llä on erityinen komento käskemään sitä tarkistamaan ulkoinen LDAP-tietokanta: $ ulkoinen.

Joitakin muita varoituksia LDAP: n käytöstä:

  • Luo käyttäjä .luo käyttäjä kuten normaalisti, mutta muista käyttää db / collection-resurssitunnisteita.
  • Lisäksi LDAP-todennus vaatii vielä kaksi kenttää:
    • mekanismi: “PLAIN”
    • digestPassword: väärä

Mukautetut roolit

Roolipohjainen kulunvalvonta (RBAC) on MongoDB: n ydin. Sisäänrakennetut roolit ovat olleet käytettävissä MongoDB: ssä version 2.6 jälkeen. Voit jopa luoda omia, aina tiettyihin toimiin, jotka tietty käyttäjä voi tehdä. Tämän avulla voit määrittää, mitä tietty käyttäjä voi tehdä tai nähdä partakoneen tarkkuudella. Tämä on MongoDB: n ydinominaisuus, että se on saatavilla lähes jokaisen toimittajan avoimen lähdekoodin ohjelmistoversiossa.

Viisi sisäänrakennettua MongoDB-roolia, joista sinun tulisi olla tietoinen:

  • lukea:
    • Vain luku -oikeus, yleensä useimmille käyttäjille
  • lukea kirjoittaa:
    • lukea kirjoittaa pääsy sallii tietojen muokkaamisen
    • lukea kirjoittaa sisältää luetun
  • dbOmistaja:
    • Sisältää lukea kirjoittaa, dbAdmin, userAdmin (tietokannalle). userAdmin tarkoittaa käyttäjien lisäämistä tai poistamista, käyttöoikeuksien myöntämistä käyttäjille ja roolien luomista. Nämä oikeudet määritetään vain tietylle tietokantapalvelimelle.
  • dbAdminAnyDatabase:
    • Luo dbAdmin kaikissa tietokannoissa, mutta ei salli käyttäjien hallintaa (esimerkiksi käyttäjien luomista tai poistamista). Voit luoda hakemistoja, puhelun tiivistyksiä ja muuta. Tämä ei tarjoa sirpaleita.
  • juuri:
    • Tämä on superkäyttäjä, mutta rajoituksin
    • Se voi tehdä useimpia asioita, mutta ei kaikkia:
      • Järjestelmän kokoelmaa ei voi muuttaa
      • Jotkut komennot eivät vieläkään ole käytettävissä tälle roolille versiosta riippuen. Esimerkiksi MongoDB 3.2 -juurirooli ei salli sinun muuttaa oplogin tai profiloijan kokoa, eikä MongoDB 3.4 -juurirooli anna sinun lukea nykyisiä näkymiä.

Jokerimerkit tietokannat ja kokoelmat

Jokerimerkki tarkoittaa käyttöoikeuksien myöntämistä suurille tietokantaryhmille tai kokoelmille (tai kaikille) palvelimella. Nolla-arvolla voit määrittää kaikki tietokannat tai kokoelmat ja välttää dbAdminAnyDatabase rooli. Tämä antaa tietyille käyttäjille kaikki oikeudet, mukaan lukien hallintatoiminnot.

Tämä on vaarallista.

Kun käytät jokerimerkkejä, annat paljon erityisoikeuksia, ja sinun on tiedettävä, että avaat mahdollisia hyökkäysmahdollisuuksia:

  • readWriteAnyDatabase On erittäin ja altistaa käyttäjänimet ja roolit potentiaaliselle hyökkäykselle sovelluksen käyttäjän kautta
  • Jokerimerkkien käyttö tarkoittaa, että et rajoita tiettyjä sovelluksia tiettyihin tietokantoihin
  • Jokerimerkit estävät sinua käyttämästä multitenanciaa useiden tietokantojen kanssa
  • Uusille tietokannoille ei myönnetä automaattisesti käyttöoikeuksia

Mukautetun roolin luominen

MongoDB-roolien voima syntyy mukautettujen roolien luomisesta. Mukautetussa roolissa voit määrittää, että mikä tahansa resurssitoiminto voidaan määrittää tietylle käyttäjälle. Tämän tarkkuustason avulla voit hallita syvästi kuka voi tehdä mitä MongoDB-ympäristössäsi.

Mukautetun roolin määrittämisessä on neljä erityyppistä resurssia:

  • db. Määrittää tietokannan. Voit käyttää merkkijonoa nimessä tai "" mitä tahansa "(ei jokerimerkkiä).
  • kokoelma. Määrittää kokoelman asiakirjoja. Voit käyttää merkkijonoa nimessä tai "" mitä tahansa "(ei jokerimerkkejä).
  • klusteri. Määrittää sirpaleisen klusterin tai muut metatietoresurssit. Se on totuus / epätosi -arvo.
  • anyResource. Määrittää pääsyn mihin tahansa, mihin tahansa. Se on totuus / epätosi -arvo.

Mikä tahansa rooli voi periä toisen roolin ominaisuudet. On taulukko nimeltä "roolit", ja voit pudottaa uuden roolin ryhmään. Se perii määritetyn roolin ominaisuudet.

Käyttää createRole lisätä rooli taulukkoon.

Voit lisätä käyttäjälle tai roolille uusia tai olemassa olevia tietokantoja. Voit esimerkiksi lisätä tietokantaan luku- ja kirjoitusoikeuden liittämällä tietokannan rooliin.

Käytä grantPrivilegesToRole komento lisätä uusia resursseja olemassa olevaan rooliin.

Alla on esimerkki uuden Super-käyttäjäroolin luomisesta. Tämän roolin tarkoituksena on jälleen yksi käyttäjä, jota ei millään tavalla rajoiteta MongoDB-ympäristössä (hätätilanteita varten).

db = db.geSiblingDB (“admin”);

db.createRole ({

rooli: "superRoot",

etuoikeudet: [{

resurssi: {anyResource: true},

toimet: [’anyAction’]

     }]     

roolit: []

});

db.createUser ({

käyttäjä: “comanyDBA”,

pwd: “EWqeeFpUt9 * 8zq”,

roolit: [“superRoot”]

})

Nämä komennot luovat uuden roolin tietokantaan geSiblingDB olla nimeltään superRoot ja määritä tälle roolille kaikki resurssit ja toimet. Sitten luomme uuden käyttäjän samaan tietokantaan nimeltä yritysDBA (salasanalla) ja määritä sille uusi superRoot rooli.

SSL: n käyttäminen kaikkeen

SSL auttaa varmistamaan tietojesi turvallisuuden suojaamattomissa verkoissa. Jos käytät tietokantaa, joka on vuorovaikutuksessa Internetin kanssa, sinun on käytettävä SSL: ää.

SSL: n käyttämiseen MongoDB: n suojaamiseen on kaksi erittäin hyvää syytä: yksityisyys ja todennus. Ilman SSL: ää tietojasi voidaan käyttää, kopioida ja käyttää laittomiin tai haitallisiin tarkoituksiin. Todennuksen avulla sinulla on toissijainen turvallisuustaso. SSL: n yksityisen avaimen infrastruktuuri (PKI) takaa, että vain käyttäjät, joilla on oikea CA-varmenne, voivat käyttää MongoDB: tä.

MongoDB: llä on ollut SSL-tuki pitkään, mutta se on parantanut dramaattisesti SSL-tukea viimeisimmissä versioissa. Aikaisemmin, jos halusit käyttää SSL: ää, sinun oli ladattava se ja käännettävä se manuaalisesti MongoDB Community -versiolla. MongoDB 3.0: sta lähtien SSL käännetään oletusarvoisesti ohjelmiston kanssa.

MongoDB: n vanhoista versioista puuttui myös kelvollinen isäntätarkistus; isännän vahvistus oli vain lippu, jonka voit tarkistaa kokoonpanotiedostosta, joka täyttää yhteyden SSL-pyynnön.

MongoDB: n uusimmat SSL-versiot sisältävät seuraavat tärkeimmät ominaisuudet:

  • Tarkista kelvolliset isännät (valinnainen)
  • Kyky osoittaa tiettyyn käytettävään .key-tiedostoon
  • Mukautettu varmentaja (CA) itse allekirjoittaneille varmenteille tai vaihtoehtoisille allekirjoittajille
  • allowSSL, mieluumminSSL, vaadiSSL tilat, joiden avulla voit valita SSL-käytön tarkkuuden (vähemmän turvallisesta turvallisempaan)

SSL: Mukautetun varmentajan käyttö

SSL: n uudemmat versiot MongoDB: ssä mahdollistavat mukautetun varmentajan käytön. Vaikka tämä antaa sinulle joustavuutta määrittää, miten haluat työskennellä SSL: n kanssa, siihen sisältyy varoituksia. Jos yrität vain suojata yhteyttä, saatat olla kiusaus valita sslAllowInvalidCertficates. Tämä on kuitenkin yleensä huono idea joistakin syistä:

  • Sallii yhteyden vanhentuneista peruutettuihin varmenteisiin
  • Et takaa rajoituksia tietylle isäntänimelle
  • Et ole läheskään yhtä turvallinen kuin luulet olevasi

Korjaa tämä yksinkertaisesti asettamalla net.ssl.CAFile, ja MongoDB käyttää molemmat avain ja CA-tiedosto (sinun on tehtävä tämä asiakkaalla).

SSL: n käytöllä on kuitenkin tunnettu haittapuoli: suorituskyky. Menetät varmasti jonkin verran suorituskykyä käyttäessäsi SSL: ää.

Levyn salaus

Tiedot ovat joko "kuljetuksessa" tai "levossa". Voit salata jommankumman tai molemmat MongoDB: ssä. Olemme keskustelleet tiedonsiirrosta (SSL). Katsotaan nyt tietoja levossa.

Lepotiedot ovat levylle tallennettuja tietoja. Data-at-rest-salaus viittaa tyypillisesti salattuun tallennuspaikkaan tallennettuihin tietoihin. Tällä pyritään estämään varkaudet fyysisillä keinoilla ja luomaan varmuuskopiot, jotka on tallennettu tavalla, jota kolmannet osapuolet eivät voi helposti lukea. Tällä on käytännön rajoituksia. Suurin on luottaa järjestelmänvalvojiin - ja olettaen, että hakkeri ei ole saanut järjestelmänvalvojan käyttöoikeuksia.

Tämä ei ole MongoDB: n ainutlaatuinen asia. Myös muissa järjestelmissä käytettävät ennalta ehkäisevät toimenpiteet toimivat täällä. Ne voivat sisältää salaustyökaluja, kuten LUKS ja cryptfs, tai jopa turvallisempia menetelmiä, kuten salausavainten allekirjoittaminen LDAP: llä, älykortit ja RSA-tyyppiset tunnukset.

Suoritettaessa tätä salaustasoa sinun on otettava huomioon tekijät, kuten asemien automaattinen yhdistäminen ja salauksen purku. Mutta tämä ei ole uusi järjestelmänvalvojillesi. He voivat hallita tätä vaatimusta samalla tavalla kuin he hallitsevat sitä verkon muissa osissa. Lisäetuna on yksi tallennussalausmenettely, ei yksi kutakin tekniikkaa kohti, jota tietty toiminto käyttää.

Data-at-rest-salaus voidaan ratkaista jollakin seuraavista:

  • Salaa koko äänenvoimakkuus
  • Salaa vain tietokantatiedostot
  • Salaa sovelluksessa

Ensimmäinen kohta voidaan ratkaista tiedostojärjestelmän levysalauksella. Se on helppo asentaa LUKS: n ja dm-crypt: n avulla. Vain ensimmäinen ja toinen vaihtoehto vaaditaan PCI DSS -yhteensopivuuden ja muiden sertifiointivaatimusten täyttämiseksi.

Tarkastus

Keskeistä hyvän tietoturvasuunnittelun kannalta on pystyä seuraamaan, mikä käyttäjä teki minkä tahansa toiminnan tietokannassa (samanlainen kuin sinun pitäisi hallita todellisia palvelimia). Auditoinnin avulla voit suodattaa tietyn käyttäjän, tietokannan, kokoelman tai lähdekohdan lähdön. Tämä luo lokin mahdollisten tietoturvaloukkausten tarkistamiseksi. Vielä tärkeämpää on, että jokainen tietoturvatarkastaja osoittaa, että olet toteuttanut oikeat vaiheet tietokannan suojaamiseksi tunkeutumiselta ja ymmärtämään tunkeutumisen syvyyden.

Auditoinnin avulla voit seurata täysin tunkeilijan toimia ympäristössäsi.

Huomautus: Tarkastus on käytettävissä vain MongoDB Enterprise -yrityksessä. Se ei ole yhteisöversiossa. Se on saatavana joissakin muissa avoimen lähdekoodin MongoDB-versioissa, kuten Percona Server for MongoDB.

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