Софт на диете: как мы в DCAP OCR разгоняли
Привет!
Мы в «СёрчИнформ» 20 лет создаем софт для защиты информации и постоянно его оптимизируем. Например, последовательно работаем над ресурсоемкостью продуктов (низкая нагрузка на оборудование — важное преимущество для заказчиков), и придумали в этом направлении много удачных (не только наше мнение) решений.
Запускаем серию постов об этом. Сегодня — о том, как пересобрали архитектуру OCR в нашей DCAP-системе (файловом аудиторе), чтобы ускорить анализ изображений, не перегружая серверы и пользовательские ПК.
Короткие вводные
DCAP — это система для аудита и защиты файлов в корпоративных хранилищах (на файл-серверах, NAS, компьютерах сотрудников и т.д.). Система вычитывает все файлы в компании, классифицирует их по содержимому и управляет доступом к ним, контролируя права доступа и операции пользователей. Подробно об устройстве DCAP на примере нашего «СёрчИнформ FileAuditor» мы рассказывали тут, а здесь и здесь на собственном опыте показали, как он работает.
Первая задача DCAP — определить, какие файлы содержат наиболее чувствительную к утечке информацию (комтайну, персданные, финансовую отчетность и пр.). Чтобы контентная классификация состоялась, важно, чтобы система анализировала как можно больше форматов. И не только текстовых. Например, много офисной документации курсирует в PDF в виде сканов. Понять их ценность помогает распознавание текста с OCR. Вопрос в том, как удачно встроить модуль в систему.
Как работает OCR в DCAP
У нашей DCAP два формата работы: агентский и сетевой. В первом случае все операции: сканирование, вычитку контента, классификацию файлов система производит локально на файл-сервере или ПК пользователя. Во втором — система вычитывает файлы по сети, а всю аналитику осуществляет на собственном сервере.
Общая схема работы FileAuditor
Отсюда два варианта работы OCR.
Вариант 1. При агентском сканировании
Так, в общем виде, работает контентный анализ в FileAuditor, когда требуется OCR:
Создаем правила классификации в FileAuditor: ищем определенный текст в определенных документах, т.е. задаем ключ для поиска и перечень форматов документов для обработки — PDF, DOC и т.д. Например, все документы формата PDF, содержащие фразу «уставной капитал». (Характеристик для поиска можно задать больше — от атрибутов файла вроде размера или имени владельца до сложных контентных поисков, скажем, по регулярным выражениям + смысловой схожести с заданным образцом).
Запускается сканирование по правилу. Если из документа сразу извлекается текст, то и контентный анализ запускается сразу. Если нет текстового слоя, отдаем документ на распознавание TES (встроенный Text Extraction Server), он выделяет текст и отправляет в поисковый движок SearchServer (мы сделали его сами), чтобы тот искал текстовые совпадения.
После первого сканирования FileAuditor маркирует файлы в соответствии с правилами. Т.е. на каждый документ, удовлетворяющий условиям правила, ставит соответствующую метку.
После маркировки FileAuditor начинает мониторить изменения в файловой системе. Это значит, впредь перепроверка по правилам будет точечная: когда какой-нибудь документ был изменен или появились новые объекты для анализа.
FileAuditor «вырос» из нашей DLP «СёрчИнформ КИБ» и схему доступа к TES для обработки файлов с OCR унаследовал за ним. И при всех преимуществах это принесло две проблемы.
Проблема 1. В КИБ распознавание базируется на сервере, включается опционально и работает точечно: отдельно в каждом канале по заданным условиям. А в DCAP нужно вычитывать все по максимуму (хоть исключения тоже можно задать), это большие объемы данных. Перегонять их с каждой конечной точки (файл-сервера, пользовательского ПК) на «головной» сервер затратно, это перегружает сеть.
Решение: OCR на агенте
Первым делом, проектируя FileAuditor, мы переселили TES на агенты. Для этого мы его ужали и адаптировали: из 400 Мб в исходной версии для КИБ осталось 100 Мб за счет исключения из пакета редко используемых языков с собственными системами письменности (например, разнообразных азиатских и пр. –, но по запросу их можно вернуть) и других маленьких хитростей. Функциональностью пожертвовали осознанно, в приоритете была компактность.
Проблема 2. Если агент FileAuditor работает не на пользовательском ПК со сравнительно небольшим жестким диском, а на файл-сервере на условные 30 ТБ, большой объем задач OCR провоцирует рост нагрузки.
Документы на анализ выстраиваются в очередь: пока система проверяет один файл по всем правилам классификации, не запускается проверка других. Чем больше файлов в хранилище, тем больше растет время, затрачиваемое для выполнения операции.
В итоге, пока TES занят обработкой и анализом одного документа, контроль изменений в ОС уже сообщает о множестве изменившихся файлов. Могут быть ситуации, когда изменившиеся файлы нужно проверить срочно, т.к. им задан больший приоритет: например, там уже стоит метка, по которой системе требуется применить блокировку. Оперативное реагирование всегда на первом месте, а если FileAuditor занимаемся им, то другие процессы приостанавливаются — в частности, стоит на месте OCR файлов на диске.
При этом именно аудит больших хранилищ — основная задача наших клиентов. Мы сосредоточились на том, чтобы сделать OCR простым и быстрым в первую очередь на файловых серверах.
Решение: многопоточность
Мы добавили многопоточную обработку данных, это сокращает время анализа. Чтобы провернуть такое, потребовалось «размножить» наш поисковый движок на несколько маленьких. Запустить их параллельно — как открыть разные вкладки в браузере: один «минисёрч» будет заниматься, например, оперативным реагированием, другие сканировать диски. Соответственно, каждый из «минисёрчей» может запускать OCR.
Например, в папке на файловом сервере нужно просканировать 3 документа. Агент FileAuditor передает их на 3 «минисёрча», т.е. запускает обработку в 3 потока. Первый «минисёрч» обнаруживает, что его файл — PDF с неизвлекаемым текстом. Он может либо запустить один TES-экстрактор и ждать, пока ему вернется текст. Либо увидеть, что в документе 5 страниц, а в системе достаточно ресурсов, и запустить 5 экстракторов в параллель. Так же поступят второй и третий «сёрчи» — и если в каждом случае распознавание ускорится впятеро, то в общем станет в 15 раз быстрее.
(Тут надо оговориться, что все опционально: и количество потоков, и количество одновременно обрабатываемых страниц можно настроить и ограничить. Например, делать паузы в анализе, если нагрузка слишком большая. Так что многопоточность не «положит» машину, она аккуратная).
Многопоточный OCR на агенте в FileAuditor
Сейчас многопоточный OCR в FileAuditor работает только для файл-серверов. Функция становится доступна, когда агент «понимает», что имеет дело с серверной ОС.
Для десктопов функцию мы ограничили, чтобы не создавать допнагрузки. Ведь, когда агент для рабочих станций проектировался, мы хотели максимально не нагружать машину — не мешать работе пользователя ничем, даже усилившимся шумом кулера. Да и редко когда приходится анализировать сверхогромные объемы данных на обычном компьютере. Функция для ПК просто не нужна.
Вариант 2. При сетевом сканировании
Сетевое сканирование в FileAuditor предназначено для контроля «виртуальных» хранилищ вроде NAS или облаков, источников со специфическими ОС и файловыми системами и пр. Основное отличие такого варианта сканирования от «общей» схемы — отсутствие прямого контроля над файловыми операциями. Отсюда невозможность опираться на свежие изменения в файлах, чтобы сразу запускать перепроверки.
Анализ производит головной сервер FileAuditor, он подключается к сетевой шаре — берет документ — сканирует, и так до тех пор, пока не пройдет «круг». Когда круг закончен, система выдерживает паузу и заходит на второй круг, проверяя, не изменились ли файлы. Если видит, что файл изменился, то анализ по правилу происходит заново.
Первая версия сетевого сканирования файлов в FileAuditor: проверки шли «по кругу» каждый раз заново
После первого сканирования FileAuditor знает о документе все, что нужно — когда он был проверен и с каким результатом (под какие правила попал), все его атрибуты. Но если документ был изменен, вся предварительная работа как бы обнуляется. Когда речь об OCR, это значит, что в каждом случае «распознать» заново нужно каждую страничку.
Например, пользователь создал вордовский документ и вставил туда картинки с текстом. Картинок на десять страниц. Через время пользователь заменил одно изображение в файле –, а FileAuditor запустит перепроверку и новый цикл OCR на все десять страниц.
Это снова означает две проблемы: с производительностью и временем обработки.
Во-первых, OCR сам по себе — тяжеловесная операция, она требует довольно много ресурсов процессора и памяти. Нагрузка, которую создает OCR, зависит от многих факторов: количество документов на обработку, качество обрабатываемого изображения, много чего еще. При этом она одинаковая при каждом цикле проверки, сколько бы раз ни пришлось перепроверять документ после его изменений.
Во-вторых, как уже говорили, FileAuditor действует последовательно: не проверив один файл на все правила, система не может пойти дальше. Это хорошо для тщательного анализа новых документов, но раз за разом тратить время на новые перепроверки уже «обработанных» — нецелесообразно.
Решение: запись результатов распознавания
Чтобы избежать очередей и большой нагрузки, мы задействовали AAServer — компонент, которому можно делегировать обработку данных. Его удобно использовать, когда мощности основного сервера нужны для оперативного реагирования, а результаты анализа документа нужно тем не менее сохранять.
Теперь, когда FileAuditor находит файл с неизвлекаемым текстом, он проводит OCR и отдает результаты AAServer«у на хранение. AAServer записывает их в базу и может не повторять затратную операцию каждый раз, когда документ снова нужно проверить. Зато быстро выдает при новом запросе готовый результат.
Для повторных проверок получилась такая схема:
DCAP сканирует файл-сервер и встречает PDF, который нужно отправить в ОСR. Сервер FileAuditor считает хэш этой PDF и формулирует запрос для текстового поиска. Вычисленный хэш отправляется на AAServer и сравнивается с хэшем в базе.
Если точно такой же хэш в базе есть, в ответ присылается готовый текст. В этом случае «распознавание» закончено, идет контентный анализ и проверка по правилу классификации. FileAuditor может браться за следующий нетекстовый документ.
Если хэша в базе нет, FileAuditor на своем сервере запускает TES для проведения OCR. Затем TES передает на AAServer хэш обработанного файла и извлеченный из него текст (удобно, что большие документы хэшируются постранично). Тем временем сервер FileAuditor с помощью поискового движка анализирует текст и проверяет файл на соответствие правилам.
Работа OCR при сетевом сканировании FileAuditor с привлечением AAServer
Вернемся к примеру, где пользователь создал вордовский файл с картинками.
FileAuditor проверит его при первом сканировании: получим распознавание каждой вставленной в документ картинки и отдельный хэш для нее. Хэши и извлеченный текст отправятся на AAServer.
Через время, как мы помним, пользователь заменил одно изображение в файле — обнаружив изменения при следующем сканировании, FileAuditor запустит перепроверку. И вместо того, чтобы заново OCR«ить тяжелый документ целиком, обратится на AAServer. Там обнаружится, что 9 из 10 переданных по документу хэшей совпадают, то есть 9 из 10 изображений не изменились. FileAuditor не будет тратить мощности на их повторное распознавание текста и проведет OCR только для одной изменившейся картинки.
Вот, смотрите: сделали несколько анализов для одного и того же файла — скана в PDF на 90МБ. Видно, что в первом случае анализ с OCR происходит, а при повторной проверке — уже нет. Потребление ресурсов минимальное, а результат тот же: файл проверен.
Замеры производительности при первоначальной и повторной проверке нетекстового файла в FileAuditor. Слева — первое сканирование с OCR. Справа — повторная проверка, когда вместо нового OCR FileAuditor обратился за сравнением исходного и изменившегося файла на AAServer (хэш-суммы совпали, т.ч. OCR повторно не проводился)
Итого
Мы прогнали кучу тестов и убедились: OCR в FileAuditor стал быстрее, а ресурсов на него тратится меньше. В планах — объединить преимущества многопоточной обработки и интеграции с AAServer, чтобы «гибридный OCR» стал доступен и по сети, и на агенте.
Пока видим проблему, что машины с агентами, будь то ПК или файл-серверы, будут одновременно генерить огромное количество запросов. А если с каждого агента (представьте, сколько ПК в большой компании) на AAServer стучаться будет не один, а несколько «минисёрчей», есть риск его буквально «заDDoS«ить». Но это — следующая задачка, и мы над ней уже работаем (может, скоро расскажем, как справились).
Будем рады вопросам, как, что и зачем мы сделали, если что-то осталось непонятно — с удовольствием ответим в комментариях. Симпатичных находок в том, как оптимизировать свои продукты, у нас немало. Так что заглядывайте в блог, будем продолжать делиться
