Безопасность на уровне строк в хранилище данных Fabric

Область применения: конечная точка аналитики SQL и хранилище в Microsoft Fabric

Безопасность на уровне строк (RLS) позволяет использовать контекст членства в группах или выполнения для управления доступом к строкам в таблице базы данных. Например, вы можете предоставить работникам доступ только к тем строкам данных, которые связаны с работой их отдела. Еще одним примером является ограничение доступа к данным клиентов только к данным, соответствующим их компании в мультитенантной архитектуре. Эта функция аналогична безопасности на уровне строк в SQL Server.

Безопасность на уровне строк на уровне данных

Безопасность на уровне строк упрощает проектирование и кодирование безопасности в приложении. Безопасность на уровне строк помогает реализовать ограничения доступа к строкам данных.

Логика ограничения доступа находится на уровне базы данных, а не в одном уровне приложений. База данных применяет ограничения доступа при каждом попытке доступа к данным из любого приложения или платформы отчетов, включая Power BI. Это делает систему безопасности более надежной и устойчивой за счет уменьшения контактной зоны системы безопасности. Безопасность на уровне строк применяется только к запросам в конечной точке хранилища или аналитики SQL в Fabric. Запросы Power BI в хранилище в режиме Direct Lake возвращаются в режим Direct Query для соблюдения безопасности на уровне строк.

Ограничение доступа к определенным строкам определенным пользователям

Реализуйте RLS с помощью инструкции CREATE SECURITY POLICY Transact-SQL и предикаты, созданные как встроенные табличные функции.

Безопасность на уровне строк применяется к общему хранилищу или озеру, так как базовый источник данных не изменился.

Безопасность на основе предиката на уровне строк

Безопасность на уровне строк в Хранилище данных Fabric Synapse поддерживает безопасность на основе предиката. Предикаты фильтра автоматически фильтруют строки, доступные для операций чтения.

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

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

Предикат фильтра и политики безопасности имеют следующее поведение:

• Вы можете определить функцию предиката, которая присоединяется к другой таблице и (или) вызывает функцию. Если политика безопасности создана с использованием команды SCHEMABINDING = ON (по умолчанию), соединение или функция будут доступными из запроса и будут работать должным образом без каких-либо дополнительных проверок разрешений.

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

• Если пользователь dbo, член db_owner роли или владелец таблицы запрашивает таблицу с определенной и включенной политикой безопасности, строки фильтруются или блокируются, как определено политикой безопасности.

• Попытка изменить схему таблицы, связанной политикой безопасности привязки к схеме, приведет к ошибке. Тем не менее можно изменить столбцы, на которые не ссылается предикат.

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

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

• Определение нескольких активных политик безопасности, содержащих неперекрывающиеся предикаты, завершается успешно.

Предикаты фильтров имеют следующие особенности.

• Определение политики безопасности, которая фильтрует строки таблицы. Приложение не знает о каких-либо строках, отфильтрованных для SELECTопераций и DELETE тUPDATE. е. Включая ситуации, когда все строки отфильтровываются. Приложение может выполнять INSERT фильтрацию строк, даже если они будут отфильтрованы во время любой другой операции.

Разрешения

Для создания, изменения или удаления политик безопасности требуется ALTER ANY SECURITY POLICY разрешение. Для создания или удаления политики безопасности требуется ALTER разрешение на схему.

Кроме того, для каждого добавленного предиката требуются следующие разрешения:

• SELECT и REFERENCES разрешения для функции, используемой в качестве предиката.

• REFERENCES разрешение на целевую таблицу, привязанную к политике.

• REFERENCES разрешение на каждый столбец из целевой таблицы, используемой в качестве аргументов.

Политики безопасности применяются ко всем пользователям, включая пользователей dbo в базе данных. Пользователи dbo могут изменять или удалять политики безопасности, однако можно проводить аудит их изменений в политиках безопасности. Если члены ролей, таких как Администратор istrator, member или Member, должны видеть все строки для устранения неполадок или проверки данных, политика безопасности должна быть записана, чтобы разрешить это.

Если политика безопасности создана с SCHEMABINDING = OFFпомощью , то для запроса целевой таблицы пользователи должны иметь SELECT или EXECUTE разрешение на функцию предиката и любые дополнительные таблицы, представления или функции, используемые в функции предиката. Если политика безопасности создана с использованием SCHEMABINDING = ON (по умолчанию), при запросе целевой таблицы пользователями эти проверки разрешений не проводятся.

Вопросы безопасности: атаки на стороне канала

Рассмотрим и подготовьтесь к следующим двум сценариям.

Злонамеренный диспетчер политики безопасности

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

Тщательно созданные запросы

Можно вызвать утечку информации с помощью тщательно созданных запросов, использующих ошибки для эксфильтрации данных. Например, сообщить злоумышленнику знать, SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; что зарплата Джона Doe составляет ровно $ 100 000. Даже при наличии предиката безопасности для предотвращения ситуаций, когда злонамеренный пользователь может напрямую выполнять запросы о заработной плате других людей, пользователь может определить, когда запрос возвращает исключение деления на ноль.

Примеры

Мы можем продемонстрировать хранилище безопасности на уровне строк и конечную точку аналитики SQL в Microsoft Fabric.

В следующем примере создаются примеры таблиц, которые будут работать с хранилищем в Fabric, но в конечной точке аналитики SQL используются существующие таблицы. В конечной точке аналитики SQL нельзя, но вы можете CREATE TABLECREATE SCHEMAи CREATE FUNCTION.CREATE SECURITY POLICY

В этом примере сначала создайте схему sales, таблицу sales.Orders.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Создайте схему Security , функцию Security.tvf_securitypredicateи политику SalesFilterбезопасности.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Связанный контент

• Безопасность хранения данных в Microsoft Fabric
• Предоставление общего доступа к хранилищу и управление разрешениями
• Безопасность на уровне столбцов в хранилище данных Fabric
• Динамическое маскирование данных в хранилище данных Fabric

Следующий шаг

Реализация безопасности на уровне строк в Хранилище данных Fabric