Beveiliging en back-up in MongoDB

Bij het opzetten van onze service in een productieomgeving of misschien in een ontwikkelomgeving met meerdere gebruikers, moeten we eerst een beveiligingsschema maken, dit stelt ons in staat te voorkomen dat onze Databases worden door mensen verkeerd benaderd.
Het belangrijkste kenmerk van MongoDB is dat bij het installeren van een instantie het wordt uitgevoerd zonder enige vorm van authenticatiemaatregel te hebben gemaakt, het is zo om de start van ontwikkeling te vergemakkelijken, maar er komt een punt waarop we onze infrastructuur moeten beveiligen.
Een ander belangrijk punt dat verband houdt met de beveiliging en back-up van onze gegevens, is wanneer we een back-up van een bepaald moment moeten maken, maar we willen niet dat er gegevens worden verplaatst, omdat we op deze manier de integriteit van onze Database- en documentverzamelingen. In dit aspect is er ook een tool binnen MongoDB waarmee we het tijdelijk kunnen blokkeren om ervoor te zorgen dat wat we kopiëren geschikt is.
VereistenDe vereisten die we bij deze gelegenheid nodig hebben, zijn heel eenvoudig, we moeten gewoon een exemplaar hebben van: MongoDB geïnstalleerd en actief op ons systeem, hebben we ook toegang tot de service nodig via de console. Deze tutorial is ontwikkeld in ramen, dus sommige opdrachten kunnen veranderen in andere besturingssystemen, maar het heeft allemaal te maken met wat er buiten de console wordt gedaan MongoDB, en de manier waarop we de routes uitdrukken.
Het instellen van parameters voor gebruikersauthenticatie is niet iets dat essentieel is voor de werking van: MongoDB in productie, omdat we de service zo kunnen installeren dat de apparatuur waarop deze wordt uitgevoerd een verbindingsfilter heeft, dus als we proberen toegang te krijgen tot die apparatuur buiten het netwerk, hebben we geen toegang.
Deze simplistische benadering van beveiliging is zeer effectief, maar alleen voor projecten waarbij de service niet wordt gedeeld met andere teams, want als we verschillende ontwikkelteams hebben die tegen dezelfde server werken, hebben we iets anders nodig. Dit is waar de authenticatie, hiermee zorgen we desgewenst voor het opvragen van een gebruiker en wachtwoord per verzameling, waardoor we de mogelijkheid hebben om de verschillende instanties voor elke computer adequaat te scheiden.
Beide beveiligingsmaatregelen zijn niet exclusief en als we ze tegelijkertijd willen gebruiken, creëren we een veel veiligere service voor onze omgeving, of het nu gaat om productie, preproductie of ontwikkeling met meerdere teams.
De authenticatie in zijn meest basale vorm wordt het bereikt met het commando createUser Dit moet worden uitgevoerd wanneer we de . hebben geselecteerd Database beheerder dat is waar onze gebruikers zouden moeten zijn.
Het is belangrijk op te merken dat sinds de versie 2.6 van MongoDB is dat de methode begon te worden gebruikt createUser, in het verleden werd alles opgelost door de methode Voeg gebruiker toeDe wijziging is echter aangebracht om meer veelzijdigheid mogelijk te maken bij het aanbrengen van wijzigingen.
Laten we eens kijken hoe we een administrator-gebruiker kunnen instellen en vervolgens een gebruiker die alleen de database kan lezen toets.
De structuur van het document dat de methode ontvangt createUser is de volgende:

 {"Gebruiker": "gebruikersnaam", "pwd": "wachtwoord", "rollen": [{"rol": "", "db": ""},]}

Zoals we hebben opgemerkt, moeten we de naam en het wachtwoord instellen voor de gebruiker die we maken, maar daarnaast moeten we ook de rollen maken, wat een machtigingsstructuur is waarmee we de bevoegdheden kunnen definiëren die we aan de gebruiker geven .
In het volgende voorbeeld gaan we een administrator-gebruiker maken die toegang heeft tot alle Databases en die de service kan besturen, hiervoor gebruiken we de rollen:

• clusterAdmin
• lees AnyDatabase
• lezen schrijven

Met deze drie parameters kunnen we onze eerste gebruiker al beheren. Laten we eens kijken hoe dit eruit ziet op de console:

Hiermee hebben we onze administrator-gebruiker al met succes gemaakt, nu moeten we de gebruikersnaam en het wachtwoord goed onthouden, want de volgende stap die we zullen doen is beveiliging inschakelen, hiervoor moeten we de service starten met de parameter -authenticatie.
Bij het herstarten van de service kunnen we onze nieuw aangemaakte administrator-gebruiker plaatsen en om deze te testen zullen we een gebruiker maken die alleen de Database. Laten we eens kijken hoe we de service opnieuw opstarten in de volgende stappen.
We moeten het gewoon eerst stoppen, bijvoorbeeld in ramen we positioneren ons op de console waarin deze draait en drukken op de toetsen CTRL + C. Dan beginnen we onze service weer normaal, maar uiteindelijk geven we de parameter door autorisatie, zoals we kunnen zien in de volgende console:

Zodra dit is gebeurd, keren we terug naar de bedieningsconsole van MongoDB, maar in dit geval als we onze nieuw aangemaakte gebruiker gaan gebruiken:

 mongo.exe --username = root --password = 123456 admin

Met die vorige regel hebben we veilig toegang tot onze service, we kunnen dit zien in de volgende afbeelding:

Het is belangrijk om te onthouden dat we een veiliger wachtwoord moeten gebruiken dan "123456". In dit voorbeeld wordt het alleen gebruikt voor demonstratiedoeleinden, maar voor een productieomgeving is het niet geschikt.
Omdat we hebben geverifieerd hoe toegang te krijgen met authenticatie, gaan we een gebruiker maken die alleen kan lezen in de Database toets, hiervoor gaan we het aanmaken van een gebruiker herhalen, maar we gaan de rol specificeren:

 lezen

Op deze manier zullen we de gebruiker dus beperken tot het niet kunnen schrijven in de collecties. Laten we het antwoord in onze console bekijken:

Als we nu proberen een document te schrijven, krijgen we een foutmelding:

We hebben toen gezien hoe we onze gebruikers al adequaat hebben beveiligd, het is duidelijk dat dit gebruikersbeheer een beetje ingewikkeld is, maar als we het eenmaal hebben gedaan, kunnen we grote zekerheid hebben dat we geen ongeautoriseerde toegang tot de Databases die we beschermen.
Een van de meest complexe activiteiten om ervoor te zorgen dat we een back-up maken, is dat we de integriteit van de gegevens moeten garanderen, dit leidt ons tot een dilemma, het tijdstip bepalen waarop minder gebruikers werken en de back-up maken, of dit ongeacht de gegevens doen .
fsync en vergrendelenDit zou niet het geval moeten zijn, natuurlijk wordt het altijd aanbevolen om een ​​back-up te maken op het moment dat we weten dat er het minste aantal gebruikers is, omdat we applicatieproblemen vermijden, en garanderen dat de gegevens altijd mogelijk zijn als we gebruiken wat in MongoDB we weten hoe fsync Y slot.
Met deze twee parameters kunnen we ervoor zorgen dat onze database de schrijfbewerkingen weigert, en op dat juiste moment kunnen we de back-ups op de juiste manier uitvoeren.
Om dit slot te maken, moeten we de volgende opdracht in onze database uitvoeren:

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

Hiermee hebben we onze Database effectief vergrendeld tegen schrijven:

Zoals we kunnen zien, is het vrij eenvoudig en effectief, nu als we het slot willen verbreken, hoeven we alleen de opdracht opnieuw uit te voeren:

 db.fsyncUnlock ();

Met dat laatste hebben we weer onze Database in staat om schrift te ontvangen:

Hoewel het bovenstaande een grotere flexibiliteit vertegenwoordigt en ons veel meer beveiliging geeft tegen gegevenscorruptie en de integriteit bevordert, is het echt geen praktijk die we in echte productieomgevingen zouden moeten volgen.
Het ideaal is om een ​​omgeving met replicatie te creëren, waar we toegang hebben tot een kopie van de gegevens en dus met een van de opties kunnen manipuleren dat we de nodige back-ups hebben. In een replica van de Database productie kunnen we het blokkeren, of uitschakelen en de back-up zo maken dat de gebruiker nooit een fout in de applicatie zal tegenkomen omdat hij geen record kan schrijven.
Wat betreft back-ups, wordt het ingewikkelder omdat het raadzaam is om serverreplica's te gebruiken, maar vanwege de manier waarop het is bedacht MongoDB, dit soort structuren meester - slaaf Ze zijn heel eenvoudig te implementeren, dus het begrijpen van het concept is het moeilijkst, maar de toepassing ervan is uiterst gebruiksvriendelijk. DBA.
Hiermee ronden we deze tutorial af, zoals we zien bij de administratie van MongoDB Het is behoorlijk geavanceerd, als we een middelgrote structuur hebben, hebben we misschien al nagedacht over de kwestie van gebruikersbeveiliging, hoewel het maken van gebruikers niet ingewikkeld is, als het goed is om te gaan zitten en een goede structuur te definiëren om dit soort vergunningen.Vond je deze Tutorial leuk en heb je eraan geholpen?Je kunt de auteur belonen door op deze knop te drukken om hem een ​​positief punt te geven