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