Kontrole bezpieczeństwa MySQL

Ta strona jest oryginalną dokumentacją PmaControl. Zachowuje praktyczną strukturę indeksu do pracy nad optymalizacją MySQL, bez kopiowania treści zewnętrznych i bez zależności od zewnętrznego produktu.

Cel

Kontrole bezpieczeństwa MySQL zmniejszają powierzchnię ataku: zbyt silne konta, nieszyfrowane połączenia, słabe hasła, zbędne uprawnienia globalne i ekspozycja sieciowa.

Kontrole priorytetowe

1. Konta anonimowe lub konta bez hasła.
2. Użytkownicy z nieuzasadnionymi SUPER, FILE, PROCESS, GRANT OPTION albo uprawnieniami globalnymi.
3. Dostęp %, gdy wystarcza konkretny host.
4. TLS niewymuszony dla wrażliwych przepływów.
5. local_infile włączone bez potrzeby.
6. Binlogi i backupy czytelne przez zbyt szerokie konta systemowe.

Podstawowy SQL

SELECT user, host, account_locked, password_expired
FROM mysql.user
ORDER BY user, host;

SHOW GRANTS FOR 'app_user'@'%';

Najważniejsze

Zasada jest prosta: każde uprawnienie musi mieć właściciela, uzasadnienie i czas życia.

Ustal zakres i zbierz dane kont

Zinwentaryzuj serwery, proxy, konta aplikacji, administratorów, repliki i narzędzia kopii. Przypisz każdemu kontu właściciela i dozwolone źródło. Poniższe kolumny dotyczą MySQL; MariaDB przechowuje dane kont inaczej zależnie od wersji. Używaj uprawnionego konta audytowego i nie eksportuj skrótów haseł ani danych dostępowych do raportów.

SELECT VERSION() AS server_version,
       CURRENT_USER() AS matched_account, USER() AS connection_identity;

SELECT user, host, plugin, account_locked, password_expired, ssl_type
FROM mysql.user
ORDER BY user, host;

SELECT grantee, privilege_type, is_grantable
FROM information_schema.user_privileges
ORDER BY grantee, privilege_type;

CURRENT_USER() wskazuje konto używane do sprawdzania uprawnień, a USER() tożsamość połączenia. Sam wykaz globalny jest niepełny: sprawdź SHOW GRANTS, uprawnienia baz i tabel, uprawnienia dynamiczne oraz role, także domyślne i aktywne. Pusty ciąg uwierzytelniania nie dowodzi braku zabezpieczeń, ponieważ wtyczki działają różnie. Oceń wtyczkę, ograniczenie hosta, blokadę i rzeczywistą politykę.

Sprawdź transport rzeczywistego połączenia

SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'require_secure_transport', 'tls_version', 'local_infile',
  'secure_file_priv', 'bind_address', 'port'
);
SHOW SESSION STATUS WHERE Variable_name IN ('Ssl_cipher', 'Ssl_version');

Pola TLS sesji opisują tylko to połączenie. Gniazdo Unix może być bezpiecznym transportem lokalnym bez szyfru TLS. Dla TCP sprawdź szyfrowanie oraz weryfikację certyfikatu i nazwy hosta w sterowniku aplikacji. Jeśli proxy kończy TLS, testuj osobno klient–proxy i proxy–serwer. Obsługa TLS przez serwer nie oznacza, że każdy klient go wymaga.

mysql --host=db.example --user=app_reader --password \
  --ssl-mode=VERIFY_IDENTITY --ssl-ca=/path/to/ca.pem

Ten przykład klienta MySQL pyta o hasło i weryfikuje tożsamość; zmień host i ścieżkę CA. Dla innych klientów sprawdź ich własne opcje. Zaplanuj rotację certyfikatów i przetestuj nowe połączenia aplikacji przed wymuszeniem polityki, aby istniejące sesje nie ukryły awarii ponownego łączenia.

Oceń ekspozycję poza uprawnieniami SQL

Stosuj minimalne uprawnienia według zadania: oddziel ruch aplikacji, migracje, monitoring i kopie. Testuj odebranie praw i ograniczenia hostów na nowych połączeniach, zachowaj pierwotne grants do wycofania i obserwuj odmowy. Aktualizuj serwer i konektory udokumentowaną ścieżką; obsługa wtyczek uwierzytelniania zależy od wersji. Każde ustalenie powinno mieć właściciela, termin naprawy i potwierdzony wynik.

Dalsza diagnostyka

• Uwzględnij ustalenia w ocenie i sprawdź gotowość przez kontrolę stanu.

Oficjalne źródła

• MySQL encrypted connections
• MySQL SHOW GRANTS