Как нам защитить журнал

0. 450 18.01.18 00:22 Сейчас в теме
Первая и важнейшая функция бухгалтерского учета - функция защиты, охраны. В ее основе лежит идея сколь простая, столь же эффективная. Вы должны построить такую систему, в которой любое неправомерное действие будет оставлять следы. Другими словами: никто не будет делать ничего плохого, если это плохое тут же вскроется. Кстати, верно и обратное. Если в вашей системе можно сделать что-то плохое так, что никто никогда не узнает, тогда это плохое рано или поздно сделают. Для обеспечения защитной функции, в 1С уже давно существует т.н. журнал регистрации. Но, к сожалению, есть две причины, по которым этот журнал не может считаться средством защиты...

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. acsent 1172 23.01.18 12:01 Сейчас в теме
Как в данной схеме отличить правильное изменение от мухлежа?
Может версии стоит подписывать?
2. mkalimulin 450 23.01.18 12:30 Сейчас в теме
(1) Так же, как бухгалтер отличает правильную запись в базу от неправильной при первичном вводе.
Схема решает проблему "вытаскивания" изменения старых документов "наверх", в конец журнала.
Поразумевается, что бухгалтер каждый день открывает журнал, берет первичку и сверяет. Вот новый документ, сверим его, еще новый, еще... оп! старый, что такое? почему?
3. acsent 1172 23.01.18 12:51 Сейчас в теме
Сверяет с первичкой??
Нереально сверять с первичкой всегда
4. mkalimulin 450 23.01.18 12:59 Сейчас в теме
(3) При начальном вводе с первичкой ведь сверяют? Это - реально? При изменении документа в базе, бухгалтер должен сверить с первичкой? Что здесь нереального?
5. Diversus 2157 23.01.18 13:19 Сейчас в теме
Довольно интересная попытка реализации технологии блокчейн на 1С. Вопросов конечно достаточно много, но все равно это интересно.
6. mkalimulin 450 23.01.18 13:22 Сейчас в теме
(5) Спасибо за отзыв! А какие вопросы? Не могли бы вы их озвучить?
7. Diversus 2157 23.01.18 13:30 Сейчас в теме
(6) Вот несколько на вскидку:
1) Скорость работы, как быстро это все будет работать на живой базе? Все таки это больше теория.
2) Что с проверкой данных? По идее, в блокчейне, процесс вычисления и хранения блоков - это распределенная система. В нашем случае это вычисляется как я понимаю регламентным заданием и в одном месте. Это плохо тем, что возможность подделки возрастает. Опять же, если человек может прямым запросом что-то изменить в базе (это написано в описании статьи), то почему он не сможет удалить документ Докчейн до определенной даты, изменить какой-то нужный документ и заново не создать документы Докчейн? Ведь информация нигде не дублируется (кроме бэкапов), а это значит что проверить эти данные тяжело. В распределенных системах этого минуса нет.
8. mkalimulin 450 23.01.18 13:59 Сейчас в теме
(7)
1) Со скоростью проблем не будет. Здесь в основном операции чтения. Проверка работает асинхронно. У нас есть сутки, для того чтобы сверить все документы и добавить некоторое количество новых блоков. Это реально. Я даже специально ввел понятие "сложность", чтобы притормаживать работу и создавать дополнительные сложности атакующему.
2) Подмена цепочки будет обнаружена не позднее следующего дня. Цепочка будет восстановлена из бэкапа. Будет запущен контроль и "всплывет" измененный документ. Контроль подмены может осуществляться визуально. Это наиболее надежно. Если есть потребность убрать человека из этого процесса, я могу предложить другие варианты.
Удалять начало цепочки не имеет смысла. Все, что было в начале, перейдет в конец. Бухгалтер обнаружит 100 тыс. документов в журнале вчерашнего дня. Цепочка будет восстановлена из бэкапа и т.д.
9. kauksi 211 23.01.18 16:45 Сейчас в теме
Все таки модное слово "блокчейн" и попытка прикрутить его к сферическому коню в вакууме. Вам уже на другом форуме говорили, что проблема изменения документов задним числом решается другими методами, организационными либо ограничением прав. А специалист, могущий залезть в журнал регистрации напрямую точно так же и заменит весь ваш "блокчейн", если будет в том необходимость, раз уж он тоже хранится в 1с базе.
на тему применимости блокчейна недавно была хорошая статья https://habrahabr.ru/company/raiffeisenbank/blog/346534/
12. mkalimulin 450 23.01.18 17:03 Сейчас в теме
(9) За статью спасибо. Но там ведь говорится исключительно о распределенных системах. Я же предлагаю вариант использования блокчейна в одной базе. Я прекрасно знаю, как сейчас решается проблема изменения документов. И опираясь на свои знания могу утверждать - никак. Готов это аргументировать. Опишите систему обнаружения несанкционированных изменений в базе, как вы ее видите. И я вам покажу - как ее обойти.
В то же время, систему, которую предлагаю я, обойти невозможно. Если вы считаете иначе, опишите способ обхода.
10. kauksi 211 23.01.18 16:50 Сейчас в теме
Ну и ваша система говорит лишь о том, что документ изменен, а что изменилось - непонятно. Поэтому любая система логгирования изменения реквизитов или просто включение версионирования будет лучше, наглядней.
11. mkalimulin 450 23.01.18 16:55 Сейчас в теме
(10) Лучше, наглядней и бесполезней. Если система версионирования и логирования не защищена, то толку от нее 0.
Что изменилось - вопрос не принципиальный. Система зафиксировала изменение старого документа - бухгалтер поднимает первичку и сверяет. Он все равно должен полностью сверить весь документ. И подсказка о том, что конкретно изменили здесь разве что не вредна.
16. plevakin 26.01.18 10:46 Сейчас в теме
(11) В накладной скажем, на пяти листах, найти разницу в количестве, бухгалтер скорее всего не сможет. Сверит сумму, идет? Отлично. Количество строк? Идет. Проверять в каждой позиции все - нереально. А может там название поменяли, вместо Товар 1, поставили Товар 2, что тогда? Иногда незначительная разница в названии дает хорошую разницу в цене. Название похоже и хорошо, кто там будет что проверять? Тем более, что зачастую разницы бывают в каждой строке, по документам скажем бумага офисная, а в программе просто бумага, и т.д.. Так что я бы не сильно полагался на сверку первички.
18. mkalimulin 450 26.01.18 13:19 Сейчас в теме
(16) На что тогда предлагаете полагаться?
13. t.v.s. 103 25.01.18 14:00 Сейчас в теме
А смысл? Человек, имеющий доступ к базе, может просто пересчитать все хэши либо поменять данные и пересчитать только последний блок.
У вас защитный механизм и есть защищаемый механизм, а это в корне не верно.
Это примерно как хранить бэкапы на том же диске, создает лишь иллюзию безопасности, а по факту ваши бэкапы умрут вместе с данными
14. mkalimulin 450 25.01.18 15:30 Сейчас в теме
Давайте по порядку.

Я разместил журнал в базе в демонстрационных целях. Чтобы показать сам принцип работы и дать возможность опробовать его в работе. В рабочем варианте я храню журнал отдельно. В публикации я об этом прямо сказал.

Принцип защиты, который я предлагаю, идентичен бухгалтерскому принципу. Бухгалтер ведь не стоит с ружьем около склада. Бухгалтер говорит: ребята, делайте, что хотите, я все равно все тут же узнаю. Мой журнал обеспечивает то же самое. Любое изменение, в том числе сделанное сисадмином, вылезет в конец журнала. Способов внести изменения, так, чтобы они не вылезли в конец журнала нет ни у кого. Независимо от уровня доступа.
15. kauksi 211 26.01.18 10:07 Сейчас в теме
Михаил, есть много способов обмануть систему https://infostart.ru/public/531728/. Ваша публикация дает оригинальный способ решения одной из них. Но не более того
17. mkalimulin 450 26.01.18 12:46 Сейчас в теме
(15) В этой статье говорится, что от всех способов спасет автоматизация, а мой журнал спасает саму автоматизацию. И, таким, образом служит необходимым средством решения всех этих проблем.
19. herfis 414 30.01.18 11:22 Сейчас в теме
Таким образом проблема не решается. Для человека, имеющего доступ к журналу, не составляет никакой проблемы переписать всю цепочку хешей. В крупных организациях для решения этой проблемы существует СБ с собственными айтишниками и серверами, на которые осуществляется миграция логов. Они мониторят ключевые точки безопасности по этим логам и заодно выявляют попытки их подмены.
Ну а в небольших организациях это вопрос доверия и организации работ.
"Поразумевается, что бухгалтер каждый день открывает журнал, берет первичку и сверяет" - улыбнуло.
20. mkalimulin 450 30.01.18 11:37 Сейчас в теме
Решается проблема гарантированного обнаружения изменений. Замена всего журнала будет гарантированно обнаружена. Тут фишка в том, что нет способов вставить изменение в середину.
Первичку так или иначе сверяют с записями в базе. Можно это делать по штатным журналам документов (открыли ПТиУ, сверили, открыли РТиУ, сверили и т.д.) , а можно по защищенному журналу. Это будет не только эффективней, но еще и удобней.
Спасибо, что обратили внимание на ключевые точки безопасности. Где про них можно почитать?
21. herfis 414 30.01.18 13:12 Сейчас в теме
(20)
проблема гарантированного обнаружения изменений. Замена всего журнала будет гарантированно обнаружена.


Во-первых, только факт "пересчета" журнала и больше ничего. Причем при соблюдении сомнительных условий, о которых ниже.
1) производительность полной проверки целостности для по-настоящему больших баз (сводной базы холдинга, например) может быть СЛИШКОМ долгой. При этом распараллелить красиво можно проверку цепочки хэшей, но не проверку соответствия текущего содержимого объекта хэшу его последнего изменения.
2) идея сквозной цепочки хэшей для всех видов документов в базе делает невозможной их параллельное проведение. Это будет бутылочное горлышко по образцу общего журнала документов в 7.7 В больших базах это тоже станет реальной проблемой.
3) злоумышленнику вовсе не обязательно "чистить" журнал или пересчитывать его хэши. Намного проще оставить поддельную запись в логе о непровомочном изменении с корректными хэшами, указывающими на другого пользователя. В базах с большим документооборотом и работающих 24/7, отследить фальшивость такой записи в автоматическом режиме невозможно. Все формальные проверки лог будет проходить. Попытка возложить эту ответственность на самих пользователей - смехотворна. Достаточно секундной невнимательности или забывчивости - и все пропало. Концов не найти. А даже если пользователь своевременно спохватится - кроме его слов не будет никаких доказательств.
- Изменение сделано под тобой в твое рабочее время?
- Да! Но у меня записан хэш, после которого я ничего не меняла! Это не я!
- Чем докажешь? Может, поменяла, а новый хэш записать забыла?
- Усы вот и хвост мои документы!
Даже еще проще. Воткнуть фальсифицированное изменение посреди рабочего дня и фиг его кто отследит. Требовать от пользователей ежедневной сверки собственных действий с журналом - это бред.

Ну и стоит ли овчинка выделки?

ЗЫ. Под ключевыми точками безопасности я имел в виду специфические для конкретной организации метрики, выявляющие аномальные активности пользователей.
22. mkalimulin 450 30.01.18 13:40 Сейчас в теме
(21) А большего и не надо. Установили факт подмены журнала. Восстановили журнал из бэкапа. Запустили процедуру контроля. Единственное отличие от штатного режима в том, что процедура контроля должна будет обработать данные не за сутки, а за двое.
Насчёт производительности. У вас есть целые сутки для того чтобы проверить базу. Все работает асинхронно, обратите на это внимание. Нет никакого "бутылочного горлышка". Проведение само по себе, контроль сам по себе.
И ещё одно ваше заблуждение. Нет в системе никаких подписей. Она проста и прозрачна. Заключается в том, что все изменения гарантированно "всплывают". А дальше вы уже разбираетесь с ними. Подтверждаете или отклоняете.
23. mkalimulin 450 30.01.18 17:09 Сейчас в теме
(21) И, кстати, в чем вы видите бред? В сверке новых документов в базе с первичкой? В сверке измененных документов с первичкой? В чем конкретно?
24. herfis 414 30.01.18 17:27 Сейчас в теме
Все что я имел сказать, я сказал.
Бред я вижу в том, что вы собираетесь возложить на пользователей обязанность постоянной сверки записей лога с внесенными изменениями.
То, что вы это бредом не считаете, я уже понял.
25. mkalimulin 450 30.01.18 17:34 Сейчас в теме
(24) Вообще-то я сказал - с первичкой. Или с первичкой изменения сверять не надо по-вашему?
26. herfis 414 30.01.18 17:41 Сейчас в теме
(25) Бухгалтер изначально вносит данные и изменения в соответствии с первичкой. А вы предлагаете для целей защиты от несанкционированных изменений ввести двойной ручной контроль. При внесении и при проверке отраженных в логе изменений.
27. mkalimulin 450 30.01.18 17:50 Сейчас в теме
(26) Можно двойной, можно одинарный. Мое решение никаких ограничений не накладывает.
Можно представить себе две схемы работы:
1) Кладовщик вносит документы в базу. Бухгалтер сверяет с первичкой.
2) Бухгалтер вносит документы в базу и одновременно сверяет с первичкой.
Ни для первой, ни для второй схемы защищенный журнал не создает дополнительных неудобств. Где вы их увидели?
Могут быть и более сложные схемы, которые изначально подразумевали двойной контроль первичных документов.
И в этом случае защищеный журнал только упрощает работу.
28. herfis 414 30.01.18 18:35 Сейчас в теме
(27) При отсутствии ограничений ваше решение бесполезно чуть менее, чем полностью.
Я привел пример атаки с внесением несанкционированных изменений и фальсификацией их авторства в журнале.
Защититься можно только ручной верификацией всех записей об изменениях в журнале с момента их предыдущей верификации. Ни на какие "естественные" процедуры двойного контроля это не натягивается. И даже это невозможно назвать "защитой", так как человеческий фактор все равно остается.
Невозможно выстроить непрошибаемую защиту от админа, если он имеет неограниченный доступ к логам, данным и всем их копиям.
Предлагаю прекратить переливать из пустого в порожнее и тратить время друг друга.
29. mkalimulin 450 30.01.18 18:41 Сейчас в теме
(28) Давайте конкретнее. В моем журнале нет авторства. В чем заключается атака? Можно поподробнее?
Вы считаете, что нельзя сделать 100% защиту. Я считаю, что можно. Из нас двоих прав кто-то один. Вы видите уязвимость - опишите ее.
34. genayo 30.01.18 21:28 Сейчас в теме
(29) Если документ просто перепроведут - что будет зафиксировано в вашем журнале?
35. mkalimulin 450 30.01.18 21:34 Сейчас в теме
(34) Это зависит от установленных вами настроек. Если вы решили контролировать движения документа, указали значимые для вас измерения или ресурсы, и, при перепроведении, эти значения изменились, тогда в защищеном журнале появится запись об изменении документа.
36. genayo 30.01.18 21:36 Сейчас в теме
(35) Но документ не изменится, и когда бухгалтер сравнит его с первичкой будет что?
37. mkalimulin 450 30.01.18 21:48 Сейчас в теме
(36) Будет ничего. Только имейте ввиду, если вы так настроили контроль, что он будет срабатывать на 60.01 против 60.02, то кто вам виноват?
38. genayo 30.01.18 22:05 Сейчас в теме
(37) О, да вы не поняли суть атаки на обработку проведения? Ну подумайте до завтра.
39. mkalimulin 450 30.01.18 22:13 Сейчас в теме
(38) Если я не понял, почему бы вам не описать подробнее суть атаки? В чем она заключается? Конкретно.
Вы имеете ввиду, что изменят регистр, не меняя документ?
40. genayo 30.01.18 22:17 Сейчас в теме
(39) В том, что имея доступ к обработке проведения, к коду формирования печатных форм, к коду отчетов я смогу сделать все что угодно, не меняя самого документа.
41. mkalimulin 450 30.01.18 22:25 Сейчас в теме
(40) Я поставлю контроль на количество в бухгалтерском регистре, и ваша махинация "всплывет".
42. genayo 30.01.18 22:34 Сейчас в теме
(41) Я потом обратно перепроведу, и так 1000 документов, попробуйте найдите среди них 1 измененный. А сам вступлю в сговор с СБ, товар вывезу, а недостачу повесят на кладовщика. Да, и я все это сделаю в копии базы, которую потом уничтожу.
43. mkalimulin 450 30.01.18 22:43 Сейчас в теме
(42) Что-то вы разухарились )))
Если вы 1000 раз перепроведете документ, и в результате ничего не изменится, тогда в моем защищеном журнале НИЧЕГО не появится.
Если вы 1000 раз перепроведете документ, и в результате он изменится, тогда в моем защищеном журнале появится ОДНА запись.
Я понимаю, что ваш опыт говорит вам, что люди в массе своей идиоты. Но, к сожалению, разработчик не может позволить себе такую роскошь))) Вы можете в этом убедиться, проанализировав мой код в публикациях.
44. genayo 30.01.18 22:52 Сейчас в теме
(43) Я перепроведу 1000 разных документов, не меняя сам документ, из них только 1 будет левым. Попробуйте найдите.
45. genayo 31.01.18 10:09 Сейчас в теме
(43) И еще, имея полный доступ к базе я могу сделать так, что в документах и регистрах данные не будут изменены, а во всех отчетах и печатных формах будут отображаться совсем другие данные. Так что кроме контроля изменения документов, справочников и регистров нужен обязательный контроль кода конфигурации. Без этого защита будет бесполезной.
grumagargler; +1 Ответить
46. mkalimulin 450 31.01.18 10:13 Сейчас в теме
(45) Контроль кода вообще-то нужен всегда. Это, кстати, полезная мысль. Спасибо.
47. genayo 31.01.18 10:18 Сейчас в теме
(46) И когда вы все это реализуете, встанет вопрос соответствия стоимости защиты (в том числе затраты на администрирование ИС, на обработку ложных срабатываний) и вероятных потерь. И если вы сможете доказать, что профит превышает затраты - клиент ваш. Пока вы никого не убедили, если честно.
48. mkalimulin 450 31.01.18 10:29 Сейчас в теме
(47) Вас я не убедил. Это я вижу. Но почему вы ставите знак равенства между собой и всеми?
Вы, как умный человек, должны понимать, что те, кого я убедил, не пишут возражений в этой ветке.
49. genayo 31.01.18 10:42 Сейчас в теме
(48) Приведите статистику - сколько клиентов пришло к вам с этого сайта. В этой теме вы никого из возражающих не убедили.
30. Denis_CFO 46 30.01.18 18:44 Сейчас в теме
(0)
Первая и важнейшая функция бухгалтерского учета - функция защиты, охраны.
Несколько функций: функция контрольная, информационная, функция обеспечения сохранности собственности, функция обратной связи и функция аналитическая.
31. mkalimulin 450 30.01.18 19:02 Сейчас в теме
(30) Вы хотите дополнить или опровергнуть?
32. Denis_CFO 46 30.01.18 19:33 Сейчас в теме
(31) конечно,
опровергнуть?
.
P.S. Плохо, что Вы не понимаете.
33. mkalimulin 450 30.01.18 21:19 Сейчас в теме
(32) Тогда, что по-вашему является первой и важнейшей функцией бухгалтерского учета?
50. Synoecium 719 01.02.18 12:02 Сейчас в теме
Автор, зачем вы тратите время, разубеждая скептиков, просто сделайте платную публикацию с готовым решением, в ней распишите от чего защищает докчейн и насколько сложно его взломать. Кому надо - купят и будут работать.
51. mkalimulin 450 01.02.18 17:32 Сейчас в теме
(50) Я стараюсь внимательно читать каждое сообщение и, по возможности, отвечать. Иногда обсуждение принимает причудливый характер. Но тут уж, наверное, ничего не поделаешь. А платная публикация есть, конечно же.
Оставьте свое сообщение
Вопросы с вознаграждением
Вакансии
Программист 1С
Санкт-Петербург
зарплата от 110 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С (Казань)
Казань
зарплата до 130 000 руб.
Полный день

Программист 1С (Новосибирск)
Новосибирск
зарплата до 130 000 руб.
Полный день

Консультант-аналитик 1С
Москва
зарплата от 180 000 руб.
Полный день