Открыть сервисСервис
Главная → Блог → Row-Level Security

Row-Level Security

Row-Level Security (RLS, построчная безопасность) — это механизм управления доступом к данным в системах управления базами данных (СУБД), который позволяет ограничивать видимость отдельных строк таблицы для пользователей или приложений на основе определённых правил или предикатов. В отличие от традиционных методов разграничения доступа на уровне таблиц или столбцов, RLS обеспечивает более тонкую грануляцию контроля, что особенно востребовано в многопользовательских средах, где разные субъекты должны видеть только свои данные.

История и развитие

Концепция построчного ограничения доступа существовала задолго до появления формализованных механизмов RLS. В ранних реляционных СУБД (1970–1980-е годы) разработчики реализовывали подобную логику вручную — через представления (VIEW) с условиями WHERE user_id = current_user или через хранимые процедуры. Такой подход был трудоёмким, сложным в поддержке и подверженным ошибкам.

Первые коммерческие реализации RLS появились в 1990-х годах. Компания Oracle внедрила Virtual Private Database (VPD) в Oracle 8i (1999 год), что стало одним из первых системных решений для построчного контроля. В 2005 году Microsoft SQL Server 2005 представил механизм контекстного фильтра через функции fn_my_permissions, но полноценная поддержка RLS (через политики безопасности) была добавлена только в SQL Server 2016. В PostgreSQL механизм Row-Level Security появился в версии 9.5 (2016 год). В последние годы RLS активно развивается в облачных платформах: Amazon Redshift, Google BigQuery, Snowflake и Yandex Managed Service for PostgreSQL.

Принцип работы

RLS реализуется путём автоматического добавления к каждому запросу к таблице дополнительного условия (WHERE-предиката), которое фильтрует строки в соответствии с заданной политикой. Политика безопасности — это набор правил, определяющих, какие строки доступны для операций чтения (SELECT), вставки (INSERT), обновления (UPDATE) и удаления (DELETE).

Ключевые компоненты

  1. Политика безопасности (Security Policy) — именованный набор правил, привязанный к конкретной таблице. Политика определяет, какие предикаты применяются к операциям.
  2. Предикат (Predicate) — логическое выражение, которое возвращает TRUE (строка доступна) или FALSE (строка скрыта). Предикат может использовать:
  • Значения столбцов таблицы.
  • Системные функции (например, current_user, session_user).
  • Пользовательские функции, возвращающие контекстные данные.
  1. Контекст выполнения — информация о текущем пользователе, роли, приложении или сессии, на основе которой вычисляется предикат.

Пример реализации (PostgreSQL)

```sql -- Создание таблицы CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INTEGER, total DECIMAL, status TEXT );

-- Включение RLS для таблицы ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- Создание политики: менеджер видит только заказы своих клиентов CREATE POLICY manager_orders ON orders FOR SELECT USING (customer_id IN ( SELECT id FROM customers WHERE manager_id = current_user_id() )); ```

В этом примере при выполнении запроса SELECT * FROM orders для пользователя с ролью менеджера система автоматически добавит условие WHERE customer_id IN (...), скрывая заказы, не относящиеся к его клиентам.

Классификация политик RLS

Политики RLS можно классифицировать по нескольким признакам:

1. По типу операций

  • Политики чтения (SELECT) — фильтруют строки при выборке.
  • Политики записи (INSERT, UPDATE, DELETE) — контролируют, какие строки можно изменять. Для INSERT политика может проверять, соответствует ли новая строка правилам (например, запрет на вставку заказа с суммой выше лимита).
  • Комбинированные политики — применяются к нескольким операциям одновременно.

2. По способу определения предиката

  • Статические — предикат фиксирован и не зависит от контекста (например, status = 'active').
  • Динамические — предикат вычисляется на основе контекста (например, customer_id = current_user_id()).
  • Параметризованные — используют внешние параметры, передаваемые через приложение (например, app_context.get('region')).

3. По уровню изоляции

  • Пользовательские — каждый пользователь видит только свои данные.
  • Ролевые — доступ определяется ролью пользователя (например, admin видит все строки, manager — только свои).
  • Контекстные — доступ зависит от внешних условий (например, временной метки, IP-адреса).

Преимущества и недостатки

Преимущества

  • Централизованное управление — политики определяются на уровне базы данных, а не в приложении, что упрощает администрирование и снижает риск ошибок.
  • Повышенная безопасность — даже если приложение имеет уязвимости (например, SQL-инъекции), RLS ограничивает доступ к данным.
  • Гранулярность — контроль на уровне отдельных строк, что невозможно при традиционных методах.
  • Прозрачность для приложений — разработчикам не нужно реализовывать фильтрацию в коде; база данных делает это автоматически.

Недостатки

  • Производительность — каждый запрос к таблице с RLS требует дополнительного вычисления предиката, что может замедлять работу, особенно на больших объёмах данных.
  • Сложность отладки — ошибки в политиках могут приводить к неожиданному сокрытию данных, а диагностика таких проблем затруднена.
  • Ограничения функциональности — не все СУБД поддерживают RLS для всех типов операций (например, INSERT с ON CONFLICT).
  • Конфликты с кэшированием — некоторые системы кэширования результатов запросов могут не учитывать RLS, что приводит к утечке данных.

Применение в различных СУБД

PostgreSQL

  • Поддерживается с версии 9.5.
  • Политики создаются командой CREATE POLICY и привязываются к таблицам.
  • Поддерживаются все типы операций: SELECT, INSERT, UPDATE, DELETE, ALL.
  • Возможно использование WITH CHECK для ограничения вставки и обновления.

Microsoft SQL Server

  • Полноценная поддержка с SQL Server 2016.
  • Используются функции безопасности (CREATE SECURITY POLICY), которые применяют предикаты к таблицам.
  • Поддерживаются FILTER PREDICATE (для чтения) и BLOCK PREDICATE (для записи).

Oracle Database

  • Реализована через Virtual Private Database (VPD) с использованием DBMS_RLS пакета.
  • Политики могут быть привязаны к таблицам, представлениям или синонимам.
  • Поддерживаются статические, динамические и контекстные политики.

MySQL

  • Встроенной поддержки RLS нет до версии 8.0. Однако с 8.0.16 появилась возможность использовать ROW LEVEL SECURITY через CREATE TABLE ... ROW_FORMAT=FIXED, но это не полноценная реализация.
  • Для построчного контроля обычно используют представления или триггеры.

Облачные платформы

  • Snowflake — поддерживает RLS через ROW ACCESS POLICY, которая может быть привязана к таблицам.
  • Google BigQuery — использует ROW ACCESS POLICY с поддержкой GRANT и REVOKE.
  • Amazon Redshift — реализована через ROW LEVEL SECURITY с поддержкой CREATE RLS POLICY.

Примеры использования

Многопользовательские SaaS-приложения

В облачных сервисах, где одна база данных обслуживает множество клиентов (tenant), RLS позволяет автоматически изолировать данные каждого клиента. Например, приложение для управления проектами: пользователь из компании «А» видит только задачи своей компании, даже если в таблице tasks хранятся данные всех клиентов.

Финансовый сектор

В банковских системах RLS применяется для ограничения доступа к данным клиентов. Например, менеджер может видеть только счета своих клиентов, а аудитор — все счета, но без возможности изменения.

Здравоохранение

В медицинских информационных системах RLS используется для соблюдения конфиденциальности пациентов. Врач видит только истории болезней своих пациентов, а администратор — только данные о госпитализациях.

Государственные информационные системы

В России RLS применяется, например, в Единой государственной информационной системе в сфере здравоохранения (ЕГИСЗ), где доступ к данным о пациентах ограничен на уровне медицинских организаций и ролей сотрудников.

Критика и ограничения

Несмотря на очевидные преимущества, RLS не является панацеей. Критики отмечают, что:

  • Производительность — на больших таблицах с миллионами строк вычисление предиката может приводить к значительному замедлению запросов, особенно при сложных условиях.
  • Сложность миграции — перенос политик между разными СУБД часто требует переписывания кода, так как синтаксис и возможности различаются.
  • Риск ошибок — неправильно настроенная политика может либо открыть доступ к конфиденциальным данным, либо, наоборот, заблокировать легитимные запросы.
  • Несовместимость с некоторыми операциями — например, INSERT ... ON CONFLICT в PostgreSQL может не работать корректно с RLS.

Будущее развития

Развитие RLS связано с облачными технологиями и требованиями к защите данных. Ожидается, что:

  • Улучшится производительность за счёт кэширования предикатов и оптимизации планов запросов.
  • Появится поддержка RLS для нереляционных баз данных (NoSQL).
  • Будут разработаны стандарты межплатформенной совместимости политик.
  • Усилится интеграция с системами управления идентификацией и доступом (IAM).

Источники

  1. PostgreSQL Documentation: Row Security Policies (Chapter 5.8).
  2. Microsoft SQL Server Documentation: Row-Level Security (SQL Server 2016).
  3. Oracle Database Security Guide: Using Virtual Private Database.
  4. Snowflake Documentation: Row Access Policies.
  5. Google Cloud BigQuery Documentation: Row-level security.
  6. Amazon Redshift Documentation: Row-level security.
  7. Федеральный закон «О персональных данных» № 152-ФЗ (Российская Федерация).

Похожие материалы