Hur man säkrar MySQL:Del två

I det tidigare inlägget om MySQL-säkerhet har vi täckt en rad alternativ som kan användas för att göra dina MySQL-instanser säkrare. De inkluderade:

• Allmänna MySQL-säkerhetsåtgärder;
• Kontrollera åtkomst i MySQL;
• Skapa, ändra och ta bort användare i MySQL;
• Bevilja och återkalla privilegier till och från användare i MySQL;
• Kontrollera vilka privilegier som tilldelas användare i MySQL.

I det här inlägget kommer vi att dyka in i resten av alternativen, inklusive:

• Kontokategorier i MySQL;
• Roller i MySQL;
• Reserverade konton i MySQL;
• Lösenordshantering i MySQL;
• Kontolåsning i MySQL;
• Säkerhetsplugin som erbjuds av MySQL;
• Säker MySQL-säkerhetskopior.

Tänk på att vi återigen inte kommer att täcka allt du behöver veta, men vi kommer att försöka ge bra utgångspunkter för att göra din egen forskning.

Kontokategorier i MySQL

Kontokategorier introducerades i MySQL 8 - specifikt i MySQL 8.0.16. Här är kärnan i det:

• Det finns två separata kontokategorier:vanliga användare och systemanvändare;
• En vanlig användare är en användare utan privilegiet SYSTEM_USER - en systemanvändare är en användare med privilegiet SYSTEM_USER;
• En vanlig användare kan ändra vanliga konton - en sådan användare kan inte ändra systemkonton;
• En systemanvändare kan ändra både systemkonton och vanliga konton;
• Vanliga konton kan ändras av både vanliga användare och systemanvändare;
• Systemkonton kan endast ändras av systemanvändare.

För att använda kontokategorier i MySQL säkerhetsmässigt, kom ihåg att privilegiet SYSTEM_USER påverkar saker som kontomanipulation och att döda sessioner och uttalanden inom dem - detta koncept i MySQL tillåter begränsning av vissa modifieringar till vissa konton gör MySQL säkrare. Kontokategorier kan också användas för att skydda systemkonton mot manipulation av vanliga konton:för att göra det, ge inte mysql-schemaändringsprivilegier till vanliga konton.

För att ge ett konto SYSTEM_USER-privilegier, använd följande fråga på ett skapat konto:

GRANT SYSTEM_USER ON *.* TO system_user;

Roller i MySQL

I MySQL är roller samlingar av privilegier. När du ger ett användarkonto en roll i MySQL, beviljar du alla privilegier som är kopplade till den rollen. Roller kan skapas med CREATE ROLE-satsen:

CREATE ROLE ‘role_1’, ‘role_2’;

Rollnamn består av en användardel och en värddel - användardelen kan inte vara tom och värddelen är som standard "%" om den inte anges.

När roller skapas bör du tilldela privilegier till dem. Privilegier kan tilldelas med GRANT-satsen:

• GRANTA ALLA PÅ demo_database.* TILL 'demo_user'; skulle ge alla privilegier till en användare som heter demo_user på en databas som heter demo_database;
• GIVNA INFOGA, VÄLJ, UPPDATERA, DELETE PÅ databasen.* TO ‘demo_user’; skulle ge INSERT, SELECT, UPDATE och DELETE-privilegier till en användare som heter demo_user på en databas som heter demo_database;
• GIVNA VAL PÅ demo_database.* TO ‘demo_user’; skulle ge SELECT-privilegier till en användare som heter demo_user på en databas som heter demo_database.

För att tilldela en roll till en enskild användare, använd denna syntax:
 

GRANT ‘role_name’ TO ‘user_name’@’localhost’;

För att tilldela flera roller till en enskild användare, använd denna syntax:

GRANT ‘role_1’, ‘role_2’ TO ‘user_name’@’localhost’;

För att tilldela roller till flera användare samtidigt, använd denna syntax:

GRANT ‘role_name’ TO ‘user1’@’localhost’, ‘user2’@’localhost’;

Roller kan vara till hjälp för att förhindra säkerhetsincidenter eftersom om en angripare känner till lösenordet för en inte särskilt privilegierad användare felaktigt antar att användaren är mycket "kraftig" rollmässigt, kan din applikation (och din databas) vara mycket väl räddad.

Reserverade konton i MySQL

När det gäller reserverade konton, kom ihåg att MySQL skapar konton under initieringen av datakatalogen. Det finns några konton som bör betraktas som reserverade i MySQL:

• 'root'@'localhost' - det här kontot är ett superanvändarkonto och det har gudaliknande privilegier över alla MySQL-databaser (det kan utföra vilken operation som helst över vilken MySQL-databas som helst). Det är värt att notera att root-användaren också kan byta namn för att undvika att exponera ett mycket privilegierat konto. För att byta namn på kontot, kör följande fråga:

RENAME USER ‘root’@’localhost’ TO ‘username’@’localhost’;

• Se till att utfärda ett FLUSH PRIVILEGES; uttalande efter att ha bytt namn på kontot för att ändringarna ska träda i kraft.
• ‘mysql.sys’@’localhost’ – detta konto är en systemanvändare som används som definierare för vy, procedurer och funktioner i sys-schemat. Tillagt i MySQL 5.7.9 för att undvika problem som kan uppstå om root-kontot byter namn.
• ‘mysql.session’@’localhost’ – detta konto används internt av plugins för att komma åt servern.

I det här fallet kan du inte göra så mycket säkerhetsmässigt, men kom ihåg att root-kontot har gudaliknande privilegier vilket innebär att det kan utföra vilken operation som helst över vilken MySQL-databas som helst och iaktta försiktighet när du bestämmer vem som ska ge behörighet att komma åt kontot. Tänk också på vad de andra MySQL-kontona används till.

Lösenordshantering i MySQL

MySQL stöder även funktioner för lösenordshantering. Några av dem inkluderar:

• Möjligheten att regelbundet upphöra att gälla för lösenord;
• Förmågan att undvika återanvändning av lösenord;
• Förmågan att generera lösenord;
• Möjligheten att kontrollera om lösenordet som används är starkt;
• Möjligheten att tillfälligt låsa användare ute efter för många misslyckade inloggningsförsök.

Nu ska vi titta närmare på dessa alternativ.

För att förfalla ett lösenord manuellt, använd ALTER USER-satsen så här:

ALTER USER ‘user’@’localhost’ PASSWORD EXPIRE;

För att ställa in en global policy, ändra filen my.cnf så att den innehåller parametern default_password_lifetime. Parametern kan definieras under [mysqld]-sektionen (följande exempel ställer in lösenordets livslängd till 3 månader (90 dagar)):

default_password_lifetime=90

Om du vill att lösenorden aldrig ska upphöra att gälla, ställ in parametern default_password_litetime till 0.
Du kan också ställa in lösenordsutgång för specifika användare. Om du vill ställa in intervallet för lösenordets utgång för en användare som heter demo_user, kan du använda följande exempel:

ALTER USER ‘demo_user’@’localhost’ PASSWORD EXPIRE INTERVAL 90 DAY;

Så här inaktiverar du lösenordsförfall:

ALTER USER ‘demo_user’@’localhost’ PASSWORD EXPIRE NEVER;

Så här återställer du den globala policyn för lösenordsförfall:

ALTER USER ‘demo_user’@’localhost’ PASSWORD EXPIRE DEFAULT;

Restriktioner för återanvändning av lösenord tillåter inte att lösenord återanvänds - för att använda den här funktionen, använd variablerna password_history och password_reuse_interval. Du kan antingen lägga in dessa variabler i my.cnf genom att titta på exemplet nedan eller ställa in dem vid körning genom att lägga till SET PERSIST framför satserna nedan.

För att förbjuda återanvändning av något av de 5 tidigare använda lösenorden nyare än 365 dagar, använd:

password_history=5
password_reuse_interval=365

För att kräva minst 5 lösenordsändringar innan du tillåter återanvändning:

ALTER USER ‘demo_user’@’localhost’ PASSWORD HISTORY 5;

Detsamma kan göras när du skapar en användare - ersätt ALTER USER med CREATE USER.

För att generera ett slumpmässigt lösenord när du skapar en användare, kör:

CREATE USER [email protected] IDENTIFIED BY RANDOM PASSWORD;

Så här ändrar du lösenordet för en användare till ett slumpmässigt skapat:

SET PASSWORD FOR [email protected] TO RANDOM;

Ditt slumpmässiga lösenord kommer att visas under.

Tänk på att slumpmässiga standardlösenord har en längd på 20 tecken. Längden kan styras av variabeln generated_random_password_length som har ett intervall från 5 till 255.

För att kontrollera om ett använt lösenord är starkt kan du använda variabeln VALIDATE_PASSWORD_STRENGTH - funktionen visar ett tal från 0 till 100 där 0 är det svagaste och 100 är det starkaste:
VÄLJ VALIDATE_PASSWORD_STRENGTH('lösenord');

Kontolåsning i MySQL

MySQL 8.0.19 introducerade också möjligheten att tillfälligt låsa användarkonton. Detta kan åstadkommas med hjälp av variablerna FAILED_LOGIN_ATTEMPTS och PASSWORD_LOCK_TIME.

För att aktivera kontolåsning när du skapar en användare, kör:

CREATE USER ‘demo_user’@’localhost’ IDENTIFIED BY ‘password’ FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 5;

Värdet efter FAILED_LOGIN_ATTEMPTS anger efter hur många misslyckade försök kontot är låst, värdet efter PASSWORD_LOCK_TIME anger kontolåsningstiden i dagar. Det är också möjligt att ange ett värde som inte slutar förrän kontot är upplåst genom att ange PASSWORD_LOCK_TIME som UNBOUNDED.

Säkerhetsinsticksprogram som erbjuds av MySQL

MySQL erbjuder också ett par plugins som ytterligare kan förbättra säkerhetsfunktionerna. MySQL erbjuder:

• Autentiseringsplugins;
• Insticksprogram för anslutningskontroll;
• Plugins för lösenordsvalidering;
• Revisionsplugins;
• Brandväggsplugins;

Dessa plugins kan användas för ett antal saker säkerhetsmässigt:

Autentiseringsinsticksprogram

Autentiseringsinsticksprogram kan tillåta användare att välja mellan flera pluggbara autentiseringsmetoder tillgängliga i MySQL. De kan användas tillsammans med CREATE USER- eller ALTER USER-satser. Här är ett exempel: 

CREATE USER ‘user_1’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘password’;

Denna fråga skulle implementera autentisering med hjälp av den inbyggda hashmetoden för lösenord.

Connection-Control Plugins

Insticksprogram för anslutningskontroll kan introducera en ökande fördröjning i serversvar på anslutningsförsök om anslutningsförsöken överstiger ett visst antal - de kan stoppa potentiella brute-force-attacker. Det här pluginbiblioteket introducerades till MySQL i version 5.7.17 och det kan läggas till i MySQL antingen via my.cnf eller genom att ladda plugins till servern vid körning.
För att lägga till plugins till my.cnf , lägg till följande rad under [mysqld]:

plugin-load-add=connection_control.so

När du har modifierat filen, spara dina ändringar och starta om MySQL.
För att ladda in plugins till servern vid körning, kör:

INSTALL PLUGIN CONNECTION_CONTROL SONAME ‘connection_control.so’;
INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME ‘connection_control.so’;

Justera suffixet .so vid behov. Om du har gjort allt korrekt bör tabellen CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS innehålla alla misslyckade försök att ansluta.

Plugins för lösenordsvalidering

Plugins för lösenordsvalidering kan tillåta användare att använda starkare lösenord om de används på rätt sätt. Insticksprogrammet för lösenordsvalidering kan installeras via my.cnf eller genom att ladda in plugin-programmet på servern vid körning. För att installera plugin-programmet via my.cnf, lägg till följande rad under [mysqld] och starta sedan om servern:

plugin-load-add=validate_password.so

För att ladda plugin-programmet vid körning, kör följande programsats:

INSTALL PLUGIN validate_password SONAME ‘validate_password.so’;

För att ladda plugin-programmet vid körning och förhindra att det tas bort, lägg till validate-password=FORCE_PLUS_PERMANENT till my.cnf.

För att förhindra att servern körs om plugin-programmet inte initieras, använd alternativet --validate-password med värdet FORCE eller FORCE_PLUS_PERMANENT.

Policen för lösenordsstyrka kan också ändras:för att göra det, ändra värdet för validate_password_policy till LOW, MEDIUM eller STRONG. Värdet på LOW kontrollerar endast lösenordslängden, MEDIUM-policyn lägger till vissa villkor och STRONG-policyn lägger till villkoret att lösenordsdelsträngar som består av 4 eller fler tecken inte får matcha ord i en ordboksfil som kan specificeras genom att ändra variabeln validate_password_dictionary_file.

Insticksprogram för nyckelring

Insticksprogram för nyckelring kan göra det möjligt för serverkomponenter och plugins att lagra känslig information på ett säkert sätt för hämtning. För att ladda plugin-programmet till MySQL, lägg till följande under [mysqld]:

early-plugin-load=keyring_file.so

För att ange nyckelringsvalvsfilen, lägg till följande (variabeln keyring_vault_config bör peka på konfigurationsfilen):

loose-keyring_vault_config=”/var/lib/mysql_keyring/keyring_vault.conf”

Nyckelringsfilen bör innehålla variabeln vault_url som definierar valvets serveradress, variabeln secret_mount_point som definierar monteringspunktens namn där nyckelringsvalvet lagrar nycklarna och en token som ska definieras av valvservern. Valfritt kan variabeln vault_ca också definieras (den bör peka på CA-certifikatet som används för att signera valvets certifikat).

Starta om servern för att ändringarna ska träda i kraft;

Revisionsplugins

Revisionsplugin kan möjliggöra övervakning, loggning och blockering av aktivitet som utförs på MySQL-servrar. För att installera MySQL Enterprise Audit, kör ett skript som finns i delkatalogen för din MySQL-instans (undvik att ange ditt MySQL-instanslösenord i terminalen - använd my.cnf):

mysql < /path/to/audit_log_filter_linux_install.sql

Du kan också förhindra att plugin-programmet tas bort under körning - lägg till följande i avsnittet [mysqld]:

audit_log=FORCE_PLUS_PERMANENT

Starta om servern för att tillämpa ändringarna. Observera att den regelbaserade loggningen inte loggar några granskningsbara händelser som standard, så för att få den att logga allt, skapa ett filter:

SELECT audit_log_filter_set_filter(‘log_filter’, ‘{ “filter”: { “log”: true } }’);

Tilldela det sedan till ett konto:

SELECT audit_log_filter_set_user(‘%’, ‘log_filter’);

Observera att granskningsplugin endast är tillgängliga i MySQL Enterprise Edition;

Brandväggsplugins

Brandväggsplugins kan göra det möjligt för användare att tillåta eller neka exekvering av specifika SQL-satser baserat på specifika mönster. MySQL Enterprise Firewall introducerades i MySQL 5.6.24 - den kan skydda data genom att övervaka, varna och blockera obehörig aktivitet:den kan blockera SQL-injektionsattacker, övervaka hot och blockera misstänkt trafik samt att upptäcka intrång i databasen. Brandväggen kan också logga blockerade uttalanden - de kan inspekteras och en realtidsräkning av godkända och avvisade uttalanden kan också observeras.

För att installera MySQL Enterprise Firewall, aktivera den helt enkelt när du installerar MySQL Server på Windows, den kan också installeras, inaktiveras eller avinstalleras med hjälp av MySQL Workbench 6.3.4. Brandväggen kan också installeras manuellt genom att köra ett skript i delkatalogen för din MySQL-installation. För att aktivera brandväggen, lägg till följande rad under [mysqld] och starta om servern:

mysql_firewall_mode=ON

Brandväggen kan även aktiveras vid körning:

SET GLOBAL mysql_firewall_mode = ON;

Alternativt för att bevara brandväggen (vilket innebär att brandväggen inte behöver återaktiveras vid varje efterföljande serverstart):

SET PERSIST mysql_firewall_mode = ON;

Ge sedan ett FIREWALL_ADMIN-behörighet till alla konton som administrerar brandväggen och FIREWALL_USER-behörigheten till alla konton som bara ska ha tillgång till sina egna brandväggsregler. Bevilja även EXECUTE-behörigheten för brandväggens lagrade procedurer i mysql-databasen. För att brandväggen ska fungera, registrera profiler med den, träna sedan brandväggen att känna till de tillåtna satser som databasen kan köra och efteråt berätta för brandväggen att matcha inkommande satser mot den uppsatta vitlistan. Varje profil har ett funktionsläge - AV, INSPELNING, SKYDDAR eller DETEKTERAR. OFF inaktiverar profilen, RECORDING tränar brandväggen, PROTECTING tillåter eller nekar programutförande och DETECTING upptäcker (men blockerar inte) intrångsförsök. Regler för en specificerad profil kan återställas genom att ställa in dess värde till RESET. AV kommer att inaktivera profilen. För att ställa in läget, använd följande fråga där namn är profilnamnet och AV är driftläge: 

CALL mysql.sp_set_firewall_mode(name, ‘OFF’);

Brandväggsplugin är också endast tillgänglig i MySQL Enterprise Edition.

Säkra MySQL-säkerhetskopier

När det gäller MySQL-säkerhetskopior har du ett par alternativ.

• Om du använder mysqldump kan du lagra ditt användarnamn och lösenord i my.cnf och anropa mysqldump så (följande kommando dumpar alla databaser i filen /home/backup.sql):

$ mysqldump --defaults-extra-file=/var/lib/my.cnf --single-transaction --all-databases > /home/backup.sql

• ​Genom att lagra ditt användarnamn och lösenord inuti my.cnf skriver du inte ditt lösenord inuti terminalen - en sådan metod för att ta säkerhetskopior är säkrare eftersom medan dumpen körs kan kommandot ses via ps axe kommando.

• Du kan också överväga att använda mysqldump-secure som är ett POSIX-kompatibelt wrapper-skript som kan komprimera och kryptera säkerhetskopior med stark säkerhet i åtanke .

• Säkerhetskopieringar kan krypteras med OpenSSL - ta helt enkelt din säkerhetskopia och kryptera den sedan med följande kommando:

  $ openssl enc -aes-256-cbc -salt -in backup.tar.gz -out backup.tar.gz.enc -k password

  Kommandot ovan skapar en ny krypterad fil backup.tar.gz.enc i den aktuella katalogen. Filen kommer att krypteras med det lösenord du valde (ersätt lösenordet med ditt önskade lösenord). Filen kan dekrypteras senare genom att köra följande kommando:

  $ openssl aes-256-cbc -d -in backup.tar.gz.enc -out backup.tar.gz -k password

  Ersätt lösenord med ditt lösenord.

• mysqldump har ett annat alternativ för att kryptera dina säkerhetskopior (följande exempel komprimerar dem också med gzip):

  $ mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl  enc -aes-256-cbc -k password > backup.xb.enc

  Ersätt lösenordet mot ditt önskade lösenord.

• Du kan också kryptera dina säkerhetskopior med mariabackup eller xtrabackup. Här är ett exempel från MariaDB-dokumentationen:

  $ mariabackup --user=root --backup --stream=xbstream  | openssl  enc -aes-256-cbc -k password > backup.xb.enc

  Ersätt lösenordet med ditt önskade lösenord.

• Säkerhetskopieringar kan också krypteras med ClusterControl - om krypteringsalternativet är aktiverat för en viss säkerhetskopia kommer ClusterControl att kryptera säkerhetskopian med AES-256 CBC (kryptering sker på backupnoden). Om säkerhetskopian lagras på en kontrollernod, strömmas säkerhetskopieringsfilerna i ett krypterat format med socat eller netcat. Om komprimering är aktiverad kommer ClusterControl först att komprimera säkerhetskopian, efter det - kryptera den. Krypteringsnyckeln genereras automatiskt om den inte finns och lagras sedan i CMON-konfigurationen i alternativet backup_encryption_key. Tänk på att denna nyckel är kodad och bör avkodas först. För att göra det, kör följande kommando:

  $ cat /etc/cmon.d/cmon_ClusterID.cnf | grep ^backup_encryption_key | cut -d"'" -f2 | base64 -d > keyfile.key

  Kommandot läser backup_encryption_key och avkodar dess värde till en binär utgång. Nyckelfilen kan användas för att dekryptera säkerhetskopian så här:

  $ cat backup.aes256 | openssl enc -d -aes-256-cbc -pass file:/path/to/keyfile.key > backup_file.xbstream.gz

  För fler exempel, se ClusterControl-dokumentationen.

Slutsats

I dessa inlägg om MySQL-säkerhet täckte vi några säkerhetsåtgärder som kan vara till nytta om du känner ett behov av att skärpa säkerheten för dina MySQL-instanser. Även om vi inte täckte in absolut allt, anser vi att dessa punkter kan vara en bra utgångspunkt när du ska skärpa säkerheten för din MySQL-installation. Ta vad du vill från dessa inlägg, gör din egen forskning och tillämpa de säkerhetsåtgärder som är mest tillämpliga i din situation.