El handover és el producte: què conté un safe delete de debò

El compte més perillós de la teva empresa probablement és d'algú que ja no hi treballa. I no és cap hipòtesi: quan Beyond Identity va enquestar 1.121 empleats i directius als Estats Units, el Regne Unit i Irlanda, el 83% dels exempleats va admetre que encara podia accedir a comptes d'una empresa anterior. I no parlem d'un accés puntual, per descuit: accés continuat, mesos després del comiat.

Fa dues dècades que treballo en operacions corporatives, bona part operant sistemes de producció on la checklist de sortides era problema meu. He fet arqueologia forense sobre els accessos d'un contractor que ja no hi era: el compte de servei que va sobreviure un any al seu propietari, el col·laborador de GitHub de fa dos proveïdors, la bústia que va continuar rebent respostes de clients sis mesos després de buidar-se la cadira. De l'arc de desplegament — find, deploy, sustain, hand over — en vaig escriure a la peça sobre el model forward-deployed. Aquest article obre en canal l'última fase, perquè és la que ningú pregunta en una trucada comercial i la primera que et preguntarà l'auditor.

Tothom dissenya el primer dia. Gairebé ningú dissenya l'últim.

La nostra indústria porta una dècada comprimint començaments. Matches en dies, runbooks d'onboarding, accessos automatitzats des del primer dia — progrés real, i nosaltres mateixos hi competim. Als finals, en canvi, no els ha arribat gens d'aquesta enginyeria. Un projecte s'acaba com s'ha acabat sempre: una invitació de calendari, un últim standup i l'acord tàcit que algú «netejarà els comptes» en un sprint que no arriba mai.

La causa de l'asimetria cap en una frase: els començaments es venen; els finals s'hereten. L'arrencada del projecte és allò pel qual s'avalua el proveïdor, així que és allà on va anar l'esforç de disseny. El final és de qui es queda amb l'inventari d'accessos a les mans — normalment, tu.

Un projecte que s'acaba sense una passada de desaprovisionament no està acabat. Ha quedat abandonat tal com estava.

L'accés sobreviu a les persones perquè l'inventari no és de ningú

Per què l'accés d'un enginyer sobreviu a la seva marxa? No és malícia, i rarament és incompetència. L'accés s'acumula per una dotzena de portes i se'n va per una de sola:

• El proveïdor d'identitat cobreix els comptes que vas federar — i res més.
• Les llicències de SaaS a l'ombra: l'eina d'analítica, el rastrejador d'errors, el tauler de feature flags que algú va donar d'alta amb targeta corporativa el primer any.
• Les credencials compartides al vault de l'equip — o pitjor, en un missatge fixat de Slack.
• Els tokens d'API i secrets de CI de llarga vida, creats per a una migració i mai rotats.
• Les autoritzacions OAuth a comptes personals: el «Sign in with Google» d'una eina que ningú recorda haver aprovat.
• Els accessos del costat del proveïdor: els que els sistemes del teu partner mantenen en nom del seu enginyer.

L'offboarding falla com a problema d'inventari abans de fallar com a problema de seguretat. El dia que algú marxa, només pots revocar allò que pots enumerar — i si l'enumeració comença aquell dia, ja has perdut. A les dades de Beyond Identity, el 74% dels directius va dir que la seva empresa havia patit danys per l'accés d'un exempleat, i el 56% dels que van conservar accés va admetre haver-lo fet servir amb intenció de fer mal. Jo donaria més pes a la deixadesa que a la malícia — però a l'auditor no li importa el motiu, només la porta oberta.

Un safe delete és un lliurable, no una neteja

A Conectia el handover és una fase de cada projecte, amb el seu propi artefacte. Això és el que conté un «safe delete» quan es fa com a producte i no com a tasca pendent:

1. El llibre d'accessos, mantingut des del primer dia. Cada credencial, llicència, token i autorització emesa a l'enginyer, registrada quan es concedeix — no reconstruïda al final. L'última setmana d'un projecte és massa tard per començar a recordar.
2. Documentació d'allò construït. Arquitectura, decisions, runbooks, el perquè de les parts no òbvies. Si no està escrit abans de l'última setmana, el coneixement marxa amb la persona l'últim dia.
3. Comptes de treball transferits, no abandonats. Repositoris, taulers, consoles cloud — propietat reassignada a una persona amb nom del teu costat, amb el context per operar-los. Esborrar un compte que és propietari de recursos de producció és un incident en si mateix; un safe delete primer transfereix i després revoca.
4. Rotació de credencials, no només revocació. Els comptes personals es desactiven; els secrets compartits que l'enginyer pot haver vist es roten. Una contrasenya del vault que qui marxa va arribar a llegir és, a efectes pràctics, una contrasenya compromesa.
5. La decisió sobre la bústia, feta explícita. Reenviada, arxivada sota regles de retenció, o tancada — algú tria, per escrit. La bústia que continua rebent respostes de clients que ja no llegirà ningú és l'artefacte més comú que he trobat en l'arqueologia post-sortida.
6. Esborrat del costat del proveïdor. Tanquem les nostres pròpies còpies: contingut corporatiu, credencials i accessos a repositoris als nostres sistemes, comptabilitzats i eliminats. El teu offboarding només és tan complet com el del teu proveïdor.
7. Una signatura que conserven totes dues parts. Un document amb què es va lliurar, què es va revocar, què es va rotar i qui ho va verificar. No per cerimònia — per l'auditoria, divuit mesos després, quan algú pregunti «qui tenia accés a producció el tercer trimestre?».

Res d'això no és exòtic. Cada punt és una cosa que un equip d'operacions competent podria fer. La diferència entre poder-ho fer i haver-ho fet és si algú s'encarrega del final com a procés — amb checklist i signatura — o si es dona per fet.

El teu auditor troba el final abans que un atacant

Si vas camí de SOC 2 o ISO 27001, el control d'accessos és on els projectes externs t'acaben passant factura. Tots dos marcs esperen que demostris que l'accés es concedeix per necessitat, es revisa periòdicament i es revoca en acabar — i «acabar» inclou el contractor a qui el statement of work va caducar sense que ningú se n'adonés. Amb el RGPD encara hi ha més en joc: un enginyer extern amb accés a dades personals és dins del teu perímetre de tractament, i un accés que sobreviu al projecte és un punt obert a les teves obligacions de l'article 32, no només una consola IAM desendreçada.

Aquest és el patró que he vist repetir-se en auditories corporatives: les altes estan documentades de meravella, perquè contractar sempre té un responsable. A les baixes, en canvi, l'evidència comença a escassejar — el ticket de revocació que falta, la revisió d'accessos amb un nom que ningú reconeix. El final d'un projecte extern és on el teu rastre d'auditoria és més feble, perquè és el moment en què la responsabilitat passa d'una organització a l'altra i cadascuna pot donar per fet, amb arguments raonables, que la té l'altra.

Un artefacte de handover signat tanca aquest forat amb un sol document. És l'evidència de compliance més barata que produiràs, i només es pot produir a temps.

La majoria de finals són inofensius. Aquesta és la trampa.

L'argument més fort contra tot això: la majoria de projectes acaben bé. La persona correcta, una sortida neta, res explotat — i en aquest escenari, el protocol d'aquí dalt només va produir paperassa que ningú va arribar a llegir. És veritat, i no fingiré el contrari.

Però un protocol de sortides no existeix per al cas típic. Existeix per a la cua de la distribució — la retallada de pressupost que acaba tres contractes en una setmana, l'enginyer amb una sortida menys amistosa del que suggeria el fil de comiat, l'auditoria que arriba dos anys després. Que el 83% dels que marxen conservi accés no vol dir que el 83% dels finals surti malament; vol dir que gairebé tots els finals deixen la porta oberta per al que sí. La cua és on es concentra el cost, i no tries per endavant a quin final ets. El mateix argument el vaig fer sobre l'arc de desplegament sencer; a la sortida és on més es nota.

Cinc línies que voldria signades abans de l'últim dia

Si t'endus una sola cosa d'aquest article, que sigui operativa. Abans que acabi qualsevol projecte extern — el nostre inclòs — posa aquestes cinc línies davant del teu partner:

1. «Envia'm el llibre d'accessos.» Si no existeix, l'offboarding serà una excavació, no una checklist.
2. «Qui respon de cada compte l'últim dia?» Una persona amb nom per sistema, del teu costat, confirmada abans de l'última setmana.
3. «Quins secrets compartits es roten, i quan?» Revocar la persona sense rotar allò que va veure és mitja feina.
4. «Què esborreu del vostre costat, i qui ho pot provar?» Les còpies del teu proveïdor són part del teu perímetre.
5. «On és la signatura?» Una pàgina, dues signatures, arxivada on la teva pròxima auditoria la pugui trobar.

Un partner que opera un model de desplegament real respon les cinc sense consultar amb legal — les respostes són el seu procés, posat per escrit. Si les preguntes causen sorpresa, la sorpresa és la resposta.

La indústria va aprendre a dissenyar el match. El handover encara es tracta com un detall d'última hora, i els números diuen que aquest detall acaba sortint car. Nosaltres vam convertir el final en un lliurable perquè jo he estat qui ha hagut d'auditar el que queda després, i ningú no hauria d'heretar aquesta feina de nosaltres. L'staffing s'acaba al match. El desplegament s'acaba al handover — i si el final és part del que compres, és el que porten incorporat els nostres forward-deployed engineers.