Аутентификация и авторизация

Аутентификация — это любой процесс, позволяющий проверить, что человек действительно тот, за кого себя выдаёт. Авторизация — это любой процесс, позволяющий человеку попасть туда, куда он хочет, или получить нужную ему информацию.

Общие сведения об управлении доступом см. в руководстве по управлению доступом.

Связанные модули и директивы

В процессе аутентификации и авторизации задействованы три типа модулей. Обычно необходимо выбрать как минимум один модуль из каждой группы.

• Тип аутентификации (см. директиву AuthType)
  • mod_auth_basic
  • mod_auth_digest
• Поставщик аутентификации (см. директивы AuthBasicProvider и AuthDigestProvider)
  • mod_authn_anon
  • mod_authn_dbd
  • mod_authn_dbm
  • mod_authn_file
  • mod_authnz_ldap
  • mod_authn_socache
• Авторизация (см. директиву Require)
  • mod_authnz_ldap
  • mod_authz_dbd
  • mod_authz_dbm
  • mod_authz_groupfile
  • mod_authz_host
  • mod_authz_owner
  • mod_authz_user

Помимо этих модулей, существуют также mod_authn_core и mod_authz_core. Эти модули реализуют основные директивы, необходимые всем модулям аутентификации.

Модуль mod_authnz_ldap является одновременно поставщиком аутентификации и авторизации. Модуль mod_authz_host предоставляет авторизацию и управление доступом на основе имени хоста, IP-адреса или характеристик запроса, но не относится к системе поставщиков аутентификации. Для обратной совместимости с mod_access создан новый модуль mod_access_compat.

Возможно, вам также будет полезно руководство по управлению доступом, в котором рассматриваются различные способы управления доступом к серверу.

Введение

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

В этой статье описан «стандартный» способ защиты частей веб-сайта, который подойдёт большинству пользователей.

Необходимые условия

Обсуждаемые в этой статье директивы нужно размещать либо в основном файле конфигурации сервера (обычно внутри секции <Directory>), либо в файлах конфигурации для отдельных каталогов (файлах .htaccess).

Если вы планируете использовать файлы .htaccess, конфигурация сервера должна разрешать размещение директив аутентификации в этих файлах. Это задаётся директивой AllowOverride, которая указывает, какие директивы, если таковые имеются, можно размещать в файлах конфигурации для отдельных каталогов.

Поскольку речь идёт об аутентификации, вам понадобится директива AllowOverride, например:

AllowOverride AuthConfig

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

Кроме того, вам нужно иметь некоторое представление о структуре каталогов сервера, чтобы знать, где находятся те или иные файлы. Это не должно вызвать особых затруднений; я постараюсь пояснить всё, когда мы дойдём до этого.

Также убедитесь, что модули mod_authn_core и mod_authz_core либо встроены в исполняемый файл httpd, либо загружены файлом конфигурации httpd.conf. Оба модуля предоставляют основные директивы и функциональность, необходимые для настройки и использования аутентификации и авторизации на веб-сервере.

Настройка

Вот основные шаги для защиты каталога на сервере паролем.

Сначала нужно создать файл паролей. Точный способ зависит от выбранного поставщика аутентификации. Об этом мы поговорим позже. Для начала воспользуемся текстовым файлом паролей.

Этот файл следует разместить в недоступном из Интернета месте, чтобы его нельзя было скачать. Например, если документы размещены в /usr/local/apache/htdocs, файл или файлы паролей можно поместить в /usr/local/apache/passwd.

Для создания файла воспользуйтесь утилитой htpasswd, входящей в состав Apache. Она находится в каталоге bin того места, куда установлен Apache. Если вы установили Apache из стороннего пакета, утилита может быть доступна в пути поиска исполняемых файлов.

Чтобы создать файл, выполните команду:

htpasswd -c /usr/local/apache/passwd/passwords rbowen

Утилита htpasswd запросит пароль, а затем попросит ввести его ещё раз для подтверждения:

# htpasswd -c /usr/local/apache/passwd/passwords rbowen
New password: mypassword
Re-type new password: mypassword
Adding password for user rbowen

Если htpasswd отсутствует в пути поиска, для запуска утилиты, разумеется, потребуется указать полный путь к файлу. При установке по умолчанию он находится в /usr/local/apache2/bin/htpasswd

Затем нужно настроить сервер так, чтобы он запрашивал пароль, и указать, каким пользователям разрешён доступ. Для этого можно отредактировать файл httpd.conf или воспользоваться файлом .htaccess. Например, если нужно защитить каталог /usr/local/apache/htdocs/secret, можно использовать следующие директивы, разместив их либо в файле /usr/local/apache/htdocs/secret/.htaccess, либо в httpd.conf внутри секции <Directory "/usr/local/apache/htdocs/secret">.

AuthType Basic
AuthName "Restricted Files"
# (Following line optional)
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
Require user rbowen

Рассмотрим каждую из этих директив по отдельности. Директива AuthType задаёт метод аутентификации пользователя. Наиболее распространённый метод — Basic, реализованный модулем mod_auth_basic. Однако важно учитывать, что при базовой аутентификации пароль передаётся от клиента серверу без шифрования. Поэтому этот метод не следует использовать для особо конфиденциальных данных, если он не дополнен mod_ssl. Apache поддерживает ещё один метод аутентификации — AuthType Digest. Он реализован модулем mod_auth_digest и предназначался для повышения безопасности. Сейчас это уже не так, поэтому вместо него следует шифровать соединение с помощью mod_ssl.

Директива AuthName задаёт область, используемую при аутентификации. Область выполняет две основные функции. Во-первых, клиент часто показывает эту информацию пользователю в диалоговом окне ввода пароля. Во-вторых, она используется клиентом для определения пароля, который нужно отправить для данной защищённой области.

Например, после аутентификации в области "Restricted Files" клиент будет автоматически повторно использовать тот же пароль для любой области на том же сервере, которой назначена область "Restricted Files". Таким образом, можно избежать повторного запроса пароля у пользователя, назначив одинаковую область нескольким защищённым областям. Разумеется, в целях безопасности клиент всегда будет повторно запрашивать пароль, если изменится имя хоста сервера.

В данном случае директива AuthBasicProvider необязательна, поскольку file является значением по умолчанию для этой директивы. Её потребуется указать, если для аутентификации используется другой источник, например mod_authn_dbm или mod_authn_dbd.

Директива AuthUserFile задаёт путь к файлу паролей, который мы только что создали с помощью htpasswd. Если пользователей много, поиск в обычном текстовом файле при аутентификации каждого пользователя может быть довольно медленным. Apache также умеет хранить сведения о пользователях в быстрых файлах баз данных. Модуль mod_authn_dbm предоставляет директиву AuthDBMUserFile. Такие файлы можно создавать и изменять с помощью программ dbmmanage и htdbm. Сторонние модули предлагают множество других вариантов аутентификации.

Наконец, директива Require задаёт пользователя, которому разрешён доступ к этой области сервера, и тем самым обеспечивает авторизацию. В следующем разделе мы рассмотрим различные способы использования директивы Require.

Доступ для нескольких пользователей

Приведённые выше директивы разрешают доступ к каталогу только одному человеку (а именно пользователю с именем rbowen). В большинстве случаев доступ нужно предоставить нескольким пользователям. Для этого используется директива AuthGroupFile.

Чтобы разрешить доступ нескольким пользователям, нужно создать файл групп, связывающий имена групп со списками входящих в них пользователей. Формат этого файла довольно прост, и его можно создать в любом текстовом редакторе. Содержимое файла будет выглядеть так:

GroupName: rbowen dpitts sungo rshersey

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

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

htpasswd /usr/local/apache/passwd/passwords dpitts

Вы получите тот же ответ, что и раньше, но новая запись будет добавлена в существующий файл, а не создан новый. (Именно параметр -c приводит к созданию нового файла паролей.)

Теперь нужно изменить файл .htaccess или блок <Directory>, чтобы он выглядел так:

AuthType Basic
AuthName "By Invitation Only"
# Optional line:
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
AuthGroupFile "/usr/local/apache/passwd/groups"
Require group GroupName

Теперь доступ будет разрешён всем пользователям, перечисленным в группе GroupName и имеющим запись в файле password, если они введут правильный пароль.

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

Require valid-user

Использование этой директивы вместо строки Require user rbowen разрешит доступ всем пользователям, указанным в файле паролей и правильно введшим свой пароль.

Возможные проблемы

Из-за особенностей спецификации базовой аутентификации имя пользователя и пароль проверяются при каждом запросе документа с сервера. Это происходит, даже если вы повторно загружаете ту же страницу, а также для каждого изображения на странице (если оно находится в защищённом каталоге). Как можно догадаться, это несколько замедляет работу. Степень замедления пропорциональна размеру файла паролей: серверу приходится открывать файл и перебирать список пользователей, пока он не найдёт ваше имя. Это повторяется при каждой загрузке страницы.

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

Другие способы хранения паролей

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

Модули mod_authn_dbm и mod_authn_dbd позволяют это сделать. Вместо выбора AuthBasicProvider file можно выбрать dbm или dbd в качестве формата хранения.

Например, чтобы выбрать файл dbm вместо текстового файла:

<Directory "/www/docs/private">
    AuthName "Private"
    AuthType Basic
    AuthBasicProvider dbm
    AuthDBMUserFile "/www/passwords/passwd.dbm"
    Require valid-user
</Directory>

Доступны и другие варианты. Подробности см. в документации mod_authn_dbm.

Использование нескольких поставщиков

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

<Directory "/www/docs/private">
    AuthName "Private"
    AuthType Basic
    AuthBasicProvider file ldap
    AuthUserFile "/usr/local/apache/passwd/passwords"
    AuthLDAPURL ldap://ldaphost/o=yourorg
    Require valid-user
</Directory>

В этом примере сначала поставщик на основе файла попытается аутентифицировать пользователя. Если ему это не удастся, будет вызван поставщик LDAP. Это позволяет расширить область действия аутентификации, если в организации используется несколько типов хранилищ данных аутентификации. Другие сценарии аутентификации и авторизации могут включать сочетание одного типа аутентификации с другим типом авторизации. Например, аутентификацию по файлу паролей и авторизацию по каталогу LDAP.

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

<Directory "/www/docs/private">
    AuthName "Private"
    AuthType Basic
    AuthBasicProvider file
    AuthUserFile "/usr/local/apache/passwd/passwords"
    AuthLDAPURL ldap://ldaphost/o=yourorg
    AuthGroupFile "/usr/local/apache/passwd/groups"
    Require group GroupName
    Require ldap-group cn=mygroup,o=yourorg
</Directory>

Для более гибкой настройки авторизации директивы-контейнеры авторизации, такие как <RequireAll> и <RequireAny>, позволяют задавать логику и полностью контролировать в конфигурации порядок обработки авторизации. Пример их использования см. в разделе Контейнеры авторизации.

Не только авторизация

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

Настройка логики и порядка

Раньше настройка способа и порядка применения авторизации была не вполне понятной. В Apache 2.2 был представлен механизм аутентификации на основе поставщиков, отделяющий сам процесс аутентификации от авторизации и вспомогательных функций. Одним из его дополнительных преимуществ стала возможность настраивать и вызывать поставщиков аутентификации в определённом порядке, не зависящем от порядка загрузки самого модуля аутентификации. Теперь этот механизм на основе поставщиков применяется и к авторизации. Это означает, что директива Require не только указывает, какие методы авторизации следует использовать, но и задаёт порядок их вызова. Несколько методов авторизации вызываются в том же порядке, в котором директивы Require указаны в конфигурации.

С появлением директив-контейнеров авторизации, таких как <RequireAll> и <RequireAny>, в конфигурации также можно задавать, когда вызываются методы авторизации и какие условия определяют предоставление доступа. Пример использования этих директив для задания сложной логики авторизации см. в разделе Контейнеры авторизации.

По умолчанию все директивы Require обрабатываются так, как если бы они находились внутри директивы-контейнера <RequireAny>. Иными словами, авторизация предоставляется, если успешно сработал любой из указанных методов авторизации.

Использование поставщиков авторизации для управления доступом

Аутентификация по имени пользователя и паролю — это лишь часть задачи. Часто требуется предоставлять доступ людям на основании чего-либо, кроме их личности, например места, откуда они подключаются.

Поставщики авторизации all, env, host и ip позволяют разрешать или запрещать доступ на основании других критериев, связанных с хостом, например имени хоста или IP-адреса компьютера, запрашивающего документ.

Использование этих поставщиков задаётся директивой Require. Эта директива регистрирует поставщиков авторизации, которые будут вызываться на этапе авторизации при обработке запроса. Например:

Require ip address
        

где address — это IP-адрес (или часть IP-адреса), либо:

Require host domain_name
        

где domain_name — полное доменное имя (или его часть); при необходимости можно указать несколько адресов или доменных имён.

Например, если кто-то рассылает спам на вашей доске сообщений и вы хотите заблокировать ему доступ, можно сделать следующее:

<RequireAll>
    Require all granted
    Require not ip 10.252.46.165
</RequireAll>

Посетители с этого адреса не смогут просматривать содержимое, на которое распространяется действие этой директивы. Если вместо IP-адреса у вас есть имя компьютера, можно использовать его.

<RequireAll>
    Require all granted
    Require not host host.example.com
</RequireAll>

Чтобы заблокировать доступ из всего домена, можно указать только часть адреса или доменного имени:

<RequireAll>
    Require all granted
    Require not ip 192.168.205
    Require not host phishers.example.com moreidiots.example
    Require not host ke
</RequireAll>

Если использовать <RequireAll> с несколькими директивами <Require>, каждая из которых отрицается с помощью not, доступ будет разрешён только в том случае, если все отрицательные условия выполнены. Иными словами, доступ будет заблокирован, если хотя бы одно из отрицательных условий не выполнено.

Обратная совместимость управления доступом

Одним из следствий перехода к механизму аутентификации на основе поставщиков стало то, что прежние директивы управления доступом Order, Allow, Deny и Satisfy больше не нужны. Однако для обратной совместимости со старыми конфигурациями эти директивы перенесены в модуль mod_access_compat.

Кэширование аутентификации

Иногда аутентификация может создавать чрезмерную нагрузку на поставщика или сеть. Это особенно вероятно для пользователей mod_authn_dbd (а также сторонних и пользовательских поставщиков). Для решения этой проблемы в HTTPD 2.3/2.4 появился новый поставщик кэширования mod_authn_socache, который кэширует учётные данные и снижает нагрузку на исходного поставщика или поставщиков.

Для некоторых пользователей это может значительно повысить производительность.

Дополнительная информация

Также следует прочитать документацию по mod_auth_basic и mod_authz_host, где подробнее описан принцип работы этой системы. Директива <AuthnProviderAlias> также может упростить некоторые конфигурации аутентификации.

Различные шифры, поддерживаемые Apache для данных аутентификации, описаны в разделе Шифрование паролей.

Также вам может быть полезно руководство по управлению доступом, в котором рассматривается ряд связанных тем.