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 SaaS 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. 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. 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:  

Section Access; Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ]; 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.

USERID

Bevat een tekenreeks die overeenkomt met een Qlik Sense SaaS-gebruikersnaam. In Qlik Sense SaaS 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 voorwerp niet worden toegewezen aan een interne Windows-identiteit. Het IdP-voorwerp 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.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Informatie 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

InformatieNTNAME 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 SaaS 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 Sense SaaS 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 Sense SaaS. In Qlik Sense SaaS worden de aanmeldgegevens opgehaald uit de “groups”-claim van de identiteitsprovider en vergeleken met de waarde in dit veld.

InformatieGebruikersgroepen worden niet ondersteund in Qlik Sense Business of als de identiteitsprovider (IdP) van Qlik wordt gebruikt.

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.

InformatieAanbevolen 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

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.

Section Access; LOAD * inline [ ACCESS, USER.EMAIL ADMIN, USER1@example.com USER, USER2@example.com USER, USER3@example.com ]; Section Application;

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.

Informatie

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.

InformatieAlle 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.

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

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 USER, USER4@example.com, * ]; 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 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

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; 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 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.
InformatieSommige 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 .

Voorbeeld: 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, AD_DOMAIN\DEV, *, *, ]; 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.
  • De gebruiker AD_DOMAIN\DEV heeft toestemming om alle gegevens in alle velden te zien.

Qlik Sense SaaS 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 Sense SaaS

Als u gegevens zonder gegevensreductie wilt laden in Qlik Sense SaaS, 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:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, test@example.com, * ];

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 Sense SaaS:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, Developers, * ];

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 Sense SaaS 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

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

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 Sense SaaS 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 Qlik Sense SaaS, 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 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:

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.

QlikView-verificatievelden

Om achterwaartse compatibiliteit mogelijk te maken, herkent Qlik Sense SaaS de verificatievelden van QlikView. USERID wordt anders geïnterpreteerd in QlikView en Qlik Sense SaaS, maar het wordt in Qlik Sense SaaS 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 Sense SaaS 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 en Qlik Sense SaaS te gebruiken, houd dan met het volgende rekening:

USERID heeft een andere betekenis in QlikView en Qlik Sense SaaS, 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 Sense SaaS. Als u deze velden in uw sectietoegang gebruikt, is het mogelijk dat de toegang wordt geweigerd in Qlik Sense SaaS.

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

SERIAL kan niet worden gebruikt om het licentienummer te controleren in Qlik Sense SaaS. 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 (maar niet in Qlik Sense SaaS) en regel 2 toegang verleent in Qlik Sense SaaS (maar niet in QlikView).

Beveiligingstabel.
Rij SERIAL USERID Opmerking
1 4600 0123 4567 8901 * Verleent toegang tot het correcte licentienummer in QlikView.
2 QLIKCLOUD John Doe Verleent toegang tot de correcte gebruiker in Qlik Sense SaaS.

Autorisatiescript:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, John Doe, QLIKCLOUD ];

Gebruiken van Section Access en Insight Advisor Chat

Apps die gebruikmaken van Section Access gebruiken een indexgebruiker om te bepalen hoeveel informatie Insight Advisor Chat ophaalt uit de app. De indexgebruiker moet de gebruiker zijn met hoogste toegangsniveau voor de app in het script voor Section Access. Voor gegevens die beschikbaar zijn voor eindgebruikers gelden echter nog steeds beperkingen op basis van Section Access.

Waarschuwing

Als er gevoelige gegevens aanwezig zijn in namen van apps, velden of masteritems, worden deze mogelijk weergegeven als apps met behulp van Section Access zichtbaar worden gemaakt voor Insight Advisor Chat. Onder app-suggesties voor queries vallen apps in streams waartoe gebruikers toegang hebben. Hieronder kunnen apps vallen waartoe gebruikers geen toegang hebben in de Section Access van een app. Als gebruikers deze apps selecteren, gebeurt er niets. Als gebruikers op Dimensies of Metingen klikken om de beschikbare items van een app met behulp van Section Access te bekijken, zien gebruikers mogelijk items waartoe ze geen toegang hebben. Als gebruikers op deze items klikken, krijgen ze echter geen gegevens te zien.

De app-eigenaar is standaard de indexgebruiker. U kunt de indexgebruiker wijzigen via Details.

  1. In Qlik Cloud navigeert u naar de app.

  2. Klik op Meer in de app en selecteer Details.

  3. Onder Indexgebruiker selecteert u de indexgebruiker.

  4. Klik op Terug.

  5. Klik op Meer in de app en selecteer Opnieuw laden.

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 Upper 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.