(4 часа назад), Редакция Рунет | 👁 449

Облако не защитит бизнес само: как МСБ выбирать провайдера

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

«Но переход в облако не означает, что вопросы информационной безопасности автоматически переходят к провайдеру. Это одна из главных ошибок МСБ: считать, что раз данные и приложения размещены во внешней инфраструктуре, значит, безопасность полностью обеспечена поставщиком услуги», — сообщает «Код Дурова».

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

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

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

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

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

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

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

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

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

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

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

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

Хороший провайдер для МСБ — это не только низкая цена и удобная панель управления. Минимально стоит проверить расположение ЦОД, физическую защиту и резервирование, DDoS-защиту, межсетевые экраны, шифрование данных в канале и на диске, порядок резервного копирования, процедуры уведомления об инцидентах, возможность выгрузки логов и право на аудит.

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

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

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе всех новостей и событий Рунета.

Комментарии 0
Зарегистрируйтесь или , чтобы оставлять комментарии.
Читайте нас в удобном формате: