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

Ниже — опись. По каждому полю: как оно читается, чем проверяется и чего эта проверка стоит. Последняя строка описи самая интересная, потому что напротив неё не стоит ничего.

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

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

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

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

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

Мы храним зашифрованные данные, и рядом с ними лежат ключи, которые к этим данным не подходят. Выглядит как расстройство для взломщика.

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

У меня было 48 часов видеозаписей учебного курса и простая мысль: пересматривать это я не буду никогда. Сырой транскрипт немногим лучше — болото на сотни страниц. Я собрал конвейер, который превратил записи в Obsidian-вики: 47 связанных статей, и каждое утверждение в любой из них — в двух кликах от места в записи, где это было сказано.

В 2020 году я написал робота, который закрывал за меня клиентские валютные сделки на Мосбирже. Схема оценки рынка у него была, прямо скажем, наивная: восемь метрик, пять состояний и лестница if-ов. Эта схема два года зарабатывала банку его копейки — и умерла не от наивности.

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

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

Я сделал его в 2002 году, выбрал хранить, и получил вместе со скоростью проблему на двадцать лет вперёд.

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

Причина оказалась не в триггерах и не в производительности. Она в том, что одно бизнес‑правило было записано в коде шесть раз в разных местах, а в седьмом его забыли написать.