Многофакторная аутентификация как сервис: «подводные камни» внедрения и последующего использования.

Во второй статье цикла «Многофакторная аутентификация как сервис» мы обсудили ряд предметных вопросов со стороны заинтересованных заказчиков: для каких компаний предпочтительнее использовать сервис 2FA, а для каких предпочтительнее локальная инсталляция, каковы главные критерии выбора поставщика услуг, что, в конечном счете, заказчик может получить и что сервисная компания должна предоставить? Теперь мы пойдем дальше и поговорим о том, как построить процесс выбора и внедрения сервиса, а также какие неочевидные вопросы, или как говорят, «подводные камни» могут встретиться на этом пути.

Камень первый. «Сколько-сколько?» или как лучше не делать.

Итак, представим себе компанию, столкнувшуюся с потребностью усиления базовых функций аутентификации в своих информационных системах. Она приняла решение не пытаться сделать это самостоятельно, а обратиться к поставщику 2FA-сервиса, занимающемуся этим профессионально. Что дальше? По нашему опыту, большая часть заказчиков, даже тех, которые серьезно решали вопрос «самостоятельное развертывание 2FA или облачный сервис?», которые выстроили свою «систему ценностей» выбора поставщика — о критериях мы с вами уже говорили — так вот даже они начинают с вопроса о стоимости сервиса 2FA. Чего уж тогда говорить об остальных! Два самых распространённых вопроса, которые мы слышим от заказчиков, это: «Сколько стоит?» и «Можно ли поставить наш логотип на портале самообслуживания?». Случается даже, что еще до того, как заказчик получит полный ответ на свой вопрос, он восклицает: «Сколько-сколько?!».

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

Таким образом, первый «подводный камень» выбора и внедрения сервиса 2FA, как бы банально это не звучало, это не выяснение цены, а внимательное и всестороннее изучение всего будущего сервиса.

Камень второй. Готов ли поставщик сервиса вам его поставить?

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

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

Готовность проконсультировать в ходе тестирования и последующего внедрения. Заслуживающий внимания сервис-провайдер, конечно же, предоставит тестовый аккаунт для функционального тестирования своего 2FA-сервиса, и предложит заказчику не просто ответы на вопросы, а помощь с развертыванием, консультации по интеграции с информационными системами. Если, сверх того, вниманию заказчика будет предоставлен «центр компетенций» (то есть опыт аналогичной работы с предыдущими заказчиками), возможность практической или «живой» демонстрации решения именно его задач, то можно будет на практике сделать вывод об уровне компетенций данной сервисной компании и пригодности данного сервиса для специфических условий заказчика. Если в ходе тестирования 2FA-сервиса заказчик получит ответ и на простые (настройка аутентификации на устройствах под управлением Windows), и на чуть более сложные вопросы (например, настройка аутентификации в различных семействах и версиях Linux), если он получит готовые инструкции, описания, документы, каналы на YouTube, демонстрации в Интернет, то станет очевидным, что с технологической и экспертной точки зрения поставщик в полной мере «готов поставить» сервис заказчику.

Готовность службы технической поддержки. Качество работы службы технической поддержки – один из важнейших вопросов использования любого облачного сервиса. Если в основе сервиса 2FA лежит совершенное решение, если он грамотно интегрирован и настроен, то он, скорее всего, будет правильно работать, а сложности и проблемы могут сводиться лишь к обработке инцидентов в работе пользователей. Как оценить качество работы СТП поставщика 2FA-сервиса? Здесь возможна только субъективная оценка, и пока заказчик сам не пройдет через взаимодействие с реальной СТП, не сможет сделать вывод. На наш взгляд обязательно нужно попросить поставщика рассказать как работает его СТП, но затем (например, в ходе функционального тестирования) обязательно завести и собственную заявку, обратиться уже со своим вопросом. Если в распоряжение заказчика будут предоставлены не просто контакты СТП, а полноценная и удобная система формирования и отслеживания заявок на поддержку, если он получит оперативный и обстоятельный ответ, получит реальную помощь, то можно сделать вывод, что СТП поставщика облачного сервиса готова к его оказанию.

Камень третий. Нагрузочное тестирование.

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

В настоящее время на рынке нет единой и общепринятой методики нагрузочного тестирования. Более того, на рынке нет единого, общего подхода к формированию такой методики — оценке производительности систем многофакторной аутентификации. Кто-то считает запросы в единицу времени, кто-то считает количество ответов, кто-то – количество клиентов, которые потенциально могут подключиться. Многие используют показатель «Аутентификации в секунду», но что это за показатель? И как он отражает устойчивость и производительность сервиса 2FA в целом? Согласитесь, что это не совсем очевидно! Кроме того, вызывают некоторые сомнения и приводимые значения. Так, некоторые сервисные компании и производители 2FA заявляют о поддержке какого-то количества одновременных подключений, как правило, 10-15% от общего количества пользователей. Но по опыту работы с крупными корпорациями становится ясно, что такие значения не требуются! Значит необходимы какие-то другие критерии?

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

Камень четвертый. Стоимость и политика лицензирования в целом.

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

Модель оплаты. В настоящее время на рынке довольно востребована UBP-схема (Usage Based Pricing) — модель оплаты подразумевающая, что заказчик оплачивает лишь то количество лицензий, которое использовал в отчетном периоде. Например, если заказчик внедряет сервис 2FA для 100 корпоративных пользователей, то предложение о покупке «100 лицензий за год» ему может быть вовсе не интересно! Судите сами: какое-то время уйдет на внедрение, какое-то время – на проведение испытаний, при этом будут использоваться 8-10 лицензий, а платить придется сразу за 100!

Гибкая схема лицензирования. Часто случается, что в ходе тестирования или пилотного внедрения заказчик понимает, что будет эксплуатировать, условно говоря, 20-30% всей системы и 2FA-сервиса. Если при этом схема лицензирования не «гибкая» и заказчик должен заплатить за все, то цена, действительно, становится неприемлемой! Кроме того, есть вендоры, которые даже агенты интеграции лицензируют отдельно. И при отсутствии гибкости лицензирования заказчик будет вынужден оплачивать даже те возможности, которые еще не начал использовать, а только внедряет или только приближается к внедрению. Кроме того, гибкий подход важен и в процессе тестового периода и перехода в «боевой» режим. Это означает, что после тестирования, если заказчику понравится решение и сервис, и если он попросит перевести свои «тестовые» аккаунты в «боевые», то не придется все еще раз подключать и настраивать. В этом смысле «гибкость» означает возможность плавного и незаметного перехода от этапа тестирования к этапу непосредственного обслуживания.

Перспектива развития. Случается, что даже если заказчик выделил бюджет и заплатил за сервис, то не обязательно ему сразу понадобится весь набор функциональных возможностей. Безусловно, ведущие сервисные компании предоставляют набор наиболее востребованных «базовых» и «дополнительных» функциональных возможностей, например, поддержка протоколов внешней аутентификации, поддержка Keycloak, поддержка распространенных на рынке аппаратных и программных токенов. Но, тем не менее, при анализе конкретных сервисов заказчику необходимо учитывать какие возможности кроме «простой дополнительной двухфакторной аутентификации» ему потребуются уже сейчас, и какие ему будут доступны в ближайшем будущем. Будет ли развитие 2FA в организации, планируется ли использование каких-то новых агентов, потребуется что-то дополнительно подключать и расширять? Или требуется всего лишь «простой сервис» на 50-100 пользователей и в ближайшие 2-3 года у них никаких изменений не будет?

Немного формализации.

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

1. Изучение заказчиком web-сайта сервисной компании, а также сайта производителя решения, на базе которого развернут сервис. Ознакомление с условиями сервиса и продуктами.
2. Обращение к разработчику решения с просьбой рассказать о продукте. Возможно проведение презентации о решении как со стороны производителя, так и со стороны партнера — поставщика облачного 2FA-сервиса.
3. Запрос о возможности проведения «референсного визита» (звонка) к заказчику, уже использующему данное решение или сервис. Обратите внимание, что практика данных визитов в области информационной безопасности не распространена!
4. Звонки нескольким сервис-провайдерам, уточнение как они работают с заказчиками, как принимают обращения. Сравнение скорости реакции, например, предоставления презентации о сервисе, предоставления тестового аккаунта.
5. Подготовка и проведение функционального тестирования на ограниченном количестве устройств. При его проведении проверить готовность поставщика сервиса оказать помощь и консультацию во внедрении, оценить уровень его компетенции, проверить скорость и качество работы СТП.
6. Организация и проведение нагрузочных тестирований, анализ результатов совместно с каждым поставщиком сервиса.
7. Запрос проекта договора, лицензионной политики, политики ценообразования, моделей оплаты и других документов.
8. Получение и анализ дополнительной информации: возможности поставщика оказать консалтинговые услуги, возможности расширения и развития сервиса, возможности миграции на сервисы другого поставщика.
9. Анализ всей полученной информации. Интегральная оценка «готовности» поставщика сервиса помочь его внедрить, а затем – его оказать. Принятие решения на внедрение.
10. Процесс внедрения сервиса, интеграция с корпоративными информационными системами, сервисная поддержка, мониторинг качества оказания сервиса.

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