Комментарии 10
Понятно, что таким способом почти все, кто такое может себе позволить по тем или иным причинам, пробрасывают КСКПЭП (ЭЦП) физического лица, со вставленным токеном в аппаратный USB-IP сервером. Значит нужно менять часть 4 статьи 10 ФЗ-63 "Об ЭП": "Владелец сертификата обязан обеспечивать конфиденциальность ключа электронной подписи и несет предусмотренную федеральным законом ответственность за последствия его компрометации.", чтобы только владелец ЭП имел к ней доступ, а не обслуживающий персонал ЦОДа, уборщицы и другие допущенные в машзал лица.
ЭЦП, скорее резонансный и знакомый многим пример использования технологии USBoverIP - оставим такой способ на совесть и страх , пользующих.
Статья же больше для тех , кому достались в наследство аппаратные лицензии софта, давно уже живущего на виртуальных машинах.
По поводу:
чтобы только владелец ЭП имел к ней доступ, а не обслуживающий персонал ЦОДа, уборщицы и другие допущенные в машзал лица
Возможно стоит предусмотреть отдельные стойки с максимальной защитой от присутствия лишних лиц, если такая необходимость все же возникнет? Правда скорее всего это повлечет доп издержки и доп штат.
Согласен, что использование ЭЦП - это частный случай использования и вполне можно обойтись наложенными средствами физической защиты от доступа. Тут больше интересен вопрос, как например защищен PIN-код, который передается по сети до USBoverIP устройства.
Для аппаратных ключей защиты ПО использование USBoverIP было для нас очень актуально в своё время.
Сама утилита usbip, к сожалению, свой траффик не шифрует и нужно его чем то маркировать и заворачивать в туннель (еще тема для размышлений вечером под лампой вместо книги)- и в случае с ключами доступа - временная, почти бесплатная мера.
К тому же -есть аппаратные хабы, которые умеют в ss/tls и стоят они относительно недорого.
Представляю следующий вариант использования. Есть две серверные, географически разнесенные. Есть ключи, ЕГАИС, 1с и т.д. Можно ли реализовать такой вариант на случай мини тотального blackout: (ИБП + МиниПК + debian + USB хаб + MikroTik SXT) + ipsec VPN до резервной серверной? Стабильно ли будет работать связка через VPN тоннель? Можно ли забирать разные ключи разными VM?
При достаточном резервировании входящих каналов (2 роутера с каждой стороны с vrrp, мультиван так же с обеих и тд и тп) по всем прикидкам работать будет стабильно. Хотя тесты провести бы не повредило и нужно учесть что USB хаб будет самым узким местом. Была идея реализовать двухнодовую архитектуру на малинках с переключением хаба и , возможно, когда нибудь эта идея получит реализацию в виде Pet-проекта.
Можно ли забирать разные ключи разными VM?
ВМ забирают только те ключи, которые указаны в конфиге клиента, установленного на самих ВМ - хоть по ВМ на каждый ключ создавайте.
Мы использовали устройство аналогичное малинке в серверной, чтобы прикладывать ключ в плате модуля доверенной загрузки (МДЗ), чтобы сотруднику ночью не ехать, т.к. требования к использования данной плате в определенном сервере были, а другова способа, как механического с помощью другой платы, мы не придумали.
sudo modprobe usbip-coresudo modprobe usbip-hostsudo modprobe vhci-hcd
к сожалению не всегда работает. много где в дистрах выкошено нафиг в дефолтовых ядрах, так что здесь аккуратнее
Дистр - как корабль - подбирается под воду, что его окружает (в нашем случае под утилиту usbip). Благо вариантов не мерено появилось за годы с рождения linux и подбор ограничивается только временем и желанием. Если, например, регламент ИБ запрещает использовать сборок, в которых не выкошено - сразу ищем аппаратное сертифицированное решение.
И снова USB-IP — сервер теперь с автобиндом и детачем и сам подхватит ключ клиент