Область применимости
Процедура относится к отмене ранее применённого действия DLP в SharePoint и OneDrive согласно Management Activity API. Не переносите имя события на Exchange или Endpoint DLP как универсальное свидетельство обхода: у нагрузок различаются события и представления. Начните с конкретного документа, tenant и интервала. Сохраните идентификаторы правила и объекта, а также исходную запись. Одно отображаемое имя политики недостаточно для связи: оно может меняться или повторяться в разных средах.
Как отобрать отмены
В уже полученной копии исходного Audit выберите Operation=DlpRuleUndo. Команда jq оставляет ExceptionInfo как есть, не предполагая, что это всегда вложенный JSON-объект. В официальной таблице верхний тип и отдельное описание complex type не задают однозначно форму каждой конкретной выгрузки; сначала осмотрите фактическое значение. Затем уточните объект и RuleId, расширьте интервал назад и найдите DlpRuleMatch. В Activity explorer можно начать с фильтра DLPRuleUndo, но проверяйте названия столбцов и полноту экспорта отдельно от API-схемы.
Пример и причина
В авторской заметке перед отменой есть совпадение, а причиной указано Document Change. Корректная рабочая гипотеза — изменилось состояние документа, которое использовалось при оценке политики. Нельзя переименовать эту причину в «сотрудник нажал разрешить» без других данных. Схема также различает Override и Policy Change. Значение FalsePositive фиксирует заявленную оценку, а не технически доказанную ошибку классификатора. Текст Justification следует трактовать как предоставленное обоснование, проверяя его по процессу организации.
Что именно отменено
Найдите перечень OverriddenActions, если он доступен, и сопоставьте его с действиями предыдущего совпадения. Не делайте общий вывод «DLP отключён»: событие относится к конкретной оценке и объекту, а другие правила или ограничения доступа могут продолжать действовать. Сверьте действовавший режим правила, время изменения политики и версию документа. Даже после снятия одного ограничения реальный доступ внешнего получателя требует отдельного подтверждения в соответствующей нагрузке. Отмена действия и последующая передача данных — разные звенья цепочки.
Следующий шаг
При Document Change исследуйте версию и редактора объекта; при Policy Change — изменение соответствующей конфигурации; при Override — пользователя, разрешённый порядок и обоснование. Это направления проверки, не готовая атрибуция человека по DlpAgent. Сопоставьте доступные журналы изменений и временные метки, запишите расхождения часов или доставки. В расследовании оставьте ссылки на исходные события и укажите, что известно о текущей защите. Изменение политики или прав документа здесь не выполняется: сначала требуется понятное объяснение наблюдаемого результата.
Если отмена не найдена
Проверьте, что нагрузка вообще использует этот тип события, и что период включает как исходное совпадение, так и последующую оценку. Убедитесь, что не перепутаны DlpInfo, отметка ложного срабатывания и реальная отмена действия. Проверьте scope прав, задержку доставки и все страницы выгрузки. Сравните Activity explorer с исходным Audit; это преобразованные и исходные данные, а не одинаковые файлы. При отсутствии предыдущего Match или причины отметьте разрыв цепочки. Пустая выборка не подтверждает ни сохранение блокировки, ни успешный обход защиты. Отказ доступа к аудиту или неполная область выгрузки отличаются от нулевого результата. Уточните у владельца Purview разрешённую область чтения; доступ к чувствительному содержимому DLP предоставляется отдельно и для сопоставления идентификаторов обычно не требуется.