Kāpēc aizsargāt paroli, ja var no tās atteikties?

Problēma, ko esam pieraduši uzskatīt par normu

Gandrīz katrai tīmekļa lietotnei ir administrēšanas panelis. Un administrēšanas panelim parasti ir pieteikšanās adrese, autentifikācijas forma, lietotājvārds un parole.

Mēs esam tik ļoti pieraduši pie šādas kārtības, ka gandrīz vairs nejautājam: vai visam obligāti jādarbojas tieši šādi?

Ja tev ir tikai viena vietne, problēma nešķiet būtiska. Izveido sarežģītu paroli, ieslēdz divfaktoru autentifikāciju, ierobežo pieteikšanās mēģinājumus — un strādā.

Bet kas notiek, kad projektu kļūst desmit, divdesmit vai trīsdesmit?

Manā gadījumā runa ir par DigiMeld ekosistēmu, kurā apvienoti vairāk nekā trīsdesmit atsevišķi programmatūras projekti. Katram ir sava arhitektūra, servera loģika un administrēšanas saskarne.

Tāpēc katram ir vajadzīgs administratīvās piekļuves mehānisms.

Ilgu laiku izmantoju visai ierastu pieeju: atsevišķus administratora pieteikšanās datus, sarežģītas paroles un to saglabāšanu pārlūkprogrammā.

Tas darbojās.

Taču kādā brīdī es aizdomājos: kāpēc man vispār jāglabā tik daudz administratora paroļu? Kāpēc man jāaizsargā ne tikai serveri, bet arī paši piekļuves iegūšanas līdzekļi?

Un vai no šīs nepieciešamības nevarētu atteikties?

Sarežģīta parole neatrisina pašu problēmu

Mūsdienu rīki ļauj izveidot paroles ar ļoti augstu entropiju. Pareizi ģenerētu garu un nejaušu paroli praktiski nav iespējams uzminēt, izmantojot pilno pārlasi.

Taču, lai cik sarežģīta būtu parole, tā kaut kur ir jāglabā un pēc tam jāizmanto.

Var izmantot paroļu pārvaldniekus, aparatūras atslēgas, daudzfaktoru autentifikāciju un papildu ierobežojumus. Tas viss patiešām uzlabo drošību.

Tomēr pati arhitektūras uzbūve paliek nemainīga: ir noteikta saskarne, kurā lietotājs ievada savus pieteikšanās datus.

Uz to var sūtīt pieprasījumus. To var skenēt. Tā var kļūt par automatizētu uzbrukumu mērķi.

Var paslēpt administrēšanas paneļa adresi, standarta ceļa vietā izmantot garu nejaušu rakstzīmju virkni vai ierobežot piekļuvi pēc IP adreses.

Taču tad rodas jauns jautājums: kur glabāt šo adresi un kā to izmantot?

Un pats galvenais — kāpēc saglabāt pastāvīgu pieteikšanās punktu, ja administratīvā piekļuve vajadzīga tikai noteiktos brīžos?

Es nonācu pie domas, kas vēlāk kļuva par mana risinājuma pamatu:

Varbūt ir vērts aizsargāt nevis pastāvīgu pieteikšanās iespēju, bet gan pašas tiesības uz laiku iegūt piekļuvi.

Bet ja nu ierastās pieteikšanās lapas vispār nebūtu?

Savos projektos nolēmu atteikties no tradicionālā administratīvās autentifikācijas modeļa.

Nevis vienkārši paslēpt pieteikšanās formu.

Nevis pārdēvēt adresi.

Nevis aizstāt paroli ar vēl sarežģītāku paroli.

Bet gan novērst nepieciešamību pēc pastāvīgi pieejamas pieteikšanās ar paroli.

Protams, administrēšanas saskarnes nekur nepazuda. Tās joprojām ir nepieciešamas lietotņu pārvaldībai.

Mainījās veids, kā tām iegūt piekļuvi.

Lai pieteiktos pievienoto projektu administrēšanas paneļos, vairs nav jāievada saglabāts lietotājvārds un parole.

Tā vietā izmantoju savu identifikācijas un piekļuves pārvaldības sistēmu MeldID.

Princips ir pavisam vienkāršs: administratīvo piekļuvi piešķir tikai tad, kad tā patiešām vajadzīga, konkrētam lietotājam un konkrētam projektam.

Turklāt pats konta esamības fakts vēl nenozīmē tiesības atvērt administrēšanas paneli.

Šīs tiesības jāpiešķir atsevišķi.

Piekļuve, kuras pirms minūtes vēl nebija

Šī, iespējams, ir visinteresantākā visas koncepcijas daļa.

Tradicionālajā modelī administratoram pastāvīgi ir pieejami pieteikšanās līdzekļi. Viņš var tos izmantot šodien, rīt vai pēc mēneša — tik ilgi, kamēr tie ir derīgi.

Es nolēmu mainīt šo principu.

Pastāvīgu administratora pieteikšanās datu vietā tiek izmantota īslaicīga iespēja sākt pieteikšanās procesu.

Šī iespēja tiek izveidota pēc pieprasījuma, izmantojot uzticamu mobilo ierīci, tai ir kriptogrāfiski droša nejauša sastāvdaļa un ierobežots derīguma termiņš.

Taču pat šādas īslaicīgas saites iegūšana pati par sevi nenozīmē piekļuves saņemšanu.

Tas ir būtiski.

Pieņemsim, ka kāds kaut kādā veidā ir ieguvis saiti. Parastā sistēmā, kas balstās tikai uz adreses slepenību, šāda noplūde varētu radīt nopietnu problēmu.

Manā modelī saite ļauj tikai sākt apstiprināšanas procesu.

Lai to turpinātu, nepieciešams atsevišķs apstiprinājums uzticamā MeldID mobilajā ierīcē.

Bez attiecīgā apstiprinājuma administratīvā sesija netiek izveidota.

Tāpēc es uzskatu, ka īslaicīga saite nav paroles aizstājējs, bet gan viens no piekļuves piešķiršanas procesa elementiem.

Zināt, kur vērsties, un būt tiesīgam pieteikties ir divas pavisam atšķirīgas lietas.

Tālrunis kļūst par piekļuves pārvaldības rīku

Šajā modelī mobilajai ierīcei ir daudz svarīgāka loma nekā parastam vienreizējo kodu ģeneratoram.

To izmanto, lai apstiprinātu darbības, kas saistītas ar administratīvo piekļuvi.

Kad vēlos atvērt administrēšanas paneli, sistēma pieprasa apstiprinājumu, izmantojot MeldID.

Uzticamajā ierīcē redzu attiecīgo pieprasījumu un apstiprinu darbību.

Tikai pēc sekmīgas pārbaudes sistēma ļauj turpināt pieteikšanās procesu.

Turklāt apstiprinājums ir saistīts ar konkrētu darbību, nevis tikai ar faktu, ka tālrunis ir atbloķēts.

Mobilā biometriskā autentifikācija nodrošina lietotāja lokālo pārbaudi, savukārt servera puse pārbauda reģistrētās ierīces kriptogrāfisko apstiprinājumu.

Šāda pieeja ļauj nepaļauties tikai uz paroli vai ziņojumu, ka lietotājs it kā ir apstiprinājis pieteikšanos.

Te parādās vēl viena priekšrocība: uzticamās ierīces var pārvaldīt.

Ja ierīci vairs nevajadzētu izmantot piekļuves apstiprināšanai, tās uzticamo statusu var atsaukt.

Pēc tam tā vairs nevar kalpot par derīgu attiecīgo darbību autentifikācijas līdzekli.

Viena sistēma — daudzi neatkarīgi projekti

Uzsākot šī mehānisma izstrādi, viens no galvenajiem uzdevumiem bija saglabāt katra projekta neatkarību.

Es negribēju apvienot visus administrēšanas paneļus vienā milzīgā lietotnē.

Katram DigiMeld pakalpojumam joprojām pašam jāpārvalda sava loģika, iestatījumi, lietotāji un dati.

Tāpēc sadalīju divus uzdevumus.

MeldID atbild par identifikāciju un administratīvās piekļuves piešķiršanu.

Savukārt pats projekts atbild par savām administrēšanas funkcijām un spēkā esošo pilnvaru pārbaudi.

Rezultātā izveidojās centralizēts piekļuves pārvaldības modelis, necentralizējot pašas lietotnes.

Turklāt tiesības tiek piešķirtas atsevišķi.

Viena projekta administrators automātiski neiegūst piekļuvi pārējiem tikai tāpēc, ka viņam ir MeldID konts.

Katram administrēšanas virzienam var noteikt savu atļauto lietotāju loku.

Turklāt parasto lietotāju tiesības un administratīvās pilnvaras ir nodalītas.

Ekosistēmai, kurā ir desmitiem pakalpojumu, tas izrādījās īpaši ērti.

Kāpēc man īslaicīga piekļuve patīk labāk nekā pastāvīga

Sistēmā apzināti iestrādāju vēl vienu principu.

Administratīvajai piekļuvei nevajadzētu saglabāties bezgalīgi.

Atļauja ir spēkā ierobežotu laiku un tiek pārtraukta neatkarīgi no tā, vai lietotājs turpina strādāt pārlūkprogrammā.

Lai turpinātu darbu pēc termiņa beigām, nepieciešams no jauna iziet apstiprināšanas procesu.

Tas neļauj vienreiz veiktai autentifikācijai pārvērsties par pastāvīgi spēkā esošām tiesībām.

Tomēr ar laika ierobežojumu vien nepietiek.

Svarīgi ir arī spēt priekšlaikus pārtraukt jau piešķirto piekļuvi.

Tāpēc MeldID ir paredzēta centralizēta administratīvo atļauju atsaukšana.

Kad atļauja tiek atsaukta, pievienotie projekti saņem attiecīgo notikumu un anulē ar to saistītās administratīvās sesijas.

Tādējādi piekļuves pārvaldība nebeidzas brīdī, kad lietotājs ir sekmīgi pieteicies.

Iespēja atsaukt pilnvaras man ir tikpat svarīga kā iespēja tās piešķirt.

Turklāt izkliedētai sistēmai jāņem vērā notikumu pārraides aizkaves, atsevišķu komponentu īslaicīga nepieejamība un citi ekspluatācijas apstākļi. Sesiju derīguma termiņa ierobežošana kalpo kā papildu robeža.

Kas mainījās ikdienas darbā?

Pirmkārt, vairs nav nepieciešams pastāvīgi izmantot saglabātās administratora paroles.

Man vairs nav jātur pārlūkprogrammā pieteikšanās datu kopums katram pievienotajam administrēšanas panelim.

Tā vietā pārvaldu atļaujas, izmantojot vienotu mehānismu.

Izvēlos vajadzīgo projektu, apstiprinu piekļuvi un strādāju.

Kad administratīvā piekļuve vairs nav vajadzīga, to var atsaukt.

Īpaši ērti ir tas, ka, pievienojot jaunu projektu, nav no jauna jāprojektē visa administratīvās autentifikācijas sistēma.

Pietiek to pieslēgt esošajam modelim un noteikt vajadzīgās atļaujas.

Protams, tas nenozīmē, ka visi drošības riski ir pazuduši.

Arī īslaicīgas atļaujas, uzticamās ierīces, servera sesijas un centrālā infrastruktūra ir jāaizsargā.

Taču man vairs nav atsevišķi katrai lietotnei jārisina viens un tas pats administratora paroļu pārvaldības uzdevums.

Un tas bija viens no maniem sākotnējiem mērķiem.

Vai šādas tehnoloģijas jau nepastāv?

Protams, pastāv.

Bezparoles autentifikācija, privilēģētās piekļuves pārvaldība, īslaicīgas atļaujas un apstiprināšana, izmantojot uzticamas ierīces, informācijas drošības nozarē ir pazīstamas jau sen.

Šādas pieejas tiek izmantotas Identity and Access Management un Privileged Access Management sistēmās, kā arī Zero Trust koncepcijās.

Es nepretendēju uz šo principu izgudrošanu.

Mans uzdevums bija cits.

Man vajadzēja izveidot savu integrētu sistēmu, kas risina DigiMeld infrastruktūras konkrētās problēmas un ļauj pārvaldīt administratīvo piekļuvi daudziem neatkarīgiem projektiem.

Rezultātā apvienoju vairākas zināmas pieejas vienā arhitektūrā, kas atbilst manām prasībām.

Un uzskatu, ka inženiertehniskā darba vērtība ne vienmēr slēpjas pilnīgi jaunas tehnoloģijas izgudrošanā.

Dažkārt tā ir spēja pareizi noformulēt problēmu un atrast tai piemērotu risinājumu.

MeldID nav paredzēts tikai administrēšanas paneļiem

Te jāizdara atsevišķs precizējums.

MeldID netika izveidots tikai kā rīks manai personīgajai administratīvajai piekļuvei.

Izstrādātājiem tas nodrošina arī SDK identifikācijas un pieteikšanās apstiprināšanas mehānismu integrēšanai pašu lietotnēs.

Turklāt šis SDK ir pieejams bez maksas.

Piemēram, trešās puses izstrādātājs var izmantot MeldID kā papildu lietotāja autentifikācijas apstiprināšanas līmeni.

Pat ja lietotnē ir saglabāta tradicionālā pieteikšanās ar lietotājvārdu un paroli, ar sekmīgu šo datu ievadīšanu var nepietikt, lai pabeigtu autentifikāciju.

Lietotājs saņem pieprasījumu uzticamajā mobilajā ierīcē, kur var apstiprināt vai noraidīt pieteikšanās mēģinājumu.

Tas palīdz mazināt nesankcionētas piekļuves risku, ja pieteikšanās dati ir kompromitēti.

Ir svarīgi atšķirt šo MeldID publiski pieejamo iespēju no manis izstrādātā administratīvās piekļuves modeļa DigiMeld projektiem.

Tie izmanto kopīgus uzticēšanās un darbību apstiprināšanas principus, taču risina atšķirīgus uzdevumus.

Drošība nav tikai esošā aizsargāšana

Darbs pie šīs sistēmas lika man citādi palūkoties uz ierastajiem autentifikācijas mehānismiem.

Mēs bieži cenšamies aizsargāt to, kas pastāv vēsturisku iemeslu dēļ.

Pievienojam jaunas pārbaudes, ierobežojumus, papildu paroles un aizsardzības slāņus.

Dažkārt tas patiešām ir nepieciešams.

Taču dažkārt lietderīgāk ir uzdot citu jautājumu:

Vai aizsargājamajam mehānismam obligāti jāsaglabājas iepriekšējā veidā?

Manā gadījumā atbilde bija noliedzoša.

Man nebija vajadzīga pastāvīgi pieejama administratīvās pieteikšanās forma.

Man bija vajadzīga iespēja droši iegūt administratīvās pilnvaras tieši tad, kad tās ir nepieciešamas.

Tie ir divi dažādi uzdevumi.

Pāreja no pirmā uz otro mainīja ne tikai tehnisko arhitektūru, bet arī ikdienas darbu ar projektiem.

Nevis galapunkts, bet izvēlētais virziens

Šodien šī arhitektūra jau darbojas ievērojamā DigiMeld ekosistēmas daļā.

Pārējie projekti pakāpeniski tiek pārcelti uz jauno administratīvās piekļuves modeli.

Veicu migrāciju secīgi, pārbaudot katras lietotnes darbību, un pēc pārejas pabeigšanas plānoju veikt visas sistēmas papildu auditu.

Daži saskarnes elementi un sesiju pārvaldības noteikumi vēl var mainīties.

Taču pamatideja jau ir noteikta.

Es nevēlos atgriezties pie modeļa, kurā, lai pārvaldītu desmitiem savu projektu, man pastāvīgi jāglabā un jāizmanto desmitiem administratora paroļu.

Vienlaikus neuzskatu savu risinājumu par universālu risinājumu visiem.

Dažādām organizācijām ir atšķirīgas prasības, infrastruktūra, apdraudējumu modeļi un administrēšanas veidi.

Tas, kas ir ērti un pamatoti DigiMeld ekosistēmai, ne vienmēr būs optimāls citam izstrādātājam.

Tomēr pats īslaicīgas pilnvaru piešķiršanas princips ir pelnījis uzmanību.

Nobeigumā

Nolēmu dalīties šajā pieredzē nevis tāpēc, ka uzskatītu sevi par jauna autentifikācijas veida izgudrotāju.

Un ne tāpēc, ka gribētu pasniegt kārtējo sistēmu kā pilnīgi drošu.

Absolūta drošība nepastāv.

Man vienkārši šķiet interesants pats jautājuma formulējums.

Tā vietā, lai bezgalīgi aizsargātu pastāvīgu administratīvās pieteikšanās iespēju, var pārskatīt, vai tai vispār ir jāpastāv.

Daudzu paroļu glabāšanas vietā — izmantot īslaicīgas atļaujas.

Automātiskas uzticēšanās vietā pēc pirmās autentifikācijas — apstiprināt konkrētu pilnvaru piešķiršanu.

Gaidīšanas līdz sesijas beigām vietā — paredzēt iespēju centralizēti atsaukt piekļuvi.

Un, visbeidzot, atsevišķu pieteikšanās mehānismu vietā katrā projektā — izveidot vienotu administratīvās piekļuves pārvaldības sistēmu, vienlaikus saglabājot lietotņu neatkarību.

Es neapgalvoju, ka šāda pieeja izslēdz kompromitēšanas iespēju.

Tā vienkārši pārvieto uzsvaru no pastāvīgi esošu pieteikšanās datu aizsardzības uz kontrolētu pilnvaru piešķiršanu un atsaukšanu.

Varbūt dažkārt visefektīvākais veids, kā samazināt uzbrukuma virsmu, ir nevis pievienot vēl vienu aizsardzības mehānismu, bet atteikties no tā, bez kā sistēma var pilnīgi labi darboties.

Tieši ar šo domu man sākās MeldID Admin Gateway stāsts.