Hantera datasäkerhet med Section Access

Section Access används för att styra säkerheten för en app. Detta är en del av dataladdningsskriptet där du lägger till en säkerhetstabell som definierar vem som får se vad. Qlik Sense använder den här informationen för att reducera data till lämplig omfattning när användaren öppnar programmet, dvs. en del av data i appen döljs för användare baserat på deras identiteter. Section Access är nära integrerat med data i appen och är beroende av dessa för att styra åtkomsten. Den här typen av dynamisk datareduktion kan fokusera på tabellrader, tabellkolumner eller båda. Mer information finns i Trust and Security at Qlik (Förtroende och säkerhet hos Qlik).

Delavsnitt i laddningsskriptet

Kontroll av dataåtkomst styrs av en eller flera säkerhetstabeller som laddas på vanligt sätt. Därför kan du lagra tabellerna i en standarddatabas eller i ett kalkylark. De skriptsatser som styr säkerhetstabellerna definieras i ett auktoriseringsdelavsnitt, som inleds av satsen Section Access i skriptet.

Om ett auktoriseringsdelavsnitt definieras i skriptet, måste den del av skriptet som laddar appdata placeras i ett annat delavsnitt som inleds med satsen Section Application.

Exempel:

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;

Observera att när du har gjort ändringar i laddningsskriptet måste du alltid ladda data för att ändringarna ska träda i kraft.

Section Access-systemfält

Behörighetsnivåerna tilldelas användarna i en eller flera säkerhetstabeller som laddas i Section Access-delen av skriptkoden. Dessa tabeller måste innehålla minst två systemfält: ACCESS, som är det fält som definierar behörighetsnivån, och USERID eller USER.EMAIL . Andra valfria systemfält kan läggas till beroende på det enskilda fallet. Hela uppsättningen av systemfält i Section Access beskrivs nedan.

ACCESS

Definierar vilken behörighet en viss användare ska ha.

Åtkomst till Qlik Sense-appar kan ges för specifika användare. I säkerhetstabellen kan användare få behörighetsnivåerna ADMIN eller USER. En användare med ADMIN-behörighet har tillgång till alla data i appen, om inte åtkomsten begränsas av säkerhetstabellen. En användare med USER-behörighet får endast tillgång till data i enlighet med definitionen i säkerhetstabellen. Om ingen giltig behörighetsnivå är tilldelad, kan användaren inte öppna appen.

Om Section Access används i ett laddningsscenario behöver INTERNAL\SA_SCHEDULER, som är användaren av schemaläggningstjänsten, ADMIN-behörighet för att göra laddningar. Exempel:

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

Om du inte vill använda kontot INTERNAL\SA_SCHEDULER finns information om en annan metod i Använda personifiering för att ladda data.

Om Section Access används i ett ODAG-scenario (on-demand-appgenerering) i mallappen måste INTERNAL\SA_API-användaren inkluderas som ADMIN i Section Access-tabellen. Exempel:

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

USERID

Innehåller en sträng som motsvarar ett Qlik Sense-domännamn och -användarnamn. Qlik Sense hämtar inloggningsuppgifterna från proxytjänsten och jämför dem med värdet i detta fält.

Ett jokertecken (*) tolkas som alla användare och ytterligare villkor specificeras i säkerhetstabellen. I följande säkerhetstabell kan till exempel användare som ingår i Qlik Sense Tenant Admins se alla listade REDUCTION-värden.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];

USERID och NTNAME använder samma autentiseringsuppgifter, så det är inte nödvändigt att kontrollera båda på samma rad i säkerhetstabellen. Skillnaden mellan fälten är att NTNAME även kontrollerar grupper.

NTNAME

NTNAME är ett äldre QlikView-fält och USERID bör användas om inte QlikView använder samma säkerhetstabell.

Ett fält som ska innehålla en sträng som motsvarar ett gruppnamn eller användarnamn för Windows NT-domän. Om ett annat autentiseringssystem används ska det innehålla namnet på en autentiserad användare. Qlik Sense hämtar inloggningsuppgifterna från operativsystemet och jämför dem med värdet i detta fält.

GROUP

Innehåller en sträng som motsvarar en grupp i Qlik Sense. Qlik Sense löser användaren som angetts av proxytjänsten gentemot denna grupp.

SERIAL

SERIAL är ett äldre QlikView-fält och används inte om du bara använder Qlik Sense.

Innehåller en sträng som motsvarar plattformen. Om fältet innehåller strängen ‘QLIKSENSE’ eller ett jokertecken ‘*’, kan åtkomst ges beroende på övriga fält i säkerhetstabellen.

Om fältet SERIAL innehåller ett licensnummer kommer raden Section Access att neka åtkomst till dokumentet. Den här inställningen är bara giltig i QlikView.

OMIT

Innehåller namnet på det fält som ska utelämnas för just den här användaren. Jokertecken kan användas och listan kan lämnas tom.

Du bör inte tillämpa OMIT på nyckelfält. De nyckelfält som utelämnas är synliga i datamodellvyn men innehåller är inte tillgängligt, vilket kan vara förvirrande för användaren. Tillämpning av OMIT på fält som inte används i någon visualisering kan dessutom leda till ofullständiga visualiseringar för användare som inte har tillgång till de fält som har utelämnats.

Hantera användares åtkomst till en app

Section access kan, i dess enklaste form, användas för att hindra specifika användare från åtkomst till en app. Användare nekas åtkomst till en app genom uteslutning. Ett specifikt användar-ID har alltså inte tillgång till en app om inte ID:t finns med i säkerhetstabellen. Det enda undantaget är om ett jokertecken (*) är tilldelat till USERID-fältet på en av raderna i säkerhetstabellen. I det här fallet innebär ett jokertecken att alla autentiserade användare har tillgång till appen. Här visas ett exempel på en säkerhetstabell som innehåller en lista med användar-ID:n:

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

Hantera användares åtkomst till specifika data i en app

Dynamisk datareduktion begränsar åtkomsten till rader och kolumner i datatabellerna i Qlik Sense-appar efter att en användare har fått behörighet att få tillgång till själva appen.

Hantera åtkomst till data på radnivå

Begränsa åtkomsten till data på radnivå genom att lägga till en datareduktionskolumn i säkerhetstabellen i behörighetsdelavsnittet av laddningsskriptet. Specifika poster (rader) kan döljas för användare genom att Section Access-data länkas till verkliga data: Vilka värden som ska visas respektive uteslutas styr du genom att använda ett eller flera reduktionsfält med samma namn i avsnitten för Section Access och Section Application i skriptkoden. När användaren har loggat in matchar Qlik Sense urvalen i reduktionsfält i access-avsnittet med fält i application-avsnittet som har exakt samma fältnamn (fältnamnen måste skrivas med versaler). Efter att urvalen har gjorts döljer Qlik Sense permanent de data som till följd av urvalen uteslutits för användaren. Om ett jokertecken (*) används som fältvärde i datareduktionskolumnen tolkas detta som att användaren ska ha åtkomst till poster som är associerade med alla valda reduktionsfält i säkerhetstabellen.

När Qlik Sense jämför reduktionsfältet i avsnittsåtkomst med fält i datamodellen förväntas följande beteenden:

Om ett fältvärde i datamodellen matchar reduktionsfältet i avsnittsåtkomst kommer appen att öppnas och visa data med anknytning till matchningen för den angivna användaren. Övriga data döljs.
Om det reducerande fältvärdet inte matchar något av värdena i datamodellen kommer appen inte att öppnas för en normal USER. Men den kommer att öppnas oreducerad för en användare som är markerad som ADMIN.

Vi rekommenderar inte att flera reducerande fält används i avsnittsåtkomst, eftersom andra åtkomstkombinationer än de avsedda då kommer att tillåtas.

Jokertecknet * i datareduktionskolumnen refererar bara till alla värden i säkerhetstabellen. Om det finns värden i Section Application som inte är tillgängliga i reduktionskolumnen i säkerhetstabellen, kommer dessa att reduceras.

Alla fältnamn som används i överföringen som beskrivs ovan, liksom alla fältvärden i dessa fält, måste skrivas med versaler, eftersom alla fältnamn och fältvärden som standard konverteras till versaler i behörighetsdelavsnittet.

Om du vill aktivera att skript kan laddas i en Qlik Management Console-uppgift, krävs som standard INTERNAL\SA_SCHEDULER-kontoanvändaren med ADMIN-åtkomst. Om du inte vill använda kontot INTERNAL\SA_SCHEDULER finns information om en annan metod i Använda personifiering för att ladda data.

Exempel: Datareduktion på radnivå baserad på användarens identitet

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;

I det här exemplet finns fältet REDUCTION (versaler) nu i både Section Access och Section Application (även alla fältvärden skrivs med versaler). De två fälten skulle normalt vara olika och åtskilda, men när Section Access används länkas dessa fält samman och minskar det antal poster som visas för användaren.

Resultatet blir:

Användare ADMIN kan se alla fält och endast de poster som andra användare kan se när REDUCTION = 1 eller REDUCTION =2.
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, men endast de poster som är kopplade till REDUCTION=2.
Användare C kan se alla fält och endast de poster som andra användare kan se när REDUCTION = 1 eller REDUCTION =2.

Hantera åtkomst till data på kolumnnivå

Begränsa åtkomsten till data på kolumnnivå genom att lägga till systemfältet OMIT i säkerhetstabellen i Section Access-skriptet. Följande exempel bygger på det tidigare exemplet som redan innehåller datareduktion på radnivå.

Exempel: Datareduktion på kolumnnivå baserad på användarens identitet

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;

OMIT-fältet i Section Access anger de fält som ska döljas för användaren.

Resultatet blir:

ADMIN-användare kan se alla fält och endast de poster som andra användare kan se i detta exempel, när REDUCTION är 1, 2 eller 3.
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 förutom NUM, och bara de poster som är kopplade till REDUCTION=2.
Användare C kan se alla fält förutom ALPHA, och bara de poster som är kopplade till REDUCTION=3.

För en del visualiseringar gäller minimikrav för data som måste uppfyllas innan de renderas. Därför kan meddelandet ”Ofullständig visualisering” visas när ett fält på kolumnnivå utelämnas från användarens datavy.

Hantera åtkomst till användargrupper

Section Access erbjuder alternativet att med gruppmedlemskap begränsa omfattningen av de data som användare kan se. Om du vill begränsa data med hjälp av användargrupper lägger du till fältnamnet GROUP i säkerhetstabellen i behörighetsdelavsnittet och definierar värden för fältet GROUP.

Exempel: Datareduktion baserad på användargrupper

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;

Resultatet blir:

Användare som tillhör ADMIN-gruppen tillåts att se alla fält och bara de poster andra användare kan se i det här exemplet när REDUCTION är 1, 2 eller 3.
Användare som tillhör A-gruppen tillåts se data som är kopplade till REDUCTION=1 i alla fält.
Användare som tillhör B-gruppen tillåts se data som är kopplade till REDUCTION=2, men inte i NUM-fältet.
Användare som tillhör C-gruppen tillåts se data som är kopplade till REDUCTION=3, men inte i ALPHA-fältet.
Användare som tillhör GROUP1-gruppen tillåts se data som är kopplade till REDUCTION=3 i alla fält.

Qlik Sense jämför användaren med UserID:t och matchar användaren mot grupperna i tabellen. Om användaren tillhör en grupp med åtkomstbehörighet eller om användaren matchar, så ges åtkomst till appen.

Använda personifiering för att ladda data

Som standard används det interna systemkontot SA_SCHEDULER för att köra laddningsuppgifter. Kontot har förhöjd behörighet och kan i princip använda vilken datakälla som helst. I QMC finns dock en inställning som använder personifiering för att köra laddningsuppgifter med appägarens behörighet istället för med det interna systemkontot. När den här inställningen konfigureras används appägaren och inte SA_SCHEDULER för laddningar, vilket innebär att du lägger till appägaren i Section Access-tabellen istället för SA_SCHEDULER. I en uppgiftskedja kan appar ha olika ägare där behörigheten till källor beror på varje ägares åtkomstbehörighet. Mer information finns i Tjänstekluster (endast på engelska).

Hantera användaråtkomst i en Multi-Cloud-miljö

I en Qlik Sense-multimolnmiljö ingår flera sätt att autentisera användare. Med Qlik Sense Enterprise on Windows verifieras ofta USERID i Section Access-säkerhetstabellen av proxytjänsten. I Qlik Cloud tar en identitetsleverantör den autentiseringsrollen. Därför kommer inte Section Access som är konfigurerat för en lokal miljö som Qlik Sense Enterprise on Windows att fungera i en molnmiljö.

Om en OIDC-identitetsleverantör (Qlik IdP eller anpassad IdP) används med Qlik Cloud, används subject claim för att identifiera användare när de loggar in. Med Section Access jämförs värdet i USERID-fältet i säkerhetstabellen med värdet för subject claim. När du konfigurerar klientorganisationen ska du försäkra dig om att SAM-kontonamnet mappas till subject claim för identitetsleverantören. Om till exempel SAM-kontonamnet är AD_DOMAIN\Dev anger du subject claim som AD_DOMAIN\Dev. Om du vill se värdet för IdP:ns subject claim lägger du till /api/v1/diagnose-claims efter klientorganisationens URL i webbläsaren, till exempel your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. I JSON-svaret kallas subject claim för sub.

Om du inte kan använda SAM-kontonamnet finns det ett annat sätt att autentisera en användare. Eftersom samma e-postadresser ofta används i olika miljöer kan du använda fältet USER.EMAIL istället för USERID i säkerhetstabellen. Här är ett exempel på hur säkerhetstabellen kan se ut:

ACCESS	USERID	USER.EMAIL	Kommentar	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

Behörighetsskript:

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 ];

Observera att varje användare har två poster: En för lokal åtkomst och en för åtkomst i molnet. Jokertecknen säkerställer att bara relevanta autentiseringsfält används. I det här exemplet används COUNTRY som datareduktionsfält.

Använda Section Access och Insight Advisor Chat

För att appar som använder Section Access ska bli tillgängliga i Insight Advisor Chat måste du se till att följande tjänstanvändare har administratörsbehörighet i Section Access-skriptet:

INTERNAL/sa_repository: Det gör Section Access-skriptet tillgängligt i lagringstjänsten för styrning av användaråtkomst.
INTERNAL/sa_scheduler: Det gör att appen kan laddas igen med QMC-uppgifter.

Om du har känslig information i appnamn, fältnamn eller namn på originalobjekt kan dessa exponeras genom att göra appar som använder Section Access tillgängliga för Insight Advisor Chat. Appförslag för frågor omfattar appar i strömmar som användare har åtkomst till. Dessa kan omfatta appar som användare inte har åtkomst till i en apps Section Access. Om dessa appar väljs kommer det dock inte att hända något. När du klickar på Dimensioner eller Mått för att visa de tillgängliga elementen från en app med Section Access kan användare se objekt som de inte har åtkomst till. Om användaren klickar på dessa element kommer det dock inte att visas några data.

Exempel:

Section Access; LOAD * inline [ USERID ,ACCESS INTERNAL\sa_repository ,ADMIN INTERNAL\sa_scheduler ,ADMIN DOMAINNAME\user1 ,ADMIN DOMAINNAME\user2 ,USER DOMAINNAME\user3 ,USER ];

När dessa användare är i Section Access-skriptet kan du göra appen tillgänglig för Insight Advisor Chat. När appen har laddats kommer appen att vara tillgänglig i Insight Advisor Chat.

Riktlinjer och tips för användning av Section Access

Här följer några viktiga fakta och användbara tips om Section Access.

Alla fältnamn och värden som listas i LOAD- eller SELECT-satser i åtkomstdelavsnittet måste skrivas med versaler. Fältnamn som skrivits med gemener i databasen bör konverteras till versaler med hjälp av funktionen Upper innan fältet läses med LOAD- eller SELECT-satserna.
Mer information finns här Upper - skript- och diagramfunktion.
Du kan inte använda Section Access-systemfältsnamnen som listas här som fältnamn i din datamodell.
Appar måste vara publicerade innan Section Access-kontroller används. Laddning av appen leder inte till att några nya eller ändrade Section Access-skript används.
En ögonblicksbild visar data i enlighet med behörigheten för den användare som tar ögonblicksbilden, och den kan sedan delas i en berättelse. När användarna går tillbaka till en visualisering från en berättelse för att se data i realtid i appen, blir de dock begränsade av sina egna behörigheter.
Tilldela inte originaldimensionsvärden färger om du använder Section Access eller arbetar med känsliga data, eftersom värdena kan exponeras av färgkonfigurationen.
Om du vill undvika att exponera data som kräver behörighet kan du ta bort alla bifogade filer med Section Access-inställningar innan du publicerar appen. Bifogade filer inkluderas när appen publiceras. Om den publicerade appen kopieras tas de bifogade filerna med i kopian. Om avsnittsåtkomstbehörigheter har tillämpats på de bifogade datafilerna bibehålls dock inte avsnittsåtkomstinställningarna när filerna kopieras, så användare av den kopierade appen kan se alla data i de bifogade filerna.
Ett jokertecken (*) tolkas som alla (listade) värden för fältet i tabellen. Om den används i något av systemfälten (USERID, GROUP) i en tabell som laddats i skriptets behörighetsavsnitt, tolkas den som alla (även inte listade) möjliga värden i detta fält.
Säkerhetsfält kan placeras i olika tabeller.
När data laddas från en QVD-fil går laddningen långsammare om funktionen Upper används.
Om du har låst dig själv ute från en app genom att ställa in Section Access kan du öppna appen utan data och redigera behörighetsdelavsnittet i dataladdningsskriptet. För att göra detta måste du ha behörighet att redigera och ladda dataladdningsskriptet.
Mer information finns här Öppna en app utan data.
Om en binary-sats används kommer behörighetskontrollen att ärvas av den nya Qlik Sense-appen.

Var den här sidan till hjälp för dig?

Om du hittar några fel på denna sida eller i innehållet – ett stavfel, ett steg som saknas eller ett tekniskt fel – berätta för oss så att vi kan blir bättre!

Lämna din feedback här