Новости

Выбор между on-premise и облачным MFA решает, у кого окажется контроль над данными и насколько корпоративная сеть зависит от чужих сбоев. Облако даёт быстрый старт и снимает часть забот об инфраструктуре, но привязывает компанию к внешним каналам связи и площадке провайдера. Локальное развёртывание снижает риски независимых внешних сбоев и даёт полный контроль над восстановлением, хотя отвечать за отказоустойчивость приходится самой компании. На дистанции от трёх лет свой контур, как правило, обходится дешевле, а небольшим компаниям облако нередко подходит лучше.

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

Поэтому стоит заранее ответить на три вопроса:

• Насколько облако выгодно на длинной дистанции?
• Что будет, если оно окажется недоступно не на 15 минут, а на дни и недели?
• И насколько просто потом перейти на другое решение?

Рассмотрим каждую из этих сторон подробно, а заодно разберём, с какими скрытыми нюансами сталкиваются ИТ- и ИБ-отделы.

Экономика подписки против бессрочного владения

Финансовая модель — первое, на что смотрит бизнес. Облачные MFA-сервисы берут низким порогом входа: компания платит регулярные взносы за каждого пользователя, и для стартапов или коротких пилотных проектов такая схема действительно выглядит выигрышной. Но сравнивать нужно полную стоимость владения (TCO), а не одну подписку.

У локального решения TCO складывается из:

• покупки бессрочных лицензий;
• зарплат ИТ-специалистов;
• расходов на содержание серверов;
• работ по интеграции.

Техподдержка обходится сравнительно недорого. В облаке отдельной платы за поддержку нет, она уже заложена в подписку.

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

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

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

Контроль над решением: аренда вместо владения

Выбирая облако, полезно помнить, что вы берёте решение в аренду и им не владеете. У аренды есть плюсы, ведь кто-то другой:

• следит, чтобы система работала;
• делает бэкапы;
• поднимает сервис на резервных мощностях при выходе из строя серверов или целого ЦОД;
• защищает его от злоумышленников.

Вендоры охотно напоминают о надёжности своих дата-центров, и крупные провайдеры вкладывают в резервирование много ресурсов. Но регулярные аварии в магистральных сетях и крупных ЦОД показывают, что абсолютной отказоустойчивости не бывает.

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

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

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

Раньше долгое отключение облака никто всерьёз не рассматривал, теперь исключать его нельзя. Речь уже не о коротких технических сбоях:

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

Отсюда неудобный вопрос: кому в первую очередь будет уделено внимание при масштабной аварии в облаке, крупнейшим корпорациям или небольшим компаниям?

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

Проблема вендорлока и миграция

Сменить поставщика стандартных виртуальных машин относительно просто: данные переезжают на другую площадку за считанные дни. С системами управления доступом всё иначе, и начать стоит с денег:

• Перестав платить за облако, вы мгновенно теряете доступ к сервису.
• При плановом переходе на новое решение какое-то время приходится платить за оба сразу.
• При аварийной замене картина ещё хуже: пока идёт переход, компания остаётся без защиты.

Есть и технические ограничения. Облачные MFA-решения построены на проприетарных API и не позволяют вывезти в универсальном формате настроенные политики, связи и выпущенные пользователям аутентификаторы. Вендоры охотно облегчают вход, но уход от них никто не упрощает, и удобных инструментов экспорта настроек и токенов обычно просто нет. Поэтому переход к другому провайдеру или возвращение в свой контур означает сборку системы с нуля. Придётся:

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

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

Сводное сравнение для компаний разного масштаба

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

Практический подход к безопасности с Blitz Identity Provider

Компаниям, которым нужны полная независимость и строгое соответствие требованиям регуляторов, подходят автономные платформы. Вот что стоит знать о нашем флагманском продукте Blitz Identity Provider:

• Он разворачивается только on-premise, на собственных физических или виртуальных серверах заказчика.
• Сервер аутентификации берёт на себя централизованное управление доступом и поддерживает SSO и MFA. Всё работает внутри локальной сети, учётные данные, ключи и токены не покидают защищённый периметр организации.
• Решение сертифицировано ФСТЭК России по требованиям безопасности информации и входит в реестр российского ПО, так что его можно применять для импортозамещения и защиты объектов КИИ.
• Мы предлагаем полнофункциональное пилотное тестирование в реальном контуре организации, чтобы ИБ-специалисты могли проверить систему сами до заключения договора.

Если вы небольшая компания, не стоит заранее считать облако единственным вариантом.Команда Blitz Identity Provider поможет рассчитать совокупную стоимость владения, спроектировать отказоустойчивую архитектуру и без спешки и лишних рисков перейти с действующего облачного решения на автономный контур.

Выводы

Облачный MFA хорошо подходит небольшим компаниям, сервисам с некритичными данными и быстрой проверке гипотез. Когда речь заходит о защите инфраструктуры крупного предприятия, на первый план выходят автономность, предсказуемость затрат и контроль над каналами связи. On-premise требует от внутренней команды больше ответственности, зато даёт независимость от внешних факторов.