Часть VI: Крупные проекты — архитектура на уровне гигантов

Глава 30

Безопасность на масштабе — как не стать заголовком новостей

Проблема

Проблема: Маленькие стартапы взламывают редко — хакерам неинтересно. Когда ваша система вырастает, вы становитесь целью. DDoS-атаки, утечки данных, supply chain атаки, комплаенс-проверки. Вопрос не в том, «атакуют ли нас?» — атакуют. Вопрос: «выдержим ли мы?»

Представьте, что вы проснулись утром, открыли Twitter (простите, X), а там — ваш сервис в топе трендов. Не потому, что вы запустили крутую фичу. Потому что утекли данные пользователей. 10 миллионов записей. И ваш CTO уже отвечает на вопросы журналистов.

Звучит как кошмар? Это реальность для десятков компаний каждый год.

Безопасность на масштабе — это не про «поставить firewall и забыть». Это про систему решений, которые работают вместе: от того, как вы храните секреты, до того, как реагируете на инцидент в 3 часа ночи.

Эта глава — не учебник по безопасности. Это набор практик, которые реально работают, когда ваша система обслуживает миллионы пользователей.

#Defense in Depth — ваш лук не должен иметь слабых мест

Есть старая шутка: «Как защититься от медведя в лесу? Бегать быстрее, чем твой друг». В безопасности примерно так же. Вы не должны быть «абсолютно неуязвимы» — это невозможно. Вы должны быть менее привлекательной целью, чем сосед.

Концепция Defense in Depth (эшелонированная защита) — это когда у вас не один замок на двери, а несколько уровней. И если хакер прошёл первый, его ждёт второй, третий и чёрт знает какой по счёту.

#Уровни защиты

Level 1: Network & Perimeter

Firewall, DDoS protection, Web Application Firewall (WAF)
Ограничение доступа по IP, geo-blocking
Только нужные порты открыты. Остальное — закрыто.

Level 2: Identity & Access

Authentication: кто ты?
Authorization: что тебе можно?
Least Privilege: минимум прав для работы

Level 3: Application Security

Input validation, SQL injection protection
Rate limiting, API security
OWASP Top 10 — ваш чек-лист (мы к нему ещё вернёмся)

Level 4: Data Security

Encryption at rest — данные зашифрованы в базе
Encryption in transit — TLS везде, никакого HTTP
Secrets management — никаких паролей в коде

Level 5: Monitoring & Response

Log everything, alert on anomalies
Incident response playbook
Penetration testing

Ключевой принцип: Trust No One (да, мы к этому ещё вернёмся в секции про Zero Trust). Каждый уровень предполагает, что предыдущий может быть скомпрометирован.

#Почему один уровень — это плохо

В 2017 году Equifax — одна из крупнейших кредитных бюро в США — пережила утечку данных 147 миллионов человек. Как? Через известную уязвимость в Apache Struts (CVE-2017-5638). Патч был доступен за два месяца до атаки. Equifax просто не задеплоили его.

Если бы у них был WAF, блокирующий эксплуатацию этой уязвимости — ничего бы не произошло. Если бы сегментация сети не давала доступ к базе с веб-сервера — ущерб был бы меньше. Если бы мониторинг заметил подозрительный трафик — атаку бы остановили раньше.

У них не было ни одного из этих уровней. Они полагались на один замок. И замок не закрыли.

#OWASP Top 10 на практике — не чек-лист, а образ мыслей

OWASP Top 10 — это список самых критичных рисков безопасности для веб-приложений. Каждый разработчик хотя бы слышал о нём. Большинство техлидов кивают: «да, мы знаем». Но на практике...

Давайте пройдёмся по топ-рискам и посмотрим, как они выглядят в реальном коде.

#1. Broken Access Control (Нарушение контроля доступа)

Самый частый и самый опасный. Пользователь может посмотреть чужие данные, потому что вы забыли проверить права.

// ПЛОХО: кто угодно может посмотреть любой заказ
app.get('/api/orders/:id', async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  res.json(order);
});

// ХОРОШО: проверяем, что заказ принадлежит пользователю
app.get('/api/orders/:id', async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  if (order.userId !== req.user.id && req.user.role !== 'admin') {
    throw new ForbiddenError();
  }
  res.json(order);
});

Звучит банально? Вы удивитесь, сколько реальных утечек происходит именно из-за отсутствия этой проверки.

[Anti-pattern: см. references/anti-patterns.md — отсутствие валидации доступа — частный случай «No Observability», только в контексте безопасности. Беда в том, что вы можете не заметить, что кто-то читает чужие данные, пока не станет слишком поздно.]

#2. Cryptographic Failures

Не кастомная криптография. Пожалуйста, никогда не пишите свою криптографию. Используйте стандартные библиотеки.

Храните пароли через bcrypt (не md5, не sha256, не «я сам придумал алгоритм»)
TLS 1.3 — дефолт (TLS 1.0 и 1.1 — уже legacy, отключайте)
Шифрование данных в покое — AES-256, не свой алгоритм
Никогда не храните чувствительные данные в логах

#3. Injection

SQL injection, NoSQL injection, Command injection, LDAP injection — все они лечатся одним способом: никогда не доверяйте пользовательскому вводу.

// ПЛОХО: SQL injection — классика
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`;

// ХОРОШО: parameterized queries
const query = 'SELECT * FROM users WHERE email = $1';
const result = await db.query(query, [req.body.email]);

Используйте ORM или parameterized queries. Всегда. Неважно, насколько «безопасный» ваш input.

#4. Security Logging and Monitoring Failures

Если вы не логируете подозрительную активность — вы не узнаете об атаке, пока не станет слишком поздно. Среднее время обнаружения утечки (dwell time) — 207 дней (источник: IBM Cost of Data Breach 2024). Двести семь дней, Карл.

Логируйте все authentication failures
Логируйте access denial (403)
Alert на аномалии: 100 failed logins с одного IP за минуту
Correlation ID через все сервисы (см. Главу 10: Observability)

Остальные риски из OWASP Top 10 (Cross-Site Scripting, Server-Side Request Forgery, Insecure Design и т.д.) — тоже важны. Но если вы закроете эти четыре, вы уже закроете 80% проблем.

Совет

Совет: Сделайте OWASP Top 10 частью code review. Не как чек-лист «проверить и забыть», а как набор сценариев: «а что если этот endpoint вызовет злоумышленник?»

#Secrets Management — пароли не хранятся в Git

Если я вижу в репозитории config/database.yml с паролем от продакшн-базы, у меня дёргается глаз. Серьёзно, 2026 год на дворе. Почему пароли всё ещё в Git?

#Проблема

Секреты — это не только пароли от базы. Это:

API-ключи (AWS, Stripe, OpenAI, SendGrid)
JWT signing keys
TLS-сертификаты
SSH-ключи
Encryption keys

Всё это должно быть не в репозитории. Никогда. Даже если репозиторий приватный.

#HashiCorp Vault

Vault — это стандарт де-факто для управления секретами. Ключевая фишка: секреты не хранятся на диске сервера, а запрашиваются по API.

# application получает секрет на старте
$ vault kv get secret/db/prod

Key                Value
---                -----
host               db.prod.internal
port               5432
username           app_user
password           a1b2c3d4e5...

Vault поддерживает:

Dynamic secrets — секреты с TTL, которые автоматически ротируются
Lease — временные доступы с истечением
Audit log — каждый запрос к Vault логируется
Auto-unseal — автоматическая расшифровка хранилища

// Vault integration example
import * as vault from 'node-vault';

const client = vault({ endpoint: 'https://vault.internal:8200' });
await client.approleLogin({ role_id, secret_id });

const { data } = await client.read('secret/data/db/prod');
const dbConfig = data.data;

const db = await createConnection({
  host: dbConfig.host,
  password: dbConfig.password,
});

#AWS Secrets Manager (или GCP Secret Manager, или Azure Key Vault)

Если вы уже в облаке, managed secrets manager — ваш выбор. AWS Secrets Manager автоматически ротирует секреты для RDS, Redshift, DocumentDB.

// AWS Secrets Manager
import { SecretsManager } from '@aws-sdk/client-secrets-manager';

const sm = new SecretsManager({ region: 'us-east-1' });
const { SecretString } = await sm.getSecretValue({
  SecretId: 'prod/db/orders',
});

const dbConfig = JSON.parse(SecretString);

Разница между Vault и облачными решениями:

Vault — кроссплатформенный, работает везде (on-prem, multi-cloud)
Managed — меньше ops, интеграция с облачными сервисами
Vault — сложнее в настройке (unseal, HA, storage backend)
Managed — дороже при большом количестве секретов

#Best Practices для секретов

Никогда не хардкодьте. Правда, не делайте этого.
Ротация. Пароль от базы должен меняться. Раз в 90 дней — минимум.
Least privilege. Сервис A не должен знать секреты сервиса B.
Audit trail. Логируйте, кто и когда запрашивал какой секрет.
Временные секреты. Если секрет может иметь TTL — пусть он его имеет.

#Supply Chain Security — ваш код не одинок

Помните SolarWinds (2020)? Хакеры скомпрометировали систему сборки SolarWinds и внедрили бэкдор в обновление их Orion-продукта. 18 000 организаций скачали заражённое обновление. Жертвы: Министерство финансов США, Министерство юстиции, десятки Fortune 500.

Это supply chain attack. И вы тоже в зоне риска.

#Что под угрозой

Ваш код зависит от сотен библиотек. Каждая из них — потенциальный вектор атаки:

Компрометация пакета (malicious package)
Устаревшая зависимость с известной CVE
Компрометация инструмента сборки
Компрометация CI/CD пайплайна

#SBOM (Software Bill of Materials)

SBOM — это полный список всех компонентов вашего ПО: библиотек, их версий, лицензий, транзитивных зависимостей. Как список ингредиентов на упаковке продуктов.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "metadata": {
    "component": {
      "name": "my-app",
      "version": "1.2.3"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2"
    },
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21"
    }
  ]
}

Форматы: CycloneDX (OWASP) и SPDX (ISO). CycloneDX стал де-факто стандартом.

Генерировать SBOM можно автоматически:

# Для Node.js
npx @cyclonedx/cyclonedx-npm --output-file bom.json

# Для Go
cyclonedx-gomod -o bom.json -main .

# Docker image
docker buildx imagetools inspect myapp:latest --format '{{ json .SBOM }}'

#Signature Verification

SLSA (Supply chain Levels for Software Artifacts) — это фреймворк для оценки безопасности пайплайна сборки. Уровни от SLSA 1 (начальный) до SLSA 4 (максимальный).

На практике: подписывайте свои образы и артефакты.

# Подписать Docker образ
cosign sign --key cosign.key myapp:latest

# Проверить подпись
cosign verify --key cosign.pub myapp:latest

#Что делать прямо сейчас

Dependency scanning. Dependabot, Snyk, Renovate — автоматическое обнаружение уязвимых зависимостей
Lock files. package-lock.json, go.sum, Cargo.lock — фиксируйте версии
Mirror registries. Не качайте пакеты напрямую из npm/PyPI — используйте зеркало с проверкой
CI/CD security. Не запускайте untrusted код в пайплайне
SBOM generation. Включите в CI/CD генерацию SBOM для каждого релиза

#Zero Trust для микросервисов — доверяй, но проверяй (точнее, не доверяй вообще)

Zero Trust — это не продукт. Это модель безопасности, которая предполагает, что компрометация уже произошла.

#Традиционная модель (Perimeter-based)

Помните старую архитектуру? Внутренняя сеть — доверенная, внешняя — недоверенная. Все, кто внутри корпоративной сети, — «свои». Firewall на границе, а внутри — полное доверие.

Проблема: как только хакер проник внутрь (через VPN, фишинг, уязвимый сервис), он получает доступ ко всему.

#Zero Trust модель

Никому не доверяем по умолчанию. Каждый запрос — верифицирован, авторизован, зашифрован и залогирован.

#Принципы Zero Trust для микросервисов

#mTLS (Mutual TLS)

mTLS — это когда не только клиент проверяет сертификат сервера, но и сервер проверяет сертификат клиента. Оба конца аутентифицируют друг друга.

# Конфигурация mTLS в service mesh (Istio)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: prod
spec:
  mtls:
    mode: STRICT  # все сервисы обязаны использовать mTLS

В режиме STRICT ни один сервис не может общаться с другим без валидного сертификата.

#Service Mesh как реализация Zero Trust

Service Mesh (см. Главу 18) даёт Zero Trust «из коробки»:

mTLS между сервисами — автоматически
Authorization policies — на уровне API
Auditing каждого запроса

# Istio Authorization Policy
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: orders-service-policy
  namespace: prod
spec:
  selector:
    matchLabels:
      app: orders
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/prod/sa/payment-service"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/orders"]

Только payment-service может создавать заказы. Любой другой запрос — denied.

#Где не нужен Zero Trust

Zero Trust — не бесплатно. mTLS добавляет latency, сертификаты нужно ротировать, политики — управлять. Для небольших систем (< 10 микросервисов) — оправдан ли overhead? Чаще всего нет.

Решение: start with perimeter security, добавляйте Zero Trust по мере роста.

#Безопасность AI-агентов — новые векторы угроз

С появлением AI-coding агентов возникают угрозы, которых не было в классической модели безопасности. Они требуют отдельного внимания.

#Least Agency Principle

Агент должен иметь минимально необходимые права для выполнения задачи.

Звучит очевидно. На практике означает:

Агент, редактирующий README, не должен иметь production-доступ
Агент, пишущий код, не должен иметь доступ к secrets management
Каждый запуск агента — в изолированном workspace/sandbox
Права выдаются на задачу, а не на роль

#Data Exfiltration через Skills

Комбинация Skills (процедурных инструкций) + open network access = высокий риск утечки данных. Агент может получить доступ к внутренним данным и отправить их на внешний сервер.

Mitigation: двухуровневая система allowlist:

Организационный уровень: какие домены разрешены в принципе
Запросный уровень: какие домены разрешены для конкретного запроса

#Domain Secrets Pattern

Credentials инжектятся через sidecar (domain_secrets), а не через промпт. Агент не видит сам секрет — только получает доступ к ресурсу.

# Вместо того чтобы давать агенту API-ключ в промпте:
You have the API key: sk-xxx

# Используйте sidecar-инъекцию:
agent --secret db-host --secret api-key
# Агент может подключиться к БД, но не может прочитать/передать ключ

#Инцидент: Agent-to-Agent

Задокументированный случай (Google CTO office, 2026):

AI-агент сгенерировал false URL
Подключился к deprecated legacy agent
Legacy agent отправил false emails 50 коллегам

Урок: изоляция агентов, запрет agent-to-agent communications без approval. Даже если агенты принадлежат одной системе.

#Permission Fatigue

Исследования показывают: пользователи одобряют 93% всех permission prompts. Не потому что 93% запросов осмысленны. А потому что предупреждений слишком много — и люди перестают их читать.

Вывод: диалоговая безопасность не работает. Нужен defense-in-depth:

Sandboxing на уровне инфраструктуры
Auto-mode classifiers (агент сам определяет уровень риска)
Zero Trust для AI-агентов (каждый доступ проверяется, даже если агент «свой»)
Audit trails для всех действий агента

#⚠️ Slopsquatting

Новый тип supply chain атаки, порождённый AI-агентами:

AI-агент подбирает библиотеку для решения задачи
Находит typosquatting-пакет с вредоносным кодом
Устанавливает его без ведома разработчика

Mitigation:

Ограничить реестры, из которых агент может устанавливать пакеты
Использовать lock-файлы (package-lock.json, poetry.lock, Cargo.lock)
Не давать агенту права на npm install / pip install без подтверждения
Dependency scanning на каждый PR (Dependabot, Snyk)
~20% AI-генерированного кода ссылается на несуществующие пакеты (Zenodo, 2026)

#DDoS Protection — когда ваш сервер атакует вся планета

DDoS (Distributed Denial of Service) — это когда злоумышленник отправляет на ваш сервер столько запросов, что он перестаёт отвечать легитимным пользователям. Просто, эффективно, дёшево.

#Типы DDoS-атак

Layer 3/4 (Network): SYN flood, UDP amplification, ICMP flood

Цель: исчерпать сетевые ресурсы
Защита: AWS Shield, Cloudflare Magic Transit

Layer 7 (Application): HTTP flood, Slowloris, запросы к тяжёлым endpoint'ам

Цель: исчерпать вычислительные ресурсы
Защита: WAF, rate limiting, Cloudflare WAF

#Cloudflare — как это работает

Cloudflare использует Anycast-сеть. У них один IP-адрес, но он анонсируется из 300+ датацентров. Атака распределяется по всей сети.

Когда приходит DDoS-атака:

Трафик поступает в ближайший датацентр Cloudflare
Анализируется на уровне edge (не доходя до вашего сервера)
Подозрительный трафик отбрасывается
Чистый трафик — проксируется на ваш origin (или кэшируется на CDN)

flowchart LR
    A[Атакующий] -->|Мусорный трафик| B[Cloudflare Edge]
    B -->|Отбрасывается| X[Корзина]
    C[Реальный пользователь] -->|Чистый трафик| B
    B -->|Проксируется| D[Ваш сервер origin]
    D -->|Ответ| B
    B -->|Кэшированный ответ| C

#AWS Shield

AWS Shield — это встроенная защита от DDoS в AWS. Два уровня:

Shield Standard (бесплатно):

Защита от L3/L4 атак (SYN/UDP floods)
Включена для всех AWS-ресурсов
Автоматическая — ничего настраивать не надо

Shield Advanced ($3000/мес + трафик):

Защита от L7 атак (HTTP floods)
Финансовая защита — AWS компенсирует затраты на масштабирование во время атаки
Dedicated DDoS Response Team (DRT) — 24/7 поддержка
Аналитика и дашборды

#Rate Limiting — первый уровень защиты

# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
    }
}

Честно: rate limiting не остановит мощную DDoS-атаку. Но он отсечёт 90% «бытовых» атак — ботов, scrapers, script kiddies.

#Что делать при DDoS-атаке

Кэш. Чем больше контента вы можете отдать из кэша (CDN), тем меньше нагрузка на origin
Ручной threshold. AWS WAF + rate-based rules
Scaling. Auto-scaling может помочь, но не для всех атак (Layer 7 всё равно съедает capacity)
Звонок провайдеру. Cloudflare, Akamai, AWS — у них есть команды, которые включат защиту вручную

#Penetration Testing как процесс, а не разовая активность

«Мы наймем пентестеров перед запуском» — звучит как план. Но давайте честно: если ваш пентест проходит раз в год, а код вы деплоите каждый день, между проверками вы живёте с открытой уязвимостью.

#Разовые пентесты — прошлый век

Проблемы разовых пентестов:

В день аудита пентестер проверяет атаки, которые уже неактуальны (вы починили ту уязвимость за месяц до)
Через неделю после пентеста вы задеплоили новую фичу — и она уже содержит баг
Результаты пылятся в табличке, никто их не смотрит до следующего аудита

#Continuous Security Testing

Современный подход — интегрировать тестирование безопасности в CI/CD.

SAST (Static Application Security Testing):

Анализ исходного кода без запуска
Инструменты: SonarQube, Semgrep, CodeQL, Checkmarx
Запускается на каждом PR

# GitHub Actions — SAST на каждый PR
name: Security Scan
on: pull_request
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/default  # OWASP Top 10 rules

DAST (Dynamic Application Security Testing):

Анализ работающего приложения
Инструменты: OWASP ZAP, Burp Suite, Acunetix
Запускается на staging/review apps

IAST (Interactive Application Security Testing):

Агент внутри приложения анализирует трафик
Меньше false positives, больше контекста

#Bug Bounty — когда хакеры работают на вас

Bug Bounty программа — вы платите исследователям безопасности за найденные уязвимости. Модель «pay per bug».

HackerOne, Bugcrowd — managed платформы
Цены: от $100 за low до $10,000+ за critical
Лучший ROI в безопасности: вы платите только за результат

Совет

Совет: Bug Bounty не заменяет пентесты. Но дополняет. Разовый пентест — depth, bug bounty — breadth. У вас 1000 хакеров ищут проблемы вместо одной команды.

#Security Compliance — SOC2, PCI-DSS, HIPAA

Compliance (соответствие стандартам) — то, о чём вы узнаёте, когда продаёте enterprise-клиенту и он просит «а SOC2 report у вас есть?».

#SOC2 (Service Organization Control 2)

Стандарт для SaaS-компаний, обрабатывающих данные клиентов. Самый популярный compliance-фреймворк среди технологических компаний.

Критерии SOC2:

Security (обязательно): защита от несанкционированного доступа
Availability, Confidentiality, Processing Integrity, Privacy — опционально

Что нужно сделать:

Контроль доступа (SSO, MFA, least privilege)
Мониторинг и логирование
Incident response plan
Vendor management
Encryption (at rest и in transit)
Физическая безопасность (датацентров)

Уровни:

Type I: «это задокументировано» (дешевле, быстрее)
Type II: «это реально работает в течение N месяцев» (дороже, дольше, но именно его просят enterprise-клиенты)

#PCI-DSS (Payment Card Industry Data Security Standard)

Если вы принимаете кредитные карты — PCI-DSS обязателен.

12 требований группируются по 6 целям:

Build and Maintain a Secure Network
Protect Cardholder Data (encryption!)
Maintain a Vulnerability Management Program
Implement Strong Access Control Measures
Regularly Monitor and Test Networks
Maintain an Information Security Policy

Уровни:

Level 1: > 6M транзакций/год — ежегодный аудит QSA (Qualified Security Assessor)
Level 2-4: меньше транзакций — SAQ (Self-Assessment Questionnaire)

Самое болезненное в PCI-DSS: вы не можете хранить CVV (код с обратной стороны карты) — ни в базе, ни в логах, нигде. Даже временно. Если CVV есть в логах — вы нарушаете compliance.

#HIPAA (Health Insurance Portability and Accountability Act)

Если вы работаете с медицинскими данными в США — HIPAA.

Ключевое: Protected Health Information (PHI) должна быть защищена.

Encryption обязательна
Audit logs — кто и когда смотрел данные пациента
Business Associate Agreements (BAA) с каждым подрядчиком
Breach notification — уведомление в течение 60 дней

#Как не сойти с ума от compliance

Compliance на масштабе — это организационная проблема, а не техническая.

Советы:

Автоматизируйте. Compliance as Code — Osquery, Cloud Custodian, Checkov
Делегируйте. Вам не нужно управлять всем вручную — используйте managed сервисы (AWS имеет PCI/HIPAA/SOC2 аттестацию для многих сервисов)
Не ждите последнего момента. Начать готовиться к SOC2 за месяц до аудита — это боль
Compliance != Security. Можно быть SOC2 compliant и при этом иметь утечку данных. Compliance — минимальный порог, а не гарантия безопасности

#Incident Response — когда всё горит

#Прежде всего: у вас есть план?

Не в голове. Написанный. С контактами. С check-list'ами. С clear ownership.

Если ваш план реагирования: «позвонить Васе, он знает что делать» — у вас нет плана.

#Структура Incident Response (NIST SP 800-61)

1. Preparation

Incident response team (IRT)
Инструменты: SIEM, SOAR, forensic tools
Runbook и playbooks для типовых инцидентов
Communication tree — кто кого оповещает

2. Detection & Analysis

Обнаружение: SIEM alerts, пользователи жалуются, провайдер предупредил
Triage: насколько серьёзно? Какой blast radius?
Документирование: время, детали, действия (каждый шаг)

3. Containment, Eradication & Recovery

Stop the bleeding: отключить скомпрометированный сервис
Forensics: что произошло? Как попали?
Remove access: отозвать ключи, сбросить пароли
Patches: закрыть уязвимость
Restore из backup'ов (которые вы проверяете, правда?)

4. Post-Incident Activity

Post-mortem: что пошло не так? Что сделали правильно?
Action items: что нужно изменить в системе
Без blameless culture: не «кто виноват», а «как система должна измениться»

#Playbook: пример типового инцидента

=== SECURITY INCIDENT PLAYBOOK: Data Breach ===

1. ОБНАРУЖЕНИЕ
   - Кто обнаружил: __________
   - Время: __________
   - Первичные признаки: __________

2. TRIAGE (первые 15 минут)
   - [ ] Подтвердить, что инцидент реален
   - [ ] Определить severity (SEV1/SEV2/SEV3)
   - [ ] Уведомить IRT лида
   - [ ] Завести тикет с хронологией

3. CONTAINMENT (первые 60 минут)
   - [ ] Отключить скомпрометированный сервис от сети
   - [ ] Отозвать все ключи доступа
   - [ ] Заблокировать подозрительные IP на firewall
   - [ ] Сделать snapshot compromised системы (forensics)

4. INVESTIGATION
   - [ ] Проверить логи доступа
   - [ ] Определить scope утечки (какие данные?)
   - [ ] Проверить другие сервисы на признаки компрометации
   - [ ] Связаться с compliance officer

5. COMMUNICATION
   - [ ] Внутреннее: статус C-level каждые 30 минут
   - [ ] Клиенты: если утечка данных — legal review до публикации
   - [ ] Регуляторы: в соответствии с требованиями (GDPR: 72 часа)

6. RECOVERY
   - [ ] Patch уязвимость
   - [ ] Восстановить из backup
   - [ ] Дополнительные проверки безопасности
   - [ ] Вернуть сервис в продакшн (после approval)

7. POST-MORTEM
   - [ ] Timeline инцидента
   - [ ] Root cause analysis
   - [ ] Action items с дедлайнами
   - [ ] Update runbooks

#War Room — когда case открыт

При серьёзном инциденте собирается War Room:

Slack/Discord канал (или Zoom/Google Meet)
Только участники — не нужно оповещать всю компанию
Канал только для коммуникации по инциденту — без флуда
Чёткие роли: commander, investigator, communicator, scribe

#Game Days — не ждите реального инцидента

Game Day — это симуляция инцидента. Вы искусственно создаёте проблему и смотрите, как система и команда реагируют.

«А что если наш сертификат TLS истёк?» — проверяем
«А что если наш secrets manager недоступен?» — проверяем
«А что если атакующий получил доступ к CI/CD?» — проверяем

Game Days не обязаны быть сложными. Начните с малого: один сценарий, 30 минут, одно открытие.

#Кейс: Cloudflare — защита от DDoS в 2 Tbps+

В 2024 году Cloudflare отразила одну из крупнейших DDoS-атак в истории — пиковая мощность превысила 2 терабита в секунду.

#Атака

Тип: HTTP/2 Rapid Reset — новая техника, использующая уязвимость в протоколе HTTP/2
Мощность: > 2 Tbps
Источник: ботнет из тысяч скомпрометированных устройств
Цель: клиент Cloudflare (финансовый сектор)

Атака эксплуатировала саму природу HTTP/2: мультиплексирование запросов. Злоумышленник открывал одно TCP-соединение, отправлял поток запросов и сразу же отменял их (RST_STREAM), заставляя сервер выделять ресурсы на несуществующие запросы.

#Как Cloudflare защитилась

Edge-фильтрация на уровне Anycast. Трафик атаки распределился по всей сети Cloudflare — 300+ датацентров. Ни один датацентр не получил критической нагрузки.
Автоматические WAF-правила. Cloudflare WAF автоматически обновился, блокируя паттерн HTTP/2 Rapid Reset.
Машинное обучение. ML-модель анализировала трафик в реальном времени и отличала легитимные пользовательские запросы от атаки.
Автоматическое кэширование. Cloudflare Edge кэшировал ответы, снижая нагрузку на origin-сервер клиента.

#Ключевой инсайт

Cloudflare не выиграла за счёт «железа» или «толстых каналов». Они выиграли за счёт архитектуры: распределённая Anycast-сеть, интеллектуальная фильтрация на каждом edge node, автоматическое обнаружение аномалий.

Если бы клиент полагался на собственный датацентр — даже с 100 Гбит/с каналом атака в 2 Tbps просто насытила бы линк за доли секунды. Только глобально распределённая инфраструктура может поглотить атаку такого масштаба.

Источники: Cloudflare Blog, Cloudflare Radar

#Чек-лист: готовы ли вы к атаке?

У нас есть WAF перед production-трафиком
Все секреты хранятся в Vault или Secrets Manager (не в репозитории)
Все внешние соединения — только через TLS 1.3
mTLS между микросервисами (или хотя бы шифрование)
Dependency scanning (Dependabot/Snyk) работает и alert'ит
Генерируется SBOM для каждого релиза
Rate limiting настроен на всех публичных endpoint'ах
Есть DDoS-защита (Cloudflare / AWS Shield / провайдер)
Деплой SAST-сканера в CI/CD
Написан Incident Response Plan (не в голове)
Проведён хотя бы один Game Day в этом году
Известны требования compliance (SOC2? PCI-DSS? HIPAA?)
Есть Bug Bounty программа (или хотя бы channel для security research)

#Не делай так

#«У нас всё в облаке, Amazon сам всё защитит»

AWS Shared Responsibility Model — ваш лучший друг и враг. AWS защищает облако, но вы защищаете то, что в облаке. S3 bucket открыт на весь интернет? Это ваша ответственность. RDS без encryption? Ваша. Security group открывает 0.0.0.0/0:3306? Догадались, чья это вина.

Реальная история: Компания оставила S3 bucket открытым. «Там же не было секретных данных, только статика для сайта». В bucket лежал JavaScript с API-ключами. Компрометация за 24 часа. Классика.

#«Мы наняли пентестеров — мы защищены»

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

#«Нам не нужен compliance, мы не банк»

Пока ваши данные не утекли. После утечки — заказчикам будет всё равно, были у вас SOC2 или нет. Compliance — это про доверие. И про то, что вы хотя бы попытались.

#«Пароль? Давайте запишем в .env и забудем»

.env в репозитории — это боль. .env не в репозитории — вы всё ещё рискуете. .env на сервере в plain text — рискуете. Пароль должен быть в secrets manager, с ротацией, audit trail и временным доступом.

#«soc2-is-easy.py»

Видел однажды скрипт, который «автоматизирует прохождение SOC2». Спойлер: compliance — это процесс, а не галка в чек-боксе. Никакой скрипт не создаст культуру безопасности. А без культуры — compliance report ничего не стоит.

#Ключевые выводы

Defense in Depth — единственная работающая стратегия. Никогда не полагайтесь на один уровень защиты. Предполагайте, что каждый уровень может быть скомпрометирован, и стройте следующий.
Безопасность — это процесс, не проект. Разовый пентест, однократный security review, compliance audit раз в год — этого недостаточно. Continuous security — SAST в CI/CD, dependency scanning на каждый PR, security monitoring 24/7.
Zero Trust — это про архитектуру, не про продукт. Не покупайте «Zero Trust solution». Стройте архитектуру, где каждый запрос верифицирован, авторизован и залогирован.
Secrets management — базовая гигиена. Если у вас пароль от продакшн-базы лежит в Git — остановитесь и исправьте это. Всё остальное можно делать после.
Incident Response — самый важный документ, который вы никогда не хотите использовать. Но когда придётся — вы будете рады, что он есть. Напишите playbook, проведите Game Day, соберите контакты. До инцидента.

Forward reference: С появлением AI-coding агентов возникают новые векторы угроз: slopsquatting, agent-to-agent атаки, permission fatigue. Zero Trust архитектура становится обязательной и для AI-агентов. См. Главу 37 «Анти-паттерны AI-assisted разработки» (раздел «Безопасность AI-агентов»).