Статья двугодичной давности напечатанная в журнале Системный Администратор, кое что изменилось, но основы остались прежними.

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

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

В протоколе HTTP предусмотрено два типа аутентификации: basic и digest, которые определены в RFC 2617. Остановлюсь лишь их на недостатках. Для базовой аутентификации самым главным недостатком является передача пароля в открытом виде. И кроме того веб-браузер запоминает эту информацию и передает ее серверу при каждом обращении, а если не очистить кеш браузера, то возможно получить доступ к серверу без ввода пароля даже через неделю, месяц. Самое главное, что у злоумышленника всегда будет возможность перехватить логин и пароль и получить доступ ко всей охраняемой области. Не защищена 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 используется в работе, без распространения, то коммерческая лицензия не нужна. Если же вы распространяете продукт, базирующийся на DACS он должен быть Open Source, иначе вы должны приобрести коммерческую лицензию. Но хотя 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-адрес, группу и пр.). Об этом более подробно рассказано ниже. Правила контроля доступа задаваемые администратором позволяют точно указать кто, что и при каких условиях будет использовать ресурс. Поддерживается и анонимный, т.е. неавторизированный доступ к ресурсу.

Сredentials

Пользователю успешно прошедшему процедуру аутентификации предоставляется криптографически защищенное удостоверение (credentials), которое является неким аналогом билета (tiket) используемого в системе Kerberos. Такое удостоверение в дальнейшем подтверждает полномочия пользователя. Внутри удостоверения может содержаться имя пользователя, роль, IP-адрес с которого пользователь зарегистрировался и куда был отправлен credentials, и время жизни. Пароль как видите, не входит в состав удостоверения. При такой схеме использование пароля внутри credentials не является необходимым. Для максимального удобства и лучшего взаимодействия credentials обычно возвращается пользователю в виде cookie, который по умолчанию использует спецификации Netscape, но при необходимости синтаксис можно изменить в конфигурационном файле специальной директивой COOKIE_SYNTAX. Передача credentials всегда происходит через SSL, что затрудняет его перехват и повторное использование. Куки являются основным и рекомендуемым способом, хотя в принципе могут быть использованы и дополнительные расширения HTTP, например описанные в RFC 2617 посредством WWW-Authenticate, либо применены другие методы безопасной передачи (VPN). При этом в состав DACS входят утилиты, позволяющие самому создавать credentials, или получать их с веб-сервера для использования другими (возможно не веб-утилитами) приложениями. Учитывая, что credentials являются основой работы DACS, отношение к их безопасности самое серьезное. Так, например, кроме шифрования самой куки, отдельно контролируется отсутствие модификации при помощи хеша, где могут использоваться различные алгоритмы HMAC (Keyed-Hash Message Authentication Code), 160-бит NIST, SHA-1 или MD5. Ключ применяется отличный от используемого при шифровании самого удостоверения. Также кеш-каталог в котором лежит текущий credentials должен обязательно принадлежать тому же пользователю на чье имя выписано удостоверение. И только он должен иметь доступ в используемый каталог. Если это не так, во избежание попытки использования credentials посторонним, он должен быть отвергнут. Аналогичная ситуация и при попытке отправить credentials созданный для другого IP-адреса, при соответствующих настройках, сервер его отвергнет и запросит повторную аутентификацию, и в том случае когда она пройдет успешно создаст новый credentials с новыми параметрами. Хотя такой метод защиты естественно не подходит для тех случаев, когда адрес может изменяться (например, при модемном соединении) или пользователь находится за NAT. Запрещено также использовать одному identity несколько действительных credentials, такая ситуация вызовет ошибку. И как уже говорилось, все credentials могут иметь ограниченное время жизни. По умолчанию оно не установлено, и администратору следует его подобрать и выставить самостоятельно, исходя из требований безопасность/удобство. Если максимальное время жизни не установлено, то в любом случае все credentials будут уничтожены, только после того как пользователь закроет окно браузера или нажмет на кнопку выхода. Если аутентификация закончилась не удачно, могут быть использованы различные обработчики. Поэтому DACS можно использовать для реакции на любые аварийные ситуации, например, перенаправляя незарегистрированных пользователей на страницу с лицензионным соглашением.

Юрисдикции и федерации

Дальнейший разговор будет бесполезен, если не рассказать еще о двух центральных структурах в системе DACS. Для удобства управления доступом к ресурсам, DACS различает два понятия: юрисдикция (jurisdiction) и федерация (federation). Юрисдикция является минимальной автономной областью, которая представляет веб-услуги и полностью отвечает за аутентификацию своих пользователей и за доступ к своим ресурсам. Территориально это может быть как веб-сервер целиком, так и его часть. Федерация является следующей ступенью и включает в себя одну (хотя если быть точнее, то две, так как понятие федерации в этом случае бессмысленно) или несколько юрисдикций. Все юрисдикции, принадлежащие одной федерации должны иметь уникальное имя. В пределах федерации все юрисдикции соглашаются соблюдать определенные правила, позволяющие сохранить безопасность и одновременно повысить удобство использования всей системой.

В федерации используется единый для всех 128 битный (по умолчанию) симметричный AES ключ, а все юрисдикции обмениваются информацией позволяющей дешифровать, зашифровывать и контролировать целостность полученных credentials. Для пользователя (identity) это означает, что один раз подтвердив свои полномочия в юрисдикции, он может при наличии соответствующих разрешений без повторной регистрации получить доступ к ресурсу находящемуся в другой юрисдикции одной федерации. Таким образом, DACS поддерживает режим однократной регистрации (SSO – single sign-on). Для администраторов упрощается поддержка сервиса, так как теперь он может следить за распределением ролей только в своей юрисдикции. Общее количество пользователей будет меньше, так как не надо заводить дополнительные акаунты на других серверах. Администратор доверенного сервера теперь будет решать разрешать или запрещать доступ к своим ресурсам для определенных ролей, не вникая в подробности. Но это еще не все начиная с версии 1.4.11 (март 2006) появился новый сервис dacs_auth_transfer, позволяющий передавать credentials не только между федерациями, но и другими, в том числе не-DACS системами умеющими оперировать identity. В терминологии DACS такие федерации называются присоединенными (affiliated) федерациями (хотя фактически передача происходит между юрисдикциями). При этом передача не обязательно должна быть взаимной т.е. можно свободно переходить из федерации А в Б, а наоборот необязательно. При передаче credentials конвертируется в новую форму, которая будет признана другой стороной, но оригинальные удостоверения у пользователя остаются и не изменяются. При возвращении пользователя в родную федерацию ему опять выдается credentials, но если выданный ранее еще не закончил своего действия, то он считается более сильным, поэтому новый признается недействительным. Передача естественно происходит при помощи SSL, тождество сервера проверяется при помощи сертификатов и IP-адреса. Так как имя пользователя содержит и название федерации, то при переходе в другую федерацию оно по-прежнему остается уникальным.

Имена.

Поскольку пользователь может свободно перемещаться между федерациями и юрисдикциями без повторной аутентификации, имя играет большую роль в системе DACS. Кроме того, имя используется и для совместимостями с различными методами аутентификации. Поэтому в DACS принято несколько вариантов присваивания имени. Имя текущей федерации описывается в конфигурационном файле dacs.conf в переменной FEDERATION_NAME. При работе формат такой.

federation-name::

Имя юрисдикции задается при помощи JURISDICTION_NAME, но в правилах оно состоит из имени федерации, к которой она принадлежит и имени юрисдикции.

federation-name::jurisdiction-name:

Хотя для текущей федерации или отсутствии федераций ее имя может опускаться.

::jurisdiction-name:

Добавив третий компонент, получим имя пользователя.

federation-name::jurisdiction-name:username

Все имена чувствительны к регистру (если это не переопределено специальными директивами). Для удобства федерации и юрисдикции пишутся заглавными буквами, а пользователи маленькими. Например, в credentials имя заносится в таком виде.

HOME::SALES:boss

А можно и так.

::SALES:boss

SALES:boss

:boss

В имени не должны встречаться знаки * , : + ( ) ~ < > = | \ / и «. Все остальные разрешены. Длина имен не ограничена, здесь просто стоит подходить к процессу творчески, чтобы при большом количестве юрисдикций и федераций, можно было понять, о ком речь. Имя пользователя при запросах передается как переменная DACS_USERNAME.

Но это в credentials. В правила в параметр user могут быть занесены группы, IP-адреса, сети и под сети. Имена группы образуются аналогично пользовательским, только на первом месте должен стоять знак процента %.

%HOME::SALES:friends

%::SALES:friends

%SALES:friends

%:friends

Понятие группы в контексте DACS имеет двойное значение. С одной стороны это списки пользователей в обычном понимании, с другой стороны здесь могут быть указаны роли, под которыми здесь понимают информацию о членстве конкретного пользователя в группах. В юрисдикции можно определить любое количество групп, на которые можно ссылаться в группах и правилах в других юрисдикциях. То есть когда DACS нужно решить к какой группе принадлежит сделавший запрос пользователь система обращается локальным группам, роли соответствующей пользователю, и к группам, определенными другими юрисдикциями.

Например, такие пользователи в правилах будут легитимными.

user name=»SALES:boss»

user name=»%SALES:admin»

user name=»10.0.0.118″

user name=»192.168.0.0/24″

user name=»home.com»

user name=»HOME:»

user name=»auth»

user name=»unauth»

Последние два правила описывают соответственно авторизированного и неавторизованного пользователей. Обратите внимание, что такие правила не равнозначны.

user name=»auth»

user name=»HOME:auth»

Первое, соответствует всем успешно зарегистрировавшимся пользователям, второе только принадлежащим к юрисдикции HOME.

Если использовать пользователя «any», то запрос о соответствии имени в проверяемом правиле всегда будет возвращать true. Также поддерживаются и некоторые операции. Например, такой конструкцией можно выделить всех пользователей admin любой юрисдикции.

user name=»*:admin»

Или всем кроме пользователя sergej.

user(«not *:sergej»)

Можно задавать и более разветвленные конструкции, список всех поддерживаемых операторов найдете в документации. Например, для всех не sergej и неавторизованных список будет выглядеть так.

user(«not *:sergej and noauth»)

При создании более сложных конструкций можно создавать списки пользователей (user_list).

Правила контроля доступа.

Компонентом отвечающим за получение решений о доступе, является сервис контроля доступа DACS (access control service – ACS). Реализован при помощи программы dacs_acs. После успешной авторизации пользователя ACS производит поиск правил соответствующих его тождеству. Здесь может быть применено несколько вариантов правил.

Иногда администратору нужно быстро произвести какое то действие не обращаясь к правилам. Чаще всего необходимость такая возникает во временном отключении пользователя или целого участка сети. Для этих целей в DACS применяется т.н. revocation list. Такой список состоит из линий, в каждой описан пользователь (все правила указанные выше естественно и здесь соблюдаются) и действие. Действия предусмотрено всего два: deny и revoke. Первое означает запрет доступа и окончание дальнейшей обработки revocation list. Второе, игнорирует полученное удостоверение, делая пользователя фактически неавторизованным, обработка списка при этом продолжается. Например.

Запрет доступа не аутентифицированных пользователей

deny user(«unauth»)

Сброс всех удостоверений

revoke user(«any»)

Запрет доступа на выходные

deny time(«wday») eq 6 or time(«wday») eq 0

Сброс всех удостоверений кроме полученных из внутренней сети, т.е пользователь из внешней всегда будет анонимным

revoke not from(«192.168.1.0/24″)

После того как будет обработан revocation list, модуль далее ведет просмотр правил контроля доступа. Типичное правило состоит из двух частей: services и rule и должно быть интуитивно понятно.

<acl_rule>

<services>

<service url_pattern=»/cgi-bin/*»/>

</services>

<rule order=»allow,deny»>

<allow>

user(«auth»)

</allow>

</rule>

</acl_rule>

Кроме того, DACS предоставляет возможность делегировать права на определенный ресурс другому пользователю. Выглядит это так.

<delegate url_pattern=»/cgi-bin/myprog» rule_uri=»my_acls»/>

Возможности по аутентификации

Управление аутентификацией пользователя является еще одной из сильных сторон системы безопасности DACS. Непосредственно за аутентификацию отвечает юрисдикция, которой принадлежит пользователь, и который естественно должен быть ей известен. При этом способ аутентификации используемый в разных юрисдикциях в пределах федерации не обязательно должен совпадать. Администратор сам волен, выбирать наиболее подходящий способ или их комбинацию, исходя из конкретных условий. При этом DACS уже имеет встроенные модули аутентификации, но при необходимости можно использовать и имеющие в веб-сервере Apache. Для обмена данными между сервисом аутентификации DACS и модулем аутентификации используется XML протокол. Модуль аутентификации сообщает DACS об успешной аутентификации и имени пользователя (через переменную REMOTE_USER), пользователь Apache при этом автоматически преобразуется в пользователя DACS. DACS расширяет стандартные возможности по аутентификации Apache. Так DACS может удостоверить пользователя, используя несколько методов:

- сертификат X.509 (через SSL)

- паролей Unix или Apache (созданных утилитами htpasswd, htdbm или htdigest)

- Windows NT LAN Manager (NTLM)

- Microsoft Active Directory или LDAP

- системы Pluggable Authentication Modules (PAM)

- собственной базы логинов и паролей

- тождества установленного любым модулем аутентификации Apache

- внешней программы

- комбинируя стили

Basic и Digest аутентификация может обрабатываться непосредственно DACS, для генерирования credentials используется команда autologin, которая позволяет DACS использовать любой из существующих методов аутентификации Apache при сохранении простоты конфигурации. Кроме того, начиная с версии 1.4.13, DACS поддерживает еще одну систему аутентификации Central Authentication Service (CAS), разрабатываемую проектом JA-SIG [http://www.ja-sig.org/products/cas/index.html]. Кратко сервер CAS позволяет реализовать режим однократной регистрации всем легальным пользователям для доступа к любому ресурсу (веб, почта и пр.), путем реализации режима прокси аутентификации, посредством ticket (эта система сильно напоминает Kerberos). CAS также поддерживает все доступные сегодня варианты аутентификации. Кроме того, как уже говорилось выше, можно создать более тонкое описание параметров доступа к ресурсам, в зависимости от IP-адреса, доменного имени, даты и времени суток, используемого метода аутентификации, расширения файла и прочих параметров. То есть фактически задать персональные параметры для доступа к любому ресурсу. После успешной регистрации на основании данных пользователя (имени, группы, роли и т.д.), могут быть выполнены некоторые действия, например перенаправление на определенную веб-страницу, необходимые для этого параметры сохранены в переменной AUTH_SUCCESS_HANDLER. Все запросы регистрируются в контрольном журнале.

Совместимость и требования.

Актуальной на момент написания статьи является версия 1.4.13а с датой релиза 2 июня 2006 (сегодня 1.4.20, в феврале ожидается выход следующего релиза). Буква «а» появилась в результате небольшого недоразумения, когда после релиза 1.4.13 состоявшегося днем раньше была обнаружена ошибка, при определенных опциях завершающий конфигурирование с ошибкой (Invalid boolean result value). Если DACS используется для веб-аутентификации то для его установки потребуется Apache 2.0.х (желательна последняя версия 2.0.58) и начиная с 1.4.13а уже возможно использование Apache 2.2. Поддержка версии 1.3 уже закончена, как говорят разработчики по причине малой ее актуальности. DACS может быть установлен в принципе на любую Unix платформу, где можно найти работающий компилятор GCC 3.3/3.4. На сайте дается информация, что DACS успешно протестирован с такими дистрибутивами и платформами CentOS (Red Hat Enterprise) Linux (AMD64), Solaris 10 (SunOS 5.10, x86), FreeBSD 5.X и 6.X (i686) и частично испытана с Cygwin. Я собирал систему DACS на ALTLinux 3.0 и Slackware 10.1. На клиентской стороне не требуется установка специфичного программного обеспечения.

Что имеем?

Из всего сказанного можно сделать вывод, о том что система DACS обладает достаточно мощными возможностями при достаточной гибкости в настройках. Правда для администратора это означает, что придется провести не один час за первоначальной настройкой всей системы. Имеет смысл использовать DACS в том случае, когда необходимо организовать доступ пользователей к нескольким серверам. Затраты на установку и настройку затем с лихвой окупятся простотой сопровождения. Также вероятно имеет смысл использовать DACS, для того чтобы унифицировать различные схемы аутентификации. Проект предоставляет большое количество документации, которая, по моему мнению, несколько запутана, хотя вероятно это связано с наличием многочисленных понятий и вариантов настроек. В документе «DACS Quick Start Tutorial» сказано, что тестовую конфигурацию можно собрать всего за 30 минут. Так ли это? Проверим в следующий раз. Успехов.

Ссылки

1. Сайт DSS – http://www.dss.ca/

2. Сайт National Forest Information System – http://www.nfis.org/

3. Сайт проекта CAS – http://www.ja-sig.org/products/cas/index.html