Модель разделённой ответственности
Провайдер защищает платформу; вы защищаете то, как её используете — и граница смещается с IaaS, PaaS и SaaS. Доминирующий сбой — не 0-day, а ваша собственная неверная конфигурация. Identity — это новый периметр; радиус поражения — ключевая метрика.
Команда выкатывает фичу аналитики. Данные попадают в S3-бакет, приложение их читает, все идут дальше. Через восемь месяцев приходит письмо от исследователя безопасности: бакет доступен на чтение всему миру и уже проиндексирован публичным сканером. Внутри — шесть миллионов записей о клиентах. Никто не отключал шифрование, никого не фишили, не эксплуатировали ни одной CVE — кто-то оставил политику бакета на "Principal": "*", потому что предположил, что облако «само защищает хранилище». Провайдер действительно защитил диски, дата-центр и гипервизор. Но политику бакета писать должны были не они. Именно этот зазор — между тем, что запускает провайдер, и тем, что настраиваете вы, — и есть место, где живёт большинство облачных утечек.
К концу этого урока вы будете точно знать, где проходит граница ответственности «клиент против провайдера» на IaaS, PaaS и SaaS, и почему неверная конфигурация на вашей стороне этой границы — а не 0-day — это тот сбой, от которого вы будете защищаться всю карьеру.
Граница и почему она смещается
Каждое крупное облако формулирует безопасность одинаково: безопасность самого облака — забота провайдера; безопасность внутри облака — ваша. AWS называет это моделью разделённой ответственности (Shared Responsibility Model), у Azure и Google почти идентичные версии. Провайдеру принадлежат физический дата-центр, оборудование, гипервизор и софт управляемых сервисов, которые он запускает для вас. Вам принадлежат ваши данные, ваши identity и политики доступа, ваши сетевые правила и — в зависимости от сервиса — операционная система и код приложения поверх.
Ловушка — считать эту границу неподвижной. Это не так: чем более управляемый сервис, тем большую часть стека провайдер берёт на себя и тем меньше остаётся вам. В этом и весь смысл спектра IaaS → PaaS → SaaS.
- IaaS (сырой EC2-инстанс, голая ВМ): вы получаете примитивы compute, хранилища и сети. Провайдер защищает гипервизор и всё ниже; всё от гостевой ОС и выше — ваше: патчинг, runtime, приложение, данные и обвязка из IAM и сетевой конфигурации вокруг них.
- PaaS (управляемая платформа приложений, serverless-функция, управляемая БД): провайдер также запускает и патчит ОС и runtime. Вы перестаёте думать о CVE в ядре, но по-прежнему владеете своим кодом, данными и — что критично — конфигурацией доступа и сети.
- SaaS (готовый продукт вроде размещённой CRM): провайдер запускает почти весь стек. Ваша ответственность сжимается до данных и конфигурации identity/доступа — кто может входить, с какими правами и как.
Обратите внимание на один столбец, который ни на одном уровне не переходит к провайдеру: данные и identity всегда ваши. Это самое важное прочтение всей модели.
| Слой | IaaS (сырая ВМ) | PaaS (управляемый runtime) | SaaS (готовый продукт) |
|---|---|---|---|
| Данные (ваши) | Клиент | Клиент | Клиент |
| IAM / политика доступа | Клиент | Клиент | Клиент |
| Сетевая конфигурация | Клиент | Клиент | Провайдер* |
| Приложение | Клиент | Клиент | Провайдер |
| Runtime | Клиент | Провайдер | Провайдер |
| Операционная система | Клиент | Провайдер | Провайдер |
| Compute / виртуализация | Провайдер | Провайдер | Провайдер |
*В SaaS сеть запускает провайдер, но вы по-прежнему настраиваете доступ на уровне тенанта и любые доступные вам настройки IP/allowlist. Данные и IAM не переходят к провайдеру ни на одном уровне.
Identity — это новый периметр
В дата-центре периметр был местом: фаервол, VLAN, запертая стойка. Внутри было доверенно, снаружи — враждебно, и «безопасность» в основном означала охрану края. Облако стирает эту географию. Ваши сервисы, хранилища данных и management plane достижимы через интернет по API, и единственное, что стоит между запросом и вашими ресурсами, — это то, кем запрос себя докажет, и то, что этому identity разрешено делать.
Так что периметр сместился. Это больше не сетевая граница, на которую можно показать пальцем, — это набор identity (пользователи, роли, сервис-аккаунты, ключи доступа) и привязанные к ним политики. Утёкший ключ доступа, чрезмерно широкая IAM-роль, сервис-аккаунт с *:* или неаутентифицированный эндпоинт и есть путь пробоя. Внутренней сети, на которую можно откатиться, нет. Поэтому «identity — это новый периметр» — не лозунг, а буквальное описание того, где теперь стена; и именно поэтому следующий юнит этого трека — про IAM.
Практическое следствие — минимальные привилегии как рефлекс по умолчанию: каждый identity получает ровно те права, которые ему реально нужны, ограниченные конкретными ресурсами и действиями, и ничего сверх того. Wildcard-политика — это не удобство, а заранее подготовленный пробой.
Доминирующий сбой — неверная конфигурация, а не 0-day
Вот сеньорское переосмысление облачной безопасности. Заголовки кричат «взлом», и вы представляете гениальный эксплойт. Реальность почти всегда скучнее и целиком на вашей стороне границы: оставленный публичным бакет, IAM-политика с wildcard, база без аутентификации на публичном IP, security group, открытая на 0.0.0.0/0, секрет, закоммиченный в репозиторий, дефолтные учётки, которые так и не сменили. Отраслевые разборы и рекомендации провайдеров год за годом сходятся на одном выводе — подавляющее большинство облачных утечек данных восходит к неверной конфигурации клиента, а не к уязвимости в платформе провайдера. Широко цитируемая формулировка Gartner: до 2025 года подавляющее большинство сбоев облачной безопасности будет виной клиента. Сторона провайдера, честно говоря, укреплена куда лучше, чем большинство команд способно укрепить собственный дата-центр.
Это меняет то, куда уходят усилия. Вы не охотитесь прежде всего за новыми эксплойтами; вы следите, чтобы скучные контроли были корректны и оставались корректными: каждый бакет приватен по умолчанию, каждая IAM-политика сужена, каждое сетевое правило обосновано, каждый секрет — в менеджере секретов. Поэтому остальная часть этого трека — про posture (непрерывную проверку того, что ваша сторона границы настроена именно так, как вы думаете) гораздо больше, чем про экзотические атаки.
▸Почему это работает
Почему сторона клиента настолько слабее стороны провайдера при тех же инженерах? Потому что провайдер настраивает одну укреплённую платформу миллионы раз с глубокой автоматизацией и выделенной службой безопасности, тогда как каждый клиент изобретает свою конфигурацию под давлением дедлайнов, с широкими дефолтами, которые предпочитают «работает» вместо «закрыто наглухо». Новый бакет легко сделать публичным; новой роли легко выдать *. Модель не делает вас менее защищёнными — она вручает вам мощный острый инструмент и доверяет держать его правильно. Большинство утечек — это кто-то порезавшийся.
Радиус поражения: метрика, которая всё связывает
Минимальные привилегии — не самоцель, а способ управлять радиусом поражения (blast radius): масштабом ущерба, когда (не если) один identity, ключ или компонент будет скомпрометирован. Исходите из того, что любой отдельный credential рано или поздно утечёт. Вопрос, который важен: когда это случится, до чего сможет дотянуться атакующий?
- Утёкший ключ, ограниченный чтением одного бакета, раскрывает один бакет.
- Утёкший ключ с
AdministratorAccessраскрывает весь аккаунт.
Та же утечка — кардинально разные исходы, и разница целиком в правах, которые вы выдали заранее. Это сквозная линия всего трека: сужение IAM, изоляция контейнеров, infrastructure-as-code, проверенный до выкатки, и сканирование posture существуют ради того, чтобы радиус поражения оставался малым. Вы проектируете так, будто компрометация неизбежна, потому что на масштабе она именно такова, и следите, чтобы цена любой отдельной компрометации оставалась локализованной.
- 01Объясните модель разделённой ответственности и как граница «клиент против провайдера» смещается на IaaS, PaaS и SaaS.
- 02Почему «identity — это новый периметр» и почему неверная конфигурация, а не 0-day, — доминирующий облачный сбой?
Модель разделённой ответственности делит облачную безопасность на безопасность самого облака (задача провайдера: дата-центр, оборудование, гипервизор и управляемые ОС/runtime на верхних уровнях) и безопасность внутри облака (ваша). Граница не фиксирована — она сползает вниз по стеку к провайдеру по мере перехода от IaaS к PaaS и к SaaS, — но два слоя её никогда не пересекают: ваши данные и ваша конфигурация IAM/доступа всегда ваши. Поскольку ресурсы достижимы по API без внутренней доверенной сети, identity становится новым периметром: утёкший ключ или чрезмерно широкая роль — это путь пробоя, поэтому минимальные привилегии — рефлекс по умолчанию. А доминирующий облачный сбой — не 0-day в платформе провайдера (та сторона укреплена лучше, чем вы могли бы справиться), а неверная конфигурация на вашей стороне: публичный бакет, wildcard-политика, открытая security group. Метрика, которая всё связывает, — радиус поражения: вы сужаете каждый identity и ресурс так, будто компрометация неизбежна, чтобы, когда один credential утечёт, он дотянулся до как можно меньшего. Эта сквозная линия — минимальные привилегии ради сдерживания радиуса поражения — и есть то, на чём строятся юниты по IAM, контейнерам, infrastructure-as-code и posture этого трека.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.
Примени это
Примени этот урок в реальном проекте.