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 остаётся правильным для людей и инструментов, чья одобренная работа этого требует. Ограничьте этот проект ролями, сетевым охватом и операционными пределами, а остальным клиентам оставьте более узкий интерфейс. Смешивание двух групп в одной роли — это место, где начинаются споры.