Zaštita MongoDB baze podataka

MongoDB je bez sumnje postao sastavni deo modernih aplikacija. Koristi se gotovo svuda: od e-commerce platformi, preko real-time analitike, IoT uređaja, gaming industrije, pa sve do društvenih mreža. Nažalost, kao i kod drugih sličnih aplikacija, ova popularnost mu je neizbežno donela i potencijalnu opasnost od zlonamernih napada.

U ovom tekstu objasnićemo neke od najvažnijih načina zaštite MongoDB baze. Od mrežnih podešavanja i autentikacije, preko šifrovanja podataka i audit logova, do backup-a, monitoring alata, pa sve do naprednih tehnika zaštite.

Cilj je da do kraja teksta dobijete jasan i praktičan pregled šta sve treba da uradite da bi vaša MongoDB baza bila bezbedna u produkciji.

Ukoliko ste već zadovoljni načinom na koji je vaša MongoDB baza zaštićena, predlažemo da se pozabavite i njenom optimizacijom. Za tu namenu prelažemo da pročitate naš tekst Optimizacija MongoDB baze podataka.

Zašto je važno da prvo zaštitite bazu podataka?

Baza podataka je glavni deo svake aplikacije. Ako napadač uspe da je kompromituje, to obično u praksi znači i potpuno kompromitovanje vaše aplikacije i svih njenih korisnika. To je posebno izraženo kod MongoDB-a, jer je do verzije 3.0 podrazumevano dolazio bez uključenih bezbednosnih mehanizama. Nije bilo autentikacije ni šifrovanja, a instanca je slušala na svim mrežnim interfejsima.

U praksi je to dovelo do velikog broja napada gde su napadači jednostavno pretraživali internet (npr. pomoću Shodan-a ili masovnih port-scan skripti), pronalazili otvorene MongoDB instance i brisali sve podatke. Nakon toga bi ostavljali poruku: “Pošaljite 0.2 BTC na ovu adresu ako želite svoje podatke nazad”.

Primer iz 2017. godine: više od 27.000 javno dostupnih MongoDB instanci je bilo kompromitovano u roku od nekoliko nedelja upravo zbog ovih propusta.

Dakle, bezbednost baze nije nikakav luksuz već pre svega neophodnost. Ona štiti poverljive podatke vaših korisnika, obezbeđuje integritet vaše aplikacije i sprečava finansijske i reputacione gubitke koji mogu da vas pogode ukoliko dođe do kompromitacije.

Promena podrazumevanog porta

Jedan od najjednostavnijih, ali i često zanemarenih koraka je promena podrazumevanog porta. MongoDB podrazumevano koristi port 27017, što ga čini lakom metom za automatizovane napade. Botovi koji skeniraju internet obično prvo testiraju upravo taj port, pokušavajući da dobiju pristup.

Kako promeniti port?

Sve se radi u konfiguracionom fajlu mongod.conf.

Primer (Linux, /etc/mongod.conf):

net:

  port: 37500

  bindIp: 127.0.0.1

Nakon izmene fajla, potrebno je restartovati MongoDB servis:

sudo systemctl restart mongod

ili, na starijim distribucijama:

sudo service mongod restart

Na ovaj način smo postigli da se baza ne nalazi na očekivanom portu, što eliminiše veliki deo automatizovanih napadača koji testiraju samo port 27017.

Napomena: Imajte u vidu da promena porta predstavlja samo security through obscurity. Ne rešava problem ako je instanca otvorena ka internetu. Napadač koji radi full port scan na IP adresi svakako može da otkrije bazu. Ipak, ovo je korisna dodatna zaštita jer sprečava veliki broj jednostavnih napada.

Napredna praksa – korišćenje firewall-a zajedno sa promenjenim portom

Ukoliko želite maksimalnu zaštitu, Idealno bi bilo da kombinujete promenu porta sa firewall pravilima:

Primer sa UFW (Ubuntu):

sudo ufw allow from 192.168.1.0/24 to any port 37500

sudo ufw deny 37500

sudo ufw deny 27017

Primer sa iptables:

iptables -A INPUT -p tcp --dport 37500 -s 192.168.1.0/24 -j ACCEPT

iptables -A INPUT -p tcp --dport 37500 -j DROP

iptables -A INPUT -p tcp --dport 27017 -j DROP

Na ovaj način, čak i ako neko otkrije port, samo IP adrese iz vašeg internog opsega će moći da se povežu.

Ograničavanje mrežnog pristupa

Jedna od najvećih grešaka koju administratori prave jeste da MongoDB instancu ostave otvorenu za ceo internet. Podrazumevana konfiguracija (posebno kod starijih verzija) bila je takva da mongodb proces sluša na svim interfejsima (0.0.0.0), što znači da bilo ko sa mreže može da pokuša da se poveže. Ako uz to nije uključena autentikacija, napadač odmah ima potpun pristup podacima.

Bind IP konfiguracija

Prvi korak je da jasno definišemo na kojim adresama MongoDB prihvata konekcije. To se radi u fajlu mongod.conf:

net:

  port: 37500

  bindIp: 127.0.0.1

Ovim podešavamo da MongoDB može da se koristiti samo lokalno (npr. aplikacija i baza su na istom serveru). Ako aplikacija koristi poseban serverski čvor, dodajemo i internu IP adresu:

net:

  port: 37500

  bindIp: 127.0.0.1,192.168.100.10

Nikada ne treba ostaviti 0.0.0.0, osim ako znate šta radite i imate dodatne slojeve zaštite (VPN, firewall, bastion host).

VPN i bastion host

Još jedna dobra praksa koju možete da primenite je da MongoDB nikada ne bude direktno dostupan spolja, već samo kroz VPN (OpenVPN, WireGuard) ili bastion host.

Ovaj pristup značajno smanjuje površinu napada.

Realni scenario napada

Napadač pokreće nmap scan:

nmap -p 27017 --open -Pn 203.0.113.15

Ako dobije odgovor i vidi otvoren MongoDB port, sledeći korak je:

mongo --host 203.0.113.15 --port 27017

Ako je autentikacija isključena, odmah može da vidi sve baze:

show dbs

i obriše ih komandom:

db.dropDatabase()

Zato je ograničavanje mrežnog pristupa prva linija odbrane i osnova svake dalje zaštite.

Autentikacija i RBAC

Ako mreža predstavlja prvu liniju odbrane, autentikacija i kontrola pristupa su druga. Bez njih, bilo ko ko dođe do MongoDB instance ima potpunu kontrolu nad podacima.

Uključivanje autentikacije

Autentikacija se uključuje u fajlu mongod.conf dodavanjem:

security:

authorization: enabled

Nakon toga restartujemo servis:

sudo systemctl restart mongod

Sada niko ne može da pristupi bazi bez validnog korisnika.

Kreiranje admin korisnika

Prvi korisnik mora da se napravi dok je autentikacija privremeno isključena.

Primer:

use admin

db.createUser({

  user: "admin",

  pwd: "VrloSlozenaLozinka123!",

  roles: [ { role: "root", db: "admin" } ]

})

Nakon toga se uključi autentikacija i pristup je moguć samo sa tim korisnikom.

Role-Based Access Control (RBAC)

RBAC znači da korisnici dobijaju samo onaj nivo pristupa koji im je potreban. U MongoDB-u postoje predefinisane role:

• read – samo čitanje nad bazom
  
• readWrite – čitanje i pisanje
  
• dbOwner – puna kontrola nad jednom bazom
  
• userAdmin – kreiranje i upravljanje korisnicima
  
• clusterAdmin – administracija celog klastera
  

Primer kreiranja korisnika za aplikaciju:

use moja_aplikacija

db.createUser({

  user: "appUser",

  pwd: "JakaLozinkaApp2025!",

  roles: [ { role: "readWrite", db: "moja_aplikacija" } ]

})

Sada aplikacija može da piše i čita samo iz te baze, ali ne može da pristupi admin bazi niti drugim bazama.

Granularne permisije

RBAC dozvoljava i kreiranje sopstvenih rola sa vrlo preciznim dozvolama.

Primer – korisnik može samo da čita dokumenta iz kolekcije orders:

db.createRole({

  role: "readOrders",

  privileges: [

    { resource: { db: "moja_aplikacija", collection: "orders" }, actions: [ "find" ] }

  ],

  roles: []

})

db.createUser({

  user: "analyst",

  pwd: "Analyst2025!",

  roles: [ "readOrders" ]

})

Ovim ograničavamo mogućnost eksfiltracije podataka. Sada čak i ako neko ukrade nalog, može da pročita samo određene kolekcije.

Integracija sa LDAP/Kerberos

U enterprise okruženjima korisnici ne bi trebalo da imaju posebne naloge za bazu, već da se koristi centralizovani identitet (LDAP, Active Directory, Kerberos).

Primer konfiguracije (mongod.conf):

security:

authorization: enabled

 ldap:

  servers: "ldap.example.com"

  bind:

      method: "simple"

      queryUser: "cn=admin,dc=example,dc=com"

      queryPassword: "StrongPassword"

    userToDNMapping: '[{ match: "(.+)@example.com", substitution: "uid={0},ou=users,dc=example,dc=com" }]'

Ovim omogućavamo da se zaposleni autentifikuju svojim korporativnim nalozima.

Dobre prakse

• Lozinke neka budu dugačke i složene (najbolje preko password manager-a).
  
• Ne koristiti zajedničke naloge (svaki korisnik svoj).
  
• Aplikacija nikada ne treba da koristi root ili dbOwner u produkciji.
  
• Rotirati lozinke i ključeve (npr. kvartalno).
  
• Koristiti x.509 sertifikate za autentikaciju između članova klastera (detaljno u sekciji o TLS-u).
  

TLS/SSL enkripcija

Čak i kada je mrežni pristup ograničen i autentikacija uključena, postoji još jedna ranjivost: prenos podataka u čistom tekstu. Ako aplikacija i baza komuniciraju preko interne mreže bez enkripcije, svako ko uspe da se ubaci u taj mrežni saobraćaj može da presretne podatke: korisnička imena, lozinke, brojeve kartica, odnosno sve što prolazi kroz tu bazu.

Rešenje je da obavezno koristite TLS/SSL enkripciju, koja osigurava da svi podaci putuju šifrovano.

Kako uključiti TLS u MongoDB-u?

Generišemo privatni ključ i sertifikat:

openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes \

  -out /etc/ssl/mongodb-cert.crt \

  -keyout /etc/ssl/mongodb-cert.key

Kombinujemo ih u .pem fajl koji koristi MongoDB:

cat /etc/ssl/mongodb-cert.key /etc/ssl/mongodb-cert.crt > /etc/ssl/mongodb.pem

U konfiguracionom fajlu mongod.conf dodajemo:

net:

  port: 37500

  tls:

    mode: requireTLS

    certificateKeyFile: /etc/ssl/mongodb.pem

    CAFile: /etc/ssl/ca.pem

Restartujemo servis:

sudo systemctl restart mongod

Sada svi klijenti moraju koristiti TLS da bi se povezali.

Klijentska konekcija sa TLS-om

Ako koristimo mongo shell:

mongo --host db.example.com --port 37500 \

  --ssl --sslCAFile /etc/ssl/ca.pem \

  --sslPEMKeyFile /etc/ssl/mongodb.pem

Ako koristimo Node.js driver:

const { MongoClient } = require("mongodb");

const uri = "mongodb://appUser:JakaLozinkaApp2025!@db.example.com:37500/?ssl=true";

const client = new MongoClient(uri, {

  sslCA: "/etc/ssl/ca.pem",

  sslKey: "/etc/ssl/mongodb.pem",

  sslCert: "/etc/ssl/mongodb.pem"

});

async function run() {

  await client.connect();

  console.log("Povezano preko TLS-a!");

  await client.close();

}

run();

Napredne opcije

• x.509 autentikacija – umesto korisničkog imena i lozinke, korisnici i članovi klastera se autentifikuju sertifikatima.
  
• Onemogućavanje slabih protokola – u mongod.conf treba eksplicitno isključiti zastarele verzije:

net:

  tls:

    disabledProtocols: TLS1_0,TLS1_1

• Perfect Forward Secrecy (PFS) – koristite moderne šifre kao AES-256-GCM koje sprečavaju retroaktivno dešifrovanje saobraćaja čak i ako ključ kasnije procuri.
  

Tipične greške

• Oslanjanje na samopotpisane sertifikate bez validnog CA – u redu za razvoj, ali u produkciji pravi sigurnosne rupe.
  
• Mešanje –ssl i –tls parametara u zavisnosti od verzije MongoDB-a. Od verzije 4.2 nadalje koristi se –tls.
  
• Korišćenje allowTLS umesto requireTLS – prvo znači da klijent može da bira da li će koristiti enkripciju, drugo da mora.
  

IP whitelisting u MongoDB Atlas-u

Ako koristimo managed rešenje (Atlas), postoji opcija whitelisting-a:

1. Ulogujemo se na Atlas.
   
2. Odemo na Network Access → IP Whitelist.
   
3. Dodamo samo IP adrese aplikacionih servera i developera.
   

Primer:

• 203.0.113.50 – produkcioni server
  
• 198.51.100.22 – bastion host
  

Sve ostale IP adrese dobiće 403 Forbidden pri pokušaju konekcije.

Napredne prakse

• Kombinovati firewall + VPN → baza dostupna samo unutar VPN mreže.
  
• Redovno proveravati firewall pravila (iptables -L, ufw status).
  
• Automatski audit firewall-a kroz CI/CD pipeline (npr. Terraform + Inspec testovi).

Realni scenario napada

Administrator ostavlja MongoDB otvoren (bindIp: 0.0.0.0) sa autentikacijom. Napadač radi brute force na 27017, uspe da pogodi lozinku admin/admin i dobija pristup celom sistemu.

Sa pravilno podešenim firewall-om i whitelisting-om, ovaj scenario je nemoguć jer napadač uopšte ne može da dođe do porta.

Redovno ažuriranje MongoDB-a

Čak i kada sve druge mere zaštite postavimo ispravno, zastarela verzija MongoDB-a može da bude najslabija karika. Svaki softver ima bezbednosne propuste, a MongoDB nije izuzetak. Developeri stalno otkrivaju ranjivosti, ali one ostaju otvorene za sve koji ne ažuriraju na vreme. Zato je važno da redovno ažurirate svoju bazu svim dostupnim zakrpama.

Zašto je važno ažurirati?

• Poznate ranjivosti – napadači prate CVE bazu (Common Vulnerabilities and Exposures) i ciljaju sisteme koji još nisu zakrpljeni.
  
• Bolje podrazumevane postavke – novije verzije MongoDB-a imaju bezbednije podrazumevane vrednosti (npr. od verzije 3.6 autentikacija više nije opciona).
  
• Performanse i stabilnost – mnoge zakrpe osim sigurnosti donose i bolje performanse replikacije, sharding-a i indeksiranja.
  
• Kompatibilnost sa alatima – najnovije verzije klijenata i biblioteka često ne podržavaju stare verzije servera.

Primer iz prakse: 2018. godine ranjivost u starijim verzijama MongoDB-a (pre 3.4) omogućavala je napadačima da iskoriste nešifrovanu replikaciju i izvuku podatke sa sekundarnih čvorova.

Kako proveriti verziju?

Jednostavno u mongo shell-u:

db.version()

ili u CLI:

mongod --version

Kako ažurirati na Linux-u (Ubuntu/Debian)?

Dodamo oficijalni MongoDB repozitorijum:

wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | sudo apt-key add -

echo "deb [ arch=amd64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

Ažuriramo:

sudo apt-get update

sudo apt-get install -y mongodb-org

Restartujemo servis:

sudo systemctl restart mongod

Na CentOS/RedHat:

sudo vi /etc/yum.repos.d/mongodb-org-7.0.repo

Dodamo:

[mongodb-org-7.0]

name=MongoDB Repository

baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/7.0/x86_64/

gpgcheck=1

enabled=1

gpgkey=https://www.mongodb.org/static/pgp/server-7.0.asc

Zatim:

sudo yum install -y mongodb-org

sudo systemctl restart mongod

Dobre prakse

• Uvek prvo ažurirati staging okruženje pre produkcije.
  
• Pročitati release notes – neke verzije menjaju default podešavanja (npr. writeConcern ili TLS protokole).
  
• Koristiti rolling upgrade u klasterima (sekundari se ažuriraju jedan po jedan, pa tek onda primarni).
  
• Automatski pratiti CVE feed i obaveštenja MongoDB tima.
  

Audit logovi

Kao što znate, nijedna zaštita nije potpuna bez mogućnosti praćenja i otkrivanja sumnjivih aktivnosti. Audit logovi u MongoDB-u omogućavaju administratorima da vide ko se povezao, šta je radio, da li je pokušao da pristupi neovlašćenim podacima i da li je menjao neke bitne konfiguracije.

Zašto audit logovi?

• Otkrivanje napada – ako napadač pokuša brute force na korisničke naloge, to se vidi u logu.
  
• Praćenje internih korisnika – insajderi sa širokim privilegijama mogu nenamerno ili namerno da zloupotrebe sistem.
  
• Forenzika – nakon incidenta logovi pomažu da se rekonstruiše šta se tačno dogodilo.
  
• Regulatorna usklađenost – standardi poput PCI DSS i GDPR zahtevaju evidenciju pristupa podacima.
  

Uključivanje audit logova

Audit log je deo MongoDB Enterprise izdanja, ali postoje i open-source rešenja koja hvataju standardne logove i prerađuju ih.

U mongod.conf dodajemo:

auditLog:

  destination: file

  format: JSON

  path: /var/log/mongodb/audit.json

  filter: '{ atype: { $in: ["authenticate", "createUser", "dropUser", "insert", "update", "remove"] } }'

Restartujemo servis:

sudo systemctl restart mongod

Primer zapisa iz audit loga

{

  "atype": "authenticate",

  "ts": { "$date": "2025-09-20T12:30:45.123Z" },

  "local": { "ip": "127.0.0.1", "port": 37500 },

  "remote": { "ip": "192.168.100.20", "port": 50234 },

  "param": { "user": "appUser", "db": "moja_aplikacija", "mechanism": "SCRAM-SHA-256" },

  "result": 0

}

Ovde vidimo da je korisnik appUser uspešno autentifikovan preko SCRAM-SHA-256 mehanizma.

Slanje logova u SIEM

Za ozbiljne sisteme logove ne čuvamo lokalno, već ih šaljemo u SIEM (Security Information and Event Management) alat poput Splunk-a, ELK stack-a ili Graylog-a.

Primer forwardinga sa Filebeat:

filebeat.inputs:

- type: log

  paths:

    - /var/log/mongodb/audit.json

output.elasticsearch:

  hosts: ["http://localhost:9200"]

Monitoring anomalija

Na osnovu audit logova možemo definisati alarme, npr:

• Više od 5 neuspelih pokušaja logovanja u 1 minuti.
  
• Kreiranje novog admin korisnika van radnog vremena.
  
• Masovno čitanje kolekcije sa PII podacima (npr. > 10.000 dokumenata).
  

Dobre prakse

• Logove čuvati na posebnom serveru, zaštićenom od pisanja od strane MongoDB procesa.
  
• Uvesti log rotation (npr. preko logrotate) da se disk ne bi napunio.
  
• Redovno pregledati logove – logovi koje niko ne gleda ne znače ništa.
  
• Koristiti hash ili digitalni potpis za očuvanje integriteta logova (bitno u slučaju sudskih sporova).

Backup i recovery strategije

Bezbednost MongoDB baze nije potpuna bez kvalitetne strategije za backup i oporavak. Napadi, ljudske greške, kvarovi hardvera ili softvera i prirodne nepogode, svi oni mogu u sekundi da unište vaše podatke. Backup i recovery nisu samo tehničko pitanje, već i poslovno: ako ne možemo brzo da vratimo bazu, možemo da izgubimo korisnike, ugovore i poverenje.

Zašto je backup kritičan?

• Ransomware napadi – napadač obriše bazu i ostavi poruku da pošaljete Bitcoin da biste dobili podatke. Ako imate backup, jednostavno ga vratite i ignorišete ucenu.
  
• Greške u kodu – loše napisan update query može obrisati pola dokumenata. Backup vraća stanje pre greške.
  
• Hardverski kvarovi – SSD diskovi mogu otkazati, RAID nije zamena za backup.
  
• Regulatorni zahtevi – GDPR i zahteva dokaze da organizacija može da povrati podatke.
  

Vrste backup-a u MongoDB-u

Logički backup (mongodump / mongorestore)
Omogućava izvoz dokumenata u BSON/JSON format i vraćanje istih.
Pogodan je za manje baze ili pojedinačne kolekcije.

mongodump --db moja_baza --out /backup/2025-09-20/

mongorestore --db moja_baza /backup/2025-09-20/moja_baza

Fizički backup (filesystem snapshot)
Radi snapshot na nivou fajl sistema ili storage sistema. Pogodan je za velike baze i brzi restore.
Na Linux-u se često koristi LVM snapshot ili cloud snapshot (EBS u AWS-u).

lvcreate --size 2G --snapshot --name mongo_snap /dev/vg0/mongo

Point-in-time recovery (oplog backup)
Kombinacija snapshot-a i oplog fajlova (operation log). Omogućava da bazu vratimo na tačno vreme pre incidenta.

mongodump --oplog --out /backup/full_with_oplog

Cloud backup (MongoDB Atlas ili Ops Manager)
Ako koristimo Atlas, backup je integrisan i dostupan kroz web interfejs. Ops Manager za on-premise nudi slično rešenje.

Dobre prakse

• Testirati restore – backup koji se nikad ne testira je kao da ga i nemamo.
  
• Automatizovati procese – cron job za mongodump ili skripta koja pokreće snapshot svakog dana u 2h ujutru.
  
• Čuvati kopije van lokacije – off-site ili u drugom data centru, u slučaju požara, poplave ili provale.
  

Šifrovati backup fajlove – da i oni ne postanu ranjivost ako procure. Na Linux-u, GPG je često korišćen:

gpg -c /backup/2025-09-20/mongodump.tar.gz

• Ograničiti pristup backup-ima – samo administratori bi trebalo da imaju dozvolu da preuzmu i vrate backup.
  

Scenario iz prakse

Startup iz Berlina izgubio je celu korisničku bazu jer je MongoDB instance bila hakovana i obrisana. Nisu imali ni jedan validan backup. Posledica: aplikacija je ugašena, a investitori se povukli. Da su imali makar dnevni mongodump, šteta bi bila minimalna.

Monitoring i praćenje performansi i bezbednosti

Backup nas spašava kada se incident već dogodi, ali monitoring je taj koji može da ga spreči. Bez aktivnog praćenja performansi i bezbednosnih događaja u MongoDB-u, teško je znati da li baza radi stabilno i da li neko pokušava da je kompromituje.

Zašto je monitoring važan?

• Prevencija napada – otkrivanje neuobičajenih pokušaja logovanja, skokova u latenciji, naglih promena u prometu.
  
• Performanse – spori upiti, rast memorijske potrošnje, preopterećen CPU.
  
• Stabilnost – replike koje kasne sa sinhronizacijom mogu da dovedu do gubitka podataka.
  
• Regulatorni zahtevi – logovanje i nadzor su deo standarda kao što su PCI DSS i ISO 27001.
  

Alati za monitoring

MongoDB built-in monitoring

• db.currentOp() – prikazuje trenutne operacije.
  
• db.serverStatus() – osnovne informacije o resursima.
  
• db.stats() – stanje kolekcija i baza.
  

Primer:

db.serverStatus().connections

 Rezultat:

{ "current" : 32, "available" : 818, "totalCreated" : 1000 }

Percona Monitoring and Management (PMM)
Open-source alat sa grafičkim interfejsom, prikazuje metrike u realnom vremenu i omogućava alerting.

ELK stack (Elasticsearch, Logstash, Kibana)
Koristi se za analizu audit logova i sistemskih logova.

Prometheus + Grafana
Prometheus scrape-uje metrike sa MongoDB eksportera, Grafana daje vizuelne dashboarde.

Primer konfiguracije Prometheus eksportera:

scrape_configs:

  - job_name: 'mongodb'

    static_configs:

      - targets: ['localhost:9216']

MongoDB Atlas Monitoring
Ako koristimo Atlas, monitoring je već ugrađen – CPU, RAM, IOPS, slow queries, svi grafički dostupni.

Šta pratiti?

Slow queries – aktivirati profilingLevel:

db.setProfilingLevel(1, { slowms: 100 })

•  Ovo loguje sve upite koji traju duže od 100ms.
  
• Replikaciju – kašnjenje između primary i secondary node-ova (rs.printSlaveReplicationInfo()).
  
• Disk I/O – nagli rast može da ukaže na pokušaj masovnog dump-ovanja podataka.
  
• Neuspeli login pokušaji – znak brute force napada.
  

Upozorenja i alarmi

• Ako replikacija kasni više od 30 sekundi → alarm.
  
• Ako broj konekcija premaši očekivane vrednosti → alarm.
  
• Ako se pojavi novi admin nalog u sistemu bez odobrenja → kritičan alarm.
  

Dobre prakse

• Postaviti baseline – znati kako baza izgleda kada radi normalno.
  
• Automatizovati alerting – ljudski faktor ne može pratiti svaki log u realnom vremenu.
  
• Kombinovati performanse i bezbednosni monitoring – jedan bez drugog ne daje celu sliku.

Šifrovanje podataka

Šifrovanje je jedna od primarnih linija odbrane u slučaju kompromitovanja sistema. Ako napadač uspe da dođe do fajlova sa diska ili da presretne saobraćaj između aplikacije i baze, šifrovani podaci mu neće biti od koristi bez ključeva. MongoDB nudi nekoliko nivoa šifrovanja: od transportnog (TLS/SSL), preko šifrovanja podataka u mirovanju (encryption at rest), pa do naprednih metoda poput Client-Side Field Level Encryption (CSFLE).

Šifrovanje podataka u mirovanju (Encryption at Rest)

Kada se podaci fizički čuvaju na disku, oni su u osnovi samo binarni fajlovi. Ako bi disk bio ukraden, ili ako neko neovlašćeno dođe do storage sloja, mogao bi da pročita podatke. Encryption at rest ovo sprečava.

MongoDB Enterprise nudi integrisano rešenje sa WiredTiger storage engine-om:

storage:

  dbPath: /var/lib/mongodb

  wiredTiger:

    engineConfig:

      encryption:

        enableEncryption: true

        encryptionKeyFile: /etc/mongodb-keyfile

Za generisanje ključa može se koristiti openssl:

openssl rand -base64 32 > /etc/mongodb-keyfile

chmod 600 /etc/mongodb-keyfile

chown mongodb:mongodb /etc/mongodb-keyfile

Dobre prakse

• Ključeve nikada ne čuvati u istom folderu gde su i podaci.
  
• Rotirati ključeve periodično (na primer na 6 meseci).
  
• Ako koristite cloud (AWS, Azure, GCP), bolje je integrisati KMS (Key Management Service) da se ključevi ne drže lokalno.

Za opensource verziju MongoDB-a, gde nema native enkripcije na disku, možete da koristite rešenja poput LUKS-a na Linux-u ili ZFS sa dataset-level enkripcijom.

Šifrovanje na nivou polja (Client-Side Field Level Encryption – CSFLE)

Ovo je napredna tehnika koja omogućava da određena polja u dokumentima budu šifrovana još pre nego što napuste aplikaciju i stignu do MongoDB-a. To znači da administrator baze može da vidi strukturu dokumenata, ali ne i vrednosti šifrovanih polja.

Primer:

const { MongoClient, ClientEncryption } = require("mongodb-client-encryption");

const uri = "mongodb://localhost:27017";

const client = new MongoClient(uri, { useUnifiedTopology: true });

async function run() {

  await client.connect();

  const db = client.db("moja_baza");

  const collection = db.collection("korisnici");

  await collection.insertOne({

    ime: "Petar",

    prezime: "Petrović",

    jmbg: new Binary(Buffer.from("1234567890123"), 6) // šifrovano polje

  });

}

run();

JMBG se ovde čuva šifrovan i aplikacija ga može dešifrovati samo ako poseduje ključ.

Upotreba

• PII podaci (ime, prezime, JMBG, broj pasoša).
  
• Finansijski podaci (brojevi kartica, transakcije).
  
• Zdravstveni podaci (medicinski izveštaji).
  

Upravljanje ključevima (Key Management)

Šifrovanje je beskorisno bez pravilnog upravljanja ključevima. MongoDB može da koristi različite izvore ključeva:

• KMIP server – standardizovani protokol za centralno upravljanje ključevima.
  
• Cloud KMS – AWS KMS, Azure Key Vault, Google Cloud KMS.
  
• HSM (Hardware Security Module) – fizički uređaji koji čuvaju kriptografske ključeve.
  

Dobre prakse

• Ne čuvati ključeve u kodu ili mongod.conf fajlu.
  
• Koristiti rotaciju ključeva – periodično menjati aktivne ključeve.
  
• Postaviti stroge privilegije – samo određeni servisi ili osobe mogu pristupiti KMS-u.
  

Dodatne tehnike

• Maskiranje podataka – za test okruženja koristiti maskirane podatke (npr. umesto pravih JMBG-a, generisati nasumične).
  
• Hashing umesto šifrovanja – za lozinke uvek koristiti hashing algoritme poput bcrypt ili Argon2, nikada plain-text enkripciju.
  
• Kombinacija enkripcije na više slojeva – transport + disk + polje. Ako jedan sloj padne, drugi ostaje zaštita.
  

Ugrađene uloge

MongoDB nudi veliki broj ugrađenih uloga. Najčešće korišćene su:

• read – može samo da čita podatke iz kolekcija.
  
• readWrite – može da čita i menja podatke.
  
• dbAdmin – administracija na nivou baze (indeksi, validacija).
  
• userAdmin – kreiranje i menjanje korisnika i njihovih uloga.
  
• clusterAdmin – kontrola nad replikama i shardovima.
  
• root – puni superuser pristup (koristi se isključivo za inicijalno podešavanje).
  

Primer dodele uloge:

use moja_baza

db.createUser({

  user: "appUser",

  pwd: "JakaSifra456!",

  roles: [ { role: "readWrite", db: "moja_baza" } ]

})

Ovaj korisnik može da radi sve sa podacima, ali nema administratorske privilegije nad celim klasterom.

Kreiranje prilagođenih uloga

Za veće sisteme često je potrebno kreirati custom role koja sadrži samo specifične dozvole.

Primer: korisnik treba da može samo da čita podatke iz jedne kolekcije (orders), ali ne i iz drugih kolekcija u bazi.

use moja_baza

db.createRole({

  role: "ordersReader",

  privileges: [

    {

      resource: { db: "moja_baza", collection: "orders" },

      actions: [ "find" ]

    }

  ],

  roles: []

})

Zatim dodeljujemo korisnika toj ulozi:

db.createUser({

  user: "orderAnalyst",

  pwd: "Analiza789!",

  roles: [ { role: "ordersReader", db: "moja_baza" } ]

})

Onemogućavanje nepotrebnih servisa i interfejsa

Neke stare verzije MongoDB-a dolazile su sa uključenim HTTP status interfejsom (na portu 28017). To je bilo korisno za debugging, ali je istovremeno i izlagalo informacije o instanci.

Uvek proverite da su svi nepotrebni interfejsi i API-ji isključeni:

net:

  http:

    enabled: false

Ako ne koristite REST interfejs ili SNMP, isključite ih. Pravilo je jasno: manje servisa = manje ulaznih tačaka za napad.

Restrikcije na fajl sistemu

Fajlovi koje MongoDB koristi moraju biti zaštićeni:

chown -R mongodb:mongodb /var/lib/mongodb

chmod 700 /var/lib/mongodb

• Data direktorijum – sme da ga čita/piše samo MongoDB servis.
  
• Konfiguracioni fajl (mongod.conf) – treba da bude čitljiv samo root-u i MongoDB korisniku.
  
• Keyfile za replikaciju/enkripciju – uvek chmod 600.
  

Ako napadač ima pristup fajl sistemu, može da manipuliše konfiguracijom ili ukrade podatke.

Onemogućavanje direct access-a sa root naloga

Česta greška je da se MongoDB pokreće kao root proces. To znači da bi svaka greška u kodu ili exploit u mongod procesu dao napadaču root privilegije. Zato MongoDB uvek treba da radi kao sistemski korisnik:

useradd -r -s /bin/false mongodb

a servisni fajl /etc/systemd/system/mongod.service mora imati:

[Service]

User=mongodb

Group=mongodb

Limitiranje resursa i uloga na nivou OS-a

Na Linux-u, systemd omogućava sandboxing MongoDB procesa. U /etc/systemd/system/mongod.service:

[Service]

NoNewPrivileges=true

PrivateTmp=true

ProtectSystem=full

ProtectHome=true

Ovo osigurava da MongoDB ne može da pristupi nepotrebnim delovima fajl sistema i ne može da eskalira privilegije.

Onemogućavanje server-side skriptovanja

MongoDB omogućava izvršavanje JavaScript koda na serveru (db.eval()), ali to može da dovede do potencijalnih bezbednosnih problema. Ako aplikacija ima injection propust, napadač bi mogao da izvrši zlonamerni JS kod direktno na serveru.

Od verzije 4.2 db.eval() je deprecated, ali u starijim verzijama ga treba obavezno onemogućiti.

Redovno primenjivanje sigurnosnih zakrpa OS-a

Redovno ažuriranje Linux distribucije (ili Windows Server-a ako se koristi) je jednako važno kao i update MongoDB-a.

Dobre prakse za hardening

• Isključiti direct access preko mreže, koristiti bastion host ili VPN.
  
• Obezbediti centralizovano logovanje (SIEM).
  
• Implementirati fail2ban za blokiranje IP adresa koje više puta pokušavaju brute-force logovanje.
  
• Koristiti AppArmor ili SELinux profile da se MongoDB proces drži u sandbox-u.

Dvofaktorska autentikacija (2FA) za administratore

RBAC i lozinke nisu dovoljni ako se admin nalozi kompromituju. Zato je preporuka uvesti 2FA ili integraciju sa identitetskim provajderom.

LDAP + Google Authenticator primer

MongoDB Enterprise može da koristi LDAP autentikaciju, a LDAP server se integriše sa 2FA rešenjem poput Google Authenticator-a ili Duo Security-ja.

LDAP + 2FA tok:

1. Admin se loguje na MongoDB pomoću LDAP kredencijala.
   
2. LDAP šalje izazov ka 2FA serveru.
   
3. Tek nakon uspešne verifikacije kodom, MongoDB dozvoljava pristup.
   

Ovim napadač ne može da uđe ni ako zna lozinku.

DevSecOps i automatsko skeniranje konfiguracija

U modernim timovima MongoDB se često podiže kroz CI/CD pipeline (Docker, Kubernetes, Terraform). Tu je ključno automatski proveravati bezbednosna pravila.

Primer GitHub Actions job-a:

name: MongoDB Security Scan

on: [push]

jobs:

  security-scan:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v2

      - name: Run MongoDB configuration scanner

        run: |

          docker run --rm -v $PWD/mongod.conf:/scan/mongod.conf security-scanner check /scan/mongod.conf

Postoje alati poput Mongoaudit i kubesec koji automatski proveravaju:

• da li je TLS uključen,
  
• da li se koristi 0.0.0.0 bind,
  
• da li postoje korisnici bez lozinki,
  
• da li audit log radi.

Dinamička detekcija pretnji pomoću SIEM sistema

Samo konfiguracija nije dovoljna, potrebno je i kontinuirano posmatranje. MongoDB se može integrisati sa SIEM alatima (Splunk, ELK Stack, Wazuh).

Primer alert pravila (Elastic SIEM):

• Ako korisnik sa ulogom read pokuša da izvrši insert → šalje se alert.
  
• Ako se kreira novi admin korisnik van radnog vremena → incident se eskalira.
  

Field-Level Encryption (FLE)

Standardno šifrovanje na nivou diska štiti podatke u mirovanju, ali administrator baze i dalje može da ih pročita. Zato MongoDB nudi client-side field level encryption.

Primer (Node.js driver):

const { MongoClient, ClientEncryption } = require("mongodb-client-encryption");

const client = new MongoClient(uri, {

  autoEncryption: {

    keyVaultNamespace: "encryption.__keyVault",

    kmsProviders: {

      local: { key: Buffer.from("MojLokalniKljuc123...") }

    }

  }

});

await client.db("moja_baza").collection("users").insertOne({

  ime: "Nenad",

  jmbg: "1234567890123"  // šifrovano na klijentu

});

Time ni DBA ni napadač koji kompromituje server ne može da pročita JMBG.

Zero Trust networking

Sve više organizacija prelazi na Zero Trust pristup: nema implicitnog poverenja ni za jedan servis u mreži. Svaki zahtev prema MongoDB-u mora da bude autentifikovan i autorizovan, bez obzira da li dolazi sa interne IP adrese.

Primer: korišćenje mTLS (mutual TLS) gde i klijent i server imaju sertifikate i obostrano se verifikuju.

Honeypot kolekcije kao mamci

Napredna defanzivna tehnika je kreiranje honeypot kolekcija koje niko u legitimnom sistemu ne bi smeo da koristi.

Primer:

db.createCollection("admin_backup")

Ako se ikada pojavi query prema ovoj kolekciji, znate da je neko probio RBAC ili pokušava lateralni pokret. SIEM može automatski da reaguje i blokira IP adresu.

Zaključak

Kao što ste videli MongoDB može biti i izuzetno moćan, ali i izuzetno ranjiv sistem. Sve zavisi od toga kako ga postavimo i održavamo.

Fleksibilnost i brzina koju nudi često navode developere da ga pokrenu sa podrazumevanim podešavanjima i tek kasnije razmišljaju o bezbednosti. Upravo tu nastaje najveći problem: otvoreni portovi, neautentifikovani pristupi i nedostatak šifrovanja najčešći su uzrok kompromitovanih instanci i gubitka podataka.

Drugim rečima: MongoDB može biti vaš saveznik ili vaša slaba tačka. Izbor zavisi od toga koliko ozbiljno pristupite bezbednosti već u prvoj liniji koda i prvom podešavanju vašeg mongod.conf fajla.