Принудительное применение доступа к данным: задайте права на данные один раз и контролируйте доступ для каждого запроса

Retool может подключаться практически к любому источнику данных, используемому вашим бизнесом. До сих пор ресурсы, которые не поддерживали аутентификацию для каждого пользователя, полагались на единый набор общих учетных данных, а эти учетные данные имели доступ к каждой таблице и столбцу.

Командам, которым требовался более детальный контроль, приходилось создавать и пересоздавать правила на уровне таблиц, столбцов и строк в своих приложениях, рабочих процессах и ИИ-агентах. По мере того как все больше людей занимаются разработкой, и все большую ее часть выполняют ИИ, команды безопасности не успевают проверять каждый запрос.

Именно поэтому мы рады анонсировать функцию принудительного применения доступа к данным (Data Access Enforcement). Теперь средства контроля доступа переносятся на уровень ресурса, а не приложения. Это означает, что владельцы ресурсов один раз определяют политики доступа на уровне таблиц, столбцов и строк, а Retool применяет их везде, где используется этот ресурс — будь то в приложении, рабочем процессе, библиотеке запросов или ИИ-агенте.

Функция принудительного применения доступа к данным по умолчанию закрыта, и не верьте нам на слово: сторонняя охранная фирма провела тестирование на проникновение перед этим запуском. Наш полный отчет о тестировании на проникновение за 2026 год будет доступен через наш Центр доверия.

Для обеспечения безопасности доступа к данным на платформе Retool у нас было четыре основных требования.

• Закрыто по умолчанию. Когда вы включаете принудительное применение для ресурса, он закрывается для всех, включая администраторов, во всех средах. Доступ расширяется только при наличии активной политики. Нет никаких правил запрета, которые нужно поддерживать, а таблица или столбец, добавленные в следующем месяце, остаются заблокированными до тех пор, пока их не покроет политика.
• Для каждого запроса требуется идентификатор пользователя. Retool оценивает политику на основе идентификатора, стоящего за запросом: на сегодняшний день это вошедший в систему пользователь, независимо от того, поступил ли запрос из приложения, запущенного им рабочего процесса или агента, работающего от его имени. Запрос без указания идентификатора блокируется.
• Доступ проверяется на бэкенде до выполнения запроса. Retool разбирает каждый запрос с помощью грамматики Postgres и проверяет каждую таблицу, затем каждый затрагиваемый столбец, а затем фильтр строк. Запрос, затрагивающий непредоставленную таблицу или столбец, завершается ошибкой до выполнения, с указанием имени этого объекта. Данные извлекаются и поступают на фронтенд только в том случае, если у пользователя есть к ним доступ.
• Сбой с закрытием. Если Retool не может проанализировать или оценить запрос, он блокирует его.
• Таблицы. Запрос к таблице, доступ к которой не был предоставлен, завершается ошибкой, а в сообщении об ошибке указывается имя таблицы, чтобы не гадать, какая именно из них вызывает проблему.
• Столбцы. Предоставьте доступ к одним столбцам и не давайте к другим. Выражение SELECT * никому не откроет доступ к столбцу, на который у него нет прав. Обозреватель схемы также скрывает непредоставленные столбцы.
• Строки. С помощью безопасности на уровне строк (RLS) вы можете фильтровать строки по идентификатору пользователя, выполняющего запрос. Это может быть его электронная почта или атрибут пользователя, которым вы уже управляете в Retool, например команда или регион.
• Чтение или запись. Предоставляйте права только на чтение или на чтение и запись отдельно от того, кто может использовать подключение. Одно ограничение: фильтры строк определяют, какие существующие строки пользователь может читать, обновлять или удалять, но не какие строки он может добавлять.

Один клик в приложении может инициировать запросы в нескольких частях Retool. Например, предположим, что менеджер по работе с клиентами нажимает кнопку «Подготовить сводку по продлению» в приложении для продления. Это запускает рабочий процесс, который выполняется от их имени, извлекает данные об использовании, тикеты и счета из Postgres и передает их ИИ-агенту, который составляет чертеж сводки.

Одна политика на ресурс охватывает все это:

• Фильтр строк по полю account_owner означает, что приложение, рабочий процесс и агент могут читать только те учетные записи, которые принадлежат этому менеджеру по работе с клиентами.
• discount_pct и gross_margin предоставляются только финансовому отделу. Если агент выберет их, запрос завершится ошибкой, и эти цифры не попадут в сводку.

Никакая логика разрешений не заложена в приложении, рабочем процессе или промпте агента. Следующее приложение, созданное на основе этого ресурса, получает ту же политику начиная с самого первого запроса.

Поскольку принудительное применение по умолчанию закрыто, его включение блокирует любой запрос, не покрытый ни одной политикой. Прежде чем включать эту функцию для ресурса, ознакомьтесь со следующими рекомендациями:

• Спланируйте политики для групп, использующих ресурс, чтобы вы могли сразу восстановить их доступ, и существующие приложения продолжили работу.
• Подключайтесь напрямую к Postgres. Прокси-серверы пула соединений, такие как PgBouncer, могут нарушить работу принудительного применения.
• Укажите конкретные среды. Каждая политика применяется только к выбранным вами средам.

Имейте в виду, что некоторые запросы на защищенном ресурсе блокируются всегда, независимо от политики. К ним относятся запросы, которые нельзя сопоставить с вошедшим в систему пользователем (например, из публичных или внедренных приложений, а также рабочих процессов, запускаемых по расписанию или через вебхук), а также запросы к ресурсам с отключенными подготовленными выражениями (prepared statements).

Чтобы включить принудительное применение, перейдите в раздел «Ресурсы» (Resources), выберите вкладку «Применение доступа» (Access Enforcement), включите переключатель «Принудительное применение доступа к данным» (Data access enforcement) и нажмите «Сохранить изменения» (Save changes).

Хорошей отправной точкой является создание единой политики «Полный доступ» (Full access) для всех пользователей, которая сохраняет работу ресурса в прежнем режиме. После этого добавьте более узкие политики для групп, доступ которых вы хотите ограничить, и используйте функцию «Кроме» (Except), чтобы исключить эти группы из общей политики.

Для получения дополнительной информации следуйте пошаговому руководству по настройке.

Функция принудительного применения доступа к данным теперь доступна в публичной бета-версии для организаций уровня Enterprise в облачных, граничных (edge) и стабильных развертываниях для ресурсов Postgres.

Если у вас есть ресурсы Postgres с большим количеством разработчиков или более конфиденциальными данными, чем вам хотелось бы, начните работу уже сегодня.

В будущих релизах мы продолжим развивать эту основу, и вы можете помочь нам сформировать стандарты отличной безопасности данных! Делитесь своими отзывами в Twitter/X (открывается в новой вкладке), LinkedIn (открывается в новой вкладке) или в нашем сообществе.

Функция принудительного применения доступа к данным была создана следующими разработчиками: Эндрю Гуан, Эндрю Морс, Энджи Палм, Бен Луи, DJ Заппегос, Фрэнк Ган, Джефф Розенберг, Дженнифер Ярнефельдт, Кешав Синхал, Кун Цянь, Кайл Чунг, Леонид Домницер, Марк Нгуен, Стефан Пфистнер и Тим Чанг.