Клиент вставляет номер карты в чат поддержки, когда спрашивает о возврате денег. Специалист замечает это, но разговор уже сохранен. Если включить маскирование после такого случая, это еще не докажет, что следующая чувствительная запись будет защищена.
Не включайте маскирование данных в надежде, что оно сработает само. Проверьте его на синтетических сообщениях во всех нужных каналах, направлениях отправки, экранах и сохраненных записях. Хороший тест скрывает чувствительное значение, оставляет полезный контекст читаемым и показывает, кто отвечает за пропуск.
Microsoft описывает ручное скрытие сообщения специалистом как опциональную функцию Dynamics 365 Contact Center с плановой общей доступностью в сентябре 2026 года. Она дополняет автоматические правила. Сроки могут измениться, поэтому сначала убедитесь, что функция появилась в вашем арендаторе. В описании функции Microsoft сказано, что специалист может скрыть отдельное сообщение клиента, чтобы личное значение не сохранялось в репозитории.
Сначала составьте карту возможного раскрытия
Начните с разговоров, которые действительно ведет ваша служба поддержки. Не копируйте длинный набор регулярных выражений другой компании. У нее другие данные, форматы и каналы.
- Чувствительные совпадения исчезаютКаждое одобренное критичное значение скрыто в обещанном канале и сохраненном представлении.
- Полезный контекст остаетсяНомера заказов и безопасные похожие значения остаются читаемыми.
- Различия каналов объяснимыКоманда объясняет различия чата, асинхронных каналов и направления отправителя.
- У отката есть владелецНазначенный человек отключит правило, вернет настройку и повторит набор тестов.
Запишите несколько типов данных, раскрытие которых действительно причинит вред. Это могут быть номер платежной карты, национальный идентификатор или личный адрес электронной почты. Номер заказа или серийный номер товара, наоборот, может быть нужен специалисту для решения вопроса.
Простыми словами определите область действия. Кто отправляет значение? По какому каналу? Нужно ли скрыть его от клиента, специалиста, стенограммы или везде? Автоматическое правило, ручное скрытие и права доступа являются разными мерами. Модель безопасности остается важной, потому что рядом со скрытым сообщением может лежать открытое вложение, заметка или карточка клиента.
Создавайте тесты без реальных данных клиентов
Нельзя проверять защиту, вставляя настоящий идентификатор клиента в тестовый разговор. Подготовьте синтетические значения, похожие на реальные форматы, но не связанные с человеком и платежом.
Для каждого правила нужны четыре группы:
- точное совпадение в ожидаемом формате
- реальные варианты с пробелами и знаками
- безопасные похожие значения, которые должны остаться видимыми
- неполные или ошибочные значения с заранее определенным результатом
Текущая инструкция по правилам маскирования говорит, что Dynamics 365 применяет регулярные выражения к чату и асинхронным сообщениям. Правила могут работать для сообщений клиента, специалиста или обеих сторон. Документация также перечисляет готовые правила для платежных карт, электронной почты и американских номеров социального страхования и ограничивает общее число правил десятью, включая готовые.
Поэтому важен приоритет. Слишком широкое выражение скроет номера заказов, даты и гарантийные ссылки. Слишком узкое пропустит номер карты с пробелами. Проверяйте оба вида ошибки.
Проверьте каждое место действия правила
Запустите синтетический набор в непроизводственной среде с теми же настройками каналов. Проверьте сообщение клиента в живом чате, асинхронное сообщение клиента, сообщение специалиста, если оно входит в область, и ручное скрытие.
Не ограничивайтесь окном разговора. Откройте его под другой разрешенной ролью, проверьте сохраненную стенограмму и поддерживаемые последующие представления. Если экспорт, аналитика или скопированная заметка находятся вне границы маскирования, так и запишите.
Общий ящик должен оставлять следующему владельцу достаточно контекста. Если правило превращает все сообщение в пустой блок, команда попросит клиента повторить информацию. Это не защищает ни конфиденциальность, ни обслуживание.
Разбирайте пропуски и ложные тревоги отдельно
Ложный отрицательный результат оставляет чувствительное значение открытым. Ложный положительный скрывает обычное значение, необходимое команде. Обе ошибки блокируют выпуск, но исправляются по-разному.
При пропуске сначала проверьте активность правила, направление отправителя и канал, затем сравните входные данные с выражением. При лишнем скрытии сузьте область. Меняйте одну причину за раз и повторяйте весь набор.
| Контроль | Доказательство до выпуска | Ответственный |
|---|---|---|
| Область правила | Утвержденный тип данных, отправитель и канал | Владелец приватности |
| Поведение выражения | Совпадения, варианты и безопасные похожие значения | Администратор Dynamics |
| Экран разговора | Правильное скрытие для каждой роли | Руководитель поддержки |
| Сохраненная запись | Синтетическое значение отсутствует в обещанном представлении | Владелец данных |
| Восстановление | Отключение или изменение проверено вне производства | Владелец изменения |
Закрепите владельцев выпуска
Один человек решает, что является чувствительным. Другой может настроить правило, но не должен незаметно менять политику во время написания выражения. Руководитель поддержки подтверждает, что оставшийся контекст пригоден для работы, а владелец данных объясняет границы удаления.
Задайте простое условие остановки. Не выпускайте правило, если критическое значение видно, безопасное значение стало бесполезным или команда не может объяснить разницу между каналами. Сохраните прежнюю конфигурацию, исправьте одну причину и повторите тест.
Маскирование является лишь одним уровнем контролируемой работы. Нужны права в карточке клиента, безопасные границы автоматизации и принятая ответственность после передачи. В DripTell мы используем тот же принцип: не переносить лишнее, но сохранять проверенный контекст для правильного человека.
Если команда проектирует такие меры для нескольких каналов, рабочая встреча с DripTell поможет превратить политику в проверяемый процесс. Решение о выпуске все равно должно опираться на ваши доказательства и обязанности.
Часто задаваемые вопросы
Удаляет ли маскирование Dynamics 365 старые чувствительные сообщения?
Не рассчитывайте на это без проверки. Поведение нового контроля испытайте в своем арендаторе, а ранее сохраненный контент считайте отдельной задачей исправления.
Можно ли тестировать с настоящими номерами карт?
Нет. Используйте синтетические значения нужного формата, которые не идентифицируют человека и не позволяют провести платеж. После проверки удалите тестовые данные.
Достаточно ли ручного скрытия?
Нет. Оно полезно для неожиданного сообщения, но человек может его пропустить. Сочетайте ручное действие с точными автоматическими правилами, правами, обучением и планом реакции.
Что должно остановить выпуск?
Открытое критическое значение, бесполезно скрытое обычное значение, необъяснимая разница каналов, отсутствие доказательства по хранилищу или владельца отката должны остановить выпуск.
Помочь применить это руководство?Спросить команду DripTell
От чтения к действию
Нужна помощь с применением этого подхода в вашей компании?
Оставьте контакты. Мы учтём материал, который вы читаете, и начнём с полезного ответа для вашей команды.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники
