KeyMeld: общий ключ для iPhone и Android и архитектура Zero Vault для проекта

У кроссплатформенных приложений есть проблема, которую пользователь обычно не замечает. На экране он видит один аккаунт и ожидает одинаковую работу на любом устройстве. Но внутри iPhone и Android используют разные механизмы защиты и по-разному работают с локальными ключами.

На iPhone приложение может защищать локальный ключ устройства средствами Apple Keychain. На Android для этого используется Android Keystore. Эти технологии предназначены для того, чтобы чувствительные ключи оставались в защищённой среде устройства, но они не являются взаимозаменяемыми.

Для пользователя это не имеет значения. Он просто хочет открыть приложение на iPhone, затем установить его на Android и продолжить работу с теми же защищёнными данными.

Для разработчика здесь возникает архитектурный вопрос: как организовать общий доступ на двух платформах, не перенося локальные ключи устройств и не складывая их копии в базу собственного backend?

Разбираясь в KeyMeld, я увидел, что сервис предлагает для этого отдельный универсальный ключ, не вмешиваясь во внутреннюю защиту iOS и Android.

Общий ключ для разных платформ

Локальный ключ устройства относится к конкретному телефону и защищается средствами соответствующей операционной системы. Он остаётся в защищённой среде конкретного устройства и не предназначен для свободного переноса между устройствами.

Универсальный ключ KeyMeld — другая сущность. Он создаётся для конкретного проекта, аккаунта и защищённого пространства и становится общим для авторизованных клиентов на разных платформах.

Сервис не забирает ключ у iPhone, не переносит его на Android и не пытается превратить два разных ключа в один. Платформенная защита остаётся самостоятельной, а приложение получает общий уровень доступа для своего проекта.

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

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

Zero Vault принадлежит проекту

Сразу важно уточнить: Zero Vault — не название самого KeyMeld. Это архитектурная модель, которую может построить подключённый продукт.

KeyMeld работает как отдельный SaaS-сервис. Его не устанавливают внутрь backend приложения и не размещают рядом с базой проекта как ещё один программный модуль. Универсальный ключ обслуживается в отдельном SaaS-контуре KeyMeld, за пределами backend самого продукта.

Чтобы такая модель сохранялась, границы доверия между проектом и KeyMeld должны оставаться независимыми. У backend приложения и внешнего сервиса используются раздельные учётные данные, права доступа и механизмы администрирования.

Именно такой результат в архитектуре проекта можно обозначить как модель Zero Vault: его серверная база не хранит ключ от клиентского защищённого хранилища.

Zero Vault не означает, что backend продукта вообще ничего не хранит. На его стороне остаются аккаунты, настройки, бизнес-данные и всё необходимое для работы приложения. Но универсального ключа рядом с ними нет.

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

Живой сценарий: один аккаунт на iPhone и Android

Представим приложение с локальными защищёнными данными. Это может быть аутентификатор, корпоративный клиент или любой сервис, которому нужно работать с зашифрованной информацией непосредственно на устройстве.

На iPhone приложение защищает локальный ключ средствами iOS. На Android используется собственный механизм защиты Android. Внутренние ключи устройств разные, и это нормально.

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

Можно было бы создавать отдельные схемы для iOS и Android, пытаться переносить локальные ключи вручную или хранить их копии на сервере.

KeyMeld позволяет отказаться от переноса локальных ключей и хранения их серверных копий, добавляя общий универсальный ключ.

Клиент на iPhone и клиент на Android получают доступ к одному и тому же универсальному ключу в рамках авторизованного проекта и аккаунта. При этом каждый телефон продолжает использовать собственные средства защиты.

Для пользователя это выглядит как единый аккаунт на разных устройствах. Ему не нужно знать, какой механизм работает внутри iPhone и какой используется на Android.

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

Backend участвует в авторизации запроса, но универсальный ключ предназначен авторизованному клиенту и не сохраняется в серверной базе продукта.

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

Три разных типа ключей и секретов

Чтобы не путать разные части архитектуры, достаточно различать три понятия.

• Локальный ключ устройства принадлежит конкретному телефону и обслуживается средствами iOS или Android.

• Универсальный ключ используется авторизованными клиентами одного проекта и аккаунта. Именно он связывает разные платформы на уровне самого продукта.

• Служебный секрет нужен backend для защищённого взаимодействия с KeyMeld. Он не передаётся мобильному приложению или браузеру.

Служебный секрет и универсальный ключ выполняют разные задачи. В архитектуре Zero Vault универсальный ключ не сохраняется в базе продукта рядом со служебными данными backend.

Для работы KeyMeld не требуются имя человека, его пароль, содержимое TOTP-хранилища или бизнес-смысл записей. Сервису важна связка проекта, аккаунта и права клиента получить универсальный ключ.

Доступ к ключу остаётся управляемым

Получение универсального ключа не является безусловным правом любого клиента.

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

Здесь важно не делать слишком широких выводов. Это не означает автоматическое уничтожение уже существующей локальной копии ключа. Речь идёт о контроле дальнейшего получения ключа и подключении новых клиентов.

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

Для разработчика — что такую логику не приходится самостоятельно строить отдельно для iOS и Android. При этом итоговая модель Zero Vault всё равно зависит от того, хранит ли проект универсальный ключ у себя и сохраняет ли разделение между собственной инфраструктурой и внешним SaaS-контуром KeyMeld.

Что KeyMeld не делает

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

Это не замена Apple Keychain или Android Keystore. Сервис оставляет локальные механизмы платформ на своих местах и добавляет общий уровень для продукта.

Это также не обязательный сервис идентификации пользователя. За идентификацию и авторизацию может отвечать отдельный сервис, например MeldID, тогда как KeyMeld решает другую задачу — предоставить авторизованному клиенту единый универсальный ключ, не помещая его в backend самого продукта.

И наконец, KeyMeld не делает Zero Vault автоматически. Он предоставляет проекту внешний контур универсального ключа. Чтобы сохранить эту архитектуру, разработчик не должен помещать универсальный ключ в собственную серверную базу. Независимые доверенные зоны также должны оставаться разделёнными.

Кому это может быть нужно

Такой подход интересен приложениям, которые работают сразу на нескольких платформах и используют локальные защищённые данные.

Это могут быть аутентификаторы, корпоративные приложения, SaaS-продукты, сервисы с несколькими устройствами и любые проекты, где один аккаунт должен одинаково работать на iPhone и Android.

Для разработчика ценность заключается не только в сокращении платформенной логики. Гораздо важнее возможность разделить ответственность. Продуктовый backend хранит свои данные, а KeyMeld как внешний SaaS-сервис предоставляет универсальный ключ и управляет его дальнейшей выдачей.

После знакомства с проектом я бы описал KeyMeld не как готовый Zero Vault, а как инструмент, с помощью которого разработчик может построить такую модель для собственного продукта.

iOS и Android продолжают использовать собственные механизмы защиты. Клиенты получают общий универсальный ключ. А backend приложения, если он не хранит этот ключ у себя и сохраняет разделение между собственной инфраструктурой и KeyMeld, не становится сейфом с ключом от клиентского хранилища.

Для пользователя это означает единый доступ на разных платформах. Для разработчика — возможность вынести универсальный ключ за пределы собственного backend. А для проекта в целом — архитектуру Zero Vault, в которой сервер приложения не хранит ключ от защищённых данных клиента.

Подробнее о проекте: KeyMeld