La autenticación y la autorización se encuentran entre las principales prioridades de los desarrolladores de aplicaciones en la actualidad. Si bien a menudo se usan indistintamente, en realidad representan dos cosas muy diferentes. Sin embargo, para garantizar una experiencia segura y fluida para los usuarios, ambos deben trabajar en conjunto.
Para ilustrar la distinción entre autenticación y autorización, suelo utilizar el ejemplo de llevar a la familia a Disneylandia. La autenticación es como la puerta de entrada donde, al llegar, muestra su boleto e identificación al portero, quien verifica que usted es quien dice ser, muy parecido a cuando inicia sesión en una aplicación en la que el sistema de autenticación verifica su nombre de usuario y contraseña para validar su identidad.
La autorización es lo que sucede una vez que pasa la puerta principal. Es posible que su boleto tenga un “Pase rápido” que le permita saltarse las filas de espera, o que sus hijos tengan boletos diferentes destinados solo para ciertos viajes. Estas medidas de autorización (o control de acceso) rigen «lo que usted puede hacer» después de estar autenticado. En un contexto organizacional, esto es similar a tener los permisos adecuados para acceder a ciertos archivos o programas.
Por supuesto, gestionar la autorización para una aplicación empresarial es mucho más complejo y matizado que el ejemplo compartido anteriormente. Quizás necesite otorgar acceso a un recurso de forma temporal y solo a un subgrupo selecto de usuarios. O tal vez haya ciertos recursos que sólo deberían estar disponibles para personas bajo condiciones específicas, como ser parte de un equipo de proyecto o trabajar en un departamento en particular.
RBAC y ABAC
Es por eso que en las últimas dos décadas hemos visto la introducción y adopción de varios modelos diferentes de control de acceso. Los modelos de autorización de primera generación, como los controles de acceso obligatorios, priorizaron un enfoque único para todos sobre los controles de acceso detallados. Sin embargo, en la empresa moderna, donde es posible que sea necesario otorgar o revocar derechos de acceso a ciertas aplicaciones, sistemas o recursos a diario, se hizo evidente que se necesitaban soluciones más dinámicas. Esto llevó al desarrollo de modelos de autorización más modernos, como control de acceso basado en roles (RBAC) y, posteriormente, control de acceso basado en atributos (ABAC).
RBAC simplificó la gestión de acceso asignando permisos a roles en lugar de a usuarios individuales. En un entorno corporativo, roles como «gerente», «contador» o «técnico de TI» vienen con derechos de acceso predefinidos, lo que agiliza el proceso de otorgar o revocar acceso a medida que los empleados asumen diferentes roles o responsabilidades. ABAC fue un paso más allá al incorporar una gama más amplia de atributos (como la ubicación del usuario, la hora de acceso y el tipo de dispositivo utilizado) en la administración de las decisiones de acceso.
Sin embargo, si bien ABAC ofrece un alto grado de granularidad y flexibilidad, también es engorroso de administrar, ya que requiere la definición y el mantenimiento continuo de numerosos atributos y políticas en constante cambio. Esta complejidad, a su vez, ha generado una variedad de desafíos administrativos, especialmente en entornos de gran escala donde la gran cantidad de atributos y reglas, y las relaciones entre ellos, pueden convertirse rápidamente en una carga abrumadora.
ReBAC ingresa al chat
Control de acceso basado en relaciones, o ReBAC, ofrece una opción más flexible para que los desarrolladores de software agreguen autorización detallada a aplicaciones y recursos. Residencia en El marco de Zanzíbar de Google, ReBAC considera las relaciones entre entidades (como usuarios, recursos y grupos) para gobernar el acceso. Proporciona un enfoque de control de acceso más consciente del contexto en comparación con RBAC o ABAC, lo que lo hace particularmente adecuado para entornos complejos donde se priorizan las relaciones e interacciones para determinar a quién se le debe otorgar acceso y a quién no.
Por ejemplo, consideremos un hospital típico que cuenta con una amplia gama de personas y funciones, desde administradores hospitalarios, médicos y enfermeras hasta técnicos de laboratorio, guardias de seguridad y conserjes. Si bien a todas estas personas se les puede otorgar acceso a la puerta de entrada, eso no significa que todos posean los mismos derechos de autorización. Además, el hecho de que un médico tenga la autoridad para revisar los registros detallados de los pacientes no significa necesariamente que deba tener acceso a la información privilegiada de cada paciente, solo los que están bajo su cuidado mientras la institución les brinda atención.
Según un modelo ReBAC, cuando se asigna un médico a un paciente, se le concede acceso a los registros médicos de ese paciente. Este acceso se puede revocar dinámicamente cuando ese paciente ya no esté bajo el cuidado del médico. De manera similar, una enfermera en el mismo sistema podría tener diferentes derechos de acceso, limitados a los pacientes con los que está directamente involucrada. Esta agilidad garantiza que los profesionales de la salud tengan la información necesaria para brindar atención mientras mantienen una estricta privacidad del paciente que cumple con los requisitos reglamentarios.
ReBAC también permite una gestión más detallada y precisa de los permisos de los usuarios en comparación con los modelos tradicionales de control de acceso, lo que se logra centrándose en la naturaleza, el contexto y los atributos de las relaciones entre varias entidades (como usuarios, recursos y datos). Sin embargo, si bien ReBAC ofrece un camino prometedor a seguir, no está exento de desafíos.
Directrices de implementación del ReBAC
Implementar y gestionar un sistema ReBAC puede ser una tarea compleja, especialmente en organizaciones grandes donde las relaciones e interdependencias son numerosas y están en constante evolución. Si planea implementar ReBAC, considere estas tres pautas.
Centrarse en la definición inicial.
Antes de sumergirse en el grupo de ReBAC, es esencial invertir tiempo desde el principio para obtener una comprensión completa de las diversas relaciones que existen dentro de su organización. Esto incluye trazar en detalle cómo se relacionan los usuarios entre sí, con los recursos y con la organización en su conjunto. Comprender y comunicar estas dinámicas es crucial para definir políticas efectivas de control de acceso. Establecer estas definiciones iniciales desempeñará un papel fundamental a la hora de determinar no sólo cómo se implementa inicialmente ReBAC sino también cómo podría evolucionar con el tiempo.
Empiece poco a poco para conseguir resultados rápidos
Antes de implementar ReBAC en toda una organización, es mejor comenzar con una pequeña implementación o programa piloto que permitirá probar el sistema en un entorno controlado. Por ejemplo, considere probar ReBAC inicialmente en el departamento de recursos humanos (RR.HH.), que normalmente tienen relaciones estables y bien definidas, como las que existen entre gerentes de RR.HH., empleados y datos confidenciales. En este contexto, ReBAC puede gestionar el acceso a información confidencial de los empleados, como datos personales, evaluaciones de desempeño y datos de nómina. Este enfoque ayuda a identificar problemas potenciales, afinar políticas y comprender las implicaciones prácticas del sistema sin abrumar al personal ni interrumpir procesos organizacionales importantes.
Desarrollar, probar y perfeccionar políticas
Como parte de una implementación a pequeña escala, es esencial garantizar que las políticas que se implementan se prueben y perfeccionen periódicamente en función de los comentarios de las partes interesadas, y que reflejen con precisión los controles de acceso deseados basados en las relaciones. Las políticas también deberían probarse utilizando diversos escenarios hipotéticos para evaluar su eficacia y viabilidad. Esto podría incluir escenarios como cambios de roles, transferencias de departamentos o cambios en los equipos del proyecto, asegurando que dichas políticas otorguen el acceso adecuado en cada escenario y que cualquier cambio en las relaciones resulte en una actualización inmediata de los derechos de acceso. También es importante reconocer que el desarrollo y prueba de políticas es un proceso iterativo y que a medida que la organización evoluciona y surgen nuevos tipos de relaciones, las políticas deberán revisarse y actualizarse para seguir siendo efectivas y relevantes.
No importa dónde se encuentre en su proceso de autenticación y autorización, es esencial mantenerse informado sobre la evolución de los modelos de seguridad como ReBAC, ya que ofrecen enfoques más matizados y adaptables para proteger sus recursos y datos en el panorama digital actual.
Rishi Bhargava es el cofundador de Descubriruna plataforma de gestión de identidad y autenticación de clientes del tipo arrastrar y soltar.
—
New Tech Forum ofrece un lugar para que los líderes tecnológicos, incluidos proveedores y otros contribuyentes externos, exploren y debatan la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva y se basa en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para su publicación y se reserva el derecho de editar todo el contenido aportado. Envia todo consultas a doug_dineley@foundryco.com.
Copyright © 2024 IDG Communications, Inc.
