Не так давно был у меня в работе проект по внедрению системы MFA в ИТ-компании. Сейчас наблюдаю как другие ИТ-компании внедряют MFA системы и вижу много ошибок руководителей, которые в дальнейшем влияют на негатив сотрудников к системе в целом и к подразделениям его внедрившим в частности. Хочу поделиться болью, с которой сталкивается руководитель, когда внедряет подобные системы на компанию с 2000+ сотрудников, а также рассказать про методы, которые позволили добиться поставленных целей.

Про само понятие MFA или его подвид (2FA) рассказывать не вижу смысла, т.к. на хабре видел миллион статей по этой теме. Поэтому сразу перейду к сути.

После моделирования угроз в компании, в которой я когда-то работал, мной было принято решение внедрять различные СЗИ, чтобы эти угрозы нивелировать. Одним из таких СЗИ была система MFA.

Я начал изучать рынок, смотреть что предлагают российские вендоры — мы же «за импортозамещение»! На рынке я обнаружил 2 типа архитектур функционирования MFA систем: self-hosted и сервисную. Начнем с последней.

В сервисной архитектуре MFA предполагается взаимодействие с сервером аутентификации на стороне поставщика услуг. Сама же архитектура выглядит примерно следующим образом (рассмотрим достаточно поверхностно на примере доступа к VPN-серверу, без излишнего погружения в технические детали):

1. Пользователь с помощью VPN-клиента подключается к VPN-серверу.

2. Вводит логин и пароль от учетной записи VPN.

3. VPN-сервер отправляет запрос на Radius Server.

4. Radius Server обращается к сервису провайдера учетной записи, например Active Directory. В данном сервисе проверяется валидность введенных данных пользователя. Если все ОК, то Radius серверу передается сообщение о валидности введенных данных. На этом этапе первый фактор аутентификации заканчивается.

5. Radius Server отправляет запрос на подтверждение второго фактора аутентификации к серверу аутентификации, расположенному в ЦОДе поставщика услуг.

6. Сервер аутентификации ожидает ввода пользователем ОТР (код, сгенерированный приложением, СМС-код и т.п.). Пользователь предъявляет серверу ОТР (код, сгенерированный приложением, СМС-код и т.п.).

7. При получении валидного ОТР от пользователя сервер аутентификации посылает Radius серверу сообщение о его валидности.

8. Radius Server разрешает VPN-серверу предоставить пользователю доступ.

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

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

Итак, я начал поиск хорошего self-hosted решения для системы MFA. Поиски шли не очень долго, благо на рынке их не так много. Мое внимание остановилось на одном решении, которое подходило по всем моим требованиям (self-hosted, возможность передачи ОТР в виде СМС и кодов, сгенерированных в специальном приложении, возможность генерации сервером одноразовых QR-кодов для подключения пользователя и еще кучу других требований, про которые писать не буду, дабы сократить время чтения статьи). Название выбранной мной системы MFA я сообщать не буду, т.к. я ничего не рекламирую, а просто делюсь опытом.

Дальше был процесс пилотирования. Пилот проходил в 3 этапа с постоянным увеличением нагрузки на сервер и тестированием различных функций системы с разной нагрузкой. На первом этапе мы пилотировали систему тестовой группой из 20 пользователей, на втором этапе группой из 50 пользователей, на третьем этапе группой из 100 пользователей. При этом на каждом этапе проверяли нагрузку на систему в единицу времени, т.е. все пользователи разом запрашивали ОТР, либо в один момент вводили полученные коды в приложение и т.п. В общем, при тестировании выявлялись определенные проблемы, но не критические, вендор успевал исправить их за несколько дней. Кстати, надо отдать должное вендору — работал на ура, все делал быстро, за что его сотрудникам хочется сказать большое спасибо (если вдруг кто-то из них сейчас читает эту статью). По итогу пилот немного затянулся из-за возникавших проблем, но после его завершения, я уже был уверен в качестве и работоспособности средства и в том, что после внедрения в компании все будет работать штатно и безопасно.

Далее переходим к самому интересному — к тому как я внедрял данную систему и к проблемам, которые мне приходилось решать.

Проблема первая. Как внедрить сервис MFA на компанию в 2000+ человек, при условии разного формата работы всех сотрудников (офис, гибрид, полная удаленка)?

Проблема заключалась в том, что 2FA в первую очередь нужно было ставить на VPN, т.е. если что-то пойдет не так, то сотрудник не сможет работать в корпоративных системах (а они практически все у нас были за VPN), что приведет к простою организации, финансовым потерям и...

Как решить эту проблему? Первая мысль, которая пришла мне в голову — проводить внедрение не разово, а постепенно, группами, чтобы локализовать возможные проблемы. Первое что я сделал для этого — это взял справочник сотрудников, посмотрел к каким группам в LDAP относятся их подразделения, и начал нарезать группы человек +- по 50. Т.е. идея была следующая: вносим в MFA данные о конкретных группах LDAP (в которые входят ± 50 человек), им на почту приходит одноразовый QR-код, который они сканируют приложением на устройстве, тем самым получая генератор OTP на мобильном устройстве.

Почему была выбрана группа именно из 50 человек? Все просто — потенциально, я обрабатывал риски при внедрении, и понимал, что не все люди дружат с техникой и кто-то из них сам не разберется что делать, хоть я и разработал для них краткую, но максимально точную инструкцию (с картинками, стрелочками, в общем так, чтобы понял даже первоклассник) по проведению необходимых действий при подключении. В связи с такими рисками для их обработки я пришел в ДИТ и поговорил с товарищами из технической поддержки. Совместно было принято решение о том, что в случае появления таких пользователей, служба технической поддержки сможет в день обрабатывать заявки и помогать настраивать систему не более, чем 50 людям. Когда мы это обсуждали, ребята из поддержки посмеивались надо мной, мол «да ладно, инструкция понятная, все смогут сами все подключить». Но я знал, что люди бывают разные и не стал рисковать. Спойлер — когда начали внедрять MFA, люди повалили в поддержку и закидали их заявками и просьбами помочь с подключением. Конечно, не по 50 человек в день приходило, но в среднем человек по 10-20 было, а когда дошли до подразделений, не относящихся к IT, то и по 30-35 человек в день. В общем потом сотрудники поддержки мне еще спасибо сказали, за то что группы внедрения были по 50 человек.

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

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

Как вы думаете, достаточно 3 дня сотруднику, чтобы скачать приложение и отсканировать QR-код? Вот и я думаю, что достаточно. Спойлер — процентов 15, т.е. порядка 300 человек НЕ УСПЕЛИ это сделать. Сотрудники поддержки и администраторы системы были вынуждены кроме обслуживания пользователей в соответствии со списком внедрения, обслуживать еще и этих ребят. Поддержка и админы начали работать до позднего вечера.

Проблема вторая. Как объяснить пользователям, что метод доставки ОТР посредством СМС менее безопасен и надо использовать ОТР, сгенерированные специальным приложением, при этом остаться живым и без пулевого ранения в области груди?

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

Отказ от СМС-кодов был нужен компании не только для достижения более серьезного показателя безопасности, но также и для минимизации финансовых потерь, которые возникли бы при их использовании.

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

Порядка 70% сотрудников компании постоянно пользуются VPN и только 30% сотрудникам он будет не очень-то и нужен. Получается, что VPN будут пользоваться:

Если разрешить пользователю самому выбирать метод доставки ОТР, то порядка 80% будут пользоваться СМС-кодами:

В среднем пользователи будут запрашивать по 3 СМС-кода в сутки. Получается пользователям необходимо будет отправить:

Это обойдется компании в:

В год траты компании на СМС-коды составит:

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

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

Я пользуюсь кнопочным телефоном и не могу скачать приложение

Я принципиально не собираюсь ставить приложение от какого-то вендора на СВОЙ ЛИЧНЫЙ ТЕЛЕФОН, вы меня не заставите

У меня вообще нет телефона, покупайте мне смартфон и давайте сим-карту, чтобы я мог пользоваться вашим приложением MFA

Если вы думаете «Да таких людей не бывает», «Что за бред?», то вот вам спойлер — таких людей я насчитал порядка 50 за время внедрения.

Я понимал, что нам либо придется таким людям от компании покупать смартфоны (а они самые дешевые стоят тысяч по 5-10, плюс сим-карты для связи — это еще порядка 500 рублей в месяц, да и возиться с этим придется столько, что мама не горюй), что приведет к еще большим потерям, либо разрешить им использовать СМС-коды для аутентификации (при наличии у них устройств) — этот вариант казался самым логичным. Если разрешить таким людям использовать СМС-коды, то появляется другая проблема:

В общем опять замкнутый круг.

Значит нужно было придумать что-то, что позволит таким сотрудникам применять СМС-коды и чтобы другие сотрудники не хотели ими пользоваться. Желательно еще сделать так, чтобы компания добилась своих целей:

• внедрить 2FA (чтобы люди не отказывались ей пользоваться);

• не потерять лишних денег (использовать ОТР-коды);

• чтобы никто не уволился (разработчики в наше время очень обидчивые и ценные как «яйцо фаберже»);

• чтобы сотрудники были довольны (чтобы не негативили из-за применения технологий, которые они не выбирали).

Для достижения первой цели (внедрить 2FA) мне пришлось проводить агитацию и пропаганду с использованием различных корпоративных сервисов: я писал письма на всю компанию с объяснением причин внедрения MFA и планов по ее внедрению, пропагандировал необходимость внедрения на различных собраниях (встречах, ВКС, корпоративных мероприятиях и т.п.), спамил в корпоративный месенджер, даже создал отдельную группу в мессенджере для особо упертых сотрудников, где обосновывал причины внедрения такой технологии. Через определенное время люди вроде бы смирились и были готовы к внедрению.

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

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

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

• обеспечил лояльность сотрудников.

Как вы понимаете разрешив людям выбирать, большинство (процентов 80 навскидку) выберут именно получение СМС-кодов, а не ОТР-кодов. Это повлечет финансовые потери, а ведь мне нужно было достигнуть еще одной цели: не потерять лишних денег (использовать ОТР-коды).

Тогда передо мной встал вопрос: как разрешить пользователям выбирать любой метод получения ОТР, при этом сократить число пользователей (до минимума), которые будут получать СМС-коды? И все это надо было сделать так, чтобы сам пользователь остался доволен и продолжал плодотворно сотрудничать с компанией. Для этого он должен был сам принять решение о выборе ОТР-кодов для аутентификации, при том что у него был и другой выбор. В таком случае он остается доволен, а компания не теряет деньги.

Для решения этой нетривиальной задачи в голову пришло следующее решение. Мною было разработано 2 инструкции. Первая инструкция была на одну страничку А4, в которой было сказано какое приложение скачать, как отсканировать QR и как пользоваться ОТР-кодом. Вторая же инструкция по подключению метода доставки ОТР через СМС включала в себя упоминание о том, что эта технология небезопасная, и что лучше бы использовать ОТР-коды. Если на этом месте пользователь не «воспринимал» данную информацию, то дальше шла инструкция: пользователь, который хотел использовать СМС-коды для второго фактора аутентификации, должен был распечатать и подписать заявление. В этом заявлении была устрашающая фраза а-ля «Я понимаю, что выбираю небезопасный метод получения ОТР и несу полную ответственность за любую утрату корпоративной информации и другие последствия, наступившие в случае реализации с использованием моего аккаунта НСД к информации, обрабатываемой в корпоративных сервисах компании». Это должно было стать второй контрольной точкой, на которой сотрудник должен был задуматься о том, что он хочет применять небезопасную технологию и осознать риски с этим связанные. Если и тут пользователь хотел продолжить, то это означало, что любые убеждения о небезопасности данной технологии в отношении него не работают. Тогда включался обычный механизм всеми нелюбимой бюрократии, от которой среднестатистический сотрудник должен был отказать в пользу более простого для него метода подключения ОТР-кодов. Этот механизм предполагал следующее: сотрудник должен был распечатать заявление, подписать его сам, подписать у руководителя, подписать у юриста, подписать у руководителя службы ИБ и в конечном счете у меня. После получения моей финальной подписи этот документ сканировался службой ИБ и отправлялся в Service Desk сотрудникам ДИТ, которые переключали для данного пользователя метод аутентификации в приложении. Результат на лицо — 1 120 пользователей хотело использовать СМС-коды для аутентификации, в результате 1 115 пользователей самостоятельно приняли решение о том, что будут использовать ОТР-коды, лишь бы не погружаться в бюрократию. Из тех 50 человек, которые приходили и говорили что не могут пользоваться ОТР-кодами по тем или иным причинам, только 5 человек все-таки прошли эту процедуру и получили возможность использовать СМС-коды, остальные все-таки «нашли вдруг смартфоны» и пошли устанавливать приложение.

Да, вы сейчас это читаете и думаете «вот же нехороший человек, редиска... зачем так извращаться?», но попробуйте взглянуть на это с другой стороны. Мне нужно было выполнить все поставленные цели. Я хотел, чтобы работа пользователей с сервисами компании была безопасной, чтобы они пользовались MFA без негативных эмоций, компания не потратила лишних денег и владельцы бизнеса остались довольны. Проделанная работа позволила мне достичь всех поставленных целей. Я сэкономил для своей компании порядка 2 500 000 рублей в год, на которые мы смогли нанять еще одного сотрудника, который сможет сделать продукты и услуги компании лучше. Людям я ничего не запрещал — они действовали по своей воле и руководствовались своим выбором. И да, практически вся компания (99,9%) в итоге использует более безопасную технологию, чем обеспечивает защиту важной информации, обрабатываемой на внутренних ресурсах. Всем добра и спасибо, что дочитали до конца!