L’accés a la VPN s’atura i l’alerta diu que el servei de segon factor no és accessible. Si algú encara es pot connectar és una qüestió de política que s’havia de respondre abans de la interrupció, no durant. Un verificador no disponible no és prova que un factor hagi passat, i un repte rebutjat no és el mateix esdeveniment que un d’inabastable. El manual següent converteix aquesta distinció en una regla escrita que podeu provar.

Pas 1: anomeneu els tres resultats per separat

Escriviu tres estats i refuseu d’ajuntar-los: l’autenticació primària ha fallat, el repte del segon factor ha estat denegat o ha caducat, i el servei MFA no ha respost mai. Cadascun té un propietari diferent, una línia de registre diferent i una resposta correcta diferent. Un sol missatge genèric de temps esgotat amaga en quin estat sou, i aquesta ambigüitat és el que converteix una interrupció en una discussió. Anomeneu els estats al manual abans que us calguin.

Una denegació significa que el verificador ha respost i ha dit que no, cosa que és un resultat de política i no un problema de disponibilitat. Un intent caducat significa que el repte existia i ningú el va completar a temps. Un servei inaccessible significa que la pregunta no va rebre cap resposta. Només el tercer és una interrupció.

Pas 2: llegiu el mode de fallada que el proxy fa servir realment

Trobeu el paràmetre que regeix el comportament quan no es pot contactar amb el servei i llegiu-lo de la configuració en execució, no d’una plantilla. Al proxy RADIUS de Duo, els valors documentats de failmode són safe i secure, amb safe permetent un intent només quan l’autenticació primària té èxit i secure rebutjant l’intent en aquesta condició.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

El nom safe descriu una opció de disponibilitat, no una garantia que cada sessió admesa hagi tingut un segon factor nou. Aquesta frase pertany al registre de riscos, perquè és exactament la contrapartida que fa el paràmetre. No generalitzeu el valor a un altre proveïdor, una altra integració o un altre mode de proxy; llegiu la documentació d’aquell producte per al seu equivalent. Una configuració copiada d’un exemple de proveïdor sense aquesta comprensió és una sorpresa que espera la propera interrupció.

Atureu-vos si ningú no pot dir quin mode és actiu. La resta del manual depèn d’aquesta resposta.

Pas 3: feu que els reintents coincideixin amb el flux

Alineeu el temps d’espera i el comportament de reintent de la passarel·la amb el flux d’autenticació que condueix. Els reintents no coordinats creen diversos avisos, confonen l’aparellament d’intents i deixen el registre incapaç de dir quin resultat pertany a quin inici de sessió. Un temps d’espera molt llarg no és un disseny de disponibilitat; és una espera més llarga per a la mateixa resposta.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

El temps d’espera propi de la sol·licitud del proxy és un límit separat: una sol·licitud d’autenticació que s’emet i no es completa mai es rebutja, i aquest rebuig no és una interrupció de la qual es pugui retrocedir. Tracteu una denegació, un repte inacabat i un servei inaccessible com tres entrades diferents a la vostra taula de decisions. Després feu la taula explícita: quin estat admet, quin estat reté i quin estat escala a una persona.

Si dos components reintenten tots dos, arregleu primer la propietat dels reintents. Els avisos duplicats són un símptoma de dos propietaris, no d’un servei lent.

Pas 4: governeu l’accés d’emergència a part

Si cal accés d’emergència, doneu-li el seu propi abast, identitat, autorització i rastre d’auditoria. Desactivar MFA en silenci per a tots els usuaris no és un procediment d’emergència; és un debilitament permanent amb un incident adjunt. El propietari de seguretat aprova per endavant la regla d’accés, la visibilitat i el camí d’escalada.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Proveu tota la matriu en un entorn que no sigui de producció: fallada primària, rebuig deliberat, caducitat del repte i indisponibilitat del servei. Per a cadascun, anoteu el resultat d’accés i el motiu que es va registrar. No creeu una interrupció de producció per descobrir el comportament configurat i no proveu el camí d’emergència per primera vegada durant l’incident per al qual es va escriure. Un procediment de recuperació que mai no s’ha executat és un document, no un control.

El manual acaba quan els tres estats tenen nom, el mode de fallada s’ha llegit del sistema en execució, els reintents tenen un sol propietari i l’accés d’emergència té la seva pròpia aprovació i revisió. L’aplicació previsible més un camí de recuperació conegut és el resultat que val la pena documentar.

Articles relacionats