Com retirar versions antigues d'una API sense trencar integracions web

Una versió antiga d'una API pot continuar disponible molt després d'una migració web, un canvi de CRM o la implantació d'un nou checkout. El problema apareix quan ningú no pot confirmar quina aplicació, proveïdor o automatització la consumeix. Apagar-la sense comprovar-ho pot interrompre comandes, formularis, sincronitzacions o altes de clients; mantenir-la sense control prolonga una superfície d'exposició que l'empresa no coneix prou bé.

Retirar versions antigues d'una API exigeix tractar el canvi com una tasca d'operació i seguretat, no com una simple eliminació tècnica. L'objectiu no és desconnectar tot allò que sembli obsolet, sinó disposar d'evidència suficient sobre el seu ús, el seu responsable, les dades que mou i la possibilitat de fer marxa enrere si un procés crític falla.

El problema: una integració heretada que ningú no s'atreveix a apagar

És habitual trobar rutes com /v1/, subdominis de proves, connectors creats per una agència o endpoints que van sobreviure a una renovació de WordPress o d'una botiga en línia. Que una API estigui documentada no significa que continuï activa, i que no aparegui a la documentació tampoc demostra que es pugui retirar. La pregunta útil és qui la utilitza, per a quin procés de negoci, amb quina freqüència i sota quina responsabilitat.

OWASP identifica la gestió inadequada de l'inventari com un risc específic per a les APIs. Entre els problemes associats inclou desconèixer quines versions estan operatives, quin entorn les executa, qui hi ha d'accedir o com retirar versions antigues. També recomana valorar el risc de les versions anteriors quan les noves incorporen millores de seguretat. [1]

Crear un inventari mínim que serveixi per decidir

L'inventari no s'ha de convertir en un projecte documental interminable. Per a cada API, host, endpoint rellevant o integració convé registrar un identificador, URL o domini, entorn, versió, data prevista de revisió, responsable tècnic, responsable de negoci i proveïdor extern si n'hi ha. També ha de quedar clar quin sistema envia la informació i quin la rep.

Afegiu una classificació pràctica de les dades intercanviades —operatives, personals, comercials, credencials o pagaments—, el mètode d'autenticació, la ubicació segura de les credencials i el nivell d'exposició previst: públic, intern o limitat a socis concrets. Completeu cada fitxa amb evidència d'ús recent i el seu origen, com ara registres del gateway, del servidor, de la CDN o de l'aplicació. NIST contempla inventaris de programari, serveis, aplicacions personalitzades, serveis API i serveis al núvol, i assenyala la necessitat d'assignar responsabilitats i actualitzar l'inventari durant canvis i retirades. [2] [3]

• Identificador, URL o host i versió.
• Entorn: producció, preproducció, proves o desenvolupament.
• Propietari tècnic, propietari de negoci i proveïdor, si escau. Intercanvis de dades i consumidors coneguts. Evidència d'ús, data,

Comprovar què està actiu sense afectar el servei

Contrasteu l'inventari amb fonts d'observació autoritzades, com logs d'accés, mètriques del gateway, esdeveniments de l'aplicació o registres d'infraestructura al núvol. No cal fer proves intrusives ni explorar sistemes aliens. Cerqueu sol·licituds recents, origen de les crides, codis de resposta, comptes de servei i processos de negoci relacionats. Si no hi ha prou traçabilitat, la integració no està preparada per apagar-se: queda pendent de confirmació.

Una classificació senzilla redueix les decisions ambigües. Marqueu cada element com a actiu i aprovat quan té ús, responsable i manteniment coneguts; en migració si hi ha consumidors identificats i data de canvi; pendent de confirmació quan l'evidència no permet decidir; o retirable quan no hi ha ús confirmat, el responsable aprova la baixa i existeix una reversió definida. Per exemple hipotètic, si un endpoint de catàleg no rep crides durant el període d'observació acordat, però un proveïdor no n'ha confirmat la substitució, hauria de continuar pendent de confirmació, no declarar-se retirat.

Retirar la versió amb una seqüència de canvi controlada

Abans de desactivar una versió, confirmeu qui assumeix la decisió tècnica i qui valida l'impacte de negoci. Identifiqueu consumidors interns, integracions de tercers i automatitzacions aparentment menors, com un formulari que crea contactes o una tasca que actualitza existències. Comuniqueu una data, un canal per a incidències i l'abast exacte del canvi. Una finestra d'observació acordada permet detectar dependències sense convertir la retirada en un apagat improvisat.

Apliqueu el canvi en un moment previst per l'empresa i verifiqueu els fluxos crítics que es podrien veure afectats: enviament de formularis, creació de comandes, altes de clients, sincronitzacions i notificacions. Deseu l'evidència de la retirada, actualitzeu l'inventari i manteniu una reversió limitada, documentada i amb una durada definida internament. ENISA recomana mantenir un inventari d'APIs, contrastar-lo amb la visibilitat del perímetre i el coneixement de desenvolupament i operacions, així com restringir el trànsit entrant als serveis necessaris. [4]

• Confirmar els propietaris tècnic i de negoci.
• Avisar els consumidors interns, proveïdors i responsables operatius.
• Observar, aplicar el canvi i validar processos crítics autoritzats. Documentar la baixa, actualitzar l'inventari i conservar una reversió

Evitar que l'API retirada torni a quedar òrfena

Els entorns no productius requereixen una atenció proporcional a la seva exposició i a les dades que processen. Utilitzar dades reals com a drecera en proves pot augmentar l'impacte d'una API heretada si els seus controls són més febles o si queda exposada de manera innecessària. OWASP recomana no utilitzar dades de producció en desplegaments d'API no productius; quan no es pugui evitar, indica que han de rebre el mateix tractament de seguretat. [1]

Convertiu l'inventari en una font de veritat operativa. Reviseu-lo després de cada integració nova, migració web, canvi de proveïdor o retirada d'un servei, a més d'establir una revisió periòdica realista. Una auditoria de protecció web pot ajudar a ordenar actius exposats i dependències dins d'un abast autoritzat, però la decisió de retirar una integració ha de conservar responsables de negoci i de tecnologia clarament definits.

• Té responsable tècnic i de negoci?
• Se sap quins sistemes i tercers la consumeixen?
• Existeix evidència recent d'ús o desús? Hi ha una data de canvi comunicada i una reversió limitada?

Preguntes freqüents

Quan es pot considerar retirada una versió antiga d'una API?

Quan existeix evidència suficient que no té consumidors actius, els responsables tècnic i de negoci aproven la baixa, els processos afectats s'han verificat i l'inventari reflecteix la retirada. L'existència d'una versió nova, per si sola, no és suficient.

Quant de temps cal observar una API abans de retirar-la?

No hi ha un termini universal. S'ha de definir segons la freqüència dels processos associats, els seus cicles operatius i la criticitat del servei. L'important és que el període estigui acordat, que es revisin fonts d'evidència autoritzades i que es puguin identificar dependències poc freqüents.

Què cal fer si no se sap qui utilitza un endpoint antic?

Classifiqueu-lo com a pendent de confirmació. Reuniu dades d'observació autoritzades, consulteu els equips i proveïdors relacionats i eviteu apagar-lo fins a comptar amb una decisió documentada. Si la seva exposició o les dades que tracta eleven el risc, prioritzeu-ne l'anàlisi i apliqueu controls defensius proporcionals mentre se n'aclareix la sit