Sigurnost i sigurnosna kopija u MongoDB -u

Prilikom uspostavljanja naše usluge u proizvodnom okruženju ili možda u razvojnom okruženju s nekoliko korisnika, prvo što moramo učiniti je stvoriti sigurnosnu shemu, što nam omogućuje da spriječimo naše Baze podataka ljudima netočno pristupaju.
Glavna značajka MongoDB je da prilikom instaliranja instance radi bez stvaranja bilo koje vrste mjere provjere autentičnosti, ovako je kako bi se olakšao početak razvoja, ali dolazi do točke u kojoj moramo osigurati svoju infrastrukturu.
Druga važna točka koja se odnosi na pitanje sigurnosti i sigurnosne kopije naših podataka je kada moramo napraviti sigurnosnu kopiju određenog trenutka, ali ne želimo da dođe do kretanja podataka, jer na taj način jamčimo integritet naših podataka Zbirke baza podataka i dokumenata. U tom aspektu postoji i alat unutar MongoDB to nam omogućuje privremeno blokiranje kako bismo bili sigurni da je ono što kopiramo prikladno.
ZahtjeviUvjeti koji su nam potrebni ovom prilikom vrlo su jednostavni, jednostavno moramo imati primjerak MongoDB instaliran i pokrenut na našem sustavu, trebat će nam i pristup usluzi putem konzole. Ovaj vodič razvijen je godine Windows, pa se neke naredbe mogu promijeniti u drugim operativnim sustavima, ali sve to ima veze s onim što se radi izvan konzole MongoDB, i način na koji izražavamo rute.
Postavljanje parametara autentifikacije korisnika nije nešto što je od vitalnog značaja za rad MongoDB u proizvodnji, budući da možemo instalirati uslugu tako da oprema na kojoj radi ima filter veze, pa ako pokušamo pristupiti spomenutoj opremi izvan mreže, nećemo imati pristup.
Ovaj pojednostavljeni pristup sigurnosti vrlo je učinkovit, ali samo za projekte u kojima se usluga ne dijeli s drugim timovima, jer ako imamo različite razvojne timove koji rade protiv istog poslužitelja, potrebno nam je nešto drugo. Ovdje se nalazi ovjera, s njim brinemo o zahtjevu korisnika i lozinke po zbirci ako želimo, pa tako imamo mogućnost adekvatnog odvajanja različitih instanci za svako računalo.
Obje sigurnosne mjere nisu ekskluzivne i ako ih želimo koristiti istodobno, ono što radimo je stvaranje mnogo sigurnije usluge za naše okruženje, bilo da se radi o proizvodnji, pretprodukciji ili razvoju za više timova.
The ovjera u svom najosnovnijem obliku postiže se naredbom createUser To se mora izvršiti kad odaberemo Baza podataka admin gdje bi naši korisnici trebali biti.
Važno je napomenuti da od verzije 2.6 od MongoDB je da se metoda počela koristiti createUser, u prošlosti je sve bilo riješeno metodom addUserMeđutim, promjena je napravljena kako bi se omogućila veća svestranost prilikom unosa promjena.
Pogledajmo kako možemo postaviti administratorskog korisnika, a zatim i korisnika koji može čitati samo bazu podataka test.
Struktura dokumenta koji prima metodu createUser je sljedeći:

 {"Korisnik": "korisničko ime", "pwd": "lozinka", "uloge": [{"role": "", "db": ""},]}

Kao što smo primijetili, moramo uspostaviti ime i lozinku za korisnika kojeg stvaramo, ali osim toga moramo stvoriti i uloge, što je struktura dopuštenja koja će nam omogućiti definiranje ovlasti koje dajemo korisniku .
U sljedećem primjeru stvorit ćemo administratorskog korisnika koji ima pristup svim datotekama Baze podataka i to može kontrolirati uslugu, za to ćemo koristiti ulogama:

• clusterAdmin
• readAnyDatabase
• readWrite

S ova tri parametra već možemo imati prvog korisnika za upravljanje. Pogledajmo kako ovo izgleda na konzoli:

Time smo već uspješno stvorili našeg administratorskog korisnika, sada se moramo pravilno sjećati korisničkog imena i lozinke jer sljedeći korak koji ćemo učiniti je omogućiti sigurnost, za to moramo pokrenuti uslugu s parametrom -auth.
Prilikom ponovnog pokretanja usluge tada možemo postaviti našeg novostvorenog administratorskog korisnika, a za testiranje ćemo stvoriti korisnika koji može čitati samo Baza podataka. Pogledajmo kako ćemo ponovno pokrenuti uslugu u sljedećim koracima.
Jednostavno to moramo prvo zaustaviti, na primjer u Windows postavljamo se na konzolu u kojoj radi i pritisnemo tipke CTRL + C. Zatim ponovno normalno pokrećemo našu uslugu, ali na kraju prosljeđujemo parametar auth, kao što možemo vidjeti na sljedećoj konzoli:

Nakon što to učinimo, vratit ćemo se na upravljačku konzolu MongoDB, ali u ovom slučaju ako ćemo koristiti našeg novostvorenog korisnika:

 mongo.exe --korisničko ime = root -lozinka = 123456 admin

S tom prethodnom linijom možemo sigurno pristupiti našoj usluzi, to možemo vidjeti na sljedećoj slici:

Važno je zapamtiti da moramo koristiti sigurniju lozinku od "123456" u ovom primjeru, ona se koristi samo u demonstracijske svrhe, međutim za proizvodno okruženje nije prikladna.
Budući da smo provjerili kako pristupiti autentifikacijom, stvorit ćemo korisnika koji može čitati samo u Baza podataka test, za ovo ćemo ponoviti kreiranje korisnika, ali ćemo navesti ulogu:

 čitati

Stoga ćemo na ovaj način ograničiti korisnika na nemogućnost pisanja u zbirke. Pogledajmo odgovor na našoj konzoli:

Sada kada pokušavamo napisati dokument dobit ćemo pogrešku:

Vidjeli smo kako smo već adekvatno osigurali svoje korisnike, jasno je da je ovaj posao administriranja korisnika pomalo složen, ali nakon što to učinimo možemo imati veliku sigurnost da nećemo imati neovlašteni pristup Baze podataka koje štitimo.
Jedna od najsloženijih aktivnosti koju treba osigurati prilikom izrade sigurnosne kopije jest da moramo jamčiti integritet podataka, što nas dovodi do dileme, locirati vrijeme kada radi manje korisnika i napraviti sigurnosnu kopiju, ili to učiniti bez obzira na podatke .
fsync i zaključavanjeTo ne bi trebao biti slučaj, naravno da se uvijek preporučuje izrada sigurnosne kopije u vrijeme kada znamo da je najmanji broj korisnika jer izbjegavamo probleme s aplikacijom, jamčeći da su podaci uvijek mogući ako koristimo ono što je u MongoDB znamo kako fsync Y zaključavanje.
S ova dva parametra možemo natjerati našu bazu podataka da odbije zapise, au tom pravom trenutku možemo na odgovarajući način izvesti sigurnosne kopije.
Da bismo stvorili ovu bravu, moramo pokrenuti sljedeću naredbu u našoj bazi podataka:

 db.runCommand ({"fsync": "1", "lock": "1"});

S ovim ćemo imati svoje Baza podataka učinkovito spriječeno od pisanja:

Kao što vidimo, prilično je jednostavno i učinkovito, pa ako želimo probiti bravu, moramo samo ponovno pokrenuti naredbu:

 db.fsyncUnlock ();

S potonjima ćemo opet imati svoje Baza podataka sposoban za pisanje:

Iako gore navedeno predstavlja veću fleksibilnost i daje nam mnogo veću sigurnost protiv oštećenja podataka i pogoduje integritetu, to doista nije praksa koju bismo trebali slijediti u stvarnim proizvodnim okruženjima.
Idealno je stvoriti okruženje s replikacijom, gdje možemo pristupiti kopiji podataka i na taj način moći manipulirati bilo kojom od opcija za koje imamo potrebne sigurnosne kopije. Biti u replici Baza podataka produkciju možemo blokirati ili isključiti i napraviti sigurnosnu kopiju na takav način da korisnik nikada neće naići na pogrešku u aplikaciji jer ne može napisati zapis.
Što se tiče sigurnosnih kopija, stvari se kompliciraju jer je poželjno koristiti poslužiteljske replike, međutim zbog načina na koji su zamišljene MongoDB, ova vrsta građevina gospodar - rob Vrlo su jednostavni za implementaciju, pa je razumijevanje koncepta najteže, ali je njegova primjena izuzetno jednostavna za korištenje. DBA.
Ovim završavamo ovaj vodič, kao što vidimo administraciju MongoDB Prilično je napredno, ako imamo strukturu srednje veličine, možda smo već razmišljali o pitanju sigurnosti korisnika, iako stvaranje korisnika nije složeno, ako je dobro sjesti i definirati dobru strukturu za stvaranje ove vrste dozvole.Je li vam se svidio i pomogao ovaj vodič?Autor možete nagraditi pritiskom na ovaj gumb kako biste mu dali pozitivan bod