La Seguridad se Encuentra con la Usabilidad: Creando Soluciones de Control de Acceso Dinámicas y Granulares

Hola a todos. Soy Samhita. Soy una ingeniera full-stack en BlackRock. Y aquí hay algo sobre mí. Ahora, si estuviéramos haciendo esta sesión en persona, habríamos jugado un rápido juego para romper el hielo. Habría presumido de mis habilidades para hacer press de banca y les habría mostrado muchos memes. Pero desafortunadamente, no pude unirme a ustedes en Ámsterdam este año. Así que tendremos que omitir todo esto y sumergirnos de lleno. Comencemos.

Imagina que estás construyendo control de acceso en tu aplicación web. Entonces, la primera pregunta que probablemente te harías es, ¿qué estrategias debería usar para asegurarme de que los datos sensibles sean accedidos solo por aquellos que realmente lo necesitan? Entonces podrías empezar a pensar. ¿Debería implementarlo a nivel de componente o en la capa de API? ¿O es seguro que el back end lo maneje todo? Entonces podrías considerar otra capa de complejidad. ¿Cómo integro todos estos permisos con verificaciones de lógica de negocio y banderas de características para que ciertas características estén disponibles solo para usuarios específicos?

Para ahora, espero que entiendas que el control de acceso no es una sola decisión y tendrías que pensar en múltiples capas en tu arquitectura para hacerlo bien. Así que, en la sesión de hoy, repasaremos todo esto y exploraremos dos formas de implementar control de acceso que sea granular, dinámico y escalable. ¿Por qué deberías preocuparte por esto? OASP ha listado el control de acceso roto como el riesgo de seguridad número uno en aplicaciones web. También recomiendan el control de acceso basado en atributos sobre el tradicional control de acceso basado en roles que otorga acceso a los usuarios solo basado en los roles del usuario.

¿Por qué? Porque el control de acceso basado en atributos es más efectivo para implementar el principio de privilegio mínimo, y también maneja necesidades de acceso dinámicas. Veamos cómo. Considera a Sam, quien es una publicadora para una aplicación de blogs. Cuando se unió, se le asignaron categorías dentro de las cuales puede realizar acciones. La regla de control de acceso es que los publicadores pueden publicar publicaciones aprobadas en sus categorías asignadas pero solo durante el horario laboral. Cada vez que se crea una publicación de blog, se le asigna una categoría. Inicialmente no está revisada, pero eventualmente es aprobada por el editor. Ahora, si Sam quiere publicar esta publicación, el acceso se otorga no solo basado en su rol, que es el caso con el control de acceso basado en roles, sino también basado en sus atributos, los atributos del recurso, que es la publicación, y atributos ambientales como el tiempo y la ubicación. Estos tres, junto con las políticas de control de acceso en sí mismas, son los cuatro componentes principales que conforman ABAC. Si alguno de sus atributos cambia, como si se traslada al departamento de membresía o se le asigna a moda, su acceso se revoca automáticamente. Y debido a que todos estos atributos se incorporan en el proceso de toma de decisiones, la seguridad de tu aplicación es mucho más robusta.

¿Dónde deberías aplicarlo? Deberías aplicar el control de acceso en el front-end para que los usuarios tengan retroalimentación instantánea. Saben inmediatamente lo que pueden o no pueden hacer, y esto hace que la interfaz de usuario sea muy intuitiva. Este es un ejemplo crudo de cómo podría verse. Aparte del hecho de que es un FL-stangle y la solución no es escalable, el problema aquí es que el control de acceso en el front-end es solo la primera línea de defensa. Es como colgar un cartel de no entrar en tu puerta y no cerrarla con llave. Así que es muy crucial que también apliques el control de acceso en el back-end porque el control de acceso en el front-end puede ser fácilmente eludido con las herramientas adecuadas. Así que podrías replicar las mismas reglas en el back-end. Eso es mucha duplicación y es difícil asegurar la consistencia de políticas a través de ambas capas, por lo que aunque la aplicación de políticas necesita ocurrir tanto en el front-end como en el back-end, la definición de las reglas o tus permisos mismos necesitan estar en el back-end como una única fuente de verdad. Así que podrías descargar toda tu lógica de control de acceso al back-end y hacer que el front-end haga una llamada API al back-end y obtenga la decisión de control de acceso.

Esta solución es segura, pero introduce compensaciones en términos de usabilidad y rendimiento, especialmente en ABAC porque vimos cómo depende de factores dinámicos como usuario, recurso y atributos ambientales. Y cada vez que estos atributos cambian, tu interfaz de usuario necesita activar una llamada API al back-end para obtener la decisión de control de acceso actualizada, lo que causa latencia y una experiencia de usuario lenta. Y sin mencionar, si hay actualizaciones de políticas o adiciones de políticas, tu código necesita ser reescrito. Además, ¿cómo manejarías las banderas de características como usuarios premium o recursos exclusivos? ¿Y qué pasa cuando hay múltiples front-ends y múltiples servicios de back-end? ¿Cómo asegurarías la consistencia de la definición de políticas a través de estas capas? Y más importante, ¿cómo creas una solución escalable que satisfaga todos los criterios de diseño que discutimos hasta ahora? Como dije al principio, repasaremos dos soluciones. La primera es CASL. Es una biblioteca de JavaScript de código abierto que te permite definir permisos de manera declarativa como lo que el usuario puede o no puede hacer en lugar de preocuparse por cómo verificar los permisos. Considera estos ejemplos de nuestra aplicación de blogs. Un administrador puede gestionar todo. Un autor puede crear y editar sus propias publicaciones dentro de las categorías asignadas, pero no puede eliminar publicaciones publicadas. Estos se llaman habilidades en CASL.

Vamos a convertir esto en código. Comencemos definiendo una función llamada defineAbilityFor, que toma al usuario como entrada y devuelve las habilidades del usuario. Si el usuario es un admin, el usuario puede manage all. Manage y all son palabras clave en CASL donde manage significa cualquier acción y all significa cualquier sujeto. Si el usuario es un author, el usuario puede crear un post pero no puede eliminar un post. También puedes verificar el tipo de estas habilidades definiendo un tipo para las acciones y sujetos y creando un objeto de habilidad que se ajuste a los tipos definidos.

Nota aquí que createMongoAbility no significa que tu aplicación tenga que usar MongoDB. Solo significa que usaremos ciertos operadores del lenguaje de consulta de MongoDB. Uno de esos operadores es el operador in, que se usa para especificar condiciones en estas habilidades. Por ejemplo, el usuario puede crear un post en tech y lifestyle o el usuario puede actualizar solo los campos de título y descripción de sus propios posts que están en estado de borrador. Si el objeto de descripción está anidado, puedes usar un comodín para indicar que solo quieres otorgar acceso a los campos de nivel superior. Finalmente, puedes usar cannot para describir lo que el usuario no puede hacer, como eliminar posts publicados.

Detrás de escena en Kazzle, estas reglas can se combinan usando or lógico y reglas invertidas, como cannot y todas las condiciones se van a combinar usando and lógico, que son los cuadros rosados que ves. Bien, así que recuerda esto, tenemos la función definability for que devuelve todas las habilidades para el usuario. Debido a que la definición de permisos necesita ser una única fuente de verdad, esto va a ser una biblioteca compartida entre la UI y el servidor. Una vez que el usuario está autenticado, invocarías esta función definability for y obtendrías las habilidades del usuario. Para validar una acción en el lado del servidor, harías ability.can y pasarías la acción y el sujeto. La misma función ability.can se puede usar en el front-end para realizar verificaciones programáticas y devuelve un booleano true o false.

Mejor aún, crea un contexto y pasa la instancia de ability a la aplicación para que todos los componentes en la app tengan acceso a ella. Bazel también proporciona una opción para crear un componente contextual can, que es como un componente envoltorio alrededor de otros componentes que puedes usar para renderizado condicional.

¿Puedo eliminar un post? ¿Ves lo legible que es la verificación de permisos? Significa que estás preguntando si tienes el permiso para eliminar al menos un post. Pero por otro lado, si preguntas, ¿puedo eliminar este post?, significa que estás preguntando si tienes el permiso para eliminar esa instancia particular del post porque post aquí es el tipo del sujeto.

Puede ser un poco confuso, lo que me lleva a mi siguiente punto. ¿Deberías estar usando una biblioteca de terceros? Aunque ofrecen mucha conveniencia, hay algunas preocupaciones sobre su uso en aplicaciones empresariales especialmente para el control de acceso y especialmente en aplicaciones que manejan datos sensibles. Porque los documentos podrían ser poco claros, desactualizados o inexactos. Pero lo más importante, puede haber vulnerabilidades en la propia biblioteca.

¿Cómo escribimos las políticas de manera que puedan ser utilizadas tanto por la UI como por el servidor? ¿O que puedan ser utilizadas por múltiples UIs y múltiples servidores? Otro punto, sé que la mayoría de ustedes pueden ser desarrolladores de JavaScript, pero ¿qué pasa si la pila tecnológica del backend no está basada en JavaScript en absoluto? Entonces, para resolver eso, utilizaremos policy as code, lo que significa que estás usando código o archivos de configuración como JSON o YAML para definir y gestionar las políticas. El beneficio de hacer esto es que las políticas estarán bajo control de versiones, y también es más fácil de escalar.

Así es como podría verse en YAML. Tenemos dos políticas aquí. Esta es la primera y la segunda. Y cada política tiene una condición.

Si la condición se evalúa como verdadera, significa que tu política está en efecto. El campo de efecto determina si la acción sobre el recurso dado está permitida o denegada. Y las condiciones en sí mismas se escribirán usando el lenguaje de expresión común de Google que supuestamente es muy rápido y seguro. Así que mejoremos la estructura de estas políticas.

Y aun con el crecimiento de las políticas, el tiempo de búsqueda va a permanecer constante. Bien. Ahora que tenemos las políticas en su lugar, ¿cómo evaluamos las condiciones? Hay evaluadores CEL disponibles para diferentes lenguajes.

Pero para el front-end, usaremos el evaluador cell javascript, que toma la condición y todos los objetos correspondientes como usuario, recurso y entorno. Y va a producir un Booleano verdadero o falso. El validador reside dentro de la aplicación web y obtiene los atributos de recurso y entorno del componente que lo invoca. Este.

Bien. Recuerda, también necesitamos atributos de usuario y políticas. Una vez que el usuario está autenticado, los detalles del usuario como el rol y el departamento se van a almacenar en el estado global y serán leídos por el evaluador. Las políticas pueden ser obtenidas de un servicio de gestión de políticas.

Sabes, para evitar solicitudes de red innecesarias. Y si estás usando RTK o Tanstack Query para esto, las políticas se van a almacenar automáticamente en caché en el store. Vamos a leer desde el store para los propósitos de este ejemplo, pero por favor ten mucho cuidado al almacenar datos sensibles de usuario y políticas en el store.

Bien. Más a menudo de lo que piensas, incluso si tienes el permiso requerido para realizar una acción, aún puede que no se te permita hacerlo debido a la lógica de negocio contextual. Y esta lógica de negocio puede depender del estado de la aplicación y puede necesitar ser manejada dinámicamente.

Ejemplos serían prevenir la aprobación de una publicación si está siendo editada actualmente, deshabilitar el botón de comentario si no hay contenido escrito en el cuadro de comentarios, y prevenir la creación de una categoría de publicación si el nombre ya existe. Bien. Así que si una regla de acción contextual está presente, va a ser evaluada junto con el validador de políticas contextuales. Encapsula toda esta lógica de validación dentro de un hook de uso de permisos para que pueda ser usado por cualquier componente que necesite verificar permisos. Con el cambio de estado de la aplicación y los atributos cambiantes, el hook volvería a calcular la salida de validación y desencadenaría un re-renderizado en todos los componentes que lo usan. A un alto nivel, así es como se ve el código simplificado para eso. Aquí es donde estoy obteniendo las políticas condicionalmente después de que un ID de usuario válido está presente. Y luego aquí está la lógica de validación para la evaluación de cell JSC y la validación de acción contextual. Pero hay una cosa en este código que necesita ser reescrita. Ves cómo aquí estoy usando el hook de uso de selector para suscribirme a todo el estado de la aplicación. Lo que significa que cualquier cambio de estado va a desencadenar un re-renderizado en todos los componentes que usan el hook de uso de permisos.

Lo cual es por qué eso es una mala práctica y se supone que debes usar tu hook de use selector para suscribirte solo a lo necesario. Hazlo lo más granular posible.

Bien. Pasando a la última parte, vimos la definición de permisos usando la solución personalizada. Ahora veamos cómo hacer cumplir estos permisos. Puedes crear un componente wrapper can inspirado en CASL para ocultar o mostrar un componente en este caso. Para deshabilitar un componente y luego crear una ruta protegida. Si el usuario tiene permisos, mostrarías el outlet. Si no, navega a la página de inicio de sesión. Y finalmente, para omitir una llamada API si el usuario no tiene permisos.

Eso fue todo por hoy. Eso concluye nuestra sesión. Pero antes de dejarte ir, resumamos. Aprendimos dos formas de hacer cumplir un control de acceso basado en atributos de grano fino. La primera usando CASL y la segunda usando una solución personalizada. Ambas soluciones son escalables en el sentido de que agregar una nueva política significa actualizar un solo archivo sin reescrituras de código. Son dinámicas porque funcionan sin problemas con el estado cambiante de la aplicación. Son legibles como, ¿puedo leer una publicación? ¿Puedo eliminar una publicación? Y finalmente, son limpias porque hay una separación de preocupaciones. Espero que recuerdes todo de esta sesión. Pero porque fue mucho y si tuvieras que recordar solo una cosa, sería considerar usar el control de acceso basado en atributos recomendado por OWASP porque es más efectivo en implementar el principio de privilegio mínimo.