Одной из самых сложных задач интеграций, по мнению директора департамента продвижения и развития Rubytech Дмитрия Бутмалая, является внедрение подразделения информационной безопасности в процесс непрерывной разработки.
При поддержке экспертной команды своей компании он поделится с руководителями ИТ-подразделений рекомендациями, как грамотно внедрить методологию и выстроить взаимодействие между всеми участниками рабочих групп.
Чтобы оставаться на плаву, современный бизнес вынужден постоянно совершенствовать подходы ИТ-подразделений к разработке: непрерывно наращивать темпы вывода на рынок программных продуктов, но при этом обеспечить высокое качество кода и максимальный уровень надежности прикладного софта.
В таких условиях классические методологии создания ПО и приложений — например, каскадная модель Waterfall и даже более гибкая методология Agile, — когда служба ИБ подключается только на последних этапах, представляются недостаточно эффективными. В отличие от них, DevSecOps предполагает интеграцию задач безопасности во все процессы разработки и может рассматриваться как надежная и вполне рабочая альтернатива.
Но и здесь есть свои нюансы: подход оказывается возможным только благодаря взаимодействию кроссфункциональных команд, в которых объединены исторически разрозненные рабочие группы.
Одной из самых сложных интеграций всегда оставалось внедрение в процесс непрерывной разработки подразделения информационной безопасности. О том, как устранить извечный конфликт безопасности и разработки и обеспечить общее информационное поле создания программных продуктов, пойдет речь в статье.
DevSecOps as is
DevSecOps подразумевает обеспечение информационной безопасности (ИБ) на каждом из этапов разработки программного продукта: от проектирования до развертывания. Однако методология вбирает в себя не только высокую культуру обеспечения ИБ, но и применение только тех методов, процессов и инструментов, которые максимально эффективны для конкретного бизнеса.
Следование этой концепции помогает устранить «пропасть» между подразделениями разработки (Dev), информационной безопасности (Sec) и операционной деятельности (Ops).
Авторы методологии подчеркивают, что важно использовать коллективный опыт для снижения рисков ИБ на каждом этапе разработки программного продукта. Его устойчивость к угрозам (resilient software) возможна только на стыке качества, стабильности и безопасности. Вокруг этого принципа выстраиваются процессы разработки и формируются компетенции команд.
Как правило, идеология DevSecOps всегда «приземляется» на бизнес-процессы компании и на технологический стек, который в ней используется. Не менее важен здесь и управленческий подход. Применение DevSecOps оказывается возможным только благодаря эффективному взаимодействию кроссфункциональных команд, представленных сотрудниками различных департаментов компании.
Чтобы это сотрудничество было мирным и согласованным, важно обеспечить такой уровень автоматизации разработки, который бы позволил максимально вытеснить человеческий фактор.
Зачем это нужно бизнесу?
Экономия ресурсов
Для многих организаций, в том числе финансовых, основная ценность перехода к DevSecOps заключается не столько в экономии ресурсов, сколько в возможности наиболее быстрого вывода программного продукта на рынок (time-to-market). Разумеется, не в ущерб отказоустойчивости и безопасности.
Принцип Shift Left («сдвиг влево») в рамках DevSecOps означает, что задачи безопасности перемещаются как можно ближе к началу цикла доставки программного продукта, а сама безопасность становится неотъемлемой частью процесса.
Больше обнаружений
При таком подходе обнаруживается больше уязвимостей. Это позволяет исключать их на этапе разработки и даже проектирования, а значит, избавляет от необходимости создавать исправления (патчи), или даже отзывать продукт с рынка, и тем самым снижает расходы на его сопровождение.
Снижение трудозатрат
Помимо того, что DevSecOps повышает безопасность продукта, методология облегчает труд разработчиков в целом за счет автоматизации процессов: внедряемый инструментарий многофункционален не ограничивается проверкой безопасности в контексте отладки и тестирования кода. Его можно рассматривать как усиление существующей облачной инфраструктуры.
Повышение скорости входа в проект
Кроме того, вводится важный информационный ресурс: внутренняя база знаний о проблемах безопасности, современных рисках и угрозах, типовых решениях и рекомендациях для разработчиков, тестировщиков и инженеров. Наличие такой базы позволяет значительно ускорить включение новых или переведенных с другого проекта сотрудников в рабочий процесс.
Особенности методологии
Infrastructure as Code должна у вас быть
Стоит учитывать, что DevSecOps — не универсальная методология, которая подходит каждой компании для разработки любого программного продукта. Она работает только применительно к определенной архитектуре приложений и использует определенный технологический стек. К примеру, внедрить DevSecOps можно, только применяя подход Infrastructure as Code, который предполагает использование контейнеров в качестве среды исполнения.
Внедрение DevSecOps требует существенных ресурсов
Польза и экономия от применения методологии DevSecOps ощущается не сразу, в то же время, для внедрения и поддержки инструментов DevSecOps требуются существенные инвестиции. Эффект от применения методологии может быть оценен далеко не мгновенно и, скорее, по косвенным показателям.
Здесь все зависит от целей и готовности бизнеса: насколько продукт совместим с ограничениями, которые методология накладывает на архитектуру, какой приоритет у различных требований к продукту, готова ли компания выделять средства, время и персонал для перехода на нужное ПО и обучения специалистов. Все эти факторы необходимо учесть, прежде чем принимать решение о внедрении.
Важно оценить и готовность менеджмента: данная методология подразумевает иные подходы к управлению командой, и для ее внедрения руководители должны быть способны быстро перестроиться и помочь сделать это сотрудникам. Особенно тяжело такие изменения даются специалистам в традиционно консервативной области ИБ — возникает необходимость значительно менять регламенты, зачастую формировавшиеся годами.
Полный список того, что следует учесть перед внедрением DevSecOps, всегда зависит от особенностей компании, отрасли и продукта.
Вот лишь примерный перечень проблем, с которыми можно столкнуться:
- отсутствие необходимых компетенций у сотрудников и нехватка кадров;
- страх перемен, недостаток поддержки руководства;
- отсутствие проработанной стратегии;
- слишком высокие риски не окупить вложения;
- нехватка финансирования;
- отсутствие необходимой инфраструктуры.
Роль службы ИБ
Стоит понимать, что DevSecOps — это не только технологический подход, который реализуется набором программных инструментов. На первый план здесь выходят организационные и идеологические вопросы.
Как правило, из-за специфики своей деятельности наиболее чувствительно к таким переменам подразделение ИБ. Но именно их мотивация станет решающей для внедрения DevSecOps.
Встроить стратегию внедрения DevSecOps-практик в каждодневную работу команды поможет глубокое понимание угроз и скрытых рисков и того, какое влияние они способны оказать на конечный продукт. Например, если используются Open Source решения, необходимо организовать проверку их на уязвимости в рамках новой системы: аналитики компании в сфере кибербезопасности «Ростелеком-Солар» выявили, что пять из десяти приложений с открытым кодом включают критические уязвимости.
Технологическая база
Не менее важно обеспечить надежный технологический фундамент. База должна быть одновременно современной и зрелой, отвечать требованиям методологии и при этом специфике основных направлений компании. Так что, универсального решения не существует — каждая компания должна сама определить технологический стек. В противном случае полноценно внедрить методологию и добиться результата будет невозможно.
Нюансы законодательства
Помимо этого, на каждом этапе возникают дополнительные факторы, которые необходимо учесть. Особенно если вопрос касается уже сложившейся практики: нюансов законодательства, касающихся конкретной отрасли, или существующей практики и квалификации отраслевых разработчиков.
Например, к кредитным организациям предъявляется ряд жестких регуляторных требований, касающихся банковской тайны, так что даже для обеспечивающих в другой отрасли достаточный уровень безопасности инструментов DevOps и других решений потребуется проводить аудит ИБ и, возможно, ограничивать их функционал или вовсе отказываться от них. Законодательство может выставлять ограничения на использование отдельных решений — например, в рамках программ по импортозамещению ПО.
Команды
Внедрение любых новых технологий потребует привлечения специалистов, у которых зачастую раньше не было опыта работы в отрасли, с которой связан продукт. В таких условиях остро встанет вопрос формирования команд и сопряженные с ним задачи организации процессов.
Комплексный подход к внедрению DevSecOps в компании подразумевает:
- Готовность топ-менеджмента и исполнителей к организационным изменениям.
- Инвестиции в автоматизацию процессов разработки, в том числе тестирования безопасности.
- Понимание принципов разработки.
- Осознание каждым участником кросс-функциональной команды своей роли.
- Повышение прозрачности процессов, открытый доступ к ИБ-отчетности.
- Грамотный выбор и применение ИТ-инструментов DevSecOps.
Подводя итоги
Хотя внедрение DevSecOps выглядит весьма сложным и протяженным по времени процессом, помимо существенных затрат и организационных изменений оно влечет за собой ряд заменых выгод для бизнеса.
Вот лишь главные:
- Обучение команды разработчиков правилам написания безопасного кода и улучшение продукта за счет изменения культуры разработки.
- Уменьшение time-to-market.
- Снижение затрат на поддержку продукта.
- Повышение отказоустойчивости продукта.
- Автоматизация процессов, исключение влияния человеческого фактора.
- Внутренняя инфраструктурная безопасность облачной среды.
Перечисленных в статье аргументов вполне достаточно, чтобы принять аргументированное и взвешенное решение о внедрении DevSecOps в компании.
Фото на обложке: Pexels
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Материалы по теме
ВОЗМОЖНОСТИ
08 декабря 2024
09 декабря 2024
10 декабря 2024
11 декабря 2024