Table of Contents
DevOps появился из-за культурных, функциональных и технических разногласий между командами разработчиков, желающими часто выпускать свой продукт, и командами эксплуатации, желающими сохранить надежность и стабильность. Культура DevOps затрагивает как сотрудничество, принципы мышления, так и методы достижения этих целей, включая методы DevOps — непрерывную интеграцию и доставку (CI/CD), инфраструктуру как код (IaC), AIOps, использующий машинное обучение для мониторинга приложений.
По мере роста числа людей и компаний, принявших DevOps, стало ясно, что понятие «DevOps» не может полностью описать полное состояние движения, его принципы и цели. Я чуть ранее называл все это словом DevQaOps, и рекомендую внедрять методы тестирования ShiftLeft там, где это возможно.
Но не менее важным, если не более, является необходимость обеспечения безопасности всем и каждому. С этим вам поможет перенос обеспечения безопасности в разработку и поддержку, или DevSecOps.
Для улучшения принципов написания кода, устранения уязвимостей в разработке и поставки приложений с высокой степенью защиты следует внедрить DevSecOps как можно раньше.
Безопасность ПО начинается с разработчиков
До DevOps команды разработчиков часто обеспечивали безопасную работу на последних этапах процесса выпуска приложения, обычно как необходимый шаг Cовета по Изменениям (CAB). По причине того, что команды безопасности появлялись в процессе слишком поздно, у них было мало времени для ознакомления с бизнес-требованиями, понимания технических изменений, оценки рисков и запуска тестов безопасности. Если они подтверждали проблемы, было слишком мало времени для их решения без нарушения сроков выпуска, а проблемы, требующие существенных правок кода, ставили команду разработчиков перед трудным выбором (знакомая тема, как-то раз уже попадал в такую ситуацию, прим. переводчика).
Позднее тестирование безопасности в процессе выпуска может стать критическим риском для команд DevOps, увеличивающих частоту выпусков или желающих перейти на микросервисы. Согласно отчету State Of DevOps 2019 года (перевод на русском), публикуемому DORA и Google Cloud, о 43% опрашиваемых можно сказать, что они исполнители с высокими или элитными показателями, выпускающие приложения ежедневно или еженедельно. Это значительное увеличение производственных развертываний, частота которых требует внедрения передовых методов обеспечения безопасности на раннем этапе процесса разработки.
Совместная работа гибких команд разработчиков и infosec нужна в следующих областях:
- Ознакомление с требованиями безопасности, архитектурой и принципами разработки;
- Обеспечение автоматических тестов безопасности в конвейерах CI/CD;
- Мониторинг угроз для приложений, решение проблем безопасности.
Я предлагаю почитать некоторые руководства, чтобы получить представление о каждой области в разделах ниже. Первая, вторая, третья ссылки.
Совместная работа над требованиями безопасности, архитектурой и принципами разработки
Команды разработки и infosec должны работать вместе над безопасностью в гибком процессе разработки, даже ранее, чем начнется непосредственно написание кода. В отчете State of DevOps, публикуемом Puppet, CircleCI и Splunk, авторы определили несколько передовых методов для совместной работы команд разработки и infosec:
- Эти команды должны работать над моделями угроз.
- Функциональные и нефункциональные требования безопасности должны быть включены в список задач с высоким приоритетом.
- Требования безопасности надо рассматривать как архитектурные ограничения.
Гибкие команды разработки могут применить эти методы, выставляя более высокие требования к рискам и реализациям безопасности при анализе уязвимостей. Разработчики должны сотрудничать с infosec при работе над требованиями, архитектурой, дизайном и реализацией частей приложения, обрабатывающих пользовательские данные, управление авторизацией, другие чувствительные данные.
Для менее рискованных изменений при написании кода гибкие команды должны описать критерии приемлемости пользовательской истории с учетом требований и ограничений infosec.
Гибкие разработчики должны также учитывать принципы основ безопасности от OWASP, включающих несколько передовых методов:
- Установка по умолчанию политик, основанных на безопасности, в различных областях, например, срок действия пароля.
- Реализация принципа минимальных привилегий при определении ролей и предоставлении доступа к бизнес-процессам.
- Понимание принципов безопасности, например, разделение задач, «недоверенные» сервисы, минимизация поверхности атаки, недопущение безопасности через неясность.
- Быстрое исправление проблем безопасности после понимания ключевых причин, реализация целостных исправлений.
Ну и наконец, команды разработки и infosec должны совместно установить описание передовых методов при написании кода. Здесь можно использовать передовые методы используемых языков программирования и платформ, включая методы Университета Карнеги Меллон, Университета Мичигана.
Если вы производите развертывание в публичные облака, потребуется также изучить передовые методы, к примеру, от AWS, Azure, Google Cloud
Тестирование безопасности в конвейерах CI/CD
Следующий этап учета безопасности — конвейеры CI/CD, где автоматические проверки кода и безопасности могут остановить процесс сборки и уведомить об этом разработчиков. Следует учитывать некоторые наиболее распространенные методы и инструменты, используемые при составлении стандартов безопасности конвейеров CI/CD:
- Платформы тестирования безопасности статических приложений (SAST), например SonarQube, Veracode, Sentinel Source и Checkmarx проверяют исходный код на различные уязвимости и шаблоны. Например, SonarQube проверяет плохие входы (анализ испорченности), межсайтовый скриптинг, раскрытие чувствительных данных, а также известные уязвимости. Разработчики Veracode заявляют, что они проанализировали более 11 триллионов строк кода, а также, что у них при этом менее 5% ложных срабатываний. Checkmarx поддерживает 20+ языков программирования, соответствует требованиям PCI-DSS, HIPAA, FISMA и другим нормативным стандартам. Все три инструмента работают с многими IDE и платформами CI/CD. Есть также SAST и с открытым исходным кодом, например CodeWarrior и NodeJsScan. OWASP тоже перечисляет более 20 инструментов и заявляет, что их недостатки включают в себя обнаружение проблем с настройками, уязвимости в управлении аутентификацией и доступом.
- Инструменты проверки зависимостей проверяют нижестоящие программные компоненты, включая библиотеки с открытым исходным кодом, и сообщают уязвимости. GitLab Secure поддерживает SAST и другие инструменты безопасности, включая проверку зависимостей, может работать с Java, JavaScript, PHP, Python, Ruby, Scala и Go. OWASP Dependency Check имеет поддержку в Jenkins, CircleCI и SonarQube. С помощью диспетчера управления безопасностью Snyk, имеющего открытый исходный код, разработчики могут найти и убрать уязвимости в открытом коде. Microsoft недавно выпустила Application Inspector, инструмент анализа кода, работающий с более чем 400 шаблонами, включая функции проверки безопасности.
- Тестирование на проникновение уже часто используется, но его во многих организация запускают по старинке, отдельно от процессов написания кода, сборки и развертывания в цикле разработки программного обеспечения (SDLC). Еще один известный инструмент OWASP ZAP (Zed Attack Proxy) можно подключить к комплексам CI/CD, например Jenkins и проверять развертывания. В цикле видеороликов All Day DevOps Simon Bennetts, руководитель проекта ZAP, отметил: «Чем раньше, тем лучше. ZAP для автоматизации покажет себя на все сто!»
- Инструменты DevOps, а также инструменты разработчиков и управления облаками, обычно предлагают свои дополнения безопасности. Например Jenkins и Azure DevOps имеют более 40 дополнений безопасности, CircleCI предлагает свыше 20. Microsoft Azure опубликовала методики обеспечения непрерывной безопасности, а AWS — руководство DevSecOps для пользователей CodePipeline. Технологии обеспечения безопасности, интеграции и инструменты DevOps развиваются быстро, так что команды infosec и разработки должны периодически освежать знания по этим инструментам в рамках новых дополнений безопасности.
- Еще одно важное примечание — обеспечение безопасной работы самих конвейеров CI/CD. Например защита ключей и параметров является критически важной для безопасности, так что CircleCI, Jenkins и другие предоставляют инструменты и рекомендации для их блокировки.
Цикл закрытия безопасности с мониторингом и AIOps
Еще есть целый альтернативный набор дисциплин DevSecOps, покрывающий инфраструктуру как код, усиление безопасности контейнеров и настройку облачных сервисов. Дополнительно есть специальные темы DevSecOps по безопасности данных, управления идентичностью, а также безопасностью устройств IoT. Если ваши инженерные и программные проекты затрагивают инфраструктуру, мобильные устройства, сети, IoT или аналитику — вам определенно понравятся эти специализированные методы и инструменты безопасности для указанных областей.
Любой разработчик приложений, выходя за рамки безопасности данных и инфраструктуры, должен лучше понимать, как приложения запускаются в производственных окружениях. Анализ инцидентов, ключевых причин, устранение дефектов — важнейшие обязанности при разработке приложений. Кроме того, для разработчиков это обычно значит улучшение аналитики, включая журналы из инструментов мониторинга приложений.
Новейшая технология для команд поддержки это AIOps, с ее помощью можно получить пользу от машинного обучения и автоматизации для упрощения DevOps и мониторинга приложений. Команды поддержки обычно работают с разными инструментами мониторинга, но жонглирование с разными инструментами может замедлить решение инцидентов — особенно что касается сложных многооблачных окружений, а также особенно если команды разработчиков часто раскатывают новые версии.
Инструменты AIOps забирают эксплуатационные данные из различных инструментов мониторинга, журналов приложений или инфраструктурных частей. Затем к этим данным применяется машинное обучение, чтобы помочь обозначить инциденты, активировать автоматические ответы, а также сократить время на их решение. Эти инструменты также помогают исследовать выбросы и медленно развивающиеся проблемы, просеивая длительные серии эксплуатационных данных.
Результатом деятельности команд infosec и разработки при возвращении эксплуатационных инцидентов безопасности обратно в процесс гибкой разработки является анализ с помощью мониторинга и AIOps. В принципе, это реактивная позиция, но этот метод является критически важным для гибких команд и компаний, внедривших DevOps, стремящихся к управлению безопасностью своих приложений и повышению ее уровня.
Кроме того, решение проблем с безопасностью требует сочетания проактивных шагов, введенных в начале процесса гибкой разработки, передовых методов и инструментов в конвейер разработки, а также реактивных мер, основанных на мониторинге производственных систем. Угрозы безопасности быстро меняются, так что гибкие команды и компании, внедрившие DevOps, должны постоянно учитывать методы обеспечения безопасности и внедрять новые технологии.