Bazy danych i SQL

Lekcja 1 · Część A

Podstawy relacyjnych baz danych

Baza danych to uporządkowany zbiór danych, a system zarządzania bazą danych (SZBD) to program, który je przechowuje, udostępnia i chroni (np. MariaDB, MySQL, PostgreSQL, SQL Server, Oracle). W modelu relacyjnym dane są zapisane w tabelach powiązanych relacjami.

Rodzaje poleceń SQL

Lekcja 2 · Część A

Typy danych i więzy integralności

Dobór typu danych wpływa na poprawność, miejsce i bezpieczeństwo. Za mały typ powoduje błędy przepełnienia, za duży marnuje miejsce i obniża wydajność.

Więzy integralności

CREATE TABLE klasy (
  id    INT UNSIGNED NOT NULL AUTO_INCREMENT,
  nazwa VARCHAR(10)  NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uq_klasy_nazwa (nazwa)
) ENGINE=InnoDB;

CREATE TABLE uczniowie (
  id        INT UNSIGNED NOT NULL AUTO_INCREMENT,
  imie      VARCHAR(50)  NOT NULL,
  nazwisko  VARCHAR(80)  NOT NULL,
  email     VARCHAR(120) NOT NULL,
  klasa_id  INT UNSIGNED NOT NULL,
  utworzono DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  UNIQUE KEY uq_uczniowie_email (email),
  CONSTRAINT fk_uczniowie_klasa FOREIGN KEY (klasa_id) REFERENCES klasy (id)
) ENGINE=InnoDB;

Lekcja 3 · Część A

Modelowanie: diagramy związków encji i rodzaje relacji

Projekt bazy zaczyna się od diagramu związków encji (ERD): ustalamy encje (obiekty, np. uczeń, klasa, przedmiot), ich atrybuty oraz relacje między nimi. Dopiero potem tworzymy tabele.

KLASY (1) ----< UCZNIOWIE (N)

UCZNIOWIE (N) >----< PRZEDMIOTY (M)
   realizowane przez tabelę łączącą OCENY:
   OCENY(id, uczen_id -> UCZNIOWIE, przedmiot_id -> PRZEDMIOTY, ocena, data)

• w tabeli łączącej klucz główny bywa złożony (uczen_id + przedmiot_id + data) lub sztuczny (id),
• nazwy tabel i kolumn powinny być spójne i opisowe,
• każdy diagram opisuje kardynalność (1, N) i obowiązkowość (czy relacja musi istnieć),
• diagram jest dokumentacją: aktualizuj go razem ze schematem.

Lekcja 4 · Część A

Normalizacja: eliminacja redundancji

Normalizacja to porządkowanie tabel tak, aby ograniczyć redundancję (powtarzanie tych samych danych) oraz anomalie: wstawiania, aktualizacji i usuwania. Kolejne postacie normalne dodają coraz ostrzejsze wymagania.

-- Przed: powtarzają się dane klienta i produktu
zamowienia(id_zam, klient, adres_klienta, produkt, cena, ilosc)

-- Po (3NF):
klienci(id_klienta, nazwa, adres)
produkty(id_produktu, nazwa, cena)
zamowienia(id_zam, id_klienta -> klienci, data)
pozycje_zamowienia(id_zam -> zamowienia, id_produktu -> produkty, ilosc)

Korzyść: adres klienta zapisany raz, więc jego zmiana to jedna aktualizacja, a usunięcie zamówienia nie niszczy danych o kliencie. Denormalizację (świadome powtórzenia) stosuje się czasem dla wydajności raportów, ale kosztem spójności i złożoności.

Lekcja 5 · Część A

Separacja danych wrażliwych i minimalizacja danych

Dane wrażliwe (PESEL, adres, dane zdrowotne, hasła) wymagają osobnej ochrony. Projekt schematu powinien oddzielić je od danych zwykłych i ograniczyć ich dostępność.

CREATE DATABASE szkola_wrazliwe;
CREATE TABLE szkola_wrazliwe.dane_osobowe (
  uczen_id INT UNSIGNED NOT NULL PRIMARY KEY,
  pesel    CHAR(11)     NOT NULL,
  adres    VARCHAR(200) NOT NULL
) ENGINE=InnoDB;

CREATE VIEW szkola.v_uczniowie AS
  SELECT id, imie, nazwisko, klasa_id FROM szkola.uczniowie;

Lekcja 6 · Część A

Transakcje, ACID, indeksowanie i audytowalność

Transakcja to zestaw operacji, które wykonują się jako jedna całość. Poprawne transakcje spełniają zasady ACID:

Klasyczny przykład: przelew. Zdjęcie kwoty z jednego konta i dopisanie na drugie musi być jedną transakcją, bo awaria po pierwszej operacji zniszczyłaby spójność danych.

Indeksowanie i partycjonowanie (pojęcia)

• indeks przyspiesza wyszukiwanie i sortowanie, ale spowalnia zapis i zajmuje miejsce,
• partycjonowanie dzieli dużą tabelę na części (np. po miesiącach), co ułatwia zarządzanie i archiwizację,
• audytowalność: możliwość ustalenia, kto, co i kiedy zmienił (kolumny audytowe, tabele historii, logi).

Lekcja 7 · Część B

Tworzenie i modyfikowanie struktur: DDL

CREATE DATABASE szkola CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE szkola;

ALTER TABLE uczniowie ADD COLUMN telefon VARCHAR(20) NULL AFTER email;
ALTER TABLE uczniowie MODIFY COLUMN telefon VARCHAR(25) NULL;
ALTER TABLE uczniowie DROP COLUMN telefon;

TRUNCATE TABLE tymczasowe;       -- usuwa wszystkie wiersze, nie da się wycofać w wielu SZBD
DROP TABLE tymczasowe;           -- usuwa tabelę wraz z danymi
DROP DATABASE IF EXISTS testowa;

Izolowane schematy i przestrzenie tabel. Osobne schematy (w MariaDB/MySQL baza danych = schemat, w PostgreSQL schematy są wewnątrz bazy) pozwalają oddzielić dane i nadać różne uprawnienia. Przestrzenie tabel (tablespaces) pozwalają umieścić dane na wybranych dyskach, np. szybkim lub szyfrowanym.

Zmiany struktury bez zakłócania działania

• wykonuj zmiany w oknie serwisowym, najpierw na kopii lub środowisku testowym,
• przed zmianą wykonaj kopię zapasową,
• dla dużych tabel używaj zmian online: ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE (MariaDB/MySQL), narzędzi do zmiany schematu bez blokad lub kolumn dodawanych jako opcjonalne,
• pamiętaj, że w MariaDB/MySQL polecenia DDL zatwierdzają transakcję domyślnie, a w PostgreSQL DDL można wycofać w transakcji,
• zmiany wprowadzaj skryptami i dokumentuj (lekcja 13).

ALTER TABLE oceny
  ADD COLUMN komentarz VARCHAR(200) NULL,
  ALGORITHM=INPLACE, LOCK=NONE;

Lekcja 8 · Część B

Indeksy i widoki

Indeksy

CREATE INDEX idx_oceny_uczen ON oceny (uczen_id);
CREATE INDEX idx_logowania_ip_czas ON logowania (adres_ip, czas);     -- indeks złożony
CREATE UNIQUE INDEX uq_uczniowie_email ON uczniowie (email);

EXPLAIN SELECT * FROM oceny WHERE uczen_id = 42;
SHOW INDEX FROM oceny;

W wyniku EXPLAIN kolumna type z wartością ALL oznacza pełne przeglądanie tabeli, a ref lub const użycie indeksu. W indeksie złożonym liczy się kolejność kolumn: indeks (adres_ip, czas) pomaga przy warunku na adres_ip, ale nie na samym czas.

• indeks pomaga przy WHERE, JOIN, ORDER BY i GROUP BY,
• nie pomaga przy kolumnach o małym zróżnicowaniu (np. płeć) ani przy funkcjach na kolumnie (WHERE YEAR(data) = 2026),
• zbędne indeksy spowalniają zapis i zajmują miejsce.

Widoki

CREATE VIEW v_oceny_uczniow AS
SELECT u.imie, u.nazwisko, p.nazwa AS przedmiot, o.ocena
FROM oceny o
JOIN uczniowie u  ON u.id = o.uczen_id
JOIN przedmioty p ON p.id = o.przedmiot_id;

SELECT * FROM v_oceny_uczniow WHERE nazwisko = 'Kowalska';

Widok upraszcza złożone zapytania i pozwala udostępnić wybrane kolumny i wiersze bez dawania dostępu do tabel źródłowych. Zwykły widok nie przyspiesza zapytań, bo jest wykonywany przy każdym użyciu.

Lekcja 9 · Część B

Klucze obce, kaskady i spójność referencyjna

Spójność referencyjna oznacza, że każdy klucz obcy wskazuje istniejący wiersz tabeli nadrzędnej. Baza nie pozwoli dodać ucznia z nieistniejącą klasą ani usunąć klasy, do której należą uczniowie (zależnie od ustawionej akcji).

ALTER TABLE oceny
  ADD CONSTRAINT fk_oceny_uczen
  FOREIGN KEY (uczen_id) REFERENCES uczniowie (id)
  ON DELETE CASCADE
  ON UPDATE RESTRICT;

Lekcja 10 · Część B

Wstawianie, zmiana i usuwanie danych z rozliczalnością

INSERT INTO uczniowie (imie, nazwisko, email, klasa_id)
VALUES ('Anna', 'Kowalska', 'anna.k@szkola.pl', 3),
       ('Jan',  'Nowak',    'jan.n@szkola.pl',   3);

UPDATE uczniowie SET klasa_id = 4 WHERE id = 17;
DELETE FROM uczniowie WHERE id = 17;

Rozliczalność i bezpieczne usuwanie

• kolumny audytowe: utworzono, zmodyfikowano, zmodyfikowal (kto),
• tabele historii lub wyzwalacze zapisujące poprzednie wartości (lekcja 27),
• usuwanie logiczne: kolumna usunieto_at zamiast kasowania wiersza, a fizyczne usunięcie według procedury (po okresie retencji),
• usuwanie zgodnie z procedurą: najpierw kopia/archiwum, potem usunięcie, potem weryfikacja, a także usunięcie z kopii zapasowych zgodnie z polityką,
• nigdy nie wpisuj haseł w jawnej postaci do tabel i logów.

ALTER TABLE uczniowie
  ADD COLUMN zmodyfikowano DATETIME NULL ON UPDATE CURRENT_TIMESTAMP,
  ADD COLUMN usunieto_at   DATETIME NULL;

UPDATE uczniowie SET usunieto_at = NOW() WHERE id = 17;
SELECT * FROM uczniowie WHERE usunieto_at IS NULL;

Lekcja 11 · Część B

Transakcje w SQL: COMMIT, ROLLBACK i punkty przywracania

START TRANSACTION;

UPDATE oceny SET ocena = ocena + 0.5
WHERE przedmiot_id = 3 AND ocena < 5.5;

SELECT COUNT(*) AS zmienione FROM oceny WHERE przedmiot_id = 3 AND ocena > 5.5;   -- kontrola

COMMIT;       -- zatwierdź, jeśli wynik zgodny z oczekiwaniem
-- ROLLBACK;  -- albo wycofaj wszystkie zmiany

START TRANSACTION;
INSERT INTO uczniowie (imie, nazwisko, email, klasa_id) VALUES ('A', 'B', 'a@b.pl', 3);
SAVEPOINT po_wstawieniu;
UPDATE uczniowie SET klasa_id = 99 WHERE email = 'a@b.pl';   -- błąd: nie ma klasy 99
ROLLBACK TO po_wstawieniu;      -- wycofuje tylko część zmian
COMMIT;

• domyślnie wiele SZBD działa w trybie autocommit: każde polecenie jest zatwierdzane od razu; transakcję zaczynasz poleceniem START TRANSACTION,
• COMMIT zatwierdza, ROLLBACK wycofuje, SAVEPOINT pozwala wycofać część zmian.

Poziomy izolacji

Przy dłuższych transakcjach rośnie ryzyko blokad i zakleszczeń (deadlock), więc transakcje powinny być krótkie.

Lekcja 12 · Część B

Maskowanie danych wrażliwych i walidacja

Maskowanie ukrywa część danych wrażliwych przy ich wyświetlaniu, np. osobom z działu pomocy. Dane w tabeli pozostają kompletne, a użytkownik widzi wersję zasłoniętą.

SELECT id,
       CONCAT(LEFT(email, 2), '***@', SUBSTRING_INDEX(email, '@', -1)) AS email_maska,
       CONCAT('*******', RIGHT(pesel, 4))                               AS pesel_maska
FROM dane;

CREATE VIEW v_wsparcie AS
SELECT id, imie, CONCAT(LEFT(email, 2), '***@', SUBSTRING_INDEX(email, '@', -1)) AS email
FROM uczniowie;
-- GRANT SELECT ON szkola.v_wsparcie TO rola_wsparcie;

Walidacja danych względem typów

• włącz tryb ścisły (STRICT_TRANS_TABLES), aby błędne wartości kończyły się błędem,
• używaj CHECK (np. ocena BETWEEN 1 AND 6), ENUM lub tabel słownikowych,
• waliduj dane także w aplikacji: baza jest ostatnią linią obrony, nie jedyną (obrona warstwowa).

Lekcja 13 · Część B

Dokumentowanie zmian i wersjonowanie schematu

Schemat bazy zmienia się razem z aplikacją. Zmiany wprowadzane ręcznie na serwerze są trudne do odtworzenia i śledzenia. Dlatego stosuje się migracje: kolejne, numerowane skrypty SQL przechowywane w repozytorium (np. Git).

migracje/
  V001__utworz_tabele_podstawowe.sql
  V002__dodaj_kolumne_telefon.sql
  V003__indeks_oceny_uczen.sql
  V004__widok_wsparcie.sql

• narzędzia takie jak Flyway i Liquibase zapamiętują w bazie, które migracje zostały wykonane (tabela historii),
• każda migracja ma skrypt „w przód” i, jeśli to możliwe, skrypt cofający,
• migracje przechodzą przegląd kodu i testy na kopii przed wdrożeniem,
• obok skryptów utrzymuj dokumentację: aktualny diagram ERD i słownik danych (opis tabel i kolumn, typy, więzy, wrażliwość danych),
• zmiany na produkcji wykonuj wyłącznie przez migracje, nigdy ręcznie.

Lekcja 14 · Część C

SELECT: wybieranie, filtrowanie i sortowanie danych

W tej części korzystamy z przykładowych tabel: uzytkownicy(id, login, rola) i logowania(id, uzytkownik_id, adres_ip, wynik, czas), gdzie wynik to „OK” lub „BLAD”.

SELECT login, rola FROM uzytkownicy WHERE rola IN ('admin', 'kadry') ORDER BY login;

SELECT DISTINCT adres_ip FROM logowania WHERE wynik = 'BLAD';

SELECT id, czas FROM logowania
WHERE czas BETWEEN '2026-10-05 00:00:00' AND '2026-10-05 23:59:59'
ORDER BY czas DESC
LIMIT 20;

SELECT login FROM uzytkownicy WHERE login LIKE 'a%';       -- zaczyna się od „a”
SELECT login FROM uzytkownicy WHERE telefon IS NULL;       -- uwaga: nie „= NULL”

Lekcja 15 · Część C

JOIN: łączenie tabel i korelowanie logów

Dane z kilku tabel łączy się klauzulą JOIN na podstawie kluczy. To podstawowe narzędzie analizy zdarzeń: np. powiązanie logów logowania z kontami użytkowników.

SELECT u.login, l.adres_ip, l.czas
FROM logowania l
JOIN uzytkownicy u ON u.id = l.uzytkownik_id
WHERE l.wynik = 'BLAD'
  AND l.czas >= NOW() - INTERVAL 1 HOUR
ORDER BY l.czas DESC;

SELECT u.login
FROM uzytkownicy u
LEFT JOIN logowania l ON l.uzytkownik_id = u.id
WHERE l.id IS NULL;

Lekcja 16 · Część C

Funkcje agregujące, GROUP BY i wykrywanie ataków brute-force

Funkcje agregujące zwracają jedną wartość dla grupy wierszy: COUNT, SUM, AVG, MIN, MAX. Z GROUP BY liczą wartości osobno dla każdej grupy.

SELECT adres_ip,
       COUNT(*)  AS proby,
       MIN(czas) AS pierwsza,
       MAX(czas) AS ostatnia
FROM logowania
WHERE wynik = 'BLAD'
  AND czas >= NOW() - INTERVAL 15 MINUTE
GROUP BY adres_ip
HAVING COUNT(*) >= 10
ORDER BY proby DESC;

Wiele błędnych prób z jednego adresu w krótkim czasie to typowy sygnał ataku brute-force. Podobnie wykrywa się anomalie statystyczne: konta z liczbą logowań wyraźnie powyżej średniej lub aktywność w nietypowych godzinach.

SELECT uzytkownik_id, COUNT(*) AS liczba
FROM logowania
WHERE czas >= NOW() - INTERVAL 1 DAY
GROUP BY uzytkownik_id
HAVING COUNT(*) > (SELECT AVG(c) + 3 * STDDEV(c)
                   FROM (SELECT COUNT(*) AS c FROM logowania
                         WHERE czas >= NOW() - INTERVAL 1 DAY
                         GROUP BY uzytkownik_id) t);

Lekcja 17 · Część C

Podzapytania i wykrywanie nieautoryzowanych powiązań

Podzapytanie to zapytanie zagnieżdżone w innym. Może zwracać jedną wartość, listę wartości lub tabelę pomocniczą. Skorelowane podzapytanie odwołuje się do wiersza zapytania zewnętrznego.

-- skalarne: konta z największą liczbą logowań
SELECT login FROM uzytkownicy
WHERE id = (SELECT uzytkownik_id FROM logowania GROUP BY uzytkownik_id ORDER BY COUNT(*) DESC LIMIT 1);

-- IN: użytkownicy z nieudanymi logowaniami
SELECT login FROM uzytkownicy
WHERE id IN (SELECT uzytkownik_id FROM logowania WHERE wynik = 'BLAD');

-- tabela pochodna w FROM
SELECT AVG(liczba) FROM (SELECT COUNT(*) AS liczba FROM logowania GROUP BY adres_ip) t;

Podzapytania świetnie nadają się do znajdowania nieautoryzowanych powiązań, np. użytkowników, którzy mają dostęp do zasobu, choć nie mają wymaganej roli:

SELECT d.uzytkownik_id
FROM dostepy d
WHERE d.zasob = 'place'
  AND NOT EXISTS (SELECT 1
                  FROM role_uzytkownikow r
                  WHERE r.uzytkownik_id = d.uzytkownik_id
                    AND r.rola = 'kadry');

Lekcja 18 · Część C

Generatywna AI i zapytania SQL: tworzenie, refaktoryzacja i weryfikacja

Narzędzia generatywnej AI potrafią napisać zapytanie SQL na podstawie opisu w języku naturalnym, zaproponować czytelniejszą wersję i wyjaśnić działanie istniejącego kodu. Wynik zawsze wymaga weryfikacji: zapytanie może wyglądać poprawnie, a zwracać błędne dane.

Dobry opis zadania dla AI

• podaj schemat (nazwy tabel, kolumn, typy, klucze), bez prawdziwych danych,
• określ dialekt SQL (MariaDB, PostgreSQL),
• opisz oczekiwany wynik i warunki (zakres czasu, progi),
• poproś o wyjaśnienie kroków, aby łatwiej sprawdzić poprawność.

Weryfikacja ręczna

-- „Usuń nieaktywnych użytkowników”
DELETE FROM uzytkownicy;                      -- brak WHERE: usunie wszystkich!

-- Poprawnie (po kontroli SELECT i w transakcji):
START TRANSACTION;
SELECT COUNT(*) FROM uzytkownicy WHERE ostatnie_logowanie < NOW() - INTERVAL 2 YEAR;
UPDATE uzytkownicy SET usunieto_at = NOW() WHERE ostatnie_logowanie < NOW() - INTERVAL 2 YEAR;
COMMIT;

Lekcja 19 · Część D

Instalacja i konfiguracja serwera bazy danych

Po instalacji SZBD (np. apt install mariadb-server w Linux, instalator MSI lub pakiet WAMP w Windows) wykonuje się wstępne zabezpieczenie i konfigurację.

sudo mariadb-secure-installation
# ustaw hasło/uwierzytelnianie root, usuń anonimowych użytkowników,
# zablokuj zdalne logowanie roota, usuń bazę „test”, przeładuj uprawnienia

[mysqld]
bind-address = 127.0.0.1        # nasłuch tylko lokalnie
port         = 3306
sql_mode     = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
local_infile = 0

CREATE USER 'app'@'10.0.20.%' IDENTIFIED BY 'LosoweDlugieHaslo!';
GRANT SELECT, INSERT, UPDATE ON szkola.* TO 'app'@'10.0.20.%';

Lekcja 20 · Część D

Przestrzeń dyskowa, wydajność i monitorowanie serwera

SELECT table_schema AS baza,
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) AS rozmiar_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY rozmiar_mb DESC;

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW FULL PROCESSLIST;                       -- aktualnie wykonywane zapytania
SHOW GLOBAL VARIABLES LIKE 'slow_query_log%';

-- w konfiguracji: logowanie wolnych zapytań
slow_query_log      = 1
long_query_time     = 1
log_queries_not_using_indexes = 1

Lekcja 21 · Część D

Kopie zapasowe baz danych

mariadb-dump --single-transaction --routines --triggers --events \
             --databases szkola > szkola_$(date +%F).sql

pg_dump -Fc szkola > szkola_$(date +%F).dump        # PostgreSQL

mariabackup --backup --target-dir=/kopie/pelna --user=kopie --password='...'
mariabackup --backup --target-dir=/kopie/inc1 --incremental-basedir=/kopie/pelna --user=kopie --password='...'
mariabackup --prepare --target-dir=/kopie/pelna

• --single-transaction daje spójną kopię tabel InnoDB bez blokowania zapisu,
• dziennik binarny (binlog) i WAL (PostgreSQL) pozwalają odtworzyć stan z konkretnej chwili (PITR),
• kopie szyfruj i chroń uprawnieniami (chmod 600), a hasło do kopii trzymaj w magazynie sekretów,
• kopie przechowuj zgodnie z zasadą 3-2-1 i testuj odtwarzanie.

Lekcja 22 · Część D

Odtwarzanie po awarii, harmonogram i monitorowanie logów

Odtwarzanie

# odtworzenie bazy z kopii
mariadb < szkola_2026-10-05.sql

# odtworzenie do chwili sprzed błędnego polecenia (PITR): kopia pełna + dziennik binarny
mariadb-binlog --start-datetime="2026-10-05 10:00:00" --stop-datetime="2026-10-05 10:29:59" \
               /var/lib/mysql/mariadb-bin.000012 | mariadb

Procedura: zatrzymaj aplikację (lub przełącz w tryb tylko do odczytu), odtwórz dane na osobnej instancji, sprawdź spójność (liczby rekordów, wybrane zapytania, CHECK TABLE), a dopiero potem przywróć ruch. Odtwarzanie ćwicz regularnie, bo nieprzetestowana kopia nie jest gwarancją.

Harmonogram zadań

# crontab -e (konto kopii)
30 1 * * *  /usr/local/bin/kopia_baz.sh
0  4 * * 0  find /kopie -name "*.sql.gz" -mtime +30 -delete

Logi i wykrywanie błędów oraz prób nadużyć

• dziennik błędów (np. /var/log/mysql/error.log) pokazuje awarie, błędy uruchamiania, zapełnienie dysku,
• komunikat Access denied for user powtarzany z jednego adresu to sygnał próby zgadywania hasła,
• regularnie rotuj i czyść logi, ale archiwizuj te potrzebne do audytu,
• wysyłaj logi do centralnego systemu (SIEM) i ustaw alerty na krytyczne błędy.

Zasada 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, jedna poza lokalizacją podstawową (lub niezmienialna kopia odłączona od sieci, ochrona przed ransomware).

Lekcja 23 · Część E

Użytkownicy, role i zasada najmniejszych uprawnień

Dostęp do bazy nadaje się przez konta i role. Zasada najmniejszych uprawnień oznacza, że każde konto ma tylko takie prawa, jakich wymaga jego zadanie, i nic więcej.

CREATE USER 'raport'@'10.0.20.%' IDENTIFIED BY '...';
GRANT SELECT ON szkola.v_oceny_uczniow TO 'raport'@'10.0.20.%';        -- tylko widok, tylko odczyt

CREATE ROLE nauczyciel;
GRANT SELECT, INSERT, UPDATE ON szkola.oceny TO nauczyciel;
GRANT SELECT ON szkola.uczniowie TO nauczyciel;
GRANT nauczyciel TO 'anna'@'%';
SET DEFAULT ROLE nauczyciel FOR 'anna'@'%';

SHOW GRANTS FOR 'anna'@'%';
REVOKE INSERT ON szkola.oceny FROM nauczyciel;
DROP USER 'anna'@'%';                                                     -- po odejściu pracownika

Lekcja 24 · Część E

Hasła, MFA i magazyny sekretów

Polityka haseł i rotacja

• silne, długie i losowe hasła dla kont serwisowych, zapisane w magazynie sekretów (nie w kodzie),
• polityka haseł: plugin sprawdzający jakość hasła (np. simple_password_check w MariaDB, validate_password w MySQL),
• rotacja haseł kont serwisowych według harmonogramu, najlepiej automatyczna,
• wygasanie haseł kont ludzkich tylko tam, gdzie wymaga tego polityka (zgodnie z aktualnymi zaleceniami nie wymusza się zbyt częstych zmian).

ALTER USER 'serwis'@'10.0.20.5' PASSWORD EXPIRE INTERVAL 90 DAY;
ALTER USER 'anna'@'%' ACCOUNT LOCK;        -- czasowa blokada konta

Sekrety dla aplikacji

Aplikacja potrzebuje hasła do bazy, ale nie powinno ono leżeć w kodzie ani w repozytorium. Dobre sposoby dostarczania sekretów:

Uwierzytelnianie wieloskładnikowe dla administratorów

Większość SZBD nie ma wbudowanego MFA dla zwykłych połączeń, dlatego stosuje się je na poziomie dostępu do serwera: administrator łączy się przez VPN lub bastion z MFA (TOTP, klucz FIDO2/U2F), a konta administracyjne można uwierzytelniać przez PAM lub SSO. Dostęp bezpośredni z internetu do portu bazy jest wykluczony.

Lekcja 25 · Część E

Integracja z LDAP/Active Directory, limity i okna czasowe

Centralne zarządzanie tożsamością (LDAP, Active Directory) pozwala zarządzać kontami w jednym miejscu: wyłączenie konta w AD blokuje dostęp do bazy, a zmiany grup przekładają się na uprawnienia.

# TYPE  DATABASE  USER  ADDRESS         METHOD
host    szkola    all   10.0.20.0/24    ldap ldapserver=ldap.szkola.local ldapprefix="uid=" ldapsuffix=",ou=ludzie,dc=szkola,dc=local" ldaptls=1

Limity sesji i konta techniczne

CREATE USER 'raport'@'10.0.20.%' IDENTIFIED BY '...'
  WITH MAX_USER_CONNECTIONS 5 MAX_QUERIES_PER_HOUR 5000;

SET GLOBAL wait_timeout = 600;           -- zamykanie bezczynnych sesji po 10 minutach

• limity (liczba połączeń, zapytań na godzinę, czas bezczynności) ograniczają skutki przejęcia konta i nadużyć,
• okna czasowe (dostęp tylko w godzinach pracy dla kont technicznych) realizuje się zwykle poza SZBD: modułem PAM (pam_time), regułami zapory lub zdarzeniami, które blokują i odblokowują konto,
• konta techniczne (kopie, raporty) powinny być osobne, z minimalnymi prawami i ograniczonym adresem.

Lekcja 26 · Część E

Szyfrowanie: w spoczynku i w ruchu

# konfiguracja
[mysqld]
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
innodb_encrypt_tables = ON
innodb_encrypt_log    = ON
ssl_ca   = /etc/mysql/tls/ca.pem
ssl_cert = /etc/mysql/tls/server-cert.pem
ssl_key  = /etc/mysql/tls/server-key.pem
tls_version = TLSv1.2,TLSv1.3

ALTER USER 'app'@'10.0.20.%' REQUIRE SSL;
SHOW STATUS LIKE 'Ssl_cipher';            -- w sesji klienta: czy połączenie jest szyfrowane

Lekcja 27 · Część E

Audyt, wyzwalacze i monitorowanie zdarzeń

[mysqld]
plugin_load_add = server_audit
server_audit_logging = ON
server_audit_events  = CONNECT,QUERY_DDL,QUERY_DCL
server_audit_file_path = /var/log/mysql/audit.log

Wyzwalacz audytowy

CREATE TABLE oceny_audyt (
  id       BIGINT AUTO_INCREMENT PRIMARY KEY,
  ocena_id INT NOT NULL,
  stara    DECIMAL(2,1),
  nowa     DECIMAL(2,1),
  zmienil  VARCHAR(100) NOT NULL,
  kiedy    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

DELIMITER //
CREATE TRIGGER trg_oceny_audyt AFTER UPDATE ON oceny
FOR EACH ROW
BEGIN
  IF OLD.ocena <> NEW.ocena THEN
    INSERT INTO oceny_audyt (ocena_id, stara, nowa, zmienil)
    VALUES (OLD.id, OLD.ocena, NEW.ocena, CURRENT_USER());
  END IF;
END//
DELIMITER ;

Nietypowe wzorce wskazujące na naruszenia

Dla zdarzeń krytycznych (awaria serwera, brak miejsca, nietypowy wzrost nieudanych logowań) skonfiguruj automatyczne alarmy: wysyłanie logów do systemu SIEM i powiadomienia e-mail lub komunikator.

Lekcja 28 · Część E

Utwardzanie serwera bazy danych

Utwardzanie bazy to systematyczne ograniczanie jej powierzchni ataku i usuwanie niebezpiecznych ustawień domyślnych.

SELECT user, host, plugin, password_expired FROM mysql.user;
SELECT user, host FROM mysql.user WHERE user = '' OR host = '%';      -- anonimowi i konta z dowolnego adresu
SHOW FULL PROCESSLIST;                                                   -- aktywne sesje
SHOW GRANTS FOR 'app'@'10.0.20.%';

[mysqld]
bind-address        = 10.0.20.10
local_infile        = 0
skip_symbolic_links = 1
secure_file_priv    = /var/lib/mysql-files
tls_version         = TLSv1.2,TLSv1.3
sql_mode            = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION

Lekcja 29 · Część F

SQL Injection: mechanizm i skutki

SQL Injection (wstrzyknięcie SQL) to atak, w którym dane wprowadzone przez użytkownika są interpretowane jako część polecenia SQL. Powstaje, gdy aplikacja buduje zapytanie przez sklejanie tekstów z danymi z formularza, adresu URL, nagłówka lub ciasteczka. Znajduje się w kategorii Injection listy OWASP Top 10.

login = request.form["login"]
haslo = request.form["haslo"]
zapytanie = "SELECT id FROM uzytkownicy WHERE login = '" + login + "' AND haslo = '" + haslo + "'"
cursor.execute(zapytanie)

# Dane wpisane w formularzu: login:  admin' --   hasło: dowolne
# Zapytanie po sklejeniu:
SELECT id FROM uzytkownicy WHERE login = 'admin' -- ' AND haslo = 'dowolne'
# „--” zaczyna komentarz: sprawdzenie hasła zostało pominięte

Skutki

• obejście logowania i uzyskanie dostępu do cudzych kont,
• odczyt całej bazy (dane osobowe, hasła, dane finansowe),
• zmiana lub usunięcie danych,
• przy nadmiernych uprawnieniach konta bazy: odczyt plików, wykonanie poleceń na serwerze, przejęcie hosta.

Lekcja 30 · Część F

Identyfikacja miejsc podatnych na wstrzykiwanie SQL

Podatności szuka się w kodzie źródłowym (przegląd kodu, analiza statyczna) i w działającej aplikacji. Wzorzec jest zawsze ten sam: dane od użytkownika trafiają do zapytania bez parametryzacji.

grep -rnE "(query|execute|exec)\(.*(\+|\$|\{)" --include=*.py --include=*.php --include=*.java .
grep -rnE "SELECT .*\$_(GET|POST|REQUEST)" --include=*.php .

W aplikacji działającej źródłem wejścia są wszystkie dane od klienta: pola formularzy, parametry URL, nagłówki HTTP (np. User-Agent), ciasteczka, treść JSON. Każde z nich trzeba traktować jako niezaufane.

Lekcja 31 · Część F

Parametryzacja zapytań (zapytania przygotowane)

Najskuteczniejszą obroną jest parametryzacja: struktura zapytania i dane są przekazywane oddzielnie. Serwer najpierw otrzymuje wzór zapytania z miejscami na parametry, a wartości traktuje wyłącznie jako dane, nigdy jako kod SQL.

$st = $pdo->prepare('SELECT id, imie FROM uzytkownicy WHERE login = :login AND aktywny = 1');
$st->execute([':login' => $login]);
$uzytkownik = $st->fetch();

cursor.execute("SELECT id FROM uzytkownicy WHERE login = %s AND aktywny = %s", (login, 1))

PreparedStatement ps = conn.prepareStatement("SELECT id FROM uzytkownicy WHERE login = ?");
ps.setString(1, login);
ResultSet rs = ps.executeQuery();

DOZWOLONE = {"nazwisko": "nazwisko", "klasa": "klasa_id", "data": "utworzono"}
kolumna = DOZWOLONE.get(request.args.get("sort"), "nazwisko")
cursor.execute(f"SELECT imie, nazwisko FROM uczniowie ORDER BY {kolumna}")   # kolumna pochodzi z naszej listy, nie od użytkownika

Lekcja 32 · Część F

Walidacja, minimalne uprawnienia i ograniczanie skutków

Parametryzacja jest podstawą, ale bezpieczna aplikacja stosuje obronę warstwową:

CREATE USER 'app_szkola'@'10.0.20.5' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE ON szkola.oceny TO 'app_szkola'@'10.0.20.5';
GRANT SELECT ON szkola.uczniowie TO 'app_szkola'@'10.0.20.5';

Lekcja 33 · Część F

Testowanie pod kątem SQL Injection i weryfikacja poprawek

Testy bezpieczeństwa sprawdzają, czy aplikacja jest odporna na wstrzykiwanie SQL. Wykonuje się je wyłącznie za zgodą właściciela i w środowisku testowym, np. na celowo podatnej aplikacji w izolowanym laboratorium.

def test_logowanie_odporne_na_sqli(baza_testowa):
    wynik = zaloguj("admin' OR '1'='1", "dowolne")
    assert wynik is None            # logowanie nie może się udać

def test_logowanie_poprawne(baza_testowa):
    assert zaloguj("anna", "PoprawneHaslo!1") is not None

Naprawa i weryfikacja

• napraw przyczynę (parametryzacja), a nie objawy (filtr znaków),
• ponów ten sam test, który wykrył lukę, i sprawdź, że już nie działa,
• dodaj test regresji i opisz zmianę w dokumentacji,
• zbadaj podobne miejsca w kodzie (ta sama luka często powtarza się w wielu zapytaniach).

Lekcja 34 · Część G

Bazy nierelacyjne: rodzaje, cechy i zastosowania

Bazy nierelacyjne (NoSQL) to systemy, które nie opierają się na tabelach z rygorystycznym schematem. Powstały, by obsługiwać duże ilości danych o zmiennej strukturze i skalować się poziomo (przez dodawanie serwerów).

Lekcja 35 · Część G

MongoDB: kolekcje, dokumenty i operacje CRUD

W MongoDB dane są zapisane w dokumentach (format BSON, odpowiednik JSON z dodatkowymi typami), pogrupowanych w kolekcje, a kolekcje w bazach. Każdy dokument ma unikalne pole _id. Pracę wykonuje się np. w konsoli mongosh.

use szkola

// Create
db.uczniowie.insertOne({ imie: "Anna", nazwisko: "Kowalska", klasa: "2A",
                         oceny: [ { przedmiot: "Sieci", ocena: 5 }, { przedmiot: "Bazy", ocena: 4 } ] })
db.uczniowie.insertMany([ { imie: "Jan", nazwisko: "Nowak", klasa: "2A" } ])

// Read
db.uczniowie.find({ klasa: "2A" }, { imie: 1, nazwisko: 1, _id: 0 })
db.uczniowie.find({ "oceny.ocena": { $gte: 5 } })
db.uczniowie.countDocuments({ klasa: "2A" })

// Update
db.uczniowie.updateOne({ imie: "Anna" }, { $set: { klasa: "3A" } })

// Delete
db.uczniowie.deleteOne({ imie: "Jan" })

Lekcja 36 · Część G

Projektowanie dokumentów, JSON/BSON i walidacja schematu

W bazach dokumentowych projekt zależy od sposobu odczytu danych. Główna decyzja to osadzanie (embedding) czy odwołania (references).

• rozmiar jednego dokumentu jest ograniczony (w MongoDB do 16 MB), więc nie osadzaj list rosnących bez końca,
• BSON rozszerza JSON o typy: data, ObjectId, Decimal128 (dokładne liczby dziesiętne), dane binarne,
• pola, po których szukasz, wymagają indeksów: db.uczniowie.createIndex({ nazwisko: 1 }).

db.createCollection("uczniowie", {
  validator: { $jsonSchema: {
    bsonType: "object",
    required: ["imie", "nazwisko", "klasa"],
    properties: {
      imie:     { bsonType: "string", maxLength: 50 },
      nazwisko: { bsonType: "string", maxLength: 80 },
      klasa:    { bsonType: "string", pattern: "^[1-5][A-Z]$" }
    }
  } },
  validationAction: "error"
})

Lekcja 37 · Część G

Bezpieczeństwo baz nierelacyjnych

Wiele wycieków danych dotyczyło baz NoSQL wystawionych do internetu bez uwierzytelniania. Starsze instalacje i niektóre domyślne konfiguracje nie wymuszały haseł, więc każdy, kto znalazł otwarty port, miał pełny dostęp.

net:
  port: 27017
  bindIp: 127.0.0.1
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/tls/server.pem
security:
  authorization: enabled

use szkola
db.createUser({
  user: "app_szkola",
  pwd: passwordPrompt(),
  roles: [ { role: "readWrite", db: "szkola" } ]
})

Wstrzykiwanie w bazach NoSQL

NoSQL injection polega na przekazaniu w danych wejściowych operatorów zapytania, które zmieniają jego sens. Gdy aplikacja wstawia do zapytania obiekt z żądania bez sprawdzenia typu, atakujący może przesłać zamiast hasła obiekt z operatorem.

// aplikacja: db.uzytkownicy.findOne({ login: req.body.login, haslo: req.body.haslo })

// dane w żądaniu:  { "login": "admin", "haslo": { "$ne": null } }
// powstaje warunek: haslo różne od null, czyli prawdziwy dla każdego konta

• waliduj typy: login i hasło muszą być tekstem, a nie obiektem,
• nie przechowuj haseł w jawnej postaci (skrót z solą), więc porównuje się je w aplikacji, a nie w zapytaniu,
• unikaj operatorów wykonujących kod ($where, JavaScript po stronie serwera),
• używaj bibliotek mapujących i walidujących dane wejściowe.

Lekcja 38 · Część G

Migracja i integracja SQL z NoSQL oraz dobór technologii

Dane często trzeba przenieść z bazy relacyjnej do dokumentowej (lub połączyć obie). Narzędzia AI mogą zaproponować mapowanie schematu, skrypt migracji i przykładowe zapytania, ale wynik wymaga dokładnej kontroli.

-- 1. eksport z SQL do JSON (np. przez zapytanie JSON_OBJECT lub skrypt w Pythonie)
-- 2. walidacja: liczba rekordów w tabeli = liczba dokumentów w kolekcji
-- 3. import do MongoDB: mongoimport --db szkola --collection uczniowie --file uczniowie.json --jsonArray
-- 4. porównanie wyników zapytań w obu systemach na próbce

Dobór technologii do wymagań