Bezpieczeństwo SQL Server — szyfrowanie, audyt i ochrona danych

Dlaczego bezpieczeństwo SQL Server jest krytyczne?

Baza danych to serce każdej aplikacji biznesowej — przechowuje dane klientów, transakcje finansowe, dane osobowe i tajemnice handlowe. Naruszenie bezpieczeństwa SQL Server może oznaczać:

• Kary RODO — do 20 mln EUR lub 4% rocznego obrotu
• Utratę reputacji — klienci tracą zaufanie po wycieku danych
• Straty finansowe — średni koszt naruszenia danych w Europie to ponad 4 mln EUR (IBM, 2025)
• Odpowiedzialność prawna — dyrektywa NIS2 nakłada osobistą odpowiedzialność na zarząd

SQL Server 2022 oferuje najszerszy zestaw mechanizmów bezpieczeństwa wśród relacyjnych baz danych — ale trzeba je prawidłowo skonfigurować.

TDE (Transparent Data Encryption) — szyfrowanie bazy danych

TDE szyfruje całą bazę danych na poziomie plików (.mdf, .ldf). Dane na dysku są zaszyfrowane, ale aplikacja widzi je jako niezaszyfrowane — szyfrowanie/deszyfrowanie odbywa się transparentnie (stąd nazwa).

Co chroni TDE?

• Kradzież dysku twardego lub kopii zapasowej
• Nieautoryzowany dostęp do plików bazy danych
• Kopiowanie plików .mdf/.ldf na inny serwer

Czego TDE nie chroni?

• Danych w pamięci (RAM) — gdy baza jest uruchomiona, dane w pamięci są odszyfrowane
• Danych przesyłanych przez sieć — do tego potrzebne jest szyfrowanie SSL/TLS
• Dostępu przez autoryzowanych użytkowników — TDE nie zastępuje kontroli uprawnień

Jak włączyć TDE w SQL Server 2022

-- 1. Utwórz klucz główny bazy master
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'SilneHaslo123!';

-- 2. Utwórz certyfikat szyfrowania
CREATE CERTIFICATE TDE_Cert WITH SUBJECT = 'Certyfikat TDE';

-- 3. Przejdź do docelowej bazy danych
USE MojaBaza;

-- 4. Utwórz klucz szyfrowania bazy danych
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDE_Cert;

-- 5. Włącz szyfrowanie
ALTER DATABASE MojaBaza SET ENCRYPTION ON;

-- WAŻNE: Zrób backup certyfikatu!
BACKUP CERTIFICATE TDE_Cert TO FILE = 'C:BackupTDE_Cert.cer'
WITH PRIVATE KEY (FILE = 'C:BackupTDE_Cert.pvk',
ENCRYPTION BY PASSWORD = 'HasloDoKlucza456!');

⚠️ Krytyczne: Zawsze rób backup certyfikatu TDE i klucza prywatnego! Bez nich nie odzyskasz bazy danych z zaszyfrowanej kopii zapasowej — nawet na tym samym serwerze po reinstalacji.

Always Encrypted — szyfrowanie kolumn wrażliwych danych

Always Encrypted szyfruje konkretne kolumny (np. numery PESEL, karty kredytowe, dane medyczne) tak, że nawet administrator bazy danych nie może ich odczytać. Klucze szyfrowania są przechowywane po stronie aplikacji, nie serwera.

Kiedy używać Always Encrypted?

• Numery PESEL, NIP, dowodu osobistego
• Numery kart kredytowych (PCI DSS compliance)
• Dane medyczne (HIPAA compliance)
• Wynagrodzenia i dane finansowe pracowników
• Wszelkie dane, do których administrator DB nie powinien mieć dostępu

Always Encrypted vs TDE — różnice

Audyt SQL Server — śledzenie dostępu do danych

Audyt pozwala rejestrować, kto i kiedy uzyskał dostęp do danych, jakie zapytania wykonał i czy próbował nieautoryzowanego dostępu. Jest wymagany przez RODO (art. 30 — rejestr czynności przetwarzania) i NIS2.

Jak skonfigurować SQL Server Audit

-- 1. Utwórz specyfikację audytu serwera
CREATE SERVER AUDIT MojAudyt
TO FILE (FILEPATH = 'C:SQLAudit', MAXSIZE = 100 MB)
WITH (ON_FAILURE = CONTINUE);

-- 2. Włącz audyt
ALTER SERVER AUDIT MojAudyt WITH (STATE = ON);

-- 3. Utwórz specyfikację audytu bazy danych
USE MojaBaza;
CREATE DATABASE AUDIT SPECIFICATION AudytDanych
FOR SERVER AUDIT MojAudyt
ADD (SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo BY public);

-- 4. Włącz specyfikację
ALTER DATABASE AUDIT SPECIFICATION AudytDanych WITH (STATE = ON);

Co warto audytować?

• Logowania — udane i nieudane próby (wykrywanie ataków brute-force)
• Dostęp do danych osobowych — SELECT na tabelach z danymi klientów
• Zmiany struktury — ALTER TABLE, DROP TABLE, CREATE LOGIN
• Eskalacja uprawnień — GRANT, REVOKE, ALTER ROLE
• Zmiany konfiguracji — sp_configure, zmiany ustawień serwera

Row-Level Security (RLS) — kontrola dostępu na poziomie wierszy

RLS pozwala ograniczyć, które wiersze w tabeli widzi dany użytkownik. Na przykład: handlowiec widzi tylko swoich klientów, kierownik widzi klientów swojego zespołu, a dyrektor — wszystkich.

Przykład implementacji RLS

-- 1. Utwórz funkcję filtrującą
CREATE FUNCTION dbo.fn_SecurityPredicate(@SalesRep AS nvarchar(50))
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'admin';

-- 2. Zastosuj politykę bezpieczeństwa
CREATE SECURITY POLICY dbo.KlienciPolicy
ADD FILTER PREDICATE dbo.fn_SecurityPredicate(SalesRep)
ON dbo.Klienci WITH (STATE = ON);

RLS działa transparentnie — aplikacja nie wymaga zmian. Zapytanie SELECT * FROM Klienci automatycznie zwraca tylko wiersze, do których użytkownik ma dostęp.

Backup i odzyskiwanie po awarii

Bezpieczeństwo to nie tylko ochrona przed atakami — to też ochrona przed utratą danych. SQL Server oferuje kilka strategii backupu:

Typy backupu SQL Server

Zalecany harmonogram backupu

-- Pełny backup codziennie o 2:00
BACKUP DATABASE MojaBaza TO DISK = 'C:BackupMojaBaza_FULL.bak'
WITH COMPRESSION, CHECKSUM;

-- Różnicowy backup co 6 godzin
BACKUP DATABASE MojaBaza TO DISK = 'C:BackupMojaBaza_DIFF.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;

-- Backup logu transakcji co 15 minut
BACKUP LOG MojaBaza TO DISK = 'C:BackupMojaBaza_LOG.trn'
WITH COMPRESSION, CHECKSUM;

Zasada 3-2-1 dla SQL Server: 3 kopie, 2 nośniki (lokalny dysk + chmura/offsite), 1 kopia poza siedzibą.

Najlepsze praktyki zabezpieczeń SQL Server

1. Zasada najmniejszych uprawnień

• Nigdy nie używaj konta sa w aplikacjach — twórz dedykowane konta z minimalnymi uprawnieniami
• Używaj ról bazy danych zamiast nadawania uprawnień bezpośrednio
• Regularnie przeglądaj uprawnienia: sp_helprotect lub sys.database_permissions

2. Szyfrowanie połączeń

• Włącz Force Encryption w SQL Server Configuration Manager
• Zainstaluj certyfikat SSL/TLS na serwerze
• W connection string dodaj: Encrypt=True;TrustServerCertificate=False

3. Regularne aktualizacje

• Instaluj Cumulative Updates (CU) co kwartał
• Instaluj Security Updates natychmiast po wydaniu
• Testuj aktualizacje na środowisku testowym przed produkcją

4. Firewall i dostęp sieciowy

• SQL Server powinien słuchać tylko na potrzebnych interfejsach (nie 0.0.0.0)
• Zmień domyślny port 1433 na niestandardowy
• Ogranicz dostęp do serwera SQL w firewall — tylko z serwerów aplikacyjnych
• Wyłącz protokół SQL Server Browser, jeśli nie jest potrzebny

5. Monitoring i alerty

• Skonfiguruj SQL Server Agent Alerts na zdarzenia bezpieczeństwa
• Monitoruj nieudane logowania w logach systemowych
• Używaj Extended Events do śledzenia podejrzanej aktywności

6. Hardening — lista kontrolna

• Wyłącz konto sa lub zmień jego hasło na bardzo silne
• Wyłącz xp_cmdshell (domyślnie wyłączone — nie włączaj!)
• Wyłącz CLR integration, jeśli nie jest potrzebne
• Wyłącz Remote Admin Connections na serwerach produkcyjnych
• Wyłącz OLE Automation i Ad Hoc Distributed Queries
• Włącz TDE na wszystkich bazach produkcyjnych
• Skonfiguruj audyt logowań i dostępu do danych

SQL Server 2022 — nowe funkcje bezpieczeństwa

SQL Server 2022 wprowadza kilka istotnych usprawnień:

• Ledger tables — kryptograficznie weryfikowalna historia zmian (blockchain-like)
• Always Encrypted z Secure Enclaves — operacje na zaszyfrowanych danych bez deszyfrowania po stronie klienta
• Microsoft Purview integration — automatyczna klasyfikacja i etykietowanie danych wrażliwych
• Ulepszone zarządzanie certyfikatami — automatyczna rotacja certyfikatów TDE