Как стать автором
Обновить
16
0.2

Пользователь

Отправить сообщение

Четкого ответа, «как хранить 50 лет» – не нашел. Кто «не в теме», вследствие «размытой подачи» материала в статье, - вообще не поймет "за что зацепиться" по этому вопросу.

Рассмотренный в статье электронный архив я бы разбил на три совсем Разных архива:

- архив копий. Это сканирование и документы без электронной подписи. Для этой категории должно быть название: «электронный архив КОПИЙ бухгалтерских документов».  

- архив документов с ЭП, но не подлинников.

- архив подлинников (документов с ЭП).

Второй архив отличается от третьего тем, что архив хранит документы с электронной подписью, но это не архив подлинников. Например, это архив документов, полученных из Диадок (основное место их хранения Диадок). Тут не нужно думать об обеспечении юридической значимости на годы – этим пусть озаботится Диадок (это их бизнес).

В третьем «архив подлинников» проблема обеспечения юридической значимости на 50 лет (или 150 лет, – не принципиально) выступает «в полный рост». Если в этом «своем» архиве, Вы хоть на один день «проспали» и срок действия сертификата проверки подписи закончился, то безвозвратно «карета превратится в тыкву», т.е. юридическая значимость документа-подлинника будет потеряна безвозвратно, см.     

3 Основной «подводный камень» КЭДО и иного ЭДО

https://habr.com/ru/post/703388/

Документ есть, но подпись "протухла" (прямые доказательства подлинности подписи утеряны) и вернуть ее обратно - уже невозможно: придется заморозить "как есть" и хранить уже в таком виде, а если потребуется разбирательства (в суде например), то уже будут использованы лишь "косвенные доказательства".

 

Короткий и Четкий ответ: как хранить 50 и более лет документы с обеспечением юридической значимости. Всего два более-менее «приличных» варианта (всякие там «доверенные стороны или доверенные архивы – не рассматриваем»):

1 CADES-T (TSP) + сертификат проверки подписи на 15 лет;

2 CADES-XL и выше (TSP+OCSP), т.е. усовершенствованная ЭП.

Для обоих вариантов – требуется перештамповка через 15 лет (главное не «проспать»). Физику «материального носителя» - не рассматриваем.

Заметим, что есть специальные подходы к электронным архивам бухгалтерских отчетов и первичных документов, например, доверенные архивы в рамках 2346-У Банка России (ярлычок с контрольной суммой DVD подписывается рукописно). Собственно, если увеличить срок хранения документов по 2346-У, например, втрое, то ничего из этого Указания более менять не потребуется, т.к. «заверяющая» рукописная подпись «вечная».  

Метазнания = знания о знаниях.

Знания об одном и том же «ручном» процессе:

- в регламенте;

- в голове у исполнителя процесса (при этом он, зная, как нужно сделать, делает иначе).

Знания об одном и том же «автоматическом» процессе:

- код (возможно даже с комментариями), понятный только машине;

- рабочая документация на программу (она может не синхронизироваться с кодом, т.е. может не совпадать).

Еще есть знания о том же процессе, но со «стороны» - это как окружение полагает, как работает процесс.

Полагаю, что для «ручных» процессов «Явные знания» могут быть в трех «хранилищах»:

- знания «из мира идей»;

- регламент по процессу;

- «голова» исполнителя в процессе (его понимание алгоритма и бизнес-правил).

Рассмотрим простой процесс \ алгоритм. Знания «из мира идей» - это в целом образ знаний (образ стула обычно всем понятен). Это абстракция, но она есть, хоть обычно не полная и не подробная.

В реальном процессе образ знаний проецируется на «мир вещей»: часть знаний «упакована» в регламенте по процессу. Часть знаний этого регламента «подгружено» в «оперативно-запоминающее устройство» исполнителя – человека (память человека). Если вдруг что-то он подзабыл, то может снова почитать регламент и догрузить. Обычно текстовые регламенты – не отличаются логичностью (последовательности изложения), имеют «много букв», сложно найти что нужно и некогда читать. Есть графические регламенты, но там тоже много проблем.

В итоге исполнитель - человек только частично владеет информацией, спроецированной из «объективной составляющей». Сотни тысяч (а может и миллионы) страниц регламентов одной крупной гос-компании, особенно из отрасли сильно «за регламентированной», например, госбанки, имеет основную цель не путеводителя по процессу для его исполнителей. Регламенты по 100-300 страниц нужны обычно для двух задач: а) найти крайнего если «что-то пошло не так» б) предъявить регулятору при проверке: при этом, такой «регламент для регулятора» содержит много фраз из документов самого регулятора, но понять, как устроен процесс – почти невозможно.

Мы говорим о «процессных регламентах», где описаны шаги процесса. Верхнеуровневые документы, типа политика и положение – фиксируют некие общие концепты, которые часто не позволяют определить, а что конкретно нужно делать.    

Часто работает такой принцип: большой начальник говорит малому начальнику: «делай как хочешь (не важен сам процесс), но выдай хороший результат». Тут вообще знания о процессе могут замыкаться внутри подразделения малого начальника и не выходить наружу. Неявные знания могут быть вообще только в голове одного исполнителя. Большому начальнику «если что» проще на рынке взять нового малого, если предыдущий не справился.  

Такой способ, часто достаточно эффективен и на новый экземпляр процесса может применяться логика (алгоритм) отличная от предыдущего экземпляра процесса. В таком случае, если по роли меняются исполнители, то вмете с ними часто и меняются алгоритмы процессов. Отсутствуют накладные расходы (обычно они значительные) на формализацию процесса.   

Иное дело со знаниями в ПО. Автоматические операции в ИТ-системах подразумевают: когда человек нажал кнопку «выполнить», то происходит набор автоматических операций. Алгоритм процесса зашит в код ПО. Главное: если нет сбоев, то исполнение будет ровно как указано в коде. Правда сам пользователь обычно не знает, что же конкретно происходит по «нажатой кнопке»: эксплуатационная документация также объемна и может содержать другую логику, чем реально запрограммирована. Современный BPMN помогает, но не очень (в Low Code в реальности оказывается "много кода", и сам BPMS - ограниченного применения).   

Фактически артефакты «из мира вещей» для ПО – это рабочая (не эксплуатационная) документация. Есть Process Mining, но он тоже пока не позволяет рядовому пользователю получить информацию: «как работает его процесс».

С одной стороны, четкий регламент и «ни шагу сторону» - это часто хорошо:

- в ручном процессе, исполнитель имеет четкую и подробную инструкцию;

- в автоматическом, весь рабочий день сводится к нажатию утром «одной большой Красной кнопки «Сделать работу»;

- в автоматизированном: жми весь день кнопку «далее».

Человечество обязано своим существованием некоторым людям, которые не доверились четкому регламенту, а смогли «капнуть глубже» (хотя подобное промедление могло привести к «не успели с ответным ударом»): Уильям Бассетт, Станислав Петров. 

 

Итого: исполнитель-человек, может действовать:

А) «существуют явные знания в регламенте» - «перенос явных знаний в голову»: т.е. выполнить так «как задумано», причем объективно-формализовано задумано;  

Б) «существуют явные знания в регламенте» - «перенос явных в голову лишь частично»: в регламенте все есть, но исполнитель выполнил их не так, при этом считая, что работал по регламенту (субъективные явные знания в голове не соответствуют объективным, т.е. формализованным);

В) «существуют явные знания в регламенте» - «в голове совсем иное»: зная, как нужно сделать, исполнитель сделал иначе (Уильям, Станислав), «подчерпнув» знания «из мира идей»;

Г) «не существуют / скудные явные знания в регламенте», т.е. регламент не четкий или «много букв» (иголка в стоге сена). Тут также несколько сценариев.

Проблема, как документировать сложные процессы «ручная составляющая + автоматическая», включая что происходит «по нажатию кнопки», - сегодня большая и нерешенная проблема. Обычно даже нет оценки «качества» регламентов, один из подходов: попробуйте по «пухлому» текстовому нарисовать схему процесса, например, EPC. Часто такие текстовые регламенты – всего лишь «обязательная» макулатура и назвать их «явными знаниями» - скорее всего, - не верно. Когда-нибудь появится ПО, которое сможет по текстовому регламенту автоматом построить схему процесса и тогда загрузив в него эти тонны обязательной нормативной «макулатуры» станет понятно их реальное качество.  

«Корень зла» тут во многом в том, что компании не
публикуют свои процессы и не обмениваются по ним информацией.

Кнопка "подписать" где будет? Как в MS сделать получится? Открыть КриптоАРМ и в нем подписать файл можно без myoffice. Можете ссылку дать, но не на криптоАРМ, а на то как файл подписать из myoffice?

Также про кнопку "проверить".

Есть ли где-нибудь кнопочка "подписать" (и проверить) электронной подписью? Как это, например, в MS.

наши решения совместимы с программой КриптоАРМ

Что это значит? Речь про открепляемую и (или) не открепляемую подпись?

Мы также наблюдаем, что МойОфис наращивает свою экспертизу через механизм технологического партнерства с другими участниками рынка посредством плотной работы с производителями операционных систем, СЭД

С какими-то СЭД есть (ведется) интеграция? Можно ли подписывать документы средствами МойОфис? Какими стандартами?

наступает 01/01/2050.

Зачем так далеко? Этот момент наступает на следующий день после окончания действия сертификата. УЦ спокойно себе работает еще годами, но по истекшим сертификатам уже не направляет «crl-ы».

Не обязан, т.к. статус сертификата – просрочен. Если Вы ранее не позаботились с доказательствами действительности подписи после окончания срока действия сертификата (например, заранее усовершенствовав подпись), то на руках у Вас будет «тыква» уже на следующий день. И доказать для «усиленной КЭП\НЭП» (не усовершенствованной), что это еще вчера «была карета» - будет очень сложно или невозможно.

Насколько знаю, многие аккредитованные УЦ хранят у себя статус (что не был отозван или отозван тогда-то) просроченного сертификата (выданного этим УЦ),

но не направляют по ним crl-ы (СОСы):

Важное свойство СОС — он содержит информацию только о сертификатах, срок действия которых не истёк.

https://ru.wikipedia.org/wiki/Certificate_Revocation_List

УЦ хранят просроченные сертификаты для того, чтобы ПОТОМ и дополнительно оказывать платные услуги по подтверждению подлинности подписи на основе выданных им сертификата (у УЦ можно заказать «независимую» экспертизу), но это всего лишь дополнительная «бизнес-услуга», которой к тому же может и не быть.   

Я конечно добавил в текст уточнение в виде (усиленная КЭП/НЭП), но из контекста это следовало.

Одной OCSP-квитанция также не достаточно. Собственно все эти моменты раскрыты в обсуждаемой статье.

Также:

Юридическая значимость документов по истечению срока действия ЭП

https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=15510

Кто это готов будет покупать?

У FLOSS разные подходы. Иногда он вообще не подразумевает монетизацию.

Если нужна монетизация, то могут быть направления: платная поддержка внедрения (центр компетенций), расширение "Community Edition" до "Professional Edition" и др.

"Community Edition" обычно создает краудсорсинговую экосистему в целях более быстрого развития платформы.

Так вроде Вы и ответили на свой же вопрос:

На мой взгляд, можно придерживаться следующих правил. Если это внутрикорпоративный документооборот, где ведется строгий контроль за компьютерами, то достаточно использовать формат подписи CAdes-BES, которая включает в себя помимо математической подписи в соответствии с ГОСТ Р 34.10-2012 и время формирования подписи (поле «Текущее время»). Если жесткого контроля за компьютерами нет (каждый на своем компьютере может выставить любое время), и важна дата подписания документа, то необходимо использовать формат CAdes-T или CAdes-XLT1. 

https://habr.com/ru/post/457288/

Только нужно учесть, что:

А) нет юридически значимого «ведется строгий контроль за компьютерами», во всяком случае применительно к КЭДО. Полагаю, что в суде время подписания только по CADES-BES доказать будет проблематично, даже с таким обещанием \ заявлением "строгий контроль";

Б) только CADES-T при просроченном сертификате проверки подписи – не поможет, т.к. не будет информации, был ли отозван сертификат, а если был, то до подписания или после.

Ваша аналогия с бумажными документами станет точная, если мы не можем установить момент ухода должностного лица с должности: он мог подписать и до и после.

А выдумывать его специально ради кадровых документов, как мне кажется, довольно странно.

Тем не менее, недавно его государство выдумало. Полагаю, что уже сотни тысяч сотрудников подписывают кадровые документы с помощью ЭП.

Ответ видимо идентичен как для: Какой смысл было апгрейдить Трудовой кодекс статьями 21.1 – 22.3, введенными ФЗ от 22.11.2021 N 377?

Образование в России — даже не требующее капитальных затрат обучение программированию — следует за общим уровнем развития страны и при общем низком уровне зарплат в отрасли с годами по-моему становится только хуже. Можно ли еще как-то переломить данную тенденцию или детей уже однозначно настала пора отправлять на обучение в Штаты?

Про «Образование в России — даже не требующее капитальных затрат» и вариант как «как-то переломить данную тенденцию» см. Социальный труд и открытое проектирование. Введение
Какие бесплатные каталогизаторы посоветуете для ведение библиотеки нормативных документов компании? Фактически хранятся скан — копии документов (считай фото).
Или каталогизатор для хранения (учета) просто электронных книг, но тогда с возможностью добавления новых справочников-классификаторов. Хотелось бы доступ через web (корпоративный портал).
12 ...
30

Информация

В рейтинге
2 663-й
Зарегистрирован
Активность