Привет, Хабр! На связи Алексей Парфентьев, я в «СёрчИнформ» заведую инновациями и аналитикой. Каждый год мы изучаем, чем и как защищают данные российские компании (кстати, недавно делились первыми результатами этого года). Увидели, что доля внедрения DCAP-решений с 2021 года выросла почти в 10 раз (с 2,5% до 21%). Эта цифра меня зацепила — и вот я тут.
Вот в чем дело. DCAP — не новичок на рынке, первые полноценные российские решения появились пять лет назад, зарубежные гранды вроде Varonis известны и того дольше. На сегодня, на волне спроса почти каждый отечественный вендор DLP выпустил или начал разрабатывать собственную DCAP‑систему. И при этом ни у заказчиков, ни у вендоров пока нет консенсуса, что DCAP точно должны уметь!
На практике это значит, что системы на рынке часто сходятся только в заявленных задачах: это аудит, классификация и защита данных в корпоративных хранилищах (Data‑Centric Audit and Protection — см. классификацию по Gartner). А решают их все по-своему. Я решил разобраться, от чего это зависит, какие преимущества и риски у разных подходов и какой вариант — оптимальный.
Дисклеймер
Сразу оговорюсь: я разбирал общие практики на российском рынке, конкретные системы и вендоров не называл. Прямо говорю о нашем собственном опыте разработки DCAP, наша задача — най ти баланс, чтобы весь заявленный для класса решений функционал работал эффективно.
Краткая версия этих размышлений уже выходила на CNews: прочтите, если экономите время.
Какие бывают DCAP
Работа систем файлового аудита начинается с подключения к хранилищам данных и журналам. Источниками для DCAP выступают компьютеры пользователей, сетевые папки, облака, файловые, почтовые сервера, СХД, базы данных, контроллеры домена и т.д. Принцип работы DCAP с источниками определяется архитектурой: сетевой или агентской.
Самые распространенные DCAP — сетевые. Они подключаются к хранилищам по сетевым протоколам, сканируют их содержимое, читают логи, «смотрят» характеристики файлов и права доступа к ним. Как правило, такие DCAP работают с внешними источниками: сетевыми папками, облаками, сторонними файловыми логами и пр.
Реже используются агентские DCAP. Их главный инструмент — агенты. Это элементы программы, которые устанавливаются в нужное хранилище и внедряются в его ОС. Они собирают полные и подробные данные о файлах и операциях с ними, пользователях, которые работают с файлами, и их правах доступа. Но работать агенты могут только внутри инфраструктуры — там, где до хранилища можно «дотянуться» локально: на ПК и физических файл-серверах.
Архитектура определяет ограничения и возможности систем в том, чтобы выполнить свои задачи. Напомню, по Gartner это:
обнаружение и классификация данных,
отслеживание операций с файлами и прав доступа к ним,
обеспечение защиты данных.
Рассмотрим по пунктам, как эти функции должны работать «в идеале» и что показывают на практике в каждой из архитектур.
1. Аудит хранилищ
Первый шаг — аудит хранилищ. Понятно, что DCAP тем эффективней, чем больше источников может взять под контроль. В идеале система «видит» все: и локальные, и сетевые хранилища, и дополнительную информацию о правах пользователей на файлы и действиях с ними — из журналов файловых операций и системы распределения доступов.
Для этого нужны агенты под разные ОС, поддержка разных сетевых протоколов (FTP, API, WebDav и т. д.) и файловых систем (DFS, Ext4, NTFS и т. д.), интеграция с серверами почты и контроллеров домена, облаками и иными сервисами. В таком случае система будет универсальной, подойдет для любой инфраструктуры. На практике же такая комбинация встречается редко.
«Сетевые» DCAP номинально охватней. Они используют протоколы (NFS, FTP, SMB и др.), каждый из которых — возможность подключиться к целому классу хранилищ: облакам, файловым или обычным серверам и т. д. Плюс в том, что работа системы не ограничена особенностями OC, на которой работает источник. Но информация, которую такая DCAP получит из хранилищ, будет скуднее. Например, без дополнительных инструментов сложно достать данные о файловых операциях. Также DCAP логично останется ни с чем, если хранилище будет недоступно по сети — ведь обработка файлов в сетевом режиме происходит на стороне источника.
«Агентские» DCAP работают с меньшим количеством хранилищ. Во‑первых, агент не установишь в облако или на почтовый сервер. Во‑вторых, он «привязан» к ОС. А значит, привычный для одной системы функционал может быть недоступен для другой, в реалиях импортозамещения это может быть критично. Но у агентов есть важное преимущество. Часто у них больше полномочий, чем дает ОС, и поэтому они могут самостоятельно писать журналы: файловых операций, входов/выходов пользователей и иные. То есть не зависят от того, что им передаст источник, и получают больше информации — при аудите это дает более полную картину происходящего в хранилищах. Ну и имеют прямой, непосредственный доступ к файлам.
2. Классификация данных
Пожалуй, ключевая задача DCAP — качественная классификация обнаруженных данных. На этой основе отдел ИБ затем распределяет права пользователей и принимает решение, какие данные требуют дополнительной защиты.
Чтобы отнести файл к какой‑то категории, DCAP нужно «прочитать» его содержимое. Для этого нужны парсеры для разных хранилищ и форматов. Они извлекают контент и собирают атрибуты файлов, чтобы привести это все в читаемый для системы вид. Сюда же относятся элементы OCR и Speech‑to‑Text: аудиозаписи должны быть расшифрованы в текст, а изображения распознаны.
Далее требуются инструменты анализа: поисковый движок и разные виды поиска (по атрибутам, словарям, регулярным выражениям, смысловой схожести и пр.), по которым работают правила классификации. Они позволяют системе «понять», какая информация лежит внутри файла: номера телефонов, чертежи, платежные акты и т. д.
По правилам классификации данным присваиваются метки, которые описывают тип содержимого (ПДн, отчетность, договоры) и/или рекомендуемые уровни доступа к файлам (конфиденциально, общедоступно и пр.). В зависимости от реализации, метки:
«вшиваются» в тело файла (и видны конечному пользователю, который работает с документом),
вписываются в его метаданные («оболочку», характеристики файла – и «видны» ОС, файловой системе и ПО),
остаются «краткими описаниями» файла внутри DCAP-системы (и видны только ИБ-специалисту).
На практике это устроено так.
И сетевые, и агентские DCAP имеют парсеры, которые собирают информацию о файлах в хранилищах. Они «стучатся» в файл, вычитывают его и предоставляют системам «сводку» о том, какие данные в нем содержатся.
Различия начинаются при проставлении меток классификации. «Вшивать» их, то есть физически добавлять в файл или его метаданные, могут только агентские системы. Сетевые DCAP на это неспособны и ограничиваются метками, которые существуют только в среде программы. Но от того, где расположена метка, зависит, как DCAP справляется со следующей приоритетной задачей – защитой файлов.
3. Защита файлов
Управление доступом к файлам — самая востребованная для нужд ИБ функция DCAP. Система должна блокировать опасные действия пользователя с файлом, который ему не предназначен. Это предотвратит возможные нарушения: попытки переслать, изменить или уничтожить информацию.
Управлять доступом можно по‑разному. Например, так, как это базово умеют ОС и файловые системы: на уровне отдельных файлов, директорий и операций с ними (просмотр, изменение, удаление и пр.), «открытых» пользователю или группе. Ограничения применяются по атрибутам, когда доступ закрывается к конкретному файлу или папке. Но они не сработают, если пользователь получит статус администратора или изменит атрибуты (например, расширение), скопирует содержимое в новый документ или перенесет файл в другую директорию.
Там, где возможностей «стандартных» моделей управления доступом не хватает, их помогает дополнить и усовершенствовать атрибутивная модель. В случае DCAP это значит управлять доступом к файлам, опираясь на их содержимое: когда система применяет ограничения сразу ко всем файлам со схожим контентом, которым присвоена нужная метка.
Работает это следующим образом: драйвер, контролирующий файловую систему, распознает метку в файле и обращается в DCAP за «инструкциями», как его обрабатывать. Система дает инструкции вида:
какой класс файлов (по метке, атрибутам)
кому (по пользователям/группам)
где (на заданном ПК, в хранилище)
как (с помощью любого заданного процесса — Word, Skype, 1C, самописный мессенджер и т.д.)
можно/нельзя обрабатывать.
Например: запретить группе «Менеджеры» и пользователю Петрову взаимодействовать с файлами, где есть метка «Бухгалтерская отчетность». Или: запретить всем открывать файлы с меткой «Для служебного пользования» в приложениях почты, мессенджеров и облаков (читай – прикреплять их во вложения или загружать во внешние хранилища).
Если метка внедрена в метаданные файла, а не присутствует в виде текста или вотермарки в теле документа, «вытащить» ее невозможно. Даже при переносе контента в другой файл метка, привязанная к контенту, сохранится. Соответственно, если блокировка настроена по такой метке, обойти ее проблематично — это надежно. Но возможен такой вариант только там, где агенты DCAP внедряются в драйвер файловых операций — программу, которая контролирует все операции в ОС.
На деле это означает, что реально защищать файлы могут только агентские DCAP. В сетевых системах функции управления доступом или не реализуются вовсе, или ограничиваются описанными выше инструментами ОС (если контролируемое по сети хранилище это позволяет) — это сужает возможности.
Где баланс (и как мы его ищем)
Итак, оба распространенных типа DCAP имеют свои ограничения. Сетевые работают с большим количеством источников, но получают меньше данных. Агентские отлично защищают файлы, но только в локальных хранилищах. В идеале же ИБ-специалисту нужна система, которая сочетает плюсы обоих подходов. То есть гибридная DCAP — система, которая использует как агенты, так и сеть.
Это то, куда мы развиваем наш FileAuditor. С одной стороны, он работает локально на ПК и файл-серверах под управлением Windows и Linux. Агент работает в ядре ОС на драйверном уровне и записывает метки классификации в метаданные и в альтернативный файловый поток – это наша запатентованная технология, благодаря ей метки еще сложнее снять с файла* и обойти блокировки по ним.
*
Метка не видна пользователю, рядовой сотрудник точно не сможет ее снять. А если с ней что-то все же случится (например, не разобравшись, снимет администратор ОС, или ее повредит ошибка какого-то процесса), то FileAuditor заметит изменения, автоматически перепроверит файл и снова поставит метку.
С другой, на сетевом уровне FileAuditor поддерживает большое количество распространенных протоколов (SSH, SMB, FTP/SFTP/FTPS, HTTPS, WebDAV и др.), поэтому может контролировать сетевые папки, СХД и облачные хранилища за пределами локальной инфраструктуры. Можно подключить вычитку почтовых серверов Exchange.
В теории гибридная DCAP может все: от аудита и классификации до защиты, включая мониторинг прав и отслеживание истории файловых операций. Но на практике пока что это все еще происходит в разных местах — блокировки так и не применишь по сети, а агенты не поставишь в облако. Так что вендорам DCAP предстоит решить «задачу со звездочкой»: сделать так, чтобы аудит и защита работали везде одинаково хорошо.
Способы могут быть разные, общего подхода пока нет. Но работа идет. Например, мы видим решение в том, чтобы создавать интеграции.
Первый шаг в том, чтобы получать недостающие для DCAP данные оттуда, где они уже есть.
Возьмем файловые операции. Любая СХД «пишет» их в том или ином виде, в зависимости от своей ОС и файловой системы. Если СХД работает на Windows, нужно вычитывать ее журналы. Если ФС уникальная, например, как в хранилищах NetApp — ее журналы. Мы решили подключать эти журналы как отдельный дополнительный источник. В итоге FileAuditor вычитывает их, а затем сопоставляет данные об операциях из журналов с данными о файлах из СХД.
Так же FileAuditor работает с ActiveDirectory — получает оттуда данные о пользовательских правах. Плюс добавили вычитку журналов создания учетных записей и изменения прав и паролей.
Второй шаг — добирать функционал из других решений.
Например, FileAuditor не может применять свои блокировки в облаках, потому что при контроле сетевых источников метки не вшиваются в файл. Зато это умеет DLP. С нашим «СёрчИнформ КИБ» FileAuditor интегрирован бесшовно (буквально в общем интерфейсе). Он передает в DLP данные о метках в качестве собственного атрибута — он все еще существует только в рамках системы, зато КИБ «понимает» его, и может применять по нему уже свои блокировки. Например, «увидит» метку FileAuditor в перехвате с облаков — и запретит пользователю дальнейшие действия с таким файлом. Таким образом, классификация получается сквозная, и защита работает повсюду: причем не только всетевых источниках, а и в таких, к которым DCAP не «притрагивается» в принципе — например, на флешках, в печати и т. п.
Итого
Понятно, что просто так «сферический конь в вакууме», или DCAP «из палаты мер и весов», на практике не нужен. При выборе решения нужно отталкиваться от своих задач: это нормально, что кому‑то достаточно аудита там, где у другого в приоритете управление доступом к файлам. И все же мы ожидаем, что вскоре весь класс DCAP придет к пути объединения преимуществ «агентского» и «сетевого» подходов, и выбирать между «широтой обзора» и качеством защиты не придется. Средства и методы, вероятно, будут разные — продолжим следить за ситуацией и посмотрим, какой вариант окажется эффективней.