Política de Control de Acceso
Política operativa que rige quién puede acceder a qué y cómo. Implementa el principio de mínimo privilegio (Least Privilege) y necesidad de conocer (Need-to-Know). Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Alcance
Esta política aplica a:
- Acceso a sistemas de Lawra (Firebase Console, GitHub, Google Workspace, AI provider consoles, AWS / GCP, etc.);
- Acceso a información confidencial o restringida;
- Acceso físico a oficinas y áreas restringidas (cuando aplique);
- Acceso a datos de clientes procesados como Encargado.
2. Principios
2.1. — Mínimo privilegio: cada usuario recibe solo los accesos estrictamente necesarios para su función. 2.2. — Necesidad de saber: acceso a información se otorga por necesidad operativa, no por jerarquía o curiosidad. 2.3. — Separación de funciones: funciones críticas (provisión de accesos vs. auditoría; deploy a producción vs. revisión de código) están separadas. 2.4. — Just-in-time (JIT): cuando posible, accesos elevados se otorgan temporalmente para tareas específicas, no de forma permanente. 2.5. — Revisión periódica: accesos se revisan trimestralmente.
3. Autenticación
3.1. — Autenticación multi-factor (MFA): OBLIGATORIO en:
- Todas las cuentas administrativas;
- Acceso a Firebase Console / Google Cloud / GitHub;
- Acceso al AI Suite (cuentas internas);
- Acceso a sistemas con datos confidenciales.
3.2. — Métodos aceptados: TOTP (Authenticator app), security keys (YubiKey), passkeys. No se acepta SMS para roles administrativos.
3.3. — Política de Contraseñas:
- Mínimo 12 caracteres (recomendado 16+).
- Combinación de mayúsculas, minúsculas, números y símbolos.
- Sin reutilización entre servicios; uso de gestor de contraseñas obligatorio (1Password, Bitwarden, Dashlane).
- Sin caducidad obligatoria (alineado con NIST SP 800-63B), salvo evidencia de compromiso.
- Bloqueo de cuenta tras 5 intentos fallidos en 15 minutos.
3.4. — Single Sign-On (SSO): Activado cuando técnicamente factible (Google Workspace SSO para servicios soportados).
4. Niveles de Acceso
| Rol | Sistemas | Datos | MFA | Aprobación |
|---|---|---|---|---|
| Owner / Gerente | Todos | Todos | Obligatorio + key | Asamblea |
| Senior Engineering | Producción + dev + GitHub admin | Confidencial + restringida | Obligatorio + key | Gerente |
| Engineering | Dev + staging | Confidencial (limitado) | Obligatorio | Gerente |
| Operations / Customer Success | Tools + dashboards | Datos de clientes (limitado) | Obligatorio | Gerente |
| Marketing / Content | CMS + analytics | Pública + interna | Obligatorio | Gerente |
| Contratistas | Solo lo asignado al proyecto | Solo lo del proyecto | Obligatorio | Gerente + DPA firmado |
| Asesores / Advisors | Lectura limitada | Pública + interna | Obligatorio | NDA firmado |
5. Provisión de Accesos (Onboarding)
5.1. — Workflow estándar:
- Solicitud documentada (correo electrónico al Gerente).
- Justificación de la necesidad + rol asignado.
- Aprobación por Gerente o delegado.
- Provisión por persona designada (no la misma que aprobó cuando posible — separación de funciones).
- Notificación al solicitante + entrenamiento básico de seguridad si aplica.
- Registro del acceso otorgado en el log de gestión de accesos.
5.2. — Plazo: Accesos básicos en 1 día hábil; accesos administrativos requieren 24-48 horas adicionales para revisión.
5.3. — Documentación obligatoria antes de provisión:
- NDA + IP Assignment firmado (empleados / contratistas);
- DPA firmado (cuando procesa datos de clientes);
- Confirmación de capacitación de seguridad básica.
6. Modificación de Accesos
6.1. Cambios de rol generan revisión completa de accesos en máximo 5 días hábiles.
6.2. Promociones / cambios laterales: accesos previos se revocan y nuevos se provisionan explícitamente, no se acumulan.
6.3. Acceso elevado temporal (just-in-time): aprobación del Gerente, plazo definido, log automático.
7. Desprovisión de Accesos (Offboarding)
7.1. Inmediatamente al notificarse separación (renuncia, terminación, conclusión de contrato):
- Revocación de credenciales corporativas (Google Workspace, Firebase, GitHub, etc.);
- Revocación de SSO;
- Cambio de contraseñas compartidas (en cuentas que las tengan, idealmente ninguna);
- Inhabilitación de tarjetas de acceso físico (si aplica);
- Borrado de información corporativa de equipos personales (BYOD).
7.2. Dentro de 24 horas:
- Logs de actividad reciente del usuario archivados;
- Confirmación documentada del cierre de accesos;
- Notificación a equipos relevantes del cambio.
7.3. Datos en posesión del saliente:
- Devolución de equipos asignados;
- Borrado de información corporativa en dispositivos personales;
- Certificación por escrito del cumplimiento.
8. Cuentas Compartidas
8.1. Prohibidas salvo casos justificados (ej. cuenta de servicio root inicial). Deben:
- Documentarse;
- Tener custodios designados;
- Auditar accesos;
- Migrar a cuentas individuales en cuanto sea técnicamente posible.
9. Acceso de Emergencia (Break Glass)
9.1. En emergencias críticas (caída total del sistema, pérdida de credenciales del único administrador), un procedimiento documentado de “break glass” permite acceso de emergencia mediante:
- Llave maestra custodiada en sobre sellado;
- Aprobación de al menos 2 socios;
- Notificación post-evento a todos los socios + análisis post-mortem.
10. Revisiones Periódicas
10.1. — Trimestral: revisión de todos los accesos activos por el Gerente. Validación de necesidad continuada con cada persona.
10.2. — Anual: auditoría completa de la matriz de accesos por el Oficial de Cumplimiento, con reporte a la Asamblea.
10.3. — Ad-hoc: revisión inmediata tras incidente de seguridad, cambio de rol material, o reporte de comportamiento anómalo.
11. Acceso Físico (cuando aplique)
11.1. — Tarjetas de acceso únicas por persona, con log de uso. 11.2. — Áreas restringidas (ej. servidor) requieren acceso registrado + acompañamiento. 11.3. — Visitantes: registro obligatorio + acompañamiento + identificación visible.
12. Sanciones
Violación de esta política es causa justa de:
- Acciones disciplinarias graduales;
- Terminación con justa causa para incumplimientos materiales;
- Acciones civiles / penales bajo Ley 53-07 cuando aplique (acceso indebido a sistemas).
Adoptada por la Asamblea General de Socios en fecha [__]. Próxima revisión: [fecha + 12 meses].
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...