Cómo proteger cuentas críticas y APIs de servicios en la nube con autenticación robusta

Introducción

Las cuentas que administran servicios en la nube han dejado de ser simples accesos a una aplicación. En una microempresa pueden concentrar correo, documentación, inteligencia artificial, automatizaciones, infraestructura, facturación, credenciales de API y capacidad de generar consumo económico. Por eso, protegerlas únicamente con una contraseña ya no es una estrategia razonable.

El problema se vuelve especialmente importante cuando el proveedor factura por uso. Una cuenta administrativa comprometida puede permitir modificar configuraciones, crear nuevas credenciales o acceder a información sensible; una clave API robada puede, además, utilizarse para generar consumo automatizado. Son dos superficies de ataque distintas y deben protegerse con controles diferentes.

Una arquitectura robusta no consiste en elegir un único método “muy seguro”, sino en combinar varias capas: una contraseña exclusiva, autenticación multifactor, un mecanismo resistente al phishing, recuperación independiente del teléfono, restricciones técnicas para las APIs, límites de consumo y supervisión. El objetivo es que el fallo de una capa no implique automáticamente la pérdida de control de la cuenta o un gasto inesperado.

Este artículo explica cómo diseñar esa protección con un enfoque realista para autónomos, profesionales y pequeñas empresas, sin necesidad de desplegar una infraestructura corporativa compleja.

Índice

• Por qué algunas cuentas deben considerarse críticas
• Amenazas que conviene separar
• Capas de autenticación recomendadas
• Aplicaciones autenticadoras TOTP
• Passkeys, FIDO2 y WebAuthn
• Llaves físicas de seguridad
• Cómo evitar depender de un único móvil o dispositivo
• La seguridad de una API es un problema distinto
• Restricciones por IP autorizada
• Límites de consumo, gasto y velocidad
• Monitorización y respuesta ante incidentes
• Arquitectura recomendada para una microempresa
• Plan de implantación por fases
• Errores habituales
• Cuándo conviene revisar la arquitectura con un especialista
• Preguntas frecuentes

Por qué algunas cuentas de servicios en la nube deben considerarse críticas

No todas las cuentas tienen el mismo impacto. Perder el acceso a un servicio de escasa importancia no es comparable con comprometer una identidad desde la que se administran correo, facturación, APIs, repositorios de código o datos empresariales.

Una cuenta debería tratarse como crítica cuando permite realizar una o varias de estas acciones:

• Crear, eliminar o modificar credenciales de acceso.
• Administrar métodos de pago, suscripciones o facturación por consumo.
• Generar claves API o tokens de servicio.
• Acceder a datos empresariales, documentación o información de clientes.
• Modificar configuraciones de seguridad.
• Dar acceso a otros usuarios.
• Controlar automatizaciones o sistemas que funcionan sin supervisión directa.
• Acceder a otros servicios mediante inicio de sesión federado.

Cuantas más funciones administrativas concentra una misma identidad, mayor debe ser la protección. Una pequeña empresa puede tener pocas cuentas, pero precisamente por eso cada una de ellas puede concentrar una proporción muy alta de la operativa.

Amenazas que conviene separar

Antes de configurar medidas de seguridad resulta útil diferenciar los incidentes posibles. Una contraseña robada, un teléfono perdido y una clave API expuesta no son el mismo problema.

Robo de contraseña

Puede producirse por phishing, malware, filtraciones de otros servicios o reutilización de contraseñas. La defensa principal es utilizar una contraseña larga, aleatoria y exclusiva, acompañada de un segundo factor.

Pérdida o robo del teléfono

Si el mismo smartphone contiene la aplicación autenticadora, el correo, la mensajería, el gestor de contraseñas y las aplicaciones empresariales, se ha concentrado una gran parte de la capacidad de recuperación en un único dispositivo físico.

Phishing del segundo factor

Los códigos SMS y TOTP mejoran considerablemente la seguridad respecto a una contraseña aislada, pero un usuario puede introducirlos en una página falsa. Los mecanismos FIDO2/WebAuthn están diseñados para reducir este riesgo porque la autenticación queda ligada criptográficamente al servicio legítimo.

Robo de una clave API

Una API key es una credencial para software. Un atacante que la obtiene puede intentar utilizarla directamente, sin necesidad de conocer la contraseña del administrador ni superar su MFA. Por eso las claves API requieren controles propios.

Compromiso del servidor autorizado

Incluso una restricción por IP pierde eficacia si el propio servidor desde el que se permite el acceso ha sido comprometido. En ese escenario resultan esenciales los límites de consumo, la segmentación, la rotación de credenciales y la monitorización.

Capas de autenticación recomendadas

Para cuentas críticas, una configuración razonable puede combinar cuatro elementos complementarios:

1. Contraseña única y robusta.
2. Aplicación autenticadora TOTP como método habitual si el proveedor la admite.
3. Passkey o llave física FIDO2/WebAuthn como método resistente al phishing y respaldo independiente.
4. Métodos de recuperación controlados, evitando que todos dependan del mismo teléfono.

La fortaleza está en la combinación. Una contraseña protege frente a accesos triviales; TOTP añade un segundo factor; FIDO2 mejora la resistencia al phishing; y una estrategia de recuperación evita que la propia seguridad deje al propietario fuera de su cuenta.

Aplicaciones autenticadoras TOTP

Una aplicación TOTP genera códigos temporales, normalmente de seis cifras, a partir de un secreto compartido y del tiempo. No necesita recibir un SMS para crear cada código y puede funcionar incluso sin cobertura.

Para una pequeña empresa presenta varias ventajas:

• No depende del operador telefónico para cada inicio de sesión.
• Reduce la exposición a ataques basados en duplicados de SIM.
• Es compatible con muchos servicios.
• Permite mantener el segundo factor separado de la contraseña.

Sin embargo, conviene entender su limitación: TOTP no es completamente resistente al phishing. Una página fraudulenta puede solicitar el código y utilizarlo inmediatamente contra el servicio real.

¿Tiene sentido utilizar un móvil dedicado?

Para cuentas especialmente sensibles puede ser una medida muy razonable disponer de un teléfono que permanezca habitualmente en casa u oficina y que tenga pocas aplicaciones instaladas. Puede funcionar como terminal de autenticación, protegido mediante PIN fuerte, cifrado y actualizaciones.

La precaución importante es no convertirlo en un punto único de fallo. Un teléfono puede romperse, perderse o quedar inutilizado. Debe existir al menos un método de acceso alternativo físicamente independiente.

Passkeys, FIDO2 y WebAuthn

Una passkey es una credencial criptográfica basada en un par de claves. La parte privada queda bajo control del usuario y la parte pública se registra en el servicio.

Cuando se inicia sesión, el servicio presenta un desafío criptográfico que el autenticador firma. La clave privada no necesita enviarse al servidor.

Una passkey puede estar almacenada en diferentes lugares:

• Un teléfono.
• Un ordenador.
• Un gestor de credenciales compatible.
• Un sistema sincronizado entre dispositivos.
• Una llave física de seguridad FIDO2.

Por tanto, passkey y llave física no son sinónimos. La passkey es la credencial; la llave física es uno de los dispositivos que puede almacenarla o utilizarla.

Por qué FIDO2 mejora la resistencia al phishing

Un código puede copiarse. Una passkey FIDO2/WebAuthn se vincula al dominio o servicio para el que fue registrada. Esto dificulta que una web fraudulenta consiga utilizar una autenticación destinada al servicio legítimo.

Para cuentas críticas, esta característica es especialmente valiosa porque reduce el riesgo de que un usuario técnicamente cuidadoso termine entregando involuntariamente un código válido en una página falsa.

Llaves físicas de seguridad: independencia del móvil y del ordenador

Una llave física FIDO2/WebAuthn es un dispositivo criptográfico especializado. Puede parecer un pequeño pendrive, pero su función no es almacenar archivos. Está diseñada para realizar operaciones de autenticación.

Puede conectarse mediante USB-A, USB-C o NFC, según el modelo. Para un uso centrado en passkeys no es necesario adquirir necesariamente un dispositivo multiprotocolo avanzado: una llave sencilla compatible con FIDO2/WebAuthn puede ser suficiente.

Qué aporta frente a una passkey almacenada en el PC

Una credencial local del ordenador puede depender de la instalación concreta del sistema, de su TPM o del sistema de sincronización utilizado. Una llave física independiente sigue existiendo aunque se sustituya el ordenador o se reinstale el sistema operativo.

Esto la convierte en un excelente mecanismo de emergencia:

teléfono averiado + ordenador nuevo no tiene por qué significar pérdida de la cuenta si existe una llave física previamente registrada.

PIN FIDO2

Las llaves modernas pueden utilizar un PIN FIDO2 propio. Este PIN no es la contraseña del proveedor, ni el PIN de Windows, ni el PIN del teléfono. Protege el uso de la credencial dentro del autenticador.

La idea es combinar:

• Algo que se posee: la llave física.
• Algo que se conoce: su PIN.

Comprar a fabricantes especializados

Cuando la llave va a proteger accesos críticos conviene cuidar también la cadena de suministro. Es preferible utilizar fabricantes especializados de llaves de seguridad hardware FIDO2/WebAuthn y, cuando sea viable, comprar mediante su canal directo o un distribuidor autorizado.

Esto no elimina cualquier riesgo imaginable, pero reduce incertidumbres frente a dispositivos genéricos, vendedores desconocidos o hardware de procedencia dudosa.

Cómo evitar depender de un único móvil o dispositivo

La redundancia debe ser física, no sólo lógica. Tener TOTP y mensajería en el mismo smartphone proporciona dos métodos, pero ambos pueden desaparecer con el mismo incidente.

Una arquitectura más sólida puede ser:

• Método habitual: TOTP en un dispositivo controlado.
• Método alternativo: passkey o llave física FIDO2.
• Recuperación: mecanismos documentados por el proveedor y conservados fuera del dispositivo principal.

Dos llaves físicas para cuentas especialmente críticas

Cuando la dependencia del servicio es elevada, puede ser razonable registrar dos llaves físicas distintas:

• Llave A, disponible para uso o recuperación.
• Llave B, guardada separadamente.

No es necesario clonar una llave. Cada dispositivo se registra de manera independiente en la cuenta.

Si una se pierde, se accede con la otra, se revoca la llave desaparecida y se registra una nueva.

La seguridad de una API es un problema distinto

Proteger perfectamente el inicio de sesión del administrador no protege automáticamente una API key ya emitida.

Un robot que consume una API suele utilizar una credencial de servicio. No introduce la contraseña del administrador ni un código TOTP en cada llamada. Por tanto, si esa clave es copiada, el atacante puede intentar usarla directamente.

Antes de automatizar un servicio conviene entender bien la diferencia entre autenticación humana y autenticación de software. Si se necesita una visión más amplia de cómo funcionan los clientes, credenciales y formas de consumo, puede consultarse el artículo Cómo conectarse a una API: formas de acceder, probar y consumir APIs.

Separar credenciales por proyecto

Cuando el proveedor lo permita, es preferible evitar una única clave universal para toda la empresa. Una credencial por proyecto o robot facilita:

• Revocar sólo el componente comprometido.
• Identificar mejor el origen del consumo.
• Aplicar permisos específicos.
• Establecer límites diferentes.
• Rotar credenciales sin afectar a otros sistemas.

Restricciones por IP autorizada

Cuando una API permite establecer una lista de direcciones IP autorizadas, esta medida puede reducir mucho el impacto del robo de una clave.

Supongamos que un robot siempre realiza sus peticiones desde un servidor con IP pública fija. Puede configurarse:

API key válida + IP autorizada = petición permitida.

API key válida + IP diferente = petición rechazada.

Esto significa que una clave filtrada pierde gran parte de su utilidad para un atacante que intenta usarla desde otra infraestructura.

Qué no soluciona una IP allowlist

No debe confundirse con una protección absoluta. Si el propio servidor autorizado es comprometido, el atacante puede generar tráfico desde una IP válida.

Tampoco debe suponerse que una restricción aplicada a las llamadas API protege necesariamente el inicio de sesión humano en el panel del proveedor. Son superficies diferentes.

Por eso la restricción por IP debe combinarse con:

• MFA para las cuentas administrativas.
• Permisos mínimos para las credenciales.
• Límites de consumo.
• Monitorización.
• Rotación y revocación de claves.

Límites de consumo, gasto y velocidad

En los servicios con tarificación por uso, la seguridad debe incorporar una dimensión económica. No basta con evitar accesos no autorizados: también hay que limitar cuánto daño podría producirse si una credencial válida es utilizada indebidamente.

Límites de velocidad

Según el proveedor pueden existir controles equivalentes a solicitudes por minuto, unidades procesadas por minuto, tokens por minuto u otros límites operativos.

La buena práctica consiste en configurarlos cerca de las necesidades reales del sistema, dejando un margen razonable, pero evitando valores enormes que jamás serían necesarios en la operativa normal.

Presupuestos y límites de gasto

Si el proveedor ofrece presupuestos, límites duros, alertas o controles de recarga, deben formar parte del diseño de seguridad. Conviene distinguir con claridad entre:

• Un aviso de consumo.
• Un presupuesto informativo.
• Un límite que realmente impide seguir consumiendo.

No todos los proveedores interpretan estos conceptos de la misma manera, por lo que hay que comprobar qué ocurre exactamente cuando se alcanza cada umbral.

Reducir límites cuando no hay actividad

En automatizaciones que sólo trabajan durante determinadas ventanas temporales, puede tener sentido reducir los límites cuando los procesos están inactivos, siempre que el proveedor permita hacerlo sin introducir un riesgo operativo mayor.

Monitorización y respuesta ante incidentes

Una arquitectura segura puede fallar si nadie revisa lo que ocurre.

En servicios con consumo económico conviene revisar periódicamente:

• Consumo diario o semanal.
• Credenciales activas.
• Proyectos existentes.
• Direcciones IP permitidas.
• Inicios de sesión y alertas de seguridad disponibles.
• Métodos MFA registrados.
• Usuarios con privilegios administrativos.

Qué hacer ante una anomalía

Debe existir un procedimiento sencillo y conocido:

1. Revocar la credencial sospechosa.
2. Detener temporalmente la automatización si es necesario.
3. Revisar consumo y registros.
4. Cambiar credenciales relacionadas cuando exista posibilidad de exposición.
5. Comprobar los métodos de autenticación de la cuenta administrativa.
6. Reactivar de forma controlada con nuevas credenciales.

La capacidad de actuar rápidamente reduce mucho el impacto de un incidente.

Arquitectura recomendada para un profesional o una pequeña empresa

Una configuración robusta y razonablemente sencilla puede organizarse de la siguiente manera.

Protección de la cuenta administrativa

• Contraseña larga, aleatoria y exclusiva.
• MFA activado.
• TOTP como método habitual, si el proveedor lo admite.
• Passkey o llave física FIDO2 como método resistente al phishing y alternativa independiente.
• Métodos de recuperación conocidos y verificados antes de necesitarlos.
• Segunda llave física para servicios realmente críticos, si el riesgo lo justifica.

Protección de los robots y APIs

• Una credencial específica por proyecto o proceso.
• Permisos mínimos.
• IP allowlist cuando sea técnicamente posible.
• Valores de velocidad ajustados a la carga real.
• Controles económicos.
• Monitorización periódica.
• Procedimiento de revocación y rotación.

Separación de dispositivos

Para reducir puntos únicos de fallo puede establecerse:

• Un móvil controlado para TOTP.
• Una llave física independiente.
• Un ordenador que no sea el único lugar donde exista capacidad de recuperación.

La idea no es acumular dispositivos, sino evitar que el robo o avería de uno solo elimine todos los caminos legítimos de acceso.

Plan de implantación por fases

No es necesario cambiar toda la seguridad de una empresa en una tarde. Resulta más seguro implantar las medidas por fases y comprobar cada una antes de pasar a la siguiente.

Fase 1: inventario

1. Identificar las cuentas críticas.
2. Identificar las APIs que pueden generar consumo económico.
3. Localizar las credenciales actualmente activas.
4. Anotar qué métodos de recuperación ofrece cada proveedor.

Fase 2: endurecer las cuentas

1. Asignar contraseñas únicas.
2. Activar MFA.
3. Configurar TOTP si está disponible.
4. Probar un cierre e inicio de sesión controlado.

Fase 3: introducir FIDO2

1. Adquirir una llave de fabricante especializado.
2. Verificar el dispositivo cuando el fabricante ofrezca mecanismos para ello.
3. Configurar su PIN FIDO2.
4. Registrar la llave en las cuentas compatibles.
5. Probar el acceso antes de considerarla un mecanismo de emergencia válido.

Fase 4: proteger las APIs

1. Separar claves por proyecto.
2. Aplicar IP allowlist.
3. Reducir permisos.
4. Ajustar límites de consumo y velocidad.
5. Configurar controles económicos disponibles.

Fase 5: documentar

Debe quedar documentado qué hacer si:

• se pierde el móvil;
• se pierde la llave física;
• se formatea el ordenador;
• se roba una API key;
• se detecta consumo anormal;
• fallece o deja de estar disponible la persona que administraba el sistema.

Errores habituales al intentar mejorar la seguridad

Concentrar todos los factores en el mismo smartphone

Puede resultar cómodo, pero reduce la independencia entre mecanismos.

Pensar que una passkey es siempre una llave USB

Una passkey puede residir en múltiples tipos de dispositivos. Hay que saber dónde se está almacenando antes de confiar en ella como respaldo.

Comprar una llave física y no probarla

Registrar una llave no basta. Debe realizarse un inicio de sesión de prueba antes de considerarla un mecanismo de recuperación.

Guardar una única llave junto al teléfono

Si ambos viajan juntos, un mismo robo puede eliminar los dos mecanismos.

Creer que MFA protege una API key robada

La clave API puede utilizarse independientemente de la sesión humana. Necesita controles propios.

Confiar sólo en alertas de gasto

Una alerta informa; no necesariamente detiene el consumo. Hay que conocer la diferencia entre alertas, presupuestos y límites efectivos.

Configurar límites exageradamente altos

Un límite muy superior al uso normal protege poco frente a automatizaciones maliciosas.

No revisar la recuperación

Un sistema puede ser muy resistente a ataques y, al mismo tiempo, estar mal diseñado para la recuperación legítima. Ambas dimensiones deben comprobarse.

Cuándo conviene revisar la arquitectura con un especialista

En una microempresa es razonable gestionar internamente una configuración sencilla. Sin embargo, cuando una cuenta controla varias plataformas, existen APIs con tarificación variable, funcionan robots de forma desatendida o una credencial comprometida podría producir un gasto significativo, el problema deja de ser únicamente “activar el 2FA”.

En esos casos hay que revisar conjuntamente identidades, métodos de recuperación, privilegios, arquitectura de claves, servidores de origen, restricciones de red, límites de consumo y procedimientos de respuesta.

Una revisión de seguridad bien planteada no consiste en añadir indiscriminadamente herramientas. Consiste en localizar los puntos únicos de fallo y decidir qué combinación de controles reduce realmente el riesgo sin hacer la operativa diaria inmanejable.

Para un autónomo o una pyme pequeña, el objetivo debería ser conseguir una arquitectura que pueda entender, mantener y comprobar periódicamente. Una configuración muy sofisticada pero mal documentada puede terminar siendo menos segura que un sistema más sencillo y bien controlado.

Preguntas frecuentes