Beveiliging

Een beveiligingsmechanisme in QlikView kan op twee verschillende manieren worden ingesteld. Het kan in het script van het QlikView-document worden ingebouwd of het kan worden ingesteld met QlikView Publisher.

Verificatie en autorisatie

Verificatie is een proces waarbij u controleert of iemand is wie hij of zij beweert te zijn. QlikView kan de verificatie via het Windows-besturingsssysteem laten verlopen, of zelf vragen om een eigen gebruikers-ID en wachtwoord (anders dan die voor Windows) of de QlikView-licentiesleutel gebruiken als eenvoudige verificatiemethode.

Autorisatie is het controleren of de persoon na identificatie toegang mag krijgen tot de bron. QlikView kan de autorisatie via het Windows-besturingsssysteem laten verlopen, of deze zelf afhandelen. Voor de laatste mogelijkheid moet een beveiligingstabel in het script worden opgenomen.

Beveiliging met QlikView Publisher

Als QlikView Publisher is ingesteld voor de afhandeling van de beveiliging, wordt elk QlikView-bestand opgedeeld in diverse bestanden, elk met de gegevens die van belang zijn voor de desbetreffende gebruiker of gebruikersgroep. Deze bestanden worden opgeslagen in mappen met de juiste beveilingsinstellingen van het besturingssysteem. QlikView laat de verificatie en autorisatie dus over aan het besturingssysteem.

Er is echter geen beveiliging in het bestand zelf ingebouwd, zodat er geen beveiliging is bij een gedownload bestand.

De bestandsgrootte is meestal geringer, omdat één bestand in meerdere wordt opgedeeld en de gebruiker alleen het bestand met de relevante gegevens opent. Dit betekent echter ook dat een QlikView-server mogelijk meer geheugen kan gebruiken dan wanneer alle gegevens in één bestand blijven, omdat soms meerdere bestanden met dezelfde gegevens zullen worden geladen.

Zie de documentatie voor QlikView Publisher voor meer informatie.

Beveiliging met Section Access in het QlikView-script

Als Section Access in het QlikView-script is ingesteld voor de afhandeling van de beveiliging, kunt u de relevante gegevens voor meerdere gebruikers of gebruikersgroepen in één bestand opnemen. QlikView gebruikt de informatie in Section Access voor de verificatie en autorisatie en zorgt voor de dynamische reductie van de gegevens, zodat de gebruikers alleen hun eigen gegevens zien.

De beveiliging is in het bestand zelf ingebouwd, zodat ook een gedownload bestand in zekere mate is beveiligd. Als de beveilingseisen echter nogal strikt zijn, moet u het downloaden van bestanden en offline gebruik vermijden. De bestanden mogen alleen door de QlikView Server-server worden gepubliceerd.

Aangezien alle gegevens in één bestand zijn ondergebracht, kan de bestandsgrootte fors oplopen.

QlikView-documenten kunnen onzichtbaar worden gemaakt in de offlinemodus. Als u een document van een offlinegebruiker onzichtbaar wilt maken, voegt u het volgende kenmerk toe aan de informatiesectie van een gebruikersdocument met behulp van de QMC:

• Naam:  Onzichtbaar
• Waarde: True

Alle informatie verderop heeft betrekking op de beveiligingsmethode met behulp van Section Access in het QlikView-script.

Secties in het script

Toegang op rijniveau wordt geregeld via een of meer beveiligingstabellen die op dezelfde wijze worden geladen als reguliere gegevens. Deze tabellen kunnen daardoor worden opgeslagen in een standaarddatabase of in een spreadsheet. De scriptopdrachten voor de beveiligingstabellen worden opgegeven in een verificatiesectie die in het script wordt gestart met de opdracht Section Access.

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

Voorbeeld:  

Autorisatieniveaus in het gedeelte 'Section Access'

Toegang tot QlikView-documenten kan worden verleend aan bepaalde gebruikers of gebruikersgroepen. In de beveiligingstabel kunnen aan gebruikers de toegangsniveaus USER of ADMIN worden toegewezen. Als er geen toegangsniveau wordt toegewezen, kan de gebruiker het QlikView-document niet openen.

Een gebruiker met de bevoegdheid ADMIN kan alles wijzigen in het document. Op de pagina Beveiliging in de dialoogvensters Documenteigenschappen en Werkbladeigenschappen kan een persoon met de bevoegdheid ADMIN de mogelijkheden beperken van gebruikers om het document te wijzigen. Een persoon met de rechten USER heeft geen toegang tot de pagina's Beveiliging.

Systeemvelden in Section Access

De toegangsniveaus worden toegewezen aan gebruikers in een of meer tabellen die worden geladen in de sectietoegang van het script. Deze tabellen kunnen verschillende gebruikersspecifieke systeemvelden bevatten, meestal USERID en PASSWORD, en het veld ACCESS waarin het autorisatieniveau wordt vastgelegd. Alle systeemvelden in het gedeelte section access zullen worden gebruikt voor verificatie of autorisatie. De volledige set systeemvelden voor het gedeelte Section Access wordt hieronder beschreven.

Geen, alle of elke combinatie van de beveiligingsvelden kan worden geladen in de sectietoegang. Het is daarom niet nodig het veld USERID te gebruiken. Autorisatie kan ook worden gekoppeld aan andere velden, bijvoorbeeld alleen het serienummer.

 

In QlikView wordt het QlikView-serienummer vergeleken met het veld SERIAL, de Windows NT-gebruikersnaam en -groepsnaam met NTNAME, de Windows NT-domein-SID met NTDOMAINSID en de Windows NT-SID met NTSID. Daarnaast moet de gebruiker de gebruikers-ID en het wachtwoord invoeren. Deze worden vergeleken met de waarden in de velden USERID en PASSWORD.

Als de gevonden combinatie van gebruikers-ID, wachtwoord en omgevingseigenschappen ook wordt gevonden in de tabel Section Access, wordt het document geopend met het corresponderende toegangsniveau. Als dit niet het geval is, krijgt de gebruiker geen toegang tot het document. Als de gebruikers-ID en/of het wachtwoord niet binnen drie pogingen juist worden ingevoerd, moet de hele aanmeldprocedure worden herhaald.

Omdat de interne logica, het kenmerk van QlikView, ook wordt gebruikt in de toegangssectie, kunnen de beveiligingsvelden in verschillende tabellen worden geplaatst. (Een systeembeheerder kan zo een QlikView-document maken op basis van de beveiligingstabellen. In dit geval wordt een correct serienummer, wachtwoord etc. gesimuleerd door een klik op de corresponderende veldwaarde.)

In de aanmeldprocedure controleert QlikView eerst SERIAL, NTNAME, NTDOMAINSID en NTSID om te zien of deze informatie voldoende is om de gebruiker toegang tot het document te geven. Als dat het geval is, wordt het document in QlikView geopend zonder te vragen om een gebruiker-ID en wachtwoord.

Als slechts enkele van de toegangsvelden worden geladen, zijn de relevante vereisten hierboven van toepassing.

Alle velden in Load- en Select-opdrachten in Section Access moeten IN HOOFDLETTERS worden geschreven. Een veldnaam met kleine letters in de database moet worden omgezet naar hoofdletters met de functie upper, voordat het veld wordt gelezen door de opdracht Load of Select.

Upper - script- en grafiekfunctie

De gebruikers-ID en het wachtwoord dat door de eindgebruiker worden ingevoerd tijdens het openen van de QlikView-documenten zijn niet hoofdlettergevoelig.

Een jokerteken (*) wordt geïnterpreteerd als alle waarden (in de lijst) voor dit veld, dat wil zeggen een waarde elders in deze tabel. Bij het gebruik in een van de systeemvelden (USERID, PASSWORD, NTNAME of SERIAL) in een tabel die bij de toegangssectie van het script wordt geladen, is de interpretatie alle mogelijke waarden van dit veld (ook als ze niet in de lijst staan).

Voorbeeld 1:  

Alleen het serienummer wordt gecontroleerd. Aan één bepaalde computer wordt de beheerderstoegang ADMIN toegekend. Alle overige gebruikers krijgen de gebruikerstoegang USER. Let op! Een stersymbool kan worden gebruikt om "elk serienummer" in te schakelen.

Voorbeeld 2:  

De beheerder en de server waarop QlikView wordt uitgevoerd als een batchtaak, krijgen de beheerderstoegang ADMIN. Alle andere gebruikers in het domein krijgen de gebruikerstoegang USER wanneer "USER" wordt ingevoerd als gebruikers-ID en wachtwoord.

Gemengde omgevingen

Als u van plan bent om dezelfde verificatietabel te gebruiken in zowel QlikView als Qlik Sense SaaS, moet u met het volgende rekening houden:

• USERID heeft een andere betekenis in QlikView en Qlik Sense SaaS, en kan, indien gebruikt, beveiligingsproblemen veroorzaken. Gebruik in plaats daarvan NTNAME of gebruik het in combinatie met SERIAL, zoals hieronder wordt beschreven.

• GROUP en velden die beginnen met ‘USER.’, zoals 'USER.NAME' en 'USER.EMAIL', etc. zijn (of worden) geverifieerde velden in Qlik Sense Enterprise SaaS. Als u deze velden gebruikt in uw Section Access, kan de toegang in Qlik Sense SaaS worden geweigerd.

• U kunt PASSWORD, NTSID en NTDOMAINSID niet gebruiken in Qlik Sense SaaS. De toegang wordt geweigerd, tenzij u een jokerteken gebruikt.

• U kunt SERIAL niet gebruiken om een licentienummer te controleren in Qlik Sense SaaS. Als dit veld echter de tekenreeks ‘QLIKCLOUD’ of 'QLIKVIEW' bevat, wordt er mogelijk toegang verleend. Dit betekent dat het mogelijk is om de onderstaande verficatietabel te hebben, waarbij regel 1 toegang verleent tot QlikView (maar niet in Qlik Sense SaaS) en regel 2 verleent toegang in Qlik Sense SaaS (maar niet in QlikView).

 

Beperkingen van de QlikView-functionaliteit

De besturingselementen op de pagina Documenteigenschappen: Beveiliging en de pagina Werkbladeigenschappen: Beveiliging maken het mogelijk om de toegang tot bepaalde menuopties te blokkeren en wijzigingen in de opmaak tegen te houden. Als deze instellingen als echte beveiligingsmaatregel moeten gelden, moeten de gebruikers van het document zijn aangemeld als USER. Gebruikers die zijn aangemeld als ADMIN, kunnen de beveiligingsinstellingen namelijk op elk moment wijzigen.

Voor een gebruiker die het document heeft geopend met de rechten USER, wordt de pagina Beveiliging niet weergegeven de eigenschappenvensters.

Dynamische gegevensreductie

QlikView en QlikView Server ondersteunen een functie waarmee sommige gegevens in een document op basis van de aanmeldgegevens in het gedeelte Section Access voor de gebruiker kunnen worden verborgen.

Ten eerste kunnen velden (kolommen) worden verborgen met behulp van het systeemveld OMIT.

Ten tweede kunnen records (rijen) worden verborgen door de gegevens in Section Access te koppelen aan de werkelijke gegevens: Welke waarden moeten worden weergegeven/uitgesloten, wordt geregeld door een of meer velden met dezelfde naam in de gedeelten section access en section application. Nadat een gebruiker zich heeft aangemeld, probeert QlikView de selecties in velden in Section Access te kopiëren naar de velden in section application 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 QlikView.

Deze procedure kan alleen worden gebruikt als de optie Aanvankelijke gegevensreductie gebaseerd op Section Access op de pagina Documenteigenschappen: Openen is ingeschakeld. Als deze functie wordt gebruikt in documenten die op een andere wijze moeten worden gedistribueerd dan via QlikView Server, moet de optie Binair laden verbieden op dezelfde pagina van Documenteigenschappen worden ingeschakeld om de gegevensbeveiliging te behouden.

Voorbeeld:  

section access;

LOAD * inline [

ACCESS, USERID,REDUCTION, OMIT

ADMIN, ADMIN,*,

USER, A,1

USER, B, 2, NUM

USER, C, 3, ALPHA

];

section application;

T1:

LOAD *,

NUM AS REDUCTION;

LOAD

Chr( RecNo()+ord('A')-1) AS ALPHA,

RechNo() AS NUM

AUTOGENERATE 3;

Het veld REDUCTION (hoofdletters) komt nu in zowel section access als section application voor (alle veldwaarden zijn ook in hoofdletters). De twee velden zouden normaal gesproken geheel verschillend en gescheiden zijn, maar als de optie Aanvankelijke gegevensreductie gebaseerd op sectietoegang is ingeschakeld, worden ze gekoppeld en beperken ze het aantal records dat de gebruiker te zien krijgt.

Het veld OMIT in section access legt vast welke velden moeten worden verborgen voor de gebruiker.

Het resultaat is:

Gebruiker A ziet alle velden, maar alleen de records die zijn verbonden met REDUCTION=1.

Gebruiker B ziet alle velden behalve NUM, en alleen de records die zijn verbonden met REDUCTION=2.

Gebruiker C ziet alle velden behalve ALPHA, en alleen de records die zijn verbonden met REDUCTION=3.

Overgenomen toegangsbeperkingen

Door een laadopdracht met binary worden de toegangsbeperkingen overgenomen door het nieuwe QlikView-document. Een persoon met de rechten ADMIN voor dit nieuwe document kan de toegangsrechten ervoor wijzigen door een nieuwe section access toe te voegen. Een persoon met de rechten USER kan het script uitvoeren en wijzigen, en dus gegevens toevoegen aan het binair geladen bestand. Een persoon met de rechten USER kan de toegangsrechten niet wijzigen. Zo kan een databasebeheerder de gebruikerstoegang tot ook binair geladen QlikView-documenten beheren.

Versleuteling

De communicatie tussen een QlikView-server en een QlikView Windows-client is versleuteld. Als echter de AJAX-client wordt gebruikt, is de communicatie niet versleuteld.

Daarnaast worden alle QlikView-documenten versleuteld, waardoor de informatie onleesbaar wordt voor viewers, programma's voor het opsporen van fouten enzovoort.

U kunt ook gevoelige gegevens in QVD-bestanden versleutelen met sleutelparen voor elke klant zodat u kunt beheren wie toegang tot uw gegevens krijgt. Zie QVD-versleuteling (alleen in het Engels).