MongoDB Osäkerhetsnivåer och hur man undviker dem

De flesta databashanteringssystem har flera tekniker för att säkra sina data från en utomstående eller en obehörig person eller applikation. Teknikerna förhindrar att din data läses eller kopieras utan användarens tillåtelse.

MongoDB är inte annorlunda eftersom den har vissa osäkerhetsnivåer. I det här blogginlägget kommer vi att diskutera osäkerhetsnivåerna i MongoDB och hur man undviker dem så att du kan skydda din MongoDB-installation.

För säkerheten och säkerheten för din MongoDB är följande några av de viktigaste säkerhetsåtgärderna att ta hänsyn till:

Autentisering av användaranslutningar.
Auktorisering/rollbaserad åtkomstkontroll.
Nätverkskryptering/transportkryptering.
Storage Encryption/ Encryption-at-rest.
Revision.

I den här artikeln kommer vi att titta på ovanstående säkerhetsåtgärder i detalj, med mycket fokus på autentisering och auktorisering.

Autentisering och auktorisering

Autentisering och auktorisering måste aktiveras unisont. De kan dock användas oberoende av varandra. Autentisering förhindrar åtkomst till en okänd person som har nätverksåtkomst till databasservern från att kopiera eller skada databasdata. Autentisering kräver att alla klienter och servrar tillhandahåller giltiga referenser innan de kan ansluta till systemet. Auktorisering å andra sidan hindrar en applikation eller en användare från att läsa, ändra eller radera data annat än vad de skulle.

För att konfigurera rollbaserad åtkomstkontroll;

Skapa en användaradministratör först.
Skapa ytterligare användare.
Skapa sedan en unik MongoDB-användare för varje person/applikation som kommer åt systemet.
Genom att följa principen om minsta privilegium bör du skapa roller som definierar de exakta åtkomsträttigheter som behövs för en uppsättning av användare.
Tilldela sedan användarna endast de roller som de behöver utföra i sin verksamhet. En användare kan vara en klientapplikation eller en person.

Du bör notera att en användare kan ha privilegier över olika eller flera databaser. I det scenariot, istället för att skapa en användare flera gånger i olika databaser, skapa en enda användare med roller som ger tillämpliga databasbehörigheter.

Oftare än inte kan dessa två säkerhetsåtgärder förväxlas till att betyda samma sak. I vissa scenarier liknar de varandra, men de är också olika.

Likheter mellan autentisering och auktorisering

Båda är något av en enda enhet eftersom, när du aktiverar autentisering, aktiveras auktorisering automatiskt. Auktorisering är aktiverad i samklang med autentisering och därför kommer anslutningar från okända användare inte att ha någon behörighet att komma åt databasdata. Auktorisering kräver också att användarnamnet verifieras av autentisering för att veta vilka privilegier som gäller för en anslutnings förfrågningar. Därför kan den inte aktiveras oberoende av den andra heller.
De är också båda lika i olyckliga, äldre namngivning av konfigurationsalternativ. Alternativet för konfigurationsfilen för autentisering är security.authorization istället för säkerhetsautentisering som det skulle förväntas. När du använder kommandot är autentisering den första som aktiveras och auktorisering är endast aktiverad som en efterverkan. "-auth" är kommandoradsargumentet för att aktivera autentisering som automatiskt tvingar auktorisering att vara på också.

Skillnader mellan autentisering och auktorisering

Dessa två är olika eftersom de är två delar av programvaran som har olika funktioner.

Autentisering ==Användaridentitet, med hjälp av autentiseringskontroll.

Auktorisering ==Tilldelar och upprätthåller behörigheter för DB-objekt och DB-kommando.

Under den första installationen är autentisering avaktiverad för lokala värdanslutningar. Detta är dock kortfattat eftersom du får en möjlighet att skapa den första användaren, och undantagsbehörigheten (till regeln för autentisering och auktorisering på tillsammans) tas bort.

Hur man kontrollerar om autentisering och auktorisering är aktiverade eller inte

De första versionerna av MongoDB hade "- auth" inställd som standard och detta anses allmänt vara ett dåligt drag. Även i version 4.0 var den fortfarande avstängd som standard. Tom konfiguration innebär fortfarande att auktorisering är avstängd trots att den har startvarningar och olika exponeringsminskningar till exempel att localhost blir den enda standardbundna nätverksenheten i MongoDB v3.6.

Du använder inte autentisering eller snarare så har du inte autentisering aktiverad om mongods konfigurationsfiler inte gör det:

Ha security.authorization inställd på 'enabled'.
Inkludera en security.key-fil.
Inkludera en security.clusterAuthMode-inställning som tvingar autentisering att vara på.

För att dubbelkolla om du har autentisering och auktorisering aktiverat eller inte, kan du prova denna snabba mongo shell one-liner (utan användarens autentiseringsargument inställda):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

Svaret du bör få är ett "obehörigt" fel. Men å andra sidan, om du får en lista med databasnamn betyder det automatiskt att du har en naken MongoDB-distribution.

Extern autentisering

Som namnet antyder handlar extern autentisering om att tillåta användare att autentiseras i en extern tjänst. Som ett undantag kan den inte användas för den interna mongodb __-systemanvändaren, men att använda den för alla riktiga mänskliga användare eller klientapplikationstjänstkonton är perfekt.

Den externa autentiseringstjänsten kommer helt enkelt att vara en Kerberos KDC, eller en ActiveDirectory- eller OpenLDAP-server. Du bör notera att användning av extern autentisering inte hindrar dig från att ha vanliga MongoDB-användarkonton samtidigt.

Intern autentisering

Tvärtom, MongoDB intern autentisering betyder inte motsatsen till extern autentisering. Detta beror på att en mongod-nod som körs med autentisering aktiverad inte litar på att någon TCP-peer är en annan mongod- eller mongosnod bara för att den kommunicerar som en. Snarare kräver det att kamraten autentiserar genom bevis på delad hemlighet.

Det finns två typer av interna autentiseringsmekanismer i MongoDB:

Intern nyckelfilsautentisering.
SCRAM eller x.509 intern autentisering.

Intern nyckelfilsautentisering

Detta är standardmekanismen för intern autentisering i MongoDB. Termen "nyckel" indikerar en asymmetrisk krypteringsnyckel men i verklig mening är det bara ett lösenord oavsett hur du skapade det. Nyckelfilen sparas i en identisk fil som distribueras till varje mongod och mongos nod i klustret. I scenariot som lösenordet används framgångsrikt, kommer en mongod-nod att tillåta kommandon som kommer från den autentiserade peeren att köras som "_ _ system"-superanvändare.

Om någon har en kopia av nyckelfilen kan de helt enkelt ta bort kontroll- och icke-utskrivna tecken från nyckelfilen för att skapa lösenordssträngen som gör att de kan ansluta som "_ _ system"-användare.

Men om det händer och du kör kommandot nedan som mongod (eller root) användare på en av dina MongoDB-servrar och lyckas, bör du inte oroa dig eftersom det inte kommer att finnas någon oavsiktlig läsrättighetsläcka . Detta beror på att mongod kommer att avbryta vid start om nyckelfilen är i något annat än 400 (eller 600) filbehörighetsläge.

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Om du av misstag sparar nyckelfilen i din världsläsbara källkontroll kan dock användare som inte är DBA:er (eller serveradministratörer med root) läsa en kopia av nyckelfilen. Detta betraktas som ett säkerhetsfel.

En extrem risk ökar när nyckelfilen distribueras med mongos-noder som ägs och körs som en av applikationsteamets unix-användare istället för "mongod" eller annan DBA-teamägd unix-användare.

SCRAM eller x.509 intern autentisering

Den x.509 interna autentiseringsmekanismen använder faktiskt asymmetriska privata eller publika nycklar och måste användas tillsammans med TLS/SSL. Den här mekanismen kan användas för klientanslutningar såväl som intern autentisering.

X.509- eller SCRAM-mekanismen har en fördel framför Keyfile-mekanismen eftersom det i x.509-mekanismen är mindre troligt att en av nycklarna som används med mongod- och mongos-noder kan missbrukas av en inkräktare som får en kopia av den. Detta beror dock på hur strikt x.509-certifikaten är inställda. För att få maximal säkerhet från denna mekanism bör du ha ett dedikerat säkerhetsteam som förstår x.509-koncepten och bästa praxis. Dessa bästa praxis inkluderar skärpning av vilka värdar det kommer att arbeta på, och att kunna återkalla och rulla över certifikat.

Nätverkskryptering/transportkryptering

Nätverkskryptering hindrar någon från att kopiera data som överförs via en nätverkslänk någonstans mellan två servrar. Nätverkskryptering kräver lite eller ingen tanke när det gäller att bestämma sig för om den ska användas eftersom det är avgörande. Men om till exempel ditt MongoDB-kluster och alla dess klienter finns i ett virtuellt privat nätverk som du tror inte har några hål i sin brandvägg och ingen risk för eskalering av privilegier från andra appar, så behöver du inte nätverkskryptering.

För nätverkskryptering bör du konfigurera MongoDB att använda TLS/SSL för alla utgående och inkommande anslutningar. Kryptera kommunikation mellan mongod och mongos komponenter i en MOngoDB-distribution samt mellan alla applikationer och MongoDB med TLS/SSL.

Börjar i version 4.0; MongoDB inaktiverar stöd för TLS 1.0-kryptering på system där TLS 1.1+ är tillgängligt och den använder även följande inbyggda TLS/SSL-bibliotek:

Windows - Secure Channel (Schannel).
Linux/BSD - OpenSSL.
macOS - Säker transport.

Begränsa nätverksexponering

Du bör se till att MongoDB körs i en pålitlig nätverksmiljö och även konfigurera brandvägg eller säkerhetsgrupper för att kontrollera inkommande och utgående trafik för dina MongoDB-instanser. Mer så, konfigurera för att endast tillåta betrodda klienter att komma åt nätverksgränssnitten och portarna där MongoDB-instanser är tillgängliga. Använd till exempel IP-vitlista för att tillåta åtkomst från betrodda IP-adresser.

Kör MongoDB med säkra konfigurationsalternativ

MongoDB stöder körning av JavaScript-koden för följande operationer på serversidan:

kartaReducera.
$where.
$accumulator.
$funktion.

Använd alternativet -- noscripting på kommandoraden för att inaktivera server-side scripting om du inte använder ovanstående operationer. Håll indatavalidering aktiverad även om MongoDB aktiverar indatavalidering som standard via inställningen net.wireObjectCheck. Detta säkerställer att alla dokument som lagras av mongod intsance är giltiga BSON.

MongoDB Storage Encryption/ Encryption-at-rest

Lagringskryptering hindrar någon från att få en kopia av de underliggande databasfilerna. Detta kan hända när någon bryter sig in i ditt datacenter och stjäl din servers hårddisk. MongoDB-data inkluderar datafiler, konfigurationsfiler, granskningsloggar och nyckelfiler.

Från och med MongoDB Enterprise 3.2 kan du kryptera data i lagringslagret med WiredTiger-lagringsmotorns inbyggda Encryption-at-rest. MongoDB-data bör krypteras på varje värd med filsystem, enhet eller fysisk kryptering när du inte använder WiredTigers kryptering-at-vila. Du bör också samla in loggar till ett centralt logglager eftersom dessa loggar innehåller DB-autentiseringsförsök inklusive käll-IP-adress. Lagringskryptering har dock en liten prestandakostnad.

Revision

Revision hjälper till att spåra en databasanvändare som vet hur man döljer sina spår efter att ha ändrat eller ändrat databasdata. I grund och botten spårar revision åtkomst och ändringar av databaskonfigurationer och data. MongoDB Enterprise har en revisionssystemfunktion som kan registrera systemhändelser som användaroperationer och anslutningshändelser på en MongoDB-instans.

Dessa revisionsposter hjälper till med rättsmedicinska analyser och tillåter administratörer att verifiera korrekta kontroller. Revision är av högt värde för vissa användare men kan bara vara det när vissa andra risker elimineras. Till exempel kan en angripare inte få Unix root-åtkomst på servrarna när de kör live mongod-noderna.

Gå framåt

Du kan ställa in filter för att registrera specifika händelser som autentiseringshändelser. Men var försiktig, för när granskningsfiltren görs för breda kommer dess prestanda snabbt att kvävas, vilket leder till höga prestandakostnader. Även om revisionen används på rätt sätt, kommer det inte att bli mycket prestationskostnader.