Aislamiento de datos

El aislamiento se mira en tres lugares. En los datos: dónde se guarda cada evento y con qué etiqueta. En los accesos: quién puede consultar a quién, y que el sistema lo niegue y no que solo lo prohíba un procedimiento. Y en el contenido: una regla compartida debe filtrar por cliente, para que su resultado no mezcle clientes. Basta que falle uno para que el cliente deje de estar aislado, por mucho que los otros dos estén bien. Abre roles y mira qué puede ver cada uno.

Un control de acceso se prueba mirando lo que dejó pasar, no lo que bloqueó. Una consulta denegada demuestra que el control funciona. Una permitida a un cliente que el analista no tiene asignado demuestra que no. Abre accesos y compara cliente_consultado con clientes_asignados en las filas con resultado PERMITIDO.

Cada evento llega con una etiqueta que dice a qué cliente pertenece, y debe terminar en el espacio de ese cliente. Si termina en otro, ese cliente tiene registros ajenos en sus datos y el dueño del evento no los tiene donde los espera. La causa suele ser una regla de enrutamiento mal escrita. Abre ingesta y compara la etiqueta con el espacio destino de cada fuente.

Al informar un cruce de datos hay que decir cuánto fue, no solo que ocurrió. La cifra permite al cliente evaluar el alcance y a ti decidir qué revisar. En ingesta, eventos_por_hora indica el ritmo de cada fuente. Suma el de las fuentes cuya etiqueta no corresponde al espacio donde terminan.

Un cruce de datos entre clientes no es un detalle técnico que se corrige sin decir nada: es algo que los clientes afectados tienen derecho a conocer según su contrato. Primero se detiene la causa, para que no siga ocurriendo; después se mide el alcance con los registros; y se informa a los clientes afectados por el canal que el contrato fija. Corregir sin avisar deja al cliente sin saber que sus datos estuvieron donde no debían.