При обсуждении темы
Поэтому могу рекомендовать следующее:
1) Заранее узнавать, как обстоят дела с вопросами безопасности у подрядчика.
2) Договариваться, что в случае инцидента у него он об этом не умолчит.
3) Контролировать, чтобы вашу инфраструктуру покидали правильно и чисто.
На моей памяти есть случаи, когда можно было найти служебных пользователей со слабыми паролями и высокими привилегиями или вообще шеллы, инструменты для взлома с прошлого пентеста внутри инфраструктуры. С точки зрения облачной специфики это могут быть также пользователи,
security supply chain чаще всего рассматривается только одна сторона, представляющая собой в том или ином виде код, есть и еще одна очень немаловажная. Это подрядчик/и. Уже известно не мало историй, когда внутрь компаний проникали не напрямую, а через подрядчиков, сервисные компании или просто у них забирали нужную информацию т.д. Часто такие компании с виду не представляют большого интереса и дела с вопросами безопасности там обстоят не хорошо. В итоге, проще атаковать их для достижения цели, чем, конечную, компанию.Поэтому могу рекомендовать следующее:
1) Заранее узнавать, как обстоят дела с вопросами безопасности у подрядчика.
2) Договариваться, что в случае инцидента у него он об этом не умолчит.
3) Контролировать, чтобы вашу инфраструктуру покидали правильно и чисто.
На моей памяти есть случаи, когда можно было найти служебных пользователей со слабыми паролями и высокими привилегиями или вообще шеллы, инструменты для взлома с прошлого пентеста внутри инфраструктуры. С точки зрения облачной специфики это могут быть также пользователи,
ServiceAccount и различные артефакты типа образов контейнеров, k8s ресурсов. Все это потенциально может расширить возможности реального атакующего.