CompTIA SY0-701: Seguridad de Datos, Privacidad y Criptografía — Guía de estudio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.

Los datos son el objetivo final de la mayoría de los ataques, y la criptografía es el principal mecanismo técnico para protegerlos en tránsito, en reposo y en uso. Comprender las propiedades, limitaciones y la aplicación correcta de las primitivas criptográficas es fundamental, no solo para el examen, sino para diseñar sistemas que permanezcan seguros cuando los controles individuales fallan.

Clasificación y Manejo de Datos

La clasificación de datos asigna etiquetas de sensibilidad que determinan los requisitos de manejo. Los marcos gubernamentales utilizan Sin clasificar, Confidencial, Secreto y Alto secreto. Los marcos comerciales suelen utilizar Público, Interno, Confidencial y Restringido (o equivalentes). La clasificación debe ser impulsada por la sensibilidad de los datos y las obligaciones regulatorias, no por conveniencia.

Los sistemas de Prevención de Pérdida de Datos (DLP) aplican políticas de manejo inspeccionando el contenido en los endpoints, los puntos de egreso de la red y el almacenamiento en la nube. Una regla de DLP podría bloquear archivos adjuntos de correo electrónico que contengan cadenas de 16 dígitos que coincidan con patrones de tarjetas de crédito, o alertar cuando un usuario sube un archivo que contiene la frase “objetivo de adquisición” a un servicio personal de almacenamiento en la nube. La eficacia de DLP depende de una clasificación precisa: si los datos sensibles no están etiquetados, DLP no puede protegerlos.

La soberanía de los datos se refiere a dónde residen físicamente los datos y qué leyes de jurisdicción se aplican. El GDPR exige que los datos personales de la UE transferidos fuera de la UE estén protegidos por decisiones de adecuación, Cláusulas Contractuales Estándar o Normas Corporativas Vinculantes. Las organizaciones que operan a nivel mundial deben mapear los flujos de datos y asegurarse de que las ubicaciones de almacenamiento y procesamiento cumplan con las regulaciones aplicables.

Cifrado en Tránsito y en Reposo

TLS 1.3 es el estándar actual para cifrar datos en tránsito. Elimina las suites de cifrado débiles, exige forward secrecy (intercambio de claves efímero de Diffie-Hellman) y reduce el handshake a un solo viaje de ida y vuelta (round trip). TLS 1.0 y 1.1 están obsoletos; TLS 1.2 sigue siendo aceptable, pero debe configurarse con suites de cifrado fuertes. Una configuración de Nginx que impone los estándares actuales:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

El cifrado en reposo protege los datos en los medios de almacenamiento. El cifrado de disco completo (BitLocker, FileVault, LUKS) cifra todo el volumen; el cifrado a nivel de archivo (EFS, contenedores VeraCrypt) cifra archivos individuales. El cifrado a nivel de base de datos (Transparent Data Encryption en SQL Server y Oracle) cifra los archivos de datos y las copias de seguridad. El matiz crítico: el cifrado en reposo protege contra el robo de medios físicos, pero no protege contra una aplicación comprometida que ya ha descifrado los datos para procesarlos.

Primitivas Criptográficas

Los algoritmos simétricos (AES-128, AES-256, ChaCha20) utilizan una única clave compartida y son rápidos, adecuados para datos masivos. Los algoritmos asimétricos (RSA, ECDSA, Ed25519, ECDH) utilizan pares de claves y permiten el intercambio de claves, las firmas digitales y la vinculación de identidades, pero son computacionalmente costosos. Los sistemas híbridos, como TLS, utilizan la criptografía asimétrica para negociar una clave de sesión simétrica y luego cifran el tráfico masivo de forma simétrica.

El hashing (SHA-256, SHA-3) es una función unidireccional que produce un resumen (digest) de longitud fija. Los hashes no son cifrado: no se pueden revertir con una clave porque no hay clave. Los hashes de contraseñas con salt (usando bcrypt, scrypt, Argon2 o PBKDF2) añaden un valor aleatorio por usuario para frustrar los ataques de tablas arcoíris (rainbow tables). Los hashes proporcionan verificación de integridad; HMAC combina un hash con una clave secreta para proporcionar tanto integridad como autenticidad.

Los modos de cifrado importan tanto como el algoritmo. AES en modo ECB cifra cada bloque de forma independiente, produciendo un texto cifrado idéntico para bloques de texto plano idénticos, una propiedad catastrófica que filtra patrones de datos. AES-GCM (Galois/Counter Mode) proporciona tanto confidencialidad como integridad en una sola pasada y es el estándar para los protocolos modernos. El modo CBC con un padding adecuado y un HMAC es aceptable, pero más complejo de implementar correctamente.

Gestión y Almacenamiento de Claves

La criptografía es tan fuerte como lo sea su gestión de claves. Las claves deben generarse con entropía fuerte, almacenarse por separado de los datos que protegen, rotarse según un cronograma y destruirse al ser retiradas. Los Módulos de Seguridad de Hardware (HSM) proporcionan almacenamiento de claves resistente a la manipulación y aceleración criptográfica. Un Módulo de Plataforma de Confianza (TPM) es un chip en los endpoints que almacena las claves utilizadas por BitLocker y el arranque medido (measured boot). El key escrow coloca una copia de las claves con un tercero de confianza para su recuperación legal, mientras que los agentes de recuperación de claves permiten a las empresas descifrar los datos de los empleados cuando es necesario. Los servicios de KMS en la nube (AWS KMS, Azure Key Vault, Google Cloud KMS) ofrecen cifrado de sobre (envelope encryption), donde una clave de cifrado de datos (DEK) protege los datos y, a su vez, es cifrada por una clave de cifrado de claves (KEK) mantenida en el HSM.

Infraestructura de Clave Pública

La PKI (Infraestructura de Clave Pública) vincula identidades a claves públicas a través de certificados emitidos por una Autoridad de Certificación (CA). Una CA subordinada se encadena a una CA raíz cuyo certificado debe ser previamente confiable. El ciclo de vida del certificado comienza con una Solicitud de Firma de Certificado (CSR) generada junto con una clave privada:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

La CA valida al solicitante, firma la CSR y emite un certificado X.509. La revocación se publica a través de Listas de Revocación de Certificados (CRL) —listas de números de serie revocados que se descargan periódicamente— o el Protocolo de Estado de Certificados en Línea (OCSP), con servidores de respuesta (responders) que contestan consultas por certificado en tiempo real. El OCSP stapling permite que el servidor presente un estado reciente y firmado durante el handshake de TLS, evitando las búsquedas del cliente a la CA. Los certificados caducan y deben renovarse; la automatización a través de ACME (Let’s Encrypt, servidores ACME internos) previene interrupciones de servicio por certificados vencidos.

Firma de código y validación de integridad

La firma de código utiliza la clave privada de un desarrollador para firmar un artefacto de software; los destinatarios verifican la firma con el certificado del desarrollador, confirmando tanto la integridad como el origen. Esto protege contra la manipulación en la cadena de suministro. Las herramientas de monitoreo de integridad de archivos (Tripwire, AIDE) y la publicación de hashes (valores sha256sum junto a las descargas) detectan de manera similar modificaciones no autorizadas, pero el hashing por sí solo solo prueba que el archivo coincide con un valor; no autentica quién produjo ese valor. Solo una firma digital, respaldada por una PKI, proporciona tanto integridad como no repudio.

Retención, sanitización y eliminación segura

Las políticas de retención definen cuánto tiempo debe conservarse cada clase de datos y cuándo debe eliminarse. Las regulaciones a menudo exigen tanto mínimos (registros financieros durante siete años) como máximos (datos personales retenidos no más tiempo del necesario). Las copias de seguridad no están exentas: si un sujeto ejerce su derecho al olvido, la organización debe tener un proceso defendible para eliminar esos datos de las copias de seguridad o documentar las limitaciones técnicas y los controles compensatorios. Las retenciones legales anulan la retención normal y congelan los datos durante un litigio.

Cuando los medios llegan al final de su vida útil, la sanitización debe coincidir con la sensibilidad de los datos y el destino del medio. NIST SP 800-88 define tres niveles: Clear (sobrescritura lógica, suficiente para la reutilización dentro de la organización), Purge (borrado criptográfico, borrado de bloques o desmagnetización, suficiente para la reutilización externa) y Destroy (trituración, desintegración, incineración, pulverización). El borrado criptográfico —destruir la clave de cifrado para que el texto cifrado se vuelva irrecuperable— es rápido y efectivo para las unidades autocifrantes que se están reutilizando. La desmagnetización deja inutilizables los medios magnéticos y no funciona en las unidades SSD. La destrucción física es el único método garantizado para medios dañados o para las clasificaciones más altas.

Escenario práctico: Falla en la gestión de claves que conduce a una brecha de seguridad

Una empresa de SaaS cifró su base de datos de clientes usando AES-256, pero almacenó la clave de cifrado en un archivo de configuración en texto plano en el mismo repositorio que el código de la aplicación. Cuando un desarrollador subió accidentalmente el repositorio a una cuenta pública de GitHub, un bot automatizado de escaneo de credenciales descubrió la clave en 11 minutos. El atacante usó la clave para descifrar una copia de seguridad de la base de datos que había sido almacenada en un bucket de S3 de acceso público (otra configuración errónea). El cifrado era técnicamente correcto —AES-256 es inquebrantable por fuerza bruta— pero la gestión de claves era catastróficamente deficiente. Una gestión de claves adecuada habría almacenado la clave en un gestor de secretos (AWS Secrets Manager, HashiCorp Vault) con el acceso controlado por roles de IAM, nunca en el código fuente o en archivos de configuración.

← Seguridad de Cloud · Todos los dominios · Continuidad del Negocio y Recuperación ante Desastres →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →