Funcionamiento, riesgos, almacenamiento, rotación y uso controlado de credenciales estáticas en APIs corporativas
Edición en profundidad - material de estudio y consulta profesional
Por João Ricardo Dutra••Material íntegro
Tres mecanismos de credenciales con propiedades muy diferentes
Figura inicial: las , y parecen simples, pero requieren una gestión de credenciales completa.
Principio central
Todos dependen de , gestión secreta, privilegios mínimos, rotación y observabilidad para un uso seguro.
Edición en profundidad: material de estudio y consulta profesional.
Presentación del capítulo
El capítulo anterior separó autenticación y autorización y mostró que una identidad sólo resulta útil cuando existe una prueba, un principal y una decisión de acceso. Ahora, el curso profundiza en tres mecanismos históricamente importantes que aún se encuentran en las corporativas: Basic, y . Aparecen en integraciones heredadas, automatizaciones, productos SaaS, puertas de enlace, dispositivos y sistemas internos que necesitan una incorporación sencilla.
La simplicidad operativa es la razón principal de su persistencia, pero también crea dificultades. envía una credencial reutilizable en cada llamada y depende completamente de para su confidencialidad. evita transmitir la contraseña directamente y utiliza desafío-respuesta, pero sigue siendo sensible a contraseñas débiles, reproducción mal controlada y limitaciones de interoperabilidad. Las identifican aplicaciones y planes de consumo, pero a menudo se tratan como si fueran una identidad de usuario sólida o una autorización suficiente para cualquier operación.
Los tres mecanismos son credenciales estáticas o de larga duración en comparación con cortos. Por tanto, la seguridad no puede limitarse al formato del encabezado. Es necesario considerar generación, almacenamiento, exposición de registros, rotación, revocación, alcance, cuotas, segregación por ambiente, auditoría y respuesta a incidentes. Una clave segura filtrada sigue siendo una credencial válida hasta que la plataforma la detecta y la revoca.
Este capítulo presenta el marco de autenticación , el flujo detallado de y , la arquitectura de administración de y la aplicación en . El objetivo es permitir al lector reconocer cuándo estos mecanismos son aceptables, qué controles compensatorios son indispensables y cuándo se debe priorizar la migración a 2.0, o identidades de workload.
Cómo estudiar este capítulo
Para cada mecanismo, realice un seguimiento de la credencial desde la emisión hasta la revocación. Pregunte dónde existe el secreto a la vista, quién puede reutilizarlo, cómo la puerta de enlace identifica al consumidor, cómo recibe el contexto el y durante cuánto tiempo una exposición permanecería válida.
Objetivos de aprendizaje
Explique el marco de desafíos y el papel de 401, autenticación y autorización WWW.
Describir la codificación de y diferenciar del cifrado.
Analizar los riesgos de exposición, reproducción, intercambio y almacenamiento de contraseñas.
Comprender el desafío-respuesta de y sus principales parámetros.
Explique , , , , , , algorithm y .
Reconocer las limitaciones prácticas y de seguridad de en las modernas.
Distinga la de la identidad del usuario, el y la firma .
Diseñar generación, almacenamiento, alcance, cuota, rotación y revocación de claves.
Aplique validación de credenciales a sin propagar secretos al .
Planifique la migración de credenciales estáticas a mecanismos de prueba de posesión o de corta duración.
Estructura del capítulo
15.1 Credenciales estáticas en el contexto de las
15.2 Marco de autenticación
15.3 : formato y flujo
15.4 no es cifrado
15.5 sobre e intermediarios
15.6 Almacenamiento y validación de contraseñas
15.7 Hardening y migración de
15.8 : motivación y desafío-respuesta
15.9 Parámetros y cálculo de
15.10 , , y limitaciones
15.11 : modelo de propósito y amenaza
15.12 Generación, formato y distribución
15.13 Almacenamiento, búsqueda y metadata
15.14 Alcances, cuotas y autorización
15.15 Rotación, revocación y detección de fugas
15.16 Firma de solicitudes y mecanismos relacionados
15.17 Uso en
15.18 Comparación, retroubleshooting y estudios de casos
Resumen, lista de verificación, ejercicios, glosario y referencias.
15.1 Credenciales estáticas en el contexto de las
Una credencial estática es un valor que permanece válido durante un tiempo relativamente largo y se puede reutilizar en varias llamadas. Las contraseñas y las entran en esta categoría. El problema no es solo la duración: debido a que el mismo valor prueba el acceso repetidamente, cualquier copia obtenida por registro, repositorio, estación comprometida, o fuga de configuración se puede utilizar hasta su vencimiento o revocación.
Las credenciales estáticas ofrecen una implementación sencilla. Un consumidor recibe un nombre de usuario y contraseña o una clave, agrega un encabezado y llama a la . No hay servidor de autorización, flujo de obtención de ni renovación. Esta simplicidad puede ser apropiada en laboratorios, integraciones estrechas y sistemas heredados, pero transfiere la responsabilidad a procesos operativos que muchos equipos descuidan.
En una arquitectura segura, cada credencial tiene una identidad individual, propietario, entorno, propósito, alcance, fecha de creación, vencimiento, último uso, estado e historial de rotación. Compartir la misma credencial en múltiples sistemas destruye la trazabilidad y coordina la revocación. El principio fundamental es que la simplicidad del protocolo no puede significar ausencia de gobernanza.
Tabla 1: La credencial estática segura depende del ciclo de vida explícito.
Propiedad
Pregunta operativa
Riesgo si está ausente
Individualización
¿Qué aplicación o persona controla la credencial?
Incapacidad para asignar tráfico e incidencia.
Alcance
¿Qué API y operaciones se pueden utilizar?
El compromiso amplía el acceso lateral.
Caducidad
¿Cuándo deja de aceptarse el valor?
El secreto abandonado permanece activo.
Rotación
¿Cómo intercambiar sin indisponibilidad?
La credencial nunca se renueva.
Revocación
¿Cuánto tiempo para bloquear una fuga?
Larga ventana de abuso.
15.2 Marco de autenticación
define un marco de autenticación general basado en desafíos. Cuando un recurso requiere autenticación y el cliente no presenta una credencial aceptable, el servidor puede responder 401 Unauthorized acompañado de uno o más encabezados . Cada desafío informa el esquema y los parámetros requeridos, como el dominio. El cliente elige un esquema compatible y repite la solicitud con Autorización.
El nombre 401 Unauthorized es históricamente confuso: en la práctica, representa la ausencia o falla de autenticación. Una vez autenticada la identidad, una denegación por falta de permiso suele utilizar 403 Prohibido. Esta separación preserva la semántica, facilita la retroubleshooting y evita que los consumidores intenten intercambiar credenciales cuando el verdadero problema es la autorización.
Una puerta de enlace puede anunciar más de un desafío u ocultar detalles para reducir la enumeración. En las , también es común recibir credenciales de forma preventiva, sin el primer 401. Aún así, comprender el modelo de desafío es esencial para Basic y , además de ayudar con la interpretación de registros, clientes y bibliotecas.
Figura 1: y utilizan el marco de desafío definido por .
Basic utiliza un identificador de usuario y una contraseña combinados en el formato ID de usuario:contraseña. La secuencia de bytes resultante está codificada en y se envía en el Authorization con el prefijo Basic. El servidor descifra el valor, encuentra la cuenta y verifica la contraseña. En las integraciones de máquina a máquina, la identificación de usuario puede representar una aplicación o una cuenta técnica, pero esto no transforma automáticamente el mecanismo en una identidad sólida de workload.
El cliente puede esperar un desafío 401 o enviar el encabezado en la primera llamada. Muchos y herramientas ocultan este detalle. En ambos casos, la credencial se transmite en todas las solicitudes, incluso cuando se abren diferentes conexiones. Esto aumenta la superficie de exposición en comparación con una contraseña utilizada únicamente para obtener un de corta duración.
El permite al servidor indicar el espacio de protección. Los clientes pueden utilizar esta información para decidir qué credenciales reenviar. En entornos con múltiples hosts, redirecciones y servidores , la configuración debe evitar que la autorización se reenvíe a un destino que no sea de confianza.
Ejemplo conceptual de
# Texto lógico antes de la codificación
integracion-facturacion:ContrasenaDeEjemplo
# Header HTTP
Authorization: Basic aW50ZWdyYWNhby1mYXR1cmFtZW50bzpTZW5oYURlRXhlbXBsbw==
15.4 no es cifrado
es una codificación para representar bytes en caracteres seguros para el transporte textual. No utiliza clave, no ofrece confidencialidad y puede ser revertido por cualquier persona o herramienta. Tratar el valor como o cifrado es un error grave. Sólo protege contra problemas de suplantación, no de observación del tráfico.
Por este motivo, la solo debe utilizarse sobre correctamente validado. Sin , el nombre de usuario y la contraseña quedan expuestos a quien capture la comunicación. Incluso con , la credencial puede aparecer en registros de depuración, volcados de memoria, herramientas de observabilidad, historial de comandos, variables de entorno y configuraciones. El canal protegido no corrige las fugas en los o terminadores intermediarios.
La codificación tampoco impide la repetición. Si un atacante obtiene el encabezado completo, puede reutilizarlo siempre que la contraseña siga siendo válida. La protección se basa en un alto secreto, rotación, detección de anomalías, limitación de reintentos y privilegios mínimos.
Figura 2: El único elemento que protege la confidencialidad de la en tránsito es el canal .
Regla de funcionamiento
Nunca coloque en , cadenas de consulta, registros, tickets o ejemplos con credenciales reales. Las redacciones visuales en las capturas de pantalla no eliminan el valor de los archivos de configuración o los historiales del terminal.
15.5 sobre e intermediarios
Cuando hay un inverso o , puede finalizar antes que el . El tramo cliente- y el tramo - son conexiones independientes. Si el pasa la Autorización original al , la contraseña continúa circulando internamente y puede aparecer en más puntos de observación. Una mejor arquitectura valida la credencial en el borde y reenvía una identidad interna restringida o un de corta duración.
Los redireccionamientos también merecen atención. Los clientes seguros evitan reenviar la autorización a otro host, pero los comportamientos varían según la biblioteca y la configuración. Un autenticado no debe responder con una redirección a un dominio que no sea de confianza. Las reglas de deben eliminar los encabezados de identidad externos antes de insertar un contexto validado.
El servidor debe aplicar protección contra la fuerza bruta y el relleno de credenciales. Limitación de tarifas por cuenta, fuente y dispositivo, bloqueo progresivo, detección de contraseñas filtradas, monitoreo y ayuda de alertas. El bloqueo permanente después de algunos intentos puede causar denegación de servicio; La política debe equilibrar la seguridad y la disponibilidad.
15.6 Almacenamiento y validación de contraseñas
El servidor no debe almacenar una contraseña reversible solo para compararla con el valor recibido. Las contraseñas de los usuarios humanos deben estar protegidas mediante funciones de derivación específicas, con sal individual y parámetros de costo adecuados. El cheque recalcula la derivada y la compara en tiempo constante. Las cuentas técnicas se pueden migrar a claves, certificados o identidades de cargas de trabajo, evitando tratar los secretos de las aplicaciones como contraseñas humanas.
Basic requiere que el servidor obtenga la contraseña presentada en cada llamada y la valide. Esto no significa que la contraseña deba quedar clara en el banco. Sin embargo, algunos sistemas heredados delegan la autenticación en directorios o almacenan credenciales reversibles para la integración. Estos casos aumentan el impacto del compromiso y deben contar con un plan de migración.
Los registros de autenticación deben registrar el identificador, el resultado, el motivo categorizado, el origen, la correlación y la política aplicada, pero nunca la contraseña ni el Authorization. Los mensajes al cliente deben evitar diferenciar un usuario inexistente de una contraseña incorrecta cuando esto permita la enumeración.
Tabla 2: El almacenamiento seguro reduce el impacto de las fugas en el almacén de credenciales.
Elemento
Mejores prácticas
evitar
banco de contraseñas
Sal individual y función bypass adecuada.
Borrar contraseña o cifrado reversible sin necesidad.
Comparación
Rutina constante y biblioteca consolidada.
Comparaciones de viviendas y registros de valores.
cuenta técnica
Identidad individual y propietario.
Usuario compartido por múltiples trabajos.
Observabilidad
Resultado, origen y correlación.
Autorización y contraseña en el log.
15.7 Migración y refuerzo de
se puede tolerar en una integración controlada cuando se requiere , la cuenta es individual, la contraseña es aleatoria y larga, el acceso es limitado y hay rotación. También debe haber un plan de reemplazo. El mecanismo no es adecuado para credenciales humanas en de alto riesgo o para aplicaciones distribuidas que no pueden proteger secretos estáticos.
Una migración común introduce credenciales de cliente 2.0, o identidad administrada. Durante la coexistencia, la puerta de enlace acepta Basic solo para consumidores registrados, registra el uso por client_id y comunica la fecha límite de retiro. El nuevo mecanismo se activa en paralelo; Una vez que la telemetría confirma la migración, se revoca la contraseña anterior.
No basta con cambiar Basic por un de larga duración copiado en la configuración. El objetivo es reducir la reutilización y la superficie: cortos, audiencia específica, alcance mínimo, emisión auditable y credenciales de cliente protegidas por bóveda o prueba asimétrica.
Criterios de migración
Priorice a los consumidores con credenciales compartidas, falta de rotación, acceso privilegiado, que se ejecutan en dispositivos que no son de confianza o exposición pública. Estos factores aumentan el impacto y la probabilidad de compromiso.
15.8 : motivación y desafío-respuesta
se creó para evitar que la contraseña se envíe directamente al servidor con cada solicitud. El servidor envía un desafío con opciones de , , algoritmo y calidad de protección. El cliente combina estos valores con nombre de usuario, contraseña, método y para calcular una respuesta . El servidor realiza un cálculo equivalente y compara el resultado.
El es un valor emitido por el servidor para limitar la reutilización. El cliente también puede enviar contador y . Con =auth, el método y el ingresan a la prueba, vinculando la respuesta a la solicitud. En =auth-int también participa el órgano de la entidad, aunque el soporte operativo es más complejo.
mejora una propiedad específica respecto a Basic: la contraseña no aparece directamente en el cable. Sin embargo, no reemplaza a . Los metadata y el contenido permanecen expuestos sin cifrado de canal, y aún es necesario considerar la degradación, la manipulación o los ataques de captura sin conexión.
Figura 3 - El cliente demuestra conocimiento de un secreto sin enviar la contraseña directamente.
15.9 Parámetros y cálculo de
El separa espacios de protección y participa en el cálculo. El lo genera el servidor; es un valor que el cliente devuelve sin interpretar. El algoritmo informa la función y posibles variantes con -sess. selecciona la calidad de protección. es el contador de uso de y es un valor aleatorio producido por el cliente.
De forma simplificada con =auth, se calcula a partir del usuario, y la contraseña; del método y destino de solicitud; y respuesta de , , , , y . La implementación debe seguir estrictamente las especificaciones y utilizar bibliotecas probadas. Pequeñas diferencias en codificación, , juego de caracteres o parámetros producen fallas que son difíciles de diagnosticar.
Los algoritmos y parámetros deben negociarse de forma segura. Las implementaciones no deberían aceptar rebajas silenciosas por opciones débiles cuando la política requiere algoritmos más sólidos. También es importante validar que el cliente responda al mismo , y asociados con el desafío.
Tabla 3: Los parámetros del Digest deben validarse como un conjunto coherente.
Parámetro
Origen
Función
realm
Servidor
Define el espacio de protección y participa en el cálculo.
nonce
Servidor
Hace que la prueba dependa de una prueba y de una validez temporal.
opaque
Servidor
Valor opaque devuelto por el cliente.
qop
Servidor/cliente
Seleccione autenticación u otra calidad admitida.
cnonce
Cliente
Agrega aleatoriedad controlada por el cliente.
nc
Cliente
Cuenta los usos del nonce y ayuda a detectar la repetición.
response
Cliente
Prueba de hash calculada para la solicitud.
15.10 , , y limitaciones de
Un seguro debe ser impredecible o estar autenticado, tener una ventana de validez y estar vinculado al contexto necesario. El servidor puede mantener el estado o codificar la marca de tiempo y MAC en el valor. Cuando el expira, el desafío puede indicar =true, lo que permite al cliente repetir la operación con un nuevo sin asumir que el nombre de usuario o la contraseña son incorrectos.
El contador debe crecer por cada uso del mismo y . El servidor puede detectar la reproducción, pero esto requiere lógica de estado o de ventana. Los clústeres distribuidos y las puertas de enlace deben compartir o validar esta información de manera consistente. Una implementación que solo verifica el e ignora el contador y la validez pierde una parte importante de la protección de reproducción.
permanece sujeto a ataques fuera de línea cuando un atacante captura el desafío y la respuesta y la contraseña tiene baja entropía. Tampoco ofrece confidencialidad de la carga útil, no resuelve la autorización, no reemplaza a y tiene una interoperabilidad desigual entre clientes, servidores y puertas de enlace. En las modernas, a menudo se mantiene por compatibilidad, no como primera opción para nuevos proyectos.
Límite de seguridad
protege la contraseña en tránsito de manera diferente a , pero no transforma una contraseña débil en una credencial segura. Capturar una respuesta puede permitirle probar a los candidatos sin conexión sin volver a interactuar con el servidor.
15.11 : modelo de propósito y amenaza
La es un valor asignado a una suscripción de consumidor, aplicación, proyecto o producto. Le permite identificar quién está utilizando la , aplicar cuotas, limitación de tarifas, facturación, análisis y políticas. En algunos entornos también se utiliza como autenticación de aplicaciones. Sin embargo, la posesión de la clave no prueba la identidad humana ni establece, en sí misma, una autorización comercial.
Una clave normalmente es portadora: cualquiera que conozca el valor puede utilizarla. Por lo tanto, no debe integrarse en un JavaScript público, una aplicación móvil distribuida, un repositorio o un firmware fácilmente extraíble cuando el acceso asociado sea confidencial. En clientes públicos, la clave sólo puede servir como identificador de producto, sin ser tratada como un secreto fuerte.
El modelo de amenaza incluye filtraciones en registros, cadenas de consulta, herramientas de análisis, historial del navegador, referencias, canalizaciones, contenedores, cuadernos, mensajes y soporte. También incluye compartir intencionalmente entre equipos, copiar en el entorno incorrecto y permanecer después de que se cancela el propietario.
15.12 Generación, formato y distribución de
Se debe generar una con una fuente criptográficamente segura y suficiente entropía para evitar conjeturas. Los formatos legibles por humanos pueden incluir un prefijo no secreto que identifica el producto o el entorno, seguido de material aleatorio. El prefijo facilita el enrutamiento, el soporte y la detección de la clave de prueba utilizada en producción sin revelar el secreto completo.
La clave solo debe mostrarse al consumidor en el momento de su creación o a través de un canal seguro. Luego, la plataforma almacena una representación protegida. El correo electrónico, las hojas de cálculo y los tickets no son seguros. Las aplicaciones deben recibir el valor a través de un , una canalización protegida o un mecanismo de arranque, y nunca mediante la confirmación de código.
Las claves de producción, homologación y desarrollo deben ser diferentes. La segregación reduce la propagación de fugas y permite políticas diferentes. La plataforma también puede limitar el origen, el certificado, el host, la o la operación de la red, pero estos controles complementan y no reemplazan la protección de claves.
Figura 4: La emisión es solo el comienzo del ciclo de vida de una .
15.13 Almacenamiento, búsqueda y metadata
Cuando la clave solo funciona como portadora, el servidor no necesita almacenar el valor en formato claro. Puede almacenar o MAC y comparar la presentación. Para una búsqueda eficiente, son útiles los formatos con identificador público y secreto separado: el prefijo ubica el registro y el secreto se valida de forma segura. Esto evita escanear toda la base de con cada solicitud.
El registro de clave debe contener propietario, aplicación, producto, entorno, alcances, cuotas, estado, creación, vencimiento, última rotación, último uso y motivo de revocación. Los metadata permiten tomar decisiones sin exponer el secreto. También admite campañas de inventario, informes de claves huérfanas y rotación.
Si la plataforma necesita recuperar el valor para firmar solicitudes en nombre del consumidor, la clave ya no es solo una clave de verificación y requiere almacenamiento reversible en una bóveda o , con controles de auditoría y acceso más estrictos. Este caso debe distinguirse de una clave utilizada únicamente para autenticar llamadas entrantes.
Tabla 4: La separación de identificador, secreto, verificador y metadata mejora la operación y la respuesta a incidentes.
Componente
Contenido
Exposición
ID de clave/prefijo_
Identificador público para búsqueda.
Puede aparecer en registros y portales.
secret
Material aleatorio presentado en la convocatoria.
Solo para consumidores y proceso de validación.
verificador
Hash o MAC del secreto.
Banco protegido; no permite el uso directo.
metadata
Propietario, alcance, cuota, estado y fechas.
Servicios de gestión y políticas.
15.14 Transmisión, alcances, cuotas y autorización
Las deben transmitirse preferiblemente en un encabezado dedicado o Autorización con un esquema definido por la plataforma. Ponerlos en una cadena de consulta aumenta las filtraciones en los registros de acceso, el historial, los análisis, las cachés y los encabezados de Referer. sigue siendo obligatorio porque una clave capturada se puede reutilizar.
Cada clave debe tener un alcance mínimo: producto, , operaciones, entorno y, cuando sea posible, datos o inquilino específicos. Las cuotas y el limitan el consumo y reducen el impacto del abuso, pero no equivalen a una autorización. Una clave con una cuota de mil llamadas aún puede acceder a un objeto inadecuado si el servidor no valida la propiedad.
Para operaciones de nombre de usuario, la puede identificar la aplicación mientras otro mecanismo autentica al usuario. Esta separación permite asignar el tráfico a dos sujetos: cliente técnico y usuario final. La puerta de enlace debe preservar tanto el contexto como los registros sin confundirlos.
Métodos de transmisión de
# Header dedicado
X-API-Key: pk_live_7F2A...secreto...
# O esquema de Authorization definido por el proveedor
Authorization: ApiKey pk_live_7F2A...secreto...
# Evitar
GET /v1/clientes?api_key=pk_live_7F2A...
15.15 Rotación, revocación y detección de fugas
La rotación sin tiempo de inactividad normalmente requiere un período de superposición. El consumidor crea o recibe una segunda clave, actualiza sus aplicaciones, valida el tráfico con el nuevo valor y sólo entonces revoca el anterior. Las plataformas pueden permitir dos claves activas por suscripción. El período de coexistencia debe ser breve y vigilado para evitar duplicaciones permanentes.
La revocación debe ser rápida y global. Los cachés de puerta de enlace deben respetar el estado de compatibilidad con riesgos y el . En incidentes, el equipo necesita encontrar todos los entornos y dependencias que utilizan la clave. Esto sólo es posible cuando cada consumidor tiene sus propias credenciales y un inventario confiable.
La detección de fugas puede utilizar escáneres de repositorio, patrones de prefijos, monitoreo de origen, aumento repentino de volumen, cambios geográficos y uso fuera de horario. Los Honeytokens o las claves no utilizadas deliberadamente pueden generar alertas inmediatas cuando aparecen en el tráfico.
Tabla 5 - La respuesta depende del inventario, la individualización y la capacidad de revocación.
Evento
Acción inmediata
Acciones adicionales
Sospecha de fuga
Deshabilitar o reducir privilegios; preservar la evidencia.
Investigar el origen y emitir una nueva clave.
Rotación planificada
Activar nueva clave en paralelo.
Confirmar el uso y revocar el antiguo.
Propietario desconectado
Suspender las credenciales asociadas.
Reasignar o eliminar integración.
clave sin usar
Confirme con el propietario y bloquee la prueba.
Eliminar activo huérfano.
15.16 Firma de solicitudes y mecanismos relacionados
La firma de solicitudes es diferente a simplemente enviar una . El cliente utiliza un secreto para calcular una firma sobre el método, la ruta, la marca de tiempo, los encabezados y el del cuerpo. El servidor recalcula y compara. La clave puede identificar al consumidor, mientras que la firma vincula la prueba a una solicitud específica y reduce la repetición cuando se validan la marca de tiempo y el .
Este modelo lo utilizan algunas financieras y de nube, pero requiere una canonicalización estricta. Las diferencias en codificación, orden de encabezados, ruta y normalización del cuerpo producen fallas. La seguridad depende de un fuerte secreto, una ventana temporal corta, una comparación segura, una protección del reloj y una prevención de la reutilización.
no reemplaza a : sin , el contenido y los metadata permanecen visibles y pueden manipularse antes de la verificación. Tampoco proporciona no repudio, porque el cliente y el servidor comparten el mismo secreto. Las firmas asimétricas o pueden ser más apropiadas cuando la separación de responsabilidades y la prueba de propiedad son importantes.
Distinción importante
Por lo general, una se presenta directamente. En la firma , el secreto no viaja; produce una firma específica para la solicitud. Los dos modelos requieren diferentes ciclos de vida y controles.
15.17 Uso en , Axway y Azure
El es un punto natural para validar , o , aplicar limitación de velocidad, registrar consumo y bloquear credenciales revocadas. La política debe ocurrir antes del enrutamiento al y debe distinguir falla de autenticación, clave suspendida, cuota excedida y falta de autorización. La puerta de enlace también debe eliminar las credenciales originales antes de reenviar la solicitud, siempre que el no las necesite.
En productos corporativos, la clave puede estar asociada a una aplicación, contrato, producto o suscripción. La puerta de enlace consulta el repositorio local, la caché o el servicio de administración. Los cachés mejoran el rendimiento, pero hacen que la revocación dependa de la propagación. Para credenciales críticas, el debe ser corto o la plataforma debe ofrecer invalidación activa.
La integración con Axway , Azure Management y otros productos debe validarse según la versión implementada. Las políticas pueden extraer encabezados, validar claves de suscripción, consultar bóvedas, aplicar cuotas y transformar el contexto. El diseño debe evitar la derivación directa al y garantizar que los encabezados de identidad insertados por la puerta de enlace no puedan falsificarse externamente.
Figura 5: la puerta de enlace valida la credencial y reenvía el contexto confiable, no el secreto original.
15.18 Comparación entre , y
Los tres mecanismos comparten la simplicidad y la falta de un flujo complejo de emisión de , pero resuelven problemas diferentes. transporta nombre de usuario y contraseña. crea pruebas basadas en la contraseña y un desafío. La identifica una aplicación o suscripción con un valor aleatorio. Ninguno de ellos, de forma aislada, proporciona autorización detallada, identidad federada o consentimiento delegado.
La elección debe considerar dónde se puede proteger la credencial, quién es el sujeto, la duración, la necesidad de rotación y la compatibilidad de los clientes. Para los nuevos servicios de alto riesgo, las credenciales cortas, , 2.0 o identidades de workload tienden a ofrecer mejores propiedades. , y siguen siendo útiles cuando se aplican con un alcance limitado y controles de compensación claros.
Tabla 6: Ningún mecanismo elimina la necesidad de TLS, alcance, rotación y autorización.
Criterio
Basic Auth
Digest
API Key
El secreto se transmite directamente
Sí, dentro de Base64 y TLS.
No como contraseña, pero existe una prueba reutilizable en contexto.
Sí, normalmente al portador.
Dependencia TLS
Total.
Sigue siendo necesario.
Total.
Sujeto típico
Cuenta de usuario o técnica.
Cuenta de usuario o técnica.
Solicitud, proyecto o suscripción.
Repetir después de la captura
Posible siempre que la contraseña sea válida.
Mitigado por nonce/nc cuando es correcto.
Posible siempre que la clave sea válida.
Operación
Simple, pero la contraseña necesita protección.
Más complejo y menos interoperable.
Simple, requiere un ciclo de vida robusto.
Uso recomendado
Legado controlado y temporal.
Compatibilidad específica.
Identificación y control de aplicaciones.
15.19 basada en evidencia
Cuando Basic falla, confirme que el encabezado llegó al punto correcto, que se generó a partir del juego de caracteres esperado, que la contraseña contiene caracteres especiales y que el o el redireccionamiento eliminaron la Autorización. Diferenciar entre 401 por credencial inválida y 403 por falta de permiso y 429 por cupo.
En , compare , , , algoritmo, y método utilizado en el cálculo. Verifique la sincronización entre nodos, la validez del , el contador y la canonicalización del objetivo de solicitud. Las fallas intermitentes del clúster a menudo indican un estado no compartido o claves diferentes para autenticar el desafío.
En las , investigue el nombre del encabezado, el entorno, el prefijo, el estado, la caducidad, los alcances, la cuota y la caché de revocación. Una clave de portal válida puede fallar en tiempo de ejecución si el producto, la suscripción o la implementación no son coherentes. Siempre correlacione los registros de la puerta de enlace, el servicio de administración y el .
Tabla 7 - El diagnóstico requiere identificar el punto que produjo la respuesta.
Síntoma
Hipótesis
evidencia
Basic devuelve 401
contraseña cambiada, Base64 incorrecta, realm o header eliminado
registros de autenticación, nodos, cuentas y encabezados enmascarados.
Digest falla después de un tiempo
nonce expirado, nc repetido o stale no tratado
desafío, marca de tiempo, contador y nodo de clúster.
La API key funciona en aprobación
clave o producto del entorno incorrecto
prefijo, metadata, implementación y suscripción.
La clave revocada aún funciona
caché o backend directamente accesible
TTL, invalidación y ruta de bypass.
429 inesperado
cuota compartida o clave reutilizada
propietario, mostradores y consumidores por clave.
15.20 Estudios de casos y laboratorios
Caso 1: contraseña compartida por diez integraciones
Diez trabajos utilizan el mismo usuario de . Aparece un secreto en un repositorio y la organización no puede atribuir su uso. La respuesta crea cuentas individuales, restringe alcances, migra a las credenciales de la aplicación y revoca el usuario compartido después de que la telemetría confirma la transición.
El caso muestra que el mayor problema no fue , sino la falta de individualización y rotación. Incluso en lo que respecta a , la filtración tuvo un amplio impacto y una baja trazabilidad.
Caso 2 - intermitente en clúster
Dos nodos emiten con claves diferentes y el balanceador distribuye llamadas sin afinidad. El cliente recibe un desafío de un nodo y envía la prueba al otro, que rechaza el . La solución comparte la clave de autenticación o utiliza una validación consistente entre nodos.
Las capturas y los registros muestran 401 sucesivos con diferentes . El error parecía una contraseña incorrecta, pero la causa estaba en el estado distribuido del motor.
Caso 3: expuesta en una cadena de consulta
Una integración envía la clave en consulta. El valor aparece en los registros de y en la herramienta de análisis. El equipo revoca la clave, elimina parámetros de los registros, cambia la transmisión al encabezado, agrega escáneres y revisa a todos los consumidores.
La investigación también identifica que se utilizó la misma clave en producción y prueba. La segregación por entorno reduce el impacto de futuras fugas.
Laboratorios sugeridos
Codifique y decodifique un valor de de laboratorio y tenga en cuenta que es reversible.
Configure un servidor local autorizado con desafío Basic e inspeccione 401, autenticación WWW y autorización.
Simule el cálculo del con controlado y cambie el método o para verificar la falla.
Modele una con prefijo público, secreto aleatorio y verificador almacenado.
Implemente la rotación con dos claves activas y confirme la revocación de la anterior.
Compare los registros de una clave en el encabezado y la cadena de consulta, utilizando solo valores ficticios.
Resumen del capítulo
La codifica el nombre de usuario y la contraseña en y envía la credencial en cada llamada. no protege el secreto; , almacenamiento adecuado, individualización, rotación y limitación de intentos son fundamentales. En las puertas de enlace, la credencial debe validarse en el borde y eliminarse antes del cuando sea posible.
utiliza desafío-respuesta con , , algoritmo, , y contador. Evita transmitir la contraseña directamente, pero se basa en una implementación estricta, una contraseña segura, control de y . Su complejidad e interoperabilidad significan que se adopta principalmente por compatibilidad.
Las identifican aplicaciones, proyectos o suscripciones y admiten cuotas y análisis. Como normalmente son portadores, necesitan alta entropía, transmisión de encabezados, almacenamiento protegido, metadata, alcance, rotación y revocación rápida. No reemplazan la identidad del usuario ni la autorización de un recurso.
Los mecanismos estáticos deben evaluarse durante todo el ciclo de vida. Para nuevos casos de alto riesgo, los cortos, , 2.0 y las identidades de cargas de trabajo ofrecen propiedades superiores. La migración debe basarse en la telemetría y la convivencia controlada.
Siguiente paso del curso
El capítulo 16 profundizará en el 2.0 completo: roles, otorgamientos, código de autorización con , credenciales de cliente, de actualización, alcances, seguridad y aplicación en .
Lista de verificación de credenciales estáticas
, y solo se aceptan a través de correctamente validado.
Cada consumidor tiene una credencial individual, un propietario y un entorno definido.
Los secretos no aparecen en , registros, código fuente, tickets ni análisis.
Las contraseñas están protegidas por un mecanismo de almacenamiento adecuado y nunca se registran.
tiene validez, integridad y control de repetición.
Los algoritmos de y siguen una política explícita y no se degradan silenciosamente.
Las tienen suficiente entropía, prefijo seguro y distribución a través de un canal protegido.
Los verificadores y los metadata están separados del secreto presentado.
Los alcances, cuotas y límites de tarifas no reemplazan la autorización de objetos y dominios.
La rotación permite una breve superposición y una revocación confirmada por telemetría.
Los cachés de puerta de enlace respetan la revocación y no crean ventanas excesivas.
No se puede acceder directamente al para evitar la política de puerta de enlace.
Las alertas detectan uso anómalo, origen inesperado y claves huérfanas.
Existe un plan de migración de credenciales cortas o asimétricas cuando el riesgo lo requiere.
Ejercicios
Explique por qué no protege la .
Describir el flujo 401, autenticación WWW y autorización.
Enumere los riesgos de compartir un usuario de entre aplicaciones.
Explique el papel de kingdom, , , y en .
Describa cómo =true cambia el comportamiento del cliente.
Explique por qué todavía necesita .
Diferenciar entre , de acceso e identidad de usuario.
Proponer un formato con key_id público y secreto aleatorio.
Describir el almacenamiento con verificador y metadata.
Cree un plan de rotación sin tiempo de inactividad.
Compare la directa y solicite la firma .
Describir la para la clave revocada que aún funciona en la puerta de enlace.
Glosario
Tabla 8 - Vocabulario esencial del capítulo.
Término
Definición
API Key
Valor asociado a la aplicación, proyecto, producto o suscripción API.
Base64
Codificación de bytes reversible para caracteres textuales.
Basic Auth
Esquema HTTP que transmite el ID de usuario y la contraseña codificados en Base64.
cnonce
Nonce creado por el cliente en HTTP Digest.
Credential stuffing
Uso automatizado de credenciales obtenidas de filtraciones anteriores.
Digest
Esquema de desafío-respuesta HTTP basado en hash.
HA1
Valor derivado del usuario, dominio y contraseña en Digest.
HA2
Valor derivado del método y el destino de la solicitud en Digest.
HMAC
Código de autenticación de mensajes basado en hash y secreto compartido.
ID_clave_
Identificador público utilizado para localizar el registro de una clave.
nc
Contador de uso de un nonce en Digest.
nonce
Valor utilizado una vez o dentro de una ventana limitada para reducir la repetición.
opaque
Valor de desafío resumido devuelto sin interpretación por parte del cliente.
qop
Calidad de la protección negociada en el Digesto.
realm
Espacio de protección anunciado por un desafío HTTP.
Replay
Reutilización no autorizada de una credencial o evidencia capturada.
Secret manager
Servicio de almacenamiento, distribución y auditoría de secretos.
stale
Indicación de que el nonce ha caducado, no necesariamente la contraseña.
Verifier
Representación protegida utilizada para validar un secreto sin almacenarlo de forma clara.
WWW-Authenticate
Encabezado de respuesta que anuncia desafíos de autenticación HTTP.
Anexo A - Matriz de decisión
Tabla 9 - La opción adecuada depende de la capacidad de proteger el secreto y del riesgo de la operación.
Escenario
Opción de inicio
Condiciones
Integración temporal heredada
Basic Auth
TLS, cuenta individual, contraseña segura, bóveda y fecha límite de migración.
Equipo con soporte restringido
Digest
Algoritmo seguro, nonce consistente, TLS y pruebas de interoperabilidad.
ID de aplicación y cuota
API Key
Clave individual, alcance, rotación y autorización separada.
Servicio interno moderno
Credenciales de cliente OAuth 2.0, mTLS o federación
Credencial corta, audiencia e identidad de workload.
Cliente o navegador móvil público
No confíes en la API key como un secreto
Backend intermedio, autenticación de usuarios y controles de abuso.
Solicitud que requiere prueba específica
HMAC o firma asimétrica
Canonicalización, marca de tiempo, nonce y protección de claves.
Referencias técnicas
. 9110 - Semántica . 2022.
. 7617: el esquema de autenticación Basic. 2015.
. 7616: Autenticación de acceso implícito . 2015.
. 7235 - Autenticación /1.1, posteriormente consolidada en 9110.
. Hoja de referencia de autenticación.
. Hoja de referencia para el almacenamiento de contraseñas.
. Hoja de trucos de seguridad .
. Hoja de referencia de gestión de secretos.
. SP 800-63B - Autenticación y gestión de autenticadores.
Microsoft aprende. Claves y políticas de suscripción de Azure Management.
Documentación Axway. , Basic y políticas de autenticación en .
Nota de actualización
Los protocolos y productos tienen detalles específicos de implementación y soporte. Antes de adoptar , o , valide la documentación oficial de la versión implementada y ejecute pruebas en un entorno autorizado.
