Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Чи зливає Microsoft 365 Copilot ваші дані? Як захистити дозволи Graph, DLP і Purview (ШІ-дубляж)

Transcript

Чи зливає Microsoft 365 Copilot ваші дані? Як захистити дозволи Graph, DLP і Purview (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, що формують майбутні роботи.
• 0:07
  Цього січня M365Con повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас на живі сесії, демонстрації реальних кейсів та практичні знання від MVP та експертів галузі з усього світу.
• 0:18
  Жодних загальних слайдів, жодних безкінічних модних слів.
• 0:22
  Ми беремося за реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви і те фахівець, розробник або бізнес-лідер, для вас знайдуться спеціальні сесії.
• 0:35
  Протягом 10 повних днів ви можете дослідити безліч технологій та поспілкуватися з глобальною спільнотою.
• 0:40
  Дивіться наживо та приносте практичні ідеї у свою організацію.
• 0:44
  Січень 2027 року, 10 днів, одна спільнота Microsoft. Реєстрацію відкрито.
• 0:51
  Заходьте на M365Con.net і забезпечте собі місце вже сьогодні.
• 0:56
  Це M365Con.net
• 0:59
  Приєднуйтесь зараз на M365Con.net і побачимося в січні.
• 1:04
  Якщо ви думаєте, що Co-Pilot показує лише те, на що у вас є дозвіл, подумайте ще раз.
• 1:09
  Один неправильний дозвіл граф і вас ще раптом може вивести дані, які ваша служба комплеєнсу ніколи не схвалювала.
• 1:14
  Найстрашніше те, що ви можете навіть не помітити, як це відбувається.
• 1:17
  У цьому відео я розберу реальні ризики некерованого доступу Co-Pilot і як конфіденційні файли, фінансові таблиці та дані клієнтів можуть витекти.
• 1:25
  Потім я покажу, як обмежити це за допомогою дозволів граф, політик, DLP та перв'ю, не порушуючи продуктивність тих, кому справді потрібен доступ.
• 1:33
  Коли Co-Pilot знає забагато, молодший співробітник просить нотатки з огляду проєкту минулого кварталу,
• 1:39
  і замість акуратного підсумку власної наради він отримує детальний протокол закритого засідання правління,
• 1:45
  включно зі стратегічними рішеннями, скороченням бюджету та іменами, які ніколи не мали потрапити в пошту цієї людини.
• 1:51
  Жодних сповіщень про витік, жодних попереджень DLP просто ще тихо надає документ, якого він ніколи не мав торкатися.
• 1:58
  Це стається тому, що Co-Pilot не зупиняється магічним чином на пошті користувача чи папці Onidrive.
• 2:03
  Його межі визначаються дозволами, наданими через Microsoft Graph.
• 2:07
  І Graph – це не просто база даних, це центральна точка доступу майже до кожного фрагмента контенту в Microsoft 365,
• 2:14
  SharePoint, повідомлень Teams, події календаря, OneNote, даних CRM, прив'язаних до тенанта.
• 2:19
  Усе це проходить через Graph, якщо відчинені правильні двері.
• 2:22
  Це момент, який пропускають багато адміністраторів.
• 2:25
  Існує поширена думка, що якщо я увійшов під своїм обліковим записом, Co-Pilot бачитиме лише те, що бачу я.
• 2:30
  Звучить логічно.
• 2:31
  Проблема в тому, що сам Co-Pilot часто працює з окремим набором дозволів за стосунку.
• 2:36
  Якщо ці права доступу ширші за права входу користувача, ви отримуєте ще й помічника, здатного назначно більше, ніж людина за клавіатурою.
• 2:45
  І в деяких розгортаннях ці підвищені привілеї надаються без жодних запитань про їхню необхідність.
• 2:50
  Уявіть фінансового аналітика, який працює над квартальним прогнозом.
• 2:54
  Він запитує в Co-Pilot поточні дані щодо воронки продажів для топ-20 клієнтів.
• 2:58
  Згідно зі своєю посадовою інструкцією, він має бачити показники лише для певної групи клієнтів.
• 3:03
  Але завдяки тому, як граф був налаштований у реєстрації за стосунку Co-Pilot,
• 3:07
  ще витягує весь звіт з воронки продажів зі спільного командного сайту, до якого аналітик ніколи не мав прямого доступу.
• 3:12
  З погляду кінцевого користувача нічого підозрілого немає.
• 3:16
  Але з точки зору безпеки та комплеєнсу це розкриття конфіденційних даних.
• 3:20
  Дозволи граф АРІ – це фактично парадні двері до даних вашої організації.
• 3:24
  Майкрософт розділяє їх на делеговані дозволи, що діють від імені користувача,
• 3:29
  та дозволи за стосунку, які дозволяють програмі працювати незалежно.
• 3:33
  Сценарії Co-Pilot часто потребують делегованих дозволів для отримання вмісту,
• 3:37
  але деякі функції, як от підсумовування зустрічі в Teams, де користувача не було,
• 3:41
  можуть спонукати адміністраторів схвалити дозволи на рівні за стосунку.
• 3:45
  І саме тут виникає небезпека.
• 3:47
  Дозволи за стосунку ігнорують обмеження окремих користувачів,
• 3:50
  якщо ви навмисно не обмежите їхню дію.
• 3:52
  Такі схвалення часто відбуваються на початку впровадження,
• 3:55
  і те адміністратор, що тестує Co-Pilot у тестовому середовищі,
• 3:59
  може натиснути «Прийняти» у запиті на дозвіл, щоб швидше завершити налаштування,
• 4:03
  а потім скопіювати цю конфігурацію в робоче середовище без аналізу наслідків.
• 4:07
  Після встановлення ці широкі дозволи залишаються в силі, доки хтось активно їх не перевірить.
• 4:11
  З часом, коли нові джерела даних підключаються до М365,
• 4:15
  сфера дії Co-Pilot розширюється без будь-яких свідомих рішень.
• 4:19
  Це непомітне накопичення дозволів, жодної драми, жодних скарг користувачів,
• 4:23
  лише поступове розширення можливостей ЩІ.
• 4:25
  Проблема в тому, що більшість команд безпеки не знають,
• 4:28
  які можливості Co-Pilot вимагають певного рівня доступу до граф.
• 4:32
  Вони можуть бачити дозвіл читати всі файли у SharePoint і вважати,
• 4:35
  що він обмежений контекстом користувача,
• 4:37
  не усвідомлюючи, що цей дозвіл діє в межах усього тенента на рівні застосунку.
• 4:41
  Без зіставлення конкретних сценаріїв ще з мінімально необхідними дозволами,
• 4:45
  ви в підсумку залишаєтеся з тими параметрами,
• 4:47
  які були схвалені під час першого налаштування.
• 4:50
  І чим ширші ці права, тим більший потенційний розрив
• 4:53
  між очікуваною та реальною поведінкою.
• 4:56
  Варто також пам'ятати, що результати роботи Co-Pilot
• 5:00
  не супроводжуються видимим для користувача журналом дозволів.
• 5:04
  Якщо ЩІ витягує в міст із місця,
• 5:06
  до якого користувачу зазвичай заборонено доступ,
• 5:08
  немає жодного попереджувального банера про те,
• 5:10
  що це поза межами його повноважень.
• 5:12
  Ця відсутність прозорості полегшує проникнення
• 5:14
  ризикованих випадків витоку даних у повсякденні робочі процеси.
• 5:17
  Висновок полягає в тому, що дозволи граф для впровадження ЩІ
• 5:21
  – це не просто чергова галочка в процесі налаштування.
• 5:24
  Це дизайнерське рішення, яке формує кожну взаємодію Co-Pilot у вашій мережі.
• 5:28
  Ставтеся до них так само, як до правил брандмауера
• 5:31
  чи налаштувань доступу VPN, виважено з перевірками
• 5:33
  та періодичною актуалізацією.
• 5:35
  Стандартні налаштування допоможуть швидко розпочати,
• 5:38
  але вони також припускають, що вас влаштовує ширше охоплення ЩІ,
• 5:41
  ніж у людини, яка ним користується.
• 5:42
  Тепер, коли ми побачили, як легко вийти за межі доступу,
• 5:45
  виникає питання, як виявити ці прогалини до того,
• 5:47
  як вони переростуть у серйозний інцидент.
• 5:49
  Знаходити витоки до того, як вони стануть критичними.
• 5:52
  Якби Co-Pilot уже відображав дані, яких не мав би показувати,
• 5:54
  чи помітили б ви це взагалі?
• 5:56
  Для більшості організацій чесна відповідь – ні.
• 5:58
  Справа не в тому, що інформація потрапить на публічний сайт чи в розсилку.
• 6:03
  Витік може непомітно з'явитися всередині чернетки документа,
• 6:07
  резюме або відповіді згенерованої щі.
• 6:10
  І якщо хтось не помітить нічого незвичного,
• 6:12
  це пройде повз увагу без жодних сигналів тривоги.
• 6:14
  Проблема видимості починається з того,
• 6:16
  як побудовані більшість систем моніторингу.
• 6:19
  Вони налаштовані на традиційні дії – завантаження файлів,
• 6:22
  незвичні місця входу, масові розсилки,
• 6:25
  а не на спосіб, у який щі збирає та компілює інформацію.
• 6:28
  Co-Pilot не відкриває файли у звичному розумінні.
• 6:31
  Він запитує джерела даних через Microsoft Graph,
• 6:34
  компілює результати та представляє їх у вигляді тексту природною мовою.
• 6:38
  Це означає, що стандартні звіти про доступ до файлів
• 6:40
  можуть виглядати чистими, тоді якші продовжує витягувати дані
• 6:43
  з конфіденційних місць у фоновому режимі.
• 6:45
  Я бачив ситуації, коли компанія усвідомлювала проблему лише тому,
• 6:49
  що працівник випадково згадав назву клієнта,
• 6:51
  яка не входила до компетенції їхнього відділу.
• 6:54
  Коли керівник запитав, звідки вони це знають,
• 6:56
  відповідь була – Co-Pilot включив це в мою чернитку.
• 6:58
  Не було жодного тікета про інцидент,
• 7:00
  жодного автоматичного сповіщення,
• 7:01
  лише випадковий коментар, який змусив і те відділ почати розслідування.
• 7:05
  На той час, коли вони все з'ясували,
• 7:07
  ці самі відповіді «Щ» вже були поширені в кількох командах.
• 7:10
  Microsoft 365 надає інструменти для розслідування таких сценаріїв,
• 7:14
  але потрібно знати, де шукати.
• 7:16
  Функція аудиту в перв'ю може детально записувати доступ Co-Pilot до даних,
• 7:20
  просто він не позначений великим помітним значком «Щ».
• 7:23
  Опинившись у пошуку журналів аудиту,
• 7:25
  ви можете відфільтрувати специфічні операції,
• 7:27
  які використовує Co-Pilot, як от «Виконаний пошуковий запит»,
• 7:30
  або «Доступ до файлу» і звузити їх за ідентифікатором програми,
• 7:33
  прив'язаним до вашого розгортання Co-Pilot.
• 7:35
  Це потребує певної підготовки.
• 7:37
  Вам варто підтвердити деталі реєстрації програми Ventra ID,
• 7:40
  щоб ви могли ідентифікувати трафік.
• 7:42
  Далі справа за виявленням закономірностей.
• 7:44
  Якщо ви бачите великий обсяг запитів від облікових записів,
• 7:46
  які зазвичай мають низьку потребу в даних,
• 7:48
  наприклад, обліковий запис стажера,
• 7:50
  що виконує 10 складних пошуків за годину,
• 7:51
  це варто перевірити.
• 7:52
  Те саме стосується раптових сплесків в місту
• 7:54
  з позначкою «Конфіденційно»,
• 7:56
  який з'являється у відділах, що зазвичай з ним не працюють.
• 7:58
  Перв'ю може позначати активність міток,
• 8:01
  тому якщо запит Co-Pilot залучає позначений документ,
• 8:04
  ви побачите це в журналах,
• 8:05
  навіть якщо ще не видав повний текст.
• 8:08
  Перевірки доступу на основі ролей –
• 8:09
  це ще один спосіб пов'язати факти.
• 8:12
  Зіставляючи, хто саме використовує Co-Pilot,
• 8:14
  із типами даних, з якими вони працюють,
• 8:16
  можна завчасно виявити потенційні невідповідності.
• 8:19
  Можливо, фінансовий відділ активно використовує Co-Pilot для звітів,
• 8:22
  що логічно, але чому кілька маркетингових акаунтів
• 8:25
  звертаються до платіжних відомостей через запити ЩІ.
• 8:27
  Такі перевірки дають ширшу картину,
• 8:29
  ніж окремі події в аудиторському журналі.
• 8:32
  Проблема в тому, що загальні інформаційні панелі моніторингу
• 8:35
  тут мало чим допоможуть.
• 8:36
  Вони агрегують усі діїв М365 у широкі категорії,
• 8:40
  через що поведінка ЩІ може змішуватися зі звичайними операціями.
• 8:44
  Без створення спеціальних фільтрів або звітів,
• 8:47
  зосереджених на ідентифікаторі вашого додатка Co-Pilot
• 8:50
  і шаблонах використання,
• 8:52
  ви фактично шукаєте окремі піщенки в морі даних.
• 8:55
  Вам потрібна цільова видимість, а не просто більше видимості.
• 8:58
  Справа не в створенні культури стеження,
• 8:59
  а в тому, щоб з упевненістю знати, що саме залучає ваш ЩІ.
• 9:03
  Належний підхід до ведення журналів відповідає на три критичні питання.
• 9:06
  Що отримав Co-Pilot?
• 9:07
  Хто це ініціював?
• 9:09
  І чи відповідала ця дія вашим чинним політикам безпеки та комплеєнсу?
• 9:13
  Ці відповіді дозволяють вирішувати проблеми точно,
• 9:15
  коригувати дозволи, вдосконалювати правила DLP
• 9:18
  або посилювати призначення ролей.
• 9:21
  Без цієї ясності ви змушені гадати,
• 9:23
  а припущення – це не стратегія безпеки.
• 9:26
  Тож, замість того, щоб чекати чергового випадкового коментаря,
• 9:30
  варто витратити час на структурування моніторингу,
• 9:33
  щоб слід Co-Pilot був помітним і відстежуваним.
• 9:36
  Таким чином, будь-яка ознака надмірного викриття даних
• 9:39
  стає керованою подією, а не сюрпризом.
• 9:42
  Знати, де виникають витоки – це лише перший крок.
• 9:45
  Справжня мета – переконатися, що вони не повторяться,
• 9:47
  і саме тут стають у пригоді правильні запобіжники.
• 9:50
  Запобіжники, які дійсно працюють.
• 9:52
  DLP призначено не лише для виявлення електронних листів
• 9:54
  і з номерами кредитних карток.
• 9:56
  У контексті Co-Pilot це може бути сигналізацією,
• 9:59
  яка зупиняє потрапляння конфіденційних даних
• 10:02
  у згенеровану ЩІ-відповідь, що копіюється в чат Teams
• 10:05
  або експортується в документ за межі вашого клієнта.
• 10:08
  Це все той самий базовий інструмент у Microsoft 365,
• 10:12
  але підхід до його налаштування для сценаріїв ЩІ потребує іншого мислення.
• 10:16
  Проблема в тому, що політики DLP більшості організацій
• 10:20
  все ще написані з огляду на застарілі тригери,
• 10:22
  вкладення електронної пошти, завантаження файлів на USB-накопичувачі,
• 10:26
  копіювання даних у несанкціоновані додатки.
• 10:29
  Co-Pilot не активує ці правила за замовчуванням,
• 10:31
  оскільки він не надсилає файли.
• 10:33
  Він генерує контент на люту.
• 10:35
  Якщо ви попросите Co-Pilot надати повний список клієнтів з грифом,
• 10:39
  обмежено, і він отримає його з позначеного документа,
• 10:42
  ці дані можуть вийти за межі системи,
• 10:44
  не активувавши традиційні умови DLP.
• 10:47
  Саме тому запити та відповіді ЩІ потрібно чітко включити
• 10:50
  до сфери дії вашої DLP-політики.
• 10:53
  Практичний приклад.
• 10:54
  Скажімо, ваша політика забороняє експорт певних контрактних документів
• 10:58
  за межі захищеного середовища.
• 11:00
  Користувач може попросити Co-Pilot витягти ключові положення
• 11:03
  та вставити їх у PowerPoint.
• 11:05
  Якщо ваші DLP-правила не відстежують контент,
• 11:07
  згенерований ЩІ, цей конфіденційний матеріал,
• 11:10
  опиняється у незахищеному файлі.
• 11:12
  Розширивши перевірку DLP на вихідні дані Co-Pilot,
• 11:15
  ви зможете заблокувати збереження цього PowerPoint
• 11:18
  у некерованому місці або його надсилання зовнішньому гостю в Teams.
• 11:22
  Налаштування цього в Microsoft 365 не є складним,
• 11:25
  але вимагає виваженого підходу.
• 11:27
  Спершу в порталі відповідності вимогам Microsoft Perview
• 11:30
  перейдіть до розділу запобігання втраті даних
• 11:32
  і створіть нову політику.
• 11:34
  Вибираючи місця для застосування,
• 11:35
  додайте Exchange, SharePoint, Onedrive і, що важливо, Teams,
• 11:39
  оскільки Co-Pilot може виводити дані в будь-який із цих сервісів.
• 11:43
  Потім визначте умови.
• 11:44
  Ви можете орієнтуватися на вбудовані типи конфіденційної інформації,
• 11:48
  як-от номери фінансових рахунків або на власні,
• 11:50
  що виявляють ваші внутрішні коди проєктів.
• 11:53
  А якщо ви послідовно використовуєте мітки конфіденційності,
• 11:56
  ви також можете налаштувати умову активації,
• 11:58
  коли позначений контент з'являється у фінальному файлі,
• 12:01
  який зберігається або надається спільно.
• 12:03
  Нарешті, налаштуйте дії.
• 12:04
  Заблокуйте спільний доступ,
• 12:06
  покажіть користувачеві підказку щодо політики
• 12:08
  або вимагайте обґрунтування для продовження.
• 12:10
  Самі мітки конфіденційності є ключовим елементом роботи цієї системи.
• 12:14
  У контексті ЩІ-мітка – це метадані,
• 12:16
  які Coopilot може считувати так само,
• 12:18
  як і будь-яка інша служба М365.
• 12:21
  Якщо документ із високим рівнем конфіденційності має мітку,
• 12:24
  що обмежує доступ і використання,
• 12:26
  Coopilot дотримуватиметься цих обмежень
• 12:28
  при створенні відповідей за умови,
• 12:30
  що параметри захисту міток застосовуються
• 12:32
  перепослідовно в усіх залучених програмах.
• 12:34
  Якщо ЩІ намагається використати контент
• 12:36
  із міткою поза дозволеною сферою,
• 12:38
  DLP-політика, пов'язана з цією міткою,
• 12:40
  може заблокувати дію або позначити її для перевірки.
• 12:43
  Без такого зв'язку мітка з точки зору відповідності вимогам
• 12:46
  є лише прикрасою.
• 12:48
  Одна з найпоширеніших помилок у конфігурації,
• 12:50
  з якою я стикаюся,
• 12:51
  це залишення DLP-політик без урахування сценаріїв роботи ЩІ.
• 12:54
  Правила існують, але зв'язку з вихідними даними
• 12:56
  Coopilot немає, оскільки адміністратори
• 12:58
  не розглядають це як окремий канал.
• 13:00
  Це створює сліпу зону, де конфіденційні терміни
• 13:02
  у згенерованій відповіді не перевіряються,
• 13:05
  хоча такий самий текст в електронному листі
• 13:07
  був би заблокований.
• 13:08
  Щоб виправити це, ви повинні розглядати
• 13:10
  робочі процеси з підтримкою ЩІ,
• 13:12
  як одне з ваших DLP-розташувань
• 13:14
  і контролювати їх на рівні з іншими.
• 13:16
  Коли DLP та мітки конфіденційності
• 13:18
  правильно налаштовані та взаємодіють
• 13:20
  між собою, Coopilot залишається
• 13:22
  корисним інструментом без проблем із
• 13:24
  комплеєнсом. Ви можете дозволити йому
• 13:26
  створювати звіти, підсумовувати документи
• 13:28
  та аналізувати набори даних, тихо
• 13:30
  застосовуючи ті самі обмеження, що й
• 13:32
  у листах чи повідомленнях Teams.
• 13:34
  Користувачі отримують переваги щі допомоги,
• 13:36
  а захисні бар'єри не дають конфіденційні
• 13:38
  інформації вийти за межі. Перевага тут
• 13:40
  полягає не лише у запобіганні випадковому
• 13:42
  розголошенню даних, а в тому, щоб
• 13:44
  дозволити технології працювати за чіткими
• 13:46
  правилами. Таким чином, ви не вдаєтеся
• 13:48
  до загальних обмежень, які дратують
• 13:50
  команди та стримують впровадження.
• 13:52
  Ви можете налаштувати контроль так,
• 13:54
  щоб відділ маркетингу міг працювати
• 13:56
  з Coopilot, фінанси, проводити
• 13:58
  аналіз, а HR, створювати посібники
• 14:00
  для новачків, кожен у своїй зоні
• 14:02
  доступу. Але контроль вихідних даних
• 14:04
  це лише частина загальної картини.
• 14:06
  Щоб повністю знизити ризики,
• 14:08
  потрібно також визначити, хто саме
• 14:10
  отримує доступ до конкретних можливостей
• 14:12
  ЩІ. Універсальний підхід до
• 14:14
  доступу не працює. Чи повинні стажер
• 14:16
  із маркетингу та фінансовий директор
• 14:18
  мати однакові привілеї в Coopilot?
• 14:20
  Ця ідея звучить абсурдно вголос,
• 14:22
  але в багатьох клієнських середовищах
• 14:24
  налаштовано саме так. Coopilot
• 14:26
  вмикають для всіх з однаковими дозволами,
• 14:28
  бо це швидше і простіше, ніж займатися
• 14:30
  налаштуваннями для кожної ролі окремо.
• 14:32
  Мінус у тому, що доступ ЩІ
• 14:34
  відповідає максимально відкритому сценарію,
• 14:36
  а не потребам кожної ролі.
• 14:38
  Ось тут на допомогу приходять групи доступу
• 14:40
  до Coopilot на основі ролей. Замість
• 14:42
  того, щоб вважати всіх користувачів рівнозначними,
• 14:44
  ви адаптуєте можливості ще до інформації
• 14:46
  та робочих процесів, які дійсно
• 14:48
  потрібні конкретним ролям.
• 14:50
  Маркетингу може знадобитися доступ
• 14:51
  до рекламних матеріалів та брендбуків,
• 14:54
  але не до фінансових моделей.
• 14:56
  Фінансам потрібні ці моделі, але
• 14:58
  не потрібні плани розвитку продуктів
• 14:59
  на ранніх стадіях.
• 15:01
  Мета не в тому, щоб зробити Coopilot менш корисним,
• 15:03
  а в тому, щоб його сфера застосування
• 15:05
  відповідала роботі кожної людини.
• 15:07
  Ризики від універсального ввімкнення більші,
• 15:09
  ніж очікує більшість команд.
• 15:10
  Coopilot працює, використовуючи дані,
• 15:12
  які вже містяться у вашому середовищі Microsoft 365.
• 15:16
  Якщо весь персонал має однаковий доступ до ЩІ,
• 15:18
  технологія може зруйнувати ізольовані структури,
• 15:21
  які ви навмисно підтримували.
• 15:22
  Саме таки, чар-асистенти можуть натрапити
• 15:25
  на зведення доходів або керівник операцій запитає Coopilot
• 15:28
  про план випуску продуктів на наступний рік
• 15:31
  і отримає ще не затверджені деталі дизайну.
• 15:34
  У той момент це не виглядає як витік,
• 15:36
  але загроза цілком реальна.
• 15:38
  Правильна модель доступу починається з визначення
• 15:40
  відповідності посадових обов'язків та потреб у даних
• 15:43
  не лише додатків, які люди використовують,
• 15:45
  а й глибини та чутливості даних,
• 15:46
  з якими вони працюють щодня.
• 15:48
  Ви можете виявити, що 70% запитів вашого відділу продажів до Coopilot
• 15:52
  стосується історії клієнтів, тоді як менш ніж 5%
• 15:55
  стосується конфіденційних файлів контрактів.
• 15:57
  Це означає, що ви можете безпечно обмежити
• 15:59
  більшість сценаріїв використання ще певними бібліотеками
• 16:01
  SharePoint, заблокувавши решту.
• 16:03
  Виконайте цю вправу для кожного відділу
• 16:05
  і ви побачите певні закономірності.
• 16:07
  Коли ви зрозумієте потреби кожної групи
• 16:09
  Microsoft EntraID, яку багато хто досі називає Azure ID,
• 16:12
  стане вашим інструментом контролю.
• 16:14
  Ви створюєте групи безпеки, що відповідають вашим визначеним ролям,
• 16:17
  а потім призначаєте дозволи Co-Pilot на рівні цих груп.
• 16:20
  Це може означати надання певних областей граф
• 16:23
  арі лише членам групи Co-Pilot для фінансистів,
• 16:26
  тоді як група маркетингу матиме інший набір.
• 16:29
  Доступ до конфіденційних сайтів, каналів Teams
• 16:31
  або окремих папок Onedrive можна налаштувати за тією ж моделью.
• 16:34
  Сила цього підходу полягає в його поєднанні
• 16:36
  з елементами керування, які ми вже розглянули.
• 16:39
  Дозволи граф визначають зовнішні межі того,
• 16:41
  до чого Co-Pilot може технічно отримати доступ.
• 16:44
  Політики DLP відстежують вихідні дані щі на наявність конфіденційного вмісту.
• 16:49
  Рольові групи займають проміжне місце,
• 16:51
  гарантуючи, що дозволи граф не будуть занадто широкими
• 16:54
  для ролей із низьким рівнем доступу,
• 16:56
  а DLP не реагуватиме на те,
• 16:58
  що можна було попередити обмеженням вхідних даних.
• 17:01
  Але, як і будь-яку систему, її можна довести до крайнощів.
• 17:04
  Виникає спокуса створювати окрему мікругу для кожного сценарію.
• 17:08
  Co-Pilot для фінансового аналітика з правами звітовання
• 17:10
  чи для стажера з маркетингу без доступу до Teams,
• 17:13
  і в результаті ви отримуєте десятки варіацій.
• 17:15
  Такий рівень деталізації може виглядати точно на папері,
• 17:17
  але в реальному робочому середовищі
• 17:19
  це створює головний біль при обслуговуванні.
• 17:20
  Користувачі змінюють посади,
• 17:22
  проєкти оновлюються, підрядники приходять і йдуть.
• 17:24
  Якщо групова модель занадто жорстка,
• 17:26
  ваш ІТ-персонал витрачатиме більше часу
• 17:28
  на вирішення проблем із доступом,
• 17:29
  ніж на реальне підвищення безпеки.
• 17:31
  Справжня мета – це баланс.
• 17:33
  Кілька чітких, добре визначених рольових груп
• 17:35
  покриють більшість випадків без створення адміністративного колапсу.
• 17:38
  Групі фінансового директора потрібні широкі аналітичні можливості,
• 17:42
  але суворий контроль над поширенням результатів.
• 17:44
  Група стажерів отримує обмежений доступ до даних,
• 17:47
  але достатній для виконання реальної роботи.
• 17:50
  Керівники відділів отримують золоту середину,
• 17:52
  а ІТ-відділ зберігає можливість вносити корективи,
• 17:55
  коли спеціальні проєкти вимагають винятків.
• 17:57
  Ви не намагаєтеся заблокувати все до стану повної неможливості працювати.
• 18:01
  Ви робите кожен досвід використання щідоречним,
• 18:03
  безпечним і відповідним до політик компанії.
• 18:05
  Коли ви все робите правильно, переваги стають помітними дуже швидко.
• 18:08
  Користувачі перестають дивуватися даним, які їм надає Coopilot,
• 18:11
  оскільки це завжди інформація в межах їхньої сфери відповідальності.
• 18:14
  У команд з комплеєнсу стає менше інцидентів для розслідування,
• 18:16
  оскільки випадки надмірного розголошення даних не виникають випадково.
• 18:19
  ІТ-фахівці нарешті можуть впроваджувати нові функції Coopilot,
• 18:23
  не хвилюючись, що глобальний запуск непомітно зруйнує всі межі даних,
• 18:27
  які вони так старанно будували.
• 18:29
  Завдяки спільній роботі доступу та засобів захисту
• 18:31
  ви значно знизили свій профіль ризиків.
• 18:34
  Але навіть добре спроєктована модель має значення лише тоді,
• 18:36
  коли ви можете довести, що вона працює як для себе,
• 18:38
  так і для будь-кого, хто звернеться за аудиторським запитом.
• 18:41
  Доведення відповідності вимогам без уповільнення процесів.
• 18:44
  Відповідність – це не просто безпекова вистава,
• 18:46
  це докази, які задовольняють аудиторів.
• 18:48
  Політики та захисні бар'єри – це чудово,
• 18:50
  але якщо ви не можете точно показати,
• 18:52
  що сталося з даними під час роботи ЩІ,
• 18:54
  вам залишається лише робити припущення замість доказів.
• 18:56
  Готове до аудиту середовище Coopilot означає,
• 18:59
  що кожну взаємодію від запиту користувача
• 19:01
  до отримання даних штучним інтелектом
• 19:03
  можна пояснити та підтвердити верифікованим записом.
• 19:06
  Складність у тому, що багато компаній вважають себе захищеними,
• 19:09
  оскільки проходять внутрішні перевірки.
• 19:11
  Такі перевірки часто лише перевіряють
• 19:13
  наявність засобів контролю та кілька вибіркових сценаріїв,
• 19:16
  але вони не завжди вимагають того рівня деталізації,
• 19:18
  який очікують зовнішні аудитори.
• 19:21
  Коли зовнішній оцінювач запитує журнал
• 19:23
  усього конфіденційного контенту,
• 19:25
  до якого Coopilot звертався минулого кварталу,
• 19:27
  разом із тим, хто його запитував і чому,
• 19:30
  дивно, як часто з'являються прогалини.
• 19:32
  Або журнали неповні, або в них взагалі відсутні події,
• 19:35
  пов'язані з вші, оскільки вони не були позначені
• 19:37
  відповідним чином від самого початку.
• 19:39
  Ось тут Microsoft Perview може суттєво змінити ситуацію.
• 19:42
  Його можливості забезпечення відповідності
• 19:44
  – це не лише застосування міток і політик DLP.
• 19:47
  Вони також збирають докупи необхідні вам криміналістичні докази.
• 19:50
  У контексті Coopilot Perview може записувати
• 19:52
  кожен відповідний запит на доступ до даних,
• 19:54
  ідентифікатор особи, що його здійснила,
• 19:56
  та вихідне розташування.
• 19:57
  Він також може корелювати ці події
• 19:58
  з моделями руху даних,
• 20:00
  наприклад, коли конфіденційні файли
• 20:02
  згадуються в чернетках, резюме або експортах,
• 20:04
  не покладаючись на звіти самого ЩІ.
• 20:06
  Показник відповідності Perview –
• 20:08
  це більше, ніж просто марна метрика.
• 20:10
  Це знімок того, як ваше середовище
• 20:12
  відповідає рекомендованим Microsoft засобам контролю,
• 20:14
  включаючи ті, що безпосередньо обмежують ризики,
• 20:17
  пов'язані з ЩІ.
• 20:18
  Краща гігієна дозволів граф,
• 20:19
  жорсткіші конфігурації DLP
• 20:21
  та належне ведення ролевих груп –
• 20:23
  усе це впливає на цей показник.
• 20:25
  А оскільки оцінка оновлюється в міру внесення
• 20:27
  вами змін, ви можете майже в реальному часі
• 20:29
  бачити, як покращення в управлінні ЩІ
• 20:31
  підвищують ваш рівень відповідності.
• 20:34
  Уявіть регуляторну перевірку,
• 20:35
  де вам потрібно обґрунтувати,
• 20:37
  чому певні дані клієнтів з'явилися у звіті,
• 20:40
  створеному Co-Pilot.
• 20:41
  Без структурованого ведення журналів
• 20:43
  така розмова перетворюється на здогадки.
• 20:45
  Якщо Perview налаштовано правильно,
• 20:46
  ви можете показати запит на доступ у журналі аудиту,
• 20:48
  вказати на роль і дозволи, що його авторизували,
• 20:51
  та продемонструвати, що результат залишився
• 20:53
  в межах схвалених каналів.
• 20:54
  Це значно легша дискусія, ніж намагання
• 20:56
  пояснити недокументовану подію.
• 20:58
  Головне – зробити звітовання про відповідність
• 21:00
  частиною вашого звичайного циклу IT-управління,
• 21:03
  а не просто окремим проєктом перед аудитом.
• 21:05
  Автоматизоване звітовання тут дуже допомагає.
• 21:07
  Perview може створювати періодичні звіти
• 21:09
  щодо відповідності політикам захисту інформації,
• 21:11
  інцидентів DLP та використання міток конфіденційності.
• 21:15
  Коли ці звіти щомісяця надходять до робочого простору
• 21:18
  вашої команди з управління,
• 21:19
  ви формуєте базу активності ЩІ, яку легко перевіряти.
• 21:23
  Будь-яка аномалія одразу виділяється
• 21:24
  на фоні історичних даних.
• 21:26
  Функції економії часу справді додають переваг.
• 21:28
  Наприклад, Perview постачається з готовими звітами,
• 21:31
  що виділяють усі інциденти з маркованим контентом,
• 21:33
  згруповані за розташуванням або типом активності.
• 21:36
  Якщо сеанс Coopilot додав конфіденційний документ,
• 21:39
  у результат, а ваша DLP-система відреагувала,
• 21:42
  цей інцидент вже є у звіті без створення запитів вручну.
• 21:46
  Ви можете заглибитися в цей запис для деталей,
• 21:48
  але складну роботу зі збору та категоризації вже виконано.
• 21:52
  Ще одна ефективна особливість – це інтеграція аудиту
• 21:55
  Perview з даними про доступ на основі ролей у Microsoft 365.
• 21:59
  Оскільки Perview розпізнає групи EntraID,
• 22:02
  він може розділяти журнали доступу за типом ролей.
• 22:05
  Це означає, що ви можете швидко відповідати на конкретні запитання,
• 22:08
  як от «Покажи всі випадки»,
• 22:09
  коли маркетингові ролі отримували доступ до фінансових даних
• 22:12
  через Coopilot за останні 90 днів.
• 22:14
  Здатність фільтрувати дані одночасно за ролью та класифікацією –
• 22:18
  це саме те, що шукають зовнішні аудитори.
• 22:21
  Якщо замислитися, відповідність вимогам такого рівня – це не тягар.
• 22:24
  Це запобіжний захід, який підтверджує,
• 22:26
  що ваша система управління працює на практиці.
• 22:28
  Це також знімає стрес під час аудитів,
• 22:30
  оскільки вам не доводиться збирати інформацію.
• 22:31
  Дякую!