Безопасность облачных сервисов: кто за что отвечает

Коротко. Безопасность облачных сервисов делится между провайдером и клиентом — это называют моделью разделённой ответственности. Провайдер отвечает за физические дата-центры, оборудование и ту часть платформы, которой управляет сам. Клиент всегда отвечает за свои данные, учётные записи, права доступа и настройки. Чем больше готового сервиса вы берёте (IaaS → PaaS → SaaS), тем меньше слоёв на вашей стороне, но эти три пункта не уходят никогда. Большинство громких облачных утечек происходят не из-за взлома провайдера, а из-за открытого хранилища, слабого пароля администратора или забытого ключа доступа. Ниже — таблица ответственности, типичные ошибки и чек-лист.

Для руководителей и ИТ-специалистов компаний, которые держат сайт, почту, CRM или 1С в облаке.

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

Облачные услуги принято делить на три модели — такие определения даёт, например, NIST в документе SP 800-145:

• IaaS (инфраструктура как услуга) — вы арендуете виртуальные серверы, сети и хранилища. Всё, что выше виртуальной машины, — ваше: операционная система, программы, настройки.
• PaaS (платформа как услуга) — провайдер даёт готовую среду: базу данных, среду выполнения кода, контейнерную платформу. Вы размещаете приложение и данные.
• SaaS (программное обеспечение как услуга) — готовый сервис: почта, CRM, бухгалтерия, облачный диск. Вы им пользуетесь и управляете пользователями.

Аналогия: IaaS — аренда пустого помещения, PaaS — офис с мебелью и охраной здания, SaaS — коворкинг. Но ключи от своего кабинета и то, что лежит на столе, в любом случае на вас.

Кто за что отвечает: таблица по IaaS, PaaS и SaaS

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

Где компании ошибаются чаще всего

Облако ломают не хитрыми атаками, а через ошибки на стороне клиента:

1. Хранилище с публичным доступом. Папку или бакет с выгрузками, резервными копиями или сканами документов открыли «на время» по ссылке — и забыли.
2. Администратор облака без двухфакторной аутентификации. Учётная запись владельца аккаунта даёт власть над всем: серверами, копиями, биллингом. Пароль от неё крадут фишингом. Где включить второй фактор в первую очередь — в статье о двухфакторной аутентификации для компании.
3. Ключи доступа в коде. API-ключи и пароли к базе в репозитории, в конфигурационном файле на сайте, в переписке с подрядчиком.
4. Открытые порты управления. RDP, SSH, панели баз данных доступны из интернета напрямую, а не через VPN.
5. Одна общая учётная запись на всех. Невозможно понять, кто что сделал, и нельзя отключить одного человека, не сменив пароль всем.
6. Бывшие сотрудники и подрядчики сохраняют доступ. Облачные консоли и SaaS часто живут вне корпоративного каталога и выпадают из процедуры увольнения — как этого избежать, разобрано в чек-листе отзыва доступов при увольнении.
7. Журналы выключены или никто их не читает. Об инциденте узнают из письма провайдера или от клиентов.
8. Копии только внутри того же аккаунта. Если аккаунт захвачен или провайдер недоступен, копии пропадают вместе с данными. Как построить копии вне досягаемости — в статье о резервном копировании 3-2-1.

Что проверить у провайдера и в договоре

До переноса данных задайте провайдеру вопросы и найдите ответы в договоре, а не в рекламной презентации:

• Где физически хранятся данные — в какой стране и может ли это измениться. Если за пределами Беларуси и среди данных есть персональные, это трансграничная передача с отдельными требованиями, разобранными в статье о трансграничной передаче персональных данных.
• Кто у провайдера имеет доступ к вашим данным и в каких случаях.
• Уведомление об инцидентах — в какой срок и каким способом провайдер сообщит об утечке или взломе на своей стороне.
• Резервирование и восстановление — что провайдер восстанавливает сам, а что только ваша забота.
• Доступ к журналам — сможете ли вы получить записи о входах и действиях в своём аккаунте и за какой срок они хранятся.
• Выход из договора — в каком формате и за какой срок можно выгрузить данные и как подтверждается их удаление.
• Субподрядчики — кому провайдер передаёт часть работ.
• Подтверждения — сертификат ISO/IEC 27001, аттестация системы защиты информации, если она требуется для вашего типа информации.

Роль облачного провайдера при обработке персональных данных по закону № 99-З и требования к размещению информационных систем отдельных категорий в облаке оценивайте с юристом до подписания договора.

Базовые настройки на своей стороне

Учётные записи и доступы

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

Сеть и данные

• Порты управления закрыты из интернета, доступ через VPN или бастион.
• Хранилища по умолчанию закрыты, публичные ссылки — только с ограничением по сроку и под контролем.
• Шифрование данных при хранении и передаче включено; секреты — в хранилище секретов, не в коде.

Журналы и копии

• Журналы входов и административных действий включены и уходят туда, где их смотрят.
• Оповещения на критичные события: вход администратора из новой страны, отключение журналов, массовое удаление.
• Резервные копии критичных данных хранятся вне основного облачного аккаунта, восстановление проверено.

Для IaaS к этому добавляются обновления операционных систем и настройка по отраслевым рекомендациям, например CIS Benchmarks для вашей платформы.

Как проверить безопасность облачной инфраструктуры

Самостоятельно — пройти чек-лист ниже и выгрузить из консоли список пользователей, открытых портов и публичных ресурсов. Если ответов больше, чем вопросов, стоит заказать внешнюю проверку. В услугах кибербезопасности Viviar облачная инфраструктура входит в экспресс-аудит: до 30 узлов, одно интервью, неделя работы и отчёт с приоритетами — от 5 200 BYN.

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

Чек-лист безопасности облачных сервисов

• Есть список всех облачных сервисов компании и владелец у каждого
• Для каждого сервиса понятно, какие слои на нас, а какие на провайдере
• Двухфакторная аутентификация включена у всех администраторов
• Нет общих учётных записей, в том числе у подрядчиков
• Хранилища не имеют публичного доступа без необходимости
• Порты управления не открыты в интернет
• Ключи и пароли не хранятся в коде и переписке
• Журналы входов включены, на критичные события настроены оповещения
• Копии критичных данных лежат вне основного облачного аккаунта
• Известно, в какой стране хранятся данные, и оценена трансграничная передача
• В договоре есть сроки уведомления об инцидентах и порядок выгрузки данных

Частые вопросы

Кто отвечает, если данные утекли из облака?

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

Облако безопаснее своего сервера?

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

Нужны ли резервные копии, если данные хранятся в SaaS?

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

Можно ли хранить персональные данные в зарубежном облаке?

Размещение персональных данных на серверах за пределами Беларуси — это трансграничная передача, и для неё закон № 99-З устанавливает отдельные требования. Прежде чем выбирать зарубежный сервис для CRM, почты или аналитики, выясните страну хранения и оцените основания передачи. Подробный разбор мы сделали в отдельной статье базы знаний.

С чего начать проверку безопасности облака?

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

Вывод

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

Источники: NIST SP 800-145 «The NIST Definition of Cloud Computing» (nist.gov); CIS Benchmarks (cisecurity.org); ENISA — материалы по безопасности облачных вычислений (enisa.europa.eu); Закон Республики Беларусь от 07.05.2021 № 99-З «О защите персональных данных» (pravo.by); Указ Президента Республики Беларусь от 14.02.2023 № 40 «О кибербезопасности» (pravo.by); цены — публичные пакеты Viviar, действуют с 01.09.2026.