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

Как избежать ада зависимости в ограничительной среде

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

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

Как сбалансировать безопасность с необходимостью доступа к публичным репозиториям? Есть ли способ ограничить зависимость от внешних репозиториев, не сделав установку программного обеспечения Linux невозможной? Какие аргументы можно привести в пользу безопасности и надежности репозиториев yum или apt-get?

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

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

В качестве конкретного примера я ранее видел примеры, когда в полуофициальных сторонних репозиториях пакетов для стабильного дистрибутива Linux пакеты приходили и уходили с течением времени. Это вызвало массу проблем, потому что мы могли создать несколько машин одновременно, на каждой из которых была бы одна и та же версия критического пакета. Некоторое время спустя, когда мы начали собирать больше машин, указанная нами версия больше не была доступна (ее заменила более новая, более блестящая версия), и нам пришлось снова все протестировать, чтобы убедиться, что новый пакет по-прежнему работает правильно.

Это не худший вариант. Что если мы не сделал протестировать новый пакет, и в нем есть критическая ошибка? Облом. Конечно, в выбранной нами версии может быть обнаружен недостаток безопасности, но это нормально, потому что, как ответственные упаковщики, мы следим за сообщениями о безопасности восходящего направления и следим за тем, чтобы все уязвимости были исправлены надлежащим образом.

Осторожный администратор устанавливает пакеты в свои системы только из двух мест:

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

Содержимое этого набора внутренних репозиториев можно заполнить несколькими способами:

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