5 ошибок безопасности облака, которые мы видим в каждом аудите

Откуда берутся эти ошибки

Когда команда мигрирует приложение в облако, фокус обычно стоит на том, чтобы оно заработало. Безопасность подключают позже, и часто не подключают вообще, потому что облачный провайдер декларирует, что инфраструктура защищена. Это правда наполовину. Провайдер защищает свою часть инфраструктуры. Конфигурация ваших ресурсов, политики доступа, шифрование, мониторинг это ваша часть ответственности по модели shared responsibility, и именно здесь происходит большинство инцидентов.

В нашей практике аудитов облачных аккаунтов в Yandex Cloud, VK Cloud, AWS, Azure и других платформах мы видим одни и те же пять ошибок практически в каждом проекте. Иногда все пять одновременно. Ниже разбираем каждую с конкретными способами проверки и устранения.

Ошибка 1: Открытые публичные бакеты с конфиденциальными данными

Это классика облачных утечек, и она продолжает встречаться, несмотря на все улучшения интерфейсов и предупреждений от провайдеров. Команды создают бакеты для хранения файлов, по умолчанию или по ошибке делают их публичными, и через какое-то время в этих бакетах оказываются персональные данные клиентов, копии баз данных, секреты, бэкапы.

В 2024-2025 годах мы видели в публичных российских инцидентах утечки из открытых бакетов на сотни тысяч записей. Каждая такая утечка это штраф по 152-ФЗ, репутационный ущерб и потенциальные уголовные последствия для ответственных лиц.

Быстрая проверка в AWS через CLI: aws s3api list-buckets и для каждого aws s3api get-bucket-acl с поиском "AllUsers" или "AuthenticatedUsers". Аналогично в других провайдерах через их CLI или API.

Устранение включает три уровня. Закрыть существующие публичные бакеты, перенеся при необходимости публичный контент в отдельные бакеты с явной маркировкой. Включить bucket public access block на уровне аккаунта, чтобы новые бакеты по умолчанию не могли быть публичными. Регулярно сканировать конфигурации через инструменты вроде Prowler, ScoutSuite или встроенных средств провайдера.

Ошибка 2: Слишком широкие IAM-привилегии

Принцип минимальных привилегий звучит хорошо в теории, но в облачной практике он постоянно нарушается. Разработчик для своей задачи берёт policy AdministratorAccess, чтобы не разбираться с тонкими разрешениями. После релиза этот policy остаётся, потому что переписывать его никто не хочет. Через месяц у CI-сервиса оказывается полный контроль над всем аккаунтом, и компрометация одного токена даёт злоумышленнику ключи от всего.

Похожая история с групповыми политиками. Группа Developers получает PowerUserAccess для удобства, потом в эту группу попадают практиканты, временные подрядчики, бывшие сотрудники, которых забыли удалить.

Быстрая проверка. В AWS используйте IAM Access Analyzer для автоматического обнаружения чрезмерных политик. В других провайдерах есть аналогичные инструменты или можно использовать сторонние сканеры. Простое правило: ни один service principal не должен иметь Administrator или Owner привилегий, если это не обосновано документально.

Устранение. Перейти от широких managed policies к гранулярным custom policies, разработанным под конкретные задачи. Использовать инструменты вроде krane, Cloudsplaining, Parliament для анализа реально используемых разрешений и предложения минимальных policies. Регулярно пересматривать назначения через quarterly access review.

Ошибка 3: Отсутствие MFA на критичных учётных записях

Логин в облачную консоль root-учётной записи или администраторской учётной записи без второго фактора это широко открытая дверь. Брутфорс, фишинг, утечка пароля через старый сервис, и злоумышленник получает полный контроль над вашим облачным аккаунтом.

В качественной практике 2026 года MFA должен быть обязательным для всех учётных записей с привилегиями выше базового user. Для root-учётных записей это абсолютная необходимость. Для service principals и API-ключей нужны механизмы ротации и хранения в защищённых секрет-менеджерах.

Быстрая проверка. В AWS: aws iam generate-credential-report и проверка статуса MFA для всех учётных записей. В других облаках аналогичные команды. Если хоть одна административная учётка без MFA, это критичная находка.

Устранение. Включить требование MFA на уровне политик. Для root-учётной записи использовать аппаратные ключи U2F, не только SMS или authenticator app. Для service principals и автоматизации использовать short-lived credentials через STS или аналоги, а не долгоживущие access keys.

Ошибка 4: Отсутствие централизованного логирования и мониторинга

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

В реальном инциденте отсутствие логов означает, что вы не сможете восстановить хронологию атаки, не сможете понять масштаб компрометации, не сможете предоставить доказательства регулятору. Команды узнают про эту проблему уже после инцидента, когда уже поздно.

Минимальный набор логов, которые должны быть включены и сохраняться. Audit log всех API-вызовов в облачном аккаунте. В AWS это CloudTrail с включёнными data events для критичных сервисов. В Yandex Cloud это Audit Trails. В Azure это Activity Log плюс Diagnostic Settings. Network flow logs для VPC и подсетей. Application logs из ваших сервисов, особенно критичных. Access logs для S3, Object Storage, баз данных.

Быстрая проверка. В AWS: aws cloudtrail describe-trails и проверка наличия multi-region trail с включёнными management events и data events. Аналогично в других провайдерах.

Устранение. Включить полное аудит-логирование с самого начала. Настроить отправку в централизованное хранилище за пределами облачного аккаунта, идеально в SIEM. Хранение минимум на год, для регулируемых отраслей дольше. Правила корреляции на типичные сценарии атак: невозможные путешествия между регионами, попытки эскалации привилегий, аномальные API-вызовы.

Ошибка 5: Незашифрованные данные

Шифрование в облаке должно быть включено везде, где это возможно. На практике мы регулярно встречаем ситуации, когда чувствительные данные хранятся в открытом виде, потому что шифрование "не было включено по умолчанию" или "не помешало бы, но и так работает".

Базовый набор требований по шифрованию выглядит так. Encryption at rest для всех бакетов, дисков, баз данных, очередей сообщений. Большинство провайдеров поддерживают это с минимальной настройкой через managed keys или customer-managed keys в KMS. Encryption in transit через TLS 1.2 минимум, лучше 1.3 для всех соединений. Шифрование между сервисами внутри облака, а не только наружу. Управление ключами через KMS с rotation policy и audit log на использование ключей.

Быстрая проверка. В AWS: проверка encryption status для всех бакетов через aws s3api get-bucket-encryption, для дисков через aws ec2 describe-volumes с фильтром Encrypted false, для RDS через aws rds describe-db-instances и проверку StorageEncrypted. Аналогично в других провайдерах.

Устранение. Включить default encryption на уровне аккаунта, чтобы все новые ресурсы автоматически создавались зашифрованными. Зашифровать существующие ресурсы через миграцию или snapshot-restore. Для регулируемых данных использовать customer-managed keys вместо provider-managed для большего контроля.

Дополнительные распространённые проблемы

Помимо топ-5 есть ещё несколько проблем, которые мы регулярно находим в аудитах.

Открытые ports security groups. Дефолтные правила, которые разрешают весь входящий трафик из любого источника. Особенно опасно для управляющих портов: SSH, RDP, базы данных.

Старые snapshots с конфиденциальными данными. Команды забывают удалять snapshots после миграций или экспериментов, и эти snapshots остаются доступными ещё годы.

Хардкоженные секреты в Lambda и контейнерных образах. Переменные окружения с паролями, AWS access keys в коде, API-токены в конфигурационных файлах.

Отсутствие network segmentation. Все ресурсы в одной VPC без разделения на zones, отсутствие изоляции между production и staging, прямой доступ из публичных подсетей к базам данных.

Игнорирование рекомендаций встроенных средств. AWS Trusted Advisor, Yandex Cloud Recommendations, Azure Security Center дают список конкретных проблем, и эти списки часто игнорируются командами.

План устранения по приоритету

Если у вас в облачном аккаунте обнаружились несколько проблем сразу, не пытайтесь закрыть всё одновременно. Работайте по приоритету.

Первая неделя закрывает критичные проблемы. Открытые публичные бакеты с конфиденциальными данными немедленно. MFA на root-учётной записи и всех администраторах. Отключение дефолтных учётных записей с широкими правами. Это можно сделать без серьёзных изменений в архитектуре.

Первый месяц включает улучшения, требующие планирования. Включение полного аудит-логирования. Шифрование чувствительных данных at rest. Пересмотр IAM-политик для service accounts. Настройка автоматического сканирования конфигураций.

Первый квартал это системные улучшения. Внедрение принципа минимальных привилегий через гранулярные политики. Сегментация сети с явными zones и правилами. Централизованный мониторинг с правилами корреляции. Регулярные access reviews с автоматизацией.

Постоянная работа это поддержка достигнутого уровня. Мониторинг отклонений от baseline. Регулярный пентест облачной инфраструктуры. Обучение команды на актуальных угрозах. Обновление политик при появлении новых сервисов.

Сколько это стоит

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

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

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

Что делать прямо сейчас

Самое простое начало это запустить любой бесплатный сканер конфигурации на ваш облачный аккаунт. Prowler для AWS, Steampipe, ScoutSuite для нескольких провайдеров, встроенные рекомендации в самих облаках. Это даст вам базовое представление о масштабе проблем.

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