ABAC와 함께 RBAC 사용

Important

RBAC는 공개 미리 보기로 제공됩니다. ABAC는 일반적으로 사용할 수 있습니다. 이 페이지에서는 두 가지가 함께 작동하는 방법을 설명합니다.

Unity 카탈로그의 RBAC(역할 기반 액세스 제어) 및 ABAC(특성 기반 액세스 제어) 는 함께 작동하도록 설계된 보완적인 컨트롤입니다. 다음과 같은 다양한 질문에 답변합니다.

  • RBAC는 사용자가 세션에서 어떤 ID로 동작하는지를 제어합니다. 사용자는 자신의 역할 대신 해당 역할의 권한으로 작업할 역할을 가정합니다. RBAC를 사용하여 한 사용자에게 명시적으로 전환할 수 있는 여러 가지 권한 집합(예: 임상 시험, 프로젝트 또는 민감도 계층 간에 액세스 구분)을 제공합니다.
  • ABAC는 활성 ID가 볼 수 있는 데이터를 행 단위 또는 열 단위로 제어합니다. 정책은 관리 태그 를 통해 데이터에 연결되고 쿼리를 실행하는 ID에 적용됩니다. 데이터 특성에 의해 구동되는 여러 테이블에서 일관된 필터링 또는 마스킹을 위해 ABAC를 사용합니다.

RBAC는 세션의 활성 ID를 설정하고 ABAC는 해당 ID에 대해 해당 정책을 평가합니다. 이 페이지에서는 해당 상호 작용이 실제로 어떻게 진행되는지, ID 관련 SQL 함수의 동작 및 결합된 사용 패턴을 다룹니다.

역할을 가정할 때 ID 함수가 작동하는 방식

Unity 카탈로그의 ID 관련 SQL 함수는 실제 인증 사용자가 아니라 세션의 활성 ID를 기준으로 확인됩니다. 사용자가 역할을 가정하면 활성 세션 ID가 역할이 됩니다.

Function 사용자가 자신의 사용자 ID 역할을 하는 경우 사용자가 역할을 가정하는 경우
current_user() 사용자의 사용자 이름을 반환합니다. 맡은 역할의 이름을 반환합니다.
is_member(group) 사용자가 그룹의 구성원(작업 영역-로컬 그룹 또는 작업 영역에 할당된 계정 그룹)인지 여부를 반환 true 합니다. 가정된 역할 자체가 group의 멤버인 경우에만 true을 반환합니다. 기반 사용자는 구성원이지만 가정된 역할은 속해 있지 않은 그룹에 대해 false를 반환합니다.
is_account_group_member(group) 사용자가 계정 수준 그룹의 구성원인지를 반환 true 합니다. is_member와 동일: 기본 사용자의 그룹 멤버십이 아니라 수임한 역할의 그룹 멤버십만을 기준으로 true만 반환합니다.

이러한 함수를 참조하는 ABAC 정책은 사용자가 아닌 맡은 역할에 대해 평가합니다. 수임된 역할은 ABAC 정책 평가, Unity Catalog 권한 부여 확인 및 감사 귀속에 사용되는 활성 ID입니다. 결과적으로 역할이 사용자별 ID를 중심으로 빌드된 기존 정책 및 뷰의 동작을 변경한다고 가정합니다.

비고

역할은 자동으로 자기 자신의 구성원이 아닙니다. 사용자가 역할 G을 가정하면 current_user()은 G를 반환하지만, G가 자기 자신의 멤버로 명시적으로 추가된 경우가 아니면 is_member('G') 및 is_account_group_member('G')는 false를 반환합니다. 정책에서 수임한 역할을 일치 대상으로 하려면 is_member 또는 is_account_group_member로 멤버십을 확인하지 말고 current_user()와 비교하세요.

흔한 함정: current_user()를 기반으로 구축된 행 수준 보안 뷰

ABAC 및 테이블 수준 행 필터의 일반적인 패턴은 반환된 사용자 이름에 키가 지정된 current_user()(매핑 테이블 또는 액세스 제어 목록이라고도 함)에 조인하여 행을 필터링하는 것입니다. 다음은 그 예입니다.

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = current_user()
    AND p.facility_id = facility_id
);

동일한 사용자가 역할을 current_user() 가정하는 경우 더 이상 해당 사용자 이름을 반환하지 않습니다. 역할의 이름을 반환합니다. 역할이 프로비저닝 테이블에 없으므로 필터는 행을 반환하지 않으며 사용자에게 부여된 데이터에 대한 액세스 권한이 손실된 것처럼 보입니다.

프로비저닝 테이블에 역할 추가

역할을 프로비저닝 데이터의 또 다른 보안 주체로 취급합니다. 각 역할에 대해 해당 역할이 볼 수 있어야 하는 시설(또는 기타 속성)을 포함한 행을 하나씩 삽입합니다. 그런 다음 필터는 활성 ID가 사용자인지 또는 맡은 역할인지와 일치합니다.

결합 사용 패턴

다음은 고객이 RBAC와 ABAC를 함께 사용하여 실제 액세스 제어 문제를 해결하는 방법의 예입니다. 이것들은 출발점일 뿐이며, 모든 것을 망라한 완전한 지침은 아닙니다.

수임한 역할을 기준으로 한 프로젝트별 행 필터

프로젝트별 행 필터링은 한 팀이 여러 격리된 프로젝트에서 작업하는 임상 시험 연구, 계약 마케팅, 클라이언트 컨설팅 및 기타 설정에서 일반적으로 필요합니다. 다음 예제에서는 임상 시험을 사용하지만 패턴은 프로젝트별 데이터 격리로 일반화됩니다.

임상 연구 조직은 각각 자체 액세스 역할에서 여러 동시 시험을 실행합니다. 프로젝트 식별자를 사용하여 각 테이블에 태그를 지정합니다. 사용자는 현재 역할로 가정한 프로젝트의 행만 볼 수 있습니다.

설치:

  • 아래 clinical_trials.* 테이블에는 project_id제어 태그 키 project로 태그가 지정된 열이 있습니다.
  • 각 프로젝트에는 role-<project>라는 이름의 해당 액세스 역할이 있습니다(예: role-alpha, role-beta).
  • 사용자에게는 작업 중인 프로젝트에 대한 역할에 대해서만 Assume 권한이 있습니다.

행 필터 UDF:

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_user() = CONCAT('role-', project_id);

정책:

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

이 UDF는 현재 활성 ID를 각 행의 project 태그 값과 연결하므로, TO / EXCEPT와 같은 보안 주체 대상 절로는 이를 표현할 수 없습니다. 왜냐하면 그런 절은 행 콘텐츠가 아니라 보안 주체를 대상으로 하기 때문입니다. 보안 주체 대상 지정 지침에서 설명한 대로 단일 규칙이 활성 ID와 행의 콘텐츠 모두에 종속되는 경우 UDF 내의 간단한 보안 주체 범위 지정 및 예약 ID 함수를 선호 TO / EXCEPT 합니다.

단일 정책은 모든 프로젝트를 USING COLUMNS (project) 다룹니다. 각 행의 project 태그 값을 UDF에 전달하므로 프로젝트당 별도의 정책이 필요하지 않습니다. 역할 이름 일치 대신 조회 테이블에서 행 액세스를 구동하는 이 기술의 일반적인 형태는 동적 액세스 제어에 매핑 테이블 사용을 참조하세요.

행동:

  • 자신의 사용자 ID로 동작하는 사용자는 어떤 clinical_trials 테이블에서도 행이 없습니다. current_user()는 해당 사용자의 사용자 이름을 반환하며, 이는 role-* 명명 패턴과 절대 일치하지 않습니다. 이는 의도된 기본 거부입니다.
  • role-alpha를 가정한 사용자는 project_id가 alpha와 같은 행만 볼 수 있습니다. 다른 항목을 다시 쿼리하지 않고 표시되는 데이터를 교환하도록 role-beta 전환합니다.

지정된 역할로 활동하는 사용자에 대한 PII 마스킹 완화

기본적으로 PII 열(SSN, 전자 메일, 전화)은 모든 사용자에 대해 마스킹된 것으로 표시됩니다. 원시 값을 확인하려면 사용자가 PII 열람 권한이 부여된 지정된 역할로 명시적으로 전환해야 합니다. 감사 로그는 역할 가정 이벤트를 기록하므로 "실제 PII를 확인해야 했습니다."는 앰비언트 권한 대신 감사 가능한 옵트인이 됩니다.

설치:

  • 민감한 열에는 governed 태그 키 pii로 태그가 지정됩니다(허용되는 값: ssn, email, phone).
  • role-pii-cleared라는 이름의 액세스 역할에 대해 원시 PII를 볼 수 있는 권한이 있는 사용자에게 Assume 권한이 부여됩니다.

열 마스킹 UDF(정적 — 정책이 마스킹할 주체를 지정함):

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

정책:

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

EXCEPT 절은 role-pii-cleared를 정책에서 완전히 제외하므로, 해당 역할이 활성 ID일 때는 UDF가 호출되지 않습니다. 보안 주체 대상 지정에는 TO/EXCEPT 사용을 선호를 참조하여 TO / EXCEPT를 통한 보안 주체 대상 지정에 대한 일반적인 지침을 확인하세요.

행동:

  • 자신의 사용자 ID로 작업하는 사용자는 모든 PII 열에서 ***을(를) 봅니다. role-pii-cleared에 대한 Assume 권한이 있는 사용자를 포함한 모든 사용자의 기본 상태입니다.
  • 가정 role-pii-cleared한 후에는 정책이 더 이상 세션에 적용되지 않으며 동일한 사용자에게 원시 값이 표시됩니다.
  • 세션 레코드 identity_metadata.run_as = role-pii-cleared에 대한 감사 로그 항목이 기록되므로, 검토자는 PII 마스킹이 정확히 언제 해제되었는지와 누가 해제했는지 확인할 수 있습니다.

맡은 역할에 따라 달라지는 민감도 계층 정책

데이터는 민감도 계층(internal, confidential, restricted)으로 분류됩니다. 각 계층에는 해당하는 액세스 역할이 있으며, restricted은(는) confidential 및 internal에도 액세스할 수 있음을 의미합니다. 단일 행 필터 UDF는 각 행의 계층을 사용자가 가정한 역할과 비교하여 해당 행의 표시 여부를 결정합니다.

설치:

  • 테이블에는 sensitivity_levelgoverned 태그 키 sensitivity(허용되는 값: internal, confidential, restricted)로 태그가 지정된 열이 있습니다.
  • 세 가지 액세스 역할: role-sens-internal, role-sens-confidential. role-sens-restricted

행 필터 UDF:

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN current_user() = 'role-sens-restricted' THEN TRUE
  WHEN current_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN current_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

정책:

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

역할은 자체 멤버가 아니므로 이 UDF는 멤버 자격을 current_user()테스트하는 대신 각 역할 이름과 비교합니다is_account_group_member(). 멤버 자격 테스트가 맡은 역할과 일치하지 않는 이유는 위의 참고 사항을 참조하세요. UDF에서 ID 함수의 성능 특성에 대한 행 필터 및 열 마스크 정책에 대한 성능 고려 사항을 참조하세요.

행동:

  • 사용자 ID 역할을 하는 사용자는 행을 볼 수 없습니다. ELSE FALSE 분기는 세 가지 역할 중 어느 하나에도 해당하지 않는 모든 항목과 일치합니다. 위의 프로젝트별 예제에서와 같이 의도한 기본 거부입니다.
  • role-sens-internal에 internal개 행만 표시된다고 가정합니다.
  • role-sens-confidential을 가정하면 internal 및 confidential 행이 표시됩니다.
  • role-sens-restricted가 모든 행을 표시한다고 가정합니다.

사용자는 세션에 필요한 가장 높은 계층을 가정합니다. 필터는 사용자가 분류를 보유하는 테이블을 알 필요 없이 해당 계층 위의 모든 항목을 자동으로 제외합니다.

감사 출처

ABAC 정책 평가와 기본 쿼리는 모두 RBAC run_as / run_by 특성을 준수합니다. 감사 로그 항목에는 평가 중 어떤 ABAC 정책이 적용되었는지와 관계없이 인증하는 사용자로 identity_metadata.run_by이(가), 수임한 역할로 identity_metadata.run_as이(가) 기록됩니다. 전체 감사 로그 스키마에 대한 감사 로그 시스템 테이블 참조 를 참조하세요.

다음 단계

  • Last updated on