OneLake 보안을 통해 Microsoft Fabric은 조직이 워크로드 전반에서 데이터 액세스를 관리하고 적용하는 방법을 확대하고 있습니다. 이 보안 프레임워크를 사용하면 관리자가 권한을 보다 유연하게 구성할 수 있습니다. 관리자는 OneLake를 통한 중앙 집중식 거버넌스 또는 SQL 분석 엔드포인트 내의 세분화된 SQL 기반 제어 중에서 선택할 수 있습니다.
SQL 분석 엔드포인트의 Access 모드
SQL 분석 엔드포인트 사용하는 경우 선택한 access 모드는 데이터 보안이 적용되는 방식을 결정합니다. Fabric은 운영 및 규정 준수 요구 사항에 따라 서로 다른 이점을 제공하는 두 가지 고유한 access 모델을 지원합니다.
사용자 ID 모드: OneLake 역할 및 정책을 사용하여 보안을 적용합니다. 이 모드에서 SQL 분석 엔드포인트는 로그인한 사용자의 ID를 OneLake에 전달하고 읽기 액세스는 전적으로 OneLake 내에 정의된 보안 규칙에 의해 제어됩니다. 비데이타 개체(뷰, 저장 프로시저, 함수)에 대한 SQL 수준 권한이 지원되어 Power BI, Notebook 및 lakehouse와 같은 도구 간에 일관된 거버넌스를 보장합니다.
위임된 ID 모드: SQL을 통해 모든 권한을 제공합니다. 이 모드에서 SQL 분석 엔드포인트는 작업 영역 또는 항목 소유자의 ID를 사용하여 OneLake에 연결하며, 보안은 데이터베이스 내에 정의된 SQL 권한에 의해서만 제어 됩니다. 이 모델은 GRANT, REVOKE, 사용자 지정 역할, Row-Level 보안 및 동적 데이터 마스킹을 비롯한 기존 보안 방법을 지원합니다.
각 모드는 다양한 거버넌스 모델을 지원합니다. 해당 의미를 이해하는 것은 패브릭 환경에서 올바른 접근 방식을 선택하는 데 필수적입니다.
중요합니다
SQL 분석 엔드포인트를 사용하는 데 필요한 아티팩트 액세스입니다. SQL 분석 엔드포인트를 통해 데이터에 연결하고 쿼리하려면 사용자에게 엔드포인트와 연결된 아티팩트에서 읽기 권한이 있어야 합니다. 사용자가 아티팩트(예: 작업 영역 역할 액세스 또는 명시적 항목 권한)에 대한 제어 평면 액세스 권한이 없는 경우 해당 사용자에 대해 존재할 수 있는 SQL 권한에 관계없이 SQL 분석 엔드포인트에 대한 연결이 거부됩니다.
접근 모드 비교
다음 표에서는 사용자 ID 모드에서 보안을 설정하는 방법과 위치를 개체 유형 및 데이터 액세스 정책에 따라 구분하여 위임된 ID 모드와 비교합니다.
| 보안 대상 | 사용자 ID 모드 | 위임된 ID 모드 |
|---|---|---|
| Tables | OneLake 보안 역할에 의해 액세스가 제어됩니다. SQL GRANT/REVOKE 은 허용되지 않습니다. |
SQL GRANT/REVOKE을 사용하여 전체 제어 권한. |
| 조회 수 | SQL GRANT/REVOKE 을 사용하여 사용 권한을 할당합니다. |
SQL GRANT/REVOKE 을 사용하여 사용 권한을 할당합니다. |
| 저장 프로시저 | SQL GRANT EXECUTE 을 사용하여 사용 권한을 할당합니다. |
SQL GRANT EXECUTE 을 사용하여 사용 권한을 할당합니다. |
| 함수 | SQL GRANT EXECUTE 을 사용하여 사용 권한을 할당합니다. |
SQL GRANT EXECUTE 을 사용하여 사용 권한을 할당합니다. |
| 행 수준 보안(RLS) | OneLake 보안 역할의 일부로 OneLake UI에 정의됩니다. | SQL CREATE SECURITY POLICY을 사용하여 정의합니다. |
| 열 수준 보안 (Column-Level Security) | OneLake 보안 역할의 일부로 OneLake UI에 정의됩니다. | 열 목록과 함께 SQL GRANT SELECT 을 사용하여 정의됩니다. |
| DDM(동적 데이터 마스킹) | OneLake 보안에서는 지원되지 않습니다. | SQL ALTER TABLE을 사용하여 MASKED 옵션과 함께 정의됩니다. |
OneLake 보안의 사용자 ID 모드
사용자 ID 모드에서 SQL 분석 엔드포인트는 통과 인증 메커니즘을 사용하여 데이터 접근을 적용합니다. 사용자가 SQL 분석 엔드포인트에 연결하면 해당 Entra ID ID가 OneLake로 전달되어 권한 검사를 수행합니다. 테이블에 대한 모든 읽기 작업은 SQL 수준 GRANT 또는 REVOKE 문이 아닌 OneLake Lakehouse 내에 정의된 보안 규칙을 사용하여 평가됩니다.
이 모드를 사용하면 보안을 중앙에서 관리하여 Power BI, Notebook, Lakehouse 및 SQL 분석 엔드포인트를 비롯한 모든 패브릭 환경에서 일관된 적용을 보장할 수 있습니다. 거버넌스 모델을 위해 설계되었으며, OneLake에서 접근 권한을 한 번 정의하면 모든 곳에서 자동으로 적용되어야 합니다.
사용자 ID 모드에서:
테이블 접근은 완전히 OneLake 보안으로 제어됩니다. 테이블의 SQL
GRANT/REVOKE문은 무시됩니다.RLS(Row-Level 보안), CLS(Column-Level 보안) 및 Object-Level 보안은 모두 OneLake 환경에서 정의됩니다.
뷰, 저장 프로시저 및 함수와 같은 비데이터 개체에 대해 SQL 권한이 허용되므로 데이터에 대한 사용자 지정 논리 또는 사용자 연결 진입점을 유연하게 정의할 수 있습니다.
쓰기 작업은 SQL 분석 엔드포인트에서 지원되지 않습니다. 모든 쓰기는 패브릭 포털의 Lakehouse 페이지를 통해 발생해야 하며 작업 영역 역할(관리자, 멤버, 기여자)에 의해 관리됩니다.
중요합니다
생산자와 소비자 간의 일대일 신원 매핑(허브 앤 스포크)입니다. OneLake 보안 정책이 생산자(역할이 정의된 원본 항목)에서 소비자(바로 가기를 통해 데이터에 액세스하는 대상 항목)로 전달되는 경우 생산자의 OneLake 보안 역할에 할당된 ID는 소비자에서 정확히 1:1 로 매핑되어야 합니다. 동일한 주체(사용자 또는 그룹)가 소비자 아티팩트에 대해 Fabric 읽기 권한을 부여받아야 하며, 이는 생산자의 보안 역할에서 참조된 것과 동일해야 합니다. 중첩 그룹 멤버 자격이나 유효 그룹 멤버 자격은 이 경계를 넘어서는 확인되지 않습니다.
예를 들어, 생산자의 OneLake 보안 역할에서 user123@microsoft.com를 참조하는 경우, user123@microsoft.com (정확한 개체 ID)에는 소비자 레이크하우스에 대한 Fabric 읽기 권한도 있어야 합니다. 마찬가지로 생산자 역할이 Group A 참조하는 경우 Group A 자체에 Fabric 소비자에 대한 읽기 권한을 부여해야 합니다. 그룹 A의 멤버에게만 해당 권한을 부여해도 일치 항목이 충족되지 않습니다.
사용자의 ID 모드를 사용하는 사용 권한 모델에 대한 자세한 내용은 OneLake 보안에 대한 데이터 액세스 제어 모델을 참조하세요.
OneLake와 SQL 분석 엔드포인트 간의 보안 동기화
사용자 ID 모드의 중요한 구성 요소는 보안 동기화 서비스입니다. 이 백그라운드 서비스는 OneLake의 보안 역할에 대한 변경 내용을 모니터링하고 이러한 변경 내용이 SQL 분석 엔드포인트에 반영되도록 합니다.
보안 동기화 서비스는 다음을 담당합니다.
새 역할, 업데이트, 사용자 할당 및 테이블 변경 내용을 포함하여 OneLake 역할의 변경 내용을 검색합니다.
OneLake 정의 정책(RLS, CLS, OLS)을 동등한 SQL 호환 데이터베이스 역할 구조로 변환합니다.
원격으로 액세스하는 경우에도 원래 OneLake 보안 설정을 적용할 수 있도록 바로 가기 개체 (다른 레이크하우스에서 제공하는 테이블)의 유효성을 올바르게 검사합니다.
이 동기화를 통해 OneLake 보안 정의가 신뢰할 수 있게 유지되며, 보안 동작을 복제하기 위한 수동 SQL 수준 개입이 필요하지 않습니다. 보안은 중앙에서 적용되므로 다음을 수행합니다.
이 모드에서는 T-SQL을 사용하여 RLS, CLS 또는 OLS를 직접 정의할 수 없습니다.
SQL 권한은 여전히
GRANT또는EXECUTE문을 사용하여 뷰, 함수 및 저장 프로시저에 적용할 수 있습니다.
보안 동기화 다시 시도 백오프
보안 동기화에는 시스템 안정성을 보호하고 불필요한 컴퓨팅 소비를 방지하기 위한 재시도 백오프 메커니즘이 포함되어 있습니다.
SQL 분석 엔드포인트에 OneLake 보안 역할을 적용하는 동안 반복되는 오류가 발생하면 시스템에서 자동 동기화 시도를 일시적으로 일시 중지할 수 있습니다.
기존 OneLake 보안 역할이 수정되거나 새 OneLake 보안 역할이 만들어지면 동기화가 자동으로 다시 시작됩니다.
보안 동기화 오류 및 해결 방법
| Scenario | 사용자 ID 모드의 동작 | 위임된 모드의 동작 | 수정 작업 | 비고 |
|---|---|---|---|---|
| RLS 정책은 삭제되거나 이름이 바뀐 열을 참조합니다. | 오류: 행 수준 보안 정책은 더 이상 존재하지 않는 열을 참조합니다. 정책이 수정될 때까지 데이터베이스가 오류 상태를 입력합니다. | 오류: 열 이름 열 이름이 <>잘못되었습니다. | 영향을 받는 역할을 하나 이상 업데이트하거나 제거하거나 누락된 열을 복원합니다. | 역할이 만들어진 레이크하우스에서 업데이트를 수행해야 합니다. |
| CLS 정책은 삭제되거나 이름이 바뀐 열을 참조합니다. | 오류: 열 수준 보안 정책은 더 이상 존재하지 않는 열을 참조합니다. 정책이 수정될 때까지 데이터베이스가 오류 상태를 입력합니다. | 오류: 열 이름 열 이름이 <>잘못되었습니다. | 영향을 받는 역할을 하나 이상 업데이트하거나 제거하거나 누락된 열을 복원합니다. | 역할이 만들어진 레이크하우스에서 업데이트를 수행해야 합니다. |
| RLS/CLS 정책은 삭제되거나 이름이 바뀐 테이블을 참조합니다. | 오류: 보안 정책은 더 이상 존재하지 않는 테이블을 참조합니다. | 오류가 표시되지 않습니다. 테이블이 없으면 쿼리가 자동으로 실패합니다. | 영향을 받는 역할을 하나 이상 업데이트하거나 제거하거나 누락된 테이블을 복원합니다. | 역할이 만들어진 레이크하우스에서 업데이트를 수행해야 합니다. |
| DDM(동적 데이터 마스킹) 정책은 삭제되거나 이름이 바뀐 열을 참조합니다. | DDM은 OneLake 보안에서 지원되지 않습니다. 는 SQL을 통해 구현되어야 합니다. | 오류: 열 이름 열 이름이 <>잘못되었습니다. | 영향을 받는 DDM 규칙을 하나 이상 업데이트하거나 제거하거나 누락된 열을 복원합니다. | SQL 분석 엔드포인트에서 DDM 정책을 업데이트합니다. |
| 시스템 오류(예기치 않은 오류) | 오류: 예기치 않은 시스템 오류가 발생했습니다. 다시 시도하거나 지원에 문의하세요. | 오류: SQL에 테이블 변경 내용을 적용하는 동안 내부 오류가 발생했습니다. | 작업을 다시 시도합니다. 문제가 지속되면 Microsoft 지원 문의하세요. | N/A |
| 사용자에게 아티팩트 권한이 없습니다. | 오류: 사용자에게 아티팩트 권한이 없습니다. | 오류: 사용자에게 아티팩트 권한이 없습니다. | 사용자에게 아티팩트에 대한 objectID {objectID} 권한을 부여합니다. |
개체 ID는 OneLake 보안 역할 멤버와 패브릭 항목 권한 간의 정확한 일치여야 합니다. 그룹이 역할 멤버 자격에 추가되면 동일한 그룹에 Fabric 읽기 권한이 부여되어야 합니다. 해당 그룹의 멤버를 항목에 추가하는 것은 직접 일치 항목으로 간주되지 않습니다. |
| 사용자 주체는 지원되지 않습니다. | 오류: 사용자 계정은 지원되지 않습니다. | 오류: 사용자 계정은 지원되지 않습니다. | 사용자 {username}를 역할 DefaultReader에서 제거합니다. |
이 오류는 사용자가 더 이상 유효한 Entra ID 없는 경우에 발생합니다(예: 사용자가 조직을 떠났거나 삭제됨). 역할에서 제거하여 오류를 해결합니다. |
보안 동기화 시 바로 가기 작동 방식
OneLake 보안은 단일 신뢰 소스에서 적용되므로, 보안 동기화는 바로 가기가 포함된 테이블 및 뷰에 대해 소유권 체인을 비활성화합니다. 이렇게 하면 다른 데이터베이스의 쿼리에 대해서도 원본 시스템 권한이 항상 평가되고 적용됩니다.
결과적으로 다음을 수행합니다.
사용자는 both소스 바로 가기(현재 Lakehouse 또는 SQL 분석 엔드포인트)과 데이터가 물리적으로 상주하는 대상 위치에 유효한 접근 권한이 있어야 합니다.
사용자에게 어느 한 쪽에 대한 권한이 없는 경우 액세스 오류로 쿼리가 실패합니다 .
바로 가기를 참조하는 애플리케이션 또는 뷰를 디자인할 때 바로 가기 관계의 양쪽 끝에서 역할 할당이 제대로 구성되었는지 확인합니다.
이 디자인은 Lakehouse 경계를 넘어 보안 무결성을 유지하지만, 레이크하우스 간 역할이 정렬되지 않은 경우 access 오류가 발생할 수 있는 시나리오를 소개합니다.
OneLake 보안의 위임된 모드
위임된 ID 모드에서 SQL 분석 엔드포인트는 기존 SQL 보안 모델과의 이전 버전과의 호환성을 유지합니다.
보안은 SQL 엔진 계층에서 정의되고 적용되며 OneLake 보안 역할 및 액세스 정책은 테이블 수준 액세스로 이월되지 않습니다. 스키마 및 테이블에 대한 액세스, Row-Level 보안(RLS), CLS(Column-Level 보안) 및 DDM(동적 데이터 마스킹)을 포함한 모든 필터링 및 액세스 제어는 SQL 구문(GRANT/REVOKE, 보안 정책 등)을 사용하여 정의해야 합니다.
최종 사용자에 대한 OneLake 보안 역할은 직접 적용되지 않으므로 OneLake에 정의된 보안 규칙(예: Spark 또는 OneLake를 통해 읽은 다른 엔진에 의해 적용된 규칙)은 SQL 분석 엔드포인트를 통해 동일한 데이터를 쿼리할 때 적용되지 않습니다 . 워크로드가 SQL 네이티브 보안 의미 체계에 종속되거나 기존 T-SQL 도구에 완전한 호환성이 필요한 경우 이 모드를 선택합니다.
사용자가 SQL 분석 엔드포인트에 연결하고 쿼리를 발급하는 경우:
SQL은 SQL 계층에 정의된 권한에 대해 쿼리의 유효성을 검사합니다.
쿼리에 권한이 부여되면 시스템은 OneLake에 저장된 데이터에 접근합니다.
이 데이터 액세스는 로그인한 사용자가 아닌 항목 계정이라고도 하는 Lakehouse 또는 SQL 분석 엔드포인트 소유자의 ID를 사용하여 수행됩니다.
따라서 항목 소유자는 OneLake에서 워크로드를 대신하여 기본 파일을 읽을 수 있는 충분한 권한이 있어야 합니다. 최종 사용자에게 부여된 SQL 권한과 항목 소유자의 OneLake 액세스 간의 정렬이 잘못되면 쿼리가 실패합니다.
이 모드는 DBA 또는 애플리케이션에서 사용하는 기존 T-SQL 도구 및 사례를 지원하며, 모든 개체 수준과 SQL 정의 RLS, CLS 및 DDM에서 SQL GRANT/REVOKE 에 대한 완전한 호환성을 제공합니다.
위임된 모드의 바로 가기 동작
위임된 모드는 항목 소유자의 ID를 사용하여 OneLake에 연결되므로 바로 가기는 소유자가 전체 원본 테이블에 무제한으로 액세스할 수 있는 경우에만 작동합니다. 원본 테이블에 RLS(Row-Level Security), CLS(Column-Level Security)와 같은 OneLake 수준 보안 규칙이 적용된 경우 SQL 분석 엔드포인트는 해당 바로 가기에 대한 액세스를 차단합니다.
결과적으로 다음을 수행합니다.
데이터 수준 보안 규칙이 없는 원본 테이블을 가리키는 바로 가기는 일반적으로 위임된 모드에서 작동합니다.
최종 사용자에게 바로 가기 개체에 대한 SQL 권한이 있더라도 생산자의 OneLake 보안에서 RLS 또는 CLS가 있는 원본 테이블을 가리키는 바로 가기는 위임된 모드의 SQL 분석 엔드포인트를 통해 액세스할 수 없습니다 .
원본에 OneLake 보안 정책이 있는 바로 가기를 사용하려면 최종 사용자의 ID 가 원본의 OneLake 보안 규칙에 따라 평가되도록 소비자 엔드포인트에서 사용자 ID 모드를 사용합니다.
OneLake access 모드를 변경하는 방법
액세스 모드는 SQL 분석 엔드포인트를 통해 OneLake를 쿼리할 때 데이터 액세스를 인증하고 적용하는 방법을 결정합니다. 다음 단계를 사용하여 사용자 ID 모드와 위임된 ID 모드 간에 전환할 수 있습니다.
패브릭 작업 영역으로 이동하여 레이크하우스를 엽니다. 오른쪽 위 모서리에서 lakehouse에서 SQL 분석 엔드포인트로 전환합니다.
위쪽 탐색 창에서 보안 탭으로 이동하여 다음 OneLake 액세스 모드 중 하나를 선택합니다.
사용자 ID – 로그인한 사용자의 ID를 사용합니다. OneLake 역할을 강제로 적용합니다.
위임된 ID – 항목 소유자의 ID를 사용합니다. SQL 권한만 적용합니다.
선택 항목을 확인하기 위한 팝업이 시작됩니다. 예를 클릭하여 변경 내용을 확인합니다.
중요합니다
보안 모드를 일시적으로 변경하면 전체 작업 영역에서 SQL 분석 엔드포인트를 사용할 수 없게 됩니다. 이 작업은 해당 작업 영역의 모든 SQL 분석 엔드포인트에서 실행 중인 쿼리와 큐에 대기 중인 모든 쿼리를 취소합니다. 필요한 경우에만 모드를 변경하고 가동 중지 시간을 방지하기 위해 업무 외 시간에는 모드를 변경하는 것이 좋습니다.
모드 간 전환 시 고려 사항
중요합니다
사용자 ID와 위임된 모드 간에 전환하면 현재 TVF(테이블 반환 함수) 및 스칼라 반환 함수를 비롯한 인라인 메타데이터 개체가 제거됩니다. 이 동작은 메타데이터 정의에만 영향을 줍니다. OneLake의 기본 데이터는 영향을 받지 않습니다.
사용자 ID 모드로 전환
SQL RLS, CLS 및 테이블 수준 권한은 무시됩니다.
사용자의 접근 권한을 유지하기 위해 OneLake 역할을 구성해야 합니다.
뷰어 권한 또는 공유 읽기 전용 액세스 권한이 있는 사용자만 OneLake 보안의 적용을 받습니다.
기존 SQL 역할은 삭제되며 복구할 수 없습니다.
위임된 ID 모드로 전환
OneLake 역할 및 보안 정책은 더 이상 적용되지 않습니다.
SQL 역할 및 보안 정책이 활성화됩니다.
항목 소유자에게 유효한 OneLake access 있어야 합니다. 그렇지 않으면 모든 쿼리가 실패할 수 있습니다.
비고
SQL 개체는 소유권을 상속하지 않습니다. 바로 가기는 SQL 분석 엔드포인트에서 테이블로 작동하지만 의도적으로 표준 SQL 소유권 체인에서 벗어나 통합 보안 상태를 유지합니다.
상속 금지 규칙: 파생 SQL 개체(뷰, 저장 프로시저 또는 함수)는 개체 소유자의 사용 권한을 상속하지 않습니다.
런타임 유효성 검사: SQL 추상화가 OneLake 수준 정책을 우회할 수 없도록 실행 시 호출자의 ID에 대해 권한이 확인됩니다.
: SQL, Spark 또는 Power BI 통해 데이터에 액세스하는지 여부에 관계없이 보안 정책은 일관성을 유지합니다.
컨트롤 플레인 종속성(엄격한 ID 일치): OneLake 보안을 사용하려면 생산자에서 부여된 ID 액세스가 소비자 데이터 평면에서 액세스 평가 중에 인식되는 ID와 동일해야 합니다. 시스템은 원본에서 액세스 권한이 부여된 특정 보안 주체의 유효성을 검사하고 중첩된 그룹 멤버 자격을 확장하거나 간접 멤버 자격을 통해 유효 액세스를 유추하지 않습니다.
리터럴 주체 일치: 생산자에게 부여된 정확한 객체 ID와의 일치 여부에 따라 액세스가 평가됩니다.
중첩/유효 해결 방법 없음: 중첩된 그룹 멤버 자격 또는 간접 상속은 적용하기에 충분하지 않습니다. 작동 예시는 OneLake 보안의 사용자 아이덴티티 모드의 호출부를 참조하십시오.
사용 권한 평가 동작: 권한 평가는 현재 적용 모델에 따라 테이블 유형에 따라 다릅니다.
바로 가기 테이블: 필요한 권한 부여 조건이 충족되지 않으면 액세스가 거부될 수 있습니다. 이는 OneLake 보안의 역할 기반 DENY 기능이 아니라 제한적인 적용 결과입니다.
일반 규칙: 적용에서 액세스의 유효성을 명확하게 검사할 수 없는 경우 시스템은 가장 제한적인 결과를 적용합니다.
CLS(Column-Level 보안) 디자인: CLS는 엄격한 열 허용 목록을 유지 관리합니다.
허용된 열의 이름을 바꾸거나 제거하면 보안 규칙이 무효화됩니다. 규칙은 시스템에서 유지되지만 원래 열 이름이 복원될 때까지 리소스에 대한 모든 액세스를 거부하는 비활성 상태로 유지됩니다.
동기화 보호: 정책이 유효하지 않으면 OneLake 보안 패널에서 규칙이 수정될 때까지 메타데이터 동기화가 의도적으로 차단됩니다.
스키마 유효성 검사: 보안 정책을 업데이트하지 않고 열 이름을 바꾸면 구성이 동기화될 때까지 열이 "존재하지 않는다"는 UI 오류가 트리거됩니다.
SLA(역할 전파 및 동기화):
OneLake 보안 동기화: OneLake 보안 역할이 사용자 ID 모드에서 변경되면 업데이트가 즉시 수행되지 않습니다. 일반적으로는 빠르지만 SQL 분석 엔드포인트와 동기화하는 데 최대 5분 이 걸릴 수 있습니다.
자동 접두사 부여: OneLake 보안 역할은 접두사를 추가하여 SQL 분석 엔드포인트로 전달됩니다.
동기화 우선 순위: 보안 동기화 프로세스는 정기적으로 역할의
OLS_상태를 새로 고칩니다. 이러한 역할에 대한 수동 변경은 지원되지 않으며 다음 동기화 주기 동안 덮어씁니다. 동기화에 대한 변경 내용이 없으면 보안 동기화가 수동 변경 내용을 재정의하지 않습니다.
웨어하우스 SQL 보안 및 바로 가기: RLS(Row-Level Security), CLS(Column-Level Security) 또는 OLS(Object-Level Security)와 같은 웨어하우스의 SQL 구문을 사용하여 정의된 보안 정책은 웨어하우스(TDS 엔드포인트)의 SQL 실행 컨텍스트 내에서만 적용됩니다.
중요합니다
OneLake 바로 가기를 통해 웨어하우스의 데이터에 액세스하는 경우 이러한 SQL 보안 의미 체계는 OneLake 보안 정책으로 변환되지 않습니다. 따라서 바로 가기를 통해 데이터에 액세스하는 사용자는 원본 웨어하우스에 구성된 SQL 보안 정책에 관계없이 전체 데이터 세트를 볼 수 있습니다.
제한점
읽기 권한자만 적용됩니다. OneLake 보안은 주로 뷰어 수준 작업 영역 또는 항목 액세스를 통해 데이터에 액세스하는 사용자에게 적용됩니다. 관리자, 멤버 또는 참가자와 같은 광범위한 작업 영역 역할을 가진 사용자는 상승된 액세스를 유지하며 OneLake 보안 적용의 주요 대상이 아닙니다.
예외:
바로 가기 거부 동작: 바로 가기 지원 테이블의 경우 적용은 특정 경우에 관리자, 구성원 또는 참가자에 대한 액세스를 계속 거부할 수 있습니다.
보안 동기화 실패 사례: 보안 동기화가 특정 테이블 또는 역할에 대해 보안을 올바르게 적용하지 못하는 경우 영향을 받는 역할의 멤버인 관리자, 멤버 또는 기여자 역할의 사용자도 제한된 액세스를 경험할 수 있습니다.
사용자 ID 모드의 RLS: RLS(Row-Level Security)가 사용자 ID 모드로 구성된 경우 정의된 보안 규칙은 관리자, 멤버 및 기여자 역할을 포함한 모든 사용자에 대해 적용됩니다.
보안 동기화 종속성: 사용자 ID 모드에서 OneLake 보안 역할은 보안 동기화 프로세스를 통해 SQL 분석 엔드포인트에 동기화됩니다. 동기화가 완료될 때까지 SQL은 기존 SQL 권한 상태를 사용하여 액세스를 일시적으로 평가할 수 있습니다. 동기화가 완료되면 SQL 엔드포인트는 OneLake 보안 구성을 반영합니다.
바로 가기 경계 인식: SQL 분석 엔드포인트는 처음에 표준 SQL 개체 의미 체계를 사용하여 바로 가기 지원 테이블을 평가할 수 있습니다. 보안 동기화가 수행되면 액세스 적용이 아티팩트 및 작업 영역 경계와 일치하도록 OneLake 보안 정책이 적용됩니다.
아티팩트 간 액세스 적용 타이밍: 다른 아티팩트에서 데이터를 참조하는 OneLake 바로 가기에서 지원되는 테이블에 대한 액세스는 동기화된 OneLake 보안 역할을 통해 적용됩니다. 동기화가 발생할 때까지 SQL 권한 부여는 일시적으로 이전 사용 권한 상태를 반영할 수 있습니다.
바로 가기 지원 테이블의 소유권 변경: 바로 가기 지원 테이블은 SQL 분석 엔드포인트에서 SQL 개체로 표시되므로 표준 SQL 소유권 작업을 지원합니다. 관리 명령어
ALTER AUTHORIZATION는 바로가기로 지원되는 테이블의 소유자를 변경할 수 있습니다. 특정 시나리오에서는 OneLake 보안 정책을 우회하고 기본 데이터에 의도하지 않은 액세스 권한을 부여하는 소유권 체인 동작을 허용할 수 있습니다. 추가 실행 메커니즘이 도입될 때까지 관리자는 바로 가기 백업 테이블에서 소유권을 수정하지 않아야 합니다.대상 유효성 검사 가동 중지 시간: 바로 가기 대상이 변경되면(예: 이름 바꾸기 또는 URL 업데이트) 시스템에서 새 대상의 유효성을 검사하는 동안 데이터베이스가 잠시 단일 사용자 모드 로 전환됩니다. 이 기간 동안 쿼리는 차단됩니다. 이러한 작업은 일반적으로 빠르지만 내부 프로세스에 따라 동기화하는 데 최대 5분이 걸릴 수 있습니다.
- 스키마 바로 가기를 만들면 유효성 검사에 영향을 미치고 메타데이터 동기화를 지연시키는 알려진 오류가 발생할 수 있습니다.
위임된 모드 토큰 캐싱: 위임된 모드에서 SQL 분석 엔드포인트는 소유자 ID를 대신하여 OneLake에서 데이터를 검색하는 데 사용되는 스토리지 액세스 토큰을 캐시합니다. 소유자의 사용 권한이 변경되면 이전에 발급한 토큰이 만료될 때까지 유효한 상태를 유지할 수 있습니다. 따라서 소유자 ID와 연결된 액세스 변경 내용은 즉시 적용되지 않을 수 있으며 토큰이 만료될 때까지 일반적으로 최대 30~60분 동안 지속될 수 있습니다.
OneLake 보안 GRANT/DENY 정책의 변경 내용은 즉시 적용되며 스토리지 토큰 캐싱으로 인해 지연되지 않습니다.
활성 쿼리 취소: 데이터 무결성 및 보안을 유지하기 위해 실행 중에 바로 가기 구성이 변경되면 활성 쿼리가 자동으로 취소될 수 있습니다.
Row-Level 보안(RLS) 제약 조건:
공개 미리 보기의 경우 단일 식 테이블만 지원됩니다. 동적 RLS 및 다중 테이블 RLS를 사용할 수 없습니다.
필터 식에 사용되는 열을 삭제하면 OneLake 보안 패널에서 RLS가 고정될 때까지 메타데이터 동기화가 중단됩니다.
역할 복잡성 및 메타데이터 동기화: 보안 역할의 복잡성이 높으며, 특히 RLS를 사용하는 수많은 교집합 및 공용 구조체 의미 체계를 포함하면 보안 동기화가 실패할 수 있습니다. 보안 동기화가 실패하면 보안 정책이 적용되지 않고 메타데이터를 동기화하는 기능이 차단됩니다.
스키마 및 역할 제약 조건:
이름 바꾸기: OneLake 보안 역할은 테이블 이름에 연결됩니다. 테이블 이름을 바꾸면 연결이 끊어지고 정책이 자동으로 마이그레이션되지 않습니다. 이로 인해 정책이 다시 적용될 때까지 의도하지 않은 데이터가 노출될 수 있습니다.
문자 제한: OneLake 보안 역할 이름은 124자를 초과할 수 없습니다. 그렇지 않으면 SQL 분석 엔드포인트에서 역할 만들기 또는 동기화가 실패합니다.
OLS_역할 수정: 역할에 대한OLS_사용자 변경은 지원되지 않으며 예기치 않은 동작이 발생할 수 있습니다.
지원되지 않는 ID: 메일 사용 보안 그룹 및 배포 목록은 현재 지원되지 않습니다.
Lakehouse 소유자 요구 사항:
Lakehouse의 소유자는 관리자, 구성원 또는 기여자 작업 영역 역할의 구성원이어야 합니다. 그렇지 않으면 보안이 SQL 분석 엔드포인트에 적용되지 않습니다.
레이크하우스의 소유자는 보안 동기화가 작동하기 위한 서비스 주체가 될 수 없습니다.