Al comparar Qlik Sense con QlikView, las diferencias más obvias se encuentran en el front-end, con su diseño totalmente reacondicionado y completamente revisado. Otras diferencias importantes son el desarrollo basado en servidor, el uso de elementos maestros y el cambio hacia API, mashups, extensiones y widgets. Algo menos prominente, aunque muy merecedor de su atención, es el modelo de seguridad en Qlik Sense. Esto tiene un enfoque completamente nuevo en comparación con QlikView, y puedes crear variaciones infinitas. En lugar de hackear cosas juntas y esperar que funcionen, recientemente decidimos adoptar un enfoque más estructurado y hacer algo de I + D en las reglas de seguridad de Sense. Nuestro objetivo era obtener una mayor comprensión de la seguridad en Sense, desarrollar métodos para recopilar y modelar los requisitos de seguridad y diseñar patrones de referencia para escenarios de implementación comunes. Me gustaría compartir con ustedes algunas de las pequeñas cosas interesantes, extrañas y notables que encontramos. Estos van desde básicos hasta poco claros, pero todos deberían ayudarlo a obtener una mayor comprensión de las reglas de seguridad de Qlik Sense. Comencemos por señalar que el enfoque en Sense es totalmente diferente de lo que era en QlikView … El enfoque ABAC En Qlik Sense, la seguridad funciona a través del Control de acceso basado en atributos. Esto, en resumen, significa que un usuario obtiene acceso a cualquier parte del entorno mediante el uso de reglas de seguridad (políticas) que combinan atributos. Estas reglas pueden usar cualquier tipo de atributo: derivado del sistema o creado por el usuario (propiedades personalizadas). Estos atributos pueden pertenecer a cualquier recurso: usuarios, secuencias, aplicaciones, contenido de la aplicación, conexiones de datos y, de hecho, cada faceta de Sense QMC. Juntas, las reglas creadas se combinan en un total mayor de sentencias condicionales (IF, THEN) para formar el acceso de seguridad del usuario. Recursos Al crear reglas de seguridad, tenemos que definir el filtro de recursos. Esto responde a la pregunta: ¿a qué recurso (s) debemos otorgar derechos basados en la condición? Al poder establecer reglas sobre todos estos diversos recursos, podemos ser muy flexibles. Sin embargo, al tratar de crear y combinar reglas para crear roles, descubrimos que hay muchos más recursos para usar que el menú desplegable sugiere, ¡y algunos de ellos no se deben dejar de lado! Aquí hay una lista. QmcSection-resources Entre estos recursos, están los QmcSection * -resources. Lo que estos hacen, es claramente permitir que el usuario acceda a esas secciones particulares en el QMC. Cuando se permite en una sección, todavía tenemos que asignar derechos a los usuarios para crear / leer / actualizar / eliminar el contenido. Ahora, no nos queda claro por qué todavía podemos optar por aplicar estas reglas a Hub, QMC o a ambos, ya que, en el caso de QmcSection * -resources, obviamente solo se aplican al QMC. Toma nota de esto cuando construyas las reglas. Esto parece un comportamiento un tanto extraño, y el efecto en el centro de establecer una regla sobre tal recurso no es del todo claro para nosotros. El uso de, p. Aplicación * frente a App_ * Al elegir sus recursos, tenga en cuenta el uso de ‘*’ frente a ‘_ *’ como el filtro de recursos; una ligera diferencia, pero con gran impacto. La primera versión crea una regla en cada recurso desde la aplicación hacia abajo (app_objects, app_datasegments, etc.), esta última solo aplica para aplicaciones. Usar el primero otorgará acceso a todos los objetos subyacentes, data_segments, etc. El uso de este último dará como resultado aplicaciones visibles en el Hub, pero al abrir, no se mostrará contenido. De esta forma, podemos otorgar acceso a ciertos app_objects a ciertos usuarios, mientras que denegamos el acceso a esos datos a otros usuarios, si quisiéramos. Muy flexible de hecho, pero tenga en cuenta este uso. Atributos y propiedades personalizadas Los recursos tienen atributos estándar. Piense en un nombre, una identificación y tal vez un grupo para un usuario, derivado de la conexión del usuario. Además de estos atributos “estándar”, se pueden crear y asignar propiedades personalizadas para enriquecer aún más nuestros recursos. Por ejemplo, podemos crear la propiedad personalizada “@Department” y asignarla a una secuencia, un usuario, una conexión de datos, etc. Esta propiedad personalizada puede usarse en las reglas de seguridad para que podamos otorgar o denegar derechos basados en un departamento Este es un ejemplo, por supuesto, pero puede ver el uso de otras maneras. Reglas Como se señaló anteriormente, en Qlik Sense, la configuración de seguridad se realiza mediante la creación de reglas. Estas reglas usan estructuras condicionales (IF, THEN) para otorgar o denegar el acceso. Lo que es importante entender, es que en Qlik Sense, un usuario no tiene ningún derecho, a menos que asignarlos. Esto significa que tenemos que empezar de cero y que podemos ir en todas las direcciones que queramos, porque podemos usar todo tipo de atributos (de usuarios y otros recursos) para otorgar acceso a todo tipo de recursos. Como se mencionó, tanto los atributos heredados como las propiedades personalizadas recién creadas se pueden usar para crear las reglas. Superposición en las reglas Al construir reglas de seguridad, encontramos que las reglas pueden superponerse. Notará esto cuando elabore esas reglas usted mismo, pero algunas reglas entregadas de forma estándar pueden superponerse a sus reglas. Descubrimos esto estableciendo derechos de publicación para ciertos usuarios. El usuario tenía derecho a publicar aplicaciones, y pensamos que habíamos restringido las transmisiones de estos usuarios. Sin embargo, también se aplicó una regla que le daba acceso a todas las transmisiones (secuencias *). No es tan inteligente, por supuesto, pero esto podría suceder. Por lo tanto: ¡Usa la función de auditoría! Es genial. Realmente lo es La función de auditoría es muy útil cuando se crean roles usando reglas de seguridad. La funcionalidad de auditoría brinda una visión general por usuario y sus derechos por recurso de su elección.Al hacer clic en una letra que corresponde a un cierto derecho, aparece ‘Reglas asociadas’. Al hacer clic , se muestra una descripción general de todas las reglas aplicables a este usuario / recurso. De esta manera, la superposición (o lagunas) en las reglas se puede detectar fácilmente, y al hacer clic en la regla y “Ver”, podemos ir a la regla de seguridad y modificarla, o incluso deshabilitarla o eliminarla. Acceso a la sección Después de crear las reglas de seguridad, encontramos que también en el acceso a la sección, hay algunas diferencias en comparación con QlikView. No entramos en esto aquí, sino que encontramos las cosas más importantes sobre SA en Sense aquí. Ocultando el Hub Dev Una última cosa sobre otorgar o negar derechos a los usuarios. Si queremos evitar que los usuarios entren o usen el Dev Hub (denegar el acceso a esta sección), esto no parece posible. Es decir, Dev Hub no es un recurso sobre el que podamos aplicar las reglas. Espacio para adiciones … Entonces, como habrás notado, esta es solo una lista de cosas que encontramos ser notables. Si ha encontrado otros artículos, compártalos en un comentario a continuación. ¡Podríamos construir una base de conocimiento agradable y compacta aquí!