Михаил Божнев: Мы выбрали Change Auditor — он единственный работал в режиме реального времени

Мы побеседовали с Михаилом Божневым, ведущим специалистом отдела системного администрирования АО «СУЭК» — одной из крупнейших угольно-энергетических компаний. Центральной темой разговора был опыт внедрения продуктов Quest Software — Change Auditor и Enterprise Reporter. Также Михаил рассказал о своём видении повестки дня в ИБ, о контроле доступа к неструктурированным данным в компании и об интересных сценариях применения средств ИТ-аудита.

Из-за пандемии и «удалёнки» в ИТ и ИБ, как известно, многое изменилось. Какие тенденции, основные риски и «болевые точки» для российского крупного бизнеса можно выделить сейчас, в нынешних условиях?

М. Б.: Можно отметить большое нежелание выставлять важные сервисы наружу. Допустим, есть некий портал с расписанием работы сотрудников; коллеги из ИБ не очень хорошо представляют себе, что внутри этого портала, какие данные он в себе хранит и что позволяет сделать, и к тому же у них нет способов и механизмов безопасной его публикации — с выдачей доступа узкому кругу людей. Обычно проблема решается так: пользователю выдаётся VPN-подключение, позволяющее ему работать с порталом. Однако внутри VPN тяжело логировать что-либо, трудно анализировать веб-трафик, далеко не у всех есть системы, которые на это способны — а проверка такого рода важна, потому что пользователь может иметь доступ к VPN и к порталу просто в силу того, что состоит в определённой группе Active Directory, например. В конце концов, гранулярно выдавать доступ к VPN тоже тяжело. Так вот: всё ли он делает хорошо, когда взаимодействует с этим порталом? Возможно, он пытается внутри этого VPN-трафика поснифить порты или сделать ещё что-то подобное.

Сейчас прозвучала важная, на мой взгляд, тема: управление правами. Чем больше сервисов, тем труднее контролировать права.

М. Б.: Проблема даже не в том, чтобы управлять правами, а в том, что при большом количестве сервисов трудно их нормально описать — куда эти права распространяются, например. Даже если есть какой-нибудь ресурс — вики, Confluence, SharePoint, — где в теории можно составить такое описание, многочисленные сервисы потребуют отдельного человека или целого отдела, который бы этим занимался. В итоге получается, что сотруднику нужен доступ к какому-то сервису, а как этот доступ безопасно предоставить, никто не знает. С технической точки зрения проблем нет: имеется группа в Active Directory, есть правила на файрволе, настроена VPN и так далее. Но в организационном отношении нужная последовательность действий, правильная цепочка операций — в какие группы добавить этого сотрудника, кого уведомить о предоставлении доступа и тому подобное — не выработана или известна лишь паре сотрудников.

И ещё нужно убедиться, что мы не сделали чего-нибудь лишнего, проходя все эти шаги — например, не дали кому-то избыточные права.

М. Б.: Да. Повторюсь, есть нужные технические инструменты, которые позволяют всё это делать — в частности, IdM-системы, — но количество сервисов растёт быстрее, чем люди успевают создавать и отлаживать рабочий процесс. Основная проблема — именно в этом. Даже если сотрудники вовремя создают, скажем, статьи в вики или автоматизируют операции по наделению правами, возникают трудности при контроле. Допустим, рабочий процесс прошёл, каждый выполнил свою часть, но при этом нет ответа на вопрос: а то ли мы сделали, что было нужно человеку?

К слову об IdM-системах. Крупный бизнес, похоже, привык к мысли, что IdM — это важно и нужно, и я вижу, что сейчас уже начинают обсуждать некие новые вещи: например, управление правами доступа к неструктурированным данным. Приходилось ли вам решать такие задачи и насколько это актуально?

М. Б.: Приходилось, часто и много. В большой компании огромное количество файловых серверов. Наша айтишная часть развивается уже давно, и в любой такой структуре найдутся старые хранилища с неактуальными правами доступа, которые надо приводить в порядок. Решать такие проблемы можно опять же только при помощи организационного подхода. Вариантов два: либо мы остаёмся на старых серверах и упрощаем выдачу доступа, либо мы уходим в некое подобие SharePoint, когда у начальника отдела, например, есть некий ресурс, где он сам может посмотреть, у кого и к чему есть доступ. У нас сейчас — следующий подход: мы делаем новые файловые серверы и упрощаем там выдачу прав, регламентируя для каждого ответственного лица уровень вложенности этих прав для каждой сетевой папки.

Допустим, у нас есть папка предприятия, на которую уже распространяются некие присущие именно ей права доступа, а в ней — порядка пятидесяти папок отделов плюс общие директории для переноса данных и прочего. Внутри этих папок отделов — ещё каталоги, ещё права на них, постоянно поступают заявки на предоставление доступов. В итоге возникает вопрос: как мне посмотреть, у кого есть какие права применительно к папке моего отдела? Как сделать так, чтобы я мог сам зайти и выставить настройки: кому надо иметь доступ, а кому — не надо? И если мы говорим именно об обычных файловых серверах, то сделать это малореально. Продукт Enterprise Reporter, о котором мы будем подробнее говорить позже, хорошо помогал нам в этом; без него решать такие задачи не удавалось бы. Он позволял нам удобно мигрировать со старых серверов с хаотичными правами доступа на новые.

Сейчас мы ограничиваемся тем, что определённая группа пользователей (отдел) имеет доступ ко своей сетевой папке. Если некий отдел нуждается в предоставлении особого доступа узкому кругу лиц, мы предпочитаем создавать для этого отдельные каталоги и заводить особые группы пользователей. Так файлы не теряются в недрах сетевой папки отдела и всегда находятся на виду.

То есть, если я правильно понял, потребность в управлении доступом к неструктурированным данным появилась тогда, когда возникли запросы на проведение своеобразного аудита прав?

М. Б.: Причина здесь не столько в аудите, сколько в росте количества запросов на выдачу доступа. Было бы странно выделять особого сотрудника или целое подразделение сугубо на работу с правами для файловых серверов. Запросы, конечно, несложные, но отнимают очень много времени. Если же говорить об аудите, то он важен не сам по себе, а как составная часть другой задачи: начальники отделов просят, чтобы у них была возможность контролировать доступ к папкам своих подразделений. Для обычных файловых серверов, как я уже говорил, сделать это очень тяжело. Можно было бы реализовать это через систему автоматизации или некий аналог One Identity, но тогда не будет обратной связи. Такой подход не будет гарантировать стопроцентного понимания того, у кого есть доступ, потому что кто-то, например, может зайти в систему и выдать права вручную. Иначе говоря, через One Identity или другую подобную систему начальник отдела не узнает, у кого есть права на самом деле.

В системах Microsoft можно сделать запрос: выбрать папку, указать учётную запись пользователя и увидеть, какие у него есть права. Но это неудобно: нужно углубляться в настройки папки и к тому же можно посмотреть только одного человека за раз. Это — один из самых больших минусов файлового доступа.

И как раз для того, чтобы решить эту задачу, вы внедрили Quest Enterprise Reporter.

М. Б.: Частично. Он решает задачи аудита: когда кто-то спрашивает, у кого есть доступ к такой-то папке. Продукт генерирует нам кастомный отчёт, в котором эта информация представлена в лёгком для понимания виде. Но это — лишь часть проблемы. Другая часть — дать владельцам папок инструменты для управления доступом, чтобы они могли им распоряжаться самостоятельно. Здесь решение мы пока ищем. Один из вариантов — онлайн через SharePoint или другую аналогичную систему, где есть волшебная кнопка «Поделиться». Там это организовано буквально на уровне выпадающего меню, то есть никаких проблем нет вообще. Владелец видит, какие есть группы, кто в этих группах состоит, кому был предоставлен доступ к ресурсу вне групп и так далее. Основное затруднение — сам SharePoint, особенно если он облачный, потому что работать с его ресурсами как с обычными файлами трудно: другая идеология, надо переучиваться. Людям хочется просто щёлкнуть на файле правой кнопкой мыши, скопировать и вставить.

А в вашем случае Enterprise Reporter внедрялся легко или нужно было провести подготовительную работу, поднять какие-нибудь сервисы?

М. Б.: Там всё легко и сложно одновременно. Поднимается он легко, необходимые компоненты ставятся на один сервер. Сложнее понять принцип работы с ним. Change Auditor, например, прост и в плане установки, и в плане осознания логики его функционирования. Enterprise Reporter, наоборот, тяжело использовать, если ты не понимаешь, как он работает. Кроме того, если ты не взаимодействовал с ним, скажем, пару месяцев, то при возвращении приходится вспоминать — что, например, нужно сделать, чтобы он выдал отчёт.

А приходят ли к вам безопасники с вопросами о том, какие права поменялись?

М. Б.: Приходят, конечно. Это обычные запросы, ничего сложного для Enterprise Reporter в них нет. Но изменения прав лучше видны в событиях Change Auditor, и именно ему проще отвечать на такие вопросы. Enterprise Reporter может сделать два отчёта — что было тогда и что стало потом, — но это не так наглядно и не так удобно, отчёты нужно сравнивать вручную.

Соответственно, Change Auditor таким образом дополняет Enterprise Reporter и складывается эффективная связка. Они так и поставлялись — пакетно, вместе с ещё одним инструментом под названием InTrust. Change Auditor показывает события изменения чего-либо, а Enterprise Reporter — текущее состояние чего-либо. Например, когда у нас была крупномасштабная миграция серверов, Enterprise Reporter делал аудит всего имевшегося и далее на основании этого аудита коллеги переносили данные со старого сервера на новый, чтобы не искажать права доступа.

Ещё один сценарий — общий почтовый ящик. В Exchange не всегда возможно как следует посмотреть права на него; Enterprise Reporter способен их показать надлежащим образом. Тогда мы можем, например, увидеть, что не хватает чего-то имевшегося раньше, и с этой информацией целенаправленно поискать события в Change Auditor.

Что касается InTrust, который был с ними в одном пакете, это — подобие SIEM-системы. Он собирает журналы из любых источников, в том числе кастомных, и позволяет делать запросы — скажем, всей информации по некоему сотруднику — через веб-портал. Эта система у нас «не взлетела», по множеству причин. Есть и аналогичные системы, которые удобнее, и всё-таки InTrust требует много времени для настройки и корректной работы, а время в данный момент у нас — самый важный ресурс.

Насколько я понимаю, чтобы использовать оба продукта на том же файловом сервере, нужно установить на него агенты.

М. Б.: Да, два отдельных агента.

А как там дела с совместимостью? Поддерживаются все популярные среды?

М. Б.: Файловые серверы у нас только под управлением Windows; с ними никаких проблем нет. Охватить другие операционные системы было бы невозможно по техническим причинам: например, Change Auditor взаимодействует с драйвером файловой системы, который у Windows — свой собственный. Оба продукта, впрочем, работают с хранилищами EMC, которые не основаны на Windows; но и полноценный Linux там тоже не используется. Мы прорабатывали вопрос совмещения с Linux, но в итоге поняли, что для таких систем пришлось бы писать собственный парсер логов, которые с учётом специфики этой ОС могли бы к тому же оказаться недостаточно информативными. В общем, если мы говорим о файловых серверах, то это решение — для Windows-инфраструктур.

Каким из продуктов вы пользуетесь чаще?

М. Б.: Enterprise Reporter требуется нам изредка, а Change Auditor — буквально каждый день или через день, потому что его возможности по отслеживанию изменений являются более востребованными.

Change Auditor показывает изменения прав в режиме реального времени?

М. Б.: Это и не только. Он позволяет смотреть «в онлайне» вообще все события файловой системы: кто что удалил, кто изменил файл или права на него, перенёс папку и так далее, вплоть до простого открытия файла.

О, это важно. Сотрудник ведь может открыть файл и сфотографировать его на смартфон, например.

М. Б.: Да. Эти события настраиваются в профиле аудита, то есть их можно отслеживать, если есть такая потребность. Мы можем определить, какие именно события мы хотим забирать с файлового сервера. Здесь важен баланс, потому что избыточные логи тоже будут малополезны.

Стояла ли у вас задача провести совместно с отделом ИБ некую категоризацию данных? Выделить критически важные, разметить, если у того же Change Auditor есть такая возможность, и далее работать с ними уже более предметно?

М. Б.: Эта идея давно обсуждается, но на практике ещё не реализована. Было бы хорошо сделать это.

Внедрение Change Auditor и Enterprise Reporter было вашей инициативой, к которой потом подключился отдел ИБ, или наоборот?

М. Б.: Изначально мы искали продукты, которые позволили бы именно нам решить нужные задачи — такие как экономия рабочего времени. Некоторые из основных проблемных вопросов были связаны с Active Directory. Например, кто-то постоянно блокирует мою учётную запись; как выяснить, кто это делает? Если у тебя большая организация, то ответить на такой вопрос без внедрения стороннего продукта невозможно. Change Auditor легко справляется с этим и опять же экономит тем самым время коллег-администраторов.

Возможных сценариев здесь много. Допустим, кто-то зашёл в общий почтовый ящик и удалил все письма. Нужно определить, кто это был. То же самое — с файловыми серверами, только вариантов больше: в итоге может, например, оказаться, что человек ничего не удалял, а просто переместил папку с особо важными документами в другую, соседнюю. В Change Auditor всё это хорошо видно, можно делать выборку по времени, сортировать по действиям — удаление, перемещение и прочее. На это тратится буквально десять минут вместо часов разбирательств и переписок с коллегами и отделом ИБ, восстановления потерявшейся папки из бэкапа и так далее. К тому же восстановление из бэкапа в такой ситуации может привести к двоению данных, появлению дубликата: ведь папка была перемещена, а не удалена. Нужные документы обязательно начнут попадать «не туда».

А приходилось ли обосновывать покупку?

М. Б.: Расчёты окупаемости у нас не практикуются, но мы согласовывали закупку как совместный с отделом ИБ проект, пояснив, что это прикладной софт для работы, для контроля нашей инфраструктуры — тем более что стоимость там не астрономическая, не какие-нибудь десятки миллионов долларов. Нашу инициативу одобрили.

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

М. Б.: Именно. Благодаря этому у нас и внедрение прошло быстро. Мы с представителем вендора сели и всё сделали с нуля буквально за два-три дня. Мы дольше ждали серверы, чем ставили систему. Потом этот же представитель вендора показал нам, как в целом пользоваться продуктами, а дальше мы уже учились сами, иногда консультируясь с ним по сложным сценариям. Разобраться в Change Auditor, например, совсем нетрудно, он интуитивен, логично сделан и не вызывает проблем.

Кстати, как вы выбирали этот продукт, почему остановились именно на нём? Что для вас было важно, что понравилось?

М. Б.: Когда мы смотрели другие системы, оказалось, что решений по аудиту файловых серверов и событий на них в принципе немного, их даже можно не перечислять — все и так поймут, о ком речь. В других продуктах нас не устроил сам принцип их работы: например, в течение дня информация собирается, а ночью — анализируется, поэтому если кто-то одномоментно удалит 500 папок на файловом сервере, то мы об этом узнаем не сразу, а только ночью — то есть завтра утром. Компания у нас большая, от Владивостока до Москвы, и с учётом часовых поясов администраторы на Дальнем Востоке смогут получить информацию и отреагировать чуть ли не к концу второго рабочего дня. Инженеры того вендора, к сожалению, не смогли предложить никакого решения, когда мы обсуждали с ними этот кейс. Хорошо, что мы провели «пилот», потому что без него трудно было бы заметить эти особенности функциональности.

В итоге Change Auditor оказался единственным продуктом, который работал в режиме реального времени, и именно это нас и привлекло.

По опыту использования важный плюс — например, то, что он требует мало времени и сил на обслуживание и поддержание в рабочем состоянии. Максимум, что с ним может произойти, — переполняется база данных, недостаточно места для новых событий. Это неопасно: события просто кешируются и вносятся в базу позже, когда там снова появляется пространство. Мониторинг свободного места в БД — это, по большому счёту, всё, чего он от нас требует.

А чего, на ваш взгляд, не хватает в Change Auditor?

М. Б.: Нам очень не хватает логирования DNS-записей. Галочка в настройках есть, но нет нужных событий. У нас было много кейсов, когда DNS-записи пропадали: вчера она была и работала, а сегодня куда-то делась. Или, предположим, есть некий Windows-сервер, который сам сделал DNS-запись в домене; через неделю мы проверяем и оказывается, что сервер никто не трогал, а запись исчезла. Она просто не создалась заново или её кто-то удалил руками? По логам Change Auditor мы этого не поймём. Это, пожалуй, единственная наша проблема с ним.

Вы давно им пользуетесь?

М. Б.: В «боевом» режиме — примерно с мая 2017 года. За это время у нас возникло много интересных кейсов; на этапе «пилота» мы даже не предполагали, что они появятся. Впрочем, потребность в логировании DNS-записей возникает редко.

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

М. Б.: Из дополнительных функций мы начали активно осваивать кастомные отчёты. Например, раз в неделю Change Auditor автоматически создаёт нам отчёт по каким-либо событиям вроде доступа пользователей к определённой особо важной папке. Коллеги сами формируют себе шаблоны для отчётов, которые хотят получать на почту, контролируя тем самым разные интересные вещи — скажем, заполняются ли документы по бюджетированию на следующий год и почему такие-то люди, на которых возложена соответствующая задача, ещё не прикасались к этим файлам. Получается польза не только с точки зрения безопасности, но и в организационном плане. Бывает, люди отнекиваются: мол, я всё заполнил, а ваша система ничего не сохранила. Мы смотрим отчёт и видим, что человек даже не открывал этот документ.

Когда коллеги поняли, что в системе есть такая функциональность, они стали охотно ею пользоваться, тем более что процесс даже не зависит от администратора: один раз настроил, а дальше продукт всё делает сам.

Ещё отмечу, что Change Auditor может создавать алерты по событиям. Например, если в группу энтерпрайз-администраторов в Active Directory добавляется новая учётная запись, всем заинтересованным лицам сразу уходят уведомления об этом. Аналогичная функциональность есть в Microsoft SCOM, но тут это сделано сильно удобнее. Да и в любом случае два канала получения информации для разных людей — это лучше, чем один.

К слову, если говорить о развитии атаки, то есть ещё такой момент: уведомление позволяет реагировать быстрее.

М. Б.: Да, больше информированности. Система получает данные в режиме онлайн от агентов на файловых серверах и в других точках инфраструктуры, задержка очень мала. Мы можем сразу посмотреть событие, получить алерт на почту и так далее. При этом алерты от Change Auditor выглядят по-своему, отличаются от других уведомлений, и при получении такого предупреждения ты понимаешь, что оно было подготовлено вручную — его специально настраивали для каких-то конкретных целей. Иначе говоря, если этот продукт о чём-то сообщает, то, значит, случилось нечто важное.

Может быть, Change Auditor позволяет и запрещать какие-то действия?

М. Б.: Позволяет. Допустим, у нас есть консоль AD и у доменного администратора в теории имеются права на любые группы, которые он видит. Одна из таких групп даёт доступ к особо важной папке на файловом сервере, где лежат все финансовые отчёты компании. Предположим теперь, что администратор хочет добавить в такую группу самого себя или другого пользователя по его просьбе, чтобы «быстренько посмотреть» данные. Так вот, если работает механизм Protect в Change Auditor, то ты не сможешь никого включить в подобную группу, даже если являешься администратором домена. Это создаёт дополнительный уровень безопасности, который неподвластен привилегированному пользователю Active Directory: администратору не удастся быстро добавить кого-то в критически важную группу, потому что он не знает, что и где нужно для этого отключить. Клиент Change Auditor стоит на контроллере домена и пропускает через себя все события; если включена политика защиты, то он не даст внести изменения в группу.

Можно заметить, что эта функциональность хорошо ложится на ландшафт IdM и PAM. Когда администратор обнаруживает, что операция не выполняется, он может пойти в IdM- или PAM-систему и сделать запрос через соответствующий рабочий процесс, а не напрямую. В этом отношении Change Auditor может хорошо дисциплинировать привилегированных пользователей — чтобы прямых изменений в целевых системах не происходило. Здесь тоже есть потенциал для освоения новых функций и для централизации всех действий вокруг одного большого продукта по автоматизации рабочих процессов — в том числе организационными мерами, которые пока отстают от технических.

А есть ли ещё какие-нибудь «живые» сценарии использования продукта кроме тех, которые прозвучали раньше?

М. Б.: В основном мы отслеживаем изменения групповых политик и значимые операции над элементами в AD. Очень частая причина вопросов и обращений — блокировка учётной записи; использование других методов для поиска причины блокировки занимает гораздо больше времени, чем поиск с помощью Change Auditor, где всё доступно буквально на дашборде.

Change Auditor нравится нам в том числе и за эту доступность. Не обязательно вникать в то, какие данные он собирает и с каких серверов, чтобы оперативно получить нужную информацию.

Ещё один интересный кейс связан с тем, что у некоторых сотрудников бывает доступ к личным почтовым ящикам других людей — секретаря, например. В Change Auditor можно сразу увидеть, что операцию над почтовым ящиком произвёл кто-то не являющийся его владельцем. Это именно отдельная категория событий. В нативных логах Exchange подобного нет в принципе. Как следствие, мы можем отсекать, скажем, события чтения почты владельцем ящика и протоколировать только те случаи, когда его почту читает посторонний.

Спасибо за беседу! Желаю успехов!