Source: Deutsche Nachrichten
Un acceso que nadie le dio por error
Conviene empezar por distinguir este problema de uno parecido, con el que suele confundirse. El access creep —la acumulación de permisos que una persona va juntando a lo largo de los años, a medida que cambia de puesto, de proyecto o de jefe, sin que nadie le revoque los accesos anteriores— es un problema de historia: de permisos que quedaron pegados a un legajo después de que la función que los justificaba ya no existe. Lo que este artículo plantea es distinto y, en cierto sentido, más incómodo: qué pasa cuando el acceso nunca fue un resabio de nada. Cuando, desde el primer día, una persona en un puesto legítimo, con una función real y evaluada, tiene autorización para entrar a información que su tarea concreta no necesita, porque así fue diseñado el sistema desde el principio.
No es un empleado con malas intenciones que un mal proceso de verificación no detectó. Es, muchas veces, exactamente el empleado correcto —el que fue evaluado, contratado y capacitado como corresponde— operando dentro de un sistema que le dio, por diseño organizacional, más alcance del que su rol específico requiere. El riesgo, en este caso, no está en la persona: está en la arquitectura del acceso.
El caso que ilustra el problema, aunque haya ocurrido en otro país
En julio de 2011, el sistema de salud de la Universidad de California en Los Ángeles (UCLA Health System) acordó pagar 865.500 dólares a la Oficina de Derechos Civiles del Departamento de Salud de Estados Unidos (HHS/OCR) para resolver una investigación por violaciones a la ley federal de privacidad médica (HIPAA). La investigación, según documentó el propio organismo regulador, había constatado que empleados de los tres hospitales de UCLA involucrados accedieron, de manera reiterada y sin ninguna razón laboral que lo justificara, a información médica protegida de pacientes —entre ellos, figuras públicas cuya identidad generó curiosidad interna— entre 2005 y 2009. Trece trabajadores fueron despedidos, según reportó la prensa especializada en la cobertura del caso. El acuerdo incluyó, además de la sanción económica, la obligación de implementar un nuevo sistema de monitoreo de accesos, capacitar al personal, revisar las políticas internas y reportar avances a la autoridad regulatoria durante tres años.
Vale la aclaración que corresponde hacer siempre que se cita un antecedente extranjero: es un caso estadounidense, regido por una ley —HIPAA— que no rige en Argentina, y no existe evidencia de que algo equivalente haya ocurrido, con esa escala o esa resolución pública, en un caso argentino verificable. Se lo trae acá no como precedente jurídico aplicable, sino porque documenta con extraordinaria claridad la lógica de fondo que interesa a este artículo: el personal que accedió a esas historias clínicas no lo hizo explotando una falla de seguridad externa ni vulnerando ninguna contraseña ajena. Tenía, como parte de su función general dentro del hospital, acceso al sistema de historias clínicas. Lo que no tenía era ninguna razón funcional para abrir, específicamente, el registro de un paciente que no estaba bajo su cuidado. El sistema se lo permitía igual.
Qué exige la ley argentina sobre esto, con precisión
La Ley de Protección de Datos Personales N° 25.326 ofrece, en dos de sus artículos, un fundamento directo para pensar este problema en clave local. El artículo 4° establece que los datos personales deben ser “ciertos, adecuados, pertinentes y no excesivos en relación al ámbito y finalidad para los que se hubieren obtenido”, y que no pueden ser utilizados para finalidades distintas o incompatibles con aquellas que motivaron su obtención. El artículo 7°, por su parte, refuerza esa lógica de manera todavía más estricta para los datos sensibles —entre ellos, los datos de salud—, cuyo tratamiento la ley limita a razones de interés general autorizadas por ley. Ninguno de los dos artículos usa la expresión “need-to-know”, pero ambos consagran, en sustancia, el mismo principio: que la pertinencia de un dato se mide en relación con una finalidad concreta, no con el hecho de que el sistema técnicamente lo permita.
La Agencia de Acceso a la Información Pública (AAIP), autoridad de aplicación de esa ley, publicó en 2018 la Resolución 47/2018, una guía de buenas prácticas de seguridad de la información —recomendada, no una norma que cree obligaciones nuevas por sí sola— que desarrolla ese principio en términos operativos. En su apartado sobre control de acceso, la guía recomienda implementar mecanismos de autenticación y segregación de roles y funciones, y diseñar los procedimientos de manera que los usuarios solo accedan a los datos necesarios para el ejercicio de sus funciones. Es, en la práctica, una descripción bastante cercana al principio de need-to-know, aunque el texto no use ese término en inglés: la obligación legal de fondo —cuidar, restringir y justificar el acceso a datos personales, especialmente los sensibles— surge del artículo 9° de la Ley 25.326, y la Resolución 47/2018 es la guía que orienta cómo implementarla, no la que la crea.
A nivel de estándares voluntarios, la norma ISO/IEC 27002 —guía de controles de seguridad de la información ampliamente adoptada, aunque de aplicación no obligatoria salvo pacto contractual o certificación voluntaria— incluye un control específico de restricción de acceso a la información, orientado a que el acceso a sistemas y datos se limite según la necesidad funcional de cada usuario y no según la disponibilidad técnica del sistema. Es exactamente el mismo principio que subyace al caso de UCLA: no importa si el sistema permite el acceso: importa si la función lo requiere.
Por qué esto no es un problema de vigilar más a la gente
Es importante marcar, con la misma claridad con la que se plantea el problema, lo que este artículo no propone. No se trata de sospechar de cada empleado que tiene acceso amplio a un sistema, ni de asumir que cualquier permiso no utilizado en el día a día es indicio de mala fe. La inmensa mayoría de los accesos amplios que existen en cualquier organización son, simplemente, el resultado de una decisión de diseño que privilegió la simplicidad operativa por sobre la segmentación fina: es más fácil, al configurar un sistema, darle a un área entera el mismo nivel de acceso que distinguir, permiso por permiso, qué necesita cada rol específico dentro de esa área. Esa decisión no es, en sí misma, una falla de seguridad: es una elección, muchas veces razonable en el momento en que se tomó, que con el tiempo puede dejar de estarlo a medida que crece el volumen de información sensible que ese sistema administra.
Tampoco es un problema que se resuelva “investigando más” a las personas que ya tienen ese acceso. “Es gente de confianza, hace años que trabaja acá”, “nunca tuvimos un problema con eso”, son razonamientos legítimos sobre la conducta pasada de las personas, y al mismo tiempo, irrelevantes para la pregunta de diseño que este artículo plantea: la cuestión no es si esas personas son confiables, sino si la arquitectura del sistema depende, para su seguridad, de que lo sean. Un diseño de acceso bien construido no necesita apostar a la buena voluntad de nadie, porque limita, desde el sistema mismo, lo que cada función puede ver.
Human Risk Management como diseño, no como sospecha
Human Risk Management, entendido como la gestión estructurada del riesgo asociado a personas, funciones, accesos y decisiones —y no como vigilancia permanente ni como la idea de que todo empleado con acceso amplio representa una amenaza—, ofrece acá un criterio de trabajo relativamente simple de enunciar y, al mismo tiempo, exigente de implementar: cada acceso a información sensible debería poder justificarse por una función concreta, y no simplemente por la pertenencia a un área, una jerarquía o una antigüedad determinada. Validato, compañía especializada en Background Screening y Human Risk Management con operación en Argentina, describe sus procesos de verificación como estructurados en función del rol, el acceso y el nivel de exposición de cada posición; ese mismo criterio —diseñar el acceso a partir de la función, no de la conveniencia operativa— es aplicable, en términos generales, a cualquier organización que administre información sensible de personas, sin que esto implique que la compañía audite o rediseñe los sistemas de acceso de ninguna organización en particular.
La pregunta que el caso de UCLA deja para cualquier organización
El caso de UCLA no trata sobre empleados que hackearon un sistema ni sobre un fallo técnico de ciberseguridad en sentido estricto. Trata sobre personas con acceso legítimo, otorgado de manera regular, que lo usaron para ver algo que su función no requería que vieran, simplemente porque el sistema no distinguía entre lo que necesitaban y lo que podían alcanzar. Para RR.HH., Seguridad, Legal y Compliance, la pregunta que ese antecedente deja no es si conviene confiar menos en el personal, sino si alguien, dentro de la organización, puede explicar hoy, función por función, por qué cada persona tiene acceso a lo que tiene, y no simplemente a todo lo que el sistema le permitiría alcanzar.
Fuentes y marco normativo consultado
– U.S. Department of Health and Human Services, Office for Civil Rights, acuerdo de resolución con UCLA Health System (8 de julio de 2011), 865.500 USD, violaciones HIPAA por accesos no autorizados a historias clínicas entre 2005 y 2009
– HIPAA Journal, cobertura del caso UCLA Health System, detalles del acuerdo, medidas correctivas y despidos de personal
– Ley 25.326, art. 4° (calidad de los datos: pertinencia y no exceso respecto de la finalidad) y art. 7° (datos sensibles, limitación a razones de interés general autorizadas por ley)
– Ley 25.326, art. 9° (deber de seguridad y confidencialidad de los datos personales)
– Agencia de Acceso a la Información Pública (AAIP), Resolución 47/2018, guía de buenas prácticas de seguridad de la información, apartado de control de acceso (autenticación, segregación de roles y funciones, acceso limitado a la necesidad funcional)
– ISO/IEC 27002, control de restricción de acceso a la información (estándar voluntario)
– Validato, descripción de servicios de Background Screening y Human Risk Management estructurados por rol en Argentina: https://validato.ch/ar-en/human-risk