Практически любая организация в той или иной степени использует DevOps. Бизнес-эффект от быстрой доставки программного обеспечения и быстрой адаптации к потребностям рынка настолько велик, что это стало обязательным требованием — вы либо применяете DevOps, либо идёте прямой дорогой к банкротству. Однако вместе с нашей потребностью в скорости возросла и наша потребность в безопасности, и объединение того и другого — не самая простая задача.
Ключом к быстрой работе DevOps является автономия разработчика. Командам разработчиков необходимо ежедневно принимать решения о том, что и как делать, и им следует делать это самостоятельно. Необходимость получения внешнего одобрения является узким местом, замедляет процесс и снижает чувство ответственности за результат у команды разработчиков. Это ведёт к тому, что ожидаемые результаты достигаются не полностью, а наиболее эффективные разработчики выдыхаются.
Однако практика управления безопасностью, к сожалению, часто зависит от наличия процедур одобрения. Аудит и проверка безопасности, при которых эксперты определяют, насколько то или иное решение является безопасным, — это хлеб насущный для большинства организаций, работающих в области обеспечения безопасности. Чтобы безопасность работала со скоростью разработки, эта практика должна измениться и дать разработчикам возможность принимать решения в области безопасности. В противном случае создаваемое программное обеспечение не будет безопасным, а разработка его версий будет работать медленно.
Как же обеспечить расширение полномочий разработчиков и создать условия для непрерывной разработки безопасного программного обеспечения? Давайте рассмотрим некоторые ключевые практики.
Трансформация менталитета
Команды site reliability engineering (SRE) несут такую же ответственность за безотказную работу службы, какую ранее несли системные администраторы. Изменение роли произошло из-за изменения методов достижения надёжности. Команды SRE не обрабатывают большинство инцидентов и не проверяют весь код, влияющий на надежность. Вместо этого они разрабатывают инструменты, позволяющие разработчикам самим принимать решения и создавать работоспособное программное обеспечение. Команда SRE должна привлекаться только в крайних случаях, будь то инцидент или необходимость в пересмотре архитектуры.
Группы, отвечающие за безопасность, должны работать таким же образом. Им следует фокусироваться на тактических решениях, позволяющих снизить их вовлечённость в процесс, передав основную часть ответственности разработчикам. Безусловно, возможны ситуации, в которых их опыт будет иметь решающее значение, но их участие в выполнении типовых задач должно быть сведено к минимуму.
Изменение инструментария
До появления DevOps владельцем систем мониторинга производительности приложений (application performance monitoring, APM) была ИТ-служба, которая использовала синтетические измерения из многих точек мира для оценки и мониторинга производительности приложений. Это были довольно мощные решения, но их применимость была ограничена. Они были дорогостоящими, что ограничивало возможности разработчиков проводить тесты. Они превосходно справлялись с оценкой состояния посредством агрегированных тестов, но приносили мало ценности разработчикам, пытающимся определить причины проблем с производительностью. В результате разработчики редко ими пользовались.
Затем на сцену вышли новые инструменты, представившие другой подход к мониторингу производительности приложений. Они были бесплатными или дешевыми, что делало их доступными для всех команд разработчиков. Они предлагали функциональность, необходимую разработчикам для устранения проблем. Этот новый подход произвел революцию в индустрии APM, внедрив мониторинг производительности в практику разработки и сделав интернет быстрее.
То же самое должно произойти и с безопасностью приложений. Если именно разработчики принимают важные решения по обеспечению безопасности, то ключевыми пользователями средств обеспечения безопасности являются уже не сотрудники Службы безопасности, а сами разработчики. Таким образом, необходимо сфокусироваться в первую очередь на принятии средств обеспечения безопасности разработчиками, даже если для этого необходимы дополнительные усилия со стороны Службы безопасности.
Изменение системы управления
Одна из моих любимых пословиц DevOps гласит: “Если оно движется, измерьте его. Если оно не движется, измерьте его, если оно начнёт двигаться”. Эта пословица иллюстрирует, насколько важно успешно контролировать запущенное приложение. В то время как конвейер CI/CD помогает вам доставлять программное обеспечение до продуктивной среды, мониторинг помогает делать это быстро, обеспечивая необходимый уровень уверенности. Вам не нужно слишком сильно беспокоиться об ошибке, попавшей в продуктив, если вы уверены, что быстро узнаете о ней и сможете откатиться или развернуть исправление.
Следует обеспечивать безопасность с применением такого же подхода. Обнаружение уязвимости сразу же после развёртывания и осуществление необходимых действий по её устранению работает почти так же хорошо, как блокировка её непосредственно перед развертыванием, и при этом гораздо менее разрушительно. Но чтобы делать так, вам нужно будет инвестировать в мониторинг.
Разработчики являются ключевыми участниками процесса создания приложений. Поэтому будет вполне логично, если они также будут являться инженерами решений для обеспечения безопасности. Предоставление разработчикам полномочий на принятие решений, которые раньше принимала Служба безопасности, позволяет ИТ-командам и специалистам по безопасности сфокусироваться на различных аспектах работы бизнеса, сократить длительность разработки и, в конечном итоге, создавать приложения, обеспечивающие достижение наилучших результатов.
С оригиналом статьи можно ознакомиться по ссылке.
