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

Кросплатформените приложения имат проблем, който потребителите обикновено не забелязват. На екрана виждат един акаунт и очакват еднакво функциониране на всяко устройство. Но вътрешно iPhone и Android използват различни механизми за защита и по различен начин работят с локалните ключове.

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

За потребителя това няма значение. Той просто иска да отвори приложението на iPhone, след това да го инсталира на Android и да продължи работа с едни и същи защитени данни.

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

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

Общ ключ за различни платформи

Локалният ключ на устройството се отнася за конкретния телефон и се защитава със средствата на съответната операционна система. Той остава в защитена среда на устройството и не е предназначен за свободен пренос между устройства.

Универсалният ключ на KeyMeld е друга концепция. Той се създава за конкретен проект, акаунт и защитена среда и става общ за авторизираните клиенти на различни платформи.

Услугата не взима ключ от iPhone, не го пренася на Android и не опитва да съчетае двата различни ключа в един. Платформената защита си остава независима, а приложението получава общо ниво на достъп за своя проект.

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

За различните продукти и акаунти се създават независими контури на ключове. Така всеки проект запазва своята собствена област на достъп, а няколко акаунта на един и същ апарат остават разделени.

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

Първо, важно е да уточним: Zero Vault не е името на самия KeyMeld. Това е архитектурен модел, който може да бъде построен от свързан продукт.

KeyMeld работи като отделна SaaS услуга. Не се инсталира вътре в бекенда на приложението и не се поставя до базата данни като още един компонент. Универсалният ключ се обслужва в отделен SaaS контур на KeyMeld, извън бекенд системата на самия продукт.

За да се запази тази модел, границите на доверие между проекта и KeyMeld трябва да останат независимо разделени. За бекенда на приложението и външната услуга се използват отделни идентификационни данни, права и механизми за администриране.

Точно такъв резултат в архитектурата на проекта може да бъде обозначен като модел Zero Vault: сървърната му база не съхранява ключа от клиентското защитено хранилище.

Zero Vault не означава, че бекендът на продукта изобщо не съхранява нищо. Там остават акаунти, настройки, бизнес данни и всичко необходимо за функциониране на приложението. Но около тях няма универсален ключ.

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

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

Да предположим приложение с локални защитени данни. Това може да е удостоверител, корпоративен клиент или всяка услуга, която трябва да работи с криптирана информация директно на устройството.

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

Без отделен общ слой разработчикът щеше да трябва да реши как да организира достъпа до едни и същи защитени данни на двете платформи. Платформеното съхранение щеше да остане различно, а продуктът трябва да сам да се справя с обединяването им.

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

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

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

За потребителя това изглежда като единен акаунт на различни устройства. Той не трябва да знае кой механизъм работи вътре в iPhone и кой – на Android.

При смяна на устройство не е необходимо да се експортира локалният ключ от старото устройство или да се създава отделна версия на защитеното хранилище за новата платформа. Новият клиент се свързва към същия проект и получава достъп до същия универсален ключ.

Бекендът участва в авторизацията на заявката, но универсалният ключ е предназначен за авторизиран клиент и не се съхранява в сървърната база на продукта.

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

Три различни вида ключове и тайни

За да се различават различните части на архитектурата, е достатъчно да се разберат три понятия.

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

• Универсален ключ се използва от авторизираните клиенти на един проект и профил. Той свързва различни платформи на ниво продукта.

• Служебна тайна е необходима на бекенда за сигурна комуникация с KeyMeld. Тя не се предава на мобилното приложение или браузъра.

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

За работа на KeyMeld не се изисква име, парола, съдържание на TOTP-хранилището или бизнес смисъл на записите. Услугата е важна само за свързването на проект, акаунт и правата на клиента да получи универсален ключ.

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

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

Ако устройството престане да се счита за доверено, статутът на акаунта се промени или екипът оттегли достъпа до проекта, KeyMeld може да спре издаването на универсалния ключ на този клиент.

Важно е да се правят предпазливи изводи. Това не означава автоматично унищожаване на съществуващата локална копия на ключа. Говорим за контрол върху по-нататъшното получаване на ключа и добавянето на нови клиенти.

За потребителя това означава, че свързването на нови устройства и управлението на достъпа им до получаване на ключ е част от една система.

За разработчика — че такава логика не трябва да се изгражда отделно за iOS и Android. Итоговата модел Zero Vault все пак зависи дали проектът съхранява универсалния ключ при себе си и дали поддържа разделянето между своя инфраструктура и външния SaaS кантур на KeyMeld.

Какво не прави KeyMeld

KeyMeld не е мениджър на пароли и не съхранява потребителските TOTP-записи. Не става облачна база данни за приложението и не замества синхронизацията на неговото съдържание.

Това не е заместител на Apple Keychain или Android Keystore. Услугата оставя вътрешните механизми на платформите си на мястото и добавя общ слой за продукта.

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

И накрая, KeyMeld не прави автоматично Zero Vault. Той предоставя на проекта външен контур на универсалния ключ. За да се запази тази архитектура, разработчикът не трябва да поставя универсалния ключ в собствената си сървърна база данни. Независимите доверени зони също трябва да останат разделени.

За кого е подходящо

Тази концепция е интересна за приложения, работещи на повече от една платформа и използващи локални защитени данни.

Това могат да бъдат удостоверители, корпоративни приложения, SaaS продукти, услуги с няколко устройства и всякакви проекти, където един акаунт трябва да работи еднакво на iPhone и Android.

За разработчика стойността не се ограничават само до намаляване на платформената логика. Значимо е възможността за делегиране на отговорност. Продуктовият бекенд съхранява своите данни, а KeyMeld като външен SaaS услуга предоставя универсалния ключ и управлява неговото раздаване.

След запознаване с проекта бих описал KeyMeld не като готов Zero Vault, а като инструмент с който разработчикът може да построи такава модел за свой продукт.

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

За потребителя това означава единен достъп на различни платформи. За разработчика — възможност да изведе универсалния ключ извън собствената си бекенд система. А за цялостния проект — архитектура Zero Vault, при която сървърът на приложението не съхранява ключа за клиентските защитени данни.

Повече за проекта: KeyMeld