Безопасность должна рассматриваться как интегрированный и постоянный компонент процесса разработки и доставки приложений, пишет на портале The New Stack Джеймс Сандерс, главный аналитик по облачным технологиям и инфраструктуре компании CCS Insight.

Разработка ПО как дисциплина по своей сути эвристична. Это делает ее периодически подверженной влиянию социальных тенденций и тенденций в организации управления.

Такие практики, как DevOps, Agile и разработка на основе тестирования, проникли и в стартапы, и в крупные предприятия, как и другие технические достижения, включая нативные облачные вычисления, событийно-ориентированные архитектуры и наблюдаемость всего стека. Эти практики направлены на повышение надежности ПО и снижение трудозатрат разработчиков, однако достижение этих целей сопряжено с определенными компромиссами.

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

Небезопасный код предшествует (и должен предшествовать) безопасному

Проблемы в ПО обычно делятся на две категории: функциональность или безопасность. При создании новых приложений разработка функциональности и устранение ошибок имеют приоритет перед обеспечением безопасности. Понятно, что большинство организаций стимулируют достижение измеримых показателей, таких как функциональность, в ущерб невидимым атрибутам (например, отсутствию уязвимостей). Проблема заключается в ролевом подходе: разработчики по своей сути не являются специалистами по безопасности; рабочий процесс разработки плохо подходит для проверки и подтверждения безопасности.

Проведем параллель: написание кода функционально идентично написанию прозы — максимы, применимые к первому, применимы и ко второму. В качестве показательного примера можно привести мнение писательницы Джанет Халстранд: «Плохая писанина предшествует хорошей. Это непогрешимое правило, поэтому не стоит тратить время на то, чтобы ее избежать. (Это только замедляет процесс.) Все, что записано на бумаге, может быть изменено. Главное — начать, а потом двигаться дальше».

Перекладывать на разработчиков задачу создания безопасного кода с самого начала — такая же глупость, как и перекладывать на писателей задачу создания хорошей прозы в первом варианте. Точно так же, как плохо написанное можно исправить путем доработки и редактирования, небезопасный код можно сделать безопасным путем тестирования, доработки и проверки — разработка ПО, как и писательство, является итеративным процессом. Лучше всего это достигается путем тестирования кода на ранних этапах разработки (т. н. «shift left», «сдвиг влево»), что позволяет найти уязвимости и уменьшить нагрузку на программистов, устраняя эти уязвимости на ранних этапах, а не требуя серьезного переписывания или значительного изменения дизайна ближе к концу проекта. Аналогичным образом, ограничение масштабов новых проектов целевым набором задач — так называемым минимальным жизнеспособным продуктом — помогает уменьшить количество неожиданностей после поставки.

Shift Left требует сотрудничества и мотивации

Написание кода — это лишь один из аспектов разработки приложений, хотя именно он является основным критерием, по которому сегодня оценивают отдельных программистов. Эффективный «сдвиг влево» требует внимания к управлению персоналом и рабочей нагрузкой. Добавление обязанностей по тестированию безопасности без выделения времени на их выполнение приведет к тому, что усилия будут минимальными. Разработчики будут воспринимать это как «не свою работу», если не будет ни выгоды, ни оценки за выполнение этой (да и практически любой) задачи.

Перенос обеспечения безопасности «влево» — это не просто передача обязанностей от операционных групп к группам разработки. Речь идет о том, чтобы разработчики могли писать безопасный код, не прерывая своего рабочего процесса. Инвестиции в автоматизацию, в том числе в проверенные общие платформы, поддерживающие «золотые пути», не только способствуют формированию культуры безопасности, но и позволяют сократить дублирование усилий в управлении жизненным циклом приложений.

Это движение также требует определенного уровня повышения квалификации, поскольку разработчики могут не знать полного каталога сервисов в том или ином облаке, а также лучших практик и мер безопасности для реализации того или иного сервиса на той или иной облачной платформе. Не менее полезным является и сотрудничество с платформенными инженерами по поводу имеющихся возможностей. Среди специалистов по облачным технологиям, участвовавших в исследовании CCS Insight «IT Infrastructure & Software Survey for Financial Services & Insurance», безопасность была названа наиболее влиятельным фактором при определении места размещения рабочих нагрузок.

Практические соображения по обеспечению непрерывной интегрированной безопасности

Развертывание приложения — это не только оценка ПО, но и оценка базовой среды, в которой работает приложение. Создание, тестирование и проверка среды с помощью инструментов «инфраструктуры как кода» (Infrastructure as Code, IaC), которые могут использоваться совместно с другими командами и повторно применяться в системах разработки и в производстве, позволяет значительно сократить объем работы разработчиков над каждым проектом, избавляя их от необходимости изобретать и перепроверять среду для каждой платформы, среды или рабочей нагрузки.

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

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

Существуют ли для приложений, написанных на скриптовых языках, жесткие зависимости, требующие устаревших/небезопасных версий интерпретаторов, таких как Python 2.7 или PHP 7? Являются ли библиотеки, используемые в программе, актуальными и активно ли они поддерживаются? Как обстоят дела с происхождением этих библиотек? Можете ли вы — от менеджера пакета до его мейнтейнера — подвергнуться риску повторения известного инцидента с NPM-пакетом left-pad?

В более общем плане, существует ли проверка ввода? Шифруется ли насквозь среда приложения, и разумно ли реализовано само шифрование? Существует ли ролевой контроль доступа (RBAC), и откуда наследуются определения ролей и назначения пользователей? Как часто проверяется этот источник на наличие устаревших записей (бывших сотрудников)?

С точки зрения функциональности и практического использования, изменился ли объем услуг, для предоставления которых было развернуто приложение? Если отдельные функции и, как следствие, данные, предоставляемые приложением, не нужны, то рефакторинг приложения с целью сокращения функциональности уменьшает потенциальную поверхность атаки для злоумышленников.

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

Превращение утопии в реальность

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