Gå till huvudinnehåll

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 begränsa data till rätt omfattning när användaren öppnar programmet, dvs. vissa data i appen döljs för användaren baserat på dennes identitet. 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.

Observera: Insight Advisor Chat har inte stöd för appar som använder Section Access.

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 i skriptet inleds av satsen Section Access.

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.

Example:  

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 ... ];
Observera: 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

Observera: 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

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

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

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

Observera:

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.

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

Example: 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å.

Example: 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.
Observera: 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.

Example: 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 se alla data och alla fält.
  • 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 och löser användaren mot grupper 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 SaaS editions of Qlik Sense 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 SaaS editions of Qlik Sense, 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. Till exempel, om 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.

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ält som listas i LOAD- eller SELECT-satser i behörighetsdelavsnittet 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 i 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 i Öppna en app utan data.

  • Om en binary-sats används kommer behörighetskontrollen att ärvas av den nya Qlik Sense-appen.