Сначала атака была небольшой и мы попытались отбиться своими силами, поэтому мы использовали настройки, доступные в nginx. Например, забанили адреса, с которых велась атака, так как их было немного и это могло сработать. Однако тут же появились новые, атака усилилась и мы перешли к подключению loadbalancer.
То есть вы просто подняли Cloudflare и настроили его у клиента, так выходит?
И написали статью :)
Не только. Используя CloudFlare, мы смогли быстро перевести балансировку запросов на их серверы, спрятать реальные IP адреса инфраструктуры.
В инфраструктуре проекта был произведен аудит доступов, настроены системы автоматической блокировки «нежелательных» запросов.
"После этого перенесли управление данными из кабинета Яндекса в Cloudflare. Атакующей стороне пришлось «бороться» уже не с небольшим сервером магазина, а с масштабной и гибко настроенной инфраструктурой Амазона." - сайт перенесли на амазон или ошибка, cloudflare не продукт amazone. Ну и опыт такой себе, обойти защиту cloudlfare вполне реально, даже не нужен реальный ip. Но как cdn ему сейчас нет равных.
Плюс вам в карму за внимательность к нашему тексту. Мы действительно упустили слово «уровня».
«…и гибко настроенной инфраструктурой уровня Амазона».
"Не допускайте, чтобы их записывали на бумажку и оставляли на столе или держали в заметках на телефоне.:"
Как это сделать с другими людьми в компании?
Это один из самых сложных вопросов. В голову сразу приходят кейсы про телеинтервью специалистов, у которых на заднем фоне на мониторе приклеен стикер с паролями...
В профилактических целях подойдёт то, что отзывается в корпоративной культуре, даже беседа с сотрудниками с описанием кейсов взлома и влияния их работы на других. Но полагаться на обещания всё равно рискованно.
Тут, как говорится, надо «стелить солому» везде, где возможно. По максимуму пройтись по настройкам рабочих сервисов и выставить там, двухфакторные авторизации, требования к сложности пароля, разграничить доступ по нужным функциям и т.д.