Автор: Олег Митичкин, руководитель направления DCAP ГК InfoWatch
Привычное представление об утечке данных прочно связано с понятием периметра, через который уходит нечто важное: письмо с вложением, загружаемый в публичное облако файл, копируемый на внешний носитель документ. Подобные действия – это кульминация инцидента. Но на деле все начинается гораздо раньше и куда менее заметно – с того момента, когда доступ к файлу получает сотрудник, не имеющий на это формального основания, но обладающий для этого технической возможностью. Документ еще не покинул организацию, еще не стал объектом сработки DLP, но уже перешел в зону потенциальной угрозы.
Такие перемещения от защищенной области к внутреннему публичному пространству почти никогда не воспринимаются как нарушение. Ведь данные все еще внутри периметра, передача произошла между коллегами, а доступ, возможно, сохранился с прежней роли или был выдан на время и забыт. Но именно такие незаметные смещения и составляют первую, настоящую фазу компрометации. Это утечка в латентной форме – без триггеров, без логов пересылки, без ощущения опасности.
Зрелость процессов информационной безопасности невозможна без способности видеть, фиксировать и анализировать внутренние перемещения и доступы – не только то, что вышло наружу, но и то, что вышло из поля контроля. DCAP в этой логике – не вспомогательный инструмент, а архитектурный слой наблюдения. Он нужен не для того, чтобы дублировать DLP, а чтобы работать там, где DLP еще не включилась. DCAP не противопоставляется DLP и не конкурирует с системами реагирования, а дополняет их в той области, которую они по определению не охватывают. Это взгляд внутрь – в ту самую зону, где утечка еще не произошла, но уже возможна, где документ еще не покинул инфраструктуру, но уже оказался в чужих руках. DCAP работает в области допущений, контекста и фонового анализа. И именно это делает его фундаментальным элементом зрелой архитектуры безопасности: без способности понимать, что происходит с данными внутри, невозможно всерьез защищать то, что уходит наружу.
Попытки внедрения DCAP в организациях нередко оборачиваются тем, что система либо остается декоративной, либо оказывается перегруженной. Она либо фиксирует слишком мало, ограничиваясь механическим поиском файлов с шаблонами номеров паспортов и бухгалтерских форм, либо предъявляет к ИБ-службе непосильные требования: вручную настраивать классификаторы, определять, что считать чувствительным, заполнять правила, согласовывать исключения и обрабатывать каждый отчет как инцидент. В обоих случаях решение формально присутствует, но практически не используется – не потому, что оно бесполезно, а потому что не встроено в инфраструктуру.
InfoWatch решает эту проблему принципиально иначе – не через расширение перечня возможностей, а через правильную точку входа. DCAP в этой модели – не просто инструмент в портфеле ИБ, а слой, встроенный в единую архитектуру безопасности. Это самостоятельный продукт, который логически и функционально дополняет DLP-систему InfoWatch Traffic Monitor [1]. Используются те же классификаторы, те же политики, тот же понятийный функционал. Файл, однажды признанный чувствительным в трафике, остается таковым и в хранилище. Доступ, выданный без основания, не просто зафиксирован – он становится частью досье, в котором объединяются события, люди и документы.
Решение InfoWatch отличается не тем, что может глубже сканировать, а тем, что не образует разрывов. DCAP и DLP формируют единое поле наблюдения: все, что найдено в покое, может быть проконтролировано в движении, а все, что зафиксировано в трафике, получает отражение в анализе хранения.
Вспомним, что утечка начинается не в момент отправки письма вовне, а в тот момент, когда файл оказался в общем доступе, стал доступен для копирования, сохранился в локальной папке пользователя, который не имел ни служебной необходимости, ни права на его просмотр. Такие случаи не попадают в поле зрения классических DLP-систем, потому что там еще не произошло действие, только возможность, которая имеет тенденцию превратиться в инцидент.
Другими словами, DCAP смотрит не на нарушение по факту его свершения, а на его предпосылку. Он фиксирует внутреннее движение данных, которое еще не стало утечкой, но уже вышло за пределы обоснованного доступа. И именно в этом его архитектурная ценность.
Программные модули установлены, политики заданы, отчеты приходят по расписанию – и этого вроде бы достаточно. Но в случае с DCAP подобная формальность оказывается особенно уязвимой: здесь недостаточно включить механизм, нужно чтобы все его части были согласованы – в логике, в ритме, в результате.
Суть DCAP – не в наличии функций, а в том, насколько они связаны между собой.
И наоборот: только тогда, когда все это соединено в единый цикл – осмысления, наблюдения, действия и восстановления – можно говорить, что DCAP не просто присутствует в инфраструктуре, а действительно защищает.
В архитектуре InfoWatch эта связанность достигается не путем интеграций между независимыми системами, а за счет изначального проектирования. Категоризация работает по тем же принципам, что и в DLP, правила едины, политики общие, логика согласована. Расследования формируются автоматически – не как внешняя экспертиза, а как продолжение сбора данных. И если что-то произошло – будь то утечка, удаление, нарушение доступа – платформа не просто показывает, кто что сделал, но дает путь к восстановлению: через бэкап, откат изменений, пересмотр прав.
На протяжении последних лет в информационной безопасности протекает острая дискуссия о миграции в облака – внешние, публичные, гипермасштабируемые. Однако в реальности крупные и особенно инфраструктурноответственные организации все чаще выбирают иной путь: они не уходят в облако, а строят его внутри, на своей земле, в своих стенах, в собственной зоне ответственности. Частные облака в формате on-premise становятся не компромиссом, а архитектурной нормой. И вместе с этим приходит новая сложность: контролировать данные в системах, которые вроде бы под контролем, но при этом асинхронны и полицентричны.
DCAP должен идти вслед за этой реальностью. Он больше не может быть привязан к простой файловой структуре, к статичному списку сетевых шар и серверам в дата-центре. Он должен уметь наблюдать за данными там, где нет иерархий, но есть сервисы; где нет папок, но есть тома; где нет локальных машин, но есть кластеры. Это не вызов на будущее – это задача уже настоящего.
InfoWatch DCAP [2] системно разворачивается в эту сторону. Именно в таких сценариях философия DCAP проявляется особенно четко: его задача не в том, чтобы просматривать список файлов, а в том, чтобы сохранять смысл даже там, где структура ускользает. Контроль в облаках – это не о визуализации, это о доверии.
Этот вопрос неизбежно возникает всякий раз, когда речь заходит о DCAP: действительно ли это самостоятельный класс решений, или мы имеем дело с очередной надстройкой, которая делает то же самое, что давно делают другие системы – только описано это другими словами? В картине мира, где каждый элемент ИБинфраструктуры требует ресурсов, внимания, сопровождения и отчетности, подобные сомнения вполне закономерны.
Но чтобы ответить на этот вопрос честно, нужно задать другой – а в каком виде DCAP действительно имеет смысл? Отдельный продукт, оторванный от DLP, от классификаторов, от политик и логики реагирования, превращается в нечто странное: в сканер, который знает, где лежит файл, но не понимает, что с этим знанием делать. Такая система может накапливать отчеты, может показывать диаграммы, но она не встраивается в принятие решений, не влияет на контуры доверия, не взаимодействует с инцидентами. Это больше наблюдатель, чем участник. И потому – да, DCAP "в отрыве" действительно не нужен.
Но когда он становится частью общей архитектуры, когда использует те же классификаторы, что и DLP, когда передает информацию в единое досье Центра расследований [3], когда связан с механизмами реагирования, – он перестает быть отдельным продуктом и становится новым уровнем в системе защиты данных. Он превращает защиту из череды разрозненных точек контроля в связную систему, где все, что происходит с данными, видно, объяснимо и обратимо. Поэтому InfoWatch DCAP – это самостоятельное решение, но в связке с Traffic Monitor он заметно расширяет ваши возможности.
Информационная безопасность – это не просто реакция на инциденты и не свод мер, регламентов и отчетов. Это, прежде всего, способность организации видеть собственные данные, понимать их и действовать в их отношении. И чем раньше включается такая логика, тем меньше вероятность, что вмешательство будет запоздалым. В этом смысле зрелая архитектура защиты строится не вокруг событий, а вокруг состояний: файлов, к которым не должно быть доступа; пользователей, которые не должны его сохранять; документов, которые не должны быть забыты в общих папках. Эти состояния не вызывают срабатывание тревоги сами по себе – но именно в них зарождаются последствия. InfoWatch DCAP встроен в этот цикл.
Он не замыкает его, не подменяет собой DLP или резервное копирование, но встраивается между ними как уровень осознания происходящего с данными до того, как возникает необходимость защиты или восстановления. Он делает то, что невозможно сделать только при помощи DLP: распознает скрытые доступы, теневые копии, растущие зоны доверия, которые никто не отслеживает, потому что они внутри периметра. Он делает то, что не сможет сделать бэкап: объясняет, почему файл исчез, кто его видел, как его путь пересекся с другими, какие решения к этому привели.
Именно благодаря этому появляется возможность действовать не вслепую, а уверенно – на основании контекста, смысла. DCAP превращает наблюдение в понимание, а понимание – в управляемость. И это уже не модуль и не инструмент, а элемент зрелой культуры обращения с данными, где защита – это не крайняя мера, а встроенная функция мышления.
Сегодня, когда границы инфраструктур размыты, когда облака находятся внутри периметра, а пользователи становятся распределенными, безопасность должна опираться не на формальные контуры, а на способность интерпретировать реальность в моменте. И именно это делает InfoWatch DCAP – не заменяя то, что уже выстроено, а добавляя к нему слой видимости, без которого все остальное остается частично уязвимым.