Revision er overvågning og registrering af udvalgte brugerdatabasehandlinger. Det bruges typisk til at undersøge mistænkelig aktivitet eller overvåge og indsamle data om specifikke databaseaktiviteter. For eksempel kan databaseadministratoren samle statistik om, hvilke tabeller der opdateres, hvor mange handlinger der udføres, eller hvor mange samtidige brugere der forbinder på bestemte tidspunkter.
I dette blogindlæg vil vi dække de grundlæggende aspekter af revision af vores open source-databasesystemer, især MySQL, MariaDB, PostgreSQL og MongoDB. Denne artikel er rettet mod DevOps-ingeniører, som almindeligvis har mindre erfaring eller eksponering i bedste praksis for overholdelse af revision og god datastyring, når de administrerer infrastrukturen primært til databasesystemerne.
Revision af erklæringer
MySQL-erklæringsrevision
MySQL har den generelle forespørgselslog (eller general_log), som grundlæggende registrerer, hvad mysqld laver. Serveren skriver information til denne log, når klienter opretter forbindelse eller afbryder, og den logger hver SQL-sætning, der modtages fra klienter. Den generelle forespørgselslog kan være meget nyttig ved fejlfinding, men ikke rigtig bygget til kontinuerlig revision. Det har en stor ydeevnepåvirkning og bør kun aktiveres i korte tidsintervaller. Der er andre muligheder for at bruge performance_schema.events_statements* tabeller eller Audit Plugin i stedet.
PostgreSQL-erklæringsrevision
For PostgreSQL kan du aktivere log_statment til "alle". Understøttede værdier for denne parameter er ingen (fra), ddl, mod og alle (alle sætninger). For "ddl" logger den alle datadefinitionssætninger, såsom CREATE-, ALTER- og DROP-sætninger. For "mod" logger den alle DDL-sætninger plus datamodificerende sætninger såsom INSERT, UPDATE, DELETE, TRUNCATE og COPY FROM.
Du skal sandsynligvis konfigurere de relaterede parametre som log_directory, log_filename, logging_collector og log_rotation_age, som vist i følgende eksempel:
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 Ovenstående ændringer kræver en PostgreSQL-genstart, så planlæg venligst omhyggeligt, før du anvender dit produktionsmiljø. Du kan derefter finde de aktuelle logfiler under pg_log-mappen. For PostgreSQL 12 er placeringen på /var/lib/pgsql/12/data/pg_log/ . Bemærk, at logfilerne har en tendens til at vokse meget over tid og kan tære betydeligt på diskpladsen. Du kan også bruge log_rotation_size i stedet, hvis du har begrænset lagerplads.
MongoDB Statement Auditing
For MongoDB er der 3 logningsniveauer, der kan hjælpe os med at revidere erklæringerne (operationer eller operationer i MongoDB-term):
-
Niveau 0 - Dette er standardprofileringsniveauet, hvor profileren ikke indsamler nogen data. Mongoden skriver altid operationer længere end slowOpThresholdMs-tærsklen til sin log.
-
Niveau 1 - Indsamler kun profileringsdata til langsomme operationer. Som standard er langsomme operationer dem, der er langsommere end 100 millisekunder. Du kan ændre tærsklen for "langsomme" operationer med slowOpThresholdMs runtime-indstillingen eller setParameter-kommandoen.
-
Niveau 2 - Indsamler profileringsdata for alle databaseoperationer.
For at logge alle operationer skal du indstille db.setProfilingLevel(2, 1000), hvor det skal profilere alle operationer med operationer, der tager længere tid end de definerede millisekunder, i dette tilfælde er 1 sekund (1000 ms) . Forespørgslen, der skal søges i systemprofilsamlingen for alle forespørgsler, der tog længere tid end et sekund, sorteret efter faldende tidsstempel, vil være. For at læse operationerne kan vi bruge følgende forespørgsel:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Der er også Mongotail-projektet, som forenkler operationsprofileringsprocessen med et eksternt værktøj i stedet for at forespørge direkte til profilsamlingen.
Husk på, at det ikke anbefales at køre fuld erklæringsrevision i produktionsdatabaseserverne, fordi det almindeligvis introducerer en betydelig indvirkning på databasetjenesten med en enorm mængde logning. Den anbefalede måde er at bruge et databaserevisionsplugin i stedet (som vist længere nede), som giver en standardmetode til fremstilling af revisionslogfiler, der ofte kræves for at overholde offentlige, finansielle eller ISO-certificeringer.
Privilege Auditing for MySQL, MariaDB og PostgreSQL
Privilege revision reviderer privilegier og adgangskontrol til databaseobjekterne. Adgangskontrol sikrer, at brugerne, der får adgang til databasen, er positivt identificeret og kan få adgang til, opdatere eller slette de data, de har ret til. Dette område bliver almindeligvis overset af DevOps-ingeniøren, hvilket gør overprivilegering til en almindelig fejl, når der oprettes og tildeles en databasebruger.
Eksempler på overprivilegerede er:
-
Brugernes adgangsværter er tilladt fra en meget bred vifte, f.eks. at give brugervært [email protected]' %', i stedet for en individuel IP-adresse.
-
Administrative rettigheder bliver tildelt til ikke-administrative databasebrugere, f.eks. tildeles en databasebruger til applikationen med SUPER eller RELOAD privilegium.
-
Manglende ressourcekontrol mod enhver form for overdreven brug såsom Max User Connections, Max Queries Per Hour eller Max Forbindelser pr. time.
-
Giv også specifikke databasebrugere adgang til andre skemaer.
For MySQL, MariaDB og PostgreSQL kan du udføre privilegie-revision via informationsskemaet ved at forespørge på tildelings-, rolle- og privilegierelaterede tabeller. For MongoDB, brug følgende forespørgsel (kræver viewUser handling for andre databaser):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl giver en flot oversigt over de privilegier, der er tildelt en databasebruger. Gå til Administrer -> Skemaer og brugere -> Brugere, og du vil få en rapport over brugernes privilegier sammen med de avancerede muligheder som Kræver SSL, Maks. forbindelser pr. time og så videre.
ClusterControl understøtter privilegerevision for MySQL, MariaDB og PostgreSQL under samme bruger interface.
Skemaobjektrevision
Skemaobjekter er logiske strukturer skabt af brugere. Eksempler på skemaobjekter er tabeller, indekser, visninger, rutiner, hændelser, procedurer, funktioner, triggere og andre. Det er dybest set objekter, der indeholder data eller kun kan bestå af en definition. Normalt vil man revidere tilladelserne forbundet med skemaobjekterne for at opdage dårlige sikkerhedsindstillinger og forstå relationen og afhængighederne mellem objekter.
For MySQL og MariaDB er der informationsskema og performance_schema, som vi grundlæggende kan bruge til at revidere skemaobjekterne. Performance_schema er en smule dybde i instrumenteringen, som navnet antyder. MySQL indeholder dog også et sys-skema siden version 5.7.7, som er en brugervenlig version af performance_schema. Alle disse databaser er direkte tilgængelige og kan forespørges på af klienterne.
Databaserevision plugins/udvidelser
Den mest anbefalede måde at udføre erklæringsrevision på er ved at bruge et revisionsplugin eller en udvidelse, der er specielt bygget til den anvendte databaseteknologi. MariaDB og Percona har deres egen Audit-plugin-implementering, som er en smule anderledes end MySQL's Audit-plugin tilgængelig i MySQL Enterprise. Revisionsregistreringer omfatter oplysninger om den handling, der blev revideret, brugeren, der udfører handlingen, og dato og klokkeslæt for handlingen. Posterne kan lagres i enten en dataordbogstabel, kaldet databaserevisionssporet, eller i operativsystemfiler, kaldet et operativsystemrevisionsspor.
For PostgreSQL er der pgAudit, en PostgreSQL-udvidelse, der giver detaljeret sessions- og/eller objektauditlogning via standard PostgreSQL-logningsfaciliteten. Det er dybest set en forbedret version af PostgreSQL's log_statement-funktion med mulighed for nemt at søge og slå op i de opsamlede data til revision ved at følge standard revisionslog.
MongoDB Enterprise (betalt) og Percona Server til MongoDB (gratis) inkluderer en revisionsfunktion til mongod- og mongos-instanser. Med revision aktiveret vil serveren generere revisionsmeddelelser, som kan logges ind på syslog, konsol eller fil (JSON- eller BSON-format). I de fleste tilfælde er det at foretrække at logge på filen i BSON-format, hvor ydeevnepåvirkningen er mindre end JSON. Denne fil indeholder oplysninger om forskellige brugerhændelser, herunder godkendelse, godkendelsesfejl og så videre. Se revisionsdokumentationen for detaljer.
Overvågningsspor til operativsystemet
Det er også vigtigt at konfigurere operativsystemets revisionsspor. Til Linux ville folk almindeligvis bruge auditd. Auditd er brugerpladskomponenten i Linux Auditing System og ansvarlig for at skrive revisionsposter til disken. Visning af loggene udføres med ausearch- eller aureport-værktøjerne. Konfiguration af revisionsreglerne udføres med værktøjet auditctl eller ved at ændre regelfilerne direkte.
Følgende installationstrin er vores almindelige praksis ved opsætning af enhver form for servere til produktionsbrug:
$ 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 restartBemærk, at den sidste linje-tjeneste, auditd genstart er obligatorisk, fordi revision ikke fungerer rigtig godt, når regler indlæses med systemd. Systemd er dog stadig påkrævet for at overvåge den reviderede tjeneste. Under opstart læses reglerne i /etc/audit/audit.rules af auditctl. Selve revisionsdæmonen har nogle konfigurationsmuligheder, som administratoren måtte ønske at tilpasse. De findes i filen auditd.conf.
Følgende linje er et output taget fra en konfigureret revisionslog:
$ 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=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Som du kan se fra ovenstående, er det nemt at finde en klartekst-adgangskode til MySQL ("--password=S3cr3tPassw0rdKP") ved at bruge ausearch-værktøjet som fanget af auditd. Denne form for opdagelse og revision er afgørende for at sikre vores databaseinfrastruktur, hvor en klartekstadgangskode er uacceptabel i et sikkert miljø.
Sidste tanker
Revisionslog eller -spor er et vigtigt aspekt, som almindeligvis overses af DevOps-ingeniører, når de administrerer infrastrukturer og systemer, endsige databasesystemet, som er et meget kritisk system til at gemme følsomme og fortrolige data. Enhver eksponering eller brud på dine private data kan være ekstremt skadelige for virksomheden, og ingen ville ønske, at det skulle ske i den nuværende informationsteknologiske æra.