Права доступа к данным в Nginx: аутентификация и контроль

Nginx проверяет HTTP-запрос до передачи его статическому файлу или приложению. Политику доступа задают в блоках server и location с помощью auth_basic, allow, deny, internal и других директив. После этого операционная система Linux отдельно проверяет, может ли пользователь Nginx читать файл или проходить по каталогам.

Для проксируемых ресурсов схема выглядит так: клиент - Nginx - статический файл или proxy_pass - backend. Basic Auth проверяет логин и пароль, IP-фильтр ограничивает сетевой источник, а Unix-права защищают файлы на диске. Для критичных административных ресурсов эти уровни обычно комбинируют. Basic Auth передает учетные данные в кодируемом виде, поэтому доступ нужно публиковать только через HTTPS.

Одна директива не решает все задачи. Правило deny all не защитит приложение, если backend доступен по публичному порту в обход Nginx. Корректный auth_basic не заменит авторизацию внутри приложения. Права Linux не определяют, какой URL увидит пользователь. Надежная политика связывает все три уровня.

Как организовать права доступа к данным в Nginx

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

Контроль доступа к данным удобно разделить на три уровня.

• Nginx. Определяет, какие HTTP-запросы пропускать, какие URL закрывать, требуется ли пароль, разрешен ли IP-адрес и можно ли выдавать файл напрямую.
• Файловая система Linux. Определяет, может ли worker-процесс Nginx читать файл и проходить по родительским каталогам.
• Backend-приложение. Проверяет учетную запись, роль пользователя, токен, область доступа и право на конкретный объект.

Например, для каталога /srv/site/private Nginx может разрешить запрос только после Basic Auth. Но если пользователь Nginx не имеет права чтения каталога, клиент получит ошибку сервера. Обратная ситуация тоже опасна: корректные права Linux не помешают публикации файла через неправильно настроенный location.

Для API Nginx может ограничить доступ по IP и добавить Basic Auth, но окончательное решение о доступе к данным должен принимать backend. Это особенно важно для многопользовательских систем, где один и тот же endpoint возвращает разные документы разным учетным записям.

Какой метод выбрать для задачи

Публичный сайт обычно оставляют открытым, а административные URL выносят в отдельные location. Для внутреннего API полезна связка из приватного upstream, ограничения по IP и собственной авторизации приложения. Для приватных документов подходит схема, где приложение принимает решение, а Nginx выдает файл через X-Accel-Redirect.

Подготовка Nginx и резервной копии конфигурации

Диагностика перед изменением

Сначала получите фактическую конфигурацию, а не только содержимое предполагаемого файла:

sudo nginx -T > /tmp/nginx-config-before.txt

Команда выводит все подключенные файлы и показывает эффективную конфигурацию. По ней проверьте:

• активный server_name и нужный виртуальный хост;
• значения root, alias и фактические пути к данным;
• существующие блоки location и их порядок;
• адреса proxy_pass и определения upstream;
• директивы allow, deny, auth_basic, internal;
• настройки real_ip_header и set_real_ip_from, если перед Nginx стоит балансировщик.

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

Структуру основных блоков конфигурации и готовые примеры для статики, HTTPS и API можно сверить в статье о структуре nginx.conf и практических настройках.

Как сохранить возможность отката

Сделайте копию файла перед редактированием. Путь зависит от дистрибутива и схемы установки, поэтому сначала используйте вывод nginx -T. Пример для отдельного файла конфигурации:

sudo cp /etc/nginx/conf.d/site.conf /etc/nginx/conf.d/site.conf.bak.$(date +%F-%H%M%S)

Меняйте один логический блок за раз. После каждой группы изменений выполняйте:

sudo nginx -t
sudo systemctl reload nginx

Команда nginx -t проверяет синтаксис и доступность подключенных файлов. Она не подтверждает, что запрос попал в правильный location, поэтому после reload нужны реальные HTTP-проверки.

При проблеме верните резервную копию, снова выполните nginx -t, а затем сделайте reload:

sudo cp /etc/nginx/conf.d/site.conf.bak.YYYY-MM-DD-HHMMSS /etc/nginx/conf.d/site.conf
sudo nginx -t
sudo systemctl reload nginx

Для production полезно сначала проверить правила на тестовом виртуальном хосте или отдельном сервере. Файл с паролями, приватные каталоги и резервные копии не размещайте внутри web-root.

Nginx: базовая HTTP-аутентификация для директорий и endpoint

Создание файла пользователей htpasswd

Nginx читает файл пользователей в формате htpasswd. В Debian и Ubuntu нужная утилита обычно входит в пакет apache2-utils:

sudo apt update
sudo apt install apache2-utils

В RHEL-подобных системах используется пакет httpd-tools:

sudo dnf install httpd-tools

Создайте каталог для служебных секретов и первого пользователя:

sudo install -d -m 0750 /etc/nginx/auth
sudo htpasswd -c /etc/nginx/auth/.users admin

Команда запросит пароль интерактивно и сохранит хеш, а не открытый пароль. Для добавления следующего пользователя параметр -c не используйте:

sudo htpasswd /etc/nginx/auth/.users operator

Проверьте владельца и режим файла. Worker Nginx должен иметь право чтения, но файл не должен быть доступен всем пользователям системы:

sudo chown root:nginx /etc/nginx/auth/.users
sudo chmod 0640 /etc/nginx/auth/.users

В Debian имя группы часто отличается, например www-data. Уточните пользователя и группу в конфигурации директивой user или командой:

grep -R '^[[:space:]]*user[[:space:]]' /etc/nginx/nginx.conf

Файл с учетными данными храните вне каталогов, которые раздает root или alias. Подключение дополнительных модулей может потребоваться для отдельных механизмов контроля, поэтому состав сборки проверяйте в полном конфиге и пакете вашей ОС. Сведения об архитектуре модулей Nginx собраны в руководстве по модулям Nginx.

Защита конкретной директории через location

Для закрытия административного пути добавьте отдельный блок в нужный server:

server {
    server_name example.com;
    root /srv/www/site;

    location ^~ /admin/ {
        auth_basic "Restricted area";
        auth_basic_user_file /etc/nginx/auth/.users;
        try_files $uri $uri/ =404;
    }
}

В этом шаблоне example.com и /srv/www/site нужно заменить на реальные значения. Префикс ^~ /admin/ подходит для раздела с вложенными URL. Если нужно защитить ровно один endpoint, используйте точное сопоставление:

location = /admin/status {
    auth_basic "Restricted endpoint";
    auth_basic_user_file /etc/nginx/auth/.users;
    try_files $uri =404;
}

Правила location сопоставляются по определенному алгоритму. Точный блок с = имеет приоритет, префиксный блок с ^~ влияет на дальнейший поиск регулярных выражений, а вложенные и регулярные блоки могут изменить ожидаемое поведение. Проверяйте итог через nginx -T, особенно если в конфигурации есть общие регулярные location.

Аутентификацию можно отключить для отдельного вложенного пути:

location ^~ /admin/ {
    auth_basic "Restricted area";
    auth_basic_user_file /etc/nginx/auth/.users;

    location = /admin/health {
        auth_basic off;
    }
}

Отключать проверку следует только для endpoint, который не раскрывает чувствительные данные. Заголовок WWW-Authenticate в ответе без учетных данных подтверждает, что сервер применил Basic Auth.

Аутентификация проксируемого ресурса

Basic Auth размещают в том же location, где находится proxy_pass:

upstream private_app {
    server 127.0.0.1:8080;
}

server {
    server_name example.com;

    location ^~ /admin-api/ {
        auth_basic "Private API";
        auth_basic_user_file /etc/nginx/auth/.users;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://private_app/;
    }
}

Такой блок защищает запрос до передачи его backend. Приложение при этом может иметь собственную проверку токена или роли. Если upstream должен быть доступен только через Nginx, слушайте loopback или внутренний интерфейс, а публичный firewall-порт закройте.

Nginx: ограничение доступа по IP

Разрешение одного IP и подсети

Директивы allow и deny применяют к клиентскому адресу, который Nginx считает реальным. Минимальный шаблон для одного IPv4-адреса:

location ^~ /private/ {
    allow 203.0.113.10;
    deny all;
}

Адрес 203.0.113.10 относится к документальному диапазону. Замените его адресом VPN, офиса или другого доверенного узла. Для подсети укажите CIDR:

location ^~ /internal-api/ {
    allow 192.0.2.0/24;
    allow 2001:db8:1234::/48;
    deny all;
}

В примере использованы документальные IPv4- и IPv6-диапазоны. В production подставьте реальные сети и проверьте, что политика охватывает оба протокола. Если разрешить только IPv4, пользователь с IPv6 может получить неожиданный отказ или обойти ожидаемую схему при неверной настройке DNS и firewall.

Порядок правил влияет на результат: Nginx проверяет правила последовательно до первого совпадения. Поэтому разрешения размещают перед финальным deny all.

Защита админки по IP

Панель управления можно закрыть для всех источников, кроме VPN-подсети, а затем добавить пароль:

location ^~ /admin/ {
    allow 192.0.2.0/24;
    deny all;

    auth_basic "VPN admin area";
    auth_basic_user_file /etc/nginx/auth/.users;

    try_files $uri $uri/ =404;
}

Клиент из запрещенной сети должен получить 403 Forbidden. Клиент из разрешенной сети без учетных данных получит 401 Unauthorized. После ввода правильного логина и пароля запрос пройдет к ресурсу.

Ограничение по IP удобно для стабильного офиса или VPN. При динамических адресах лучше использовать постоянную VPN-подсеть, защищенную админку через identity-aware proxy или собственную систему авторизации приложения. Не добавляйте в allow широкие публичные диапазоны без ясной причины.

Реальный IP клиента за балансировщиком

Если перед Nginx стоит балансировщик или reverse proxy, переменная $remote_addr может содержать адрес этого прокси. Тогда IP-фильтр будет проверять не пользователя, а промежуточный узел.

Пример настройки для доверенного прокси:

set_real_ip_from 198.51.100.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

198.51.100.10 здесь служит шаблоном для адреса доверенного прокси. Директиву set_real_ip_from ограничьте конкретными адресами или сетями своего контура. Нельзя безусловно доверять X-Forwarded-For, если любой клиент может отправить этот заголовок напрямую.

После изменения проверьте access log. В нем должны фиксироваться ожидаемые адреса клиентов, а не только IP балансировщика. Если фильтр внезапно блокирует всех пользователей, временно верните исходную настройку через rollback и проверьте цепочку прокси.

Защита файлов, директорий и конфиденциальных данных

Запрет служебных файлов и скрытых директорий

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

Базовый шаблон блокирует скрытые файлы и каталоги:

location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

Отдельно закройте резервные копии, временные файлы и конфигурации:

location ~* \.(env|ini|conf|config|bak|backup|old|orig|swp|sql|log)$ {
    deny all;
}

location ~* /(\.git|\.svn|vendor|node_modules)(/|$) {
    deny all;
}

Регулярные выражения должны соответствовать реальной структуре сайта. Слишком широкое правило может заблокировать рабочие ресурсы, а слишком узкое пропустит файл с другим расширением. После настройки проверьте URL для .env, каталога .git, резервной копии и лога.

Не включайте автоматическую выдачу неизвестных файлов через универсальный location. Для публичного контента задавайте понятные root и alias, а приватные данные храните в отдельном каталоге.

Права Linux для файлов и каталогов

Сначала выясните, под каким пользователем работают worker-процессы Nginx. В Debian часто используется www-data, в RHEL-подобных системах встречается nginx:

ps -eo user,group,comm | grep '[n]ginx'
namei -l /srv/www/site/private/report.pdf

Для чтения файла процессу нужны:

• право r на сам файл;
• право x на каждый родительский каталог;
• подходящий владелец или членство в группе, если используются групповые права.

Проверка от имени пользователя Nginx зависит от дистрибутива:

sudo -u nginx test -r /srv/www/site/private/report.pdf && echo readable
sudo -u www-data test -r /srv/www/site/private/report.pdf && echo readable

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

Проверьте весь путь через namei -l. Ошибка может находиться не в файле, а в одном из каталогов выше. Настройка root объединяет путь каталога с URI, а alias заменяет совпавшую часть URI. Неверный завершающий слеш в alias часто приводит к неожиданному пути.

Отключение листинга директорий

Листинг каталога не должен раскрывать структуру файлов, если для этого нет отдельной задачи:

server {
    root /srv/www/site;
    autoindex off;
}

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

Для защищенной выдачи файлов используйте internal. Запрос клиента к такому location получает отказ, а приложение может обратиться к нему через заголовок X-Accel-Redirect. Это позволяет вынести документы за пределы публичного маршрута.

Контроль доступа к проксируемым ресурсам

Публичный сайт и закрытый административный endpoint

Публичные страницы и административный API разделяйте разными блоками:

upstream app_backend {
    server 127.0.0.1:8080;
}

server {
    server_name example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://app_backend;
    }

    location ^~ /admin-api/ {
        allow 192.0.2.0/24;
        deny all;

        auth_basic "Private administration API";
        auth_basic_user_file /etc/nginx/auth/.users;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://app_backend;
    }
}

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

Как не открыть backend в обход Nginx

Ограничения Nginx действуют только для трафика, который проходит через Nginx. Проверьте, на каком интерфейсе слушает backend:

ss -lntp | grep ':8080'

Для сервиса на том же сервере используйте loopback:

127.0.0.1:8080

Для нескольких узлов привяжите приложение к внутреннему адресу и разрешите соединения только из приватной сети или от reverse proxy. Проверьте security groups, host firewall и публикацию Docker-портов. Запись вида 0.0.0.0:8080 означает прослушивание всех интерфейсов и требует отдельной проверки сетевых правил.

Попробуйте подключиться к backend из внешней сети. Защищенный URL через Nginx и прямой порт приложения должны иметь разные результаты: первый проходит предусмотренную политику, второй недоступен извне.

Передача клиентского контекста в приложение

Backend обычно получает исходную схему, host и адрес клиента через заголовки:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Приложение должно доверять этим заголовкам только от известного прокси-контура. Если backend доступен напрямую, клиент сможет подделать контекст и повлиять на логирование, редиректы или прикладную политику. Согласуйте с разработчиками список доверенных proxy и правила обработки цепочки X-Forwarded-For.

Для сложной маршрутизации и разделения публичных и внутренних endpoint пригодится материал о Nginx как L7-маршрутизаторе.

Проверка результата и диагностика ошибок

Проверка конфигурации перед reload

Минимальный порядок проверки:

1. Сохраните резервную копию изменяемого файла.
2. Проверьте синтаксис командой sudo nginx -t.
3. Сравните нужный server и location с выводом sudo nginx -T.
4. Выполните sudo systemctl reload nginx.
5. Проверьте открытый URL, закрытый URL и прямой адрес backend.

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

Таблица ожидаемых HTTP-ответов

Проверка через curl позволяет отделить поведение браузера от ответа сервера:

curl -I https://example.com/admin/
curl -I -u admin:'пароль' https://example.com/admin/
curl -I https://example.com/.env
curl -I https://example.com/admin-api/

В примерах example.com и пароль нужно заменить на реальные значения. Пароль в командной строке может попасть в историю shell, поэтому для рабочих систем используйте безопасный способ ввода.

Проверка журналов

Сопоставьте время запроса с access log и error log:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

В access log ищите URI, статус, remote_addr и, если включено логирование прокси, upstream_status. По этим полям можно определить, заблокировал ли запрос Nginx или отказал backend.

Временно повысить уровень журнала можно для конкретной диагностики, но после проверки верните обычный уровень. Подробный error log на production увеличивает объем записей и может раскрыть лишние технические сведения.

Типичные ошибки и безопасная эксплуатация

Почему правило не срабатывает

• Изменен файл, который не подключен в активной конфигурации.
• Запрос попадает в другой виртуальный хост из-за несовпадения server_name.
• URI отличается завершающим слешем: /admin и /admin/ могут обрабатываться разными правилами.
• Регулярный location перехватывает запрос после префиксного блока.
• allow проверяет IP балансировщика, а не клиента.
• Правильный URL указывает на другой путь из-за ошибки в root или alias.
• Изменения не применились после reload или reload завершился ошибкой.

Начинайте диагностику с nginx -T, затем проверяйте точный URI и журнал. Не исправляйте проблему добавлением нескольких широких правил сразу, иначе будет сложнее определить реальную причину.

Когда комбинировать IP-фильтр и Basic Auth

Для критичной админ-панели используйте два независимых условия: запрос должен прийти из доверенной сети и содержать правильные учетные данные. IP allowlist снижает число доступных источников, Basic Auth добавляет проверку личности.

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

Basic Auth подходит для закрытия legacy-инструмента или небольшого внутреннего сервиса. Для пользовательских приложений с ролями, аудитом и отзывом сессий используйте авторизацию backend, а Nginx оставьте сетевым барьером и reverse proxy.

Краткий контрольный список

• Сохранена резервная копия конфигурации Nginx.
• Файл htpasswd находится вне web-root и доступен только нужной группе.
• Basic Auth работает только через HTTPS.
• Проверены точные и префиксные location.
• Служебные файлы, .env, .git и резервные копии закрыты.
• autoindex off задан явно там, где каталог не должен раскрываться.
• Пользователь Nginx имеет минимальные права чтения и прохода по каталогам.
• Проверены IPv4 и IPv6.
• Backend не слушает публичный интерфейс без необходимости.
• Проверены nginx -t, reload, запросы через curl и журналы.
• Описаны владельцы политики доступа и дата следующего пересмотра.

Регулярно удаляйте неиспользуемые учетные записи, пересматривайте IP allowlist и меняйте пароли при кадровых или сетевых изменениях. Для production полезно хранить конфигурацию в системе контроля версий без секретов и применять изменения через проверяемый процесс.

Практические сценарии настройки Nginx

Админ-панель только из VPN

Сценарий подходит для панели, которая не должна быть доступна из интернета:

location ^~ /admin/ {
    allow 192.0.2.0/24;
    allow 2001:db8:1234::/48;
    deny all;

    auth_basic "VPN only";
    auth_basic_user_file /etc/nginx/auth/.users;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:8080;
}

Замените сети на адреса VPN, проверьте реальный IP за балансировщиком и закройте порт приложения firewall-правилами. Тестируйте три состояния: запрос из VPN без пароля, запрос из VPN с правильным паролем и запрос из внешней сети.

Приватные документы с выдачей через Nginx

Каталог с документами вынесите за пределы публичного root. Приложение проверяет пользователя и запрашиваемый объект, после чего возвращает Nginx внутренний путь:

location /protected-files/ {
    internal;
    alias /srv/private-documents/;
}

Приложение передает заголовок X-Accel-Redirect: /protected-files/report.pdf. Клиент не может напрямую получить этот ресурс, потому что блок internal принимает только внутренние перенаправления Nginx.

Права Linux должны разрешать worker-процессу чтение /srv/private-documents. Проверьте запрет прямого URL, ответ приложения для пользователя без права и корректную выдачу разрешенного документа. Путь в X-Accel-Redirect не должен формироваться из непроверенного пользовательского ввода.

Внутренний API за proxy_pass

Разделите публичный frontend и служебный API:

upstream internal_api {
    server 127.0.0.1:9000;
}

location ^~ /api/internal/ {
    allow 192.0.2.0/24;
    deny all;

    auth_basic "Internal API";
    auth_basic_user_file /etc/nginx/auth/.users;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://internal_api/;
}

Backend слушает только loopback, а Nginx принимает решение о сетевом источнике и базовой аутентификации. Приложение дополнительно проверяет токен, роль и допустимый метод запроса. Проверьте, что публичный endpoint не проксирует тот же внутренний маршрут без ограничений.

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

Рабочая политика доступа начинается с точного списка ресурсов: публичные страницы, административные endpoint, приватные документы и backend-порты должны иметь разные правила. После этого настройте соответствующий уровень контроля, проверьте эффективную конфигурацию, выполните тестовые запросы и сохраните результаты в журнале изменений.