Política de Contraseñas y MFA
Política operativa interna. Define los requisitos de autenticación para todas las cuentas corporativas de Lawra, S.R.L., incluyendo contraseñas, autenticación multi-factor (MFA), gestores de contraseñas, SSO y cuentas de servicio. Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Propósito y Alcance
1.1. Esta política reduce el riesgo de acceso no autorizado a los sistemas de Lawra mediante el establecimiento de estándares rigurosos de autenticación, alineados con la guía de identidad digital del NIST SP 800-63B (Digital Identity Guidelines — Authentication and Lifecycle Management).
1.2. Soporta el control SOC 2 CC6.1 (Logical and Physical Access Controls — Identification and Authentication).
1.3. — Aplica a:
- Todos los socios, empleados, contratistas y asesores con acceso a sistemas de Lawra.
- Todas las cuentas corporativas: Google Workspace, Firebase Console, GitHub, Google Cloud Platform, gestores de contraseñas, herramientas de comunicación, y cualquier SaaS con acceso a datos confidenciales.
- Cuentas de servicio y credenciales de automatización (CI/CD, APIs internas, scripts).
1.4. — Principio fundamental: La identidad verificada es la primera línea de defensa. Una contraseña comprometida con MFA es exponencialmente más segura que una contraseña fuerte sin MFA. MFA prevalece sobre la longitud de contraseña como control prioritario.
2. Requisitos de Contraseñas
2.1. — Longitud mínima:
| Tipo de cuenta | Longitud mínima | Formato recomendado |
|---|---|---|
| Cuentas de usuario (corporativas) | 14 caracteres | Contraseña compleja o frase de contraseña |
| Cuentas administrativas (Firebase, GCP, GitHub Admin) | 20 caracteres | Frase de contraseña aleatoria de ≥5 palabras o contraseña generada por gestor |
| Cuentas de servicio / API keys (si aplica contraseña) | 32 caracteres | Generada aleatoriamente por gestor |
2.2. — Formato de contraseñas:
Lawra acepta dos formatos equivalentes (alineado con NIST SP 800-63B, que desaconseja reglas de complejidad arbitrarias que llevan a contraseñas débiles):
Opción A — Contraseña compleja:
- Mínimo 14 caracteres.
- Combinación de letras mayúsculas, minúsculas, números y símbolos.
- Generada por un gestor de contraseñas aprobado (ver sección 4).
Opción B — Frase de contraseña (passphrase):
- Mínimo 4 palabras aleatorias no relacionadas (método Diceware o equivalente).
- Ejemplo conceptual (no usar este ejemplo):
cebolla-mástil-terciopelo-4321. - Longitud resultante típicamente ≥20 caracteres.
- Más fácil de recordar, igualmente segura matemáticamente.
2.3. — Prohibiciones:
- Usar el nombre de usuario como contraseña o parte de ella.
- Usar el nombre de la empresa (
Lawra,lawra, variantes). - Usar fechas de nacimiento, nombres de mascotas, lugares, o información personal.
- Reutilizar contraseñas entre servicios diferentes.
- Contraseñas que aparezcan en listas de contraseñas comprometidas conocidas (los gestores de contraseñas modernos verifican esto automáticamente contra bases de datos como HaveIBeenPwned).
- Compartir contraseñas con compañeros (cada cuenta debe ser individual).
3. Política de Rotación de Contraseñas
3.1. — Alineación con NIST SP 800-63B: Lawra sigue el criterio del NIST que desaconseja la rotación periódica obligatoria de contraseñas cuando no hay evidencia de compromiso. Los cambios forzados frecuentes llevan a contraseñas más débiles y predecibles (p.ej., Lawra2024! → Lawra2025!).
3.2. — Rotación obligatoria en los siguientes casos:
| Evento | Acción requerida | Plazo |
|---|---|---|
| Sospecha o confirmación de compromiso de la cuenta | Cambiar contraseña + revocar sesiones activas | Inmediato |
| Desvinculación de un empleado / contratista | Cambiar todas las contraseñas compartidas que conocía el saliente | Dentro de las 24 horas |
| Detección de la contraseña en una lista de breach (alerta del gestor) | Cambiar contraseña | 48 horas |
| Acceso a un sistema desde un dispositivo no gestionado o potencialmente comprometido | Cambiar contraseña de las cuentas accedidas | 24 horas |
| Pentest o auditoría revela contraseña débil o comprometida | Cambiar contraseña | 48 horas |
3.3. — Revisión anual de cuentas de servicio: Las credenciales de cuentas de servicio y tokens de larga duración se revisan y rotan anualmente, independientemente de si hay evidencia de compromiso.
4. Gestor de Contraseñas (Obligatorio)
4.1. El uso de un gestor de contraseñas aprobado es obligatorio para todos los miembros del equipo con acceso a sistemas corporativos. No se permite gestionar contraseñas de cuentas corporativas en notas físicas, notas de escritorio, o en la memoria del navegador de forma no cifrada.
4.2. — Gestores aprobados:
| Gestor | Plan | Uso |
|---|---|---|
| 1Password Teams | Business / Teams | Preferido para Lawra; permite compartir secretos entre equipo de forma auditada |
| Bitwarden for Business | Business / Enterprise | Alternativa open-source igualmente válida |
4.3. — Configuración mínima del gestor corporativo:
- Contraseña maestra del gestor: mínimo 20 caracteres o frase de contraseña de ≥5 palabras.
- MFA activado en el gestor de contraseñas (obligatorio — ver sección 5).
- Todas las cuentas corporativas (no personales) deben estar en la vault corporativa, no en vaults personales individuales.
- El gestor debe tener activada la verificación de brechas contra bases de datos de contraseñas comprometidas.
4.4. — Compartición de credenciales: Si es técnicamente inevitable compartir una credencial (ej. cuenta de facturación compartida sin SSO), se usa la funcionalidad de compartición segura del gestor corporativo, nunca envío por correo, chat, o texto plano. Se documenta quién tiene acceso y se revoca al desvincularse cualquier miembro con acceso.
5. Autenticación Multi-Factor (MFA)
5.1. — MFA obligatorio en todas las cuentas corporativas. Sin excepción. Esto incluye:
- Google Workspace (Gmail corporativo, Drive, Calendar).
- Firebase Console.
- Google Cloud Platform.
- GitHub (organización Lawra).
- Gestor de contraseñas corporativo (1Password / Bitwarden).
- Cualquier herramienta SaaS con acceso a datos de clientes o financieros.
5.2. — Jerarquía de métodos de MFA (de más a menos seguro):
| Nivel | Método | Aprobado para | Notas |
|---|---|---|---|
| 1 (Más seguro) | Hardware security keys (YubiKey, Google Titan Key) | Cuentas de máximo privilegio (Owner, Admin) | Resistente a phishing. Obligatorio para Owner/Admin en cuanto sea operativamente viable. |
| 2 | Passkeys (FIDO2 en plataforma) | Todas las cuentas | Resistente a phishing. Preferido cuando el proveedor lo soporta. |
| 3 | TOTP via app de autenticación (Google Authenticator, Authy, 1Password, Bitwarden) | Todas las cuentas | Aceptable como método primario para la mayoría de roles. |
| 4 (Menos seguro) | SMS / llamada telefónica | Último recurso — solo si el sistema no soporta métodos superiores | Vulnerable a SIM swapping. Prohibido para cuentas Admin. No se usa como método principal. |
5.3. — Cuentas administrativas: Las cuentas con privilegios administrativos (Firebase Console Owner, GitHub Org Admin, GCP Owner/Editor) deben usar métodos de nivel 1 o 2 cuando sea técnicamente posible. El uso de SMS para cuentas administrativas está prohibido.
5.4. — Códigos de recuperación (backup codes): Los códigos de recuperación de MFA se almacenan en la vault corporativa del gestor de contraseñas, bajo acceso del CTO y el Gerente. No se almacenan en texto plano, en correo electrónico, ni en papel sin custodia segura.
5.5. — Pérdida de dispositivo MFA: En caso de pérdida del dispositivo autenticador:
- Notificar al CTO inmediatamente.
- Acceder a la cuenta usando los códigos de recuperación almacenados en la vault corporativa.
- Revocar el dispositivo perdido como factor de autenticación.
- Configurar el nuevo dispositivo como factor MFA.
- Generar nuevos códigos de recuperación y actualizar la vault corporativa.
6. Single Sign-On (SSO) via Google Workspace
6.1. Lawra utiliza Google Workspace SSO como proveedor de identidad para los servicios que lo soporten. Los miembros del equipo se autentican en servicios externos con su cuenta @lawra.com en lugar de crear cuentas adicionales.
6.2. El MFA de Google Workspace (activado bajo la política anterior) se hereda por los servicios integrados via SSO.
6.3. — Servicios preferidos con SSO de Google:
- GitHub (vincular cuenta personal con Google Workspace SSO en la organización Lawra donde sea posible).
- Firebase Console (usa Google Workspace natively).
- Google Cloud Platform (usa Google Workspace natively).
- Notion, Linear, u otras herramientas internas que soporten OAuth/OIDC con Google.
6.4. La provisión y desprovisión de acceso via SSO está regulada en access-control-policy.
7. Bloqueo de Cuentas y Detección de Anomalías
7.1. — Bloqueo automático tras intentos fallidos:
- Google Workspace: aplica sus propias políticas de detección de fuerza bruta y bloqueo temporal.
- Firebase Auth: aplica rate limiting nativo.
- GitHub: aplica sus propias políticas.
- Lawra configura las políticas de seguridad en Google Workspace Admin Console para maximizar la protección: notificación de inicio de sesión sospechoso, bloqueo de acceso desde países de alto riesgo (cuando aplique), y alertas de acceso no habitual.
7.2. — Alertas de Google Workspace: El CTO recibe notificaciones de:
- Inicios de sesión desde nuevos dispositivos o ubicaciones inusuales.
- Intentos de inicio de sesión fallidos repetidos.
- Cambios en la configuración de MFA de cuentas críticas.
8. Credenciales de Cuentas de Servicio y Automatización
8.1. — Tipos de credenciales de servicio en Lawra:
| Tipo | Descripción | Requisitos |
|---|---|---|
| GitHub Actions Secrets | Tokens y API keys usados en workflows CI/CD | Almacenados como GitHub Encrypted Secrets; rotación semestral |
| Firebase service account keys | Acceso programático a Firebase Admin SDK | Rotación anual; acceso restringido a procesos que los necesitan |
| Google Cloud service account keys | Identidades de servicio para procesos automatizados | Preferir Workload Identity Federation en lugar de llaves descargadas; rotación anual si se usan llaves |
| API keys de Gemini / Google AI | Acceso a LLM desde el cliente | Restricción por HTTP referrer y por API habilitadas en GCP Console; rotación anual |
8.2. — Sin contraseñas en código: Ninguna credencial de cuenta de servicio puede existir en el código fuente del repositorio. Ver secure-sdlc-policy para el proceso de gestión de secretos en desarrollo.
8.3. — Inventario de cuentas de servicio: El CTO mantiene un inventario actualizado de todas las cuentas de servicio activas, sus permisos, y sus propietarios. Se revisa trimestralmente. Las cuentas de servicio sin uso activo se desactivan.
8.4. — Principio de mínimo privilegio para cuentas de servicio: Cada cuenta de servicio recibe solo los permisos estrictamente necesarios para su función (p.ej., la cuenta de backup de Firestore solo tiene acceso de lectura a Firestore y escritura al bucket de GCS de backups, no a toda la organización de GCP).
9. Formación y Concienciación
9.1. — Onboarding: Todo nuevo miembro del equipo recibe en su primera semana:
- Configuración obligatoria de la cuenta corporativa en el gestor de contraseñas aprobado.
- Activación de MFA en Google Workspace y demás herramientas corporativas.
- Lectura y firma de esta política.
- Sesión breve con el CTO sobre el setup de seguridad de autenticación de Lawra.
9.2. — Phishing simulation: Lawra ejecuta simulaciones de phishing trimestrales para evaluar la resiliencia del equipo. Los miembros que caen en la simulación reciben formación adicional inmediata, no sanción.
9.3. — Refresher anual: Revisión anual del estado de seguridad de autenticación del equipo, incluyendo verificación de MFA activo y gestor de contraseñas en uso.
10. Sanciones
El incumplimiento de esta política puede dar lugar a:
- Amonestación escrita para incumplimientos de primer nivel (ej. no usar gestor de contraseñas).
- Suspensión temporal de acceso hasta regularización.
- Terminación con justa causa para incumplimientos graves o reiterados (ej. compartir contraseñas de cuentas admin con externos, desactivar MFA sin autorización).
- Acciones civiles o penales bajo Ley 53-07 si el incumplimiento facilita un acceso no autorizado.
11. Referencias Normativas y Técnicas
- SOC 2 Trust Services Criteria: CC6.1 (Logical Access Controls — Identification and Authentication)
- NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
- NIST SP 800-63C — Federation and Assertions
- ISO/IEC 27001:2022 — Anexo A, Control 8.5 (Secure Authentication)
- Ley No. 53-07 (R.D.) — Crímenes y Delitos de Alta Tecnología (acceso no autorizado a sistemas)
- Ley No. 172-13 (R.D.) — Protección de Datos Personales (medidas de seguridad de autenticación)
access-control-policy— Política de Control de Acceso de Lawraencryption-policy— Política de Cifrado de Lawrainfosec-policy— Política de Seguridad de la Información de Lawra
12. Revisión y Modificación
Esta política se revisa anualmente o ante cambios en los estándares de autenticación (nuevas guías NIST, deprecación de métodos MFA) o ante incidentes de seguridad relacionados con credenciales. 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...