Direct Lake 보안 통합

Direct Lake 보안은 권한 있는 사용자만 OneLake에서 델타 테이블을 쿼리할 수 있도록 합니다. 작업 영역 역할을 통해 데이터 액세스 권한을 관리할 수 있습니다. 작업 영역 참가자, 구성원 및 관리자는 OneLake에서 데이터를 읽을 수 있습니다. 항목 수준 및 컴퓨팅 권한을 통해 OneLake의 데이터에 대한 액세스 권한을 부여할 수도 있습니다. 세 번째 옵션은 OneLake 보안을 활용하여 모든 패브릭 컴퓨팅 엔진에서 세분화된 역할 기반 보안을 적용하는 것입니다. 이 문서에서는 권한 모델을 정렬하고, SSO(Single Sign-On) 또는 고정 ID를 선택하고, OLS(개체 수준 보안) 및 RLS(행 수준 보안)를 활용하는 방법을 설명합니다. OneLake 보안 개요에서 자세히 알아보세요.

주요 개념 및 용어

이 문서에서는 다음과 같은 개념에 대해 잘 알고 있다고 가정합니다.

• Direct Lake는 의미 체계 모델 메타데이터의 공유 M 식을 사용하여 파워 쿼리 데이터 액세스 함수인 OneLake의 Direct Lake용 AzureStorage.DataLake 및 SQL 엔드포인트의 Direct Lake용 Sql.Database 를 통해 데이터 원본을 참조합니다. 그러나 Direct Lake는 이러한 함수를 사용하여 원본 델타 테이블을 읽지 않습니다. OneLake API를 통해 델타 테이블을 직접 읽습니다.
• 권한 있는 사용자만 데이터를 쿼리하도록 Direct Lake는 유효 ID의 데이터 액세스 권한을 확인합니다. 유효 ID는 데이터 연결 구성에 따라 달라집니다. 기본적으로 Direct Lake는 SSO(Microsoft Entra ID)를 사용하고 의미 체계 모델을 쿼리하는 현재 사용자의 ID를 사용합니다. Direct Lake 모델을 명시적 클라우드 연결에 바인딩하여 고정 ID를 제공할 수도 있습니다.
• 작업 영역 역할을 통해 데이터 액세스 권한을 부여하는 경우 기여자 역할(이상) 멤버만 OneLake에서 데이터를 읽을 수 있습니다. 그러나 작업 영역 뷰어는 OneLake에서 읽기 권한이 없습니다. 작업 영역 역할의 멤버가 아닌 뷰어와 사용자는 항목 권한, 컴퓨팅 권한 또는 OneLake 보안 역할의 조합을 통해 읽기 액세스를 얻을 수 있습니다.
• OneLake 보안을 사용하면 작업 영역 관리자 및 작업 영역 멤버 역할의 멤버가 뷰어 역할의 사용자에 대한 세분화된 역할 기반 보안을 정의할 수 있습니다. 뷰어 또는 명시적 읽기 권한이 있는 사용자가 특정 행 또는 열에 액세스하고 제외할 수 있는 테이블을 지정합니다. OneLake 보안 역할에 대한 자세한 내용은 OneLake의 테이블 보안, OneLake의 열 수준 보안 및 OneLake의 RLS를 참조하세요.

연결 구성

Direct Lake 모델에 대한 데이터 연결을 다른 의미 체계 모델 형식과 동일한 방식으로 구성합니다. 자세한 내용은 Power BI 서비스의 클라우드 데이터 원본에 연결을 참조하세요.

Direct Lake는 패브릭 데이터 원본에만 연결되므로 기본 SSO(Microsoft Entra ID) 구성이 일반적으로 작동하므로 의미 체계 모델을 명시적 데이터 연결에 바인딩할 필요가 없습니다. 이 방법은 구성 복잡성을 줄이고 관리 오버헤드를 줄입니다.

SSO(Microsoft Entra ID)를 사용하여 Direct Lake는 의미 체계 모델을 쿼리하는 현재 사용자가 데이터에 대한 읽기 권한이 있는지 확인합니다. 읽기 권한이 있는 사용자만 데이터를 쿼리할 수 있습니다. 다음 스크린샷은 기본 SSO 구성을 사용하는 Direct Lake 모델을 보여 줍니다.

SSO 대신 고정 ID로 명시적 데이터 연결을 사용하는 경우 Direct Lake에서 모든 사용자가 기본 데이터에 대한 읽기 권한을 가질 필요가 없습니다. Microsoft Entra SSO가 데이터 연결에서 비활성화된 상태로 유지되는 경우 고정 ID의 권한에 따라 Direct Lake에서 액세스할 수 있는 데이터가 결정됩니다.

인증 요구 사항

Direct Lake 모델은 Microsoft Entra ID 인증을 사용합니다. 데이터 연결 구성에서 인증 방법으로 OAuth 2.0, 서비스 주체 또는 작업 영역 ID 를 선택합니다. 키 또는 SAS 인증과 같은 다른 방법은 구성 UI에 나타날 수 있지만 Direct Lake 모델에는 지원되지 않습니다.

사용 권한 요구 사항

사용 권한 요구 사항은 SQL 엔드포인트의 Direct Lake와 OneLake의 Direct Lake 간에 다릅니다. 이는 SQL 엔드포인트의 Direct Lake가 대상 데이터 원본의 SQL 분석 엔드포인트를 사용하는 반면 OneLake의 Direct Lake는 권한 검사를 위해 OneLake API를 사용하기 때문입니다.

SQL 엔드포인트에서의 Direct Lake

SQL 엔드포인트의 Direct Lake는 SQL 분석 엔드포인트를 통해 권한 검사를 수행하여 데이터에 액세스하려는 유효 ID에 필요한 데이터 액세스 권한이 있는지 여부를 확인합니다. 특히 유효 ID는 OneLake에서 델타 테이블을 직접 읽을 수 있는 권한이 필요하지 않습니다. 패브릭 아티팩트(예: 레이크하우스)에 대한 읽기 권한과 SQL 분석 엔드포인트를 통한 테이블에 대한 SELECT 권한만 있으면 충분합니다. 패브릭은 의미 체계 모델에 델타 테이블 및 관련 Parquet 파일을 읽는 데 필요한 권한을 부여하기 때문입니다( 열 데이터를 메모리로 로드하기 위해). 의미 체계 모델에는 쿼리 사용자(또는 고정 ID)가 액세스할 수 있는 데이터를 확인하기 위해 SQL 분석 엔드포인트를 주기적으로 읽을 수 있는 권한이 있습니다.

OneLake의 Direct Lake

OneLake의 Direct Lake는 권한 검사에 SQL 분석 엔드포인트를 사용하지 않습니다. OneLake Security를 사용합니다. OneLake Security를 사용하도록 설정하면 OneLake의 Direct Lake는 현재 사용자(또는 고정 ID)를 사용하여 OneLake 보안 역할을 해결하고 대상 패브릭 아티팩트에서 OLS 및 RLS를 적용합니다. OneLake Security가 활성화되지 않은 경우, OneLake의 Direct Lake는 OneLake의 델타 테이블에 접근하기 위해 대상 패브릭 아티팩트에 대해 효과적인 신원이 읽기 및 모두 읽기 권한을 갖추어야 합니다. 읽기 및 읽기 모두 권한에 대한 자세한 내용은 OneLake 보안 개요 문서의 항목 권한 섹션을 참조하세요.

Direct Lake 사용자

다음 시나리오에서는 최소 권한 요구 사항을 나열합니다.

자세한 내용은 의미 체계 모델 사용 권한참조하세요.

Direct Lake 소유자

유효한 ID(현재 사용자 또는 고정 ID) 외에도 Direct Lake는 의미 체계 모델 소유자가 원본 테이블에 대한 읽기 액세스 권한을 갖도록 요구하므로 Direct Lake는 데이터 새로 고침의 일부로 의미 체계 모델을 구성할 수 있습니다. Direct Lake 모델을 새로 고치는 사용자에 관계없이 Direct Lake는 소유자의 권한을 확인하여 모델이 데이터에 액세스할 수 있는지 확인합니다. 소유자의 데이터 액세스 권한 요구 사항은 모델을 쿼리하는 사용자와 동일합니다.

의미 체계 모델 소유자에게 필요한 데이터 액세스 권한이 없는 경우 Direct Lake는 프레이밍 중에 다음 오류를 발생합니다. We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

원본 테이블의 바로 가기

바로 가기는 패브릭 레이크하우스 또는 다른 패브릭 아티팩트에서 내부 또는 외부 스토리지 위치를 가리키도록 추가하는 OneLake 개체입니다. Direct Lake 모델에서 바로 가기를 통해 추가된 델타 테이블은 OneLake API를 통해 데이터에 액세스할 때 바로 가기가 투명하기 때문에 연결된 패브릭 구성 요소에서 네이티브로 표시됩니다.

SQL 엔드포인트를 통해 Direct Lake를 통해 바로 가기에 액세스하는 경우 Direct Lake는 먼저 유효 ID(현재 사용자 또는 고정 ID)가 의미 체계 모델의 데이터 원본에 있는 테이블에 액세스할 수 있는지 확인합니다. 내부 바로 가기의 경우 검증이 통과한 후, Direct Lake는 데이터 소스 소유자의 ID를 사용하여 테이블의 패브릭 아티팩트에 있는 바로 가기를 통해 델타 테이블을 읽습니다. 데이터 원본 소유자는 대상 OneLake 위치에 대한 액세스 권한이 있어야 합니다. 외부 바로 가기의 경우 데이터 원본 소유자는 델타 테이블을 호스트하는 외부 시스템에 대한 클라우드 연결에 대한 사용 권한도 필요합니다. 자세한 내용은 OneLake 바로 가기를 참조하세요.

SQL Analytics 엔드포인트가 관련되지 않기 때문에 Direct Lake의 사용 권한 요구 사항은 OneLake에서 다릅니다. 사용자가 다른 OneLake 위치에 대한 내부 바로 가기를 통해 데이터에 액세스하는 경우 유효 ID(현재 사용자 또는 고정 ID)에는 대상 위치에 대한 권한이 있어야 합니다. 유효 ID는 참가자(이상)이어야 하며, 읽기 및 전체 읽기 권한을 가지거나 읽기 접근을 부여하는 OneLake 보안 역할에 속해야 합니다.

OLS(개체 수준 보안) 및 RLS(행 수준 보안)

OneLake 보안 및 Direct Lake 모델 모두 OLS 및 RLS를 지원합니다. OLS를 사용하면 아티팩트 소유자와 관리자가 특정 테이블 또는 열을 보호할 수 있습니다. RLS를 사용하여 필터에 따라 행 수준에서 데이터 액세스를 제한할 수 있습니다. OneLake Security, Direct Lake 모델 또는 두 위치 모두에서 OLS 및 RLS를 정의할 수 있습니다.

OneLake 보안 OLS/RLS를 적용한 OneLake OLS/RLS의 Direct Lake

OneLake의 Direct Lake는 유효 ID의 OneLake 보안 역할을 확인하고 정의된 OLS/RLS 규칙을 적용하여 OLS/RLS 보안 개체에 대한 액세스를 평가합니다. OneLake 보안 역할은 Direct Lake 역할과 동일하게 처리됩니다. 유효 ID가 OneLake 보안 및 Direct Lake의 여러 역할에 속하는 경우 Direct Lake는 먼저 OneLake 보안 역할을 통합한 다음 결과를 Direct Lake 역할과 교차합니다.

이 표에서는 OneLake 보안 및 Direct Lake 규칙 충돌로 인한 일반적인 문제 해결 상황을 나열합니다.

OLS/RLS 범위 차이

OneLake Security에서 OLS 및 RLS를 적용하면 모든 컴퓨팅 엔진에 규칙이 적용되고 사용자에 대한 통합 액세스 제어가 보장됩니다. 즉, 컴퓨팅 엔진(레이크하우스, 웨어하우스, 의미 체계 모델 또는 기타 아티팩트)에 관계없이 OneLake 보안 규칙이 사용자의 데이터 액세스를 제어합니다. 반면 Direct Lake 의미 체계 모델 내에 정의된 OLS/RLS는 해당 모델의 범위 내에서만 적용됩니다. 다른 컴퓨팅 엔진은 사용자가 다른 경로를 통해 데이터에 액세스할 때 다른 결과를 생성할 수 있는 이러한 Direct Lake 보안 규칙을 적용하지 않습니다.

OneLake OLS 및 의미 체계 모델 메타데이터

의미 체계 모델 메타데이터에는 테이블, 열, 관계 및 기타 스키마 요소의 정의가 포함됩니다. 빌드 이상의 권한이 있는 사용자는 XMLA(XML for Analysis) 및 REST API를 통해 모델 메타데이터를 볼 수 있습니다. 자세한 내용은 의미 체계 모델 사용 권한참조하세요.

OneLake OLS를 사용하여 OneLake에서 중요한 테이블 및 열 이름을 보호하려면 OneLake 보안이 작업 영역 뷰어 역할의 멤버에게만 적용된다는 점을 기억하세요. OneLake OLS는 모든 작업 영역 아티팩트의 쓰기 권한이 이미 있으므로 기여자(또는 그 이상) 작업 영역 역할의 멤버가 보안 테이블 또는 열을 검색하는 것을 방지하지 않습니다. Direct Lake 모델에 대한 빌드 이상의 권한이 있는 뷰어 역할의 멤버는 의미 체계 모델 메타데이터를 통해 중요한 스키마 정보를 검색할 수 있습니다. 이러한 높은 권한의 뷰어는 여전히 데이터 액세스 권한이 없지만 보안 테이블과 열이 존재하는 것을 볼 수 있습니다.

Direct Lake 모델은 원본 아티팩트 또는 별도의 작업 영역과 동일한 작업 영역에 있을 수 있습니다. 항목 권한을 통해 동일한 작업 영역 빌드 (또는 그 이상)의 뷰어에게 Direct Lake 모델에 대한 액세스 권한을 부여합니다. 별도의 작업 영역에서 사용자는 기여자(이상) 또는 모델 메타데이터에 액세스할 수 있는 빌드 (또는 그 이상) 항목 권한이 있을 수 있습니다.

OneLake OLS 및 Git 통합

Git 통합을 통해 개발자는 ALM(애플리케이션 수명 주기 관리) 프로세스를 Fabric 플랫폼에 통합할 수 있습니다. Git 리포지토리는 지원되는 모든 아티팩트를 포함하여 작업 영역 구조를 유지합니다. 개발자는 Git 리포지토리에 있는 모든 항목의 메타데이터를 완전히 볼 수 있습니다. Direct Lake 모델 메타데이터를 사용하면 다른 작업 영역의 대상 데이터 원본에 액세스할 수 없는 경우에도 보안 테이블 또는 열이 존재하는 것을 볼 수 있습니다. 자세한 정보를 확인하려면 Microsoft Fabric Git 통합이란?을 참조하세요.

고려사항 및 제한사항

이러한 Direct Lake 보안 제한 사항을 고려합니다.

• OneLake 보안 역할을 작업 영역 뷰어에게 할당하여 원본 Fabric 아티팩트에 대한 읽기 권한을 부여합니다. 원본 아티팩트의 다른 패브릭 아티팩트 바로 가기가 있는 경우 사용자는 각 바로 가기의 대상 패브릭 아티팩트에도 대한 읽기 액세스 권한이 필요합니다.
• 고정 ID를 사용하여 원본 패브릭 아티팩트에서 사용자를 격리합니다. Direct Lake 모델을 클라우드 연결에 바인딩합니다. 새로 고침 및 쿼리에 고정 ID를 사용하려면 클라우드 연결에서 SSO를 사용하지 않도록 설정합니다.
• 원본 아티팩트에서 Fabric OneLake 보안을 사용하는 Direct Lake 의미 체계 모델은 백업 작업을 지원하지 않습니다.
• 원본 패브릭 아티팩트가 OneLake 보안 RLS를 사용하는 경우 Direct Lake 모델에서는 양방향 관계가 지원되지 않습니다.
• 공개 미리 보기 중에 OneLake 보안은 단일 테이블에서 정적 RLS만 지원합니다.
• 공개 미리 보기 중에 OneLake 보안은 관련된 테이블에서 여러 OLS 및 RLS 역할을 결합하는 것과 같은 동적 정의 또는 복잡한 역할 구성을 지원하지 않습니다.
• OneLake 보안 RLS 및 OLS 권한을 여러 역할을 할당하는 대신 사용자당 하나의 역할로 통합합니다.
• 대상 아티팩트에서 바로 가기 변경으로 인해 OneLake 보안 구성이 변경되는 경우 해당 아티팩트 액세스하는 OneLake 모델에서 Direct Lake를 새로 고칩니다. 자동 동기화를 사용하는 경우 서비스는 일반적으로 자동으로 새로 고칩니다. 그렇지 않으면 모델을 수동으로 새로 고칩니다.
• 레이크하우스에 OneLake 보안이 있는 경우:
  • SQL 분석 엔드포인트는 기본적으로 Lakehouse 소유자에 대한 고정 ID이므로 SQL 분석 엔드포인트 OneLake 보안은 소유자와 동일합니다(제한 없음). 추가 SQL 세분화된 액세스 역할이 추가되지 않는 한 SQL의 Direct Lake는 Direct Lake를 계속 사용합니다.
  • SQL 분석 엔드포인트를 SSO로 변경할 수 있습니다. 이 경우 OneLake 보안 역할은 SQL 세분화된 액세스 제어 규칙으로 추가되고 사용자는 SQL 분석 엔드포인트에서 직접 편집할 수 없습니다. 이 시점에서는 SQL의 Direct Lake가 항상 DirectQuery로 돌아갑니다.