ABAC(특성 기반 액세스 제어)에 대한 핵심 개념

이 페이지에서는 ABAC, 관리 태그, 정책사용자 정의 함수 를 사용하여 사용자가 볼 수 있는 행과 열 값이 표시되는 방식 및 해당 이점을 제어하는 방법을 소개합니다. 이 페이지에서는 ABAC를 설정하는 데 필요한 권한과 팀 전체에서 사용할 수 있는 업무 분리에 대해서도 설명합니다.

자습서, 정책 관리, 모범 사례 및 제한 사항을 포함한 모든 ABAC 항목에 대한 개요는 Unity 카탈로그의 특성 기반 액세스 제어 를 참조하세요.

ABAC란?

ABAC(특성 기반 액세스 제어) 는 보안 개체와 연결된 특성에 대해 평가된 정책에 따라 액세스 결정이 결정되는 동적 액세스 제어 모델입니다. Unity 카탈로그에서 이러한 특성은 관리 태그를 통해 표시됩니다. 이러한 관리 태그는 정책 조건에서 카탈로그 또는 스키마와 같은 지정된 범위 내의 데이터 개체와 일치하도록 사용됩니다. 이렇게 하면 단일 정책이 해당 조건을 충족하는 여러 데이터 개체에 자동으로 적용될 수 있습니다.

예를 들어 ABAC 정책은 태그HR가 지정된 스키마 내의 테이블의 태그PII가 지정된 모든 열을 마스킹할 수 있습니다. 새 데이터 개체가 만들어지고 태그가 지정되면 정책은 각 개체에 대해 별도의 정책 정의를 요구하지 않고 자동으로 적용됩니다.

ABAC는 테이블, 구체화된 뷰 및 스트리밍 테이블에 대한 행 필터 정책열 마스크 정책을 통해 행 및 열 수준 보안을 지원합니다. 행 필터 정책은 사용자가 볼 수 있는 행을 제한합니다. 열 마스크 정책은 열 값이 사용자에게 표시되는 방식을 제어합니다.

테이블 수준 행 필터 및 열 마스크와의 비교는 ABAC와 테이블 수준 행 필터 및 열 마스크를 사용하는 경우를 참조하세요.

관리 태그

Unity 카탈로그에서 특성은 제어 태그로 구현됩니다. 관리 태그는 계정 수준에서 정의되고 작업 영역 개체 외에도 카탈로그, 스키마, 테이블 및 열과 같은 Unity 카탈로그 보안 개체에 적용되는 키-값 쌍입니다. 민감도, 분류 또는 비즈니스 도메인과 같은 특성을 나타냅니다.

기본적으로 태그는 부모 카탈로그와 스키마에서 테이블로 상속되지만 테이블에서 열로 상속되지는 않습니다. 모든 수준에서 상속된 태그를 재정의할 수 있지만 열 수준 태그는 직접 적용해야 합니다.

관리 태그 계층 구조 다이어그램

관리 태그는 지정된 태그가 직접 또는 태그 상속을 통해 대상 데이터 개체에 있는지 여부를 확인하는 같은 has_tag()기본 제공 함수를 사용하여 has_tag_value() 조건에서 참조할 수 있습니다.

제어 태그는 계정 수준에서 정의됩니다. 즉, 여러 메타 저장소를 포함하여 계정의 전체 데이터 자산에서 동일한 태그 분류를 사용할 수 있습니다.

자세한 내용은 관리 태그 및Unity 카탈로그 보안 개체에 태그 적용을 참조하세요.

정책

정책은 태그 조건에 따라 액세스 제어 규칙을 정의하기 위해 Unity 카탈로그의 보안 개체 에 연결됩니다. 예제는 아래와 같습니다.

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

각 정책은 다음을 지정합니다.

  • 범위: ON 절에 명시된 정책이 연결된 보안 가능한 개체입니다. 보안 가능한 항목에 정책을 연결하면 FOR 절에 명시된 형식의 모든 개체에 대해 해당 보안 가능한 항목과 그 모든 하위 항목에서 정책 조건이 평가됩니다.
    • 현재 지원되는 정책 범위는 CATALOG, SCHEMA, 또는 TABLE입니다.
    • 스트리밍 테이블과 구체화된 뷰를 포함한 테이블만이 현재 FOR TABLES 절을 사용하여 지정할 수 있는 유일한 지원되는 보안 형식입니다.
    • 카탈로그에 연결된 정책은 해당 카탈로그의 모든 테이블에 대해 평가됩니다. 스키마에 연결된 정책은 해당 스키마의 모든 테이블에 대해 평가됩니다. 테이블에 연결된 정책은 해당 테이블에 대해서만 평가됩니다.

메모

Databricks는 거버넌스 효율성을 최대화하기 위해 가장 높은 적용 가능한 수준(일반적으로 카탈로그)에 정책을 연결하는 것이 좋습니다. ABAC 정책에 대한 모범 사례를 참조하세요.

  • 대상 주체: 정책이 적용되는 대상과 면제되는 대상을 설명합니다. 이 절은 TO 정책의 적용을 받는 사용자, 그룹 또는 서비스 주체를 지정합니다. 선택적 EXCEPT 절은 이 정책에서 특정 보안 주체를 제외합니다.
  • 작업: 정책이 행 필터 또는 열 마스크를 적용하는지 여부입니다. 작업은 필터링 또는 마스킹 논리를 정의하는 UDF(사용자 정의 함수) 에 의해 구현됩니다. 정책 유형을 참조하세요.
  • 조건: 정책의 대상이 되는 테이블 또는 열을 결정하는 태그 기반 식입니다. 조건 및 기본 제공 함수를 참조하세요.

정책은 UI를 통해 또는 SQL 문(예: CREATE POLICY, DROP POLICY또는 SHOW POLICIESDESCRIBE POLICY, Databricks SDK 또는 Terraform)을 사용하여 프로그래밍 방식으로 만들어지고 관리됩니다. 전체 구문 및 예제에 대한 ABAC 정책 만들기 및 관리를 참조하세요.

정책 유형

ABAC는 행 필터 정책과 열 마스크 정책의 두 가지 정책 유형을 지원합니다. 둘 다 필터링 또는 마스킹 논리를 구현하려면 UDF 가 필요합니다.

행 필터 정책

행 필터 정책은 조건 및 기본 제공 함수와 일치하는 태그로 식별되는 열의 값을 기반으로 테이블에서 사용자가 볼 수 있는 행을 제한합니다. 정책은 각 행을 평가하는 UDF를 참조합니다. 함수가 반환 FALSE 하는 행은 쿼리 결과에서 제외됩니다. 인수는 USING COLUMNS 절을 통해 UDF로 전달됩니다.

예제 사용 사례: 판매 카탈로그의 경우 EMEA 팀에서 열에 태그 region가 지정된 모든 테이블에서 EMEA 판매 레코드만 볼 수 있는지 확인합니다.

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

열 마스크 정책

열 마스크 정책은 조건 및 기본 제공 함수와 일치하는 태그로 식별되는 특정 열에 대해 사용자가 보는 값을 제어합니다. 정책은 열 값을 입력으로 사용하고 원래 값 또는 마스킹된 버전을 반환하는 UDF를 참조합니다. 마스킹된 열 값은 ON COLUMN 절에서 첫 번째 인수로 자동 바인딩되며, USING COLUMNS을 통해 추가 인수를 전달할 수 있습니다. 반환 형식은 열의 데이터 형식과 일치하거나 캐스팅할 수 있어야 합니다.

예제 사용 사례: 사용자가 ***-**-XXXX(마지막 4자리만 해당)을 볼 수 있도록, pii : ssn태그가 지정된 SSN 열을 마스킹합니다. 단, 정책에서 제외된 규정 준수 그룹에 속한 경우는 제외됩니다.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

이 절은 USING COLUMNS UDF에 인수를 전달합니다. 태그 기반 식과 일치하는 열의 별칭 또는 상수 값(따옴표 붙은 문자열, 숫자 리터럴, 부울 값(TRUE/FALSE또는 NULL))을 함수에서 예상하는 순서대로 허용합니다. 열 마스크 정책의 경우 마스킹된 열(자동으로 ON COLUMN바인딩됨)을 벗어난 추가 인수입니다. 이렇게 하면 여러 매개 변수가 있는 정책에서 단일 UDF를 다시 사용할 수 있습니다.

성능 향상을 위해 SQL UDF를 사용하는 것이 좋습니다. Unity 카탈로그에 등록된 Python UDF도 지원되지만 쿼리 최적화 프로그램은 SQL UDF를 사용할 수 있는 방식으로 인라인 또는 최적화할 수 없습니다. UDF 언어 선택에 대한 지침은 성능 고려 사항을 참조하세요.

조건 및 기본 제공 함수

조건은 정책이 해당 범위 내에서 대상으로 하는 테이블과 열을 결정하는 태그 기반 식입니다.

  • 테이블 조건 (WHEN 절): 태그에 따라 테이블과 일치하는 불리언 식입니다. 생략하면 기본적으로 정책이 TRUE범위의 모든 테이블에 적용됩니다.
  • 열 조건 (MATCH COLUMNS 절): 정책 대상이 되는 열을 식별하는 하나 이상의 쉼표로 구분된 부울 식입니다. 각 식은 같은 단일 기본 제공 함수 has_tag('pii')이거나 , 같은 논리 연산자를 사용하는 조합일 수 있습니다 has_tag_value('pii', 'ssn') AND has_tag('sensitive'). 각 식에는 AS 다음에 지정된 별칭이 할당될 수 있으며, 이는 ON COLUMNUSING COLUMNS 절에서 참조될 수 있습니다. 정책에는 최대 3개의 열 식이 포함될 수 있으며, 정책을 적용하려면 모두 일치해야 합니다.

두 절 형식 모두 Unity 카탈로그에서 보안 가능한 메타데이터에 대해 평가하는 다음과 같은 기본 제공 함수를 사용합니다.

함수 컨텍스트 Description
has_tag('tag_name') 테이블 및 열 리소스에 지정된 태그가 있으면 true를 반환합니다. 테이블 조건(WHEN)에서 테이블에 직접 설정되거나 부모 카탈로그 또는 스키마에서 상속된 태그를 확인합니다. 열 조건(MATCH COLUMNS)에서는 열에만 직접 설정된 태그가 테이블 태그와 일치하지 않는지 확인합니다.
has_tag_value('tag_name', 'tag_value') 테이블 및 열 리소스에 지정된 값이 있는 지정된 태그가 있으면 true를 반환합니다. 와 동일한 컨텍스트 동작 has_tag()

태그는 테이블에서 열로 전파되지 않습니다. has_tag()MATCH COLUMNS 절에서 사용할 때, 부모 테이블이나 상위 항목의 태그가 아닌 열 수준 태그와만 일치합니다.

메모

has_tag 함수와 has_tag_value 함수는 snake_case 명명 규칙을 사용합니다. 이전 camelCase 양식(hasTag, hasTagValue)은 계속 작동하지만 권장되지는 않습니다. Azure Databricks 새 정책을 만들 때 camelCase 양식을 더 이상 사용하지 않을 계획입니다. 기존 정책은 영향을 받지 않습니다.

예: 두 열 조건문 사용 customers 스키마에는 태그가 지정된 전자 메일 열 pii : email 과 태그가 지정된 동의 열이 있는 테이블이 consent_to_contact있습니다. 고객이 연락하는 데 동의하지 않는 한 정책은 이메일 주소를 마스킹합니다. 다음 두 열(컬럼) 조건을 사용합니다.

  1. has_tag_value('pii', 'email') 은 전자 메일 주소(마스킹할 열)가 포함된 열을 식별합니다.
  2. has_tag('consent_to_contact') 는 동의 정보가 포함된 열을 식별합니다(UDF에서 마스크할지 여부를 결정하는 데 사용됨).
CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

이 정책은 pii : email 태그가 지정된 열과 consent_to_contact 태그가 지정된 열이 모두 있는 테이블에만 적용됩니다. 테이블에 두 조건과 일치하는 열이 없으면 정책이 적용되지 않고 데이터가 마스크되지 않은 상태로 반환됩니다.

UDF(사용자 정의 함수)

행 필터 및 열 마스크 정책은 UDF(사용자 정의 함수)를 사용하여 필터링 또는 마스킹 논리를 구현합니다. UDF를 만들고 관리하는 방법은 Unity 카탈로그의 UDF(사용자 정의 함수)를 참조하고, 예제는 행 필터링 및 열 마스킹에 대한 공통 패턴을 참조하세요.

의무 및 사용 권한 분리

ABAC 설정에는 각각 고유한 권한 요구 사항이 있는 여러 단계가 포함됩니다. 조직은 업무를 분리하는 방법에 따라 이러한 작업을 특수 그룹에 분산할 수 있습니다. 예를 들어 조직은 태그 분류를 중앙에서 정의한 다음, 데이터 관리자가 데이터를 분류하고, 거버넌스 관리자가 정책을 작성하고, 데이터 작성자가 관리되는 범위 내에서 개체를 만들고, 데이터 소비자가 결과를 쿼리하게 할 수 있습니다.

ABAC에 대한 의무 분리

  1. 태그 분류를 만듭니다. 모든 사용자가 정책을 적용하거나 쓰기 전에 제어 태그 키와 해당 허용 값을 정의합니다. 예를 들어, 제어된 값(public, internal, confidential, restricted)으로 sensitivity 태그 또는 ssn, email, 그리고 phone_number와 같은 값으로 pii 태그를 만드십시오. 명명 규칙과 속성 표준화에 대한 권장 사항은 속성 및 명명 표준화를 참조하세요.

    • 필요한 권한: 계정 관리자 또는 계정 수준에서 태그에 대한 권한이 있는 CREATE 사용자입니다.
  2. 데이터 자산에 태그를 지정합니다. 데이터 관리자, 데이터 작성자 또는 AI 분류 시스템은 카탈로그, 스키마, 테이블 또는 열에 관리 태그를 적용합니다. 예를 들어 개인 식별 정보를 포함하는 열에 pii : ssn 태그를 지정합니다. 올바른 태그 지정은 ABAC 정책을 적용하는 데 필수적인 첫 번째 단계입니다.

    • 필요한 권한: ASSIGN 태그 및 APPLY TAG 개체에 대한 권한입니다.

경고

태그 지정은 보안 경계입니다. 사용자가 데이터 자산에 대한 태그를 변경할 수 있는 경우 해당 자산에 적용되는 정책을 변경할 수 있습니다. 조직은 태그를 적용하고 태그 변경 내용을 감사할 수 있는 사용자를 제어해야 합니다.

  1. 정책을 만듭니다. 거버넌스 관리자는 카탈로그 또는 스키마와 같은 범위에서 정책을 만듭니다. 정책은 적용 대상, 평가되는 조건 및 필터링 또는 마스킹 논리를 구현하는 UDF를 지정합니다.

    • 필수 권한: MANAGE 정책이 연결된 보안 개체에 대한 권한 또는 개체 소유권(카탈로그, 스키마 또는 테이블) 및 EXECUTE UDF에 대한 권한입니다.
  2. 데이터 개체를 만듭니다. 데이터 작성자는 액세스 권한이 부여된 범위 내에 테이블을 만듭니다. 새 테이블은 카탈로그 및 스키마와 같은 부모 개체에서 태그를 상속합니다. 데이터 작성자는 자신이 생성한 개체에 자동으로 APPLY TAG이 적용되며, 추가 태그를 적용할 수 있습니다. 또는 자동 데이터 분류 를 사용하여 태그 지정을 처리할 수 있습니다. 조직에서 데이터 작성자가 자신의 개체에 태그를 지정하는 경우 명확한 태그 지정 방법을 설정해야 합니다. 정책이 더 높은 수준으로 설정된 경우 데이터 작성자는 액세스 제어를 구성할 필요가 없으며 Azure Databricks 권장합니다.

    • 필수 권한: CREATE TABLE 또는 부모 개체에 대한 기타 관련 만들기 권한입니다.
  3. 데이터를 쿼리합니다. 데이터 소비자가 정책 범위 내에서 테이블을 쿼리하면 정책이 자동으로 평가됩니다. 테이블 또는 열이 정책의 조건과 일치하고 사용자가 제외되지 않으면 소비자는 필터링되거나 마스킹된 데이터를 볼 수 있습니다.

    • 필요한 권한: 사용자에게 직접 개체 부여를 통해 테이블에 대한 권한(예: SELECT)을 부여해야 합니다. ABAC 행 필터 및 열 마스킹 정책은 자체적으로 권한을 부여하지 않습니다. 사용자가 이미 액세스할 수 있는 테이블에 대한 레코드 또는 마스크 열만 필터링합니다.

ABAC의 이점

  • 특성을 기반으로 다시 사용할 수 있는 정책: 단일 정책은 하나의 특정 개체에 연결되지 않고 동일한 특성 기반 조건과 일치하는 여러 데이터 개체에 적용할 수 있습니다.

  • 새 개체에 대한 자동 애플리케이션: 범위 내에서 새 데이터 개체를 만들고 관련 특성으로 태그를 지정하면 기존 ABAC 정책이 추가 구성 없이 적용됩니다. 정책은 향후 권한 부여처럼 작동합니다. 즉, 새 데이터가 생성되고 적절하게 태그가 지정될 때 액세스 제어가 자동으로 적용됩니다.

  • 범위 내에서 일관된 적용: 카탈로그 또는 스키마 수준에서 연결된 정책은 해당 범위에서 일치하는 데이터 개체에 대해 동적으로 평가되므로 유사한 데이터가 필터링되거나 마스킹되는 방식의 차이가 제거됩니다.

  • 유지 관리의 지속적 감축: 테이블 수준 행 필터 및 열 마스크가 필요한 경우, 각 개체를 다시 방문하는 대신, 정책 논리 또는 제어 태그를 업데이트하여 변경할 수 있습니다.

  • 중앙 집중식 거버넌스: 정책을 한 번 정의하고 일치하는 여러 데이터 개체에 적용할 수 있으므로 거버넌스 팀은 더 적은 정책 정의로 데이터 자산의 큰 부분에 걸쳐 제어를 관리할 수 있습니다.

자세한 정보