imbasoft.ru

Не думали разнести это все на две базы? Одна база для ОКЗ, другая для ОКИ.
А то плучается, что журнал называется так, а начинка у журнала другая.

Не думали разнести это все на две базы? Одна база для ОКЗ, другая для ОКИ.
А то получается, что журнал называется так, а начинка у журнала другая.

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

а как у вас отражается учет КД или КИ, формируемой самими пользователями в фашей организации, но когда УЦ строронний и АИС тоже не ваша?

а как у вас отражается учет КД или КИ, формируемой самими пользователями в фашей организации, но когда УЦ строронний и АИС тоже не ваша?

В любых случаях схема одна и таже:
Акт Создания КД -> Акт передачи КД (в случае необходимости) -> Акты ввода в эксплуатацию (если систем несколько) -> Акты вывода из эксплуатации -> Акт уничтожения.

На данный момент в системе не учитывается принадлежность ИС к той или иной организации, поэтому они просто заводятся как ИС. В названии можно в скобках указать к какой организации принадлежит ИС, если это нужно.

УЦ обычно никакого отношения к ИС не имеют, за исключением случаев корпоративных УЦ, таких как ЦБ, биржа, казначейство. Для КЭП полномочия подписи для работы с ИС обычно прописываются путем добавления соответствующего OID в сертификат.

И еще, я так подозреваю, что вам интересен вопрос учета ключей формируемых по распределенной схеме, когда пользователь самостоятельно генерирует ключевую пару - закрытый ключ + запрос на сертификат (открытый ключ), а затем УЦ на запроса на сертификат выпускает непосредственно сам сертификат.

Все эта цепочка учитывается одним Актом создания КД в момент, когда УЦ выпускает сертификат. Отдельного учета закрытых ключей и запросов не проводится - это лишняя бюрократия.

imbasoft писал(а): ↑01 фев 2019, 13:20 И еще, я так подозреваю, что вам интересен вопрос учета ключей формируемых по распределенной схеме, когда пользователь самостоятельно генерирует ключевую пару - закрытый ключ + запрос на сертификат (открытый ключ), а затем УЦ на запроса на сертификат выпускает непосредственно сам сертификат.

Все эта цепочка учитывается одним Актом создания КД в момент, когда УЦ выпускает сертификат. Отдельного учета закрытых ключей и запросов не проводится - это лишняя бюрократия.

Добрый день уважаемые разработчики! Вот у нас (бюджетная гос.организация)положение как вы описали выше. Мы только начинаем учиться вести состояние наших дел по учету СКЗИ и КД.
Вопрос 1: В случае когда генерирует ключевую пару, запрос на сертификат сотрудник организации, в столбце 5 журнала учета КД, писать ФИО сотрудника нашего или все таки того, кто прислал нам сертификат, в нашем случае это Федеральное казначейство? По моей логике я должен писать своего сотрудника
Вопрос 2: Я правильно понимаю что необходимости заполнять столбец 7 и 8 нет, так как мы учитываем в данном случае жизненный цикл эксплуатации КИ? Когда сертификат пользователя закончился или сотрудник уволился, мне необходимо вывести из эксплуатации, уничтожить, а затем завести новый КД, я верно понимаю алгоритм моих действий?
Вопрос 3: В наименовании КД принципиально писать с\н сертификата или можно просто написать к примеру, УКЭП Иванова И.И? (спрашиваю в случае проверок, которых не было у нас)

Заранее спасибо за ваш труд!

Лучшее что можно сделать в начале - это провести аудит и найти все используемые криптоключи. Для этого можете воспользоваться методикой описанной в этой статье.

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

Теперь к ответам на вопросы.

(1). (2) - в Журнал КД ничего писать не надо. Данный отчет заполняется системой автоматически на основании введенных Актов. Когда вы запустите отчет, то он создаст файл, который может быть сохранен в том числе в Excel и в который вы сможете вносить любые правки, но эти правки будут только в этом файле, любой следующий отчет создаст новый файл, где ваших ручных правок уже не будет. Соответственно ручное заполнение файла не имеет практического смысла. Весь учет нужно вести Актами.

Не знаете как работать с программой? Делайте по аналогии с демонстрационной конфигурацией.

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

Добрый день, уважаемые разработчики.

Очень заинтересовались, разработанной Вами конфигурацией и в данный момент тестируем ее пред внедрением.

В связи с чем у нас возник вопрос по разграничению доступа для пользователей.
Дело в том, что у нас несколько филиалов, в каждом из которых есть свой системный администратор, ведущий учет СКЗИ, но всего один централизованный сервер 1С.
Возможно ли разграничить пользователей так, чтобы каждому специалисту было доступно редактирование и просмотр информации только по своему отдельному филиалу? Или же придется разворачивать отдельную базу под каждый отдельный филиал для разграничения прав?

Заранее спасибо за пояснение.

Добрый день.

Разграничение доступа по филиалам в текущей версии недоступно. Для решение вашей задачи необходимо создать базы для каждого филиала.