В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

1С, БСП, DevOps и Архитектура

1443 membersпожаловаться на группу
2020 January 23

Г

Г🐈рри in 1С, БСП, DevOps и Архитектура
Александр Капралов
Никто не получает закрытый ключ для каждого расчетчика. Вот в компании несколько десятков расчетчиков, каждому свой закрытый ключ получать?
а какие альтернативы то есть? Можешь на терминальный сервер всех пустить, поставить там один сертификат с ключом - и они все "одним", на кого сертификат оформлен, будут подписывать и отправлять. Вариант хороший, в свете там тонких клиентов на рабочих местах? :)
источник
13:12пожаловаться#1

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
Я вижу себе это так.
Если остаемся в парадигме что 1 организация = 1 ключ, то нужно чтобы можно было ключ разместить на сервере 1С и компонента работала через сервер.
Либо дать возможность указать для каждого пользователя свой ключ. И тогда можно будет говорить что каждый пользователь должен оформить себе свою ЭЦП.
источник
13:12пожаловаться#2

Г

Г🐈рри in 1С, БСП, DevOps и Архитектура
Александр Капралов
Я вижу себе это так.
Если остаемся в парадигме что 1 организация = 1 ключ, то нужно чтобы можно было ключ разместить на сервере 1С и компонента работала через сервер.
Либо дать возможность указать для каждого пользователя свой ключ. И тогда можно будет говорить что каждый пользователь должен оформить себе свою ЭЦП.
все так. Про второй вариант - там же еще каждая эцп будет стоить отдельных денег.
источник
13:14пожаловаться#3

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
Просто текущее решение которое сделано в типовых - не масштабируется.
источник
13:14пожаловаться#4

A

Alexey Lab Sosnoviy in 1С, БСП, DevOps и Архитектура
Г🐈рри
все так. Про второй вариант - там же еще каждая эцп будет стоить отдельных денег.
Беда не столько в цене ключа, сколько в текучке. Их постоянно надо перевыпускать на новых сотрудников.
источник
13:15пожаловаться#5

VB

Vladimir Bondarevskiy in 1С, БСП, DevOps и Архитектура
Александр Капралов
Просто текущее решение которое сделано в типовых - не масштабируется.
Проблема здесь больше в органах, они не могут работать с более чем одним сертификатом
источник
13:16пожаловаться#6

SN

Shefer Nikita in 1С, БСП, DevOps и Архитектура
Александр Капралов
Просто текущее решение которое сделано в типовых - не масштабируется.
Масштабируется при помощи велосипеда и такой до матери.
Пришлось сделать доставку закрытых ключей пользователям напрямую в реестр при входе в ОС.
источник
13:16пожаловаться#7

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
Shefer Nikita
Масштабируется при помощи велосипеда и такой до матери.
Пришлось сделать доставку закрытых ключей пользователям напрямую в реестр при входе в ОС.
СБ против :)
источник
13:17пожаловаться#8

SN

Shefer Nikita in 1С, БСП, DevOps и Архитектура
Александр Капралов
СБ против :)
Наши посчитали затраты на ключи и сопровождение решили что так будет проще 😁
источник
13:17пожаловаться#9

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
Vladimir Bondarevskiy
Вообще, самый простой путь вынести ключи на сервер - сделать адаптер под API для ЭП в облаке. В этом случае там все будет работать
Я о таком варианте думал.
Но решил что может быть проще будет переделать на платформенное шифрование. Но внешняя компонента делит шифрованные данные на 4 части, а платформа ничего не делит. И если влезать в эти дебри, то там и до собственного механизма взаимодействия с ФСС недалеко.
источник
13:19пожаловаться#10

SN

Shefer Nikita in 1С, БСП, DevOps и Архитектура
Правда и клиенты только в RDP, на местах 1С нет.
Банк клиенты и все остальное на своих ключах с токенами локально.
источник
13:19пожаловаться#11

ВЕ

Виктор Ермаков in 1С, БСП, DevOps и Архитектура
Александр Капралов
Никто не получает закрытый ключ для каждого расчетчика. Вот в компании несколько десятков расчетчиков, каждому свой закрытый ключ получать?
Каждому пользователю ставить эл подпись на машину
источник
13:44пожаловаться#12

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
Виктор Ермаков
Каждому пользователю ставить эл подпись на машину
Нельзя чужой сертификат ставить каждому пользователю на машину :)
источник
13:45пожаловаться#13

ВЕ

Виктор Ермаков in 1С, БСП, DevOps и Архитектура
Не каждому,  а тому кому можно.  У нас все автоматизированно,  есть база по управлению сертификатами в группе юл
источник
13:48пожаловаться#14

ВЕ

Виктор Ермаков in 1С, БСП, DevOps и Архитектура
1с овская
источник
13:48пожаловаться#15

ВЕ

Виктор Ермаков in 1С, БСП, DevOps и Архитектура
Там говоришь кому какой серт,  и о чудеса серт доставлен пользователю
источник
13:49пожаловаться#16

ВЕ

Виктор Ермаков in 1С, БСП, DevOps и Архитектура
А если ему не положен сертификат,  и он сам его на комп поставил,  то серт удаляется
источник
13:50пожаловаться#17

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
СБ против того, чтобы сертификат закрытого ключа конкретного человека ставился на конечные компьютеры пользователей.
источник
13:52пожаловаться#18

ДК

Денис Кириллов in 1С, БСП, DevOps и Архитектура
Александр Капралов
СБ против того, чтобы сертификат закрытого ключа конкретного человека ставился на конечные компьютеры пользователей.
А что мешает выдать сотрудникам железные КЭП?
источник
13:56пожаловаться#19

АК

Александр Капралов in 1С, БСП, DevOps и Архитектура
Денис Кириллов
А что мешает выдать сотрудникам железные КЭП?
Типовой механизм обмена с ФСС подразумевает, что к одной организации привязывается 1 ключ.
источник
13:56пожаловаться#20