Gegevensbeveiliging beheren met Section Access

Section Access wordt gebruikt om de beveiliging van een applicatie te beheren. Het is eigenlijk een deel van het load-script voor gegevens waaraan u een beveiligingstabel toevoegt om te definiëren welke gebruiker wat te zien krijgt. Qlik Cloud gebruikt deze informatie om gegevens te beperken tot het betreffende bereik als de gebruiker de applicatie opent. Dat wil zeggen dat sommige gegevens in de app op basis van zijn of haar identiteit voor de gebruiker worden verborgen. Sectietoegang is nauw verbonden met de gegevens in de app en vertrouwt hierop bij het beheer van de toegang. Deze vorm van dynamische gegevensreductie kan gericht zijn op rijen of kolommen van een tabel of een combinatie van beide. Ga voor meer informatie naar Betrouwbaarheid en beveiliging bij Qlik.

Secties in het load-script

De toegang tot gegevens wordt beheerd door middel van één of meer beveiligingstabellen, die op dezelfde wijze worden geladen als de gegevens normaal worden geladen. Deze tabellen kunnen daardoor worden opgeslagen in een standaarddatabase of in een spreadsheet. De scriptinstructies voor de beveiligingstabellen worden opgegeven in de autorisatiesectie, die in het script wordt gestart met de instructie Section Access.

Als in het script een autorisatiesectie is gedefinieerd, moet het gedeelte van het script dat de app-gegevens laadt in een andere sectie worden geplaatst. Deze sectie wordt dan gestart met de instructie Section Application.

Voorbeeld:  

Nadat u het load-script hebt gewijzigd, moet u de gegevens laden zodat de wijzigingen van kracht worden.

Systeemvelden in Section Access

De toegangsniveaus worden toegewezen aan gebruikers in één of meer beveiligingstabellen die worden geladen in het gedeelte Section Access van het script. Deze tabellen moeten minimaal twee systeemvelden bevatten: ACCESS is het veld dat toegangsniveau en USERID of USER definieert.EMAIL. Optionele systeemvelden kunnen afhankelijk van de gebruikscase worden toegevoegd. De volledige set systeemvelden voor Section Access wordt hieronder beschreven.

ACCESS

Definieert de bevoegdheden van de corresponderende gebruiker.

Toegang tot Qlik Sense-apps kan worden verleend aan bepaalde gebruikers. In de beveiligingstabel kunnen aan gebruikers de toegangsniveaus ADMIN of USER worden toegewezen. Een gebruiker met ADMIN-bevoegdheden heeft toegang tot alle gegevens in de app, met uitzondering van de beveiligingstabel. Een gebruiker met USER-bevoegdheden heeft alleen toegang tot gegevens zoals gedefinieerd in de beveiligingstabel. Als er geen toegangsniveau wordt toegewezen, kan de gebruiker de app niet openen.

USERID

Bevat een tekenreeks die overeenkomt met een Qlik Cloud-gebruikersnaam. In Qlik Cloud worden de aanmeldgegevens opgehaald uit het IdP-onderwerp en vergeleken met de waarde in dit veld. Voor een alternatieve methode om de gebruikersidentiteit met behulp van een e-mailadres te verifiëren, raadpleegt u USER.EMAIL. In multicloudomgevingen kan het IdP-voorwerp worden toegewezen aan uw interne Windows-identiteit. Als u Qlik Account gebruikt, kan het onderwerp niet worden toegewezen aan een interne Windows-identiteit. Het IdP-onderwerp van een gebruiker kan worden bekeken in de sectie Gebruikers van de Beheerconsole.

Een jokerteken (*) wordt geïnterpreteerd als alle gebruikers en is onderhevig aan aanvullende voorwaarden die in de beveiligingstabel zijn opgegeven. In de onderstaande beveiligingstabel kunnen de tenantbeheerders in Qlik Sense alle getoonde REDUCTION-waarden bekijken.

NTNAME

Een veld moet een tekenreeks bevatten die overeenkomt met een gebruikersnaam of groepsnaam van een Windows NT-domein. Als er een ander verificatiesysteem wordt gebruikt, moet de naam van de geverifieerde gebruiker zijn opgenomen.

In Qlik Cloud worden de aanmeldgegevens opgehaald uit de subject-claim en vergeleken met de waarde in dit veld.

USER.EMAIL

Bevat een tekenreeks die overeenkomt met het e-mailadres van een gebruiker. In Qlik Cloud worden de aanmeldgegevens opgehaald uit de identiteitsprovider en vergeleken met de waarde in dit veld.

GROUP

Bevat een tekenreeks die overeenkomt met een groep in Qlik Cloud. In Qlik Cloud worden de aanmeldgegevens opgehaald uit de “groups”-claim van de identiteitsprovider en vergeleken met de waarde in dit veld.

OMIT

Bevat de naam van het veld dat moet worden weggelaten voor deze specifieke gebruiker. Er kunnen jokertekens worden gebruikt, maar het veld mag ook leeg zijn.

Gebruikerstoegang tot een app beheren

Een gebruiker met USERID AD_DOMAIN\C kan de app niet openen omdat de gebruikers-id niet is opgegeven in de beveiligingstabel.

Section Access, in zijn eenvoudigste vorm, kan worden gebruikt om specifieke gebruikers toegang tot de app te ontzeggen. Gebruikers worden toegang tot een app ontzegd door middel van uitsluiting. Met andere woorden: als een specifiek e-mailadres van een gebruiker niet in de beveiligingstabel is opgenomen, kunnen ze de app niet openen. De enige uitzondering op deze regel is als er een jokerteken (*) is toegewezen aan het veld USER.EMAIL in een van de rijen in de beveiligingstabel. In dit geval betekent een jokerteken dat alle geverifieerde gebruikers de app kunnen openen. Hier volgt een voorbeeld van een beveiligingstabel met een lijst met gebruikers-id's.

Een gebruiker met USER.EMAIL USER4@example.com kan de app niet openen omdat het e-mailadres van de gebruiker niet is opgegeven in de beveiligingstabel.

Gebruikerstoegang beheren voor specifieke gegevens in een app

Met dynamische gegevensreductie wordt de toegang beperkt tot de rijen en kolommen in de gegevenstabellen in Qlik Sense-apps totdat de gebruiker is geverifieerd om zelf de app te openen.

Toegang tot gegevens op rijniveau beheren

U kunt de toegang tot gegevens op rijniveau beperken door een kolom voor gegevensreductie aan de beveiligingstabel toe te voegen in de Access Section van het load-script. Specifieke records (rijen) kunnen worden verborgen door de gegevens in Section Access te koppelen aan de werkelijke gegevens: Welke gegevens moeten worden weergegeven of uitgesloten, wordt geregeld door een of meer reductievelden met dezelfde naam in de onderdelen Section Access of Section Application van het script. Nadat een gebruiker zich heeft aangemeld, kopieert Qlik Sense de selecties in reductievelden in Section Access naar de velden in Section Access met precies dezelfde veldnamen (de veldnamen moeten worden geschreven in hoofdletters). Nadat de selecties zijn gemaakt, worden alle gegevens die door deze selecties voor de gebruiker zijn uitgesloten, permanent verborgen in Qlik Sense. Als er een jokerteken (*) is gebruikt als een veldwaarde in de kolom voor gegevensreductie, krijgt de gebruiker toegang tot toegangsrecords die zijn gekoppeld aan alle geselecteerde reductievelden in de beveiligingstabel.

Als Qlik Sense het reductieveld in Section Access vergelijkt met velden in het gegevensmodel, worden de volgende gedragingen verwacht:

• Als een veldwaarde in het gegevensmodel overeenkomt met het reductieveld in Section Access, wordt de app geopend met gegevens die aan de match voor de opgegeven gebruiker zijn gekoppeld. Overige gegevens worden verborgen.

• Als de waarde van het reductieveld niet overeenkomt met enige van de waarden in het gegevens model, wordt de app niet geopend voor een normale GEBRUIKER. Niet-gereduceerd wordt echter wel geopend voor een gebruiker gemarkeerd als ADMIN.

Het gebruik van verschillende reductievelden in Section Access wordt niet aanbevolen, omdat het andere toegangscombinaties toestaat dan de beoogde combinaties.

Voorbeeld: Gegevensreductie op rijniveau op basis van de identiteit van de gebruiker

In dit voorbeeld komt het veld REDUCTION (hoofdletters) nu in zowel Section Access als Section Application voor (alle veldwaarden zijn ook in hoofdletters). De twee velden zouden normaal gesproken verschillend en gescheiden zijn, maar bij gebruik van Section Access worden deze velden gekoppeld en het aantal records dat de gebruiker te zien krijgt beperkt.

Het resultaat is:

• Gebruiker USER1@EXAMPLE.COM ziet alle velden en alleen de records die andere gebruikers in dit voorbeeld kunnen zien als REDUCTION = 1 of REDUCTION =2 is.
• Gebruiker USER2@EXAMPLE.COM ziet alle velden, maar alleen de records die zijn gekoppeld aan REDUCTION=1.
• Gebruiker USER3@EXAMPLE.COM ziet alle velden, maar alleen de records die zijn gekoppeld aan REDUCTION=2.
• Gebruiker USER4@EXAMPLE.COM ziet alle velden en alleen de records die andere gebruikers in dit voorbeeld kunnen zien als REDUCTION = 1 of REDUCTION =2 is.

Toegang tot gegevens op kolomniveau beheren

U kunt de toegang tot gegevens op kolomniveau beperken door het OMIT-systeemveld aan de beveiligingstabel toe te voegen in het script voor Section Access. Het volgende voorbeeld is gebaseerd op het vorige voorbeeld waarbij de rij voor gegevensreductie al aanwezig is.

Voorbeeld: Kolom voor gegevensreductie op basis van de identiteit van de gebruiker

Het veld OMIT in Section Access legt vast welke velden moeten worden verborgen voor de gebruiker.

Het resultaat is:

• Gebruiker USER1@example.com ziet alle velden en alleen de records die andere gebruikers in dit voorbeeld kunnen zien als REDUCTION gelijk is aan 1, 2 of 3.
• Gebruiker USER2@example.com ziet alle velden, maar alleen de records die zijn gekoppeld aan REDUCTION=1.
• Gebruiker USER3@example.com ziet alle velden behalve NUM en alleen de records die zijn gekoppeld aan REDUCTION=2.
• Gebruiker USER4@example.com ziet alle velden behalve ALPHA en alleen de records die zijn gekoppeld aan REDUCTION=3.

Toegang tot gebruikersgroepen beheren

Section Access biedt u de optie de gegevens die zichtbaar zijn voor gebruikers op basis van een groepslidmaatschap te beperken. Om uw gegevens te beperken voor gebruikersgroepen, voegt u de veldnaam GROUP toe aan de beveiligingstabel in de Access Section en definieert u waarden voor het veld GROUP .

Voorbeeld: Gegevensreductie op basis van gebruikersgroepen

Het resultaat is:

• Gebruikers die tot de ADMIN-groep behoren zien alle velden en alleen de records die andere gebruikers in dit voorbeeld kunnen zien als REDUCTION gelijk is aan 1, 2 of 3.
• Gebruikers die behoren tot de A-groep hebben toestemming om gegevens te zien die zijn gekoppeld aan REDUCTION=1 in alle velden.
• Gebruikers die behoren tot de B-groep hebben toestemming om gegevens te zien die zijn gekoppeld aan REDUCTION=2, maar niet in het NUM-veld
• Gebruikers die behoren tot de C-groep hebben toestemming om gegevens te zien die zijn gekoppeld aan REDUCTION=3, maar niet in het ALPHA-veld
• Gebruikers die behoren tot de GROUP1-groep hebben toestemming om gegevens te zien die zijn gekoppeld aan REDUCTION=3 in alle velden.
• De gebruiker AD_DOMAIN\DEV heeft toestemming om alle gegevens in alle velden te zien.

Qlik Cloud vergelijkt de gebruiker met UserID en herleidt de gebruiker aan de hand van groepen in de tabel. Als de gebruiker deel uitmaakt van een groep die toegang heeft, of als de gebruiker overeenkomt, krijgt deze gebruiker toegang tot de app.

Gegevens laden in Qlik Cloud

Als u gegevens zonder gegevensreductie wilt laden in Qlik Cloud, wordt aanbevolen om het systeemveld USER.EMAIL in de beveiligingstabel te gebruiken. De waarde voor het veld USER.EMAIL moet het e-mailadres zijn van gebruikers die de app kunnen bewerken en laden. Dit is van toepassing op apps in gedeelde en beheerde ruimten. Bijvoorbeeld:

In dit voorbeeld is de gebruiker met het e-mailadres test@example.com een ADMIN en in staat de app te laden.

Als u groepen gebruikt, werkt het volgende voorbeeld voor zowel Qlik Sense als Qlik Cloud:

U kunt ook de USERID in de beveiligingstabel toewijzen aan de subject claim van de identiteitsprovider, zoals in het onderstaande voorbeeld wordt getoond. Deze configuratie wordt aanbevolen voor de migratie van Qlik Sense naar Qlik Cloud en voor omgevingen met meerdere clouds. Zie Gebruikerstoegang beheren in een omgeving met meerdere clouds voor meer informatie over het toewijzen van de USERID aan de subject claim

Gebruikerstoegang beheren in een omgeving met meerdere clouds

Voor een Qlik Sense-omgeving met meerdere clouds bestaat een combinatie van mechanismen voor gebruikersauthenticatie. In Qlik Sense Enterprise on Windows wordt gewoonlijk de USERID in de beveiligingstabel voor Section Access geverifieerd door de proxyservice. In Qlik Cloud wordt een identiteitsprovider met de authenticatierol gebruikt. Daardoor zal de Section Access die is ingesteld voor een on-premises omgeving zoals Qlik Sense Enterprise on Windows niet werken in een cloudomgeving.

Bij gebruik van een OIDC- of SAML-identiteitsprovider (Qlik IdP of een aangepaste IdP) met Qlik Cloud, wordt de subject claim gebruikt voor het identificeren van gebruikers als ze zich aanmelden. Met Sectietoegang wordt de waarde van het veld USERID in de beveiligingstabel vergeleken met de waarde van de subject claim. Bij het instellen van uw tenant, moet u ervoor zorgen dat de SAM-accountnaam is toegewezen aan de subject claim van uw identiteitsprovider. Als uw SAM accountnaam bijvoorbeeld AD_DOMAIN\Dev is, moet u de subject claim instellen op AD_DOMAIN\Dev. Als u de waarde wilt bekijken van de subject claim van de IdP, voegt u /api/v1/diagnose-claims toe aan de tenant-URL in de browser, bijvoorbeeld: your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. In het JSON -antwoord heeft de subject claim de naam sub.

Als u de SAM-accountnaam niet kunt gebruiken, kunt u een gebruiker op een andere manier verifiëren. Aangezien e-mailadressen doorgaans hetzelfde blijven in verschillende omgevingen, kunt u het veld USER.EMAIL in de beveiligingstabel gebruiken in plaats van het veld USERID. Hier volgt een voorbeeld van hoe de beveiligingstabel er uit kan komen te zien:

Autorisatiescript:

Houd er rekening mee dat er voor elke gebruiker twee records aanwezig zijn: Eén voor on-premises toegang en één voor cloudtoegang. De jokertekens zorgen ervoor dat de relevante authenticatievelden worden gebruikt. In dit voorbeeld wordt COUNTRY gebruikt als veld voor gegevensreductie.

QlikView-verificatievelden

Om achterwaartse compatibiliteit mogelijk te maken, herkent Qlik Cloud de verificatievelden van QlikView 12. USERID wordt anders geïnterpreteerd in QlikView 12 en Qlik Cloud, maar het wordt in Qlik Cloud op dezelfde manier geïnterpreteerd als in Qlik Sense: Het wordt vergeleken met de naam van de geverifieerde gebruiker.

PASSWORD, NTSID en NTDOMAINSID

Als een van de velden PASSWORD, NTSID en NTDOMAINSID wordt gebruikt en dit veld een relevante waarde bevat, wordt toegang tot het document geweigerd. Als het veld een jokerteken (*) bevat, kan er toegang worden verleend, afhankelijk van de andere velden in de verificatietabel.

SERIAL

Als de SERIAL wordt gebruikt en een licentienummer bevat, zal de rij Section Access toegang tot het document weigeren. Als het veld een jokerteken (*) bevat, kan er toegang worden verleend, afhankelijk van de andere velden in de verificatietabel.

In Qlik Cloud kan dit veld ook worden gebruikt om de omgeving te definiëren. Dit betekent dat als het veld de tekenreeks 'QLIKCLOUD' bevat, er toegang kan worden verleend, afhankelijk van de andere velden in de verificatietabel.

Gemengde omgevingen

Als u van plan bent om dezelfde beveiligingstabel in QlikView 12 en Qlik Cloud te gebruiken, houd dan met het volgende rekening:

• USERID heeft een andere betekenis in QlikView 12 en Qlik Cloud, en kan bij gebruik mogelijk beveiligingsproblemen veroorzaken. Gebruik in plaats daarvan NTNAME of combineer deze met SERIAL zoals hieronder beschreven.

• GROUP en velden die beginnen met ‘USER.’, zoals 'USER.NAME' en 'USER.EMAIL', zijn (of worden) verificatievelden in Qlik Cloud. Als u deze velden in uw sectietoegang gebruikt, is het mogelijk dat de toegang wordt geweigerd in Qlik Cloud.

• PASSWORD, NTSID en NTDOMAINSID kunnen niet worden gebruikt in Qlik Cloud. De toegang wordt geweigerd, tenzij u een jokerteken gebruikt.

• SERIAL kan niet worden gebruikt om het licentienummer te controleren in Qlik Cloud. Als dit veld echter de tekenreeks ‘QLIKCLOUD’ bevat, wordt er mogelijk toegang verleend. Dit betekent dat de onderstaande beveiligingstabel mogelijk is, waarbij regel 1 toegang verleent in QlikView 12 (maar niet in Qlik Cloud) en regel 2 toegang verleent in Qlik Cloud (maar niet in QlikView 12).

Autorisatiescript:

Richtlijnen en tips voor het gebruik van Section Access

Hier volgen enkele belangrijke feiten en handige tips voor Section Access.

• Alle veldnamen en veldwaarden die in sectietoegang worden getoond, worden altijd omgezet naar hoofdletters. Dit leidt ertoe dat alle velden die onderdeel zijn van een gegevensreductie ook naar hoofdletters omgezet moet worden zodat ze overeenkomen met de inhoud van de sectietoegang-instructie, zelfs als ze zich buiten de sectietoegang-instructie bevinden. Zet een veldnaam met kleine letters in de database om naar hoofdletters met de functie Hoofdletters voordat het veld wordt gelezen door de LOAD- of SELECT-instructie.

  Ga voor meer informatie naar Upper - script- en diagramfunctie.

• U kunt de systeemveldnamen voor Section Access die in uw gegevensmodel als veldnamen worden weergegeven niet gebruiken.
• Apps moeten worden gepubliceerd voordat besturingen voor Section Access worden toegepast. Als de app wordt geladen, worden geen van de nieuwe of gewijzigde scripts voor Section Access toegepast.
• Een snapshot toont gegevens op basis van de toegangsrechten van de gebruiker die de snapshot maakt en de snapshot kan vervolgens worden gedeeld in een presentatie. Als gebruikers echter teruggaan naar een visualisatie vanuit een presentatie om de live gegevens in de app te bekijken, worden zij beperkt door hun eigen toegangsrechten.
• U moet geen kleuren toewijzen aan masterdimensiewaarden als u sectietoegang gebruikt of als u met gevoelige gegevens werkt, omdat de waarden door de kleurconfiguratie mogelijk kunnen worden onthuld.
• Verwijder voordat u de app publiceert alle bijgevoegde bestanden met sectietoegangsinstellingen als u blootstelling van vertrouwelijke gegevens wilt voorkomen. Bijgevoegde bestanden worden meegenomen als de app wordt gepubliceerd. Als de gepubliceerde app wordt gekopieerd, worden de bijgevoegde bestanden meegeleverd met de kopie. Indien echter beperkingen voor sectietoegang zijn toegepast op de bijgevoegde gegevensbestanden, blijven de sectietoegangsinstellingen niet behouden wanneer de bestanden worden gekopieerd. Gebruikers van de gekopieerde app kunnen daardoor alle gegevens in de bijgevoegde bestanden bekijken.
• Een jokerteken (*) wordt geïnterpreteerd als alle waarden (in de lijst) voor het veld in de tabel. Bij het gebruik in een van de systeemvelden (USERID, GROUP) in een tabel die in de toegangssectie van het script wordt geladen, is de interpretatie alle mogelijke waarden van dit veld (ook als ze niet in de lijst staan).
• Beveiligingsvelden kunnen in verschillende tabellen worden geplaatst.
• Gegevens uit een QVD-bestand worden minder snel geladen als de functie Hoofdletters wordt gebruikt.