Облачная безопасность: что меняется при переходе с on-premise

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

Модель разделённой ответственности простыми словами

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

Что реально меняется по сравнению с on-premise

Периметр становится размытым: нет чёткой границы «внутренней сети», к которой применялись классические меры защиты. Управление доступом становится критичнее, чем когда-либо, потому что доступ к облачной консоли часто равносилен доступу ко всей инфраструктуре. Появляется новый класс ошибок: неправильная конфигурация облачных сервисов, которая на on-premise просто не существовала как категория риска. И ответственность за резервное копирование и восстановление часто ошибочно считается зоной провайдера, хотя на практике это почти всегда обязанность клиента.

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

Практический минимум для бизнеса в облаке

Многофакторная аутентификация обязательна для всех административных учётных записей облачной консоли: компрометация одной такой учётной записи может означать компрометацию всей инфраструктуры. Регулярный аудит прав доступа и конфигураций тоже важен: облачные провайдеры дают инструменты для этого, но ими редко пользуются без специального внимания. Шифрование данных в состоянии покоя и при передаче обычно не требует дополнительной разработки: в большинстве облачных платформ это включается конфигурацией. И чёткое понимание, где заканчивается зона ответственности провайдера и начинается ваша, важно для каждого конкретного используемого сервиса отдельно, потому что модель может отличаться между IaaS, PaaS и SaaS.

Частая ошибка при миграции

Компании, переезжающие в облако, часто переносят инфраструктуру «как есть», не пересматривая архитектуру безопасности под новую модель. Правила, которые работали для защищённого периметра on-premise, плохо переносятся на распределённую облачную архитектуру без адаптации. Миграция хороший повод пересмотреть подход к безопасности с нуля. Простое копирование старых настроек в новую среду эту возможность упускает.

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