Доброго времени суток, уважаемые форумчане!
DevSecOps.Начало
DevSecOps.DevOps (ч.1)
SSDLC
Наконец-то мы добрались до последнего пункта этих статей и нашей основной цели - DevSecOps. Его внедрение без SSDLC крайне болезненное, но все же не бесполезное. Мы рассмотрим инструменты, которые помогут обеспечить безопасность DevOps.
Начнем с самых основ - настройки репозитория.
Настройка репозитория
Думаю это очевидно, но уязвимости часто возникают из-за очевидных вещей.Сделайте веткой по умолчанию НЕ ПРОДАКШЕН ВЕТКУ! Серьезно, к тому же, для предотвращения неприятных инцидентов в дальнейшем лучше ограничить возможности участников проекта по влиянию на продакшен ветку.
Ну и конечно никаких Force push в основные ветки.
Предполагается, что вы оценили все удобства использования контейнеров и используете их в своем проекте. Поэтому дальше о безопасности контейнеров.
Безопасность контейнеров
- Старайтесь использовать надежный образ - из официальных образов Docker. Если вам нужно выбрать базовый дистрибутив. Рекомендуется использовать Alpine Linux. Следует ли вам использовать тег latest? Тут по вашему желанию, но стабильная версия предпочтительнее.
- Создавайте и запускайте свое приложение под непривилегированным пользователем (либо явно в Dockerfile, или с помощью произвольного идентификатор пользователя во время выполнения).
- Если вам нужно настроить доступ к хосту, используйте опции [r|w|m] для выборочного включить чтение, запись или mknod.
- Явно ограничивайте использование ресурсов, чтобы избежать DDoS-атаки.
- Ограничьте смонтированную файловую систему только на чтение.
- Создайте хранилище в оперативной памяти для временные файлов в директории /tmp.
- Настройте локальный раздел /usr/local/myapp только для чтения.
- Рекомендуется экспортировать логи на внешний сервис.
- Отключите мост по умолчанию и используйте выделенную сеть для предоставления интерфейса хоста.
Существуют множество автоматических инструментов по анализу, например Clair или Docker Bench Security.
Обучение сотрудников
Самым надежным способом защиты приложения всегда остается обучение команды разработчиков безопасной разработке. У OWASP есть документ, который содержит
Ссылка скрыта от гостей
. Если разработчики с ним ознакомятся и поймут, это повысит безопасность кода, который они пишут.Следующий шаг это практика. Можно показывать уязвимости, например с сайта
Ссылка скрыта от гостей
и как их эксплуатировать, а потом просить разрабов понять какой же код привел к этому.Дальше можно проводить CTF. И это реально несет пользу, потому что у участников будет соревновательный элемент.
Если организовывать CTF нет сил и/или времени, то хорошими ресурсами для практики являются TryHackMe и HackTheBox. Обе платформы имеют хорошее комьюнити и предназначены для любого уровня.
Главное в этом пункте - системность. Например, у вас есть встречи каждую неделю, две недели вы обучаетесь по Portswigger Academy, на третьей неделе выступает спикер с докладом о какой-то найденной уязвимости, желательно с PoC, на четвертой неделе проводится CTF, который включает изученные материалы в этом месяце плюс изученные ранее.
Из под палки обучаться тоже тяжело, поэтому тут проще выделить Security Champion, которые будут ходить обязательно, а остальные по желанию. Кроме того, таким образом можно будет обеспечить заменимость Security Champion-ов в случае их отсутствия.
Обучение это конечно хорошо, но это долго. Поэтому нужно перестраховаться до момента, когда разработчики смогут самостоятельно обезопасить код. На помощь к нам приходят SAST и DAST.
SAST
SAST (Static Application Security Testing) — тестирование «белого ящика», существует уже более десяти лет. Позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО.“В теории нет разницы между теорией и практикой. На практике есть”
Поэтому давайте внедрим в уже существующий проект pipeline с SAST для нашего кода.
Так как мы используем Gitlab CI, то можно использовать их
Ссылка скрыта от гостей
.
И получаем:
Все! Готово. Теперь у нас есть SAST =)
Важный факт, работает это только если у вас есть stage test
DAST
DAST (Dynamic Application Security Testing) — тестирование «черного ящика», может обнаруживать уязвимости и слабые места в работающем приложении, обычно веб-приложениях. Это достигается за счет использования методов внедрения ошибок в приложении, таких как передача вредоносных данных в программное обеспечение, для выявления распространенных уязвимостей безопасности, например, SQL-инъекций и межсайтовых сценариев.С таким видом тестирования сложнее. Как правило для качественного тестирования нужны довольно дорогие приложения, например Acunetix.
Нам повезло, у Gitlab есть и встроенный DAST. Подключить его не составляет труда:
1. Добавляем stage dast
2. Подключаем встроенный DAST
3. В переменных указываем что нужно проверять инструменту
Хорошим примером DAST также является OWASP ZAP и Burp Suite, а так же Acunetix (стоит как крыло от самолета)
На этом на сегодня все.
Спасибо за внимание!
Последнее редактирование модератором:
