"Доверие не отменяет контроля": как проверить безопасность облачного провайдера

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

В статье разберем, как проверить зрелость информационной безопасности провайдера, что спросить о SOC, уязвимостях и физической безопасности ЦОД. Опытом делится Демид Балашов, руководитель направления по развитию продуктов кибербезопасности МегаФона ПроБизнес.

Демид, с чего компании начать оценку кибербезопасности провайдера?

Я бы начал с вопроса: может ли провайдер показать, что его процессы безопасности работают не только на бумаге, но и в реальной ситуации?

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

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

Какие признаки показывают, что у провайдера зрелая функция ИБ?

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

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

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

Почему наличие собственного SOC у провайдера так важно?

Центр мониторинга и реагирования на инциденты информационной безопасности, или SOC, решает две задачи.

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

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

Для компаний без собственного круглосуточного SOC такой сервис помогает вовремя обнаружить подозрительную активность. При этом важно уточнять не только наличие центра мониторинга, но и его способность видеть облачный контекст. Недостаточно собирать системные журналы виртуальных машин. Нужны события IAM, API и панели управления облаком, изменения сетевых настроек, операции с хранилищами, Kubernetes, WAF, DDoS-защитой и CI/CD.

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

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

Стоит уточнить:

• какие активы и компоненты входят в периметр сканирования;
• как часто проводятся проверки;
• по каким правилам определяется критичность;
• какие сроки установлены для устранения;
• кто отвечает за исправление и контроль риска;
• как клиент получает информацию о ходе работ.

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

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

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

Один из чувствительных вопросов — доступ сотрудников провайдера к клиентской инфраструктуре. Как оценить его прозрачность?

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

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

PAM-система управляет условиями подключения привилегированных пользователей. JIT-механизм выдает права только на время конкретной задачи. Запись сессий и неизменяемые журналы позволяют восстановить команды и изменения, а процесс согласования — понять, кто разрешил подключение и на каком основании.

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

Что должно происходить при инциденте и как понять, что провайдер к нему готов?

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

Заранее стоит уточнить, есть ли контакты поддержки 24/7, сроки уведомления и реагирования, сценарии эскалации, порядок взаимодействия с SOC клиента и отчет по итогам инцидента.

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

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

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

Насколько важен отраслевой опыт провайдера?

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

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

Отраслевой опыт полезен как подтверждение реализованных сценариев. Заказчику стоит спросить, какие требования провайдер уже закрывал, есть ли референсные архитектуры и типовые защищенные контуры, проходил ли он аудиты и проверки, какие документы может предоставить и что потребуется донастроить под конкретный проект.

Что проверить в физической безопасности ЦОД?

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

Часть мер можно оценить по сертификатам ЦОД, SLA, регламентам доступа, отчетам аудитов и документам по резервированию. Для крупного или регулируемого заказчика нормальна очная проверка площадки.

Если ЦОД принадлежит третьей стороне, ответственным перед клиентом все равно остается облачный провайдер. Он должен контролировать подрядчика и подтверждать выполнение требований договором, SLA, правом аудита, регламентами доступа к стойкам и журналами посещений. Использование стороннего ЦОД — не перенос ответственности, а управление цепочкой поставки.

Какой набор ИБ-сервисов должен быть у провайдера?

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

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

Какой главный совет вы бы дали компаниям, которые выбирают облачного провайдера?

Начинать не с универсального списка требований, а с собственной задачи. До выбора облака компании нужно определить:

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

Базовый минимум — резервирование, физическая безопасность, надежность ЦОД, сертификаты, контроль доступов, мониторинг и регламенты реагирования. Но конкретные требования зависят от сценария: одно дело — использовать облако как дополнительную площадку, другое — полностью перенести туда критичную инфраструктуру.

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