Под капотом: как Mervey проектирует безопасность цифровых продуктов
Когда партнёр спрашивает, как мы защищаем продукт, он обычно ждёт услышать про шифрование и тесты на проникновение. Но для нас безопасность начинается раньше первой строки кода — как принцип, на котором строится архитектура
Манапова Гульдана
Безопасность цифровых продуктов начинается не с проверки перед релизом, а с решений, принятых ещё до разработки. Какие данные собирать? Где хранить приватные ключи? Кому предоставлять доступ? Как помочь пользователю избежать необратимой ошибки? В Mervey эти вопросы определяют архитектуру, интерфейс и процессы команды. Рассказываем, как такой подход работает на практике.
Защита данных пользователей: не собирать лишнего
Перед разработкой каждой функции мы определяем, какая информация ей действительно нужна. Каждое дополнительное поле — это данные, которые придётся хранить, защищать и своевременно удалять. Собирать информацию «на всякий случай» удобно для будущей аналитики, но это увеличивает последствия возможной утечки. Поэтому наш принцип прост: если функция работает без определённых данных, мы не собираем их без необходимости. Защита данных пользователей начинается именно с этого решения, а не с выбора алгоритма шифрования.
Безопасность криптокошелька: контроль над приватными ключами
В P2PChat приватные ключи хранятся на устройстве пользователя, а не на серверах Mervey. У команды нет доступа к ним — и, соответственно, возможности распоряжаться средствами владельца. Такое устройство криптокошелька определяет и границы нашей помощи: мы не можем отменить подтверждённый блокчейн-перевод или восстановить утраченную сид-фразу — последовательность слов для восстановления доступа к кошельку. Эти ограничения важно объяснять заранее. Контроль над цифровыми активами требует понимания того, какие действия нельзя будет отменить.
Безопасный интерфейс: предупреждать до ошибки
Когда перевод необратим, интерфейс должен помогать человеку проверить решение до отправки средств. Проверка адреса, подтверждение операции и понятное предупреждение о последствиях — часть безопасности продукта. Их задача не просто показать информацию, а обратить внимание пользователя на риск в нужный момент. Поэтому при проектировании мы оцениваем не только скорость сценария. Важно и то, достаточно ли у человека информации, чтобы выполнить действие осознанно. Дополнительное подтверждение оправданно, если оно помогает предотвратить потерю средств.
Защита от социальной инженерии
Не каждая атака начинается с уязвимости в коде. Злоумышленник может представиться сотрудником поддержки, напугать блокировкой и убедить человека раскрыть данные или подтвердить перевод. Поэтому защита от социальной инженерии требует понятных правил общения с пользователем. Наша поддержка не просит сообщать сид-фразу. Мы напоминаем об этом в интерфейсе и публичных каналах, а официальные контакты должны быть доступны и легко проверяемы. Такие меры не исключают мошенничество, но помогают пользователю распознать подозрительный запрос до того, как он передаст доступ.
Безопасная разработка: проверки кода и доступов
Безопасность зависит не только от собственного кода. Сторонние библиотеки, интеграции и работа подрядчиков также влияют на защищённость системы и требуют проверки. Перед релизом мы проводим внутренние проверки. Доступы выдаём с минимально необходимыми правами и на ограниченный срок: участнику проекта нужны только те возможности, которые требуются для его задачи. Единая команда Mervey связывает архитектуру, дизайн и разработку в один процесс. Это помогает сохранять ответственность за безопасность на стыке работ, где иначе легко упустить важное требование.
Безопасность — результат конкретных решений
Шифрование и тестирование необходимы, но сами по себе не заменяют продуманную архитектуру. Защита продукта складывается из последовательных решений: не собирать лишние данные, ограничивать доступ, проверять зависимости и предупреждать пользователя перед необратимым действием. Именно так мы понимаем безопасную разработку: учитывать риски на каждом этапе, а не возвращаться к ним только после инцидента. В следующем материале серии «Под капотом» расскажем, как тестируем продукты перед релизом и какие ограничения есть у тестовой среды. Разрабатываете продукт, который работает с деньгами или персональными данными? Опишите задачу через форму на сайте Mervey — обсудим требования к безопасности и решения, которые важно предусмотреть до запуска.
Ещё больше мыслей и опыта команды — в журнале.
Другие материалы