Первая. Можно обойти регистрацию в журнале. Например, изменив документ напрямую в базе, не используя оболочку 1С:Предприятие.
Вторая. Можно отредактировать сам журнал изменений.
В случае с файловой базой (а таких, по всей видимости, большинство) эти два действия может выполнить вообще кто угодно. С клиент-серверной базой дело обстоит чуть лучше. Но это действительно всего лишь "чуть". Администратор системы (а также любой, кто получит доступ к базе или папке с журналом) может внести такие изменения, которые никто никогда не заметит. Например, изменить документ поступления на склад. Вместо 10 шт. по 1 рублю поставить 1 шт. по 10 рублей. Взаиморасчеты с контрагентом останутся неизменными, а 9 шт. можно спокойно забрать себе.
Можно ли как-то решить эти две проблемы с журналом? Можно и ниже я покажу как. Для демонстрации я создал обработку с таблицей настройки. В ней можно отмечать документы и их реквизиты. Журнал будет формироваться только по отмеченным позициям. Так будет легче проверять его работу.
.
Для решения первой проблемы будем регулярно сравнивать документы в базе с их копиями, хранящимися в журнале. А для того, чтобы сам журнал не стал больше базы, будем хранить не сами документы, а хеш-суммы. В этом случае каждый документ будет занимать всего 64 символа (можно укоротить до 32 байт, если очень надо). Для простоты, я буду вести журнал прямо в рабочей базе. Это избавит нас от ненужных технических подробностей и позволит легче понять сам принцип защищенного журнала (в рабочем варианте я веду журнал в отдельном файле). Создадим документ и назовем его "Докчейн". Добавим два реквизита:
КонтролируемыйДокумент тип ДокументСсылка
ХешДокумента тип Строка длина 64
Добавим в наш журнал все документы, которые туда еще не попали.
запрос=новый запрос;
текстзапроса=
"ВЫБРАТЬ
| Док.Ссылка КАК Ссылка
|ИЗ
| Документ.<вид> КАК Док
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.Докчейн
| ПО Док.Ссылка = Блокчейн.КонтролируемыйДокумент
|ГДЕ
| Док.Проведен
| И Блокчейн.Ссылка ЕСТЬ NULL";
видыдокументов=настройка.ПолучитьЭлементы();
для каждого вид из видыдокументов цикл
если вид.пометка тогда
запрос.Текст=стрзаменить(текстзапроса,"<вид>",вид.имя);
выб=запрос.Выполнить().Выбрать();
пока выб.Следующий() цикл
новблок=документы.Докчейн.СоздатьДокумент();
новблок.Дата=текущаядата();
новблок.КонтролируемыйДокумент=выб.ссылка;
новблок.ХешДокумента=ПолучитьХешДокумента(выб.ссылка);
новблок.Записать();
конеццикла;
конецесли;
конеццикла;
Получить хеш документа в 1С совсем несложно. Для этого есть специальный объект ХешированиеДанных.
Функция ПолучитьХешДокумента(ссылка)
хд=новый ХешированиеДанных(ХешФункция.SHA256);
хд.Добавить(ПолучитьДокументСтрокой(ссылка));
рез=строка(хд.ХешСумма);
рез=стрзаменить(рез," ","");
возврат рез;
КонецФункции
Как получить документ в виде строки я здесь описывать не буду. Те,кому это не очевидно, могут заглянуть в приложение к данной публикации.
Итак, добавить документ мимо нашего журнала не получится. Теперь проконтролируем изменение(удаление) уже существующих документов.
выб=документы.Докчейн.Выбрать();
пока выб.Следующий() цикл
если лев(строка(выб.КонтролируемыйДокумент),1)="<" тогда
сообщить("Блок "+выб.Номер+" документ удален");
иначеесли выб.ХешДокумента<>ПолучитьХешДокумента(выб.КонтролируемыйДокумент) тогда
сообщить("Блок "+выб.Номер+" документ изменен");
конецесли;
конеццикла;
Первая проблема решена. Как нам теперь защититься от изменения самого журнала? Добавим в журнал новые реквизиты:
КлючНачальный тип Строка длина 64
КлючКонечный тип Строка длина 64
Соль тип Строка длина 16
Поменяем алгоритм создания блоков:
Процедура СоздатьНовыеБлоки()
ПоследнийБлок=ПолучитьПоследнийБлок();
если ПоследнийБлок=неопределено тогда
КлючНачальный="";
иначе
КлючНачальный=ПоследнийБлок.КлючКонечный;
конецесли;
запрос=новый запрос;
текстзапроса=
"ВЫБРАТЬ
| Док.Ссылка КАК Ссылка
|ИЗ
| Документ.<вид> КАК Док
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.Докчейн
| ПО Док.Ссылка = Блокчейн.КонтролируемыйДокумент
|ГДЕ
| Док.Проведен
| И Блокчейн.Ссылка ЕСТЬ NULL";
видыдокументов=настройка.ПолучитьЭлементы();
для каждого вид из видыдокументов цикл
если вид.пометка тогда
запрос.Текст=стрзаменить(текстзапроса,"<вид>",вид.имя);
выб=запрос.Выполнить().Выбрать();
пока выб.Следующий() цикл
новблок=документы.Докчейн.СоздатьДокумент();
новблок.Дата=текущаядата();
новблок.КонтролируемыйДокумент=выб.ссылка;
новблок.ХешДокумента=ПолучитьХешДокумента(выб.ссылка);
новблок.КлючНачальный=КлючНачальный;
новблок.Соль=ПолучитьСоль(КлючНачальный+новблок.ХешДокумента+строка(новблок.Дата));
новблок.КлючКонечный=ПолучитьКонечныйКлюч(КлючНачальный+новблок.ХешДокумента+строка(новблок.Дата)+новблок.соль);
новблок.Записать();
КлючНачальный=новблок.КлючКонечный;
конеццикла;
конецесли;
конеццикла;
КонецПроцедуры
Как видите, я связал блоки друг с другом. Конечный ключ каждого блока является начальным ключом следующего блока. В то же время, конечный ключ непосредственно связан с содержимым документа (хеш сумма считается по начальному ключу и документу вместе). Изменим, также, и алогритм контроля.
Функция КонтрольПройден()
рез=истина;
ключ="";
выб=документы.Докчейн.Выбрать();
пока выб.Следующий() цикл
если выб.КлючНачальный<>ключ тогда
сообщить("Блок "+выб.Номер+" неверный начальный, ключ нарушена последовательность блоков");
рез=ложь;
иначеесли выб.КлючКонечный<>ПолучитьКонечныйКлюч(выб.КлючНачальный+выб.ХешДокумента+строка(выб.Дата)+выб.соль) тогда
сообщить("Блок "+выб.Номер+" неверный коннечный ключ, нарушена последовательность блоков");
рез=ложь;
иначеесли лев(строка(выб.КонтролируемыйДокумент),1)="<" тогда
сообщить("Блок "+выб.Номер+" документ удален");
рез=ложь;
иначеесли выб.ХешДокумента<>ПолучитьХешДокумента(выб.КонтролируемыйДокумент) тогда
сообщить("Блок "+выб.Номер+" документ изменен");
рез=ложь;
конецесли;
ключ=выб.КлючКонечный;
конеццикла;
возврат рез;
КонецФункции
Здесь добавлен контроль начального и конечного ключа. И теперь, внимание! У нас решены обе проблемы. Наш журнал нельзя изменить, в том смысле, что его нельзя изменить незаметно. Любое изменение в середине журнала приведет к тому, что потребуется изменить весь журнал от этого момента и до конца. А это и есть то, что требует защитная концепция бухгалтерского учета. Подмену цепочки блоков будет нетрудно обнаружить. Например, путем визуального контроля.
Проверяющий записывает сегодняшний(вчерашний) последний блок и сверяет вчерашний(позавчерашний) последний блок с записью, сделанной ранее. Это — самый надежный способ. Есть и другие, менее надежные, но зато не требующие участия человека. Обратите внимание, что ключ на рисунке значительно короче 64 символов. Все правильно. Это — не конечный ключ. Это — соль. Она также участвует в формировании цепочки, поэтому можно контролировать цепочку через нее. Получить соль можно различными способами. Самый простой — использовать генератор случайных чисел. В демо-обработке и в рабочем варианте я использую т.н. POW или поиск "красивого хеша". Это дает возможность усилить защиту (подробности здесь //infostart.ru/public/717210/).
Осталась одна небольшая проблема. Наш алгоритм контроля обнаружит любое изменение документа, но что делать с этим знанием дальше? Общепринятый стиль работы в 1С подразумевает возможность многократного изменения и перепроведения документов. И если оставить все как есть, мы просто утонем в сообщениях об изменении. Выход прост. Будем добавлять факт изменения в журнал. Добавим еще два реквизита в журнал:
Предок тип ДокументСсылка.Докчейн
Потомок тип ДокументСсылка.Докчейн
Алгоритм создания новых блоков не изменится. Алгоритм проверки будет теперь таким:
Функция КонтрольПройден()
вжурнал=новый массив;
рез=истина;
ключ="";
выб=документы.Докчейн.Выбрать();
пока выб.Следующий() цикл
если выб.КлючНачальный<>ключ тогда
строкарезультата="Неверный начальный ключ"+символы.ПС+
"Цепочка документов повреждена."+символы.ПС+
"Идентификатор документа "+выб.УникальныйИдентификатор();
элементы.ПроблемныйДокумент.Видимость=истина;
ПроблемныйДокумент=выб.КонтролируемыйДокумент;
рез=ложь;
прервать;
конецесли;
если выб.КлючКонечный<>ПолучитьКонечныйКлюч(выб.КлючНачальный+выб.ХешДокумента+строка(выб.Дата)+ПолучитьПредка(выб.Предок)+выб.Соль) тогда
строкарезультата="Неверный конечный ключ"+символы.ПС+
"Цепочка документов повреждена."+символы.ПС+
"Идентификатор документа "+выб.УникальныйИдентификатор();
элементы.ПроблемныйДокумент.Видимость=истина;
ПроблемныйДокумент=выб.КонтролируемыйДокумент;
рез=ложь;
прервать;
конецесли;
если выб.Предок.Пустая() тогда
если лев(строка(выб.КонтролируемыйДокумент),1)="<" тогда
если выб.Потомок.Пустая() тогда
ст=новый структура;
ст.Вставить("ссылка",неопределено);
ст.Вставить("предок",выб.Ссылка);
вжурнал.Добавить(ст);
иначе
если не выб.Потомок.Предок=выб.Ссылка тогда
строкарезультата="Обнаружено нарушение связи предок-потомок."+символы.ПС+
"Цепочка документов повреждена.";
элементы.ПроблемныйДокумент.Видимость=истина;
ПроблемныйДокумент=выб.КонтролируемыйДокумент;
рез=ложь;
прервать;
конецесли;
конецесли;
иначе
новыйхеш=ПолучитьХешДокумента(выб.КонтролируемыйДокумент);
если новыйхеш<>выб.ХешДокумента тогда
предок=выб.Ссылка;
текблок=выб.Ссылка;
пока не выб.Потомок.Пустая() цикл
текблок=текблок.Потомок;
если не текблок.Предок=предок тогда
строкарезультата="Обнаружено нарушение связи предок-потомок."+символы.ПС+
"Цепочка документов повреждена.";
элементы.ПроблемныйДокумент.Видимость=истина;
ПроблемныйДокумент=выб.КонтролируемыйДокумент;
рез=ложь;
прервать;
конецесли;
если текблок=выб.Ссылка тогда
строкарезультата="Обнаружены циклические ссылки."+символы.ПС+
"Цепочка документов повреждена.";
элементы.ПроблемныйДокумент.Видимость=истина;
ПроблемныйДокумент=выб.КонтролируемыйДокумент;
рез=ложь;
прервать;
конецесли;
предок=текблок;
конеццикла;
если не рез тогда
прервать;
конецесли;
если новыйхеш<>текблок.ХешДокумента тогда
ст=новый структура;
ст.Вставить("ссылка",выб.ссылка);
ст.Вставить("предок",текблок);
вжурнал.Добавить(ст);
конецесли;
конецесли;
конецесли;
конецесли;
ключ=выб.КлючКонечный;
конеццикла;
если рез и вжурнал.Количество()>0 тогда
для каждого ст из вжурнал цикл
новблок=документы.Докчейн.СоздатьДокумент();
новблок.Дата=текущаядата();
новблок.КонтролируемыйДокумент=ст.ссылка;
новблок.ХешДокумента=ПолучитьХешДокумента(ст.ссылка);
новблок.КлючНачальный=ключ;
новблок.Соль=ПолучитьСоль(новблок.КлючНачальный+новблок.ХешДокумента+строка(новблок.Дата)+ПолучитьПредка(выб.Предок));
новблок.КлючКонечный=ПолучитьКонечныйКлюч(новблок.КлючНачальный+новблок.ХешДокумента+строка(новблок.Дата)+ПолучитьПредка(выб.Предок)+новблок.соль);
новблок.Записать();
ключ=новблок.КлючКонечный;
конеццикла;
конецесли;
возврат рез;
КонецФункции
Теперь все изменения(удаления) попадают в конец журнала. Бухгалтеру остается только регулярно проверять журнал. Не только на предмет подмены, но и просматривать все записи за день:
Окончательный демо-вариант обработки в приложении. Можно скачать и поиграться.
Обработки тестировались на версии 8.3.10.2639, в оригинальной конфигурации.
Любой код из этой публикации можно использовать свободно без дополнительных условий.
Рабочую версию можно приобрести здесь //infostart.ru/public/717210/
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Как в данной схеме отличить правильное изменение от мухлежа?
Может версии стоит подписывать?
(1) Так же, как бухгалтер отличает правильную запись в базу от неправильной при первичном вводе.
Схема решает проблему «вытаскивания» изменения старых документов «наверх», в конец журнала.
Поразумевается, что бухгалтер каждый день открывает журнал, берет первичку и сверяет. Вот новый документ, сверим его, еще новый, еще… оп! старый, что такое? почему?
Сверяет с первичкой??
Нереально сверять с первичкой всегда
(3) При начальном вводе с первичкой ведь сверяют? Это — реально? При изменении документа в базе, бухгалтер должен сверить с первичкой? Что здесь нереального?
Довольно интересная попытка реализации технологии блокчейн на 1С. Вопросов конечно достаточно много, но все равно это интересно.
(5) Спасибо за отзыв! А какие вопросы? Не могли бы вы их озвучить?
(6) Вот несколько на вскидку:
1) Скорость работы, как быстро это все будет работать на живой базе? Все таки это больше теория.
2) Что с проверкой данных? По идее, в блокчейне, процесс вычисления и хранения блоков — это распределенная система. В нашем случае это вычисляется как я понимаю регламентным заданием и в одном месте. Это плохо тем, что возможность подделки возрастает. Опять же, если человек может прямым запросом что-то изменить в базе (это написано в описании статьи), то почему он не сможет удалить документ Докчейн до определенной даты, изменить какой-то нужный документ и заново не создать документы Докчейн? Ведь информация нигде не дублируется (кроме бэкапов), а это значит что проверить эти данные тяжело. В распределенных системах этого минуса нет.
(7)
1) Со скоростью проблем не будет. Здесь в основном операции чтения. Проверка работает асинхронно. У нас есть сутки, для того чтобы сверить все документы и добавить некоторое количество новых блоков. Это реально. Я даже специально ввел понятие «сложность», чтобы притормаживать работу и создавать дополнительные сложности атакующему.
2) Подмена цепочки будет обнаружена не позднее следующего дня. Цепочка будет восстановлена из бэкапа. Будет запущен контроль и «всплывет» измененный документ. Контроль подмены может осуществляться визуально. Это наиболее надежно. Если есть потребность убрать человека из этого процесса, я могу предложить другие варианты.
Удалять начало цепочки не имеет смысла. Все, что было в начале, перейдет в конец. Бухгалтер обнаружит 100 тыс. документов в журнале вчерашнего дня. Цепочка будет восстановлена из бэкапа и т.д.
Все таки модное слово «блокчейн» и попытка прикрутить его к сферическому коню в вакууме. Вам уже на другом форуме говорили, что проблема изменения документов задним числом решается другими методами, организационными либо ограничением прав. А специалист, могущий залезть в журнал регистрации напрямую точно так же и заменит весь ваш «блокчейн», если будет в том необходимость, раз уж он тоже хранится в 1с базе.
на тему применимости блокчейна недавно была хорошая статья
Ну и ваша система говорит лишь о том, что документ изменен, а что изменилось — непонятно. Поэтому любая система логгирования изменения реквизитов или просто включение версионирования будет лучше, наглядней.
(10) Лучше, наглядней и бесполезней. Если система версионирования и логирования не защищена, то толку от нее 0.
Что изменилось — вопрос не принципиальный. Система зафиксировала изменение старого документа — бухгалтер поднимает первичку и сверяет. Он все равно должен полностью сверить весь документ. И подсказка о том, что конкретно изменили здесь разве что не вредна.
(9) За статью спасибо. Но там ведь говорится исключительно о распределенных системах. Я же предлагаю вариант использования блокчейна в одной базе. Я прекрасно знаю, как сейчас решается проблема изменения документов. И опираясь на свои знания могу утверждать — никак. Готов это аргументировать. Опишите систему обнаружения несанкционированных изменений в базе, как вы ее видите. И я вам покажу — как ее обойти.
В то же время, систему, которую предлагаю я, обойти невозможно. Если вы считаете иначе, опишите способ обхода.
А смысл? Человек, имеющий доступ к базе, может просто пересчитать все хэши либо поменять данные и пересчитать только последний блок.
У вас защитный механизм и есть защищаемый механизм, а это в корне не верно.
Это примерно как хранить бэкапы на том же диске, создает лишь иллюзию безопасности, а по факту ваши бэкапы умрут вместе с данными
Давайте по порядку.
Я разместил журнал в базе в демонстрационных целях. Чтобы показать сам принцип работы и дать возможность опробовать его в работе. В рабочем варианте я храню журнал отдельно. В публикации я об этом прямо сказал.
Принцип защиты, который я предлагаю, идентичен бухгалтерскому принципу. Бухгалтер ведь не стоит с ружьем около склада. Бухгалтер говорит: ребята, делайте, что хотите, я все равно все тут же узнаю. Мой журнал обеспечивает то же самое. Любое изменение, в том числе сделанное сисадмином, вылезет в конец журнала. Способов внести изменения, так, чтобы они не вылезли в конец журнала нет ни у кого. Независимо от уровня доступа.
Михаил, есть много способов обмануть систему . Ваша публикация дает оригинальный способ решения одной из них. Но не более того
(11) В накладной скажем, на пяти листах, найти разницу в количестве, бухгалтер скорее всего не сможет. Сверит сумму, идет? Отлично. Количество строк? Идет. Проверять в каждой позиции все — нереально. А может там название поменяли, вместо Товар 1, поставили Товар 2, что тогда? Иногда незначительная разница в названии дает хорошую разницу в цене. Название похоже и хорошо, кто там будет что проверять? Тем более, что зачастую разницы бывают в каждой строке, по документам скажем бумага офисная, а в программе просто бумага, и т.д.. Так что я бы не сильно полагался на сверку первички.
(15) В этой статье говорится, что от всех способов спасет автоматизация, а мой журнал спасает саму автоматизацию. И, таким, образом служит необходимым средством решения всех этих проблем.
(16) На что тогда предлагаете полагаться?
Таким образом проблема не решается. Для человека, имеющего доступ к журналу, не составляет никакой проблемы переписать всю цепочку хешей. В крупных организациях для решения этой проблемы существует СБ с собственными айтишниками и серверами, на которые осуществляется миграция логов. Они мониторят ключевые точки безопасности по этим логам и заодно выявляют попытки их подмены.
Ну а в небольших организациях это вопрос доверия и организации работ.
«Поразумевается, что бухгалтер каждый день открывает журнал, берет первичку и сверяет» — улыбнуло.
Решается проблема гарантированного обнаружения изменений. Замена всего журнала будет гарантированно обнаружена. Тут фишка в том, что нет способов вставить изменение в середину.
Первичку так или иначе сверяют с записями в базе. Можно это делать по штатным журналам документов (открыли ПТиУ, сверили, открыли РТиУ, сверили и т.д.) , а можно по защищенному журналу. Это будет не только эффективней, но еще и удобней.
Спасибо, что обратили внимание на ключевые точки безопасности. Где про них можно почитать?
(20)
Во-первых, только факт «пересчета» журнала и больше ничего. Причем при соблюдении сомнительных условий, о которых ниже.
1) производительность полной проверки целостности для по-настоящему больших баз (сводной базы холдинга, например) может быть СЛИШКОМ долгой. При этом распараллелить красиво можно проверку цепочки хэшей, но не проверку соответствия текущего содержимого объекта хэшу его последнего изменения.
2) идея сквозной цепочки хэшей для всех видов документов в базе делает невозможной их параллельное проведение. Это будет бутылочное горлышко по образцу общего журнала документов в 7.7 В больших базах это тоже станет реальной проблемой.
3) злоумышленнику вовсе не обязательно «чистить» журнал или пересчитывать его хэши. Намного проще оставить поддельную запись в логе о непровомочном изменении с корректными хэшами, указывающими на другого пользователя. В базах с большим документооборотом и работающих 24/7, отследить фальшивость такой записи в автоматическом режиме невозможно. Все формальные проверки лог будет проходить. Попытка возложить эту ответственность на самих пользователей — смехотворна. Достаточно секундной невнимательности или забывчивости — и все пропало. Концов не найти. А даже если пользователь своевременно спохватится — кроме его слов не будет никаких доказательств.
— Изменение сделано под тобой в твое рабочее время?
— Да! Но у меня записан хэш, после которого я ничего не меняла! Это не я!
— Чем докажешь? Может, поменяла, а новый хэш записать забыла?
— Усы вот и хвост мои документы!
Даже еще проще. Воткнуть фальсифицированное изменение посреди рабочего дня и фиг его кто отследит. Требовать от пользователей ежедневной сверки собственных действий с журналом — это бред.
Ну и стоит ли овчинка выделки?
ЗЫ. Под ключевыми точками безопасности я имел в виду специфические для конкретной организации метрики, выявляющие аномальные активности пользователей.
(21) А большего и не надо. Установили факт подмены журнала. Восстановили журнал из бэкапа. Запустили процедуру контроля. Единственное отличие от штатного режима в том, что процедура контроля должна будет обработать данные не за сутки, а за двое.
Насчёт производительности. У вас есть целые сутки для того чтобы проверить базу. Все работает асинхронно, обратите на это внимание. Нет никакого «бутылочного горлышка». Проведение само по себе, контроль сам по себе.
И ещё одно ваше заблуждение. Нет в системе никаких подписей. Она проста и прозрачна. Заключается в том, что все изменения гарантированно «всплывают». А дальше вы уже разбираетесь с ними. Подтверждаете или отклоняете.
(21) И, кстати, в чем вы видите бред? В сверке новых документов в базе с первичкой? В сверке измененных документов с первичкой? В чем конкретно?
Все что я имел сказать, я сказал.
Бред я вижу в том, что вы собираетесь возложить на пользователей обязанность постоянной сверки записей лога с внесенными изменениями.
То, что вы это бредом не считаете, я уже понял.
(24) Вообще-то я сказал — с первичкой. Или с первичкой изменения сверять не надо по-вашему?
(25) Бухгалтер изначально вносит данные и изменения в соответствии с первичкой. А вы предлагаете для целей защиты от несанкционированных изменений ввести двойной ручной контроль. При внесении и при проверке отраженных в логе изменений.
(26) Можно двойной, можно одинарный. Мое решение никаких ограничений не накладывает.
Можно представить себе две схемы работы:
1) Кладовщик вносит документы в базу. Бухгалтер сверяет с первичкой.
2) Бухгалтер вносит документы в базу и одновременно сверяет с первичкой.
Ни для первой, ни для второй схемы защищенный журнал не создает дополнительных неудобств. Где вы их увидели?
Могут быть и более сложные схемы, которые изначально подразумевали двойной контроль первичных документов.
И в этом случае защищеный журнал только упрощает работу.
(27) При отсутствии ограничений ваше решение бесполезно чуть менее, чем полностью.
Я привел пример атаки с внесением несанкционированных изменений и фальсификацией их авторства в журнале.
Защититься можно только ручной верификацией всех записей об изменениях в журнале с момента их предыдущей верификации. Ни на какие «естественные» процедуры двойного контроля это не натягивается. И даже это невозможно назвать «защитой», так как человеческий фактор все равно остается.
Невозможно выстроить непрошибаемую защиту от админа, если он имеет неограниченный доступ к логам, данным и всем их копиям.
Предлагаю прекратить переливать из пустого в порожнее и тратить время друг друга.
(28) Давайте конкретнее. В моем журнале нет авторства. В чем заключается атака? Можно поподробнее?
Вы считаете, что нельзя сделать 100% защиту. Я считаю, что можно. Из нас двоих прав кто-то один. Вы видите уязвимость — опишите ее.
(0)
Несколько функций: функция контрольная, информационная, функция обеспечения сохранности собственности, функция обратной связи и функция аналитическая.
(30) Вы хотите дополнить или опровергнуть?
(31) конечно,
.
P.S. Плохо, что Вы не понимаете.
(32) Тогда, что по-вашему является первой и важнейшей функцией бухгалтерского учета?
(29) Если документ просто перепроведут — что будет зафиксировано в вашем журнале?
(34) Это зависит от установленных вами настроек. Если вы решили контролировать движения документа, указали значимые для вас измерения или ресурсы, и, при перепроведении, эти значения изменились, тогда в защищеном журнале появится запись об изменении документа.
(35) Но документ не изменится, и когда бухгалтер сравнит его с первичкой будет что?
(36) Будет ничего. Только имейте ввиду, если вы так настроили контроль, что он будет срабатывать на 60.01 против 60.02, то кто вам виноват?
(37) О, да вы не поняли суть атаки на обработку проведения? Ну подумайте до завтра.
(38) Если я не понял, почему бы вам не описать подробнее суть атаки? В чем она заключается? Конкретно.
Вы имеете ввиду, что изменят регистр, не меняя документ?
(39) В том, что имея доступ к обработке проведения, к коду формирования печатных форм, к коду отчетов я смогу сделать все что угодно, не меняя самого документа.
(40) Я поставлю контроль на количество в бухгалтерском регистре, и ваша махинация «всплывет».
(41) Я потом обратно перепроведу, и так 1000 документов, попробуйте найдите среди них 1 измененный. А сам вступлю в сговор с СБ, товар вывезу, а недостачу повесят на кладовщика. Да, и я все это сделаю в копии базы, которую потом уничтожу.
(42) Что-то вы разухарились )))
Если вы 1000 раз перепроведете документ, и в результате ничего не изменится, тогда в моем защищеном журнале НИЧЕГО не появится.
Если вы 1000 раз перепроведете документ, и в результате он изменится, тогда в моем защищеном журнале появится ОДНА запись.
Я понимаю, что ваш опыт говорит вам, что люди в массе своей идиоты. Но, к сожалению, разработчик не может позволить себе такую роскошь))) Вы можете в этом убедиться, проанализировав мой код в публикациях.
(43) Я перепроведу 1000 разных документов, не меняя сам документ, из них только 1 будет левым. Попробуйте найдите.
(43) И еще, имея полный доступ к базе я могу сделать так, что в документах и регистрах данные не будут изменены, а во всех отчетах и печатных формах будут отображаться совсем другие данные. Так что кроме контроля изменения документов, справочников и регистров нужен обязательный контроль кода конфигурации. Без этого защита будет бесполезной.
(45) Контроль кода вообще-то нужен всегда. Это, кстати, полезная мысль. Спасибо.
(46) И когда вы все это реализуете, встанет вопрос соответствия стоимости защиты (в том числе затраты на администрирование ИС, на обработку ложных срабатываний) и вероятных потерь. И если вы сможете доказать, что профит превышает затраты — клиент ваш. Пока вы никого не убедили, если честно.
(47) Вас я не убедил. Это я вижу. Но почему вы ставите знак равенства между собой и всеми?
Вы, как умный человек, должны понимать, что те, кого я убедил, не пишут возражений в этой ветке.
(48) Приведите статистику — сколько клиентов пришло к вам с этого сайта. В этой теме вы никого из возражающих не убедили.
Автор, зачем вы тратите время, разубеждая скептиков, просто сделайте платную публикацию с готовым решением, в ней распишите от чего защищает докчейн и насколько сложно его взломать. Кому надо — купят и будут работать.
(50) Я стараюсь внимательно читать каждое сообщение и, по возможности, отвечать. Иногда обсуждение принимает причудливый характер. Но тут уж, наверное, ничего не поделаешь. А платная публикация есть, конечно же.