Простая и надежная защита удаленного доступа
В этой статье я постараюсь сформулировать решение задачи защиты доступа сотрудников при удаленной работе с корпоративными информационными системами.
Беспрецедентный, массовый формат дистанционной работы, привел к необходимости предоставления доступа к информационным системам с личных устройств сотрудников. Это в свою очередь привело необходимости пересмотра существующих политик и методов обеспечения информационной безопасности.
Задача, которую формулирует бизнес — в короткие сроки обеспечить простую и надежную защиту доступа к корпоративными системам с минимальными затратами.
Текущая ситуация
Обозревая положение дел, можно сказать, что методы аутентификации пользователей по логину/паролю недостаточны. Смарт-карты и аппаратные токены, несмотря на зрелость технологии дешевле не стали.
Удаленный доступ в корпоративную сеть организуется по-прежнему, с помощью VPN. Это старое, проверенное решение, которое, к сожалению, не справляется с новыми вызовами:
- VPN предназначен для объединения доверенных сетей и устройств в единую сеть с трансляцией адресного пространства;
- В случае с личными устройствами, фактора доверия нет, поскольку устройства не управляются организацией;
- Кроме того, VPN-соединение одно из сложных видов подключения, которое требует от пользователей установки дополнительного ПО, настройки и управления сертификатами. Именно поэтому увеличивается количество обращений в службу технической поддержки;
- Сотрудники поддержки, решая запрос пользователя по настройке VPN-соединения первым делом устанавливают одно из средств удаленного доступа и этим создают, возможно не первую, дыру в безопасности корпоративной сети;
- Что касается организации, то VPN требует развития соответствующей инфраструктуры, как-то VPN-коммутаторы, стоимости которых пропорционально возрастают от количества обслуживаемых подключений.
Альтернативой является протокол HTTPS, который не требует доверия от устройства или сетей с которых осуществляется запрос. Передача данных осуществляется поверх криптографических протоколов TLS, обеспечивая шифрование аналогично VPN и защищая от атак, основанных на прослушивании сетевого соединения и атак типа человек по середине.
Далее, в поиске решения будем ориентироваться на протокол HTTPS, а за решением проблемы слабой аутентификации обратимся к концепции нулевого доверия (Zero Trust).
Нулевое доверие
Концепция исходит из того факта, что прежде надежное устройство выйдя из корпоративной сети, может вернуться скомпрометированным, при этом пользователь не будет подозревать, что стал источником серьезного нарушения безопасности.
Именно поэтому устройство и пользователь всегда должны подтверждать, что не обладают угрозой, прежде чем получить доступ к информационным системам.
Фундаментальным методом безопасности в этой концепции является многофакторная аутентификация, при которой пользователю необходимо предъявить более одного доказательства аутентификации, к которым относят:
- Фактор знания – обычно пароль;
- Фактор владения – подтверждает, что устройство с которого мы получаем доступ принадлежит нам;
- Фактор свойства – подтверждает, что это именно мы запрашиваем доступ. К этим свойствам относятся наши биометрические особенности.
Вопросы биометрии оставим в стороне, рассмотрим подробнее механизмы подтверждения владением или второй фактор аутентификации.
Многофакторная аутентификация
В основе подтверждения лежат алгоритмы генерации одноразовых кодов – HOTP и TOTP. HOTP (упр. Hash-Based One-Time Password) — алгоритм односторонней аутентификации т.е. сервер производит аутентификацию клиента.
В качестве первого параметра, отвечающего за динамику генерации кодов, используется событие, то есть сам факт генерации. Каждый раз при создании нового кода счётчик событий увеличивает своё значение на единицу, и именно это возрастающее значение используется как основной параметр алгоритма.
Вторым параметром для расчёта одноразовых паролей является симметричный ключ, который должен быть уникальным для каждого пользователя и закрытым от всех, кроме сервера и самого генератора.
Алгоритм впервые был описан в декабре 2005. В качестве хэш функции используется SHA-1, которая более не считается устойчивой к коллизиям. В 2008 году HOTP подарил жизнь более сильному алгоритму Time-based One-time Password (TOTP), который во многом наследует черты родителя.
Основным отличием TOTP, является генерация кода на основе метки времени, при этом используется не точное значение времени, а текущий интервал, границы которого были установлены заранее (например, 30 или 60 секунд).
Поскольку в основе HOTP находится счётчик, то HOTP-коды остаются действительными в течение неограниченного количества времени, в то время как TOTP-коды перестанут быть действительными спустя малый промежуток времени.
В итоге, при условии использования той же самой хеш-функции, TOTP является более безопасным и предпочтительным решением для расширенной аутентификации.
Надо отметить, что как и любая зрелая технология, ее реализация хорошо представлена для многих платформ, а именно:
- Приложения для самартфонов Microsoft Authenticator, Google Authenticator, Яндекс.Ключ и др.;
- Плагины для браузеров Google Chrome, Mozilla Firefox, Microsoft Edge;
- Коды можно отправлять по каналам связи Email, SMS, Voice, Messengers.
Теперь мы сориентировались в протоколе доступа и методе аутентификации, а для решения первоначальной задачи, нам нужно рассмотреть системы, которые могут реализовать обе практики.
Службы доступа
Такие системы в инфраструктуре Microsoft есть – это ADFS и RDG, подробно обозревать их не буду, опишу только суть.
Active Directory Federation Services (ADFS)
Служба Windows Server, которая предоставляет пользователям, работающим как во внутренней, так и во внешней сети, доступ к веб-приложениям с использованием механизма сквозной аутентификации. При этом учетные записи пользователей и приложений могут быть в различных сетях и принадлежать различным организациям.
Для публикации корпоративных веб-ресурсов в сети Интернет ADFS работает совместно с другой службой Windows Server — Web Application Proxy (WAP). Примерами веб-приложений является:
- Outlook Web Access;
- Порталы SharePoint Server;
- 1C: Предприятие тонкий клиент и 1С-Битрикс;
- Любые корпоративные веб-приложения с авторизацией пользователей на основе учетных записей в Active Directory.
Remote Desktop Gateway (RDG)
Вторая служба представляющая интерес, является шлюз удаленных рабочих столов, который создает зашифрованное подключение по протоколу HTTPS между пользователем и удаленной рабочей станцией.
К основным возможностям шлюза относят:
- Подключение к сетевым ресурсам, которые размещены за межсетевыми экранами в частных сетях или NAT;
- Отслеживание состояния шлюза для аудита безопасности, например, логирование неудачных попыток подключения к серверу шлюза, адресов соединений;
- Настройка политик авторизации для разных случаев, которые должны быть выполнены при подключении к корпоративным ресурсам.
Итог
- Для работы в новой парадигме безопасности, в большинстве случаев нам не нужны аппаратные токены, потому что современные мобильные устройства могут самостоятельно генерировать коды безопасности или в крайнем случае получать их по различным каналам связи;
- Код подтверждения постоянно меняется, это гораздо безопаснее, чем логин-пароль, а совместное применение двух факторов предоставляет необходимый уровень защиты доступа;
- Поскольку в качестве протокола используем HTTPS, то у нас упрощается инфраструктура доступа, и соответственно снижаются затраты на сопровождение;
- C точки зрения пользователя, реализуемые методы гораздо дружелюбнее, поскольку обеспечивают понятный для них процесс доступа, а это в свою очередь повышает лояльность к соблюдению правил информационной безопасности и снижает количество обращений в техническую поддержку.
Теория выглядит убедительной, посмотрим как дело обстоит на практике.
Видео с демонстрацией работы провайдеров многофакторной аутентификации записывал одним дублем, поэтому прошу извинить за артефакты.
Подробная информация о решении размещена на портале https://www.n-kraft.ru/rmw/mfa