Полный контроль над Production: Архитектура, автоматизация и защита «от проектирования до релиза»

1. Архитектура с нулевым доверием: изоляция как основа

Production-инфраструктура спроектирована по модели zero trust: ни один компонент не считается «надёжным» по умолчанию. Все серверы размещены в изолированном сетевом контуре, использующем частные IPv4-адреса (например, 10.x.x.x или 192.168.x.x). Прямой доступ из интернета к базам данных, микросервисам или внутренним API физически невозможен.

Это не просто «ограничение» — это архитектурное требование, позволяющее:

• Снизить поверхность атаки до единственной точки входа.
• Устранить риск непосредственного сканирования или эксплуатации уязвимостей в сервисах.
• Упростить аудит и соответствие требованиям регуляторов (PCI DSS, GDPR).

2. Глубокая защита: два слоя фронта

Весь входящий трафик проходит через двухуровневую защиту, построенную по принципу «глубокой защиты»:

1. FortiGate WAF (Web Application Firewall)
   Аппаратный шлюз на границе сети обеспечивает фильтрацию на уровнях L3–L7:

   • Блокировка DDoS-атак и сканеров.
   • Сигнатурная и поведенческая защита от SQLi, XSS, RCE.
   • Интеграция с threat intelligence для актуальных сигнатур.

2. Nginx как policy enforcement point
   За WAF расположен Nginx, настроенный как строгий reverse proxy:

   • Белый список разрешённых HTTP-методов, путей и заголовков.
   • Валидация User-Agent и Origin.
   • Ограничение скорости и защиты от fuzzing-запросов.
   • Ведение детального лога всех обращений (для SIEM и анализа).

Эта схема гарантирует, что даже при обходе WAF (например, через нулевой день) атакующий столкнётся с жёсткими правилами применения и отсутствием прямого доступа к бизнес-логике.

3. Микросервисы и сетевая дисциплина

Архитектура приложения следует методологии 12-Factor App, особенно в части изоляции и конфигурирования. Критически важно:

• Микросервисы без публичного интерфейса не имеют открытых портов. Их взаимодействие происходит исключительно внутри доверенной сети:
  • В Kubernetes — через Pod-to-Pod communication с применением NetworkPolicy.
  • В Docker Swarm или Compose — через overlay-сети с ограничением egress/ingress трафика.
• Сервисы с внешним API никогда не обрабатывают чувствительные данные по открытым каналам. Даже если интерфейс вызывается через TLS, сами данные не передаются в открытом виде.

Такой подход исключает ситуацию, когда «внутренний» сервис случайно становится публичным из-за ошибки в балансировке или DNS.

4. Защита данных «в движении» и «в покое»

Данные — главный актив. Поэтому:

• Все данные в PostgreSQL, содержащие PII, токены, финансовые идентификаторы, шифруются на уровне приложения.
• Инструменты администрирования (pgAdmin, DBeaver) не могут получить расшифрованное значение — даже при успешной аутентификации в СУБД.
• Расшифровка производится только в контексте авторизованного запроса внутри доверенного сервиса.

Это не «дополнительная мера» — это основа compliance. Даже при компрометации учётной записи СУБД или утечке дампа данные остаются бесполезными.

5. CI/CD как контроль качества и безопасности

Каждое изменение проходит трёхступенчатый конвейер, который одновременно является механизмом качества и аудита:

• Pre-Prod используется при классической инфраструктуре. Здесь проводится ручная приёмка, и трафик может быть направлен вручную (например, для команды продукта).
• Canary-деплой в Kubernetes применяется при облачной или контейнеризованной архитектуре: 5% трафика — новая версия, 95% — стабильная. Мониторинг ошибок, задержек и потребления ресурсов управляет автоматическим откатом.

Важно: ни один этап не пропускается. Релиз в production невозможен без прохождения всех тестов и артефактов сборки, подписанной и верифицированной через CI.

Заключение: Контроль — это выбор архитектуры, а не реакция

Приведённая модель демонстрирует, что «полный контроль над production» — это не миф и не требование ops-отдела, а результат:

• Архитектурной дисциплины (изоляция, принципы 12-Factor, zero trust),
• Инженерной автоматизации (CI/CD как средство доставки и верификации),
• Культуры безопасности (шифрование данных, защита на границе и внутри).

Такой подход обеспечивает не только соответствие compliance, но и предсказуемость, воспроизводимость и устойчивость к сбоям — ключевые признаки зрелой production-среды.

«Надёжность — это не то, что добавляют в конце. Это то, что проектируют с самого начала.»
— адаптировано из Google SRE Workbook

Диаграмма архитектуры

Ниже — схема, иллюстрирующая описанную структуру:

+---------------------+
|     Internet        |
+----------+----------+
           |
           v
+----------+----------+
|   FortiGate WAF     | ← Защита L3–L7 (DDoS, SQLi, XSS)
+----------+----------+
           |
           v
+----------+----------+
|      Nginx Proxy    | ← Белый список путей, фильтрация заголовков
+----------+----------+
           |
           v
+----------+----------+
|   Public-Facing     |
|   Microservices     | ← Только внешние API, без чувствительных данных
+----------+----------+
           |
   +-------+-------+
   |               |
   v               v
+--+--+        +---+---+
| K8s |        | Docker| ← Internal-only services
| Net |        | Net   |    (Pod-to-Pod / Overlay)
+--+--+        +---+---+
   |               |
   v               v
+--+--------------+--+
| PostgreSQL (шифрование на уровне приложения) |
| Redis, Consul, etcd                        |
+--------------------+
      (изолированная сеть, без входа извне)