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

Alla fältnamn och fältvärden som listas i avsnittsåtkomst konverteras alltid till versaler. Till följd av detta måste alla fält som ingår i en datareduktion konverteras till versaler för att matcha det som anges i avsnittsåtkomstsatsen, även om de finns utanför avsnittsåtkomstsatsen. Du kan konvertera alla fältnamn som skrivits med gemener i databasen 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.

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, ];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 Cloud-användarnamn. Qlik Cloud 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 aktivitetscentret för Administration.

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 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 Cloud 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 Cloud 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 Cloud. Qlik Cloud hämtar uppgifterna från “groups”-anspråket i identitetsleverantören och jämför dem med värdet i detta fält.

Den här funktionaliteten är inte tillgänglig i Qlik Sense Business, Qlik Cloud-analys standard eller när du använder Qlik-identitetsleverantör (IdP).

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

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.

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.

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.

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, 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 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.
Användaren AD_DOMAIN\DEV tillåts se alla data i alla fält.

Qlik Cloud 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 Cloud

Om du vill ladda en app utan datareduktion i Qlik Cloud 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 Cloud:

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 Cloud 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 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- eller SAML-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	USA
USER	*	JOE.SMITH@EXAMPLE.COM	Access-in-cloud	USA
USER	ABC\URSULA	*	Access-on-prem	Tyskland
USER	*	URSULA.SCHULTZ@EXAMPLE.COM	Access-in-cloud	Tyskland
USER	ABC\STEFAN	*	Access-on-prem	Sverige
USER	*	STEFAN.SVENSSON@EXAMPLE.COM	Access-in-cloud	Sverige

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 Cloud igen auktoriseringsfält från QlikView. Även om USERID tolkas olika i QlikView och Qlik Cloud, kommer det att tolkas på samma sätt i Qlik Cloud som i Qlik Sense: det kommer att 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 Cloud 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 Cloud ska du tänka på följande:

• USERID har olika betydelse i QlikView och Qlik Cloud. 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 Cloud. Om du använder dessa fält i Section Access, kan åtkomst nekas i Qlik Cloud.

• PASSWORD, NTSID och NTDOMAINSID kan inte användas i Qlik Cloud. Åtkomst kommer att nekas om du inte använder ett jokertecken.

• SERIAL kan inte användas för att kontrollera licensnummer i Qlik Cloud. 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 Cloud), och rad 2 beviljar åtkomst i Qlik Cloud (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 Cloud.

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.

Det finns en visuell demonstration av hur du använder avsnittsåtkomst och Insight Advisor Chat i:

Använda avsnittsåtkomst och Insight Advisor Chat

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 inkluderar appar i utrymmen som användare har åtkomst till. De kan inkludera appar som användare inte har åtkomst till i en apps avsnittsåtkomst. 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.

Gör följande:

Navigera till appen i Qlik Cloud.
Klicka på på appen och välj Detaljer.
Välj indexanvändaren under Indexanvändare.
Klicka på Tillbaka.
Klicka på på appen och välj Ladda.

Använda QVD-filer med avsnittsåtkomst

QVD-filer kan läsas som vanlig laddning eller optimerad laddning. En optimerad laddning innebär att inga dataomvandlingar sker under laddningen och att det inte finns några filter i någon WHERE-sats.

Optimerade laddningar fungerar inte om QVD-filer används med avsnittsåtkomst Om du vill använda en QVD-fil för att ladda data i avsnittsåtkomst måste du expandera QVD-filen. Enklaste sättet att expandera en QVD-fil är att ändra formatering när data laddas.

I följande exempel expanderas inte QVD-filen eftersom ingen formatering görs av data.

Exempel: Exempel som inte fungerar utan formatering av data (optimerad laddning).

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd);

I stället kan du exempelvis använda funktionen upper() för att formatera data som kommer att expandera QVD-filen.

Exempel: Exempel som fungerar med formatering av data

section access; LOAD ACCESS, USERID, PASSWORD, upper([GROUP]) as [GROUP] FROM SAccess.qvd (qvd);

Du kan även lägga till en Where 1=1-sats i LOAD-satsen.

Exempel: Ytterligare ett exempel som fungerar med formatering av data

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd) where 1=1;

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 fältvärden som listas i avsnittsåtkomst konverteras alltid till versaler. Till följd av detta måste alla fält som ingår i en datareduktion konverteras till versaler för att matcha det som anges i avsnittsåtkomstsatsen, även om de finns utanför avsnittsåtkomstsatsen. Du kan konvertera alla fältnamn som skrivits med gemener i databasen 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.

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