L'MFA redueix el risc que una contrasenya robada sigui suficient per entrar en un compte, però pot plantejar un problema operatiu quan es perd un mòbil, se substitueix un dispositiu o deixa l'empresa qui administrava un servei. Si ningú no pot recuperar l'accés a WordPress, al hosting o al DNS, una incidència tècnica senzilla pot convertir-se en una interrupció difícil de gestionar.
El problema no se soluciona compartint codis, deixant un correu personal com a recuperació o creant excepcions permanents. L'alternativa és un pla de recuperació MFA limitat als comptes crítics, amb responsables interns, una validació proporcionada a l'impacte i una revisió defensiva després de cada recuperació. L'objectiu és restablir l'accés autoritzat sense convertir el procés en una porta del darrere.
La recuperació MFA també és una acció sensible
Un compte pot estar ben protegit en l'inici de sessió i, tot i així, quedar exposat si resulta massa fàcil canviar-ne el telèfon, registrar una passkey nova o modificar el correu de recuperació. OWASP recomana que el restabliment de l'MFA permeti recuperar l'accés legítim sense facilitar el segrest del compte. També aconsella sol·licitar una autenticació nova amb un factor ja registrat abans de canviar els factors MFA, en lloc de confiar només en una sessió que podria haver estat compromesa. [3]
Convé tractar la pèrdua del segon factor com un procés de continuïtat i de seguretat, no com una sol·licitud informal per xat. La persona que demana el canvi s'ha d'identificar mitjançant un canal definit, i la decisió ha de quedar registrada. Quan el compte permet publicar continguts, modificar DNS, restaurar còpies o consultar dades de clients, una segona aprovació interna pot ser una mesura raonable.
- Exigeix una petició pel canal intern acordat.
- Comprova la identitat i el motiu abans de canviar o eliminar un factor.
- Registra qui va autoritzar l'acció, quan es va fer i què s'ha de revisar després.
Delimita els comptes inclosos en el pla
No cal començar per tots els comptes de l'empresa. Prioritza els que poden afectar la disponibilitat, la configuració o la informació del web: administració del CMS, hosting, DNS, correu corporatiu, CDN o WAF, plataforma de comerç electrònic i proveïdor d'identitat. ENISA recomana decidir quins actius i rols requereixen MFA segons la seva criticitat, definir mètodes de còpia de seguretat segurs i supervisar els registres d'autenticació. [4]
Classifica cada compte per la seva capacitat de causar impacte, no pel càrrec de qui l'utilitza. Una mateixa persona pot tenir accés a diversos proveïdors, però cada servei tindrà els seus propis mecanismes de suport, evidències i terminis. Per exemple, un compte que modifica registres DNS necessita una ruta de recuperació diferent de la del compte editorial que publica una entrada al blog.
- Servei i URL oficial d'accés.
- Propietari intern i segon responsable autoritzat.
- Nivell de privilegi i accions que permet dur a terme el compte.
Crea una fitxa de recuperació per proveïdor
Per a cada plataforma crítica, prepara una fitxa breu i accessible només per a qui l'hagi d'utilitzar. Ha d'indicar qui pot obrir una petició al proveïdor, quines comprovacions internes es fan, quin és el canal oficial de suport i quins canvis requereixen doble revisió. Evita incloure contrasenyes, codis temporals, llavors d'autenticadors o altres secrets en documents compartits.
NIST preveu mecanismes com ara codis de recuperació, contactes de recuperació i la repetició de la verificació d'identitat. També indica que els esdeveniments de recuperació han de generar notificacions per ajudar a detectar usos fraudulents. Si un proveïdor ofereix codis de recuperació, custodia'ls segons una política interna i revisa'n la vigència cada vegada que canviïn els responsables autoritzats. [1]
- Via oficial de recuperació i dades de contacte del proveïdor.
- Evidències o aprovacions internes necessàries abans d'iniciar el tràmit.
- Passos obligatoris posteriors: revisió de factors, sessions i contactes de recuperació.
Respon de manera diferent segons l'incident
Davant de la pèrdua o substitució d'un dispositiu, l'objectiu és donar d'alta un factor nou sense precipitar-se a eliminar l'anterior si encara se'n pot verificar la situació. Un exemple hipotètic: la responsable de continguts canvia de telèfon i conserva l'accés al compte corporatiu. Un segon responsable valida la sol·licitud, es registra el factor nou mitjançant el procés oficial i després es confirma que els factors antics que no són necessaris s'han retirat.
Una baixa de personal o una sospita de compromís requereix més cautela. En el primer cas, cal retirar l'accés i els mètodes de recuperació vinculats a aquella persona segons l'abast autoritzat. En el segon, recuperar la contrasenya no és suficient: OWASP aconsella revisar mètodes MFA, adreces de recuperació, sessions actives i canvis recents, i invalidar sessions o enllaços de recuperació que ja no hagin de continuar vigents. [5]
- Pèrdua de dispositiu: valida la sol·licitud i registra el factor nou.
- Sortida de personal: retira permisos, factors i contactes associats.
- Sospita de compromís: revisa sessions, canvis recents i dades de recuperació abans de tancar el cas.
Prova el procés i millora allò que falli
Un procediment que mai no s'ha provat pot dependre, sense que ningú no ho sàpiga, d'una persona concreta o d'informació obsoleta. Fes proves controlades, amb autorització prèvia i sobre comptes o entorns previstos per a això. La prova no busca forçar accessos: verifica que l'equip localitza la fitxa, identifica el responsable, utilitza el canal oficial del proveïdor i documenta el resultat.
Revisa el pla després de canvis de proveïdor, personal, dominis, rols o mètodes d'autenticació. Per als comptes de més valor o privilegi, CISA recomana prioritzar MFA resistent al phishing i començar pels serveis compatibles i per grups com ara administradors de sistemes o equips de suport. Els codis OTP introduïts manualment poden continuar tenint utilitat operativa, però NIST no els considera resistents al phishing perquè poden ser reenviats des d'un lloc impostor. [2] [1]
- Programa una revisió periòdica i una altra després de canvis rellevants.
- Anota la data de la prova, les incidències detectades i el responsable de corregir-les.
- Actualitza la fitxa només després de comprovar que la nova ruta funciona.
Preguntes freqüents
Hem de desar codis de recuperació MFA en un document compartit?
No és recomanable desar codis, contrasenyes o secrets MFA en documents compartits d'ús general. Si el proveïdor ofereix codis de recuperació, l'empresa pot definir una custòdia restringida, controls d'accés i revisions quan canviïn els responsables. La fitxa operativa ha d'indicar on és el mecanisme aprovat, no exposar el,
Dos responsables han de compartir el mateix compte administrador?
No. És preferible que cada responsable tingui una identitat pròpia i permisos d'acord amb la seva funció. Així es pot retirar l'accés individual, revisar l'activitat i mantenir una ruta de recuperació sense compartir contrasenyes ni factors MFA. Quan el proveïdor ho permeti, assigna rols diferenciats en lloc d'utilitzar un únic compte comú.
Cada quant convé revisar el pla de recuperació MFA?
Revisa'l de manera periòdica i sempre que hi hagi canvis rellevants: sortida o incorporació de personal, substitució de dispositius, canvi de proveïdor, alta d'un domini o modificació de privilegis. Una prova controlada permet detectar contactes obsolets, instruccions incompletes o dependències d'una sola persona abans que en passi una