![]() |
Интеграция безопасности в DevOps: советы по включениюКогда началась пандемия, многим компаниям пришлось быстро менять свою бизнес-модель. Фактически, многие начали упускать некоторые аспекты безопасности, которые были компромиссом для быстрого цикла разработки и предоставления новых функций для клиентов. Пришло время вернуться и пересмотреть политику и руководящие принципы безопасности, а также то, как наилучшим образом интегрировать их в процесс гибкой разработки. ![]() Самая большая проблема для многих организаций сегодня заключается в том, что группа безопасности почти всегда отделена от инженерных и эксплуатационных организаций. С появлением облачных и облачных технологий для службы безопасности становится все сложнее централизованно управлять, контролировать и работать с рабочим процессом инженерной команды. Чтобы сформировать мышление в области безопасности в инженерной организации, группы безопасности должны предоставить инженерным группам инструменты, соответствующие их рабочему процессу. Если решение группы безопасности состоит в том, чтобы просто поместить код оболочки поверх инструмента, который поручают группы безопасности, это станет дополнительным методом управления, который может замедлить прогресс. Обеспечение безопасности в гибком и разработанном способе работы Многие люди думают, что скорость снизится, когда в процесс будет включена безопасность, но это ошибочное представление. Время выхода на рынок часто задерживается, если политики безопасности и шлюзы не интегрированы или не автоматизированы в системы доставки программного обеспечения. Даже если существует централизованная группа безопасности, включение их в процесс гибкой разработки и в процесс общей трансформации DevOps поможет всем командам быстрее и эффективнее решать проблемы безопасности по мере их возникновения. DevOps в значительной степени символизируется концепцией бесконечного непрерывного цикла обратной связи. Если мы подумаем о методах обеспечения безопасности, расположенных поверх этого символа бесконечности, политики безопасности интегрированы от начала до конца – планирование, сборка, настройка, тестирование, анализ и мониторинг. Это показывает один набор общих целей, которые могут быть распределены между различными группами приложений и позволяют им взять на себя ответственность за определенную тактику безопасности, а не за одну централизованную команду, отвечающую за ответственность и полномочия политик безопасности. Вот некоторые шаги и методы, которые следует рассмотреть:
Ожидайте ловушки и избегайте ее Наиболее распространенной ловушкой является то, что команда безопасности не имеет адекватного представления о ландшафте приложений и о том, как это влияет на бизнес в дальнейшем в отношении портфеля продуктов компании и ландшафта платформы. Группы безопасности должны пройти обучение во всех четырех из этих областей, чтобы понять, какие политики и руководящие принципы необходимо реализовать. С точки зрения разработки программного обеспечения, всегда есть стремление к большей скорости. Но стратегическое мышление о структуре безопасности не всегда является частью этого мышления. Централизованные группы безопасности часто настаивают на наличии политик для каждого фрагмента кода, который внедряется в производство. Но команда безопасности может не предлагать интеграцию API, например, чтобы упростить этот процесс. Реализация политики безопасности в одиночку не принесет никакой пользы. В конечном счете, цель состоит в том, чтобы создать партнерство между командой централизованной безопасности и командой разработчиков программного обеспечения, чтобы выполнить обещание о преобразовании DevOps. Для обеспечения безопасности разрабатываемого и развертываемого уникального кода требуется постепенный процесс обучения и более глубокое понимание потребностей прикладных групп и систем доставки программного обеспечения. Только тогда на его основе можно будет построить систему безопасности. Такая эволюция подхода и мышления облегчит адаптацию к возникающим угрозам в будущем и обеспечит видимость и контроль потребностей бизнеса в эти неопределенные времена. ![]() Автор этого материала - я - Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML - то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда. ![]() |
Мои услуги
|
© upread.ru 2013-2022 При перепечатке активная ссылка на сайт обязательна. |