Rotación de claves de una API de pagos: del inventario de accesos a la verificación

La clave de producción se reemplazó con éxito en todos los servicios principales. Una semana después, la conciliación dejó de generarse: un script olvidado seguía usando el secreto anterior. En el papel, la rotación de claves se completó; en la operación, no terminó. La gestión del acceso a los pagos empieza con un inventario de consumidores, incluidos los que pasan la mayor parte del tiempo en silencio.

Haga un mapa de accesos sin los secretos

Para cada clave, registre el responsable, el entorno, la cuenta del proveedor, el propósito, las acciones permitidas, la lista de consumidores y el procedimiento de revocación. El inventario debe tener referencias al almacén protegido, pero no los valores de las claves. Marque aparte las tareas poco frecuentes: la exportación semanal, el procesador de respaldo y la herramienta manual de soporte. Son justamente las que se olvidan en una actualización normal de la aplicación.

Stripe recomienda claves de API restringidas, almacenamiento seguro y una rotación inmediata en caso de exposición. El conjunto concreto de permisos depende del producto. Por eso, primero revise las capacidades del proveedor y luego otorgue a cada componente solo el acceso necesario. Si no hay restricciones granulares, compénselo separando servicios, controlando las llamadas y reduciendo el círculo de personas con acceso, sin prometer una protección equivalente.

Analice el acceso según las tareas de trabajo

Imaginemos una plataforma con tres servicios internos. «Cobro» crea las operaciones de pago permitidas. «Reportes» lee la información necesaria para la conciliación. «Reembolsos» ejecuta los reembolsos aprobados. El esquema propuesto no da al proceso de reportes el derecho de mover dinero solo porque resulta más cómodo configurar una clave compartida. El servicio de reembolsos recibe su propio acceso y su propio historial de acciones.

La verificación de la firma de un webhook usa el mecanismo previsto para ello. Si el procesador además necesita consultar el estado actual, otórguele los permisos de lectura necesarios. No mezcle el secreto de firma de las notificaciones y la clave de servidor para llamar a la API en un mismo concepto de «la contraseña de la pasarela de pago». Su propósito y sus procedimientos de cambio pueden ser distintos.

Los entornos de prueba y de producción también deben diferenciarse en la configuración y los accesos. En el reporte de pruebas indique el identificador de la versión del secreto o de la configuración, si las reglas internas lo permiten, pero nunca el secreto completo. El operador debe entender qué entorno está atendiendo sin necesidad de abrir el valor de la clave.

Proteja el camino desde el almacén hasta la aplicación

Un almacén de secretos es un servicio que controla el acceso y la entrega de valores a las aplicaciones. Pero tenerlo no responde a la pregunta de quién puede leer el secreto. Para la infraestructura de AWS, la documentación de IAM recomienda permisos mínimos y credenciales temporales para las cargas de trabajo. Esto se refiere al acceso en AWS; ese rol por sí solo no reemplaza la clave de un proveedor de pagos externo.

Compruebe de dónde obtiene la aplicación el valor, qué procesos pueden leerlo y adónde podría ir a parar si ocurre un error. Para una prueba segura, use un marcador artificial en lugar del secreto real y siga su recorrido por los logs de prueba, los reportes de compilación y las páginas de diagnóstico. Esta prueba no demuestra que no haya ninguna filtración, pero ayuda a detectar copias no deseadas concretas.

OWASP describe la auditoría del uso de secretos y su ciclo de vida. En un inventario práctico conviene ver qué servicio obtuvo acceso, cuándo cambió la versión y quién autorizó el cambio. Para eso no hace falta que el valor del secreto quede en el log.

Haga el reemplazo planificado como un procedimiento verificable

1. 1.Aclare las reglas del proveedor: si se permiten varias claves activas a la vez, qué permisos trasladar y cómo revocar la anterior.
2. 2.Genere la nueva clave mediante un proceso protegido aprobado y guárdela en el almacén.
3. 3.Actualice a los consumidores según la lista conocida. Si se permite que ambas claves funcionen en paralelo, use una ventana de transición limitada; si no, acuerde un orden de cambio adecuado.
4. 4.Verifique las acciones permitidas y los rechazos esperados. Una consulta de lectura exitosa no demuestra que funcionen todas las funciones necesarias.
5. 5.Confirme que las tareas poco frecuentes también se actualizaron; después revoque la clave anterior y compruebe que nadie la sigue usando.

En el ejemplo, la aplicación funciona tras el cambio, pero la conciliación semanal todavía conserva la configuración anterior. El inventario de consumidores permite detectarlo antes de la siguiente ejecución. Incluya los procesos poco frecuentes en la verificación desde el principio, en vez de esperar un error fortuito días después.

Pruebe lo que la clave tiene prohibido

Leer un reporte con éxito demuestra que la clave puede leer reportes. No confirma que carezca del permiso para hacer un reembolso. Para cada conjunto de permisos, cree pruebas negativas en un entorno seguro adecuado: cualquier acción fuera del rol debe rechazarse. No pruebe la restricción con dinero real mediante una operación al azar; use el método que el proveedor ofrece y un escenario de prueba aprobado.

Analice por separado el acceso de las personas al servicio que posee la clave. Un empleado puede tener prohibido leer el secreto, pero permitido ejecutar comandos arbitrarios en el contenedor donde la aplicación tiene ese secreto disponible. En ese caso, la prohibición de verlo en el almacén no describe el acceso real. El mapa de permisos debe considerar toda la ruta de ejecución y las capacidades administrativas, no solo una lista prolija de usuarios del vault.

Un simulacro sin el secreto real

Haga un ejercicio de mesa: «se encontró una clave en un archivo de diagnóstico». ¿Quién puede revocar el acceso, quién tiene un método de acceso de respaldo, qué operaciones se detendrán, dónde buscar el uso? Prepare la respuesta antes del incidente. El equipo de producto define por separado el comportamiento seguro del servicio si la nueva clave aún no está desplegada: una pausa clara es mejor que un cambio oculto a una cuenta ajena o a credenciales de prueba.

Después del cambio, no vigile solo los errores de autorización, sino también la ausencia del trabajo esperado. El reporte nocturno puede simplemente dejar de aparecer sin disparar ninguna alerta en la aplicación principal. Vincule el cierre del proceso con la lista de consumidores verificados, incluidas las tareas poco frecuentes. Ese registro es más útil que la marca «secreto actualizado», porque describe el resultado para el negocio.

Una filtración cambia las prioridades

Ante la sospecha de exposición, actúe según el procedimiento de incidentes: revoque o reemplace con rapidez el acceso afectado, evalúe su uso y conserve la evidencia necesaria de forma segura. No vuelva a la clave expuesta para recuperarse más rápido. Borrar la línea de la última versión de un archivo no elimina las copias ya hechas ni sustituye la revocación.

Una integración bajo control permite responder cuatro preguntas: quién usa la clave, qué tiene permitido, cómo reemplazarla y cómo confirmar que el acceso anterior ya no funciona. Empiece por un servicio y lleve esa cadena hasta un resultado verificado.