Безопасность по умолчанию: программное обеспечение в DevSecOps

Это второй пост в серии, посвящённой архитектуре программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как набора технологически управляемых автоматизированных процессов. Если вы не читали первый пост, обязательно ознакомьтесь с ним!

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

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

https://blog.gitguardian.com/secure-by-design-software-in-devsecops/

#devops #девопс

Подпишись 👉@i_DevOps

Целостность и безопасность конвейера в DevSecOps

Это третий пост из серии глубокого погружения в архитектуру программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как совокупности ориентированных на технологии и автоматизированных процессов. Обязательно ознакомься также с первой и второй частью!

На данном этапе мы разобрали, как управлять уже существующими уязвимостями и как предотвращать появление новых. Теперь у нас есть жизненный цикл разработки ПО (SDLC), который обеспечивает создание программного обеспечения, безопасного «с самого начала». Осталось лишь разобраться, как обеспечить исполнение и защиту созданной нами архитектуры.

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


https://blog.gitguardian.com/pipeline-integrity-and-security-in-devsecops/

#devops #девопс

Подпишись 👉@i_DevOps

Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке

Взаимодействие между микросервисами — это больше, чем просто REST или RPC. Это фундамент архитектуры, от которого зависит масштабируемость, надёжность и производительность всей системы.

📌 Что будет на вебинаре:

— 5 ключевых стилей взаимодействия микросервисов: REST, gRPC, event-driven, messaging, CQRS;
— Сравнение: синхронное vs. асинхронное взаимодействие — плюсы, минусы, типичные ошибки;
— Когда использовать брокеры сообщений и какую роль играют очереди;
— Советы по построению отказоустойчивых коммуникаций между сервисами;
— Как логировать и отслеживать взаимодействия между микросервисами;

👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMHfWt

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Bash-совет: анализ неудачных SSH-логинов и бан «горячих» IP 🔒🐚

Хотите быстро узнать, какие IP вызывают максимум неудачных попыток входа в SSH, и оперативно заблокировать самых настырных? Ниже скрипт:

#!/usr/bin/env bash
# ssh_fail_analyzer.sh
# Анализ неудачных SSH-попыток и вывод TOP-10 IP

LOG_FILE="/var/log/auth.log"       # путь к логам (для CentOS: /var/log/secure)
TOPN=10                            # сколько IP показывать

echo "Топ $TOPN IP с неудачными SSH-входами:"
grep -E "Failed password for" "$LOG_FILE" \
  | grep -oP '(?<=from )[\d\.]+' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -n "$TOPN"

Как это работает

1. grep -E "Failed password for"
Ищем все строки с неудачными попытками.
2. grep -oP '(?<=from )\[\d.]+'
С помощью PCRE-регулярки достаём только IP-адреса после слова "from".
3. sort | uniq -c | sort -rn
Сортируем, считаем вхождения и выводим в порядке убывания.
4. head -n "\$TOPN"
Ограничиваем результат топ-10.


🛠 Можно добавить в crontab ежедневный запуск и автоматическую отправку отчёта на почту или сразу бан «горячих» IP через iptables:

# в crontab: каждый день в 00:10
10 0 * * * /path/to/ssh_fail_analyzer.sh | mail -s "SSH Fail Report" admin@example.com

Или сразу блокировать подозрительные IP, если они превысили порог:

THRESHOLD=50
for ip in $(grep -E "Failed password for" "$LOG_FILE" \
              | grep -oP '(?<=from )[\d\.]+' \
              | sort | uniq -c \
              | awk -v t="$THRESHOLD" '$1 > t {print $2}'); do
  iptables -I INPUT -s "$ip" -j DROP
  echo "$(date): Заблокирован $ip за превышение $THRESHOLD неудачных попыток" >> /var/log/ssh_ban.log
done

👉@bash_srv

Почему нельзя парсить вывод ls(1)

Команда ls(1) достаточно хорошо справляется с отображением атрибутов одного файла (по крайней мере, в некоторых случаях), но когда просишь у неё список файлов, возникает огромная проблема: Unix позволяет использовать в имени файла почти любой символ, в том числе пробелы, переносы строк, точки, символы вертикальной черты, да и практически всё остальное, что вы можете использовать как разделитель, за исключением NUL.
Существуют предложения по «исправлению» этой ситуации внутри POSIX, но они не помогут в решении текущей ситуации (см. также, как правильно работать с именами файлов). Если в качестве стандартного вывода не используется терминал, в режиме по умолчанию ls разделяет имена файлов переносами строк. И никаких проблем не возникает, пока не встретится файл, в имени которого есть перенос строки. Так как очень немногие реализации ls позволяют завершать имена файлов символаи NUL, а не переносами строк, это не позволяет получить безопасным образом список имён файлов при помощи ls (по крайней мере, портируемым способом).

https://habr.com/ru/articles/823298/

#devops #девопс

Подпишись 👉@i_DevOps

systemd: как писать юниты с элегантной перезагрузкой

Разработка системы с элегантным завершением работы может оказаться той ещё пляской с бубном. В идеальном мире каждый сервис управлялся бы юнитом systemd. ExecStart запускала бы процесс, обрабатывающий SIGTERM, а ExecStop оповещало бы процесс и осуществляло блокировку, которая бы корректно завершала процесс и его ресурсы.

Однако многие программы завершаются некорректно, а то и вовсе сбивают все настройки при закрытии. В этой статье мы рассмотрим поведение systemd при завершении работы и методы написания юнитов systemd для выборочной очистки (custom cleanup) перед закрытием.

https://www.psdn.io/posts/systemd-shutdown-unit/


#devops #девопс

Подпишись 👉@i_DevOps

Переезд с облака на свои сервера: взгляд со стороны инфраструктуры и бизнеса

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

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

https://habr.com/ru/articles/914438/

#devops #девопс

Подпишись 👉@i_DevOps

Нужно выкатить новую фичу, но нет уверенности, что всё пойдет как надо?

А еще…

🔻 Слабый мониторинг или его нет совсем.
🔻 Непонятно, почему система тормозит.
🔻 Клиенты жалуются на ошибки и долгое время ответа.

Знакомо? Приглашаем на онлайн-интенсив по Service mesh от Слёрм, на котором вы:

👉 решите реальные бизнес-кейсы;
👉 поймёте принцип работы и в будущем сможете применить знания на любом решении;
👉 научитесь искать причины проблем.

Даты проведения: 27-29 июня.

Спикеры:
– Александр Лукьянченко, руководитель юнита PaaS в Авито
– Виталий Лихачев, SRE в крупном голландском тревелтехе
– Георг Гаал, CTO AEnix

Специальные условия группам от 3-х человек.

👉 Программа и запись на интенсив по ссылке.

Pipeline инфраструктуры (Infra Pipeline)

Этот workflow описывает сквозной CI/CD-pipeline для сборки и деплоя инфраструктуры, включая quality gates (детекторы и оценку рисков).

Ветвление (Branching)
Рекомендуется создавать короткоживущие feature-ветки (локальные копии основной ветки trunk/main). В них выполняются изолированные изменения. На локальную ветку нет жёстких ограничений, но вы как разработчик обязаны регулярно синхронизировать её с основной (через rebase или merge), чтобы избежать merge conflicts.

Основная ветка (mainline/trunk)
Mainline (или trunk) служит для сборки и публикации deployable артефактов. Любой merge в неё может автоматически попасть в staging или production. Поэтому ветка должна быть постоянно в deployable-состоянии. Для этого в CI/CD pipeline настраиваются quality gates: статический анализ кода, unit- и интеграционные тесты, security scans, оценка рисков 🔒. Trunk остаётся locked до прохождения всех проверок и подтверждения безопасности изменения.

https://medium.com/@tusharmurudkar/devops-infrastructure-pipeline-beab47e7b876


#devops #девопс

Подпишись 👉@i_DevOps

«Прогрессивная доставка инфраструктуры с помощью Kargo и Argo CD» – Engin Diri, Pulumi

С момента выхода Kargo я изучаю возможность использовать его не только для доставки и продвижения приложений, но и для постепенного развёртывания инфраструктуры. С помощью Kubernetes-ориентированных инструментов, таких как Crossplane или Pulumi, мы описываем инфраструктуру как код и можем плавно развертывать её сначала в наших управляющих кластерах, а затем последовательно продвигать изменения через разные этапы без необходимости в дополнительных скриптах CD.

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

* Описание проблемы: необходимость безопасного и контролируемого релиза изменений в инфраструктуре
* Решение: использование Kargo для поэтапного развёртывания (Progressive Delivery)
* Инструменты IaC: Crossplane, Pulumi
* Преимущества:

* автоматизация продвижения конфигурации между окружениями
* отказ от «волшебных» CD-скриптов
* единый pipeline для приложений и инфраструктуры

Настройка Kargo вместе с Argo CD позволяет интегрировать управление приложениями и инфраструктурой в единую платформу progressive delivery, минимизируя риски и ускоряя итерации.

источник

#devops #девопс

Подпишись 👉@i_DevOps