Переносим интернет-магазин в облако: с какими уязвимостями облачной безопасности чаще всего сталкиваются на практике?

Самый критичный технический косяк — оставлять старую версию сервиса метаданных виртуалок (metadata service). Если в каком-то плагине окажется SSRF-уязвимость, атакующий дернет этот локальный адрес и стянет временные креды, привязанные к инстансу. Принудительно включайте вторую версию метаданных и режьте роли до минимума.

Мы при переносе ритейл-сайта схожего масштаба случайно забыли открытым порт базы в тестовом окружении на 2 дня. За 48 часов прилетело 14 тысяч попыток автоматического брутфорса с разных IP. Если бюджет 1 200 евро, хотя бы 150 заложите на централизованное логирование и алерты в реальном времени.

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

Перед запуском обязательно проверьте три вещи: 1) Включите блокировку публичного доступа (block public access) на всех хранилищах. 2) Уберите серверы в приватную подсеть, наружу пусть смотрит только балансировщик нагрузки. 3) В админку пускайте всех сотрудников без исключения только с аппаратной или программной двухфакторкой.

чаще всего народ горит на конфигах, которые разрабы пушат в публичные репы на гитхабе. если api key улетел в код — все, суши весла, через пару часов на сервере уже майнер крутится.

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

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

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

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

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

Это мое мнение, не утверждаю, что оно единственно верное.

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

Удачи.

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

Надеюсь, это будет полезно.

Я тоже так считаю. Непроверенная резервная копия — не резервная копия.

То, что делают все, не значит, что это правильно. Удачи.

Хорошо, что вы создали эту тему. Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.

Это мое мнение, не утверждаю, что оно единственно верное.

Я маленький бизнес, расскажу со своей стороны. То, что делают все, не значит, что это правильно.

Я бы пошел этим путем.

Вы правы.

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

на этом всё, извините если затянул.

Сохранил. Спешка в решениях оборачивается исправлениями через полгода.

Удачи.

Мы тоже какое-то время назад застряли на том же месте. Меры, принятые без инвентаризации, оставляют открытыми двери, о которых вы не знаете.

Это мое мнение, не утверждаю, что оно единственно верное.