Безопасность данных в облаке: как правильно заключить договор с провайдером по ФЗ-152

Вы решили перевести базу клиентов или внутренние документы компании в облако. Звучит удобно: доступ из любой точки, автоматические бэкапы, не нужно покупать дорогие серверы. Но есть подвох. Как только вы передаете данные третьему лицу - провайдеру, вы становитесь участником сложной правовой игры. Ошибка в договоре может стоить вам огромных штрафов от Роскомнадзора или репутационного краха после утечки.

Многие считают, что если данные хранятся у «большого» провайдера, то ответственность за их безопасность лежит на нем. Это опасное заблуждение. По российскому законодательству оператор персональных данных (то есть ваша компания) остается главным ответственным лицом перед законом. Провайдер лишь помогает, но не снимает с вас вины в случае ЧП. Именно поэтому ключевым документом становится не просто счет на оплату хостинга, а грамотно составленный договор.

Правовая база: почему одного счета недостаточно

В России отношения вокруг хранения и обработки личной информации регулируются двумя основными законами: ФЗ-152 «О персональных данных» и федеральный закон, устанавливающий требования к защите конфиденциальной информации граждан, а также ФЗ-149 «Об информации» и закон, определяющий правила оборота информационных ресурсов.

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

Суды в России четко расценивают предоставление прав на хранение и обработку информации как возмездное оказание услуг. Поэтому у вас должно быть два документа:

• Основной договор об оказании облачных услуг (техническая часть).
• Договор-поручение на обработку персональных данных (юридическая часть).

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

Что обязательно должно быть в договоре с провайдером

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

Во-первых, четко пропишите перечень действий. Что именно провайдер будет делать с данными? Хранить? Копировать? Анализировать метаданные для оптимизации поиска? Каждое действие должно быть описано. Размытые формулировки вроде «оказание услуг по размещению информации» могут трактоваться против вас при инцидентах.

Во-вторых, определите цель обработки. Данные хранятся исключительно для обеспечения работы вашего бизнеса, например, для предоставления доступа сотрудникам к CRM-системе. Любое иное использование (например, продажа аналитики вашим конкурентам) должно быть прямо запрещено.

В-третьих, детализируйте меры безопасности. Договор должен ссылаться на конкретные стандарты защиты. Это не просто слова «мы защищаем данные», а ссылки на сертификаты ФСТЭК и ФСБ, описание шифрования, методы контроля доступа.

SLA: цифры вместо пустых обещаний

Соглашение об уровне сервиса (SLA и Service Level Agreement, документ, фиксирующий гарантии качества обслуживания) - это сердце технического договора. Без измеримых показателей вы ничего не сможете доказать в суде, если сервис ляжет.

На что смотреть в первую очередь?

1. Доступность (Uptime). Стандарт рынка для серьезных проектов - 99,95% времени доступности. Это означает, что простой допускается не более чем на 4 минуты в месяц. Уточните, как считается этот процент. Исключаются ли плановые работы? Кто утверждает график этих работ?
2. Штрафы за нарушение. Матрица штрафов должна быть прозрачной. Если сервис недоступен 1 час, вы получаете скидку 10%. Если 5 часов - 50%. Если день - право расторгнуть договор без штрафов. Избегайте формулировок «компенсация в виде дополнительных часов», они малоценны при критических сбоях.
3. Время реакции на инциденты. Сколько времени у провайдера есть, чтобы заметить проблему и начать ее решать? Для критических систем это должны быть минуты, а не часы.

Помните: SLA работает только тогда, когда у вас есть независимый способ мониторинга доступности. Не доверяйте отчетам самого провайдера слепо.

Сертификация и закрытый контур: требования регуляторов

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

Провайдер должен предоставить доказательство того, что его инфраструктура сертифицирована. Речь идет о проверках со стороны ФСТЭК России и Федеральная служба по техническому и экспортному контролю, контролирующая защиту гостайны и коммерческой тайны и ФСБ России и Федеральная служба безопасности, отвечающая за криптографическую защиту информации.

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

Переносимость данных и свобода выбора

Самая частая ошибка компаний - попадание в «клетку» вендора (vendor lock-in). Вы начинаете использовать проприетарные форматы файлов или специфичные API провайдера, и через год понимаете, что уйти к другому поставщику невозможно без потери данных или огромных затрат на конвертацию.

В договоре должно быть прописано:

• Данные хранятся в открытых, стандартных форматах.
• Провайдер обязан обеспечить полный выгруз данных в течение определенного срока (например, 30 дней) после расторжения договора.
• Процедура удаления данных подтверждается актом с гарантией невозможности восстановления.

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

Ответственность за кибератаки и инциденты

Даже самая крепкая крепость может быть атакована. Важно заранее договориться, кто платит за последствия.

Часто в договорах есть пункт о DDoS-атаках. Если атака идет с ваших IP-адресов (например, взломали ваш офис), провайдер имеет право отключить вас. Но что, если атака внешняя и направлена на провайдера, из-за чего ваш сервис лег?

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

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

Практические шаги перед подписанием

Не подписывайте первый попавшийся шаблон. Вот чек-лист для вашей юридической и IT-службы:

1. Запросите у провайдера образец договора и договор поручения на обработку ПДн.
2. Проверьте наличие действующих сертификатов ФСТЭК/ФСБ на конкретные услуги.
3. Добавьте приложение с матрицей штрафов за нарушение SLA.
4. Убедитесь, что в договоре прописан механизм полного возврата данных при расторжении.
5. Проверьте, соответствует ли политика использования сервиса вашим внутренним регламентам.

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