У корпоративних тенантів Microsoft 365 зафіксовано інцидент, коли Microsoft 365 Copilot отримував можливість читати та підсумовувати конфіденційні листи, попри діючі політики Data Loss Prevention (DLP) і мітки чутливості. Цей випадок демонструє, наскільки критично для бізнесу контролювати поведінку інтегрованих ІІ-сервісів у хмарних офісних платформах.
Суть інциденту з Microsoft 365 Copilot та помилкою CW1226324
Проблема торкнулася компонента Copilot Chat — чат-бота з доступом до робочого контексту користувача, вбудованого в Word, Excel, PowerPoint, Outlook та OneNote. Цей інструмент має на меті підвищувати продуктивність: генерувати резюме листів і документів, відповідати на запити, автоматизувати рутинні дії за допомогою генеративного ІІ.
Збій було зафіксовано 21 січня та зареєстровано під ідентифікатором CW1226324. Помилка проявлялася у вкладці Work в інтерфейсі Copilot Chat. Саме там асистент некоректно обробляв вміст папок «Надіслані» та «Чернетки», включно з листами, позначеними як конфіденційні за допомогою вбудованих засобів захисту інформації Microsoft 365.
Ключова проблема полягала в тому, що Copilot фактично ігнорував політики DLP та обмеження, накладені мітками чутливості (sensitivity labels). У типовому сценарії такі політики мають блокувати аналіз і повторне використання вмісту конфіденційних листів автоматизованими сервісами, щоб запобігти витоку чутливих даних через відповіді ІІ.
Чому збій у DLP є критичним для безпеки бізнесу
Як працюють мітки чутливості та політики DLP у Microsoft 365
В екосистемі Microsoft 365 мітки чутливості та політики Data Loss Prevention призначені для класифікації та захисту критичних відомостей: комерційної таємниці, персональних даних, фінансової, юридичної чи R&D-інформації. За правильної конфігурації ці механізми не лише шифрують дані й контролюють їх поширення, а й обмежують обробку такими сервісами, як Copilot та інші ІІ-інструменти.
У випадку з CW1226324 саме листи, позначені мітками чутливості, стали доступні для читання та узагальнення Copilot, що свідчить про логічну помилку в механізмі перевірки прав доступу на боці Copilot Chat. Microsoft публічно визнала наявність «помилки в коді», однак технічних деталей реалізації уразливості наразі не розкриває, що є типовою практикою для зменшення ризиків подальшої експлуатації.
Чому папки «Чернетки» та «Надіслані» становлять підвищений ризик
Папки «Чернетки» і «Надіслані» у корпоративній пошті часто містять максимально деталізовану інформацію. У чернетках фіксуються «сирі» ідеї, чорнові формулювання угод, неузгоджені фінансові показники чи внутрішні коментарі. У надісланих листах — вже погоджені позиції сторін, точні цифри, посилання на внутрішні системи, ПІБ співробітників та контрагентів.
Якщо ІІ-асистент може опрацьовувати ці папки в обхід DLP, зростає ризик того, що конфіденційна інформація опиниться у відповідях Copilot на запити користувачів, буде ненавмисно переслана іншим співробітникам або стане доступною ширшому колу осіб, ніж передбачено матрицею доступів організації. Навіть без зовнішнього витоку це вже порушує принципи мінімальних привілеїв і внутрішньої сегментації доступу.
Масштаби інциденту та розгортання виправлення Microsoft
За даними Microsoft, розгортання виправлення помилки CW1226324 розпочалося на початку лютого. Водночас компанія не розкриває точні терміни повного усунення збою, а також кількість постраждалих користувачів і організацій. Наголошується, що оцінка масштабів інциденту може змінюватися в міру продовження внутрішнього розслідування.
Як показують провідні галузеві звіти з кібербезпеки, дедалі більше інцидентів пов’язані не з класичними зламами периметра, а з логічними помилками, хибними налаштуваннями та дефектами в хмарних і ІІ-сервісах. Інцидент з Microsoft 365 Copilot — яскравий приклад: ІІ-помічник, покликаний спростити роботу з даними, сам стає потенційним каналом витоку внаслідок дефекту в реалізації політик доступу.
Що варто зробити організаціям, які використовують Microsoft 365 Copilot
1. Переглянути політику використання ІІ в організації. Доцільно тимчасово обмежити або диференціювати доступ до Copilot Chat для підрозділів, що працюють з особливо чутливою інформацією (юридичні служби, фінансові підрозділи, M&A, R&D). Один з підходів — розділення облікових записів і робочих середовищ для рутинних задач та для роботи з критичними даними.
2. Провести аудит міток чутливості та політик DLP у Microsoft 365. Варто ретельно перевірити налаштування DLP-політик, sensitivity labels, умов доступу (Conditional Access) та інших механізмів інформаційної безпеки. Для категорій даних з найвищим рівнем критичності, де це можливо, слід заборонити обробку ІІ-інструментами або максимально її обмежити. Важливо не обмежуватися теоретичною конфігурацією, а протестувати політики на практичних сценаріях використання Copilot.
3. Посилити моніторинг та аналіз журналів аудиту. Організаціям варто активувати й регулярно переглядати журнали доступу до контенту, зокрема запити до Copilot Chat. Це допоможе виявляти аномальні або надто широкі запити, пов’язані з конфіденційною поштою, а також швидше розслідувати потенційні інциденти.
4. Інтегрувати ІІ-сервіси в модель Zero Trust. Підхід Zero Trust передбачає, що жоден користувач чи сервіс — включно з внутрішніми ІІ-асистентами — не повинен мати надмірних прав доступу. Copilot слід розглядати як окремий застосунок із чітко визначеними правами на читання, індексацію й обробку даних. Обмеження мають регулярно переглядатися в контексті змін бізнес-процесів і ризиків.
5. Підвищувати обізнаність співробітників щодо ризиків ІІ. Навчання користувачів тому, які дані безпечно передавати ІІ-асистентам, а які ні, залишається одним з найефективніших захисних заходів. Співробітники мають розуміти, що навіть «вбудований» інструмент Microsoft 365 не гарантує абсолютної безпеки, якщо мова йде про критичну інформацію.
Інцидент з помилкою CW1226324 у Microsoft 365 Copilot демонструє: інтеграція генеративного ІІ в корпоративну інфраструктуру вимагає не лише оцінки користі, а й впровадження додаткових шарів контролю, валідації та моніторингу. Компанії, які вже сьогодні переглядають свої DLP-політики, впроваджують принципи Zero Trust для ІІ-сервісів та інвестують у навчання персоналу, суттєво знижують імовірність критичних витоків завтра. Використати цей інцидент як «контрольний аудит» власної стратегії кібербезпеки — прагматичний крок для будь-якої організації, що покладається на Microsoft 365 як на ключову бізнес-платформу.
