Seguridad Empresarial: RBAC, SSO y Multi-Tenancy en CorePlexML
Por Que la Seguridad Empresarial Importa en ML
Las plataformas de machine learning ocupan una posicion unica en el panorama de seguridad empresarial. Manejan algunos de los activos mas sensibles que posee una organizacion: datos de entrenamiento propietarios que pueden contener PII de clientes, propiedad intelectual de modelos que representa meses de inversion en I+D, y pipelines de prediccion que influyen directamente en decisiones de negocio. Una brecha o una mala configuracion en una plataforma ML puede exponer datos de clientes, filtrar ventajas competitivas o permitir que usuarios no autorizados manipulen predicciones que impulsan sistemas criticos para los ingresos.
Sin embargo, muchas plataformas ML tratan la seguridad como algo secundario. Comienzan como herramientas internas con controles de acceso minimos, y para cuando la organizacion crece lo suficiente como para requerir una gobernanza adecuada, la arquitectura de la plataforma dificulta la incorporacion retroactiva de seguridad. CorePlexML adopta el enfoque contrario: la seguridad esta integrada en los cimientos, no atornillada despues del hecho.
Esta guia cubre la arquitectura de seguridad completa de CorePlexML, desde multi-tenancy y control de acceso basado en roles hasta integracion SSO, seguridad a nivel de fila, gestion de API keys y registro de auditoria.
Arquitectura Multi-Tenant
CorePlexML implementa multi-tenancy a nivel de proyecto. Cada recurso en la plataforma (datasets, experimentos, modelos, despliegues, alertas, politicas de re-entrenamiento) pertenece a un proyecto, y los proyectos pertenecen a usuarios. Esto crea un limite natural de aislamiento: un usuario solo puede acceder a recursos dentro de sus propios proyectos a menos que se configure un uso compartido explicito.
El aislamiento a nivel de proyecto se extiende a la capa de base de datos. Cada consulta que recupera recursos incluye una verificacion de propiedad del proyecto, asegurando que incluso si existe un bug en la logica de aplicacion, la base de datos no devolvera recursos del proyecto de otro usuario.
from coreplexml import CorePlexClient
client = CorePlexClient(
base_url="https://api.coreplexml.io",
api_key="your-api-key"
)
# Create a project with team access
project = client.projects.create(
name="Fraud Detection Pipeline",
description="Real-time fraud scoring for payment processing",
team_members=[
{"email": "alice@company.com", "role": "editor"},
{"email": "bob@company.com", "role": "viewer"},
{"email": "carol@company.com", "role": "editor"}
]
)
print(f"Project ID: {project.id}")
print(f"Owner: {project.owner}")
print(f"Team size: {len(project.team_members)}")Los limites de recursos se imponen en cada endpoint de la API. Cuando un usuario solicita un dataset, el sistema verifica no solo que el dataset existe, sino que el usuario solicitante tiene el rol apropiado en el proyecto propietario del dataset. Esta verificacion de propiedad se implementa como una capa de middleware que se ejecuta antes de cualquier logica de negocio, lo que hace imposible eludirla a traves de bugs a nivel de aplicacion.
Control de Acceso Basado en Roles
CorePlexML implementa tres roles con limites de permisos claramente definidos. Cada rol representa un nivel diferente de confianza y capacidad dentro de un proyecto.
Owner
El rol de owner tiene control total sobre el proyecto y todos sus recursos. Los owners pueden crear, leer, actualizar y eliminar cualquier recurso. Pueden gestionar la membresia del equipo, incluyendo invitar nuevos miembros, cambiar roles y revocar acceso. Pueden configurar la facturacion, cambiar los ajustes del proyecto y eliminar el proyecto por completo. Cada proyecto tiene exactamente un owner, que es el usuario que lo creo. La propiedad puede transferirse pero no compartirse.
Editor
El rol de editor puede crear y modificar recursos dentro del proyecto pero no puede gestionar la membresia del equipo ni los ajustes del proyecto. Los editores pueden subir datasets, ejecutar experimentos, crear despliegues, configurar alertas y establecer politicas de re-entrenamiento. Pueden modificar recursos creados por otros editores. No pueden invitar nuevos miembros del equipo, cambiar roles ni eliminar el proyecto.
Viewer
El rol de viewer tiene acceso de solo lectura a todos los recursos dentro del proyecto. Los viewers pueden navegar por los datasets, revisar resultados de experimentos, inspeccionar metricas de modelos y ver el estado de los despliegues. No pueden crear, modificar ni eliminar ningun recurso. El rol de viewer es apropiado para stakeholders que necesitan visibilidad sobre las operaciones de ML sin la capacidad de realizar cambios, como product managers, responsables de cumplimiento o sponsors ejecutivos.
# Manage team roles
client.projects.update_member(
project_id="proj_abc123",
email="bob@company.com",
role="editor"
)
# List current team with roles
team = client.projects.list_members(project_id="proj_abc123")
for member in team:
print(f"{member.email}: {member.role} "
f"(joined: {member.joined_at.strftime('%Y-%m-%d')})")La matriz de permisos cubre cada tipo de recurso en la plataforma:
- Datasets: Owners y editors pueden subir, modificar y eliminar. Viewers pueden leer y descargar.
- Experimentos: Owners y editors pueden crear y configurar. Viewers pueden ver resultados y leaderboards.
- Modelos: Owners y editors pueden registrar, transicionar etapas y actualizar tarjetas de modelo. Viewers pueden ver metricas y linaje.
- Despliegues: Owners y editors pueden crear, modificar estrategias y disparar rollbacks. Viewers pueden ver estado y metricas.
- Alertas: Owners y editors pueden crear y configurar reglas y canales. Viewers pueden ver el historial de alertas.
- Politicas de re-entrenamiento: Owners y editors pueden crear y modificar. Viewers pueden ver la configuracion de la politica y el historial de ejecucion.
Stack de Autenticacion
CorePlexML soporta multiples metodos de autenticacion para acomodar diferentes patrones de acceso y requisitos empresariales.
Sesiones Basadas en Cookies para la UI
La interfaz web utiliza cookies HTTP-only, seguras y same-site para la gestion de sesiones. Cuando un usuario inicia sesion a traves del navegador, el servidor crea una sesion, la almacena en PostgreSQL y establece una cookie de sesion. Las solicitudes subsiguientes incluyen esta cookie automaticamente, y el servidor la valida contra los datos de sesion almacenados.
Las sesiones tienen expiracion configurable. Por defecto, las sesiones expiran despues de 24 horas de inactividad o 7 dias de tiempo de vida total, lo que ocurra primero. Las organizaciones pueden ajustar estos valores para coincidir con sus politicas de seguridad. Cuando una sesion expira, el usuario es redirigido a la pagina de inicio de sesion.
La proteccion CSRF se aplica a todas las solicitudes que modifican estado. El servidor genera un token CSRF que debe incluirse en las solicitudes POST, PUT y DELETE. El frontend incluye este token automaticamente a traves de la libreria ApiClient.
Autenticacion Bearer Token para la API
El acceso programatico utiliza bearer tokens en el header Authorization. Los tokens se generan a traves de la interfaz de gestion de API keys y pueden estar delimitados a permisos y proyectos especificos:
# Authenticate with bearer token
import requests
headers = {
"Authorization": "Bearer cpx_live_abc123def456",
"Content-Type": "application/json"
}
response = requests.get(
"https://api.coreplexml.io/api/projects",
headers=headers
)Los bearer tokens no expiran automaticamente pero pueden ser revocados en cualquier momento a traves de la interfaz de gestion. Las organizaciones que requieren rotacion de tokens pueden establecer fechas de expiracion al momento de la creacion.
Gestion de API Keys
Las API keys proporcionan acceso delimitado y auditable para sistemas automatizados, pipelines de CI/CD e integraciones de terceros. Cada key tiene un nombre, un conjunto de permisos, una fecha de expiracion opcional y un alcance de proyecto opcional:
# Create a scoped API key
api_key = client.api_keys.create(
name="CI/CD Pipeline - Production",
permissions=["deployments:read", "deployments:create",
"models:read", "predictions:create"],
project_ids=["proj_abc123"],
expires_at="2026-06-30T23:59:59Z",
description="Used by GitHub Actions for automated model deployment"
)
print(f"Key ID: {api_key.id}")
print(f"Key: {api_key.key}") # Only shown once at creation time
print(f"Permissions: {api_key.permissions}")
print(f"Expires: {api_key.expires_at}")
# List active API keys
keys = client.api_keys.list()
for key in keys:
print(f"{key.name}: {key.id} - "
f"Last used: {key.last_used_at or 'Never'} - "
f"Expires: {key.expires_at or 'Never'}")
# Revoke a compromised key
client.api_keys.revoke(key_id="key_compromised_123")El valor de la key se muestra una sola vez en el momento de la creacion y nunca se almacena en texto plano. Si una key se pierde, se debe crear una nueva y revocar la antigua. Esto previene la exfiltracion de keys desde backups de base de datos o acceso interno.
El uso de API keys se rastrea y esta disponible en el log de auditoria. Cada llamada a la API registra que key se utilizo, cuando, desde que direccion IP y que accion se realizo. Esto proporciona una pista de actividad completa para cualquier sistema automatizado.
Integracion SSO y SAML
Las organizaciones empresariales tipicamente gestionan la identidad a traves de un proveedor central como Okta, Azure Active Directory o Google Workspace. CorePlexML se integra con estos proveedores mediante los protocolos SAML 2.0 y OIDC, permitiendo a los usuarios autenticarse con sus credenciales corporativas existentes.
Configuracion SAML
La integracion SAML requiere configurar CorePlexML como un service provider (SP) en tu identity provider (IdP). La plataforma proporciona la metadata del SP (entity ID, ACS URL y certificado) que tu IdP necesita:
# Configure SAML for your organization
saml_config = client.auth.configure_saml(
organization_id="org_enterprise_01",
config={
"idp_entity_id": "https://idp.company.com/saml/metadata",
"idp_sso_url": "https://idp.company.com/saml/sso",
"idp_certificate": "-----BEGIN CERTIFICATE-----\nMIIC...\n-----END CERTIFICATE-----",
"sp_entity_id": "https://api.coreplexml.io/saml/metadata",
"attribute_mapping": {
"email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"first_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
"last_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
"groups": "http://schemas.xmlsoap.org/claims/Group"
},
"auto_provision_users": True,
"default_role": "viewer",
"group_role_mapping": {
"ml-admins": "owner",
"ml-engineers": "editor",
"ml-stakeholders": "viewer"
}
}
)El parametro group_role_mapping mapea los grupos del IdP a roles de CorePlexML. Cuando un usuario se autentica a traves de SAML, la plataforma lee sus membresias de grupo desde la asercion SAML y asigna el rol correspondiente. Esto permite a las organizaciones gestionar el acceso a la plataforma ML a traves de sus flujos de trabajo existentes de gestion de grupos.
El flag auto_provision_users controla si los nuevos usuarios se crean automaticamente cuando se autentican por primera vez a traves de SSO. Cuando esta habilitado, un usuario que existe en el IdP pero no en CorePlexML sera creado con el default_role. Cuando esta deshabilitado, los usuarios deben ser invitados explicitamente antes de poder iniciar sesion.
Proveedores OAuth
Para organizaciones que prefieren autenticacion basada en OAuth, CorePlexML soporta Google y GitHub como proveedores de identidad:
# Configure Google OAuth
oauth_config = client.auth.configure_oauth(
provider="google",
config={
"client_id": "your-google-client-id.apps.googleusercontent.com",
"client_secret": "your-google-client-secret",
"allowed_domains": ["company.com", "subsidiary.com"],
"auto_provision_users": True
}
)
# Configure GitHub OAuth
github_config = client.auth.configure_oauth(
provider="github",
config={
"client_id": "your-github-client-id",
"client_secret": "your-github-client-secret",
"allowed_organizations": ["company-org"],
"auto_provision_users": True
}
)Los parametros allowed_domains y allowed_organizations restringen la autenticacion a usuarios que pertenecen a dominios u organizaciones aprobadas. Sin estas restricciones, cualquier usuario con una cuenta de Google o GitHub podria autenticarse, lo cual es inapropiado para despliegues empresariales.
Row-Level Security en PostgreSQL
CorePlexML aprovecha el Row-Level Security (RLS) de PostgreSQL como un mecanismo de defensa en profundidad para el aislamiento de datos. Las politicas RLS se definen a nivel de base de datos y son aplicadas por PostgreSQL mismo, de forma independiente al codigo de aplicacion.
Cuando RLS esta habilitado en una tabla, cada consulta se filtra automaticamente para devolver solo las filas a las que el usuario actual esta autorizado a acceder. Incluso si la aplicacion construye una consulta sin una clausula WHERE adecuada (debido a un bug o un ataque de inyeccion), RLS asegura que las filas no autorizadas sean invisibles.
Las politicas RLS en CorePlexML estan estructuradas en torno a la propiedad del proyecto. Cada tabla que contiene datos con alcance de proyecto tiene una politica que restringe el acceso a filas donde el project_id coincide con uno de los proyectos autorizados del usuario. Esto crea un limite de aislamiento a nivel de base de datos que complementa las verificaciones de propiedad a nivel de aplicacion.
RLS proporciona proteccion contra varios vectores de ataque que las verificaciones a nivel de aplicacion por si solas no pueden abordar completamente. Los ataques de inyeccion SQL que eluden la logica de aplicacion siguen estando restringidos por las politicas RLS. Las herramientas internas o scripts de administracion que accidentalmente omiten filtros de propiedad no pueden acceder a datos no autorizados. Las operaciones de backup y recuperacion de base de datos que restauran datos en el entorno equivocado estan protegidas por la aplicacion de RLS sobre los datos restaurados.
Registro de Auditoria
CorePlexML mantiene un registro de auditoria integral que graba cada evento significativo en la plataforma. El log de auditoria es de solo adicion e inmutable: los eventos no pueden ser modificados ni eliminados despues de ser registrados.
# Query the audit log
events = client.audit.list_events(
project_id="proj_abc123",
event_types=["deployment.created", "deployment.rollback",
"model.stage_transition", "api_key.created"],
start_time="2026-02-01T00:00:00Z",
end_time="2026-03-01T00:00:00Z",
limit=50
)
for event in events:
print(f"[{event.timestamp}] {event.event_type}")
print(f" User: {event.user_email}")
print(f" IP: {event.ip_address}")
print(f" Details: {event.details}")
print()El registro de auditoria captura las siguientes categorias de eventos:
- Eventos de autenticacion: Intentos de inicio de sesion (exitosos y fallidos), creacion y expiracion de sesiones, aserciones SSO, uso de API keys
- Eventos de autorizacion: Verificaciones de permisos, cambios de rol, cambios en la membresia del proyecto
- Eventos de ciclo de vida de recursos: Creacion, modificacion y eliminacion de datasets, experimentos, modelos, despliegues, alertas y politicas de re-entrenamiento
- Eventos de despliegue: Creacion de despliegues, avance canary, rollback, promocion y decomisionamiento
- Eventos de seguridad: Creacion y revocacion de API keys, cambios de contrasena, cambios en la configuracion SSO, intentos de autorizacion fallidos
Cada registro de evento incluye la marca temporal, el usuario que inicio la accion (o la API key utilizada), la direccion IP de la solicitud, el recurso afectado y un objeto de detalles estructurado con informacion especifica del evento.
Cumplimiento GDPR
Para organizaciones sujetas al Reglamento General de Proteccion de Datos, CorePlexML proporciona herramientas para cumplir con los derechos clave definidos por la regulacion:
Derecho de acceso. Los usuarios pueden exportar todos los datos asociados a su cuenta, incluyendo datasets, metadata de modelos, logs de prediccion y eventos de auditoria. La exportacion se genera como un archivo estructurado que incluye tanto los datos como la metadata que describe su formato.
Derecho de supresion. Los usuarios pueden solicitar la eliminacion de su cuenta y todos los datos asociados. El proceso de eliminacion remueve los registros de usuario, datos de proyecto, artefactos de modelos y logs de prediccion. Las entradas del log de auditoria se anonimizan en lugar de eliminarse, preservando la pista de auditoria mientras se elimina la informacion de identificacion personal.
Derecho a la portabilidad de datos. Todas las exportaciones de datos utilizan formatos abiertos y estandar (CSV para datos tabulares, JSON para metadata, ONNX para artefactos de modelos donde se soporte) para asegurar la portabilidad a otras plataformas.
# Export all user data (GDPR data access request)
export = client.compliance.export_user_data(
user_id="user_abc123",
format="archive",
include_predictions=True,
include_audit_events=True
)
print(f"Export ID: {export.id}")
print(f"Status: {export.status}")
print(f"Estimated size: {export.estimated_size_mb} MB")
print(f"Download URL: {export.download_url}")
print(f"Expires: {export.expires_at}")Gestion de Sesiones
CorePlexML proporciona control granular sobre el ciclo de vida de las sesiones para soportar las politicas de seguridad empresariales:
# Configure session policies for an organization
client.auth.configure_session_policy(
organization_id="org_enterprise_01",
config={
"max_idle_minutes": 30,
"max_lifetime_hours": 8,
"max_concurrent_sessions": 3,
"enforce_single_device": False,
"require_re_auth_for_sensitive_ops": True,
"sensitive_operations": [
"deployment.create",
"api_key.create",
"project.delete",
"model.stage_transition"
]
}
)
# View active sessions for a user
sessions = client.auth.list_sessions(user_email="alice@company.com")
for session in sessions:
print(f"Session: {session.id}")
print(f" Created: {session.created_at}")
print(f" Last active: {session.last_active_at}")
print(f" IP: {session.ip_address}")
print(f" Device: {session.user_agent}")
print()
# Revoke a specific session
client.auth.revoke_session(session_id="sess_abc123")
# Revoke all sessions for a user (force logout everywhere)
client.auth.revoke_all_sessions(user_email="alice@company.com")El limite max_concurrent_sessions previene el uso compartido de credenciales al restringir el numero de sesiones activas que un unico usuario puede tener. Cuando se excede el limite, la sesion mas antigua se revoca automaticamente.
La configuracion require_re_auth_for_sensitive_ops obliga a los usuarios a re-autenticarse (ingresar su contrasena o completar SSO) antes de realizar operaciones de alto impacto. Esto protege contra el secuestro de sesion al asegurar que una cookie de sesion robada no pueda usarse para crear despliegues, generar API keys o eliminar proyectos sin re-verificar la identidad del usuario.
Mejores Practicas para Despliegues Empresariales
Impone SSO para todos los usuarios. Deshabilita la autenticacion basada en contrasena una vez que SSO este configurado. SSO proporciona gestion centralizada de credenciales, autenticacion multifactor a traves del IdP y desaprovisionamiento automatico cuando los empleados dejan la organizacion.
Aplica el principio de minimo privilegio. Asigna a los nuevos miembros del equipo el rol de viewer y escala a editor solo cuando necesiten acceso de escritura. La mayoria de los stakeholders que interactuan con la plataforma ML solo necesitan ver dashboards y resultados, no modificar recursos.
Rota las API keys regularmente. Establece fechas de expiracion en todas las API keys y define un calendario de rotacion. Una rotacion trimestral es un valor por defecto razonable para la mayoria de las organizaciones. Las keys de pipelines CI/CD deberian rotarse cada vez que cambien las configuraciones del pipeline.
Revisa los logs de auditoria periodicamente. Programa revisiones mensuales del log de auditoria, enfocandote en intentos de autenticacion fallidos, cambios de permisos y patrones inusuales como el uso de API keys desde direcciones IP inesperadas.
Delimita las API keys de forma estricta. Crea API keys separadas para diferentes sistemas y restringe cada key a los permisos minimos que necesita. Un pipeline de CI/CD que solo despliega modelos no deberia tener permiso para eliminar datasets. Un sistema de monitoreo que lee metricas no deberia tener permiso para crear despliegues.
Habilita RLS y verifica el aislamiento. Despues de configurar multi-tenancy, verifica que las politicas RLS estan funcionando correctamente intentando acceso entre proyectos con diferentes cuentas de usuario. Esta verificacion deberia ser parte de tus procedimientos regulares de pruebas de seguridad.
La seguridad empresarial para plataformas ML no es una unica funcionalidad sino una arquitectura por capas. Cada capa, desde RBAC hasta RLS pasando por el registro de auditoria, aborda una clase diferente de riesgo. En conjunto, proporcionan la defensa en profundidad que las organizaciones empresariales requieren para confiar en una plataforma ML con sus datos mas sensibles y sus predicciones mas criticas.
Para mas detalles sobre la arquitectura de seguridad y las certificaciones de cumplimiento de CorePlexML, visita la pagina de seguridad.