Электронная подпись без риска: защита ключей, удобство сотрудников и безопасность цепочки поставок

Электронная подпись стала повседневным инструментом бизнеса, а при удалённой работе ключи и сертификаты — одной из главных целей атак. Надёжность обеспечивается на простых вещах: генерация и хранение ключей в «железе», быстрый отзыв сертификатов при инцидентах, понятные правила аутентификации и прозрачный контроль операций.

Редакция CISOCLUB поговорила с Павлом Анфимовым, заместителем директора по управлению продуктами Компании «Актив», о том, как выстроить эту основу без лишних сложностей: USB-токены, смарт-карты, HSM и TPM, адаптивная аутентификация (PIN и биометрия), раздельное хранение и подписание, CRL/OCSP и поведенческий анализ. Обсудили безопасные мобильные и кроссплатформенные сценарии (стандартные API и нативный код для критичных операций), управление жизненным циклом PKI с напоминаниями и кабинетами самообслуживания, а также практики защиты цепочки поставок ПО на принципах Zero Trust.

Какие подходы помогают защитить ключи электронной подписи от кражи или подмены при массовом дистанционном доступе?

Ключевым принципом защиты ключей электронной подписи является их создание и хранение на защищенных аппаратных устройствах, не позволяющих эти ключи скопировать или извлечь. К таким устройствам относятся USB-токены и смарт-карты, HSM и TPM-модули.

Каждый из этих типов устройств имеет свои особенности использования:

• Смарт-карты и USB-токены являются относительно недорогими персональными устройствами. Они обеспечивают высокую степень мобильности и защиту PIN-кода от перебора.
• HSM (Hardware Security Module) предназначен для массовых операций и обеспечивает высокую производительность. Относительная дороговизна компенсируется уровнем защиты.
• TPM (Trusted Platform Module) защищает ключи на уровне конкретного ПК или сервера. В данном случае устройство подписания является не отдельным от ПК, а доступ к модулю зависит от механизмов аутентификации на нем в ОС. Как правило, это логин-пароль и биометрия.

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

• использовать уникальный PIN-код к ключевому носителю и не использовать PIN-код по умолчанию от производителя;
• хранить ключи подписи и осуществлять подписание на разных устройствах (ключ храним на токене, а подписываем ЭП на ПК);
• использовать для аутентификации на устройстве биометрический фактор, такой как вектор отпечатка пальца или лица, что повышает безопасность операции, т.к. исключает возможность передачи устройства сторонним лицам;
• иметь налаженный процесс отзыва сертификатов в УЦ для выпуска ключей ЭП, который при компрометации ключа (утере токена, увольнении сотрудника и пр.) позволит немедленно внести сертификат в списки отзыва (CRL — Certificate Revocation List) или проверить его через онлайн-протоколы (OCSP — Online Certificate Status Protocol). Без этого механизма украденный ключ можно использовать до истечения срока действия его сертификата, что может занять годы. Это не предотвращает кражу, но минимизирует ущерб;
• обеспечивать с помощью прикладных сервисов ПО логирование и анализ операций с ключами ЭП, например, успешными и неуспешными попытками подписания и доступа к системам. Наиболее эффективным является поведенческий анализ операций, отслеживающий такие события как: подписание документов вне рабочего времени или из необычного местоположения; аномально большое количество подписываемых документов или документов одного типа; попытки подписать значимые платежи неизвестным или новым контрагентам; многократный неверный ввод PIN-кода.

Как совмещать требования законодательства о защите информации с удобством сотрудников при работе с ЭП и токенами?

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

Мобильность и универсальность ключевых хранилищ

Удобные средства электронной подписи должны быть мобильными. Среди ключевых носителей сейчас доступны сверхтонкие и компактные форм-факторы (кольца, брелоки, стикеры), способные бесконтактно работать на ПК и на смартфоне/планшете по каналу NFC. Это позволяет сотрудникам подписывать документы на своем мобильном устройстве без проводов, переходников и лишних действий.

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

Адаптивные подходы к аутентификации

Для различных бизнес-сценариев следует применять адаптивный уровень аутентификации:

• для ключевых хранилищ без биометрического сканера, для операций с низким риском для информационной безопасности (например, подписания внутренней отчетности) допустима одноразовая аутентификация пользователя по PIN-коду в начале сессии. Для каждой последующей операции подписания внутри приложения требуется биометрическая аутентификация (Face ID или Touch ID). Это предоставляет доступ к временно сохраненному PIN-коду, что избавляет от необходимости его постоянного ввода. Для ключевых хранилищ со встроенным сканером процесс становится еще удобнее: доступ к ключевой информации предоставляется исключительно по биометрической информации для каждой операции. Это обеспечивает баланс между безопасностью и удобством, не нарушая принцип аутентификации.

• для высокорисковых операций (финансовые документы, внешние договоры) при каждом подписании требуется многофакторная аутентификация. В этом сценарии биометрия (Face ID/Touch ID) может использоваться для входа в приложение, но для каждого подписания система в обязательном порядке запрашивает PIN-код от ключевого носителя. Для моделей со встроенным биометрическим сканером система дополнительно запрашивает биометрический фактор (например, отпечаток пальца), обеспечивая уже трехфакторную аутентификацию непосредственно на уровне “железа”. Это помогает создать максимальный уровень защиты для критически важных действий.

«Невидимое» программное обеспечение

Включение всех необходимых настроек для подписания ЭП в целевое ПО или настройка их администратором (в том числе, с помощью автонастройщиков).

Глубокое взаимодействие ИБ и UX/UI-команд

Вовлечение специалиста по ИБ в качестве полноправного участника в работу проектной команды на этапе проектирования и логики интерфейса ПО.

Управление жизненным циклом ключей и сертификатов (PKI)

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

Как обеспечить безопасную работу электронной подписи в мобильных и кроссплатформенных средах?

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

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

Для хранения закрытых ключей ЭП целесообразно использовать аппаратные ключевые носители (смарт-карты, USB-токены). Эти устройства обеспечивают доступность, мобильность, отчуждаемость от ПК/мобильных устройств. Они защищают доступ с помощью уникального PIN-кода, при переборе которого (brute force) мошенником в случае кражи или утери токена или смарт-карты происходит блокировка доступа к ключевой информации. Все криптографические операции (подпись, шифрование) выполняются внутри защищенного чипа такого аппаратного носителя. Закрытый ключ никогда не копируется в оперативную память компьютера или телефона.

Хранение нераспределенного ключа ЭП целиком в виде файла на мобильном устройстве делает память смартфона или планшета уязвимой для сложных атак, особенно на root- или jailbreak- устройствах. Secure Element в айфонах или гаджетах на Android имеют критические ограничения:

• не обеспечен фактор владения, так как устройство хранения является и устройством подписания;
• доступ к ключам, защищенным TPM, в рамках операционной системы зависит от ее механизмов аутентификации — как правило, это связка логин-пароль и биометрия.
• Secure Element российской разработки и с отечественными алгоритмами попросту не существует.

Также следует обеспечить защиту процесса подписания ЭП. Пользователь должен видеть на экране именно те данные, которые он подписывает.

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

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

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

Обязательно нужно обеспечить непрерывный мониторинг и анализ аномалий — операции с ключами ЭП (успешные и неуспешные попытки подписания, доступ к системам) должны логироваться и анализироваться в режиме реального времени. И, наконец, потребуется отлаженный механизм отзыва сертификатов в случае утери или компрометации ключа электронной подписи. Все эти задачи лучше поручить системе управления жизненным циклом ключевых носителей, ключевых документов, сертификатов электронной подписи, СЗИ и СКЗИ.

Как развивается защита цепочек поставок ПО и сервисов, когда ключи и сертификаты становятся целью атак?

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

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

Решением этих проблем является применение аппаратных защищенных хранилищ и введение политики строго контроля доступа

Аппаратные защищенные хранилища, такие как модули HSM, USB-токены и смарт-карты, TPM-модули физически защищают закрытые ключи от извлечения и копирования. Все операции подписи происходят внутри таких устройств, и ключ никогда не покидает защищенную среду.

Для осуществления строгого контроля доступа необходимо определить, какие артефакты (скажем, только определенные версии ПО), какой пользователь (конкретный сотрудник или система CI/CD) и при каких условиях (например, после успешного прохождения тестов) могут быть подписаны. Такой контроль реализуется через системы управления привилегированным доступом (PAM) при заданных политиках подписания. Все эти подходы ставят перед собой задачу построить сквозной Zero Trust для защиты цепочек поставок. Это означает, что каждый шаг — от написания кода разработчиком до развертывания ПО — должен быть проверяемым и аутентифицированным.