Bakit poprotektahan ang password kung maaari namang hindi na gumamit nito?

Isang problemang nakasanayan na nating ituring na normal

Halos lahat ng web application ay may admin panel. At karaniwan, may login address, form ng pagpapatotoo, username, at password ang admin panel.

Sanay na sanay na tayo sa ganitong ayos kaya halos hindi na natin itinatanong: kailangan ba talagang ganito gumana ang lahat?

Kapag iisa lang ang website mo, hindi gaanong mabigat ang problema. Gumawa ka ng malakas na password, nag-on ng two-factor authentication, nagtakda ng limitasyon sa mga pagtatangkang mag-login — at tuloy na ang trabaho.

Pero ano ang mangyayari kapag umabot na sa sampu, dalawampu, o tatlumpu ang mga proyekto?

Sa kaso ko, ang pinag-uusapan ay ang DigiMeld ecosystem, na binubuo ng mahigit tatlumpung magkakahiwalay na software project. May kanya-kanyang arkitektura, lohika sa server, at administratibong interface ang bawat isa.

Dahil dito, kailangan ng bawat isa ng mekanismo para sa administratibong access.

Matagal akong gumamit ng karaniwang paraan: magkakahiwalay na administratibong kredensyal, malalakas na password, at pag-save ng mga ito sa browser.

Gumana naman ito.

Pero dumating ang panahong naisip ko: bakit kailangan ko talagang mag-imbak ng napakaraming administratibong password? Bakit kailangan kong protektahan hindi lang ang mga server kundi pati ang mga paraan para makakuha ng access sa mga ito?

At maaari ko bang tuluyang alisin ang pangangailangang iyon?

Naisip ko ang isang bagay na kalaunan ay naging pundasyon ng solusyon ko:

Baka mas mainam na protektahan hindi ang palaging nakahandang login, kundi ang karapatang pansamantalang makakuha ng access.

Paano kung wala talagang nakasanayang pahina ng pag-login?

Pinili kong talikuran ang tradisyonal na modelo ng administratibong pagpapatotoo sa mga proyekto ko.

Hindi lang itago ang login form.

Hindi lang palitan ang address.

Hindi lang palitan ang password ng mas mahirap pang password.

Kundi alisin ang mismong pangangailangang magkaroon ng palaging umiiral na pag-login gamit ang password.

Siyempre, hindi naman nawala ang mga administratibong interface. Kailangan pa rin ang mga ito para pamahalaan ang mga application.

Ang nagbago ay ang paraan ng pagkuha ng access sa mga ito.

Ngayon, hindi na kailangang maglagay ng naka-save na username at password para makapag-login sa mga administratibong panel ng mga konektadong proyekto.

Sa halip, ginagamit ko ang sarili kong sistema ng pagkakakilanlan at pamamahala ng access na MeldID.

Simple lang ang ideya: ibinibigay lang ang administratibong access kapag talagang kailangan ito, sa partikular na user at para sa partikular na proyekto.

At ang pagkakaroon lang ng account ay hindi nangangahulugang may karapatan nang buksan ang administratibong panel.

Kailangang ibigay nang hiwalay ang karapatang iyon.

Access na wala pa isang minuto ang nakalipas

Marahil ito ang pinakakawili-wiling bahagi ng buong konsepto.

Sa tradisyonal na modelo, palaging may paraan ang administrator para mag-login. Maaari niya itong gamitin ngayon, bukas, o makalipas ang isang buwan, habang valid pa ang mga kredensyal na iyon.

Pinili kong baguhin ang prinsipyong ito.

Sa halip na permanenteng administratibong kredensyal, gumagamit ako ng pansamantalang kakayahang magsimula ng proseso ng pag-login.

Gumagawa nito kapag hiniling sa pamamagitan ng isang pinagkakatiwalaang mobile device. Mayroon itong cryptographically secure na random na bahagi at limitadong validity period.

Pero kahit hawak mo ang pansamantalang link, hindi pa rin ibig sabihin nito na may access ka na.

Mahalagang punto ito.

Ipagpalagay nating may nakakuha ng link sa anumang paraan. Sa isang karaniwang sistemang nakasalalay lamang sa pagiging lihim ng address, maaaring maging seryosong problema ang ganitong pagtagas.

Sa modelo ko, pinapayagan lang ng link na simulan ang proseso ng pagkumpirma.

Para magpatuloy, kailangan ng hiwalay na pahintulot sa pamamagitan ng pinagkakatiwalaang mobile device na may MeldID.

Kung walang kaukulang kumpirmasyon, hindi gagawa ng administratibong session.

Kaya hindi ko itinuturing ang pansamantalang link bilang pamalit sa password, kundi bilang isa sa mga bahagi ng proseso ng pagbibigay ng access.

Magkaibang-magkaiba ang malaman kung saan pupunta at magkaroon ng karapatang pumasok.

Nagiging kasangkapan sa pamamahala ng access ang telepono

Sa modelong ito, mas mahalaga ang papel ng mobile device kaysa sa karaniwang generator ng mga one-time code.

Ginagamit ito para kumpirmahin ang mga pagkilos na may kaugnayan sa administratibong access.

Kapag gusto kong buksan ang administratibong panel, humihingi ang sistema ng kumpirmasyon sa pamamagitan ng MeldID.

Nakikita ko ang kaukulang kahilingan sa pinagkakatiwalaang device at kinukumpirma ko ang pagkilos.

Pagkatapos lamang ng matagumpay na pagsusuri pinapayagan ng sistema na magpatuloy ang proseso ng pag-login.

Nakaugnay ang kumpirmasyon sa partikular na pagkilos, hindi lang sa katotohanang na-unlock ang telepono.

Sinusuri ng mobile biometrics ang user sa mismong device, samantalang sinusuri naman ng server ang cryptographic confirmation mula sa nakarehistrong device.

Sa ganitong paraan, hindi kailangang umasa lamang sa password o sa mensaheng nagsasabing kuno ay kinumpirma ng user ang pag-login.

May isa pang pakinabang dito: maaaring pamahalaan ang mga pinagkakatiwalaang device.

Kung hindi na dapat gamitin ang isang device para kumpirmahin ang access, maaari nang bawiin ang pinagkakatiwalaang status nito.

Pagkatapos nito, hindi na ito magsisilbing valid na paraan ng pagpapatotoo para sa mga kaukulang operasyon.

Iisang sistema — maraming magkakahiwalay na proyekto

Nang simulan kong buuin ang mekanismong ito, isa sa mga pangunahing layunin ko ang mapanatili ang kasarinlan ng bawat proyekto.

Ayaw kong pagsamahin ang lahat ng administratibong panel sa iisang napakalaking application.

Dapat patuloy na pamahalaan ng bawat serbisyo ng DigiMeld ang sarili nitong lohika, mga setting, user, at data.

Kaya pinaghiwalay ko ang dalawang gawain.

Responsable ang MeldID sa pagkakakilanlan at pagbibigay ng pahintulot para sa administratibong access.

Samantala, ang bawat proyekto mismo ang namamahala sa sarili nitong mga administratibong function at nagsusuri kung may bisa pa ang mga pahintulot.

Nabuo ang isang sentralisadong modelo ng pamamahala ng access nang hindi kailangang isentralisa ang mga application mismo.

Higit pa rito, magkakahiwalay na ibinibigay ang mga pahintulot.

Hindi awtomatikong nagkakaroon ng access sa iba pang proyekto ang administrator ng isang proyekto dahil lang mayroon siyang MeldID account.

Maaaring magtakda ng magkakahiwalay na grupo ng mga awtorisadong user para sa bawat administratibong bahagi.

Magkahiwalay din ang mga karapatan ng karaniwang user at ang mga administratibong kapangyarihan.

Lalo itong naging kapaki-pakinabang para sa isang ecosystem na may dose-dosenang serbisyo.

Bakit mas gusto ko ang pansamantalang access kaysa sa permanente

May isa pang prinsipyong sinadya kong isama sa sistema.

Hindi dapat manatili nang walang hanggan ang administratibong access.

May takdang tagal ang pahintulot at awtomatiko itong nawawalan ng bisa, kahit patuloy pang ginagamit ng user ang browser.

Para makapagpatuloy sa pagtatrabaho kapag natapos na ang validity period, kailangan ng panibagong proseso ng kumpirmasyon.

Sa ganitong paraan, hindi nagiging permanenteng karapatan ang isang beses na pagpapatotoo.

Pero hindi sapat ang pagtatakda lang ng limitasyon sa oras.

Mahalaga ring maagang wakasan ang access na naibigay na.

Kaya may sentralisadong mekanismo ang MeldID para bawiin ang mga administratibong pahintulot.

Kapag binawi ang pahintulot, natatanggap ng mga konektadong proyekto ang kaukulang event at kinakansela nila ang mga kaugnay na administratibong session.

Ibig sabihin, hindi natatapos ang pamamahala ng access sa sandaling matagumpay nang nakapag-login ang user.

Para sa akin, kasinghalaga ng kakayahang magbigay ng mga kapangyarihan ang kakayahang bawiin ang mga ito.

Gayunman, kailangang isaalang-alang ng isang distributed system ang mga pagkaantala sa pagpapadala ng mga event, pansamantalang hindi pagiging available ng ilang component, at iba pang sitwasyong maaaring mangyari sa operasyon. Nagsisilbing karagdagang pananggalang ang limitadong validity period ng mga session.

Ano ang nagbago sa pang-araw-araw na trabaho?

Una sa lahat, hindi ko na kailangang palaging gamitin ang mga naka-save na administratibong password.

Hindi ko na kailangang magtago sa browser ng magkakahiwalay na kredensyal para makapag-login sa bawat konektadong administratibong panel.

Sa halip, pinamamahalaan ko ang mga pahintulot sa pamamagitan ng iisang mekanismo.

Pinipili ko ang proyektong kailangan ko, kinukumpirma ang access, at nagtatrabaho na.

Kapag hindi na kailangan ang administratibong access, maaari ko itong bawiin.

Lalo nang maginhawa na kapag may bagong proyekto, hindi na kailangang muling idisenyo ang buong sistema ng administratibong pagpapatotoo.

Sapat nang ikonekta ito sa umiiral na modelo at tukuyin ang mga kailangang pahintulot.

Siyempre, hindi ibig sabihin nito na nawala na ang lahat ng panganib sa seguridad.

Kailangan ding protektahan ang mga pansamantalang pahintulot, pinagkakatiwalaang device, mga session sa server, at sentral na imprastraktura.

Pero hindi ko na kailangang lutasin nang hiwalay sa bawat application ang iisang problema ng pamamahala ng mga administratibong password.

At isa iyon sa mga orihinal kong layunin.

Hindi ba umiiral na ang ganitong mga teknolohiya?

Oo, umiiral na ang mga ito.

Matagal nang kilala sa industriya ng seguridad ng impormasyon ang passwordless authentication, privileged access management, mga pansamantalang pahintulot, at pagkumpirma sa pamamagitan ng mga pinagkakatiwalaang device.

Makikita ang ganitong mga pamamaraan sa mga sistema ng Identity and Access Management, Privileged Access Management, at mga konsepto ng Zero Trust.

Hindi ko inaangking ako ang nag-imbento ng mga prinsipyong ito.

Iba ang layunin ko.

Kailangan kong gumawa ng sarili kong integrated system na lulutas sa mga partikular na problema ng imprastraktura ng DigiMeld at magbibigay-daan sa pamamahala ng administratibong access para sa maraming magkakahiwalay na proyekto.

Sa huli, pinagsama ko ang ilang kilalang pamamaraan sa iisang arkitekturang tumutugon sa mga pangangailangan ko.

Naniniwala akong hindi laging nakasalalay sa pag-imbento ng ganap na bagong teknolohiya ang halaga ng gawaing pang-inhinyeriya.

Minsan, nasa tamang pagtukoy ito sa problema at paghahanap ng angkop na solusyon.

Hindi lang para sa mga administratibong panel ang MeldID

Narito ang isang mahalagang paglilinaw.

Hindi ginawa ang MeldID para lang maging kasangkapan sa sarili kong administratibong access.

Nagbibigay rin ito sa mga developer ng SDK para maisama nila sa sarili nilang mga application ang mga mekanismo ng pagkakakilanlan at pagkumpirma sa pag-login.

At libre ang SDK na ito.

Halimbawa, maaaring gamitin ng isang third-party developer ang MeldID bilang karagdagang antas ng kumpirmasyon sa pagpapatotoo ng user.

Kahit gumagamit pa rin ang application ng tradisyonal na pag-login gamit ang username at password, maaaring hindi sapat ang matagumpay na paglalagay ng mga kredensyal na ito para makumpleto ang pagpapatotoo.

Makakatanggap ang user ng kahilingan sa pinagkakatiwalaang mobile device, kung saan maaari niyang kumpirmahin o tanggihan ang pagtatangkang mag-login.

Makakatulong ito na mabawasan ang panganib ng hindi awtorisadong access kapag nakompromiso ang mga kredensyal.

Mahalagang pag-ibahin ang pampublikong kakayahang ito ng MeldID at ang modelong administratibong access na binuo ko para sa mga proyekto ng DigiMeld.

Magkapareho ang mga prinsipyong ginagamit nila tungkol sa tiwala at pagkumpirma ng mga pagkilos, pero magkaiba ang mga problemang nilulutas nila.

Hindi lang pagprotekta sa umiiral na ang seguridad

Dahil sa paggawa sa sistemang ito, nagbago ang pananaw ko sa mga nakasanayang mekanismo ng pagpapatotoo.

Madalas nating sinusubukang protektahan ang mga bagay na umiiral dahil lang sa mga dahilan sa kasaysayan.

Nagdaragdag tayo ng mga bagong pagsusuri, limitasyon, dagdag na password, at pananggalang.

Minsan, talagang kailangan ang mga ito.

Pero kung minsan, mas kapaki-pakinabang na magtanong ng ibang bagay:

Kailangan ba talagang manatili sa dating anyo ang mismong mekanismong pinoprotektahan natin?

Sa kaso ko, hindi ang sagot.

Hindi ko kailangan ng administratibong login form na laging available.

Kailangan ko ng ligtas na paraan para makakuha ng mga administratibong kapangyarihan sa mismong oras na kailangan ko ang mga ito.

Dalawang magkaibang gawain ang mga ito.

At ang paglipat mula sa una patungo sa ikalawa ay nagpabago hindi lang sa teknikal na arkitektura kundi pati sa pang-araw-araw na pagtatrabaho ko sa mga proyekto.

Hindi ito pangwakas na hakbang, kundi ang direksiyong pinili

Gumagana na ngayon ang arkitekturang ito sa malaking bahagi ng DigiMeld ecosystem.

Unti-unting inililipat sa bagong modelo ng administratibong access ang mga natitirang proyekto.

Isinasagawa ko ang migration nang paisa-isa, sinusuri ang bawat application, at pagkatapos makumpleto ang paglipat ay plano kong magsagawa ng karagdagang audit sa buong sistema.

Maaari pang magbago ang ilang elemento ng interface at mga panuntunan sa pamamahala ng session.

Pero malinaw na ang pangunahing ideya.

Ayaw kong bumalik sa modelong kailangan kong palaging mag-imbak at gumamit ng dose-dosenang administratibong password para pamahalaan ang dose-dosenang sarili kong proyekto.

Gayunman, hindi ko itinuturing ang sarili kong implementasyon bilang solusyong angkop para sa lahat.

Iba-iba ang pangangailangan, imprastraktura, mga modelo ng banta, at paraan ng pamamahala ng bawat organisasyon.

Maaaring maginhawa at makatuwiran para sa DigiMeld ecosystem ang isang pamamaraan, pero hindi ibig sabihin na ito rin ang pinakamainam para sa ibang developer.

Gayunman, nararapat bigyang-pansin ang mismong prinsipyo ng pansamantalang pagbibigay ng mga kapangyarihan.

Bilang pangwakas

Pinili kong ibahagi ang karanasang ito hindi dahil iniisip kong nakaimbento ako ng bagong paraan ng pagpapatotoo.

At hindi rin dahil gusto kong ipakita ang panibagong sistema bilang ganap na ligtas.

Walang ganap na seguridad.

Interesante lang para sa akin ang mismong paraan ng paglalatag ng tanong.

Sa halip na walang katapusang protektahan ang permanenteng administratibong login, maaari nating muling suriin kung kailangan ba talaga itong umiral.

Sa halip na mag-imbak ng napakaraming password — gumamit ng mga pansamantalang pahintulot.

Sa halip na awtomatikong magtiwala pagkatapos ng unang pagpapatotoo — kumpirmahin ang pagbibigay ng mga partikular na kapangyarihan.

Sa halip na hintaying matapos ang session — maglaan ng kakayahang bawiin ang access sa sentral na paraan.

At sa halip na gumamit ng magkakahiwalay na mekanismo ng pag-login sa bawat proyekto — bumuo ng iisang sistema para pamahalaan ang administratibong access, habang nananatiling magkakahiwalay ang mga application.

Hindi ko sinasabing inaalis ng ganitong pamamaraan ang posibilidad na makompromiso ang sistema.

Binabago lang nito ang pokus: mula sa pagprotekta sa mga kredensyal na palaging umiiral tungo sa kontroladong pagbibigay at pagbawi ng mga kapangyarihan.

Marahil, kung minsan, ang pinakamabisang paraan para paliitin ang attack surface ay hindi ang magdagdag ng panibagong pananggalang, kundi ang alisin ang isang bagay na hindi naman kailangan para gumana ang sistema.

Sa ideyang ito nagsimula para sa akin ang kuwento ng MeldID Admin Gateway.