Традиционная инфраструктура веб-приложений была разработана по ныне устаревшим стандартам безопасности, и на протяжении более 25 лет компании пытаются залатать эту принципиально небезопасную архитектуру. Данная архитектура создавалась на основе предположения, что серверу можно доверять и не беспокоиться о его безопасности, но многолетний опыт научил нас, что ни один сервер не защищен от внешних атак, не говоря уже о внутренних сбоях. Другими словами, сервер по своей сути централизован.
Мы привыкли думать, что “проблемой” является связь между пользователем и сервером, поэтому мы добавили SSL и HTTPS. Но затем мы обнаружили, что хакеры могут взломать базу данных и украсть пароли. Поэтому мы решили вместо этого хранить хеши паролей, однако быстро поняли, что хакеры подбирают пароли путём перебора уже после кражи хешей. Затем мы внедрили ротацию паролей, так чтобы пароль менялся к тому времени, когда он будет подобран, и так далее.
Предприятия тратят миллиарды долларов, пытаясь защитить свои серверы и базы данных, и, несмотря на все эти усилия, до сих пор не существует по-настоящему простого способа аудита систем и обеспечения чёткого непрерывного рабочего процесса.
Block.one создает программное обеспечение на блокчейне для защиты баз данных и аккаунтов пользователей от несанкционированного доступа и неучтенных изменений. В рамках блокчейна пользователи получают закрытые ключи с высокой степенью защиты, которые хранятся на защищенном оборудовании и используются для подписи каждого пользовательского взаимодействия, а не просто для проверки при соединении с сервером. Блокчейн создает неизменяемый журнал записей, в котором в абсолютном и детерминированном порядке хранятся полученные входные данные пользователя, а смарт-контракты задают детерминистическую бизнес-логику, обеспечивающую согласованность во всех системах.
Будущее, над которым работает Block.one, делает ненужными пароли и дорогостоящий аудит, экономя компаниям миллиарды долларов и, что даже более важно, предотвращая кражу личных данных и предлагая повышенную надежность и доступность аудита всем желающим.
В течение многих лет я утверждал, что любой многопользовательский веб-сайт можно улучшить за счёт использования блокчейн-бэкенда. Вопреки распространенному мнению, блокчейны не обязательно должны быть медленными неэффективными базами данных, работающими в условиях цензуры и открытого доступа. Блокчейн может перевести компанию на совершенно новый уровень безопасности, аудита, прозрачности и общей целостности бизнес-процесса, даже если он полностью управляется самой компанией, и ничего из содержимого этого блокчейна нигде не публикуется. Данная статья призвана пролить свет на истинную ценность блокчейна для корпоративной среды и продемонстрировать перспективы индустрии.
Распространенные заблуждения
Многие люди в блокчейн-индустрии считают, что блокчейны приносят пользу только тогда, когда они объединяют множество сторон, которые не доверяют друг другу. По их мнению, традиционные технологии баз данных уже и так могут дать всё необходимое для обеспечения неуязвимости бизнеса. Иными словами, они считают традиционную репликацию баз данных и гарантии “целостности данных” вполне достаточными. В процессе они либо игнорируют, либо не знают о принципиальных различиях между гарантиями безопасности и целостности, которые предлагаются блокчейнами:
- Приверженность глобальной последовательности событий
- Детерминированное выполнение бизнес-логики
- Тесная связь бизнес-логики и целостности данных
- Устранение необходимости паролей
В традиционных архитектурах бизнес-приложений логика отделена от базы данных. Обычно под приложение выделен сервер, такой как Node.js или J2EE, который предоставляет пароль для изменения базы данных. Именно сервер Node.js должен аутентифицировать пользователя с помощью пароля или многофакторной схемы. Как только сервер приложения аутентифицирует пользователя, он выдает токен сеанса, который используется для аутентификации будущих действий пользователя, пока не истечёт время ожидания или не изменится какой-либо элемент сеанса (например, IP).
Довольно очевидно, что этот традиционный дизайн выполняет все операции с базой данных через один логин/пароль, управляемый сервером приложения. Сервер приложения отвечает за реализацию собственной схемы аутентификации с конечным использованием. Также не менее очевидно, что обычно есть несколько сторон, которые имеют доступ к имени пользователя и паролю. Администратор базы данных может задавать и отзывать учётные данные для множества различных серверов приложений и/или отдельных лиц.
Усовершенствованные системы гарантируют, что в горизонтально масштабируемой схеме каждый сервер приложения имеет своё имя пользователя/пароль, а в некоторых случаях он может даже использовать инфраструктуру открытого ключа (Public Key Infrastructure) и аппаратные модули безопасности (Hardware Security Modules – HSM). Однако даже здесь база данных только аутентифицирует соединение с сервером приложения. Для осуществления аудита журнала необходимо записать весь поток данных защищённого соединения. Однако даже в этом журнале записываются только «операции чтения и записи», запрошенные сервером приложения, который уже потерял всю информацию о первоначальных намерениях пользователей.
Аудитор, проверяющий такую систему, не сможет узнать, следует ли сервер приложения (например, Node.js) правильной бизнес-логике и верно ли он аутентифицирует конечного пользователя. Процесс Node.js может “регистрировать в журнале” действия пользователя в базе данных, чтобы аудитор мог попытаться воспроизвести те же самые вычисления, но такой журнал сам по себе не защищен от несанкционированного вмешательства и не содержит никакой независимо проверяемой аутентификации, подтверждающей, что рассматриваемый конечный пользователь авторизовал зарегистрированные действия.
Можно было бы попробовать регистрировать каждое пользовательское соединение, но, поскольку пользователь часто передает через соединение свой пароль, эти журналы в конечном итоге стали бы причиной утечки учётных данных пользователей. Более сложные системы способны шифровать записи в таком журнале, чтобы их мог прочитать только аудитор.
Если предположить, что журнал аудита не был подделан, аудитор должен будет выполнить ту же последовательность действий через логику приложения, дабы убедиться, что полученное состояние базы данных соответствует заявленному. Это подразумевает, что сервер приложения должен быть организован детерминистическим образом.
Сложность детерминированных вычислений
На первый взгляд написание детерминированного кода может показаться “простым”, однако на практике все распространённые компьютерные языки являются недетерминированными, поскольку они позволяют разработчику получать доступ к данным вне базы данных. Это может быть что-то столь же простое, как временная метка, адрес памяти, переменная среды, IP-адрес, или что-то гораздо более неприметное, такое как поведение плавающей точки на оборудовании или порядок вставки в хеш-таблицу. Во многих случаях простого доступа к переменным в памяти долго работающего сервера приложения будет достаточно для введения недетерминизма. Сам момент запуска/остановки сервера приложений должен быть зарегистрирован и воспроизведён, иначе каждый доступ к локальной памяти будет потенциально недетерминирован во время повторного воспроизведения.
Дело в том, что написание детерминированного кода является сложной задачей даже для опытных разработчиков, прошедших все распространенные ошибки и активно ищущих недетерминизм. Типичному разработчику бизнес-приложений будет трудно или непрактично писать в детерминистической манере.
Если мы пойдем дальше и предположим, что код был детерминированным и приложение точно записало пользовательские события, у нас всё ещё остаётся проблема отслеживания версии кода, развернутого в какой-либо момент времени. Приложения являются динамическими по своей сути и часто обновляются, поэтому сам код приложения также должен быть частью состояния базы данных, а его обновления должны управляться и регистрироваться с той же степенью безопасности и доступности аудита, что и действия пользователя. В этом случае аудитор должен будет иметь копии всех версий кода сервера приложения и воспроизводить пользовательские действия, обновляя версию по мере необходимости (и перезапуская код всякий раз, когда он был перезапущен в прошлом).
Даже если бы отдельно взятый сервер приложения мог работать детерминистическим образом как с точки зрения его реализации, так и развертывания, это бы не избавило его от серьезной проблемы масштабируемости. С базой данных может работать только один экземпляр сервера приложения. Параллельный доступ мог бы быть реализован через сложные замки, но даже условия гонки на этих замках нужно будет регистрировать и воспроизводить, иначе два экземпляра логики приложения с различными локальными переменными могут привести к недетерминированному результату.
В этот момент может возникнуть искушение вовсе отказаться от детерминизма, однако при его отсутствии единственное маленькое различие может со временем привести к огромным расхождениям в окончательном наборе данных. Аудиторы будут вынуждены использовать логику с допущениями и приблизительными совпадениями, и все должны будут верить, что эта логика была достаточно хороша.
Само собой, единственное, что нужно для сведения на нет всех усилий, приложенных к написанию и развертыванию детерминированного кода – это чтобы администратор базы данных мог изменять её напрямую и без каких-либо следов. В некоторых случаях тщательное обновление журнала пользовательского ввода и состояния может создать два разных состояния базы данных, каждое из которых проходит детерминированный тест, но, тем не менее, выдаёт разные и несовместимые результаты. Например, представьте, что профессор отправляет в систему оценку F, а затем студент взламывает/покупает свой путь к базе данных и меняет как свою оценку, так и запись в журнале, оставленную профессором.
Замена паролей
Конечная цель любой многопользовательской системы, которая заботится о целостности – гарантировать, что введённые пользователем данные не могут быть подделаны. Использование имени пользователя/пароля или даже другой субъективной многофакторной аутентификации (такой, как SMS или Google Authenticator) напрямую зависит от вывода сервера о том, что введённый пароль или SMS-код/ссылка на электронную почту/код аутентификатора является верным. Очевидно, что это огромная проблема для целостности системы, но на всякий случай я приведу реальный пример того, насколько уязвимыми могут быть такие системы.
В 2016 году у меня был аккаунт на криптовалютной бирже, который был взломан и позволил хакеру украсть у меня биткоинов на несколько десятков тысяч долларов. Взлом, как я мог наблюдать, начался с электронного письма со “сбросом пароля”, отправленного на мой адрес, за которым последовало другое письмо, указывавшее, что мой пароль был успешно изменён. Затем я получил письмо с просьбой подтвердить вывод моих биткоинов (с кодом/ссылкой). В итоге я получил уведомление, что вывод средств был обработан.
На первый взгляд может показаться, что была взломана моя электронная почта, однако это не было возможно, поскольку я использовал для неё многофакторную аутентификацию. Беглый просмотр страницы безопасности моей электронной почты показал, что несанкционированного доступа совершено не было. Я был в этом уверен, потому что Google регистрирует и отображает все IP/устройства, которые когда-либо получали доступ к конкретной электронной почте.
В реальности случилось следующее: злоумышленник перехватил отправленное биржей электронное письмо до того, как оно попало на мою почту. Сервер приложения не мог знать, что письмо было перехвачено, и поэтому без проблем авторизовал сброс и изменение пароля исключительно на основании того, что у злоумышленника был одноразовый код, сгенерированный сервером приложения.
Этот же эксплойт может быть использован в случае с SMS или любым другим методом, основанным на чём-либо отличном от закрытого ключа, контролируемого пользователем. В конце концов, единственный способ по-настоящему защитить аккаунты – это убедить всех пользователей начать использовать для входа в систему аппаратные закрытые ключи, добавив к этому надёжный и трудоемкий процесс безопасного сброса на тот случай, если эти ключи потеряны.
На этом этапе многопользовательское бизнес-приложение может начать подписывать каждый запрос пользователя с помощью его закрытого ключа, регистрировать этот подписанный запрос в базе данных и обрабатывать его с помощью детерминированного кода. Даже это не вполне обеспечивает ожидаемую целостность, поскольку весь пользовательский запрос может быть удалён вместе с любыми производными эффектами. Что будет, если вы взломаете базу данных полиции и удалите подписанную запись сотрудника полиции о выписке вам штрафа, а затем и все состояния, полученные из этой записи?
На этом этапе прозорливый инженер заявил бы, что каждая проблема, которую я здесь поднял, может быть решена путём изменения логики приложения. Он был бы прав: опытный разработчик мог бы использовать “традиционную базу данных”, “традиционный сервер приложения” и “типичные криптографические примитивы” и создать систему, которая является относительно безопасной и подлежащей аудиту. Исходя из этой же логики, инженер может утверждать, что база данных совершенно не нужна, и вместо этого всё должно быть построено непосредственно в файловой системе. Другой инженер отметил бы, что лучше будет повысить производительность за счёт написания кода с нуля, нежели полагания на готовые фреймворки серверов приложений, такие как Node.js и J2EE. Это создаёт ощущение, будто всё до сих пор работает на низкоуровневых технологиях; мы могли бы с тем же успехом начать конструировать транзисторы для максимизации производительности.
Я намеренно впадаю в крайности, потому что они подчеркивают истинную полезность высокоуровневых фреймворков для надёжности и ускорения разработки новых приложений. Весьма немногие пишут свои собственные криптографические библиотеки или алгоритмы, и те, кто это делают, либо являются экспертами, либо в итоге становятся предостерегающим примером, когда их система оказывается взломана. Стоимость разработки/переделки всего с нуля может сделать приложение гораздо более дорогим, чем при построении на основе проверенных фреймворков.
Преимущество серверов приложений/баз данных на блокчейне
Причина существования блокчейнов и сред разработки, таких как EOSIO, выражается в стремлении освободить разработчиков приложений от необходимости заново изобретать “базу данных” ради создания безопасных приложений. Безопасность и детерминизм сложны, поэтому технологии строятся слоями, которые выделяют важные детали. EOSIO объединяет детерминированную среду выполнения (WebAssembly) с быстрой базой данных в единый процесс. Все пользовательские действия подписаны их собственными закрытыми ключами и зарегистрированы в реплицированной распределенной базе данных с возможностью вносить публичные записи в заголовки блоков.
Это лишь вопрос времени – когда такие фреймворки, как EOSIO, станут столь же мощными и простыми в разработке, как и традиционные небезопасные системы. Во многих отношениях архитектура EOSIO уже обладает более высокой производительностью, чем традиционные системы, благодаря одному лишь расположению логики приложения (WebAssembly) в том же пространстве процесса, что и база данных в памяти. Это создает этакие “прокачанные”детерминированные хранимые процедуры.
В предстоящие годы Block.one намерен добавить в эту среду инструменты и интерфейсы, чтобы сделать развёртывание ваших бизнес-приложений на блокчейне таким же простым (или даже более простым), как развёртывание тех же приложений поверх традиционных архитектур.
Я думаю, что внедрение технологии блокчейн должно стать приоритетом для государственных органов, госкорпораций и частных предприятий, в обязанности которых входит предотвращение мошенничества и/или ведение финансовой отчетности. Отказ от использования технологии блокчейн в ближайшие годы станет практически абсурдным, как если бы банк почему-то не внедрял SSL, и как только эта технология станет широко доступной, намеренное игнорирование блокчейна может, на мой взгляд, рассматриваться как халатность.
Настало время действовать. Ваши бизнесы и пользователи не защищены и не будут защищены без фундаментальных изменений в процессе создания наших приложений. Каждый день, когда вы откладываете эти изменения в долгий ящик – это ещё один день, когда ваш бизнес подвергается риску взлома или мошенничества. Выбор за вами.
Оригинал поста: ЗДЕСЬ
Если вам нравится то, что мы делаем - поддержите блокпродюсера blockchained в сети EOS
Развивайте сеть EOS вместе с нами - делегируйте свой голос proxy: dposproxyeos
Телеграм чат: https://t.me/EOS_RU
Загрузите десктопное приложение с открытым исходным кодом RuDex
Вы можете торговать токенами EOS на RuDEX
@blockchained, Поздравляю!
Ваш пост был упомянут в моем хит-параде в следующей категории:
@blockchained спасибо за перевод. оооочень интересная статья. с огромным удовольствием прочитала.
@ladyzarulem пожалуйста