Банковское обозрение

Сфера финансовых интересов

  • Обеспечение кибербезопасности автоматического развертывания программного обеспечения
11.01.2019 Best-practice
Обеспечение кибербезопасности автоматического развертывания программного обеспечения

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



Автоматизация разработки

Автоматизация стала неотъемлемой частью разработки программного обеспечения, причем не только в крупных компаниях, но и у небольших команд, а также у индивидуальных разработчиков. Автоматизируются сборка, установка и тестирование программ. В мире Linux всем знакомы команды ./ configure && make && make install, которые использовались до появления пакетных менеджеров типа apt и продолжают использоваться сейчас. Последовательность команд, запускающих проверку и компиляцию исходного кода, объединяется в набор скриптов для облегчения повторного использования в процессах разработки, отладки и тестирования ПО.

Следующая ступень в зрелости процесса разработки — это организация «непрерывности»: Continuous Integration, Continuous Delivery, Continuous Deployment. Слово «Continuous» в данном контексте и означает «непрерывность» — снижение временных затрат, связанных со взаимодействием нескольких специалистов в процессе разработки ПО.

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

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

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

Однако у непрерывной разработки есть свои проблемы. Многие ошибки, возникшие в процессе разработки, требуют вмешательства человека, а обеспечение кибербезопасности нуждается в дополнительных мерах. Обычно, когда говорят о DevOps и безопасности (DevSecOps), имеют в виду автоматизацию статического (SAST) или динамического (DAST) сканирования. Эти виды сканирования направлены на обеспечение качества кода. В этой статье мы не будем рассматривать вопросы качества кода, SSDL и общий подход к безопасности DevOps, а сосредоточимся на обеспечении безопасности автоматического развертывания программного обеспечения.

Различия ручной и автоматизированной установки ПО

1. Учетная запись в среде исполнения приложения: операционная система или сервер приложений

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

2. Токены API-доступа к сторонним системам и прочие секретные параметры конфигурации приложения

К данному классу относятся все параметры конфигурации разворачиваемого приложения, раскрытие которых нежелательно и может повлечь за собой несанкционированный доступ к сторонним ресурсам: СУБД, справочники и иные информационные системы. Отличие данного класса от предыдущего состоит в том, что эти данные не используются во время развертывания для получения доступа к сторонним системам, а лишь записываются в конфигурацию разворачиваемого приложения. С увеличением количества таких параметров растет вероятность ошибки человека, который может указать некорректные данные при ручной установке. Такие ошибки очень тяжело обнаружить в момент развертывания, так как чаще всего они проявляются только при начале эксплуатации, а последствия могут быть катастрофическими: например, для стенда нагрузочного тестирования указать реквизиты «боевой» базы данных.

Четыре правила безопасности Continuous Deployment

Для защиты от компрометации секретных данных необходимо следовать четырем правилам безопасности Continuous Deployment:

1) применять при автоматическом развертывании и только для него отдельные учетные записи;

2) использовать защищенное хранилище учетных данных, исключающее несанкционированный доступ к этим данным;

3) управлять доступом к секретным данным, разработав ролевую модель;

4) вести журналирование доступа к учетным данным.

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

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

Пример: защита без бюджета

Когда бюджет компании на кибербезопасность ограничен, можно ограничиться бесплатными OpenSource-решениями. Если для автоматизации установки сборок используется Ansible, то для защищенного хранения секретных данных следует использовать инструмент Ansible Vault:

• Ansible Vault шифрует inventory-файлы Ansible с помощью AES-256;

• зашифрованные inventory-файлы нужно сохранить в git-репозиторий, например GitLab, и управлять доступом к данным встроенными средствами репозитория;

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

У описанной реализации есть недостатки. Если понадобится изменить один пароль, придется расшифровывать весь inventory-файл, внести изменения, затем заново зашифровать файл и отправить обновления в репозиторий. Так как в системе контроля версий хранится зашифрованный файл, изменения не видны в истории коммитов — их трудно отслеживать. А еще могут случаться ошибки, когда в репозиторий отправляется незашифрованный файл. В таком случае секретные данные попадают в историю коммитов, что требует дополнительных действий над репозиторием и смены всех скомпрометированных паролей.

Пример: коммерческое решение

Коммерческие решения более функциональны и удобны. Например, Liebermann Enterprise Random Password Manager может отдавать пароли в тот же Ansible через REST API, а также более гибко настраивать доступ к сохраненным секретам:

• в отличие от Ansible Vault, ERPM позволяет и зашифровать данные, и управлять доступом к ним;

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

Удобство ERPM порождает еще одну угрозу: администратор инструмента имеет возможность выгрузить все сохраненные данные в открытом виде. Для минимизации этого риска можно применять разделение секрета, сохраняя одну половину пароля в ERPM, а другую — в другом месте.

Пример: альтернатива

Еще пара интересных продуктов — это Hashicorp Vault и CyberArk Conjur, представленные как в бесплатном OpenSource-варианте, так и в виде коммерческого продукта. Hashicorp Vault интегрируется со всеми основными системами автоматизации развертывания ПО: Ansible, Chef, Puppet, а его бесплатный вариант по функциональности превосходит Ansible Vault. CyberArk Conjur поставляется в виде Docker-контейнера, что облегчает масштабирование решения.

Заключение

Подведем итоги. Мы выяснили, чем ручная установка отличается от автоматической, сформулировали четыре правила безопасности Continuous Deployment и рассмотрели два варианта их реализации с использованием бесплатного и коммерческого инструментария. Также привели продукты, у которых есть как бесплатная, так и платная версия. Даже небольшая компания, использующая бесплатные OpenSource-продукты, сможет сделать свои процессы разработки более безопасными.

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