Ваша DCAP не справляется: еще раз об идеальных vs достижимых требованиях к системе файлового аудита

Привет, Хабр! На связи Алексей Парфентьев, я в «СёрчИнформ» заведую инновациями и аналитикой. Каждый год мы изучаем, чем и как защищают данные российские компании (кстати, недавно делились первыми результатами этого года). Увидели, что доля внедрения 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 придет к пути объединения преимуществ «агентского» и «сетевого» подходов, и выбирать между «широтой обзора» и качеством защиты не придется. Средства и методы, вероятно, будут разные – продолжим следить за ситуацией и посмотрим, какой вариант окажется эффективней.