Política de Cifrado
Política operativa interna. Define los estándares criptográficos y las prácticas de gestión de llaves que aplican a todos los datos y comunicaciones de Lawra, S.R.L. Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Propósito y Alcance
1.1. Esta política establece los estándares mínimos de cifrado para proteger la confidencialidad e integridad de los datos de Lawra y de sus clientes, tanto en tránsito como en reposo, y define los requisitos de gestión de llaves criptográficas.
1.2. Soporta los controles SOC 2:
- CC6.1 — Logical Access Controls (cifrado como control de acceso lógico complementario)
- CC6.7 — Transmission and Movement of Information (cifrado de datos en tránsito)
- C1.1 — Confidential Information (protección de información confidencial mediante cifrado)
1.3. — Aplica a:
- Datos almacenados en Firestore (base de datos de producción).
- Datos en tránsito entre el cliente web y los servidores.
- Datos en tránsito entre Lawra y proveedores de IA (Gemini / Google AI).
- Endpoints (laptops y dispositivos del personal).
- Correo electrónico corporativo para comunicaciones sensibles.
- Llaves criptográficas y secretos en uso por la organización.
2. Algoritmos y Protocolos Aprobados
2.1. Solo se permiten los siguientes algoritmos y protocolos criptográficos. El uso de algoritmos no listados requiere aprobación previa del CTO.
2.1.1. Cifrado simétrico
| Algoritmo | Longitud de llave | Uso aprobado | Estado |
|---|---|---|---|
| AES-256-GCM | 256 bits | Cifrado de datos en reposo, cifrado de archivos | Preferido |
| AES-256-CBC | 256 bits | Cifrado de datos en reposo (legacy, con IV aleatorio) | Aceptable |
| ChaCha20-Poly1305 | 256 bits | Alternativa moderna a AES donde el hardware no soporta AES-NI | Aceptable |
Prohibidos: DES, 3DES (Triple-DES), RC4, Blowfish con keys < 128 bits, AES-128 para datos confidenciales o restringidos.
2.1.2. Cifrado asimétrico y firma digital
| Algoritmo | Longitud de llave / curva | Uso aprobado | Estado |
|---|---|---|---|
| RSA-2048 | 2048 bits mínimo | Cifrado de llaves, firmas digitales (legacy) | Aceptable |
| RSA-4096 | 4096 bits | Certificados raíz, llaves de larga vida | Preferido donde aplique RSA |
| Ed25519 / X25519 | Curva 25519 | Firmas digitales, intercambio de llaves (SSH, signing) | Preferido |
| ECDSA P-256 | secp256r1 | Firmas TLS, certificados | Aceptable |
| ECDH P-256 | secp256r1 | Intercambio de llaves TLS | Aceptable |
Prohibidos: RSA < 2048 bits, DSA (cualquier longitud), claves EC en curvas NIST < P-256.
2.1.3. Protocolos de transporte
| Protocolo | Versión mínima | Uso | Estado |
|---|---|---|---|
| TLS | 1.3 | Toda comunicación HTTPS y API | Preferido |
| TLS | 1.2 | Comunicaciones con servicios legacy que no soporten TLS 1.3 | Aceptable (con suites seguras) |
Prohibidos: TLS 1.0, TLS 1.1, SSL 2.0, SSL 3.0. HTTP plano (sin TLS) está prohibido para cualquier dato confidencial o autenticado.
2.1.4. Funciones de hash
| Función | Uso aprobado | Estado |
|---|---|---|
| SHA-256 | Hash de integridad, derivación de llaves, deduplicación (ej. newsletter) | Aceptable |
| SHA-384 / SHA-512 | Hash de integridad para datos de alta criticidad | Preferido |
| BLAKE3 | Hash de alta velocidad para integridad | Aceptable |
| bcrypt / Argon2id | Hash de contraseñas | Obligatorio para passwords almacenados |
Prohibidos para seguridad: MD5, SHA-1 (uso estrictamente no criptográfico como checksums de integridad de archivos no sensibles únicamente, con aprobación del CTO).
2.1.5. Suites TLS 1.2 aceptables (cuando TLS 1.3 no esté disponible)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Prohibidas: Suites con RC4, 3DES, DHE con DH < 2048 bits, o EXPORT ciphers.
3. Cifrado de Datos en Reposo
3.1. — Firestore (base de datos de producción): Firestore cifra todos los datos en reposo de forma predeterminada mediante AES-256 con llaves gestionadas por Google. Esta protección está activa sin configuración adicional de Lawra. Para clientes con requerimientos de mayor control, Lawra puede evaluar Customer-Managed Encryption Keys (CMEK) en Google Cloud KMS.
3.2. — Google Cloud Storage (backups):
Los buckets de GCS cifran datos en reposo con AES-256 de forma predeterminada. Ver backup-recovery-policy para la configuración de buckets de backup.
3.3. — Google Drive (documentación corporativa): Google Workspace cifra todos los datos en reposo con AES-256 por defecto. Los documentos de alta sensibilidad (contratos con datos de clientes, evidencia de auditoría) se almacenan en unidades compartidas con acceso restringido.
3.4. — Endpoints del personal: Ver sección 6. El cifrado de disco completo es obligatorio en todos los equipos del personal.
3.5. — Secretos y llaves:
Los secretos en uso activo (API keys, tokens de servicio) se almacenan en gestores de secretos aprobados (ver password-mfa-policy y sección 4 de esta política), nunca en texto plano en archivos de configuración o código fuente.
4. Gestión de Llaves Criptográficas
4.1. — Principios de gestión de llaves:
- Separación de funciones: La persona que crea una llave no es la misma que la aprueba para uso en producción (cuando el tamaño del equipo lo permita).
- Escrow: Las llaves de cifrado críticas (llaves maestras de KMS, llaves de firma de documentos) deben tener un mecanismo de escrow documentado que permita su recuperación si el custodio principal está incapacitado.
- Principio de mínimo privilegio: Solo los procesos y personas que necesitan una llave tienen acceso a ella.
- No compartición: Las llaves criptográficas no se comparten entre sistemas o entre individuos salvo que sea técnicamente inevitable y esté documentado.
4.2. — Google Cloud KMS: Lawra usa Google Cloud KMS para gestionar las llaves de cifrado de datos en los servicios de Google Cloud. El acceso a KMS está restringido a la cuenta de servicio del CTO y a las cuentas de servicio de los procesos autorizados.
4.3. — Rotación de llaves:
| Tipo de llave | Frecuencia de rotación | Rotación automática |
|---|---|---|
| Llaves de cifrado de datos (KMS) | Anual | Sí (Cloud KMS auto-rotation) |
| API keys de servicios externos (Gemini, etc.) | Anual o ante sospecha de compromiso | No (manual) |
| Tokens de acceso personal (GitHub, GCP) | Semestral | No (manual) |
| Certificados TLS | Según expiración (máx. 90 días con Let’s Encrypt) | Sí (auto-renovación) |
| Contraseñas de cuentas de servicio | Trimestral o ante compromiso | No (manual) |
| Llaves SSH de equipo | Anual | No (manual) |
4.4. — Proceso de rotación de llaves comprometidas: Al detectar o sospechar el compromiso de una llave criptográfica:
- Revocar o desactivar la llave comprometida inmediatamente.
- Generar una nueva llave siguiendo los estándares de esta política.
- Actualizar todos los sistemas que usan la llave afectada.
- Verificar que la llave comprometida no puede ser usada.
- Evaluar el impacto: ¿Fueron descifrados datos? ¿Se accedió a sistemas? Activar
incident-response-plansi hay evidencia de uso indebido. - Documentar el incidente en el registro de gestión de llaves.
4.5. — Destrucción de llaves: Al retirar una llave (por rotación o fin de vida útil), la llave se destruye de forma segura: eliminación en KMS + borrado seguro de cualquier copia física o en archivo. Se documenta la fecha de destrucción en el registro de llaves.
5. Cifrado en Tránsito
5.1. — HTTPS obligatorio: El sitio web de Lawra (lawra.io y subdominios) opera exclusivamente sobre HTTPS. No se aceptan conexiones HTTP planas; los servidores deben configurar redirección 301 de HTTP a HTTPS.
5.2. — HSTS: El header Strict-Transport-Security debe estar configurado con max-age mínimo de 1 año (max-age=31536000; includeSubDomains).
5.3. — Conexiones a APIs externas: Las llamadas a Gemini AI, Firebase, y cualquier API externa se realizan exclusivamente sobre HTTPS con TLS 1.2+ (TLS 1.3 preferido). Las SDKs de Google implementan esto por defecto; se prohíbe desactivar la validación de certificados TLS en ningún cliente HTTP de la aplicación.
5.4. — Sin HTTP en ningún canal de datos sensibles: Ningún dato confidencial, dato personal de usuarios, ni credencial puede enviarse sobre HTTP plano. Cualquier componente que procese datos de usuario debe operar exclusivamente sobre HTTPS.
5.5. — Comunicaciones internas de equipo: Las herramientas de comunicación del equipo (Google Workspace, Slack, etc.) usan TLS en tránsito por defecto como parte de la configuración del proveedor. Lawra no usa herramientas de comunicación interna que transmitan en texto plano.
6. Cifrado de Endpoints
6.1. — Cifrado de disco completo obligatorio: Todos los equipos del personal con acceso a sistemas o datos de Lawra deben tener el cifrado de disco completo activado:
| Sistema operativo | Solución requerida |
|---|---|
| macOS | FileVault 2 activado (AES-XTS 128-bit) |
| Windows | BitLocker activado (AES-256) con TPM + PIN |
| Linux | LUKS (Linux Unified Key Setup) con AES-256 |
6.2. — Verificación: El CTO verifica anualmente que todos los equipos del personal tienen el cifrado de disco activado. Los equipos nuevos deben tener el cifrado activado antes de recibir acceso a sistemas de producción.
6.3. — Móviles: Los dispositivos móviles corporativos (si aplica) deben tener el cifrado de almacenamiento activado (iOS y Android modernos activan esto por defecto al establecer un PIN/contraseña).
7. Cifrado de Correo Electrónico
7.1. Google Workspace implementa TLS en tránsito para el correo entre servidores compatibles (STARTTLS / TLS obligatorio). Esto protege el correo en tránsito entre Google y otros proveedores que soporten TLS.
7.2. — Comunicaciones de alta sensibilidad: Para el envío de documentos con datos personales de clientes, contratos no firmados, o información financiera confidencial a partes externas:
- Preferir el uso de Google Drive con enlace compartido restringido en lugar de adjuntos de correo.
- Si se usa correo, proteger el adjunto con contraseña compartida por un canal separado.
- Evaluar la implementación de S/MIME en Google Workspace para firmas digitales y cifrado end-to-end en comunicaciones legales críticas (recomendado cuando el equipo alcance un tamaño operativo mayor).
7.3. No se envían datos personales de clientes en texto plano por correo electrónico sin cifrado de transporte.
8. Cifrado y LLM
8.1. Los prompts enviados a Gemini AI y las respuestas recibidas viajan sobre TLS (implementado por el SDK de Google). Los datos del usuario incluidos en prompts son tratados como datos confidenciales sujetos a esta política.
8.2. Los prompts del sistema (system prompts) de los asistentes de Lawra son activos confidenciales. No se almacenan en texto plano en lugares accesibles públicamente; están en el código fuente del repositorio privado.
8.3. Las conversaciones de usuarios registrados almacenadas en Firestore están protegidas por el cifrado en reposo de Firestore (AES-256) y por las reglas de seguridad de Firestore que limitan el acceso al propietario de la conversación.
9. Referencias Normativas y Técnicas
- SOC 2 Trust Services Criteria: CC6.1 (Logical Access Controls), CC6.7 (Transmission and Movement of Information), C1.1 (Confidential Information)
- NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management
- NIST SP 800-175B Rev. 1 — Guideline for Using Cryptographic Standards in the Federal Government
- FIPS 140-3 — Security Requirements for Cryptographic Modules
- ISO/IEC 27001:2022 — Anexo A, Controles 8.24 (Use of Cryptography), 8.25 (Secure Development)
- Ley No. 172-13 (R.D.) — Protección de Datos Personales (medidas de seguridad técnicas)
- GDPR Art. 32 — Cifrado como medida técnica de seguridad apropiada
backup-recovery-policy— Política de Respaldo y Recuperación de Lawraaccess-control-policy— Política de Control de Acceso de Lawrapassword-mfa-policy— Política de Contraseñas y MFA de Lawra
10. Revisión y Modificación
Esta política se revisa anualmente o cuando surjan nuevas vulnerabilidades criptográficas relevantes (p.ej., deprecación de un algoritmo por NIST), cambios en los estándares de la industria, o cambios materiales en la infraestructura. Modificaciones requieren aprobación del CTO; modificaciones materiales requieren aprobación de la Asamblea.
Próxima revisión: [fecha de adopción + 12 meses].
Adoptada por la Asamblea General de Socios de LAWRA, S.R.L. en fecha [__], conforme consta en el Libro de Actas.
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...