Безопасность на уровне строк в Fabric Data Warehouse

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрешения

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

В следующем примере создаются примеры таблиц, которые будут работать с хранилищем в Fabric, но в конечной точке аналитики SQL используются существующие таблицы. В конечной точке аналитики SQL нельзя CREATE TABLE, но вы можете CREATE 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

Чтобы изменить функцию безопасности на уровне строк, необходимо сначала удалить политику безопасности. В следующем скрипте мы удаляем политику SalesFilter перед выполнением инструкции ALTER FUNCTION для Security.tvf_securitypredicate. Затем мы повторно создадим политику SalesFilter.

-- Drop policy so we can change the predicate function.
DROP SECURITY POLICY SalesFilter;
GO

-- Alter the function for the SalesRep evaluation
ALTER 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() = 'president@contoso.com';
GO
 
-- Re-create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

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

Реализовать безопасность на уровне строк в Fabric Data Warehouse

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

  • Last updated on