Использование токена при подключении к недоверенной среде
В Windows при использовании токенов на удаленном сервере ожидаемо возникает угроза несанкционированного использования токена в случае, если подключение идет к скомпрометированному (malicious) серверу. Суть в том, что на удаленный сервер экспортируется низкоуровневый интерфейс смар-карты, а не прикладной.
Нашлась статья "Attacking RDP from Inside..." и ссылка на CVE-2022-24533 на один из вариантов простого использования уязвимости (Attack Complexity: Low, Privileges Required: Low). В статье так же есть видео с демонстрацией эксплуатации уязвимости "Video 3: Smart Card Redirection".
В отличие от RDP, при использовании SSH экспортируется не низкоуровневый, а прикладной интерфейс аутентификации в форме "SSH Agent", что выглядит намного безопаснее для сценария подключения к скомпрометированному серверу. Конечное обслуживание запросов производится на клиентской машине, которая предполагается доверенной, а не на удаленном сервере. В утилите "ssh-add" есть ключ "-с" для инициации интерактивного запроса на использование ключа (Indicates that added identities should be subject to confirmation before being used for authentication). А для Putty есть, как минимум, pagent из состава Putty CAC с опцией запроса использования ключа.
В связи с этим вопрос.
Есть ли сейчас варианты (или планируется ли) повышения дуракоустойчивасти использования Рутокена в сценарии подключения к скомпрометированному серверу (в первую очередь, к Windows)?
Сейчас, на одном токене могут располагаться ключи от разных несвязанных систем, но все они защищены единственным PIN-кодом. Если принять стратегию, что под каждое применение должен быть свой отдельный токен, то это может привести к обратному эффекту по безопасности: ключи могут путаться, теряться, не вписываться в бюджет проекта и т.п.
Одной из идей была возможность назначить разные PIN-коды на разные ключи (возможно, тема "Локальные PIN" относится к этому). Т.е. что бы утечка PIN-кода не раскрывала всех секретов.
Так же был продукт Рутокен Touch, требующий физического подтверждения операции. Но, как я понял, он снят с производства.
Хотелось бы услышать мнение специалистов на этот счет.