Secure UDF와 저장 프로시저로 민감한 정보 보호하기

중요한 정보에 대한 액세스 권한이 없는 사용자에게 해당 정보가 보이지 않도록 확실히 숨기기 위해 사용자 정의 함수(UDF)와 저장 프로시저를 만들 때 SECURE 키워드를 사용할 수 있습니다.

이 항목에서는 다음과 같이 할 수 있는 방법에 대해 설명합니다.

이 항목의 내용:

UDF 또는 프로시저 정의의 가시성 제한하기

UDF 또는 저장 프로시저의 경우 사용자가 정의의 구체적인 정보를 보지 못하도록 할 수 있습니다. UDF 또는 프로시저를 보안으로 지정하면 이러한 세부 정보는 권한 있는 사용자, 즉 해당 함수를 소유하는 역할이 부여된 사용자에게만 보입니다.

예를 들어 보안 함수 또는 프로시저의 경우 무단 사용자에 대해 생략된 정보에는 함수나 프로시저에 대한 다음 정보가 포함됩니다.

  • 본문(논리를 구성하는 처리기 코드)

  • 가져오기 목록

  • 처리기 이름

  • 패키지 목록

무단 사용자가 다음을 포함하는 정보를 계속 볼 수 있습니다.

  • 매개 변수 유형

  • 반환 유형

  • 처리기 언어

  • Null 처리

  • 휘발성

역할 부여에 대한 자세한 내용은 GRANT ROLE 및 액세스 제어의 개요 섹션을 참조하십시오.

보안 상태의 함수나 프로시저를 사용하면 해당 함수 또는 프로시저를 소유하는 역할이 부여되지 않은 무단 사용자가 다음 중 하나를 사용할 때 함수 또는 프로시저 정의를 볼 수 없습니다.

처리기가 Java, Python 또는 Scala로 작성된 함수와 프로시저는 Snowflake 스테이지에서 코드 또는 데이터 파일을 가져오는 IMPORTS 절을 허용합니다. SECURE 키워드를 사용해도 해당 스테이지의 가시성 또는 액세스에 어떤 영향도 미치지 않습니다.

또한 처리기가 Java, Python 또는 Scala로 작성된 함수와 프로시저의 경우 함수와 프로시저를 보안으로 만들면 서로 간에 어떤 리소스도 공유되지 않도록 별도의 샌드박스에서 실행됩니다.

SECURE 키워드 사용에 대한 자세한 내용은 보안 UDF 또는 저장 프로시저 만들기 섹션을 참조하십시오.

UDF의 중요한 데이터의 가시성 제한하기

UDF에서는 UDF를 보안으로 설정하여 숨겨야 하는 데이터를 사용자가 보지 못하게 할 수 있습니다. UDF를 만들거나 변경할 때 SECURE 키워드를 사용하면 됩니다.

데이터의 개인정보를 보호하기 위해 UDF 가 특별하게 지정된 경우(즉, 기본 테이블의 모든 사용자에게 노출되지 않아야 하는 민감한 데이터에 대한 액세스를 제한하기 위해) 이를 보안으로 정의합니다.

사용자가 기본 데이터의 표현 방식을 이해할 필요가 없는 쿼리 데이터를 단순화하기 위해 생성될 때와 같이 쿼리의 편의성을 위해 UDF를 정의할 때 이를 보안으로 설정하면 안 됩니다. 왜냐하면 보안 UDFs를 평가할 때 Snowflake 쿼리 최적화 프로그램은 일반 UDFs에 사용되는 최적화를 우회하기 때문입니다. 이는 보안 UDFs의 쿼리 성능을 저하할 수 있습니다.

UDF의 기본 데이터에 대한 가시성을 제한하려면 데이터 생성 또는 변경 시에 SECURE 키워드를 사용하십시오. 자세한 내용은 보안 UDF 또는 저장 프로시저 만들기 섹션을 참조하십시오.

데이터가 보이게 하는 방법

푸시다운 이라는 최적화를 포함하여, UDF를 위한 일부 내부 최적화에서는 기본 테이블에 포함된 기본 데이터에 액세스해야 합니다. 이러한 액세스에서는 UDF 사용자에게 숨겨진 데이터가 프로그래밍 방식을 통해 간접적으로 노출될 수 있습니다. 어떤 상황에서는 사용자가 직접 볼 수 없는 행에 대한 정보를 추론할 수도 있습니다.

보안 UDF에서는 이러한 최적화가 사용되지 않으므로 사용자가 기본 데이터에 간접적으로도 액세스할 수 없습니다. 푸시다운에 대한 자세한 내용은 푸시다운 최적화 및 데이터 가시성 섹션을 참조하십시오.

팁

보안 UDF의 사용 여부를 결정하는 경우에는 UDF의 목적을 고려하고 데이터 개인정보 보호/보안과 쿼리 성능 사이의 균형을 고려해야 합니다.

또한, 한 가지 형식의 오브젝트(예: UDFs)를 통한 액세스의 보안을 유지해야 한다고 결정할 정도로 민감한 데이터인 경우, 다른 형식의 오브젝트(예: 뷰)를 통한 액세스 역시 보안 유지를 보장할 방안을 반드시 고려해야 합니다.

예를 들어, 주어진 테이블에 액세스하기 위한 보안 UDFs만 허용하는 경우 같은 테이블에 대한 액세스를 허용하는 모든 뷰도 보안 설정해야 합니다.

Secure UDF가 데이터를 보호하는 방법

푸시다운 최적화 및 데이터 가시성 에 설명된 대로, 푸시다운 최적화로 쿼리 처리 방법을 결정하는 필터를 다시 정렬할 수 있습니다. 최적화가 데이터 보안에 사용되는 적절한 필터가 적용되기 전에 일반 필터를 실행할 수 있도록 해주는 방식으로 필터를 다시 정렬하는 경우, 기본 세부 정보가 노출될 수 있습니다. 따라서 이러한 최적화가 안전하지 않은 경우 최적화 프로그램이 특정 유형의 필터를 푸시다운하지 못하게 하는 것이 해결책입니다(더 일반적으로는, 최적화 프로그램이 필터 푸시다운 등을 포함한 특정 유형의 최적화를 사용하지 못하게 함).

UDF를 “보안”으로 선언하면 최적화 프로그램이 특정 필터를 푸시다운하지 않습니다(더 일반적으로는, 특정 최적화를 사용하지 않음). 하지만 특정 유형의 최적화를 방지하면 성능에 영향을 미칠 수 있습니다.

중요한 데이터에 대한 액세스를 보호하기 위한 모범 사례

보안 UDFs를 사용하면 함수에 의해 필터링된 테이블 행의 데이터가 사용자에게 노출되는 것을 방지할 수 있습니다. 그러나 UDFs가 신중하게 구성되지 않은 경우에는 실수로 데이터 소유자가 기본 데이터 관련 정보를 노출할 수 있습니다. 이 섹션에서는 피해야 할 몇 가지 잠재적 함정에 대해 설명합니다.

시퀀스 생성 열 값 노출 방지하기

대체 키를 생성하는 일반적인 방법은 시퀀스 또는 자동 증가 열을 사용하는 것입니다. 모든 기본 데이터에 액세스할 수 없는 사용자에게 이러한 키가 노출되면 사용자는 기본 데이터 배포의 세부 정보를 추측할 수 있습니다.

예를 들어 ID 열을 노출하는 함수 get_widgets_function() 이 있다고 가정해보십시오. 시퀀스에서 ID가 생성되면 get_widgets_function() 사용자는 사용자가 액세스할 수 있는 두 위젯의 생성 타임스탬프 사이에서 총 몇 개의 위젯이 생성되었는지를 추측할 수 있습니다. 다음 쿼리 및 결과를 생각해 보십시오.

select * from table(get_widgets_function()) order by created_on;

------+-----------------------+-------+-------+-------------------------------+
  ID  |         NAME          | COLOR | PRICE |          CREATED_ON           |
------+-----------------------+-------+-------+-------------------------------+
...
 315  | Small round widget    | Red   | 1     | 2017-01-07 15:22:14.810 -0700 |
 1455 | Small cylinder widget | Blue  | 2     | 2017-01-15 03:00:12.106 -0700 |
...
Copy

결과에 따라, 사용자는 1월 7일에서 1월 15일 사이에 1139개의 위젯(1455 - 315)이 생성된 것으로 추측할 수 있습니다. 이러한 정보가 매우 민감하여 함수 사용자에게 노출되지 않아야 하는 경우에는 다음 대안 중 하나를 사용할 수 있습니다.

  • 시퀀스에 따라 생성된 열을 함수의 일부로 노출하지 않습니다.

  • 무작위 식별자(예: UUID_STRING 에 의해 생성된 식별자)를 시퀀스에 따라 생성된 값 대신 사용합니다.

  • 프로그래밍 방식으로 식별자를 난독화합니다.

스캔된 데이터 크기에 대한 가시성 제한하기

보안 함수가 포함된 쿼리의 경우 Snowflake는 스캔된 데이터의 양(바이트 또는 마이크로 파티션 단위) 또는 전체 데이터 양을 노출하지 않습니다. 이는 데이터의 하위 세트에만 액세스할 수 있는 사용자로부터 정보를 보호하기 위한 것입니다.

그러나 사용자는 쿼리의 성능 특성에 따라 여전히 기본 데이터의 양을 관찰할 수 있습니다. 예를 들어, 실행 시간이 2배인 쿼리는 2배의 데이터를 처리할 수 있습니다. 이러한 관찰은 근사치이지만, 일부 경우에는 이러한 수준의 정보가 노출되는 것도 바람직하지 않을 수 있습니다.

그러한 경우에는 기본 데이터에 대한 함수를 사용자에게 노출하는 대신, 사용자/역할별로 데이터를 구체화해야 합니다. 이 항목에서 설명하는 widgets 테이블의 경우, 위젯에 대한 액세스 권한이 있는 각 역할에 대해 테이블이 생성됩니다. 이러한 각 테이블에는 해당 역할이 액세스할 수 있는 위젯만 포함되며, 역할에는 해당 테이블에 대한 액세스 권한이 부여됩니다. 이렇게 하는 것은 단일 함수를 사용하는 것보다 훨씬 번거롭지만 매우 높은 수준의 보안이 요구되는 경우에 적합합니다.

특정 계정의 사용자에 대한 기본 테이블 액세스 권한 부여하기

데이터 공유 와 함께 보안 UDFs를 사용하는 경우에는 CURRENT_ACCOUNT 함수를 사용하여 특정 계정의 사용자에게 기본 테이블의 행에 대한 액세스 권한을 부여할 수 있습니다.

참고

Snowflake 계정과 공유되는 보안 UDFs와 함께 CURRENT_ROLE 및 CURRENT_USER 기능을 사용할 때 Snowflake는 이러한 기능에 대해 NULL 값을 반환합니다. 왜냐하면 공유되는 데이터의 소유자가 일반적으로 UDF가 공유되는 계정의 사용자 또는 역할을 관리하지 않기 때문입니다.

보안 UDFs 및 마스킹 정책

UDF를 사용하는 경우, UDF가 보안 UDF인지 여부와 관계없이 마스킹 정책 에서 열의 데이터 타입, UDF, 마스킹 정책이 일치하는지 확인합니다.

자세한 내용은 마스킹 정책의 사용자 정의 함수 섹션을 참조하십시오.

보안 UDF 또는 저장 프로시저 만들기

UDF 또는 프로시저를 만들거나 변경할 때 SECURE 키워드를 사용하여 UDF나 프로시저를 보안 상태로 설정할 수 있습니다.

보안 상태의 UDF를 만들거나 변환하려면 다음을 사용할 때 SECURE를 지정하십시오.

보안 상태의 프로시저를 만들려면 다음을 사용할 때 SECURE를 지정하십시오.

UDF 또는 프로시저가 보안 상태인지 확인하기

SHOW FUNCTIONS 또는 SHOW PROCEDURES 명령을 사용하여 함수 또는 프로시저가 보안 상태인지 확인할 수 있습니다. 이 명령은 값이 보안인 경우 Y 이고 보안이 아닌 경우 N 인 IS_SECURE 열이 있는 테이블을 반환합니다.

다음 예제의 코드는 MYFUNCTION 함수의 속성 테이블을 반환합니다.

show functions like 'MYFUNCTION';
Copy

쿼리 프로필에서 보안 함수 세부 정보 보기

보안 함수의 내부는 웹 인터페이스의 쿼리 프로필 에 노출되지 않습니다. 소유자가 아닌 사용자가 소유자의 쿼리 프로필에 액세스할 수 있으므로 이러한 규칙은 보안 함수의 소유자에게도 적용됩니다.

언어: 한국어