Многофакторная аутентификация как сервис: как сервис-провайдеру построить и предоставить облачные услуги МФА?

Дмитрий Соболев

Генеральный директор АО «НИЦ»

Михаил Рожнов

Технический директор MFASOFT (ООО «СИС разработка»)

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

«Сервис – это деньги»! Или зачем вообще поставщикам облачных услуг 2FA-сервис?

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

Безопасность своих пользователей и услуг. В самом общем случае, 2FA-сервис объективно необходим самому широкому кругу сервис-провайдеров, чтобы обеспечить более безопасное подключение пользователей. О необходимости 2FA мы подробно поговорили в первой статье. И в этом смысле, любой поставщик облачных услуг мог бы начинать предоставление такого сервиса (самостоятельно или в партнерстве со специализированной компанией) с того, чтобы просто поощрять своих клиентов заходить в свою же сервисную инфраструктуру с помощью многофакторной аутентификации. Тем самым, сначала он будет увеличивать – буквально «на копеечку» – стоимость сервисов, составляющих основу его бизнеса, предоставляя пользователям «дополнительный» 2FA-сервис. А уже после того, как он этот сервис разовьет и усовершенствует, то сможет предоставлять его уже не только своим «традиционным», но и «внешним» клиентам — уже всем, кто будет нуждаться в многофакторной аутентификации.

Потенциально облачные услуги 2FA могут быть интересны многим провайдерам: поставщикам облачной вычислительной инфраструктуры и облачных хранилищ, облачных коммуникаций, облачной бухгалтерии — словом, любых дистанционных услуг. Но «Сервис – это деньги», поэтому размер и специфика конкретной компании не так уж важны, все упирается в экономическую целесообразность. Если издержки поставщика на поддержание инфраструктуры для оказания 2FA-сервиса (англ. Operating Expenditure, OPEX) не будут превышать те деньги, которые он получит за него с клиентов, то такой сервис будет, как минимум, конкурентным преимуществом — клиенты будут заходить в свои личные кабинеты, и получать «основные» услуги поставщика более безопасно. А вот если нет, если такие затраты будут слишком высоки, то лучше будет построить партнерское взаимодействие (или «коллаборацию») со специализированным поставщиком облачного 2FA-сервиса, и брать такую услугу уже у него.

Специализация на услугах ИБ. Особое место на ИТ- и ИБ-рынке занимают сервисные компании, специализирующиеся на облачных услугах информационной безопасности (англ. Managed Security Service Provider, MSSP). Про концепцию «безопасность как сервис» начали говорить с начала 2000-х годов, но только сейчас она стала не просто обсуждаемой в профессиональной среде, но действительно применяемой. Как правило, основными причинами возросшего интереса к этой концепции называют экономию бюджетов и нехватку на рынке специалистов в области ИБ. А провайдеры облачных ИБ-сервисов, как правило — это крупные компании, имеющие достаточное количество высококвалифицированных специалистов. Потенциально они могут содержать штат сотрудников, способных не просто развернуть решение для многофакторной аутентификации, но и построить на его основе сервис, соблюдать заявленный SLA, сопровождать и поддерживать в актуальном состоянии сервисную инфраструктуру, обеспечить техническую поддержку заказчиков, а также консультировать их по более сложным вопросам, нежели чем просто «2FA для удаленного доступа к корпоративной инфраструктуре». Но вот всем ли MSSP это необходимо сделать сразу?

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

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

1. компании, которые ранее вообще не оказывали облачные сервисы, желающие попробовать вести такой бизнес;
2. поставщики «прикладных» облачных услуг, заинтересованные любыми путями расширить свой сервисный портфель.

Безусловно, поставщику даже с минимальным опытом и небольшим портфелем услуг это сделать проще — у него уже есть аудитория его «прикладного» сервиса, есть отказоустойчивая сервисная инфраструктура и построена добротная служба технической поддержки (1 и 2 линия, о которых мы еще поговорим чуть подробнее). Но и первые, и вторые компании в целом поступают одинаково: рассматривают относительно недорогие сервисы, которые не очень широко представлены на рынке, в которых можно относительно «легко войти», и которые (на первый взгляд) можно будет легко продать. Найдя такие сервисы, они пытаются запускать именно их. «Выстрелит» – отлично! А если нет – тогда они не много потеряют! Вроде бы, по современным меркам, это не самый масштабный сервис: не нужно строить большой ЦОД, разворачивать масштабную сервисную инфраструктуру и прочее-прочее.

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

Ключевые клиенты поставщика облачных услуг 2FA

Во второй статье мы обсудили кто в большей степени может быть заинтересован в использовании облачных услуг MFA. Но это был взгляд с точки зрения потенциального заказчика – кому 2FA-сервис подходит? А вот кто может быть интересен потенциальному поставщику такого сервиса – на кого он должен обратить свое внимание прежде всего, чтобы быстро нарастить свою клиентскую базу и заслужить у рынка доверие? Здесь необходимо признать, что не все существующие или «традиционные» клиенты провайдера, пользователи сервисов, составляющих основу его бизнеса, сразу окажутся поклонниками и потребителями 2FA. По нашему опыту выделим три ключевые группы «потенциальных» клиентов:

1. Компании, которым необходим «быстрый вход» в многофакторную аутентификацию. Зачастую они могут и самостоятельно набрать команду, выделить ИТ-ресурсы, необходимые для развертывания 2FA, но по какой-то причине у них нет на это времени. Поэтому чтобы успешно работать с такими потенциальными клиентами у поставщика должны быть досконально отлажены процессы представления, тестирования, продажи, оформления и включения сервиса в информационную инфраструктуру заказчика. В идеальном случае «на следующий день»!
2. Организации, которые не нуждаются в большом количестве подключений, большом количестве пользователей 2FA-сервиса. Даже крупные компании могут испытывать потребность в усилении базовой аутентификации для 5-10 ключевых сотрудников – руководство, бухгалтерия, учредители, администраторы важнейших ИТ-систем. В работе с такими потенциальными клиентами кроме оперативности и четкости может потребоваться гибкость и «специфические» варианты включения сервисов 2FA в инфраструктуру – на «нетиповых» (если не сказать «эксклюзивных») рабочих станциях и ноутбуках, операционных системах и приложениях, а также на мобильных устройствах.
3. Компании, заинтересованные в тестировании конкретных решений многофакторной аутентификации, в знакомстве с сервисами конкретных поставщиков, или желающие убедиться в принципиальной целесообразности последующего внедрения 2FA. Конечно же, в работе с такими потенциальными клиентами существует опасность потратить много времени и ресурсов, но не получить никакого серьезного результата. Поэтому мы рекомендуем предлагать таким «исследователям» и «тестировщикам» досконально продуманную типовую методику тестирования, типовой порядок подключения и оказания сервисов, а также бесконечно не продлевать по их просьбе «бесплатный тестовый период» – переходить на коммерческие условия оказания услуг четко в положенное время.

Безусловно, в первую очередь для облачного провайдера, начавшего оказывать сервисы 2FA, будут важны его существующие или «традиционные» клиенты, до которых он может «дотянуться» быстрее и проще всего. Во вторую очередь – наиболее крупные из новых потенциальных клиентов, поскольку их подключение и обслуживание сразу может дать много денег. И только в третью очередь оказываются важны небольшие потенциальные клиенты. Часто случается, что чем такой клиент меньше, тем работать с ним сложнее – проблем от него как от крупного, затраты на его обслуживание велики, но отдача мала.

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

Что поставщик облачных услуг 2FA должен иметь в ИТ-инфраструктуре и кого в штате?

Поставщику облачных услуг, у которого уже развернута своя сервисная инфраструктура и есть 1-я линия технической поддержки (ТП), добавить в свой портфель услуги 2FA будет относительно легко. Самое простое вхождение в 2FA – это когда у провайдера есть набор «традиционных» услуг и он просто «масштабируется»: разворачивает решение MFA и 2-ю линию технической поддержки (3-я линия – это уже прерогатива вендора), формализует бизнес-процессы своего нового сервиса. Безусловно, мелочей в таком бизнесе нет, но мы выделим три главные, на наш взгляд, вопроса:

1. Что нужно иметь в инфраструктуре? По-хорошему необходимы два независимых сервера — физическая инфраструктура должна быть резервирована. В идеале необходимо георезервирование, то есть 2 дублирующих ЦОД в географически разнесенных местах. Но это все доступно тем, у кого уже есть большая клиентская база, а для остальных потребуется совсем немного: 1 провайдер доступа в Интернет, 2 сервера, общесистемное ПО. Операционная система может быть и Open Source, сертифицированная ОС потребуется в редких случаях.
2. Какие сотрудники должны быть в составе службы технической поддержки? Начнем с 1 линии ТП. Ее численность зависит от того, какой предоставляется SLA. Если клиенты обслуживаются в режиме 8х5 (проблемы решаются только в рабочее время), то высоких требований не будет. Если же в режиме 24х7 (например, если клиенты обслуживаются по всей стране, по всем часовым поясам), то требования будут сложнее. Только одна смена – минимум 5 человек, а также потребуются 2 инженера, работающие в дневные часы. Получается, что для круглосуточной смены будут необходимы 7 человек, а если «с запасом», то даже 10 человек. Теперь о 2-й линии ТП. Как правило, для небольшой компании достаточно 2-х сотрудников — чтобы компенсировать отпуск и отсутствие по различным причинам (болезнь, отгул и прочее), чтобы было «перекрытие». Но дополнительно может потребоваться проработать вопрос об увеличении времени обслуживания, чтобы 2-я линия могла обрабатывать обращения до 22 часов (в почте или по телефону).
3. Кто будет внедрять решение 2FA, нужны ли сотрудники с опытом внедрения? Мы считаем, что небольшому поставщику облачных услуг «заходить» в новый для себя сервис логичнее всего будет через экспертизу разработчика 2FA-решения и его партнеров. В настоящий момент есть тенденция, предоставления поставщиками облачных 2FA-сервисов интеграционных услуг по внедрению решения многофакторной аутентификации в инфраструктуру заказчика. Это интересно многим небольшим провайдерам: коллеги развернули сервис у себя, у них хватило квалификации развернуть масштабное «облако», поэтому они способны качественно сделать это и в нашей инфраструктуре!

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