← Back to blog

L7 Security: Сбор архитектурной модели (Level 1)

Feb, 21, 2026

#security#architecture#checkpoint#l7#ddos

⚙️ Теория

⚙️ Контрольный день

В этот день ничего нового не изучать.
Задача: собрать цельную рабочую модель из уже изученных блоков.

🧩 Нужно нарисовать на листе

  1. End-to-end путь запроса: Client -> Edge -> WAF -> Rate Limiter -> Bot Management -> Cache -> Origin

  2. Где именно принимается решение:

  • allow;
  • block;
  • challenge;
  • log/count.
  1. Где находится состояние:
  • stateless edge rules;
  • shared counters/quotas;
  • origin-side state.
  1. Где находятся bottleneck-точки:
  • rule engine CPU;
  • shared counters/locks;
  • upstream latency;
  • connection limits;
  • cache miss pressure.

❓ Ответить письменно на вопросы

Почему L7-атака может быть дешевле для атакующего?

Потому что атакующий отправляет дешёвые для себя запросы, а дорогая часть вычисления выполняется вашим origin.

Где должен стоять WAF — до или после cache?

В edge-конвейере security-проверки выполняются до доступа к origin; конкретный порядок с cache зависит от платформы/фазы, но принцип один: опасный трафик должен отсеиваться максимально рано.

Почему distributed rate limiting сложнее локального?

Нужно согласовывать состояние между узлами при гонках и задержках репликации.

Почему anycast помогает против DDoS?

Поток атаки рассеивается по множеству PoP, уменьшая локальную перегрузку.

Как отличить flash crowd от атаки?

Смотреть не только на RPS, а на поведение: URI skew, ошибки, latency tail, bot/challenge сигналы и impact на origin.

Где возможен bottleneck в WAF?

В тяжёлой normalization/regex-инспекции и в слишком широком наборе deep rules на каждый запрос.

Почему edge filtering дешевле origin filtering?

Потому что ранний drop экономит самый дорогой слой: приложение, БД, внутренние очереди и upstream.

🧪 Смоделировать сценарии

1. 10k RPS + медленный upstream

Ожидаемое поведение:

  • рост active requests/connections;
  • рост p95/p99;
  • риск saturation по worker/upstream pool;
  • усиление эффекта при cache miss.

2. Burst 100k req/s

Ожидаемое поведение:

  • фильтрация/лимиты на edge должны сработать раньше origin;
  • без достаточного burst control появятся массовые drops/challenges;
  • bottleneck быстро проявится в rule CPU и shared counters.

3. 10MB request body

Ожидаемое поведение:

  • рост buffering/memory/temp-file I/O;
  • выше цена WAF/body inspection;
  • повышенный риск деградации на upload endpoints.

4. Отключённый keepalive

Ожидаемое поведение:

  • больше handshake/accept overhead;
  • рост CPU на соединения;
  • ниже эффективность при одинаковом полезном RPS.

✅ Критерий Level 1

Если вы можете предсказать поведение системы в этих сценариях до эксперимента и затем подтвердить прогноз метриками, значит базовый архитектурный уровень освоен.

🧪 Практика

  • Используйте команды и примеры из разделов выше как рабочий чеклист.
  • Перед применением в production валидируйте изменения на test/stage и сверяйте с официальной документацией.

🧾 Вывод

Материал резюмирует ключевые принципы и практики по теме статьи. Для production-решений опирайтесь на ограничения вашей инфраструктуры и официальные источники.

📚 Ссылки

✅ Проверка источников

L7 Security: Сбор архитектурной модели (Level 1) | Aleksandr Suprun