Приложения/сайты Web <=2.0 никогда не являются безопасными для использования

Немного растянутое название, но просто подумайте об этом:

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

Безопасно ли это?

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

  • Откуда ему знать, что он действительно общается с вашим приложением? Все еще может иметь место атака «человек посередине».

  • Может ли пользователь быть уверен, что ваше приложение не делает что-то подозрительное в фоновом режиме? Можете ли вы быть в этом уверены?

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

Вредоносный код и поведение

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

Допустим, у вас типичная установка: вы вводите изменения в git, ваш CI собирает, тестирует и развертывает ваше приложение в облачном кластере kubernetes. Ваше изменение работает в течение пары минут, полностью протестировано. А вы — параноик, поэтому вы подписываете свои коммиты, только подписанные коммиты собираются, и ваши образы контейнеров также подписаны, и поэтому только подписанные контейнеры развертываются в вашем k8s. Звучит здорово!

Но на самом деле это довольно длинная цепочка остановок для вашего приложения, где все может пойти не так:

  • Может быть, один из ваших коллег вот-вот будет уволен и закоммитит какой-нибудь бэкдор… А вы все проверяете?

  • Доверяете ли вы своему CI? Может быть, у вас есть сторонний CI на основе контейнеров, например, GitHub Actions или Gitlab. Как много вы знаете об этой платформе? Содержит ли ваш образ сборки вредоносный код?

  • Может быть, ваша зависимость изменилась без вашего ведома, и теперь в фоновом режиме работает какая-то жуткая штука? Вы на 100% закрепили эту вещь? И теперь это странное изменение находится в вашем подписанном образе контейнера…

  • Действительно ли ваш облачный провайдер k8s выполняет ваше приложение без изменений? А облачный сервис XYZ не изменяет и не читает ваши данные?

Можете ли вы быть уверены, что ничего подозрительного не происходит? Вы хотя бы проверяете это?

Верификация — это ключ

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

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

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

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

Если посмотреть на ваше типичное приложение web3, которое размещает систему с открытым исходным кодом на IPFS и блокчейне, то пользователь фактически может проверить код, артефакты сборки и выполнение. Таким образом, такая система безопасна (r) для использования, если пользователь делает домашнее задание, фактически проверяя, и если мы игнорируем ошибки и проблемы безопасности в коде для этого аргумента.

Заключение

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

Открытость необходима пользователям и разработчикам для проверки приложения в его коде и исполнении.

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

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *