Безопасная миграция в облако: оценка рисков и пошаговый план

На вебинаре эксперты К2 Cloud и К2 Кибербезопасность обсудили, какие задачи бизнеса можно доверить облачной инфраструктуре, как минимизировать риски переезда, на какие критерии ориентироваться при выборе облачного провайдера для безопасной миграции.

Представляем вашему вниманию расшифровку вебинара.

Анжелика Захарова. В конце 2025 года мы совместно с компанией Positive Technologies провели масштабное исследование, в котором участвовало более 400 компаний. Мы изучали, как выстроены процессы ИБ, какие ИБ-сервисы используются, как определяется бюджет и т. д.

Ниже приводятся наши ключевые выводы.

Бюджетирование:

• У 38% компаний выделенного бюджета на ИБ нет вообще

• У 29% расходы на ИБ включены в общий ИТ-бюджет

• У 24% финансирование идет по остаточному принципу

• Лишь 9% применяют формальный риск-ориентированный подход

Это говорит о низкой зрелости бюджетного планирования в сфере ИБ.

Соответствие требованиям регуляторов:

• 34% компаний соответствуют требованиям частично или находятся в процессе обеспечения соответствия

• 26% не соблюдают никаких требований регуляторов

• Только 19% формально соответствуют критериям хотя бы одного аудита и могут его пройти
  
  

Процессы и сервисы:

• Только 9% компаний имеют четкий процесс управления уязвимостями с охватом всех активов и подробно описанными SLA и метриками

• 12% участвуют в программе Bug Bounty и проводят регулярные пентесты (своими силами или привлекая внешних экспертов)

• 84% вообще не имеют сценария реагирования на инциденты

• Только у 17% внедрен полноценный SOC или иной сервис со всеобъемлющим покрытием активов
  
  

Процессы ИБ в большинстве организаций все еще формализованы не полностью и сильно зависят от ИТ-функций. Наиболее зрелые направления —  обучение, управление уязвимостями и мониторинг, но и там преобладает ситуативный, а не системный подход.

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

Какие тренды мы видим в 2026 году? 

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

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

Арина, с какими запросами сейчас приходят заказчики?

Арина Ашотян. Я бы выделила следующее:

• Приведение в соответствие требованиям Федерального Закона № 187-ФЗ (безопасность КИИ)

• Аудиты государственных информационных систем в связи с вступлением в силу Приказа № 117 ФСТЭК

• Усиление защиты в финансовом секторе (банки, страховые компании, МФО) под давлением требований ЦБ

Кроме того, участились запросы на оценку зрелости ИБ по международным стандартам (например, ISO 2700х). Компании хотят понимать реальное состояние дел, а не просто выполнять требования для галочки.

Арина Ашотян. Есть несколько устойчивых мифов относительно облачной безопасности. Давайте обсудим каждый из них. 

Миф 1: провайдер отвечает за все
Миграция в облако не снимает с заказчика ответственности за ИБ. Провайдер отвечает за безопасность инфраструктуры, гипервизора и физической среды. Все, что выше, находится в зоне ответственности заказчика. 

Это подтверждается и требованиями регуляторов. Так, например, оператор персональных данных или субъект КИИ несет полную ответственность за безопасность независимо от места размещения данных.

Миф 2: субъектам КИИ нельзя в облако
Это не так. Прямых регуляторных запретов нет. Нужно выяснить, является ли организация действительно субъектом КИИ (и если да, какие у нее есть значимые объекты), провести категорирование объектов и понять, какие ограничения действительно применимы. 

Для значимых объектов КИИ действуют требования Приказа № 239 ФСТЭК, Указов № 166 и № 250 Президента РФ и Постановлений Правительства,  например, запрет на иностранное ПО и обязательная локализация данных в России. 

Но все эти требования выполнимы, и миграция части инфраструктуры в облако возможна. Российские провайдеры предлагают гибкие решения: выделенные инсталляции, отдельные сегменты под значимые объекты КИИ (ЗОКИИ) или PCI DSS. Инфраструктура под конкретные требования безопасности — это объективная реальность нашего рынка, а не исключение.

Миф 3: финансовым организациям нельзя в облако
ГОСТ 57580.1 не запрещает облака. Он устанавливает требования к мерам защиты, которые должны быть реализованы независимо от места размещения. Ключевой вопрос — как распределить ответственность за ИБ между провайдером и финансовой организацией и документально это зафиксировать. 

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

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

• Жесткие комплаенс-ограничения, прямо предписывающие размещать системы локально 

• Системы реального времени с критическими требованиями к задержкам

• Системы с устаревшими ПО и архитектурой, которые не менялись 10–20 лет

В таких ситуациях мы предлагаем гибридную модель: часть систем остается on premise, часть переносится в облако. Это позволяет соблюсти требования, гибко управлять бюджетом благодаря оплате по фактическому использованию (pay as you go) и снизить риски.

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

• Анализ текущей схемы
• Получение аттестата ФСТЭК
• Предоставление инфраструктуры, средств защиты информации и VPN
• Миграцию и взаимодействие с аттестующим органом

В итоге вы получаете аттестат, полный пакет документов, защищенный контур и инфраструктуру, аттестованные на соответствие требованиям Приказа №117 ФСТЭК. Длительность проекта составляет от 2 до 5 месяцев в зависимости от начальных условий.

Подробнее читайте на странице услуги на нашем сайте.

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

1. Соблюдение требований регуляторов. Мы в K2 Cloud системно инвестируем в безопасность и регулярно проходим аудиты. К2 Облако имеет 

• сертификации по ГОСТ ISO/IEC 27001, 27017

• лицензии ФСТЭК и ФСБ 

• аттестацию на соответствие требованиям Федерального Закона № 152-ФЗ

• отраслевые сертификаты ГОСТ 57580.1-2017, PCI DSS 4.0
  
  

2. Доступные ИБ-сервисы из облака. Помимо стандартных инструментов облачной безопасности особо отмечу два сервиса, которые мы внедрили в конце 2025 года:

• Анти-DDoS с очисткой трафика на уровнях L3 и L4 на платформе Servicepipe

• Зеркалирование трафика. Мы — единственный российский облачный провайдер, предлагающий эту услугу в облаке (ранее такое делали только международные игроки)

Арина Ашотян. Как еще до подписания договора понять, что провайдер действительно готов к работе с вашими системами? Рекомендуем обсудить несколько ключевых вопросов:

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

2. Управление уязвимостями: проводятся ли регулярные сканирования, каковы сроки устранения критических уязвимостей?

3. Мониторинг: вся ли инфраструктура охвачена мониторингом?
   
   

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

Анжелика Захарова. Я бы добавила еще три маркера:

1. Комплаенс. Наличие широкого стека сертификатов (включая отраслевые) говорит о системных вложениях в безопасность.

2. Зрелость процессов. Хороший индикатор — участие в программе Bug Bounty. Провайдер открыто предлагает исследователям искать уязвимости.

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

Арина Ашотян. Начинать нужно не с вопроса «как защитить облако?», а с вопроса «что именно мы переносим и что из этого требует особого внимания?». Важно понять:

• какие системы и данные будут мигрированы

• какова их архитектура

• к какой регуляторной сфере они относятся
  
  

Типы систем и соответствующая регуляторика:

• Системы обработки персональных данных (HR, CRM, веб-сайты с формами) — № 152-ФЗ, Приказ № 21 ФСТЭК

• Объекты КИИ — требования ФСТЭК, Указов Президента и Постановлений Правительства РФ

• Финансовые системы (процессинг, ДБО) — ГОСТ 57580.1-2017 с определенным уровнем защиты
  
  

Актуализация процессов ИБ. При смене инфраструктуры или привлечении провайдера облачных услуг нужно обновить регламенты, политики и модели угроз. Так, например, по сравнению с локальной системой в облаке появляются новые векторы атак (атаки через API, риски при управлении доступом), поэтому модель угроз должна стать двухслойной:

• Слой провайдера (физическая инфраструктура, гипервизор, сеть)

• Слой заказчика (приложения, данные, доступ, конфигурации)
  
  

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

Локализация данных. В Федеральном Законе № 152-ФЗ четко указано, что с 1 июля 2025 года сбор, хранение и обработка персональных данных граждан РФ должны осуществляться исключительно на серверах, расположенных в России. И даже у российских провайдеров нужно проверять фактическое расположение инфраструктуры и отражать это в договоре. Если же говорить о ЗОКИИ, то для них, помимо локализации, необходимо использовать доверенный российский стек, т. е. иностранное ПО и оборудование фактически запрещено использовать.

А теперь поговорим о распределении ответственности.

Анжелика Захарова. На слайде показана наша модель разделения ответственности: кто за что отвечает в зависимости от модели облачных услуг.

Модель IaaS (инфраструктура как услуга)

• Провайдер: физические серверы, инженерная инфраструктура, гипервизор

• Заказчик: все, что находится внутри виртуальной машины — операционная система, установка патчей, настройка СЗИ, управление пользователями, защита данных
  
  

Модель PaaS (платформа как услуга). Можно сказать, что это модель, которая базируется на совместной ответственности.

• Провайдер: работоспособность платформы, патчи безопасности приложений

• Заказчик: управление данными внутри базы, согласование окон для установки обновлений
  
  

Модель SaaS (ПО как услуга)

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

• Заказчик: управление доступом и данными
  
  

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

Арина Ашотян. Компания K2 Кибербезопасность предлагает полное сопровождение в части ИБ на всех этапах:

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

2. Выбор провайдера: помощь в формировании матрицы ответственности (RACI) — «живого» документа, который снимает множество вопросов до начала работ

3. В процессе миграции: аудит систем, актуализация документации (политик, регламентов, модели угроз) под новую среду

4. После миграции: аудит новой инфраструктуры, проверка конфигураций (опция)

5. Поддерживающие GAP-аудиты: периодические проверки, призванные убедиться, что с течением времени работа системы не отклонилась от требований (по желанию заказчика)
   
   

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

Мы также анонсируем наш совместный с Positive Technologies проект — новый релиз аудита зрелости и готовности бизнеса к миграции в облако и построению защищенной инфраструктуры. С его помощью вы сможете самостоятельно оценить текущий уровень процессов, потребностей и рисков. Следите за анонсами на веб-сайтах K2 Cloud и K2 Кибербезопасность.

Вопрос. Как защитить информацию в облаке от специалистов, обслуживающих облако?

Анжелика Захарова. Мы априори не имеем доступа к вашим инфраструктурам. Это гарантируется договором и внутренними процедурами. Кроме того, для усиления гарантий конфиденциальности размещаемых вами данных мы ежегодно добавляем новые сервисы для усиления безопасности. Так, скоро мы запустим два новых сервиса: Key Management System (KMS) и шифрование дисков. Специалисты облака не имеют доступа к вашим данным и системам и никак не могут на них влиять.

Вопрос. Мы из финтеха, и наш комплаенс категорически против облаков в силу ГОСТ 57580. Как доказать аудитору из ЦБ, что меры безопасности на стороне провайдера соответствуют стандарту?

Арина Ашотян. Повторюсь: ГОСТ 57580 не запрещает облака. Он требует реализации мер защиты. Часть мер принимает провайдер, часть вы. Стандартная практика — запросить у провайдера ответы на опросные листы. Скорее всего, вам придется подписать с провайдером договор о неразглашении. Все обязательства можно зафиксировать в договоре или в дополнительном соглашении с четко определенными SLA и зонами ответственности.

Анжелика Захарова. В проектах с жесткими требованиями к безопасности мы проявляем полное понимание и обеспечиваем максимальную прозрачность предоставления информации, чтобы минимизировать все возможные издержки (включая временные) при подтверждении соответствия.

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

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

Вопрос. Как разделяется ответственность за сохранность персональных данных при утечке по вине исполнителя?

Арина Ашотян. В соответствии с №152-ФЗ вся ответственность за сохранность персональных данных возлагается на оператора, то есть на организацию, которая эти данные собирает, определяет цели использования, объем данных и т.д. Если вскроется утечка по вине подрядчика, то, во-первых, уведомлять регулятора о факте утечки должен оператор персональных данных, то есть вы, а во-вторых, всю ответственность перед регулятором тоже будете нести вы. Однако вы можете взыскать убытки с исполнителя, если в договоре прописаны соответствующие условия (поручение на обработку персональных данных или соглашение о конфиденциальности). Мы также рекомендуем обязать подрядчика оперативно уведомлять о происшествиях и участвовать в расследовании.

Вопрос. Как выстроить единый мониторинг безопасности при гибридной модели?

Арина Ашотян. Главное — выработать единый подход и привести процессы ИБ к единому стандарту с учетом работы с подрядчиком. Не менее важно настроить интеграцию. Современные SOC-платформы и SIEM-системы позволяют собирать события как из локальной инфраструктуры, так и из облака. Интеграция позволит команде ИБ видеть полную картину, а не разрозненные фрагменты. Необходимо обратить внимание на техническую составляющую, чтобы выяснить, покрывают ли имеющиеся технические средства защиты все потребности и всю облачную инфраструктуру, и при необходимости выполнить дополнительную настройку или, возможно, закупить дополнительные технические средства.

Вопрос. Как обеспечить интеграцию между ИС в разных контурах при гибридной схеме?

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

Вопрос. Для всех ли работает зеркалирование трафика или только для VIP-клиентов? Можно ли подключить свой анализатор?

Анжелика Захарова. Это публичный NTA-мониторинг, работающий в российском публичном облаке. Система разворачивается в виде виртуальной машины, трафик копируется на порт анализатора и при помощи технологии зеркалирования анализируется на уровне облачной платформы. Сервис совместим с решениями PT NAT, UDV NTA, Garda NDR и другими решениями с открытым исходным кодом.