Comments 87
Как технология USB over IP позволила людям забыть о расстоянии
...всего за каких-то несчастных $900!
А сколько можно USB-устройств подключить к девайсу с OpenWRT? Ну в смысле на реальных роутерах с OpenWRT, и без хабов.
Как я понимаю смысл всяких DistKontrol — 16+ устройств + готовый интерфейс управления.
Так и не понял зачем это нужно. Я думал насчёт HID-устройств (мышь, клавиатура...), устройств хранения данных, веб-камер. В случае с этими устройствами USB over IP является бесполезной технологией. Могли бы вы привести примеры устройств, использование USB over IP с которыми даёт какие-то реальные преимущества? В моём понимании USB-устройства - это про портативность, а вы предлагаете "пихать что-то в какой-то концентратор", и указываете централизованность как один из плюсов. Хотя, возможно, что это я чего-то очевидного не вижу.
Но ведь… USB-ключи тем и хороши, что без физического обладания им, невозможно ничего сделать, где он требуется.
Тссссс, это древняя война, один придумали usb токены, а другие их передают друг другу, имеют один на всю бухгалтерию и ещё бэкап у айтишников. Вот такая вот информационная безопасность.
Тут как бы дело в том, что при использовании ЭЦП не получается реализовать обычные сценарии делегирования полномочий, как в случае с бумажными доверенностями. Получил ЭЦП юрлица - всё, у тебя по факту полномочия генерального директора, неважно для какой конкретно задачи тебе она понадобилась. И отследить, для чего эта ЭЦП на флэшке была получившим её товарищем применена и сколько раз, никак. А лично руководитель, даже в не очень большой компании, всё и всегда подписывать не может.
Поэтому разграничивать полномочия на использование ЭЦП на другом уровне, например, контролируя доступ к такому вот устройству, куда они централизованно воткнуты, - вполне себе повышает безопасность. Можно дать одноразовый доступ, доступ с подтверждением и т.п. Если, конечно, именно разграничивать, мониторить и т.п., а не тупо расшарить на всю контору :)
У юрлица вроде есть своя печать, может быть это её аналог?
Только необходимость ставить и вообще иметь печать для юр. лиц несколько лет назад из законодательства успешно выпилили, а ЭЦП юр. лица живее всех живых.
Хотя, казалось бы, у государства есть ЕГРЮЛ, из данных которого однозначно следует, какое физ. лицо в конкретный момент времени уполномочено без доверенности представлять какое юр. лицо. А для остальных ничто не мешает доверенности подписывать той же ЭЦП... но нет.
"ЭЦП юрлица" это что-то странное.
Так да. ЭЦП - это "аналог собственноручной подписи". Но собственноручная подпись есть только у директора, а ЭЦП ещё и у условного ООО.
И условному менеджеру Васе, который на условной площадке эл. торгов подаёт по десять заявок в день, надо авторизоваться на этой площадке именно с ЭЦП ООО, а не со своей личной. Отсюда и весь этот сюр с флэшками.
Иногда работает по-другому. Например, юрист может документы в суд подписать своей личной ЭЦП, приложив скан доверенности, и подать через my.arbitr.ru. Но в основном не так.
"ЭЦП юрлица" это что-то странное. ЭЦП это аналог физической подписи. Физическую подпись ставит конкретный человек. У каждого человека своя ЭЦП (и может быть не одна).
Насколько я помню, по закону об электроподписи, юрлицу не может быть выдала квалифицированная электрическая подпись.
Но зато может быть выдана на физлицо-руководителя, позволяющая подписывать от имени организации (руководитель же лицо, имеющее право действовать от имени организации без доверенности) и в какой-то области применения ("для бухотчётности", "для торгов" (причём разная цена в зависимости от числа площадок), "для документооборота" и т.п.).
После чего обычно геморроиться с доверенностями и платой за подписи на других лиц в СМБ влом (крупняки и ГОСы с бюджетниками разве что - потому что одних заставляет СБ, а других Казначейство), и подпись руководителя используют как "подпись организации".
Знаю случай, когда бухгалтер долгое время подписывала бумажные документы за генерального директора его подписью (по его же просьбе, т.к. лично он физически не успевал).
Однажды он пришел в банк, чтобы подписать какой-то важный договор, где нужно было личное присутствие, а ему сказали, что не примут подписанные им документы, т.к. его подпись совсем не похожа на ту, которой он обычно им всё подписывал
Это не единичный случай - в моём прошлом личный секретарь руководителя подписывала за него почти все документы, при чём подпись в её исполнении (практически?) полностью совпадала с подписью в паспорте, а вот когда пришлось лично в банке какие-то документы получать, тот самый руководитель изрядно намучался, чтобы воспроизвести свою же подпись.
Что уж там - даже моя подпись в 10 случаях из 10 будет разной... но парадоксально совпадать с подписью одного из моих начальников далёкого прошлого. Году так, в 98-м довелось расписываться в зарплатной ведомости... а подпись уже стоит! Ну, думаю, сейчас буду бучу поднимать - ан, нет, у шефа, который за 2 человека передо мной стоял в очереди, пусто в графе... пришлось его звать в кассу, чтобы он и за себя расписался.
Интересно, планы по машиночитаемым доверенностям
( https://www.nalog.gov.ru/rn77/related_activities/el_doc/use_electronic_sign/#t4 например) что-то изменят? (там идея что подпись юрлица ладно уж — на директора можно а все остальные должные подпись физика + доверенность)
На самом деле, даже сейчас формально ничто не мешает подписать доверку ЭЦП директора / юр. лица, а собственно документы - ЭЦП доверенного лица. Только что доверенность будет не машиночитаемая и наличие полномочий придётся проверять вручную - но это другая проблема.
И в ряде случаев (см. мой коммент выше по ветке про суды) это так и работает. Но в основном таки требуется ЭЦП юр. лица на любой чих.
Гос-во о вас позаботилось (см. 476-ФЗ пп. 2 п.1 ст. 17.2 и п. 2 ст. 17.3). Разъяснения нормальным языком можно почитать например тут.
Если совсем не хочется читать:
Сейчас. Есть УКЭП#1 Иванова Ивана Ивановича как физлица. Ей можно... например продать квартиру Иванова Ивана Ивановича, или декларацию в УФНС подать за физика Иванова Ивана Ивановича.
Есть УКЭП#2 (выдаваемая в любом УЦ страны) всё на того же физика Иванова И.И. но в спец обученом поле есть инфа, что он менеджер ООО "Рога и Копыта", а заодно в некотором наборе других (пролоббированных) полей мммм... урощённо говоря на каких ресурсах можно использовать эту ЭЦП. Если на площадке самые_лучшие_госторги_рф.ру Иванов И.И. от лица ООО "Рога и Копыта" захочет забашлять пару шагающих экскаваторов для ФГУП "Ритуал", то он не может использовать для этого УКЭП#1 ни при каких обстоятельствах. Вместо этого при регистрации на самые_лучшие_госторги_рф.ру он подгрузит сканы всех документов ООО "Рога и Копыта" (уставы, выписки и т.д.) + скан доверенности (с синей печатью), что гендир ООО "Рога и Копыта" разрешает ему продавать экскаваторы от имени компании.
Но это ведь геморрой!? Поэтому 146% тендерных отделов компаний этой страны (если они участвуют в чуть больше чем 1 тендере в год) получают (экспортируемую) ЭЦП на первое лицо компании на рутокене. Дальше копия грузится в реестр M$ Windows АРМ тендерных, бухгалтеров, юристов, менеджеров (которым нужны разные госпорталы) и т.д. Это аналог рисования например менеджером например на накладных подписи первого лица.
Побочка: все люди, использующие копию ЭЦП могут зайти за директора везде, где можно зайти через Госуслуги: посмотреть всю его недвижку, счета за границей, чем и когда он болел, you name it. А заодно продать эту самую его недвижимость. Или загнать компанию в чёрный список (или неслабо просадить по деньгам), снизив цену шагающего экскаватора на 99.9% от начальной цены аукциона.
Чего хотят сделать? (спойлер: упразднить УКЭП#2) будут УЦ, одобренные ФНС (на самом деле, вероятно, в течении года ими станут примерно все существующие УЦ), куда 1 лицо компании должно приехать ЛИЧНО (да, сейчас, личное присутствие в случае УКЭП#2 из примера выше зависит от моральных устоев конкретного УЦ) и получить токен с НЕИЗВЛЕКАЕМОЙ подписью. Назовём её УКЭП#3. Я не вникал сможет ли первое лицо использовать её например для личных госуслуг, но, скорее всего, да. Дальше создадут реестр электронных доверенностей, куда можно засылать подписанную УКЭП#3 доверку (непонятно XML ли, PDF ли, JPG со сканом бумажной доверенности - это пока не очень работает) в которой говорится, что первое лицо ООО "Рога и Копыта" доверяет Иванову Ивану Ивановичу. После этого на площадке самые_лучшие_госторги_рф.ру, сайте Суда или ЭДО Иванов И.И. сможет делать что-то от имени ООО "Рога и Копыта", используя УКЭП#1
Справедливости ради: использовать УКЭП#3 также можно будет на тех же торгах, госпорталах и проч, но только если пользователи будут готовы целый день бегать и отбирать у друг друга токен с ЭЦП первого лица.
Опять же в случае аналогового мира это эквивалентно тому, что в УПД написано Иванов И.И. по доверенности + приложена копия этой доверенности. И теперь мы не можем продать особняк гендира. А если на торгах Иванов И.И. понизит стоимость экскаватора на пару миллиардов рублей, и компания будет вынуждена поставить технику на этих условиях, то после судебного разбирательства между ООО "Рога и Копыта" и Ивановым И.И., дети, внуки и правнуки первого должны будут по почке детям, внукам и правнукам владельцев ООО "Рога и Копыта".
Простите за многобукаф: я застал ЖЖ и динозавров.
Если оставить в стороне иронию, то вы путаете обладание ключом и, например, необходимость того, что он воткнут в порт конкретной рабочей станции. Удаленный доступ к ключу не означает автоматически возможность совместного использования ключа одновременно - это все еще может быть эксклюзивное использование, просто ключ и рабочая станция могут быть разнесены в пространстве, не более.
Удаленный доступ к ключу не означает автоматически возможность совместного использования ключа одновременно
А если не автоматически? ;) Есть принципиальная невозможность совместного использования?
До какой степени "принципиальная"? Это зависит от того, как устроен обмен между ключом и остальными элементами защиты. Например, если используется аналог сессионного ключа.
Более верный вопрос должен звучать так: "Есть ли виды аппаратных ключей, которые становятся значительно более уязвимы благодаря этой технологии, и если есть, то какие". Ответ, очевидно, что такие виды есть - например, тупой ID. Частный случай - всякие DS1990A.
Несмотря на заверения минцифры ещё несколько лет назад, что вот-вот будет возможно использовать сертификаты, выпущенные различными УЦ, в различных цифровых системах, до сих пор это по факту не осуществилось (к справедливости, зато и нет единого корневого сертификата для всех УЦ, контролируемого ФСБ). В ЭДО, "Честном знаке" и системах бухгалтерской и налоговой отчётности ситуация немного лучше, что реализовано благодаря более-менее универсальному набору полномочий выпускаемых сертификатов (к примеру: сертификат выдан УЦ "СКБ Контур", пользователь работает в системе "Астрал").
А вот система делегирования полномочий реализуется на уровне системы, но не типовых наборов прав сертификата, поэтому неудобства зависят, как правило, от выбора системы. Нет единого набора прав и полномочий, например, в системе ФС РАР: нельзя просто делегировать выпущенному сертификату дополнительный набор полномочий сертификата, а необходимо выпускать новый. По этой причине когда-то я сам, на заре первых внедрений РАР, использовал программный usb-over-ip для токена, чтобы можно было использовать токен JaCarta с неэкспортируемым сертификатом на разных рабочих местах.
Плюс ко всему, персональный сертификат для каждого сотрудника – это накладно, хотя даже у малого бизнеса есть потребность в делегировании полномочий: часто оказывается так, что токен с необходимым сертификатом, с которым в теории можно хоть закрыть предприятие, хоть взять кредит, "где-то у бухгалтера лежит", а чаще всего путешествует с бухгалтером и порой даже теряется.
А пока не сделали полноценное делегирование, иногда приходится делегировать временные полные права как раз через usb-over-ip.
Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования USB over IP ключом может воспользоваться кто угодно, кто сможет подключиться. То есть "физическое обладание ключом" заменяется на "задача контроля доступа". И тут весь вопрос в том, как это будет реализовано. Можно конечно удариться в аниме и соединить сервер с физическим ключом и клиент отдельной витой парой по типу точка-точка с авторизацией по физическому ключу... В теории так сделать можно, и это будет супер надёжно и безопасно, но мы же понимаем, что ни кто так делать не будет. А как только мы упрощаем способ подключения, то мы автоматом понижаем безопасность решения. То есть грубо говоря если у нас авторизация просто по паролю, а доступ есть не только из локальной сети, а через интернет, то это конечно удобно для пользователей, но считай, что никакого ЭЦП у тебя нет, а есть только пароль. Так как любой кто знает пароль может воспользоваться твоей ЭЦП. Если проводить аналогию, это всё равно, что поставить дорогую железную дверь, но ключ хранить под ковриком.
И обрати внимание. Я не говорю, что это априори плохо. Как ни странно формальное снижение безопасности по факту может даже увеличивать безопасность. Приведу что имеется в виду. Предположим у нас есть дверь на склад. Огромная сейфовая дверь, способная выдержать прямое попадание из РПГ. С электронным замком с биометрией и одноразовыми паролями подписанными лично ЭЦП директора. Круто? Круто! Но через неделю в двери будет лежать деревянный брусочек чтобы дверь не закрывалась. И внезапно оказывается, что китайская картонная дверь с авторизацией по обычным NFC меткам безопасней, так как люди не будут лениться её закрывать.
Так, что я не говорю, что USB over IP это однозначно плохо. Просто его использование снижает безопасность и поэтому теперь уже ты должен придумать как организовать контроль доступа так, чтобы компенсировать это снижение безопасности.
Я не знаю, зачем вы мне решили читать лекцию по основам безопасности, будучи только поверхностно знакомым с вопросом и приводя неуместные аналогии.
Для архитектуры безопасности аппаратных ключей доступ к ним через USB вообще - это уже работа через неподконтрольный канал, который с точки зрения осуществления атаки типа mitm (частным случаем которой является добавление произвольного числа участников диалога с ключом) только чуть сложнее, чем USB over IP.
Потому безопасный с этой точки зрения ключ должен иметь средства, которые позволяют удостовериться, что диалог ведётся с одним и тем же приложением (или с несколькими, но с известным ограниченным числом).
Если же вы представляете себе архитектуру безопасного ключа, как тупой идентификатор и проверку наличия устройства, его содержащего, на шине USB - я вас поздравляю, вы отстали где-то на сорок лет от того, как это делается сейчас.
Пример из жизни: изъяли сервер + usb-ключ.
Стоимость нового ключа около 90000 рублей.
Если бы ключи были в другом офисе\дома у директора\на другом континенте - компания продолжила бы работу практически без перерыва, со "вчерашнего" бекапа. А так пришлось заказывать экстренно новый ключ и ждать несколько дней доставку.
Вы пытаетесь реши административную проблему изъятия сервера техническими средствами. А если дома у директора устроят маски-шоу, то лучше бы ключ был в сервере.
Если у Вас изъяли usb-ключ, то его формально можно считать скомпрометированным и это нужно фиксировать документально с отзывом сертификата или приостановкой его действия... Используя бэкап изъятого ключа потом будет сложно доказать кто реально пользовался вашим сертификатом, Вы или не честные сотрудники которые изъяли usb-ключ
Вот вам пример. Есть купленная за 3000000 система с USB-ключом. Позволяет развернуть один инстанс. На вопрос: "как для отказоустрйчивости развернуть дублирующую ноду во втором цоде" предложили купить ща 3ляма еще один инстанс. Естественно обошлись одним ключом с выносом в отдельный сервис. Осталась проблема в том что ключ физически только в одном цоде - нет защиты от разрушения но с этим уже можно жить.
Это очень узкая задача, хотя она и нужна многим. На самом же деле, есть множество legacy и просто специальных устройств, у которых есть только USB, как сравнительно быстрый интерфейс, выбранный разработчиками. Добавление аппаратной поддержки сети до сравнительно недавнего времени было не то чтобы легкой задачей, на самом деле. Вот например: https://www.winradio.com/home/receivers.htm - только серия G6x имеет сетевой интерфейс.
пробросить USB-ключ, к примеру, внутрь облака
Да даже один ключ в 2 облака!
ЭЦП те же самые не хранить у сотрудников
а подписывать за сотрудников все самим
Какие ЭЦП и зачем?
А от какие-то донглы можно хранить. Но дешевле их эмулировать
Один из возможных сценариев это физическое хранение HASP ключей с лицензиями на софт в отдельном месте.
Например на моей прошлой работе у нас был ЦОД в одном городе и офисы с небольшими серверными в других городах. В ЦОДе крутились все виртуальные и не очень сервера, всяческие там К+, 1С и т.п. Договора заключались в разных городах и почему-то было принято решение HASP ключи к ним хранить в них же. Т.е. USB ключ был установлен в одном городе, а сервера с соответствующим софтом были в другом.
Подключение программатора и удалённая отладка устройства. У меня несколько случаев было, когда нужен USBIP (вот как, оказывается, называется такая технология). Неудобно каждый раз взбираться и протягивать кабель с программатором к устройству, которому ещё и ограничили движения из-за кабеля.
Так и не понял зачем это нужно. Я думал насчёт HID-устройств (мышь, клавиатура...), устройств хранения данных, веб-камер. В случае с этими устройствами USB over IP является бесполезной технологией. Могли бы вы привести примеры устройств, использование USB over IP с которыми даёт какие-то реальные преимущества?
Да те же камеры уже давно со встроенным IP умеют делать...
А вот когда надо в облаке или в онпремиз виртуализации запустить в виртуалке софт с ключом защиты... Порой вариантов, отличных от USB over IP просто нет.
В моем случае, я отлаживал устройство с GPS, которое нормально работает только за окном. Чтобы не тянуть 10 метров usb кабеля, просто кинул на подоконник ноутбук, а уже отладку вел в уютном кресле, используя VirtualHere.
Практическая задача, можно сказать боль. Нужно прокинуть в виртуалки hasp ключи для специфического софта. Втыкаешь напрямую флешки, дело то. А потом, когда нужно мигрировать витуалку - начинаются танцы и бег в серверную перетыкать флешку из одного сервера в другой. Сабж помог бы избавиться от этого ручного труда и необходимости физического присутствия в серверной при vMotion таких виртуалок.
В Hyper-V научились USB-устройства пробрасывать в виртуалки с хоста?
Так что такой приём еще не во всякой системе виртуализации сработает, плюс если кластер - то при миграции ВМ на вторую ноду и выключения первой, - воткнутые в первую ноду ключи будут недоступны после миграции ВМ.
Hyper-V не пользуюсь) зачем, если есть vmware?
При выключении первой ноды с ключами, прокинутыми на вторую - да, ключи отвалятся. Потому и говорю, что нужно физически переткнуть ключ во вторую после миграции.
Hyper-V не пользуюсь) зачем, если есть vmware?
Если у вас всё равно винда - то кластер "из коробки" доступен без дополнительно платы, и бэкап можно делать. Хотя если у вас "всё равно платный вариант vmware" - то да, разницы нет.
При выключении первой ноды с ключами, прокинутыми на вторую - да, ключи отвалятся. Потому и говорю, что нужно физически переткнуть ключ во вторую после миграции.
Ну а в случае железяки для ключей USB-over-IP - не отвалится ничто, а вероятность отключения этой железки ниже, чем сервера.
Вот как-бы так и живут...
Токены доступа всякие не таскать с собой.
Либо иметь возможность иметь на хостинге в том же Selectel виртуалку с виндой внутри которой надо использовать VPN с токеном.
Ну и если надо пробрасывать с рабочего места куда то еще / нет желания покупать железку но все равно есть комп с кучей портов — есть программные решения — USB Network gate и VirtualHere
я сейчас тестирую для удаленного контроля usb-rs232(uart) устройств, конкретно контроллеры gsm doorhan и домовой ip (в нашем городе 2g gsm сети на передачу данных не работают практически, как оказалось)
у меня есть несколько клиентов которые заняты в одной сфере бизнеса - бухаутсорс. их 1 клиент=1-2 (редко 3) ключа. итого у тебя есть десятки ключей, которые нужны разным бухам работающим локально и удаленно на терминалке, где установлено все то, что они подписывают этими ключами. и часто в течение дня нужны около десятка ключей, а во время отчетного периода нужны больше половины, а во время годового отчета нужны все ключи.
сбросить все подписи на 1 ключ невозможно принципиально ибо 1 разработчик крипты предусматривает такую возможность только во время генерации серта, 2 ключ не твоя собственность, ты не можешь ей распоряжаться как тебе вздумается, если клиент уйдет ты обязан ему вернуть ключ в рабочем состоянии с рабочим сертом, чтобы он воткнул это к себе в комп, с помощью тп установил и настроил ПО и у него все работало, 3 банки слегка против такой мешанины)
железка позволяет прокинуть ключ в облако, где у клиента установлена 1с, которая в свою очередь для отправки некоторых данных требует сначала их подписать этим самым сертом.
итого стоит в сети вот такая железка на 64 порта, в ней стоят одновременно все ключи всех клиентов. админ не дурит себе голову регулярными зависаниями ПО которое умеет пробрасывать ключи и его чисткой, порты в пк/ноутах не раздалбываются перевтыканием ключей, бухи не дурят себе голову поисками нужного, потому что в среднем на одного буха 10 ключей, а портов в локальном пк/ноуте далеко не столько, директор не дурит себе голову организационными вопросами как забрать ключи у удаленного работника в другом городе, если он заболел, в отпуске и тд. ВСЕ ключи находятся только в офисе, после появления железки это стало законом. клиент когда приезжает за ключом для генерации нового серта, то секретарь тупо достает из железки ключ согласно распечатки об их расположении и туда же возвращает потом, а только потом сообщает админу об этом, чтобы он установил новый серт.
стоит ли это 2к денег? однозначно.
На серваке куда подключается бух в пользователя копируется ключ с токена и никакого гимора и путаницы нет
https://habr.com/ru/company/selectel/blog/587522/comments/#comment_23674854
чтобы не повторяться. вы - яркий пример из первого предложения.
цитирую разработчиков "скопировать запись о сертификате НЕВОЗМОЖНО, она попадает туда только в момент генерации запроса на сертификат и может быть только удалена. под это даже не разрабатывались инструменты"
если есть желание я дам комплект софта и прокину ключ к вам на пк через интернет. скопируете с него запись о серте на другой ТАКОЙ ЖЕ ключ - с меня ящик пива. а на серваке криптопровайдер не умеет искать в принципе.
доступно?
У меня был кейс - есть маленькая, но важная софтина, которая взаимодействует с GSM модемом. Так как софтина маленькая - крутится она в виртуалке внутри весьма большого кластера, жирновато под нее отдельный физический сервер иметь. Единственный способ надежно прокинуть в нее модем - USB over IP. Я правда софтварные методы использовал и модем был воткнут в какую-то дешевую железку где был поднят линукс с нужной софтиной для прокидывая USB.
Например, сервер 1с держать в виртуалке на HA-кластере. Без сабжа (технология, не железка) он не может уехать на другую ноду, поскольку привязан к той, в которую физически воткнут юэсбический ключ.
Так и не понял зачем это нужно.Последовательные порты, УСО, например.
Я думал насчёт HID-устройств (мышь, клавиатура...), устройств хранения данных, веб-камер.Это только малая часть возможных устройств.
это костыль, чтобы поправить другой костыль
Если идет интенсивная двусторонная коммуникация, то latency даже в несколько миллисекунд делает эту штуку бесполезной.
Я как-то раз писал кастомный протокол, чтобы быстро прокручивать цикл запрос/ответ, без отправки данных через интернет. А в usbip такую фичу можно реализовать?
Существуют железки с поддержкой USB3.0, гигабитного ethernet и изохронного режима USB — например https://3dnews.ru/969181 (там еще и тесты есть, диск тестировали)
Как всегда в рекламе все хорошо.
На практике головная боль.
Половину того, что должны делать драйвера USBoverIP возможно Вы знаете как JetDirect . Висит демон, слушает 910n порт, пришедшие данные пересылает на устройство, ответ от него в сеть.
Казалось бы с другой стороны нужно только это оформить как виртуальное устройство .
Но тут возникают проблемы маршрутизации и детекта обрыва. Нужно периодически гонят пинги (по другому обрыв не поймать).
В общем часть описанную выше писать и отлаживать самому (собирать из опенсорса) то еще удовольствие, ну а платные решения можете поискать сами и глянуть на порядок цен.
Из универсальных решений можно глянуть в сторону построенных на https://ru.wikipedia.org/wiki/MQTT
А так чаще реализуют частные решения . Как пример то, что напридумывали для ККМ (облачные кассы).
По поводу железки
Для проброса лицензий она хороша. Но весьма странно что за столько лет авторы не додумались до иных сценариев (потому что основной их сценарий это один ключ подключается к одному клиенту на одном пк) и не сделали нормальную работу в терминальном режиме, когда все ключи подключаются к одному пк, но видимы только конкретным юзерам. Про интеграцию с АД вообще молчу - учетки считывает, на их основе создает свои локальные, которые в терминалке та-дааам, не работают, потому что ты или подключаешь все ключи под одним логин-пасом или идешь лесом, т.е. в терминалке тупо невозможно подключить 10 ключей под разными логинами и привязать подключение ключа логон-скриптом к юзеру, чтобы все ключи были по умолчанию отключены, а подключался 1 нужный только когда юзер залогинился, а потом отключался.
Эта схема, наверное, только сверхразумам доступна для прогнозирования. Это же так трудно предположить, что сисадмин захочет иметь доменную авторизацию в железке и привязку к юзеру.
В итоге, изза того что криптопровайдер не расчитан разрабами для работы с десятками ключей одновременно, приходится задачами в планировщике периодически перезапускать порты, чтобы отвалившиеся в крипте ключи снова вернулись. Но, как описал выше в другом коменте схему работы, плюсы все таки перевешивают отсутствие нормальной работы с терминалкой и доменом
Если речь идёт об электроподписях, то их можно пробрасывать в терминальном режиме как правило. А если о ключах защиты - то терминал не поможет. Или брать другую схему лицензирования - ради одного рабочего места не всегда целесообразно...
бич айтишников и сисадминов из рф, что в соцсетях, что на хабре - они думают что все используют криптопро, рутокен и прочие подобные продукт и делают соответствующие выводы, что их опыт такой же как у других.
я из беларуси, о чем в профиле специально указано. криптопровайдер у нас единственный, "терминальные" ключи ввели только относительно недавно, пара лет гдето, +за замену с обычного на такой надо платить (попробуйте объяснить вашему новому клиенту, почему он должен своими деньгами и временем оплачивать ваши локальные хотелки, до которых он ни каким боком). и ключ при этом вставляется именно в комп с которого производится подключение, только так и никак иначе - он определяется как смарткарта. т.е. появляется проблема, которую я озвучил немного выше - удаленный сотрудник должен иметь набор ключей у себя локально. а если учесть что они работают по схеме домашний пк-впн-виртуалка в офисе-терминалка то ключ чисто теоретически уже не пробросится в терминалку.
про лицензирование согласен, сам всегда ною клиентам про прогнозирование развития и выбор схемы исходя из этого, а не из текущих потребностей.
ПС иногда доводится работать с клиентами, которые являются филиалом российских фирм. так вот московские админы частенько не горят желанием разбираться в нашей кухне. им проще заплатить денег мне, чтобы я сделал как надо, что собственно и происходит. притом что я самостоятельно при нужде разобрался и с российскими наборами по и ключей, а одно время потрогал и грузинскую.
я из беларуси, о чем в профиле специально указано. криптопровайдер у нас единственный
не совсем понял, в чём у вас проблема - токен "обычный" не прикидывается смарт-картой, и потому его нельзя пробросить в терминал, нужно брать относительно недавно появившийся "новый" тип токена, который смарт-картой умеет прикидываться?
они работают по схеме домашний пк-впн-виртуалка в офисе-терминалка
то есть у них двойной терминал получается - первый с домашнего компа на виртуалку в офисе, а второй - с этой виртуалки на терминальный сервер?
да, именно так.
обычный самый распространенный токен работает только локально или с пробросом софтом или железом по айпи. терминальный токен определяется как смарткарта и пробрасывается именно рдп соединением, а не сам по себе или криптопровайдером (на него ставится свой драйвер, если в настройках рдп не будет галочки о пробросе смарткарт, то он не пробросится. не помню нужно ли чтобы драйвер стоял с двух сторон. имею такой ключ только на двух небольших серверах, давно последний раз его настраивал для работы, в прошлом году как минимум). само собой что по умолчанию тебе выдают обычный токен, а терминальный по отдельному запросу и само собой любой из них не бесплатно. т.е. я не могу взять пачку терминальных токенов, напихать их в пк с полусотней портов и чтобы они были доступны на терминалке, тупо потому что они этого не умеют. а с ПО или железкой из статьи могу это сделать с обычными токенами.
да, у них двойной терминал по сути. в офисе у каждого настроено его собственное рабочее место (есть только удаленные сотрудники, есть только офисные, есть переменные) либо на железе, либо на виртуалке. все виртуалки крутятся на рабочих пк по схеме 1+1 - один сотрудник за пк и 1 на виртуалке на этом же пк. если в офис приезжает тот, кто работает на виртуалке, то он садится за любой пк, подключается к своей виртуалке и работает. такая схема дешевле чем полноценный терминальный сервер на серверной платформе+виртуалка в любой момент может быть поднята на любом доступном железе из шаблона, а настройки профиля раздаются политиками (что опять же проще и быстрее чем сетевой профиль), благо их там немного: закладки, ярлыки, сетевая шара. если офисный сотрудник захотел домой на пару дней то он точно также подключается к своему рабочему пк - все равно за ним скорее всего никто не работает. все посещения отмечаются в общем яндекс-календаре всеми сотрудниками. чаще всего в офисе 1 человек или вообще никого, только пк работают, т.е. конечная цель почти достигнута) рабочие процессы ведутся централизованно в трелло через расшаренные доски.
схема такая потому, что моя задача по подключению заключается в том, чтобы выслать сотруднику инструкцию по настройке впн и все. а где он работает, с какого пк или ноута, из какого города и тд меня уже мало волнует (есть такие которые ездят по рб по родне или на дачу или еще куда и работают при этом. директор опять же не против). и также я не дурю себе голову переносимыми профилями. и еще одна немаловажная причина - все подключения рдп, внутренние и внешние забиты у каждого сотрудника на его пк в рдп менеджер, с сохранением паролей. а я не хочу подключать на непонятный мне комп сетевую шару, ставить менеджер с полным списком клиентов и тд. поэтому все подключения к терминалке только с локальных компов (собственно это и настроено в АД), без вариантов.
все довольны, все понимают в какой ситуации что им делать, где что взять для подключения куда надо, схема легко масштабируется на любое количество работников и клиентов. мои задачи это завести нового юзера под клиента или работника, доустановить то, что не делается политиками при первом входе, ну и пара мелких задач типа не печатает или установить новый серт. ну и бэкапы проверять само собой, хотя вим с его surebackup-ом тоже оставляет немного работы)
Внедрял такое в 2010-2011. И Linux usbip и платные windows и аппаратные девайсы.
Со всеми была одна проблема. Иногда высокий latency tcp/ip стека нарушал взаимодействие клиента и сервера. Примерно раз в месяц приходилось хотя бы один ключ вытаскивать/вставлять из разъема (их было много разных).
Как сейчас с этим ?
В статье не указана проблема, что даже реальное USB может не работать, в компьютере, если в него залогиниться по RDP сессии. Только физический доступ в компьютер. Так что USB в облаке, а компьютер...
Большое спасибо за статью.
Есть где на практике применить, ибо как заметили выше, прикидывать USB в ESXi можно, но не совсем удобно в случае миграции и т.д.
Описанный в статье способ видимо должен помочь.
Можно ли один usb-ключ прокидывать каждые N секунд на виртуалки поочереди? И таким образом вместо одной машины получить несколько машин с ПО защищённым usb-ключом.
можно попробовать.
в теории на виртуалке надо написать скрипт, который подключится к железке, подключит устройство к себе, подождет эн секунд, отключит его. далее по таймауту такой же скрипт запускается на другой виртуалке. при такой схеме критично стабильно работающий сервер времени.
http://distkontrol.ru/upload/RukovodstvoUSBoverIPv4.pdf 89-91стр
другой вопрос как на это будет реагировать ПО. 1с например проверяет ключ только при запуске платформы/конфиги. во время работы он не требуется. но вариантов работы другого ПО множество. т.е. надо экспериментировать.
Есть ли опыт проброс GSM-usb модема в Linux?
Не совсем понял как в ПО Selectel прослеживается VirtualHere, она там и есть?
Это идеальный, сферический костыль в вакууме. Ни для чего кроме этих самых ключей оно по хорошему неприменимо. А сама концепция ключа физического в физическом контроле над оным, а не овер айпи...
А я токены с сертификатами телепортирую https://youtu.be/jpe_gtYhe5U
Как технология USB over IP позволила людям забыть о расстоянии