El incidente que cambió mi forma de gestionar las API Keys

Hace unos meses me llevé el mayor susto técnico que recuerdo desde que trabajo como desarrollador.

No porque fuera el problema más complejo que he tenido que resolver, sino porque durante unos minutos llegué a pensar que aquello podía tener un impacto enorme para la empresa.

Visto desde hoy se resume en una frase: al final no fue una caída, ni una pérdida de datos, ni un ataque. Fue una factura. Y no una factura cualquiera: una factura de seis cifras.

Lo que pasa es que esa frase solo se puede escribir al final. Mientras duró, las tres posibilidades estaban abiertas.

Foto: ImagePerson, CC BY-SA 4.0; imagen recortada y disponible bajo la misma licencia.

Las primeras horas

Durante unos segundos pensé que tenía que tratarse de un error de facturación. Después llegó la parte complicada: comprobar si realmente lo era.

Porque una factura desproporcionada en un servicio externo admite varias explicaciones, y ninguna se puede descartar por corazonada. ¿De dónde salía ese consumo? ¿Qué proyecto estaba llamando a esa API? ¿Ese proyecto seguía existiendo siquiera? ¿Nos habían robado la credencial y la estaba usando otro? ¿Había un fallo de seguridad detrás?

Esa cuarta pregunta fue la que peor se llevó, porque es la única que, además de cara, es grave. Y no se responde mirando la factura: se responde reconstruyendo qué había hecho esa clave, desde dónde y desde cuándo.

Reconstruir varios años de historial tiene un efecto secundario incómodo: descubres que no recuerdas todas las decisiones que tomaste. Eso también es deuda técnica, aunque no tenga forma de código.

Lo que había debajo

Como ocurre en muchos proyectos, utilizábamos distintos servicios externos para cubrir necesidades concretas. Con los años unos proyectos desaparecen, otros evolucionan, algunos servicios dejan de usarse, y sin darte cuenta ciertas credenciales siguen activas mucho más tiempo del que deberían.

Ese fue el verdadero problema. No la tecnología, no el proveedor, no la API: una API Key que seguía viva y que todavía podía generar consumo, asociada a algo que ya no formaba parte de nuestro día a día.

Y pasado el impacto inicial me di cuenta de que la cifra no era lo más preocupante. Lo preocupante era el inventario: servicios, credenciales, permisos y configuraciones que prácticamente había olvidado y que seguían funcionando por su cuenta. Todo aquello funciona durante años, hasta que un día deja de hacerlo o, peor, hasta que un día hace demasiado.

El incidente terminó provocando una revisión completa de la infraestructura, no solo del servicio implicado: todas las claves activas, los servicios de terceros que ya no usábamos, los permisos de cada proyecto, las cuentas antiguas, los métodos de pago vinculados, los sistemas de autenticación, las alertas de consumo y la documentación interna. En pocos días desaparecieron varios servicios que llevaban tiempo sin aportar nada, y quedó mucho más claro qué dependencias seguían vivas.

La resolución

Afortunadamente, la historia no terminó con esa factura pagada.

Tras varios días intercambiando correos con el proveedor, explicando el caso y reconstruyendo lo ocurrido, aceptaron revisarlo en detalle. La rapidez con la que reaccionamos fue determinante, y también lo fue su predisposición a investigar y a valorar las circunstancias concretas. La factura acabó emitiéndose con un abono por el exceso de consumo generado por aquella clave, así que el impacto económico terminó siendo muy distinto del que anunciaba el primer importe.

Fue un enorme alivio. Y una lección incómoda, porque durante la investigación el proveedor fue muy claro en un punto: según sus términos y condiciones, la responsabilidad sobre las API Keys y sobre el uso que se haga de ellas es del cliente.

Es decir, aquella resolución fue una excepción basada en las circunstancias del caso y en cómo se gestionó desde el primer momento. No había ninguna garantía de que una situación parecida se resolviera igual. Y, sinceramente, tampoco quería volver a comprobarlo.

Lo que de verdad cambió

Todo lo anterior es la anécdota. Esto es lo que me quedó:

Desde aquel día, cada vez que creo una nueva API Key también pienso cuándo y cómo voy a eliminarla.

Suena a obviedad y no lo es. Creamos credenciales pensando únicamente en el momento de encenderlas —qué permisos necesita esto para funcionar hoy— y nunca en el de apagarlas. Por eso sobreviven a los proyectos que las justificaban: nadie decidió que siguieran, es que nadie decidió nada.

Desde entonces intento dedicarle a la salida el mismo minuto que a la entrada. Cuando emito una credencial, dejo escrito, en el sitio donde se pueda encontrar después:

• Quién responde de ella. Una persona, no un equipo ni un buzón compartido.
• Para qué existe. En una frase, con el nombre del proyecto que la usa.
• Con qué permisos mínimos. Los que hacen falta para eso y ni uno más.
• Con qué alerta o tope de consumo, cuando el servicio lo permita. Es la parte que puede convertir una sorpresa de seis cifras en un aviso temprano.
• Cuándo toca revisarla. Una fecha concreta, aunque sea dentro de un año.
• Y qué la retira. Una fecha de caducidad si el servicio la soporta o, en su defecto, la condición que la deja sin sentido: «cuando se apague este proyecto, esta clave se va con él».

No siempre se puede rellenar todo. Un servicio antiguo puede no ofrecer permisos granulares, ni alertas, ni caducidad. Pero saber cuál de las seis casillas te falta ya es información: te dice de qué credenciales tendrás que acordarte tú, porque el proveedor no va a acordarse por ti.

Mirándolo con perspectiva

Fue incómodo. Muy incómodo. Pero sirvió para revisar procesos que probablemente habría seguido posponiendo durante años, y hoy tengo bastante más control sobre lo que tengo contratado y encendido.

Si este artículo sirve para que alguien dedique una tarde a revisar las claves que tiene olvidadas, habrá merecido la pena. Crear una credencial lleva unos segundos; olvidarse de ella puede salir mucho más caro.

Las API Keys olvidadas también son deuda técnica. Y, a veces, también deuda económica.