Концепції моделі безпеки
Модель безпеки в Dynamics 365 Customer Engagement (on-premises) використовується для захисту цілісності та конфіденційності даних у організації Customer Engagement (on-premises) . Модель безпеки також сприяє ефективному доступу до даних і співпраці. Цілі моделі такі:
Надання багаторівневої моделі ліцензування для користувачів.
Надання користувачам доступу тільки до тих рівнів отримання інформації, що необхідні їм для виконання обов'язків.
Класифікація користувачів і робочих груп за ролями безпеки й обмеження доступу на основі цих ролей.
Підтримка обміну даними, щоб користувачі могли отримати доступ до об'єктів, якими вони не володіють, для співпраці на тимчасовій основі.
Заборона доступу до об'єктів, якими користувачі не володіють або до яких не надано спільний доступ.
Підрозділи, заходи безпеки на основі ролей, записів і полів об'єднуються і визначають загальні права доступу до інформації для користувачів у вашій організації Customer Engagement (on-premises).
Підрозділи
Організаційна одиниця – це група користувачів. Великі організації, які мають багато клієнтських баз, часто використовують багато організаційних одиниць для керування доступом до даних і визначення ролей безпеки, щоб користувачі мали змогу отримувати доступ до записів тільки у своїх організаційних одиницях. Додаткові відомості: Створення бізнес-одиниць
Система безпеки на основі ролей.
Ви можете використовувати безпеку на основі ролей, щоб групувати набори привілеїв у ролі , які описують завдання, які може виконувати користувач або команда. Customer Engagement (on-premises) включає набір попередньо визначених ролей безпеки, кожна з яких є набором прав, зібраних разом, щоб полегшити керування безпекою. Сукупність прав визначає можливість створювати, читати, писати, видалити й ділитися записами сутності певного типу. Для кожного права також визначаються межі застосування: на рівні користувача, підрозділу, для всієї ієрархії підрозділу або всієї організації.
Наприклад, якщо ви увійшли як користувач із роллю «Продавець», у вас є право читати, створювати повідомлення та користуватися спільним доступом до облікових записів для всієї організації, але ви можете видаляти лише інформацію власного облікового запису. Крім того, у вас немає права на виконання завдань системного адміністрування, таких як інсталяція оновлення продукту або додавання користувачів у систему.
Користувач із роллю «Віце-президент по продажах» може виконувати ширший набір завдань (і має більше прав), пов'язаних із переглядом і модифікацією даних і ресурсів, ніж користувач із роллю «Продавець». Користувач із роллю «Віце-президент по продажах» може, наприклад, читати та призначити будь-який обліковий запис будь-кому в системі, а користувач із роллю «Продавець» такого права не має.
Є дві ролі з дуже широкими правами: «Системний адміністратор» та «Настроювач». Щоб мінімізувати ймовірність неправильної конфігурації, використання цих ролей у вашій організації слід обмежити нечисленним персоналом, відповідальним за управління та настройку Customer Engagement (on-premises). Організації також можуть настроїти наявні і створити власні ролі для задоволення певних потреб. Додаткові відомості: Ролі безпеки
Доступ користувача та ліцензування
За промовчанням під час створення користувача користувач отримує доступ для читання й запису будь-яких даних, для яких у нього є дозвіл. Крім того, за промовчанням клієнтську ліцензію (CAL) користувача встановлено як Professional. Ви можете змінити будь-який із цих параметрів для подальшого обмеження доступу до даних і функцій.
Режим доступу. Виберіть потрібний рівень доступу для кожного користувача.
Доступ для читання й записування. За промовчанням користувачі мають доступ для читання й записування, що дає їм доступ до даних, для яких вони мають відповідні дозволи за ролями безпеки.
Адміністративний доступ. Дозволяє отримати доступ до областей користувачеві з відповідним дозволом, настроєним ролями безпеки, але не дозволяє користувачеві переглядати чи отримувати доступ до бізнес-даних, які зазвичай можна знайти в областях «Збут», «Послуга» та «Маркетинг», таких як бізнес-партнери, контактні особи, інтереси, потенційні угоди, кампанії та інциденти. Наприклад, адміністративний доступ може бути використаний для створення адміністраторів Customer Engagement (on-premises), які можуть мати доступ для виконання різноманітних адміністративних завдань, таких як створення підрозділів, користувачів, встановлення пошуку повторів, але не можуть переглядати чи використовувати бізнес-дані. Зверніть увагу, що користувачі, яким призначено цей режим доступу, не використовують CAL.
Доступ для читання. Дозволяє отримати доступ до областей, до яких користувач має відповідний доступ, установлений роллю безпеки. Але користувач з доступом для читання може лише переглядати дані і не зможе створити або змінити наявні дані. Наприклад, користувачі з роллю безпеки системного адміністратора, які мають доступ для читання, можуть переглядати підрозділи, користувачів і робочі групи, але не можуть створити або змінити ці записи.
Тип ліцензії. Визначає користувача CAL і визначає, які функції та області доступні для користувача. Ця функція та елемент керування області є окремо від параметра ролі безпеки користувача. За промовчанням користувачі створюються з CAL Professional для доступу до більшості функцій та областей залежно від наданих їм дозволів.
Робочі групи
Команди дають змогу легко ділитися бізнес-об'єктами і дозволяють співпрацювати з іншими користувачами з інших підрозділів. Хоча робоча група належить до одного підрозділу, вона може містити користувачів з різних підрозділів. Користувача можна пов'язати з більш ніж однією робочою групою. Додаткові відомості: Керування командами
Система безпеки на основі записів
Можна використовувати систему безпеки на основі записів для керування правами користувачів і робочих груп щодо дій із окремими записами. Це застосовується до екземплярів сутностей (записів) і передбачено правами доступу. Власник запису може надавати доступ до нього іншому користувачу або робочій групі. Коли це буде зроблено, власник повинен визначати, які саме права буде надано. Наприклад, власник інформації облікового запису може надати право на її читання, але не надавати права на запис.
Права доступу застосовуються лише після того, як права набрали сили. Наприклад, якщо користувач не має права на перегляд інформації (читання) облікового запису, йому не вдасться переглянути жоден обліковий запис, незалежно від права доступу, яке інший користувач може надати йому для конкретного облікового запису, забезпечивши до нього спільний доступ.
Ієрархічна система безпеки
Модель ієрархічної безпеки можна застосовувати для доступу до ієрархічних даних. Завдяки додатковим функціям безпеки надається більш гранулярний доступ до записів, що дозволяє керівникам отримувати доступ до записів власних підлеглих або виконувати роботу від їх імені. Додаткові відомості: Ієрархічна безпека
Змінення параметрів безпеки на основі полів
Використовуючи функції безпеки на рівні полів, можна обмежити доступ до певних настроюваних полів у сутності, вміст яких матиме значний вплив на ведення комерційної діяльності, надавши доступ лише окремим користувачам або групам. Як і для системи безпеки на основі записів, це застосовується після того, як права набрали сили. Наприклад, користувач може мати право на перегляд інформації облікового запису, але йому може бути заборонено переглядати певні поля в усіх облікових записах. Додаткові відомості: Безпека на рівні поля
Моделювання системи безпеки за допомогою Customer Engagement (on-premises)
Щоб отримати докладні відомості та практичні поради щодо розробки моделі безпеки в Customer Engagement (on-premises) Україні, ознайомтеся з технічним документом Масштабоване моделювання безпеки за допомогою Microsoft Dynamics CRM , доступним у Центрі завантажень Microsoft.
Див. також
Безпека на рівні поля
Ієрархічна система безпеки
Контролюйте доступ до даних
Створіть або відредагуйте роль безпеки
Копіювання ролі безпеки
Керування користувачами
Керування робочими групами
Додайте робочі групи або користувачів до профілю безпеки поля
Керуйте безпекою, користувачами та командами