Четкого ответа, «как хранить 50 лет» – не нашел. Кто «не в теме», вследствие «размытой подачи» материала в статье, - вообще не поймет "за что зацепиться" по этому вопросу.
Рассмотренный в статье электронный архив я бы разбил на три совсем Разных архива:
- архив копий. Это сканирование и документы без электронной подписи. Для этой категории должно быть название: «электронный архив КОПИЙ бухгалтерских документов».
- архив документов с ЭП, но не подлинников.
- архив подлинников (документов с ЭП).
Второй архив отличается от третьего тем, что архив хранит документы с электронной подписью, но это не архив подлинников. Например, это архив документов, полученных из Диадок (основное место их хранения Диадок). Тут не нужно думать об обеспечении юридической значимости на годы – этим пусть озаботится Диадок (это их бизнес).
В третьем «архив подлинников» проблема обеспечения юридической значимости на 50 лет (или 150 лет, – не принципиально) выступает «в полный рост». Если в этом «своем» архиве, Вы хоть на один день «проспали» и срок действия сертификата проверки подписи закончился, то безвозвратно «карета превратится в тыкву», т.е. юридическая значимость документа-подлинника будет потеряна безвозвратно, см.
Документ есть, но подпись "протухла" (прямые доказательства подлинности подписи утеряны) и вернуть ее обратно - уже невозможно: придется заморозить "как есть" и хранить уже в таком виде, а если потребуется разбирательства (в суде например), то уже будут использованы лишь "косвенные доказательства".
Короткий и Четкий ответ: как хранить 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?
Мы также наблюдаем, что МойОфис наращивает свою экспертизу через механизм технологического партнерства с другими участниками рынка посредством плотной работы с производителями операционных систем, СЭД
С какими-то СЭД есть (ведется) интеграция? Можно ли подписывать документы средствами МойОфис? Какими стандартами?
Зачем так далеко? Этот момент наступает на следующий день после окончания действия сертификата. УЦ спокойно себе работает еще годами, но по истекшим сертификатам уже не направляет «crl-ы».
Не обязан, т.к. статус сертификата – просрочен. Если Вы ранее не позаботились с доказательствами действительности подписи после окончания срока действия сертификата (например, заранее усовершенствовав подпись), то на руках у Вас будет «тыква» уже на следующий день. И доказать для «усиленной КЭП\НЭП» (не усовершенствованной), что это еще вчера «была карета» - будет очень сложно или невозможно.
Насколько знаю, многие аккредитованные УЦ хранят у себя статус (что не был отозван или отозван тогда-то) просроченного сертификата (выданного этим УЦ),
но не направляют по ним crl-ы (СОСы):
Важное свойство СОС — он содержит информацию только о сертификатах, срок действия которых не истёк.
УЦ хранят просроченные сертификаты для того, чтобы ПОТОМ и дополнительно оказывать платные услуги по подтверждению подлинности подписи на основе выданных им сертификата (у УЦ можно заказать «независимую» экспертизу), но это всего лишь дополнительная «бизнес-услуга», которой к тому же может и не быть.
У FLOSS разные подходы. Иногда он вообще не подразумевает монетизацию.
Если нужна монетизация, то могут быть направления: платная поддержка внедрения (центр компетенций), расширение "Community Edition" до "Professional Edition" и др.
"Community Edition" обычно создает краудсорсинговую экосистему в целях более быстрого развития платформы.
На мой взгляд, можно придерживаться следующих правил. Если это внутрикорпоративный документооборот, где ведется строгий контроль за компьютерами, то достаточно использовать формат подписи CAdes-BES, которая включает в себя помимо математической подписи в соответствии с ГОСТ Р 34.10-2012 и время формирования подписи (поле «Текущее время»). Если жесткого контроля за компьютерами нет (каждый на своем компьютере может выставить любое время), и важна дата подписания документа, то необходимо использовать формат CAdes-T или CAdes-XLT1.
А) нет юридически значимого «ведется строгий контроль за компьютерами», во всяком случае применительно к КЭДО. Полагаю, что в суде время подписания только по CADES-BES доказать будет проблематично, даже с таким обещанием \ заявлением "строгий контроль";
Б) только CADES-T при просроченном сертификате проверки подписи – не поможет, т.к. не будет информации, был ли отозван сертификат, а если был, то до подписания или после.
Ваша аналогия с бумажными документами станет точная, если мы не можем установить момент ухода должностного лица с должности: он мог подписать и до и после.
Образование в России — даже не требующее капитальных затрат обучение программированию — следует за общим уровнем развития страны и при общем низком уровне зарплат в отрасли с годами по-моему становится только хуже. Можно ли еще как-то переломить данную тенденцию или детей уже однозначно настала пора отправлять на обучение в Штаты?
Какие бесплатные каталогизаторы посоветуете для ведение библиотеки нормативных документов компании? Фактически хранятся скан — копии документов (считай фото).
Или каталогизатор для хранения (учета) просто электронных книг, но тогда с возможностью добавления новых справочников-классификаторов. Хотелось бы доступ через web (корпоративный портал).
Четкого ответа, «как хранить 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.
Что это значит? Речь про открепляемую и (или) не открепляемую подпись?
С какими-то СЭД есть (ведется) интеграция? Можно ли подписывать документы средствами МойОфис? Какими стандартами?
Зачем так далеко? Этот момент наступает на следующий день после окончания действия сертификата. УЦ спокойно себе работает еще годами, но по истекшим сертификатам уже не направляет «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" обычно создает краудсорсинговую экосистему в целях более быстрого развития платформы.
Так вроде Вы и ответили на свой же вопрос:
https://habr.com/ru/post/457288/
Только нужно учесть, что:
А) нет юридически значимого «ведется строгий контроль за компьютерами», во всяком случае применительно к КЭДО. Полагаю, что в суде время подписания только по CADES-BES доказать будет проблематично, даже с таким обещанием \ заявлением "строгий контроль";
Б) только CADES-T при просроченном сертификате проверки подписи – не поможет, т.к. не будет информации, был ли отозван сертификат, а если был, то до подписания или после.
Ваша аналогия с бумажными документами станет точная, если мы не можем установить момент ухода должностного лица с должности: он мог подписать и до и после.
Тем не менее, недавно его государство выдумало. Полагаю, что уже сотни тысяч сотрудников подписывают кадровые документы с помощью ЭП.
Ответ видимо идентичен как для: Какой смысл было апгрейдить Трудовой кодекс статьями 21.1 – 22.3, введенными ФЗ от 22.11.2021 N 377?
Про «Образование в России — даже не требующее капитальных затрат» и вариант как «как-то переломить данную тенденцию» см. Социальный труд и открытое проектирование. Введение
Или каталогизатор для хранения (учета) просто электронных книг, но тогда с возможностью добавления новых справочников-классификаторов. Хотелось бы доступ через web (корпоративный портал).