다음을 통해 공유

패브릭 데이터 웨어하우징의 행 수준 보안

  • 아티클

적용 대상: Microsoft Fabric의 SQL 분석 엔드포인트 및 웨어하우스

RLS(행 수준 보안)를 사용하면 그룹 멤버 자격 또는 실행 컨텍스트를 사용하여 데이터베이스 테이블의 행에 대한 액세스를 제어할 수 있습니다. 예를 들어 작업자가 자신의 부서와 관련된 데이터 행에만 액세스하도록 할 수 있습니다. 또 다른 예는 고객의 데이터 액세스를 다중 테넌트 아키텍처의 해당 회사와 관련된 데이터로만 제한하는 것입니다. 이 기능은 SQL Server의 행 수준 보안과 유사합니다.

데이터 수준의 행 수준 보안

행 수준 보안은 애플리케이션의 보안 설계 및 코딩을 간소화합니다. 행 수준 보안을 사용하면 데이터 행 액세스에 대한 제한을 구현할 수 있습니다.

액세스 제한 논리는 단일 애플리케이션 계층이 아닌 데이터베이스 계층에 있습니다. 데이터베이스는 Power BI를 포함한 모든 애플리케이션 또는 보고 플랫폼에서 데이터 액세스를 시도할 때마다 액세스 제한을 적용합니다. 이렇게 하면 보안 시스템의 노출 영역을 줄임으로써 보안 시스템을 보다 안정적이고 강력하게 만들 수 있습니다. 행 수준 보안은 Fabric의 웨어하우스 또는 SQL 분석 엔드포인트에 대한 쿼리에만 적용됩니다. Direct Lake 모드의 웨어하우스에 대한 Power BI 쿼리는 행 수준 보안을 준수하기 위해 직접 쿼리 모드로 대체됩니다.

특정 행에 대한 액세스를 특정 사용자로 제한

CREATE SECURITY POLICY Transact-SQL 문을 사용하여 RLS를 구현하고 인라인 테이블 반환 함수로 만든 조건자를 구현합니다.

기본 데이터 원본이 변경되지 않았기 때문에 행 수준 보안이 공유 웨어하우스 또는 레이크하우스에 적용됩니다.

조건자 기반 행 수준 보안

Fabric Synapse Data Warehouse의 행 수준 보안은 조건자 기반 보안을 지원합니다. 필터 조건자는 읽기 작업에 사용할 수 있는 행을 자동으로 필터링합니다.

테이블의 행 수준 데이터에 대한 액세스는 인라인 테이블 반환 함수로 정의된 보안 조건자에 의해 제한됩니다. 그런 다음, 보안 정책에 의해 함수가 호출되고 적용됩니다. 필터 조건자의 경우 애플리케이션은 결과 집합에서 필터링된 행을 인식하지 못합니다. 모든 행이 필터링되면 null 세트가 반환됩니다.

필터 조건자는 기본 테이블에서 데이터를 읽는 동안 적용됩니다. 모든 get 작업에 영향을 줍니다. SELECT, DELETE및 UPDATE. 사용자는 필터링된 행을 선택하거나 삭제할 수 없습니다. 사용자는 필터링된 행을 업데이트할 수 없습니다. 그러나 나중에 필터링되는 방식으로 행을 업데이트할 수 있습니다.

필터 조건자 및 보안 정책에는 다음과 같은 동작이 있습니다.

  • 다른 테이블과 조인하거나 함수를 호출하는 조건자 함수를 정의할 수 있습니다. SCHEMABINDING = ON(기본값)을 사용하여 보안 정책을 만든 경우에는 조인 또는 함수를 쿼리에서 액세스할 수 있으며, 다른 추가 권한 검사 없이 올바르게 작동합니다.

  • 보안 조건자가 정의되었지만 사용하지 않도록 설정된 테이블에 대해 쿼리를 실행할 수 있습니다. 필터링되거나 차단된 행은 영향을 받지 않습니다.

  • dbo 사용자, 역할의 db_owner 멤버 또는 테이블 소유자가 보안 정책이 정의되고 사용하도록 설정된 테이블을 쿼리하는 경우 행은 보안 정책에 정의된 대로 필터링되거나 차단됩니다.

  • 스키마 바운드 보안 정책에 의해 바인딩된 테이블의 스키마를 변경하려 하면 오류가 발생합니다. 그러나 조건자에 의해 참조되지 않는 열은 변경할 수 있습니다.

  • 지정된 작업에 대해 정의된 조건자가 이미 있는 테이블에 조건자를 추가하려고 하면 오류가 발생합니다. 조건자가 사용되도록 설정된 상태인지에 관계없이 오류가 발생합니다.

  • 스키마 바인딩된 보안 정책 내의 테이블에 대한 조건자로 사용되는 함수를 수정하려고 하면 오류가 발생합니다.

  • 겹치지 않는 조건자를 포함하는 여러 활성 보안 정책을 정의하면 성공합니다.

필터 조건자는 다음 동작을 수행합니다.

  • 테이블의 행을 필터링하는 보안 정책을 정의합니다. 애플리케이션은 , UPDATE및 DELETE 작업에 대해 SELECT필터링된 행을 인식하지 못합니다. 모든 행이 필터링되는 상황을 포함합니다. 애플리케이션은 다른 작업 중에 필터링되더라도 행을 사용할 수 INSERT 있습니다.

사용 권한

보안 정책을 만들거나 변경하거나 삭제하려면 권한이 필요합니다 ALTER ANY SECURITY POLICY . 보안 정책을 만들거나 삭제하려면 스키마에 대한 권한이 필요합니다 ALTER .

또한 추가되는 각 조건자마다 다음 권한이 필요합니다.

  • SELECT조건자로 사용되는 함수에 대한 권한과 REFERENCES

  • REFERENCES 정책에 바인딩되는 대상 테이블에 대한 사용 권한입니다.

  • REFERENCES 인수로 사용되는 대상 테이블의 모든 열에 대한 사용 권한입니다.

보안 정책은 데이터베이스의 dbo 사용자를 포함하여 모든 사용자에게 적용됩니다. Dbo 사용자는 보안 정책을 변경하거나 삭제할 수 있습니다. 그러나 보안 정책에 대한 변경 내용을 감사할 수 있습니다. 관리자, 멤버 또는 기여자 같은 역할의 멤버가 데이터 문제를 해결하거나 유효성을 검사하기 위해 모든 행을 확인해야 하는 경우 이를 허용하도록 보안 정책을 작성해야 합니다.

를 사용하여 보안 정책을 만든 SCHEMABINDING = OFF경우 대상 테이블을 쿼리하려면 조건자 함수 및 조건자 함수 내에서 사용되는 추가 테이블, 뷰 또는 함수에 대한 사용 권한이 있어야 합니다 SELECT EXECUTE . SCHEMABINDING = ON (기본값)을 사용하여 보안 정책을 생성된 경우 사용자가 대상 테이블을 쿼리할 때 이러한 권한 검사는 무시됩니다.

보안 고려 사항: 측면 채널 공격

다음 두 가지 시나리오를 고려하고 준비합니다.

악의적인 보안 정책 관리자

중요한 열 위에 보안 정책을 만들 수 있는 충분한 권한과 인라인 테이블 반환 함수를 만들거나 변경할 수 있는 권한이 있는 악의적인 보안 정책 관리자는 데이터를 유추하기 위해 사이드 채널 공격을 사용하도록 설계된 인라인 테이블 반환 함수를 악의적으로 만들어 데이터 반출을 수행하기 위해 테이블에 대한 선택 권한이 있는 다른 사용자와 공모할 수 있음을 관찰하는 것이 중요합니다. 이러한 공격에는 공모(또는 악의적인 사용자에게 부여되는 과도한 권한)가 필요하고, 정책을 수정하고(스키마 바인딩을 중단하기 위해 조건자를 제거할 수 있는 권한 필요) 인라인 테이블 반환 함수를 수정하고 대상 테이블에서 select 문을 반복적으로 하는 실행하는 작업을 여러 번 반복해야 합니다. 필요에 따라 권한을 제한하고 의심스러운 활동을 모니터링하는 것이 좋습니다. 행 수준 보안과 관련된 정책 및 인라인 테이블 반환 함수와 같은 작업을 모니터링해야 합니다.

신중하게 작성된 쿼리

오류를 사용하여 데이터를 유출하는 신중하게 작성된 쿼리를 사용하여 정보 유출을 일으킬 수 있습니다. 예를 들어 악의적 SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME='John Doe'; 인 사용자에게 John Doe의 급여가 정확히 $100,000임을 알릴 수 있습니다. 악의적인 사용자가 다른 사용자의 급여를 직접 쿼리하지 못하도록 하기 위한 보안 조건자가 있지만 사용자는 쿼리에서 0으로 나누기 예외를 반환하는 시기를 결정할 수 있습니다.

예제

Microsoft Fabric에서 행 수준 보안 웨어하우스 및 SQL 분석 엔드포인트를 시연할 수 있습니다.

다음 예제에서는 Fabric의 Warehouse와 함께 작동하지만 SQL 분석 엔드포인트에서는 기존 테이블을 사용하는 샘플 테이블을 만듭니다. SQL 분석 엔드포인트에서는 수행할 수 없지만CREATE TABLE, 수행할 수 CREATE SCHEMACREATE FUNCTION있습니다CREATE SECURITY POLICY.

이 예제에서는 먼저 스키마 sales, 테이블을 sales.Orders만듭니다.

CREATE SCHEMA sales;
GO

-- Create a table to store sales data
CREATE TABLE sales.Orders (
    SaleID INT,
    SalesRep VARCHAR(100),
    ProductName VARCHAR(50),
    SaleAmount DECIMAL(10, 2),
    SaleDate DATE
);

-- Insert sample data
INSERT INTO sales.Orders (SaleID, SalesRep, ProductName, SaleAmount, SaleDate)
VALUES
    (1, 'Sales1@contoso.com', 'Smartphone', 500.00, '2023-08-01'),
    (2, 'Sales2@contoso.com', 'Laptop', 1000.00, '2023-08-02'),
    (3, 'Sales1@contoso.com', 'Headphones', 120.00, '2023-08-03'),
    (4, 'Sales2@contoso.com', 'Tablet', 800.00, '2023-08-04'),
    (5, 'Sales1@contoso.com', 'Smartwatch', 300.00, '2023-08-05'),
    (6, 'Sales2@contoso.com', 'Gaming Console', 400.00, '2023-08-06'),
    (7, 'Sales1@contoso.com', 'TV', 700.00, '2023-08-07'),
    (8, 'Sales2@contoso.com', 'Wireless Earbuds', 150.00, '2023-08-08'),
    (9, 'Sales1@contoso.com', 'Fitness Tracker', 80.00, '2023-08-09'),
    (10, 'Sales2@contoso.com', 'Camera', 600.00, '2023-08-10');

Security 스키마, 함수 Security.tvf_securitypredicate및 보안 정책을 SalesFilter만듭니다.

-- Creating schema for Security
CREATE SCHEMA Security;
GO
 
-- Creating a function for the SalesRep evaluation
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO
 
-- Using the function to create a Security Policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

관련 콘텐츠

다음 단계

패브릭 데이터 웨어하우징 행 수준 보안 구현