Säkerhet och säkerhetskopiering i MongoDB

När vi etablerar vår tjänst i en produktionsmiljö eller kanske i en utvecklingsmiljö med flera användare, är det första vi måste göra att skapa ett säkerhetsschema, detta gör att vi kan förhindra våra Databaser får åtkomst av personer på fel sätt.
Huvuddragen i MongoDB är att när du installerar en instans körs den utan att ha skapat någon typ av autentiseringsåtgärd, det är så här för att underlätta utvecklingen, men det kommer en punkt där vi måste säkra vår infrastruktur.
En annan viktig punkt som är relaterad till frågan om säkerhet och säkerhetskopiering av våra data är när vi behöver göra en säkerhetskopia av ett visst ögonblick, men vi vill inte att det ska ske dataförflyttning, eftersom vi på så sätt garanterar integriteten hos våra Databas- och dokumentsamlingar. I denna aspekt finns det också ett verktyg inom MongoDB som tillåter oss att tillfälligt blockera det för att säkerställa att det vi kopierar är lämpligt.
KravKraven som vi behöver vid det här tillfället är mycket enkla, vi måste helt enkelt ha en instans av MongoDB installerat och kört på vårt system, kommer vi också att behöva åtkomst till tjänsten via konsolen. Denna handledning utvecklades i Windows, så vissa kommandon kan ändras i andra operativsystem, men allt har att göra med vad som görs utanför konsolen MongoDB, och hur vi uttrycker rutterna.
Att ställa in användarverifieringsparametrar är inte något som är avgörande för driften av MongoDB i produktion, eftersom vi kan installera tjänsten så att utrustningen där den körs har ett anslutningsfilter, så om vi försöker komma åt utrustningen utanför nätverket har vi inte åtkomst.
Denna förenklade strategi för säkerhet är mycket effektiv, men bara för projekt där tjänsten inte delas med andra team, eftersom om vi har olika utvecklingsteam som arbetar mot samma server behöver vi något annat. Det är här autentisering, med det tar vi hand om att begära en användare och lösenord per samling om vi vill, så vi har möjlighet att på ett adekvat sätt separera de olika instanserna för varje dator.
Båda säkerhetsåtgärderna är inte exklusiva och om vi vill använda dem samtidigt är det vi gör att skapa en mycket säkrare tjänst för vår miljö, vare sig det är produktion, förproduktion eller utveckling av flera team.
De autentisering i sin mest grundläggande form uppnås det med kommandot skapa användare Detta måste utföras när vi har valt Databas administration det är där våra användare ska vara.
Det är viktigt att notera att sedan versionen 2.6 av MongoDB är att metoden började användas skapa användare, tidigare löstes allt med metoden Lägg till användareÄndringen gjordes dock för att möjliggöra större mångsidighet vid ändringar.
Låt oss se hur vi kan ställa in en administratörsanvändare och sedan en användare som bara kan läsa databasen testa.
Strukturen för det dokument som tar emot metoden skapa användare är nästa:

 {"Användare": "användarnamn", "pwd": "lösenord", "roller": [{"role": "", "db": ""},]}

Som vi noterade måste vi fastställa namnet och lösenordet för användaren som vi skapar, men utöver detta måste vi också skapa rollerna, vilket är en behörighetsstruktur som gör att vi kan definiera de befogenheter som vi ger användaren .
I följande exempel kommer vi att skapa en administratörsanvändare som har åtkomst till alla Databaser och som kan styra tjänsten, för detta kommer vi att använda roller:

• clusterAdmin
• readAnyDatabase
• läsa skriva

Med dessa tre parametrar kan vi redan ha vår första användare att hantera. Låt oss se hur det ser ut på konsolen:

Med detta har vi redan skapat vår administratörsanvändare framgångsrikt, nu måste vi komma ihåg användarnamnet och lösenordet ordentligt eftersom nästa steg vi kommer att göra är att aktivera säkerhet, för detta måste vi starta tjänsten med parametern -äkta.
När vi startar om tjänsten kan vi sedan placera vår nyskapade administratörsanvändare och för att testa den skapar vi en användare som bara kan läsa Databas. Låt oss se hur vi startar om tjänsten i följande steg.
Vi måste helt enkelt stoppa det först, till exempel i Windows vi placerar oss på konsolen där den körs och trycker på knapparna CTRL + C. Sedan startar vi vår tjänst igen normalt men i slutändan passerar vi parametern aut, som vi kan se i följande konsol:

När detta är gjort återgår vi till kontrollpanelen för MongoDB, men i det här fallet om vi ska använda vår nyskapade användare:

 mongo.exe -användarnamn = root -lösenord = 123456 admin

Med den tidigare raden kan vi komma åt vår tjänst på ett säkert sätt, vi kan se detta i följande bild:

Det är viktigt att komma ihåg att vi måste använda ett säkrare lösenord än "123456" i det här exemplet, det används bara för demonstrationsändamål, men för en produktionsmiljö är det inte lämpligt.
Eftersom vi har verifierat hur vi kommer åt med autentisering kommer vi att skapa en användare som bara kan läsa i Databas testa, för detta kommer vi att upprepa skapandet av en användare, men vi kommer att specificera rollen:

 läsa

På så sätt kommer vi att begränsa användaren till att inte kunna skriva i samlingarna. Låt oss se svaret i vår konsol:

När vi försöker skriva ett dokument får vi ett felmeddelande:

Vi har då sett hur vi redan har säkrat våra användare på ett adekvat sätt, det är klart att detta användaradministrationsarbete är lite komplext, men när vi väl har gjort det kan vi ha stor säkerhet om att vi inte kommer att få obehörig åtkomst till Databaser som vi skyddar.
En av de mest komplexa aktiviteterna för att säkerställa när vi gör en säkerhetskopia är att vi måste garantera datans integritet, detta leder oss till ett dilemma, lokaliserar den tid då färre användare arbetar och gör säkerhetskopian, eller gör det oavsett data .
fsync och låsDetta bör inte vara fallet, naturligtvis gör vi alltid en säkerhetskopia när vi vet att det finns minst antal användare eftersom vi undviker programproblem, garanterar att data alltid är möjliga om vi använder vad i MongoDB vi vet hur fsync Y låsa.
Med dessa två parametrar kan vi få vår databas att avvisa skrivningarna, och i det rätta ögonblicket kan vi utföra säkerhetskopiorna på lämpligt sätt.
För att skapa detta lås måste vi köra följande kommando i vår databas:

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

Med detta kommer vi att ha vår Databas effektivt låst mot att skriva:

Som vi kan se är det ganska enkelt och effektivt, nu om vi vill bryta låset måste vi bara köra om kommandot:

 db.fsyncUnlock ();

Med det senare kommer vi återigen att få vårt Databas kan ta emot skrivande:

Även om ovanstående representerar större flexibilitet och ger oss mycket mer säkerhet mot datakorruption och gynnar integritet, är det verkligen inte en praxis som vi bör följa i verkliga produktionsmiljöer.
Idealet är att skapa en miljö med replikering, där vi kan komma åt en kopia av data och därmed kunna manipulera med valfritt alternativ som vi har nödvändiga säkerhetskopior. Att vara i en kopia av Databas produktion kan vi blockera det, eller stänga av det och göra säkerhetskopian på ett sådant sätt att användaren aldrig kommer att stöta på ett fel i applikationen eftersom han inte kan skriva en post.
När det gäller säkerhetskopior blir saker och ting mer komplicerade eftersom det är lämpligt att använda serverreplikat, dock på grund av hur det var tänkt MongoDB, denna typ av strukturer mästare - slav De är mycket enkla att implementera, så att förstå konceptet är det svåraste, men dess tillämpning är extremt användarvänlig. DBA.
Med detta avslutar vi denna handledning, som vi ser administrationen av MongoDB Det är ganska avancerat, om vi har en medelstor struktur kan vi redan ha tänkt på frågan om användarsäkerhet, även om det inte är komplext att skapa användare, om det är bra att sätta sig ner och definiera en bra struktur för att skapa denna typ av tillstånd.Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng