Чем проверка криптографической подписи артефакта на границе развёртывания отличается от проверки его хеша?
Хеш позволяет проверить целостность артефакта только относительно заранее доверенного значения, тогда как криптографическая подпись дополнительно связывает артефакт с владельцем закрытого ключа. Поэтому подпись позволяет на границе развёртывания проверить не только факт изменения, но и происхождение артефакта — при условии, что открытый ключ и правила доверия защищены.
Хеши появились как эффективный способ обнаруживать изменения данных: одинаковый вход даёт одинаковое контрольное значение, а изменение входа с высокой вероятностью меняет хеш. Однако сам по себе хеш не отвечает на вопрос, кто сформировал эталонное значение.
Криптографические подписи решают эту проблему для распределённых процессов поставки программного обеспечения. Разработчик или доверенный конвейер подписывает конкретный артефакт закрытым ключом, а система развёртывания проверяет подпись соответствующим открытым ключом.
Артефакт может пройти сборку, попасть в реестр и затем быть изменён на одном из этапов доставки. Если система проверяет только наличие файла или его хеш, злоумышленник, получивший возможность заменить артефакт и эталонный хеш, сможет подменить оба значения.
Проверка хеша также бесполезна против подмены источника эталонного значения. Если хеш скачивается из того же недоверенного канала, что и артефакт, он подтверждает лишь согласованность двух подменённых объектов.
Неверное понимание подписи тоже опасно: валидная подпись не доказывает отсутствие уязвимостей и не делает артефакт безопасным сама по себе. Она подтверждает связь содержимого с ключом, которому система доверяет.
При проверке хеша система вычисляет хеш полученного артефакта и сравнивает его с доверенным эталоном. Это обнаруживает случайное повреждение или замену, если эталон хранится отдельно и защищён от изменения. Хеш не содержит сведений об авторе и не препятствует злоумышленнику пересчитать его после подмены.
При проверке подписи система использует открытый ключ, чтобы убедиться, что подпись создана соответствующим закрытым ключом и относится именно к полученному содержимому. Изменение даже небольшого фрагмента артефакта делает подпись недействительной.
Безопасная граница развёртывания должна проверять как минимум:
Подпись не заменяет хеш: хеш обычно является частью подписываемого содержимого и помогает однозначно идентифицировать артефакт. Практическая схема часто использует подпись для проверки происхождения и хеш для фиксации точной версии содержимого.
Главный компромисс — сложность управления ключами. Компрометация закрытого ключа позволяет подписывать вредоносные артефакты, поэтому нужны защищённое хранение ключей, ограничение полномочий подписантов, ротация и процедура отзыва. При этом доверие к подписи не должно быть шире необходимого: ключ сборочного проекта не обязан иметь право выпускать артефакты для производства.
Команда хранит контейнерные образы в реестре. Вариант с проверкой только хеша прост и дёшев, но безопасен лишь при независимом и защищённом канале доставки эталонных хешей. Если злоумышленник получил право изменять реестр или метаданные рядом с образом, он может заменить образ и его хеш.
Второй вариант — разрешать развёртывание любого образа из доверенного реестра. Это снижает количество настроек, но доверяет административной границе реестра и не отличает легитимный образ от вредоносного, загруженного с украденными полномочиями.
Выбран вариант, при котором конвейер подписывает образ отдельным ключом, а кластер принимает только образы с подписью разрешённого проекта и конвейера. Дополнительно используется хеш-фиксация версии вместо подвижного тега. В результате подмена содержимого обнаруживается, а сам факт нахождения образа в реестре больше не считается достаточным основанием для развёртывания.
1. Дополнительный вопрос: Достаточно ли валидной подписи, если ключ принадлежит доверенной организации?
Нет. Подпись подтверждает владение ключом и целостность подписанного содержимого, но не доказывает, что конкретный артефакт прошёл нужные тесты, не содержит уязвимостей и предназначен для данного окружения. Политика развёртывания должна проверять контекст выпуска: проект, тип артефакта, ветку или выпуск, результаты обязательных проверок и область действия ключа.
2. Дополнительный вопрос: Что произойдёт, если злоумышленник украдёт закрытый ключ подписи?
Он сможет создавать артефакты с технически корректной подписью. Поэтому компрометация ключа должна приводить к его отзыву или исключению из доверенной политики, а ключ следует хранить в защищённом средстве с ограниченным доступом и по возможности использовать раздельные ключи для разных проектов и окружений.
Одна только ротация не исправляет уже выпущенные подписи, если система продолжает доверять старому ключу. Нужны правила определения момента компрометации, проверка статуса ключа и журналирование подписей, чтобы оценить, какие артефакты необходимо перепроверить или отозвать.
3. Дополнительный вопрос: Почему нельзя считать имя или тег артефакта доказательством его подлинности?
Имя и тег обычно являются изменяемыми метаданными и могут указывать на другое содержимое после перезаписи или повторной публикации. Они удобны для поиска, но не обеспечивают криптографическую фиксацию версии.
Для строгой идентификации используют дайджест содержимого, а для проверки происхождения — подпись этого содержимого и политики доверия к подписанту. Поэтому развёртывание по неизменяемому хешу безопаснее, чем развёртывание по подвижному тегу, даже если тег выглядит ожидаемым.