Не только смс и токен: многофакторная аутентификация на базе SafeNet Authentication Service
Обычно при фразе “многофакторная аутентификация” люди в первую очередь вспоминают про смс-коды, которые приходят, когда оплачиваешь картой онлайн-покупки. Чуть реже на ум приходит флешка с цифрами, токен.
Сегодня я расскажу про другие способы многофакторной аутентификации и задачи, которые они помогают решить компании. Рассказывать буду на примере решения Gemalto Safenet Authentication Service (SAS), которое существует в формате облачного сервиса и on-premise версии, сертифицированной ФСТЭК.
Все примерно представляют, что такое многофакторная аутентификация: это когда помимо пароля (фактор знания) нужно ввести дополнительный подтверждающий фактор. Их два:
Ниже приведу несколько примеров того, какие задачи можно решить с помощью SafeNet Authentication Service.
Задача: соблюдение стандарта PCI DSS
Многофакторная аутентификация – одно из требований стандарта PCI DSS (п. 8.3.). Более того, стандарт требует, чтобы многофакторная аутентификация была одноэтапной: пароль и второй фактор должны вводиться в одном поле. Если злоумышленник попробует завладеть учеткой и ошибется при вводе, ему будет непонятно, где была допущена ошибка – в пароле или токене.
Решение: одноэтапная многофакторная аутентификация по схеме PIN + OTP
Такая схема аутентификации на базе SafeNet реализована в нашей IaaS-платформе, соответствующей требованиям PCI DSS и 152-ФЗ, – Cloud-152. Ее проходят администраторы платформы Cloud-152 для доступа к management-сегменту. Для авторизации нужно ввести в одном поле PIN и OTP, который приходит push-уведомлением в мобильном приложении Mobile Pass.
Так выглядит авторизация для администраторов Cloud-152 со стороны DataLine.
*Здесь должен был быть скриншот с SafeNet Mobile Pass, но приложение блокирует скриншоты.
Задача: двухфакторная аутентификация для сотрудников без смартфона и мобильного интернета
Компания собирается внедрять двухфакторную аутентификацию для входа на рабочие станции. У компании распределенная сеть офисов по всей России, у многих сотрудников нестабильный мобильный интернет или вообще нет смартфона. Получается, что Push-уведомления от мобильных приложений в качестве второго фактора не подойдут. СМС и физические токены отпадают из-за дороговизны.
Решение: использование в качестве второго фактора GrIDSure
GrIDSure – это одноразовый пароль (OTP). Он состоит из таблицы с символами и паттерна, который пользователь сам задает при настройке аутентификации. Для авторизации пользователь выбирает символы из таблицы по этому паттерну и вводит в качестве второго фактора.
Таблица с символами, которую пользователь получает при авторизации на рабочие станции.
Дальше пользователь просто следует выбранному паттерну. Например, вот такому.
В качестве символов можно использовать цифры, буквы и спецсимволы. Размер таблицы настраивается: это может быть таблица 5 на 5 или больше.
При каждой попытке аутентификации таблица обновляется, поэтому такой пароль не забрутфорсить.
С Gridsure также не нужно мобильное приложение, и следовательно, смартфон с мобильным интернетом. GrIDSure отображается в том же интерфейсе и устройстве, что и защищаемый сервис.
Задача: защита веб-сервиса от атаки методом перебора
Многофакторную аутентификацию на базе SafeNet можно использовать для защиты веб-сервисов, опубликованных в интернете, например, Outlook Web App (OWA). Safenet поддерживает RADIUS и SAML-протоколы, поэтому легко интегрируется с сервисами Microsoft Outlook, Office 365, Saleforce, Dropbox, Apache и т.д.
Если злоумышленник знает email’ы, то он сможет атаковать такие сервисы с помощью перебора паролей. Целью такой атаки не всегда может быть захват учетки, а ее блокировка. В теории можно заблокировать всей компании почту.
Решение: использование OTP в качестве второго фактора
Тут можно использовать GrIDSure или Mobile Pass в качестве второго фактора.
Задача: автоматизация выдачи и обслуживания токенов
В компании с распределенной сетью отделений на 20 тысяч сотрудников уже используют двухфакторную аутентификацию с GrIDSure в качестве второго фактора.
Проблема в том, что администраторам приходится тратить много времени на обслуживание токенов: выпускать новые, сбрасывать паттерны и т. д.
Решение: использование портала самообслуживания
В SafeNet есть портал самообслуживания, который поможет автоматизировать рутинные операции и снизить нагрузку на администраторов.
На портале самообслуживания пользователь может оставить всю информацию, необходимую для выпуска токена. Администратору остается только подтвердить ее и отправить ссылку на формирование токена. Если пользователь забыл, какую траекторию выбрал для GrIDSure, то опять-таки самостоятельно может сбросить ее здесь и задать новую.
Задач: Регламентирование доступа к рабочим станциям
В call-центре работают 200 сотрудников посменно. Для экономии ресурсов на двух сотрудников приходится одна рабочая станция. Нужно настроить доступы так, чтобы не было конкурентных сессий.
Решение: внедрение входа по токенам и политики доступа
SafeNet можно установить на каждую рабочую станцию и через него задать политики доступа по времени и IP-адресам. Если смена сотрудника еще не началась, то он не сможет зайти на свою рабочую станцию. Администратор сможет проследить, когда тот или иной сотрудник заходил в систему и с какого IP-адреса в журнале.
Многофакторная аутентификация становится все актуальнее, так как статический пароль даже с большим количеством символов – уже не сложное препятствие на пути злоумышленника.
Еще одна из тенденций в этом направлении – использование токена для доступа сразу к нескольким системам или приложениям компании (SSO-вход). Такой сценарий также можно реализовать с помощью SafeNet. Если интересно, расскажу про него в отдельном посте.
Обзор мультифакторной аутентификации в облаке Microsoft Azure
В систему безопасности Microsoft (тогда еще Windows) Azure недавно была внедрена новая функциональность – мультифакторная проверка подлинности. МПП, понятное дело, нужна для того, чтобы выстроить дополнительный контур защиты вокруг учетной записи либо облачных сервисов как Microsoft, так и решений сторонних компаний или приложений и сервисов, которые используют в качестве системы аутентификации сервис Microsoft Azure Active Directory. Можно защищать и локальную инфраструктуру – например, наш Multifactor Authentication Server можно интегрировать в контур RADIUS. Интересно? Под катом – описание решения ситуации, когда нам нужно защитить доступ в подписку Azure не только логином и паролем, и немного про то, куда идти за более сложными вещами.
Мультифакторная проверка подлинности Windows Azure предоставляет дополнительный слой проверки подлинности в дополнение к учетным данным пользователя. При этом многофакторную проверку подлинности можно использовать для защиты доступа как к расположенным on-premise, так и облачным приложениям. К возможным опциям мультифакторной проверки подлинности относятся:
• мобильные приложения,
• телефонные звонки
• текстовые сообщения,
Пользователи могут выбрать то, что им удобно, как самостоятельно, так и принудительно – администратор может это регламентировать. В контексте защиты локальных приложений мультифакторную проверку подлинности можно использовать для защиты VPN удаленного доступа, RADIUS, и Web-приложений с помощью специального SDK. Если облачное приложение использует Active Directory Federation Services, то разработчик может настроить синхронизацию с Windows Server Active Directory или другим каталогом LDAP. Что же касается других сервисов Microsoft, то мультифакторная проверка подлинности полезна для защиты доступа к Microsoft Azure, Microsoft Online Services, Office 365 и Dynamics CRM Online.
Давайте посмотрим, как приготовить многофакторную аутентификацию в Windows Azure.
Что нужно для того, чтобы повторить демо:
• Подписка Windows Azure — хватит триала: free trial
• Тенант Windows Azure Active Directory
Сначала создадим провайдера MFA: на вкладке Active Directory на портале управления Azure перейдем на страницу ПОСТАВЩИКИ МНОГОФАКТОРНОЙ ПРОВЕРКИ ПОДЛИННОСТИ. Нажмем Создать, и введем данные — имя поставщика (логическое), «на включенного пользователя» и выберем каталог, к которому надо привязать поставщика. Теперь создадим нового пользователя на странице Пользователи — это нужно для того, чтобы активировать MFA, так как MFA не работает для Microsoft Account (только для организационных).
Добавление пользователя — процесс, состоящий из трех шагов: типа учетной записи пользователя…
… Его роли в организации и тенанте (установите роль глобального администратора и отметьте опцию включения многофакторной проверки подлинности)…
… и установке временного пароля.
Создадим новый пароль и завершим настройку нового пользователя. Под этим пользователем и будем заходить в систему позже. После создания пользователя зайдите на его страницу и укажите мобильный телефон — обратите внимание, что также указывается код страны в выпадающем меню — не надо писать его в поле.
Отлично — инфраструктурные задачи для нашего простого сценария кончились. Теперь попробуем выйти с портала и снова зайти, но уже под новым пользователем. Появится новая опция — Set it up now, означающая, что администратор тенанта форсировал применение MFA для нашего пользователя.
На странице настройки MFA для нашего пользователя есть все нужные поля — выбор типа аутентификации, номер телефона, и выбор между СМС и звонком.
На следующей странице нам предложат верифицировать выбранный тип аутентификации. В нашем случае приятный женский голос по телефону расскажет, что надо нажать для того, чтобы пройти дополнительный контур безопасности. Попробуйте войти в аккаунт Azure под новой учетной записью – опыт тот же самый.
Посмотрим теперь на более сложные сценарии — использование MFA для каталога и On-Premise.
Для того, чтобы использовать MFA On-Premise — например, интегрировать с IIS, RADIUS, Windows auth или даже LDAP — нам нужно загрузить и установить Multi-Factor Authentication Server. Загружается он, если нажать на созданном ранее провайдере MFA, перейти на управление этим провайдером и нажать Сервер || Загрузка.
Пока загружается сервер, нажмем также «Создать учетные данные для активации» — они нужны будут для активации сервера после установки.
Установим и активируем сервер. Обратите внимание — пароль действует 10 минут после момента его создания, поэтому не затягивайте с процессом активации.
В процессе настройки сервера вы увидите множество интересных опций — например, на вкладке Applications можно настроить, какие сервисы и приложения будут защищены MFA.
Сервер MFA настроен на каталог AD по умолчанию, но перенастроить или добавить еще один каталог — совершенно не проблема — достаточно на вкладке Directory Integration выбрать Synchronization и нажать ADD, после чего настроить синхронизацию и периодичность ее проведения.
Еще одна, типично корпоративная полезность — это интеграция MFA с RADIUS для защиты VPN и прочих функциональностей типа Microsoft Unified Access Gateway, TMG или даже RDG. Настройка интеграции на вкладке RADIUS Authentication.
Резюме
Мы посмотрели на функцию Windows Azure Active Directory — Multi-Factor Authentication. Процесс ее настройки значительно упростился по сравнению с тем периодом, когда она только выходила в свет, и теперь не видится особых проблем по тому, чтобы настроить MFA как в простейших сценариях типа обеспечения дополнительного слоя безопасности для входа в подписку Windows Azure, так и в сложнейших корпоративных — интеграции с RADIUS. О других сценариях – позже.
Multifactor — российская система многофакторной аутентификации
Введение
Долгое время считалось, что классический метод аутентификации, основанный на комбинации логина и пароля, весьма надёжен. Однако сейчас утверждать такое уже не представляется возможным. Всё дело — в человеческом факторе и наличии у злоумышленников больших возможностей по «угону» пароля. Не секрет, что люди редко используют сложные пароли, не говоря уже о том, чтобы регулярно их менять. К сожалению, является типичной ситуация, когда для различных сервисов и ресурсов применяется один и тот же пароль. Таким образом, если последний будет подобран посредством брутфорса или украден с помощью фишинговой атаки, то у злоумышленника появится доступ ко всем ресурсам, для которых применялся этот пароль. Для решения описанной проблемы можно использовать дополнительный фактор проверки личности. Решения, основанные на таком методе, называются системами двухфакторной аутентификации (two-factor authentication, 2FA) или многофакторной аутентификации (multi-factor authentication, MFA). Одним из таких решений является Multifactor от компании «Мультифактор». Эта система позволяет выбрать в качестве второго фактора один из следующих инструментов: аппаратный токен, SMS-сообщения, звонки, биометрию, UTF, Google Authenticator, «Яндекс.Ключ», Telegram или мобильное приложение. Необходимо добавить, что данное решение предлагается только в качестве сервиса, когда у заказчика устанавливаются лишь программные агенты, а ядро системы размещается на стороне вендора, избавляя таким образом специалистов заказчика от проблем с внесением изменений в инфраструктуру и решением вопросов по организации канала связи с провайдерами для приёма звонков и SMS-сообщений.
Функциональные возможности системы Multifactor
Система Multifactor обладает следующими ключевыми функциональными особенностями:
Большой выбор способов аутентификации: Telegram, биометрия, U2F, FIDO, OTP, Google Authenticator, «Яндекс.Ключ», мобильное приложение Multifactor, звонки и SMS-сообщения.
Предоставление API для управления пользователями из внешних систем.
Журналирование действий пользователей при получении доступа.
Управление ресурсами, к которым осуществляется доступ.
Управление пользователями из консоли администрирования.
Возможность импорта пользователей из файлов формата CSV или простого текстового файла.
Большой перечень ресурсов, с которыми возможна интеграция Multifactor: OpenVPN, Linux SSH, Linux SUDO, Windows VPN, Windows Remote Desktop, Cisco VPN, FortiGate VPN, Check Point VPN, VMware vCloud, VMware Horizon, VMware AirWatch, Citrix VDI, Huawei.Cloud (в России — SberCloud), Outlook Web Access, и другие.
Управление функциями системы Multifactor через единую консоль администратора.
Информирование администратора системы о потенциальных инцидентах в сфере ИБ.
Поддержка Active Directory и RADIUS. Возможность возвращать атрибуты на основе членства пользователя в группе.
Архитектура системы Multifactor
Как уже было сказано, Multifactor является сервисным продуктом. Таким образом, вычислительные мощности и сетевая инфраструктура, необходимые для работы системы, размещены в Москве, в дата-центре «Даталайн». ЦОД сертифицирован по стандартам PCI DSS (уровень 1) и ISO/IEC 27001:2005. На стороне заказчика устанавливаются только следующие программные компоненты с открытым исходным кодом:
RADIUS Adapter (для приёма запросов по протоколу RADIUS)
IIS Adapter (для включения двухфакторной аутентификации в Outlook Web Access)
Портал самообслуживания (для самостоятельного управления средствами аутентификации со стороны пользователей).
Системные требования Multifactor
Для корректного функционирования Multifactor производитель установил отдельные системные требования по каждому из компонентов системы. В таблице 1 указаны минимальные ресурсы для RADIUS Adapter.
В таблице 2 приведены показатели, соответствие которым необходимо для установки портала самообслуживания (Self-Service Portal).
Для взаимодействия с большей частью средств коммутации и сервисов в целях осуществления доступа в Multifactor используется сетевой протокол RADIUS (Remote Authentication Dial-In User Service). Система полагается на данный протокол в следующих сценариях:
Схема двухфакторной аутентификации, где в качестве первого фактора пользователь применяет пароль, а в качестве второго — мобильное приложение, Telegram или одноразовый код (OTP);
Схема однофакторной аутентификации, где пользователь применяет логин, а вместо пароля вводится второй фактор (например, пуш-уведомление).
Для того чтобы можно было использовать протокол RADIUS, необходимо обеспечить беспрепятственное подключение устройства доступа (сервер, межсетевой экран или другое средство сетевой коммутации) к адресу radius.multifactor.ru по UDP-порту 1812. Соответственно, данный порт и веб-адрес должны находиться в списке разрешённых.
Кроме того, протокол RADIUS можно применять для обеспечения безопасности подключения по SSH, использования команды SUDO и других операций, требующих усиленного контроля доступа. Также сетевой протокол RADIUS пригодится как дополнительный инструмент проверки подлинности Windows для подключения к удалённому рабочему столу (Remote Desktop).
Для полноценного использования протокола RADIUS в Multifactor применяется программный компонент Multifactor RADIUS Adapter. Multifactor RADIUS Adapter реализует следующие возможности:
получение запросов для прохождения аутентификации по протоколу RADIUS;
проверка логина и пароля пользователя в Active Directory или NSP (Microsoft Network Policy Server);
проверка второго фактора аутентификации на мобильном устройстве пользователя;
настройка доступа на основе принадлежности пользователя к группе в Active Directory;
включение второго фактора на основе принадлежности пользователя к группе в Active Directory;
применение мобильного телефона пользователя из Active Directory для отправки одноразового кода через SMS.
Помимо RADIUS в Multifactor также используется протокол взаимодействия SAML, который кроме двухфакторной аутентификации предоставляет технологию единого входа (SSO) в корпоративные и облачные приложения, где первым фактором может быть логин и пароль от учётной записи в Active Directory либо в Google или Yandex. При использовании протокола SAML в Multifactor можно настроить взаимодействие для аутентификации со следующими приложениями и сервисами: VMware, Yandex.Cloud, SberCloud, Salesforce, Trello, Jira, Slack и др.
Если вас заинтересовал данный продукт, то мы готовы провести совместное тестирование. Следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Многофакторная аутентификация в дата-центре — какой она должна быть?
Продолжая разговор на тему информационной безопасности, сегодня предлагаем обсудить такую важную тему, как многофакторная аутентификация в корпоративной сети. В прошлый раз мы писали о том, что такое «ловушка для человека» в дата-центре. Аутентификация сотрудников в крупной компании, а в особенности дата-центре компании, где находится все самое ценное — информация, это важнейший фактор защиты от утечки информации.
В компании, где работает больше десятка человек, необходимо назначать различные уровни доступа пользователям для защиты информации. Обычно используется несколько уровней защиты, включая аутентификацию (подтверждение личности), авторизацию (контроль доступа) и учет действий (логирование). Доступ к любой критически важной информации или оборудованию должен осуществляться посредством многофакторной защиты. Давайте посмотрим, как это может работать в сети компании.
Итак, любое устройство, дающее доступ к общим ресурсам, которые являются критически важными, чаще всего запрашивает логин и пароль. В простейшем варианте эти данные записаны в локальной базе данных, откуда и берется информация для сверки данных и подтверждения прав конкретного пользователя на доступ к конкретным ресурсам.
Но в крупных компаниях использование локальной аутентификации непрактично. Любые изменения (например, если пользователь переходит на новую должность или покидает компанию) нужно тогда вносить во все локальные базы в каждой из точек доступа. Лучше использовать общую базу.
Серверная аутентификация
В корпоративной сети устройства доступа лучше подключать к общей базе, которая размещается в облаке или удаленном сервере. Устройство, как и в случае локальной аутентификации, работает со связкой логин/пароль, но данные для проверки корректности данных пользователя при этом берутся с сервера. Если необходимо вносить изменения о пользователе, это нужно сделать всего один раз.
Сейчас одним из наиболее популярных протоколов дистанционной аутентифицкации пользователей, не зависящим от поставщиков, является Radius. Он был разработан корпорацией Livingston Enterprises в качестве протокола аутентификации и учета для сервера доступа. В Сети без труда можно найти как проприетарные, так и open-source реализации протокола. Есть и другие варианты — это, например, LDAP (обычно его используют в окружении продуктов Microsoft) и TACACS (используется в окружении Cisco).
LDAP (англ. Lightweight Directory Access Protocol — «облегчённый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP.
TACACS (англ. Terminal Access Controller Access Control System) — сеансовый протокол, использовавшийся на серверах доступа ARPANET. Центральный сервер, который принимает решение, разрешить или не разрешить определённому пользователю подключиться к сети.
Факторы аутентификации: то, что вы знаете, то, что у вас есть и то, чем вы являетесь
Большинство простых систем безопасности использует для защиты информацию, которая известна определенной категории пользователей. Это обычно пароль и логин. Для того, чтобы получить несанкционированный доступ к ресурсам или оборудованию, злоумышленнику необходимо получить эти данные. У дата-центров подавляющего большинства компаний не один, а несколько уровней защиты.
Второй уровень защиты обычно использует нечто, что принадлежит пользователю. Это, например, одноразовый пароль, сгенерированый картой-токеном, или же тот же пароль, отправленный на смартфон пользователя по SMS. Для получения доступа к закрытым ресурсам злоумышленнику теперь нужно не только знать связку логин и пароль, но и получить какое-то оборудование у авторизованного пользователя, что уже сложнее. Защита такого типа уже является двухуровневой.
И, наконец, третий уровень защиты — это биометрия. Отпечаток пальца, рисунок радужной оболочки глаза, анализ голоса — все это биометрия. Добавление третьего слоя защиты значительно затрудняет доступ злоумышленников к критически важным для компании ресурсам.
Мультифакторная аутентификация для управления инфраструктурой
Системные инженеры и администраторы обычно имеют привилегированный статус в системе. Для доступа к ресурсам компании они проходят все три уровня доступа. Обычным же пользователям обычно выдают лишь связку логин/пароль, обеспечивающих доступ к наименее критичным ресурсам, необходимым для работы.
Двухфакторные системы аутентификации обычно работают уже с протоколом Radius. Два примера реализации такой системы — это RSA SecurID и Duo Security. Пользователь получает карту-токен (выглядит, как небольшой калькулятор) или мобильное приложение. И устройство, и программа делают одно и то же — выдают одноразовый пароль для доступа к ресурсам. Этот пароль имеет определенный срок действия.
Сейчас прослеживается два тренда в вопросе мультифакторной аутентификации:
В ближайшие годы мы увидим бурное развитие технологий мультифакторной аутентификации, постепенное упрощение решений с их одновременным удешевлением. Эти решения будут также постепенно переходить в «облако», обеспечивая возможность работы с ними из любой точки мира. Собственно, это уже происходит.
