Відокремте публікацію HTTP від виконання застосунку та постійних даних. Зворотний проксі може організувати маршрутизацію та обмеження, але доступ до джерела, авторизація застосунку, пропускна здатність висхідного вузла та відновлення кожен потребують власних елементів керування.
Веб-запит охоплює кілька зон відповідальності
Веб-сервер отримує запити HTTP і може обслуговувати статичні файли. Процес застосунку виконує динамічну поведінку проєкту, як-от перевірка облікового запису чи запит до бази даних. Зворотний проксі отримує запити від імені цього процесу та пересилає їх на висхідний вузол. Одна програма може виконувати кілька ролей, але розділення обов'язків полегшує осмислення конфігурації та відновлення.
Простежте один запит від розпізнавання імені хоста до відповіді. Запишіть, де закінчується TLS, який процес обирає маршрут і який компонент може читати дані застосунку. Зробіть те саме для адміністративного запиту. Ця вправа часто виявляє слухача або ім'я хоста, створене для тестування, яке випадково залишилося доступним. Діаграма повинна описувати розгорнутий шлях, а не архітектуру, яку ви сподівалися побудувати.
Використовуйте периметр для організації поведінки HTTP
NGINX документує як обслуговування статичного вмісту, так і пересилання запитів на висхідний вузол. Його архітектура робочих процесів і модулі HTTP надають механізми конфігурації, але конкретна конфігурація все одно визначає поведінку. Визначайте імена хостів, висхідні вузли та корені файлової системи навмисно. Обмежте файли, які можуть обслуговуватися, щоб конфігурація, облікові дані та метадані репозиторію ніколи не ставали завантажуваними лише тому, що вони випадково розташовані поруч із застосунком.
Встановіть відповідні обмеження для тіл запитів, тайм-аутів і з'єднань відповідно до застосунку. Ставтеся до кешів як до рішення щодо даних: вміст, прив'язаний до користувача чи дозволу, не може безпечно успадковувати спільне правило кешування без перевірки. Перевіряйте автентифікацію та поведінку кешу разом. Зберігайте відтворювану конфігурацію та перевіряйте зміни перед перезавантаженням служби, маючи відомий шлях повернення до попередньої робочої версії.
| Шар | Корисна відповідальність | Перевірте перед запуском |
|---|---|---|
| Публічний веб-периметр | TLS, маршрутизація за іменем хоста та обмеження HTTP | Сертифікати, корені та призначені імена хостів |
| Процес застосунку | Бізнес-логіка та авторизація | Автентифікація, перевірки введення та збій залежностей |
| Внутрішня служба даних | Постійний стан застосунку | Обмежений доступ і перевірене відновлення |
| Мережа висхідного постачальника | Законтрактована мережева послуга | Обсяг захисту та шлях ескалації |
Зворотний проксі не усуває відкритість джерела
Якщо джерело залишається загальнодоступним, клієнт може дістатися до нього, не використовуючи призначений маршрут проксі. Обмежте доступ до джерела через проєктування мережі та конфігурацію застосунку, коли розгортання вимагає такої межі. На одній машині бекенд часто може слухати на loopback або локальному сокеті. Між машинами використовуйте явні обмежені маршрути та відповідний захист для з'єднання з висхідним вузлом.
Переслані заголовки також потребують правила довіри. Приймайте інформацію про початкового клієнта лише від довірених посередників і не дозволяйте довільним викликам надавати значення, які застосунок вважає авторитетними. Визначте, що з'являється в журналах доступу та звітах про помилки. Проксі може змінювати інформацію, доступну на кожному рівні; він не стирає ідентифікатори облікових записів і не робить застосунок анонімним для його власного оператора.
Застосовуйте рішення про доступ усередині застосунку
Архітектура Zero Trust від NIST зосереджується на рішеннях про доступ до ресурсів, а не на неявній довірі лише на основі мережевого розташування. Застосуйте цей принцип конкретно: автентифікуйте виклик, авторизуйте запитану операцію та надавайте службовим обліковим записам лише необхідний обсяг. Запит, що надходить із внутрішньої підмережі, не повинен автоматично ставати адміністративним запитом.
Розділяйте публічні та адміністративні функції, де це практично. Перевіряйте дозвіл повторно, коли користувач звертається до запису, а не покладайтеся лише на початковий вхід. Тримайте облікові дані для проксі, застосунку та бази даних окремо. Впроваджуйте зміни поетапно, щоб їх можна було перевірити, починаючи з вузького чутливого шляху. Називати розгортання Zero Trust менш корисно, ніж продемонструвати, що заборонена дія справді відхиляється на компоненті, відповідальному за неї.
Плануйте захист від відмови в обслуговуванні на більш ніж одному рівні
Перевантажене мережеве з'єднання та дорогий запит застосунку зазнають збою в різних місцях. Обмеження швидкості на веб-периметрі може допомогти стримати шаблони запитів, тоді як обмеження застосунку можуть обмежити роботу, як-от пошук, завантаження чи експорт. Модуль обмеження запитів NGINX надає один механізм; ключ і пороги повинні відповідати реальним користувачам і бути перевіреними, щоб не відхиляти легітимний трафік.
Настанови OWASP щодо відмови в обслуговуванні також розглядають вичерпання ресурсів у поведінці застосунку. Встановіть обмеження часу та розміру для дорогої роботи, використовуйте обмежені черги та відстежуйте сигнали збоїв. Локальні елементи керування не можуть створити пропускну здатність у вже перевантаженому висхідному з'єднанні. Підтвердьте конкретний мережевий захист, включений до обраної пропозиції, і підготуйте шлях ескалації. Ніколи не припускайте, що захист рівня 3–4, зазначений у каталозі, також доводить захист для кожного робочого навантаження HTTP.
Зробіть відновлення частиною публікації
Перевірте сайт із зовнішнього клієнта, використовуючи його призначене ім'я хоста. Перевірте HTTPS, перенаправлення, статичні ресурси, входи та репрезентативну транзакцію застосунку. Підтвердьте, що адміністративні слухачі та приватні файли залишаються недоступними. Змоделюйте зупинений висхідний вузол і перевірте, що периметр повертає контрольований збій, а не розкриває внутрішні деталі чи чекає без обмеження.
Для Canvas ознайомтеся з елементами керування, доступними в обліковому записі хостингу. Для VPS підтримуйте веб-периметр і застосунок як частину вашого власного операційного плану. Великий мережевий порт — це специфікація пропускної здатності, а не доказ того, що застосунок може підтримувати таку пропускну здатність. Тримайте моніторинг, відновлення та контакти постачальника в операційному посібнику. Публікуйте лише після перевірки фактичного шляху запиту та практичного шляху відновлення.
Ваш практичний контрольний список.
- Простежте публічний та адміністративний запит.
- Визначте корені, що обслуговуються, та слухачі висхідних вузлів.
- Довіряйте пересланим заголовкам лише від затверджених посередників.
- Перевірте авторизацію та межі кешу.
- Підготуйте обмеження та ескалацію для мережевих збоїв і збоїв застосунку.
Деталі, які мають значення.
Чи може веб-сервер також діяти як зворотний проксі?+
Так. NGINX є одним задокументованим прикладом. Його ролі залежать від конфігурації, і застосунок усе ще потребує власної авторизації та обслуговування.
Чи автоматично зворотний проксі приховує джерело?+
Ні. Джерело може залишатися доступним, якщо налаштування маршрутизації, брандмауера та слухача не забезпечують призначену межу.
Чи зупинить обмеження запитів кожну атаку DDoS?+
Ні. Воно стосується вибраних шаблонів запитів HTTP. Перевантаження мережі та інші збої ресурсів потребують відповідних елементів керування висхідним вузлом і застосунком.
Перейдіть до джерела.
Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи.
- NGINX: Посібник для початківців nginx.org
- NGINX: Обмеження запитів HTTP nginx.org
- NIST SP 800-207: Архітектура Zero Trust nvlpubs.nist.gov
- OWASP: Запобігання відмові в обслуговуванні cheatsheetseries.owasp.org
Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо.