TLS, мережевий доступ і права SQL відповідають на різні питання
Шифрування з’єднання, допуск джерела і надання таблиці — це три рішення. Пройдіть їх по порядку, перш ніж питати, чи може TLS замінити VPN.
Хтось пропонує надати клієнтові логін PostgreSQL, щоб заявка на витрати йшла зашифрованою від початку до кінця. Адміністратору бази даних потрібна справжня сесія SQL, а хтось інший пропонує натомість вебформу. Обидві пропозиції розв’язують не ту проблему, бо жодна не починалася з операції, яку клієнт справді виконує. Пройдіть три рішення по порядку, і питання про те, чи може TLS замінити VPN, відповість саме на себе.
Почніть з операції, яка потрібна клієнтові
Запишіть, чого має досягти клієнт. Подання заявки, читання одного рядка звіту й виконання разового запиту — це три різні операції з трьома різними профілями ризику.
Потім запишіть, хто робить запит. Клієнт, фахівець підтримки й адміністратор не є взаємозамінними, навіть коли вони торкаються тієї самої таблиці. Різниця визначає, яку частину мови запитів клієнт узагалі має бачити.
Пара відповідей визначає інтерфейс. Усе подальше — реалізація, і більшість суперечок про шифрування насправді суперечки про те, який інтерфейс обрано.
Три контролі, три рішення
Автентифікований TLS захищає з’єднання і визначає, які ідентичності TLS приймаються. Мережевий доступ визначає, які джерела взагалі можуть дістатися до слухача. Авторизація в базі даних визначає, які об’єкти й дії може використовувати роль.
Жоден із трьох не замінює інші, що таблиця показує прямо.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Прочитайте рядок, на який ви спираєтеся, перш ніж прибрати інший. Більшість таких проєктів провалюються, бо контроль припустили, а не налаштували.
Прямий SQL залишає політику бази даних відповідальною
За схваленого прямого з’єднання збережіть і перевірку ідентичності служби, і передбачену політику доступу. Увімкнення TLS робить зашифровані з’єднання доступними; воно не відхиляє незашифровані, якщо конфігурація доступу не вимагає цього через записи hostssl.
Цю різницю варто перевіряти в робочій конфігурації, а не в шаблоні. Сервер, який пропонує TLS і приймає відкритий текст, — не той проєкт, який більшість вважає розгорнутим. Прочитайте правила доступу й подивіться, які записи справді цього вимагають. Ця одна перевірка відокремлює сервер, здатний шифрувати, від сервера лише із шифруванням.
Використовуйте ролі лише з привілеями, потрібними для роботи, і переглядайте власність, успадковане членство та широко надані дозволи. Модель привілеїв PostgreSQL — це межа повноважень для об’єктів бази даних.
VPN може обмежити, які пристрої дістаються до служби до автентифікації в базі даних, а шлюз доступу може робити щось подібне. Жоден із них не скасовує потреби обслуговувати відкритий компонент, керувати обліковими даними й обмежувати використання ресурсів.
Клієнтські сертифікати — це облікові дані, а не ACL
Клієнтський сертифікат може додати вимогу під час з’єднання. Параметр clientcert може вимагати довіреного сертифіката і, в суворішому режимі, зв’язку між іменем сертифіката й користувачем бази даних.
Це сильніші облікові дані. Це не список авторизації, і він не робить сервер невидимим, бо компонент, який приймає з’єднання, досі обробляє мережевий трафік і рукостискання. Ставлення до сертифіката як до списку доступу залишає фактичні дозволи недоторканими. Він також схильний розширювати розповсюдження сертифікатів, що створює наступну проблему.
Сильний сертифікат, прив’язаний до ролі з надмірними привілеями, дає добре автентифікованого адміністратора. Перевірте роль, перш ніж святкувати сертифікат.
Виберіть вужчий інтерфейс, коли він пасує
Для заявки на витрати кінцева точка застосунку, яка приймає заявку, застосовує бізнес-правила й повертає дозволений результат цього користувача, представляє операцію краще, ніж загальний обліковий запис SQL.
Далі застосунок використовує власну обмежену ідентичність у базі даних, і клієнт ніколи не отримує мову запитів як функцію. Це менша поверхня з меншою кількістю способів помилитися.
Це варіант проєктування, а не твердження, що код застосунку автоматично безпечніший. Цей код має автентифікувати своїх викликачів, авторизувати кожну дію й перевіряти свій ввід, і його власні дозволи в базі даних досі важливі.
Прямий SQL залишається правильним для людей та інструментів, чия схвалена робота цього вимагає. Обмежте цей проєкт ролями, мережевим охопленням і операційними межами, а іншим клієнтам залиште вужчий інтерфейс. Змішування двох груп в одній ролі — це місце, де починаються суперечки.