Закупка облачных услуг и ЦОД: как соблюсти 152-ФЗ, SLA и требования импортозамещения

Закупка облачных услуг и размещение оборудования в центрах обработки данных (ЦОД) давно перестали быть узкой технической задачей. Для государственного или корпоративного заказчика это сложный юридический и организационный процесс, в котором пересекаются нормы 44-ФЗ (или 223-ФЗ), требования регуляторов к защите персональных данных (152-ФЗ), жесткие параметры соглашения об уровне сервиса (SLA) и политика импортозамещения. Ошибка на этапе планирования или составления технического задания грозит не только неработоспособностью сервиса, но и серьезными штрафами.

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

Почему облачные услуги и ЦОД требуют особого подхода в закупках

Специфика закупки облачной инфраструктуры (IaaS), платформенных сервисов (PaaS) или услуг дата-центров (colocation) вытекает из нематериальной природы предмета договора. Заказчик приобретает не коробочный продукт, а непрерывный сервис, качество которого напрямую влияет на его операционные процессы. Ключевые риски связаны с тремя направлениями: утечка или незаконная обработка персональных данных, длительные простои из-за аварий и нарушение запретов на закупку иностранного ПО.

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

Соблюдение 152-ФЗ при закупке облачных сервисов

Федеральный закон «О персональных данных» требует от оператора обеспечить локализацию баз данных на серверах, физически расположенных в России. При использовании облака или аренде стойки в ЦОД заказчик должен быть уверен, что провайдер не выведет данные за пределы страны, а трансграничная передача не происходит без законных оснований.

Ключевые требования к провайдеру

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

Кроме того, провайдер должен соответствовать требованиям к защите информации. Если заказчик обрабатывает государственные информационные системы (ГИС), может потребоваться аттестация по требованиям ФСТЭК. В документации о закупке стоит прописать обязанность исполнителя предоставить копии действующих лицензий ФСТЭК на деятельность по технической защите конфиденциальной информации и сертификаты на средства защиты.

Порядок действий для заказчика

1. Определите категорию данных. Установите, относятся ли обрабатываемые сведения к персональным данным, специальным категориям или биометрии. От этого зависит уровень защищенности.
2. Проведите аудит модели угроз. Еще до публикации извещения определите актуальные угрозы безопасности для вашей информационной системы.
3. Включите требования в проект контракта. Пропишите обязанность провайдера уведомлять заказчика о любых инцидентах, связанных с несанкционированным доступом, и о плановых изменениях в инфраструктуре.
4. Предусмотрите право на аудит. Включите в договор условие о возможности проведения заказчиком или уполномоченным органом проверки соблюдения провайдером требований 152-ФЗ.

Формулирование SLA: от обещаний к измеримым показателям

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

Основные метрики SLA

• Доступность (Uptime). Обычно выражается в процентах (99,9%, 99,99%). Важно уточнить, как считается простой: включаются ли плановые регламентные работы и время, необходимое для восстановления после сбоя.
• Время реакции на инцидент (Response Time). Период с момента регистрации обращения до первого ответа технической поддержки.
• Время восстановления сервиса (RTO). Максимально допустимый срок, в течение которого услуга должна быть восстановлена после серьезного сбоя.
• Допустимая потеря данных (RPO). Максимальный период, за который данные могут быть утеряны в результате инцидента.

Как встроить SLA в закупочную документацию

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

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

Импортозамещение в облаках и ЦОД: нацрежим в действии

Политика импортозамещения в IT-сфере реализуется через механизмы национального режима, установленные статьей 14 44-ФЗ и соответствующими постановлениями Правительства. Для закупок по 223-ФЗ также действуют нормативные акты, обязывающие отдавать приоритет российским товарам и программному обеспечению. Закупка облачных услуг и инфраструктуры ЦОД напрямую попадает под эти ограничения, так как предполагает использование программно-аппаратных комплексов.

Реестры отечественного ПО и оборудования

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

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

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

Предположим, государственное казенное учреждение планирует закупить услугу IaaS для развертывания внутренней системы электронного документооборота, содержащей персональные данные сотрудников. Алгоритм действий заказчика будет выглядеть так:

1. Анализ потребности. Определяются необходимые вычислительные мощности, объем хранилища, требования к резервному копированию и сетевой связности.
2. Проверка нацрежима. Заказчик изучает реестр отечественного ПО. Поскольку система документооборота может быть развернута на базе российской операционной системы и платформы виртуализации, включенных в реестр, устанавливается запрет на закупку иностранного ПО.
3. Формирование техзадания. В описание объекта закупки включается требование о предоставлении услуги на базе сертифицированного российского программного обеспечения. Указывается, что все данные должны храниться в ЦОД на территории РФ, а провайдер обязан иметь лицензию ФСТЭК.
4. Расчет НМЦК. Цена определяется методом сопоставимых рыночных цен на основе коммерческих предложений российских облачных провайдеров.
5. Установление SLA. В проект контракта включаются показатели доступности не ниже 99,95%, время реакции на критические инциденты — не более 15 минут, штраф за час простоя — 1% от месячной платы.

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

Распространенные ошибки и способы их избежать

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

• Копирование требований из коммерческих оферт. Заказчики часто переносят в техзадание формулировки с сайта конкретного провайдера («уровень Tier III», «премиум-поддержка»), не раскрывая их содержание. Это создает риск ограничения конкуренции и жалоб в ФАС. Каждое требование должно быть расшифровано в измеряемых показателях.
• Игнорирование физического размещения данных. Указание в договоре юридического адреса провайдера в России не гарантирует, что серверы находятся в РФ. Необходимо требовать конкретные адреса ЦОД и право на их проверку.
• Размытые санкции за нарушение SLA. Если в контракте просто указано «исполнитель несет ответственность в соответствии с законодательством», добиться компенсации за простой будет крайне сложно. Штрафные санкции должны быть четко привязаны к конкретным метрикам и периодам нарушения.
• Закупка иностранного облака без обоснования. Попытка обойти запрет, сославшись на «уникальность» зарубежного сервиса без сбора доказательств несовместимости с российскими аналогами, почти гарантированно приведет к предписанию контрольного органа.

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

FAQ: часто задаваемые вопросы

Можно ли закупить услуги зарубежного ЦОД, если в России нет аналогов по мощности?

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

Обязан ли провайдер облака использовать только российское «железо»?

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

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

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

Что делать, если облачный провайдер нарушает SLA, но отказывается платить штраф?

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

Итог

Закупка облачных услуг и мощностей ЦОД — это мультидисциплинарная задача, требующая от заказчика одновременного владения нормами контрактного законодательства, регулирования в сфере защиты данных и технической грамотности. Успех сделки закладывается на этапе подготовки документации: четкое описание требований к локализации данных, измеримые и жесткие параметры SLA, а также корректное применение механизмов импортозамещения. Игнорирование любого из этих аспектов создает риск получения неработающего сервиса или, что еще хуже, административной и уголовной ответственности за утечку данных. Тщательная проработка технического задания и проекта контракта с опорой на актуальные нормы — единственный способ минимизировать эти риски и получить надежную облачную инфраструктуру.