«Договор с облачным провайдером, это не просто формальность, а технический документ, который определяет, кто и за что отвечает в случае инцидента. Пропущенная строчка может означать недели простоя и миллионы убытков. Большинство компаний подписывает его, не читая, полагаясь на шаблонность. Я проверил свой — и нашёл четыре критических момента, которые напрямую влияют на соответствие 152-ФЗ и требованиям ФСТЭК.»
Почему договор с облаком, это не «бумажка», а часть ИБ-ландшафта
При переносе инфраструктуры в облако ответственность за безопасность делится между клиентом и провайдером. Эта модель разделённой ответственности — краеугольный камень облачных технологий, но в российском правовом поле она сталкивается с жёсткими требованиями регуляторов. ФСТЭК России и Роскомнадзор смотрят на компанию-оператора персональных данных (ПДн) как на единый центр ответственности. Если происходит утечка из облака, штраф по 152-ФЗ получает оператор, а не провайдер. Договор становится ключевым документом, который определяет границы этой ответственности, порядок взаимодействия при инцидентах и технические возможности для выполнения предписаний регулятора.
Типовой договор публичной оферты облачного провайдера написан в первую очередь для защиты его интересов и масштабирования услуги. Он редко учитывает специфические требования отраслевых стандартов или необходимость проведения плановых проверок ФСТЭК. Без детальной проработки приложений и спецификаций компания рискует оказаться в ситуации, когда формально инфраструктура в облаке, а юридически и технически выполнить требования регулятора невозможно.
Ошибка 1: Неопределённость в хранении и обработке ПДн
В разделе об обработке данных часто используется обтекаемая формулировка: «Провайдер обеспечивает функционирование сервисов, Клиент несёт ответственность за размещаемые данные». Для регулятора этого недостаточно. Требуется чёткое определение: являются ли услуги обработкой ПДн по смыслу 152-ФЗ? Если да, то провайдер становится оператором или поручающим обработку лицом? От этого зависит необходимость уведомления Роскомнадзора, составление отдельного соглашения на поручение обработки и весь комплекс организационных мер.
В моём случае в договоре отсутствовало прямое указание на возможность обработки ПДн. Это создавало правовой вакуум. При проверке Роскомнадзор мог трактовать это как сокрытие факта обработки с использованием сторонних мощностей. Решение — составить и подписать дополнительное соглашение о поручении обработки ПДн, где явно прописать цели, состав данных, меры безопасности, обязанности сторон и условия уничтожения данных после прекращения договора. Без такого документа вся облачная инфраструктура, где хранятся, например, данные клиентов, оказывается вне правового поля.
Ошибка 2: «Тихая» смена юрисдикции данных
Публичные оферты часто содержат право провайдера перемещать данные между своими дата-центрами для обеспечения отказоустойчивости и балансировки нагрузки. На первый взгляд, это техническая необходимость. Однако с точки зрения 152-ФЗ и требований ФСТЭК к трансграничной передаче ПДн это критично. Если данные клиента из России неожиданно начали обрабатываться на физическом сервере в Казахстане или Армении (где также могут присутствовать дата-центры крупных провайдеров), это может быть расценено как трансграничная передача.
Для такой передачи требуется отдельное информированное согласие субъекта ПДн или выполнение ряда условий, предусмотренных законом. В моём договоре эта возможность была «спрятана» в общих положениях об архитектуре сервиса. Исправление — внести в договор или приложение к нему явный запрет на перемещение данных за пределы географического региона, указанного при создании облачного ресурса (например, «Москва» или «Санкт-Петербург»). Провайдеры обычно предоставляют такую техническую возможность, но её нужно активировать и юридически зафиксировать.
Ошибка 3: Недоступность журналов аудита для ФСТЭК
Требования ФСТЭК обязывают обеспечивать регистрацию событий безопасности. В облаке логи генерируются как на уровне инфраструктуры (виртуальные машины, сети), так и на уровне платформы (управляемые базы данных, объектные хранилища). Ключевой вопрос: кто и как имеет к ним доступ? Типовой договор может предоставлять клиенту доступ к базовым метрикам, но не к низкоуровневым журналам хостовой системы или сетевого оборудования, которые необходимы для полноценного расследования инцидента.
Я обнаружил, что доступ к критически важным журналам безопасности (например, logs of management plane — логи действий в панели управления, включая входы администраторов провайдера) либо не предусмотрен, либо предоставляется только по отдельному запросу и за дополнительную плату. Время предоставления таких логов может составлять несколько дней, что неприемлемо при отражении кибератаки или по требованию регулятора. В договор необходимо включить положение, гарантирующее клиенту доступ ко всем релевантным журналам аудита в машиночитаемом формате в near real-time или с минимальной задержкой, определённой в SLA.
Ошибка 4: Расплывчатое SLA и процедура инцидентов
Service Level Agreement (SLA), это обычно процент доступности, например, 99.9%. Однако для целей ИБ важнее не цифра, а процедурная часть. Как определяется инцидент, связанный с безопасностью? Кто и в какие сроки ставится в известность? Каков порядок взаимодействия? В стандартном договоре инциденты безопасности часто смешиваются с общесервисными сбоями.
Я столкнулся с тем, что в договоре не было чёткого определения «инцидента информационной безопасности» и отдельного канала связи для таких случаев. Уведомление о подозрительной активности или потенциальной утечке данных могло уйти в общую службу поддержки и потеряться среди тикетов о медленной работе виртуальной машины. Это недопустимо. В договор нужно добавить приложение, описывающее процедуру обработки инцидентов ИБ, включая:
- Определение инцидента ИБ.
- Выделенный контакт (телефон, зашифрованная почта) для экстренных уведомлений.
- Обязательные сроки первичного ответа и предоставления предварительного отчёта.
- Обязанность провайдера содействовать в расследовании, предоставляя данные.
Без этого компания не сможет выполнить требования 152-ФЗ об уведомлении Роскомнадзора об утечке в установленные законом сроки.
Как исправить: практические шаги
Пересмотр договора с облачным провайдером — не однократное действие, а процесс. Вот последовательность шагов, которая позволит привести документ в соответствие с регуляторными требованиями.
1. Аудит текущего договора и приложений
Совместно с юристом и специалистом по ИБ составьте таблицу требований (из 152-ФЗ, приказов ФСТЭК, отраслевых стандартов) и проверьте, какие из них покрываются текущими положениями договора. Особое внимание — определениям, хранению данных, доступу к информации и процедурам.
2. Запрос типовых дополнительных соглашений у провайдера
Крупные провайдеры часто имеют подготовленные пакеты документов для корпоративных клиентов, работающих с ПДн или гостайной. Запросите их. Это может быть:
- Соглашение о поручении обработки ПДн.
- Приложение о мерах технической защиты информации.
- Дополнение к SLA по инцидентам ИБ.
Часто эти документы существуют, но не публикуются в открытом доступе.
3. Переговоры и фиксация
Если типовых документов недостаточно, инициируйте переговоры на техническом и юридическом уровне. Все достигнутые договорённости, даже если они касаются конфигурации сервиса (например, «все ВМ создаются только в зоне доступности ru-central1-a»), должны быть отражены в письменном виде — в спецификации, приложении или дополнительном соглашении к договору. Устные завершения не имеют силы при проверке ФСТЭК.
4. Интеграция в процессы компании
Скорректированные договорные условия должны быть отражены во внутренних документах компании: в политике ИБ, регламентах по реагированию на инциденты, инструкциях для администраторов. Это замыкает цикл и делает работу с облаком управляемой и проверяемой.
Что будет, если оставить как есть
Игнорирование тонкостей договора не останется незамеченным навсегда. Риски материализуются в нескольких сценариях:
- При плановой проверке ФСТЭК. Аудитор запросит договор с облачным провайдером. Отсутствие чёткого разграничения ответственности, соглашения на обработку ПДн и процедур по ИБ будет расценено как нарушение требований к организации системы защиты информации. Последует предписание об устранении, а в худшем случае — штраф.
- При инциденте (утечка, DDoS). Выяснится, что для расследования нет доступа к необходимым журналам, а провайдер не обязан оперативно реагировать на запросы по ИБ. Время на реагирование будет упущено, убытки — умножены. Несоблюдение сроков уведомления об утечке ПДн повлечёт отдельный штраф от Роскомнадзора.
- При смене провайдера или прекращении договора. Непрописанные условия гарантированного удаления всех данных (включая резервные копии) могут привести к тому, что чувствительная информация останется в инфраструктуре провайдера неопределённо долго, создавая постоянный риск.
Договор с облачным провайдером, это фундамент, на котором строится безопасная и соответствующая закону ИТ-инфраструктура. Его проверка и доработка не являются «юридическими придирками». Это техническая необходимость для любой компании, которая серьёзно относится к compliance и хочет избежать многомиллионных потерь не из-за хакерской атаки, а из-за невнимательности к тексту на тридцатой странице оферты.