На что важно обращать внимание при выборе отечественных средств защиты? Об этом рассказывает эксперт направления «Solar Интеграция» компании «РТК-Солар» Алексей Павлов на основе собственного опыта реализации интеграционных проектов.
Уровень зрелости отечественных средств защиты неоднороден и различается в зависимости от класса решения. При этом на российском рынке есть немало зрелых продуктов, например, антивирусы, сканеры уязвимостей и системы защиты от утечек данных. Причем в ряде случаев организации уже предпочитают отечественные продукты, поскольку они наиболее полно отвечают требованиям к функциональности. Например, так происходит с системами защиты от утечек данных: российские продукты этого класса предоставляют более удобную и стабильную функциональность поиска при хранении полного архива коммуникаций, что не характерно для иностранных решений.
Другая особенность российских средств защиты — медленные темпы развития в условиях небольшой инсталляционной базы. На сегодняшний день вокруг отечественных инструментов кибербезопасности в сравнении с иностранными сформировалось менее широкое экспертное сообщество. Это означает, что российские производители получают гораздо меньше обратной связи от пользователей, что сужает их возможности по выявлению и исправлению недостатков в решениях.
При создании экосистемы кибербезопасности на основе отечественных продуктов важно взвешенно подойти к выбору решений и подготовке к их внедрению в инфраструктуру. С какими проблемами компании могут столкнуться при внедрении российских средств защиты? На этот вопрос я отвечу в статье, исходя из собственного опыта создания систем безопасности на базе отечественных решений, в том числе при реализации крупных федеральных проектов.
Первая проблема при внедрении отечественных средств защиты зачастую возникает уже на этапе тестирования. При выборе нового продукта или его новой версии для внедрения в инфраструктуру заказчика мы всегда проводим два вида тестирования: функциональное и нагрузочное. В первом случае реальность, как правило, совпадает с ожиданиями, разве что документация может отставать от недавно появившихся функций решения. А вот во втором случае нередки сюрпризы: достичь заявленной производительности не всегда удается. Такие проблемы мы решаем совместно с вендором: иногда помогает тонкая настройка продукта, иногда установка патча. Чтобы избежать подобных сложностей непосредственно при внедрении, мы рекомендуем всегда тестировать продукты.
Еще одна проблема может скрываться за заявленной высокой отказоустойчивостью. Нередко производители говорят о реализации отказоустойчивости по принципу active-standby, когда у каждого узла в кластере есть работоспособная копия, однако такие копии не обрабатывают трафик, пока функционирует первый узел. Встречаются и случаи, когда поставщики решений заявляют реализацию модели active-active, при которой все узлы кластера обрабатывают трафик и являются активными. На практике зачастую оказывается, что отказоустойчивость происходит на уровне приложения, приема трафика и конфигурации. То есть в случае отказа одной из нод начинает работать другая, но если спуститься на уровень ниже, например, уровень хранения данных, то очень часто отказоустойчивость СУБД ложится на плечи инженеров, а это создает трудности при внедрении и эксплуатации продукта. Мы рекомендуем уделять этому аспекту повышенное внимание еще на этапе выбора решения при общении с производителями.
Когда средство защиты нужно развернуть на большом количестве хостов, не обойтись без инструментов автоматизации. В случае со средой Windows такие решения существуют и по нашему опыту работают хорошо. Есть общие методы развертывания, например, распространение через групповые политики Active Directory или c помощью технологии System Center Configuration Manager (SCCM), так что можно установить любое количество агентов на серверы и рабочие станции. К тому же, в целом практически каждое решение имеет собственную систему распространения хостовых средств защиты в Windows-среде.
Если же необходимо выполнить аналогичные действия в среде Linux, а сегодня это становится актуальным для всех, кто переходит на отечественные операционные системы, есть риск столкнуться со значительными трудностями. Дело в том, что далеко не каждое отечественное средство защиты имеет систему управления, позволяющую распространить автоматизированным способом на Linux-машины требуемые хостовые продукты кибербезопасности. Мы решаем эти сложности в каждом случае по-разному. Например, если создается новая информационная система, для нее можно подготовить «золотой» образ операционной системы с заранее выставленными настройками безопасности либо с предустановленным средством защиты. Это значительно упростит внедрение, когда инфраструктура будет развернута. Если же продукт нужно встроить в готовую инфраструктуру, целесообразно исходить из количества хостов. Например, при небольшом количестве серверов и рабочих станций можно выбрать решение «в лоб» — точечно установить средства защиты там, где это требуется. Если организация распределенная, и в инфраструктуре насчитывается несколько десятков или сотен хостов, для автоматизации развертывания средств защиты стоит разработать соответствующие скрипты. Например, мы для решения подобных задач используем систему управления конфигурациями Ansible.
Угодить в ловушку при внедрении отечественных средств защиты можно и по причине отсутствия в них API (Application Programming Interface) — интерфейса, с помощью которого взаимодействуют различные решения. Этот инструмент помогает автоматизировать многие действия на проектах по системной интеграции, включая миграцию с иностранных решений на отечественные. Например, при тестировании одного из российских межсетевых экранов следующего поколения нам нужно было проверить, как функционирует продукт, когда в нем работает примерно пять тысяч установленных правил, при этом какого-либо API в продукте не было. За пару часов работы над этой задачей проводивший тестирование инженер пришел к выводу, что рутинные действия отнимут у него несколько десятков часов, тогда как на решение похожих задач с API обычно требуется не более нескольких часов. Конечно, несмотря на возникшие сложности, решение всё-таки нашлось: для ускорения настройки специалист смог написать скрипт, который автоматически генерировал файл конфигурации. Чтобы избежать подобных проблем, особенно в случаях, когда стоит задача миграции с одного решения на другое, стоит обращать внимание на наличие API еще на этапе выбора продукта.
Параллельно со средствами защиты сегодня развиваются и отечественные инфраструктурные решения, а именно операционные системы и платформы виртуализации. Однако поддержка инфраструктурных решений с точки зрения средств защиты пока немного отстает, и здесь кроется еще одна ловушка. Чтобы ее миновать, в теории необходимо попросить производителя продукта по кибербезопасности протестировать его на совместимость с инфраструктурными решениями и предоставить официальную поддержку, но это долгий процесс. В действительности на это зачастую не хватает времени, и отвечающим за внедрение командам, как правило, приходится брать такие риски на себя и самостоятельно проверять совместимость решений. В нашей практике были случаи, когда производители принимали результаты наших проверок и заявляли свою поддержку с решением, которое мы протестировали. Впрочем, подобные кейсы не всегда приносят успешный результат. Например, у нас был такой случай: для активации лицензии сканера уязвимости требовалось пробросить физический токен с хоста виртуализации в виртуальную машину. Справиться с этой проблемой нам не удалось ни самостоятельно, ни с помощью экспертов производителя среды виртуализации. Фактически это означало, что стандартный способ активации продукта не подходил для данной среды виртуализации, хотя формально решение внутри неё работало. В итоге вендор виртуализации признал необходимость доработки своего продукта, вендор средства защиты также согласился, что вопрос нужно взять в проработку, а нам пришлось решать задачу другим методом.
Еще одна проблема может возникнуть при выполнении требований регуляторов. Цикл сертификации средств защиты в России довольно долгий, что приводит к некоторому отставанию используемых в инфраструктуре сертифицированных продуктов по кибербезопасности от технологий, которые применяют разработчики. Если информационная система только создается, решение несложное: достаточно сообщить команде, отвечающей за построение инфраструктуры, все необходимые требования на старте проекта. При их соблюдении проблем с установкой средств защиты не возникнет. А вот если средства защиты нужно установить на готовую инфраструктуру, сценарии могут быть разными. Если изначального требований в инфраструктуре с точки зрения информационной безопасности не предъявлялось, то может возникнуть много технических проблем, которые не всегда решаются техническими методами ввиду несовместимости средства защиты и ПО инфраструктуры. В одних случаях приходится использовать предыдущие сертифицированные версии ПО, в других – переделывать само приложение, а иногда и вовсе искать нетехнические меры для закрытия актуальных угроз. В каждом случае наиболее подходящий вариант определяется индивидуально.
Среди ИТ-специалистов широко распространено мнение о том, что с приходом безопасности начинаются проблемы с работоспособностью систем. Например, если нужно внедрить межсетевой экран, это значит, что пропускная способность канала наверняка упадет. Однако по нашему опыту подобные сложности не всегда связаны с безопасностью и могут лежать в плоскости сетевых коммуникаций. Это еще одна ловушка, которую важно предусмотреть до внедрения отечественных средств защиты. Взять хотя бы установку того же межсетевого экрана или криптошлюза: эти работы нередко проводятся одновременно с настройкой сетевого оборудования, и источником проблем может стать банальное отсутствие взаимодействия между сетевыми инженерами и специалистами по информационной безопасности. Бывают и такие случаи, когда задачу оказывается эффективнее решить на стороне разработки. Например, в одном из проектов нам нужно было обеспечить защищенный удаленный доступ к внутреннему порталу компании через TLS-шлюз с использованием шифрования каналов связи по стандарту ГОСТ. Аутентификация на портале происходила с помощью цифровых сертификатов: по одному из полей автоматически определялось, в какой раздел будет направлен пользователь. После установки TLS-шлюза этот механизм перестал работать. Мы долго общались с производителем средства защиты и заказчиком по отдельности и даже осуждали с вендором возможность доработки продукта, но положительного результата это не принесло. Ситуация разрешилась, когда мы собрали все заинтересованные стороны вместе: команда разработки заказчика и эксперты вендора посмотрели на архитектуру решения и пришли к выводу, что оптимальный путь решения проблемы – изменить пару строчек кода в самом портале. По этому пути мы в итоге и пошли.
Многие отечественные средства защиты сегодня требуют высоких компетенций от инженеров, отвечающих за их внедрение в инфраструктуру и последующую эксплуатацию. Нередко для работы с продуктами необходимо продвинутое знание Linux, поскольку на этой операционной системе может быть реализована часть функциональности продукта. В то же время мы видим, что отечественные производители готовы обучать специалистов заказчиков и интеграторов, помогать экспертизой на проектах, а в ряде случаев даже выпускать обновления, не предусмотренные стратегией развития продуктов. Все это дает надежду на то, что в перспективе на проектах по внедрению отечественных средств защиты компаниям будет грозить всё меньше ловушек и связанных с ними сложностей.
Автор: Алексей Павлов, руководитель отдела внедрения направления «Solar Интеграция» компании «РТК-Солар»
Спойлер: мы раскрываем их любимые трюки