Семь распространенных проблем при внедрении отечественных средств защиты: практика интегратора

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

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

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

Проблема №1. Производительность

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

Проблема №2. Отказоустойчивость

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

Проблема №3. Автоматизация развертывания решений в Linux-среде

Когда средство защиты нужно развернуть на большом количестве хостов, не обойтись без инструментов автоматизации. В случае со средой Windows такие решения существуют и по нашему опыту работают хорошо. Есть общие методы развертывания, например, распространение через групповые политики Active Directory или c помощью технологии System Center Configuration Manager (SCCM), так что можно установить любое количество агентов на серверы и рабочие станции. К тому же, в целом практически каждое решение имеет собственную систему распространения хостовых средств защиты в Windows-среде.

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

Проблема №4. Отсутствие API

Угодить в ловушку при внедрении отечественных средств защиты можно и по причине отсутствия в них API (Application Programming Interface) — интерфейса, с помощью которого взаимодействуют различные решения. Этот инструмент помогает автоматизировать многие действия на проектах по системной интеграции, включая миграцию с иностранных решений на отечественные. Например, при тестировании одного из российских межсетевых экранов следующего поколения нам нужно было проверить, как функционирует продукт, когда в нем работает примерно пять тысяч установленных правил, при этом какого-либо API в продукте не было. За пару часов работы над этой задачей проводивший тестирование инженер пришел к выводу, что рутинные действия отнимут у него несколько десятков часов, тогда как на решение похожих задач с API обычно требуется не более нескольких часов. Конечно, несмотря на возникшие сложности, решение всё-таки нашлось: для ускорения настройки специалист смог написать скрипт, который автоматически генерировал файл конфигурации. Чтобы избежать подобных проблем, особенно в случаях, когда стоит задача миграции с одного решения на другое, стоит обращать внимание на наличие API еще на этапе выбора продукта.

Проблема №5. Интеграция с российскими ОС и платформами виртуализации

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

Проблема №6. Соответствие требованиям

Еще одна проблема может возникнуть при выполнении требований регуляторов. Цикл сертификации средств защиты в России довольно долгий, что приводит к некоторому отставанию используемых в инфраструктуре сертифицированных продуктов по кибербезопасности от технологий, которые применяют разработчики. Если информационная система только создается, решение несложное: достаточно сообщить команде, отвечающей за построение инфраструктуры, все необходимые требования на старте проекта. При их соблюдении проблем с установкой средств защиты не возникнет. А вот если средства защиты нужно установить на готовую инфраструктуру, сценарии могут быть разными. Если изначального требований в инфраструктуре с точки зрения информационной безопасности не предъявлялось, то может возникнуть много технических проблем, которые не всегда решаются техническими методами ввиду несовместимости средства защиты и ПО инфраструктуры. В одних случаях приходится использовать предыдущие сертифицированные версии ПО, в других – переделывать само приложение, а иногда и вовсе искать нетехнические меры для закрытия актуальных угроз. В каждом случае наиболее подходящий вариант определяется индивидуально.

Проблема №7. Проблема не всегда в безопасности

Среди ИТ-специалистов широко распространено мнение о том, что с приходом безопасности начинаются проблемы с работоспособностью систем. Например, если нужно внедрить межсетевой экран, это значит, что пропускная способность канала наверняка упадет. Однако по нашему опыту подобные сложности не всегда связаны с безопасностью и могут лежать в плоскости сетевых коммуникаций. Это еще одна ловушка, которую важно предусмотреть до внедрения отечественных средств защиты. Взять хотя бы установку того же межсетевого экрана или криптошлюза: эти работы нередко проводятся одновременно с настройкой сетевого оборудования, и источником проблем может стать банальное отсутствие взаимодействия между сетевыми инженерами и специалистами по информационной безопасности. Бывают и такие случаи, когда задачу оказывается эффективнее решить на стороне разработки. Например, в одном из проектов нам нужно было обеспечить защищенный удаленный доступ к внутреннему порталу компании через TLS-шлюз с использованием шифрования каналов связи по стандарту ГОСТ. Аутентификация на портале происходила с помощью цифровых сертификатов: по одному из полей автоматически определялось, в какой раздел будет направлен пользователь. После установки TLS-шлюза этот механизм перестал работать. Мы долго общались с производителем средства защиты и заказчиком по отдельности и даже осуждали с вендором возможность доработки продукта, но положительного результата это не принесло. Ситуация разрешилась, когда мы собрали все заинтересованные стороны вместе: команда разработки заказчика и эксперты вендора посмотрели на архитектуру решения и пришли к выводу, что оптимальный путь решения проблемы – изменить пару строчек кода в самом портале. По этому пути мы в итоге и пошли.

Вместо заключения

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

Автор: Алексей Павлов, руководитель отдела внедрения направления «Solar Интеграция» компании «РТК-Солар»