Cifrado
Dónde se usa el cifrado y dónde todavía no.
El cifrado protege una verificación en varios puntos distintos: la conexión, la imagen, el secreto, la copia de seguridad, la contraseña. Preferimos enumerar cada uno con honestidad antes que decir "cifrado" una sola vez y dejar que usted suponga que lo cubre todo.
En tránsito
TLS en el perímetro, y aplicado de forma obligatoria en la base de datos del registro.
Cada solicitud a ShieldID se cifra antes de llegar a la aplicación.
- El perímetro público finaliza TLS en cada conexión, con HSTS y un conjunto restringido de encabezados de seguridad, de modo que una solicitud se cifra antes de llegar a cualquier elemento posterior.
- La base de datos principal del registro exige TLS en cada conexión que acepta. Una conexión en texto sin cifrar se rechaza de plano, y no solo se desaconseja mediante la configuración.
- La aplicación verifica el certificado de la base de datos contra una autoridad fijada y comprueba su nombre de host, en lugar de confiar en el primer certificado que aparezca.
En reposo
Las imágenes de documentos y las fechas de nacimiento están cifradas. Somos específicos sobre qué más no lo está, por ahora.
Con frecuencia se dice "cifrado en reposo" de toda una plataforma de una sola vez. Esto es lo que eso realmente abarca hoy.
- Imágenes del documento de identidad y la selfie
- Cifradas con AES-256-GCM mientras están almacenadas, antes de la eliminación automática que las borra.
- Fecha de nacimiento
- Se almacenan cifradas, nunca en texto sin cifrar, dondequiera que las conserve un registro de verificación.
- Secretos (claves de API, credenciales de la base de datos, claves de firma)
- Se conservan en una bóveda de secretos dedicada, no en la configuración de la aplicación ni en el código fuente.
- El resto de la base de datos y los volúmenes de almacenamiento general
- Hoy no están cifrados a nivel de disco o de base de datos. Lo decimos directamente en lugar de dar a entender una cobertura total.
Secretos
Una sola bóveda, con acceso mediante token y con la rotación registrada.
Las credenciales de la aplicación no están dispersas en archivos de configuración.
Centralizado
Las claves de API, las credenciales de la base de datos y los secretos de webhook se conservan en un sistema dedicado de gestión de secretos, que se lee y se escribe únicamente mediante una API autenticada y con acceso por token.
La rotación se audita
Un proceso de rotación dedicado registra cada cambio de credenciales y cada intento rechazado en un registro a prueba de manipulaciones que almacena únicamente las huellas digitales de los valores, nunca los valores mismos.
Nunca en el código ni en la configuración
Los secretos se leen desde la bóveda al arrancar; no se incluyen en el código fuente ni se dejan en un archivo de entorno que se distribuya con una implementación.
Copias de seguridad
Se cifran antes de salir de la memoria, con un simulacro de restauración que puede ejecutar sin tocar producción.
Una copia de seguridad abarca la aplicación, su configuración y la base de datos.
- Cifradas con AES-256, mediante una clave conservada en la bóveda de secretos. Si esa clave no está disponible, el script de copia de seguridad se niega a escribir un archivo sin cifrar en lugar de recurrir a ello silenciosamente.
- Existe un procedimiento de restauración documentado y automatizado mediante script, que admite un modo de ensayo en una ubicación temporal, de modo que el proceso pueda probarse sin tocar los datos en producción.
- Hoy las copias de seguridad permanecen en las mismas instalaciones. No ofrecemos copias de seguridad con redundancia geográfica ni un sitio separado de recuperación ante desastres, y lo indicamos en las páginas de residencia y de cumplimiento, no solo aquí.
Contraseñas, sesiones y claves de API
Nada de lo que lo autentica se almacena en una forma que alguien pueda leer y reutilizar.
Tres tipos distintos de secreto, tres tratamientos distintos, todos de un solo sentido.
- Contraseñas
- Con hash, nunca almacenadas ni registradas en texto sin cifrar.
- Tokens de sesión
- El token en la cookie de sesión de su navegador es un valor aleatorio de 32 bytes configurado como cookie HttpOnly.
- Claves de API
- Se almacenan como hashes SHA-256. Solo se conserva un prefijo corto en texto claro, para que pueda reconocer una clave en una lista sin que el valor completo pueda recuperarse nunca más.
Lo que esta página no afirma
Sin protección contra DDoS, sin WAF, sin redundancia geográfica.
Hoy no estamos detrás de una red de distribución de contenido ni de un firewall de aplicaciones web, y no afirmamos cifrado a nivel de disco o de base de datos para cada byte que almacenamos. Un límite básico de solicitudes protege el inicio de sesión y otros endpoints costosos, pero todavía no es una capa de protección contra abusos robusta y persistente. Si un control específico es importante para la revisión de su propia organización, consúltenos directamente en lugar de suponer que una frase general lo cubre.
Preguntas
Respuestas directas sobre cifrado.
Más sobre el registro
Lea cómo se relacionan la conservación y la residencia de datos.
El cifrado es un control entre varios. Vea qué se purga, cuándo y dónde residen los datos mientras existen.