Säkerhet

En säkerhetsmekanism i QlikView kan ställas in på två olika sätt. Den kan antingen byggas in i QlikView-dokumentets skript, eller så kandet ställas in via QlikView Publisher.

Autentisering och behörighetskontroll

Autentisering innebär att kontrollera att någon är den han utger sig för att vara. QlikView kan antingen överlåta autentiseringen till Windows operativsystem eller fråga efter ett användar-ID och lösenord (separat från användar-ID och lösenord i Windows) eller använda QlikViews licensnyckel för en enkel autentisering.

Behörighetskontroll innebär att ta reda på vilken tillgång den identifierade personen ska få till materialet. QlikView kan antingen överlåta behörighetskontrollen till operativsystemet Windows eller genomföra den själv. För det senare alternativet behöver en säkerhetstabell byggas in i skriptet.

Säkerhet med QlikView Publisher

Om QlikView Publisher är inställd för att hantera säkerhet blir varje QlikView-fil uppdaterad i ett flertal filer som i sin tur innehåller rätt information för respektive användare eller användargrupp. Filerna lagras i mappar med rätt säkerhetsinställningar för operativsystemet. Med andra ord låter QlikView operativsystemet hantera autentisering och behörighetskontroll.

Däremot är ingen säkerhet inbyggd i själva filen, så det finns inget skydd för en hämtad fil.

Filstorlekarna är vanligtvis mindre eftersom en fil delas upp i flera och användaren endast öppnar filen med sin egen information. Däremot kan detta innebära att en QlikView Server använder mer minne än om all information lagras i en fil, för ibland kan flera filer med samma datainnehåll laddas.

För mer information, se dokumentationen om QlikView Publisher.

Säkerhet med Section Access i QlikView-skriptet

Om Section Access i QlikView-skriptet är inställd för att hantera säkerhet, kan en enda fil innehålla data för ett antal användare eller användargrupper. QlikView använder informationen i Section Access för autentisering och behörighetskontroll och reducerar informationen dynamiskt så att användaren endast ser sin relevanta information.

Säkerheten är inbyggd i själva filen, så även hämtade filer är till viss del skyddade. Om säkerhetskraven är höga, bör nedladdning av filer och offline-användning förebyggas. Filerna bör publiceras endast via QlikView Server.

Eftersom all information lagras i en fil, kan filen bli mycket stor.

QlikView dokument kan ha ställts in som osynliga i nedkopplat läge. Om du vill göra ett dokument för nedkopplade användare osynligt lägger du till följande attribut i avsnittet för dokumentinformation i ett användardokument med QMC:

  • Namn: Osynlig
  • Värde: True

All information nedan handlar om säkerhetsmetoden där Section Access används i QlikView-skriptet.

Avsnitt i skriptet

Behörighetskontroll styrs av en eller flera säkerhetstabeller som laddas på vanligt sätt i QlikView. Därför kan man lagra tabellerna i en vanlig databas. Skriptsatserna som hanterar säkerhetstabellerna deklareras i behörighetsektionen, som i skriptet börjar med skriptsatsen section access.

Om en sådan behörighetssektion deklareras i skriptet, måste den del av skriptet som laddar "vanliga" data föregås av skriptsatsen section application.

Exempel:  

Section Access;

Load * inline

[ACCESS,USERID,PASSWORD

ADMIN, A,X

USER,U,Y ];

Section Application;

Load... ... from... ...

Behörighetsnivåer i Section Access

Behörighet till QlikView-dokument kan ges till namngivna användare eller användargrupper. I säkerhetstabellen kan användare få behörighetsnivåerna ADMIN eller USER. Har man inte tilldelats en behörighetsnivå kan man inte ens öppna QlikView-dokumentet.

En person med ADMIN-rättigheter kan ändra allt i dokumentet. Med hjälp av sidan Säkerhet i dialogerna Dokumentegenskaper och Arkegenskaper kan en person med ADMIN-rättigheter begränsa användarnas möjligheter att göra ändringar i dokumentet. En person med användarbehörighet (USER) har inte tillgång till sidorna Säkerhet.

Observera: ADMIN-behörigheter är endast relevanta för lokala dokument! Dokument som öppnas på en server nås alltid med USER-behörigheter.

Systemfält i Section Access

Behörighetsnivåerna tilldelas användarna i en eller flera tabeller som lästs in inom section access. Dessa tabeller kan innehålla flera användarspecifika systemfält, typiskt USERID (användaridentitet) och PASSWORD (lösenord), samt det fält som anger behörighetsnivå ACCESS (behörighetsgrupp). Alla systemfält i Section Access används för autentisering eller behörighetskontroll. Hela uppsättningen av behörighetssektionernas, section access, systemfält beskrivs nedan.

Inga, alla eller någon kombination av dessa skyddade fält kan laddas i behörighetssektionen. Det krävs alltså inte att man använder USERID - det kan räcka med en kontroll av exempelvis serienumret.

 

ACCESS Ett fält som anger vilken behörighet en viss användare ska ha.
USERID Ett fält som ska innehålla ett godkänt användar-ID. QlikView frågar efter ett användar-ID som jämförs med värdet i detta fält. Detta användar-ID är inte samma som användar-ID för Windows.
LÖSENORD Ett fält som ska innehålla ett godkänt lösenord. QlikView frågar efter ett lösenord som jämförs med värdet i detta fält. Detta lösenord är inte samma som lösenordet för Windows.
SERIAL Ett fält som ska innehålla ett nummer som motsvarar QlikViews serienummer.
Exempel: 4900 2394 7113 7304
QlikView kontrollerar användarens serienummer som jämförs med värdet i detta fält.
NTNAME Ett fält som ska innehålla en sträng som motsvarar ett Windows NT-domänanvändarnamn (user name) eller gruppnamn (group name).
QlikView hämtar användarens inloggningsinformation från operativsystemet och jämför den med värdet i detta fält.
NTDOMAINSID Ett fält som ska innehålla en sträng som motsvarar ett Windows NT Domänens säkerhets-id.
Exempel: S-1-5-21-125976590-4672381061092489882
QlikView hämtar användarens inloggningsinformation från operativsystemet och jämför den med värdet i detta fält.
NTSID Ett fält som ska innehålla ett Windows NT SID.
Exempel: S-15-21-125976590-467238106-1092489882-1378
QlikView hämtar användarens inloggningsinformation från operativsystemet och jämför den med värdet i detta fält.
OMIT

Ett fält som bör innehålla en lista över fält som ska utelämnas för denna användare. Jokertecken kan användas och listan kan lämnas tom. Ett smidigt sätt att göra detta är att använda subfält.

Observera: Du ska inte använda OMIT i nyckelfält, eftersom det förändrar den underliggande datastrukturen. Det kan skapa logiska öar och inkonsekventa beräkningar.

QlikView jämför QlikView-licensnumret med fältet SERIAL, Windows NT-användarnamnet och grupperna med NTNAME, Windows NT Domänens säkerhets-id med NTDOMAINSID och Windows NT SID med NTSID. Vidare frågar programmet efter Användaridentitet (User ID) och Lösenord (Password) och jämför dessa med fälten USERID och PASSWORD.

Om den funna kombinationen av användaridentitet, lösenord och närliggande egenskaper stämmer överens med de som finns i tabellen section access öppnas dokumentet på motsvarande behörighetsnivå. I alla andra fall nekas användaren dokumentåtkomst. Om användaridentitet och/eller lösenord inte förts in rätt efter tre försök, måste hela inloggningsproceduren upprepas.

Eftersom den interna logiken som är QlikViews signatur också används i behörighetssektionen, kan de skyddade fälten mycket väl finnas i olika tabeller. (Det är således möjligt för en systemadministratör att göra ett QlikView-dokument av de skyddade tabellerna. Korrekt licensnummer, lösenord etc. simuleras då genom en klickning på motsvarande fältvärde.

Under inloggningsproceduren kommer QlikView först att kontrollera SERIAL, NTNAME, NTDOMAINSID och NTSID för att se om den information som ges där är tillräcklig för att ge användaren behörighet till dokumentet. Om informationen räcker öppnas dokumentet utan att användaren krävs på vare sig användaridentitet eller lösenord.

Om bara några av de skyddade fälten laddas, kommer programmet att använda sig av ett passande urval av ovanstående krav.

Alla fält som listas i Load eller Select-satser i section access måste skrivas med VERSALER. Fältnamn som skrivits med gemener bör konverteras till versaler med hjälp av funktionen upper, innan de läses in med Load- eller Select-satser.

​Se: Upper - skript- och diagramfunktion

Det användar-ID och lösenord som slutanvändaren fyller i för att öppna QlikView-dokument är dock inte versalkänsliga.

Jokertecknet, *, tolkas som alla (listade) värden i ett fält. Om den används i något av systemfälten (USERID, PASSWORD; NTNAME eller SERIAL) i en tabell som laddats i skriptets behörighetssektion, tolkas den som alla (även inte listade) möjliga värden i detta fält.

Observera: När data laddas från en QVD-fil går laddningen långsammare om den övre funktionen används.
Observera: Generera behörighetstabeller i inline-satser med Tabellguide för behörighetsbegränsning.
Observera: Om du har aktiverat section access, kan du inte använda namnen på systemfälten angivna här för section access som fältnamn i din datamodell.

Exempel 1:  

Endast serinumret kontrolleras. En specifik dator ges ADMIN-åtkomst. Övriga får USER-åtkomst. Observera att en asterisk kan användas för att markera “vilket serienummer som helst”.

ACCESS SERIAL
ADMIN 4900 2394 7113 7304
ANVÄNDARE *

Exempel 2:  

Administratören och den server som QlikView kör som ett batchjobb får ADMIN-behörighet. Övriga inom domänen får USER-rätttigheter när de skriver in “USER” som identitet och lösenord.

ACCESS SERIAL NTDOMAINSID USERID LÖSENORD
ADMIN * S-1-5-21-125976590-467238106-1092489882 ADMIN ADMIN
ADMIN 4900 2394 7113 7304 * * *
ANVÄNDARE * S-1-5-21-125976590-467238106-1092489882 ANVÄNDARE ANVÄNDARE

Behörighetskontroll för vissa QlikView-funktioner

Kontrollerna som finns på sidan Dokumentegenskaper: Säkerhet och på sidan Arkegenskaper: Säkerhet gör det möjligt att förhindra åtkomst till vissa menyalternativ och förbjuda layoutändringar. För att dessa inställningar ska kunna användas som säkerhetsåtgärder är det emellertid viktigt att dokumentanvändarna har endast USER-rättigheter. Alla som har ADMIN-rättigheter kan när som helst ändra säkerhetsinställningarna.

Användare med USER-rättigheter som har öppnat dokumentet har inte tillgång till sidan Säkerhet i dialogen Egenskaper.

Dynamisk datareduktion

QlikView och QlikView Server stöder en funktion som gör att användaren kan förhindras att se delar av datamängden i ett dokument baserat på section access-inloggningen.

För det första kan fält (kolumner) döljas med hjälp av systemfältet OMIT.

För det andra kan register (rader) döljas genom att länka Section Access-data till reell data: Valet av värden som ska visas/uteslutas styrs genom att ha ett eller flera fält med gemensamma namn i section access och section application. När användaren har loggat in, kopierar QlikView de valda fältvärdena i section access till fält i section application med samma fältnamn (fältnamnen måste skrivas med VERSALER). Efter att valen har gjorts kommer QlikView permanent att dölja de data som till följd av de kopierade valen blivit uteslutna för användaren.

För att denna procedur ska kunna äga rum måste alternativet Reducerad datamängd p.g.a. section access på sidan Dokumentegenskaper: Öppning väljas. Om denna funktion används i dokument som distribueras på annat sätt än via QlikView Server måste alternativet Förbjud binär laddning på samma sida i dialogen Dokumentegenskaper vara valt för att dataskyddet ska vara intakt.

Observera: Alla fältnamn som används i överföringen, liksom namnen på alla fältvärden i dessa fält, måste skrivas med versaler, eftersom regeln är att fältnamn och namn på fältvärden konverteras till versaler i section access.

Exempel:  

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;

Fältet REDUCTION (versaler) finns nu både i section access och section application (alla fältvärden skrivs också i versaler). De båda fälten skulle normalt vara helt olika och separata, men om alternativet Reducerad datamängd enligt Section Access är valt länkas de samman och reducerar antalet poster som visas för användaren.

Fältet OMIT i section access anger de fält som ska döljas för användaren.

Resultatet blir då följande:

Användare A kan se alla fält, men endast de poster som är kopplade till REDUCTION=1.

Användare B kan se alla fält, utom NUM, och endast de poster som är kopplade till REDUCTION=2.

Användare C kan se alla fält, utom ALPHA, och endast de poster som är kopplade till REDUCTION=3.

Ärvda behörigheter

Om en binary-sats används kommer behörighetskontrollen att ärvas av det nya QlikView-dokumentet. En person med ADMIN-rättigheter till detta nya dokument kan göra en ändring i behörighetslistan till dokumentet genom att lägga till en ny behörighetssektion (access). En person med USER-rättigheter kan exekvera skriptet och göra ändringar i det (genom att lägga till egna data till filen som laddats med en binary-sats). En användare med USER-rättighet kan emellertid inte ändra behörigheter. På detta sätt bibehålls säkerheten och databasadministratören kan styra behörigheter även till de QlikView-dokument som inleds med en binary-sats.

Kryptering

Kommunikationen mellan QlikView Server och en QlikView-klient i Windows är krypterad. Om däremot AJAX-klienten används är kommunikationen inte krypterad.

Dessutom slumpkodas alla QlikView-dokument, vilket gör att informationen inte går att läsa med visningsprogram, felsökningsprogram etc.

Hjälpte den här informationen?

Tack för att du berättar det här. Är det något du vill säga om det här avsnittet?

Varför var informationen inte till hjälp och hur kan vi förbättra den?