Użytkownicy, uprawnienia i bezpieczeństwo SQL

Tożsamość i uprawnienia to dwa różne pytania

Uwierzytelnianie ustala, kto się łączy: np. konto i hasło, konto systemowe lub mechanizm organizacji. Autoryzacja ustala, co ta osoba albo aplikacja może zrobić. Poprawne logowanie nie oznacza prawa do każdej tabeli. Konto bazy danych nie jest automatycznie kontem klienta w tabeli uzytkownicy aplikacji.

Zasada najmniejszych uprawnień oznacza ograniczenie operacji, obiektów, źródła połączenia i czasu dostępu. Role grupują uprawnienia; nie zastępują przemyślenia ich zakresu.

MySQL / MariaDB: konto i konkretny obiekt

Poniższy przykład jest instrukcją dla administratora oddzielnej bazy ćwiczeniowej. Nie uruchamiaj go na bazie strony. Zastąp znacznik hasła własnym unikalnym hasłem; nie publikuj rzeczywistej wartości w pliku ani zrzucie.

CREATE USER 'cn_czytelnik'@'localhost'
IDENTIFIED BY '<UNIKALNE_HASLO>';

GRANT SELECT ON cn_sql_cwiczenia_2026.produkty
TO 'cn_czytelnik'@'localhost';

SHOW GRANTS FOR 'cn_czytelnik'@'localhost';

REVOKE SELECT ON cn_sql_cwiczenia_2026.produkty
FROM 'cn_czytelnik'@'localhost';

W MySQL i MariaDB tożsamość zawiera nazwę i host: 'cn_czytelnik'@'localhost' nie jest tym samym kontem co konto z innym hostem. localhost ogranicza źródło do lokalnego hosta według zasad danego serwera i sposobu połączenia; nie oznacza otwarcia usługi do internetu. GRANT nadaje wskazane prawo, REVOKE je odbiera. Nie trzeba wykonywać FLUSH PRIVILEGES po zwykłym CREATE USER/GRANT.

Odebranie jednego grantu może nie usunąć efektywnego dostępu, jeśli to samo prawo pochodzi z roli lub szerszego grantu. Sprawdzaj wszystkie źródła uprawnień i wykonuj próbę na nowym połączeniu konta docelowego.

Ten sam cel w innych środowiskach

SQL Server

Login jest zwykle tożsamością na poziomie serwera, a user reprezentuje ją w konkretnej bazie. Istnieją również użytkownicy baz zawartych, więc nie każde rozwiązanie wymaga osobnego loginu. Zakładając przygotowany przez administratora login cn_czytelnik, w bazie ćwiczeniowej:

CREATE USER cn_czytelnik FOR LOGIN cn_czytelnik;
GRANT SELECT ON OBJECT::dbo.produkty TO cn_czytelnik;
REVOKE SELECT ON OBJECT::dbo.produkty FROM cn_czytelnik;

REVOKE usuwa nadanie lub odmowę; nie jest synonimem DENY, czyli jawnej odmowy. Uprawnienia wynikają też z ról, poziomów zabezpieczeń i reguł pierwszeństwa. Nie zakładaj, że samo REVOKE dowodzi braku dostępu.

Oracle 19c

Dla już istniejącego konta ćwiczeniowego administrator lub właściciel obiektu może nadać uprawnienie obiektowe. Nazwa schematu jest istotna:

GRANT SELECT ON kurs.produkty TO cn_czytelnik;
REVOKE SELECT ON kurs.produkty FROM cn_czytelnik;

Tworzenie użytkownika i możliwość połączenia wymagają osobnej konfiguracji, zależnej m.in. od PDB i polityki organizacji. Do tych ćwiczeń nie potrzeba konta SYS ani roli DBA.

Microsoft Access

Pliki .accdb nie obsługują starego zabezpieczenia na poziomie użytkowników znanego z wybranych baz .mdb. Nie przenosimy więc powyższego GRANT jako recepty na współczesny plik Access. Stosujemy uprawnienia systemu plików, kontrolę udostępniania i odpowiednią ochronę pliku. Szyfrowanie hasłem nie tworzy osobnych uprawnień każdego użytkownika. Przy tabelach połączonych z serwerem uprawnienia do danych ustala również ten serwer.

Bezpieczna aplikacja korzystająca z SQL

• Przechowuj dane połączenia po stronie serwera, poza publicznym repozytorium i JavaScriptem przeglądarki.
• Stosuj zapytania parametryzowane. Walidacja danych jest potrzebna, ale nie zastępuje parametrów chroniących strukturę SQL.
• Przy wyświetlaniu wyniku koduj dane dla HTML. Parametry SQL nie chronią przed wstrzyknięciem HTML.
• Nie pokazuj użytkownikowi haseł, stosu błędu ani szczegółów konfiguracji. Zapisuj diagnostykę w chronionych logach.
• Do połączeń sieciowych stosuj konfigurację szyfrowania i weryfikację serwera odpowiednią dla środowiska.
• Regularnie przeglądaj konta i role; usuwaj niepotrzebny dostęp zgodnie z procedurą administratora.

Edytor kursu działa na izolowanym SQLite i nie ma kont serwerowych. Nie emuluje CREATE USER, GRANT ani REVOKE. Powyższe polecenia są przykładami do rzeczywistego, wydzielonego SZBD.

Ćwiczenia z rozwiązaniami

Zapamiętaj i sprawdź źródła

Konto określa tożsamość, grant — dozwoloną operację, a role i inne nadania wpływają na końcowy zakres dostępu. Administracja uprawnieniami należy do bazodanowej części INF.03. Składnia i model zabezpieczeń są zależne od SZBD.

MySQL 8.4: GRANT · SQL Server: REVOKE · Oracle 19c: GRANT · Access: zabezpieczenia na poziomie użytkownika