Отделите публикацию HTTP от выполнения приложения и постоянных данных. Обратный прокси может организовать маршрутизацию и ограничения, но доступ к источнику, авторизация приложения, пропускная способность вышестоящего узла и восстановление требуют собственных средств контроля.
Веб-запрос пересекает несколько зон ответственности
Веб-сервер принимает запросы HTTP и может отдавать статические файлы. Процесс приложения выполняет динамическое поведение проекта, например проверку учётной записи или запрос к базе данных. Обратный прокси принимает запросы от имени этого процесса и пересылает их на вышестоящий узел. Одна программа может выполнять несколько ролей, но разделение обязанностей упрощает понимание конфигурации и восстановления.
Проследите один запрос от разрешения имени хоста до ответа. Зафиксируйте, где заканчивается TLS, какой процесс выбирает маршрут и какой компонент может читать данные приложения. Сделайте то же самое для административного запроса. Это упражнение часто выявляет слушателя или имя хоста, созданные для тестирования и случайно оставшиеся доступными. Схема должна описывать развёрнутый путь, а не архитектуру, которую вы надеялись построить.
Используйте периметр для организации поведения HTTP
NGINX документирует как отдачу статического содержимого, так и пересылку запросов на вышестоящий узел. Его архитектура рабочих процессов и модули HTTP предоставляют механизмы конфигурации, но конкретная конфигурация всё равно определяет поведение. Определяйте имена хостов, вышестоящие узлы и корни файловой системы осознанно. Ограничьте файлы, которые могут отдаваться, чтобы конфигурация, учётные данные и метаданные репозитория никогда не становились доступными для скачивания только потому, что они оказались рядом с приложением.
Задайте подходящие ограничения для тел запросов, тайм-аутов и соединений в соответствии с приложением. Относитесь к кэшам как к решению о данных: содержимое, привязанное к пользователю или разрешению, не может безопасно наследовать общее правило кэширования без проверки. Тестируйте аутентификацию и поведение кэша вместе. Храните воспроизводимую конфигурацию и проверяйте изменения перед перезагрузкой службы, имея известный путь возврата к предыдущей рабочей версии.
| Слой | Полезная зона ответственности | Проверьте перед запуском |
|---|---|---|
| Публичный веб-периметр | TLS, маршрутизация по имени хоста и ограничения HTTP | Сертификаты, корни и предполагаемые имена хостов |
| Процесс приложения | Бизнес-логика и авторизация | Аутентификация, проверки ввода и отказ зависимостей |
| Внутренняя служба данных | Постоянное состояние приложения | Ограниченный доступ и проверенное восстановление |
| Сеть вышестоящего провайдера | Законтрактованная сетевая услуга | Объём защиты и путь эскалации |
Обратный прокси не устраняет подверженность источника
Если источник остаётся общедоступным, клиент может достичь его, не используя предполагаемый маршрут прокси. Ограничьте доступ к источнику через проектирование сети и конфигурацию приложения, когда развёртывание требует такой границы. На одной машине бэкенд часто может слушать loopback или локальный сокет. Между машинами используйте явные ограниченные маршруты и подходящую защиту соединения с вышестоящим узлом.
Пересылаемые заголовки тоже нуждаются в правиле доверия. Принимайте информацию об исходном клиенте только от доверенных посредников и не позволяйте произвольным вызывающим сторонам передавать значения, которые приложение считает достоверными. Решите, что попадает в журналы доступа и отчёты об ошибках. Прокси может изменить информацию, доступную на каждом уровне; он не стирает идентификаторы учётных записей и не делает приложение анонимным для собственного оператора.
Применяйте решения о доступе внутри приложения
Архитектура нулевого доверия NIST сосредоточена на решениях о доступе к ресурсам, а не на неявном доверии, основанном только на сетевом расположении. Применяйте этот принцип конкретно: аутентифицируйте вызывающую сторону, авторизуйте запрошенную операцию и предоставляйте сервисным учётным записям только необходимую область. Запрос, приходящий из внутренней подсети, не должен автоматически становиться административным запросом.
Разделяйте публичные и административные функции там, где это практично. Перепроверяйте разрешение при доступе пользователя к записи, а не полагайтесь только на первоначальный вход. Держите учётные данные для прокси, приложения и базы данных разными. Вводите изменения поэтапно, чтобы их можно было тестировать, начиная с узкого чувствительного пути. Называть развёртывание нулевым доверием менее полезно, чем демонстрировать, что запрещённое действие действительно отклоняется на отвечающем за него компоненте.
Планируйте защиту от отказа в обслуживании более чем на одном уровне
Насыщенный сетевой канал и дорогостоящий запрос приложения отказывают в разных местах. Ограничение скорости на веб-периметре может помочь ограничить шаблоны запросов, а ограничения приложения могут ограничить работу, например поиск, загрузку или экспорт. Модуль ограничения запросов NGINX предоставляет один механизм; ключ и пороги должны соответствовать реальным пользователям и быть протестированы, чтобы не отклонять законный трафик.
Руководство OWASP по защите от отказа в обслуживании также рассматривает исчерпание ресурсов в поведении приложения. Установите ограничения по времени и размеру для дорогостоящей работы, используйте ограниченные очереди и отслеживайте сигналы сбоев. Локальные средства контроля не могут создать пропускную способность в уже насыщенном канале вышестоящего узла. Подтвердите конкретную сетевую защиту, включённую в выбранное предложение, и подготовьте путь эскалации. Никогда не предполагайте, что защита уровня 3–4 из каталога также доказывает защиту для каждой рабочей нагрузки HTTP.
Сделайте восстановление частью публикации
Проверьте сайт с внешнего клиента, используя его предполагаемое имя хоста. Проверьте HTTPS, перенаправления, статические ресурсы, входы и типовую транзакцию приложения. Убедитесь, что административные слушатели и приватные файлы остаются недоступными. Смоделируйте остановленный вышестоящий узел и проверьте, что периметр возвращает контролируемый сбой, а не раскрывает внутренние детали или ждёт без ограничения.
Для Canvas ознакомьтесь со средствами контроля, доступными в хостинговой учётной записи. Для VPS поддерживайте веб-периметр и приложение как часть собственного эксплуатационного плана. Большой сетевой порт — это спецификация пропускной способности, а не доказательство того, что приложение может выдержать такую пропускную способность. Держите мониторинг, восстановление и контакты провайдера в регламенте. Публикуйте только после проверки фактического пути запроса и практического пути восстановления.
Ваш практический чек-лист.
- Проследите публичный и административный запрос.
- Определите отдаваемые корни и слушателей вышестоящих узлов.
- Доверяйте пересылаемым заголовкам только от утверждённых посредников.
- Проверьте авторизацию и границы кэша.
- Подготовьте ограничения и эскалацию для сетевых сбоев и сбоев приложения.
Детали, которые важны.
Может ли веб-сервер также действовать как обратный прокси?+
Да. NGINX — один из документированных примеров. Его роли зависят от конфигурации, и приложению всё равно нужны собственные авторизация и обслуживание.
Автоматически ли обратный прокси скрывает источник?+
Нет. Источник может оставаться доступным, если маршрутизация, межсетевой экран и настройки слушателя не обеспечивают предполагаемую границу.
Остановит ли ограничение запросов каждую атаку DDoS?+
Нет. Оно устраняет отдельные шаблоны запросов HTTP. Насыщение сети и другие отказы ресурсов требуют соответствующих средств контроля вышестоящего узла и приложения.
Перейдите к источнику.
Эти источники поддерживают технические концепции в этом руководстве. Следуйте актуальной документации, прежде чем менять производственную систему.
- NGINX: руководство для начинающих nginx.org
- NGINX: ограничение запросов HTTP nginx.org
- NIST SP 800-207: архитектура нулевого доверия nvlpubs.nist.gov
- OWASP: предотвращение отказа в обслуживании cheatsheetseries.owasp.org
Редакционное руководство от SwissOctet. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно.