Для подписания кода используется инфраструктура открытых ключей (PKI), которая служит цифровым паспортом Вашего программного обеспечения. С помощью цифровых подписей она создает криптографическое доказательство подлинности и целостности. Она удостоверяет Вашу подлинность как издателя и гарантирует целостность кода, доказывая, что Ваш код не был изменен с момента выпуска.
Когда пользователи загружают Ваше программное обеспечение, они доверяют Вам безопасность своей системы. Нарушьте это доверие один раз, и Вам конец.
Оглавление
- Защитите личные ключи с помощью аппаратных модулей безопасности
- Реализуйте строгий контроль доступа к ключам подписи кода
- Поставьте временную метку на Ваш код во время процесса подписания
- Отделите среду подписания теста от среды подписания релиза
- Внедрите аутентификацию и проверку целостности кода перед подписанием
- Выполните проверку кода на вирусы перед подписанием
- Ротация ключей и использование нескольких сертификатов
- Отнеситесь к отзыву сертификата серьезно
- Использование сертификатов подписи кода расширенной валидации
- Автоматизируйте и централизуйте управление подписанием кода
- Защитите свою цепочку поставок программного обеспечения с помощью SSL Dragon
Ставки стали реальными после того, как взлом SolarWinds выявил критические уязвимости в цепочке поставок программного обеспечения, показав, как скомпрометированные ключи подписи могут стать оружием для законных обновлений программного обеспечения и скомпрометировать тысячи организаций. Сейчас, как никогда ранее, следование лучшим практикам подписания кода не является чем-то необязательным — оно имеет фундаментальное значение для защиты Ваших пользователей и Вашей репутации.
Защита цепочки поставок программного обеспечения стала главным приоритетом для организаций любого размера. Эти рекомендации помогут Вам реализовать меры безопасности, которые имеют значение, независимо от того, являетесь ли Вы одиночным разработчиком или управляете корпоративными конвейерами DevOps. Независимо от того, подписываете ли Вы исполняемые файлы Windows, приложения macOS, пакеты Linux или мобильные приложения для iOS и Android, эти принципы применимы ко всем платформам.
Защитите личные ключи с помощью аппаратных модулей безопасности
Ваш личный ключ В подписании кода это все. Скомпрометируйте его, и злоумышленники смогут подписывать вредоносные программы под Вашими данными. Ваш сертификат будет отозван, Ваши клиенты потеряют доверие, а Ваш бренд получит удар, от которого Вы, возможно, не сможете оправиться.
Почему безопасность закрытых ключей имеет решающее значение
Считайте, что Ваш закрытый ключ — это главный ключ к надежности Вашего программного обеспечения: он генерирует цифровые подписи, подтверждающие Вашу личность. Если кто-то украдет его, он сможет распространять вредоносный код, который будет выглядеть так, будто он исходит от Вас. Вам придется отозвать свой сертификат, заново подписать все, что Вы когда-либо выпускали, и надеяться, что Ваши клиенты заметят разницу, прежде чем установят зараженное ПО.
Традиционный подход к хранению ключей на жестких дисках или серверах сборки чреват неприятностями. Машины разработчиков взламывают. Серверы сборки могут быть взломаны. Даже зашифрованное хранение на обычном оборудовании оставляет ключи уязвимыми для извлечения.
Сертифицированные по стандарту FIPS 140-2 аппаратные решения
Аппаратные модули безопасности (HSM) решают эту проблему, храня закрытые ключи в устойчивом к взлому оборудовании. Являясь краеугольным камнем Вашей инфраструктуры PKI, HSM обеспечивают фундамент безопасности, необходимый для доверия на основе сертификатов. Эти устройства генерируют и используют ключи внутри системы, не подвергая их воздействию Вашу систему. Если попытаться физически взломать HSM, ключи будут уничтожены.
Сертификация FIPS 140-2 здесь имеет значение. Уровень 2 требует физической защиты от несанкционированного доступа, а уровень 3 добавляет активную защиту от несанкционированного доступа, которая обнуляет ключи при попытке взлома. Для большинства организаций уровень 2 обеспечивает надежную защиту. Эти аппаратные решения легко интегрируются в среды разработки Windows, macOS и Linux, защищая Ваши ключи независимо от платформы сборки. Правительственные и высокозащищенные приложения должны рассматривать уровень 3.
USB-токены предлагают портативную альтернативу HSM. Это FIPS-сертифицированное криптографическое оборудование, которое Вы можете носить с собой, добавляя физическую безопасность за счет владения. Основные центры сертификации поддерживают как HSM, так и реализацию USB-токенов для подписания сертификатов.
Однако политика ЦС различается, и Вам необходимо планировать ее с учетом этого. DigiCert и GoGetSSL выдают сертификаты подписи кода только на 1 год, и Вы можете использовать либо HSM, предоставляемый ЦС, либо свое собственное оборудование.
Sectigo (Comodo) предлагает многолетние сертификаты сроком до 3 лет, но с более строгими правилами. Если Вы выбираете 2- или 3-летний сертификат, Вы должны использовать свой собственный HSM. Оборудование, предоставляемое CA, доступно только для заказов на 1 год.
Хотите подписывать код? Вам нужен токен. Нет токена — нет подписи, даже если кто-то скомпрометирует всю Вашу сеть.
Реализуйте строгий контроль доступа к ключам подписи кода
Не всем в Вашей команде нужен доступ к производственным ключам подписи. На самом деле, большинство людей не должны его иметь.
Принцип прост: меньше людей с доступом — меньше векторов атак. Настройте контроль доступа на основе ролей (RBAC), который ограничивает права на подписание определенными ролями. Вашей команде QA не нужен доступ к подписи на производстве. Вашим младшим разработчикам, вероятно, тоже.
Создайте рабочие процессы утверждения, требующие нескольких подписей для производственных релизов. Один человек отправляет код на подписание, другой утверждает его, и только потом происходит фактическое подписание. Такое разделение обязанностей позволяет избежать ошибок и предотвратить инсайдерские угрозы.
Ведите полные журналы аудита. Записывайте, кто что подписал, когда подписал и с какой системы. В документе Совета по безопасности CA «Лучшие практики подписания кода» подчеркивается, что подробное ведение журналов важно для реагирования на инциденты и проведения судебной экспертизы. Когда что-то идет не так — а в конечном итоге это всегда происходит, — Вам необходимо точно знать, что именно произошло.
Физическая безопасность тоже имеет значение:
- Не оставляйте USB-жетоны на столах.
- Не храните учетные данные доступа к HSM в обычных текстовых файлах.
- Не пишите PIN-коды на липких записках.
Это кажется очевидным, но это распространенные проблемы, которые подрывают надежную безопасность.
Поставьте временную метку на Ваш код во время процесса подписания
Вот в чем проблема: срок действия сертификатов подписи кода истекает, как правило, через один-три года. Без временной маркировки Ваша подпись становится недействительной, когда срок действия сертификата истекает. Пользователи начинают видеть предупреждения о недоверенном программном обеспечении, хотя в Вашем коде ничего не изменилось.
Временная маркировка устраняет эту проблему, добавляя во время процесса подписания доверенную временную метку с сервера временных меток центра сертификации. Эта временная метка доказывает, что Вы подписали код, когда Ваш сертификат был еще действителен. Подпись остается надежной даже после того, как срок действия Вашего сертификата истечет или он будет отозван.
Подумайте об этом как о печати нотариуса с датой. Нотариус может уйти на пенсию или закрыть магазин, но его печать на Вашем документе от 2020 года все равно доказывает, что документ существовал и был заверен в 2020 году.
Технический процесс прост. Во время подписания Ваш инструмент обращается к серверу временных меток, управляемому Вашим центром сертификации. Сервер возвращает подписанную временную метку, которая встраивается в подпись Вашего кода. Когда пользователи проверяют Вашу подпись на любой платформе — Windows, macOS, Linux, iOS или Android — они проверяют как Ваш сертификат подписи, так и временную метку. Этот процесс проверки поддерживает целостность кода в течение долгого времени, даже когда срок действия сертификатов истекает, а стандарты безопасности меняются.
Это также экономит деньги. Без временной маркировки Вам пришлось бы заново подписывать все распространяемое программное обеспечение каждый раз, когда Вы обновляете сертификат. С временной маркировкой старые версии остаются надежными на неопределенный срок.
Сэкономьте 10% на SSL-сертификатах, сделав заказ в SSL Dragon сегодня!
Быстрая выдача, надежное шифрование, 99,99% доверия к браузерам, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10
Отделите среду подписания теста от среды подписания релиза
Ваша тестовая среда не должна использовать те же ключи подписи, что и рабочая. Когда-либо.
Тестовые сертификаты должны быть либо самоподписанными, либо выпущенными внутренним центром сертификации, который привязан к другому корню, чем Ваши рабочие сертификаты. Такое архитектурное разделение предотвращает принятие подписанного тестового кода за готовое к выпуску программное обеспечение.
Создайте отдельную инфраструктуру подписи для каждой среды. Тестовая подпись может быть более доступной и менее строгой — разработчикам необходимо быстро выполнять итерации. Но подписи в производственной среде должны быть строго заблокированы с помощью всех мер безопасности, которые мы уже обсуждали.
Четко маркируйте тестовые пакеты. Включите в названия файлов слова «TEST» или «BETA». Используйте различные идентификаторы продуктов. Сделайте невозможным случайное распространение подписанного тестового кода среди клиентов.
Контроль доступа тоже должен существенно отличаться. Разработчики могут иметь прямой доступ к тестовой подписи. Для подписи на производстве должны требоваться рабочие процессы утверждения и, возможно, совсем другие учетные данные.
Внедрите аутентификацию и проверку целостности кода перед подписанием
Подписание кода обеспечивает аутентификацию кода, подтверждая, кто опубликовал программу. Она не подтверждает, что программное обеспечение безопасно.
Это различие имеет значение, потому что Вы в конечном итоге несете ответственность за все, что подписываете, даже если Вы не написали всего этого. Подписывать код, который Вы не проверили, — это все равно что подписывать кредит, не проверив финансы заемщика.
Внедрите процессы представления и утверждения до того, как что-либо будет подписано. Пусть кто-нибудь проверяет то, что подписывается. Сравните код на Вашем сервере сборки с кодом в Вашем репозитории исходного кода. Убедитесь, что они полностью совпадают.
Взлом SolarWinds показал нам, что злоумышленники могут внедрять вредоносный код в конвейеры сборки. Эта атака подчеркнула важность безопасности цепочки поставок программного обеспечения — каждый компонент, зависимость и шаг сборки представляет собой потенциальный вектор атаки. Если Вы подписываете без проверки, Вы доверяете каждой части своей инфраструктуры и каждому фрагменту кода из внешних источников. Это не та ставка, которую Вы хотите сделать.
Установите автоматические проверки, где это возможно. Проверяйте цифровые подписи на коде, который разработчики вносят в Ваш репозиторий. Запустите инструменты статического анализа. Создавайте контрольные суммы утвержденных сборок и проверяйте их перед подписанием.
Записывайте все в журнал. Когда кто-то подает код на подпись, записывайте, что было подано, кто подал, кто одобрил и что было подписано. Такие журналы аудита очень важны при расследовании инцидентов.
Выполните проверку кода на вирусы перед подписанием
Подписание кода доказывает, что Вы опубликовали программу. Пользователи доверяют Вам в том, что Вы не будете публиковать вредоносные программы, но сертификаты подписания кода не подтверждают безопасность.
Это важно, когда Вы включаете код из внешних источников — библиотек с открытым исходным кодом, компонентов сторонних производителей, вкладов подрядчиков. Вы подписываете все это под своим именем.
Просканируйте все перед подписанием. По возможности используйте несколько антивирусных систем. Проверьте наличие известных сигнатур вредоносного ПО, подозрительных шаблонов и потенциальных уязвимостей. Это относится к тому, готовите ли Вы исполняемые файлы для Windows, приложения для macOS, пакеты для Linux или мобильные приложения для iOS и Android.
Поймав непреднамеренную вредоносную вставку до подписания, Вы защитите своих пользователей и свою репутацию. Обнаружение вредоносной вставки после того, как Вы распространили подписанное вредоносное ПО, означает отзыв сертификата, уведомление клиентов и контроль ущерба.
Сканирование занимает минимум времени в процессе сборки, но обеспечивает существенную защиту целостности и подлинности кода. Сделайте его обязательным, а не опциональным.
Ротация ключей и использование нескольких сертификатов
Не кладите все яйца в одну корзину. Использование одного сертификата подписи кода для всего создает единую точку отказа.
Подумайте о том, чтобы использовать разные сертификаты для разных линеек продуктов или основных релизов. Если Вы обнаружите недостаток безопасности в том, как управлялся один сертификат, Вам нужно будет отозвать только этот конкретный сертификат. Остальные Ваши продукты останутся надежными.
Регулярная ротация ключей также ограничивает риск. Если кто-то скомпрометировал Ваш ключ полгода назад, но с тех пор Вы перешли на новый сертификат, он не сможет подписать текущий код как Вы. Ущерб будет нанесен только старым версиям.
Некоторые организации присваивают уникальные сертификаты разным командам DevOps или веткам релизов. Это распределяет риск и облегчает расследование компрометации. Когда что-то идет не так, Вы точно знаете, какой сертификат был задействован и какие релизы затронуты.
Установите график ротации, который уравновешивает безопасность и эксплуатационные расходы. Для многих организаций подходит ежегодная или полугодовая ротация. В средах с высоким уровнем безопасности ротация может проводиться ежеквартально.
Отнеситесь к отзыву сертификата серьезно
Отзыв сертификата — это ядерный вариант, но иногда он необходим.
Немедленно отзовите ключ, если Ваш закрытый ключ скомпрометирован. Не ждите, пока Вы оцените ущерб. Не надейтесь, что никто не заметил. Отзовите ключ, уведомите свой центр сертификации и начните сдерживание.
Отзыв затрагивает весь код, подписанный этим сертификатом. Пользователи увидят предупреждения. Автоматические системы могут заблокировать установку. Именно поэтому маркировка по времени имеет решающее значение — она ограничивает ущерб, наносимый коду, подписанному после отметки времени, но до отзыва.
Тщательно отслеживайте свои сертификаты в инфраструктуре PKI. Знайте, где они находятся, кто имеет к ним доступ, когда истекает срок их действия и какой код был ими подписан. Управление жизненным циклом сертификатов приобретает решающее значение по мере расширения масштаба.
Сообщите о компрометации в Ваш центр сертификации в соответствии с их процедурами. Они помогут с отзывом сертификата и могут дать рекомендации по требованиям к уведомлению.
Наличие плана отзыва до того, как он Вам понадобится, сделает этот процесс менее хаотичным. Задокументируйте шаги, распределите обязанности и отработайте процедуру.
Использование сертификатов подписи кода расширенной валидации
Сертификаты подписи кода Extended Validation (EV) — это цифровые сертификаты X.509, обеспечивающие более высокую степень гарантии, чем стандартные сертификаты. Перед их выдачей центр сертификации проводит более тщательную проверку личности.
Сертификаты EV требуют аппаратного хранения, соответствующего стандартам FIPS 140-2 Level 2 или выше. Вы не можете получить EV-сертификат и хранить его на жестком диске. Эта обязательная аппаратная защита снижает риск компрометации ключей.
Большинство EV-сертификатов поставляются на USB-токенах с защитой PIN-кодом. Чтобы подписать код, Вам нужен и физический токен, и PIN-код. Такой двухфакторный подход затрудняет несанкционированное подписание.
Исследование Лаборатории инноваций в киберкриминалистике Georgia Tech показало, что исполняемые файлы с EV-подписями противостояли 99,99% протестированных фишинговых атак, по сравнению с 90% для стандартных подписей. Операционные системы, включая Windows, macOS и мобильные платформы, такие как iOS и Android, распознают EV-подписи и отображают пользователям индикаторы повышенного доверия. Повышенные индикаторы доверия и тщательная проверка дают ощутимую разницу.
Выбирайте сертификаты EV когда Вам необходимо максимальное доверие — флагманские продукты, широко распространенное программное обеспечение или приложения, работающие с конфиденциальными данными. Дополнительные затраты и накладные расходы на управление окупятся повышенным доверием и безопасностью.
Автоматизируйте и централизуйте управление подписанием кода
Ручное управление сертификатами не подходит для сред DevOps, в которых несколько команд постоянно отправляют код.
Решения для управления жизненным циклом сертификатов (CLM) централизуют контроль и интегрируются с конвейерами CI/CD. Такие платформы, как Sectigo Certificate Manager и AppViewX CERT+, предоставляют CLM-возможности корпоративного уровня, разработанные специально для рабочих процессов подписания кода. Разработчики получают доступ к самообслуживанию для создания цифровых подписей без прямого доступа к ключам. Команды безопасности обеспечивают видимость и соблюдение политик во всех действиях по подписанию.
Эти платформы отслеживают запасы сертификатов, сроки их действия и характер использования. Централизованное управление становится необходимым для обеспечения безопасности цепочки поставок программного обеспечения, особенно когда в Вашу кодовую базу вносят вклад несколько команд и подрядчиков. Они автоматизируют продление срока действия и упрощают аудит. Когда Вам нужно узнать, что было подписано тем или иным сертификатом, информация уже есть.
Интеграция с системами сборки означает, что разработчикам не нужно думать о деталях сертификата. Они отправляют код, конвейер автоматически подписывает его, используя соответствующий сертификат, и на выходе получается подписанный артефакт.
Заранее определенные рабочие процессы обеспечивают соблюдение Ваших политик безопасности. Код не может быть подписан без одобрения. Тестовые сертификаты не могут быть использованы в производстве. Разработчики одного подразделения не могут получить доступ к ключам подписи другого подразделения.
Централизация упрощает безопасность, не усложняя жизнь разработчикам. Это тот баланс, который Вам нужен — сильная безопасность, которая работает с Вашим процессом разработки, а не против него.
Защитите свою цепочку поставок программного обеспечения с помощью SSL Dragon
SSL Dragon предоставляет сертификаты подписи кода от ведущих центров сертификации, включая DigiCert и Sectigo. Нужна ли Вам стандартная подпись кода для внутренних приложений или EV-сертификаты для широко распространяемого программного обеспечения, мы поможем Вам выбрать правильное решение.
Наша команда понимает, с какими проблемами безопасности сталкиваются разработчики программного обеспечения. Мы поможем Вам выбрать сертификат, внедрить его и управлять им, чтобы Ваша инфраструктура подписи кода соответствовала лучшим отраслевым практикам.
Ознакомьтесь с сертификатами подписи кода SSL Dragon или свяжитесь с нашей командой, чтобы обсудить, какое решение лучше всего соответствует Вашим требованиям к разработке и безопасности программного обеспечения. Защитите свою цепочку поставок программного обеспечения — Ваши пользователи рассчитывают на это.
Сэкономьте 10% на SSL-сертификатах при заказе сегодня!
Быстрая выдача, надежное шифрование, 99,99% доверия к браузеру, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10
