Сергей Яремчук

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

Недостатки базовой и digest-аутентификаций

В протоколе HTTP предусмотрено два типа аутентификации: basic и digest, которые определены в RFC 2617. Их механизм очень подробно рассмотрен в статьях Алексея Мичурина [1, 2]. Остановлюсь на недостатках.

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

В digest-схеме эти проблемы частично решены. По сети (опять же при каждом обращении) передается Response, который представляет собой контрольную (обычно MD5) сумму от комбинации логина, пароля, запрашиваемого URL, метода HTTP и строки nonce, генерируемой сервером при ответе. Все параметры, кроме последнего, теоретически можно попробовать либо угадать, либо подобрать, поэтому от алгоритма генерирования nonce во многом зависит уникальность всей комбинации. Хотя здесь также возможны варианты. Например, включение в nonce метки времени позволяет не только сделать ее уникальной, но и контролировать время отклика, использование клиентского IP-адреса, откуда идут запросы, добавив счетчик соединений и контролировать количество запросов, сделанных конкретным клиентом. К сожалению, современные веб-серверы и браузеры пока еще не полностью поддерживают все спецификации и рекомендации. Поэтому если информация действительно имеет ценность, то многие вопросы можно решить, применив в защищаемой области протокол SSL.

Это взгляд со стороны сети. Администрирование при использовании как  basic, так и digest-методов можно назвать простым, но только в случае когда количество пользователей или защищаемых ресурсов относительно мало. Для ограничения доступа достаточно поместить в нужный каталог файл .htaccess и создать файл с паролями при помощи htpasswd или htdigest. Если же каталогов много, лучше все описания собрать в одном месте, т.е. файле конфигурации веб-сервера.

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

Знакомство с системой DACS

Система веб-аутентификации и управления доступом DACS (Distributed Access Control System) представляет собой набор программ, позволяющих ограничить доступ пользователей к любому ресурсу популярного веб-сервера Apache. Начало разработок датировано маем 2001 года. Дизайном, внедрением и поддержкой занимается небольшая канадская фирма-разработчик DSS (Distributed System Software) при содействии Metalogic Software Corp. В настоящее время DACS является ключевым компонентом канадской государственной информационной системы (National Forest Information System, NFIS).

Последние версии DACS распространяются под двойными лицензионными условиями: свободной и коммерческой. Если вы распространяете продукт, базирующийся на DACS, он должен быть Open Source, иначе вы должны приобрести коммерческую лицензию. Но если DACS просто используется в работе, без распространения, то коммерческая лицензия не нужна. Но хотя DACS и может распространяться под Open Source-лицензией, проект таковым не является. За все разработки отвечает только небольшая группа, хотя исправления от пользователей принимаются.

Первоначальная задача, на решение которой был ориентирован DACS, – это упрощение использования и администрирования совместных веб-ресурсов с сохранением максимальной безопасности. Используемая в DACS система аутентификации и авторизации позволяет очень точно установить параметры доступа и отслеживать взаимодействие пользователей с сервером. Конструктивно DACS состоит из модуля Apache (mod_auth_dacs), через который веб-сервер связывается с DACS, для определения разрешений доступа к ресурсу, блока программ CGI, обеспечивающих веб-сервис DACS, и набора утилит, выполняющих административные и вспомогательные функции. Пользователи в системе DACS представлены тождествами (identity). При получении доступа к защищенной области он должен сначала идентифицировать и удостоверить себя DACS. Обычно для этого применяется пара логин и пароль, но может быть использован цифровой сертификат или оба этих метода одновременно. Здесь пока ничего не обычного. Отличие заключается в том, что система доступа DACS осуществлена при помощи ролевой модели RBAC (role-based access control). Поэтому здесь логин не равен identity, пользователь может быть ассоциирован сразу с несколькими identity, и, наоборот, identity может описывать не только логин и системное имя (т.е. фактически имя процесса), но и другие параметры (роль, IP-адрес, группу и пр.). Правила контроля доступа, задаваемые администратором, позволяют точно указать кто, что и при каких условиях будет использовать ресурс. Поддерживается и анонимный, т.е. неавторизированный доступ к ресурсу.