С помощью существующего протокола единого входа OpenID Connect 10 страница
6.5. Аутентификация пользователей с помощью существующего протокола единого ... v 81
Обсуждение
|
|
https://tools.ietf.org/html/rfc7517
6.5. Аутентификация пользователей
с помощью существующего протокола единого входа OpenID Connect
Задача
Вам нужно перенести проверку подлинности с помощью OpenID Con- nect в NGINX Plus.
Решение
Используйте модуль JWT, поставляемый с NGINX Plus, для защиты местоположения или сервера и дайте директиве auth_jwt указание ис- пользовать $cookie_auth_token в качестве токена для проверки:
location /private/ {
auth_jwt "Google Oauth" token=$cookie_auth_token; auth_jwt_key_file /etc/nginx/google_certs.jwk;
}
В этой конфигурации мы направляем NGINX Plus для защиты пути
/private/ URI с проверкой JWT. В OpenID Connect используется куки-файл
|
|
|
auth_token, а не токен на предъявителя по умолчанию. Таким образом, вы
должны указать NGINX искать токен в этом куки-файле, а не в располо-
82 v Глава 6. Аутентификация
жении по умолчанию NGINX Plus. Для местоположения auth_jwt_key_file
задан произвольный путь, который мы рассмотрим в рецепте 6.6.
Обсуждение
|
|
|
|
NGINX Plus также может управлять потоком с кодом подтверждения
|
См. также:
https://www.nginx.com/blog/authenticating-users-existing-applications- openid-connect-nginx-plus/
https://openid.net/connect/
6.6. Получение ключа в формате JSON
От Google
Задача
Вам необходимо получить ключ в формате JSON от Google, чтобы использовать его при проверке токенов OpenID Connect с помощью NGINX Plus.
6.6. Получение ключа в формате JSON от Google v 83
Решение
Используйте Cron для запроса нового набора ключей каждый час, чтобы гарантировать, что ключи всегда актуальны:
0 * * * * root wget https://www.googleapis.com/oauth2/v3/ \ certs-O /etc/nginx/google_certs.jwk
|
|
|
|
Обсуждение
Cron – это распространенный способ запуска запланированной за- дачи в Unix-подобной системе. Следует регулярно выполнять ротацию ключей в формате JSON, чтобы обеспечить их безопасность и, в свою очередь, безопасность своей системы. Чтобы у вас всегда был самый актуальный ключ от Google, вам нужно регулярно проверять наличие новых JWK. Cron – один из способов сделать это.
См. также:
 |
https://linux.die.net/man/8/cron
Глава 7
Контроль безопасности
| |
7.0. Введение
|
|
|
|
7.1. Доступ на основе IP-адреса
Задача
Вам необходимо контролировать доступ на основе IP-адреса клиента.
Решение
Используйте модуль доступа по протоколу HTTP для управления до- ступом к защищенным ресурсам:
location /admin/ { deny 10.0.0.1;
7.2. Разрешение совместного использования ресурсов между разными источниками v 85
|
}
Данный блок разрешает доступ с любого адреса IPv4 в 10.0.0.0/20, кро- ме 10.0.0.1, доступ с IPv6-адресов в подсети 2001:0db8::/32 и возвращает ошибку 403 для запросов, исходящих с любого другого адреса. Директи- вы allow и deny действительны в контексте HTTP, сервера и местополо- жения. Правила проверяются последовательно, пока не будет найдено соответствие для удаленного адреса.
Обсуждение
|
7.2. Разрешение совместного использования ресурсов между разными источниками
Задача
Вы обслуживаете ресурсы из другого домена и вам нужно разрешить совместное использование ресурсов между разными источниками (CORS), чтобы браузеры могли использовать эти ресурсы.
Решение
Измените заголовки на основе метода request, чтобы активировать
CORS:
map $request_method $cors_method { OPTIONS 11;
GET 1;
POST 1;
default 0;
86 v Глава 7. Контроль безопасности
}
server {
...
location / {
|
add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
add_header 'Access-Control-Allow-Origin' '*.example.com';
add_header 'Access-Control-Allow-Headers' 'DNT,
Keep-Alive, User-Agent,
X-Requested-With, If-Modified-Since, Cache-Control, Content-Type';
}
if ($cors_method = '11') {
add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=UTF-8'; add_header 'Content-Length' 0;
return 204;
|
}
}
В этом примере происходит много всего, что было сжато при ис- пользовании карты для группировки методов GET и POST. Метод запроса OPTIONS возвращает предварительный запрос клиенту о правилах CORS этого сервера. Методы OPTIONS, GET и POST разрешены правилами CORS. Установка заголовка Access-Control-Allow-Origin позволяет также исполь- зовать контент, обслуживаемый этим сервером, на страницах проис- хождения, которые соответствуют этому заголовку. Предварительный запрос можно кешировать для клиента на 1 728 000 секунд, или 20 дней.
Обсуждение
Такие ресурсы, как JavaScript, используют технологию CORS, когда запрашиваемый ими ресурс находится в домене, отличном от их собст- венного. Когда запрос рассматривается как предполагающий совмест-
7.3. Шифрование на стороне клиента v 87
|
7.3. Шифрование на стороне клиента
Задача
|
и клиентом.
Решение
Используйте один из SSL-модулей, например ngx_http_ssl_module или
ngx_stream_ssl_module, для шифрования трафика:
http { # All directives used below are also valid in stream server {
listen 8433 ssl;
ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5;
ssl_certificate /etc/nginx/ssl/example.pem; ssl_certificate_key /etc/nginx/ssl/example.key; ssl_certificate /etc/nginx/ssl/example.ecdsa.crt; ssl_certificate_key /etc/nginx/ssl/example.ecdsa.key; ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
}
}
Данная конфигурация настраивает сервер на прослушивание порта 8443, зашифрованного с помощью SSL. Сервер принимает протоколы SSL версий TLSv1.2 и TLSv1.3. Для применения данным сервером рас-
|
крываются два набора местоположений сертификата и пар ключей. Серверу предписывается применять наивысшую предлагаемую его клиентом неприступность при ограничении небольшим числом, не яв- ляющимся безопасным. Поскольку мы предоставили некую пару клю- чей ECC (Elliptic Curve Cryptopgraphy), наивысшим приоритетом обла- дает именно шифрование ECC. Имеющиеся кеш SSL сеанса и тайм-аут делают для исполнителей возможным кешировать и сохранять пара- метры сеанса на заданный промежуток времени. Существует большое число прочих параметров кеширования сеанса, которые способствуют производительности и безопасности для любых видов вариантов при- менения. Вы можете использовать параметры кеширования сеанса сов- местно друг с другом. Однако если определять параметр без значения по умолчанию, это отключит значение по умолчанию, которое встроено в кеширование сеанса.
|
Безопасные транспортные уровни являются наиболее распростра- ненным способом шифрования информации при передаче. На момент написания этих строк предпочтительнее использовать протокол TLS вместо SSL, потому что версии SSL с 1 по 3 теперь считаются небезопас- ными. Хотя имя протокола можетотличаться, TLS по-прежнему устанав- ливает уровень защищенных сокетов. NGINX позволяет вашей службе защищать информацию между вами и вашими клиентами, что, в свою очередь, защищает клиента и ваш бизнес. При использовании подпи- санного сертификата необходимо объединить сертификат с цепочкой сертификатов центра сертификации. Когда вы объединяете свой сер- тификат и цепочку, ваш сертификат должен находиться над цепочкой в файле. Если ваш центр сертификации предоставил большое количество файлов в цепочке, он также может указать порядок их размещения. Кеш SSL-сессии повышает производительность благодаря отсутствию согла- сования шифров и версий SSL/TLS.
При тестировании было установлено, что сертификаты ECC быстрее,
чем аналогичные сертификаты RSA. Размер ключа меньше, что при- водит к возможности обслуживать больше SSL/TLS-соединений и с бо- лее быстрым квитированием. NGINX позволяет настраивать несколько сертификатов и ключей, а затем обслуживать оптимальный сертификат для клиентского браузера. Это дает вам возможность воспользоваться преимуществами новой технологии, но при этом обслуживать старых клиентов.
7.4. Восходящее шифрование v 89
См . также : https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_con fi gurationshttps://ssl-con fi g.mozilla.org
https://www.ssllabs.com/ssltest/
7.4.
|
Задача
Вам требуется шифровать трафик между NGINX и конкретной служ- бой восходящего потока, а также устанавливать особые правила согла- сования для регулировок надежности или когда данный восходящий поток пребывает вне вашей безопасной сетевой среды.
|
Для задания правил SSL вам следует применить директивы SSL для своего модуля посредника HTTP:
location / {
proxy_pass https://upstream.example.com; proxy_ssl_verify on; proxy_ssl_verify_depth 2; proxy_ssl_protocols TLSv1.2;
}
Эти директивы посредника устанавливают особые правила SSL чтобы подчиняться NGINX. Эти настраиваемые директивы гарантируют, что NGINX удостоверяет: данный сертификат и цепочка в данной службе восходящего потока подтверждены до двух сертификатов в глубину. Соответствующая директива proxy_ssl_protocols определяет, что этот NGINX будет применять только TLS с версией 1.2. По умолчанию NGINX не проверяет сертификаты восходящего потока и применяет все версии TLS.
Обсуждение
Имеющиеся директивы для нашего модуля посредника HTTP очень многочисленны, а если вам требуется шифровать трафик восходящего потока, следует, по крайней мере, включить установление подлинно- сти. Вы можете выступать посредником поверх HTTPS, изменяя прото- кол в том значении, которое передается в соответствующую директиву
90 v Глава 7. Контроль безопасности
Дата добавления: 2021-01-21; просмотров: 116; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!