Если вы, как и я, отвечаете за успешный запуск критически важных приложений, помогающих бизнесу быть на передовой в цифровой трансформации, то, несомненно, поймете, о чем пойдет речь в этой статье. Для руководства такой миссией, помимо навыков проектирования архитектуры, требуются также навыки менторинга и управления инженерными ресурсами, а также контроль работы бизнес-аналитиков, выявляющих требования. Эти навыки в значительной степени детерминированы и управляемы по сравнению с другими, необходимыми для обеспечения надежной и безопасной работы приложений. Из-за этого разработчиков часто противопоставляют администраторам инфраструктуры и специалистам по информационной безопасности, считая их "последней миле" на пути к запуску приложения. Но у администраторов и "безопасников" возникают следующие проблемы:

• Инфраструктура. Планирование мощностей и провиженинг инфраструктуры по своей сути сложный и длительный процесс. Он требует времени, чтобы убедиться в доступности необходимых и достаточных вычислительных ресурсов, систем хранения данных, пропускной способности сети еще до того, как будет написана первая строчка кода. Необходимо прогнозировать увеличение нагрузки и резервировать соответствующие ресурсы, что приводит к их избыточному выделению только для того, чтобы избежать их нехватки в будущем, когда они потребуются. Это контрастирует с работой разработчиков, для которых скорость, гибкость и реакция на изменения являются фундаментальными принципами. Если вы используете локальные датацентры (aka On-Prem), то поймете меня.

• Безопасность. Из-за традиционного разделения разработки и эксплуатации, у разработчиков есть только ограниченная высокоуровневая информация об инфраструктуре, на которой будет работать их приложение. И "проверка безопасности" часто откладывается на поздние этапы разработки, хотя по-прежнему рассматривается как обязательное условие для запуска в продакшн. Это, как известно, вызывает серьезные трения между разработчиками и специалистами по информационной безопасности, поскольку очень часто требования по безопасности могут повлечь за собой значительные изменения в архитектуре и дизайне приложения, вызывая задержки и недовольство архитекторов и разработчиков.

В обеих вышеуказанных проблемах прослеживается общая черта — отсутствие прозрачности, общения и сотрудничества между разработчиками, администраторами и специалистами по информационной безопасности. Понять причины проблем нетрудно, поскольку эти группы исторически работают изолированно. Но можно посмотреть на эту проблему с другой стороны — неспособность видеть межфункциональные проблемы. Например, с точки зрения разработчика, он разрабатывает критически важную функциональность для бизнеса. Однако для специалистов по эксплуатации и безопасности потенциальные сбои в работе приложения превосходят любую бизнес-ценность, которую оно может принести. И до тех пор, пока не появится работающий механизм, обеспечивающий ​​кросс-функциональное видение, ситуация останется прежней. К счастью, такой подход появился естественным образом, и сегодня, как мы увидим ниже, он жив и процветает.

Инфраструктура как код (infrastructure as code)

"Инфраструктура как код" (Infrastructure-as-code) или "программируемая инфраструктура" — это практика провиженинга и управления ресурсами датацентра с помощью инструментов, которые описывают ресурсы (вычислительные, системы хранения данных, сеть), в форме машиночитаемых файлов. Для описания используются языки, похожие на языки программирования высокого уровня, с помощью которых разработчики могут автоматизировать настройку, развертывание, управление инфраструктурой, используя современные практики разработки программного обеспечения. Преимущества такого подхода невозможно переоценить, поскольку благодаря контролю версий появляется независимость, контроль, иммутабельность, повторяемость и трассируемость. Это первая практика, которая появилась для облегчения понимания межфункциональных проблем между разработчиками и администраторами инфраструктуры. С развитием этой практики стали проявляться два фундаментальных сдвига:

• У разработчиков появляется мощный инструмент для работы с аппаратными ресурсами, хоть и виртуальными, с помощью знакомого им простого интерфейса: API и библиотек. Внезапно развертывание и эксплуатация становятся просто продолжением процесса разработки. Полезным побочным эффектом становится то, что разработчики теперь понимают требования к уровню обслуживания, такие как высокая доступность, масштабируемость, надежность и отказоустойчивость.

• Администраторы инфраструктуры получают четкое представление о динамике разработки программного обеспечения, скорости и гибкости, которые становятся все более привычными. И они сами приобретают навыки разработки, внося свой вклад в программируемую инфраструктуру. Уходят проблемы нехватки и избыточности выделенных ресурсов, а также конфликты при изменениях, что позволяет им плотно взаимодействовать с разработчиками в достижении "эластичности" и "эфемерности" программируемого инфраструктурного облака.

Слияние двух вышеупомянутых трендов известно как "DevOps", ознаменовавшее появление "инфраструктуры как кода":

Безопасность как код (security as code)

Успех практики "инфраструктура как код" послужил примером для привлечения специалистов по информационной безопасности к обсуждению требований безопасности на ранних этапах разработки. Основным требованием для практики "безопасность как код" является возможность реализации программного управления безопасностью, автоматизации определения требований к безопасности, возможность оценки и обеспечения безопасности до и после запуска приложений, а также на протяжении всего жизненного цикла разработки. К безопасности инфраструктуры и приложений предъявляются определенные фундаментальные требования, такие как видимость, прозрачность и повторяемость средств управления безопасностью. Сложность состоит в том, чтобы реализовать все это без ущерба для скорости разработки, которая нужна разработчикам, особенно с учетом наличия в их арсенале платформ автоматизации инфраструктуры и DevOps.

Как и в случае с программируемой инфраструктурой, описанной в предыдущем разделе, здесь также происходят два фундаментальных сдвига в мышлении:

• Специалисты по информационной безопасности теперь считают, что можно ожидать от разработчиков следования практикам безопасного программирования и использования наглядного и автоматизированного способа анализа безопасности кода. Теперь уязвимости кода выявляются на ранних этапах. Также специалистам по информационной безопасности становится проще предоставлять разработчикам платформы с усиленной безопасностью ("security hardened") и полностью пропатченные ("fully patched"), на основе которых разработчики будут создавать приложения.

• Разработчики понимают, что обеспечение безопасности приложений должно быть "сдвинуто влево" и это безусловный критерий для продвижения приложения по дальнейшим этапам жизненного цикла (Dev, QA, Staging, Production).

Конвергенция двух вышеупомянутых сдвигов известна как "SecOps" — "безопасность как код" (security as code):

Собираем все вместе —- "DevSecOps"

На основе вышеизложенного должно быть очевидно, что напрашивается объединение подходов "инфраструктура как код" и "безопасность как код". Как показано на рисунке ниже, эти практики естественным образом сливаются для гармоничного взаимодействия между различными ролями и используемыми системами.

Можно выделить несколько фундаментальных принципов DevSecOps:

• Обеспечьте гибкость и скорость, инвестируя в hardened-инструменты, охватывающие весь жизненный цикл приложений и ресурсов: разработка-тестирование-развертывание-мониторинг.

• Подвергайте все сомнению, обеспечивая прозрачность на каждом этапе CI / CD-конвейера.

• Сделайте безопасность фундаментальным и безусловным критерием приемки на раннем этапе процесса разработки. Другими словами, "сдвиньте безопасность влево".

• Относитесь ко всему с подозрением, включая код, конфигурацию, артефакты, инфраструктуру, и установите оценку безопасности в качестве требования для продвижения по конвейеру.

• Как можно чаще прогоняйте приложение через Dev, QA, Staging и Production.

• И, наконец, автоматизируйте, автоматизируйте и автоматизируйте.

Решения для этого можно разработать и собственными силами, но выгоднее использовать готовые продуманные решения. Есть несколько работоспособных платформ с открытым исходным кодом, создание аналогов которых может потребовать серьезных ресурсов, знаний и опыта.

Основные характеристики платформы оркестрации, ориентированной на DevSecOps

На рынке существует множество решений для компаний, заинтересованных во внедрении DevSecOps-практик. При выборе любой такой платформы необходимо учитывать следующие критерии:

• Программный интерфейс с открытым API. Красивый пользовательский интерфейс — это здорово, но с его помощью невозможно сделать серьезную интеграцию со сторонними продуктами. 

• Возможность интегрироваться и взаимодействовать с существующей ИТ-экосистемой. В enterprise-мире много легаси-систем и есть большая вероятность, что это будут критически важные системы для бизнеса.

• Должна быть возможность развертывания в различных конфигурациях инфраструктуры без привязки к облакам.

• Обеспечение безопасности приложений до их развертывания в рабочей среде.

• Установка базового уровня безопасности (baseline) и постоянный мониторинг отклонений от него.

• Поддержка оценки безопасности как на определенный момент времени, так и на основе мониторинга и событий. Это очень важно для отслеживания таких метрик, как MTTD (Mean-time-to-detect, среднее время обнаружения) и MTTR (Mean-time-to-recover, среднее время восстановления) для постоянного улучшения процессов.

• Сбор всей необходимой информации о проблеме и предложение способов ее устранения — зачем говорить о проблеме, если мы не знаем, как ее решить?

• Обеспечение информированности о работе конвейера через отправку уведомлений.

• Поддержка механизмов реагирования на инциденты через интеграцию с другими системами, чтобы анализ "первопричин" проводился сразу же, а не через несколько дней после инцидента, повлиявшего на бизнес.

Материал подготовлен в рамках курса «Внедрение и работа в DevSecOps». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.