Een van de beveiligingsaspecten van het beheren van een database is om te begrijpen wie de database heeft geopend, wanneer en wat ze hebben gedaan. Hoewel we de MongoDB-service al hebben beveiligd, willen we toch weten wie wat doet en detecteren of er iets vreemds aan de hand is. Bij een onderzoek naar een datalek stelt een auditlogboek ons in staat om historische activiteiten te analyseren, te begrijpen van welk eindpunt de aanvaller afkomstig was en welke bewerkingen ze uitvoerden zodra ze zich in de database bevonden.
In deze blog zullen we controlelogboeken voor MongoDB en implementatie bekijken.
Auditregistratie inschakelen in MongoDB
Om auditregistratie in MongoDB in te schakelen, moeten we naar het mongod.conf-configuratiebestand gaan, sectie auditLog:
auditLog:
destination: file
format: BSON
path: /var/lib/mongodb/audit_mongodb.bson
Er zijn 3 soorten logboekbestemmingen, namelijk:bestand, syslog en console. Idealiter kunnen we het auditlogboek naar een bestand sturen, in JSON- of BSON-ondersteund formaat. We kunnen het auditlogboek ook inschakelen tijdens het opstarten van de MongoDB-service, zoals hieronder weergegeven:
mongod --dbpath /var/lib/mongodb --auditDestination file --auditFormat BSON --auditPath /var/lib/mongodb/audit_mongodb.bson
Auditfilter in MongoDB
Nog steeds in de auditLog sectie, is er een parameter genaamd filter. We kunnen het actiepatroon dat we willen loggen filteren. Als we bijvoorbeeld authenticatie bij een specifieke database willen loggen, kunnen we het onderstaande commando gebruiken:
auditLog:
destination: file
format: BSON
path: /var/lib/mongodb/audit_mongodb.bson
filter: '{ atype: "authenticate", "param.db": "user_profile" }'
Het zal elke authenticatie naar de user_profile database volgen. Nog een voorbeeld:we willen de acties volgen; drop index, hernoem collectie en drop collectie in user_profile database. Het commando zou zijn:
auditLog:
destination: file
format: BSON
path: /var/lib/mongodb/audit_mongodb.bson
filter: { atype: { $in: [ "dropIndex", "renameCollection", "dropCollection" ] }, "param.ns": /^user_profile\\./ } }
We kunnen ook het auditproces voor de specifieke rollen monitoren, we zouden de rollen en database in het filter moeten definiëren:
auditLog:
destination: file
format: BSON
path: /var/lib/mongodb/audit_mongodb.bson
filter: { roles: { role: "readWrite", db: "user_profile" } }
Het registreert elke actie met betrekking tot de gebruiker die de readWrite-rollen heeft in de user_profile database.
Voor auditlogging van schrijf- en leesbewerkingen moeten we eerst de auditAuthorizationSuccess inschakelen in MongoDB. We kunnen het onderstaande commando uitvoeren:
db.adminCommand( { setParameter: 1, auditAuthorizationSuccess: true } )
Of een andere optie is om het volgende in de mongod.conf te wijzigen, zoals hieronder:
auditLog:
destination: file
format: BSON
path: /var/lib/mongodb/audit_mongodb.bson
filter: { roles: { role: "readWrite", db: "user_profile" } }
setParameter: { auditAuthorizationSuccess: true }
Percona Server voor MongoDB biedt de auditregistratiefuncties gratis, terwijl het in MongoDB alleen beschikbaar is in Enterprise Edition. Houd er rekening mee dat het inschakelen van de parameter invloed heeft op de databaseprestaties van uw MongoDB, vooral in de productieomgeving.
Wat nu?
We kunnen het MongoDB-auditlogboek naar een Logging Management System sturen, bijvoorbeeld:ELK (Elasticsearch, Logstash en Kibana) stack of we kunnen het Log Management System van de provider gebruiken voor analysedoeleinden.
De eenvoudigste manier is om het hulpprogramma jq tools in de Linux-omgeving te gebruiken om het logboek in JSON- of BSON-formaat te lezen.