Технологи

KeyMeld: општи кључ за iPhone и Android и архитектура Zero Vault за пројекат

KeyMeld сам по себи није Zero Vault. То је одвојена SaaS услуга која помаже развојном тиму да извуче универзални кључ изван бэкенда производа, повезује клијенте iOS и 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-у се користи његов механизам за заштиту. Унутрашњи кључеви уређаја су различити, и то је у реду.

Без посебног заједничког слоја, развијач би морао да реши како организовати приступ истим заштићеним подацима на две платформе. Онда би платформски начин чувања остао раздвојен, а производ би морао сам да повезује две реализације.

Могао би да пристане на одвојене шеме за iOS и Android, да ручно преноси локалне кључеве или да их чува у копијама на серверу.

KeyMeld омогућава одсуство преноса локалних кључева и чувања њихових серверских копија, додајући универзални заједнички кључ.

Клијент на iPhone-у и клијент на Android-у добијају приступ истом универзалном кључу у оквиру ауторизованог пројекта и налога. При том, сваки телефон и даље користи свој механизам за заштиту.

За корисника изгледа као да има један налог на различитим уређајима. Не мора да зна који механизам ради унутар iPhone-а и који на Android-у.

При преласку на нови уређај није потребно експортовати локални кључ са старог уређаја или креирати посебну заштићену верзију за нову платформу. Нови клијент се повезује на исти пројекат и добија приступ истом универзалном кључу.

Бэкенд узима учешће у аутентификацији захтева, али универзални кључ је намењен ауторизованом клијенту и не чува се у бази производа.

Сам KeyMeld не преноси базу апликације нити замењује систем синхронизације корисничких записа. Његова улога је јасна: пружити клијенту кључ који је потребан за рад са заштићеним подацима. Оквирак хранилиšta и његово ажурирање остају одговорност саме апликације.

Да би се избегла конфузија у архитектури, довољно је разликовати три појма.

  • Локални кључ уређаја припада одређеном телефону и заштићен је средствима iOS или Android-а.

  • Универзални кључ се користи ауторизованим клијентима истог пројекта и налога. Он повезује различите платформе на нивоу саме апликације.

  • Службена тајна потребна је за безбедну комуникацију бэкенда са KeyMeld-ом. Она се не преноси у мобилну апликацију или браузер.

Службена тајна и универзални кључ имају различите намене. У Zero Vault архитектури, универзални кључ се не чува у бази производа поред службених података бэкенда.

Да би KeyMeld радио, не требају нам име особе, његова лозинка, TOTP складиште или пословни садржај записа. Важно је да постоји веза између пројекта, налога и овлашћења да корисник добије универзални кључ.

Приступ кључу остаје под контролом

Добијање универзалног кључа није аутоматско право сваког корисника.

Ако уређај више није поверења вредан, ако се промени статус налога или ако тим повуче приступ пројекту, KeyMeld може престати да даје универзални кључ том клијенту.

Важно је избегавати претеране закључке. Ово не значи автоматско брисање већ постојеће локалне копије кључа. Ради се о контролисаном даљем добијању кључа и нових клијената.

За корисника то значи да управљање новим уређајима и њихов приступ кључу функционише као једна интегрисана система.

За развојног инжењера — ове логике не треба самостално развијати за iOS и Android. Међутим, коначна Zero Vault архитектура зависи и од тога да ли пројекат чува универзални кључ код себе и одвојено одржава између своје инфраструктуре и спољног SaaS контура KeyMeld.

Шта KeyMeld не ради

KeyMeld није менаџер лозинки и не чува корисничке TOTP записе. Он не постаје облачна база података апликације и не замењује систем синхронизације садржаја.

Ово није замена за Apple Keychain или Android Keystore. Услуга оставља локалне механизме платформи на месту и додаје заједнички ниво за производ.

Није ни даљња замена за Zero Vault. Он пружа спољни контур универзалног кључа. Да би архитектура била таква, развојни тим не треба да чува универзални кључ у својој серверској бази. Исто тако, засебне поверење зоне требају остати раздвојене.

Коме може бити корисно

Тај приступ је погодан за апликације које раде на више платформи и користе локално заштићене податке.

То могу бити аутентификатори, корпоративне апликације, SaaS производи, сервиси са више уређаја и сви пројекти у којима један налог треба да ради на iPhone и Android истовремено.

За развојног тима, поента није само у смањењу платформске логике. Важније је делити одговорности. ПРОДУКТ бэкенд чува своје податке, а KeyMeld као спољни SaaS сервис пружа универзални кључ и управља његовим даљим преносом.

После упознавања са пројектом, могу рећи да је KeyMeld више алат за изградњу архитектуре него готово решење Zero Vault. То је начин да развојни тим креира такву структуру за свој производ.

iOS и Android настављају да користе сопствене механизме за заштиту. Клијенти добијају заједнички универзални кључ. А бэкенд апликације, ако не чува овај кључ у свом окружењу, јер одржава раздвојеност између своје инфраструктуре и KeyMeld-а, не постаје сигурносни ваулт са приватним кључем.

За корисника то значи један приступ за различите платформе. За развојног тима — приступ да извуче универзални кључ изван свог бэкенда. А за целокупни пројекат — архитектура Zero Vault у којој сервер производа не чува кључ од заштићених података корисника.

Детаљи о пројекту: KeyMeld