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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор этого материала - я - Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML - то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.

статьи IT, информационная безопасность

Мои услуги

Занимательная постапокалиптическая сказка

Именование томов Windows

Урок 38. Глобальная область видимости JavaScript

Здравствуйте! Вы можете задать мне любой вопрос. Если не получается отправить сообщение через эту форму, то пишите на почу up777up@yandex.ru