OneLake 보안은 누가 OneLake 내 데이터에 접근할 수 있는지, 그리고 그 데이터에 대해 어떤 조치를 취할 수 있는지 결정하는 역할 기반 시스템입니다. 데이터 접근 제어 모델을 이해하면 사용자에게 필요한 접근만 허용할 수 있어, 민감한 데이터를 보호하면서도 적절한 사람들이 다룰 수 있도록 할 수 있습니다.
이 글에서는 OneLake 보안 역할이 어떻게 구조화되는지, 작업 공간 및 아이템 권한과 어떻게 통합되는지, OneLake가 데이터 접근 권한을 어떻게 적용하고 해결하는지, 그리고 주의해야 할 제한사항을 설명합니다.
OneLake 보안 역할
OneLake 보안은 OneLake 내 데이터 접근을 관리하기 위해 역할 기반 접근 제어(RBAC) 모델을 사용합니다. OneLake 보안 경험에서 각 역할은 다음과 같은 구성 요소를 포함합니다:
- 권한: 해당 역할이 데이터에 부여하는 권한, 예를 들어 읽기(Read 또는 ReadWrite)입니다.
- 유형: 역할 유형. OneLake 보안은 회원들이 역할 내 데이터에 접근할 수 있도록 하는 그랜트 역할만 지원합니다. 접근 권한을 제거하는 거부 역할은 지원하지 않습니다.
- 역할 내 데이터: 역할이 접근 권한을 부여하는 테이블, 폴더 또는 스키마들. 테이블에 대해 행 및 열 수준의 보안을 적용한 데이터 접근을 정의할 수도 있습니다.
- 역할 구성원: 역할에 할당된 Microsoft Entra 신원, 예를 들어 사용자, 그룹, 비사용자 식별 등. Microsoft Entra 그룹을 할당하면 OneLake 보안이 그룹 내 모든 구성원에게 해당 역할을 부여합니다.
OneLake 보안은 기본적으로 거부 모델을 사용하므로, 사용자는 OneLake 보안 역할이 명시적으로 접근 권한을 부여하지 않는 한 데이터에 접근할 수 없습니다. 일부 Fabric 항목은 사용자가 작업 공간 권한에 따라 기본 접근 권한을 주는 기본 역할로 시작합니다.
사용 권한 및 지원되는 항목
OneLake 보안 역할은 다음과 같은 권한을 지원합니다:
-
읽다: 사용자에게 테이블에서 데이터를 읽고 연결된 테이블 및 열 메타데이터를 볼 수 있는 기능을 부여합니다. SQL에서 이 권한은
SELECT및VIEW_DEFINITION둘 다와 동등합니다. 자세한 내용은 메타데이터 보안을 참조하세요. -
읽기 쓰기: 사용자가 테이블이나 폴더의 데이터를 읽고 쓰고 관련 테이블 및 열 메타데이터를 볼 수 있는 기능을 제공합니다. SQL 용어로는 이 권한은
DROP,UPDATE,INSERT, 및ALTER와 같습니다. 자세한 내용은 ReadWrite 권한을 참조하세요.
다음 Fabric 항목에 대해 OneLake 보안 역할을 생성할 수 있습니다:
| 직물 항목 | 지원되는 권한 |
|---|---|
| 레이크하우스 | 읽기, 읽기/쓰기 |
| Azure Databricks 미러링된 카탈로그 | 읽기 |
| 미러된 데이터베이스 | 읽기 |
| 미러링된 카탈로그 | 읽기 |
읽기쓰기 권한
읽기 쓰기 권한을 사용하여 항목 내 특정 데이터에 대해 읽기 전용 사용자에게 쓰기 권한을 부여합니다.
ReadWrite는 항목에 대해 읽기 권한을 가진 사용자, 예를 들어 뷰어 작업 공간 역할을 가진 사용자에게만 적용됩니다. 워크스페이스 관리자, 멤버, 기여자에게 ReadWrite를 할당해도 효과가 없는데, 이 워크스페이스 역할들은 이미 쓰기 권한을 가지고 있기 때문입니다.
ReadWrite는 Read 권한으로 부여된 모든 권한을 포함하며, 선택한 객체와 그 내용에 대한 쓰기 권한도 부여합니다. 예를 들어, 폴더에 대한 ReadWrite 권한은 폴더와 그 안의 데이터 모두에 쓰기 권한을 부여합니다.
ReadWrite 권한을 가진 사용자는 다음과 같은 작업을 수행할 수 있습니다:
- 폴더나 테이블을 생성, 삭제 또는 이름 변경하세요.
- 파일을 업로드하거나 편집하세요.
- 단축키를 만들거나, 삭제하거나, 이름을 바꿔보세요.
사용자는 Spark 노트북, OneLake 파일 탐색기, 또는 OneLake API를 통해 쓰기 작업을 수행할 수 있습니다. Fabric은 데이터에 대한 단일 엔진 쓰기만 지원하기 때문에, 읽기 권한이 있는 사용자는 OneLake를 통해서만 해당 데이터에 쓸 수 있습니다. 모든 쿼리 엔진은 계속해서 읽기 연산을 일관되게 강제합니다.
읽기 권한을 부여하는 OneLake 보안 역할은 행 수준 보안(RLS) 또는 열 수준 보안(CLS) 제약을 포함할 수 없습니다.
OneLake 보안 및 작업 영역 권한
워크스페이스 역할은 OneLake에서 데이터의 첫 번째 보안 경계입니다. 제어 플레인을 관리하며 Fabric 항목과 권한을 생성하고 관리하며, 작업 공간 내 모든 항목에 적용됩니다. 각 워크스페이스 역할이 부여하는 특정 OneLake 권한에 대해서는 워크스페이스 역할로 접근 권한 부여를 참조하세요. 워크스페이스 역할에 대해 더 알고 싶다면 'Fabric의 워크스페이스에서 역할(Roles in workspaces in workspaces)'을 참조하세요.
제어 평면 접근 외에도, 워크스페이스 역할은 OneLake 보안 기본 역할을 통해 데이터 항목에 접근할 수 있습니다. (기본 역할은 뷰어에게만 적용되며, 관리자, 멤버, 기여자 역할은 작성 권한을 통해 권한을 상승 처리합니다.) 기본 역할은 Fabric이 새 항목마다 자동으로 생성하는 일반적인 OneLake 보안 역할입니다. 특정 작업 영역 또는 항목 권한이 있는 사용자에게 해당 항목의 데이터에 대한 기본 액세스 수준을 제공합니다. 예를 들어 Lakehouse 항목에는 ReadAll 권한이 있는 사용자가 Lakehouse의 데이터를 볼 수 있는 DefaultReader 역할이 있습니다. 이 기본 접근 권한은 새로 생성된 항목을 다루는 사용자가 기본 수준의 접근 권한을 갖도록 보장합니다. 모든 기본 역할은 멤버 가상화 기능을 사용하여, 역할의 구성원은 해당 작업 공간에 필요한 권한을 가진 모든 사용자가 됩니다. 예를 들어 Lakehouse에 대한 ReadAll 권한이 있는 모든 사용자입니다.
다음 표는 표준 기본 역할을 보여줍니다. 아이템은 해당 아이템 유형에만 적용되는 특수한 기본 역할을 가질 수 있습니다.
| 직물 항목 | 역할 이름 | 허가 | 할당된 멤버 |
|---|---|---|---|
| 레이크하우스 | DefaultReader |
읽기 | ReadAll 권한이 있는 모든 사용자 |
| Azure Databricks 미러링된 카탈로그 | DefaultReader |
읽기 | 읽기 권한이 있는 모든 사용자 |
| 미러링된 카탈로그 | DefaultReader |
읽기 | 읽기 권한이 있는 모든 사용자 |
| 미러된 데이터베이스 | DefaultReader |
읽기 | ReadAll 권한이 있는 모든 사용자 |
Fabric 항목에서 기본 역할을 수정하거나 제거할 수 있어 해당 회원 그룹의 사용자 접근 권한을 변경할 수 있습니다.
데이터에 대한 엔진 및 사용자 액세스
OneLake 보안은 기본적으로 최소 권한 접근 권한을 가지고 있습니다. 일부 스토리지 레벨 작업은 RLS나 CLS를 강제하지 못하므로, 쿼리가 안전하게 필터링되지 않을 때 OneLake는 사용자가 볼 수 없는 데이터를 노출할 위험을 피하기 위해 쿼리를 완전히 차단합니다. 쿼리가 필터링되거나 차단될지는 접근 경로(지원되는 쿼리 엔진 또는 직접 사용자 접근)에 따라 달라집니다.
RLS 및 CLS 필터링을 지원하는 엔진과 각각의 요구사항에 대해서는 OneLake 보안으로 보호된 데이터 읽기 항목을 참조하세요.
범위 및 집행
이 섹션에서는 OneLake 보안 역할이 특정 범위에 대한 액세스 권한을 부여하는 방법, 해당 액세스가 작동하는 방식 및 여러 역할 및 액세스 유형에서 액세스가 확인되는 방법에 대해 자세히 설명합니다.
테이블 수준 보안
OneLake는 모든 테이블을 폴더로 표현하지만, Fabric의 OneLake 보안 및 쿼리 엔진 관점에서 모든 폴더가 테이블인 것은 아닙니다. 유효한 테이블이 되려면 폴더가 다음 조건을 충족해야 합니다:
- 폴더는 아이템의 디렉터리에
Tables/존재합니다. 스키마 사용 항목의 경우 폴더도 유효한 스키마 폴더에 있어야 합니다. - 폴더에는 테이블 메타데이터에 해당하는 JSON 파일이 포함된 폴더가 있습니다
_delta_log. - 폴더에는 자식 바로가기가 전혀 없습니다.
테이블에 RLS 또는 CLS를 설정하면, 테이블의 폴더가 이 기준을 충족하지 못하면 OneLake가 접근을 거부합니다. RLS나 CLS가 없으면, OneLake는 이러한 기준을 충족하지 않는 폴더를 폴더로 간주하고 폴더 수준의 보안을 적용합니다.
행 수준 및 열 수준 보안
역할 내에서는 행 수준 보안과 열 수준 보안을 사용하여 테이블의 특정 행과 열에 대한 접근을 제한할 수 있습니다. 각 컨트롤이 무엇을 하는지, 그리고 OneLake가 이를 어떻게 강제하는지에 대한 자세한 내용은 OneLake의 Table, column, row-level 보안을 참조하세요. 사용자가 여러 역할에 속했을 때 RLS와 CLS가 어떻게 해결하는지에 대한 정보는 '여러 OneLake 보안 역할 평가'를 참조하세요.
메타데이터 보안
OneLake 보안의 읽기 권한은 테이블의 데이터 및 메타데이터에 대한 모든 액세스 권한을 부여합니다. 테이블에 액세스할 수 없는 사용자의 경우 데이터가 노출되지 않습니다. 이 규칙은 열 수준 보안과 사용자가 해당 테이블에서 해당 열을 볼 수 있는지 여부에도 적용됩니다. 하지만 OneLake 보안이 테이블의 메타데이터가 접근 불가능하다는 보장은 없습니다. 일부 오류 메시지 및 환경에는 열 이름이 표시될 수 있습니다.
폴더 권한 상속 및 탐색
폴더 권한은 계층 구조에 두 가지 방향으로 영향을 미칩니다:
- 상속: 폴더에 부여된 권한은 아래쪽 파일과 하위 폴더에 적용됩니다.
- 탐색 및 목록: 사용자가 자식 항목에 권한이 있을 경우, OneLake 보안은 사용자가 상위 폴더를 목록화하고 탐색하여 접근할 수 있는 데이터를 발견하고 탐색할 수 있도록 합니다. 트래버설은 형제 파일이나 폴더에 대한 접근을 주지 않습니다.
OneLake에서 호숫가 집의 다음 계층 구조를 생각해 보십시오:
Tables/
──── (empty folder)
Files/
────folder1
│ │ file11.txt
│ │
│ └───subfolder11
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
│
└───folder2
│ file21.txt
Role1 역할을 만들어 subfolder11에 대한 읽기 권한을 부여합니다. 상속을 통해 해당 역할의 구성원은 subfolder111 및 file111.txt의 모든 항목을 읽을 수 있습니다. 구성원은 folder1을(를) 보고 탐색하여 subfolder11에 도달할 수 있지만, subfolder11은(는) file11.txt의 형제 항목이므로 볼 수 없고, Tables은(는) Files의 형제 항목이므로 볼 수 없습니다.
Files/
│
└───folder1
│ │
│ └───subfolder11 <-- READ
│ │ file111.txt
│ │
│ └───subfolder111
│ │ file1111.txt
folder2에 대한 Read 권한을 부여하는 또 다른 역할 Role2을 만듭니다. 상속을 통해 멤버는 file21.txt를 읽을 수 있습니다. 구성원은 folder2 및 Files을(를) 거쳐 해당 위치에 도달할 수 있지만, folder1 또는 그 하위 항목은 볼 수 없습니다.
Files/
│
└───folder2 <-- READ
│ file21.txt
지름길의 경우, 동작이 약간 다릅니다. 외부 데이터 소스로 가는 단축키는 폴더와 동일하게 작동합니다. 하지만 다른 OneLake 지점으로 가는 지름길은 특수한 동작을 가지고 있습니다. OneLake 바로 가기에 대한 액세스 권한이 바로 가기의 대상 권한에 따라 결정됩니다. 단축키를 나열할 때, OneLake는 대상 접근 권한을 확인하라는 호출을 하지 않습니다. 그 결과, 디렉터리를 나열하면 OneLake는 대상 디렉터리에 대한 접근 여부와 상관없이 모든 내부 단축키를 반환합니다. 접근 검사는 바로가기를 열려고 하면 평가되고, 그 후에는 필요한 권한이 있는 데이터만 보입니다.
바로 가기
OneLake 보안은 OneLake 내부와 외부의 데이터를 안전하게 보호하는 단축키와 통합됩니다. 단축키는 두 가지 인증 모드 중 하나를 사용합니다:
- 패스스루: 이 단축키는 쿼리 사용자의 신원을 이용해 대상에 접근합니다. OneLake 간 단축키는 Passthrough가 기본값입니다.
- 위임: 이 단축키는 지정된 연결 식별자 또는 자격 증명을 사용하여 대상에 접근합니다. OneLake 간 단축키는 위임 인증을 사용할 수 있으며, 외부 시스템으로의 단축키는 항상 위임 인증을 사용합니다.
바로가기를 생성하려면 바로가기가 생성되는 경로와 대상 경로 모두에 대한 권한이 필요합니다. 각 단축어 유형을 생성하고 접근하기 위한 요구사항은 OneLake 단축키 보안을 참조하세요.
통과 바로 가기의 OneLake 보안
사용자가 OneLake에서 OneLake로 패스스루 바로가기를 통해 데이터에 접근할 때, OneLake는 발신자의 신원을 이용해 대상 경로에 대한 접근 권한을 부여합니다. 사용자의 실질적인 접근 권한은 지름길 경로와 목표 경로 모두에 대한 권한에 의해 제한됩니다.
비고
쿼리 엔진 신원과 바로가기 인증은 별도의 설정입니다. 패스스루 단축키는 일반적으로 발신자의 신원을 이용해 대상에 접근합니다. 그러나 위임된 ID 모드에서 SQL 기반 Direct Lake 및 SQL 분석 엔드포인트를 사용하는 Power BI 시맨틱 모델은 소비자 항목 또는 데이터 원본의 소유자 ID를 사용합니다. 이 동작은 단축키의 인증 모드를 변경하지 않습니다. 종단 간 사용자 신원 패스스루를 위해서는 OneLake 대신 Direct Lake를 사용하거나 SQL 분석 엔드포인트를 사용자 신원 접근 모드를 사용하도록 설정하세요.
OneLake 간 단축키에서 OneLake 보안 권한을 직접 정의할 수는 없습니다. 바로가기가 포함된 폴더의 권한은 대상 경로에 대한 권한과 결합됩니다. 대상 항목이 OneLake 보안을 지원한다면, 사용자는 OneLake 보안 역할을 통해 접근해야 합니다. 대상 항목이 OneLake 보안을 지원하지 않는 경우, 사용자는 대상 항목에 대해 Fabric ReadAll 권한이 필요합니다. 사용자는 목표 항목에 대해 단지 바로가기를 통해 데이터를 접근하기 위해 Fabric Read 권한이 필요하지 않습니다.
위임된 바로 가기의 OneLake 보안
위임된 단축키는 호출 사용자의 신원 대신 설정된 연결 신원 또는 자격 증명을 사용하여 대상에 접근합니다. OneLake 보안은 해당 연결을 통해 사용자가 접근할 수 있는 범위를 제한합니다.
위임된 OneLake 바로 가기
위임된 OneLake-to-OneLake 단축키의 경우, 호출자는 단축키 경로상의 자신의 접근 지점과 지정된 연결 식별자의 대상 경로 접근 교차점을 보게 됩니다. 두 경로 모두에서 컬럼 레벨 보안(CLS)이 지원됩니다. 대상 경로에서는 행 수준 보안(RLS)을 지원하지만, 단축 경로에서는 RLS를 정의할 수 없습니다.
위임된 외부 단축
ADLS, Amazon S3, Dataverse와 같은 외부 시스템으로 가는 단축키는 설정된 연결 자격 증명을 통해 외부 소스에 접근합니다. OneLake 보안은 해당 자격 증명으로 부여된 접근 권한 위에 적용됩니다.
예를 들어, user1이 Amazon S3 버킷의 한 폴더에 대한 lakehouse 바로가기를 만들고, user2가 lakehouse에서 그 바로가기에 접근한다고 가정해 봅시다. User2는 설정된 S3 연결 자격 증명이 소스에 접근할 수 있고 OneLake 보안이 user2에게 단축 경로 접근 권한을 부여할 때만 S3 데이터에 접근할 수 있습니다.
OneLake는 전체 외부 바로가기 또는 선택된 서브패스에 보안 권한을 부여할 수 있습니다. 폴더의 권한은 바로가기 내 폴더를 포함한 모든 하위 폴더에 재귀적으로 상속됩니다. 다른 OneLake 단축키를 통해 외부 단축키에 도달하는 사용자는 원래 외부 단축키에 적용된 OneLake 보안의 승인을 받아야 합니다.
Spark를 통한 외부 단축키나 OneLake API 호출을 통한 외부 단축키에 접근하려면 해당 외부 단축키가 포함된 항목에 대해 Fabric Read 권한이 필요합니다. 이 허가는 외부 시스템과의 연결을 안전하게 해결하기 위해 필요합니다.
여러 OneLake 보안 역할을 평가하세요
사용자는 여러 OneLake 보안 역할에 속할 수 있습니다. OneLake는 해당 역할들이 부여한 접근 권한을 결합하여 사용자가 접근할 수 있는 데이터를 결정하는 효과적인 역할을 만듭니다. OneLake는 단계별로 효과적인 역할을 평가합니다.
각 역할 내 접근 권한을 해결하세요
OneLake는 먼저 각 역할을 독립적으로 해결합니다. 역할 내에서 사용자는 세 가지 보안 구성 요소 모두에서 허용된 데이터에만 접근할 수 있습니다:
- 객체 수준 보안(OLS)은 역할이 접근할 수 있는 테이블이나 폴더를 결정합니다.
- 행 수준 보안(RLS)은 해당 역할이 접근할 수 있는 테이블의 행을 제한합니다.
- 컬럼 레벨 보안(CLS)은 해당 역할이 접근할 수 있는 테이블의 컬럼을 제한합니다.
세 구성 요소가 모두 적용되므로 OneLake는 그 교집합을 사용합니다. 예를 들어, Role1이 Table1에 대한 접근 권한을 부여하고 그 행과 열을 제한한다면, Role1의 해결된 접근 권한은 다음과 같습니다:
Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS
교차 기호(∩)는 사용자가 해당 역할에서 OLS, RLS, CLS가 허용하는 접근만 받는다는 것을 의미합니다.
역할 간 접근 권한을 결합하기
각 역할을 해결한 후, OneLake는 유니언 또는 최소 제한 모델을 사용하여 역할을 결합합니다. 유니언 심볼(∪)은 어떤 역할에 의해 부여된 접근이 유효 역할의 일부가 됨을 의미합니다. Role1이 TableA에 접근을 부여하고 Role2가 TableB에 접근을 허용하면, 두 역할에 속한 사용자가 두 테이블 모두에 접근할 수 있습니다.
두 역할의 경우 효과적인 역할은 다음과 같습니다:
Effective role = Role1 ∪ Role2
여러 역할이 동일한 테이블에 대한 액세스 권한을 부여하는 경우, 행 수준 보안 규칙은 OR 연산자로 결합됩니다. 예를 들어, city = 'Redmond' OR city = 'New York'와 city = 'Redmond'를 허용하는 술어는 city = 'New York'로 결합됩니다.
컬럼 레벨 보안 규칙도 유니언으로 결합되지만, SQL 분석 엔드포인트에서는 예외입니다. SQL 분석 엔드포인트에서는 CLS가 더 엄격한 부정 의미론을 사용합니다. 어떤 역할이 열을 숨기면, 엔드포인트는 해당 열에 대한 접근을 차단합니다. 그 결과, 엔드포인트는 모든 사용자의 역할에 걸친 CLS 허용 목록과 교차하며, 이를 유니언으로 결합하지 않습니다.
중요
함께 적용되어야 하는 RLS 및 CLS 규칙은 동일한 역할에 유지하세요. OneLake는 두 역할이 테이블에 대해 서로 다른 열 집합을 허용하고, 어느 역할이든 해당 테이블에 RLS를 적용하는 역할 조합을 지원하지 않습니다. 예를 들어, 사용자는 Role1에 속할 수 없는데, Role1은 열(열은 c1, c2와 일부 행)을 허용하며, Role2는 열(열은 c2와 c3)를 허용합니다.
단축키와 목표 접근 결합
지름길이 경우, OneLake는 지름길 위치와 지름길 목표에서 역할을 별도로 평가합니다. 대상 역할은 바로 가기 위치에서 추론된 역할이 됩니다. OneLake는 단축키 역할의 결합 접근과 추론된 목표 역할의 결합 접근을 교차시킵니다. 이 단계는 단축키 위치에서 상속된 접근이 대상에 대한 제한을 무시하는 것을 방지합니다.
두 개의 단축 역할과 두 개의 추론된 목표 역할에 대해 유효 접근은 다음과 같습니다:
Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)
이 표현식에서 ShortcutRole1 및 ShortcutRole2는 바로 가기 위치의 역할입니다.
InferredRole1 와 InferredRole2 는 단축키 목표에서 추론된 대응하는 역할입니다. 각 역할은 OLS, RLS, CLS 구성 요소에서 해결된 후 OneLake가 역할을 통합합니다.
OneLake 보안 제한 사항
B2B 게스트 사용자에게 OneLake 보안 역할을 할당하는 경우 Microsoft Entra 외부 ID의 B2B에 대한 외부 공동 작업 설정을 구성해야 합니다. 게스트 사용자 접근 설정을 '게스트 사용자가 회원과 동일한 권한을 가지는(가장 포괄적)'으로 설정하세요.
OneLake 보안 역할에 배포 목록을 추가하면 SQL 분석 엔드포인트는 액세스 제어를 적용하기 위해 해당 목록의 구성원을 확인할 수 없습니다. 그 결과, 사용자가 SQL 분석 엔드포인트에 접근할 때 역할의 구성원이 아닌 것처럼 보입니다. SQL 의미 모델 Direct Lake도 이 제한에 노출됩니다.
Spark 노트북은 환경이 3.5 이상이어야 하고 Fabric 런타임 1.3을 사용해야 합니다.
스키마 없는 레이크하우스는 RLS 및 CLS로 보호되는 테이블의 데이터 미리 보기를 지원하지 않습니다. OneLake 보안이 적용된 스키마 지원 호숫가를 사용하세요.
OneLake 보안은 Azure Data Share나 Purview Data Share에서는 작동하지 않습니다. 자세한 내용은 Azure Data Share를 참조하세요.
다음 표는 OneLake 보안 역할의 한계를 나열하고 있습니다.
시나리오 한계 Fabric 항목당 OneLake 보안 역할의 최대 수 아이템당 250개의 역할 (주석 참조) OneLake 보안 역할당 최대 멤버 수 역할당 500명의 사용자 또는 사용자 그룹 OneLake 보안 역할당 최대 권한 수 역할당 500개 권한 비고
아이템당 역할 수를 1,000개까지 늘리도록 요청할 수 있습니다. 한도 증가를 요청하려면 Azure 지원에 문의하세요.
지연 시간
역할 정의 변경 내용을 적용하는 데 약 5분이 걸립니다.
OneLake 보안 역할에서 사용자 그룹을 변경하는 경우 OneLake가 업데이트된 사용자 그룹에 역할의 권한을 적용하는 데 약 1시간이 걸립니다. 일부 패브릭 엔진에는 자체 캐싱 계층이 있으므로 모든 시스템에서 액세스를 업데이트하는 데 1시간이 더 필요할 수 있습니다.