Почему хакеры так часто проникают в облака. В «Мегафоне» назвали главные ошибки клиентов

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

По итогам прошлого года число атак на облачные архитектуры в РФ увеличилось на 30%, сообщал SecPost. При этом у 88% компаний с уязвимыми публичными виртуальными машинами обнаружены критические уязвимости, а в каждой четвертой организации — признаки состоявшегося проникновения.

Что остается за клиентом

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

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

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

Та же логика работает и с настройками облачных сервисов. Например, команда открыла бакет наружу на время тестирования, а потом забыла закрыть. Постепенно в нем появились документы, резервные копии или выгрузки из CRM. Для утечки в таком случае не потребуется взламывать облако — данные уже доступны извне из-за настроек самого клиента.

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

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

Бэкап есть. А восстановиться получится?

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

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

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

Облако заканчивается, приложение — нет

Часть рисков появляется уже поверх облачной инфраструктуры. Например, разработчик оставляет пароль, токен или API-ключ прямо в коде. Если репозиторий окажется в открытом доступе или учетную запись разработчика скомпрометируют, вместе с кодом злоумышленник может получить и действующие ключи. Для таких данных существуют отдельные сервисы управления секретами. Но они не помогут, если команда продолжает хранить ключи в исходном коде, не проверяет репозитории и не меняет скомпрометированные учетные данные. Секреты лучше хранить отдельно от кода, а ключи — регулярно менять. Особенно это касается учетных данных с широкими правами доступа к облачным ресурсам.

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

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

Где искать серую зону

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

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

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