Еще пара слов о веб-аутентификации
Поговорим о веб-аутентификации. Действительно, как бы ни развивался мир современных информационных технологий, человек продолжает смотреть на мир через окошко веб-браузера. И я себя ловлю на мысли, что, приходя на работу, первым делом запускаю почту и веб-браузер. Даже еще не подумав, а зачем я это делаю. А браузер в этот момент уже подключается к различным ресурсам и инициирует различные механизмы аутентификации. Давайте разберем, что такое эта самая веб-аутентификация, как она устроена и где и как применяется. В этой статье я не ставлю целью дать формальный и корректный анализ, а скорее хочу дать общий обзор и информацию к размышлению.
Элементы
Вобщем-то, мы сталкиваемся в веб-аутентификацией не один десяток раз в день, начиная от входа в облачную почту Yandex или Google и далее по всему списку, не пропустив и интернет-банк.
Какие же элементы мы можем выделить ? Первый из них – сам клиент, любой веб-браузер. Лирическое отступление: как бы хотелось поверить в слово «любой», но это неправда. Все системы тестируются с определенным набором браузеров, и я уже давно не видел людей, у которых на компьютере есть только один из них. Так что если ваш любимый браузер не работает как надо – не ждите, что разработчик системы что-то оперативно поправит. Лучше попробуйте другой браузер.
Второй элемент – это сам аутентификатор. Им может быть и веб-сервер, и межсетевой экран, и маршрутизатор и т. д. и т. п. Иногда перед веб-сервером установлено специальное устройство, которое предназначено для ускорения SSL-шифрования. Понятно, что оно же выполняет и роль аутентификатора. Такое устройство называется либо SSL-акселератор, либо обратный прокси-сервер.
Следующим элементом является сам сервер аутентификации, авторизации (нам же надо ограничивать полномочия подключающегося) и учета (а чем он, собственно, занимался и в каком объеме?). Он определяет доступные для пользователя ресурсы, права доступа к приложениям и правила аутентификации.
Ну и еще один элемент – это каталог пользователей. Для корпоративной сети такой каталог является общим для всех приложений. За его наполнение отвечают администраторы, которые как раз и устанавливают правила доступа, соблюдение которых обеспечивает аутентификатор. Обычно это либо Active Directory, либо LDAP-сервер.
Несмотря на то что я выделяю аутентификатор, сервер аутентификации и каталог пользователей как отдельные элементы, они могут существовать и комбинироваться совместно. А также могут быть и дополнительные элементы, о которых мы поговорим ниже.
Протоколы
Итак, у нас есть четыре логических элемента. Давайте теперь обратим внимание на те протоколы, которые используются между ними. Первая наша пара – это клиент и аутентификатор, Аутентификатор в большинстве случаев и есть веб-сервер. Тут наш выбор ограничен двумя основными протоколами – HTTP и HTTPS. Разница между ними проста и примитивна: HTTP передает наши драгоценные идентификационные параметры, например имя и пароль, в открытом виде, а HTTPS – в зашифрованном по протоколу SSL/TLS. Честно говоря, вариант с HTTP используется все реже и реже, причем не только при доступе к публичным ресурсам, таким как уже упомянутые Yandex и Google, но и при аутентификации во внутренних сетях предприятий. Великая статистика в настоящее время говорит, что трафик HTTPS сейчас представляет собой уже от 30 до 50% веб-трафика Интернета, и дальше его будет только больше.
Теперь, когда обсудили вопрос о протоколе взаимодействия между клиентом и аутентификатором, двинемся дальше, к протоколу между аутентификатором и сервером аутентификации, авторизации и учета. И этих протоколов может быть множество, начиная от широко применяемых в сетевом мире протоколов TACACS+ и RADIUS и заканчивая такими распределенными протоколами аутентификации, как Kerberos.
Далее, сервер аутентификации должен добраться до каталога пользователей. Тут может быть все что угодно, начиная от LDAP и заканчивая базой данных с доступом по OBDC.
Сценарии
Ну вот, с общей структурой и основными протоколами разобрались. Теперь давайте поговорим, как же веб-аутентификация применяется сегодня в сетях предприятий. Рассмотрим несколько основных сценариев. Самый простой: пришел к нам гость, а то еще и представитель подрядной организации. Мы совершенно не рвемся пускать его в нашу корпоративную сеть, но хоть какой-то доступ ему предоставить надо. Если гость – то Интернет, чтобы ему не было скучно ожидать начала встречи, если подрядчик – доступ к тем системам, которые он обслуживает. И тут как раз нам на помощь и приходит веб-аутентификация: мы имеем возможность зарегистрировать гостя/подрядчика, выдать ему индивидуальный код доступа, при аутентификации рассказать, что ему можно делать, а что нельзя. Попросить подтвердить, что он принимает условия использования наших сетевых ресурсов, и потом предоставить ему контролируемый доступ к ним. На самом деле ровно этот же метод используется и при предоставлении доступа в Интернет в гостиницах, аэропортах, кафе, ресторанах и тому подобных заведениях.
Второй сценарий применения веб-аутентификации в корпоративных сетях уже более сложный. Давайте представим, что у нас есть требования по защите и управлению рабочими местами пользователей. И тут кто-то из наших пользователей получил новый служебный компьютер или провел последние пару недель, а то и месяцев в непрерывных командировках. И вот хочет такой пользователь к сети подключиться, а сеть тут как тут, видит, что компьютер пользователя не соответствует требованиям к установленному программному обеспечению и безопасности, и перенаправляет его на веб-портал, откуда все нужное программное обеспечение может быть установлено.
Следующий сценарий очень прост и понятен – аутентификация пользователей при доступе к внешним ресурсам. Например, есть у нас политика использования сети Интернет, поэтому, когда сотрудник из внутренней сети идет вовне, мы можем его перенаправить на веб-портал, заставить дополнительно аутентифицироваться и после этого решить, к каким внешним ресурсам и когда он может иметь доступ.
Для этих трех сценариев у нас могут быть совершенно различные варианты аутентификаторов. Например, для гостевого доступа – это обычно портал на базе физического или виртуального сервера. То же самое – для установки необходимого программного обеспечения. А вот для третьего сценария – в качестве аутентификатора может быть и межсетевой экран, включая межсетевые экраны нового поколения. Кстати, последний сценарий имеет и обратную сторону. Мы можем использовать межсетевые экраны для защиты ресурсов в центре обработки данных предприятия и использовать веб-аутентификацию на защищающих его межсетевых экранах для контроля и ограничения доступа на сетевом уровне.
Кстати, тут вспоминается классический попутный вопрос: а зачем ограничивать доступ на сетевом уровне, если мы можем контролировать доступ к приложению непосредственно на сервере? И такой же классический ответ: если мы не ограничиваем доступ на сетевом уровне, злоумышленник имеет широкое поле для попыток взлома, сканирования и других вредоносных действий, если же зона доступа сужена на сетевом уровне – его возможности и объем возможного ущерба существенно сокращаются. В общем, несколько основных сценариев рассмотрено, хотя варианты применения ими не ограничиваются.
Варианты
Но пора перейти к следующему вопросу: а как можно усилить аутентификацию? Тут хотелось бы коротко остановиться на современных методах аутентификации. Первый, простой и понятный, – имя пользователя и пароль. Ну и самый проблемный, если честно. Что бы парольная защита была эффективной, накладываются и требования по длине пароля, набору символов, частоте смены и т. п. Потом пользователь, особенно работающий с множеством систем, не может все эти пароли вспомнить. Тут на помощь приходят системы управления паролями, сброса паролей и т. п. В общем, политика управления паролями достойна отдельной статьи, и такие статьи не единожды были написаны.
Второй метод аутентификации – по цифровым сертификатам. Опять же в детали мы не полезем, информации на эту тему предостаточно. Можно только отметить, что наиболее распространенный в Интернете протокол защиты SSL/TLS использует как раз сертификаты. У пользователей обычно сертификаты самоподписанные, а вот у серверов вариантов сертификатов может быть несколько.
Следующий вариант, который я, откровенно говоря, люблю – по однократным паролям (см. рис. 2). Это система, которая создает пароли, которые работают только один раз. Поэтому их можно не шифровать, не защищать и т. п. Один раз воспользовались, и далее пароль недействителен. Для того чтобы такая система работала, нужно два дополнительных компонента – клиентская система генерации паролей и сервер проверки паролей. Они должны быть синхронизированы между собой. Клиентская часть может жить либо в виде отдельного устройства, либо в виде программного модуля для компьютера или смартфона/планшета. Сервер обычно имеет интерфейс взаимодействия с каталогом пользователей и сервером аутентификации.
Рис. 2. Скриншот процедуры аутентификации с одноразовым паролем. Кроме собственно логина и пароля нужно дополнительно ввести одноразовый код
Теперь, после того, как мы рассмотрели несколько методов аутентификации, давайте посмотрим, как мы можем их комбинировать для ее усиления. Это называется многофакторной аутентификацией. Тут есть стандартный подход – комбинация того, что я знаю, с тем, чем я обладаю. Примеров можно привести множество. Один из частых вариантов – совмещение аутентификации по имени и паролю и цифровому сертификату. Например, клиентский сертификат моего браузера используется для взаимной аутентификации с аутентификатором, для установления соединения HTTPS, а затем уже внутри этого защищенного канала я использую аутентификацию по имени и паролю. Причем весьма просто и еще усилить эту систему, поместив мой клиентский сертификат на отдельный носитель (токен), защищенный своим паролем – ПИН-кодом. И вот теперь несчастному злоумышленнику надо узнать мое имя и пароль, а за одно украсть мой токен и узнать к нему ПИН-код. В общем, задача становиться весьма сложной.
При использовании однократных паролей жизнь злоумышленника не на много легче. Ему надо знать мое имя пользователя, что совсем не сложно, но вот дальше ему нужно получить доступ к моему устройству для генерации однократных паролей, да еще знать для него ПИН-код. Так что вариантов создания многофакторной аутентификации множество, проработаны они весьма хорошо – вплоть до создания необходимых облачных сервисов – и надо просто начать ими пользоваться.
Удобства
А теперь мы подобрались к наиболее интересному вопросу: как сделать эту систему удобной для пользователя? Идея постоянно вводить один и тот же пароль, не говоря уж про многофакторную аутентификацию для доступа к разным ресурсам корпоративной сети или выхода из нее в Интернет, способна вывести из себя самого лояльного сотрудника. Ответ на этот вопрос очень прост: SSO (single sign-on) – система единого входа. Есть два основных метода ее построения. Первый – это сквозная аутентификация. То есть если я успешно аутентифицировался первый раз, то остальные системы могут проверить эту информацию и предоставить мне нужный доступ без повторной аутентификации. Один из протоколов аутентификации, работающий подобным методом, – уже упомянутый выше и широко применяемый Kerberos. При этом Kerberos широко применяется именно в сетях предприятий. В Интернете же применяются такие стандарты сквозной аутентификации, как SAML и OpenID.
Но вернемся к корпоративным сетям. Второй метод создания систем SSO – это использование специальных систем управления аутентификацией, когда пользователь аутентифицируется в ней, а потом уже эта система «представляет» пользователя во всех других системах. Кстати, а при чем тут веб-аутентификация? На самом деле она может использовать как системы многофакторной аутентификации, так и системы SSO, что обеспечивает надежную сквозную аутентификацию пользователя.
Заключение
На этой позитивной ноте я хотело бы закончить свой краткий обзор технологий веб-аутентификации. И сказать о том, что теперь, когда вы будете подключаться к Интернету, сидя в кафе, в аэропорту или приходя ко мне на встречу, а также получать доступ к корпоративным ресурсам своего предприятия, вы будете знать, что же скрывается за этим процессом. А если вы специалист, планирующий внедрять подобную систему, то знание о том, что многие десятки, а то и сотни тысяч таких систем уже работают по всему миру и технологии их построения отлажены годами, должно помочь вам в ее разработке и реализации. В качестве заключительного аккорда надо бы привести примеры реализаций, с которыми можно ознакомиться… Это сложный вопрос, потому что называть имена компаний и применяемые у них решения без официального на то разрешения нельзя. Поэтому из всего множества реализованных в России проектов я скажу только о двух: первый – это корпоративная сеть компании Cisco, второй – это ряд проектов и сервисов, реализованных компанией Orange.
