10 вопросов облачному провайдеру, прежде чем отдать ему данные клиентов

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

1. Где физически находятся серверы и в каких дата-центрах хранятся данные?

Провайдер обязан назвать конкретные дата-центры, их географическое расположение и правовую юрисдикцию. Для персональных данных граждан РФ это критично: по закону 152-ФЗ запись, накопление и хранение персональных данных должны выполняться в базах данных на территории России.

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

2. Кто именно внутри провайдера имеет доступ к данным и как это контролируется?

Нужно узнать, какие сотрудники провайдера могут технически дотянуться до ваших данных, как разграничены их права и ведётся ли журнал доступа. В облаках действует принцип разделения ответственности (shared responsibility): провайдер отвечает за безопасность инфраструктуры, клиент - за настройки доступа, ключи и политики.

Спросите, как выдаются роли и как можно самостоятельно ограничить доступ. Управление доступом - это набор правил, определяющих, кто и какие действия может выполнять с данными. У большинства провайдеров управление доступом к объектному хранилищу настраивается через IAM-роли и политики бакетов - например, так это работает в MWS, Yandex Cloud и VK Cloud. Это позволяет гибко контролировать, кто и что может делать с объектами.

3. Что будет при аварии: как быстро провайдер восстановит сервис?

Авария - не гипотеза, а вопрос времени. Узнайте, какой уровень доступности зафиксирован в SLA. SLA - это соглашение об уровне сервиса, в котором прописаны допустимое время простоя и компенсации за его превышение.

Спросите, есть ли резервирование на уровне дата-центров, автоматическое переключение при отказе и план действий при крупной аварии. Сравнение провайдеров стоит проводить по уровню поддержки (SLA), наличию сертификатов и географической распределённости ЦОД. Готовый реестр контейнеров обычно имеет предсказуемую доступность - провайдеры дают гарантии SLA на этот сервис.

4. Как устроено резервное копирование и проверяется ли восстановление?

Резервная копия - это отдельная сохранённая версия данных, из которой можно восстановиться после сбоя, удаления или атаки. Недостаточно просто «делать бэкапы». Нужно знать, как часто они создаются, где хранятся и как проверяется возможность восстановления.

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

5. Что реально написано в договоре про возмещение ущерба?

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

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

6. Есть ли у провайдера сертификаты и аттестации по информационной безопасности?

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

Спросите, есть ли аттестация по требованиям ФСТЭК, сертификаты соответствия и заключения о соответствии. Например, у MWS есть аттестация по требованиям информационной безопасности, аналогичные подтверждения есть у Yandex Cloud и VK Cloud. Конкретный список сертификатов и аттестаций стоит запросить у провайдера напрямую - он должен быть готов показать документы, а не только сослаться на них в презентации.

7. Как провайдер изолирует клиентов друг от друга?

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

Микросегментация - это разбиение сети на изолированные сегменты с точной настройкой доступа между ними. Микросегментация - стандартная практика для облаков, работающих с чувствительными данными. Например, при хостинге 1С в MWS сервисы и данные изолируются в отдельные подсети с точной настройкой доступа между ними. Похожие механизмы изоляции есть у Yandex Cloud и Cloud.ru. Если злоумышленник проникнет в одну подсеть, другие сегменты останутся в безопасности.

8. Как провайдер соблюдает закон 152-ФЗ о персональных данных?

Если вы работаете с персональными данными граждан РФ, провайдер должен обеспечить хранение баз данных на территории России. Это требование Федерального закона № 152-ФЗ «О персональных данных».

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

9. Как обеспечивается безопасность контейнеров и образов?

Если вы используете Kubernetes или контейнеры, безопасность образов - это отдельный слой защиты. Спросите, есть ли у провайдера готовый реестр контейнеров с контролем доступа и шифрованием.

Готовый Container Registry ускоряет деплой, потому что образы лежат рядом с вычислительными узлами. Частный репозиторий образов закрыт от посторонних, данные шифруются, а доступ выдаётся по ролям. Интеграция с Kubernetes работает через сервисный аккаунт, без ручной ротации секретов в каждом пространстве имён. Такой подход снижает риск несанкционированного доступа к производственным образам.

10. Можно ли провести тестовую миграцию перед полным переездом?

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

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

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