Керування доступом та безпека

Уяви собі нічний жах: ти — адміністратор бази даних, а важлива таблиця з даними клієнтів раптом бере і... зникає. Хто це зробив? Чому? Може, це помилка недосвідченого стажера, який випадково написав DROP TABLE. А може, це був злий користувач, у якого був доступ до бази... Що б це не було, метушитися пізно! Лишається тільки прокинутися, прийти до тями і взятися за вивчення захисту баз даних. Бо база даних без налаштованої безпеки — як дім без фундаменту.

Для баз даних захист має бути на висоті, щоб запобігти таким загрозам, як:

• Несанкціонований доступ: хтось отримує доступ до даних, до яких у нього немає прав.
• Витік даних: паролі, кредитки або конфіденційна інформація потрапляють не в ті руки.
• SQL-інʼєкції: підступний метод, який може дозволити зловмиснику маніпулювати твоєю базою через погано захищені запити.
• Людські помилки: випадкове видалення даних або зміна, яку не можна відкотити.

У PostgreSQL безпека реалізована на кількох рівнях: від створення ролей і керування правами до обмеження мережевого доступу. Це дозволяє гнучко налаштовувати, хто і що може робити з твоїми даними.

Основні рівні безпеки в PostgreSQL

У PostgreSQL є три головних рівні, на яких ти можеш керувати доступом:

1. Керування доступом на рівні бази даних. На цьому рівні ти вирішуєш, кому можна підключатися до твоєї бази даних і що користувач може робити, коли він підключився. Наприклад, можна заборонити деяким користувачам взагалі входити в базу. Іншим — дозволити тільки читання даних. Ключовий інструмент для цього — ролі.

2. Контроль доступу на рівні таблиць, рядків і стовпців.

У PostgreSQL доступ до даних можна обмежувати дуже точково. Ти можеш:

• Дозволити користувачу читати тільки певні стовпці.
• Дозволити читати дані в таблиці, тільки якщо користувач — власник рядка. Це називається ROW LEVEL SECURITY (RLS), і ми його детально розберемо в наступних лекціях.
• Обмежити доступ тільки до розділів бази (схем), у яких знаходяться важливі дані.

3. Налаштування мережевого доступу. База даних може бути налаштована так, щоб приймати запити тільки від довірених клієнтів. Це налаштовується через конфігураційний файл PostgreSQL під назвою pg_hba.conf. За допомогою цього файлу можна, наприклад, дозволити підключення тільки з локальної машини або певних IP-адрес.

Інструменти безпеки PostgreSQL

Давай розберемося, які засоби безпеки пропонує PostgreSQL і як вони працюють на практиці.

Почнемо з ролей і привілеїв — це основа системи керування доступом. У PostgreSQL роль — це не просто користувач, а щось більш гнучке. Вона може представляти як одну людину, так і цілу групу. Наприклад, ти можеш створити роль з іменем manager, яка буде мати повний доступ до таблиці із замовленнями, а стажеру підійде роль intern, у якої будуть права тільки на читання — щоб він випадково нічого не зіпсував.

Самі ролі можна налаштовувати досить гнучко: комусь давати більше прав, комусь менше, а ще — дозволяти одній ролі наслідувати права іншої. Через них і визначається, хто може підключатися до бази, які схеми і таблиці доступні, і навіть які саме рядки можна побачити чи змінити.

Далі йдуть конфігураційні файли. У PostgreSQL є два ключових конфігураційних файли, які відіграють важливу роль у забезпеченні безпеки.

Перший — це pg_hba.conf. Він відповідає за мережевий доступ до бази даних. Саме тут налаштовується, хто взагалі має право підключатися до сервера, з якої IP-адреси і яким способом буде проходити автентифікація. Якщо треба обмежити доступ тільки для певних машин або користувачів — це якраз робиться тут.

Другий файл — postgresql.conf. Він керує загальними налаштуваннями сервера, і серед іншого в ньому задаються параметри логування та аудиту. Це дозволяє стежити за тим, хто що робить, вчасно помічати підозрілу активність і за потреби розбиратися в деталях.

Нарешті, логування і аудит. "Логи — це твій найкращий друг". Звучить дивно, але для адміністратора бази даних це правило номер один. У PostgreSQL можна налаштувати логування всіх запитів і дій користувачів. Це допоможе розібратися, хто що зробив з базою, якщо щось пішло не так.

Приклад: захист даних від SQL-інʼєкцій

SQL-інʼєкції — це один із найпопулярніших способів атаки на базу даних. І від нього ну дуже важливо вміти захищатися. Уяви, що у тебе є застосунок, де користувач вводить ID свого акаунта, щоб подивитися профіль. І ось такий запит викликає застосунок:

SELECT * FROM users WHERE id = 123;

А що, якщо користувач введе 123 OR 1=1 замість числа? Тоді запит перетвориться на щось типу:

SELECT * FROM users WHERE id = 123 OR 1=1;

І замість одного запису вся таблиця users стане доступною.

Як захиститися? PostgreSQL дозволяє тобі використовувати параметризовані запити або підготовлені команди (PREPARE і EXECUTE), щоб користувацькі дані ніколи не змішувалися з кодом SQL. Ось як це виглядає:

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

Ще приклади реальних загроз

Щоб ти чітко зрозумів, навіщо потрібна безпека, наведу два реальних сценарії:

Приклад 1: "Працівник видалив всю таблицю"

Одного разу в одній компанії (насправді, не одного разу, і компаній таких було багато...) стажер випадково ввів у консоль команду:

DROP TABLE employees;

І 10 років даних про працівників канули в Лету. Як цього уникнути?

• Керуйте правами! Наприклад, ролі intern можна дозволити тільки читання.
• Налаштовуйте аудит! Логи покажуть, хто викликав фатальний запит.

Приклад 2: "Витік даних через незашифроване з'єднання"

Якщо користувач підключається до сервера PostgreSQL без шифрування, його логін і пароль можуть бути перехоплені зловмисником. Налаштуй SSL і переконайся, що з'єднання захищені.

Ключові задачі для адміністраторів

На завершення цього вступу виділимо три головні задачі будь-якого адміністратора PostgreSQL:

• Розмежування доступу. Переконайся, що тільки уповноважені користувачі можуть виконувати певні дії.
• Шифрування. Конфіденційні дані завжди мають зберігатися і передаватися у зашифрованому вигляді.
• Моніторинг. Налаштуй аудит і стеж за підозрілою активністю в логах.

На наступних лекціях ти дізнаєшся, як створювати ролі, керувати доступом за допомогою GRANT і REVOKE, впроваджувати контроль доступу на рівні рядків і використовувати шифрування для захисту даних.