Как безопасно заменить критичную технологию под давлением санкций.

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

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

Я не согласен с формулой «сначала переедем, потом обеспечим безопасность». После переезда временные решения быстро становятся постоянными, а принятый в спешке риск исчезает из поля зрения руководства.

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

Сначала — минимально необходимая способность Первая доступная альтернатива не становится безопасной только потому, что прежняя технология недоступна. Но воспроизвести весь исторический набор функций в сжатый срок тоже нереалистично.

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

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

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

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

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

Новый поставщик тоже должен выдержать кризис Ускоренный выбор — не причина пропускать проверку. Опубликованное 8 июля 2026 года NIST SP 1326 предлагает оценивать поставщиков ИКТ по происхождению, устойчивости, базовым практикам кибербезопасности, уровням цепочки поставки и иностранному влиянию.

Иначе организация может заменить известную зависимость новой, ещё менее прозрачной.

Global Cybersecurity Outlook 2026 показывает масштаб проблемы: 91% крупнейших организаций изменили киберстратегию из-за геополитической волатильности. Для совета директоров это решение о непрерывности бизнеса, а не только технический проект.

Когда миграция действительно завершена Отключение старой системы — лишь событие в плане. Миграция завершена, когда компания доказала: - работу критичных сервисов под целевой нагрузкой; - целостность данных и корректность полномочий; - восстановление и передачу журналов в средства мониторинга; - готовность поддержки и реагирования на инциденты; - удаление старых доступов, интеграций, копий и секретов; - путь выхода уже из новой зависимости.

Моя позиция: зрелый CISO не блокирует неизбежную миграцию и не создаёт иллюзию обычного уровня гарантий. Он заставляет руководство осознанно выбрать переходный риск, ограничить срок его жизни и доказать восстановимость новой среды.

Что опаснее: остаться на неподдерживаемой платформе или ускоренно перейти на решение, безопасность и восстановление которого ещё не доказаны?