Section Access를 사용하여 데이터 보안 관리

Section Access를 사용하여 응용 프로그램의 보안을 제어합니다. 기본적으로 보안 테이블을 추가하여 누가 무엇을 보게 되는지 정의하는 데이터 로드 스크립트의 일부입니다. Qlik Cloud 사용자가 응용 프로그램을 열 때 는 이 정보를 사용하여 데이터를 적절한 범위로 줄입니다. 즉, 앱의 일부 데이터는 ID를 기반으로 사용자에게 숨겨집니다. Section Access는 앱의 데이터와 긴밀하게 통합되며, 이에 따라 액세스를 제어합니다. 이러한 형태의 동적 데이터 축소는 테이블 행, 열 또는 둘의 조합을 대상으로 할 수 있습니다. 자세한 내용은 Qlik의 신뢰 및 보안을 참조하십시오.

로드 스크립트의 섹션

데이터 액세스 제어는 일반적으로 데이터를 로드하는 것과 동일한 방식으로 로드한 하나 이상의 보안 테이블을 통해 관리됩니다. 따라서 이러한 테이블을 표준 데이터베이스 또는 스프레드시트에 저장할 수 있습니다. 보안 테이블을 관리하는 스크립트 문은 스크립트에서 Section Access 문으로 시작하는 인증 섹션 내에 지정됩니다.

Section Access에 나열된 모든 필드 이름과 필드 값은 항상 대문자로 변환됩니다. 결과적으로, 데이터 축소의 일부인 모든 필드는 Section Access 문 외부에 있더라도 Section Access 문에 명시된 내용과 일치하도록 대문자로 변환되어야 합니다. 데이터베이스에서 소문자를 포함한 필드 이름은 LOAD 또는 SELECT 문으로 필드를 읽기 전에 Upper 함수를 사용하여 대문자로 변환할 수 있습니다.

자세한 내용은 Upper - 스크립트 및 차트 함수를 참조하십시오.

스크립트에 인증 섹션이 정의되어 있는 경우 앱 데이터를 로드하는 스크립트 부분은 Section Application 문으로 시작하는 다른 섹션에 지정해야 합니다.

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;

로드 스크립트를 변경한 후 변경 사항을 적용하려면 항상 데이터를 다시 로드해야 합니다.

Section Access 시스템 필드

액세스 수준은 Section Access 내에서 로드되는 하나 이상의 보안 테이블에서 사용자에게 할당됩니다. 이러한 테이블에는 최소한 두 개의 시스템 필드가 포함되어야 합니다. 액세스 수준을 정의하는 필드인 ACCESS 및 USERID 또는 USER.EMAIL . 다른 선택적 시스템 필드는 사용 사례에 따라 추가될 수 있습니다. 전체 Section Access 시스템 필드 집합에 대한 설명이 아래에 나와 있습니다.

ACCESS

해당 사용자에게 있어야 하는 액세스 권한을 정의합니다.

지정된 사용자에 대해 Qlik Sense 앱에 대한 액세스 권한을 부여할 수 있습니다. 보안 테이블에서 사용자에게 ADMIN 또는 USER 액세스 수준을 할당할 수 있습니다. ADMIN 권한이 있는 사용자는 보안 테이블로 제한되지 않는 한 앱의 모든 데이터에 액세스할 수 있습니다. USER 권한이 있는 사용자는 보안 테이블에 정의된 데이터에만 액세스할 수 있습니다. 유효한 액세스 수준이 할당되지 않은 사용자는 앱을 열 수 없습니다.

USERID

Qlik Cloud 사용자 이름에 해당하는 문자열이 포함되어 있습니다. Qlik Cloud는 IdP 주체에서 로그인 정보를 가져와서 이 필드의 값과 비교합니다. 이메일 주소를 사용하여 사용자 ID을 다른 방법으로 확인하려면 USER.EMAIL을 참조하십시오. Multi-Cloud 환경의 경우 내부 Windows ID에 대해 IdP 주체를 매핑할 수 있습니다. Qlik Account 사용 시에는 내부 Windows ID에 대해 주체를 매핑할 수 없습니다. 사용자 IdP 주제는 관리 활동 센터의 사용자 섹션에서 볼 수 있습니다.

와일드카드 문자(*)는 보안 테이블에 지정된 추가 조건에 따라 모든 사용자로 해석됩니다. 예를 들어 다음 보안 테이블에서 Qlik Sense Tenant Admins에 있는 사용자는 나열된 모든 REDUCTION 값을 볼 수 있습니다.

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

USERID 및 NTNAME 둘 다 동일한 인증 정보를 사용하므로 보안 테이블의 동일한 행에서 둘 다 확인할 필요가 없습니다. 두 필드의 차이는 NTNAME이 그룹도 확인한다는 점입니다.

NTNAME

NTNAME은 레거시 QlikView 필드이며 QlikView에서 동일한 보안 테이블을 사용하지 않는 경우 USERID를 사용하는 것이 좋습니다.

NetBIOS 버전의 Windows NT 도메인 사용자 이름 또는 그룹 이름에 해당하는 문자열을 포함해야 하는 필드입니다. 다른 인증 시스템을 사용하는 경우 인증된 사용자의 이름을 포함해야 합니다.

Qlik Cloud는 ID 공급자의 subject 클레임에서 로그온 정보를 가져와서 이 필드의 값과 비교합니다.

USER.EMAIL

사용자 이메일 주소에 해당하는 문자열을 포함합니다. Qlik Cloud는 ID 공급자에서 이 정보를 가져와서 이 필드의 값과 비교합니다.

GROUP

Qlik Cloud의 그룹에 해당하는 문자열이 포함되어 있습니다. Qlik Cloud는 ID 공급자의 “groups” 클레임에서 정보를 가져와서 이 필드의 값과 비교합니다.

이 기능은 Qlik Sense Business 또는 Qlik Cloud Analytics 표준에서 사용할 수 없으며, 또한 Qlik IdP(ID 공급자)를 사용할 때에도 사용할 수 없습니다.

OMIT

이 특정 사용자에 대해 생략할 필드의 이름이 포함되어 있습니다. 와일드카드가 사용될 수 있으며 필드는 비워둘 수 있습니다.

키 필드에 OMIT를 적용하지 않는 것이 좋습니다. 생략된 키 필드는 데이터 모델 뷰어에 표시될 수 있지만 사용자에게 혼란을 줄 수 있어 콘텐츠는 사용할 수 없습니다. 또한 시각화에서 사용되는 필드에 OMIT를 적용하면 생략된 필드에 액세스 권한이 없는 사용자에게는 시각화가 불완전할 수 있습니다.

앱에 대한 사용자 액세스 관리

USERID AD_DOMAIN\C가 있는 사용자는 해당 사용자 ID가 보안 테이블에 나열되지 않기 때문에 앱을 전혀 열 수 없습니다.

가장 간단한 형태의 Section Access는 특정 사용자가 앱에 액세스하지 못하도록 제한하는 데 사용할 수 있습니다. 사용자는 제외를 통해 앱에 대한 액세스가 거부됩니다. 다시 말해, 특정 사용자 이메일 주소가 보안 테이블에 나열되지 않으면 앱에 액세스할 수 없습니다. 이 규칙의 유일한 예외는 보안 테이블의 행 중 하나에 있는 USER.EMAIL 필드에 와일드카드(*)가 지정된 경우입니다. 이 경우 와일드카드는 인증된 모든 사용자가 앱에 액세스할 수 있음을 의미합니다. 다음은 사용자 ID 목록이 있는 보안 테이블의 예입니다.

Section Access; LOAD * inline [ ACCESS, USER.EMAIL ADMIN, USER1@EXAMPLE.COM USER, USER2@EXAMPLE.COM USER, USER3@EXAMPLE.COM ]; Section Application;

USER.EMAIL USER4@example.com을 사용하는 사용자는 해당 사용자 이메일 주소가 보안 테이블에 나열되지 않기 때문에 앱을 전혀 열 수 없습니다.

앱의 특정 데이터에 대한 사용자 액세스 관리

동적 데이터 축소는 사용자가 앱 자체에 액세스할 수 있는 권한이 부여된 후 Qlik Sense 앱 내 데이터 테이블의 행과 열에 대한 액세스를 제한합니다.

행 수준 데이터에 대한 액세스 관리

로드 스크립트의 액세스 섹션에 있는 보안 테이블에 데이터 축소 열을 추가하여 행 수준 데이터에 대한 액세스를 제한합니다. 특정 레코드(행)는 Section Access 데이터를 실제 데이터와 연결하여 숨길 수 있습니다. 표시하거나 제외할 데이터의 선택은 스크립트의 Section Access 및 섹션 응용 프로그램 부분에 공통 이름을 가진 하나 또는 여러 개의 축소 필드를 포함하여 제어됩니다. 사용자 로그인 후 Qlik Sense는 액세스 섹션의 축소 필드 선택을 정확하게 동일한 필드 이름(필드 이름은 대문자로 작성되어야 함)으로 응용 프로그램 섹션의 필드에 일치시킵니다. 선택이 완료되면 Qlik Sense는 이러한 선택에 의해 제외된 모든 데이터를 해당 사용자에게 영구적으로 숨깁니다. 와일드카드(*)가 데이터 축소 열의 필드 값으로 사용되는 경우 사용자가 보안 테이블에서 선택한 모든 축소 필드와 연관된 레코드에 액세스할 수 있도록 허용하는 것으로 해석됩니다.

Qlik Sense는 Section Access의 감소 필드를 데이터 모델의 필드와 비교할 때 다음 동작이 예상됩니다.

데이터 모델의 필드 값이 Section Access의 감소 필드와 일치하면 앱이 열리고 지정된 사용자의 일치와 관련된 데이터가 표시됩니다. 다른 데이터는 숨겨집니다.
감소하는 필드 값이 데이터 모델의 값과 일치하지 않으면 일반 사용자에 대해 앱이 열리지 않습니다. 그러나 ADMIN으로 표시된 사용자에게는 축소되지 않은 상태로 열립니다.

Section Access에서 여러 감소 필드를 사용하는 것은 의도한 것 이외의 다른 액세스 조합을 허용하므로 권장되지 않습니다.

데이터 축소 열의 와일드카드 문자(*)는 보안 테이블의 모든 값만 참조합니다. 보안 테이블의 축소 열에서 사용할 수 없는 섹션 응용 프로그램에 값이 있는 경우에는 값이 줄어듭니다.

액세스 섹션에서는 모든 필드 이름 및 필드 값이 기본적으로 대문자로 변환되므로 위에서 설명한 전송에 사용된 모든 필드 이름과 이 필드의 모든 필드 값은 대문자여야 합니다.

사용자 ID를 기반으로 행 수준 데이터 축소

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;

이제 필드 REDUCTION(대문자)이 Section Access 및 섹션 응용 프로그램 모두에 있습니다(모든 필드 값도 대문자임). 두 필드는 일반적으로 다르고 별개이지만 Section Access를 사용할 경우 서로 연결되어 사용자에게 표시되는 레코드 수가 축소됩니다.

결과는 다음과 같습니다.

사용자 USER1@EXAMPLE.COM은 모든 필드를 볼 수 있으며 REDUCTION = 1 또는 REDUCTION =2일 때 다른 사용자가 볼 수 있는 레코드만 볼 수 있습니다.
사용자 USER2@EXAMPLE.COM은 모든 필드를 볼 수 있지만 REDUCTION=1에 연관된 레코드만 해당됩니다.
사용자 USER3@EXAMPLE.COM은 모든 필드를 볼 수 있지만 REDUCTION=2에 연관된 레코드만 해당됩니다.
사용자 USER4@EXAMPLE.COM은 모든 필드를 볼 수 있으며 REDUCTION = 1 또는 REDUCTION =2일 때 다른 사용자가 볼 수 있는 레코드만 볼 수 있습니다.

열 수준 데이터에 대한 액세스 관리

Section Access 스크립트의 보안 테이블에 OMIT 시스템 필드를 추가하여 열 수준 데이터에 대한 액세스를 제한합니다. 다음 예는 이미 행 데이터 축소가 있는 이전 예를 기반으로 합니다.

사용자 ID를 기반으로 열 데이터 축소

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;

Section Access에서 OMIT 필드는 사용자에게 숨겨야 하는 필드를 정의합니다.

결과는 다음과 같습니다.

사용자 USER1@example.com은 모든 필드와 더불어, REDUCTION이 1, 2 또는 3일 때 다른 사용자가 이 예에서 볼 수 있는 레코드를 볼 수 있습니다.
사용자 USER2@example.com은 모든 필드를 볼 수 있지만 REDUCTION=1에 연관된 레코드만 해당됩니다.
사용자 USER3@example.com은 NUM를 제외한 모든 필드와 REDUCTION=2과 연관된 레코드만 볼 수 있습니다.
사용자 USER4@example.com은 ALPHA를 제외한 모든 필드와 REDUCTION=3과 연관된 레코드만 볼 수 있습니다.

일부 시각화는 최소 데이터 요구 사항을 충족해야 렌더링할 수 있습니다. 결과적으로 열 수준 필드가 사용자의 데이터 보기에서 생략되면 "불완전한 시각화"가 표시될 수 있습니다.

사용자 그룹에 대한 액세스 관리

Section Access는 그룹 구성원 자격을 통해 사용자에게 표시되는 데이터 범위를 제한하는 옵션을 제공합니다. 사용자 그룹을 사용하여 데이터를 제한하려면 액세스 섹션의 보안 테이블에 GROUP 필드 이름을 추가하고 GROUP 필드에 대한 값을 정의합니다.

사용자 그룹을 기반으로 데이터 축소

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;

결과는 다음과 같습니다.

ADMIN 그룹에 속한 사용자는 모든 필드를 볼 수 있으며 REDUCTION이 1, 2 또는 3일 때 이 예에서 다른 사용자가 볼 수 있는 레코드만 볼 수 있습니다.
A 그룹에 속한 사용자는 모든 필드에서 REDUCTION=1에 연결된 데이터를 볼 수 있습니다.
B 그룹에 속한 사용자는 NUM 필드를 제외하고 REDUCTION=2에 연관된 데이터를 볼 수 있습니다.
C 그룹에 속한 사용자는 ALPHA 필드를 제외하고 REDUCTION=3에 연관된 데이터를 볼 수 있습니다.
GROUP1 그룹에 속한 사용자는 모든 필드에서 REDUCTION=3에 연관된 데이터를 볼 수 있습니다.
AD_DOMAIN\DEV 사용자는 모든 필드의 모든 데이터를 볼 수 있습니다.

Qlik Cloud는 사용자를 UserID와 비교하고 테이블의 그룹에 대해 사용자를 확인합니다. 액세스가 허용되는 그룹에 사용자가 속하거나 사용자가 일치하는 경우 앱에 액세스할 수 있습니다.

Qlik Cloud에서 데이터 다시 로드

Qlik Cloud에서 데이터 축소 없이 앱을 다시 로드하려면 보안 테이블에서 USER.EMAIL 시스템 필드를 사용하는 것이 좋습니다. USER.EMAIL 필드 값은 앱을 편집하고 로드할 수 있는 사용자의 이메일 주소여야 합니다. 이는 공유 공간과 관리 공간 모두에 있는 앱에 적용됩니다. 예:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, TEST@EXAMPLE.COM, * ];

이 예에서 이메일 주소가 test@example.com인 사용자는 ADMIN이며 앱을 다시 로드할 수 있습니다.

그룹을 사용하는 경우 다음 예는 Qlik Sense와 Qlik Cloud 모두에 대해 동일하게 작동합니다.

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

다음 예와 같이 보안 테이블의 USERID를 ID 공급자의 subject claim에 매핑할 수도 있습니다. 이 구성은 Qlik Sense에서 Qlik Cloud로의 마이그레이션과 Multi-Cloud 환경에 사용하는 것이 좋습니다. USERID를 subject claim에 매핑하는 방법에 대한 자세한 내용은 Multi-Cloud 환경에서 사용자 액세스 관리를 참조하십시오.

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

Multi-Cloud 환경에서 사용자 액세스 관리

Qlik Sense Multi-Cloud 환경에는 사용자 인증 메커니즘이 혼합되어 있습니다. 일반적으로 Qlik Sense Enterprise on Windows를 사용하여 프록시 서비스가 Section Access 보안 테이블의 USERID를 확인합니다. Qlik Cloud에서는 ID 공급자가 해당 인증 역할을 수행할 것입니다. 결과적으로 Qlik Sense Enterprise on Windows와 같은 온프레미스 환경에 대해 설정된 Section Access는 클라우드 환경에서 작동하지 않습니다.

Qlik Cloud와 함께 OIDC 또는 SAML ID 공급자(Qlik IdP 또는 사용자 지정 IdP)를 사용하는 경우 subject claim은 로그인할 때 사용자를 식별하는 데 사용됩니다. Section Access를 사용하면 보안 테이블의 USERID 필드 값이 subject claim 값과 비교됩니다. 테넌트를 설정하는 경우 SAM 계정 이름이 ID 공급자의 subject claim에 매핑되는지 확인합니다. 예를 들어 SAM 계정 이름이 AD_DOMAIN\Dev인 경우 subject claim을 AD_DOMAIN\Dev로 설정합니다. IdP의 subject claim 값을 보려면 브라우저의 테넌트 URL에 /api/v1/diagnose-claims를 추가합니다(예: your-tenant.us.qlikcloud.com/api/v1/diagnose-claims). JSON 응답에서 subject claim은 sub라고 합니다.

SAM 계정 이름을 사용할 수 없는 경우 사용자를 인증하는 다른 방법이 있습니다. 이메일 주소는 다른 환경에서 동일하게 유지되는 경향이 있으므로 보안 테이블에서 USERID 대신 USER.EMAIL 필드를 사용할 수 있습니다. 다음은 보안 테이블의 예입니다.

ACCESS	USERID	USER.EMAIL	주석	COUNTRY
사용자	ABC\JOE	*	Access-on-prem	미국
사용자	*	JOE.SMITH@EXAMPLE.COM	Access-in-cloud	미국
사용자	ABC\URSULA	*	Access-on-prem	독일
사용자	*	URSULA.SCHULTZ@EXAMPLE.COM	Access-in-cloud	독일
사용자	ABC\STEFAN	*	Access-on-prem	스웨덴
사용자	*	STEFAN.SVENSSON@EXAMPLE.COM	Access-in-cloud	스웨덴

인증 스크립트:

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

각 사용자에게는 두 개의 레코드가 있습니다. 하나는 온프레미스 액세스용이고 다른 하나는 클라우드 액세스용입니다. 와일드카드를 사용하면 관련 인증 필드만 사용되도록 합니다. 이 예에서 COUNTRY는 데이터 축소 필드로 사용됩니다.

QlikView 인증 필드

하위 호환성을 위해 Qlik Cloud는 QlikView에서 인증 필드를 인식합니다. USERID는 QlikView 및 Qlik Cloud에서 다르게 해석되지만 Qlik Cloud에서는 Qlik Sense에서와 동일한 방식으로 해석됩니다. 인증된 사용자의 이름과 일치합니다.

PASSWORD, NTSID 및 NTDOMAINSID가 있는 차트의 속성 패널

PASSWORD, NTSID 및 NTDOMAINSID 필드 중 하나가 사용되고 관련 값이 포함된 경우 문서에 대한 액세스가 거부됩니다. 필드에 와일드카드(*)가 포함된 경우 인증 테이블의 다른 필드에 따라 액세스가 부여될 수 있습니다.

SERIAL

SERIAL 필드가 사용되고 라이센스 번호가 포함된 경우 Section Access 행은 문서에 대한 액세스를 거부합니다. 필드에 와일드카드(*)가 포함된 경우 인증 테이블의 다른 필드에 따라 액세스가 부여될 수 있습니다.

또한 Qlik Cloud에서 이 필드를 사용하여 환경을 정의할 수도 있습니다. 즉, 필드에 문자열 ‘QLIKCLOUD’가 포함된 경우 인증 테이블의 다른 필드에 따라 액세스가 부여될 수 있습니다.

혼합 환경

QlikView 및 Qlik Cloud에서 동일한 보안 테이블을 사용하려면 다음 사항에 유의합니다.

• USERID는 QlikView 및 Qlik Cloud에서 의미가 다르므로 사용 시 보안 문제가 발생할 수 있습니다. 대신 NTNAME을 사용하거나 아래 설명된 대로 SERIAL과 조합하여 사용합니다.

• GROUP 및 ‘USER.’로 시작하는 필드(예: 'USER.NAME' 및 'USER.EMAIL')는 Qlik Cloud의 인증 필드입니다. Section Access에서 이러한 필드를 사용할 경우 Qlik Cloud에서 액세스가 거부될 수 있습니다.

• PASSWORD, NTSID 및 NTDOMAINSID는 Qlik Cloud에서 사용할 수 없습니다. 와일드카드를 사용하지 않으면 액세스가 거부됩니다.

• SERIAL은 Qlik Cloud에서 라이센스 번호를 확인하는 데 사용할 수 없습니다. 하지만 이 필드에 무자열 ‘QLIKCLOUD’가 포함된 경우 액세스가 부여될 수 있습니다. 즉, 다음과 같은 보안 테이블에서 1행은 QlikView에서 액세스가 부여되고(Qlik Cloud에서는 안 됨) 2행은 Qlik Cloud에서 액세스가 부여됩니다(QlikView에서는 안 됨).

보안 테이블
선	SERIAL	USERID	주석
1	4600 0123 4567 8901	*	QlikView에서 올바른 라이센스 번호에 액세스를 부여합니다.
2	QLIKCLOUD	JOHN DOE	Qlik Cloud에서 올바른 사용자에게 액세스를 부여합니다.

인증 스크립트:

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

Section Access 및 Insight Advisor Chat 사용

Section Access를 사용하는 앱은 인덱스 사용자를 사용하여 Insight Advisor Chat가 앱에서 검색하는 정보의 양을 결정합니다. 인덱스 사용자는 Section Access 스크립트에서 앱에 대한 최고 수준의 액세스 권한을 가진 사용자여야 합니다. 그러나 최종 사용자에게 제공되는 데이터는 여전히 Section Access 제한에 의해 제어됩니다.

Section Access 및 Insight Advisor Chat을 사용하는 방법에 대한 시각적 데모는 다음을 참조하십시오.

Section Access 및 Insight Advisor Chat 사용

앱 이름, 필드 이름 또는 마스터 항목 이름에 중요한 정보가 있는 경우 Section Access를 사용하는 앱을 Insight Advisor Chat에 사용할 수 있게 하여 이러한 정보가 노출될 수 있습니다. 쿼리에 대한 앱 제안에는 사용자가 액세스할 수 있는 공간의 앱이 포함됩니다. 여기에는 사용자가 앱의 Section Access에 액세스할 수 없는 앱이 포함될 수 있습니다. 그러나 이러한 앱을 선택하면 아무 작업도 수행되지 않습니다. Section Access를 사용하여 앱에서 사용 가능한 항목을 보기 위해 차원 또는 측정값을 클릭하면 사용자가 액세스 권한이 없는 항목을 볼 수 있습니다. 그러나 이러한 항목을 클릭해도 사용자에게 데이터가 제공되지 않습니다.

기본적으로 앱 소유자는 인덱스 사용자입니다. 세부 정보에서 인덱스 사용자를 변경할 수 있습니다.

다음과 같이 하십시오.

Qlik Cloud에서 앱으로 이동합니다.
앱에서 을 클릭하고 세부 정보를 선택합니다.
인덱스 사용자에서 인덱스 사용자를 선택합니다.
뒤로를 클릭합니다.
앱에서 을 클릭하고 다시 로드를 선택합니다.

Section Access와 함께 QVD 사용

QVD 파일은 일반 로드 또는 최적화된 로드로 읽을 수 있습니다. 로드 중에 데이터 변환이 이루어지지 않고 WHERE 절에 필터가 없는 경우 로드가 최적화됩니다.

Section Access가 포함된 QVD를 사용하는 경우 최적화된 로드가 작동하지 않습니다. QVD 파일을 사용하여 Section Access에 데이터를 로드하려면 QVD 파일을 확장해야 합니다. QVD 파일을 확장하는 가장 쉬운 방법은 데이터를 로드할 때 형식 지정을 변경하는 것입니다.

다음 예에서는 데이터에 형식 지정이 적용되지 않았으므로 QVD 파일이 확장되지 않습니다.

데이터 형식이 지정되지 않아 작동하지 않는 예(최적화된 로드)

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

대신, 예를 들어, upper() 함수를 사용하여 QVD 파일을 확장할 데이터 형식을 지정할 수 있습니다.

데이터 형식 지정을 사용한 실제 예

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

LOAD 문에 Where 1=1 문을 추가할 수도 있습니다.

데이터 형식 지정을 사용한 또 다른 실제 예

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

Section Access 사용에 대한 지침 및 팁

다음은 Section Access에 대해 알아야 할 몇 가지 중요한 사실과 유용한 힌트입니다.

Section Access에 나열된 모든 필드 이름과 필드 값은 항상 대문자로 변환됩니다. 결과적으로, 데이터 축소의 일부인 모든 필드는 Section Access 문 외부에 있더라도 Section Access 문에 명시된 내용과 일치하도록 대문자로 변환되어야 합니다. 데이터베이스에서 소문자를 포함한 필드 이름은 LOAD 또는 SELECT 문으로 필드를 읽기 전에 Upper 함수를 사용하여 대문자로 변환할 수 있습니다.
자세한 내용은 Upper - 스크립트 및 차트 함수를 참조하십시오.
데이터 모델에서 필드 이름으로 나열된 Section Access 시스템 필드 이름을 사용할 수 없습니다.
Section Access 제어가 적용되기 전에 앱을 게시해야 합니다. 앱을 다시 로드해도 새 Section Access 스크립트 또는 변경된 Section Access 스크립트가 적용되지 않습니다.
스냅샷은 스냅샷을 만드는 사용자의 액세스 권한에 따라 데이터를 표시하며, 스토리에서 공유될 수 있습니다. 그러나 사용자가 앱에서 라이브 데이터를 보기 위해 스토리에서 시각화로 되돌아가면 자체 액세스 권한에 따라 제한됩니다.
Section Access를 사용하거나 중요한 데이터로 작업할 경우에는 값이 색 구성에 의해 노출될 수 있으므로 마스터 차원 값에 색을 지정해서는 안 됩니다.
제한된 데이터를 노출하지 않으려면 앱을 게시하기 전에 Section Access 설정이 있는 모든 첨부 파일을 제거합니다. 앱이 게시될 때 첨부 파일이 포함됩니다. 게시된 앱을 복사하는 경우 복사본에 첨부 파일이 포함됩니다. 하지만 첨부된 데이터 파일에 Section Access 제한이 적용된 경우, 파일을 복사할 때 Section Access 설정이 유지되지 않으므로 복사된 앱 사용자는 첨부된 파일에서 모든 데이터를 볼 수 있습니다.
와일드카드(*)는 테이블에 있는 필드의 (나열된) 모든 값으로 해석됩니다. 스크립트의 액세스 섹션에서 로드된 테이블의 시스템 필드(USERID, GROUP) 중 하나에서 사용된 경우 이 필드에 사용 가능한(나열되지 않은) 모든 값으로 해석됩니다.
보안 필드를 다른 테이블에 넣을 수 있습니다.
QVD 파일에서 데이터를 로드할 경우 Upper 함수를 사용하면 로딩 속도가 저하됩니다.

이 페이지가 도움이 되었습니까?

이 페이지 또는 해당 콘텐츠에서 오타, 누락된 단계 또는 기술적 오류와 같은 문제를 발견하면 개선 방법을 알려 주십시오!

여기에 피드백을 남겨주십시오.