KeyMeld: Pangkalahatang Susi para sa iPhone at Android at Zero Vault na Arkitektura para sa Proyekto

May problema ang mga cross-platform na aplikasyon na karaniwang hindi napapansin ng gumagamit. Nakikita nila sa screen ang isang account at inaasahan na parehong gagana nang pareho sa kahit anong device. Ngunit sa loob, ginagamit ng iPhone at Android ang magkaibang mekanismo ng proteksyon at magkaibang paraan ng paghawak sa mga lokal na susi.

Sa iPhone, maaaring protektahan ng app ang lokal na susi ng device gamit ang Apple Keychain. Sa Android naman, ginagamit ang Android Keystore. Ang mga teknolohiyang ito ay idinisenyo upang panatilihing nasa ligtas na kapaligiran ng device ang mga sensitive na susi, ngunit hindi sila pwedeng mapalitan o mapalitan ng magkaparehong paraan.

Para sa user, walang halagang malaman ito. Gusto lang niyang mabuksan ang app sa iPhone, pagkatapos ay gamitin ito sa Android, at magpatuloy sa trabaho gamit ang parehong protektadong data.

Sa bahagi ng developer, may isang arkitektural na tanong: paano magbibigay ng shared na access sa dalawang platform nang hindi kailangang ilipat ang mga lokal na susi ng device o ilagay ang mga kopya nito sa database ng kanilang sariling backend?

Sa pag-aaral tungkol sa KeyMeld, nakita ko na nag-aalok ang serbisyo ng isang hiwalay na unibersal na susi para dito, nang hindi nakikialam sa panloob na proteksyon ng iOS at Android.

Pangkalahatang Susi para sa Iba't Ibang Platform

Ang lokal na susi ng device ay nauukol sa isang partikular na telepono at pinoprotektahan ito gamit ang panukala ng kani-kaniyang operating system. Nananatili ito sa ligtas na kapaligiran ng isang device at hindi ito naka-design para sa malayang paglilipat sa pagitan ng mga device.

Ang unibersal na susi ng KeyMeld ay ibang entidad. Ito ay nilikha para sa isang partikular na proyekto, account, at protektadong espasyo, at nagiging pangkalahatan para sa mga authenticated na kliyente sa iba't ibang platform.

Hindi kinukuha ng serbisyo ang susi mula sa iPhone, hindi ito inilipat sa Android, at hindi sinusubukang pag-isahin ang dalawang magkaibang susi. Mananatiling hiwalay ang platform-specific na proteksyon, at makakatanggap ang app ng isang pangkalahatang antas ng access para sa kanilang proyekto.

Ito mismo ang naglalarawan sa arkitektural na papel ng KeyMeld. Hindi nito pinapantay ang iOS at Android o pinapalitan ang kanilang mga panloob na mekanismo. Nagdaragdag ito ng isang pangkalahatang lebel ng pakikitungo sa unibersal na susi, na hindi nangangahulugang kailangang i-manage ng proyekto ang cross-platform na distribusyon nito nang sariling kakayahan.

Para sa iba't ibang produkto at account, nililikha ang mga hiwalay na core ng mga susi. Kaya, bawat proyekto ay nagsisiguro ng sariling waveform ng access, at nananatiling hiwalay ang maraming account sa isang device.

Zero Vault ay Pag-aari ng Proyekto

Kaagad na linawin: ang Zero Vault ay hindi pangalan mismo ng KeyMeld. Ito ay isang arkitektural na modelo na pwedeng buuin ng isang bahagi ng konektadong produkto.

Ang KeyMeld ay gumagana bilang isang hiwalay na SaaS na serbisyo. Hindi ito ini-install sa loob ng backend ng app, ni inilalagay malapit sa database ng proyekto bilang isang karagdagang module. Ang unibersal na susi ay pinapatakbo sa isang hiwalay na SaaS core ng KeyMeld, sa labas ng backend mismo ng produkto.

Para mapanatili ang ganitong modelo, ang mga boundary ng tiwala sa pagitan ng proyekto at ng KeyMeld ay kailangang manatiling hiwalay. May sarili silang mga kredensyal, karapatan sa pag-access, at mga mekanismo para sa pamamahala.

Ang ganitong resulta sa arkitektura ang maaaring tawaging Zero Vault: ang server-side na database nito ay hindi nag-iingat ng susi mula sa client-side na ligtas na storage.

Hindi nangangahulugan na ang backend ng produkto ay hindi nag-iingat ng kahit anong bagay. Mananatili dito ang mga account, mga setting, business data, at lahat ng kailangan upang gumana ang app. Ngunit walang unibersal na susi na katabi nito.

Ang posibleng kompromiso sa server-side database ng produkto ay hindi awtomatikong magbubunyag sa unibersal na susi: hindi ito nakatago kasama ng mga account o iba pang server-side na data. Ngunit, ang modelong ito ay hindi nangangahulugang walang panganib—natutugunan lang nito ang isang partikular na layunin, na alisin ang unibersal na susi mula sa client storage sa database ng mismo ng produkto.

Aktwal na Scenario: Isang Account sa iPhone at Android

Ilarawan natin ang isang aplikasyon na may lokal na protektadong data. Maaaring itong isang authenticator, isang corporate client, o isang serbisyo na kailangang magtrabaho sa encrypted na impormasyon sa mismong device.

Sa iPhone, minoprotektahan ng app ang lokal na susi gamit ang panukala ng iOS. Sa Android, ginagamit ang sariling mekanismo ng proteksyon. Magkaibang mga lokal na susi ang ginagamit ng mga device, at ito ay normal.

Kung walang isang hiwalay na common layer, kailangang lutasin ng developer kung paano ayusin ang access sa parehong protektadong data sa dalawang platform. Mananatiling magkakaiba ang platform-specific na storage, at kakailanganin ng app na i-handle ang magkakaibang mga implementasyon.

Maaaring gumawa ng hiwalay na schema para sa iOS at Android, subukang i-manually transfer ang mga lokal na susi, o mag-imbak ng kopya nito sa server.

Pinapayagan ng KeyMeld na iwasan ang paglilipat ng mga lokal na susi at ng kanilang server-side na mga kopya, sa pamamagitan ng pagdaragdag ng isang unibersal na susi.

Makakatanggap ang client sa iPhone at Android ng isang shared na access sa isang unibersal na susi sa ilalim ng isang authenticated na proyekto at account. Samantala, ginagamit pa rin nila ang kani-kanilang mga lokal na mekanismo ng proteksyon.

Para sa user, parang isang account lang sa iba't ibang device ang hitsura. Hindi niya kailangang alam kung aling mekanismo ang ginagamit sa iPhone at sa Android.

Sa pagpapalit ng device, hindi kailangang mag-export ng lokal na susi mula sa lumang device o gumawa ng bagong protektadong storage para sa bagong platform. Kumokonekta ang bagong client sa parehong proyekto at nakakatanggap ng access sa parehong unibersal na susi.

Ang backend ay nakikibahagi sa pag-autorize ng request, ngunit ang unibersal na susi ay para lang sa na-validate na client at hindi ito iniimbak sa database mismo ng produkto.

Ang KeyMeld mismo ay hindi naglilipat ng database ng app, ni pinapalitan ang synchronization system ng user records. Ang pangunahing tungkulin nito ay magbigay ng susi na kinakailangan para sa pag-access sa protektadong data. Ang laman ng storage at mga update nito ay responsibilidad pa rin ng mismo ng produkto.

Tatlong Uri ng Susi at Sekreto

Upang maiwasan ang kalituhan sa arkitektura, sapat na malaman ang tatlong pangunahing konsepto.

• Lokal na susi ng device ay nauukol sa isang partikular na telepono at pinoprotektahan ito gamit ang iOS o Android.

• Unibersal na susi ay ginagamit ng mga authenticated na client ng isang proyekto at account. Siya ang nag-uugnay sa magkaibang platform sa antas ng mismo ng produkto.

• Sekretong pang-operasyon ay ginagamit ng backend para sa ligtas na interaksyon sa KeyMeld. Hindi ito ipinapasa sa mobile app o browser.

Magkaibang mga sekretong pang-operasyon at unibersal na susi ang kanilang mga layunin. Sa arkitektura ng Zero Vault, hindi iniimbak ang unibersal na susi sa database ng produkto malapit sa mga sekretong pang-backend.

Hindi kailangan ng KeyMeld ang pangalan ng user, password, TOTP storage, o mga business record. Mahalaga sa serbisyo ang pagkakaugnay-ugnay ng proyekto, account, at karapatan ng client na makuha ang unibersal na susi.

Kontroladong Access sa Susi

Hindi awtomatiko ang pagbibigay ng unibersal na susi sa bawat client.

Kung ang device ay itinuturing nang hindi ninyong mapagkakatiwalaan, nagbago ang status ng account, o inatras ang access sa proyekto, maaaring ihinto ng KeyMeld ang karagdagang pagbibigay ng unibersal na susi sa client na iyon.

Huwag agad-agad na maghinuha. Hindi ito nangangahulugang awtomatikong i-wipe ang kasalukuyang lokal na kopya ng susi. Pinapamahalaan lang nito ang susunod na pagkuha at pagkukonekta ng mga bagong client.

Para sa user, nangangahulugan ito na ang pag-link ng mga bagong device at kanilang access sa susi ay isang sistema.

Para sa developer, nangangahulugan ito na hindi kailangang hiwalay na magpatupad ng ganitong logic sa iOS at Android. Ngunit, ang final na modelo ng Zero Vault ay nakasalalay pa rin kung ang proyekto ay nagtago ng unibersal na susi sa kanilang sariling infrastructure at kung may paghiwalay pa rin ng kanilang ecosystem at sa external na SaaS core ng KeyMeld.

Hindi Kayang Gawin ng KeyMeld

Hindi ang KeyMeld ay isang manager ng password o nag-iimbak ng user TOTP records. Hindi rin ito nagiging cloud database ng app o pumapalit sa synchronization ng mga record nito.

Hindi ito isang kapalit ng Apple Keychain o Android Keystore. Mananatili pa rin ang mga lokal na mekanismo ng platform, at nagdaragdag lamang ito ng isang pangkalahatang lebel para sa produkto.

Hindi rin ito isang mandatory na serbisyo para sa pagkilala sa user. Maaari kang gumamit ng hiwalay na serbisyo, tulad ng MeldID, para sa authentication at authorization, habang ang KeyMeld ay nakatuon lang sa pagbibigay ng unibersal na susi sa na-validate na client nang hindi ito inilalagay sa sariling backend ng app.

Sa huli, hindi awtomatikong ginagawang Zero Vault ng KeyMeld. Nagbibigay lamang ito ng external na core ng unibersal na susi para sa proyekto. Upang mapanatili ang arkitektura, hindi kailangang ilagay ng developer ang unibersal na susi sa kanilang personal na database. Ang hiwalay na trusted zones ay kailangan pa ring panatilihin na hiwalay.

Sino ang maaaring makinabang dito

Ang ganitong paraan ay akma sa mga app na nagtatrabaho sabay-sabay sa maraming platform at gumagamit ng lokal na protektadong data.

Puwede itong maging mga authenticator, enterprise applications, SaaS products, services na may maraming device, at anumang proyekto kung saan isang account ang kailangang gumana nang pantay sa iPhone at Android.

Para sa developer, malaking benepisyo ang hindi lang sa pagbabawas ng platform-specific logic. Mas mahalaga ang paghihiwalay ng responsibilidad: ang backend ng produkto ay nag-iingat ng sarili nitong data, habang ang KeyMeld bilang isang external SaaS ay nag-aalok ng unibersal na susi at namamahala sa mga access nito sa hinaharap.

Pagkatapos kong makilala ang proyekto, masasabi ko na ang KeyMeld ay hindi isang handang Zero Vault, kundi isang tool na pwedeng gamitin ng developer para makabuo ng ganitong modelo para sa kanilang sariling produkto.

Patuloy na gagamitin ng iOS at Android ang kani-kanilang mga mekanismo ng proteksyon. Ang mga client ay makakatanggap ng isang pangkalahatang unibersal na susi. At ang backend ng app, kung hindi ito nag-iimbak ng susi at naghihiwalay sa kanilang ecosystem at sa sa exte rnalk na SaaS core ng KeyMeld, ay hindi magiging safep na pinanggagalingan ng susi mula sa client storage.

Para sa user, nangangahulugan ito ng isang pinagsamang access sa iba't ibang platform. Para sa developer, isang paraan ito para mailabas ang unibersal na susi mula sa kanilang sariling backend. At para sa buong proyekto, isang arkitektura ng Zero Vault na ang server ay hindi nag-iimbak ng susi mula sa protected client data.

Para sa karagdagang impormasyon tungkol sa proyekto: KeyMeld