Auditing is het bewaken en vastleggen van geselecteerde acties in de gebruikersdatabase. Het wordt meestal gebruikt om verdachte activiteiten te onderzoeken of om gegevens over specifieke database-activiteiten te controleren en te verzamelen. De databasebeheerder kan bijvoorbeeld statistieken verzamelen over welke tabellen worden bijgewerkt, hoeveel bewerkingen worden uitgevoerd of hoeveel gelijktijdige gebruikers op bepaalde tijden verbinding maken.
In deze blogpost gaan we de fundamentele aspecten behandelen van het controleren van onze open-source databasesystemen, met name MySQL, MariaDB, PostgreSQL en MongoDB. Dit artikel is bedoeld voor DevOps-technici die doorgaans minder ervaring of bekendheid hebben met best-practice op het gebied van auditcompliance en goed gegevensbeheer bij het beheer van de infrastructuur, voornamelijk voor de databasesystemen.
Verklaring controleren
MySQL-verklaring controle
MySQL heeft het algemene querylogboek (of general_log), dat in feite registreert wat mysqld doet. De server schrijft informatie naar dit logboek wanneer clients verbinding maken of verbreken, en registreert elke SQL-instructie die van clients wordt ontvangen. Het algemene querylogboek kan erg handig zijn bij het oplossen van problemen, maar is niet echt gebouwd voor continue controle. Het heeft een grote impact op de prestaties en zou alleen moeten worden ingeschakeld tijdens korte tijdvakken. Er zijn andere opties om in plaats daarvan performance_schema.events_statements* tabellen of Audit Plugin te gebruiken.
Controle van PostgreSQL-verklaring
Voor PostgreSQL kunt u de log_statment op "alles" zetten. Ondersteunde waarden voor deze parameter zijn geen (uit), ddl, mod en alle (alle instructies). Voor "ddl" worden alle gegevensdefinitie-instructies vastgelegd, zoals CREATE-, ALTER- en DROP-instructies. Voor "mod" logt het alle DDL-statements, plus data-modificerende statements zoals INSERT, UPDATE, DELETE, TRUNCATE en COPY FROM.
U moet waarschijnlijk de gerelateerde parameters configureren, zoals log_directory, log_filename, logging_collector en log_rotation_age, zoals weergegeven in het volgende voorbeeld:
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes De bovenstaande wijzigingen vereisen een herstart van PostgreSQL, dus plan deze zorgvuldig voordat u deze toepast op uw productieomgeving. Je kunt dan de huidige logs vinden onder de pg_log directory. Voor PostgreSQL 12 is de locatie /var/lib/pgsql/12/data/pg_log/ . Houd er rekening mee dat de logbestanden de neiging hebben om in de loop van de tijd veel te groeien en de schijfruimte aanzienlijk kunnen opslokken. U kunt in plaats daarvan ook log_rotation_size gebruiken als u beperkte opslagruimte heeft.
MongoDB-verklaringscontrole
Voor MongoDB zijn er 3 logboekniveaus die ons kunnen helpen de verklaringen te controleren (bewerkingen of ops in MongoDB-term):
-
Niveau 0 - Dit is het standaard profiler-niveau waar de profiler geen gegevens verzamelt. De mongod schrijft altijd bewerkingen die langer zijn dan de slowOpThresholdMs-drempel naar zijn logboek.
-
Niveau 1 - Verzamelt profileringsgegevens alleen voor langzame bewerkingen. Standaard zijn langzame bewerkingen die langzamer dan 100 milliseconden. U kunt de drempel voor "trage" bewerkingen wijzigen met de runtime-optie slowOpThresholdMs of de opdracht setParameter.
-
Niveau 2 - Verzamelt profileringsgegevens voor alle databasebewerkingen.
Om alle bewerkingen te loggen, stelt u db.setProfilingLevel(2, 1000) in, waar het alle bewerkingen moet profileren met bewerkingen die langer duren dan de gedefinieerde milliseconden, in dit geval is dit 1 seconde (1000 ms) . De zoekopdracht die in de systeemprofielverzameling moet worden gezocht voor alle zoekopdrachten die langer dan een seconde duurden, gerangschikt op aflopend tijdstempel, is. Om de bewerkingen te lezen, kunnen we de volgende query gebruiken:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Er is ook een Mongotail-project, dat het proces voor het profileren van bewerkingen vereenvoudigt met een externe tool in plaats van rechtstreeks naar de profielverzameling te zoeken.
Houd er rekening mee dat het niet wordt aanbevolen om volledige verklaringscontrole uit te voeren op de productiedatabaseservers, omdat dit gewoonlijk een aanzienlijke impact heeft op de databaseservice met een enorme hoeveelheid logboekregistratie. De aanbevolen manier is om in plaats daarvan een plug-in voor database-audits te gebruiken (zoals verderop weergegeven), die een standaardmanier biedt voor het produceren van auditlogboeken die vaak nodig zijn om te voldoen aan overheids-, financiële of ISO-certificeringen.
Privilege Auditing voor MySQL, MariaDB en PostgreSQL
Privilege auditing controleert de privileges en toegangscontrole tot de database-objecten. Toegangscontrole zorgt ervoor dat de gebruikers die toegang hebben tot de database positief worden geïdentificeerd en de gegevens waar ze recht op hebben kunnen inzien, bijwerken of verwijderen. Dit gebied wordt vaak over het hoofd gezien door de DevOps-engineer, waardoor te veel privileges een veelvoorkomende fout zijn bij het maken en toekennen van een databasegebruiker.
Voorbeelden van overbevoorrechte personen zijn:
-
Toegangshosts van gebruikers zijn toegestaan uit een zeer breed bereik, bijvoorbeeld door gebruikershost [email protected] toe te kennen' %', in plaats van een individueel IP-adres.
-
Beheerdersrechten worden toegewezen aan niet-beheerdersdatabasegebruikers, bijvoorbeeld een databasegebruiker voor toepassing wordt toegewezen met SUPER of RELOAD privilege.
-
Gebrek aan resourcecontrole tegen elke vorm van overmatig gebruik, zoals Max. gebruikersverbindingen, Max. zoekopdrachten per uur of Max. Verbindingen per uur.
-
Sta specifieke databasegebruikers ook toe om andere schema's te openen.
Voor MySQL, MariaDB en PostgreSQL kunt u bevoegdhedencontrole uitvoeren via het informatieschema door de tabellen met betrekking tot toekenningen, rollen en bevoegdheden op te vragen. Gebruik voor MongoDB de volgende query (vereist viewUser-actie voor andere databases):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl geeft een mooi overzicht van de privileges die aan een databasegebruiker zijn toegewezen. Ga naar Beheren -> Schema's en gebruikers -> Gebruikers en je krijgt een rapport van de gebruikersrechten, samen met de geavanceerde opties zoals SSL vereist, Max. aantal verbindingen per uur enzovoort.
ClusterControl ondersteunt de controle van bevoegdheden voor MySQL, MariaDB en PostgreSQL onder dezelfde gebruiker koppel.
Schema Object Auditing
Schema-objecten zijn logische structuren die door gebruikers zijn gemaakt. Voorbeelden van schema-objecten zijn tabellen, indexen, views, routines, gebeurtenissen, procedures, functies, triggers en andere. Het zijn in feite objecten die gegevens bevatten of alleen uit een definitie kunnen bestaan. Gewoonlijk zou men de machtigingen controleren die zijn gekoppeld aan de schemaobjecten om slechte beveiligingsinstellingen te detecteren en de relatie en afhankelijkheden tussen objecten te begrijpen.
Voor MySQL en MariaDB zijn er information_schema en performance_schema die we kunnen gebruiken om de schema-objecten in principe te controleren. Performance_schema is een beetje diepte in de instrumentatie, zoals de naam al doet vermoeden. MySQL bevat echter ook een sys-schema sinds versie 5.7.7, een gebruiksvriendelijke versie van performance_schema. Al deze databases zijn direct toegankelijk en opvraagbaar door de klanten.
Database Audit Plugins/Extensies
De meest aanbevolen manier om verklaringscontrole uit te voeren, is door een controleplug-in of extensie te gebruiken, speciaal gebouwd voor de gebruikte databasetechnologie. MariaDB en Percona hebben hun eigen Audit-plug-in-implementatie, die een beetje verschilt van de Audit-plug-in van MySQL die beschikbaar is in MySQL Enterprise. Auditrecords bevatten informatie over de bewerking die is gecontroleerd, de gebruiker die de bewerking uitvoert en de datum en tijd van de bewerking. De records kunnen worden opgeslagen in een datadictionary-tabel, de database-audittrail genoemd, of in besturingssysteembestanden, een audittrail van het besturingssysteem.
Voor PostgreSQL is er pgAudit, een PostgreSQL-extensie die gedetailleerde sessie- en/of object-auditregistratie biedt via de standaard PostgreSQL-registratiefaciliteit. Het is in feite een verbeterde versie van PostgreSQL's log_statement-functie met de mogelijkheid om gemakkelijk de vastgelegde gegevens voor controle te zoeken en op te zoeken door het standaard auditlogboek te volgen.
MongoDB Enterprise (betaald) en Percona Server voor MongoDB (gratis) bevatten een auditfunctie voor mongod- en mongos-instanties. Als auditing is ingeschakeld, genereert de server auditberichten die kunnen worden aangemeld bij syslog, console of bestand (JSON- of BSON-indeling). In de meeste gevallen verdient het de voorkeur om in BSON-indeling bij het bestand in te loggen, waar de impact op de prestaties kleiner is dan bij JSON. Dit bestand bevat informatie over verschillende gebruikersgebeurtenissen, waaronder authenticatie, autorisatiefouten, enzovoort. Bekijk de controledocumentatie voor details.
Controlesporen voor besturingssysteem
Het is ook belangrijk om de controlesporen van het besturingssysteem te configureren. Voor Linux zouden mensen vaak auditd gebruiken. Auditd is de gebruikersruimtecomponent van het Linux Auditing System en is verantwoordelijk voor het schrijven van auditrecords naar de schijf. Het bekijken van de logboeken gebeurt met de hulpprogramma's ausearch of aureport. Het configureren van de auditregels wordt gedaan met het auditctl-hulpprogramma of door de regelbestanden rechtstreeks te wijzigen.
De volgende installatiestappen zijn onze gebruikelijke praktijk bij het opzetten van servers voor productiegebruik:
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartMerk op dat de laatste regel service auditd herstart verplicht is omdat audit niet echt goed werkt bij het laden van regels met systemd. Systemd is echter nog steeds vereist om de auditd-service te controleren. Tijdens het opstarten worden de regels in /etc/audit/audit.rules gelezen door auditctl. De audit-daemon zelf heeft enkele configuratie-opties die de beheerder mogelijk wil aanpassen. Ze zijn te vinden in het bestand auditd.conf.
De volgende regel is een uitvoer uit een geconfigureerd auditlogboek:
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Zoals je hierboven kunt zien, is het gemakkelijk om een wachtwoord in leesbare tekst voor MySQL ("--password=S3cr3tPassw0rdKP") te vinden met behulp van het ausearch-hulpprogramma zoals vastgelegd door de auditd. Dit soort detectie en controle is essentieel om onze database-infrastructuur te beveiligen, waar een wachtwoord in leesbare tekst onaanvaardbaar is in een beveiligde omgeving.
Laatste gedachten
Auditlogboek of -spoor is een essentieel aspect dat vaak over het hoofd wordt gezien door DevOps-technici bij het beheren van infrastructuren en systemen, laat staan het databasesysteem, dat een zeer kritisch systeem is om gevoelige en vertrouwelijke gegevens op te slaan. Elke blootstelling aan of inbreuk op uw privégegevens kan zeer schadelijk zijn voor het bedrijf en niemand zou willen dat dit gebeurt in het huidige informatietechnologietijdperk.