Публикации и ответы на комментарии в блогах JetBrains не выходят на русском языке с 2022 года.
Приносим извинения за неудобства.
Дополнительная защита вашего сервера TeamCity
TeamCity лежит в основе процесса сборки. Он собирает исходный код в артефакты и зачастую также выполняет развертывание. Это значит, что у TeamCity потенциально есть доступ к конфиденциальным данным.
TeamCity обеспечивает высокую безопасность по умолчанию. Однако мы хотим предложить вам некоторые дополнительные шаги, которые обеспечат еще более надежную защиту пайплайнов сборки.
Общие рекомендации
Регулярно обновляйте сервер TeamCity
Рекомендуем вам регулярно обновлять TeamCity до последней версии.
Интерфейс TeamCity автоматически уведомляет о доступных обновлениях. Также вы можете отслеживать их самостоятельно: чтобы просмотреть доступные обновления TeamCity, перейдите в Server Administration > Updates, а для обновлений плагинов — в Server Administration > Plugins.
Обновления, выпускаемые между релизами с исправлениями ошибок, у которых совпадает младший/старший номер версии, обладают обратной совместимостью (например, 2020.1.1 → 2020.1.2) и поддерживают возвращение к предыдущей версии (в простых случаях). Что касается других крупных обновлений, мы стараемся обеспечить максимально гладкий переход. При этом настоятельно рекомендуем вам выполнять резервное копирование — оно облегчает откат к предыдущим версиям.
С точки зрения лицензий, обновления, выпускаемые между релизами с исправлениями ошибок, также абсолютно безопасны. И если, например, ваша лицензия покрывает версию 2020.1.1, вы сможете обновиться до любой версии с номером 2020.1.x.
Подпишитесь на оповещения службы безопасности
Рекомендуем подписаться на оповещения службы безопасности, чтобы всегда быть в курсе проблем, которые могут затронуть TeamCity и другие продукты JetBrains.
Учетные данные
Используйте надежные учетные данные и осторожно обращайтесь с ними
Рекомендуем использовать надежные учетные данные не только для вашего сервера TeamCity, но и для всех остальных сервисов, которые используются для сборки либо необходимы вашему ПО в продакшне.
Важно не хранить учетные данные в:
- Репозиториях, таких как GitHub, GitLab и др.
- Переменных окружения, поскольку они часто логируются или отсылаются в сторонние системы мониторинга.
- Логе сборки — проверьте, что вы не логируете учетные данные.
Также, если вы используете настройки управления версиями (в формате Kotlin DSL или XML), никогда не сохраняйте учетные данные в конфигурационные файлы. Вместо этого можно применять токены.
Храните конфиденциальные данные в параметрах типа password
Мы настоятельно рекомендуем использовать параметры типа password для хранения паролей и других конфиденциальных данных в настройках TeamCity. В таком случае эти значения никогда не отобразятся в веб-интерфейсе TeamCity и будут скрыты в логе сборки (вместо них вы увидите звездочки).
Подключите инструмент управления секретами
Хотя пароли маскируются веб-интерфейсом, шифруются и не отображаются в логе сборки, это зачастую не обеспечивает должного уровня безопасности.
Вы можете воспользоваться HashiCorp Vault — инструментом, который позволяет управлять учетными данными, необходимыми для сборки, и менять их. HashiCorp Vault прекрасно интегрируется с TeamCity.
Используйте внешнюю аутентификацию
Вы можете использовать один из наших модулей аутентификации, в частности, предоставляющих интеграцию с LDAP и Windows Domain, возможность аутентификации через GitHub, GitLab и др. Тогда вы сможете отключить встроенную аутентификацию TeamCity, и он больше не будет хранить хэши паролей в своей внутренней базе.
Используйте пользовательский ключ шифрования
Пароли, необходимые для аутентификации в сторонних системах (таких как VCS, баг-трекеры и др.), хранятся в зашифрованном виде в <TeamCity Data Directory>. Также они могут храниться в базе данных. И хотя эти значения защищены шифрованием, пользователь, у которого есть доступ к файловой системе сервера или базе данных, сможет получить их.
Вместо того, чтобы выполнять шифрование по умолчанию, вы можете подключить пользовательский ключ шифрования. Тогда TeamCity не будет применять стандартный механизм шифрования, а будет использовать уникальный пользовательский ключ для шифрования всех конфиденциальных значений.
Права доступа
Пользуйтесь предопределенными ролями
В TeamCity по умолчанию задано несколько ролей:
- Системный администратор
- Администратор проекта
- Разработчик в проекте
- Пользователь, просматривающий проект
Вы можете создать группы пользователей, соответствующие вашей организационной структуре, и назначить им вышеперечисленные роли. Далее вам останется добавить пользователей в нужные группы, предоставляя каждому из них наиболее низкий уровень привилегий, которого будет достаточно для повседневной работы.
Также рекомендуется создать роли с дополнительными правами. Так, если потребуется выдать пользователю больше привилегий, вам не придется выдавать ему роль администратора проекта. (Необходимо включить опцию per-project permissions.)
Включите авторизацию на уровне проекта
Для усиления безопасности вы также можете воспользоваться авторизацией на уровне проекта. К примеру, это позволит вам ограничить разработчиков доступом только к той части цепочки сборки, которая связана с компиляцией, а DevOps-специалисты будут работать с той частью, которая связана с развертыванием.
Отключите гостевой вход
По умолчанию анонимный вход в TeamCity запрещен. Важно не включать его на продакшн-серверах, доступных через интернет. Иначе внешние пользователи смогут просматривать все ваши сборки, а также соответствующие файлы логов и артефакты.
Создайте отдельного пользователя для REST
Если вы запрашиваете TeamCity’s REST API из внешнего скрипта или программы, рекомендуем создать отдельного пользователя с соответствующим набором прав. Также полезно создать токены доступа с истекающим сроком действия, чтобы не использовать логины и пароли пользователей для доступа к API.
Ограничьте права на сборки с развертыванием
Убедитесь, что для цепочек сборок с развертыванием запрещены персональные сборки. Ограничьте круг разработчиков, которым разрешено запускать эти сборки, и используйте для их выполнения отдельные пулы со свежими агентами.
Сервер TeamCity
Защитите директорию Data
Пользователи, которым доступна на чтение директория <TeamCity Data Directory>, также имеют доступ ко всем настройкам сервера, включая пароли. Поэтому важно сделать эту директорию доступной для чтения только тем пользователям ОС, которые являются администраторами сервиса.
Защитите ваш сервер TeamCity
Ограничьте доступ к компьютеру, на котором запущен ваш сервер TeamCity. Настройте логи доступа и регулярно просматривайте их.
Используйте HTTPS
Разрешите TeamCity использовать HTTPS. На сегодняшний день мы рекомендуем настроить HTTPS на обратном прокси (например, Nginx или Apache).
Обеспечьте безопасность внешней базы данных
Для работы со схемой базы данных сервера TeamCity используйте специальный пользовательский аккаунт с надежными учетными данными. Вы также можете использовать шифрование, если ваша база данных поддерживает его.
Система контроля версий
Обновляйте Git
На билд-агентах всегда должна быть установлена самая свежая стабильная версия операционной системы и Git. Регулярно выполняйте обновления.
Грамотно управляйте SSH-ключами
Если для доступа к репозиториям вы используйте SSH-ключи, не следует хранить их на билд-агентах. Вместо этого используйте предоставляемые TeamCity возможности по управлению SSH-ключами и загружайте эти ключи на сервер TeamCity.
А вместо того, чтобы отключать проверки известных хостов, создайте на сервере и билд-агентах файлы .ssh/known_hosts для каждого хоста, к которому вы подключаетесь.
Заведите специального VCS-пользователя
Если вы не используете продвинутые возможности вроде Kotlin DSL, а ваш процесс сборки вовсе не требует коммитов в репозиторий, рекомендуем вам завести специального VCS-пользователя без прав на запись и взаимодействовать с репозиторием при помощи него.
Билд-агенты
Запускайте чистые продакшн-сборки
Рекомендуем включить опцию Enforcing Clean Checkout для продакшн-сборок, чтобы не допустить изменения исходного кода на агентах.
Используйте одноразовые билд-агенты с защитой от доступа из сети
По возможности используйте одноразовые билд-агенты. Чем меньше срок службы агента, тем ниже вероятность того, что его взломают. Также важно применять задаваемые ОС правила брандмауэра, позволяющие блокировать доступ к облачным агентам из сети.
Используйте отдельный пул агентов для каждого проекта
Если вы запускаете несколько агентов на одном компьютере и у вас выключена опция Enable Clean Checkout, вам следует помнить, что взломанные агенты и неизвестные проекты смогут менять исходный код в соседних директориях.
Чтобы снизить риск, попробуйте запускать по одному агенту на компьютере и использовать свои пулы агентов для каждого проекта (как для закрытого, так и для публичного).
Интеграция
Не собирайте публичные пул-реквесты вслепую
Если вы собираете пул-реквесты от неизвестных пользователей или от тех, кто не состоит в вашей организации, вы должны помнить, что таким образом на ваши билд-агенты вполне может попасть и вредоносный код.
Необходимо либо запретить сборку публичных пул-реквестов, либо использовать изолированные одноразовые агенты. TeamCity также предоставляет встроенные отчеты о состоянии системы, которые включают информацию о сборках подобных пул-реквестов.
Версионирование настроек может иметь последствия для безопасности
Когда вы используете версионирование настроек (Kotlin DSL, XML) и эти настройки хранятся в том же репозитории, что и исходный код, злоумышленник вполне может изменить настройки конфигурации проекта и организовать их утечку. Для этого достаточно добавить шаг сборки, который выводит пароли и отправляет их куда-либо в виде файла.
Как вариант, вы можете использовать для версионирования настроек отдельный репозиторий, возможность коммита в который будет доступна только ограниченному кругу пользователей.
Будьте осторожны со сторонними плагинами
Устанавливая плагины, проверяйте, что они из надежного источника и их исходный код есть в общем доступе. Дело в том, что у плагинов потенциально есть доступ ко всей информации на сервере TeamCity, включая конфиденциальные данные.
Хранение артефактов
Блокируйте анонимный доступ
Независимо от того, где вы храните артефакты сборки (такие как S3), важно блокировать доступ анонимных пользователей к вашему хранилищу.
Используйте надлежащие политики доступа
Используйте надлежащие политики доступа для защиты S3 и прочих хранилищ или репозиториев для артефактов. Также по возможности используйте шифрование. Регулярно пересматривайте и проверяйте логи доступа ваших хранилищ.
Не храните конфиденциальные данные в артефактах
Само собой разумеется — не стоит хранить учетные данные и другую конфиденциальную информацию в виде текста в артефактах сборки.
История сборок и логи
Храните историю сборок
Храните историю сборок дольше (особенно если для них выполняется критическое развертывание), указывая для проекта соответствующие правила чистки. Не выдавайте разработчикам права на удаленные сборки, так как это может помешать архивированию.
И то, и другое поможет отследить поведение злоумышленников, даже если это произошло давно.
Архивируйте логи сервера и агентов
Собирайте логи сервера TeamCity и билд-агентов в архив и храните их в безопасном месте.
Поделитесь этой статьей
Для удобства распространения мы также подготовили эту статью в формате PDF. Поделитесь ей с коллегами: скачать PDF (на англ. яз.).
Ваша команда TeamCity
The Drive to Develop
Subscribe to TeamCity Blog updates
