Назад | Перейти на главную страницу

Предостережения при установке средств разработки на рабочий сервер

Я хочу установить некоторое программное обеспечение в производственной системе CentOS, которое недоступно в репозитории (например, tmux и т. Д.). Я могу загрузить исходный код и скомпилировать его локально, но для этого мне понадобятся инструменты разработки (gcc и т. Д.) В производственной коробке. Хорошая идея - установить инструменты разработки на производственной коробке?

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

  • Наличие «лишнего» программного обеспечения на машине означает большее количество «движущихся частей» и большую вероятность отказа.

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

  • На мой взгляд, компиляция вещей с нуля на производственных машинах противоречит строгому процессу контроля изменений.

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

Основные риски, связанные с эксплуатационным аспектом / аспектом безопасности наличия средств разработки в производственных системах, заключаются в том, что проще говоря:

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

Для того, чтобы :

  1. используйте пакеты из хорошо обслуживаемых репозиториев, позвольте сопровождающему беспокоиться о подписке на списки рассылки, объявлениях CVE, отслеживании ошибок, создании и тестировании пакетов и т. д.
  2. создайте свои собственные пакеты и сделайте это самостоятельно. Создавайте систему для разработки или сборки, тестируйте и выполняйте управление выпусками в UAT перед развертыванием в производственной среде.