# Отделите публичный веб-периметр от приложения | SwissOctet Insights https://swissoctet.com/ru/insights/separate-the-web-edge-from-the-app/ SwissOctet / Аналитика / Веб и onion Веб и onion Прикладное · 4 мин чтения Отделите публичный веб-край от приложения Дайте веб-серверу, обратному прокси и приложению отдельные обязанности, с продуманным доступом к источнику, TLS, ограничениями запросов и путём реагирования на инциденты. От редакции SwissOctet Сохранить руководство Скопировать ссылку НА ЭТОЙ СТРАНИЦЕ 01 Веб-запрос пересекает несколько зон ответственности 02 Используйте периметр для организации поведения HTTP 03 Обратный прокси не устраняет подверженность источника 04 Применяйте решения о доступе внутри приложения 05 Планируйте защиту от отказа в обслуживании более чем на одном уровне 06 Сделайте восстановление частью публикации Ваш практический чек-лист Источники и дополнительное чтение Назад в библиотеку ПРЯМОЙ ОТВЕТ Отделите публикацию HTTP от выполнения приложения и постоянных данных. Обратный прокси может организовать маршрутизацию и ограничения, но доступ к источнику, авторизация приложения, пропускная способность вышестоящего узла и восстановление требуют собственных средств контроля. 01 Веб-запрос пересекает несколько зон ответственности Веб-сервер принимает запросы HTTP и может отдавать статические файлы. Процесс приложения выполняет динамическое поведение проекта, например проверку учётной записи или запрос к базе данных. Обратный прокси принимает запросы от имени этого процесса и пересылает их на вышестоящий узел. Одна программа может выполнять несколько ролей, но разделение обязанностей упрощает понимание конфигурации и восстановления. Проследите один запрос от разрешения имени хоста до ответа. Зафиксируйте, где заканчивается TLS, какой процесс выбирает маршрут и какой компонент может читать данные приложения. Сделайте то же самое для административного запроса. Это упражнение часто выявляет слушателя или имя хоста, созданные для тестирования и случайно оставшиеся доступными. Схема должна описывать развёрнутый путь, а не архитектуру, которую вы надеялись построить. 02 Используйте периметр для организации поведения HTTP NGINX документирует как отдачу статического содержимого, так и пересылку запросов на вышестоящий узел. Его архитектура рабочих процессов и модули HTTP предоставляют механизмы конфигурации, но конкретная конфигурация всё равно определяет поведение. Определяйте имена хостов, вышестоящие узлы и корни файловой системы осознанно. Ограничьте файлы, которые могут отдаваться, чтобы конфигурация, учётные данные и метаданные репозитория никогда не становились доступными для скачивания только потому, что они оказались рядом с приложением. Задайте подходящие ограничения для тел запросов, тайм-аутов и соединений в соответствии с приложением. Относитесь к кэшам как к решению о данных: содержимое, привязанное к пользователю или разрешению, не может безопасно наследовать общее правило кэширования без проверки. Тестируйте аутентификацию и поведение кэша вместе. Храните воспроизводимую конфигурацию и проверяйте изменения перед перезагрузкой службы, имея известный путь возврата к предыдущей рабочей версии. Слой Полезная зона ответственности Проверьте перед запуском Публичный веб-периметр TLS, маршрутизация по имени хоста и ограничения HTTP Сертификаты, корни и предполагаемые имена хостов Процесс приложения Бизнес-логика и авторизация Аутентификация, проверки ввода и отказ зависимостей Внутренняя служба данных Постоянное состояние приложения Ограниченный доступ и проверенное восстановление Сеть вышестоящего провайдера Законтрактованная сетевая услуга Объём защиты и путь эскалации 03 Обратный прокси не устраняет подверженность источника Если источник остаётся общедоступным, клиент может достичь его, не используя предполагаемый маршрут прокси. Ограничьте доступ к источнику через проектирование сети и конфигурацию приложения, когда развёртывание требует такой границы. На одной машине бэкенд часто может слушать loopback или локальный сокет. Между машинами используйте явные ограниченные маршруты и подходящую защиту соединения с вышестоящим узлом. Пересылаемые заголовки тоже нуждаются в правиле доверия. Принимайте информацию об исходном клиенте только от доверенных посредников и не позволяйте произвольным вызывающим сторонам передавать значения, которые приложение считает достоверными. Решите, что попадает в журналы доступа и отчёты об ошибках. Прокси может изменить информацию, доступную на каждом уровне; он не стирает идентификаторы учётных записей и не делает приложение анонимным для собственного оператора. 04 Применяйте решения о доступе внутри приложения Архитектура нулевого доверия NIST сосредоточена на решениях о доступе к ресурсам, а не на неявном доверии, основанном только на сетевом расположении. Применяйте этот принцип конкретно: аутентифицируйте вызывающую сторону, авторизуйте запрошенную операцию и предоставляйте сервисным учётным записям только необходимую область. Запрос, приходящий из внутренней подсети, не должен автоматически становиться административным запросом. Разделяйте публичные и административные функции там, где это практично. Перепроверяйте разрешение при доступе пользователя к записи, а не полагайтесь только на первоначальный вход. Держите учётные данные для прокси, приложения и базы данных разными. Вводите изменения поэтапно, чтобы их можно было тестировать, начиная с узкого чувствительного пути. Называть развёртывание нулевым доверием менее полезно, чем демонстрировать, что запрещённое действие действительно отклоняется на отвечающем за него компоненте. 05 Планируйте защиту от отказа в обслуживании более чем на одном уровне Насыщенный сетевой канал и дорогостоящий запрос приложения отказывают в разных местах. Ограничение скорости на веб-периметре может помочь ограничить шаблоны запросов, а ограничения приложения могут ограничить работу, например поиск, загрузку или экспорт. Модуль ограничения запросов NGINX предоставляет один механизм; ключ и пороги должны соответствовать реальным пользователям и быть протестированы, чтобы не отклонять законный трафик. Руководство OWASP по защите от отказа в обслуживании также рассматривает исчерпание ресурсов в поведении приложения. Установите ограничения по времени и размеру для дорогостоящей работы, используйте ограниченные очереди и отслеживайте сигналы сбоев. Локальные средства контроля не могут создать пропускную способность в уже насыщенном канале вышестоящего узла. Подтвердите конкретную сетевую защиту, включённую в выбранное предложение, и подготовьте путь эскалации. Никогда не предполагайте, что защита уровня 3–4 из каталога также доказывает защиту для каждой рабочей нагрузки HTTP. 06 Сделайте восстановление частью публикации Проверьте сайт с внешнего клиента, используя его предполагаемое имя хоста. Проверьте 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. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно. СВЯЖИТЕ ЗНАНИЯ Связанная инфраструктура. Canvas Web Швейцария Vector VPS Швейцария Pulse NVMe Швейцария Transit 40 Швейцария СОХРАНЯЙТЕ НИТЬ Ваши следующие заметки. Изучите все руководства ЗАМЕТКА / 01 + Эксплуатация второго дня Прикладное Базовый уровень защиты Linux VPS, который вы можете поддерживать Обеспечьте безопасное администрирование, открывайте только необходимые сервисы и настройте обновления и восстановление, не заблокировав себе доступ. 6 мин чтения Читать руководство ЗАМЕТКА / 02 + Веб и onion Основа Веб-хостинг или VPS: выберите работу, которую хотите взять на себя Сравнивайте требования приложения, контроль и обязанности по обслуживанию, а не считайте VPS автоматическим следующим шагом для любого веб-сайта. 6 мин чтения Читать руководство ЗАМЕТКА / 03 + Веб и onion Прикладное Runbook переключения домена, DNS и TLS для нового сервера Подготовьте маршрутизацию по имени хоста, сертификаты и откат вместе, чтобы миграция меняла сервер, не нарушая идентичность сайта или защищённые соединения. 4 мин чтения Читать руководство