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

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

Что я имею ввиду, когда говорю об абсолютной защите базы данных от нежелательных изменений. Это такая организация работы с базой данных, которая исключает возможность внести в базу данных изменения незаметно для контролера.

За 25 лет работы с учетными системами я повидал наверное больше сотни различных информационных баз. И могу сказать, что ни в одной из них такой защиты не было. Да, есть конечно журналы транзакции, версионирование но... Пользователь, получивший так или иначе соответствующие права и доступ к базе данных может заменить в каком-нибудь более или менее древнем документе прихода

10 шт. Х 1 руб.

на

1 шт. Х 10 руб.

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

Может ли рядовой пользователь базы данных противостоять пользователю, который получил "режим бога"? Ответ: да, может. Для этого нам надо дать ему возможность получить доказательство неизменности данных.

Если говорить о данных вообще, то способ получения доказательства неизменности известен давно. Вычисляем хеш-сумму по какому-нибудь алгоритму, например, SHA-256. Записываем результат на бумажку и получаем абсолютно надежное доказательство. В случае SHA-256, результат можно записать, используя 64 символа. Задача, требующая некоторой концентрации, но в принципе доступная практически любому.

Проблема здесь в том, что рабочие базы данных меняются. Можно сказать, что они созданы для того, чтобы меняться. Когда мы решим сделать проверку нашей хеш-суммы мы обнаружим, что в базе данных с тех пор много чего добавилось.

И что для нас хуже всего, не только добавилось новое, но также изменилось "старое". Нам надо как-то отделить то, что осталось неизменным с прошлого раза, от того, что изменилось. И здесь уже не удастся обойтись одной хеш-суммой. Придется вычислить хеш-суммы для каждого объекта (что мы понимаем под объектом нам сейчас не важно). Делаем мы это для того, чтобы при очередном контроле проверить совпадение хеш-сумм для каждого объекта. И те из них, у которых суммы не совпадают, перенести в область непроверенных данных.

Записать на бумажку хеш-суммы для каждого объекта в рабочей базе данных у нас не получится. Но в этом нет необходимости. Мы по прежнему можем оперировать всего одной хеш-суммой. Для этого организуем хранение хеш-сумм следующим образом. Всякая хеш-сумма будет вычисляться на основе данных объекта и предыдущей хеш-суммы.

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

Да, да. Это именно то, о чем вы сейчас, возможно, подумали. Это - блокчейн. Только без блэк-джека. Обычно блокчейн идет в комплекте с распределенными базами данных, и тем или иным механизмом достижения консенсуса. В подавляющем большинстве баз данных, которые сейчас используются в бизнесе, достижение консенсуса не требуется. Зато доказательство неизменности данных было бы совсем не лишним. Если последнее утверждение для вас все еще не очевидно, тогда поразмышляйте еще раз над "фокусом" 10х1=1х10.

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

У этой схемы нет уязвимостей, через которые ее можно было бы эффективно атаковать. Делать что-либо с журналом нет смысла. Гипотетически, можно подменить программу обработки журнала или залезть в библиотеку SHA-256. Но такая атака вскрывается при обновлении программы обработки и при обновлении библиотеки (а это можно делать при каждом сеансе контроля). Также простая смена устройства приведет к обнаружению атаки. При минимальной осмотрительности можно гарантировать обнаружение любых изменений, даже тех, что сделаны пользователем с правами администратора базы данных.

Есть еще целый ряд второстепенных технических вопросов, связанных с данной схемой. Например, как выяснить что именно было изменено. Или как правильно сериализовать объект. Но я не буду приводить их здесь, чтобы не раздувать статью. Если у вас появились вопросы, задавайте их в комментариях. Я с удовольствием отвечу.

Комментарии (141)


  1. dprotopopov
    06.12.2022 15:15
    +3

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


    1. exwill Автор
      06.12.2022 15:37

      Как минимум, это не защищает от удаления


      1. dprotopopov
        06.12.2022 15:38
        -1

        таблицы цифровой подписью


        1. exwill Автор
          06.12.2022 15:42
          -1

          В какой момент и что именно вы будете подписывать цифровой подписью относительно таблицы в целом? Количество записей?


          1. dprotopopov
            06.12.2022 15:50

            Контрольная сумма строки = Конкатенация Контрольный сумм полей

            Контрольная суммы таблицы = Конкатенация Контрольных сумм строк

            Подпись таблицы = Персональный закрытый ключ применённый к Контрольной сумме таблицы

            Это вообще-то базовые знания для специалиста пишущего в Информационную безопастность

            Конкатенация - это не обязательно сцепление строк, можно контрольную сумму от контрольных сумм


            1. exwill Автор
              06.12.2022 15:57

              И что? Вот проверили-подписали вы таблицу по вашей схеме. К моменту следующей проверки в таблице 5 записей добавили, 3 удалили, 8 изменили. Что вам даст подпись таблицы?


              1. dprotopopov
                06.12.2022 16:05
                +4

                Если к моменту следующе проверки  в таблице 5 записей добавили, 3 удалили, 8 изменили - то подпись не верна - что вы и хотели в самом начале разговора - проверить что данные не искажены.

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


                1. exwill Автор
                  06.12.2022 16:13
                  -3

                  Да, конечно, если каждую транзакцию подписывать ЭЦП, то... Но вы же сами понимаете, что такая схема нежизнеспособна в отличие от предложенной


                  1. dprotopopov
                    06.12.2022 16:19

                    Просто подсчитав контрольную сумму и не подписав её не установишь факт внесения изменений - злоумышленник имеющий возможность внести измения в данные также может сам пересчитать контрольную сумму и записать её поверх старой в логах (даже если ему придётся переписать всю историю лога)

                    Нет ресурсов - и не поднимай вопросы с безопастностью - это не дешёвое удовольствие


                  1. lair
                    06.12.2022 16:26
                    +1

                    Но вы же сами понимаете, что такая схема нежизнеспособна в отличие от предложенной

                    Почему? Я вот не понимаю, чем она менее жизнеспособна.


                    1. exwill Автор
                      06.12.2022 16:57
                      -2

                      Тем, что надо подписывать каждую транзакцию


                      1. dprotopopov
                        06.12.2022 17:02

                        Поясните что нежизнеспособного в подписывании каждой транзакции? Чем это хуже других программных действий? Да надо технику подороже, чтобы не тормозило, поднять инфраструктуру связанную с ЭЦП... это у вас нежизнеспособно - поскольку денег нет?


                      1. exwill Автор
                        06.12.2022 17:24
                        -7

                        Подписывать должен человек. Иначе, это профанация подписи


                      1. dprotopopov
                        06.12.2022 18:45
                        +1

                        В конечном итоге да-человек

                        Вы про всякие мандантные системы слышали? Или чукча не читатель...чукча писатель?


                      1. lair
                        06.12.2022 17:04
                        +1

                        Я все еще не понимаю, что в этом менее жизнеспособного, чем хэширование каждой транзакции?


                      1. exwill Автор
                        06.12.2022 17:25
                        -2

                        А хешировать может система. При условии, что на конце цепочки появляется все тот же человек с ручкой и бумажкой.


                      1. baldr
                        06.12.2022 17:27

                        Предлагаю исключить из этой схемы бездушные железные машины, которые так легко обмануть. Оставим вахтера с бумажкой. И берданку ему дадим.


                      1. dprotopopov
                        06.12.2022 18:41

                        Вообще-то и вахтер важен...безопасность состоит из многих компонент


                      1. lair
                        06.12.2022 17:32

                        Электронные подписи тоже может генерить система. То, что изменено человеком - будет с его подписью, все остальное - с системной.


                      1. exwill Автор
                        06.12.2022 17:41
                        -1

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


                      1. lair
                        06.12.2022 17:45
                        +1

                        В моем случае "подпись ставится" по сеансом контроля в целом.

                        Непонятно, как вы это организуете технически, чтобы "сеанс контроля" захватывал все изменения в нем.

                        Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства.

                        Вы про внешние аппаратные ключи не слышали?

                        Он записывает информацию на бумажку. И все.

                        Записать результат электронной подписи на бумажку, как ни странно, все еще возможно, так что эта часть не теряется.


                      1. exwill Автор
                        06.12.2022 17:48
                        -6

                        Улучшайте, улучшайте вашу схему. В конце придете к моей )))


                      1. lair
                        06.12.2022 18:28

                        Это, если что, не моя схема.


                      1. baldr
                        06.12.2022 17:49
                        +1

                        Как ни крути, а приватный ключ так или иначе оказывается в памяти устройства.

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


                      1. exwill Автор
                        06.12.2022 17:53

                        А я ее скачаю непосредственно перед запуском. И запущусь на новом устройстве


                      1. dprotopopov
                        06.12.2022 18:48
                        -1

                        Есть танцы с бубном в виде криптосерверов и неизвлекаемой памяти. Продают такие девайсы.


                      1. exwill Автор
                        06.12.2022 19:16
                        -1

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


                      1. baldr
                        06.12.2022 19:24
                        +1

                        .. либо каждую транзакцию записываете себе в блокнотик, а блокнотик - в утку, утку в зайца, зайца в сундук, а сундук - под кровать. Где тоже не будет надежной защиты.


                      1. exwill Автор
                        06.12.2022 19:29
                        -1

                        ... либо записываете один хеш по результатам контроля

                        Скажите честно. Вы в самом деле не понимаете, как работает схема? Или вам просто хочется надо мной посмеяться?


                      1. baldr
                        06.12.2022 19:35
                        +2

                        Уже все поняли как работает схема, теперь можно и посмеяться.

                        Согласен, немного лишнего съязвил, прошу прощения.


                  1. JekaMas
                    07.12.2022 11:57

                    Мне кажется, вы тут, коллеги, изобретаете блокчейн.


                    1. exwill Автор
                      07.12.2022 13:53

                      ... только без блэк-джека


                      1. JekaMas
                        07.12.2022 14:15

                        и пирамид


      1. dprotopopov
        06.12.2022 15:39

        от конца света не защитит


      1. Akina
        06.12.2022 15:48
        +4

        Гм... а что защищает? впрочем, и автор только в заголовке говорит о защите. А по тексту он всего лишь устанавливает факт внесения изменений.


        1. exwill Автор
          06.12.2022 15:52
          -3

          А это и есть защита. Такова природа информации. Установив факт, я восстановлю информацию так или иначе


          1. dprotopopov
            06.12.2022 16:14

            Просто подсчитав контрольную сумму и не подписав её не установишь факт внесения изменений - злоумышленник имеющий возможность внести измения в данные также может сам пересчитать контрольную сумму и записать её поверх старой в логах (даже если ему придётся переписать всю историю лога)


            1. exwill Автор
              06.12.2022 16:15

              И бумажку мою он тоже перепишет?


              1. dprotopopov
                06.12.2022 16:22
                -1

                В особых случаях ему может помочь трамвай и Аннушка которая разольёт масло


      1. v3shin
        06.12.2022 17:25
        +1

        А что защищает от удаления?

        Вообще, похоже, статья больше про оповещение, а не про защиту.


        1. exwill Автор
          06.12.2022 17:26

          Все то же защищает. Удаление это всего лишь разновидность изменения


        1. exwill Автор
          06.12.2022 17:31

          Оповещение и защищает. Такова природа информации. Главное - узнать куда смотреть


  1. lair
    06.12.2022 15:28
    +2

    Организовать такую защиту технически несложно.

    Как человек, который как-то участвовал в разработке системы, где объекты подписывались ЭЦП, хочу заметить, что "не сложно" - это некоторое, гм, упрощение. В реальности там достаточно много подводных камней, благодаря которым система получается громоздкая и медленная.

    При минимальной осмотрительности можно гарантировать обнаружение любых изменений, даже тех, что сделаны пользователем с правами администратора базы данных.

    Неа. Вы можете гарантировать обнаружение факта таких изменений, но далеко не всегда - самих изменений. Т.е. вы сможете сказать "у меня тут не сошлась подпись всего", но вот почему - не сможете.

    PS А еще меня не покидает ощущение, что ровно про такую же схему, с записью кода на бумажку, на хабре уже обсуждали.


    1. dprotopopov
      06.12.2022 15:33
      -3

      купи криптопроцессор чтобы побыстрее. никто не говорит что безопасность ничего не стоит.


      1. lair
        06.12.2022 15:36

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


    1. exwill Автор
      06.12.2022 15:38

      Факта достаточно. Дальше в ход идут бэкапы


      1. lair
        06.12.2022 15:47

        ...которые все консистентны и совпадают с БД, которую вы проверяете (но которая не совпадает с вашей контрольной суммой).


      1. dprotopopov
        06.12.2022 16:51

        А с чего вы решили что вам бекапы так же не "поправят"?

        Какой-то ламерский хакинг получается

        Если овчинка стоит выделки - то будет и физическое проникновение на объект


  1. ZEV1416
    06.12.2022 15:38
    +4

    Допустим, Ваша схема работает. Мне надо поменять данные за 2000000 транзакций назад. Я меняю эти данные и пересчитываю все хеш-суммы по настоящее время (я же имею полный доступ к базе, так почему бы и да?). Последняя, естественно, с эталоном не совпадёт.

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


    1. exwill Автор
      06.12.2022 15:40
      -3

      В этом случае я просто откатываюсь к предыдущей точке контроля. Да, неприятно. Но можно сделать контроль почаще.


      1. ZEV1416
        06.12.2022 15:51
        +2

        Вы не учли, что если взять ту же торговую базу, где я таким образом украл 9 единиц товара (была продажа 1 шт за 10 руб, а я сделал 10 шт по рублю, а 9 "лишних", образовавшихся на складе - украл), то 2 миллиона транзакций - это запросто может быть и 2-3 года назад. Мне всё равно, когда править данные, лишь бы остаток на складе, указанный в базе, изменился. Вы будете откатываться на 3 года назад?


        1. exwill Автор
          06.12.2022 15:58
          -4

          Нет. Вы не поняли. Я не буду откатывать базу. Я откачу журнал к предыдущему состоянию


          1. lair
            06.12.2022 16:35
            +4

            К какому, и где вы его возьмете?


            1. exwill Автор
              08.12.2022 13:59

              Из бэкапа


              1. lair
                08.12.2022 15:02
                -1

                Так бэкап-то точно так же скомпроментирован, как и оригинал (и еще и не факт, что у вас есть инструмент это определить).


                1. exwill Автор
                  08.12.2022 17:00

                  Кто вам мешает сделать надежный бэкап? Довольно давно я лично видел у одного моего клиента дневные бэкапы на неперезаписываемых лазерных дисках. Дешево и сердито. Сейчас в этом нет необходимости. Положили бэкап на тот же Яндекс-диск и все. Что вы с ним сделаете?


                  1. lair
                    08.12.2022 17:02

                    Кто вам мешает сделать надежный бэкапы?

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

                    Положили бэкап на тот же Яндекс-диск и все. Как вы его будете компрометировать?

                    Очень просто: запишу туда измененные данные. Вы же предполагаете полный админский доступ к БД, так почему вы не предполагаете такого же доступа к тем местам, где находится бэкап?


                    1. exwill Автор
                      08.12.2022 17:10

                      Нет. Вы не можете сверять данные с бэкапами. Потому что вы не знаете что и с чем сверять. Собственно описываемая мною схема и решает этот вопрос.

                      А дату записи вы тоже попросите поменять? У кого? У админов Яндекса?


                      1. lair
                        08.12.2022 17:12

                        Нет. Вы не можете сверять данные с бэкапами. Потому что вы не знаете что и с чем сверять.

                        Да нет, я как раз знаю: сверять надо все. В вашей схеме невозможно определить, что сверять, только факт, что надо запустить сверку.

                        А дату записи вы тоже попросите поменять? У кого? У админов Яндекса?

                        "Я не знаю, почему дата поменялась, спросите у Яндекса".


                      1. exwill Автор
                        08.12.2022 17:23
                        -1

                        Сохранение бэкапа в Яндексе в принципе аналогично сохранение на неперезаписываемый лазерный диск. Что можно сделать с таким диском? Только сломать. Что можно сделать с бэкапом в Яндексе? Перезаписать? Это все равно, что сломать. Что бы вы ни делали, вы не сможете заставить меня воспользоваться непроверенными данными. В этом смысле моя защита абсолютна.

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


                      1. lair
                        08.12.2022 17:27
                        -1

                        Что можно сделать с бэкапом в Яндексе? Перезаписать? Это все равно, что сломать.

                        Нет, не "все равно". У вас нет гарантированного способа отличить валидную перезапись от невалидной.

                        С чем конкретно вы будете сравнивать дату записи (это если предположить на мгновение, что Яндекс не позволяет ее спуфить)?

                        Сделать безопасное резервное копирование - это не проблема.

                        Если это не проблема, то не проблема и сравнить данные с бэкапом.

                        Кто-то взял и поменял данные. [...] Но для начала вам надо о ней хотя бы узнать

                        Если такая ситуация есть в модели угроз системы, то в системе есть механизм рутиннной автоматической сверки с данными в защищенном хранилище.

                        Точно так же как, например, в хороших системах хранения бэкапов есть механизм рутинной валидации, что бэкап не испортился.


                      1. exwill Автор
                        08.12.2022 17:39

                        Сравнить - проблема. В этом ваша ключевая ошибка.

                        Вот смотрите. Бухгалтерская база. Бэкапы делаются ежедневно и хранятся год. Сегодня у нас 8 декабря. 1 декабря кто-то поменял приходный документ от 20 июля. И сделал это так, что изменение не прошло ни по каким журналам транзакции. Теперь у нас что-то около 100 бэкапов с правильным документом и 6 или 7 бэкапов с неправильным.

                        А теперь расскажите, пожалуйста, как вы поймаете эту ситуацию? Конкретно?


                      1. lair
                        08.12.2022 17:46
                        -1

                        А теперь расскажите, пожалуйста, как вы поймаете эту ситуацию?

                        Предположим, что у нас рутинная проверка раз в месяц, пятого числа (хотя на самом деле, не важно, какого). 5 декабря она сравнит данные за 20 июля с защищенным хранилищем и обнаружит несхождение.


                      1. exwill Автор
                        08.12.2022 18:59

                        Несхождение чего с чем? Документа в базе с документом в бэкапе? У нас таких много. В бухгалтерской базе постоянно меняются документы. И "задним числом" тоже. Как вы отличите документ, который правильно изменен от действий злоумышленника?


                      1. lair
                        08.12.2022 19:05

                        Я исхожу из того, что приходный документ идет по некоему процессу, этапы которого фиксируются, как и состояние документа на каждом процессе. Вот у нас был приходный документ, его сначала 20 июля ввели, а потом 25 - "провели" (на моем слуху термин "Released" либо "Posted"), не знаю, как это по-русски. После этого никакие его изменения невозможны, возможны только новые корректирующие документы. Это состояние фиксируется в защищенном хранилище, и с ним мы и сравниваем.


                      1. exwill Автор
                        08.12.2022 19:25

                        С 20 по 25 изменения в документе допускаются. Как вы отличите "правильные" от "неправильных"?


                      1. lair
                        08.12.2022 19:28

                        Никак, они все равно все будут проверены 25-го в момент фиксации документа.


                      1. exwill Автор
                        08.12.2022 19:52
                        -2

                        Контролер поверил документ и зафиксировал. Сразу после проверки злоумышленник его изменил. Что с чем вы будете сравнивать?


                      1. lair
                        08.12.2022 19:56

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

                        А как предлагаемый вами подход решает эту проблему?


                      1. exwill Автор
                        08.12.2022 22:13

                        Атомарно - это хорошо. На каждый документ бэкап. 100 документов - 100 бэкапов. А что с чем сравниваться то будет? Первый бэкап, последний? Каждый? Сравниваться с чем? С первым? последним? каждым? А если не атомарно? Контролер сидит, проверяет 100 документов. Дело не быстрое. В тот момент, когда он добирается до 63 документа, кто-то подменяет 5. И что тогда? Мне ваша схема не понятна. Как мне кажется, она не работоспособна.

                        Я же вам обрисовал схему простую, прозрачную и работоспособную.

                        1. Контролер сверяет хеш-сумму журнала и свою запись

                        2. Контролер запускает программу проверки

                        3. Программа проверки достраивает журнал и на выходе дает новую хеш-сумму и список измененных объектов.

                        4. Контролер записывает новую хеш-сумму и уходит проверять документы по списку.

                        Видите? Здесь акт контроля происходит мгновенно, без зазора. Здесь просто некуда влезть.


                      1. lair
                        08.12.2022 22:18
                        -1

                        На каждый документ бэкап. 100 документов - 100 бэкапов.

                        Эээ, откуда вы это взяли? Я очень аккуратно же писал: фиксация в защищенном хранилище. Это не бэкапы как таковые.

                        А что с чем сравниваться то будет?

                        Сравниваться будет зафиксированное в защищенном хранилище состояние документа с актуальным состоянием документа в БД.

                        В тот момент, когда он добирается до 63 документа, кто-то подменяет 5. И что тогда?

                        Пятый документ уже зафиксирован, акт его подмены будет обнаружен.

                        Контролер записывает новую хеш-сумму и уходит проверять документы по списку.

                        В этот момент кто-то подменяет один из документов. Что дальше?


                      1. exwill Автор
                        08.12.2022 22:25

                        Следующий сеанс контроля вынесет этот документ в список измененных.

                        Программа проверки, достраивая журнал, гарантировано добавит запись с этим документом.


                      1. lair
                        08.12.2022 22:27
                        -1

                        Следующий сеанс контроля вынесет этот документ в список измененных.

                        Ну то есть никаких преимущество по сравнению с тем, что я описал.


                      1. exwill Автор
                        08.12.2022 22:40

                        Кроме того, что оно работает, а ваше нет. Если быть точным, скорее всего нет. Вы ведь так и не описали ваш алгоритм контроля по шагам


                      1. lair
                        08.12.2022 22:45
                        -1

                        Если быть точным, скорее всего нет.

                        Если быть точным, вы не знаете.

                        Вы ведь так и не описали ваш алгоритм контроля по шагам

                        Нет никакого выделенного "контроля". Есть этап фиксации и рутинный процесс верификации. Фиксируется каждый документ, атомарно, человеком. Информация об этом - в момент фиксации - заносится в защищенное хранилище вместе с состоянием документа на этот момент. Дальше уже согласно регламенту (который зависит от того, сколько у нас ресурсов и насколько быстро мы хотим обнаруживать проблемы) система в автоматическом режиме сверяет состояние документа локально и в защищенном хранилище.


                      1. exwill Автор
                        08.12.2022 23:23

                        Это не будет работать. Я вам объясню почему. Вы правильно понимаете, что источником верификации является человеческое внимание. Но вы не понимаете, что при каждом акте контроля, человек должен верифицировать не отдельный документ атомарно, а всю базу в целом.

                        Атомарно означает, что кто-то другой может добавить "атом" к общей картине. И этот "атом" будет зафиксирован в хранилище строго по вашей схеме. И в дальнейшем будет проходить все проверки.

                        У конкретного человека должно быть на руках доказательство, что ничто не прошло мимо его внимания. "Его внимания" - ключевые слова.


                      1. lair
                        08.12.2022 23:34
                        -1

                        У конкретного человека должно быть на руках доказательство, что ничто не прошло мимо его внимания. "Его внимания" - ключевые слова.

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

                        Но если вы настолько против подписей, то можно сделать и на стороне защищенного хранилища, просто к API "зафиксировать состояние" добавится API "лично я просмотрел такой-то документ".


                      1. lair
                        08.12.2022 22:25
                        -1

                        Здесь просто некуда влезть.

                        Вот вам еще один сценарий:

                        1. Контролер сверяет хеш-сумму журнала и свою запись

                        2. Атакующий подменяет документ

                        3. Контролер запускает программу проверки

                        4. Программа проверки достраивает журнал и на выходе дает новую хеш-сумму и список измененных объектов (хэш-сумма построена по измененному объекту)

                        5. Атакующий подменяет документ на валидный

                        6. Контролер записывает новую хеш-сумму и уходит проверять документы по списку (он видит валидный объект)

                        7. После проверки атакующий заменяет объект обратно, хэш-сумма сходится


                      1. exwill Автор
                        08.12.2022 22:52

                        Не все споры в интернете бесплодны. Спасибо за интересный сценарий! Есть над чем подумать


      1. Akina
        06.12.2022 15:56

        Ну так изменены данные стопицот точек контроля назад... а вы все старые-то бумажки с хэшами давно выбросили - ибо

         для надежного контроля нам достаточно запомнить одну, последнюю.

        Откатываться к началу времён, что ли? или под откатом вы разумеете полное восстановление из бэкапа? Тогда это не просто неприятно, это куда как хуже. Данных много, восстановление длинное, работа стоит, клиенты недовольны..

        Получается, что основа защиты всё же лежит в административной плоскости. Строгий контроль за правами доступа, журналирование в независимое местоположение, исключение физического доступа и так далее..


        1. exwill Автор
          06.12.2022 16:01
          -2

          Под откатом я понимаю откат журнала, а не базы


  1. gennayo
    06.12.2022 16:37
    +1

    Немного непонятно, что делать, если необходимо восстановить старое состояние измененного объекта. Для этого же нужно, чтобы в базу не вносились изменения с момента обнаружения изменения и до момента восстановления, или как?


    1. dprotopopov
      06.12.2022 16:49
      +1

      Об этом автор видимо ещё не думал ;)


    1. exwill Автор
      06.12.2022 17:04

      А зачем вам старое состояние объекта? Нужно ведь не "старое", а такое, которое соответствует реальности. Система фиксирует факт изменения и переводит объект в разряд требующих проверки. А контролер производит проверку. Процесс проверки означает сверку с первичными документами, а не с каким-то состоянием в базе данных


      1. dprotopopov
        06.12.2022 17:18

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

        А ваша схема не отвечат на вопрос какое было изменение - вы в своём уме сравнивать ВСЕ документы? Это будет один из видов атаки от конкурента - заставить вас тратить свои ресурсы на сравнение ВСЕХ документов


        1. exwill Автор
          06.12.2022 17:29

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


      1. gennayo
        06.12.2022 19:39

        Ну так старое же соответствовало реальности, ваша система же это гарантирует.


        1. exwill Автор
          06.12.2022 20:09

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


          1. gennayo
            06.12.2022 22:05

            Хорошо, приведите алгоритм действий, как несанкционированно изменившийся документ будет приведён в соответствие с реальностью и как проверить, что объекты, созданные с момента обнаружения несанкционированного изменения, не были несанкционированно изменены.


            1. exwill Автор
              06.12.2022 22:59
              -1

              Он просто будет скорректирован контролером в полном соответствии с реальностью. Для контролера нет никакой разницы работает он с новым документом или со старым. Поймите такую простую вещь. В системе появился новый документ. Контролер берет его и проверяет. Если находит ошибки, исправляет. В системе появился исправленный документ. Контролер берет его и проверяет. Если находит ошибки, исправляет.

              Если вам все же очень надо выяснить, что именно было изменено, тогда достаете проверенную версию документа из бэкапа и сравниваете. В чем вы здесь увидели проблему?

              Предположим что бэкапы делаются раз в день и хранятся в течение года. В январе ввели документ. Контролер его проверил. Утром 5 декабря кто-то внес изменения в этот документ. Вечером при очередном сеансе контроля, контролер это обнаружил. У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа. Можно доставать из любого.

              и как проверить, что объекты, созданные с момента обнаружения несанкционированного изменения, не были несанкционированно изменены.

              вот это мне вообще не понятно. О каких объектах речь? Об одних и тех же? Мы что-то проверили сегодня, а назавтра это изменили? Завтра это и обнаружим, в чем вопрос?


              1. baldr
                06.12.2022 23:11
                +2

                Вы поставьте условие что ручной контроль в том виде как вы его предлагаете - предполагает что количество изменений - не больше нескольких штук за сеанс "проверки". Тогда можно начинать рассуждать о ручных проверках и неспешных способах отката. Это очень узкая область применения.

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

                Вот у меня есть небольшая база на 50Гб - в нее собираются данные каждый день по нескольку миллионов строк. Даже если бы я хотел внедрить какой-то контроль и защиту - о вашем способе я бы даже думать не стал.

                И еще раз - ваш способ - это не защита, а просто способ индикации факта что что-то где-то когда-то кем-то было изменено. Обнаружить это конкретнее не представляется возможным. И единственный способ исправить - откатить всю базу из предыдущего бэкапа вместе с остальными изменениями. Я не встречал еще ни одного бизнеса который был бы такому рад. Не представляю как можно бы было продать такой способ "защиты" кому-то из технического руководства.


                1. exwill Автор
                  07.12.2022 00:35

                  Зачем откатывать всю базу? Вы хотите получить проверенное состояние одного документа, так получите его в копии и делайте с ним что хотите. Но даже это не является необходимым. Вам система говорит дословно следующее: вот этот вот документ следует еще раз обработать также, как вы его когда-то обрабатывали на входе


                  1. lair
                    07.12.2022 01:22
                    -1

                    Вам система говорит дословно следующее: вот этот вот документ следует еще раз обработать также, как вы его когда-то обрабатывали на входе

                    Вот только данных, на основании которых он был создан, больше нет.


                    1. exwill Автор
                      07.12.2022 08:36

                      В момент появления нового документа в системе тоже нет никаких данных о нем


                      1. lair
                        07.12.2022 16:56
                        -1

                        В системе - нет. А в породившем событии, не важно, программный это вызов или объект из реального мира - есть.


              1. lair
                07.12.2022 01:19

                Контролер берет его и проверяет.

                На основании чего? Предположим, "документ" - это данные, вводимые оператором лично. Что с чем сверять будем?

                У него на руках свыше 300 бэкапов, в каждом из которых хранится проверенная версия этого документа.

                А чем гарантируется, что эти бэкапы не были изменены аналогично тому, как был изменен сам документ?


                1. exwill Автор
                  07.12.2022 08:36
                  -1

                  На основании реальности. Проверка документа это сверка того, что в базе и того, что в реальности


                  1. lair
                    07.12.2022 16:58

                    Вот только реальность эта была неизвестно когда. С чем вы будете сверять запись телефонного разговора, на которой стоит пометка "что-то поменялось", если разговор был полгода назад между уволенным сотрудником и каким-то клиентом?


              1. gennayo
                07.12.2022 05:46

                Хорошо, а теперь расскажите, что будет происходить после восстановления с вашим журналом хэшей, и как будет проверяться неизменность объектов, появившихся в БД с момента обнаружения несанкционированных изменений до момента их исправления.


                1. exwill Автор
                  07.12.2022 08:58

                  Вы не могли бы на примере пояснить? Я вас не понимаю


                  1. gennayo
                    07.12.2022 09:18

                    Ладно, проехали, я могу отвечать только раз в час, такой формат неконструктивен, если мы с вами разговариваем на разных языках.


                    1. exwill Автор
                      07.12.2022 09:20

                      Вы поняли, что из журнала ничего не удаляется и в нем ничего не меняется? Записи туда только добавляются


                      1. gennayo
                        07.12.2022 10:26
                        +1

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


                      1. exwill Автор
                        07.12.2022 11:21

                        Мне казалось, что я достаточно прозрачно описал схему в статье. Но, видимо, мне пока еще не хватает мастерства.

                        Попробую дать полное описание сеанса контроля.

                        1. Последняя хеш-сумма в журнале сверяется с записанной на бумажке.

                        2. Запускается программа контроля.

                        3. Программа контроля создает новые записи в журнале (как для новых документов, так и для измененных или удаленных)

                        4. Контролер записывает последний хеш на бумажку. И приступает к проверке документов по списку

                        Вам будет проще если вы от "санкционированное/несанкционированное" перейдете к рассмотрению "проверенное/непроверенное"


                      1. gennayo
                        07.12.2022 13:30

                        То есть контролер в любом случае должен проверить все изменённые объекты, получается?


                      1. exwill Автор
                        07.12.2022 14:22

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


                      1. gennayo
                        07.12.2022 14:38
                        +1

                        Так объект в процессе своего жизненного цикла после появления в БД может менять своë состояние десятки раз, и если таких объектов десятки тысяч в день, это сколько же контролёров нужно?


                      1. exwill Автор
                        08.12.2022 11:05

                        Ну вы же знаете, как работают бухгалтерские базы. Вот есть документ прихода на склад. Его при вводе в систему проверяют. А если его изменили "задним числом", тогда проверяют под лупой


                      1. gennayo
                        08.12.2022 13:12

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


                      1. exwill Автор
                        08.12.2022 14:07

                        Никто нас не заставляет хранить в журнале абсолютно всю информацию. Количество и сумму храним а комментарий не храним, например


                      1. gennayo
                        09.12.2022 08:27

                        Вы предлагаете для каждого вида объектов определять набор полей, которые будут участвовать при расчете хэш?


                      1. exwill Автор
                        09.12.2022 08:47

                        Совершенно верно


  1. baldr
    06.12.2022 17:57
    +1

    Все равно непонятно что гарантирует такая система.

    Есть старичок с ручкой и бумажкой, который раз в день делает обход и записывает хэши из каждой базы, ок..

    Пусть база изменяется не очень сильно - допустим, сыплется в день миллион транзакций.

    Кладовщик Степан, после ухода вахтера с бумажкой, меняет строчку в базе с количеством яблок и сьедает три яблока.

    На следующее утро кто будет проверять весь этот миллион транзакций?

    Через месяц ревизия обнаруживает недостачу трех яблок. Кого накажут и как его найдут?


    1. exwill Автор
      06.12.2022 18:39

      Система проверяет. И на выходе выдает вашему старичку: "вот смотри, была такая транзакция, о которой ты еще ничего не знаешь"


      1. baldr
        06.12.2022 18:42

        В смысле не знаешь? Там миллион транзакций, о которых он не знает. Что с ними делать-то?

        Хэш считается по известной формуле, Степан его посчитал и записал правильно.


        1. exwill Автор
          06.12.2022 19:24
          +1

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

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

          Задача, которую я решаю, заключается в том, чтобы гарантировать, что каждый документ хранится в базе данных ровно в том виде, в каком он был проверен и введен. А если документ изменяет это свое состояние, то он гарантировано переходит в категорию "не проверен" и при очередном контроле его снова проверят.


          1. baldr
            06.12.2022 19:34
            +1

            То есть документ изменяется один-два раза в день? Это уже не база данных, а справочник.

            Обычно в базах данных "для бизнеса" на слово никому не верят. В вашей схеме сколько человек вот так "проверяют" всю базу и держат "на бумажке" хэш-код? Один? А кто он? А если он уходит в отпуск или увольняется? А если его еще год назад [уговорили, подкупили, запугали] или он когда-то давно пропустил и "одобрил" одно изменение в базе - что тогда?

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

            Получается проверка ради проверки, ложная гарантия безопасности.


            1. exwill Автор
              06.12.2022 20:02
              -2

              Контролеров может быть несколько. Но дело даже не в этом.

              Есть природа информации. На нее и надо опираться. После того, как информация появилась в этом мире, вы не можете с уверенностью утверждать сколько копий у этой информации и где они находятся. Информация неуничтожима в принципе. "Рукописи не горят" - это не фигура речи. Это истина в некотором высшем смысле.

              Вы, как хранитель базы данных, конечно можете проявить халатность и потерять информацию навсегда. Вы можете хранить бэкапы в неправильном месте и совершать другие ошибки. Но для атакующего все это не имеет значения. У него все равно никогда не будет 100% гарантии что он знает про всех хранителей базы и про все бэкапы. У атакующего на сегодня есть только один союзник. Отсутствие системы гарантированного обнаружения. У вас, как у хранителя базы данных, все на руках. Есть бэкапы, откуда можно запросто достать правильную информацию и заменить ею неправильную в оперативной базе. Но вы этого никогда не сделаете, потому что вы просто не знаете куда смотреть, что именно искать, где вам "собаку зарыли".

              Поэтому не могу с вами согласиться. Система гарантированного обнаружения изменений - это не ложная безопасность, а самая настоящая


  1. ermouth
    06.12.2022 20:40
    +1

    Деревья Меркле, реализация для БД с верификацией – immudb.


    1. exwill Автор
      06.12.2022 21:05

      Спасибо за ссылки!


    1. dprotopopov
      06.12.2022 23:11
      -1

      Может и полезно, но автора видимо интересует как натянуть сову на глобус...в смысле обеспечить контроль отсутствия вмешательства на обычных реляционных базах...типа ms sql, postgres, orale, mysql и тд...я сомневаюсь что автор слышал про другие типы баз....при этом автор знает что у базы есть лог, который можно откатить...попробуй откатить лог у dbf которого нет...но есть и наоборот...тотже биткоин блокчей можно рассмативать как базу состоящую из одного лога без физической записи таблиц


      1. ermouth
        07.12.2022 01:35
        +1

        как базу состоящую из одного лога без физической записи таблиц

        Не обязательно blockchain же, append-only b+tree – это прямо журнал транзакций, который и есть сама БД. Некоторые особо неубиваемые NoSQL-базы именно так данные и хранят.

        А если прикрутить в добавляемые страницы иерархию хэшей и подписи, плюс запретить сжатие (удаление orphaned-страниц), как раз immudb и получится.


  1. leprosus
    08.12.2022 11:51

    Отвлечённый комментарий: проблема habr в том, что в комментариях поносят авторов статей те люди, у которых есть некие баллы (некое право). Это право они получают за их активность: писал какую-то статью, поддержал кореша в комментариях и получил одобрение в ответ. Оставшаяся часть людей читают, но ничего не пишут: ни статей, ни комментариев. Как следствие, просто поддержать автора статьи, поставив "лайк" возможности нет. А вступать в дебаты с людьми, которые пишут псевдоакадемические статьи про преобразования Фурье в разных прикладных нишах на хабре (почему-то именно на хабре, а не в целевых научных форумах), никому не хочется. Мне лично после такого общения или прочтения комментариев руки помыть хочется.
    Вот и получается, что хабр с каждым годом стимулирует появление сообщества, цель которого обосрать другого.

    В защиту автора: в 2013 году с коллегой писал ИС для официального сервисного центра Xerox. Нужно было сделать так, чтобы контактную информацию клиентов нельзя было использовать, в случае проникновения (а у них уже были утечки ранее), и должен был быть контроль неизменчивости данных из-за внешних факторов. Нечто подобное было и сделано. Оно работает до сих пор.
    Возможно, чтобы реализовать нечто подобное, нужно выбрать конкретный техн стек, чтобы всё получилось, и потратить деньги на железо (решение было комплексное), плюс, для адекватной защиты нужны ещё некоторые административные вещи, которые не позволят получить доступа к ресурсам просто. Но это уже тонкости.


    1. baldr
      08.12.2022 13:21
      +1

      Карму уже тысячу раз обсуждали. Может, не стоит снова начинать? Вкратце - да, вы правы - на хабре больший вес имеют те, кто написал более ценные (с точки зрения других участников) статьи. Это саморегулирование. Есть плюсы и минусы, но - здесь вот так.


      1. leprosus
        08.12.2022 13:27

        Так может тогда тем, кто создаёт ценность для таких же как и они немного поучиться элементарной культуре? Хотя культура - это не то, ради чего существует хабр, я полагаю. Так как, наверняка, тоже это уже обсуждали, и наверняка пришли к выводу типа: "да пошли все на ***", верно?

        PS странно, ко мне пришёл не автор, и не тот самый комментатор, а некто, с кем я даже не начинал разговор. Видимо, это тоже особенность хабр культуры, которую здоровым людям не постичь.

        NB Как же меня весили сливы кармы... Как будь-то для здорового человека циферка в профиле соцсети имеет какую-то важность...


        1. baldr
          08.12.2022 14:51
          +3

          PS странно, ко мне пришёл не автор, и не тот самый комментатор, а некто,
          с кем я даже не начинал разговор. Видимо, это тоже особенность хабр
          культуры, которую здоровым людям не постичь.

          Добро пожаловать в интернет! Теперь вы знаете что на публичный комментарий может ответить кто угодно!

          NB Как же меня весили сливы кармы... Как будь-то для здорового человека циферка в профиле соцсети имеет какую-то важность...

          Противоречие вижу здесь я. Карма вам не важна, но именно вы подняли именно эту тему в комментариях к совершенно не относящейся к этому статье. И, похоже, готовы это дальше обсуждать.


          1. leprosus
            08.12.2022 15:02
            -3

            В интернете культура отличается от нормальной жизни? Любопытно. Буду знать. Правда, не понятно, почему хабр называется интернетом...

            Смотрю, появился говор как у мастера Йоды. Видимо, кроме культуры, ещё и "русский язык знать хочешь ты". Хотя, какой русский язык? В интернете он тоже не нужен: главное больше желчи подливать между букв.

            PS удивительно, но почему-то ты предыдущее сообщение не заминусовал? Чего так? Это же нормальный рефлекс любого "уважаемого автора в интернете" на другого, с кем он не согласен.


            1. lair
              08.12.2022 16:12

              В интернете культура отличается от нормальной жизни?

              Да нет, интернет - часть "нормальной жизни". Вот от других ее частей культура и правда может отличаться, и мне несколько странно даже, что что у вас это вызывает вопрос.


              1. leprosus
                08.12.2022 16:38
                -2

                Она у тебя тут отличается исключительно потому, что здесь принято так, ибо хабр культивирует здесь такое "саморегулирование".
                Гризитесь, поливайте желчью, унижайте - это же поведение здоровых людей, верно?

                NB Ребята, нужно срочно снести мне карму, в этот момент вам любой психиатр скажет, что правильно сделали. Давайте, продолжайте.


                1. lair
                  08.12.2022 16:41

                  Она у тебя тут отличается исключительно потому, что здесь принято так

                  Гм, культура разных частей общества отличается именно потому, что "здесь" (в этой части общества) "принято так". Собственно, "культура" - это и есть "принято так".

                  Повторюсь, мне странно, что в ваших комментариях читается удивление этому совершенно нормальному явлению.


                  1. leprosus
                    08.12.2022 16:48
                    -3

                    А, то есть принято так. Понял.
                    Значит тебе и второму чукче позволительно писать здесь гадости к статье, которая описывает вполне себе рабочий механизм (моё мнение, допускаю, что для чукч сильно сложно написано)?
                    Видимо ты со вторым чукчей только писать комментарии умеешь, читать не аллё...

                    Как? Комфортно, когда я опустился до культуры вашего технологического притона?
                    Или таки вернёмся к разговору здоровых людей, где культура учитывается каждого участника, а не как в притоне принято?


                    1. lair
                      08.12.2022 17:00

                      А, то есть принято так.

                      Да, здесь так принято, что на любой комментарий может ответить любой участник сообщества.

                      Значит тебе и второму чукче позволительно писать здесь гадости к статье

                      Я что-то не помню, чтобы я писал гадости к статье, этой или какой-то другой.


                      1. leprosus
                        08.12.2022 17:34
                        -2

                        Так попробуй свои комментарии дать почитать далёкому от ИТ человеку, и главное нелояльному тебе. Так много для себя откроешь... Возможно, получится понять, что пора проходить кризис среднего возраста, и свои "личные обиды" изливать на других - это очень плохо.

                        Вообще, хорошая рефлексия по тому, как ты общаешься с миром - это очень полезная штука. Вот с двумя сейчас бесплатно делюсь обратной связью о поведении, которое считается здесь "нормой".

                        У тебя вся риторика основана на утверждениях, не на уточнениях и вопросах. То есть, ты по-умолчанию считаешь всех глупыми, кроме себя и тех, которые сейчас солидарны.

                        И для сравнения, почитай комментарии автора статьи - земля и небо. Если бы я не знал возраст всех вас, ребята, то я бы предположил, что тебе, комментатору выше и самому первому лет так до 30ти, так как очень большой шлейф максимализма тянется во всех текстах.


                      1. lair
                        08.12.2022 17:42

                        Так попробуй свои комментарии дать почитать далёкому от ИТ человеку

                        ...и он скажет "я тут ничего не понял". Я пробовал, да.

                        Вот с двумя сейчас бесплатно делюсь обратной связью о поведении, которое считается здесь "нормой".

                        Мне вот любопытно, вам никогда не говорили, что незапрошенная обратная связь не считается "нормой"?

                        У тебя вся риторика основана на утверждениях

                        Ну да, я утверждаю некоторые вещи на основании своего опыта.

                        То есть, ты по-умолчанию считаешь всех глупыми

                        Нет, я по умолчанию считаю, что я знаю некоторые вещи.


                      1. leprosus
                        08.12.2022 17:47
                        -2

                        Странно, двойные стандарты. Хотя это норма для местной культуры, я почему-то в этом уверен.

                        Я тебя не звал в ветку, ты сам пришёл со своим мнением. И, видимо, тебя это так задевает, так как с тобой поступают ровно симметрично. Не кажется тебе это странным?

                        PS А по поводу "я тут ничего не понял", человек и не должен понимать смысл, но должен понять эмоциональную составляющую риторики. У нас мозг так устроен, что настроение можно уловить по любому тексту (читай Сапольского).


                      1. lair
                        08.12.2022 17:50

                        И, видимо, тебя это так задевает, так как с тобой поступают ровно симметрично.

                        Неа, меня это не задевает. Я просто демонстрирую вам, что вы пользуетесь той же нормой, которую только что критиковали.

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

                        А эмоциональная составляющая там будет близкая к нейтральной. То, что это критика - будет читаться. Валидная ли это критика, понятно без знания предмета будет невозможно.

                        У нас мозг так устроен, что настроение можно уловить по любому тексту

                        Ммм, а эта риторика не построена на утверждениях?


                      1. leprosus
                        08.12.2022 18:07
                        -1

                        Если я всё продолжаю видеть твои ответы, значит таки задевает?

                        Ну, да ладно. Мнение, что эмоциональная составляющая будет нейтральной - это конкретно твои утверждения. Опять же, продолжаешь утверждать, вместо того, чтобы спросить альтернативного мнения.

                        Критика - это когда "это некорректно, нужно делать вот так потому что", критиканство - это "это не будет работать, тут всё говно".

                        PS твои коллеги по притону продолжают сливать карму, теперь я не могу сразу отвечать тебе на комментарии. Уж прости, но отвечать буду до поры с большой задержкой :)
                        Искренне надеюсь, что уже сольют профиль, чтобы я уже перестал писать, да и читать статьи здесь. И так тут почти читать нечего, так ещё после каждой статьи хочется руки помыть.


                      1. lair
                        08.12.2022 18:09

                        Если я всё продолжаю видеть твои ответы, значит таки задевает?

                        Нет.

                        Опять же, продолжаешь утверждать, вместо того, чтобы спросить альтернативного мнения.

                        Так я его иногда спрашиваю. Удивительно, но это мнение не обязательно совпадает с вашим.

                        Критика - это когда "это некорректно, нужно делать вот так потому что",

                        Ну так я обычно и пишу, почему именно не работает.

                        Искренне надеюсь, что уже сольют профиль, чтобы я уже перестал писать, да и читать статьи здесь. И так тут почти читать нечего, так ещё после каждой статьи хочется руки помыть.

                        Так зачем же вы продолжаете читать?


          1. leprosus
            08.12.2022 15:40
            -2

            Вот, теперь вижу рефлекс в карме. Умничка.


    1. exwill Автор
      08.12.2022 13:50

      Очень интересно. Скажите, там у вас были контролеры? Имеются ввиду люди


      1. leprosus
        08.12.2022 14:03

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