Риски цепочки поставок для ОС пакетов

Риски атаки на цепочку поставок программного обеспечения в библиотеках хорошо документированы, однако я не видел много информации о пакетах/зависимостях ОС. Насколько важно 1) зафиксировать зависимости ОС (apt, rpm и т.д.) и 2) размещать их в частных репозиториях?

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

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

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

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

Фиксация версий пакетов ОС также использовалась для установления политик стабильности ОС. Например, вы можете захотеть придерживаться текущей версии программного обеспечения в течение 6 месяцев после выхода новой версии; таким образом, если новая версия вводит какие-либо дефекты, вы не пострадаете и позволите времени решить все проблемы, прежде чем примите ее.

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

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

Они на самом деле не важны

Это кажется сценарием, где у вас есть дистрибутив GNU/Linux, такой как Ubuntu или Red Hat.

Если пакет (например, libc) был скомпрометирован вне, и Red Hat его упаковал, он поступит в вашу ОС (классический сценарий, который вы нашли обсуждаемым).

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

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

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

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

Теперь давайте проанализируем предложенные вами решения:

• размещение пакетов в частных репозиториях

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

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

Вы можете считать, что ваше другое решение:

• зафиксировать зависимости ОС (apt, rpm и т.д.)

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

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

¹ В этом случае как конечным пользователям не имеет значения, был ли сам поддерживатель злонамеренным или была ли скомпрометирована инфраструктура (включая ключ подписи).