На переговорах о размещении объекта критической информационной инфраструктуры (КИИ) в облаке звучит одна и та же формула: все, что ниже виртуальной машины, обслуживает провайдер, все, что выше, остается у заказчика. Формула верная и она описывает, кто выполняет работы. При этом информировать государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА) об инцидентах, категорировать объекты и обеспечивать их безопасность по-прежнему обязан субъект.

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

Аттестованное облако провайдера и частное облако на площадке заказчика расходятся уже на уровне слоев инфраструктуры. С 1 марта 2026 года у самой площадки есть законное определение: понятие центра обработки данных закрепил федеральный закон № 244-ФЗ, и оно ограничено зданиями, инженерными системами и оборудованием. Все, что работает поверх площадки, распределяется между сторонами договором.

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

Разграничение существует ровно в том объеме, в каком оно записано. Провайдеры закрепляют его матрицей зон ответственности в приложении к договору, и глубина этого документа у площадок разная: у одной матрица расписана по слоям и уровням сервиса, у другой — это страница общих формулировок. Для государственных информационных систем состав документа задан нормативно: постановление Правительства от 18.08.2026 № 1024, действующее с 1 сентября 2026 года, требует регламент взаимодействия с распределением ответственности между заказчиком и поставщиком, а о сбое или нарушении защиты информации поставщик уведомляет заказчика в срок не более трех часов. Для объектов КИИ вне ГИС такой нормы нет: приказ ФСТЭК № 239 адресован субъекту и обязанностей провайдера не устанавливает, поэтому состав приложения определяют сами стороны. При этом заказчик вправе запросить у провайдера аттестат, уточнить границы его действия и получить комплект документов для аттестации собственной системы. Основание этого права двойное: договор с провайдером и собственная обязанность субъекта по приказу № 239 обеспечить безопасность объекта, размещенного в чужой инфраструктуре.

На практике в приложение к договору стоит вынести пять вещей.

1. Обновления и патчи с названным владельцем по каждому слою: платформа виртуализации, операционные системы серверов, средства защиты инфраструктуры.
2. Шифрование и ключи: где хранятся, кто и по какой процедуре получает доступ.
3. Мониторинг и журналы: какие события пишет провайдер, какие заказчик, сколько хранятся записи.
4. Аттестат провайдера: границы, срок действия, порядок действий при его обновлении в середине контракта, комплект документов для аттестации системы заказчика.
5. Инциденты и выход: кто ведет расследование, сроки взаимного уведомления, порядок переноса данных при завершении договора. Передача сведений в ГосСОПКА остается за субъектом.

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

Для государственных систем приказ ФСТЭК № 117 требует обязательств по безопасности в договорах с внешними организациями и закрепленной ответственности за их исполнение, а по правкам к приказу, опубликованным в августе 2026 года, подрядчик с доступом к ГИС рассчитывает показатель уровня зрелости до получения доступа и далее не реже раза в два года. Для значимых объектов КИИ то же направление задает приказ ФСТЭК № 220: с 1 марта 2027 года подрядчик с доступом к значимому объекту рассчитывает показатель до получения доступа и далее не реже раза в три года. Требование об этом субъект закрепляет в договоре.

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

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

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

«Формула простая: все, что ниже виртуальной машины, находится в зоне провайдера, все, что выше, остается в зоне заказчика. Эта формула работает, когда она записана в договоре. Обсуждения на встречах ее не заменяют. Срок действия аттестата провайдера и порядок его обновления в середине контракта. Владелец установки обновлений по каждому слою. Порядок выхода из сервиса и переноса данных. Эти три пункта заказчик закрепляет до подписания, и с весны 2027 года к ним добавляется четвертый: требования к подрядчикам с доступом к значимому объекту по приказу № 220. Закладывать его в приложение стоит уже сейчас»

Облако VK Secure Cloud работает по аттестату соответствия № 3740.00024.2026 от 20.02.2026, который покрывает государственные информационные системы класса К1, системы персональных данных уровня УЗ-1 и значимые объекты КИИ до первой категории значимости. Граница работ проходит по виртуальной машине, и слои ниже нее собраны из компонентов собственной разработки VK Tech: виртуализация, объектное хранилище и система резервного копирования входят в периметр аттестации целиком. Под каждого заказчика выделяется изолированный аппаратный контур, оплата идет за ресурсы.

В приложение к договору граница выносится по слоям, теми же строками, что в таблице выше, вместе с комплектом документов для аттестации системы заказчика. Для организаций, которым контур нужен на собственной площадке, есть частное облако VK Private Cloud с сертификатом ФСТЭК № 4857, действующим до 24.09.2029. Стек у двух продуктов общий, выбор идет от того, где должно стоять оборудование, и у каждой модели в договоре своя матрица.