Двухфакторная аутентификация: настройка защиты в SaaS-системах

Двухфакторная аутентификация для корпоративных SaaS-систем: настройка защиты

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

Microsoft сообщала, что более 99,9% скомпрометированных корпоративных аккаунтов, наблюдавшихся компанией, не были защищены многофакторной аутентификацией. В тех же материалах приводилась оценка, что MFA способна блокировать более 99% атак на компрометацию аккаунтов. Эти показатели показывают масштаб пользы второго фактора, но сами по себе не объясняют, какие именно атаки оставались успешными и как была устроена выборка. Практический вывод проще: парольная защита оставляет слишком много на одном секрете, а эффективность MFA зависит от выбранного метода и конфигурации.

Для корпоративной среды это означает, что настройка 2FA в облачных сервисах должна быть частью управления доступом. Важно не просто включить подтверждение входа, а понять, какие факторы поддерживают критичные приложения, кто может обходить политику и что произойдёт при потере устройства.

Почему парольной защиты недостаточно

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

SaaS усложняет картину тем, что доступ к сервисам часто распределён между администраторами, сотрудниками и подрядчиками. Учётная запись может сохранять активную сессию на нескольких устройствах. Приложения связываются друг с другом через SSO, OAuth или интеграции. В результате одна скомпрометированная учётка иногда становится удобным входом в целую цепочку сервисов.

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

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

AiTM: когда фишинг проходит через настоящий сайт

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

Адресная строка здесь имеет значение. Пользователь находится на домене фишингового прокси, а не на легитимном домене SaaS-сервиса. При этом сайт-прокси может иметь действительный SSL-сертификат для собственного домена. Значок защищённого соединения говорит о шифровании канала до этого домена, но не подтверждает, что домен принадлежит нужному сервису.

Если пользователь вводит пароль и одноразовый код TOTP на такой странице, прокси может передать их настоящему сервису. Когда тот выдаёт сессионную cookie, посредник способен перехватить и её. Тогда атакующий получает возможность использовать уже созданную сессию, а не повторять вход с паролем и кодом. Push-подтверждение тоже не всегда спасает: сотрудника могут утомить повторными запросами или склонить к одобрению через социальную инженерию.

В FIDO2 защита основана на криптографии с открытым ключом и привязке учётных данных к домену. Во время входа сервер отправляет challenge, то есть случайное значение, которое аутентификатор должен подписать. Домен не содержится в самом challenge. Браузер передаёт сведения об origin в clientDataJSON, а сервер проверяет их вместе с подписью и данными аутентификатора. Для пользователя это означает, что ключ не должен подтвердить вход на поддельном домене так, как он подтвердил бы его на настоящем.

Такая привязка мешает типичному AiTM проксировать вход и получить пригодный для настоящего сервиса ответ аутентификатора. При этом FIDO2 не отменяет риски после входа. Если сессионную cookie украли с заражённого устройства, второй фактор уже был пройден. Поэтому защита доступа к SaaS-приложениям включает не только MFA, но и контроль сессий, устройств и подозрительных входов.

Что NIST считает многофакторной аутентификацией

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

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

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

Сотруднику не обязательно объяснять всю классификацию NIST, но она полезна при выборе политики. Если сервис называет проверку многофакторной, стоит выяснить, какие именно категории в ней задействованы. Особое внимание нужно уделять сценариям восстановления: запасной код или контрольные вопросы не должны превращаться в простой обход основного входа.

От TOTP к FIDO2 и passkeys

TOTP, описанный в RFC 6238, генерирует одноразовый код на основе общего секрета и времени. Приложение-аутентификатор и сервер используют один секрет, а код меняется через заданные промежутки. Метод не зависит от мобильной сети, обычно прост в подключении и поддерживается многими корпоративными сервисами.

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

FIDO2 объединяет WebAuthn и CTAP2. При регистрации создаётся пара криптографических ключей: открытый ключ передаётся сервису, а закрытый используется аутентификатором для подписи запросов. В зависимости от реализации аутентификатором может быть аппаратный ключ, встроенный модуль устройства или другой поддерживаемый механизм. Сервер не хранит закрытый ключ пользователя.

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

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

Экономика внедрения и интеграция MFA

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

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

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

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

Как встроить MFA в корпоративную среду

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

Дальше работа обычно идёт в несколько этапов:

1. Определить приоритетные сервисы. В первую очередь рассматривают корпоративную почту, административные консоли, хранилища документов, CRM, финансовые приложения и репозитории кода. Также нужно выделить учётные записи подрядчиков и бывших сотрудников, если доступ не отзывается автоматически.

2. Проверить возможности SaaS. Для каждого сервиса стоит узнать, поддерживаются ли TOTP, passkeys или аппаратные ключи, можно ли запретить вход без MFA, есть ли SSO и журналирование событий. Сам факт наличия кнопки включения MFA ещё не говорит, что администратор сможет обеспечить обязательное применение метода.

3. Централизовать вход там, где это возможно. Если сервис поддерживает SAML или OIDC, подключение через корпоративный IdP упрощает управление политиками и отзыв доступа. При этом нужно отдельно проверить локальные учётные записи, аварийный доступ и сервисные аккаунты: SSO не всегда закрывает их автоматически.

4. Выбрать метод с учётом риска. Для пользователей с административными правами и доступа к наиболее важным данным приоритетны фишинг-устойчивые методы. TOTP может быть промежуточным уровнем или практичным решением для сервисов с ограниченной поддержкой. SMS лучше оставлять для случаев, когда более подходящих вариантов нет.

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

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

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

В организациях с несколькими сотнями SaaS-приложений ручная настройка каждой учётки быстро становится неподъёмной. Здесь особенно важна интеграция MFA в корпоративную среду: единая точка аутентификации, автоматическое отключение доступа при увольнении и понятные правила для внешних пользователей сокращают число разрозненных исключений. Но централизация не должна создавать единственную точку отказа. Административные и аварийные аккаунты требуют отдельной политики, а доступ к самому IdP нужно защищать особенно строго.

Что остаётся за пределами второго фактора

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

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

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

Двухфакторная аутентификация для корпоративных SaaS-систем остаётся базовым условием безопасного входа, но качество защиты определяется деталями. SMS и TOTP затрудняют использование украденного пароля, однако не дают той же устойчивости к фишинговому прокси, что и FIDO2. Passkeys и аппаратные ключи требуют поддержки сервиса и аккуратной настройки восстановления. Поэтому внедрение стоит начинать с самых ценных аккаунтов, а затем последовательно распространять политику на весь стек. Не как формальную галочку, а как часть управления доступом, устройствами и сессиями.