Sikkerhet og sikkerhetskopiering i MongoDB

Når vi etablerer tjenesten vår i et produksjonsmiljø eller kanskje i et utviklingsmiljø med flere brukere, er det første vi må gjøre å lage en sikkerhetsordning, dette gjør at vi kan forhindre Databaser får tilgang til folk på feil måte.
Hovedtrekk ved MongoDB er at når du installerer en forekomst, kjører den uten å ha opprettet noen form for godkjenningstiltak, det er slik for å lette utviklingen, men det kommer et punkt hvor vi må sikre infrastrukturen vår.
Et annet viktig poeng som er relatert til spørsmålet om sikkerhet og sikkerhetskopiering av dataene våre, er når vi trenger å ta en sikkerhetskopi av et bestemt øyeblikk, men vi vil ikke at det skal være databevegelser, siden vi på denne måten garanterer integriteten til våre Database og dokumentsamlinger. I dette aspektet er det også et verktøy inne MongoDB som lar oss midlertidig blokkere den for å sikre at det vi kopierer er passende.
KravKravene vi trenger ved denne anledningen er veldig enkle, vi må bare ha et eksempel på det MongoDB installert og kjørt på systemet vårt, trenger vi også tilgang til tjenesten gjennom konsollen. Denne opplæringen ble utviklet i Windows, så noen kommandoer kan endres i andre operativsystemer, men alt har å gjøre med det som gjøres utenfor konsollen MongoDB, og måten vi uttrykker rutene på.
Å sette brukergodkjenningsparametere er ikke noe som er avgjørende for driften av MongoDB i produksjon, siden vi kan installere tjenesten slik at utstyret der den kjører har et tilkoblingsfilter, så hvis vi prøver å få tilgang til utstyret utenfor nettverket, har vi ikke tilgang.
Denne forenklede tilnærmingen til sikkerhet er veldig effektiv, men bare for prosjekter der tjenesten ikke deles med andre team, siden hvis vi har forskjellige utviklingsteam som jobber mot den samme serveren, trenger vi noe annet. Det er her godkjenning, med det tar vi oss av å be om en bruker og passord per samling hvis vi ønsker det, og dermed har vi muligheten til å skille de forskjellige forekomstene tilstrekkelig for hver datamaskin.
Begge sikkerhetstiltakene er ikke eksklusive, og hvis vi ønsker å bruke dem samtidig, er det vi gjør å skape en mye sikrere tjeneste for miljøet vårt, det være seg produksjon, forproduksjon eller utvikling av flere team.
De godkjenning i sin mest grunnleggende form oppnås det med kommandoen Opprett bruker Dette må utføres når vi har valgt Database admin det er der brukerne våre skal være.
Det er viktig å merke seg at siden versjonen 2.6 av MongoDB er at metoden begynte å bli brukt Opprett bruker, tidligere ble alt løst med metoden addUserEndringen ble imidlertid gjort for å gi større allsidighet ved endringer.
La oss se hvordan vi kan sette en administratorbruker og deretter en bruker som bare kan lese databasen test.
Strukturen til dokumentet som mottar metoden Opprett bruker er det neste:

 {"Bruker": "brukernavn", "pwd": "passord", "roller": [{"role": "", "db": ""},]}

Som vi noterte, må vi etablere navn og passord for brukeren vi oppretter, men i tillegg til dette må vi også lage rollene, som er en tillatelsesstruktur som lar oss definere kreftene vi gir brukeren .
I det følgende eksemplet skal vi opprette en administratorbruker som har tilgang til alle Databaser og som kan kontrollere tjenesten, for dette vil vi bruke roller:

• clusterAdmin
• readAnyDatabase
• Les Skriv

Med disse tre parameterne kan vi allerede få vår første bruker til å administrere. La oss se hvordan dette ser ut på konsollen:

Med dette har vi allerede opprettet administratorbrukeren vår vellykket, nå må vi huske brukernavnet og passordet riktig fordi det neste trinnet vi vil gjøre er å aktivere sikkerhet, for dette må vi starte tjenesten med parameteren -aut.
Når vi starter tjenesten på nytt kan vi plassere vår nyopprettede administratorbruker, og for å teste den vil vi opprette en bruker som bare kan lese Database. La oss se hvordan vi starter tjenesten på nytt i de følgende trinnene.
Vi må ganske enkelt stoppe det først, for eksempel i Windows Vi plasserer oss på konsollen der den kjører og trykker på tastene CTRL + C. Deretter starter vi tjenesten igjen normalt, men til slutt passerer vi parameteren aut, som vi kan se i følgende konsoll:

Når dette er gjort, vil vi gå tilbake til kontrollkonsollen til MongoDB, men i dette tilfellet hvis vi skal bruke vår nyopprettede bruker:

 mongo.exe -brukernavn = root -passord = 123456 admin

Med den forrige linjen kan vi få tilgang til tjenesten vår trygt, vi kan se dette på følgende bilde:

Det er viktig å huske at vi må bruke et sikrere passord enn "123456" i dette eksemplet, det brukes bare for demonstrasjonsformål, men for et produksjonsmiljø er det ikke egnet.
Siden vi har bekreftet hvordan vi får tilgang til med autentisering, skal vi opprette en bruker som bare kan lese i Database test, for dette skal vi gjenta opprettelsen av en bruker, men vi skal spesifisere rollen:

 lese

På denne måten vil vi på denne måten begrense brukeren til ikke å kunne skrive i samlingene. La oss se svaret i konsollen vår:

Når vi prøver å skrive et dokument, får vi en feilmelding:

Vi har da sett hvordan vi allerede har sikret brukerne våre tilstrekkelig, det er klart at dette brukeradministrasjonsarbeidet er litt komplekst, men når vi har gjort det, kan vi ha stor sikkerhet for at vi ikke vil ha uautorisert tilgang til Databaser som vi beskytter.
En av de mest komplekse aktivitetene for å sikre når vi tar en sikkerhetskopi, er at vi må garantere integriteten til dataene, dette leder oss til et dilemma, finner tidspunktet når færre brukere jobber og tar sikkerhetskopien, eller gjør det uavhengig av dataene .
fsync og låsDette bør ikke være tilfelle. Selvfølgelig anbefales det alltid å ta en sikkerhetskopi på det tidspunktet vi vet at det er minst antall brukere, siden vi unngår applikasjonsproblemer. Garanti av dataene er alltid mulig hvis vi bruker det i MongoDB vi vet hvordan fsync Y låse.
Med disse to parametrene kan vi få vår database til å avvise skrivingen, og i det rette øyeblikket kan vi utføre sikkerhetskopiene på riktig måte.
For å opprette denne låsen må vi kjøre følgende kommando i vår database:

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

Med dette vil vi ha vår Database effektivt låst mot å skrive:

Som vi kan se, er det ganske enkelt og effektivt, nå hvis vi vil bryte låsen, må vi bare kjøre kommandoen på nytt:

 db.fsyncUnlock ();

Med sistnevnte vil vi igjen ha vår Database i stand til å motta skriving:

Selv om det ovennevnte representerer større fleksibilitet og gir oss mye mer sikkerhet mot datakorrupsjon og favoriserer integritet, er det virkelig ikke en praksis vi bør følge i virkelige produksjonsmiljøer.
Det ideelle er å skape et miljø med replikering, hvor vi kan få tilgang til en kopi av dataene og dermed kunne manipulere med noen av alternativene vi har de nødvendige sikkerhetskopiene. Å være i en kopi av Database produksjon kan vi blokkere den, eller slå den av og ta sikkerhetskopien på en slik måte at brukeren aldri vil støte på en feil i applikasjonen fordi han ikke kan skrive en post.
Når det gjelder sikkerhetskopier, blir ting mer kompliserte siden det er tilrådelig å bruke serverreplikater, men på grunn av måten det ble tenkt MongoDB, denne typen strukturer mester - slave De er veldig enkle å implementere, så det er vanskeligst å forstå konseptet, men applikasjonen er ekstremt brukervennlig. DBA.
Med dette fullfører vi denne opplæringen, slik vi ser administrasjonen av MongoDB Det er ganske avansert, hvis vi har en mellomstor struktur, har vi kanskje allerede tenkt på spørsmålet om brukersikkerhet, selv om det ikke er komplisert å opprette brukere, hvis det er godt å sette seg ned og definere en god struktur for å lage denne typen tillater.Likte og hjalp du denne opplæringen?Du kan belønne forfatteren ved å trykke på denne knappen for å gi ham et positivt poeng