👋 Amazon уходит из облака

Amazon Web Services остаётся крупнейшим игроком на рынке, но всё чаще звучит тезис: компания пересматривает стратегию облака. Разбираем, что стоит за этим и куда движется инфраструктура.

AWS остаётся ядром компании, но Amazon перестраивает архитектуру и уходит от модели «чистого облака». Причина в том, что централизованные дата-центры всё чаще сталкиваются с ограничениями.

Во-первых, задержки: для логистики, IoT и real-time приложений критично, чтобы вычисления происходили ближе к пользователю, а не через тысячи километров.

Во-вторых, стоимость: передача и хранение огромных массивов данных, особенно для машинного обучения, в облаке обходится слишком дорого.

В-третьих, регуляторика: данные приходится хранить локально, а не в удалённых центрах, из-за требований GDPR и национальных законов.

Ответ Amazon на эти вызовы — активные инвестиции в edge-computing, развитие гибридных решений и оптимизация инфраструктуры через Nitro Systems. Это не отказ, а эволюция: облако остаётся, но становится более распределённым и ближе к конечным пользователям.

В перспективе нас ждёт сдвиг: вместо выбора между «облаком» и «on-prem» компании будут строить гибридные системы, балансируя между скоростью, стоимостью и безопасностью.

🐸Библиотека devops'a

#разбор_полётов

💥 Jenkins снова под прицелом

Представьте: вы открываете Jenkins, даже не авторизовавшись, и видите список агентов, их ОС, состояние очереди и подключённость. Именно так работала страница /securityRealm/signup до версии 2.528.

Почему так вышло

Jenkins когда-то включил туда стандартную боковую панель, а в ней отображались статусы билдов. Никто не заметил, что даже неавторизованный пользователь может глянуть в кухню CI/CD.

Как нашли

Исследователь просто прошёл по URL, получил ответ и увидел всю внутреннюю картину — идеальный старт для атакующего:

— имена агентов → подсказка для lateral movement,
— ОС узлов → выбор эксплойтов,
— статус очереди → понимание нагрузки системы.

В Jenkins 2.528 и LTS 2.516.3 разработчики вычистили include боковой панели из signup.jelly. Теперь любопытный глаз ничего лишнего не увидит.

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

🐸Библиотека devops'a

#разбор_полётов

🚨 570 ГБ данных утекают из GitLab

Группа Crimson Collective заявила о похищении ~570 ГБ данных из внутреннего GitLab-инстанса Red Hat, используемого подразделением консультационных услуг. В числе утечек — отчёты клиентов (CERs), конфигурации и внутренние коммуникации.

В Red Hat подтвердили инцидент, пояснив, что взлом затронул GitLab-инстанс, используемый только в рамках подразделения консультационных услуг, и что инстанс не был публичным сервисом Red Hat.

Ошибки и слабые стороны

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

• По заявлению злоумышленников, они пытались связаться с Red Hat с требованием выкупа, но получили шаблонный ответ и инструкцию подать отчет об уязвимости. Заявляется, что тикет непрерывно переназначался.

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

Что можно сделать

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

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

• Даже если данные украдены, шифрование может сделать их бессмысленными для злоумышленников.

• Клиенты, чьи данные могли быть скомпрометированы, должны быть уведомлены. Лучше быть честным и открытым.

➡️ Источник

🐸Библиотека devops'a

#разбор_полётов

⚠️ Oracle EBS: zero-day

Oracle выпустила экстренный патч для E-Business Suite версии 12.2.3–12.2.14.
Уязвимость CVE-2025-61882 позволяла удалённое выполнение кода без аутентификации — достаточно открытого порта и доступа к BI Publisher.

Эксплуатировалась в реальных атаках, включая кампанию группы Clop, которая крала корпоративные данные через Oracle EBS.

Что делать девопсу в таком случае

1. Патчи безопасности нужно применять вне планового цикла, особенно в системах ERP-уровня.
CI/CD-пайплайн должен поддерживать fast-lane patching: отдельный процесс для критических обновлений без фризов релиза.

2. Чтобы поставить этот патч, требуется предыдущий CPU-апдейт октября 2023 года.
DevOps-команды должны отслеживать “dependency chain” патчей — иначе экстренное обновление просто не применится.

3. Даже после установки фикса:

— анализируйте логи доступа к BI Publisher и Concurrent Processing;

— внедрите мониторинг системных вызовов и сетевой активности (reverse shell, неожиданные соединения);

— настройте оповещения SIEM на команды вроде bash -i или curl | sh

➡️ Новость

🐸Библиотека devops'a

#разбор_полётов

🚨 Взлом SMS-агрегаторов: почему CI/CD под угрозой

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

Почему это должно волновать DevOps

• Supply Chain Attack в чистом виде

SMS-агрегаторы — это классический пример supply chain риска. Через них проходят одноразовые коды, PIN-коды и ссылки восстановления паролей для тысяч сервисов. Одна скомпрометированная точка — и валится безопасность всей цепочки.

• Ваши 2FA коды больше не ваши

Перехват 2FA-кодов и ссылок восстановления открывает путь к массовым захватам аккаунтов — от банков до корпоративных систем.

Что с этим делать

• Аудит зависимостей: составьте список всех внешних сервисов, через которые идёт критичная коммуникация.

• Мониторинг аномалий: настройте алерты на необычную активность в SMS/email каналах.

• Проверка API-ключей: убедитесь, что ключи доступа к агрегаторам не светятся в логах, Slack или документации.

• Многофакторность: используйте несколько каналов для критичных операций, напримеp, SMS + authenticator app + hardware token.

• Rate limiting: ограничьте количество запросов к SMS API и OTP-генерации.

• Zero Trust для внутряков: даже если сотрудник прошёл SMS-2FA, требуйте дополнительное подтверждение для критичных действий.

Главный урок: в supply chain нет мелочей. Каждая зависимость — потенциальный вектор атаки.

А можно просто пойти в Data Science и тогда защищать будете не вы, а вас. С нашим курсом математики для Data Science переход будет проще простого, ещё и со скидкой!

🐸 Библиотека devops'a

#разбор_полётов

💥 Массовая поломка AWS

20 октября произошёл крупнейший сбой AWS в истории. Упали Netflix, Reddit, PlayStation, Amazon и ещё 2500+ сервисов по всему миру. Давайте разберём, что пошло не так и какие выводы должен сделать каждый DevOps.

Что сломалось

Проблема началась с неправильной настройкой DNS в регионе US-East-1. Это старейший и самый нагруженный дата-центр Amazon, через который проходит трафик банков, стартапов, стриминговых платформ и AI-систем.

Когда приложение обращается к базе данных, оно спрашивает у AWS: «Где мои данные?». В тот день AWS отвечал: «Не знаю». Один неправильный конфиг оборвал связь между приложениями и их базами данных.

Что делать DevOps-инженеру

Один DNS-конфиг не должен откатывать цивилизацию на 50 лет назад. Но откатил. Вот что нужно проверить в своей инфраструктуре:

• Не держите все яйца в US-East-1. Разносите критичные сервисы по регионам.

• Мониторинг внешних зависимостей — если AWS падает, вы должны узнать об этом раньше ваших пользователей.

• Graceful degradation — приложение должно уметь работать в режиме ограниченной функциональности, а не просто умирать.

• Проверка конфигов — внедрите code review для инфраструктурного кода. IaC тоже может содержать критичные ошибки.

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

🐸 Библиотека devops'a

#разбор_полётов