Sikkerhed og backup i MongoDB

Når vi etablerer vores service i et produktionsmiljø eller måske i et udviklingsmiljø med flere brugere, er det første, vi skal gøre, at oprette en sikkerhedsordning, dette giver os mulighed for at forhindre vores Databaser får adgang til personer forkert.
Hovedtræk ved MongoDB er, at når man installerer en instans, den kører uden at have oprettet nogen form for godkendelsesforanstaltning, er det sådan for at lette udviklingen, men der kommer et punkt, hvor vi skal sikre vores infrastruktur.
Et andet vigtigt punkt, der er relateret til spørgsmålet om sikkerhed og sikkerhedskopiering af vores data, er, når vi skal lave en sikkerhedskopi af et bestemt tidspunkt, men vi ønsker ikke, at der skal ske dataflytning, da vi på denne måde garanterer vores integritet Database og dokumentsamlinger. I dette aspekt er der også et værktøj inden for MongoDB det giver os mulighed for midlertidigt at blokere det for at sikre, at det vi kopierer er passende.
KravDe krav, vi har brug for ved denne lejlighed, er meget enkle, vi skal simpelthen have en forekomst af MongoDB installeret og kørende på vores system, har vi også brug for adgang til tjenesten via konsollen. Denne vejledning blev udviklet i Windows, så nogle kommandoer kan ændre sig i andre operativsystemer, men det har alt at gøre med det, der gøres uden for konsollen MongoDB, og den måde, vi udtrykker ruterne på.
Indstilling af brugergodkendelsesparametre er ikke noget, der er afgørende for driften af MongoDB i produktion, da vi kan installere tjenesten, så det udstyr, hvor det kører, har et forbindelsesfilter, så hvis vi forsøger at få adgang til det pågældende udstyr uden for netværket, har vi ikke adgang.
Denne forenklede tilgang til sikkerhed er meget effektiv, men kun til projekter, hvor tjenesten ikke deles med andre teams, da hvis vi har forskellige udviklingsteam, der arbejder mod den samme server, har vi brug for noget andet. Det er her Godkendelse, med det sørger vi for at anmode om en bruger og adgangskode pr. samling, hvis vi ønsker det, og derfor har vi mulighed for tilstrækkeligt at adskille de forskellige instanser for hver computer.
Begge sikkerhedsforanstaltninger er ikke eksklusive, og hvis vi vil bruge dem samtidigt, er det, vi gør, at skabe en meget mere sikker service for vores miljø, det være sig produktion, præproduktion eller udvikling af flere teams.
Det Godkendelse i sin mest grundlæggende form opnås det med kommandoen createUser Dette skal udføres, når vi har valgt Database admin det er her, vores brugere skal være.
Det er vigtigt at bemærke, at siden versionen 2.6 af MongoDB er, at metoden begyndte at blive brugt createUser, tidligere blev alt løst ved metoden addUserÆndringen blev imidlertid foretaget for at give større alsidighed, når der foretages ændringer.
Lad os se, hvordan vi kan indstille en administratorbruger og derefter en bruger, der kun kan læse databasen prøve.
Strukturen i det dokument, der modtager metoden createUser er det næste:

 {"Bruger": "brugernavn", "pwd": "kodeord", "roller": [{"rolle": "", "db": ""},]}

Som vi bemærkede, skal vi etablere navn og adgangskode til den bruger, vi opretter, men ud over dette skal vi også oprette rollerne, som er en tilladelsesstruktur, der giver os mulighed for at definere de beføjelser, vi giver brugeren .
I det følgende eksempel skal vi oprette en administratorbruger, der har adgang til alle Databaser og det kan kontrollere tjenesten, til dette vil vi bruge roller:

• clusterAdmin
• readAnyDatabase
• læse skrive

Med disse tre parametre kan vi allerede få vores første bruger til at styre. Lad os se, hvordan dette ser ud på konsollen:

Med dette har vi allerede oprettet vores administratorbruger med succes, nu skal vi huske brugernavnet og adgangskoden korrekt, fordi det næste trin, vi vil gøre, er at aktivere sikkerhed, for dette skal vi starte tjenesten med parameteren -auth.
Ved genstart af tjenesten kan vi derefter placere vores nyoprettede administratorbruger, og for at teste den opretter vi en bruger, der kun kan læse Database. Lad os se, hvordan vi genstarter tjenesten i de følgende trin.
Vi skal simpelthen stoppe det først, for eksempel i Windows Vi placerer os på den konsol, den kører i, og trykker på tasterne CTRL + C. Derefter starter vi vores service igen normalt, men i sidste ende passerer vi parameteren aut, som vi kan se i følgende konsol:

Når dette er gjort, vender vi derefter tilbage til kontrolkonsollen af MongoDB, men i dette tilfælde, hvis vi skal bruge vores nyoprettede bruger:

 mongo.exe --brugernavn = root -adgangskode = 123456 admin

Med den tidligere linje kan vi få adgang til vores service sikkert, vi kan se dette på følgende billede:

Det er vigtigt at huske, at vi skal bruge et mere sikkert kodeord end "123456" i dette eksempel, det bruges kun til demonstrationsformål, men til et produktionsmiljø er det ikke egnet.
Da vi har verificeret, hvordan vi får adgang til med godkendelse, vil vi oprette en bruger, der kun kan læse i Database prøve, for dette vil vi gentage oprettelsen af ​​en bruger, men vi vil specificere rollen:

 Læs

På denne måde begrænser vi således brugeren til ikke at kunne skrive i samlingerne. Lad os se svaret i vores konsol:

Når vi nu prøver at skrive et dokument, får vi en fejl:

Vi har da set, hvordan vi allerede har sikret vores brugere tilstrækkeligt, det er klart, at dette brugeradministrationsarbejde er lidt komplekst, men når vi har gjort det, kan vi have stor sikkerhed for, at vi ikke får uautoriseret adgang til Databaser som vi beskytter.
En af de mest komplekse aktiviteter, der skal sikres, når vi laver en sikkerhedskopi, er, at vi skal garantere dataintegriteten, dette fører os til et dilemma, lokaliserer det tidspunkt, hvor færre brugere arbejder og laver backup eller gør det uanset dataene .
fsync og låsDette bør ikke være tilfældet. Selvfølgelig anbefales det altid at lave en sikkerhedskopi på det tidspunkt, hvor vi ved, at der er mindst antal brugere, da vi undgår applikationsproblemer, hvilket garanterer, at data altid er mulige, hvis vi bruger hvad i MongoDB vi ved hvordan fsync Y låse.
Med disse to parametre kan vi få vores database til at afvise skrivninger, og på det rigtige tidspunkt kan vi udføre sikkerhedskopierne korrekt.
For at oprette denne lås skal vi køre følgende kommando i vores database:

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

Med dette vil vi have vores Database effektivt låst mod at skrive:

Som vi kan se, er det ret simpelt og effektivt, nu hvis vi vil bryde låsen, skal vi bare genstarte kommandoen:

 db.fsyncUnlock ();

Med sidstnævnte får vi igen vores Database i stand til at modtage skrift:

Selvom ovenstående repræsenterer større fleksibilitet og giver os meget mere sikkerhed mod datakorruption og favoriserer integritet, er det virkelig ikke en praksis, vi bør følge i virkelige produktionsmiljøer.
Det ideelle er at skabe et miljø med replikation, hvor vi kan få adgang til en kopi af dataene og dermed kunne manipulere med enhver af de muligheder, vi har de nødvendige sikkerhedskopier. At være i en kopi af Database produktion kan vi blokere det, eller slukke det og lave backup på en sådan måde, at brugeren aldrig vil støde på en fejl i applikationen, fordi han ikke kan skrive en post.
Hvad angår sikkerhedskopier, bliver tingene mere komplicerede, da det er tilrådeligt at bruge serverreplikater, men på grund af den måde, det blev udtænkt MongoDB, denne type strukturer mester - slave De er meget lette at implementere, så det er det sværeste at forstå konceptet, men applikationen er yderst brugervenlig. DBA.
Med dette afslutter vi denne vejledning, som vi ser administrationen af MongoDB Det er ret avanceret, hvis vi har en mellemstor struktur, har vi måske allerede tænkt på spørgsmålet om brugersikkerhed, selvom det ikke er komplekst at oprette brugere, hvis det er godt at sidde ned og definere en god struktur for at oprette denne type tilladelser.Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt