Облачные виртуальные машины: как защитить данные и настроить удобное управление

Сегодня ВМ выполняют большую часть задач в облаке. Их развитие идёт не столько через технологические прорывы, сколько через повышение безопасности и удобства в работе.

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

Александр Душеин

Архитектор Yandex Cloud

Байка о Сергее и Кевине

Все персонажи вымышленные, ни один сисадмин не пострадал.

Технический менеджер Сергей отвечал за разработку популярного развлекательного сайта с богатой историей, легаси-кодом и внушительным техническим долгом. Один из таких долгов — хранение паролей пользователей в базе данных в открытом виде, что Сергей оправдывал фразой «ну подумаешь, не банк же».

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

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

Мораль: не храните пароли в открытом виде, а ещё лучше не храните их совсем. Это может сыграть злую шутку, даже если данные не попадут к злоумышленникам.

Полностью отказаться от хранения паролей помогут современные облачные технологии, такие как OS Login.

Забудьте про рутину с SSH-ключами

Классический подход с локальными пользователями и SSH-ключами на каждой ВМ превращает жизнь администратора в квест. Приходится настраивать каждую машину отдельно, а потеря ключа становится настоящей головной болью. Вместо того чтобы заниматься действительно важными задачами, инженеры тратят время на рутинное управление доступом.

OS Login решает эту проблему — он связывает учётную запись в Linux с облачной учётной записью. Больше не нужно вручную добавлять SSH-ключи в ~/.ssh/authorized_keys на каждой ВМ. Теперь они привязываются к IAM-пользователю или сервисному аккаунту, а доступом можно управлять через IAM-политики.

В Google Cloud достаточно включить OS Login на уровне проекта или организации и назначить пользователю роль roles/compute.osAdminLogin. После этого он получает доступ ко всем нужным ВМ. В Yandex Cloud механизм работает похожим образом — доступ привязывается к облачному аккаунту организации.

Когда сотрудник уходит из компании, не нужно вспоминать, к каким машинам у него был доступ — при удалении из облачного IAM все его доступы закрываются автоматически. А для параноиков есть приятный бонус: в логах OS Login видны все подключения, плюс можно включить двухфакторную аутентификацию.

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

Паролефобия: почему лучший пароль тот, которого нет

Пароли, сертификаты, токены доступа, API-ключи — для работы сервисов и конвейеров (CI, CD, AirFlow и т.д.) необходимо множество секретов для доступа к различным системам и данным: container registry, базам данных, кластерам Kubernetes и другим. Для безопасного хранения учётных данных существуют специализированные сервисы и утилиты, но для доступа к ним внезапно требуются... ключи, сертификаты, пароли. Можно ли обойтись без них?

В облаке ответ — да. Вместо хранения статических паролей можно использовать более надёжные способы. OS Login избавляет от необходимости создавать отдельные пароли для каждой ВМ. SSO помогает забыть о локальных учётных записях на серверах — достаточно корпоративной. А временные токены (Security Token Service, STS) позволяют отказаться от «вечных» ключей доступа, которые так любят утекать в публичные репозитории.

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

Сервис метаданных: полезный инструмент с подвохом

Не только информация о ВМ, но и способ коммуникации с ней из внешнего мира — так можно описать сервис метаданных, доступный во всех облаках по адресу 169.254.169.254. С его помощью приложения внутри ВМ получают данные об инстансе (конфигурация, размещение и сетевые адреса) и временные IAM-токены для сервисных аккаунтов. Это избавляет от необходимости хранить учётные данные в коде.

История взлома Capital One наглядно показывает риски: злоумышленник может провести SSRF-атаку и заставить сервер обратиться к метаданным. В результате он получит доступ к IAM-токенам. Облачные провайдеры решают эту проблему по-разному. AWS требует получить специальный токен в IMDSv2. Google Cloud использует обязательный заголовок «Metadata-Flavor: Google». А Yandex Cloud и вовсе отключил поддержку IMDSv1 из-за рисков безопасности.

Для предотвращения компрометации инфраструктуры через SSRF-уязвимости разработчикам необходимо соблюдать следующие правила:

• Не храните секреты в пользовательских метаданных;
• Ограничивайте доступ к сервису для контейнеров, которым не требуются токены;
• Учитывайте, что сервис метаданных будет доступен и для контейнеров, запущенных на хосте;
• Используйте файерволл операционной системы или network policy в Kubernetes для ограничения доступа к сервису метаданных.

Федерация сервисных аккаунтов: внешние сервисы становятся своими

Представьте: у вас есть под Kubernetes, которому нужен доступ к секрету в Yandex Lockbox. Или CI/CD система вроде GitLab должна развернуть облачные сервисы через Terraform. Обычно в таких случаях создают сервисный аккаунт со статическим ключом. Но у этого подхода есть проблемы: ключи утекают в Git-репозитории, а их ротация превращается в квест.

Workload Identity Federation (федерация сервисных аккаунтов) предлагает элегантное решение: внешний сервис использует свой токен аутентификации для обмена на временные облачные креденшелы. Каждый провайдер реализует это по-своему:

• AWS использует IRSA (IAM Roles for Service Accounts) — под в Kubernetes получает JWT-токен и обменивает его на временные IAM-креденшелы;
• Azure через Microsoft Entra ID проверяет OIDC-токены от GitHub Actions или Kubernetes;
• Yandex Cloud позволяет обменять OIDC-токен от совместимого провайдера на IAM-токен сервисного аккаунта.

Защита данных: шифруем всё

Объектные хранилища вроде AWS S3 стали настоящей головной болью для специалистов по безопасности. Достаточно поискать в интернете «S3 bucket leak», чтобы понять масштаб проблемы. Первая линия защиты — временные ключи (Security Token Service, STS). Даже если их скомпрометируют, время жизни ограничено, а значит и потенциальный ущерб минимален.

Но что если злоумышленник получит физический доступ к носителю или бэкапу? Здесь поможет только шифрование данных. AWS, GCP и Yandex Cloud предлагают шифрованные диски на базе алгоритма AES-256 с управлением ключами через KMS-сервисы.

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

Но даже если вы зашифровали все данные и настроили безопасный доступ, остаётся важный вопрос: кто и что делает в вашем облаке? Помните историю про Сергея и Кевина? А что если злоумышленник всё-таки получит доступ к вашим ресурсам или кто-то из сотрудников решит «немного» превысить свои полномочия?

Здесь на помощь приходит аудит действий. Сервис аудитных логов собирает информацию обо всех событиях: кто заходил в систему, какие ресурсы создавал или удалял, какие настройки менял — и сохраняет эти данные в объектном хранилище, сервисе для управления потоками данных.

Особенно важно отслеживать «чувствительные» операции: создание и удаление ключей сервисных аккаунтов, изменение ролей пользователей, действия с ключами шифрования. Если вы работаете с конфиденциальными данными или в регулируемой отрасли, без такого мониторинга просто не обойтись.

И что приятно — вы можете интегрировать эти логи с внешними системами безопасности (SIEM), чтобы анализировать их вместе с другими источниками данных. Это позволяет выявлять сложные сценарии атак, которые могут остаться незамеченными при изолированном анализе.

Но знать о подозрительной активности — это только половина дела. Важно иметь возможность быстро отреагировать на неё и предотвратить возможный ущерб. И это подводит нас к следующей теме — прозрачности и управляемости облачной инфраструктуры.

Прозрачность и управляемость: предупреждён — значит вооружён

Проинформировать ВМ о предстоящих важных событиях и дать возможность приготовиться — вот задача сервисов мониторинга облачных провайдеров. Каждый решает её по-своему:

• AWS уведомляет о Scheduled Events через AWS Health Dashboard;
• Google Cloud использует Live Migration, предупреждая о перемещении ВМ за 60 секунд;
• Yandex Cloud через Политики обслуживания ВМ позволяет выбрать сценарий (migrate или restart) и отложить обслуживание.

Это особенно важно для сервисов реального времени. Например, RabbitMQ болезненно переживает внезапные остановки. Получив уведомление о предстоящей миграции, вы можете корректно вывести ноду из кластера, дождаться перемещения и вернуть её обратно.

Облачные провайдеры позволяют менять конфигурацию на лету. Закончилось место на диске посреди важного расчёта? Можно увеличить его объём без остановки ВМ. Хотите проверить отказоустойчивость вашего сервиса? Отключите сетевой интерфейс на ходу, имитируя сбой сети, а затем подключите его обратно — всё это без перезагрузки машины.

Готовитесь к росту нагрузки, но переделывать приложение для Kubernetes не видите смысла? Вам помогут группы виртуальных машин:

• В Yandex Cloud можно создать группу с фиксированным числом машин или настроить автоматическое масштабирование по метрикам (CPU, память, очереди и т.д.);
• AWS Auto Scaling Groups и Google Managed Instance Groups работают похожим образом: добавляют мощности при росте нагрузки и убирают лишнее при снижении;
• Гибкое управление конфигурацией через систему переменных позволяет, например, выделять IP-адреса из заранее зарезервированного пула;
• Если ВМ выходит из строя, группа автоматически заменит её, а балансировщик уберёт сбойный экземпляр из ротации.

Это особенно удобно для организации динамических GitLab-раннеров или обработки асинхронных задач — группа расширяется при появлении новых задач в очереди и сжимается, когда работы становится меньше.

Безопасность vs удобство: как найти баланс

Помните историю про Сергея и Кевина? Она показывает, как важно не просто следовать правилам безопасности, а менять сам подход к хранению учётных данных. Современные облачные технологии позволяют полностью отказаться от статических паролей и ключей.

OS Login, временные токены и федерация сервисных аккаунтов — это не просто модные слова, а реальные инструменты, которые помогают избежать компрометации данных. При этом они не усложняют работу: вместо управления SSH-ключами на каждой машине вы получаете централизованный контроль доступа, а федерация сервисных аккаунтов избавляет от головной боли с ротацией ключей.

Сервис метаданных и шифрование данных образуют дополнительные уровни защиты. А возможность получать уведомления о планируемом обслуживании и автоматически масштабировать ресурсы через группы ВМ помогает строить действительно надёжные системы — будь то высоконагруженный сервис машинного обучения или классическое корпоративное приложение.

Больше про облака и другие важные IT-инструменты — в нашем тг-канале