Урок 15: Введение в облачную безопасность — идентичность и есть новый периметр
До сих пор мы говорили о защите в терминах физической сети: периметр, внутренняя зона, серверы в серверной. Этот урок переносит нас на арену, где большинство этих допущений больше не работают, — облачные вычисления. «Сервер» больше не ваш, он стоит на чужом оборудовании, и вокруг него нельзя построи
Вкратце: в облаке нет физической стены, на которую можно положиться, поэтому новой границей становится идентичность — то, кто вы, а не откуда вы подключились. Ответственность разделена: провайдер охраняет оборудование и доступность, а вы охраняете свою конфигурацию, идентичности и данные — на каждом уровне IaaS/PaaS/SaaS. И большинство взломов в облаке — это не изощрённый взлом, а просто случайно оставленная открытой дверь.
- Облачные вычисления и модель On-Demand
- Модель, обеспечивающая удалённый доступ к вычислительным ресурсам (серверы, хранилище, базы данных, сети) через интернет, по требованию (on-demand) и с оплатой по факту использования (pay-as-you-go) — без необходимости владеть и обслуживать физические серверы на площадке организации.
- Старый против нового подхода: идентичность и есть новый периметр
- В старом подходе безопасность опиралась на физическое местоположение — внутри файрвола означало «доверенный», снаружи означало «подозрительный»; проблема: злоумышленник, прошедший стену, мог свободно перемещаться внутри. В новом подходе, когда сотрудники используют SaaS, работают из дома, а сам сервер находится в облаке, — сеть больше не является надёжной границей. Постоянным остаётся то, «кто» пытается получить доступ к информации, поэтому защита сместилась от защиты сети к защите идентичности.
- Компоненты нового периметра: MFA, контекст и минимум привилегий
- Вместо вопроса «из какой сети вы подключаетесь» система задаёт вопросы об идентичности перед каждым действием: строгая аутентификация (MFA — одного пароля недостаточно), контекстно-зависимый доступ (то ли это известное устройство, разумная страна, подходящее время суток) и минимум привилегий — даже после аутентификации доступ предоставляется только к тому, что требуется для работы.
- Zero Trust (нулевое доверие)
- Допущение, что даже внутри корпоративной сети никому не доверяют по умолчанию — каждый запрос на доступ перепроверяется так, будто он пришёл из публичного интернета, без фиксированной «доверенной зоны», которой доверяют автоматически.
- Модель разделяемой ответственности: Security OF против IN the Cloud
- Ответственность в облаке разделяется по слоям — ни провайдер не отвечает за всё, ни клиент. Security OF the Cloud (ответственность провайдера): физическая безопасность дата-центров, электропитание и охлаждение, оборудование, слой виртуализации (гипервизор) и глобальная доступность (Regions/Availability Zones). Security IN the Cloud (ответственность клиента): управление идентичностью и доступом (IAM), защита данных и шифрование, а также конфигурация сервисов.
- IaaS, PaaS и SaaS: градиент ответственности
- IaaS (например, EC2): провайдер даёт серверы, хранилище и сеть; клиент управляет ОС, сервисами и приложениями — очень высокая ответственность клиента. PaaS (например, RDS): провайдер добавляет также ОС и среду выполнения; клиент сосредоточен на коде и бизнес-логике. SaaS (например, Gmail): провайдер предоставляет готовое приложение; клиент лишь пользуется сервисом — но по-прежнему отвечает за управление пользователями, MFA и предотвращение утечки данных.
- Типы развёртывания облаков: приватное, публичное, гибридное и мульти-облако
- Приватное облако: инфраструктура, выделенная одной организации — полный контроль, но дорого в создании и обслуживании. Публичное облако: инфраструктура, разделяемая между организациями с логическим разделением, оплата по факту использования и эластичность (масштабирование вверх/вниз по мере необходимости). Гибридное облако: сочетание обоих — чувствительные данные остаются на площадке, гибкие нагрузки переносятся в публичное облако. Мульти-облако: использование нескольких публичных облачных провайдеров одновременно, чтобы избежать vendor lock-in, ради резервирования и регулирования.
- Multi-tenancy против Single-tenancy
- В публичном облаке (multi-tenant) виртуальные серверы, принадлежащие десяткам разных организаций, могут работать на одном физическом сервере — логическое разделение существует, но физические ресурсы общие. В приватном облаке (single-tenant) организация-«арендатор» единственная на оборудовании.
- Misconfiguration — угроза №1 в облаке
- Большинство инцидентов облачной безопасности — это не взлом сложной технологии, а человеческая ошибка в настройках — например, оставленное открытым хранилище S3 с публичным доступом для всего мира — из-за недостатка осведомлённости или нечёткой политики безопасности.
- Облачная сеть, данные и управление: VPC, жизненный цикл данных и суверенитет
- VPC (Virtual Private Cloud) — это частная изолированная сеть внутри публичного облака, разделённая на публичные подсети (для сервисов, обращённых в интернет) и приватные подсети (для чувствительных баз данных). Внутри неё NACL работает на уровне сети (stateless — проверяется независимо от того, кто инициировал, уже изучено в уроке 12), в отличие от Security Group, который работает на уровне сервера (stateful — проверяется на основе того, кто инициировал соединение). Жизненный цикл данных требует защиты в трёх состояниях: at rest (на диске — шифрование), in transit (в сети — SSL/TLS) и in use (в памяти во время обработки). Без логов (таких как CloudTrail), фиксирующих кто/что/когда/откуда, невозможно провести расследование. А выбор Region также определяет соответствие регуляторным требованиям (таким как GDPR) и суверенитет данных.