Частенько в процессе работы в IT возникает задача организовать защищенное быстрое функционирование того или иного веб приложения. У кого-то используются свои самописные приложения. У кого-то это сторонние готовые приложения. Но при этом приложения могут работать без аутентификации, либо при запуске использовать большой объем ОЗУ. Это, как правило, приложения на JAVA, Python и т.д., которые запускаются напрямую без использования веб сервера. В принципе, они конечно могут работать и таким образом. Но, в реальных продакшн условиях, это неэффективно с точки зрения компьютерных ресурсов. А также не секьюрно с точки зрения информационной безопасности. Во всех подобных случаях настоятельно советую использовать Nginx веб сервер как реверс прокси для Вашего приложения.
Основные преимущества такой конфигурации просты и очевидны. Во-первых, основная нагрузка по взаимодействию с клиентами перкладывается на профессиональный веб сервер. Nginx с этим делом справляется просто на УРА с минимальными затратами процессора и памяти. Во-вторых, возможность с легкостью устанавливать пароль для доступа к данному приложению. В организационной рабочей среде, приложение без пароля просто находка для хакера. Ну и в-третьих, быстрая настройка доступа через HTTPS протокол, что обеспечивает безопасность передачи данных по сети. Если у Вас публичный сервис, то Вы также можете настроить сертификат с помощью LetsEncrypt. Если сервис непубличный, то придется использовать свои самоподписанные сертификаты.
Настройка
На примере операционной системы Centos 7 покажем, как установить и настроить Nginx в качестве реверсивного прокси для нашего приложения. При этом наш фронтэнд будет отдавать данные через протокол HTTPS и аутентифицировать пользователей по своей базе.
Для начала произведем установку пакетов nginx & httpd-tools.
|
1 2 3 4 5 |
# yum install epel-release # yum install nginx # yum install httpd-tools # systemctl start nginx # systemctl enable nginx |
После этого создадим файл, в котором будут храниться аутентификационные данные пользователей для доступа к нашему веб серверу. Это делается с помощью следующей команды.
|
1 |
# htpasswd -c /etc/nginx/.htpasswd admin |
В результате этого создастся файл .htpasswd с аутентификационными данными для пользователя admin. При необходимости добавляем в этот файл дополнительных пользователей с паролями. Все это реализуется командой htpasswd.
Теперь создадим самоподписанный SSL сертификат с помощью команды openssl. В случае использования реального публичного сертификата, читаем, как писал выше, статью про LetsEncrypt.
|
1 |
# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt |
После того, как сертификат будет готов, переходим к конфигурационному файлу /etc/nginx/nginx.conf. Отредактируем его следующим образом в части раздела server.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
server { listen 443 default_server; server_name _; ssl_certificate /etc/nginx/cert.crt; ssl_certificate_key /etc/nginx/cert.key; ssl on; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; include /etc/nginx/default.d/*.conf; location / { proxy_pass http://localhost:8080;auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; } } |
В данном конкретном примере мы перенаправляем входящий https трафик на локальный хост 127.0.0.1 по 8080 TCP порту. При этом используем сгенерированный ранее самоподписанный сертификат. А также файл с паролями /etc/nginx/.htpasswd. После настройки конфигурационного файла, производим перезапуск nginx.
|
1 |
systemctl restart nginx |
После проведенных манипуляций, получем веб приложение, которое работает зашифрованным по сети с помощью протокола HTTPS, использует аутентификацию. А также в качестве фронтенда задействует nginx.
Заключение
Статья описывает вопрос, который постоянно возникает в работе любого системного администратора. Nginx в качестве реверс прокси отлично и легко решает данную проблему. Раньше для этого я использовал сервер Apache. Но на текущий момент Nginx своей скоростью работы и имеющимся функционалом значительно опережает Apache. Вообщем, берем вышеописанную технику на вооружение и используем ее при возникающей необходимости.
Ваш комментарий будет первым