https://habr.com/ru/companies/oleg-bunin/articles/786930/

Possible pilot deviation

Есть такой термин в авиации, отклонения пилота. Когда перечитываешь очередной материал про ИБ, DevOps, и концепции работы с безопасностью, задаешься вопросом, куда эти пилоты ведут наш самолет.


Я выработал две модели, в рамках которой весь мир делится либо на красное, либо на черное.

Первая модель - addictive (вызывающая привыкание) - которой следует большинство. Особенности модели - напихать анализаторов везде, где возможно, исходя из них уже чего-то делать, бегать махать руками на каждую CVE, и делать тонны QG для того, чтобы нагрузить код, систему. И безопасный пайплайн якобы.

Вторая модель - predictive (прогнозирующая) - выбор тру пацанов.
Особенности модели - мы разделяем системы и смотрим больше на их функциональность. Бекенд и фронтенд, и инстрафструктура, это разные доменные области, в рамках которых мы можем сначала разработать некоторую модель и архитектуру прогнозирующую риски. Например, бекенду плевать на CVE в рамках кубика. Ну объективно. Проблематику CVЕ можно обойти сегментацией сетей в облаке, правилами и контроля трафика + анализатор стоящий на отслеживание операций на хост машине. И обновляться раз в квартал. Экономия? значительная. Код микросервисов можно даже не гонять через анализаторы. Внезапно, так как есть другие способы его защищать.

“А как же пароли, ко-ко-ко, логины”. Для этого внезапно, можно научится наконец использовать профили и appconfig в коде. Убирать абстракции секретов из кубика, и работать только с конфигурационными файлами (которые кстати и были придуманы для этого). И конфигмапы совершенно случайно окажутся не нужны. Как и тонна доп лукошек, в которые складывают секреты, которым нужно строить еще защиту, для которой нужно еще создавать защищенные каналы.

Обе модели можно соединить. Однако в одном эксперименте, я все равно сначала сделал прогнозируемую, на основе нее построил архитектуру в облаке (отказавшись к слову от хваленых яндексовских локбоксов), и только потом начал думать над анализаторами и их внедрением. И то не для всего и вся. И в построении мифического безопасного пайплайна я не нуждаюсь.

Не страдайте possible pilot deviation.
Safety first - означает, что сначала лучше подумать, нежели потом бегать с коммунальными платформами, которые сами по себе создают угрозу компании, и несут тотальные затраты, чтобы их защищать. Я могу расписать еще более подробнее, если есть интерес. Для этого плюсик под пост.