Большинство людей слышали о DevOps, но DevSecOps все еще довольно новинка. “Sec” в середине слова “DevOps”, очевидно, означает “безопасность”. В этой статье мы рассмотрим, что означают DevOps и DevSecOps, и почему вам следует рассмотреть возможность интеграции практик DevSecOps в вашей организации.
Разница между DevOps и DevSecOps
Во-первых, давайте определим, что означают термины “DevOps” и “DevSecOps”. DevOps традиционно понимается как пересечение между ”разработкой“ и “операциями”, т.е. между областью разработки программного обеспечения и областью его запуска. Таким образом, DevOps сродни философии или способу работы, при котором вы тесно сотрудничаете между двумя ранее изолированными командами или инженерами, опытными в обеих областях. Одна из главных целей “DevOps” – добиться более быстрых циклов выпуска и поставлять программное обеспечение быстрее, чем когда-либо прежде. С годами “DevOps” как расширяла, так и совершенствовала технологии и приемы, которые входили в ее компетенцию, такие как:
- Автоматизация
- Непрерывная интеграция, непрерывная поставка и непрерывное развертывание
- Инфраструктура как код
- Упрощенные проверки кода (например, запросы на слияние на GitHub)
- Мониторинг и оповещения
- Автоматизированные процедуры смягчения последствий, принятые в качестве ответов на вышеуказанные предупреждения
- Разработка приложений, оптимизированных для DevOps (используя, например, рекомендации по применению 12 факторов)
- DevSecOps (см. Ниже)
Приведенный выше список ни в коем случае не является исчерпывающим. Как вы можете видеть, DevOps имеет широкую область применения и включает DevSecOps.
DevSecOps – это подмножество DevOps, которое охватывает пересечение понятий “разработка”, “операции” и “безопасность” с акцентом на автоматизацию. Когда автоматизация невозможна, устанавливаются правила и руководства, которым должны следовать разработчики, системные инженеры и DevOps-инженеры.
DevSecOps должны быть хорошо продуманы на каждом этапе жизненного цикла программного обеспечения, как на уровне взаимодействия с человеком, так и на уровне автоматизации. С DevSecOps как разработчики, так и операционные группы могут:
- Убедитесь, что обучение безопасности является адекватным для различных команд, работающих над программным обеспечением (например, разработчиков, тестировщиков, инженеров по эксплуатации).
- Убедитесь, что коммуникация и сотрудничество между командами быстрые, эффективные и по возможности без трений
- Автоматизируйте безопасность на каждом этапе жизненного цикла программного обеспечения, когда это возможно, например, во время:
- Моделирование угроз
- Статический анализ
- Линтинг
- Сканирование зависимостей с известными уязвимостями
- Динамическое тестирование безопасности приложений (DAST)
- Ужесточение
- Интерактивное тестирование безопасности приложений / самозащита приложений во время выполнения (IAST / RASP)
- Централизованное ведение журнала
- Мониторинг, оповещение и выполнение автоматических действий по исправлению оповещений
Предвестники ошибок в системе безопасности
Иногда команды DevOps, как правило, забывают о безопасности.
Давление, требующее выполнения
Когда на инженеров DevOps оказывается давление, они, как правило, сосредотачиваются на создании чего-то работающего и смещают приоритеты со всего, что не соответствует этой основной цели. Следовательно, они срезают углы, и безопасность часто становится первой жертвой.
Типичным примером того, как безопасность может замедлить разработку программного обеспечения, является шифрование в состоянии покоя и в процессе передачи. Это делает проверку данных (таких как данные, сохраненные на диске, или сетевой трафик) более проблематичной.
Безопасность как завершающий этап разработки программного обеспечения
Очень часто безопасность рассматривается как заключительный шаг в разработке программного обеспечения, то, что кто-то сделает позже. Основным следствием такого подхода является то, что безопасность обычно плохо продумана, является неполной и принимает форму дополнительных уровней, которые располагаются поверх приложения.
Это очень плохая практика, поскольку само программное обеспечение небезопасно. Правильный путь – разрабатывать программное обеспечение с учетом соображений безопасности с самого начала (т. Е. На Этапе проектирования) и гарантировать, что ответственность за безопасность лежит на каждом.
Отсутствие автоматизации
Обычно внедрение и тестирование аспектов безопасности возлагаются на экспертов по безопасности, обычно в конце жизненного цикла программного обеспечения. Внедрение и тестирование обычно выполняются вручную и, следовательно, отнимают много времени и подвержены ошибкам. В такой ситуации очень легко, даже экспертам по безопасности, не заметить уязвимости.
Решение заключается в повышении уровня автоматизации, особенно с точки зрения тестирования безопасности, как на этапе разработки (компоновка, статическое тестирование безопасности приложений и т.д.), так и на этапе тестирования (тестирование на проникновение, тестирование на внедрение ошибок, динамическое тестирование безопасности приложений и т.д.)
Дефицит навыков
Возможно, не все инженеры осведомлены о новейших аспектах безопасности или прошли своевременное обучение. Большинство инженеров DevOps имеют опыт работы либо с системными администраторами, либо с разработчиками программного обеспечения, они часто недостаточно знакомы с проблемами безопасности или техническими ноу-хау для создания безопасной производственной среды. Как правило, первые часто не знают о том, как программное обеспечение должно разрабатываться безопасным способом, а вторые не осознают проблем безопасности, связанных с настройкой производственной среды в целом.
В быстро меняющейся среде разработки безопасность часто является второстепенной мыслью, которая будет включена в какой-то момент в будущем. Срочность момента обычно заключается в том, чтобы внедрить определенные функции, исправить критические ошибки и запустить что-то как можно быстрее. Например, стартапу (или новому проекту в уже существующей организации) может потребоваться запустить свое программное обеспечение, прежде чем он сможет получить дополнительное финансирование (или обеспечить будущее проекта). В этом контексте предприятия часто не уделяют приоритетного внимания безопасности из-за ограниченного финансирования. С другой стороны, чем позже обнаруживается проблема, тем дороже ее устранение. Итак, необходимо достичь определенного баланса, основанного на анализе затрат / выгод и автоматизации.
Сдвинуть влево
Практика “сдвига влево” помогает смягчить проблемы, описанные в предыдущем разделе. Хотя разработчики могут проявлять осторожность в отношении безопасности при разработке и кодировании программного обеспечения, они могут не понимать общей картины, когда программное обеспечение интегрируется в производственную среду, вместе с сопутствующими уязвимостями.
“Сдвиг влево” означает преобразование способа работы разработчиков и команд DevOps с целью переноса шагов, которые обычно выполнялись позже в жизненном цикле разработки программного обеспечения, на более ранние этапы. Вот неполный список действий, которые можно предпринять для сдвига влево:
- Установите стандарты кодирования, особенно защитного программирования.
- Убедитесь, что среды разработки максимально точно соответствуют производственным средам, чтобы избежать типичного ответа “но у меня это работает”, когда разработчику сообщают об ошибке.
- Реализовать несколько инструментов, которые должны запускаться автоматически как часть конвейера непрерывной интеграции:
- Инструмент для проверки качества кода и соответствия стандартам кодирования
- Авторитетный, хорошо настроенный инструмент статического анализа
- Инструмент сканирования для обнаружения зависимостей с известными уязвимостями
- Инструмент, обеспечивающий автоматическое написание и запуск модульных тестов
- Автоматизируйте развертывание программного обеспечения в среде контроля качества и выполняйте функциональные и нефункциональные тесты (такие как интеграционные тесты, динамическое тестирование безопасности приложений и тесты производительности) после каждого развертывания автоматическим образом.
- Предоставлять разработчикам доступ к облачным ресурсам и обучать их создавать такие ресурсы и управлять ими.
Существует множество преимуществ:
- Ошибок либо полностью избегают, либо обнаруживают на ранней стадии, что всегда дешевле.
- Лучшие практики поощряются с самого начала как разработчиками, так и инженерами DevOps.
- Безопасность становится ответственностью каждого, а не просто запоздалой мыслью, включенной в конце.
В традиционной изолированной организации инженеры DevOps обычно работают с программным обеспечением, предоставляемым командой разработчиков, и имеют мало рычагов влияния на то, как разрабатывается программное обеспечение. Смещение влево означает, что разным командам придется сотрудничать. Это означает, что разработчикам и тестировщикам придется учиться у инженеров DevOps тому, как устроена производственная среда и почему она устроена именно таким образом. Аналогично, инженерам DevOps необходимо будет узнать о программном обеспечении, которое создают разработчики, и о том, как оно работает, чтобы более эффективно интегрироваться в производственную среду.
Разработчикам требуется обучение передовым методам обеспечения безопасности, и их необходимо поощрять и давать им время для применения этих лучших методов в своем коде.
Сдвиг влево потребует целенаправленных усилий от всех (разработчиков, инженеров DevOps, руководства) и временно замедлит работу всех, пока не будут внедрены новые процессы и привычки.
Принцип наименьших привилегий
Принцип наименьших привилегий является критическим аспектом безопасности в контексте разработки программного обеспечения и процессов DevOps. Этот принцип гласит, что организациям следует предоставлять ровно столько привилегий, сколько им необходимо для выполнения задач, для которых они предназначены. На первый взгляд, это имеет смысл: если программное обеспечение будет скомпрометировано, вы хотите ограничить воздействие.
Однако правильная реализация этого принципа часто бывает сложной и отнимает много времени. Существует множество систем разрешений, но обычно они либо разрешают, либо запрещают определенные действия, выполняемые с определенными ресурсами.
Проблемы внедрения
Начальная работа, необходимая для определения минимальных разрешений, часто нетривиальна. Диапазон возможных действий обычно вполне поддается определению (хотя и требует много времени само по себе). Однако ресурсы, которые потенциально могут быть задействованы, могут быть очень сложными, поскольку это может зависеть от динамических параметров. Например, вы можете знать, что определенный вызов API, скажем, Amazon Web Services, будет выполнен для работы с экземплярами EC2, но какие именно экземпляры EC2 могут быть очень сложными определить заранее. Это особенно актуально, если система спроектирована таким образом, что экземпляры EC2 являются эфемерными, что в большинстве случаев было бы правильным решением. По правде говоря, целевые ресурсы – не единственный аспект вызовов API, который может быть динамическим, поскольку диапазон действий, выполняемых с этими ресурсами, также может быть непредсказуемым; однако диапазон таких действий обычно намного более ограничен, чем диапазон целевых ресурсов.
Просто проверить, какие разрешения требуются программному обеспечению, динамически просматривая, что оно делает, недостаточно. Диапазон потенциальных действий и ресурсов может отличаться при запуске в другой среде с различными параметрами конфигурации и запросами. Вот почему вы слышите о “потенциальных” действиях и ресурсах, потому что фактические действия, которые программное обеспечение попытается выполнить с реальными ресурсами, скорее всего, будут отличаться от запуска к запуску.
Следовательно, трудно автоматизировать определение наименьших привилегий для данного программного обеспечения. Это потому, что это зависит не только от кода программного обеспечения, но и от динамических аспектов, таких как среда, в которой работает программное обеспечение, параметры конфигурации и входные параметры для данного запроса или задания. Еще одна трудность с автоматизацией обнаружения таких разрешений заключается в том, что в конце дня кто-то (или что-то) должен решить, являются ли эти разрешения приемлемыми или нет, например, в контексте регулируемой отрасли или ИТ-политики организации.
Даже при первоначальной работе по определению наименьшего объема привилегий, требуемого для данного программного обеспечения, небольшое изменение в коде может потребовать пересмотра существующих разрешений, что, опять же, отнимает много времени и его трудно автоматизировать. По сути, после внесения такого изменения ту же работу, которая была затрачена на определение начального набора разрешений, следует выполнить снова, но, надеюсь, теперь она будет намного более ограниченной по объему и, следовательно, не потребует такого же количества времени.
Учитывая вышесказанное, понятно, что инженеры DevOps, работая под давлением, часто поддаются искушению предоставить широкие разрешения. Даже при рабочей нагрузке часто используются такие широкие разрешения. Часто все начинается с благонамеренных намерений, например, просто “наладить работу”, и с уверенности, что они вернутся и ограничат их на более позднем этапе. К сожалению, этот более поздний этап часто не реализуется.
Реальность наименьших привилегий
Организации должны решить, какой уровень безопасности они хотят в сравнении со стоимостью внедрения таких мер безопасности. Стартап может быть небрежен в своих требованиях к безопасности, поскольку тратить слишком много ресурсов на создание разрешений по принципу наименьших привилегий может оказаться неподъемным.
С другой стороны, менее рискованная компания, имеющая либо финансирование, либо доход, может решить частично реализовать принцип наименьших привилегий, например, используя подстановочные знаки для ресурсов, если соответствующая система разрешений их допускает. Использование таких подстановочных знаков, по крайней мере, ограничит диапазон ресурсов, с которыми можно выполнять действия, в отличие от полного доступа, который будет использовать стартап.
Компания, требующая высокой безопасности, может иметь строгие стандарты для надлежащего внедрения принципа наименьших привилегий, чего бы это ни стоило, потому что стоимость взлома может быть колоссальной или потому, что этого требует закон.
В последних двух примерах выделенная команда DevSecOps, работающая с командой DevOps, может быть хорошей идеей или даже необходимостью. Для небольших компаний хорошим решением было бы ознакомить разработчиков с системой разрешений, которая будет использоваться для запуска их программного обеспечения, позволить им развертывать свое программное обеспечение в изолированной среде, похожей на производственную, а затем позволить им поиграть с ним. Таким образом, они, вероятно, смогут выполнить большую часть работы по определению наименьшего объема привилегий, необходимых программному обеспечению, по той простой причине, что они написали код и, таким образом, лучше всех знают, какие действия код может захотеть выполнить и на каких ресурсах.
Примеры недобросовестной практики и как их можно избежать
В этом разделе будут рассмотрены распространенные практики, наносящие ущерб безопасности, и то, как DevSecOps может их решить.
Использование уязвимого программного обеспечения
Первый и, вероятно, наиболее распространенный – это использование уязвимых пакетов программного обеспечения. Подавляющее большинство использует существующие библиотеки и другие подобные пакеты, будь то с открытым исходным кодом или проприетарные, для повторного использования существующих функциональных возможностей, а не изобретать велосипед для решения уже решенных проблем. Разработчики обычно следят за тем, чтобы их пакеты были хорошего качества и в достаточной степени свободны от дефектов и уязвимостей.
Проблема возникает, когда организациям не хватает прозрачности цепочки поставок, а разработчики не используют последние версии зависимостей. Постоянно обнаруживаются новые уязвимости. В нескольких базах данных перечислены уязвимости для различных библиотек; наиболее известной и используемой является Common Vulnerabilities and Exposures (CVE).
Библиотеки, которые когда-то считались безопасными, становятся все менее и менее безопасными, поскольку в них обнаруживаются проблемы с безопасностью. Как только такие дефекты обнаружены, люди, разрабатывающие библиотеку, обычно быстро выпускают патч для исправления или смягчения проблем безопасности и публикуют новый выпуск библиотеки. Итак, разработчики должны следить за тем, чтобы постоянно использовались последние версии их зависимостей. Обновление зависимости обычно безболезненный процесс, но время от времени могут возникать несовместимости, требующие некоторого рефакторинга кода. Если разработчики находятся в жестких сроках или под большим давлением, для них будет очень заманчиво сказать “просто сделай это позже”, что быстро превратится в “никогда”.
Решение этой проблемы относительно простое: использование надежного сканера для сканирования кода в рамках непрерывного процесса интеграции каждый раз, когда изменение передается в репозиторий кода. Таким образом, код будет сканироваться автоматически, и о проблемах можно будет немедленно сообщать ответственному разработчику, который затем сможет предпринять немедленные действия. В дополнение к этому автоматизированному процессу разработчику должно быть разрешено потратить время, необходимое для обновления неисправных зависимостей до их последних версий. Опять же, в редких случаях это может занять много времени, но это абсолютно необходимо с точки зрения безопасности.
Некоторые организации придерживаются мантры “если что-то не сломалось, не чините это”, но обновление зависимостей программного обеспечения является не подлежащей обсуждению мерой безопасности, за исключением очень специфических обстоятельств, например, если программное обеспечение вообще не взаимодействует ни с какими сетями.
Внедрение кода с высоким уровнем риска
Другой потенциальной проблемой безопасности при разработке программного обеспечения является использование опасных конструкций кода. Типичным примером может быть рекурсия, но есть много других.
Решением этой проблемы является установление стандартов кодирования для выбранных языков программирования и обеспечение соблюдения этих стандартов. Инструменты статического анализа могут проверять стандарты кодирования, отмечать высокорискованные конструкции кодирования и заблаговременно обнаруживать потенциальные ошибки. Такие инструменты можно сделать частью непрерывного конвейера, где код проверяется при каждом изменении, и разработчик, который запустил такой код, может быть немедленно уведомлен о любых проблемах. Однако инструменты статического анализа могут обнаруживать не все проблемы, поэтому проверка кода членами команды все равно будет хорошим вариантом.
Не проверяет входные данные пользователя
Всякий раз, когда ожидается, что пользователь предоставит какой-либо ввод, особенно в виде произвольного текста, существует опасность атак с внедрением кода. Неспособность очистить и подтвердить такой пользовательский ввод является одним из основных векторов атаки для злоумышленников. Этот аспект безопасности очень важен, и его может быть довольно сложно выполнить правильно и полностью обезопасить.
Для проверки такого пользовательского ввода существуют библиотеки для многих языков программирования, и организациям определенно следует использовать их, и использовать должным образом. Кроме того, некоторые инструменты статического анализа обнаружат такие потенциальные уязвимости и сообщат о них разработчикам. Наконец, средства выполнения, такие как брандмауэры веб-приложений, могут предотвращать наиболее распространенные атаки.
Не тестируется на наличие ошибок
Очевидной проблемой было бы наличие ошибок в вашем коде, поскольку ошибки часто имеют последствия для безопасности в дополнение к неисправному программному обеспечению. Ошибки – неизбежная часть разработки программного обеспечения, но их можно уменьшить, используя также инструмент статического анализа. Однако такого инструмента было бы далеко не достаточно. Также требуется комплексное и, по возможности, автоматизированное тестирование на различных этапах жизненного цикла программного обеспечения. Примерами такого тестирования могут быть:
- Модульное тестирование
- Интеграционное тестирование
- Стресс- / нагрузочное тестирование
- Сквозное тестирование
В качестве дополнительного замечания, но все же очень важного, чем позже обнаружена ошибка, тем дороже ее исправление.
Не использует шифрование
Еще одна довольно очевидная проблема – оставлять данные в виде обычного текста. Решение очевидно: используйте шифрование для данных в состоянии покоя и данных в пути. Это могут делать многочисленные библиотеки и стороннее программное обеспечение, поэтому фактическая стоимость внедрения такого шифрования на самом деле не так уж велика.
Тогда возникает проблема отсутствия мониторинга того, как программное обеспечение работает в производственной среде. Обычно это приводит к неспособности понять, что происходит, когда что-то идет не так, каковы узкие места или почему программное обеспечение или система вышли из строя или иным образом перестали функционировать должным образом. Наблюдаемость (определяемая как комбинация показателей мониторинга, ведения журнала и трассировки) необходима для понимания того, как программное обеспечение ведет себя под нагрузкой, а также для предотвращения и смягчения (в идеале автоматизированным способом) потенциальных проблем.
В качестве общего замечания, когда речь заходит о DevOps, во многих организациях часто случается так, что ИТ-безопасность оставляется на волю случая, или, точнее, на знания и добрую волю разработчиков и инженеров DevOps. Вероятно, этого достаточно для стартапа, но по мере роста организации ей определенно потребуется установить и обеспечивать соблюдение своей системы безопасности. Система безопасности – это, по сути, формализация различных аспектов безопасности ваших ИТ-систем и рабочих нагрузок. Он включает в себя следующее:
- Инвентаризация активов и поверхность для их атаки
- В организации существуют процессы обнаружения кибератак и смягчения их последствий
- Существующие процессы восстановления после успешных или частично успешных кибератак
- Какая часть этих процессов автоматизирована, а какая – выполняется вручную?
Заключение
Во многих организациях о безопасности думают как о чем-то второстепенном. Вы должны стремиться не быть одним из них. Вам необходимо оценить свои требования к безопасности для различных проектов и продуктов, разрабатываемых вашей организацией, и выполнить анализ затрат в соответствии с размером, целями и людскими и финансовыми ресурсами, доступными в вашей организации.
Если вы стартап с ограниченным финансовым и человеческим капиталом, разрабатывающий минимально жизнеспособный продукт, вы можете решить не тратить слишком много времени и усилий на безопасность, но это должно быть осознанное решение. Крайне важно учитывать последствия такого решения, особенно то, как вы будете справляться с накопленным техническим долгом.
Если ваша организация уже является значительной, с надежным финансированием и / или продажами, а безопасность по-прежнему не является центральной частью ваших ИТ-процессов и систем, то вам, вероятно, следует подумать об интеграции некоторых концепций DevSecOps.
Как показано в этой статье, DevSecOps учитывает безопасность на каждом этапе жизненного цикла программного обеспечения, уделяя особое внимание автоматизации обеспечения безопасности. DevSecOps может помочь, например, сканировать уязвимые зависимости, потенциальные ошибки или бреши в системе безопасности с помощью различных инструментов безопасности, а также отслеживать программное обеспечение во время выполнения под нагрузкой, сопровождаемой оповещением и автоматическим исправлением.
В заключение, DevSecOps является неотъемлемой частью DevOps и должна быть интегрирована с самого начала или модернизирована как можно скорее.