Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Василий Севостьянов: 
«Как безболезненно перейти с одного продукта на другой»

На вопросы «Системного администратора» о проблемах миграции и о том, как можно безболезненно переходить с одного продукта на другой, отвечает начальник отдела технического сопровождения продаж компании «Доктор Веб»

Беседовал Павел Наконечный

– Василий, насколько просто, по вашему мнению, мигрировать между корпоративным антивирусным ПО сегодня?

– Сама процедура довольно простая. Она начинается с удаления одного антивируса для перехода на другой. Как правило, для этого используются его штатные средства.

Большинство современных корпоративных антивирусов используют средства централизованного управления, которые позволяют его как установить, так и удалить. Централизованными средствами одного антивируса мы его удаляем, затем централизованными средствами управления другого антивируса устанавливаем новый. Здесь удобство и скорость процесса упираются в производительность железа и каналов связи, которые нужны для того, чтобы всю информацию туда-сюда передать. Сложно изобрести что-то принципиально новое.

Важно понимать, что антивирус как средство защиты информации обладает инструментами самозащиты, он не должен разрешать автоматически удалять себя какими-то сторонними средствами.

Для Windows существуют различные средства удаленного управления, которые как раз позволяют управлять программным обеспечением, установленным на рабочей станции: удалять и устанавливать ПО, обновлять его при необходимости.

Только антивирус не дает взаимодействовать с собой удаленно. Если антивирус позволит что-то сделать с собой без подтверждения администратора, то ровно то же самое сможет с ним сделать неквалифицированный пользователь (например, будучи введенным в заблуждение предложением «удалить антивирус, чтобы не мешал» из описания к скачанной игре) или вредоносное программное обеспечение. И после этого вредоносное ПО сможет делать с компьютером всё что угодно.

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

– Расскажите подробнее о технологии серверов центрального управления. В чем ее особенность?

– Идея довольно-таки простая. Поскольку обычно в корпоративной сети достаточно много компьютеров, управлять отдельно каждым из них трудозатратно. Чтобы этого избежать, соответственно, был создан центр управления.

Центр управления – это серверное программное обеспечение, которое, как правило, устанавливается на отдельный сервер. У нас, например, центр управления – кроссплатформенный. Он устанавливается на отдельном сервере. Затем к нему подключаются агенты, развернутые на рабочих станциях пользователей. После этого с помощью центра управления можно управлять всеми настройками этих агентов из одной точки. Сервер управления выполняет две функции.

Первая функция – это именно установка настроек и передача их агентам. Вторая функция – это сбор обратной связи от агентов. Агенты отправляют на сервер всю информацию по статистике сканирования, по выявленным угрозам, возможно, по каким-то действиям пользователя в случае необходимости.

Информация собирается на сервере центрального управления, где администратор может ее просмотреть. Соответственно, сервер в данном случае часто используется для распространения обновлений на рабочие станции пользователей. Тогда они напрямую из Интернета ничего не скачивают, это делает центр управления. Здесь еще получается экономия трафика по внешней полосе.

– При каком количестве компьютеров в сети его целесообразно использовать?

– Целесообразность зависит, в первую очередь, не столько от количества компьютеров, сколько от организации сети. Например, если в организации используется пара сотен рабочих станций, но все они автономные (не имеют подключения к сети), то их просто невозможно обслуживать с помощью сервера центрального управления.

Если же станции имеют подключение к сети, то уже при одном-двух десятках ПК использование сервера центрального управления имеет смысл просто для экономии времени специалиста. Чтобы из одного места можно было централизованно управлять всеми настройками, собирать всю информацию в сети.

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

Для администраторов крайне важен сбор информации об инцидентах. Если в локальной сети происходит инцидент с проникновением вредоносного ПО, это нужно расследовать.

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

– Как технология сервера центрального управления, которая вами разрабатывается, взаимодействует с Active Directory?

– Active Directory – это база управления, встроенная в операционную систему Windows. Она нужна как раз для передачи настроек групповых политик, централизованного управления пользователями, ведения общего списка компьютеров домена и прочего. И здесь не так уж и много получается точек пересечения.

С Active Directory центр управления может взаимодействовать для авторизации пользователей. Например, в центре управления можно задать список групп Active Directory, которые считаются администраторами антивируса. Тогда не нужно в центре управления создавать отдельных пользователей со своим логинами и паролями. Можно будет использовать те же данные для входа, которые эти администраторы уже используют в Active Directory, когда входят в домен.

Можно использовать Active Directory для распространения агентов на компьютеры. Через групповые политики Windows можно задать правило, что на компьютерах пользователей должно быть установлено ПО в виде агента антивируса. Тогда, когда эта рабочая станция в следующий раз к домену подключится, она скачает с него эти политики и применит их. Если еще не установлен агент антивируса, она его автоматически установит в соответствии с правилами, которые заданы в Active Directory.

Также Active Directory можно использовать для различных задач по группировке рабочих станций в антивирусной сети. В Dr.Web, например, все компьютеры, которые защищаются антивирусом, объединяются в так называемую антивирусную сеть. Она может выстраиваться по довольно сложной иерархической структуре.

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

Если у вас компьютер находится в какой-то конкретной организационной единице Active Directory, то на сервере Центра управления можно задать правило: компьютеры в этой организационной единице будут автоматически перемещаться в ту или иную группу антивирусной сети.

Также можно использовать список компьютеров Active Directory для того, чтобы его сканировать со стороны сервера центрального управления. Проверить: если там отсутствует антивирусный агент, то можно его туда установить.

– Вы упомянули еще одну функцию сервера центрального управления – передачу информации об инцидентах снизу вверх, от компьютеров к администратору. Какие технологии в этом помогают? Как это реализовано?

– В общем виде если на компьютере пользователя сработал один из антивирусных модулей, который обнаружил какую-то угрозу, то информация о нем передается на сервер управления.

Антивирусных модулей много. Каждый из них занимается наблюдением за своим сектором ответственности. И если какой-то из них обнаруживает угрозу, то модуль генерирует оповещение. Самый простой поиск – по сигнатурному анализатору. Просканировали какой-то файл – обнаружили, что он детектируется по сигнатурным базам.

В зависимости от настроек модуль также может выдать предупреждение пользователю: у вас выявлено вредоносное ПО. После этого на сервер управления отправляется информация о том, что на таком-то агенте в такое-то время таким-то модулем выявлена такая-то угроза, которая что-то пыталась сделать. Мы узнаем время инцидента, место инцидента, пользователя, у которого этот инцидент произошел, название файла. Сам файл будет перемещен в карантин.

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

Затем необходимо принять решение по угрозе. Если, например, в нашей вирусной лаборатории подтвердили, что это действительно угроза, то можно предпринимать какие-то действия для расследования: обратиться к этому пользователю, уточнить у него, каким именно образом он получил данную угрозу.

Здесь важны два аспекта. Можно провести опрос пользователя. Но также наш агент ведет подробные логи, по которым можно отследить весь путь проникновения файла на компьютер пользователя. Если пользователь получил файл по электронной почте, по логам можно отследить, что клиент электронной почты с такого-то адреса скачал письмо, в котором был этот самый зараженный файл. Пользователь этот файл открыл из почты и радостно нажал на кнопку «я хочу получить много счастья быстро, бесплатно, без регистрации и смс».

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

– Можно сказать, что сервер центрального управления выступает еще и как SIEM-система? Или же он интегрируется с внешними системами?

– Не совсем. Всё-таки SIEM-система – это отдельная сущность. Ее задача – собирать события безопасности от разных источников и выявлять корреляции между ними. Антивирус в данном случае будет лишь один из источников.

Важно помнить, что инциденты безопасности не ограничены исключительно вредоносным ПО. Может быть много различных аспектов, которые нужно собирать и разбирать их все вместе. SIEM-система как раз необходима для того, чтобы от различных систем информационной безопасности собрать всю информацию и выстроить общую картину. Антивирус здесь может дать только небольшую часть картины. Но довольно важную.

Мы достаточно часто сталкиваемся с просьбами помочь в интеграции с SIEM-системами. И у нас есть инструменты для этой интеграции.

– Какие еще проблемы могут появиться при смене антивирусного ПО? Мы удалили один антивирус, установили другой, а что-то не работает.

– Наиболее частые ситуации – это проблемы совместимости с различным ПО, которое уже установлено или только будет установлено на компьютеры пользователей. Чаще проблемы возникают в ситуациях, когда пользователь использует ПО, которое разработано данной компанией.

У антивируса есть достаточно много различных инструментов для анализа файлов, которые запускаются на компьютерах пользователя. Одним из важнейших элементов этой системы является ЭЦП (электронно-цифровая подпись) разработчика.

Все компании, профессионально занимающиеся разработкой ПО, имеют электронную цифровую подпись, которая также заверена в соответствующем центре сертификации. Когда они собирают свое ПО, то подписывают исполняемые файлы электронной цифровой подписью. По этой подписи можно убедиться в том, что, во-первых, это ПО было создано именно этим разработчиком, и во-вторых, что этот исполняемый файл не изменялся после того, как он был собран.

Доморощенное ПО, как правило, не имеет таких подписей. Антивирус при некоторых условиях может это ПО посчитать угрозой. Пользователь запускает какое-то неизвестное ПО, которое не подписано, мы про него ничего не знаем. У антивируса возникают вопросы, и он может начать блокировать это ПО.

Случаются проблемы с ПО, которое ведет очень активный обмен данными с диском. Мы довольно часто сталкиваемся с программным обеспечением, которое пишет большой объем логов. Всё, что пишется на диск, антивирус анализирует на лету. Поэтому если обмен данными с дисками очень интенсивный, то могут возникнуть проблемы с производительностью: ПО записало, антивирус должен теперь всё это прочитать. В случаях с не очень высокой производительностью диска и высокой загрузкой системы могут возникать проблемы. Они, как правило, решаются добавлением соответствующих файлов в исключения антивируса.

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

Если это ПО от разработчика, у которого есть электронно-цифровая подпись, то мы с такими компаниями обычно взаимодействуем.

Мы получим от них образцы ЭЦП, добавим у себя в список доверенных, и к ним будем относиться более спокойно. В некоторых ситуациях мы даем пользователю рекомендации внести какие-то файлы или папки в список исключений, чтобы антивирус их не проверял и не расходовал понапрасну системные ресурсы. Зачастую там и проверять нечего.

В некоторых ситуациях нам приходится взаимодействовать с разработчиками ПО, чтобы с ними договориться: где именно возникли проблемы совместимости, на чьей стороне их лучше всего решить, какие рекомендации можно в данном случае дать пользователю, как эту проблему решить быстрее всего.

– А какие шаги может предпринять системный администратор, чтобы упростить процедуру миграции для себя и компании?

– Рекомендация очень простая. Перед тем как начинать массовую миграцию, выделите некую пилотную зону, постарайтесь в нее собрать по максимуму разнообразные компьютеры пользователей. Разнообразные как по системной конфигурации, так и по установленному набору ПО. На пилотной зоне установите наш антивирус. И в течение какого-то времени просто понаблюдайте, не возникает ли каких-то проблем у пользователей при работе с ним.

Обычно этот период занимает 1-2 недели. Этого времени, как правило, достаточно для того, чтобы выявить все проблемы, которые появились, решить их и сформулировать конкретный перечень мер по их устранению, чтобы при массовой миграции они снова не возникли.

– Допустим, системный администратор убежден в том, что нужно провести миграцию с одного антивируса на другой, однако руководство выражает сомнение. Как убедить его в необходимости смены антивируса?

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

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

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

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

– Системный администратор убедился, что действительно стоит осуществить миграцию, – как ее осуществить, с какими проблемами может столкнуться, как убедить руководство. Остается небольшой момент – оптимизация дальнейшей работы антивируса. Какие технологии возможно использовать для Dr.Web или других антивирусов?

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

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

Но центральный сервер также будет полезен, если есть удаленные офисы. В удаленном офисе можно поставить промежуточный прокси-сервер, который будет обслуживать свои локальные рабочие станции. И этот прокси-сервер станет получать обновления от центрального сервера, а с него уже – все локальные станции. Если удаленный офис с узкими каналами, то можно на канале немножечко сэкономить.

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

– При помощи серверов центрального управления мы можем настроить обновления в закрытой сети без доступа в Интернет?

– Да. По умолчанию сервер центрального управления качает обновление из Интернета. Но он может их использовать и из локальной папки или с локального ftp-сервера, например. Тогда система будет работать в закрытом сегменте сети.

– Даст ли нам какой-то прирост производительности использование внешних баз данных для серверов антивируса?

– Здесь идея тоже довольно простая. По умолчанию сервер управления использует встроенную базу SQLite. Важно понимать, что это чисто файловая база данных. Ее основная проблема заключается в том, что, когда в базу ведется запись, все остальные операции не должны выполняться. Если мы пытаемся произвести в нее запись, когда мы из нее читаем, например, то мы не сможем ничего записать нового до тех пор, пока не завершатся все остальные операции.

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

В подобных ситуациях мы поддерживаем возможность использования внешних баз данных, причем здесь можно использовать как бесплатные (PostgreSQL, MySQL), так и платные (Microsoft, Oracle). Теоретически можно настроить связь с любой SQL-базой. Но мы стараемся из коробки поддерживать именно эти.

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

На практике же я обычно рекомендую клиентам, если они используют 250–300 станций, выбирать внешнюю базу данных, поскольку только она способна обслужить такой высокоинтенсивный обмен данными и одновременно чтение и запись. Как правило, любая современная внешняя база данных с этим неплохо справляется.

Кроме того, если требуется интеграция с SIEM-системами, то здесь тоже есть два варианта. Можно настроить прямую передачу данных из лог-файлов сервера в SIEM-систему, разбирать эти записи, анализировать. Либо SIEM-система может сама подключаться к базе данных сервера управления, получать из нее оповещения самостоятельно. Этот вариант, например, возможен только с внешней базой данных, из встроенной SQLite- базы это сделать не получится.

– Когда системный администратор принимает решение перехода с одной базы данных на другую, ему тоже нужно провести какую-то миграцию?

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

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

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

– Как системный администратор может правильно настроить подключение к серверу центрального управления при клонировании виртуальных машин в компании?

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

Если мы клонируем виртуальную машину, на которой установлен агент, то у нас появляется несколько виртуальных машин, каждая из которых имеет одинаковый идентификатор. Когда все они подключаются к серверу, у них начинается гонка за подключение: на каждого следующего подключающегося агента сервер прерывает соединение с предыдущим. Все агенты, если их много, начинают постоянно переподключаться: это нехорошо как для них, так и для сервера.

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

Мы рекомендуем, помимо того, что менять идентификатор, собирать их все в отдельную группу, и для этой группы применять агрессивную схему очистки. По умолчанию из баз данных сервера агенты удаляются по истечении 90 дней.

Если в течение 90 дней от какого-то агента подключения не было, он удаляется из базы сервера. В случае с такими клишированиями срок нужно сокращать, чтобы не было перерасхода лицензии. Иногда для хранения достаточно даже суток: если эти клонированные агенты больше суток не подключались, значит они больше не используются. Мы их удаляем из баз данных сервера, лицензии высвобождаются.

– Можем ли мы предотвратить попадание вирусов при помощи флешек, SD-карт, любых внешних носителей данных?

– Можем, причем для этого есть несколько способов. Во-первых, любой файл, который открывается с внешнего носителя, всё равно будет проверен антивирусом.

Некоторые организации вообще запрещают пользоваться внешними носителями. На этот случай у нас есть функционал контроля устройств. Он позволяет блокировать устройство как по шине подключения: USB, SD-карты, FireWire – вариантов довольно много, так и по типу устройств. Чаще всего блокируют именно внешние носители, внешние сетевые карты тоже любят блокировать.

В случае необходимости мы поддерживаем функционал белого списка (whitelist), то есть вы можете заблокировать все устройства кроме каких-то конкретных, у которых есть свои идентификаторы. Администратор добавляет этот список идентификаторов подключения в белый список, и тогда можно подключать только эти флешки, все остальные будут блокироваться.

– Может случиться такая ситуация, когда, условно говоря, мы настроили корпоративную сеть, 1000 компьютеров, и вдруг наш системный администратор забыл пароль от Active Directory или от сервера центрального управления. Что можно сделать?

– В таких случаях ему придется сбрасывать пароль. Это тоже возможно средствами центра управления, но для этого понадобится физический доступ к серверу центра управления, без каких-то потерь по настройке компьютеров или серверов.

– Какие сейчас существуют решения по автоматизации миграции у вашей компании или у каких-то других вендоров при переходе?

– Как правило, здесь используются штатные средства. Удаление в любом случае возможно только штатными средствами центра управления, а при установке обычно используются либо функционал удаленной установки, который доступен в центре управления, либо какие-то внешние системы. Нам встречались случаи, когда клиенты использовали, например, Microsoft SIEM для того, чтобы передать инсталлятор вместе с файлом конфигураций, которые он уже автоматически сам доставляет на рабочие станции пользователей. Инсталлятор с настройками запускается, подключается к серверу, сервер принимает и дальше передает все настройки.

– Что нужно знать системным администраторам при миграции о технологиях, о которых мы говорили сейчас?

– Самое главное, читать документацию, потому что в моей практике получается, что примерно 90 % вопросов, которые задают системные администраторы, на них дается ответ в виде ссылки на соответствующий раздел документации, и, как правило, этого всегда достаточно. Чтение документации решает большую часть проблем.

– Могли бы вы пошагово перечислить, что должен сделать системный администратор при переходе с одного антивируса на другой?

– Во-первых, начать надо с формулирования своих текущих политик безопасности. У кого-то они записаны на бумаге: на уровне приказа по компании или по ИТ-отделу существуют сформулированные требования к настройкам антивируса. Это идеальный случай.

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

Соответственно, нужно уже развернуть центр управления нового антивируса, и попробовать важные настройки перенести из старой базы данных в новую: воссоздать политику безопасности, понять, как переносится структура групп рабочих станций, как переносятся настройки политики безопасности для этих рабочих станций.

Предварительный шаг экономит много времени и сил на дальнейшую настройку. Уже не приходится на ходу это всё придумывать и восстанавливать. Соответственно, желательно при этом не забыть, есть ли какие-то исключения в старом антивирусе по проверке файлов или папок, если были какие-то исключения, их тоже нужно перенести.

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

В крупных компаниях, как правило, используется большой «зоопарк» как по железу, так и по различному программному обеспечению. Желательно, чтобы пилотная группа была выбрана разнообразно. Компьютеры должны быть разные по железу. Также следует постараться, чтобы весь набор программного обеспечения, который используется на предприятии, был охвачен пилотной зоной.

Естественно, это должны быть компьютеры, которые активно задействованы в работе и выход которых из строя не очень критичен. Чтобы если у кого-то произойдет какой-то инцидент, что-то перестанет работать, то это не парализовало бы работу всего предприятия.

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

– На какой размер компаний рассчитаны ваши решения по автоматизации миграции? Малый? Средний? Крупный бизнес?

– В общем, на любой. От масштаба меняется только продолжительность перехода. И то она может сильно зависеть от ресурсов ИТ-отдела. От того, сколько специалистов может быть задействовано в этом процессе. Даже если очень много рабочих станций, всё равно можно сменить довольно быстро при соответствующих ресурсах.

– Вы говорите, что многие проблемы легко решаются, если специалист внимательно читает документацию. Однако бывает сложно найти документацию разработчиков, потому что она не всегда поставляется вместе с решением, а находится где-то на сайтах. У вас документацию где можно посмотреть?

– У нас документация, во-первых, доступна внутри интерфейса центра самого управления. После разворачивания документация доступна локально. И точно так же на сайте. Как правило, когда мы продаем лицензии новым клиентам, наши менеджеры присылают им ссылки на документацию, дают рекомендации, уточняют, что искать в разделах документации. Их помощь понадобится вам на первых этапах внедрения.

Ключевые слова: миграция, антивирус, кибербезопасность, документация, лицензия

Подпишитесь на журнал
Купите в Интернет-магазине

Комментарии могут оставлять только зарегистрированные пользователи