Безопасность в devops

Основы безопасности в devops

Недавно прошло соревнование Pwn2Own 2024, результаты которого в очередной раз напоминают о главном правиле: абсолютно безопасных систем почти нет, особенно если речь идет о приложении, в котором несколько сотен тысяч строк. Open source тут далеко не гарантия надежности.

Наша задача как devops инженеров - снизить вероятность взломов.

Для этого есть несколько правил:

• Проблематично сломать то, к чему нет прямого доступа. Надежнее всего выключить сервер из сети, но это не всегда хороший вариант. Правило: наружу должно торчать только то, что необходимо. Например, если речь про сайт или мобильное приложение, то открыть нужно только доступ к 80 и 443 порту для браузера и аппки. Всякие служебные сервисы должны быть не просто закрыты файрволом, но желательно вообще сидеть во внутренней сети.

• Бекенд и фронтенд должны быть спроектированы таким образом, чтобы известные методы взлома не работали, к примеру SQL инъекции, и прочие инъекции. Это не задача девопсов, но понимать этот вектор атаки важно.

• Отказы в обслуживании или DDOS. Тут речь не про взлом, а про то что, приложение ляжет от паразитной нагрузки, что тоже так себе. Решением может стать фильтрация трафика своими средствами или внешними, вроде cloudflare.

• Грамотное разделение доступов в компании: разработчикам не нужно (ну почти) иметь доступ к данным пользователей, поэтому не нужно и провоцировать их на это. Если нужно что-то поменять в базе, пусть пишут миграцию, которая будет применена в процессе CI/CD или через специальный хендлер

• В git не должно храниться ничего, что представляет угрозу безопасности: пароли, ключи и тд. Приложение в момент запуска должно ходить в vault или аналог за всеми кредами, которые требуются для его работы.

Вот и думайте теперь, если ли абсолютно безопасные системы.