Ga naar hoofdinhoud

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 Sense gebruikt deze informatie om de gegevens aan te passen aan het geschikte bereik als de gebruiker de applicatie opent, daardoor zijn sommige gegevens in de app verborgen voor de gebruiker en dit wordt bepaald aan de hand van de identiteit. Section Access 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.

Opmerking: Insight Advisor Chat ondersteunt geen apps die gebruik maken van Section Access.

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.

Example:  

Section Access; Load * INLINE [ ACCESS, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 3 ADMIN, INTERNAL\SA_SCHEDULER, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1 AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

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.

Als Section Access is gebruikt in een in laadscenario, INTERNAL\SA_SCHEDULER, dit is de Scheduler Service voor de gebruiker, zijn ADMIN-bevoegdheden vereist om de lading uit te voeren. Bijvoorbeeld:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_SCHEDULER ];

Als u het account INTERNAL\SA_SCHEDULER niet wilt gebruiken, raadpleeg dan Imitatie gebruiken voor het laden van gegevens voor een alternatieve methode.

Als Section Access wordt gebruikt bij het genereren van een on-demand-app (ODAG) in de sjabloon-app, moet de INTERNAL\SA_API-gebruiker worden opgenomen als ADMIN in de Section Access-tabel. Bijvoorbeeld:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Bevat een tekenreeks die overeenkomt met een Qlik Sense-domeinnaam en -gebruikersnaam. In Qlik Sense worden de aanmeldgegevens opgehaald uit de proxy en vergeleken met de waarde in dit veld.

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.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Opmerking: USERID en NTNAME maken allebei gebruik van dezelfde verificatiegegevens, dus het is niet nodig om ze beide te controleren in dezelfde rij van de beveiligingstabel. Het verschil tussen deze twee velden is dat NTNAME ook groepen controleert.

NTNAME

Opmerking: NTNAME is een verouderd QlikView-veld en aanbevolen wordt om USERID te gebruiken als QlikView geen gebruikmaakt van dezelfde beveiligingstabel.

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 Sense worden de aanmeldgegevens opgehaald uit de proxy en vergeleken met de waarde in dit veld.

GROUP

Bevat een tekenreeks die overeenkomt met een groep in Qlik Sense. Qlik Sense herleidt de gebruiker die door de proxyservice wordt geleverd aan de hand van deze groep.

SERIAL

Opmerking: SERIAL is een verouderd veld van QlikView en wordt niet gebruikt als u alleen Qlik Sense gebruikt.

Bevat een tekenreeks die overeenkomt met het platform. Als het veld de tekenreeks ‘QLIKSENSE’ of een jokerteken ‘*’ bevat, kan er toegang worden verleend, afhankelijk van de andere velden in de beveiligingstabel.

Opmerking: Als de SERIAL een licentienummer bevat, zal de rij Section Access toegang tot het document weigeren. Deze instelling is alleen geldig in QlikView.

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.

Opmerking: Aanbevolen wordt om OMIT niet toe te passen op sleutelvelden. Sleutelvelden die worden weggelaten zijn zichtbaar in de viewer voor gegevensmodellen, maar de inhoud is niet beschikbaar. Dit kan verwarrend zijn voor een gebruiker. Daarnaast kan toepassing van OMIT op velden die in een visualisatie worden gebruikt, leiden tot een onvolledige visualisatie voor gebruikers die geen toegang hebben tot de weggelaten velden.

Gebruikerstoegang tot een app beheren

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 specifieke gebruikers-id 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 USERID 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.

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

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.

Opmerking:

Het jokerteken* in de kolom voor gegevensreductie verwijst alleen naar alle waarden in de beveiligingstabel. Als er waarden in de Section Application zijn die niet beschikbaar zijn in de reductiekolom van de beveiligingstabel, worden ze beperkt.

Opmerking: Alle gebruikte veldnamen in de hierboven beschreven overdracht en alle veldwaarden in deze velden moeten in hoofdletters zijn. Alle veldnamen en veldwaarden worden immers standaard omgezet in hoofdletters in de Access Section.
Opmerking: Voor het inschakelen van ladingen van het script in een Qlik Management Console-taak, is standaard de accountgebruiker INTERNAL\SA_SCHEDULER met ADMIN-toegang nodig. Als u het account INTERNAL\SA_SCHEDULER niet wilt gebruiken, raadpleeg dan Imitatie gebruiken voor het laden van gegevens voor een alternatieve methode.

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

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

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 ADMIN ziet alle velden en alleen de records die andere gebruikers in dit voorbeeld kunnen zien als REDUCTION = 1 of REDUCTION =2 is.
  • Gebruiker A ziet alle velden, maar alleen de records die zijn gekoppeld aan REDUCTION=1.
  • Gebruiker B ziet alle velden, maar alleen de records die zijn gekoppeld aan REDUCTION=2.
  • Gebruiker C 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.

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

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT ADMIN, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

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

Het resultaat is:

  • Gebruiker ADMIN 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 A ziet alle velden, maar alleen de records die zijn gekoppeld aan REDUCTION=1.
  • Gebruiker B ziet alle velden behalve NUM en alleen de records die zijn gekoppeld aan REDUCTION=2.
  • Gebruiker C ziet alle velden behalve ALPHA en alleen de records die zijn gekoppeld aan REDUCTION=3.
Opmerking: Sommige visualisaties hebben minimale vereisten voor gegevens waaraan moet worden voldaan voordat ze worden weergegeven. Dit kan ertoe leiden dat "Incomplete visualization" (onvolledige visualisatie) wordt weergegeven als een veld op kolomniveau wordt weggelaten in de gegevensweergave van een gebruiker.

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 .

Example: Gegevensreductie op basis van gebruikersgroepen

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Het resultaat is:

  • Gebruikers die behoren tot de ADMIN-groep hebben toestemming om alle gegevens en alle velden te zien.
  • 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.

Qlik Sense vergelijkt de gebruiker met de UserID en zet de gebruiker om tegen 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.

Imitatie gebruiken voor het laden van gegevens

Standaard wordt het interne systeemaccount, SA_SCHEDULER, gebruikt om laadtaken uit te voeren. Dit account heeft verhoogde bevoegdheden en kan technisch gezien alle gegevensbronnen gebruiken. Er is echter een instelling in de QMC waarbij gebruik wordt gemaakt van imitatie om laadtaken uit te voeren met de machtigingen van de app-eigenaar in plaats van met het interne systeemaccount. Als u deze instelling configureert, wordt de app-eigenaar en niet SA_SCHEDULER gebruikt voor ladingen. Dit betekent dat u niet SA_SCHEDULER toevoegt aan de Section Access-tabel, maar juist de app-eigenaar. In een taakketen kunnen apps verschillende eigenaren hebben met toestemmingen voor bronnen, afhankelijk van de toegangsrechten van elke eigenaar. Zie Servicecluster (alleen in het Engels) voor meer informatie.

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 SaaS editions of Qlik Sense 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-identiteitsprovider (Qlik IdP of een aangepaste IdP) voor SaaS editions of Qlik Sense, wordt de subject claim gebruikt voor het identificeren van gebruikers als ze zich aanmelden. Met Section Access wordt de waarde van het veld USERID in de beveiligingstabel vergeleken met de waarde van de subject claim. Bij het instellen vna 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:

ACCESS USERID USER.EMAIL Comment COUNTRY
USER ABC\Joe * Access-on-prem United States
USER * joe.smith@example.com Access-in-cloud United States
USER ABC\Ursula * Access-on-prem Germany
USER * ursula.schultz@example.com Access-in-cloud Germany
USER ABC\Stefan * Access-on-prem Sweden
USER * stefan.svensson@example.com Access-in-cloud Sweden

Autorisatiescript:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

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.

Richtlijnen en tips voor het gebruik van Section Access

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

  • Alle velden in LOAD- of SELECT-instructies in de Access Section moeten in HOOFDLETTERS worden geschreven. 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.
  • Als u zichzelf hebt buitengesloten van een app door Section Access in te stellen, kunt u de app openen zonder gegevens en Section Access bewerken in het load-script voor gegevens. Dit vereist dat u toegang hebt voor het bewerken en opnieuw laden van het load-script voor gegevens.

    Ga voor meer informatie naar Een app zonder gegevens openen.

  • Door een laadinstructie met binary worden de toegangsbeperkingen overgenomen door de nieuwe Qlik Sense-app.