Многоарендная изоляция данных с помощью Supabase и PostgreSQL RLS

Введение и архитектурный подход

В многоарендных (multi-tenant) программных архитектурах надежное разделение данных различных клиентов внутри одной базы данных является критическим требованием. В целях защиты данных предприятий и обеспечения соответствия законодательным нормам задействуются механизмы безопасности на уровне строк. В этом контексте безопасные инфраструктуры строятся с использованием технологий управления Linux, Docker, Nginx, PostgreSQL и Supabase self-hosting в рамках услуги Инфраструктура серверов и облака.

Основы PostgreSQL RLS

Функция Row Level Security (безопасность на уровне строк — RLS), предлагаемая инфраструктурой PostgreSQL, позволяет фильтровать доступ к данным в таблицах на уровне отдельных строк. В то время как стандартные методы авторизации обычно ограничиваются уровнем таблиц, механизм RLS позволяет различным арендаторам, использующим одну и ту же таблицу, видеть только собственные данные.

• Вместо безопасности на уровне таблиц применяется фильтрация на уровне строк.
• SQL-запросы автоматически выполняются с фильтром по соответствующей компании.
• Возможные риски утечки на уровне приложения предотвращаются на уровне базы данных.

Настройка изоляции арендаторов в Supabase

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

Шаги определения политик

1. Активация функции RLS для соответствующей таблицы.
2. Написание функций PostgreSQL, проверяющих идентификатор компании пользователя.
3. Создание подходящих политик (policies) для операций SELECT, INSERT, UPDATE и DELETE.

Оценка производительности и безопасности

Использование RLS в многоарендных системах должно поддерживаться правильными стратегиями индексации. Определение подходящих b-tree индексов по столбцам ID компании (tenant id) предотвращает негативное влияние политик безопасности на производительность запросов. Оптимизация инфраструктуры и процессы управления базой данных напрямую влияют на стабильность системы.

Гипотетический сценарий и пример реализации

Чтобы конкретизировать этот подход, рассмотрим гипотетический сценарий, в котором две разные компании (Компания А и Компания Б) используют одно и то же программное обеспечение для выставления счетов. Таблица faturalar содержит колонку sirket_id для каждой записи. Когда пользователи входят в систему через Supabase, они передают свои идентификаторы компаний в сеанс базы данных через поле app_metadata в токен JWT. Когда финансовый менеджер Компании А подключается к системе, автоматически срабатывает политика RLS, определенная в PostgreSQL, и ко всем запросам SELECT добавляется фильтр WHERE sirket_id = current_setting('request.jwt.claim.sirket_id', true). Благодаря этому, независимо от того, какую фильтрацию пользователь выполняет в интерфейсе, даже если он физически запросит счет, принадлежащий Компании Б, уровень базы данных вернет пустой результат или ошибку. Это предотвращает утечку данных даже при возможном уязвимости на уровне приложения. Однако основным компромиссом, на который здесь следует обратить внимание, является небольшое увеличение нагрузки на базу данных и необходимость установки контекста для каждого запроса. Неправильно настроенная структура JWT может привести к тому, что пользователи вообще не смогут получить доступ к данным или попадут в неверный контекст арендатора. В таких сценариях ошибок с помощью логов базы данных и механизмов перехвата ошибок Supabase следует мгновенно выявлять отсутствие контекста сеанса и безопасно перенаправлять пользователя на выход из системы.

Подробное руководство и контрольный список безопасности

Прежде чем переводить многоарендный проект Supabase и PostgreSQL RLS в производственную среду, необходимо выполнить следующие шаги в полном объеме:

• Включение RLS: Необходимо убедиться, что команда ALTER TABLE tablo_adi ENABLE ROW LEVEL SECURITY; выполнена для всех таблиц, содержащих конфиденциальные данные.
• Стратегия индексации: Для предотвращения падения производительности на колонке sirket_id в каждой таблице должны быть определены B-tree индексы, а планы запросов должны быть проверены с помощью (EXPLAIN ANALYZE).
• Область действия политик: Политики должны быть написаны отдельно для каждого типа операции (SELECT, INSERT, UPDATE, DELETE), и следует проверить, что условия WITH CHECK не забыты, особенно для операций INSERT.
• Интеграция JWT: Следует протестировать, что структура токена, поступающая из службы аутентификации Supabase, корректно считывается функциями базы данных и неавторизованные токены отклоняются.
• Управление ошибками и исключениями: Когда контекст арендатора не найден (например, для анонимных пользователей или в случае отсутствия токена), система должна не падать, а безопасно отказывать в доступе.
• Гарантия безопасности инфраструктуры: В соответствии со стандартами Инфраструктура серверов и облака обновления безопасности для конфигураций контейнеров Docker и PostgreSQL должны выполняться регулярно.

Ресурсы

• Инфраструктура серверов и облака — Cy Logic Software