Технологии 30 июля 2018

Юрий Корженевский — о том, как построить безопасные системы для банков на блокчейне

Далее

Юрий Корженевский — руководитель Центра исследований и разработок, в прошлом ведущий разработчик службы информационной безопасности «Яндекса». Он занимается применением технологии блокчейна в банкинге и бизнесе, а также проектированием простых сервисов для надежного хранения данных — транзакций или персональной информации. «Хайтек» записал выступление Корженевского о шардированных системах с блокчейном и о том, почему в реальном бизнесе так трудно применять криптотехнологии.

Понятные сервисы и паранойя о безопасности

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

За последние несколько лет изменилось не только отношение к криптовалютам. Изменился и сам блокчейн, и вся наша экономика в целом. Через полтора года после нашего первого предложения Центробанку, мы получили совсем другой ответ — внедрять блокчейн в банковскую систему очень важно.

Фото предоставлено спикером

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

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

В реальном бизнесе применить биткоин сложно

Распределенная система работает на то, чтобы данные сошлись. Когда мы меняем корпоративную базу, как правило, — Oracle, на систему с распределенными реестрами, мы меняем подход к архитектуре. У нас добавляется eventual consistency (согласованность в конечном итоге — «Хайтек»). Важно правильно соединить классический и новый подход к фиксации данных. Чтобы не получилось так: перевел деньги от А к Б, а после синхронизации систем окажется, что у А эти деньги списались, а к Б они еще идут.

Информационная безопасность и физическая безопасность в наших банках достаточно продвинутая. Потому что ЦБ отзывает лицензию, если организация устроена неправильно. В хороших банках контур защищен, а сервер находится под ключом. Поэтому идея форкнуть (скопировать процесс или код — «Хайтек») эфириум или какой-то любой популярный продукт на этом фоне проигрывает — нет гарантий, что получится поддерживать процесс по регламенту безопасности по мере обновления оригинального кода.

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


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

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

Для финансовой системы неприемлемо ожидание. Клиенты не будут ждать, пока приложение говорит: «Извините, сервис недоступен». Это обидно: хранишь свои деньги в системе, а тебе еще какие-то отказы в обслуживании поступают. Соответственно, это большие требования к времени загрузки.

Архитектура процессинга и большие данные

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

Каждый узел работает по принципу «как я хочу, так и дайте мне». Изначально есть один общий диапазон счетов. Например — от нуля до бесконечности. Появляется первый узел. Он смотрит на текущую ситуацию и видит, что он единственный в этой сети. Узел берет полностью на себя весь диапазон. Появляется второй узел. Он запрашивает информацию у первого, изучает ее и говорит: «Я хочу половину». Если они договариваются, то все хорошо. Договориться можно, когда узлов более трех, чтобы был кворум.

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


Основная проблема в шардированных системах (данные находятся внутри одной сетевой компоненты — «Хайтек») — появление «монстра» с большой нагрузкой. Сервисы делятся по шардам и каждый обрабатывает свой кусочек. Например, во «ВКонтакте» данные шардированы. Есть моя страничка с десятью постами, а есть страничка Павла Дурова, у которой безумное количество френдов, постов, комментариев. Сервисы, которые обрабатывают его и меня, имеют разную нагрузку. Решить такую задачу просто. Каждый гейт запрашивает «кусочек ответственности» и берет его, продлевая свои права периодически. Если не продлил — шард вернулся, и его может забрать любой другой. Поэтому добавление, удаление узлов происходит очень легко. Упал узел, или надо его обновить, вывели его — ввели. Если это сделали за секунду, то вообще никто ничего не заметит.

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

Фото предоставлено спикером

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

Надежное хранение и бесконечные базы данных

«Надежное хранилище» — место хранения всей оставшейся цепочки платформы. Такой подход используется где угодно, на любых языках и стеках технологий. Это важно. Мы не используем ни Memcached, ни Redis, потому что у нас ограниченная схема данных — только транзакция и настройка счета. При этом используется гибридный подход: с одной стороны, это распределенный реестр, с другой — надежное хранилище с транзакциями.


Memcached — ПО, реализующее сервис кэширования данных в оперативной памяти множества доступных серверов на основе хеш-таблицы.

Redis — сетевое журналируемое хранилище данных типа «ключ — значение» с открытым исходным кодом.


Достаточно надежное сохранение транзакций обеспечивается за счет хранения всех данных на каждом шарде в трех копиях. Гейты проводят транзакцию, считают баланс, и если он сошелся, перенаправляют и дублируют данные — у себя и в базе. Затем все переводится в транзакционную модель на шардах. У базы данные поделены, но уже по своей логике, независимо от гейтов. У каждого шарда есть свои реплики — в нескольких дата-центрах. Ничего не произойдет, если отключится один дата-центр. Реплики восстановят данные из двух копий.

Jepsen — фреймворк для тестирования баз данных, написанный Кайлом Кингсбери с никнеймом Aphyr. Jepsen запускает любую базу данных на пяти виртуальных машинах и начинает слать случайные запросы на каждую машину. В процессе отправки запросов на фиксацию и чтение данных, запускается сценарий — и Jepsen начинает случайно уничтожать эти машины. Гонять системное время. Замораживать процесс и размораживать его. Убивать эту машину, поднимать ее. «Полный дестрой», как в реальном мире. Кайл с помощью Jepsen разломал большинство баз данных и собрал большое количество багрепортов по ним.

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

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

Фото предоставлено спикером

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


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

Мастерчейн — система для проведения анкоринга: когда данные выгружаются из системы и фиксируются в неподконтрольном месте. Сегодня Центробанк с участниками рынка развивает легальную блокчейн-платформу общего назначения. Данные при нем уходят не в биткоин, а в Мастерчейн ЦБ. Именно Мастерчейн, скорее всего, будет иметь правовой статус платформы в России.


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

Если в базу бесконечно записывать данные, — то через 20 лет это будут миллиарды транзакций в год. Память будет увеличиваться, и придется где-то хранить информацию. Поэтому в системе активно используется шардирование на небольшие кусочки. Если какой-то шард «пухнет», он просто делится на два других, как биологическая клетка. Будет просто больше шардов, не один дата-центр, а десять. Удорожания тоже не произойдет. Все данные лежат в компактном виде, их можно хранить на дешевых дисках. Это очевидное коммерческое преимущество такой базы.