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å kan det 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ällt 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 bara ser egna data.

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 bara publiceras 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 använder du QMC och lägger till följande attribut i avsnittet för dokumentinformation i ett användardokument:

• 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örighet på radnivå styrs av en eller flera säkerhetstabeller som laddas på samma sätt som data laddas normalt. På så sätt kan du lagra tabellerna i en vanlig databas eller i ett kalkylblad. Skriptsatserna som hanterar säkerhetstabellerna deklareras i ett behörighetsdelavsnitt, som i skriptet börjar med satsen Section Access.

Om ett behörighetsdelavsnitt deklareras i skriptet, måste den del av skriptet som laddar appdata placeras i ett annat delavsnitt som börjar med satsen Section Application.

Exempel:  

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.

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. Därför krävs alltså inte att du använder USERID – det kan räcka med en kontroll av exempelvis serienumret.

 

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.

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.

Ett jokertecken (*) tolkas som alla (listade) värden för ett fält, det vill säga ett värde som listats någon annanstans i den här tabellen. 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.

Exempel 1:  

Endast serienumret 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”.

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ättigheter när de skriver in ”USER” som identitet och lösenord.

Blandade miljöer

Om du planerar att använda samma behörighetstabell i QlikView och Qlik Sense SaaS ska du tänka på följande:

• USERID har olika innebörd i QlikView och Qlik Sense SaaS, och kan orsaka säkerhetsproblem om det används. Använd NTNAME i stället eller kombinera det med SERIAL enligt beskrivningen nedan.

• GROUP och fält som inleds med ”USER.”, som till exempel ”USER.NAME” och ”USER.EMAIL”, autentiserar (eller kommer att autentisera) fält i Qlik Sense Enterprise SaaS. Om du använder dessa fält i Section Access kan åtkomst nekas i Qlik Sense SaaS.

• PASSWORD, NTSID och NTDOMAINSID kan inte användas i Qlik Sense SaaS. Åtkomst nekas om inte ett jokertecken används.

• SERIAL kan inte användas för kontroll av licensnummer i Qlik Sense SaaS. Åtkomst kan dock beviljas om fältet innehåller någon av strängarna ”QLIKCLOUD” eller ”QLIKVIEW”. Det innebär att behörighetstabellen kan se ut som nedan, där rad 1 beviljar åtkomst i QlikView (men inte i Qlik Sense SaaS), och rad 2 beviljar åtkomst i Qlik Sense SaaS (men inte i QlikView).

 

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.

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,

RecNo() 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.

Du kan även kryptera känsliga data i QVD-filer med nyckelpar som tillhandahålls av kunden, vilket gör det möjligt att kontrollera vem som får åtkomst till dina data. Mer information finns i QVD-kryptering (endast på engelska).