Централизованное управление аутентификацией и информацией о пользователях.

Экскурс в историю

С тех пор, как компьютерные сети получили широкое распространение, использовать файлы, такие как /etc/hosts, /etc/networks, /etc/group, /etc/gpasswd, /etc/passwd, /etc/shadow и им подобные для хранения соответственно информации о хостах, сетях, группах, паролях групп, пользовательской информации, паролей пользователей и прочей подобной информации, которая должна быть целостной на всех узлах сети стало неэффективно. Неэффективно в первую очередь из-за проблем синхронизации. Встал ребром вопрос о разработке технологий централицозанного управления и хранения информации из вышеуказаных файлов. И если для читабельных имен узлов и сетей выбор пал (сейчас уже практически эксклюзивно) на DNS (отщепенцы с NIS и им подобные не рассматриваются), то с пользовательской информацией и механизмами аутентификации не все так просто как кажется. В данной статье мы постараемся описать различные методы вместе с их преимуществами и недостатками.

Итак, поехали.

Для начала важно понимать принципиальное различие трех следующих ключевых терминов:

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


• Аутентификация - процесс удостоверения подлинности пользователя. Иначе говоря успешная аутентификация говорит только о том, что "Ты дейстительно тот, за кого себя выдаешь". Этот процесс может осуществляться огромным количеством способов.


• Авторизация и контроль доступа. Эти две функции отвечают за контроль "соблюдения рамок приличий", иначе говоря зв разрешенные действия и права доступа к ресурсам. Банальный пример - корректно аутентифицированному пользователю средствами авторизации может быть запрещен доступ к серверу вне рабочих часов.

Итак, немного прояснив ситуацию с терминологией определимся, о чем мы сегодня поговорим. Мы постараемся осветить первые 2 пункта. Третий пункт стоит особняком и не является темой сегодняшнего разговора. Начнем с предметного "разноса" устаревшим технологиям. Заметим, что мы рассматриваем все технологии в первую очередь как средство выполнения описанных выше задач, побочные их возможности при этом рассматривать не будем.

NIS

NIS является классическим RPC сервисом, придуманным компание SUN Microsystems
довольно давно. Суть - предоставление сервиса "хранения" пользовательской
информации на центральном сервере домена. Опционально там же хранятся хэши
пользовательских паролей. Как сервис аутентификации NIS крайне несовременен, в
силу того, что в герерогенной среде часто приходится "возвращаться" к
DES-алгоритму шифрования паролей, который был признан небезопасным. Как
хранилище пользовательской информации все еще ограниченно пригоден, а иногда
это вынужденный вариант, так как многие старые Solaris (в частности) системы
не умеют получать пользовательскую информацию с LDAP-сервера.

Принципиально NIS не предоставляет никаких механизмов аутентификации. Для
получения пользовательской информации достаточно знать IP-адрес сервера домена
и название домена. Обычно это легко выясняется с помощью nmap, rpcinfo или
паяльника ( :) ). После этого "неправильная" машина может получить дамп
локальной информации (о боже, в некоторых конфигурациях с паролями шифроваными
DES) для оффлайн-исследования. Резюмируем.

Плюсы:

• Просто и быстро развертывается.


• Простая система миграции информации из файлов /etc/passwd и /etc/shadow

Минусы:

• По умолчанию размещается на динамических RPC портах (плохо файлволлится)


• Не поддерживает шифрование


• Не предоставляет механизмов аутентичикации клиентских машин


• Совместимая со старыми системами версия позволяет использовать только слабые алгоритмы шифрования паролей


• Позволяет любому человеку, знающему ip сервера и имя домена быстро получить копию базы для оффлайн-расшифровки

Применимость:

Аутентификация: rрайне слабое средство. Применять рекомендуется только после вывода о неприменимости других систем.

Пользовательская информация: Ограниченное применение в физически изолированных сетях, обычно вызванное необходимостью совместимости со старыми Solaris

Некоторые недостатки первоначальной NIS были исправлены в NISPLUS (http://en.wikipedia.org/wiki/Nisplus). Тем не менее, бытует мнение, что NISPLUS - это ugly hack и его использовать (особенно в новых системах) не рекомендуется.

DBMS

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

Помимо прочего большинство широко используемых СУБД не позволяют достаточно гранулированно управлять правами (например невозможно запретить пользователю СУБД читать колонку с чужими паролями). Иначе говоря, как и в случае с NIS, злоумышленник часто может просто получить копию базы данных пользователей (а то и паролей).

Плюсы:

• На первый взгляд дотаточно просто

Минусы:

• Нестандартное решение, требующее внешних средств для работы


• Плохая гранулированность аутентификации пользователей в СУБД


• Низкая производительность и плохая масштабируемость

Применимость:

Аутентификация: крайне слабое средство. Don't use that.

Пользовательская информация: ограниченно применимо, если вы сможете ввиду вышеуказанных аргументов ответить на вопрос "А зачем?"

LDAP

История развития LDAP терниста и неоднозначна. В 1988 году коммитеты по стандартам ITU-T (консорциум телекоммуникационных компаний) и ISO сформулировали стандарт для хранения древовидной информации, известный как X.500 или DAP. Вспомните модель OSI, которой все учат, но мало где используют. Стандарт получился "мертворожденным" и получил крайне ограниченное распространение. Из минусов исходного стандарта можно отметить переусложенность, наличие непонятной в мире Internet иерархии, основанной на географических терминах.

Тем не менее ряд остроймных людей отпрофилировал систему, реализующую DAP и, переложив "понятия" телекоммуникационных компаний на интернет, а также разбавив изначальную спецификацию здравым смыслом, разработали протокол LDAP (Lightweight Directory Access Protocol). Кстати говоря "облегченный" этот протокол как раз в сравнении с оригинальным DAP.

В настоящее время существует несколько инкарнаций LDAP, такие как OpenLDAP, Red Hat Directory Server ( в девичестве Netscape Directory Server ) а также другие (например M$ Active Directory). В настоящее время LDAP является сдандартом де-факто для хранения пользовательской информации. При этом, правда, некоторые ошибочно воспринимают LDAP как "святой грааль", коим он не является. LDAP - не более чем концепт специальной нетранзакционной древовидной БД для хранения различных данных, грамотное использование которого возможно только при правильной "проекции" этого концепта на конкретную ситуацию.

LDAP, используемый для хранения пользовательской информации, а, возможно, и аутентифиакции имеет следующие отличительные черты:

Плюсы:

• Стандарт


• Высокая производительнось операций чтения (особенно одиночных)


• Достаточно хорошая масштабируемость, низкие "накладные расходы"


• Достаточно четкий и гранулированный механизм разграничения доступа к данным, хранящимся в директории


• Поддержка SSL/TLS - шифрования


• Наличие механизмов аутентификации клиентских машин при получении пользовательской информации

Минусы:

• Сложность в освоении в силу "непохожести" на другие технологии

Применимость:

Аутентификация: применимо. Отсутсвует фукнциональность Single Sign on. (как впрочем и в предыдущих решениях)

Пользовательская информация: о, да!

Принципиальные различия между OpenLDAP и, например, Red Hat Directory Server лежат в границах применимости и доп. возможностях. Например OpenLDAP вполне неплохо подходит для хранения небольшой директории (до 5000 записей). Начиная примерно с этого объема RHDS масштабируется заметно лучше. Помимо этого RHDS имеет следующие основные и принципиальные преимущества:

• Multi-master репликация. До четырех мастеров могут обслуживать одно дерево.


• Поддержка двунаправленной репликации с Active Directory.

Kerberos.

Kerberos был создан в стенах небезызвестного MIT и является на сегодняшний день стандартом технологии аутентификации. Хотя Kerberos и использует шифрование симметричными ключами, ключи никогда не передаются по сети. При этом достаточно сложная система аутентификации позволяет строить домены аутентификации "Authentication Realm", внутри которых действует Single Sign On, тоесть пользователю достаточно аутентифицироваться на KDC, чтобы аутентифицироваться в дальнейшем на любом из сервисов домена без необходимости ввода пароля.
Именно Kerberos для аутентификации и LDAP для хранения пользовательской информации в настоящее время считаются "референсным" решением. Подобная схема (хоть и совершенно несоответствующая общепринятым тандартам) используется в так называемых Windows-доменах.

Kerberos - исключительно механизм аутентификации. Основные действующие лица:

• KDC, он же Центр Дистрибьюции Билетиков (Ticket), он же Key Distribution Cetner. Знает секретные ключи всех остальных участников, поэтому его надо ревностно охранять.


• Client Principal, он же клиент - биологический объект, желающий аутентифицироваться


• Service Principal, он же сервис - небиологический объект (сервис), который поддерживает аутентификацию Kerberos.


• Client-Service Ticket - кратковременное "разрешение на временную аутентификацию"


• TGT, он же Ticket Granting Ticket - долговременное разрешение получать Ticket'ы

Механизм аутентификации следующий:

Сценарий 1. Клинет аутентифицируется на KDC.

1. Клиент изъявляет желание аутентифицироваться и сообщает об этом серверу. Сервер в ответ отправляет 2 ообщения:
   
   
   
   1. Ключ сессии зашифрованный секретным ключем пользователя
      
   2. TGT, зашифрованный секретным ключем KDC
      
   
   
2. Получив оба сообщения и расшифровав первое клиент обладает достаточной информацией для аутентификации на KDC
   
3. TGT (второе сообщение) не может быть расшифрован клиентом. Он кэшируется и доступен для использования всему поддереву дочерних процессов,
   

Сценарий 2. Клиент хочет получить доступ к сервису.

1. Клиент отправляет запрос на сервер аутентификации, содержащий следующие данные:
   
   
   
   1. Составное сообщение, состоящее из ID сервиса и зашифрованного секретным ключем KDC TGT из предыдущего сценария.
      
   2. Аутентификатор, сотоящий из ID клиента метки времени (timestamp), зашифрованный ключем сессии.
      
   
   
2. Расшифровав эти сообщения, сервер может принять решение о "разрешении"доступа клиента к сервису. Это есть элемент авторизации. В случае положительного решения KDC отвечает клиенту также двумя сообщениями:
   
   
   
   1. Client-Service Ticket, зашифрованный секретным ключем Service Principal'а. Client-Service Ticket включает ключ сессии клиент-сервис, а также прочую информацию. Клиент не может его расшифровать.
      
   2. Ключ сессии клиент-сервис, зашифрованный ключем сессии клиент-KDC.
      
   
   
3. Довольный клиент имеет теперь достаточно информации для аутентификации "на сервисе".
   

Сценарий 3. Аутентификация клиента с сервисом.

1. Клиент пересылает сервису следующие сообщения:
   
   
   
   1. Client-Service Ticket, зашифрованный секретным ключем Service Principal'а из предыдущего сценария.
      
   2. Аутентификатор, содержащий ID клиента и метку времени, зашифрованные ключем сессии клиент-сервис.
      
   
   
2. Сервис расшифровывает первое сообщение. Из него он получает ключ сесии клиент-сервис. Расшифровывает полученным ключем второе сообщение и аутентифицирует клиента, если метка времени находится в доверительном интервале. Отправляет клиенту подтверждение, содержащее
   
   
   
   1. Метку времени, зашифрованную ключем сессии клиент-сервис.
      
   
   
3. Клиент расшифровывает сообщение и проверяет корректность метки времени. В случае если метка обновлена корректно аутентификация прошла успешно, клиент и сервис начинают "общаться".
   

Преимущества:

• Секретные ключи не пересылаются по сети
  
• Single Sign On.
  
• Простой механизм борьбы с перехваченными ключами сессии: они истекают раньше, чем их удается расшифовать.
  

Недостатки

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

Применимость:

Аутентификация: о, да! Помимо прочего архитектурно является механизмом авторизации.

Пользовательская информация: Нет в силу другого предназначения.

Вот и все на сегодня. Мы определили, что оптимальный на сегодняшний день решением для аутентификации является Kerberos, а средством для хранения пользовательской информации служит LDAP. В случаях, когда закон жизни не диктует обратное, именно такие решения стоит реализовывать. А какнибудь попозже мы расскажем как.