> ## Knowledge Base Index > Fetch the complete knowledge base index at: https://help.danaconnect.com/sitemap.xml > Use this file to discover available pages before exploring further. > Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash). # ¿Cómo DANAconnect garantiza que los datos de sus clientes están protegidos cuando están en tránsito? DANAconnect garantiza que los datos del cliente final viajen **totalmente cifrados y protegidos** desde el navegador o dispositivo del usuario hasta nuestra plataforma, y entre nuestros propios servicios internos. Esta protección se basa en **TLS 1.2 o superior** y se refuerza con **tokenización**, **ofuscamiento** y **enmascaramiento dinámico**. Las claves criptográficas se gestionan de forma centralizada con **AWS Key Management Service (KMS)** usando algoritmos robustos (p. ej., **AES‑256**). ## 1) Cifrado en tránsito (TLS) **Qué es:** El cifrado en tránsito evita que terceros puedan leer o alterar la información mientras se transmite por redes públicas o privadas. **Cómo lo aplicamos:** * **Protocolos:** Requerimos **Transport Layer Security (TLS) v1.2 o superior** en todos los endpoints expuestos. * **Ámbitos cubiertos:** * **Canales de administración** (portales internos/administrativos) * **Interfaces de usuario** (aplicaciones web de cara al cliente/operador) * **APIs REST** (integraciones con sistemas de clientes y terceros) * **Conexiones entre servicios internos** (microservicios y data pipelines) * **Buenas prácticas criptográficas:** se priorizan suites modernas (p. ej., AES en modos GCM) y se deshabilitan protocolos obsoletos (SSL, TLS 1.0/1.1). * **Validaciones periódicas:** realizamos **evaluaciones trimestrales** de endpoints TLS (ej.: SSL Labs) y exigimos calificaciones **A o superiores**. ## 2) Capas adicionales de protección de datos Además de TLS, aplicamos controles para reducir exposición y riesgo en flujos y vistas de datos: * **Tokenización** Reemplaza valores sensibles (p. ej., un número de documento) por **identificadores alternativos irreversibles**. El dato real no se expone ni viaja completo; solo el token representativo. * **Ofuscamiento de datos** Transforma los datos (formato/carácter) para impedir su identificación directa, útil en **registros**, **trazas** o **datasets de prueba**. * **Enmascaramiento dinámico** Oculta porciones del dato (ej.: mostrar `****‑****‑1234`) **según el rol/perfil** del usuario. De este modo se minimiza el acceso a información completa cuando no es necesario. Estas capas se aplican de forma **complementaria** al cifrado de transporte: si alguien interceptara el canal, **aun así** vería tokens, datos ofuscados o enmascarados según corresponda. ## 3) Gestión de claves y cripto con AWS KMS Para asegurar que el cifrado sea consistente y auditable, utilizamos **AWS Key Management Service (KMS)**: * **Algoritmos:** claves simétricas fuertes como **AES‑256**. * **Custodia y alcance:** las claves maestras se protegen en KMS; el acceso se gobierna mediante **identidades autenticadas** y políticas de menor privilegio. * **Auditoría:** el uso de claves y las operaciones criptográficas quedan **trazadas** (logs) para fines de cumplimiento y revisiones de seguridad. * **Rotación y ciclo de vida:** las claves siguen políticas de **rotación** y de **gestión del ciclo de vida**. || **Importante:** Aunque este artículo se centra en **cifrado en tránsito**, DANAconnect también cifra **en reposo** (archivos, bases de datos, snapshots), utilizando KMS y AES‑256 (ver política para detalles). ## 4) Alcance dentro de DANAconnect (de extremo a extremo) * **Desde el cliente final** (navegador, app móvil, sistemas del cliente) hasta **nuestros endpoints**: siempre por **HTTPS/TLS**. * **Dentro de la plataforma**: comunicación **servicio‑a‑servicio** cifrada; controles de identidad y autorización en cada salto. * **Exposición de datos**: tokenización/ofuscamiento/enmascaramiento reducen la exposición incluso en canales ya cifrados. ## 5) Preguntas frecuentes (FAQ) **¿Aceptan TLS 1.2 y 1.3?** Sí. **TLS 1.2 o superior** es obligatorio. Cuando está disponible, se negocian versiones y suites modernas de forma automática. **¿Pueden habilitar mTLS (mutual TLS) para integraciones?** Sí, en escenarios Enterprise y bajo evaluación de arquitectura, podemos **mTLS** para reforzar la autenticación de clientes de API. **¿Cómo aseguran que no haya configuraciones débiles?** Mediante **escaneos trimestrales**, lineamientos criptográficos y deshabilitación de protocolos y cifrados obsoletos. **¿El correo electrónico viaja cifrado?** Los mensajes **no** se cifran de extremo a extremo de forma nativa, pero su **transporte** se realiza sobre **TLS** cuando el servidor receptor lo soporta. Además, firmamos mensajes con **DKIM** del dominio correspondiente. **¿Qué diferencia hay entre cifrado, tokenización y enmascaramiento?** * **Cifrado:** protege el dato transformándolo con una clave; el receptor autorizado lo descifra. * **Tokenización:** reemplaza el dato por un **token**; el valor original no viaja ni se almacena allí donde no corresponde. * **Enmascaramiento:** oculta parcialmente el dato en **pantallas, reportes o logs** según permisos. **¿Cómo se gestionan las claves de cifrado?** Con **AWS KMS**, políticas de acceso de **menor privilegio**, rotación y **auditoría** centralizada del uso de claves. **¿Cumplen con cifrado en reposo además de en tránsito?** Sí. S3/EBS/bases de datos y respaldos se cifran (p. ej., **AES‑256** con KMS). ## 6) Resumen para auditorías, personal de seguridad, compras y RFPs * **Transporte:** TLS **v1.2+** obligatorio (preferencia por TLS 1.3); suites modernas (AES‑GCM). * **Cobertura:** **Admin UI**, **Frontends**, **APIs REST** y **servicio‑a‑servicio interno**. * **Controles extra:** **Tokenización**, **ofuscamiento** y **enmascaramiento dinámico** por rol. * **Gestión de claves:** **AWS KMS**, **AES‑256**, rotación y **auditoría**. * **Revisión continua:** **escaneos trimestrales** de endpoints TLS, objetivo **A o superior**. * **Correo:** transporte sobre **TLS** y firma **DKIM**. * Consulte 010-POL para el detalle por componente.