Безопасность облачных сетей

Как устроена сеть в облаке и почему большинство облачных утечек — это не «взлом», а неправильно настроенный доступ.

VPC (Virtual Private Cloud) — изолированная виртуальная сеть внутри облака с собственным диапазоном адресов, подсетями и правилами трафика, которой вы управляете как своим дата-центром.

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

Зачем это знать защитнику

Подавляющее большинство громких облачных инцидентов — не эксплойты нулевого дня, а мисконфиги: публичный bucket, security group с правилом 0.0.0.0/0 на порт базы, забытый административный интерфейс. Защитник в облаке — это во многом инженер конфигурации: он проектирует сеть так, чтобы ошибка не приводила к катастрофе, и автоматически ловит опасные настройки.

Строительные блоки облачной сети

VPC и подсети

VPC задаёт частное адресное пространство (например, 10.0.0.0/16) и делится на подсети. Ключевое разделение — публичные и приватные подсети.

Публичная подсеть имеет маршрут в интернет-шлюз. Сюда выносят только то, что обязано быть доступно снаружи: балансировщик, реверс-прокси.
Приватная подсеть не имеет прямого маршрута из интернета. Здесь живут серверы приложений и, главное, базы данных. Исходящий доступ к интернету (за обновлениями) даётся через NAT-шлюз — он выпускает наружу, но не впускает входящие соединения.

Базы данных и внутренние сервисы никогда не должны жить в публичной подсети. Это первое правило облачной сетевой гигиены.

Security groups и network ACL

Security group (SG) — это файрвол на уровне самого ресурса (виртуальной машины, базы). Он stateful: если вы разрешили входящее соединение, ответ уходит автоматически. Правила — это «что разрешено» (по умолчанию запрещено всё). Network ACL работает на уровне подсети, он stateless (нужно описывать оба направления) и умеет явные deny — это грубый внешний эшелон.

# Концепт правил security group для веб-сервера (псевдоформат)
# Разрешаем HTTPS снаружи и SSH только из админ-сети
INGRESS  tcp  443   from 0.0.0.0/0           # сайт доступен всем
INGRESS  tcp  22    from 203.0.113.10/32     # SSH только с одного админ-IP
EGRESS   all                                 # исходящее по необходимости
# Базы — отдельная SG: порт БД открыт ТОЛЬКО для SG приложения,
# а не для 0.0.0.0/0
INGRESS  tcp  5432  from sg-app               # ссылка на группу, не на весь мир

Обратите внимание на последнюю строку: правило ссылается не на диапазон адресов, а на другую группу безопасности. Так база принимает соединения только от серверов приложения, и при масштабировании ничего переписывать не нужно.

Сегментация в облаке

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

По уровням приложения (tiers): web → app → data. Каждый уровень в своей подсети, со своей SG; data-уровень принимает трафик только от app, а не от web напрямую.
По окружениям: prod, staging и dev — в разных VPC или хотя бы строго разделённых подсетях, без сквозных правил между ними.
Микросегментация: минимальные разрешения между конкретными сервисами, а не «вся подсеть видит всю подсеть».

Через всё это проходит принцип наименьших привилегий: открыт только тот порт, только тому источнику и только туда, где это реально нужно.

Как это работает под капотом

Облачная сеть — программно-определяемая (SDN): «маршрутизаторы», «файрволы» и «подсети» — это записи в конфигурации платформы, а не железо. Поэтому, во-первых, всё описывается кодом (Terraform, CloudFormation) и проходит ревью, как обычный pull request. Во-вторых, security group — это не сетевой бутылочный горлышко, а фильтр, применяемый к интерфейсу каждого ресурса, поэтому он масштабируется автоматически. В-третьих, доступ к самому облаку (кто может менять правила) — это уже IAM, и слабая IAM-политика сводит на нет любую сетевую сегментацию: если злоумышленник получил права менять SG, он сам себе откроет дверь.

Как защититься от мисконфигов

Запрещено по умолчанию. Начинайте с пустых правил и добавляйте минимум. Никаких 0.0.0.0/0 на административные порты (SSH/RDP, порты БД).
Базы и внутренние сервисы — в приватных подсетях, без публичного IP. Доступ к ним — по ссылке на SG, не по адресу.
Инфраструктура как код + ревью. Изменения сети проходят через репозиторий и проверку — труднее «по-быстрому открыть порт» в проде.
Автоматический аудит конфигурации (CSPM). Инструменты непрерывно сканируют облако на опасные настройки: публичные бакеты, открытые порты, отсутствие шифрования. Это ловит человеческие ошибки до атакующего.
VPC Flow Logs. Включите журналирование сетевых потоков — без него вы не увидите ни разведку, ни эксфильтрацию, ни источник инцидента.
Сильная IAM. Право менять сетевые правила — только у тех, кому положено; MFA, наименьшие привилегии, регулярный пересмотр.

Это лабораторно-образовательный материал: экспериментируйте только в своих аккаунтах. Несанкционированный доступ к чужой облачной инфраструктуре наказуем (УК РФ ст. 272/274).

Итоги

VPC — это ваша частная сеть в облаке; делите её на публичные и приватные подсети, а базы держите только в приватных.
Security group — stateful-файрвол ресурса с логикой «запрещено по умолчанию»; ссылайтесь на другие SG вместо диапазонов адресов.
Сегментируйте по уровням (web/app/data) и окружениям (prod/stage/dev), применяя наименьшие привилегии.
Главная облачная угроза — мисконфиг, а не эксплойт; защищают инфраструктура-как-код, CSPM-аудит, Flow Logs и сильная IAM.