Per què protegir una contrasenya si en pots prescindir?

Un problema que hem après a considerar normal

Pràcticament qualsevol aplicació web té un panell d’administració. I, per regla general, aquest panell té una adreça d’accés, un formulari d’autenticació, un nom d’usuari i una contrasenya.

Ens hem acostumat tant a aquesta estructura que pràcticament hem deixat de preguntar-nos si tot ha de funcionar necessàriament així.

Quan només tens un lloc web, el problema no sembla gaire important. Crees una contrasenya complexa, actives l’autenticació de dos factors, configures un límit d’intents d’inici de sessió i ja pots treballar.

Però què passa quan els projectes passen a ser deu, vint o trenta?

En el meu cas, parlem de l’ecosistema DigiMeld, que agrupa més de trenta projectes de programari independents. Cadascun té la seva arquitectura, la seva lògica de servidor i la seva interfície d’administració.

Per tant, cadascun necessita un mecanisme d’accés administratiu.

Durant molt de temps vaig fer servir un mètode força habitual: credencials d’administració separades, contrasenyes complexes i desades al navegador.

Funcionava.

Però, en un moment donat, em vaig preguntar: per què he de desar tantes contrasenyes d’administració? Per què he de protegir no només els servidors, sinó també els mitjans per accedir-hi?

I no podria prescindir d’aquesta necessitat?

Vaig arribar a una idea que, més endavant, es convertiria en la base de la meva solució:

Potser, en comptes de protegir un punt d’entrada permanent, cal protegir el dret a obtenir accés temporalment.

I si no hi hagués cap pàgina d’inici de sessió convencional?

Vaig decidir abandonar el model tradicional d’autenticació administrativa als meus projectes.

No simplement amagar el formulari d’inici de sessió.

No canviar-ne l’adreça.

No substituir la contrasenya per una altra encara més complexa.

Sinó eliminar la necessitat que hi hagi permanentment un inici de sessió amb contrasenya.

És clar que les interfícies d’administració no han desaparegut. Continuen sent necessàries per gestionar les aplicacions.

El que ha canviat és la manera d’accedir-hi.

Ara, per entrar als panells d’administració dels projectes connectats, no cal introduir un nom d’usuari i una contrasenya desats.

En lloc d’això, faig servir el meu propi sistema d’identificació i gestió d’accés, MeldID.

La idea és força simple: l’accés administratiu només es concedeix quan realment cal, a un usuari concret i per a un projecte concret.

A més, el simple fet de tenir un compte no dona dret a obrir el panell d’administració.

Aquest dret s’ha de concedir per separat.

Un accés que no existia fa un minut

Aquesta és, probablement, la part més interessant de tot el concepte.

En el model tradicional, l’administrador disposa permanentment dels mitjans per iniciar sessió. Pot fer-los servir avui, demà o d’aquí a un mes, mentre continuïn sent vàlids.

Vaig decidir canviar aquest principi.

En lloc de credencials d’administració permanents, s’utilitza una possibilitat temporal d’iniciar sessió.

Es crea a petició mitjançant un dispositiu mòbil de confiança, conté un component aleatori criptogràficament robust i té una vigència limitada.

Però ni tan sols tenir aquest enllaç temporal vol dir, per si sol, que s’obtingui accés.

Aquest és un punt fonamental.

Suposem que algú ha aconseguit l’enllaç d’alguna manera. En un sistema convencional basat exclusivament en mantenir l’adreça en secret, aquesta filtració podria convertir-se en un problema greu.

En el meu model, l’enllaç només permet iniciar el procés de confirmació.

Per continuar, cal una autorització independent mitjançant un dispositiu mòbil de confiança amb MeldID.

Sense la confirmació corresponent, no es crea cap sessió administrativa.

Per això no considero l’enllaç temporal un substitut de la contrasenya, sinó un dels elements del procés de concessió d’accés.

Saber on adreçar-se i tenir dret a entrar són dues coses completament diferents.

El telèfon es converteix en una eina de gestió d’accés

En aquest model, el dispositiu mòbil té un paper molt més important que el d’un generador de codis d’un sol ús habitual.

S’utilitza per confirmar accions relacionades amb l’accés administratiu.

Quan vull obrir un panell d’administració, el sistema demana una confirmació mitjançant MeldID.

Veig la sol·licitud corresponent al dispositiu de confiança i confirmo l’acció.

I només després de verificar-la correctament, el sistema permet continuar el procés d’inici de sessió.

La confirmació està vinculada a una acció concreta, no simplement al fet que s’hagi desbloquejat el telèfon.

La biometria del dispositiu mòbil verifica l’usuari localment, mentre que el servidor comprova la confirmació criptogràfica del dispositiu registrat.

Aquest mètode permet no dependre exclusivament d’una contrasenya ni d’un missatge que afirma que l’usuari ha confirmat l’inici de sessió.

I aquí sorgeix un altre avantatge: els dispositius de confiança es poden gestionar.

Si un dispositiu ja no s’ha d’utilitzar per confirmar l’accés, se li pot revocar l’estat de confiança.

A partir d’aquell moment, deixa de ser un mitjà vàlid per autoritzar les operacions corresponents.

Un sistema, molts projectes independents

Quan vaig començar a desenvolupar aquest mecanisme, un dels objectius principals era preservar la independència de cada projecte.

No volia convertir tots els panells d’administració en una única aplicació enorme.

Cada servei de DigiMeld havia de continuar gestionant la seva pròpia lògica, configuració, usuaris i dades.

Per això vaig separar dues funcions.

MeldID s’encarrega de la identificació i de concedir l’autorització administrativa.

El projecte, per la seva banda, s’encarrega de les seves pròpies funcions d’administració i de verificar els permisos vigents.

Així vaig obtenir un model centralitzat de gestió d’accés sense haver de centralitzar les aplicacions mateixes.

A més, els permisos es concedeixen per separat.

Un administrador d’un projecte no obté accés automàticament a la resta només pel fet de tenir un compte de MeldID.

Per a cada àmbit administratiu es pot definir un conjunt propi d’usuaris autoritzats.

Alhora, els drets dels usuaris habituals i les autoritzacions administratives es mantenen separats.

Per a un ecosistema de desenes de serveis, això ha resultat especialment pràctic.

Per què prefereixo l’accés temporal al permanent

Hi ha un altre principi que vaig incorporar conscientment al sistema.

L’accés administratiu no s’hauria de mantenir indefinidament.

L’autorització té una vigència limitada i caduca tant si l’usuari continua treballant amb el navegador com si no.

Per continuar treballant un cop vençut el termini, cal repetir el procés de confirmació.

Així s’evita que una autorització concedida una vegada es converteixi en un dret permanent.

Però limitar-ne la durada no és suficient.

També és important poder interrompre abans d’hora l’accés ja concedit.

Per això MeldID permet revocar centralitzadament les autoritzacions administratives.

Quan es revoca una autorització, els projectes connectats reben l’esdeveniment corresponent i anul·len les sessions administratives associades.

Així, la gestió de l’accés no s’acaba en el moment que l’usuari inicia sessió correctament.

Per a mi, poder revocar les autoritzacions és tan important com poder concedir-les.

Alhora, un sistema distribuït ha de tenir en compte els retards en la transmissió d’esdeveniments, la indisponibilitat temporal d’alguns components i altres circumstàncies operatives. La limitació de la vigència de les sessions proporciona una salvaguarda addicional.

Què ha canviat en la feina del dia a dia?

En primer lloc, ja no cal recórrer constantment a les contrasenyes d’administració desades.

Ja no he de mantenir al navegador un conjunt de credencials per iniciar sessió a cada panell d’administració connectat.

En lloc d’això, gestiono els permisos mitjançant un mecanisme únic.

Trio el projecte que necessito, confirmo l’accés i m’hi poso a treballar.

Quan ja no cal l’accés administratiu, es pot revocar.

És especialment pràctic que, quan apareix un projecte nou, no calgui tornar a dissenyar tot el sistema d’autenticació administrativa.

N’hi ha prou de connectar-lo al model existent i definir els permisos necessaris.

És clar, això no vol dir que hagin desaparegut tots els riscos de seguretat.

Les autoritzacions temporals, els dispositius de confiança, les sessions del servidor i la infraestructura central també necessiten protecció.

Però ja no he de resoldre el mateix problema de gestió de contrasenyes administratives per separat per a cada aplicació.

I aquest era precisament un dels meus objectius inicials.

Que aquestes tecnologies ja no existeixen?

És clar que existeixen.

L’autenticació sense contrasenya, la gestió d’accés privilegiat, les autoritzacions temporals i la confirmació mitjançant dispositius de confiança són conceptes coneguts des de fa temps en el sector de la seguretat de la informació.

Aquests mètodes es troben en sistemes d’Identity and Access Management, Privileged Access Management i en els conceptes de Zero Trust.

No pretenc haver inventat aquests principis.

El meu objectiu era un altre.

Necessitava crear un sistema integrat propi que resolgués problemes concrets de la infraestructura de DigiMeld i permetés gestionar l’accés administratiu a molts projectes independents.

Com a resultat, vaig combinar diversos mètodes coneguts en una sola arquitectura que s’ajusta als meus requisits.

I crec que el valor de la feina d’enginyeria no rau necessàriament a inventar una tecnologia completament nova.

De vegades, rau a formular correctament el problema i trobar-hi una solució adequada.

MeldID no és només per als panells d’administració

Cal fer aquí un aclariment a part.

MeldID no es va crear exclusivament com una eina per gestionar el meu propi accés administratiu.

També ofereix als desenvolupadors un SDK per integrar mecanismes d’identificació i confirmació d’inici de sessió a les seves pròpies aplicacions.

A més, aquest SDK és gratuït.

Per exemple, un desenvolupador extern pot utilitzar MeldID com a capa addicional de confirmació de l’autenticació dels usuaris.

Encara que l’aplicació mantingui l’inici de sessió tradicional amb nom d’usuari i contrasenya, introduir correctament aquestes dades pot no ser suficient per completar l’autenticació.

L’usuari rep una sol·licitud al dispositiu mòbil de confiança, on pot confirmar o rebutjar l’intent d’inici de sessió.

Això permet reduir el risc d’accés no autoritzat si les credencials es veuen compromeses.

És important distingir aquesta funcionalitat de MeldID, disponible per a tothom, del model d’accés administratiu que he desenvolupat per als projectes de DigiMeld.

Parteixen de principis comuns de confiança i confirmació d’accions, però resolen problemes diferents.

La seguretat no consisteix només a protegir el que ja existeix

La feina en aquest sistema m’ha fet veure d’una altra manera els mecanismes d’autenticació habituals.

Sovint intentem protegir allò que existeix per raons històriques.

Hi afegim noves comprovacions, restriccions, contrasenyes addicionals i capes de protecció.

De vegades, és realment necessari.

Però de vegades és més útil fer-se una altra pregunta:

És imprescindible que el mateix mecanisme que volem protegir continuï existint com fins ara?

En el meu cas, la resposta va ser que no.

No necessitava un formulari d’inici de sessió administratiu disponible permanentment.

Necessitava poder obtenir de manera segura permisos administratius precisament quan fossin necessaris.

Són dues tasques diferents.

I passar de la primera a la segona va canviar no només l’arquitectura tècnica, sinó també la feina quotidiana amb els projectes.

No és un punt final, sinó una direcció escollida

Avui, aquesta arquitectura ja funciona en una part important de l’ecosistema DigiMeld.

Els projectes restants es van passant gradualment al nou model d’accés administratiu.

Faig la migració pas a pas, comprovant el funcionament de cada aplicació, i quan s’hagi completat el canvi, tinc previst fer una auditoria addicional de tot el sistema.

Alguns elements de la interfície i les normes de gestió de sessions encara poden canviar.

Però la idea principal ja està definida.

No vull tornar a un model en què, per gestionar desenes de projectes propis, hagi de desar i utilitzar permanentment desenes de contrasenyes d’administració.

Alhora, no considero que la meva implementació sigui una solució universal per a tothom.

Les diferents organitzacions tenen requisits, infraestructures, models d’amenaces i mètodes d’administració diferents.

Allò que és pràctic i justificat per a l’ecosistema DigiMeld no necessàriament serà òptim per a un altre desenvolupador.

Tanmateix, val la pena parar atenció al principi de concedir permisos temporalment.

En lloc d’una conclusió

He decidit compartir aquesta experiència no perquè em consideri l’inventor d’un nou mètode d’autenticació.

Ni perquè vulgui presentar un altre sistema com si fos absolutament segur.

La seguretat absoluta no existeix.

Simplement, em sembla interessant la manera mateixa de plantejar la qüestió.

En lloc de protegir indefinidament un punt d’entrada administratiu permanent, podem replantejar-nos si cal que existeixi.

En lloc de desar moltes contrasenyes, podem fer servir autoritzacions temporals.

En lloc de confiar automàticament en un usuari després de la primera autenticació, podem confirmar la concessió de permisos concrets.

En lloc d’esperar que la sessió caduqui, podem preveure la possibilitat de revocar l’accés centralitzadament.

I, finalment, en lloc de tenir un mecanisme d’inici de sessió separat per a cada projecte, podem crear un sistema unificat de gestió de l’autorització administrativa, tot mantenint les aplicacions independents.

No afirmo que aquest mètode elimini la possibilitat que el sistema es vegi compromès.

Simplement, desplaça l’èmfasi: en comptes de protegir credencials permanents, se centra a concedir i revocar permisos de manera controlada.

Potser, de vegades, la manera més eficaç de reduir la superfície d’atac no és afegir una altra capa de protecció, sinó prescindir d’allò sense què el sistema pot funcionar perfectament.

Per a mi, la història de MeldID Admin Gateway va començar precisament amb aquesta idea.