Как протестировать сервисы Контур.Эгиды: от подготовки до оценки результатов

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

Как компании приходят к тестированию

Когда компания решает протестировать ИБ-решение, у нее может не быть заранее оформленного технического задания. Часто запрос выглядит так: «Нам нужно увидеть, как продукт работает у нас». На словах все просто, но в реальности инфраструктура каждой компании устроена по-своему: где-то VPN работает через один сервис, где-то — через другой; где-то учетные записи синхронизируются автоматически, а где-то ведутся вручную; где-то администраторы работают по инструкции, а где-то — так, как сложилось годами.

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

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

Информационная безопасность бизнеса

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

Оставить заявку

Подготовка к тесту: ожидания vs. реальность

Где можно проводить тестирование и почему формат так важен

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

Иногда компания не может «пустить» продукт в боевую среду, но может выделить тестовую. Тогда создают отдельный стенд: система «как настоящая», но данных меньше. Этот вариант хорош, когда нужно провести тестирование безопасно, без влияния на работу.

Есть и третий формат — использование тестового стенда вендора. Это быстрый способ увидеть интерфейс, механики, базовые сценарии. Но он принципиально ограничен отсутствием реальных данных: никакой стенд не покажет, что происходит именно у вас.

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

Как подготовиться к тестированию

В подготовке есть несколько основных этапов.

1. Обсуждение и уточнение целей тестирования.
   Обычно это 2–3 задачи, которые компания действительно хочет проверить, — этого достаточно, чтобы тестирование было направленным, а не размытым. Если не определить цели, пилот может растянуться на месяцы, а результат все равно будет непонятным.
2. Подготовка инфраструктуры и проверка технических условий.
   Второй этап может проходить параллельно с первым: технические требования известны заранее (и проверку на соответствие им можно начинать сразу), а цели тестирования уточняются в ходе диалога с представителями вендора.
   
   На этом этапе могут обнаружиться неожиданные сложности. У кого-то не хватает нужной версии системы управления базами данных, у кого-то — дискового пространства, у кого-то — прав на установку. Иногда тестируемому решению нужен для работы интернет, но во внутреннем периметре компании (или на отдельном сервере, на котором планируется провести тест) доступ к нему по умолчанию закрыт. Иногда инфраструктура настолько ограничена, что не удается развернуть минимальный локальный модуль, через который продукт должен работать.
3. Назначение ответственных за настройку, контроль теста и оценку результата.
   Представители вендора обычно могут поддержать, проконсультировать, подсказать, но они не имеют доступа к внутренним ресурсам компании. За установку и настройку отвечает заказчик — как и за финальную оценку того, насколько успешно прошло тестирование.

Подготовка к тестированию: чек-лист

Как проходит само тестирование: на примере Контур.Эгиды

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

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

Также во время тестирования оценивают удобство предоставленной вендором версии продукта — облачной или on-prem-версии:

• Облачный продукт в пилоте обычно требует небольшого локального компонента (адаптера). Нагрузка и масштабирование обрабатываются на стороне вендора — это быстро и удобно для масштабирования системы и увеличения числа пользователей.

• On-prem требует проверки системных ресурсов: ЦП, ОЗУ, диска, резервирования и планов обслуживания. Масштабирование в этом случае может быть связано с дополнительными затратами на железо и сопровождение.

Все продукты ИБ-сервисы Контура можно протестировать в облачной версии — для этого не понадобится задействовать большое количество ресурсов компании, при этом остается возможность оценить функциональность каждого продукта. Например, для тестирования ID, PAM и Staffcop понадобится только установка пары агентов, которые будут взаимодействовать с облаком вендора. Для этого нужна минимальная подготовка — необходимо только выделить компьютер для установки компонентов, которые помогут запустить ПО на стороне вендора. Такая опция дает возможность протестировать продукт легко и быстро.

Тестирование ID

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

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

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

Двухфакторная аутентификация

ID — защита учетных записей сотрудников: подключений через VPN, RDG, ActiveSync, ADFS (протоколы OpenID Connect, SAML), защита входа в Windows, OWA.

Оставить заявку

Тестирование PAM

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

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

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

Управление привилегированными правами доступа

РАМ — полный контроль и прозрачность действий привилегированных пользователей.

Оставить заявку

Тестирование Staffcop

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

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

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

Реклама 16+

Расследуйте инциденты со Staffcop

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

Оставить заявку

Завершение тестирования и организационные моменты

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

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

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

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

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

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

Что компании получают по итогам теста, даже если продукт не подошел

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

Бывает, что в ходе тестирования выясняется:

• где есть проблемы с правами;

• какие действия невозможно отследить;

• как на самом деле устроена работа администраторов;

• сколько ресурсов потребуется при масштабировании.

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

Что нужно знать, чтобы тестирование прошло гладко

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

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

Итог

Хорошо проведенный тест — это процесс, в ходе которого оценивают не интерфейс, а реальную совместимость продукта с IT-инфраструктурой компании. Он помогает избежать рисков, заранее увидеть возможные проблемы и понять, как продукт «живет» в вашей среде. Это не быстрый эксперимент, а важный этап, который экономит ресурсы и дает уверенность: если вы идете в сторону внедрения, вы идете осознанно.