Вы находитесь на странице: 1из 14

Microsoft Dynamics AX 2012 ®

Разработка политики безопасности


данных Extensible
Белая бумага

Расширяемая система безопасности данных является мощной новой функцией в Microsoft


Dynamics AX 2012, которые могут позволить разработчикам и администраторам обеспечить
комплексную защиту данных, используя богатые политики. В этом документе описываются шаги
по разработке политики, которые имеют минимальные накладные расходы
производительности.

Дата: Январь, 2011

http://microsoft.com/dynamics/ax

Автор: Arindam Чаттерджи, главный ведущий менеджер программы, Microsoft


Dynamics AX

Предложения и комментарии по этому документу


adocs@microsoft.com , Пожалуйста, включите название с обратной связью.
Содержание

Введение ................................................. ............................................... 3

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


Зависимая таблица ................................................ .................................................. ................ 3
Первичная таблица ................................................ .................................................. ..................... 3
Политика запросов ................................................ .................................................. ....................... 3
Контекст ................................................. .................................................. ............................ 3

Разработка расширяемой политики безопасности данных ............................................ . 3


Проектирование и моделирование запроса политики ............................................ ..................................... 4
Создание политики ............................................... .................................................. ............... 5
Добавление ограниченных таблиц и представлений ............................................. .......................................... 6
Установка контекста политики .............................................. .................................................. ...... 8

Разработка эффективных расширяемых политик безопасности данных ................................. 9


Использование расширяемой безопасности данных конструкций для минимизации накладных расходов производительности ............................... 9

Отладка расширяемых политик безопасности данных ............................................. 11

Резюме ................................................. ................................................. 13

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


Введение
Расширяемая система безопасности данных является новой функцией в Microsoft Dynamics ® AX 2012, что позволяет разработчикам и администраторам
для защиты данных в общих таблицах таким образом, что пользователи имеют доступ только к части таблицы, разрешенная к насильственному политики.
Эта функция может быть использована в сочетании с ролевой безопасностью (также поддерживается в Microsoft Dynamics AX 2012), чтобы обеспечить
более всеобъемлющую безопасность, чем это было возможно в прошлом.

Extensible безопасность данных является эволюцией безопасности на уровне записей (RLS), который был доступен в более ранних версиях
Microsoft Dynamics AX. политики Extensible безопасности данных, при развертывании исполняется, независимо от того, являются ли данные,
доступа через AX богатых клиентов форм Microsoft Dynamics, веб-страницы корпоративного портала, сообщает SSRS или .NET Services.

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

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

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

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

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

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

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

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

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

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

Разработка расширяемой политики безопасности данных


Разработка расширяемой политики безопасности данных включает в себя следующие шаги:

1. Моделирование запроса на основной таблице.

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


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

3. Добавление затрудненных таблиц и представлений.

4. Установка контекста.

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

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

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

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

Для проектирования и разработки запроса политики для этой политики:

1. Определить основную таблицу. В этом случае основной таблицы VendTable.

2. Создать смоделированный запрос под AOT Запросы узел:

• Используйте VendTable в качестве первого источника данных.

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

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


На рисунке 1 показан запрос.

Рисунок 1: Политика запрос на первичной таблице

Создание политики
Теперь, когда запрос политики был создан, следующий шаг заключается в создании политики себя под АОТ безопасности > полисы узел.

1. Щелкните правой кнопкой мыши АОТ безопасности > политика узел и выберите Новая политика безопасности.

2. Установить PrimaryTable собственности на политику в VendTable.

3. Установить запрос собственности на политику в VendProfileAccountPolicy.

4. Установить PolicyGroup свойство Производитель Self Service.


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

5. Если вы хотите, основной таблицы, чтобы быть защищены с помощью этой политики, установите ConstrainedTable
свойство Да.

6. Установить Включено свойство да или Нет. Это свойство может быть использовано для управления ли
политика будет обеспечиваться посредством расширяемого выполнения защиты данных.

7. Установить ContextType свойство к одному из следующих признаков:

• ContextString - Установите свойство этого значения, если глобальный контекст должен использоваться, чтобы определить, следует
ли применять политику. При необходимости, этот контекст строка должна быть установлена ​приложением с помощью XDS ::
SetContext API.

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

• RoleProperty - Установите свойство этого значения, если политика будет применяться только тогда, когда пользователь является членом какой-либо
одной из множества ролей, которые имеют те ContextString свойство установлено одинаковое значение (см Установка контекста политики далее в этой
статье для деталей для более подробной информации).

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


Пример политики создали можно увидеть на рисунке 2. Обратите внимание, что ContextType недвижимость в настоящее время устанавливается
на значение ContextString, но ContextString Свойство пусто. Эта комбинация означает, что, когда включена, эта политика всегда будет
применяться.

Рисунок 2: Свойства политики

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

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

Для добавления стесненных таблиц или представлений:

1. Щелкните правой кнопкой мыши Зависимые Столы узел.

2. Нажмите Новый> Добавить таблицу добавить таблицу с ограничениями, например, таблицу AssetBook.

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

3. Нажмите Новый> Добавить вид добавить ограниченный View этой политики.

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

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


Рисунок 3 показывает, что такая политика будет выглядеть в АОТ.

Рисунок 3: Заключительная политика VendProfileAccount

На данный момент, политика готова к развертыванию. Когда Включено свойство имеет значение Да, политика будет функционировать в полном объеме для всех
пользователей, пытающихся получить доступ к таблицам (или представления) в
Зависимые Столы узел. Обратите внимание, что политика безопасности не применяются для системных администраторов (т.е. пользователей в роли
SysAdmin).

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


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

1. Изменить ContextType свойство на узле политики в RoleProperty.

2. Установить ContextString свойство на узле политики в ForAllVendorRoles ( Рисунок 4).

Рисунок 4: Политика в контексте роли

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

1. Переход к узлу AOT, соответствующий каждой роли, которую необходимо, связанному с этим
политики, например, VendVendor роль.

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


2. Установить ContextString недвижимость на VendVendor роль узла в ForAllVendorRoles ( видеть
Рисунок 5).

Заметка ContextString свойство не локализован. Таким образом, только культура нейтральной строки следует использовать для этого
свойства.

Рисунок 5: Настройка контекста на роли поставщика

Разработка эффективных расширяемых политик безопасности данных


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

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

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

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

производительность

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

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

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


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

Extensible конструкции защиты данных временные таблицы, заполняемые один раз для каждого сеанса клиента. Они существуют в
AOT под Словарь данных> Столы узел (рисунок 6).

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

Рисунок 6: MyLegalEntitiesForRole конструкция

10

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


На фиг.7 показан пример запроса политики, который выгодно используется MyLegalEntitiesForRole построить.

Рисунок 7: запрос политики с использованием MyLegalEntitiesForRoles

HcmXdsApplicantLegalEntity запрос предусматривает соединение по четырем источникам данных. Четвертый источник данных является MyLegalEntitiesforRole
построить, который инкапсулирует несколько соединений. Если расширяемая конструкция защиты данных не использовалось, этот запрос был бы
вовлечено присоединяется через более четырех таблиц на каждой прикладной значительной потере производительности политики.

В этом случае, задействуя конструкция безопасности расширяемых данных конвертируется запрос политики с семью или более присоединяется в запрос политики с
четырьмя Объединяет-существенный приростом производительности.

Отладка расширяемых политик безопасности данных


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

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

11

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


статической силы VerifySalesQuery (Args _args)
{
SalesTable salesTable;
XDSServices xdsServices = новые XDSServices ();

xdsServices.setXDSContext (1 '');

// Только генерировать заявление SQL для custGroup таблицы


Выбрать generateonly forceLiterals CustAccount, DeliveryDate от salesTable;

// Печать SQL заявление INFOLOG


Информация (salesTable.getSQLStatement ());

xdsServices.setXDSContext (2, '');


}

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

SELECT [PRIMARYTABLEAOTNAME], [QUERYOBJECTAOTNAME],


[CONSTRAINEDTABLE], [MODELEDQUERYDEBUGINFO],
[CONTEXTTYPE], [CONTEXTSTRING],
микросхемой generateonly команда. Затем он называет getSQLStatement () на SalesTable и отвалов вывод с помощью информации API.
[IsEnabled], [ISMODELED]
ОТ [AXDBDEV]. [DBO]. [ModelSecPolRuntimeEx]

На рисунке 8 показаны результаты запроса.

Рисунок 8: Выход запроса

12

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ В следующем задании выполняется запрос на выборку на SalesTable с
Как вы можете видеть на рисунке 8, запрос, который будет добавлен к статье WHERE любого запроса к таблице AssetBook доступен для
отладки. Другие метаданные, такие как LayerId, также доступны в случае необходимости.

Первый метод отладки рекомендуется для большинства сценариев.

Резюме
Расширяемая система безопасности данных является мощной новой функцией в Microsoft Dynamics AX 2012, которые были сделаны доступными для
разработчиков и заказчиков для решения богатых сценариев политики безопасности данных. В этом документе введены понятия, связанные с расширяемой
безопасностью данных и при условии, руководства шага bystep к разработке расширяемых политик безопасности данных. Как и с любой мощной функцией,
разработчики должны быть осведомлены о проблемах, которые могут возникать. В этом документе охвачены некоторые советы и приемы и каркасные
предоставленные конструкции, которые помогают облегчить проблемы с производительностью и легкостью отладки, которые могут потребоваться.

13

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ


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

США и Канада Toll Free 1-888-477-7989 по всему миру +


1-701-281-6500 www.microsoft.com/dynamics

Этот документ предоставляется -по-is.‖ Информация и мнения, высказанные в этом документе, включая URL-адреса и другие ссылки на веб-сайте, могут быть изменены без
предварительного уведомления. Вы несете риск его использования. Некоторые примеры, изображенные здесь предусмотрены только для иллюстрации и являются
фиктивными. Нет связи с реально существующими объектами не предполагается и не подразумевается.

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

© 2011 Microsoft Corporation. Все права защищены.

Microsoft, то Microsoft Dynamics Логотип и Microsoft Dynamics являются товарными знаками группы компаний Майкрософт.

Все другие торговые марки являются собственностью их владельцев.

14

РАЗРАБОТКА Extensible ПОЛИТИКИ БЕЗОПАСНОСТИ ДАННЫХ

Оценить