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 SaaS 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, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ]; 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.

USERID

Innehåller en sträng som motsvarar ett Qlik Sense SaaS-användarnamn. Qlik Sense SaaS hämtar inloggningsuppgifterna från IdP-subjektet och jämför dem med värdet i detta fält. Information om ett sätt att verifiera användaridentiteten med e-postadress finns i USER.EMAIL. För multimolnmiljöer kan IdP-subjektet mappas till din interna Windows-identitet. När Qlik Account används kan inte subjektet mappas till en intern Windows-identitet. Användar-IdP-subjektet kan visas i delavsnittet Användare i Management Console.

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 ... ];
Anteckning om information 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

Anteckning om informationNTNAME ä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 NetBIOS-versionen av 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 SaaS hämtar inloggningsuppgifterna från subject-anspråket i identitetsleverantören och jämför dem med värdet i detta fält.

USER.EMAIL

Innehåller en sträng som motsvarar en användares e-postadress. Qlik Sense SaaS hämtar den här informationen från identitetsleverantören och jämför den med värdet i detta fält.

GROUP

Innehåller en sträng som motsvarar en grupp i Qlik Sense SaaS. Qlik Sense SaaS hämtar uppgifterna från “groups”-anspråket i identitetsleverantören och jämför dem med värdet i detta fält.

Anteckning om informationAnvändargrupper stöds inte i Qlik Sense Business eller när Qlik Identity Provider (IdP) används.

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.

Anteckning om informationDu 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

En användare med USERID AD_DOMAIN\C skulle inte kunna öppna appen alls eftersom det användar-ID:t inte listas i säkerhetstabellen.

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. En specifik användar-e-postadress har alltså inte tillgång till en app om inte e-postadressen finns med i säkerhetstabellen. Det enda undantaget är om ett jokertecken (*) är tilldelat till USER.EMAIL-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, USER.EMAIL ADMIN, USER1@example.com USER, USER2@example.com USER, USER3@example.com ]; Section Application;

En användare med USER.EMAIL USER4@example.com skulle inte kunna öppna appen alls eftersom den användar-e-postadressen inte listas i säkerhetstabellen.

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.

Anteckning om information

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.

Anteckning om informationAlla 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.

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

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 USER, USER4@example.com, * ]; 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 USER1@example.com kan se alla fält och endast de poster som andra användare kan se när REDUCTION = 1 eller REDUCTION =2.
  • Användare USER2@example.com kan se alla fält, men endast de poster som är kopplade till REDUCTION=1.
  • Användare USER3@example.com kan se alla fält, men endast de poster som är kopplade till REDUCTION=2.
  • Användare USER4@example.com 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, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; 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:

  • USER1@example.com-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 USER2@example.com kan se alla fält, men endast de poster som är kopplade till REDUCTION=1.
  • Användare USER3@example.com kan se alla fält förutom NUM, och bara de poster som är kopplade till REDUCTION=2.
  • Användare USER4@example.com kan se alla fält förutom ALPHA, och bara de poster som är kopplade till REDUCTION=3.
Anteckning om informationFö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, AD_DOMAIN\DEV, *, *, ]; 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.
  • Användaren AD_DOMAIN\DEV tillåts se alla data i alla fält.

Qlik Sense SaaS 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.

Ladda data i Qlik Sense SaaS

Om du vill ladda en app utan datareduktion i Qlik Sense SaaS rekommenderas att du använder systemfältet USER.EMAIL i säkerhetstabellen. Värdet för fältet USER.EMAIL ska vara e-postadressen för användare som kan redigera och ladda appen. Detta gäller appar i både delade och hanterade utrymmen. Exempel:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, test@example.com, * ];

I det här exemplet är användaren med e-postadressen test@example.com ADMIN och kan ladda appen.

Om du använder grupper skulle följande exempel fungera i både Qlik Sense och Qlik Sense SaaS:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, Developers, * ];

Du kan även mappa USERID i säkerhetstabellen till subject claim för identitetsleverantören, på det sätt som visas i exemplet som följer. Den här konfigurationen föreslås för migrering från Qlik Sense till Qlik Sense SaaS och för Multi-Cloud-miljöer. Mer information om hur du mappar USERID till subject claim finns i Hantera användaråtkomst i en Multi-Cloud-miljö

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

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 Sense SaaS 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 Sense SaaS, 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.

Auktoriseringsfält från QlikView

För att ge bakåtkompatibilitet känner Qlik Sense SaaS igen auktoriseringsfält från QlikView. Även om USERID tolkas olika i QlikView och Qlik Sense SaaS, kommer det att tolkas på samma sätt i Qlik Sense SaaS som i Qlik Sense: Det matchas mot namnet på den autentiserade användaren.

PASSWORD, NTSID och NTDOMAINSID

Om ett av fälten PASSWORD, NTSID eller NTDOMAINSID används och det innehåller ett relevant värde, nekas åtkomst till dokumentet. Om fältet innehåller ett jokertecken (*) kan åtkomst ges beroende på övriga fält i behörighetstabellen.

SERIAL

Om fältet SERIAL används och innehåller ett licensnummer kommer raden Section Access att neka åtkomst till dokumentet. Om fältet innehåller ett jokertecken (*) kan åtkomst ges beroende på övriga fält i behörighetstabellen.

I Qlik Sense SaaS kan detta fält även användas för att definiera miljön. Det innebär att om fältet innehåller strängen ”QLIKCLOUD” kan åtkomst ges beroende på övriga fält i behörighetstabellen.

Blandade miljöer

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

USERID har olika betydelse i QlikView och Qlik Sense SaaS. Säkerhetsproblem kan uppstå om du använder det. Använd NTNAME istället eller kombinera med SERIAL så som beskrivs nedan.

GROUP och fält som börjar med ”USER.”, som ”USER.NAME” och ”USER.EMAIL”, är (eller kommer att bli) auktoriseringsfält i Qlik Sense 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 kommer att nekas om du inte använder ett jokertecken.

SERIAL kan inte användas för att kontrollera licensnummer i Qlik Sense SaaS. Om detta fält innehåller strängen ”QLIKCLOUD” kan dock åtkomst beviljas. Det innebär att du kan ha en säkerhetstabell som nedanstående, 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).

Säkerhetstabell
Rad SERIAL USERID Kommentar
1 4600 0123 4567 8901 * Beviljar åtkomst till korrekt licensnummer i QlikView.
2 QLIKCLOUD John Doe Beviljar åtkomst till korrekt användare i Qlik Sense SaaS.

Behörighetsskript:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, John Doe, QLIKCLOUD ];

Använda Section Access och Insight Advisor Chat

Appar som använder Section Access använder en indexanvändare för att avgöra hur mycket information Insight Advisor Chat ska hämta från appen. Indexanvändaren ska vara den användare som har den högsta åtkomstnivån till appen i Section Access-skriptet. Data som tillhandahålls till slutanvändarna styrs dock fortfarande av Section Access-begränsningarna.

Anteckning om varning

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.

Som standard är appägaren också indexanvändaren. Du kan ändra indexanvändare i Detaljer.

  1. Navigera till appen i Qlik Cloud.

  2. Klicka på Mer på appen och välj Detaljer.

  3. Välj indexanvändaren under Indexanvändare.

  4. Klicka på Tillbaka.

  5. Klicka på Mer på appen och välj Ladda.

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-satsen.

    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.