Как стать автором
Обновить

Сложности применения технологий OCR в DLP-системах, или Как мы OCR готовим

Время на прочтение 10 мин
Количество просмотров 9.7K
Всего голосов 36: ↑31 и ↓5 +26
Комментарии 13

Комментарии 13

на примере работы OCR-технологий ABBYY, которые мы используем в собственной DLP.


Коммерческий продукт ABBYY в OCR это FlexiCapture 12 версии, у которого в коробке имеются решения для всех описанных в статье проблем распознавания (речь про 2 релиз).

Таким образом все описанные проблемы из проблем превращаются в донастройки самой программы.

Куда более интересным является вопрос как именно выявляется секретная информация на изображениях и что Вы будете делать с фотографией рукописного текста, отправляемой по электронной почте?
ABBYY FlexiCapture — это решение под Windows. Мы же работаем под Linux и используем ABBYY FineReader Engine, который устанавливается прямо на серверах нашей DLP. Это решение также предоставляет возможности OCR, и это коммерческий продукт. Возможно, тут стоит подумать над интеграцией с FlexiCapture для случаев, когда он уже есть в компании.
Выявление конфиденциальной информации осуществляется согласно политике фильтрации – контентный анализ, цифровые отпечатки и т.д. Здесь OCR помогает получить текст из изображения, а дальше полученная информация отдается обратно на обработку сервису фильтрации, который прогоняет текст по политике и создает события (если есть срабатывания).
С рукописным текстом ситуация другая. Это уже технология ICR (Intelligent Character Recognition). Для распознавания тут требования строже в том плане, что буквы и цифры должны быть написаны по шаблону. Другими словами, если что-нибудь написать не каллиграфическим почерком, сфотографировать и потом попробовать распознать, то результата никакого не будет. Или будет, но нас не удовлетворит.
Задачу нахождения изображений, которые не получилось распознать, можно решить при помощи политики фильтрации DLP-системы и поиску сообщений с изображениями в архиве.
Типичное ощущение от современного ИТ.
Если бы вы кроме ИТ поработали в реальной экономике, вы бы увидели — везде существуют вполне конкретные требования к исходному сырью/материалам, при несоответствии которым любой здравомыслящий технолог прямо отправляет в лес.
И только в ИТ вижу обратное — собрав в кучу и нормальное, и мусор, пытаться сделать каменный цветок, применяя всякие подвыподверты и костыли…
Может проще было бы сортировать документы, и несоответствующие переделывать вручную с компенсацией из фонда зарплаты подразделения, увлекающегося отсылкой мусора?
Не уверен, что правильно понял вопрос.
Требования к «исходному сырью» могут существовать, а могут и нет. Даже если требования существуют, то все равно возможны ситуации, когда сотрудники пересылают несоответствующие этим требованиям документы. Требованиями можно контролировать финальный вариант документа, который вы будете сдавать руководителю/в бухгалтерию/в кадры, а вот что с документом происходит, пока он готовится и подгоняется под требования — уже другая история.
Часть мусора можно отбросить и не распознавать (задать ограничения в системе), но опять же не все хотят задавать ограничения, а хотят распознавать всё и вся.
По сортировке. По факту она есть. Это как раз системные ограничения, т.е. DLP будет сразу определять, нужно обрабатывать эту картинку или нет.
Да и в целом суть OCR и DLP как таковой в том, чтобы в огромном потоке трафика выявить утечку. А в трафике может быть все, что угодно.
После вашего второго предложения мне трудно с вами о чём-то говорить дальше. Возможные ситуации — это исключения, и как бы вы не старались, учесть их все невозможно.
Почему нельзя контролировать требованиями/ограничениями материалы для распознавания? Вы сами написали кучу требований…
Ограничения задают производители оборудования. И проблемы с ними три — нередкая неоправданность, недоведение до эксплуатационного персонала, нежелание эксплуатационного персонала их соблюдать (с чем и боремся рублём).

Ваш подход к ограничению неверен — вы пытаетесь свернуть бесконечность в круг. Нормальные ограничения — это, наоборот, построение круга из точки — НАБОР ТРЕБОВАНИЙ, которым должны отвечать документы для распознавания (а остальное — проблема отправителей).

И выявлять утечку чего с OCR вы собрались?
Мы не предъявляем жесткие требования к изображениям, которые необходимо отправлять в систему. Мы выдаём рекомендации для эффективной работы OCR-модуля нашей DLP. В саму систему можно отправлять любые изображения, а обрабатывать их или нет, DLP решает согласно заданной конфигурации.
Именно материалы для распознавания ограничить требованиями достаточно сложно. Как пример, вам придется во всей компании закупить одинаковые сканеры (чтобы все сканы были одинакового качества) и запретить создание любых скриншотов на ПК пользователей (ведь это тоже источник изображений). Но вы действительно хотите описывать для сотрудников правила создания скриншотов?
Плюс у вас все равно останется вариант, когда пользователь что-то сфотографирует и отправит по почте (доступ к корпоративному ящику с телефона).

Другой момент в том, что вы можете использовать DLP, а сотрудники об этом знать не будут, вы просто мониторите почтовый трафик и действия пользователей при помощи агентов на рабочих станциях.
Создавая регламенты\требования\ограничения на материалы для распознавания, вы вызовете у пользователей вопросы.

В целом вопрос ограничения «исходного материала» остается на стороне каждого отдельного заказчика. У кого-то интернет закрыт, кто-то телефоны на входе забирает. Поэтому тут решать вам – создавать требования к «исходному материалу» или нет.

Отвечая на последний вопрос. Изображения могут содержать конфиденциальную информацию и обычным контентным анализом текст из изображения достать не получится. Собственно для этого и нужен OCR. Он помогает получить текст из изображения, а дальше полученная информация отдается обратно на обработку сервису фильтрации, который прогоняет текст по политике и создает события (если есть срабатывания).
Обычно, если жёсткие требования не предъявляются не входе, то они не предъявляются и на выходе. Если так, о чём говорить дальше…
Почему сложно? Закупка одинакового оборудования, помимо экономии на скидке, резко облегчает многие вопросы благодаря унификации и возможностям перекрёстного обучения. По поводу скринов — имхо важно одинаковое разрешение и цветовая гамма, что опять таки вопрос унификации.

У ваших пользователей рабочие инструкции вопросов не вызывают? Почему должны вызвать вопросы другие инструкции?

Опять вы пытаетесь поставить с ног на голову… Сырьё перерабатывает ваша система. И именно её ограничения будут определяющими. Касательно запросов пользователя — вы можете только адаптировать систему к ним полностью или частично.

Честно говоря отправлять в открытом виде конфиденциальную информацию вообще нонсенс. А даже если и так — ну добавил мусора на картинку (как на капчах), занизил DPI, сделал текст низкоконтрастным и дальше что… И это не говоря уже об архивировании с паролем, стеганографии, криптографии.
1) OCR не единственная технология распознавания текстовой информации, есть также ICR, OMR и т.д.;
2) Не совсем понятно зачем выставлять таймауты? Сервера систем распознавания самостоятельно способны выстраивать очередь т.к. в любом нормальном сервисе запрос на распознавание и получение результата выполняется асинхронно;
3) В статье описаны случаи «донастройки» под каждый вариант изображения — согласен, однако где автоматизация? Или случай что в одном потоке могут приходить разные изображения в рамках одного проекта — не учтен? Т.е. например нам нельзя передавать в стороннюю систему паспорт и мы его игнорируем, но вот незадача OCR не смогла прочитать текст с имеющимися настройками — считаем что это просто картинка и передаем…
4) В статье несколько раз упоминается «единственный верный путь», что в корне разнится с современными автоматизированными системами построенными в т.ч. на нейронных сетях.
1. Да, согласны, что кроме OCR есть и другие технологии. Это распознавание рукопечатного текста, меток, штрих-кодов. Но в целом ICR, OMR можно считать некими надстройками над OCR или расширением его возможностей.
2. Таймауты нужны для корректного взаимодействия сервисов между собой. За фильтрацию отвечает один сервис, за распознавание изображений — другой. Первый делает запрос в OCR и ждёт пока он распознает. В частности, это нужно когда DLP-система работает «в разрыв» для применения активных блокировок и предотвращения утечки информации. Т.е. таймаут нужен, чтобы не ждать бесконечно ответа от сервиса распознавания (OCR).
Внутренняя очередь нужна, чтобы OCR последовательно обрабатывал все поступающие к нему запросы. Тут мы подошли к ещё одной необходимости в таймаутах. Они нужны, чтобы сам движок OCR не пытался бесконечно извлекать текст из изображения и не уходил в бесконечную обработку нескольких изображений, тем самым увеличивая ту самую внутреннюю очередь.
3. Вопрос с автоматизацией можно объединить с п.4. Определенная автоматизация есть, мы «из коробки» устанавливаем рекомендуемые параметры для OCR. Но тут речь идёт об автоматизации в более широком смысле, как я понял. Т.е. учиться распознавать изображения, откидывать мусор, донастраивать систему в автоматическом режиме, без какого-либо вмешательства. Да, нейронная сеть тут может помочь, но и её нужно обучить для начала, потому что трафик у разных заказчиков разный. Т.е. все равно донастройка потребуется, хотя и в меньшей степени.
А вот вопрос с разными изображениями в одном потоке не совсем понял. Вы имеете ввиду, что паспорт не должен утекать во внешний мир, а из-за того, что OCR не смог распознать текст, DLP его пропустила дальше?
Принято. Последний вопрос — да, что происходит с теми документами которые по той или иной причине (ошибка в т.ч.) не распознались должным образом?
Здесь мы можем либо просто пропускать, либо создавать события, либо блокировать сообщения, содержащие такие изображения (зависит от режима работы DLP — пассивный или активный).
Кроме этого есть дополнительные средства анализа документов и сообщений. Например, цифровые отпечатки.
Вот неплохо было бы в статье (последующей уже) побольше информации именно об этом написать.
Т.к. в любой системе среди главных критериев: масштабируемость, стабильность, эффективность работы. А то что в DLP можно использовать OCR — это не новость, а скорее один из вариантов автоматизации. Плюс в статье нет цифр — показатель эффекта от внедрения конкретно Fine Reader, а тоже было бы интересно.
А так, спасибо за статью. Первый раз за несколько лет пишу комментарий.
Согласны, что использование OCR в DLP — это не новость, мы хотели осветить именно возможные сложности при использовании OCR в DLP.
Замечания учтем на будущее. Спасибо за ваши комментарии.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий