Интеграция безопасности в DevOps: советы по включению

Когда началась пандемия, многим компаниям пришлось быстро менять свою бизнес-модель. Фактически, многие начали упускать некоторые аспекты безопасности, которые были компромиссом для быстрого цикла разработки и предоставления новых функций для клиентов. Пришло время вернуться и пересмотреть политику и руководящие принципы безопасности, а также то, как наилучшим образом интегрировать их в процесс гибкой разработки.



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

Чтобы сформировать мышление в области безопасности в инженерной организации, группы безопасности должны предоставить инженерным группам инструменты, соответствующие их рабочему процессу. Если решение группы безопасности состоит в том, чтобы просто поместить код оболочки поверх инструмента, который поручают группы безопасности, это станет дополнительным методом управления, который может замедлить прогресс.

Обеспечение безопасности в гибком и разработанном способе работы

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

DevOps в значительной степени символизируется концепцией бесконечного непрерывного цикла обратной связи. Если мы подумаем о методах обеспечения безопасности, расположенных поверх этого символа бесконечности, политики безопасности интегрированы от начала до конца – планирование, сборка, настройка, тестирование, анализ и мониторинг. Это показывает один набор общих целей, которые могут быть распределены между различными группами приложений и позволяют им взять на себя ответственность за определенную тактику безопасности, а не за одну централизованную команду, отвечающую за ответственность и полномочия политик безопасности.

Вот некоторые шаги и методы, которые следует рассмотреть:

• Для начала инженерным и операционным группам необходимо предвидеть угрозы не только на уровне приложений, но и на уровне инфраструктуры. Реагировать на возникающие проблемы - это хлопотно. Команды должны быть активными в этой ситуации. Это мышление, которое люди создают сейчас, которое не обязательно присутствовало, когда пандемия впервые поразила.
• Централизованная или федеративная модель безопасности практична, но не может быть реализована в первый день. Прежде чем эта общеорганизационная модель будет создана, она должна пройти постепенную трансформацию, чтобы понять целостный взгляд на управление поставкой программного обеспечения. Как и Agile, это структура, которая нуждается в тщательном изучении и совершенствовании с течением времени.
• Создайте общий подход, который состоит в определении ключевых политик безопасности, необходимых с точки зрения статического анализа кода, динамического анализа кода и мониторинга уязвимостей кода. Эти политики могут быть автоматизированы и организованы с точки зрения платформы для групп приложений. Это облегчает руководителям служб безопасности получение информации и информации от каждой из этих различных команд. Это также создает необходимый цикл обратной связи о том, какие пробелы имеются и как их улучшить.
• Предоставление интеграции API в рамках платформенного подхода – перенос кода из разработки в производственную среду – поможет упростить рабочие процессы команды инженеров, не беспокоясь о дополнительных методах безопасности на каждом этапе, поскольку они уже встроены в систему. Платформа без кода или с низким уровнем кода упрощает подключение инструментов безопасности и их запуск.
• Независимо от того, предоставляете ли вы инженерным и операционным командам возможность выбора инструментов или нет, новая практика заключается в использовании преимуществ масштабируемой платформы интеграции без кода, которая дополняет инженерные и операционные процессы. Это позволит соблюдать правила безопасности, которыми можно управлять и поддерживать со скоростью, с которой они поставляют программное обеспечение.
• Изучите ландшафт каждого приложения, включая используемую технологию, и то, как потребители используют решение. Это создает базовую основу для всех приложений, независимо от технологий, облачной инфраструктуры, платформы и т.д. Это поможет искоренить ложные срабатывания с точки зрения угрозы безопасности и даст более четкое представление о следующих шагах. Если ложное срабатывание всегда является обязательным исправлением безопасности (даже если это может не быть реальной угрозой), это влияет на скорость доставки программного обеспечения.

Например, с микросервисами Spring Boot и Node.js. В микросервисах Spring Boot у вас может быть много ложных срабатываний, проявляющихся как критическая уязвимость с высоким уровнем тревоги. На самом деле это не критические уязвимости, препятствующие развертыванию кода в рабочей среде. Это соображение должно быть включено в политику безопасности, чтобы понять необходимость этого, предоставить исключение и управлять исключениями безопасности в будущем. Это дает основу для управления исключениями, позволяющими в первую очередь запустить код в производство. Если группы безопасности продолжат останавливать процесс из-за подобных ложных срабатываний и непонимания ландшафта приложений и бизнес-потребностей, безопасность может стать помехой для руководства и бизнеса в целом.

Ожидайте ловушки и избегайте ее

Наиболее распространенной ловушкой является то, что команда безопасности не имеет адекватного представления о ландшафте приложений и о том, как это влияет на бизнес в дальнейшем в отношении портфеля продуктов компании и ландшафта платформы. Группы безопасности должны пройти обучение во всех четырех из этих областей, чтобы понять, какие политики и руководящие принципы необходимо реализовать. С точки зрения разработки программного обеспечения, всегда есть стремление к большей скорости. Но стратегическое мышление о структуре безопасности не всегда является частью этого мышления.

Централизованные группы безопасности часто настаивают на наличии политик для каждого фрагмента кода, который внедряется в производство. Но команда безопасности может не предлагать интеграцию API, например, чтобы упростить этот процесс. Реализация политики безопасности в одиночку не принесет никакой пользы.

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