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

Hace unos meses recibí 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 podía tener un impacto enorme para la empresa.

No fue una caída de servidores. No fue un ataque. No fue una pérdida de datos.

Fue una factura. Y no una factura cualquiera: una factura de seis cifras.

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

Todo empezó con una API Key

Como ocurre en muchos proyectos, utilizábamos distintos servicios externos para cubrir determinadas necesidades.

Con el paso de los años algunos proyectos desaparecen, otros evolucionan, algunos servicios dejan de utilizarse... y, sin darte cuenta, ciertas credenciales permanecen activas mucho más tiempo del que deberían.

Ese fue el verdadero problema.

No la tecnología. No el proveedor. No la API.

La existencia de una API Key que seguía activa y que todavía podía generar consumo.

La investigación

Las primeras horas fueron bastante intensas. Había que responder muchas preguntas.

• ¿Qué había ocurrido exactamente?
• ¿Qué proyecto estaba utilizando esa API?
• ¿Seguía existiendo ese proyecto?
• ¿La clave había sido comprometida?
• ¿Existía algún fallo de seguridad?

Cuando empiezas a reconstruir varios años de historial descubres algo bastante incómodo: no siempre recuerdas todas las decisiones que tomaste. Y eso también forma parte de la deuda técnica.

Lo peor no era la factura

Evidentemente, recibir una factura de ese importe impresiona.

Pero, una vez pasado el impacto inicial, me di cuenta de que eso no era lo realmente preocupante.

Lo preocupante era descubrir que todavía existían recursos que prácticamente había olvidado:

• servicios;
• credenciales;
• permisos;
• configuraciones.

Todo aquello que funciona durante años... hasta que un día deja de hacerlo.

Cambié muchas más cosas de las que esperaba

El incidente terminó provocando una revisión completa de toda nuestra infraestructura, no solo del servicio implicado.

También revisé:

• todas las API Keys activas;
• servicios de terceros que ya no utilizábamos;
• permisos asociados a cada proyecto;
• cuentas antiguas;
• tarjetas de pago vinculadas;
• sistemas de autenticación;
• alertas de consumo;
• documentación interna.

En pocos días desaparecieron varios servicios que llevaban tiempo sin aportar ningún valor.

Y, sobre todo, quedó mucho más claro qué dependencias seguían vivas y cuáles no.

La deuda técnica también tiene forma de una API Key

Normalmente pensamos en deuda técnica como código antiguo o funciones difíciles de mantener.

Pero también existe otra deuda mucho menos visible.

Las API Keys olvidadas.

Las cuentas que nadie recuerda.

Las credenciales que nadie sabe exactamente para qué siguen existiendo.

Y esa deuda, en ocasiones, también puede convertirse en deuda económica.

La resolución del incidente

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

Después de varios días intercambiando correos con el proveedor, explicando el caso y reconstruyendo todo lo ocurrido, aceptaron revisar el incidente en detalle.

La rapidez con la que reaccionamos fue determinante, pero también lo fue la predisposición del proveedor para investigar el caso con profundidad y valorar las circunstancias concretas del incidente.

Finalmente, la factura se emitió incluyendo un abono correspondiente al exceso de consumo generado por aquella API Key, por lo que el impacto económico terminó siendo muy distinto del que hacía presagiar aquella primera factura de seis cifras.

Fue un enorme alivio.

Pero también entendí que no podía volver a depender de que una situación así terminara resolviéndose de forma favorable.

Durante la investigación, el propio proveedor fue muy claro en un aspecto: según sus términos y condiciones, la responsabilidad sobre las API Keys y el uso que se haga de ellas recae en el cliente.

En otras palabras, aquella resolución fue una excepción basada en las circunstancias concretas del caso y en la forma en que reaccionamos desde el primer momento.

No había ninguna garantía de que una situación similar volviera a resolverse del mismo modo.

Y, sinceramente, tampoco quería volver a comprobarlo.

Creo que esa fue, probablemente, la lección más importante de todas.

Desde entonces

Desde aquel incidente intento seguir algunas reglas bastante sencillas.

• Cada API Key debe tener un propietario claro.
• Ninguna credencial permanece activa si ya no existe el proyecto que la utiliza.
• Todos los servicios externos se revisan periódicamente.
• El acceso mínimo necesario siempre es mejor que "por si acaso".
• Las alertas de consumo son tan importantes como las copias de seguridad.

No eliminan completamente el riesgo.

Pero reducen muchísimo las posibilidades de volver a encontrarme con una sorpresa parecida.

Mirándolo con perspectiva

Con el tiempo he terminado viendo aquel episodio de otra manera.

Fue incómodo. Muy incómodo.

Pero también sirvió para revisar procesos que probablemente habría seguido posponiendo durante años.

Hoy tengo mucho más control sobre los servicios que utilizo.

Y, curiosamente, también duermo bastante más tranquilo.

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

Porque crear una credencial lleva unos segundos.

Olvidarse de ella puede salir mucho más caro.

Si este artículo sirve para que alguien dedique una tarde a revisar las API Keys que tiene olvidadas, probablemente ya habrá merecido la pena.

Las API Keys olvidadas también son deuda técnica.

Y, a veces, también deuda económica.