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

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

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

Валентин Соколов, ИТ-директор облачной платформы RCloud by 3data, объяснил, какие риски возникают при миграции и как их снизить.

Модель разделения ответственности за облачную безопасность

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

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

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

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

Безопасность при миграции в облако: какие риски необходимо учитывать

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

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

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

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

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

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

Открытые ресурсы и избыточные права создают риск остановки операций

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

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

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

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

Провайдера выбирают не только по ресурсам и тарифам

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

Банкам и торговым сетям следует заранее оценить:

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

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

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

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

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

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

План реагирования нужен для восстановления операций

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

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

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