MongoDB-onveiligheidsniveaus en hoe ze te vermijden

De meeste databasebeheersystemen hebben verschillende technieken om hun gegevens te beveiligen tegen een buitenstaander of een onbevoegde persoon of applicatie. De technieken voorkomen dat uw gegevens worden gelezen of gekopieerd zonder toestemming van de gebruiker.

MongoDB is niet anders omdat het een aantal onveiligheidsniveaus heeft. In deze blogpost bespreken we de onveiligheidsniveaus in MongoDB en hoe u ze kunt vermijden, zodat u uw MongoDB-installatie kunt beschermen.

Voor de veiligheid en beveiliging van uw MongoDB zijn de volgende enkele van de belangrijkste beveiligingsmaatregelen die strikt in acht moeten worden genomen:

Verificatie van gebruikersverbindingen.
Autorisatie/op rollen gebaseerde toegangscontrole.
Netwerkcodering/transportcodering.
Opslagcodering/codering-at-rest.
Controle.

In dit artikel zullen we de bovenstaande beveiligingsmaatregelen in detail bekijken, met veel aandacht voor authenticatie en autorisatie.

Authenticatie en autorisatie

Verificatie en autorisatie moeten gelijktijdig worden geactiveerd. Ze kunnen echter onafhankelijk van elkaar worden gebruikt. Verificatie voorkomt dat toegang tot een onbekende persoon die netwerktoegang heeft tot de databaseserver de databasegegevens kan kopiëren of beschadigen. Verificatie vereist dat alle clients en servers geldige referenties verstrekken voordat ze verbinding kunnen maken met het systeem. Autorisatie daarentegen voorkomt dat een applicatie of een gebruiker andere gegevens leest, wijzigt of verwijdert dan de bedoeling was.

Op rollen gebaseerde toegangscontrole configureren;

Maak eerst een gebruikersbeheerder.
Maak extra gebruikers aan.
Maak vervolgens een unieke MongoDB-gebruiker aan voor elke persoon/toepassing die toegang heeft tot het systeem.
Door het principe van de minste bevoegdheden te volgen, moet u rollen maken die de exacte toegangsrechten definiëren die een set nodig heeft van gebruikers.
Wijs de gebruikers vervolgens alleen de rollen toe die ze in hun activiteiten moeten uitvoeren. Een gebruiker kan een clienttoepassing of een persoon zijn.

Houd er rekening mee dat een gebruiker privileges kan hebben over verschillende of meerdere databases. Maak in dat scenario, in plaats van meerdere keren een gebruiker in verschillende databases aan te maken, een enkele gebruiker met rollen die toepasselijke databaserechten verlenen.

Vaak kunnen deze twee beveiligingsmaatregelen worden verward om hetzelfde te betekenen. In sommige scenario's lijken ze op elkaar, maar ze zijn ook verschillend.

Overeenkomsten tussen authenticatie en autorisatie

Beide vormen een beetje een eenheid omdat, wanneer u verificatie inschakelt, autorisatie automatisch wordt ingeschakeld. Autorisatie wordt tegelijk met authenticatie ingeschakeld, dus verbindingen van onbekende gebruikers hebben geen toegangsrechten tot databasegegevens. Autorisatie vereist ook dat de gebruikersnaam wordt geverifieerd door authenticatie om te weten welke privileges van toepassing zijn op de verzoeken van een verbinding. Daarom kan het ook niet onafhankelijk van elkaar worden ingeschakeld.
Ze lijken ook allebei op de ongelukkige, oude naamgeving van configuratie-opties. De configuratiebestandsoptie voor authenticatie is security.authorization in plaats van beveiligingsauthenticatie zoals verwacht. Wanneer u de opdracht echter gebruikt, is verificatie de eerste die wordt ingeschakeld en wordt autorisatie alleen ingeschakeld als een nawerking. "-auth" is het commandoregelargument voor het inschakelen van authenticatie, waardoor autorisatie ook automatisch wordt ingeschakeld.

Verschillen tussen authenticatie en autorisatie

Deze twee zijn verschillend omdat het twee delen van de software zijn die verschillende functies hebben.

Authenticatie ==Gebruikersidentiteit, door middel van referentiecontrole.

Autorisatie ==Toewijzen en afdwingen van machtigingen voor DB-objecten en DB-opdrachten.

Tijdens de eerste installatie is verificatie uitgeschakeld voor localhost-verbindingen. Dit is echter kort, aangezien u één kans krijgt om de eerste gebruiker aan te maken, waarna de uitzondering (op de regel voor authenticatie en autorisatie op samen) komt te vervallen.

Controleren of authenticatie en autorisatie zijn ingeschakeld of niet

De eerste versies van MongoDB hadden standaard "- auth" en dit wordt algemeen beschouwd als een slechte zet. Zelfs in versie 4.0 was het nog steeds standaard uitgeschakeld. Lege configuratie staat nog steeds gelijk aan autorisatie uitgeschakeld ondanks opstartwaarschuwingen en verschillende blootstellingsbeperkingen, zoals localhost dat het enige standaardgebonden netwerkapparaat wordt in MongoDB v3.6.

U gebruikt geen verificatie of u heeft verificatie niet ingeschakeld als de mongod-configuratiebestanden dat niet doen:

Stel security.authorization in op 'enabled'.
Voeg een security.keyfile toe.
Voeg een security.clusterAuthMode-instelling toe die authenticatie dwingt.

Om te controleren of je authenticatie en autorisatie hebt ingeschakeld of niet, kun je deze snelle mongo-shell one-liner proberen (zonder argumenten voor gebruikersreferenties ingesteld):

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

Het antwoord dat u zou moeten krijgen, is een "ongeautoriseerde" fout. Maar aan de andere kant, als je een lijst met databasenamen krijgt, betekent dat automatisch dat je een naakte MongoDB-implementatie hebt.

Externe authenticatie

Zoals de naam al doet vermoeden, gaat externe authenticatie over het toestaan van authenticatie van gebruikers in een externe service. Bij wijze van uitzondering kan het niet worden gebruikt voor de interne mongodb __-systeemgebruiker, maar het is perfect geschikt om het te gebruiken voor een echte menselijke gebruiker of klanttoepassingsservice-account.

De externe auth-service zal een Kerberos KDC zijn, of een ActiveDirectory- of OpenLDAP-server. Houd er rekening mee dat het gebruik van externe authenticatie niet verhindert dat u tegelijkertijd gewone MongoDB-gebruikersaccounts heeft.

Interne authenticatie

Integendeel, interne authenticatie van MongoDB betekent niet het tegenovergestelde van externe authenticatie. Dit komt omdat een mongod-knooppunt dat draait met authenticatie ingeschakeld, er niet op vertrouwt dat een TCP-peer een ander is, een ander mongod- of mongos-knooppunt alleen omdat het als één communiceert. Het vereist eerder dat de peer authenticeert door een bewijs van gedeeld geheim.

Er zijn twee soorten interne authenticatiemechanismen in MongoDB:

Interne authenticatie van sleutelbestand.
SCRAM of x.509 interne authenticatie.

Interne authenticatie sleutelbestand

Dit is het standaard interne authenticatiemechanisme in MongoDB. De term "sleutel" geeft een asymmetrische coderingssleutel aan, maar in feite is het gewoon een wachtwoord, ongeacht hoe u het hebt gegenereerd. Het sleutelbestand wordt opgeslagen in een identiek bestand dat wordt gedistribueerd naar elk mongod- en mongos-knooppunt in het cluster. In het scenario dat het wachtwoord met succes wordt gebruikt, staat een mongod-knooppunt toe dat opdrachten van de geverifieerde peer worden uitgevoerd als de "_ _ systeem" -supergebruiker.

Als iemand een kopie van het sleutelbestand heeft, kunnen ze eenvoudig de controle- en niet-afdrukbare tekens uit het sleutelbestand verwijderen om de wachtwoordreeks te maken waarmee ze verbinding kunnen maken als de "_ _ systeem" -gebruiker.

Als dat echter gebeurt en je voert de onderstaande opdracht uit als de mongod (of root) gebruiker op een van je MongoDB-servers en slaagt erin, hoef je je geen zorgen te maken, want er zullen geen onopzettelijke leesrechten lekken . Dit komt omdat de mongod bij het opstarten afbreekt als het sleutelbestand zich in een andere modus dan 400 (of 600) bestandspermissies bevindt.

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

Echter, als u per ongeluk het sleutelbestand opslaat in uw wereldwijd leesbare bronbeheer, kunnen gebruikers die geen DBA zijn (of de serverbeheerders met root) een kopie van het sleutelbestand lezen. Dit wordt beschouwd als een beveiligingsfout.

Een extreem risico neemt toe wanneer het sleutelbestand wordt gedistribueerd met mongos-knooppunten die eigendom zijn van en worden uitgevoerd als een van de unix-gebruikers van het applicatieteam in plaats van "mongod" of een andere unix-gebruiker die eigendom is van het DBA-team.

SCRAM of x.509 interne authenticatie

Het interne authenticatiemechanisme van x.509 gebruikt in feite asymmetrische privé- of openbare sleutels en moet worden gebruikt in combinatie met TLS/SSL. Dit mechanisme kan worden gebruikt voor clientverbindingen en voor interne authenticatie.

Het x.509- of SCRAM-mechanisme heeft een voordeel ten opzichte van het Keyfile-mechanisme omdat het in het x.509-mechanisme minder waarschijnlijk is dat een van de sleutels die zijn geïmplementeerd met mongod- en mongos-knooppunten kan worden misbruikt door een indringer die er een kopie van krijgt. Dit hangt echter af van hoe strikt de x.509-certificaten zijn ingesteld. Om te profiteren van maximale beveiliging van dit mechanisme, moet u een toegewijd beveiligingsteam hebben dat de x.509-concepten en best practices begrijpt. Deze best practices omvatten het aanscherpen van de hosts waaraan het zal werken en het kunnen intrekken en overdragen van certificaten.

Netwerkcodering/transportcodering

Netwerkcodering voorkomt dat iemand de gegevens kopieert die worden overgedragen via een netwerkverbinding ergens tussen twee servers. Netwerkcodering vereist weinig of geen nadenken als het gaat om de beslissing om het te gebruiken, omdat het cruciaal is. Maar als bijvoorbeeld uw MongoDB-cluster en al zijn clients zich in een virtueel particulier netwerk bevinden waarvan u denkt dat het geen gaten in de firewall heeft en geen risico op escalatie van bevoegdheden van andere apps, dan heeft u geen netwerkversleuteling nodig.

Voor netwerkcodering moet u MongoDB configureren om TLS/SSL te gebruiken voor alle uitgaande en inkomende verbindingen. Versleutel de communicatie tussen mongod en mongos-componenten van een MOngoDB-implementatie en tussen alle applicaties en MongoDB met behulp van TLS/SSL.

Vanaf versie 4.0; MongoDB schakelt ondersteuning voor TLS 1.0-codering uit op systemen waarop TLS 1.1+ beschikbaar is en gebruikt ook de volgende native TLS/SSL-bibliotheken:

Windows - Beveiligd kanaal (Schannel).
Linux/BSD - OpenSSL.
macOS - Beveiligd transport.

Beperk netwerkblootstelling

U moet ervoor zorgen dat MongoDB in een vertrouwde netwerkomgeving draait en ook firewall- of beveiligingsgroepen configureren om inkomend en uitgaand verkeer voor uw MongoDB-instanties te controleren. Meer nog, configureer om alleen vertrouwde clients toegang te geven tot de netwerkinterfaces en poorten waarop MongoDB-instanties beschikbaar zijn. Gebruik bijvoorbeeld IP-whitelisting om toegang vanaf vertrouwde IP-adressen toe te staan.

Voer MongoDB uit met veilige configuratie-opties

MongoDB ondersteunt de uitvoering van JavaScript-code voor de volgende server-side bewerkingen:

mapReduce.
$where.
$accumulator.
$functie.

Gebruik de -- noscripting optie op de opdrachtregel om server-side scripting uit te schakelen als u de bovenstaande bewerkingen niet gebruikt. Houd invoervalidatie ingeschakeld, hoewel MongoDB invoervalidatie standaard inschakelt via de instelling net.wireObjectCheck. Dit zorgt ervoor dat alle documenten die zijn opgeslagen door de mongod-instantie geldige BSON zijn.

MongoDB-opslagversleuteling/ versleuteling-at-rest

Opslagcodering voorkomt dat iemand een kopie van de onderliggende databasebestanden bemachtigt. Dit kan gebeuren wanneer iemand inbreekt in uw datacenter en de harde schijf van uw server steelt. MongoDB-gegevens omvatten gegevensbestanden, configuratiebestanden, controlelogboeken en sleutelbestanden.

Vanaf MongoDB Enterprise 3.2 kunt u gegevens in de opslaglaag versleutelen met de native Encryption-at-rest van de WiredTiger-opslagengine. MongoDB-gegevens moeten op elke host worden gecodeerd met behulp van bestandssysteem-, apparaat- of fysieke codering wanneer geen gebruik wordt gemaakt van WiredTiger-codering in rust. U moet ook logboeken verzamelen in een centraal logboekarchief, aangezien deze logboeken DB-authenticatiepogingen bevatten, inclusief het bron-IP-adres. Opslagversleuteling heeft echter kleine prestatiekosten.

Auditing

Auditing helpt bij het volgen van een databasegebruiker die weet hoe hij zijn sporen moet verbergen na het wijzigen of wijzigen van databasegegevens. Kortom, auditing houdt toegang tot en wijzigingen aan databaseconfiguraties en gegevens bij. MongoDB Enterprise heeft een controlesysteemfunctie waarmee systeemgebeurtenissen zoals gebruikersbewerkingen en verbindingsgebeurtenissen op een MongoDB-instantie kunnen worden vastgelegd.

Deze auditrecords helpen bij forensische analyse en stellen beheerders in staat de juiste controles te verifiëren. Auditing is voor sommige gebruikers van grote waarde, maar dat kan alleen als bepaalde andere risico's worden geëlimineerd. Een aanvaller kan bijvoorbeeld geen Unix-roottoegang op de servers krijgen terwijl de live mongod-knooppunten worden uitgevoerd.

Vooruit gaan

Je kunt filters instellen om specifieke gebeurtenissen vast te leggen, zoals authenticatiegebeurtenissen. Maar wees voorzichtig, want wanneer de auditfilters te breed worden gemaakt, zullen de prestaties snel stikken, wat leidt tot hoge prestatiekosten. Hoewel, als auditing op de juiste manier wordt gebruikt, er niet veel prestatiekosten zullen zijn.