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

Створення стратегії DLP

  • Стаття

Політика запобігання втраті даних (DLP) використовується як захисний засіб, який допомагає користувачам запобігти ненавмисному розкриттю даних організації задля захисту інформаційної безпеки в клієнті. У політиці DLP встановлюються правила, для яких у кожному середовищі увімкнені з’єднувачі. Ці з’єднувачі можуть використовуватися разом. З’єднувачі класифікуються за трьома категоріями: Лише бізнес-дані, Бізнес-дані не дозволяються або Заблоковані. З’єднувач у групі, де дозволяються виключно бізнес-дані, може використовуватися виключно з іншими з’єднувачами в цій групі та в одній і тій самій програмі або потоці. Докладніші відомості див. у розділі: Виконуйте адміністрування Microsoft Power Platform: політика запобігання втраті даних

Встановлення ваших політик DLP йде рука об руку з вашою стратегією середовища.

Стислий огляд фактів

  • Політики захисту від втрати даних (DLP) діють як захисні огорожі, які допомагають запобігти ненавмисному розкриттю даних користувачами.
  • Політика DLP може бути сформульована на рівні середовища та на рівні клієнта. Тим самим вона забезпечує гнучкість індивідуально створених правил і не блокує високу продуктивність.
  • Політики DLP середовища не можуть мати пріоритет над політиками DLP для всього клієнта.
  • Якщо для одного середовища настроєно кілька наборів правил, складених у вигляді політики, до поєднання з’єднувачів застосовується найбільш обмежувальна політика.
  • За замовчуванням жодна політика DLP не реалізується в клієнті.
  • Політику неможливо застосувати на рівні користувача, тільки на рівні середовища або клієнта.
  • Стратегії DLP, сформульовані у вигляді політики, враховують з’єднувачі, але не керують з’єднаннями, які встановлюються з використанням відповідного з’єднувача. Іншими словами, політика DLP не знає, чи користуєтеся ви з’єднувачем для підключення до середовища розробки, тестування або до робочого середовища.
  • З’єднувачі PowerShell і адміністратора можуть керувати політикою.
  • Користувачі ресурсів у середовищах можуть переглядати застосовні документи політики.

Класифікація з'єднувачів

Бізнес- і не бізнес-класифікації проводять межу навколо того, з чим можуть використовуватися з’єднувачі в тій або іншій програмі чи потоці. З використанням політики DLP з’єднувачі можуть класифікуватися з поділом на наведені далі групи.

  • Бізнес: певна програма або Power Automate ресурс Power може використовувати один або кілька з’єднувачів із групи філій. Якщо програма або Power Automate ресурс Power використовує бізнес-з’єднувач, він не може використовувати будь-який небізнес-з’єднувач.
  • Некомерційна програма: певна програма або Power Automate ресурс Power може використовувати один або кілька з’єднувачів із групи, яка не належить до бізнесу. Якщо програма або Power Automate ресурс Power використовує небізнес-з’єднувач, він не може використовувати жодного бізнес-з’єднувача.
  • Заблоковано: жодна програма живлення або Power Automate ресурс не можуть використовувати з’єднувач із заблокованої групи. Повністю Microsoft належні роз’єми преміум-класу та роз’єми сторонніх виробників (стандартні та преміум) можуть бути заблоковані. Стандартні Microsoft з’єднувачі та Common Data Service з’єднувачі, що належать вам, не можуть бути заблоковані.

Імена «бізнес» і «не бізнес» не мають будь-якого особливого значення, це просто ярлики. Сам розподіл з’єднувачів за групами має значення, але не ім’я групи, до якої їх включено.

Докладніше див. у розділі: Адмініструйте Microsoft Power Platform: класифікацію з’єднувачів

Стратегії створення політик ЗВД

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

Ми рекомендуємо наведену далі відправну точку для розробки політики DLP для спільних середовищ користувачів і середовищ для досягнення продуктивності робочих груп:

  • Створіть політику, яка охоплює всі середовища, за винятком вибраних (наприклад, виробничих середовищ), забезпечуйте обмеження наявних з’єднувачів у цій політиці службою Office 365 та іншими стандартними мікрослужбами, а також блокуйте доступ до будь-чого іншого. Ця політика застосовується до середовища за замовчуванням, а також до тренувальних середовищ для проведення внутрішніх тренувальних подій. Крім того, ця політика також застосовується до будь-яких нових створених середовищ.
  • Створюйте відповідні та більш дозвільні політики DLP для спільних середовищ продуктивності користувачів і команди. На додаток до служб Office 365 така політика може дозволяти розробникам користуватися такими з’єднувачами, як Azure. Конектори, доступні в цих середовищах, залежать від вашої організації та місця зберігання бізнес-даних.

Для виробничих середовищ (бізнес-підрозділів і проектів) ми рекомендуємо наведену далі відправну точку розробки політики DLP.

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

Також рекомендуємо:

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

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

  • Відхилити запит.
  • Додати з’єднувач до стандартної політики DLP.
  • Додайте середовища до списку «Всі, за винятком» для глобальної політики DLP за замовчуванням. Створіть і застосовуйте окрему політику DLP для інцидентів, яка передбачатиме винятки.

Приклад: стратегія DLP корпорації Contoso

Давайте розглянемо спосіб, у який корпорація Contoso – організація, що використовується в якості прикладу для цих методичних рекомендацій – створила свою політку DLP. Налаштування їхніх політик DLP тісно пов’язане з їхньою стратегією щодо середовища.

На додаток до керування справами інноваційних центрів (CoE) адміністратори корпорації Contoso прагнуть підтримувати сценарії продуктивності користувачів і робочих груп, а також бізнес-програм.

Середовище та стратегія DLP адміністраторів Contoso, які тут застосовані, складається з:

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

  2. Адміністратори Contoso створили ще одне спільне середовище для користувачів, щоб створювати програми для сценаріїв продуктивності користувачів і команди. Це середовище має пов’язану політику DLP рівня клієнта, в якій не настільки не припускаються ризики, як у політиці за замовчуванням. Окрім цього, ця політика дозволяє розробникам, на додаток до служб Office 365, використовувати такі з’єднувачі, як служби Azure. Оскільки це середовище не є стандартним, адміністратори можуть активно контролювати список розробників середовища для нього. Це багатоярусний підхід до спільного середовища продуктивності користувачів і робочих груп, а також пов’язаних налаштувань DLP.

  3. Крім того, для того, щоб бізнес-підрозділи могли створювати бізнес-додатки, вони створили середовище розробки, тестування та виробництва для своїх дочірніх компаній з питань оподаткування та аудиту в різних країнах або регіонах. Здійснюється ретельне керування доступом розробників до цих середовищ. Забезпечуються відповідні з’єднувачі першої та третьої сторони з використанням політики DLP рівня клієнта. Це здійснюється за погодженням із зацікавленими сторонами бізнес-підрозділу.

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

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

Як і очікувалося, будь-які нові середовища, створені в Contoso, відповідають оригінальній політиці щодо всіх середовищ.

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

Як Contoso налаштував свою політику DLP.

Налаштування політик даних

  1. Створіть політику в центрі адміністрування Power Platform+. Додаткові відомості: Керування політиками даних

  2. Щоб додати спеціальні з’єднувачі до політики DLP, скористайтеся SDK DLP.

Необхідно надати розробникам зрозумілу інформацію про політику DLP своєї організації

Створіть веб-сайт SharePoint або вікі-сайт, на якому в доступній формі надається наведена далі інформація.

  • Політика DLP рівня клієнта та основна політика DLP рівня середовища (наприклад, середовища за замовчуванням, середовища ознайомлення), що діють у організації, включно зі списком з’єднувачів, класифікованих за категоріями: «Бізнес», «Не бізнес» і «Заблоковані».
  • Ваш ідентифікатор електронної пошти в групі, щоб розробники за виняткових обставин могли з вами зв’язатися. Наприклад, способом переміщення рішення до іншого середовища, створення нового середовища та нової політики DLP, а також переміщення розробника та ресурсу до цього нового середовища адміністратори можуть допомогти розробникам відновити редагування наявної політики DLP на предмет нормативно-правової відповідності.

Також чітко повідомте мейкерам стратегію середовища вашої організації.