8-800-700-15-02

Звонок по России
бесплатный

info@i-neti.ru

Фреймворк Extensible Data Security (XDS) в Dynamics 365 Finance for Operations

asd
Дата публикации: 13.03.2019
Фреймворк Extensible Data Security (XDS) в Dynamics 365 Finance for Operations

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

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

 

Концепция политики безопасности данных

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

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

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

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

         •   Контекст — это часть информации, устанавливающая условия, при которых политика будет применяться. Контекст имеет две категории:

  • Контекст на основе ролей активирует политику, основываясь на роли безопасности текущего пользователя
  • Контекст приложения активирует политику, основываясь на наборе данных приложения

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

 Перед тем как приступить к разработке политик XDS нужно понять пару вещей:

         •    Понять необходимый бизнес-сценарий или ответить на вопрос «Почему мы используем XDS?»

         •    Определить первичную и защищаемую таблицу, а также определить связи между ними

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

 

Возможный бизнес-сценарий

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

        1.   Первым делом мы должны определить наши таблицы с ограничениями, а также первичную таблицу, в текущем примере таблица CustTable это таблица с ограничениями, а таблица CustGroup первичная таблица.

        2.   Дальше мы создадим запрос безопасности с таблицей CustGroup

  • Для этого создадим новый Query, установим в качестве источника данных первичную таблицу, а затем выполним наложение фильтров или присоединение других источников, для того чтобы запрос возвратил тот результат, который нам необходим
  • В данном случае мы установим ограничение для пользователя, чтобы он мог видеть только клиентов с группой «10» и именем «Важные клиенты»

 

3.   Теперь мы можем создать нашу политику безопасности и установить следующие свойства для нее

  • Constrained Table в значение Yes
  • Primary Table в значение CustGroup
  • Query установим имя запроса данных, созданного на этапе 2

 

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

4.           Затем мы добавляем защищаемую таблицу в политику, в нашем случае CustTable и устанавливаем следующие параметры:

  • Имя защищаемой таблицы (CustTable)
  • Имя первичной таблицы в поле Table Relation (CustGroup)

5.           Теперь если мы соберем решение и сделаем синхронизацию базы данных, то наша политика XDS начнет работать. Чтобы показать, как это работает, я сделал два примера с применением роли безопасности FpTestRole (один результат сделан до применения и один результат после). 

Доступ пользователя без применения XDS

Доступ пользователя после применения политики XDS

 

Теперь следующий вопрос, как применить политику XDS сразу к группе ролей? Что ж именно здесь вступают в игру параметры Context Type и Context String. Параметр Context Type определяет, как параметр Context String обрабатывается. Context Type имеет три различные опции:

•       ContextString – используется если вы хотите поменять значение параметра Context String через X++ код (посредством метода XDS::SetContext)

•       RoleName – следует использовать если вы хотите использовать политику только для одной роли. Имеет схожий эффект с полем Role name.

•       RoleProperty – позволяет применять политику ко множеству ролей через значение Context String, если роль имеет такое же значение Context string, то к ней также будет применяться политика

Если мы установим Context Type в значение RoleProperty, то любая роль со строкой контекста, которую мы введем в параметр Context String, будет сопоставлена с данной XDS политикой. Так если мы установим значение CustGroup_XDSPolicy в параметр Context String,

а затем если установим такое же значение Context String на роли, то любой пользователь назначенный на данную роль, будет подвержен XDS политике.

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

Используя XDS с Dynamics 365 FO можно столкнуться с проблемами производительности запросов на таблицах, поэтому главная задача - это минимизировать эти потери. Вот пара вещей, которые нужно держать в уме:

•             Следуйте стандартным best practices при разработке запросов SQL (используйте индексы на выражениях join, применяйте правильные первичные ключи и т.д.)

•             Упрощайте запросы при любой возможности, не используйте избыточные соединения между таблицами.

Как исправлять ошибки

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

•             Выполнить кусок X++ кода чтобы посмотреть на SQL запрос, сформированный XDS политикой

•             Запустите запрос SELECT для ModelSecPolRuntimeEx чтобы увидеть понятный для восприятия запрос для данной XDS политики

  •   Например, если мы взглянем на CustomerGroupPolicy из примера выше в таблице столбец ModeledQueryDebugInfo покажет сформированный запрос SQL.

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

 

Акция "Тест-драйв Сопровождения"

Попробуй сопровождение АХ до подписания договора!


Узнать подробнее

Другие записи в блоге

18.06.2019
В этом видеоуроке Дмитрий говорит про Unit тесты в Dynamics 365 for finance and operations. Рассматриваются такие вопросы, как:1. Что такое Unit тесты и зачем они нужны.2. Виды тестов на платформе...
18.05.2019
В нашем плейлисте Dynamics 365FO (ссылка на плейлист) опубликовано новое видео про платформу PowerApps.На этом вебинаре Дмитрий познакомил участников с теоретической частью создания приложений на...
29.04.2019
Microsoft Dynamics 365 for Finance and Operations вступил в так называемую эру One Version (Единой Версии), в которой клиенты распрощаются с привычными апгрейдами ERP и будут применять непрерывную,...

Подпишитесь на блог

Все интересные статьи нашего блога на Вашем почтовом ящике!


Подписка

Служба контроля качества сервиса

Свои пожелания и отзывы о качестве обслуживания Вы можете оставить в разделе


Письмо директору