Guía de Superusuario y Administración SaaS

Guía de Superusuario y Administración SaaS

Versión: v1.0.52 Última actualización: 11-04-2026 Clasificación: Documento interno - Operaciones

Índice

1. Introducción
2. Niveles de Acceso en SaaS
3. Django Admin Panel
4. Comandos de Emergencia (CLI)
5. Medidas de Seguridad para Producción
6. Swagger API Docs (Restringido)
7. Operaciones Comunes de Soporte
8. Granular Permissions System
9. CNS — CreaRack Network Sentinel (Administración)
10. ITSM — IT Service Management (Administración)
11. Mejoras Futuras Opcionales
12. Checklist de Despliegue

1. Introducción

En una aplicación SaaS multi-tenant como CreaRack Pro, existen diferentes niveles de acceso y control. Este documento explica cómo funciona la jerarquía de permisos y qué herramientas tiene el operador del SaaS (tú) para gestionar la plataforma.

Conceptos Clave

2. Niveles de Acceso en SaaS

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   NIVEL 1: SUPERUSUARIO (Operador del SaaS)                            │
│   ─────────────────────────────────────────                            │
│   • Acceso a TODAS las organizaciones/tenants                          │
│   • Panel Django Admin (/admin/)                                        │
│   • Acceso directo a base de datos                                      │
│   • Comandos CLI (manage.py)                                            │
│   • Campo: is_superuser = True                                          │
│                                                                         │
│   Responsabilidades:                                                    │
│   - Mantenimiento de la plataforma                                      │
│   - Soporte técnico a clientes                                          │
│   - Gestión de emergencias (reseteo de contraseñas, MFA, etc.)         │
│   - Monitoreo y auditoría global                                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   NIVEL 2: ADMIN DE ORGANIZACIÓN (Cliente)                             │
│   ────────────────────────────────────────                             │
│   • Solo ve datos de SU organización                                    │
│   • Gestiona usuarios de su empresa                                     │
│   • NO puede ver otras organizaciones                                   │
│   • Campo: role = 'admin'                                               │
│                                                                         │
│   Responsabilidades:                                                    │
│   - Crear/eliminar usuarios de su organización                          │
│   - Gestionar racks y mapas de su empresa                               │
│   - Configurar ajustes de la organización                               │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   NIVEL 3: OPERADOR                                                     │
│   ─────────────────                                                     │
│   • Puede crear y editar racks/dispositivos                            │
│   • No puede gestionar usuarios                                         │
│   • Campo: role = 'operator'                                            │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   NIVEL 4: VIEWER (Solo lectura)                                       │
│   ──────────────────────────────                                       │
│   • Solo puede ver información                                          │
│   • No puede modificar nada                                             │
│   • Campo: role = 'readonly'                                            │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Modelo de Usuario en CreaRack Pro

# core/models.py
class User(AbstractUser):
    # Campos heredados de Django
    is_superuser    # True = acceso total (operador SaaS)
    is_staff        # True = puede acceder a /admin/
    is_active       # True = cuenta activa

    # Campos personalizados
    organization    # FK a Organization (aislamiento de datos)
    role            # 'admin', 'operator', 'readonly'

Sistema de Permisos Granulares (v1.0.36)

Además de los roles base, existe una capa adicional opt-in de permisos:

┌─────────────────────────────────────────────────────────┐
│ Superuser → SIEMPRE True (bypass total)                 │
├─────────────────────────────────────────────────────────┤
│ TemporaryAccess → Elevación temporal (1-72h)            │
├─────────────────────────────────────────────────────────┤
│ ModulePermission → Override JSON per-user               │
├─────────────────────────────────────────────────────────┤
│ Role defaults → admin/operator/readonly                 │
└─────────────────────────────────────────────────────────┘

La función central es has_permission(user, scope, level) en core/utils/permissions.py.

9 scopes: racks, blueprints, observatory, terminal, network, cns, itsm, fleet, users

4 niveles (jerárquicos): none < view < edit < admin

Sin ModulePermission ni TemporaryAccess, el sistema se comporta exactamente igual que antes (solo roles).

3. Django Admin Panel

Acceso

Seguridad: /admin/ en producción está protegido por AdminPathsMiddleware — solo accesible desde las IPs de trabajo (37.34.68.35), casa (93.176.0.0/16) y Domo (212.230.190.240). Cualquier otra IP recibe 404.

Credenciales Actuales (Desarrollo)

Usuario: admin
Password: [la que hayas configurado]

Acciones rápidas (v1.0.49)

Los listados de Organizations y Users muestran las acciones como botones coloreados en línea (rojo=delete, naranja=disable, verde=enable/restore, azul=resend). Seleccionar items con checkbox → click en el botón. No hace falta buscar en un dropdown.

Secciones Disponibles

Suscripción y Módulos (v1.0.48)

Guía completa de la consola: Documentation/guides/DJANGO_CONSOLE_GUIDE.md

Gestión de Usuarios y Organizaciones

Novedad v1.0.49: Los usuarios se pueden crear directamente desde la ficha de Organization (inline). El conteo de usuarios en el listado es clickable y filtra el listado global de Users.

Email de Bienvenida (v1.0.49)

Al crear un usuario con email, se envía automáticamente un email de bienvenida con:

• Nombre de la organización y credenciales (username, rol)
• Link para establecer contraseña (token de un solo uso via allauth)
• URL de acceso a la plataforma

Gestión de Datos

Blueprints (Mapas)

CNS — Network Sentinel (AI Insights)

ITSM — IT Service Management

Permisos y Acceso Granular

Seguridad y Auditoría

Diferencia: Django Admin vs App Normal

4. Comandos de Emergencia (CLI)

Acceso via SSH al servidor o docker compose exec:

Crear Superusuario

# Desarrollo (Docker)
docker compose exec web python manage.py createsuperuser

# Producción (SSH)
python manage.py createsuperuser

Resetear Contraseña (Sin conocer la anterior)

# Por username
docker compose exec web python manage.py changepassword admin

# O via shell
docker compose exec web python manage.py shell -c "
from core.models import User
user = User.objects.get(username='admin')
user.set_password('nueva_contraseña_segura')
user.save()
print('Contraseña actualizada')
"

Activar/Desactivar Usuario

docker compose exec web python manage.py shell -c "
from core.models import User
user = User.objects.get(username='usuario_bloqueado')
user.is_active = True  # o False para desactivar
user.save()
print(f'Usuario {user.username} activo: {user.is_active}')
"

Eliminar MFA de Usuario Bloqueado

docker compose exec web python manage.py shell -c "
from core.models import User
from allauth.mfa.models import Authenticator

user = User.objects.get(username='usuario_sin_acceso')
deleted = Authenticator.objects.filter(user=user).delete()
print(f'Eliminados {deleted[0]} dispositivos MFA de {user.username}')
"

Listar Superusuarios

docker compose exec web python manage.py shell -c "
from core.models import User
for u in User.objects.filter(is_superuser=True):
    print(f'{u.username} - activo: {u.is_active}')
"

Convertir Usuario en Superusuario

docker compose exec web python manage.py shell -c "
from core.models import User
user = User.objects.get(username='usuario_existente')
user.is_superuser = True
user.is_staff = True
user.save()
print(f'{user.username} ahora es superusuario')
"

Backup de Base de Datos

Producción (automatizado):

• pg_dump diario a las 3:00 AM → local (14d retención) + Hetzner Object Storage via rclone (30d retención)
• WAL archiving cada 15 min → Object Storage (permite Point-in-Time Recovery)
• pg_basebackup semanal domingos 4:00 AM → Object Storage
• Scripts: /opt/backups/pg_backup.sh, /opt/backups/wal_sync.sh, /opt/backups/pg_basebackup.sh

Manual (desarrollo o emergencia):

# PostgreSQL — backup manual
docker compose exec db pg_dump -U postgres crearack > backup_$(date +%Y%m%d).sql

# Restaurar
docker compose exec -T db psql -U postgres crearack < backup_20260130.sql

Referencia completa: Documentation/guides/DISASTER_RECOVERY.md

5. Medidas de Seguridad para Producción

5.1 Restricción por IP — Django Admin (IMPLEMENTADO)

Middleware: core/middleware/admin_paths.py → AdminPathsMiddleware

/admin/ solo es accesible desde IPs autorizadas. Cualquier otra IP recibe 404 (no 403, para no revelar que existe).

IPs autorizadas (configuradas en ALLOWED_NETWORKS):

Proxy-aware: Lee X-Forwarded-For para funcionar detrás de Traefik/Cloudflare.

Para cambiar IPs: Editar ALLOWED_NETWORKS en core/middleware/admin_paths.py y hacer deploy.

5.2 PostgreSQL Row-Level Security — RLS (IMPLEMENTADO v1.0.50)

Middleware: core/middleware/tenant_rls.py → TenantRLSMiddleware

Capa de seguridad a nivel de base de datos que impide acceso cross-tenant incluso si el código ORM omite el filtro por organización.

Funcionamiento: En cada request, el middleware ejecuta SET app.current_org_id = '{org_id}' en la conexión PostgreSQL. Las políticas RLS filtran automáticamente las filas. Al terminar el request, RESET previene leakage.

Cobertura: 35 tablas (migration core/0017_rls_policies)

Superuser bypass: Los superusers envían org_id=0 que bypassa todas las políticas RLS. Esto es necesario para el Django Admin.

Verificación en producción:

ssh root@crearack.com "docker exec crearack-pro-zcmvsl-db-1 psql -U crearack -d crearack_pro -c \"SELECT tablename, policyname FROM pg_policies LIMIT 5;\""

Huey tasks de protección (v1.0.50):

• purge_deleted_organizations (4:00 AM) — hard-delete de orgs soft-deleted >90 días
• check_tenant_integrity (4:30 AM) — detecta anomalías cross-tenant, log en SystemLog
• run_org_backups (3:30 AM) — backup ZIP diario per-org con retención configurable

5.3 Restricción por Superuser — Swagger API Docs (IMPLEMENTADO)

Mismo middleware: AdminPathsMiddleware

/api/docs y /api/openapi.json solo son accesibles para usuarios superuser autenticados. Usuarios normales y anónimos reciben 404.

5.3 Rate Limiting (IMPLEMENTADO)

Rate limiting activo en producción via RateLimitMiddleware:

5.4 MFA para Superusuarios

El sistema soporta MFA (Passkeys + TOTP) via django-allauth. Configurar en /accounts/2fa/.

Política recomendada: Todo superusuario DEBE tener MFA configurado antes de acceder a producción.

5.5 Otras Medidas Activas

Resumen de Protección de Rutas Sensibles

6. Swagger API Docs (Restringido)

6.1 Qué es

Swagger (OpenAPI) es la interfaz web interactiva que documenta todos los ~509 endpoints de la API de CreaRack Pro. Django Ninja la genera automáticamente desde los decoradores @router.get(), @router.post(), etc. y los schemas Pydantic del código fuente.

La documentación está siempre sincronizada con el código — no hay desfase entre lo documentado y lo real.

Guía completa: Documentation/guides/SWAGGER_API_DOCS_GUIDE.md

6.2 Acceso

Usuarios normales y anónimos reciben 404 (protegido por AdminPathsMiddleware).

6.3 Estructura de la interfaz

Al abrir /api/docs se presenta una interfaz Swagger UI con:

• Barra superior — Buscador de endpoints + link a la spec OpenAPI JSON
• Agrupación por tags — Los endpoints se organizan en secciones colapsables:

• Cada endpoint muestra — método HTTP, URL, parámetros (path, query, body), schemas request/response con tipos y validaciones, códigos de respuesta posibles

6.4 Cómo probar un endpoint

1. Navega al endpoint deseado y click en la fila para expandirlo
2. Click “Try it out” (botón azul en la esquina)
3. Rellena los parámetros — los obligatorios están marcados con asterisco
4. Click “Execute”
5. Swagger muestra el response (status code, headers, body JSON)

CSRF: Swagger maneja automáticamente el token CSRF si estás logueado. Para endpoints POST/PUT/DELETE, el token se envía como cookie.

6.5 Descargar OpenAPI spec

Importar en Postman:

1. Abre Postman → Import → Link
2. Pega: https://crearack.com/api/openapi.json (requiere sesión de superuser activa en el navegador)
3. Postman crea una Collection con los ~509 endpoints organizados por tags

6.6 Schemas y validación

Django Ninja genera schemas Pydantic que se reflejan en Swagger:

• Input schemas — Validan el body de POST/PUT (tipos, required, max_length, enum values)
• Output schemas — Documentan la estructura de la respuesta (campos, tipos, nullable)
• Error schemas — ErrorSchema con {error: string} para 400/404/403

Los schemas son la documentación viva de la API — si un campo cambia en el código, Swagger lo refleja inmediatamente.

6.7 Por qué está restringido

Swagger expone el mapa completo de la API (URLs, schemas, tipos de campo, validaciones). En un SaaS, esto es información que facilita:

• Enumeración de endpoints y descubrimiento de rutas internas
• Ingeniería inversa de la estructura de datos
• Ataques dirigidos con payloads construidos a partir de los schemas

Solo los operadores del SaaS (superusers) necesitan acceso. Clientes que necesiten integración reciben documentación específica de su módulo.

7. Operaciones Comunes de Soporte

Escenario 1: Usuario olvidó su contraseña

Opción A: El usuario usa “Forgot Password” (si está configurado email)

Opción B: Admin resetea la contraseña

1. Django Admin → Users → Seleccionar usuario
2. Cambiar contraseña en el formulario
3. Comunicar nueva contraseña al usuario

Escenario 2: Usuario perdió acceso a MFA

1. Django Admin → MFA → Authenticators
2. Filtrar por usuario afectado
3. Eliminar todos sus dispositivos MFA
4. El usuario puede entrar con contraseña y configurar nuevo MFA

O via CLI:

docker compose exec web python manage.py shell -c "
from allauth.mfa.models import Authenticator
Authenticator.objects.filter(user__username='usuario').delete()
"

Escenario 3: Necesito ver datos de un cliente

1. Django Admin → Racks (o Blueprints)
2. Usar filtros para seleccionar la organización
3. Ver/editar datos necesarios

Escenario 4: Cliente quiere eliminar su cuenta

1. Django Admin → Users → Seleccionar usuarios de la organización
2. Eliminar usuarios
3. Django Admin → Organizations → Eliminar organización
4. Los racks y datos asociados se eliminan en cascada (verificar configuración de FK)

Escenario 5: Debugging - Necesito “ver como” un usuario

Implementado en v1.0.36 — Solo superusers pueden impersonar.

Opción A: Via UI (recomendada)

1. Ir a Settings → User Management
2. Click “Impersonate” en la fila del usuario deseado
3. Introducir razón (obligatoria, min 3 caracteres)
4. La app se recarga mostrando un banner naranja con el usuario impersonado
5. Click “Stop” en el banner para volver a tu cuenta

Opción B: Via API

# Iniciar impersonación
curl -X POST https://crearack.com/api/admin/impersonate/start \
  -H "Content-Type: application/json" \
  -d '{"user_id": 5, "reason": "Debugging reported issue #123"}'

# Detener impersonación
curl -X POST https://crearack.com/api/admin/impersonate/stop

Restricciones:

• Solo is_superuser=True puede impersonar
• No se puede impersonar a otro superusuario
• No se puede impersonar si ya estás impersonando
• Todo queda registrado en ImpersonationLog (admin, target, razón, IP, timestamps)

Audit trail: Django Admin → Impersonation Logs (solo lectura)

Escenario 6: Dar acceso temporal a un módulo

Implementado en v1.0.36 — Solo admins pueden conceder.

Via UI:

1. Settings → User Management → Edit (usuario)
2. Sección “Temporary Access” en el modal
3. Seleccionar scope, level, duración (1-72h) y razón
4. Click “Grant”

Via API:

curl -X POST https://crearack.com/api/admin/temporary-access/grant \
  -H "Content-Type: application/json" \
  -d '{"user_id": 5, "scope": "fleet", "level": "admin", "duration_hours": 4, "reason": "Agent troubleshooting"}'

El acceso expira automáticamente (tarea Huey cada 5 min) o se puede revocar manualmente.

8. Granular Permissions System

Añadido en v1.0.36

8.1 Arquitectura

El sistema de permisos evalúa en orden de prioridad:

1. Superuser → siempre True (bypass total)
2. TemporaryAccess → elevación temporal activa (no expirada, no revocada)
3. ModulePermission → override JSON por usuario
4. Role defaults → permisos estándar del role (admin/operator/readonly)

La función central es:

from core.utils.permissions import has_permission

# Verificar si user tiene al menos nivel "edit" en "terminal"
if has_permission(user, "terminal", "edit"):
    ...

is_admin(user) sigue funcionando — internamente llama a has_permission(user, "users", "admin").

8.2 Impersonación (Superuser Only)

Permite ver la app exactamente como la ve otro usuario, útil para debugging y soporte.

Seguridad:

• Solo superusers pueden impersonar
• No se puede impersonar a otro superuser
• No se puede impersonar estando ya impersonando
• Todo queda en ImpersonationLog (admin, target, IP, razón, timestamps)

Middleware: core.middleware.ImpersonationMiddleware — va después de AuthenticationMiddleware, lee _impersonate_user_id de la session.

8.3 Module Permissions

Permite customizar permisos por usuario más allá de su role.

Ejemplo: Un operator que no debe tener acceso a Terminal:

PUT /api/admin/permissions/5
{"permissions": {"terminal": "none"}}

El operador mantiene edit en todo lo demás (por su role), pero terminal queda bloqueado.

8.4 Temporary Access

Elevación temporal de permisos sin cambiar el role permanente.

Restricciones:

• Solo admins pueden conceder
• Duración: 1-72 horas
• No se puede conceder nivel superior al propio
• Tarea Huey expire_temporary_access() cada 5 min revoca expirados

Ejemplo: Dar acceso admin a Fleet por 4 horas a un readonly:

POST /api/admin/temporary-access/grant
{"user_id": 8, "scope": "fleet", "level": "admin", "duration_hours": 4, "reason": "Agent debugging"}

8.5 Decoradores

from core.decorators import admin_required, permission_required

@router.get("/some-endpoint")
@admin_required  # requiere admin en scope "users"
def admin_view(request): ...

@router.get("/terminal-stuff")
@permission_required("terminal", "edit")  # requiere edit en scope "terminal"
def terminal_view(request): ...

8.6 Django Admin

9. CNS — CreaRack Network Sentinel (Administración)

Guía completa: Documentation/guides/CNS_GUIDE.md

9.1 Qué es CNS

CNS es el sistema de inteligencia artificial que analiza anomalías de red detectadas por el Agent local. Usa Gemini 3 Flash (principal) o Claude Haiku (alternativo) para generar diagnósticos automáticos con nivel de riesgo (HIGH/MEDIUM/LOW).

9.2 Django Admin — Modelos CNS

9.3 Purgar Insights (Reset completo)

Via API (superuser autenticado):

curl -X DELETE https://crearack.com/api/monitoring/sentinel/insights/purge \
  -H "Authorization: Bearer <token>"

Via CLI en producción:

ssh root@<servidor>
docker exec -it <container> python manage.py shell -c "from django.db import connection; cursor = connection.cursor(); [cursor.execute(f'DELETE FROM {t}') or print(f'{t}: {cursor.rowcount} deleted') for t in ['monitoring_notificationlog','monitoring_insightconversation','monitoring_aiinsightauditlog','monitoring_insightlink','monitoring_aiinsight']]"

Orden de borrado: Primero tablas dependientes (notification_log, conversation, audit_log, links), luego aiinsight.

9.4 Rate Limiting

CNS tiene límite de 100 insights/hora/organización. Configurable en monitoring/services/insight_service.py:

INSIGHT_RATE_LIMIT = 100  # insights per hour per tenant

9.5 AI Providers

El provider se configura por organización. Si Gemini devuelve 429 (rate limit), aplica exponential backoff (2s→4s).

9.6 WebSocket — Insights en Tiempo Real

Los insights se pushean via WebSocket a todos los clientes conectados al Observatory. Canal: sentinel_<org_id>.

Si un operador reporta que no recibe insights en tiempo real:

1. Verificar que el Agent está conectado (Fleet Manager → status connected)
2. Verificar que el Agent está ejecutando Sentinel Mode
3. Comprobar logs: docker compose logs -f web | grep sentinel

9.7 Auto-Resolve

Cuando el Agent detecta que un dispositivo se recupera, envía POST /sentinel/insights/recover/{target_id}. El SaaS auto-acknowledges todos los insights de conectividad pendientes para ese target.

10. ITSM — IT Service Management (Administración)

Guía completa: Documentation/guides/ITSM_GUIDE.md

10.1 Qué es ITSM

El módulo ITSM extiende CNS con capacidades de gestión de servicios IT: SLAs, notificaciones, escalado, correlación de incidentes, ventanas de mantenimiento, base de conocimiento, runbooks y detección de patrones recurrentes.

10.2 Inicialización de SLA

Las SLA policies se crean automáticamente desde el frontend (botón “Initialize Default Policies” en la pestaña ITSM del Observatory) o via API:

curl -X POST https://crearack.com/api/monitoring/sentinel/itsm/sla/initialize \
  -H "Authorization: Bearer <token>"

Crea 3 políticas por defecto:

10.3 Django Admin — Modelos ITSM

Todos los modelos ITSM están registrados en Django Admin y accesibles en /admin/monitoring/:

10.4 Gestión de Notificaciones

Para configurar un canal de notificación:

1. Django Admin → Notification Channels → Add
2. Seleccionar tipo: webhook, email, slack o teams
3. Configurar en el campo config (JSON):

// Webhook
{"url": "https://hooks.example.com/alert", "headers": {"X-Api-Key": "secret"}}

// Slack
{"webhook_url": "https://hooks.slack.com/services/T00/B00/xxx"}

// Email
{"addresses": ["ops@example.com", "noc@example.com"]}

4. Asignar risk levels: ["HIGH", "MEDIUM"]

10.5 Ventanas de Mantenimiento

Durante una ventana de mantenimiento activa, CNS suprime la creación de insights y/o el envío de notificaciones para los targets seleccionados.

Crear via API:

curl -X POST https://crearack.com/api/monitoring/sentinel/itsm/maintenance \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Switch upgrade",
    "start_at": "2026-03-15T02:00:00Z",
    "end_at": "2026-03-15T04:00:00Z",
    "suppress_insights": true,
    "suppress_notifications": true,
    "target_ids": [1, 2, 3]
  }'

Crear via Django Admin: /admin/monitoring/maintenancewindow/add/

10.6 Base de Conocimiento (Known Issues)

Los Known Issues permiten documentar problemas recurrentes con su resolución. El campo match_keywords (JSON array) permite auto-matching cuando se crea un nuevo insight con keywords similares.

10.7 Runbooks

Los runbooks son procedimientos paso a paso para resolución de incidentes. Pueden ser genéricos o vendor-specific (campo vendor: cisco_ios, juniper, etc.).

10.8 Tareas Periódicas (Huey)

Verificar estado de Huey:

docker compose logs -f web | grep huey

10.9 Reportes y Analytics

Dashboard analytics (via API):

# MTTR/MTTA por periodo
GET /api/monitoring/sentinel/itsm/analytics?period=7d

# Reporte completo
GET /api/monitoring/sentinel/itsm/reports?type=summary&period=30d

# Export CSV
GET /api/monitoring/sentinel/itsm/reports?type=summary&period=30d&format=csv

11. Mejoras Futuras Opcionales

11.1 Panel de Administración SaaS Separado

Crear una aplicación separada para gestión interna:

app.crearack.com        → Aplicación para clientes
admin.crearack.com      → Panel interno para operadores

El panel interno incluiría:

• Dashboard con métricas de todas las organizaciones
• Gestión de suscripciones/facturación
• Herramientas de soporte
• Logs y auditoría centralizados

11.2 SSO para Empleados

Single Sign-On para que los operadores accedan con cuenta corporativa:

• Google Workspace
• Microsoft Azure AD
• Okta

11.3 Audit Log Global

Parcialmente implementado: El workspace (workspace.crearack.com) ya tiene un Activity Log completo con tabla D1 activity_log, logging automático de todas las operaciones MCP y REST, filtros, búsqueda y UI en /history. Para CreaRack Pro (la app principal), un audit log similar a nivel de modelos Django está pendiente de implementación.

Modelo propuesto para CreaRack Pro:

class AuditLog(models.Model):
    user = models.ForeignKey(User)
    action = models.CharField()  # 'create', 'update', 'delete'
    model = models.CharField()   # 'Rack', 'Device', etc.
    object_id = models.IntegerField()
    changes = models.JSONField()  # Antes/después
    timestamp = models.DateTimeField(auto_now_add=True)
    ip_address = models.GenericIPAddressField()

12. Checklist de Despliegue

Antes de ir a producción, verificar:

Seguridad del Admin

• /admin/ restringido por IP (AdminPathsMiddleware) — solo trabajo/casa
• /api/docs restringido a superusers (AdminPathsMiddleware)
• /metrics restringido a IPs internas (MetricsIPRestrictionMiddleware)
• Rate limiting activo (RateLimitMiddleware: 5 req/60s en login)
• HTTPS forzado (Traefik + Cloudflare)
• DEBUG = False en producción
• SECRET_KEY única y segura
• CSP headers A+ (CSPMiddleware)
• MFA configurado para todos los superusuarios (recomendado)

Credenciales

• Contraseña del superusuario es fuerte (>16 caracteres)
• Contraseña de base de datos es fuerte
• Variables de entorno no expuestas en código

Multi-Tenancy (v1.0.52)

• RLS policies activas en 33 tablas (migration core/0019)
• TenantRLSMiddleware en cadena de middleware (SET/RESET por request)
• Superuser bypass (org_id=0) verificado
• Self-service signup (POST /api/signup) con rate limiting
• Purge automático orgs soft-deleted >90 días (Huey task 4:00 AM)
• Integrity check cross-tenant (Huey task 4:30 AM)
• 188 tests (todos los módulos + 22 cross-tenant HTTP + 33 tablas RLS)
• 22 índices custom en 18 modelos (bulk ops optimizadas)

Backups

• Backup automático per-tenant configurado (Huey task 3:30 AM)
• Retención configurable por plan (Starter 7d, Pro 30d)
• Descarga manual via GET /api/backup/latest
• Backups offsite: pg_dump diario + WAL sync → Hetzner Object Storage (rclone, bucket crearack-backups)
• WAL archiving + pg_basebackup semanal → Point-in-Time Recovery (PITR)
• Hetzner snapshots automáticos semanales
• Restore probado end-to-end desde backup automático

Monitoreo

• UptimeRobot: monitor crearack.com/health cada 5 min, alertas email
• Health endpoint: GET/HEAD /health verifica DB + Cache
• Logs accesibles via SSH: docker logs crearack-pro-zcmvsl-web-1 --tail 100
• Alertas de errores aplicativos (log-based alerting — roadmap)

Referencias

• Django Admin Documentation
• django-axes (Rate Limiting)
• OWASP Admin Panel Security

Mantenido por: Equipo CreaRack Clasificación: Documento interno - Solo para operadores del SaaS

Véase también

• [[crearack-tech—admin—django-admin]] — consola Django admin
• [[crearack-tech—guides—django-console-guide]] — consola Django admin
• [[concept—saas—multi-tenancy]] — modelo multi-tenancy con RLS
• [[concept—saas—module-gating]] — gating de módulos por plan SaaS
• [[crearack-tech—agents—dev-core]] — perfil de subagente dev-core
• [[entity—core—model—organization]] — modelo tenant principal del core
• [[entity—core—model—plan]] — planes SaaS y módulos contratables