Поділитися через

Рекомендації щодо керування ідентифікацією та доступом

Стосується цієї Power Platform рекомендації щодо контрольного списку Well-Architected Security:

СЕ:05 Застосовуйте суворе, умовне та контрольоване керування ідентифікацією та доступом (IAM) для всіх користувачів робочого навантаження, членів команди та компонентів системи. Обмежте доступ виключно до в міру необхідності. Використовуйте сучасні галузеві стандарти для всіх реалізацій аутентифікації та авторизації. Обмежуйте та суворо перевіряйте доступ, який не залежить від особистості.

У цьому посібнику описано рекомендації щодо автентифікації та авторизації профілів, які намагаються отримати доступ до ресурсів вашого робочого навантаження.

З точки зору технічного контролю, ідентичність завжди є основним периметром. Цей обсяг включає не лише межі вашого робочого навантаження. Він також включає окремі компоненти, які знаходяться всередині вашого робочого навантаження.

До типових ідентичностей належать:

  • Люди. Користувачі додатків, адміністратори, оператори, аудитори та зловмисники.
  • Системи. Посвідчення робочого навантаження, керовані посвідчення, ключі API, керівники служб і ресурси Azure.
  • Анонім. Суб’єкти, які не надали жодних доказів про те, хто вони є.

Визначення

Терміни Визначення
Аутентифікація (AuthN) Процес, який перевіряє, що особистість – це хто або що вона видає.
Авторизація (AuthZ) Процес, який перевіряє, чи має особа дозвіл на виконання запитуваної дії.
Умовний доступ Звід правил, який дозволяє діяти на основі заданих критеріїв.
ІДП Постачальник посвідчень, як-от Microsoft Entra ID.
Портрет Посадова функція або посада, яка містить набір обов’язків і дій.
Стандартні ключі Тип секрету, який передається постачальнику та споживачу та використовується за допомогою безпечного та узгодженого механізму.
Ідентичність ресурсу Ідентичність, визначена для хмарних ресурсів, якими керує платформа.
Role Набір дозволів, які визначають, що може робити користувач або група.
Scope Різні рівні організаційної ієрархії, де дозволено виконувати певну роль. Також група функцій в системі.
Принципал безпеки Посвідчення, яке надає дозволи. Це може бути користувач, група або керівник служби. Будь-які учасники групи отримують однаковий рівень доступу.
Ідентифікація користувача Особистість для людини, наприклад, співробітника або зовнішнього користувача.
Ідентичність робочого навантаження Системний ідентифікатор програми, служби, сценарію, контейнера або іншого компонента робочого навантаження, який використовується для автентифікації в інших службах і ресурсах.

Нотатка

Ідентичність може бути згрупована з іншими, подібними профілями під батьківським елементом , який називається принципом безпеки. Група безпеки є прикладом принципала безпеки. Цей ієрархічний зв’язок спрощує обслуговування і покращує узгодженість. Оскільки атрибути ідентичності не обробляються на індивідуальному рівні, ймовірність помилок також зменшується. У цій статті термін «ідентичність » включає в себе принципи безпеки.

Microsoft Entra ID як постачальник посвідчень для Power Platform

Усі Power Platform продукти використовують Microsoft Entra ідентифікатор (раніше OR Azure Active Directory Azure AD) для керування ідентифікацією та доступом. Entra ID дозволяє організаціям захищати та керувати ідентифікацією для своїх гібридних та мультихмарних середовищ. Entra ID також необхідний для управління бізнес-гостями, яким потрібен доступ до Power Platform ресурсів. Power Platform також використовує Entra ID для управління іншими додатками, яким потрібно інтегруватися з Power Platform API за допомогою можливостей принципала сервісу. Використовуючи Entra ID, Power Platform ви можете використовувати більш розширені функції безпеки Entra ID, такі як умовний доступ і безперервна оцінка доступу.

Автентифікація

Автентифікація – це процес, який перевіряє особистість. Особистість, яка подає запит, повинна надати певну форму посвідчення особи, яку можна перевірити. Приклад.

  • Ім’я користувача та пароль.
  • Спільна секретна інформація, як-от API-ключ, що надає доступ.
  • Токен підпису спільного доступу (SAS).
  • Сертифікат, який використовується для взаємної автентифікації Transport Layer Security (TLS).

Автентифікація Power Platformпередбачає послідовність запитів, відповідей і переспрямувань між браузером клієнта та Power Platform або службами Azure. Послідовність відповідає потоку Microsoft Entra грантів ID auth коду.

Підключення та автентифікація до джерела даних здійснюється окремо від автентифікації у службі Power Platform. Щоб отримати додаткові відомості , перегляньте статтюПідключення та автентифікація до джерел даних.

Авторизація

Power Platform використовує Microsoft Entra ID Microsoft Identity Platform для авторизації всіх викликів API за стандартним галузевим OAuth протоколом 2.0.

Ключові стратегії дизайну

Щоб зрозуміти потреби в ідентифікації для робочого навантаження, потрібно перерахувати потоки користувачів і системи, активи робочого навантаження та персони, а також дії, які вони виконуватимуть.

Кожен випадок використання, ймовірно, матиме свій власний набір елементів керування, які вам потрібно розробляти з урахуванням припущення. Виходячи з вимог до ідентичності випадку використання або персон, визначте умовні варіанти. Уникайте використання одного рішення для всіх випадків використання. І навпаки, контроль не повинен бути настільки деталізованим, щоб ви вводили непотрібні накладні витрати на управління.

Вам потрібно зареєструвати слід доступу до посвідчення особи. Це допоможе перевірити елементи керування, і ви зможете використовувати журнали для аудиту відповідності.

Визначте всі профілі для автентифікації

Доступ ззовні. Автентифікація Power Platformпередбачає послідовність запитів, відповідей і переспрямувань між браузером клієнта та Power Platform або службами Azure. Послідовність відповідає потоку Microsoft Entra грантів ID auth коду. Power Platform Автоматично автентифікує всіх користувачів, які звертаються до робочого навантаження для різних цілей.

Доступ зсередини. Вашому робочому навантаженню потрібно буде отримати доступ до інших ресурсів. Наприклад, читання або запис на платформу даних, отримання секретів із секретного сховища та реєстрація телеметрії в службах моніторингу. Можливо, йому навіть знадобиться отримати доступ до сторонніх сервісів. Це все вимоги до ідентичності робочого навантаження. Однак вам також потрібно враховувати вимоги до ідентичності ресурсу; Наприклад, як працюватимуть і проходитимуть автентифікацію пайплайни розгортання.

Визначаємо дії для авторизації

Далі вам потрібно знати, що намагається зробити кожен автентифікований ідентифікатор, щоб ці дії можна було авторизувати. Дії можна розділити за типом доступу, який вони вимагають:

  • Доступ до площини даних. Дії, що відбуваються в площині даних, викликають передачу даних. Наприклад, програма, яка зчитує або записує дані з Microsoft Dataverse неї, або записує логи в Application Insights.

  • Доступ до керуючої площини. Дії, що відбуваються в площині управління, призводять до створення, зміни або видалення ресурсу Power Platform . Наприклад, зміна властивостей середовища або створення політики даних.

Застосунки зазвичай націлені на операції на площині даних, тоді як операції часто мають доступ як до площин керування, так і до площин даних.

Надання авторизації на основі ролей

Виходячи з відповідальності кожної особи, санкціонуйте дії, які повинні бути дозволені. Не можна дозволяти ідентичності робити більше, ніж їй потрібно. Перш ніж встановлювати правила авторизації, потрібно мати чітке розуміння того, хто або що робить запити, що ця роль дозволена робити і в якій мірі вона може це робити. Ці фактори призводять до вибору, який поєднує ідентичність, роль і сферу застосування.

Зверніть увагу на особливості.

  • Чи потрібно робочому навантаженню мати доступ до площини даних як для читання, так і для Dataverse запису?
  • Чи потрібен робочому навантаженню доступ і до властивостей середовища?
  • Якщо особистість буде скомпрометована зловмисником, як це вплине на систему з точки зору конфіденційності, цілісності та доступності?
  • Чи потребує робоче навантаження постійного доступу чи можна розглянути умовний доступ?
  • Чи виконує робоче навантаження дії, які потребують адміністративних/підвищених дозволів?
  • Як робоче навантаження буде взаємодіяти зі сторонніми сервісами?
  • Чи є у вас вимоги до єдиного входу (SSO) для інтелектуальних програм, таких як агенти?
  • Чи працює агент у режимі неавтентифікації, автентифікації чи в обох?

Призначення ролі

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

Ставте такі запитання:

  • Чи достатньо доступу лише для читання?
  • Чи потрібні посвідченню дозволи на видалення ресурсів?
  • Чи потрібен для цієї ролі доступ лише до створених нею записів?
  • Чи потрібен ієрархічний доступ залежно від бізнес-одиниці, в якій перебуває користувач?
  • Чи потрібні для цієї посади адміністративні або підвищені дозволи?
  • Чи потрібен для цієї ролі постійний доступ до цих дозволів?
  • Що станеться, якщо користувач змінить роботу?

Обмеження рівня доступу користувачів, додатків або служб зменшує потенційну поверхню атаки. Якщо надати лише мінімальні дозволи, які потрібні для виконання конкретних завдань, ризик успішної атаки або несанкціонованого доступу значно знижується. Наприклад, розробникам потрібен лише доступ maker до середовища розробки, але не середовище Production; Їм потрібен доступ лише для створення ресурсів, але не для зміни властивостей середовища; І їм може знадобитися доступ лише для зчитування/запису даних з Dataverse таблиці, але не для зміни моделі даних або атрибутів Dataverse таблиці.

Уникайте дозволів, націлених на окремих користувачів. Детальні та користувацькі дозволи створюють складність і плутанину, і їх може бути важко підтримувати, коли користувачі змінюють ролі та переходять у бізнес, або коли нові користувачі зі схожими вимогами автентифікації приєднуються до команди. Така ситуація може створити складну застарілу конфігурацію, яку важко підтримувати та негативно вплинути як на безпеку, так і на надійність.

Компроміс: детальний підхід до контролю доступу дозволяє краще проводити аудит і моніторинг дій користувачів.

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

Вибір умовного доступу

Не надавайте всім особам однаковий рівень доступу. Ґрунтуйте свої рішення на двох основних факторах:

  • Час. Як довго профіль може мати доступ до вашого оточення.
  • Привілей. Рівень дозволів.

Ці фактори не є взаємовиключними. Скомпрометована особистість, яка має більше привілеїв і необмежену тривалість доступу, може отримати більший контроль над системою та даними або використовувати цей доступ для продовження зміни середовища. Обмежте ці фактори доступу як для профілактики, так і для контролю радіусу вибуху.

Підходи Just in Time (JIT) надають необхідні привілеї лише тоді, коли вони потрібні.

Just Enough Access (JEA) надає лише необхідні привілеї.

Хоча час і привілеї є основними факторами, є й інші умови, які застосовуються. Наприклад, для встановлення політик можна також використовувати пристрій, мережу та розташування, з яких надійшов доступ.

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

Наприклад, до вашого робочого навантаження можуть мати доступ сторонні особи, як-от постачальники, партнери та клієнти. Їм потрібен відповідний рівень доступу, а не дозволи за замовчуванням, які ви надаєте штатним працівникам. Чітка диференціація зовнішніх облікових записів полегшує запобігання та виявлення атак, які надходять із цих векторів.

Облікові записи про критичний вплив

Адміністративні ідентифікаційні дані створюють одні з найвищих ризиків безпеки, оскільки завдання, які вони виконують, вимагають привілейованого доступу до широкого набору цих систем і програм. Компрометація або неправильне використання може мати згубний вплив на ваш бізнес та його інформаційні системи. Безпека адміністрації є однією з найважливіших сфер безпеки.

Захист привілейованого доступу від рішучих супротивників вимагає від вас повного та продуманого підходу, щоб ізолювати ці системи від ризиків. Ось кілька стратегій:

  • Мінімізуйте кількість облікових записів критичного впливу.

  • Використовуйте окремі ролі замість підвищення привілеїв для наявних особистостей.

  • Уникайте постійного або постійного доступу , використовуючи функції JIT вашого постачальника ідентифікаційної інформації. У ситуаціях з розбитим склом дотримуйтесь процедури екстреного доступу.

  • Використовуйте сучасні протоколи доступу , такі як безпарольна автентифікація або багатофакторна автентифікація. Екстерналізуйте ці механізми до свого IdP.

  • Забезпечте дотримання ключових атрибутів безпеки за допомогою політик умовного доступу.

  • Виведіть з експлуатації адміністративні облікові записи, які не використовуються.

Встановити процеси для управління життєвим циклом ідентифікації

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

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

Встановіть процес управління ідентифікацією для керування життєвим циклом цифрових ідентифікацій, користувачів з високими привілеями, зовнішніх/гостьових користувачів та користувачів робочого навантаження. Впроваджуйте перевірки доступу, щоб забезпечити видалення дозволів на робоче навантаження у разі вилучення ідентифікаційних даних з організації або команди.

Захистіть секрети, що не стосуються особистості

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

Розглядайте ці секрети як сутності, які можна динамічно витягувати зі сховища секретів. Вони не повинні бути жорстко закодовані у ваших програмах, потоках, конвеєрах розгортання або будь-яких інших артефактах.

Переконайтеся, що у вас є можливість скасовувати секрети .

Застосовуйте операційні практики, які обробляють такі завдання, як ротація та термін дії ключів .

Щоб отримати інформацію про політики ротації, див. статті Автоматизація ротації секретного коду для ресурсів, які мають два набори облікових даних автентифікації та Посібник: Оновлення частоти автоматичної ротації сертифікатів у Key Vault.

Забезпечення безпеки середовищ розробки

Доступ на запис до середовищ розробника має бути обмежений, а доступ на читання вихідного коду має бути обмежений ролями на основі принципу «обов’язково знати». У вас має бути запроваджена процедура, яка регулярно сканує ресурси та виявляє найновіші вразливості.

Ведіть журнал аудиту

Одним з аспектів управління ідентифікацією є забезпечення можливості аудиту системи. Аудити перевіряють ефективність стратегій порушення припущень. Ведення журналу аудиту допомагає вам:

  • Перевірте, чи особу автентифіковано за допомогою надійної автентифікації. Будь-яка дія має бути відстежуваною, щоб запобігти атакам відкидання.

  • Виявляйте слабкі або відсутні протоколи автентифікації та отримуйте уявлення про вхід користувачів і програм у систему й аналітичні дані про це.

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

  • Відстежуйте прогрес або відхилення від вимог до дотримання вимог.

Більшість ресурсів мають доступ до площини даних. Вам потрібно знати ідентифікатори, які отримують доступ до ресурсів, та дії, які вони виконують. Ви можете використовувати цю інформацію для діагностики безпеки.

Power Platform сприяння

Power Platform Контроль доступу є життєво важливою частиною його загальної архітектури безпеки. Точки контролю доступу можуть гарантувати, що потрібні користувачі отримують доступ до ресурсів. Power Platform У цьому розділі ми розглянемо різні точки доступу, які ви можете налаштувати, та їхню роль у вашій загальній стратегії безпеки.

Ідентифікатор Microsoft Entra

Усі Power Platform продукти використовують Microsoft Entra ідентифікатор (раніше OR Azure Active Directory Azure AD) для керування ідентифікацією та доступом. Entra ID дозволяє організаціям захищати та керувати ідентифікацією для своїх гібридних та мультихмарних середовищ. Entra ID також важливий для управління діловими гостями, яким потрібен доступ до ресурсів. Power Platform Power Platform також використовує Entra ID для управління іншими додатками, яким потрібно інтегруватися з Power Platform API за допомогою можливостей принципала сервісу. Використовуючи Entra ID, можна використовувати більш просунуті функції безпеки Entra ID, такі як умовний доступ та безперервна оцінка доступу. Power Platform

Схема системи хмарних обчислень.

Призначення ліцензії

Доступ до Power Apps і Power Automate запускається з ліцензією. Ресурси та дані, до яких має доступ користувач, визначаються типом його ліцензії. У наступній таблиці на загальному рівні описано відмінності в ресурсах, доступних користувачеві, залежно від типу плану. Детальну інформацію про ліцензування можна знайти в розділі Огляд ліцензування.

Політики умовного доступу

Умовний доступ описує вашу політику щодо рішення щодо доступу. Щоб використовувати умовний доступ, потрібно розуміти обмеження, необхідні для конкретного випадку використання. Налаштуйте умовний доступ, встановивши політику доступу, яка базується на ваших операційних потребах. Microsoft Entra

Щоб отримати додаткові відомості, див.

Безперервний доступ

Безперервний доступ прискорюється, коли певні події оцінюються для визначення, чи слід скасувати доступ. Традиційно, з автентифікацією 2.0, термін дії токена доступу закінчується, коли перевірка виконується під час його поновлення. OAuth За умови безперервного доступу критичні події користувача та зміни мережевого розташування постійно оцінюються, щоб визначити, чи слід користувачеві й надалі підтримувати доступ. Ці оцінки можуть призвести до дострокового завершення активних сеансів або необхідності повторної автентифікації. Наприклад, якщо обліковий запис користувача вимкнено, він має втратити доступ до програми. Розташування також важливе; наприклад, токен міг бути авторизований з надійного місця розташування, але користувач змінив своє підключення на ненадійну мережу. Безперервний доступ призведе до перевірки політики умовного доступу, і користувач втратить доступ, оскільки він більше не підключається з дозволеного розташування.

Наразі, з Power Platform тільки Dataverse підтримує безперервну оцінку доступу. Microsoft працює над додаванням підтримки до інших служб та клієнтів. Power Platform Для отримання додаткової інформації див. **Безперервна оцінка доступу** .

Зі постійним впровадженням гібридних моделей роботи та використанням хмарних додатків, Entra ID стала ключовим первинним периметром безпеки для захисту користувачів та ресурсів. Умовний доступ розширює цей периметр за межі мережевого периметра, включаючи ідентифікацію користувача та пристрою. Безперервний доступ гарантує, що в разі зміни подій або місцезнаходження користувачів доступ буде переоцінено. Power PlatformВикористання Entra ID дозволяє вам впроваджувати управління безпекою на рівні організації, яке можна послідовно застосовувати в усьому портфоліо додатків. Перегляньте ці рекомендації щодо керування ідентифікацією для отримання додаткових інструкцій щодо створення власного плану використання Entra ID з Power Platform.

Керування груповим доступом

Замість надання дозволів певним користувачам, призначте доступ групам у **ID**. Microsoft Entra Якщо групи не існує, створіть її разом зі своєю командою ідентифікації. Потім ви можете додавати та видаляти учасників групи поза межами Azure та переконатися, що дозволи актуальні. Ви також можете використовувати групу для інших цілей, таких як списки розсилки.

Для отримання додаткової інформації див. статтю Безпечний контроль доступу за допомогою груп в Microsoft Entra ID.

Виявлення загроз

Microsoft Entra Захист ідентифікаційних даних може допомогти вам виявляти, розслідувати та усувати ризики, пов’язані з ідентифікацією. Для отримання додаткової інформації див. статтю Що таке захист особистих даних?.

Виявлення загроз може здійснюватися у формі реагування на сповіщення про підозрілу активність або проактивного пошуку аномальних подій у журналах активності. Аналіз поведінки користувачів та сутностей (UEBA) у Microsoft Sentinel спрощує виявлення підозрілих дій. Для отримання додаткової інформації див. статтю Виявлення складних загроз за допомогою UEBA в Microsoft Sentinel.

Реєстрація ідентифікації

Power Apps, Power Automate, Copilot Studio, конектори та журнал дій запобігання втраті даних відстежуються та переглядаються на порталі відповідності вимогам Microsoft. Щоб отримати додаткові відомості, див. статтю Дізнайтеся про сферу компетенції Microsoft.

Реєструє зміни, внесені до записів клієнтів у середовищі з базою даних. Dataverse Відстеження Dataverse також реєструє доступ користувачів безпосередньо до програми або за допомогою SDK у середовищі. Цей аудит увімкнено на рівні середовища, і для окремих таблиць і стовпців потрібна додаткова конфігурація.

Ролі адміністратора служби

Entra ID містить набір попередньо встановлених ролей, які можна призначити адміністраторам, щоб надати їм дозвіл на виконання адміністративних завдань. Ви можете переглянути матрицю дозволів для детального розбиття привілеїв кожної ролі.

Використовуйте Microsoft Entra Керування привілейованими ідентифікаторами (PIM) для керування ролями адміністраторів з високими привілеями в Power Platform центрі адміністрування.

Захист даних Dataverse

Однією з ключових особливостей Dataverse є його насичена модель безпеки, яка може адаптуватися до багатьох сценаріїв використання в бізнесі. Ця модель безпеки доступна лише тоді, коли в середовищі є база даних. Dataverse Як фахівець з безпеки, ви, ймовірно, не будете самостійно створювати всю модель безпеки, але можете бути залучені до забезпечення відповідності використання функцій безпеки вимогам безпеки даних організації. Dataverse використовує безпеку на основі ролей для створення набору прав. Ці ролі безпеки можна призначити напряму користувачам, або командам та підрозділам Dataverse. Для отримання додаткової інформації див. Концепції безпеки в Microsoft Dataverse.

Налаштуйте автентифікацію користувачів у Copilot Studio

Microsoft Copilot Studio підтримує кілька варіантів автентифікації. Оберіть той, який відповідає вашим потребам. Автентифікація дозволяє користувачам входити в систему, тим самим надаючи вашому агенту доступ до обмежених ресурсів або інформації. Користувачі можуть увійти, використовуючи Microsoft Entra ID або будь-якого OAuth постачальника ідентифікації 2.0, такого як Google або Facebook. Дізнайтеся більше в розділі Налаштування автентифікації користувачів у Copilot Studio.

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

Copilot Studio підтримує єдиний вхід (SSO), що означає, що агенти можуть реєструвати користувача. SSO має бути реалізовано на ваших веб-сторінках та мобільних додатках. Для Microsoft Teams єдиний вхід (SSO) працює безперебійно, якщо вибрати параметр автентифікації «Тільки в Teams». Його також можна налаштувати вручну за допомогою версії 2; однак у цьому випадку програму Teams потрібно розгорнути як zip-файл, а не за допомогою функції розгортання Teams одним клацанням миші Azure AD . Copilot Studio

Докладніше:

Безпечний доступ до даних за допомогою Customer Lockbox

Для більшості операцій, підтримки та виправлення неполадок, що виконуються персоналом корпорації Майкрософт (включно з субобробниками), не потрібен доступ до даних клієнтів. За допомогою повного контролю доступу на стороні клієнта Power Platform ми надаємо інтерфейс для клієнтів, де вони можуть переглядати та затверджувати (або відхиляти) запити на доступ до даних у рідкісних випадках, коли потрібен доступ до даних клієнтів. Наприклад, він використовується, коли інженеру Microsoft потрібен доступ до даних клієнта, чи то у відповідь на запит до служби підтримки, ініційований клієнтом, чи то у відповідь на проблему, виявлену Microsoft. Щоб отримати додаткові відомості, перегляньте статтю Безпечний доступ до даних клієнтів за допомогою входу Power Platform Customer Lockbox і Dynamics 365.

Контрольний список безпеки

Зверніться до повного зведення рекомендацій.

Контрольний список безпеки