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

Разделённая ответственность: где заканчивается провайдер

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

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

Типичные провалы: от слабых паролей до дырявых виртуалок

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

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

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

Репликация - это не бэкап. И это больно

Ещё одно массовое заблуждение - путать репликацию с резервным копированием. Репликация спасает при инфраструктурных сбоях. Но если пользователь случайно удалил данные или произошёл логический сбой, реплика просто воспроизведёт ту же ошибку. Известен реальный инцидент на Google Cloud Platform: клиент потерял 11 дней данных именно потому, что не настроил управляемые бэкапы. Инфраструктура провайдера при этом работала без нареканий.

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

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

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