Вступ до безпеки баз даних
Вступ до безпеки баз даних
Чому безпека баз даних критично важлива?
У сучасному цифровому світі дані є одним з найцінніших активів компанії. Уявіть, що ваша база даних — це сховище банку, де зберігаються не гроші, а щось набагато цінніше: персональна інформація клієнтів, фінансові дані, бізнес-секрети, медичні записи тощо.
Реальні наслідки порушень безпеки
Фінансові втрати
Репутаційні наслідки
Юридичні наслідки
Операційні збої
Приклади реальних інцидентів
CIA Triad: Три стовпи безпеки інформації
CIA Triad — це класична модель безпеки інформації, яка визначає три ключові аспекти, які потрібно захищати.
1. Confidentiality (Конфіденційність)
Визначення: Інформація повинна бути доступна лише тим користувачам, які мають на це право.
Чому це важливо:
- Захист персональних даних (GDPR, HIPAA)
- Збереження комерційних таємниць
- Запобігання промисловому шпигунству
- Захист інтелектуальної власності
Механізми забезпечення:
- Автентифікація (перевірка особи користувача)
- Авторизація (надання прав доступу)
- Шифрування даних (TDE, Always Encrypted)
- Маскування даних (Dynamic Data Masking)
Приклад порушення:
-- ПОГАНО: Всі користувачі можуть бачити зарплати
GRANT SELECT ON HR.Salaries TO PUBLIC;
-- ДОБРЕ: Тільки HR-менеджери можуть бачити зарплати
GRANT SELECT ON HR.Salaries TO HR_Managers;
DENY SELECT ON HR.Salaries TO ALL_Employees;
2. Integrity (Цілісність)
Визначення: Дані повинні залишатися точними, повними та незмінними протягом усього життєвого циклу.
Чому це важливо:
- Гарантія достовірності бізнес-даних
- Запобігання фінансовому шахрайству
- Відповідність регуляторним вимогам
- Підтримка довіри до системи
Механізми забезпечення:
- Обмеження прав на зміну даних (DENY UPDATE/DELETE)
- Транзакції та ACID властивості
- Тригери для аудиту змін
- Check constraints та foreign keys
- Хешування для перевірки цілісності
Приклад порушення:
-- ПОГАНО: Будь-хто може змінювати фінансові дані
GRANT UPDATE, DELETE ON Finance.Transactions TO PUBLIC;
-- ДОБРЕ: Тільки система може вставляти, а зміни та видалення заборонені
GRANT INSERT ON Finance.Transactions TO FinanceApp;
DENY UPDATE, DELETE ON Finance.Transactions TO FinanceApp;
-- Ще краще: Використовуйте тригер для аудиту
CREATE TRIGGER trg_AuditTransactions
ON Finance.Transactions
FOR UPDATE, DELETE
AS
BEGIN
RAISERROR('Modification of transactions is not allowed', 16, 1);
ROLLBACK;
END;
3. Availability (Доступність)
Визначення: Дані та системи повинні бути доступні та функціональні, коли користувачам потрібен доступ.
Чому це важливо:
- Безперервність бізнес-процесів
- Задоволеність клієнтів
- Дотримання SLA (Service Level Agreements)
- Конкурентоспроможність
Механізми забезпечення:
- Резервне копіювання (Backup & Restore)
- Високодоступність (Always On, Mirroring, Replication)
- Disaster Recovery планування
- Захист від DDoS атак
- Моніторинг та alerting
Загрози доступності:
- DDoS атаки
- Ransomware (шифрувальники)
- Апаратні збої
- Помилки конфігурації
- Перевантаження системи
Загрози безпеці баз даних
Розуміння загроз — перший крок до побудови надійної системи захисту. Розглянемо найпоширеніші типи атак на бази даних.
1. SQL Injection
Що це: Введення шкідливого SQL-коду через вхідні дані додатка.
Приклад вразливого коду:
// ДУЖЕ НЕБЕЗПЕЧНО! Ніколи так не робіть!
string query = "SELECT * FROM Users WHERE Username = '" + username + "' AND Password = '" + password + "'";
SqlCommand cmd = new SqlCommand(query, connection);
SqlDataReader reader = cmd.ExecuteReader();
Вхідні дані зловмисника:
Username: admin' --
Password: (будь-що)
Результуючий запит:
SELECT * FROM Users WHERE Username = 'admin' --' AND Password = ''
-- Частина після -- є коментарем і ігнорується!
Правильний підхід:
// БЕЗПЕЧНО: Використовуємо параметризовані запити
string query = "SELECT * FROM Users WHERE Username = @username AND Password = @password";
SqlCommand cmd = new SqlCommand(query, connection);
cmd.Parameters.AddWithValue("@username", username);
cmd.Parameters.AddWithValue("@password", password);
SqlDataReader reader = cmd.ExecuteReader();
- Завжди використовуйте параметризовані запити або ORM
- Валідуйте та санітизуйте вхідні дані
- Використовуйте stored procedures з правильними параметрами
- Застосовуйте principle of least privilege
- Використовуйте Web Application Firewall (WAF)
2. Privilege Escalation (Підвищення привілеїв)
Що це: Зловмисник отримує вищі права доступу, ніж йому надано.
Приклад сценарію:
-- Уразлива конфігурація:
-- Користувач має роль db_securityadmin
EXEC sp_addrolemember 'db_securityadmin', 'RegularUser';
-- Тепер RegularUser може надати собі роль db_owner!
-- (виконано як RegularUser)
EXEC sp_addrolemember 'db_owner', 'RegularUser';
-- Тепер він має повний контроль над БД
db_securityadmin та securityadmin ролей:Користувачі з цими ролями можуть підвищити свої власні привілеї. Будьте дуже обережні при призначенні цих ролей!3. Credential Theft (Крадіжка облікових даних)
Методи:
- Фішинг
- Keylogging
- Brute-force атаки
- Password spraying
- Витік даних з інших сервісів
Приклад brute-force:
-- Атакуючий намагається підібрати пароль
DECLARE @attempt INT = 1;
WHILE @attempt <= 10000
BEGIN
-- Спроба входу з різними паролями
EXEC sp_TryLogin 'admin', CONCAT('Password', @attempt);
SET @attempt = @attempt + 1;
END
Захист:
-- Увімкнути політику паролів
ALTER LOGIN [AppUser]
WITH CHECK_POLICY = ON, CHECK_EXPIRATION = ON;
-- Створити LOGON тригер для обмеження спроб
CREATE TRIGGER trg_LimitLoginAttempts
ON ALL SERVER
FOR LOGON
AS
BEGIN
-- Перевірка кількості невдалих спроб за останні 15 хвилин
DECLARE @LoginName NVARCHAR(128) = ORIGINAL_LOGIN();
DECLARE @FailedAttempts INT;
SELECT @FailedAttempts = COUNT(*)
FROM SecurityDB.dbo.FailedLogins
WHERE LoginName = @LoginName
AND AttemptTime > DATEADD(MINUTE, -15, GETDATE());
IF @FailedAttempts >= 5
BEGIN
ROLLBACK;
RAISERROR('Too many failed login attempts. Account temporarily locked.', 16, 1);
END
END;
4. Insider Threats (Внутрішні загрози)
Що це: Загрози від співробітників компанії, які мають легітимний доступ.
Типи:
- Зловмисні: Навмисна крадіжка даних, саботаж
- Необережні: Випадкове видалення, неправильна конфігурація
- Скомпрометовані: Акаунти співробітників, зламані ззовні
Статистика:
- 34% всіх порушень безпеки спричинені інсайдерами (Verizon DBIR 2023)
- Середній час виявлення insider threat: 85 днів
Захист:
-- 1. Аудит всіх дій адміністраторів
CREATE SERVER AUDIT AdminAudit
TO FILE (FILEPATH = 'D:\Audit\');
ALTER SERVER AUDIT AdminAudit WITH (STATE = ON);
CREATE SERVER AUDIT SPECIFICATION AdminActions
FOR SERVER AUDIT AdminAudit
ADD (DATABASE_OBJECT_ACCESS_GROUP),
ADD (DATABASE_OBJECT_CHANGE_GROUP),
ADD (DATABASE_PERMISSION_CHANGE_GROUP);
ALTER SERVER AUDIT SPECIFICATION AdminActions WITH (STATE = ON);
-- 2. Separation of Duties
-- DBA не повинен мати доступ до продакшн даних
DENY SELECT, INSERT, UPDATE, DELETE ON SCHEMA::Sales TO DBA_Role;
-- 3. Використовувати Dynamic Data Masking для чутливих даних
ALTER TABLE Customers
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');
ALTER TABLE Customers
ALTER COLUMN CreditCard ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)');
5. Malware та Ransomware
Що це: Шкідливе ПЗ, яке може шифрувати дані та вимагати викуп.
Вектори атаки:
- Електронна пошта з вкладеннями
- Зламані веб-сайти
- USB-носії
- Вразливості у програмному забезпеченні
Захист:
-- 1. Регулярні backup з перевіркою можливості відновлення
BACKUP DATABASE ProductionDB
TO DISK = 'D:\Backup\ProductionDB_Full.bak'
WITH COMPRESSION, CHECKSUM, INIT;
-- 2. Захист backup-файлів
-- Зберігати offline або в immutable storage
-- 3. Тестувати процедуру відновлення
RESTORE VERIFYONLY
FROM DISK = 'D:\Backup\ProductionDB_Full.bak';
Defense in Depth: Багаторівнева модель захисту
Defense in Depth (оборона в глибину) — це стратегія безпеки, яка передбачає кілька рівнів захисту. Якщо один рівень скомпрометовано, інші рівні продовжують захищати систему.
Розгляд кожного рівня
Модель безпеки SQL Server
SQL Server використовує дворівневу модель безпеки: Server Level та Database Level.
Server Level (Рівень сервера)
Основні компоненти:
- Logins — облікові записи для підключення до SQL Server
- Server Roles — групи logins з певними правами на рівні сервера
- Server Permissions — окремі права на виконання операцій на сервері
Приклад:
-- Створення логіна
CREATE LOGIN [AppUser] WITH PASSWORD = 'SecureP@ss123';
-- Додавання до серверної ролі
ALTER SERVER ROLE dbcreator ADD MEMBER [AppUser];
-- Надання специфічного права
GRANT VIEW SERVER STATE TO [AppUser];
Database Level (Рівень бази даних)
Основні компоненти:
- Users — представлення логіна в конкретній базі даних
- Database Roles — групи users з певними правами в БД
- Permissions — права на об'єкти БД (таблиці, процедури, схеми)
- Schemas — логічні контейнери для об'єктів БД
Приклад:
-- Створення користувача в БД
USE SalesDB;
CREATE USER [AppUser] FOR LOGIN [AppUser];
-- Додавання до ролі БД
ALTER ROLE db_datareader ADD MEMBER [AppUser];
-- Надання конкретних прав
GRANT EXECUTE ON SCHEMA::dbo TO [AppUser];
GRANT SELECT, INSERT ON Sales.Orders TO [AppUser];
- LOGIN існує на рівні SQL Server instance (один логін для всього сервера)
- USER існує в межах конкретної бази даних (один логін може мати різних users в різних БД)
- Один LOGIN може мати 0, 1 або багато USERS в різних базах даних
Compliance та регуляторні вимоги
Багато індустрій мають специфічні вимоги до безпеки даних, які закріплені на законодавчому рівні.
GDPR (General Data Protection Regulation)
Застосовується: ЄС та компанії, що обробляють дані громадян ЄС
Ключові вимоги:
- Право на видалення даних ("right to be forgotten")
- Право на портативність даних
- Обов'язкове повідомлення про витік даних протягом 72 годин
- Data Protection Impact Assessment (DPIA)
- Призначення Data Protection Officer (DPO)
SQL Server реалізація:
-- 1. Забезпечення права на видалення
CREATE PROCEDURE usp_DeleteUserData
@UserID INT
AS
BEGIN
BEGIN TRANSACTION;
DELETE FROM UserProfiles WHERE UserID = @UserID;
DELETE FROM UserOrders WHERE UserID = @UserID;
DELETE FROM UserPreferences WHERE UserID = @UserID;
-- Логування видалення для compliance
INSERT INTO GDPR_DeletionLog (UserID, DeletedAt, DeletedBy)
VALUES (@UserID, GETDATE(), SUSER_NAME());
COMMIT TRANSACTION;
END;
-- 2. Аудит доступу до персональних даних
CREATE SERVER AUDIT GDPR_Audit
TO FILE (FILEPATH = 'D:\Audit\GDPR\');
ALTER SERVER AUDIT GDPR_Audit WITH (STATE = ON);
HIPAA (Health Insurance Portability and Accountability Act)
Застосовується: США, медичні організації
Ключові вимоги:
- Шифрування PHI (Protected Health Information)
- Audit trails для всіх доступів до медичних даних
- Business Associate Agreements (BAA)
- Регулярні risk assessments
SQL Server реалізація:
-- Шифрування чутливих медичних даних
CREATE TABLE Patients (
PatientID INT PRIMARY KEY,
Name NVARCHAR(100),
SSN NVARCHAR(11) ENCRYPTED WITH (
ENCRYPTION_TYPE = DETERMINISTIC,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
COLUMN_ENCRYPTION_KEY = PatientDataKey
),
Diagnosis NVARCHAR(MAX) ENCRYPTED WITH (
ENCRYPTION_TYPE = RANDOMIZED,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
COLUMN_ENCRYPTION_KEY = PatientDataKey
)
);
PCI DSS (Payment Card Industry Data Security Standard)
Застосовується: Компанії, що обробляють платіжні картки
Ключові вимоги:
- Шифрування карткових даних
- Обмеження доступу за принципом "need to know"
- Регулярні vulnerability scans
- Penetration testing
SQL Server реалізація:
-- Маскування номерів карток
CREATE TABLE CreditCards (
CardID INT PRIMARY KEY,
CardholderName NVARCHAR(100),
CardNumber NVARCHAR(16) MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)'),
CVV NVARCHAR(3) MASKED WITH (FUNCTION = 'default()')
);
-- Тільки privileged users можуть бачити повні номери
GRANT UNMASK TO CardProcessingApp;
Висновки
Безпека баз даних — це не одноразова задача, а безперервний процес, який вимагає:
Проактивний підхід
Багаторівневий захист
Людський фактор
Постійне вдосконалення
Ключові takeaways
- CIA Triad (Confidentiality, Integrity, Availability) — основа безпеки інформації
- Загрози різноманітні: від SQL Injection до insider threats
- Defense in Depth — використовуйте кілька рівнів захисту
- SQL Server має дворівневу модель: Server Level (LOGIN) → Database Level (USER)
- Compliance важливий: GDPR, HIPAA, PCI DSS мають серйозні штрафи за порушення
Що далі?
У наступних статтях ми детально розглянемо кожен аспект безпеки SQL Server:
- Системні представлення — метадані та аудит
- Автентифікація — Windows vs SQL Server
- Логіни — створення та управління
- Користувачі — mapping та схеми
- Ролі сервера — права на sysadmin та інші
- Ролі БД — db_owner, db_datareader
- Ролі додатків — context switching
- Права доступу — GRANT, DENY, REVOKE
- Best Practices — аудит, шифрування, RLS