Seguridad y cumplimiento

Esta página es la referencia de los controles de seguridad de cuenta, control de acceso y cumplimiento de CORE-M. Para la autenticación a nivel de petición (JWT vs API key, headers, códigos de error) consulta Visión general de la API; para saber cómo se aíslan los tenants consulta Auth y multi-tenancy.

Autenticación multifactor

La MFA es configurable por tenant, usando TOTP más códigos de recuperación de un solo uso. Los factores se almacenan cifrados en el namespace sessions de Aerospike, set mfa, con clave {tenant_id}:{user_id}.

Acción	Comportamiento
Enrolar TOTP	El usuario confirma un código válido; el secreto cifrado se almacena; los códigos de recuperación se generan y se devuelven exactamente una vez; se escribe el audit mfa.enrolled
Login (MFA requerida)	La autenticación solo por contraseña no emite un token; la respuesta de login exige un challenge de MFA; el access token se emite únicamente tras un código TOTP válido
Usar un código de recuperación	El login tiene éxito, el código se invalida y se escribe el audit mfa.recovery_code.used

Precaución

Los códigos de recuperación y los valores de token en crudo se muestran una sola vez y nunca más. Captúralos en el momento de creación — la plataforma solo almacena hashes.

Política de contraseñas y sesiones

Los tenants configuran la fuerza de las contraseñas, la duración de la sesión y la rotación de refresh tokens; los usuarios pueden listar y revocar sus propias sesiones.

Control	Comportamiento
Política de contraseñas	Las contraseñas débiles se rechazan con INVALID_ARGUMENT; la respuesta lista las reglas no superadas sin reflejar la contraseña
Rotación de refresh	Cada refresh emite un nuevo par de tokens e invalida el refresh token anterior
Revocar una sesión	El refresh token de la sesión se invalida; su access token falla tras el retardo de propagación de revocación configurado; se escribe el audit session.revoked
Revocar todas las demás sesiones	Todas las sesiones excepto la actual se invalidan

API tokens con scope y cuentas de servicio

Los API tokens con scope y las cuentas de servicio son independientes de las keys de provisioning de dispositivos. Los tokens viven en el namespace sessions de Aerospike, set api_tokens, con clave {tenant_id}:{token_id}. El valor del token en crudo se devuelve exactamente una vez; solo se almacenan el hash, el prefix, los scopes y los timestamps.

Un token lleva:

Atributo	Significado
subject_type	user o service_account
scopes	El conjunto de permisos que otorga el token (tabla abajo)
expires_at	Timestamp de expiración
ip_allowlist	Restricción opcional de CIDR de origen
prefix	Prefix no secreto mostrado en los listados y el audit
created_at / last_used_at	Timestamps de ciclo de vida

Scopes

Scope	Otorga
devices:read	Leer el device registry
devices:write	Crear / actualizar / eliminar dispositivos
telemetry:ingest	Enviar telemetry
telemetry:read	Consultar telemetry y snapshots
rules:write	Gestionar reglas
rpc:execute	Emitir RPCs de servidor a dispositivo
exports:create	Crear jobs de export
anchoring:read	Leer lotes (batch) de anchor y pruebas

Escenario	Resultado
El token carece del scope para una llamada (p. ej. un token telemetry:read llama a CreateDevice)	PERMISSION_DENIED; el audit api_token.denied registra missing_scope="devices:write"
Rotar el token de una cuenta de servicio	Se crea un nuevo token; el anterior se programa para expirar tras overlap_seconds; ambos prefixes son visibles durante la ventana de solapamiento

Consejo

Otorga el conjunto de scopes más estrecho que necesite un token. Un worker de export que solo lee telemetry y crea exports debería tener exactamente telemetry:read y exports:create — nada más.

IP allowlists y controles de red

Las allowlists aplican tanto a nivel de tenant (UI, API, ingesta de protocolo) como a nivel de token individual.

Escenario	Resultado
Petición de token desde fuera de su CIDR allowlist	PERMISSION_DENIED; ningún handler downstream se ejecuta
Login desde una IP excluida por la allowlist de UI del tenant	Rechazado antes de la verificación de contraseña; se escribe el audit login.denied_ip

Audit log

Cada acción de seguridad, administración, gobierno de datos, ejecución de comandos, despliegue de reglas, perfil, dashboard y política de anchoring escribe un evento de audit inmutable. Los eventos se almacenan en el namespace sessions de Aerospike, set audit, con clave {tenant_id}:{event_id}, y pueden copiarse a almacenamiento de largo plazo.

Campos

Campo	Significado
event_id	ID único del evento
tenant_id	Tenant propietario
actor_type / actor_id	Quién actuó (usuario o cuenta de servicio)
action	Qué ocurrió, p. ej. device.deleted, retention.policy.updated
target_type / target_id	El recurso afectado
result / reason	Resultado y, cuando se deniega, por qué
source_ip / user_agent	Origen de la petición
trace_id	Correlaciona con la traza distribuida
created_at	Timestamp del evento
before_hash / after_hash	Hashes de integridad alrededor del cambio
redacted_details_json	Payload de detalle con los secretos removidos

Búsqueda y export

Capacidad	Comportamiento
Búsqueda	Filtra por rango de tiempo, actor y action; los resultados se paginan y ordenan de forma descendente por created_at
Redacción	Los valores sensibles nunca se registran — una rotación de token solo registra token_id, prefix, scopes y la expiración, nunca el token en crudo
Export	Los eventos de audit pueden exportarse con un manifiesto (consulta Jobs de export)

Export de cumplimiento y eliminación de datos

CORE-M admite flujos de derechos del titular de los datos con salvaguardas explícitas para las pruebas inmutables.

Flujo	Comportamiento
Export de datos del usuario	El bundle contiene el perfil del usuario, sus sesiones, los eventos de audit que lo involucran, las preferencias de dashboard y las preferencias de notificación; la URL de descarga tiene un expires_at
Eliminación de datos (dispositivo con pruebas finales)	La telemetry operacional en crudo se elimina o redacta según la política; los registros de prueba permanecen; las respuestas de verificación indican que los datos en crudo no se retienen; el audit compliance.delete.completed registra el número de pruebas preservadas

Precaución

Una solicitud de eliminación que removería una prueba final en blockchain se rechaza. La prueba es el registro inmutable de existencia histórica; solo el payload operacional en crudo puede redactarse o eliminarse. Consulta Consulta y retención de telemetry para las reglas de preservación de pruebas y Verificación para lo que ve un verificador después.

Secretos y custodia

Los controles de custodia cubren los secretos que configuras: client secrets de SSO, credenciales de protocolo, secretos de conectores y secretos de proveedores de notificación.

Secreto	Comportamiento de custodia
Secreto de conector (p. ej. bearer token de webhook)	Almacenado en el backend de secretos configurado; la configuración de la rule-chain conserva solo una referencia; las respuestas de la API nunca devuelven el valor
Credencial de protocolo / SSO	Almacenada hasheada o como referencia de backend; los valores en crudo nunca los devuelve la API

La plataforma prefiere referencias respaldadas por KMS frente al material de clave en crudo allí donde haya un backend de secretos disponible.