Как правильно создавать новые и использовать существующие SecurityKey

[Poleax]

2Владимир Максимов

Цитата:

Best Practice в данном вопросе бесполезен. Из него совершенно не понятно надо ли давать права на ключи или на объекты; надо ли создавать новые ключи. Он просто констатирует то, что есть сейчас

Как это бесполезен? Там четко написано как и на каких объектах использовать и как именовать ключи.

Зачем использовать ключи Applying Security Keys

Цитата:

Applying Security Keys
The main reasons to apply user-level security are to:

• Allow users to do only their designated tasks.
• Protect sensitive data in the database.
• Prevent users from inadvertently breaking an application by changing code or objects on which the application depends.

You need to apply a security key to:

• Tables
• Views
• Menus
• Menu items
• Form controls
• Report controls

Именование ключей Best Practices for Configuration and Security Keys

Цитата:

One of the nine security keys on a branch (the parent) should take the name of the module. For example, BOM. The other keys (up to eight more on a branch) should have the name of the module followed by one of the following suffixes: Daily, Journals, Inquiries, Reports, Periodic, Setup, Misc, or Tables. For example, BOMReports, BOMSetup, and LedgerPeriodic.

Enterprise Portal keys should have a prefix of EP followed by the name of the role. For example, EPAdmin and EPConsultant. Additional security keys for the role should take one of these suffixes: Misc, Info, Report, or Task. For example, EPAdminInfo and EPConsultantTask.

[Владимир Максимов]

Цитата:

Сообщение от Poleax

2Владимир Максимов
Как это бесполезен? Там четко написано как и на каких объектах использовать и как именовать ключи.

Это не то. Это рекомендации по созданию новых Security Keys и некие общие слова о том, как в принципе их можно использовать. А права доступа-то как настраивать? Не в смысле через какую форму, а сама идеология (концепция) настройки прав.

Ну, вот каким образом коррелируются те цитаты, которые Вы привели с тем что описывают в данной теме все остальные участники? Где, в каком месте Best Practices говорится о том, что надо настраивать права не самих Security Keys, а подчиненных объектов? А права Security Keys настривать как раз не надо.

[Ivanhoe]

Цитата:

Сообщение от Владимир Максимов

Это не то. Это рекомендации по созданию новых Security Keys и некие общие слова о том, как в принципе их можно использовать. А права доступа-то как настраивать? Не в смысле через какую форму, а сама идеология (концепция) настройки прав.

Если нужен официальный документ - то вот.
Там и кратко про ключи, и про концепцию и как искать сложные случаи при настройке прав )

Еще хороший блог.

[Владимир Максимов]

Цитата:

Сообщение от Ivanhoe

Если нужен официальный документ - то вот.
Там и кратко про ключи, и про концепцию и как искать сложные случаи при настройке прав )

Еще хороший блог.

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

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Так вот, ЭТИХ правил в приведенных описаниях нет.

[Ivanhoe]

Цитата:

Сообщение от Владимир Максимов

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

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Так вот, ЭТИХ правил в приведенных описаниях нет.

Цитата:

Approaches to Granting Security
There are a few things to consider when approaching security. For some it is best to begin with the highest permissions level and restrict access to specific objects. For others, it is best to begin with the lowest level and grant access to objects. The best approach may vary for each user group.

The advantage to starting will the highest level and then restricting specific objects is that it leaves permission granted to the parent keys, such as the “Accounts Receivable” key. On its own, this key grants nothing to a user that they can see in the application, but for some operations the inherited pieces may be necessary.

Alternatively, starting with the least access and granting has the advantage of keeping the application as locked down as possible. The disadvantage here is that when a parent key is needed, it must be turned on. This will grant access to all child keys. This means that you must go back and restrict access again, and essentially doubles the effort in a case that the need for a parent key is found.

...

Т.е. многие (в т.ч. я) идут по второму пути - более строгому и защищенному. Но есть более простой способ (и многие идут именно по нему) - давать права от ключей.

[Владимир Максимов]

Цитата:

Сообщение от Ivanhoe

Approaches to Granting Security
(...)

А это откуда цитата?

PS: Извините, уже нашел. Это из MicrosoftDynamicsAX2009Security.pdf "Understanding Security in Microsoft Dynamics AX 2009"