Extensible Data Security Policies в DAX 2012

Contents

1 Новые возможности
2 Концепции политики
3 Разработка политики XDS
4 Эффективность политики XDS
- 4.1 Использование конструкций XDS для минимизации издержек производительности
5 Отладка политики XDS

Новые возможности

Система Extensible Data Security (далее XDS) это новый механизм безопасности в DAX 2012, позволяющий разработчикам и администраторам защищать данные в общих таблицах так, что пользователь имеет доступ только к части таблицы, которая разрешена принудительной политикой. Эти возможности могут быть использованы совместно с ролями безопасности, чтобы предоставить более комплексную защиту, чем была возможна ранее.

XDS это эволюция системы Record-Level Security (RLS), которая была доступна в более ранних версиях Microsoft Dynamics AX. Развернутые политики XDS применяются независимо от того, доступны ли данные на формах клиента Dynamics AX, веб-страницах Enterprise Portal, отчетах SSRS или службах .Net.

Концепции политики

Во время разработки политики, необходимо познакомиться с несколькими концепциями, такими как:

constrained tables (таблицы с ограничениями);
primary tables (первичные таблицы);
policy queries (запросы политики);
context (содержание).

Таблица с ограничениями

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

Первичная таблица

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

Запрос политики

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

Содержание

Содержание политики — это часть информации, контролирующей условия, при которых данная политика считается применимой. Если содержание не установлено, то даже если политика активирована, она не будет применяться.

Разработка политики XDS

Разработка включает в себя следующие шаги:

Моделирование запроса на основании первичной таблицы.
Создание политики.
Добавление в политику таблиц с ограничениями и представлений.
Настройка содержания.

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

Проектирование и моделирование запроса политики

Запрос политики и таблица или таблицы, которые будут ограничены, это два самых важных аспекта в политике XDS. Запрос политики будет добавлен в выражение WHERE (или ON) во все операции SELECT, UPDATE, DELETE и INSERT каждой указанной ограничиваемой таблицы. Если не уделить должное внимание моделированию и тестированию, то запрос политики может иметь существенное влияние на производительность.

Создадим в качестве примера политику, которая в конечном счете будет ограничивать записи в нескольких таблицах, таких как AssetTable и BankChequeTable. Таким образом, пользователи, являющиеся поставщиками, могли видеть только их собственные записи.

Чтобы спроектировать и разработать запрос политики нужно:

Определить первичную таблицу. В нашем случае, это будет VendTable.
Создать модель запроса в ветке АОТ > Queries

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

Модель запроса представлена ниже. Видно, что ограничение формируется по полю UserId таблицы DirPersonUser.

Создание политики

После того как запрос был создан, следующим шагом является создание политики в ветке AOT > Security > Policies:

Создать политику безопасности и назвать ее VendProfileAccount.
Установить для свойства PrimaryTable значение VendTable.
Установить для свойства Query значение VendProfileAccountPolicy.
Установить для свойства PolicyGroup значение Vend Self Service. Значение данного свойства может быть использовано разработчиками или администраторами для быстрого определения групп связанных политик. Данное свойство не используется в работе политики.
Если требуется защитить первичную таблицу этой политикой, то необходимо для свойства ConstrainedTable установить значение Да.
Установить для свойства Enabled значение Да. Данное свойство контролирует применение политики в процессе работы приложения.
Свойство ContextType может принимать следующие значения:

ContextString – если для определения необходимости применения политики должен использоваться глобальный контекст. При необходимости эта строка должна быть установлена приложением с помощью API XDS::SetContext().
RoleName – политика должна быть применена, только если пользователь включен в определенную роль, которая определяет доступ к таблицам с ограничениями.
RoleProperty — политика должна быть применена, только если пользователь является членом одной из ролей, у которой свойство ContextString имеет одинаковое значение с данным свойством.

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

Можно увидеть, что для свойства ContextType установлено значение ContextString. Но для свойства ContextString значение не задано. Такая комбинация подразумевает, что после активации политики, она будет применяться всегда.

Добавление таблиц с ограничениями и представлений

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

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

После этого политика готова к разворачиванию. После установления свойства Enabled =
Да, политика будет применена для всех пользователей, попадающих под ее содержание, кроме пользователей с ролью SysAdmin.

Настройка контекста политики

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

В политике для свойства ContextType установить значение RoleProperty.
В политике для свойства ContextString установить значение ForAllVendorRoles.

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

В AOT нужно
зайти в
ветку
ролей. В качестве примера взять роль VendVendor.
В роли для свойства ContextString установить значение ForAllVendorRoles.

Эффективность политики XDS

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

Следовать стандартам Best Practices разработки эффективных запросов. Например, создавать индексы для условий соединения.
Уменьшать количество соединений в запросе. Сложная и нормализованная модель данных может привести к запросу с очень большим количеством соединений. Требуется рассмотреть изменение модели данных или применение шаблонов, таких как конструкции XDS, чтобы сократить количество соединений во время работы.

Использование конструкций XDS для минимизации издержек производительности

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

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

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

Конструкции XDS – это временные таблицы, которые заполняются один раз для каждой сессии клиента. Эти таблицы можно увидеть в ветке AOT > Data Dictionary > Tables.

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

На рисунке ниже показа пример запроса политики, который использует конструкцию MyLegalEntitiesForRole.

Запрос HcmXdsApplicantLegalEntity включает в себя 4 соединенных источника данных. Последним источником данных является конструкция MyLegalEntitiesForRole, которая инкапсулирует (объединяет в один объект) несколько соединений. Если бы конструкция XDS не использовалась, то этот запрос потребовал бы соединения через еще четыре таблицы в каждом применении политики – это значительное снижение производительности.

В этом сценарии, использовании конструкции XDS позволило преобразовать запрос политики с семью и более соединениями в запрос с четырьмя соединениями — это значительное повышение производительности.

Отладка политики XDS

Одной из распространённых проблем является, то что, когда развернута новая политика XDS, из таблиц с ограничениями возвращается неожиданное количество записей. Например, большее количество заказов на продажу было получено, чем ожидалось, если заказы ограничиваются данной группой клиентов.

Первое, что необходимо посмотреть в данной случае, это какой SQL запрос был сгенерирован. В AX 2012 представлен легкий метод отладки. Оператор select языка X++ был расширен командой generateonly,
которая инструктирует систему доступа к данным, что требуется сгенерировать SQL запрос без его выполнения. Сгенерированный запрос может быть возвращен вызовом простого метода.

В примере ниже генерируется запрос к таблице SalesTable и после с помощию метода getSQLStatement выводится в инфолог.

Пример:

static void VerifySalesQuery(Args _args)
{
    SalesTable salesTable;
    XDSServices xdsServices = new XDSServices();

    xdsServices.setXDSContext(1, '');

    //Only generate SQL statement for custGroup table
    select generateonly forceLiterals CustAccount, DeliveryDate from salesTable;
    //Print SQL statement to infolog
    info(salesTable.getSQLStatement());

    xdsServices.setXDSContext(2, '');
}

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