4.3 Безопасность инфраструктуры и облака

Обзор и мотивация

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

Для больших корпораций облачная инфраструктура охватывает нескольких провайдеров, тысячи учётных записей и смесь управляемых сервисов, контейнеров и бессерверных функций. Поверхность атаки не статичный периметр. Это живое, разрастающееся собрание ресурсов и идентичностей. Для государства та же сложность встречается со строгими режимами авторизации, мандатами местонахождения данных и границами классификации, определяющими каждый архитектурный выбор. В обоих случаях слой идентичности стал новым периметром: кто что может делать, с каким ресурсом, при каких условиях.

Эта глава охватывает, как защищать этот фундамент: управление идентификацией и доступом (IAM), сегментация сети, шифрование и управление ключами, безопасность контейнеров и бессерверных нагрузок и непрерывное управление состоянием защищённости, не дающее быстро меняющемуся облачному хозяйству сползти в опасность.

Ключевые принципы

Идентичность это периметр. Решения о доступе опираются на сильную идентичность и тонкую авторизацию, а не расположение в сети.
Наименьшие привилегии, всегда. Каждая идентичность, человеческая или машинная, получает минимум нужных разрешений и не больше.
Сегментируйте для сдерживания. Разделяйте сети и нагрузки, чтобы компрометация в одной области не могла свободно распространяться.
Шифруйте повсюду. Защищайте данные при передаче и в покое по умолчанию, с хорошо управляемыми ключами.
Неизменяемое и декларативное. Определяйте инфраструктуру как код (IaC), разворачивайте неизменяемо и воспринимайте дрейф как дефект.
Непрерывная проверка. Состояние защищённости не разовый аудит; сканируйте и принуждайте непрерывно.
Безопасная конфигурация по умолчанию. Состояние любого ресурса по умолчанию должно быть закрытым, а не открытым.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
RBAC	Просто, понятно, легко проверять	Грубо, взрыв ролей в масштабе
ABAC	Тонко, с учётом контекста, масштабируется с метками	Сложно проектировать и осмыслять
Ключи под управлением провайдера (KMS)	Легко, интегрировано, малое эксплуатационное бремя	Провайдер хранит ключи; меньше контроля
Ключи под управлением клиента/HSM	Полный контроль, соответствует строгим мандатам	Эксплуатационные накладные расходы, риск потери ключей
Предотвращающие ограждения	Останавливают неверную настройку до её возникновения	Могут блокировать законную работу, требуют настройки
Только обнаруживающий CSPM	Гибко, не блокирует	Ущерб может случиться до обнаружения
Микросегментация	Сильная локализация бокового перемещения	Эксплуатационная сложность, расползание политик

Доминирующий компромисс это контроль против эксплуатационного бремени. Более жёсткие средства контроля (ключи под управлением клиента, строгая микросегментация, ABAC) снижают риск, но требуют экспертизы и сопровождения, которые малым командам трудно выдерживать. Правильный уровень зависит от того, насколько чувствительны данные и какие нормы применяются. Прагматичный подход накладывает сильные безопасные умолчания для всех, затем оставляет дополнительную строгость для самых рискованных систем и отдаёт предпочтение автоматическим ограждениям, делающим безопасный выбор значением по умолчанию, а не ручной дисциплиной.

Вопросы для обсуждения с командой

Где вы проведёте жёсткие границы учётных записей или проектов и что принадлежит внутрь каждой? Выделенные учётные записи и проекты создают сильнейшую локализацию, какую предлагает облако, так что компрометация в разработке не может достичь эксплуатации, а одно бизнес-подразделение не может коснуться данных другого. Решите схему границ, прежде чем ваше хозяйство вырастет до тысяч учётных записей, потому что дооснащение изоляцией плоской структуры медленно и рискованно. Для корпоративной и государственной работы эти границы также чисто отображаются на разделение сред, классификацию данных и пределы радиуса поражения, которые ожидают увидеть аудиторы. Принесите текущую диаграмму того, какие нагрузки сегодня делят учётную запись, и отметьте, где одна избыточно широкая роль охватывает эксплуатацию и не-эксплуатацию. Если чувствительные данные лежат в той же учётной записи, что экспериментальные нагрузки, эту границу нужно исправить первой.
Каков ваш стандарт того, кто может управлять ключами против того, кто может получать доступ к зашифрованным данным? Шифрование сильно лишь настолько, насколько сильно управление ключами, а разделение хранения ключей и доступа к данным превращает вашу KMS в точку принуждения разделения обязанностей. Решите, кто может создавать, ротировать и использовать ключи, и убедитесь, что это множество не пересекается с теми, кто может читать данные, которые эти ключи защищают. Для регулируемых и государственных систем это нередко определяет выбор между ключами под управлением провайдера и ключами под управлением клиента или HSM, несущими больше контроля и больше эксплуатационного риска потери ключей. Принесите ваши текущие политики ключей и проверьте, может ли какая-либо одна идентичность и управлять ключом, и читать данные за ним, потому что это частый молчаливый пробел. Если хранение и доступ не разделены, шифрование в покое защищает вас меньше, чем предполагает панель.
Как вы сделаете безопасные умолчания неизбежными в вашей посадочной зоне, а не просто рекомендуемыми? Неверная настройка, а не экзотические эксплойты, ведущая причина облачных взломов, а исправление это предотвращающие ограждения, блокирующие публичную базу данных или нешифрованное хранилище до их появления, а не оповещения постфактум. Решите, какие политики вы будете принуждать при развёртывании (нет публичного хранилища, шифрование включено по умолчанию, обязательные метки), а какие только обнаруживать и сообщать. Для большой команды закладывание их в посадочные зоны и шаблоны инфраструктуры-как-кода означает, что каждая новая учётная запись наследует защиту без усилий на команду, превращая безопасность из повторяющегося налога в разовое вложение. Принесите находки неверных настроек за последний месяц и спросите, какие из них предотвращающее ограждение остановило бы сразу. Если ваше управление состоянием защищённости только обнаруживающее, ущерб может случиться до того, как кто-либо увидит оповещение, поэтому переносите проверки наибольшего воздействия в предотвращение.
Как вы устраните долгоживущие статические учётные данные, не сломав автоматизацию, тихо от них зависящую? Встроенные ключи доступа, никогда не истекающие, среди самых частых причин облачных взломов, потому что один утёкший ключ в скрипте, журнале или репозитории вручает атакующему долговременный доступ. Конкурирующее тяготение эксплуатационное: унаследованные задания CI, задачи cron и сторонние интеграции нередко предполагают наличие статического ключа, а переход на краткоживущие токены или федерацию идентичности нагрузок требует инженерного времени, которое никто не запланировал. Для большой команды общий путь миграции (выдавать токены автоматически, задать стандарт истечения и оповещать о любом новом долгоживущем ключе) не даёт каждой группе изобретать собственный более слабый ответ. Принесите опись каждых статических учётных данных в использовании, их возраст, радиус поражения и может ли питаемая ими система принять федеративную идентичность уже сегодня. В корпоративной и государственной среде привяжите срок к циклам аудита и авторизации, потому что учётные данные, переживающие создавшего их человека, именно та находка, что останавливает непрерывную авторизацию.
Когда ресурс неверно настроен или ключ скомпрометирован, как быстро вы можете обнаружить, локализовать и устранить это и измеряли ли вы это? Публичное хранилище или избыточно широкая роль опасны настолько, насколько долго остаётся открытым окно, поэтому среднее время обнаружения и устранения это число, действительно ограничивающее вашу экспозицию. Напряжение между предотвращающими ограждениями, останавливающими ошибку при развёртывании, и обнаруживающим управлением состоянием защищённости, ловящим проскользнувшее, и вам нужны честные числа по обоим, а не успокоительное допущение, что ограждения покрывают всё. Принесите находки неверных настроек и дрейфа за последний квартал с временными метками, медианное время от внесения до устранения и запись репетиции ротации при компрометации ключа. Для корпоративных и государственных хозяйств на тысячи учётных записей договоритесь, кто владеет устранением находки, которой очевидно не владеет ничья команда, потому что оповещение без ответственного исполнителя оповещение, старящееся до инцидента.
Как вы сохраните согласованность состояния защищённости по нескольким облакам, учётным записям и командам, не замедлив всех до ползания? Хозяйства из нескольких облаков и многих учётных записей быстро дробятся: у каждого провайдера своя модель IAM, свои умолчания и свои инструменты состояния защищённости, поэтому политика, принуждаемая в одном месте, молча отпадает в другом. Компромисс между центральным контролем, гарантирующим согласованность, и локальной автономией, позволяющей командам двигаться быстро, и перегиб в любую сторону либо создаёт узкое место в поставке, либо позволяет стандартам дрейфовать. Принесите текущую карту покрытия: какие учётные записи наследуют ограждения посадочной зоны, какие неуправляемы и где одно и то же средство контроля выражено тремя разными способами по провайдерам. Для большой или публичной организации добавьте угол аудита, потому что аудиторы ожидают один защищаемый стандарт, применяемый повсюду, а средство контроля, существующее в вашем основном облаке, но не во вторичном, пробел, который решительный атакующий или оценщик найдёт первым.

Взгляд по секторам

Стартап. Побеждают скорость и выживание, поэтому опирайтесь целиком на безопасные умолчания, идущие бесплатно: шифрование в покое включено, хранилище частное, пока человек его не откроет, MFA на корневой учётной записи и встроенная идентичность нагрузок провайдера вместо вставленных ключей доступа. Не поднимайте платформу CSPM и не собирайте вручную микросегментацию, которую не можете сопровождать; единственное ограждение, блокирующее базу данных, открытую в интернет, покупает большую часть защиты за полдня работы. Держите всё в инфраструктуре-как-коде с самого начала, чтобы укрепление масштабировалось с вами, а не становилось поздней переписью.

Малый бизнес. Без выделенного инженера по безопасности и при ограниченном бюджете предпочитайте управляемые сервисы, чьи умолчания уже укреплены, а управление ключами обеспечивается за вас, вместо построения собственной дисциплины KMS. Воспринимайте облачную безопасность как вопрос гигиены конфигурации: знайте, какие хранилища и базы данных существуют, держите их частными, требуйте MFA и включайте родные проверки состояния защищённости провайдера, которые идут без дополнительной платы. Покупая инструменты, предпочитайте те, что из коробки отмечают публичную экспозицию и нешифрованное хранилище, потому что эти две ошибки вызывают большинство предотвратимых взломов.

Крупная организация. Настоящая проблема согласованность по тысячам учётных записей и многим командам, поэтому работа платформенная: посадочные зоны, разворачивающие каждую учётную запись укреплённой, ограждения, принуждаемые как политика-как-код, и CSPM, непрерывно сканирующий дрейф. Стандартизируйте модель IAM, правила хранения ключей и базовую сегментацию, чтобы группы перестали изобретать более слабые версии, и измеряйте состояние защищённости по хозяйству, а не верьте слову каждой команды. Бюджетируйте постоянную инженерию по поддержанию политик актуальными по мере того, как провайдеры добавляют сервисы, а хозяйство растёт.

Государственный сектор. Правила закупок, мандаты местонахождения данных и режимы авторизации определяют каждый выбор, поэтому средства контроля служат и свидетельствами аудита. Отдавайте предпочтение управлению ключами, валидированному по FIPS, с хранением, отделённым от доступа к данным, изолированным регионам, держащим данные внутри национальных границ, и подписанным сканированным образам контейнеров со строгим контролем допуска. Публикуйте меры защиты, какие можете, подавайте непрерывное управление состоянием защищённости прямо в продолжающуюся авторизацию и требуйте от поставщиков раскрывать свои умолчания конфигурации и поддерживать средства сегментации и хранения ключей, которых требуют ваши границы классификации.

Примеры

Стартап. Небольшой стартап запускает всё в одной облачной учётной записи и не может укомплектовать платформенную команду, поэтому опирается на умолчания, поставляемые безопасными: шифрование в покое включено по умолчанию, хранилища частные, пока человек явно их не откроет, и MFA обязательна на корневой учётной записи. Вместо долгоживущих ключей доступа, вставленных в CI, он использует встроенную идентичность нагрузок провайдера, так что конвейер получает краткоживущие учётные данные автоматически. Единственное бесплатное ограждение, отмечающее любую базу данных, открытую в интернет, спасает их от самой частой и самой дорогой облачной ошибки ценой одного дня на настройку.

Крупная организация. Медиакомпания, ведущая тысячи учётных записей у двух облачных провайдеров, принуждает шаблон посадочной зоны: каждая учётная запись разворачивается из шаблона с шифрованием в покое по умолчанию, без публичного доступа к хранилищу, с обязательными метками и базовым набором политик ограждений. CSPM непрерывно сканирует дрейф, а федерация идентичности нагрузок устранила долгоживущие ключи для систем CI. Когда разработчик случайно пытается открыть базу данных в интернет, предотвращающая политика блокирует изменение и автоматически заводит заявку.

Государственный сектор. Ведомство, близкое к обороне, работает в изолированном облачном регионе, где местонахождение данных принуждается политикой, так что никакие данные не покидают национальных границ. Самые чувствительные ключи живут в HSM, валидированных по FIPS (Federal Information Processing Standards), с хранением ключей, отделённым от доступа к данным ради принуждения разделения обязанностей. Кластеры Kubernetes используют строгие сетевые политики и контроль допуска; каждый образ контейнера сканируется и подписывается до того, как ему разрешено работать. Непрерывное управление состоянием защищённости напрямую питает свидетельства продолжающейся авторизации ведомства.

Бизнес-обоснование: мотивы, ROI и TCO

Безопасность облачной инфраструктуры это место, где малое вложение отводит катастрофические потери уровня заголовков. Совокупная стоимость владения включает инструменты CSPM, службы управления ключами, инженерное время на проектирование IAM с наименьшими привилегиями и сегментации и постоянные усилия по поддержанию политик актуальными. Эти затраты реальны, но скромны. Цена пропуска один неверно настроенный ресурс, открывающий всю базу данных клиентов, вместе с регуляторными штрафами, затратами на уведомление и длительным ущербом бренду, которые следуют. Взломы из-за неверной облачной настройки среди самых частых и самых предотвратимых инцидентов в отрасли.

Автоматизация и повторное использование усиливают отдачу. Закладывайте безопасные умолчания в посадочные зоны и шаблоны инфраструктуры-как-кода, и каждая новая учётная запись и нагрузка наследует защиту без усилий на команду, превращая безопасность из повторяющегося ручного налога в разовое платформенное вложение. Для государства и регулируемых корпораций сильное управление состоянием защищённости также снижает стоимость аудитов и непрерывной авторизации, автоматически производя свидетельства. Обосновывая это перед руководством, подчеркните, что слой идентичности и конфигурации теперь основной вектор взлома, что неверная настройка предотвратима и что ограждения снижают и риск, и трение ручного рецензирования.

Антипаттерны и ловушки

Разрешения со звёздочкой. Предоставление широкого доступа * «чтобы всё заработало» без последующего ужесточения.
Долгоживущие статические ключи. Ключи доступа, встроенные в скрипты и CI, никогда не истекающие и в итоге утекающие.
Плоские сети. Нет сегментации, так что один скомпрометированный хост достигает всего.
Публично по случайности. Хранилища и базы данных, открытые в интернет через умолчания или небрежные настройки.
Шифрование без дисциплины ключей. Включение шифрования, но широко открытый доступ к ключам или их никогда не выполняемая ротация.
Секреты, зашитые в образы. Учётные данные, встроенные в образы контейнеров и расходящиеся повсюду, где образ запускается.
Бессерверные роли с избыточными разрешениями. Функции с гораздо большими разрешениями, чем нужно, потому что ограничение пропустили.
Состояние защищённости только для аудита. Обнаружение неверных настроек постфактум вместо их предотвращения при развёртывании.
Игнорирование дрейфа. Позволение рабочей среде расходиться с инфраструктурой-как-кодом, пока никто не знает реального состояния.

Модель зрелости

Уровень 1: Начальный. Ручное развёртывание по запросу тех, кому нужен ресурс. Широкие разрешения со звёздочкой и долгоживущие статические ключи. Плоские сети без сегментации. Шифрование применяется непоследовательно, если вообще. Нет управления состоянием защищённости; неверные настройки проявляются только после того, как инцидент вынуждает поставить вопрос.

Уровень 2: Развитие. Появляются некоторые роли IAM и MFA, а шифрование в покое включено для основных хранилищ, но практика различается по командам. Существуют базовые сетевые уровни без запрета по умолчанию. Рецензии конфигурации происходят периодически и вручную. Инфраструктура частично определена как код, поэтому укрепление зависит от того, какая группа развернула учётную запись.

Уровень 3: Стандартизация. RBAC и ABAC с наименьшими привилегиями и краткоживущими учётными данными документированы и соблюдаются по организации. Сегментация использует запрет по умолчанию «восток-запад». Шифрование при передаче и в покое включено по умолчанию, ключи в KMS по расписанию ротации, а хранение отделено от доступа к данным. Укрепление контейнеров и Kubernetes стандарт, а CSPM работает против определённых политик, применяемых последовательно по каждой учётной записи.

Уровень 4: Управление. Состояние защищённости измеряется, а не предполагается. Вы отслеживаете названные метрики относительно базовых значений и целей: долю идентичностей в пределах базового уровня наименьших привилегий, среднее время обнаружения и устранения неверных настроек и дрейфа, покрытие ограждениями и CSPM по учётным записям, соблюдение ротации ключей и число оставшихся долгоживущих учётных данных. Находки сортируются по радиусу поражения, у устранения есть владелец и цель уровня обслуживания, а данные о тенденциях этих чисел определяют, куда пойдёт следующее усилие по укреплению.

Уровень 5: Оркестрация. Безопасные умолчания заложены в посадочные зоны и инфраструктуру-как-код, так что каждый ресурс рождается укреплённым, а средства контроля адаптируются по мере сдвигов хозяйства и картины угроз. Микросегментация использует политику с учётом идентичности; ключи под управлением клиента и HSM защищают системы наивысшей гарантии с разделением хранения. Предотвращающие ограждения блокируют неверные настройки при развёртывании, дрейф автоматически обнаруживается и устраняется, а свидетельства состояния защищённости автоматически питают непрерывную авторизацию. Безопасность интегрирована с поставкой и планированием рисков, а организация регулярно выводит и пересматривает охват средств контроля по мере изменения провайдеров, сервисов и норм.

Идеи для обсуждения

Где ABAC стоит своей сложности против сохранения RBAC в вашей среде?
Как устранить долгоживущие учётные данные, не сломав унаследованную автоматизацию?
Каково правильное разделение между предотвращающими ограждениями и обнаруживающим управлением состоянием защищённости?
Какие системы оправдывают ключи под управлением клиента или HSM с учётом их эксплуатационной цены?
Как не дать разрешениям с наименьшими привилегиями молча накопиться обратно до избыточных?
Как сложность мультиоблака должна менять ваш подход к согласованному состоянию защищённости и политике?

Главные выводы

Идентичность новый периметр; вкладывайтесь в IAM с наименьшими привилегиями и краткоживущими учётными данными.
Сегментируйте сети и микросегментируйте нагрузки, чтобы сдерживать компрометацию.
Шифруйте при передаче и в покое по умолчанию и управляйте ключами через KMS/HSM с разделением хранения.
Укрепляйте контейнеры, Kubernetes и бессерверные вычисления; держите среды выполнения и образы пропатченными.
Предпочитайте предотвращающие ограждения обнаружению постфактум и управляйте состоянием защищённости непрерывно.
Закладывайте безопасные умолчания в посадочные зоны и инфраструктуру-как-код, чтобы защита масштабировалась автоматически.
Неверная настройка, а не экзотические эксплойты, ведущая причина облачных взломов, и она предотвратима.

Источники и дополнительное чтение

National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
Centre for Internet Security, CIS Benchmarks (cloud providers, Kubernetes, Docker)
Cloud Security Alliance, Cloud Controls Matrix and Security Guidance for Cloud Computing
NIST, SP 800-190: Application Container Security Guide
Liz Rice, Container Security
Marco Lancini and others, Cloud security posture and detection engineering literature
Provider Well-Architected security pillars (as vendor-neutral architectural guidance)

4.3 Безопасность инфраструктуры и облака

Обзор и мотивация

Ключевые принципы

Рекомендации

Проектируйте управление идентификацией и доступом намеренно

Сегментируйте сети и микросегментируйте нагрузки

Шифруйте данные и правильно управляйте ключами

Защищайте контейнеры, Kubernetes и бессерверные вычисления

Управляйте состоянием облачной защищённости непрерывно