OneLake 보안을 통해 Microsoft Fabric은 조직에서 워크로드 간에 데이터 액세스를 관리하고 적용하는 방법을 확장하고 있습니다. 이 새로운 보안 프레임워크를 사용하면 관리자가 권한을 보다 유연하게 구성할 수 있습니다. 관리자는 OneLake를 통한 중앙 집중식 거버넌스 또는 SQL 분석 엔드포인트 내의 세분화된 SQL 기반 제어 중에서 선택할 수 있습니다.
SQL 분석 엔드포인트의 액세스 모드
SQL 분석 엔드포인트를 사용하는 경우 선택한 액세스 모드는 데이터 보안이 적용되는 방식을 결정합니다. 패브릭은 운영 및 규정 준수 요구 사항에 따라 서로 다른 이점을 제공하는 두 가지 고유한 액세스 모델을 지원합니다.
사용자 ID 모드: OneLake 역할 및 정책을 사용하여 보안을 적용합니다. 이 모드에서 SQL 분석 엔드포인트는 로그인한 사용자의 ID를 OneLake에 전달하고 읽기 액세스는 전적으로 OneLake 내에 정의된 보안 규칙에 의해 제어됩니다. 테이블에 대한 SQL 수준 권한이 지원되어 Power BI, Notebook 및 lakehouse와 같은 도구에서 일관된 거버넌스를 보장합니다.
위임된 ID 모드: SQL을 통해 모든 권한을 제공합니다. 이 모드에서 SQL 분석 엔드포인트는 작업 영역 또는 항목 소유자의 ID를 사용하여 OneLake에 연결하며, 보안은 데이터베이스 내에 정의된 SQL 권한에 의해서만 제어 됩니다. 이 모델은 GRANT, REVOKE, 사용자 지정 역할, Row-Level 보안 및 동적 데이터 마스킹을 비롯한 기존 보안 방법을 지원합니다.
각 모드는 다양한 거버넌스 모델을 지원합니다. 해당 의미를 이해하는 것은 패브릭 환경에서 올바른 접근 방식을 선택하는 데 필수적입니다.
액세스 모드 간 비교
다음은 사용자 ID 모드와 위임된 ID 모드에서 보안을 설정하는 방법과 위치에 초점을 맞춘 명확하고 간결한 비교 테이블입니다. 개체 유형 및 데이터 액세스 정책에 따라 세분화됩니다.
| 보안 대상 | 사용자 ID 모드 | 위임된 ID 모드 |
|---|---|---|
| Tables | 액세스는 OneLake 보안 역할에 의해 제어됩니다. SQL GRANT/REVOKE 은 허용되지 않습니다. |
SQL GRANT/REVOKE을 사용하여 모든 권한 |
| Views | SQL GRANT/REVOKE를 사용하여 사용 권한을 할당합니다. | SQL GRANT/REVOKE를 사용하여 사용 권한을 할당합니다. |
| 저장 프로시저 | SQL GRANT EXECUTE를 사용하여 사용 권한을 할당합니다. | SQL GRANT EXECUTE를 사용하여 사용 권한을 할당합니다. |
| 함수 | SQL GRANT EXECUTE를 사용하여 사용 권한을 할당합니다. | SQL GRANT EXECUTE를 사용하여 사용 권한을 할당합니다. |
| Row-Level 보안(RLS) | OneLake 보안 역할의 일부로 OneLake UI에 정의됩니다. | SQL CREATE SECURITY POLICY를 사용하여 정의됩니다. |
| CLS(Column-Level 보안) | OneLake 보안 역할의 일부로 OneLake UI에 정의됩니다. | 열 목록과 함께 SQL GRANT SELECT를 사용하여 정의됩니다. |
| DDM(동적 데이터 마스킹) | OneLake 보안에서는 지원되지 않습니다. | 옵션과 함께 ALTER TABLE SQL 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 UI를 통해 발생해야 하며 작업 영역 역할(관리자, 멤버, 기여자)의 제어를 받습니다.
작업 영역 역할 동작
작업 영역 수준에서 관리자, 구성원 또는 기여자 역할이 있는 사용자는 OneLake 보안 적용을 받지 않습니다. 이러한 역할은 상승된 권한을 가지며 RLS, CLS 및 OLS 정책을 완전히 우회합니다. OneLake 보안이 준수되도록 하려면 다음 요구 사항을 따릅니다.
작업 영역에서 사용자에게 뷰어 역할 할당 또는
읽기 전용 권한을 사용하여 사용자와 Lakehouse 또는 SQL 분석 엔드포인트를 공유합니다. 읽기 전용 액세스 권한이 있는 사용자만 OneLake 보안 역할에 따라 쿼리를 필터링합니다.
역할 우선 순위: 대부분의 허용 액세스 우선 순위
사용자가 여러 OneLake 역할에 속하는 경우 가장 허용되는 역할은 유효한 액세스를 정의합니다. 다음은 그 예입니다.
한 역할이 테이블에 대한 모든 권한을 부여하고 다른 역할이 RLS를 적용하여 행을 제한하는 경우 RLS는 적용되지 않습니다.
더 광범위한 액세스 역할이 우선합니다. 이 동작은 사용자가 의도치 않게 차단되지 않도록 하지만 충돌을 방지하기 위해 신중한 역할 디자인이 필요합니다. 행 또는 열 수준 액세스 제어를 적용할 때는 제한적이고 허용적인 역할을 상호 배타적으로 유지하는 것이 좋습니다.
자세한 내용은 OneLake 보안에 대한 데이터 액세스 제어 모델을 참조하세요.
OneLake와 SQL 분석 엔드포인트 간의 보안 동기화
사용자 ID 모드의 중요한 구성 요소는 보안 동기화 서비스입니다. 이 백그라운드 서비스는 OneLake의 보안 역할에 대한 변경 내용을 모니터링하고 이러한 변경 내용이 SQL 분석 엔드포인트에 반영되도록 합니다.
보안 동기화 서비스는 다음을 담당합니다.
새 역할, 업데이트, 사용자 할당 및 테이블 변경 내용을 포함하여 OneLake 역할의 변경 내용을 검색합니다.
OneLake 정의 정책(RLS, CLS, OLS)을 동등한 SQL 호환 데이터베이스 역할 구조로 변환합니다.
원격으로 액세스하는 경우에도 원래 OneLake 보안 설정을 적용할 수 있도록 바로 가기 개체 (다른 레이크하우스에서 제공하는 테이블)의 유효성을 올바르게 검사합니다.
이 동기화를 통해 OneLake 보안 정의가 신뢰할 수 있게 유지되며, 보안 동작을 복제하기 위한 수동 SQL 수준 개입이 필요하지 않습니다. 보안은 중앙에서 적용되므로 다음을 수행합니다.
이 모드에서는 T-SQL을 사용하여 RLS, CLS 또는 OLS를 직접 정의할 수 없습니다.
GRANT 또는 EXECUTE 문을 사용하여 뷰, 함수 및 저장 프로시저에 SQL 권한을 적용할 수 있습니다.
보안 동기화 오류 및 해결 방법
| Scenario | 사용자 ID 모드의 동작 | 위임된 모드의 동작 | 수정 작업 |
|---|---|---|---|
| RLS 정책은 삭제되거나 이름이 바뀐 열을 참조합니다. | 오류: *행 수준 보안 정책은 더 이상 존재하지 않는 열을 참조합니다.*데이터베이스는 정책이 수정될 때까지 오류 상태를 입력합니다. | 오류: 열 이름 열 이름이 <>잘못되었습니다. | 영향을 받는 역할을 하나 이상 업데이트하거나 제거하거나 누락된 열을 복원합니다. |
| CLS 정책은 삭제되거나 이름이 바뀐 열을 참조합니다. | 오류: *열 수준 보안 정책은 더 이상 존재하지 않는 열을 참조합니다.*데이터베이스는 정책이 수정될 때까지 오류 상태를 입력합니다. | 오류: 열 이름 열 이름이 <>잘못되었습니다. | 영향을 받는 역할을 하나 이상 업데이트하거나 제거하거나 누락된 열을 복원합니다. |
| RLS/CLS 정책은 삭제되거나 이름이 바뀐 테이블을 참조합니다. | 오류: 보안 정책은 더 이상 존재하지 않는 테이블을 참조합니다. | 오류가 표시되지 않습니다. 테이블이 없으면 쿼리가 자동으로 실패합니다. | 영향을 받는 역할을 하나 이상 업데이트하거나 제거하거나 누락된 테이블을 복원합니다. |
| DDM(동적 데이터 마스킹) 정책은 삭제되거나 이름이 바뀐 열을 참조합니다. | OneLake Security에서 지원되지 않는 DDM은 SQL을 통해 구현되어야 합니다. | 오류: 열 이름 열 이름이 <>잘못되었습니다. | 영향을 받는 DDM 규칙을 하나 이상 업데이트하거나 제거하거나 누락된 열을 복원합니다. |
| 시스템 오류(예기치 않은 오류) | 오류: 예기치 않은 시스템 오류가 발생했습니다. 다시 시도하거나 지원에 문의하세요. | 오류: SQL에 테이블 변경 내용을 적용하는 동안 내부 오류가 발생했습니다. | 다시 시도 작업; 문제가 지속되면 Microsoft 지원에 문의하세요. |
보안 동기화를 사용하는 바로 가기 동작
OneLake 보안은 진실의 근원에서 적용되므로 보안 동기화는 바로 가기와 관련된 테이블 및 뷰에 대한 소유권 체인을 사용하지 않도록 설정합니다. 이렇게 하면 다른 데이터베이스의 쿼리에 대해서도 원본 시스템 권한이 항상 평가되고 적용됩니다.
결과적으로 다음이 수행됩니다.
사용자는 바로 가기 원본(현재 Lakehouse 또는 SQL 분석 엔드포인트) 및 데이터가 물리적으로 상주하는 대상에 대해 유효한 액세스 권한이 있어야 합니다.
사용자에게 어느 한 쪽에 대한 권한이 없는 경우 액세스 오류와 함께 쿼리가 실패합니다 .
바로 가기를 참조하는 애플리케이션 또는 뷰를 디자인할 때 바로 가기 관계의 양쪽 끝에서 역할 할당이 제대로 구성되었는지 확인합니다.
이 디자인은 Lakehouse 경계를 넘어 보안 무결성을 유지하지만, 레이크하우스 간 역할이 정렬되지 않은 경우 액세스 실패가 발생할 수 있는 시나리오를 소개합니다.
OneLake 보안의 위임된 모드
위임된 ID 모드에서 SQL 분석 엔드포인트는 Microsoft Fabric에 현재 존재하는 것과 동일한 보안 모델을 사용합니다. 보안 및 권한은 SQL 계층에서 전적으로 관리되며 OneLake 역할 또는 액세스 정책은 테이블 수준 액세스에 적용되지 않습니다. 사용자가 SQL 분석 엔드포인트에 연결하고 쿼리를 발급하는 경우:
SQL은 SQL 권한 (GRANT, REVOKE, RLS, CLS, DDM, 역할 등)에 따라 액세스의 유효성을 검사합니다.
쿼리에 권한이 부여되면 시스템은 OneLake에 저장된 데이터에 계속 액세스합니다.
이 데이터 액세스는 항목 계정이라고도 하는 Lakehouse 또는 SQL 분석 엔드포인트 소유자의 ID를 사용하여 수행됩니다.
이 모델에서는 다음을 수행합니다.
로그인한 사용자는 OneLake로 전달되지 않습니다.
액세스의 모든 적용은 SQL 계층에서 처리되는 것으로 간주됩니다.
항목 소유자는 OneLake에서 워크로드를 대신하여 기본 파일을 읽을 수 있는 충분한 권한이 있어야 합니다.
이는 위임된 패턴이므로 소유자에 대한 SQL 권한과 OneLake 액세스 간의 정렬이 잘못되면 쿼리가 실패합니다. 이 모드는 다음과의 완전한 호환성을 제공합니다.
모든 개체 수준에서 SQL GRANT/REVOKE
SQL 정의 Row-Level 보안, Column-Level 보안 및 동적 데이터 마스킹
DBA 또는 애플리케이션에서 사용하는 기존 T-SQL 도구 및 사례
OneLake 액세스 모드를 변경하는 방법
액세스 모드는 SQL 분석 엔드포인트를 통해 OneLake를 쿼리할 때 데이터 액세스를 인증하고 적용하는 방법을 결정합니다. 다음 단계를 사용하여 사용자 ID 모드와 위임된 ID 모드 간에 전환할 수 있습니다.
패브릭 작업 영역으로 이동하여 레이크하우스를 엽니다. 오른쪽 위 모서리에서 Lakehouse에서 SQL 분석 엔드포인트로 전환합니다.
위쪽 탐색 창에서 보안 탭으로 이동하여 다음 OneLake 액세스 모드 중 하나를 선택합니다.
사용자 ID – 로그인한 사용자의 ID를 사용합니다. OneLake 역할을 적용합니다.
위임된 ID – 항목 소유자의 ID를 사용합니다. 는 SQL 권한만 적용합니다.
선택 항목을 확인하기 위한 팝업이 시작됩니다. 예를 선택하여 변경 사항을 확인합니다.
모드 간 전환 시 고려 사항
사용자 ID 모드로 전환
SQL RLS, CLS 및 테이블 수준 권한은 무시됩니다.
사용자가 액세스를 유지하려면 OneLake 역할을 구성해야 합니다.
뷰어 권한 또는 공유 읽기 전용 액세스 권한이 있는 사용자만 OneLake 보안에 의해 제어됩니다.
기존 SQL 역할은 삭제되며 복구할 수 없습니다.
위임된 ID 모드로 전환
OneLake 역할 및 보안 정책은 더 이상 적용되지 않습니다.
SQL 역할 및 보안 정책이 활성화됩니다.
항목 소유자에게 유효한 OneLake 액세스 권한이 있거나 모든 쿼리가 실패할 수 있습니다.
제한점
독자에게만 적용됩니다. OneLake Security는 데이터에 액세스하는 사용자를 뷰어로 제어합니다. 다른 작업 영역 역할(관리자 구성원 또는 기여자)의 사용자는 OneLake 보안을 우회하고 모든 권한을 유지합니다.
SQL 개체는 소유권을 상속하지 않습니다. 바로 가기는 SQL 분석 엔드포인트에 테이블로 표시됩니다. 직접 또는 뷰를 통해 이러한 테이블에 액세스할 때 저장 프로시저 및 기타 파생 SQL 개체는 개체 수준 소유권을 전달하지 않습니다. 보안 바이패스를 방지하기 위해 런타임에 모든 사용 권한을 확인합니다.
바로 가기 변경 트리거 유효성 검사 가동 중지 시간: 바로 가기 대상이 변경되면(예: 이름 바꾸기, URL 업데이트) 시스템이 새 대상의 유효성을 검사하는 동안 데이터베이스가 잠시 단일 사용자 모드 로 전환됩니다. 이 기간 동안 쿼리는 차단되지만 이러한 작업은 매우 빠르지만 때로는 다른 내부 프로세스에 따라 동기화하는 데 최대 5분이 걸릴 수 있습니다.
- 스키마 바로 가기를 만들면 유효성 검사에 영향을 미치고 메타데이터 동기화를 지연시키는 알려진 오류가 발생할 수 있습니다.
지연된 권한 전파: 권한 변경은 즉시 수행되지 않습니다. 보안 모드(사용자 ID와 위임됨) 간에 전환하려면 적용하기 전에 전파하는 데 시간이 필요할 수 있지만 1분 미만이 소요됩니다.
컨트롤 플레인 종속성: 작업 영역 컨트롤 플레인에 아직 없는 사용자 또는 그룹에는 사용 권한을 적용할 수 없습니다. 원본 항목을 공유해야 하거나 사용자가 뷰어 작업 영역 역할의 멤버여야 합니다.
가장 허용되는 액세스가 우선합니다. 사용자가 여러 그룹 또는 역할에 속하는 경우 가장 허용되는 유효 권한은 적용됩니다 . 예를 들어 사용자가 한 역할을 통해 DENY를 사용하고 다른 역할을 통해 GRANT를 사용하는 경우 GRANT가 우선 적용됩니다.
위임된 모드 제한 사항: 원본 항목에 항목 소유자에게 전체 테이블 액세스 권한을 부여하지 않는 OneLake 보안 정책이 있는 경우 위임된 모드에서 바로 가기 테이블의 메타데이터 동기화가 실패할 수 있습니다.
DENY 동작: 여러 역할이 단일 바로 가기 테이블에 적용되는 경우 사용 권한의 교집합은 SQL Server 의미 체계를 따릅니다. DENY는 GRANT를 재정의합니다. 이렇게 하면 예기치 않은 액세스 결과가 생성됩니다.
예상 오류 조건: 다음과 같은 시나리오에서 오류가 발생할 수 있습니다.
바로 가기 대상의 이름이 변경되었거나 잘못되었습니다.
- 예: 테이블 원본이 삭제된 경우
RLS(Row-Level 보안) 구성 오류
RLS 필터링에 대한 일부 식은 OneLake에서 지원되지 않으며 무단 데이터 액세스를 허용할 수 있습니다.
필터 식에 사용된 열을 삭제하면 RLS가 무효화되고 OneLake 보안 패널에서 RLS가 고정될 때까지 메타데이터 동기화가 부실합니다.
공개 미리 보기의 경우 단일 식 테이블만 지원합니다. 현재 동적 RLS 및 다중 테이블 RLS는 지원되지 않습니다.
CLS(Column-Level 보안) 제한 사항
CLS는 열 허용 목록을 유지 관리하여 작동합니다. 허용되는 열이 제거되거나 이름이 바뀌면 CLS 정책이 유효하지 않습니다.
CLS가 유효하지 않으면 ONELake 보안 패널에서 CLS 규칙이 수정될 때까지 메타데이터 동기화가 차단됩니다.
메타데이터 또는 권한 동기화 실패
- 열 이름 바꾸기와 같은 테이블 변경 내용이 있는 경우 보안은 새 개체에 복제되지 않으며 열이 존재하지 않음을 보여 주는 UI 오류가 표시됩니다.
테이블 이름은 보안 정책을 유지하지 않습니다. OLS(OneLake Security) 역할이 스키마 수준에서 정의된 경우 테이블 이름이 변경되지 않는 한 해당 역할은 계속 적용됩니다. 테이블 이름을 바꾸면 연결이 끊어지고 보안 정책이 자동으로 마이그레이션되지 않습니다. 이로 인해 정책이 다시 적용될 때까지 의도하지 않은 데이터가 노출될 수 있습니다.
OneLake 보안 역할에는 이름이 124자를 초과할 수 없습니다. 그렇지 않으면 보안 동기화가 역할을 동기화할 수 없습니다.
OneLake 보안 역할은 OLS_ 접두사를 사용하여 SQL 분석 엔드포인트에 전파됩니다.
OLS_ 역할에 대한 사용자 변경은 지원되지 않으며 예기치 않은 동작이 발생할 수 있습니다.
메일 사용 보안 그룹 및 배포 목록은 지원되지 않습니다.
Lakehouse의 소유자는 관리자, 구성원 또는 기여자 작업 영역 역할의 구성원이어야 합니다. 그렇지 않으면 보안이 SQL 분석 엔드포인트에 적용되지 않습니다.