Snowflake와 Okta SCIM 통합

이 가이드는 Snowflake용 Okta에 프로비저닝을 구성하기 위해 필요한 단계를 제공하며 포함되는 섹션은 다음과 같습니다.

기능

Snowflake 애플리케이션에 대해 User 및 Role Administration이 지원됩니다.

이를 통해 Okta는 다음을 수행할 수 있습니다.

  • Snowflake에서 사용자 수명 주기(즉, 생성, 업데이트 및 삭제)를 관리합니다.

  • Snowflake에서 역할 수명 주기(즉, 생성, 업데이트 및 삭제)를 관리합니다.

  • Snowflake에서 사용자에 대한 역할 할당을 관리합니다.

지원되는 프로비저닝 기능은 다음과 같습니다.

Push New Users

OKTA를 통해 생성된 새 사용자는 Snowflake에서도 생성됩니다.

Push Profile Updates

OKTA를 통한 사용자 프로필 업데이트는 Snowflake로 푸시됩니다.

Push User Deactivation

사용자를 비활성화하거나 OKTA를 통한 사용자의 Snowflake 액세스를 비활성화하면 Snowflake에서 사용자가 비활성화됩니다.

참고

Snowflake에서 사용자 비활성화는 사용자의 DISABLED 속성을 TRUE 로 설정하는 것을 의미합니다.

Reactivate Users

Snowflake에서 사용자 계정을 다시 활성화할 수 있습니다.

Sync Password

필요한 경우, 사용자 비밀번호를 Okta에서 Snowflake로 푸시할 수 있습니다.

기본 설정은 사용자에게 has_Password=true 의 속성 설정을 제공하는 사용자에 대해 임의 비밀번호를 생성하는 것입니다. 비밀번호가 없는 경우 사용자는 반드시 Okta SSO를 통해 Snowflake에 액세스해야 합니다. 사용자의 비밀번호가 생성되지 않도록 하려면, 다음과 같이 사용자를 프로비저닝하기 전 이 설정을 꺼야 합니다.

  1. Edit 를 클릭합니다.

  2. Sync Password 아래에서 Generate a new random password whenever the user’s Okta password changes 설정을 선택 취소합니다.

  3. 변경 사항을 저장합니다.

Okta에서 이 설정을 활성화하면 사용자가 Snowflake에 액세스할 수 있는 비밀번호가 생성됩니다. 이를 통해 사용자가 SSO를 사용하지 않고 Snowflake에 액세스할 수 있는 경로가 생성될 수 있습니다.

비밀번호 동기화를 비활성화 하려면 Okta에서 이 옵션을 설정 해제하는 것과 함께 Snowflake Okta SCIM 보안 통합 을 업데이트하여 SYNC_PASSWORD 속성을 False 로 설정하십시오.

Push Groups

Push Groups 기능은 Snowflake에서 편리하게 역할을 생성하고 관리할 수 있도록 해줍니다. Okta Push Groups을 사용하여 Snowflake에서 생성된 역할은 Okta와 Snowflake에서 동일한 이름을 갖습니다. 항상 Okta에서 먼저 역할을 생성하고 Push Groups을 사용하여 Snowflake를 업데이트해 Okta와 Snowflake를 동기화시킵니다. Snowflake의 Okta 및 OKTA_PROVISIONER 사용자 지정 역할의 경우 Snowflake에서 수동으로 생성된 역할을 관리할 수 없습니다. Push Groups은 Snowflake에서 사용자를 생성하지 않습니다.

Okta의 Snowflake 애플리케이션이 Okta 사용자에게 할당된 경우 Okta는 Snowflake에서 사용자를 생성할 수 있습니다.

자세한 내용은 사용자에게 애플리케이션 할당 을 참조하십시오.

지원되는 사용자 속성은 다음과 같습니다.

특성 유형

SCIM 사용자 속성

Snowflake 사용자 속성

참고

기본 속성

userName

이름 및 로그인_이름

givenName

이름

familyName

이메일

이메일

사용자 지정 속성

defaultRole

기본_역할

defaultWarehouse

기본_웨어하우스

defaultSecondaryRoles

기본_보조_역할

이 값은 "ALL" 로만 지정할 수 있습니다.

알려진 문제

  • Okta는 밑줄을 포함한 URL을 지원하지 않습니다. Snowflake 계정 이름에 밑줄이 포함된 경우 밑줄을 하이픈으로 바꾸는 특수 계정 URL을 사용해야 합니다. 예를 들어, 계정 이름 URL 형식을 사용하는 경우 특수 URL은 https://myorg-account-name.snowflakecomputing.com 일 수 있습니다.

  • 기존 Snowflake 역할은 소유권 이전을 통해 Okta에서 관리하도록 가져올 수 없습니다. Okta를 통해서는 새 역할을 생성하는 것만 가능합니다.

  • 기존 Snowflake 사용자는 소유권 이전을 통해 Okta에서 관리하도록 가져올 수 있습니다. 자세한 내용은 이 항목의 문제 해결 을 참조하십시오.

제한 사항

  • Snowflake는 SCIM 엔드포인트(예: /Users 엔드포인트, /Groups 엔드포인트)마다 동시 요청을 계정당 최대 500개까지 지원합니다. 계정이 이 임계값을 초과한 후에 Snowflake는 429 HTTP 상태 코드(즉, 요청이 너무 많음)를 반환합니다. 이러한 요청 제한은 일반적으로 사용자 또는 그룹을 프로비저닝하기 위해 상대적으로 많은 수의 요청(즉, 10,000개 이상)이 발생할 때 초기 프로비저닝 중에만 발생한다는 점에 유의하십시오.

지원되지 않음

  • Okta의 Enhanced Group Push 및 Push Now 기능.

    참고

    defaultRole, defaultSecondaryRolesdefaultWarehouse 속성은 선택 사항이므로 매핑이 취소됩니다. Okta에서 이러한 속성을 매핑하려면 프로필 또는 식을 사용하거나 모든 사용자에 대해 기본값을 설정해야 합니다. 자세한 내용은 Okta에서 프로필 관리 를 참조하십시오.

  • Snowflake 서비스에 비공개 연결을 사용하여 Snowflake에 액세스하는 경우 통합 설정에서 이러한 URL을 입력하지 않았는지 확인하십시오. 공용 엔드포인트(즉, .privatelink 제외)를 입력하고 네트워크 정책에서 여기에 나열된 Okta IP 주소로부터의 액세스를 허용하는지 확인하십시오. 그렇지 않은 경우에는 이 통합을 사용할 수 없습니다.

  • Okta는 현재 Active Directory 중첩 그룹 가져오기를 지원하지 않습니다. 그러므로 Okta 통합이 AD에서 중첩 그룹을 사용하는 경우, Snowflake Okta SCIM 통합을 사용하여 Snowflake의 중첩 그룹을 프로비저닝하거나 관리할 수 없습니다. 중첩 그룹의 지원을 요청하려면 Okta 및 Microsoft로 문의하십시오.

전제 조건

  1. 사용자 또는 그룹을 프로비저닝하기 전, Snowflake의 네트워크 정책 에서 여기에 설명되는 Okta IP 주소로부터의 액세스를 허용하는지 확인하십시오. 자세한 내용은 SCIM 네트워크 정책 관리하기 를 참조하십시오.

  2. Snowflake에 대한 프로비저닝을 구성하기 전, Okta에서 Snowflake 애플리케이션에서 General Settings 및 모든 Sign-On Options 을 구성했는지 확인하십시오.

위의 단계가 완료되면 Okta에서 Next 을 클릭하여 Provisioning 탭으로 돌아갑니다.

구성 단계

구성 프로세스에서는 Snowflake 및 Okta에서 단계를 완료해야 합니다.

Snowflake 구성

Snowflake 구성 프로세스는 SCIM 보안 통합을 생성하여 Snowflake의 OKTA_PROVISIONER SCIM 역할이 Okta에 생성된 사용자 및 역할을 소유하고 SCIM API 요청에서 사용할 액세스 토큰을 생성하는 것을 허용합니다. 액세스 토큰의 유효 기간은 6개월입니다. 만료되면, 아래와 같이 SYSTEM$GENERATE_SCIM_ACCESS_TOKEN 을 사용하여 수동으로 새 액세스 토큰을 생성합니다.

참고

SCIM 통합에 대한 기존 액세스 토큰을 무효화하려면 DROP INTEGRATION 문을 실행합니다.

Snowflake와 함께 SCIM을 계속 사용하려면, CREATE SECURITY INTEGRATION 문을 사용하여 SCIM 통합을 다시 생성하고 SYSTEM$GENERATE_SCIM_ACCESS_TOKEN 을 사용하여 새 액세스 토큰을 생성합니다.

원하는 Snowflake 클라이언트에서 다음 SQL 문을 실행합니다. SQL 문에 대한 설명은 아래에서 제공됩니다.

use role accountadmin;
create role if not exists okta_provisioner;
grant create user on account to role okta_provisioner;
grant create role on account to role okta_provisioner;
grant role okta_provisioner to role accountadmin;
create or replace security integration okta_provisioning
    type = scim
    scim_client = 'okta'
    run_as_role = 'OKTA_PROVISIONER';
select system$generate_scim_access_token('OKTA_PROVISIONING');
Copy

중요

예시 SQL 문에서는 ACCOUNTADMIN 시스템 역할을 사용하고 ACCOUNTADMIN 역할에 OKTA_PROVISIONER 사용자 지정 역할이 부여됩니다.

권한이 낮은 역할이 아닌, ACCOUNTADMIN 역할을 사용하지 않는 것도 가능합니다. 권한이 낮은 역할을 사용하면 권한이 가장 낮은 액세스와 관련된 규정 준수 문제를 해결하는 데 도움이 되지만, 권한이 낮은 역할을 사용하면 SCIM 구성 및 관리 프로세스 중에 예기치 않은 오류가 발생할 수 있습니다.

이러한 오류가 발생하는 이유는 역할이 생성되는 방식과 결과적인 역할 계층으로 인해 권한이 낮은 역할이 SCIM을 통해 모든 역할을 관리할 수 있는 충분한 권한이 없기 때문입니다. 그러므로 구성 및 관리 프로세스 중에 오류를 방지하기 위해 다음 옵션 중 1개를 선택합니다.

  1. 예시 SQL 문에서와 같이 ACCOUNTADMIN 역할을 사용합니다.

  2. 전역 MANAGE GRANTS 권한이 있는 역할을 사용합니다.

  3. 이러한 첫 번째 두 옵션이 적합하지 않은 경우, SCIM을 사용하여 관리할 모든 역할에 대한 OWNERSHIP 권한이 있는 사용자 지정 역할을 사용합니다.

  1. ACCOUNTADMIN 역할을 사용합니다.

    use role accountadmin;
    
    Copy
  2. OKTA_PROVISIONER 사용자 지정 역할을 만듭니다. Okta가 생성한 Snowflake의 모든 사용자 및 역할은 범위가 축소된 OKTA_PROVISIONER 역할이 소유합니다.

    create role if not exists okta_provisioner;
    grant create user on account to role okta_provisioner;
    grant create role on account to role okta_provisioner;
    
    Copy
  3. ACCOUNTADMIN 역할이 OKTA_PROVISIONER 사용자 지정 역할을 사용하여 보안 통합을 생성하도록 합니다. 자세한 내용은 CREATE SECURITY INTEGRATION 을 참조하십시오.

    grant role okta_provisioner to role accountadmin;
    create or replace security integration okta_provisioning
        type = scim
        scim_client = 'okta'
        run_as_role = 'OKTA_PROVISIONER';
    
    Copy
  4. 인증 토큰을 생성한 후 클립보드에 복사하고 나중에 사용할 수 있도록 안전하게 저장합니다. 각 SCIM REST API 요청에서 이 토큰을 사용하고 요청 헤더에 추가합니다. 액세스 토큰은 6개월 후에 만료되며 이 문을 사용하여 새 액세스 토큰을 생성할 수 있습니다.

    select system$generate_scim_access_token('OKTA_PROVISIONING');
    
    Copy

    중요

    Okta가 생성한 Snowflake의 모든 사용자 및 역할은 범위가 축소된 okta_provisioner 역할이 소유합니다.

    Okta를 통해 기존 Snowflake 사용자를 관리하려면 다음 단계를 완료하십시오.

    1. 기존 사용자의 소유권을 okta_구축 프로그램 역할로 이전합니다.

      use role accountadmin;
      grant ownership on user <user_name> to role okta_provisioner;
      
      Copy
    2. 기존 Snowflake 사용자가 Okta SSO를 사용하는 경우, 이미 설정되어 있어야 하는 기존 사용자에게 login_name 속성이 설정되어 있는지 확인합니다.

    3. Okta의 사용자 이름과 일치하도록 Okta가 관리하는 기존 사용자의 이름이 업데이트됨에 유의하십시오. 사용자가 다른 통합(즉, Tableau)에서 Snowflake에 연결하기 위해 이름을 사용할 수 있으므로 이 변경 사항을 사용자에게 알립니다.

Okta 구성

이 섹션에서는 Okta에서 Snowflake 애플리케이션을 만들고 구성하는 방법을 설명합니다.

참고

Okta에서 Snowflake 애플리케이션을 만들 때 애플리케이션의 SubDomain 필드는 Snowflake 계정의 계정 식별자 를 포함해야 합니다. Snowflake 계정 이름에 밑줄이 포함되어 있고 식별자의 계정 이름 형식을 사용 중인 경우, Okta는 URL에서 밑줄을 지원하지 않으므로 밑줄을 하이픈으로 변환해야 합니다(예: myorg-account-name).

비공개 연결이 지원되지 않고 privatelink 세그먼트를 입력하면 SCIM 연결이 실패하므로 SubDomain 필드에 이 세그먼트를 포함하지 마십시오.

Okta에서 Snowflake 애플리케이션을 구성하려면 다음 절차를 완료하십시오.

  1. Settings 의 왼쪽 메뉴에서 Integration 을 선택하고 Enable API Integration 상자를 선택합니다.

  2. 위에서 클립보드에서 생성된 값을 API Token 에 입력합니다. Test API Credentials 버튼을 클릭하고 성공하면 구성을 저장합니다.

  3. 왼쪽 메뉴에서 To App 을 선택합니다.

  4. 활성화할 Provisioning Features 을 선택합니다.

  5. 속성 매핑을 확인합니다. defaultRole, defaultSecondaryRolesdefaultWarehouse 속성은 선택 사항이므로 매핑이 취소됩니다. 필요한 경우, Okta 프로필 또는 식을 사용하여 매핑하거나 모든 사용자에 대해 동일한 값을 설정할 수 있습니다.

이제 사용자는 Snowflake 애플리케이션에 사용자를 할당하고(필요한 경우) 애플리케이션 설정을 완료할 수 있습니다.

참고

Okta는 Snowflake 사용자의 name 필드에 매핑되는 snowflakeUserName 속성을 지원합니다.

Snowflake 사용자의 namelogin_name 필드 값을 다르게 설정하려면 다음 절차를 수행합니다.

  1. 계정에 대해 별도의 매핑을 활성화하려면 Snowflake 지원에 문의하십시오.

  2. Okta에서 Snowflake 애플리케이션에 액세스하고 Provisioning > Attribute Mappings > Edit Mappings 으로 이동합니다.

  3. snowflakeUserName 속성을 찾습니다.

  4. 속성을 찾을 수 없는 경우에는 Snowflake 애플리케이션이 생성된 이후에 이 속성이 사용할 수 있도록 설정된 것입니다. 아래와 같은 매핑을 사용하여 Snowflake 애플리케이션을 다시 생성하거나 속성을 다음과 같이 수동으로 추가합니다.

    • Add Attribute 를 클릭합니다.

    • 테이블에 나열된 각 필드에 값을 다음과 같이 설정합니다.

    필드

    데이터 타입

    문자열

    표시 이름

    Snowflake 사용자 이름

    변수 이름

    snowflakeUserName

    외부 이름

    snowflakeUserName

    외부 네임스페이스

    urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

    설명

    Snowflake에서 사용자의 name 필드에 매핑됩니다.

    범위

    사용자 개인

  5. Save 를 클릭합니다.

Snowflake에서 시작된 SSO를 사용하도록 설정하기

SCIM 프로비저닝 프로세스에서는 Single Sign-On(SSO)이 자동으로 활성화되지 않습니다.

SCIM 프로비저닝 프로세스가 완료된 후 SSO를 사용하려면, Snowflake에서 시작된 SSO 를 활성화합니다.

SCIM 네트워크 정책 관리하기

SCIM 보안 통합에 네트워크 정책을 적용하면 SCIM 네트워크 정책이 전체 Snowflake 계정에 적용되는 네트워크 정책과 구별될 수 있습니다. 이를 통해 SCIM 공급자는 일반 사용자의 액세스를 제어하는 네트워크 정책에 IP 주소를 추가하지 않고도 사용자와 그룹을 프로비저닝할 수 있습니다.

SCIM 통합에 적용된 네트워크 정책은 전체 Snowflake 계정에 적용된 네트워크 정책보다 우선하지만, 사용자에게 할당된 네트워크 정책보다는 우선 순위에서 밀립니다.

SCIM 보안 통합을 생성한 후 다음 명령을 사용하여 SCIM 네트워크 정책을 생성합니다.

alter security integration okta_provisioning set network_policy = <scim_network_policy>;
Copy

SCIM 네트워크 정책의 설정을 해제하려면 다음 명령을 사용합니다.

alter security integration okta_provisioning unset network_policy;
Copy

여기서

okta_provisioning

Okta SCIM 보안 통합의 이름을 지정합니다.

scim_network_policy

Snowflake에서 Okta SCIM 네트워크 정책을 지정합니다.

자세한 내용은 네트워크 정책ALTER SECURITY INTEGRATION 을 참조하십시오.

SCIM이 포함된 보조 역할 사용하기

Snowflake는 SCIM으로 사용자 속성 DEFAULT_SECONDARY_ROLES'ALL' 로 설정하여 사용자가 Snowflake 세션에서 보조 역할 을 사용할 수 있도록 지원합니다.

대표적인 예는 PUT scim/v2/Users/{id} 섹션을 참조하십시오.

Okta SCIM 보안 통합 복제하기

Snowflake는 원본 계정에서 대상 계정으로의 SCIM 보안 통합의 복제 및 장애 조치/장애 복구를 지원합니다.

자세한 내용은 여러 계정에 보안 통합 및 네트워크 정책 복제 섹션을 참조하십시오.

문제 해결

  • 소유권 이전. 사용자 업데이트가 실패하면 Snowflake에서 사용자의 소유권을 확인하십시오. okta_provisioner 역할(또는 Snowflake에서 보안 통합을 생성할 때 run_as_role 매개 변수에 설정된 역할)이 소유하지 않은 경우 업데이트가 실패하게 됩니다. Snowflake에서 다음 SQL 문을 실행하여 소유권을 이전한 후 다시 시도하십시오.

    grant ownership on user <username> to role OKTA_PROVISIONER;
    
    Copy
  • 기존 Snowflake 사용자가 Okta SSO를 사용하는 경우, 이미 설정되어 있어야 하는 기존 사용자에게 login_name 속성이 설정되어 있는지 확인합니다.

  • Okta가 Snowflake로 업데이트를 전송 중인지를 확인하려면 Snowflake 애플리케이션에 대한 Okta의 로그 이벤트 및 Snowflake의 SCIM 감사 로그를 확인하여 Snowflake에서 Okta의 업데이트를 수신 중인지 확인하십시오. 다음을 사용하여 Snowflake SCIM 감사 로그를 쿼리하십시오.

    use role accountadmin;
    use database demo_db;
    use schema information_schema;
    select * from table(rest_event_history('scim'));
    select *
        from table(rest_event_history(
            'scim',
            dateadd('minutes',-5,current_timestamp()),
            current_timestamp(),
            200))
        order by event_timestamp;
    
    Copy
  • 프로비저닝 절차 중에 인증 오류가 발생할 수 있습니다. 가능한 오류 메시지는 다음과 같습니다.

    Error authenticating: Forbidden. Errors reported by remote server: Invalid JSON: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@4c76ba04; line: 1, column: 2]
    
    Copy

    이 오류 메시지 또는 기타 인증 오류 메시지가 발생하면, 다음 문제 해결 절차를 시도하십시오.

    1. Okta에서 현재 Snowflake 애플리케이션을 제거하고 새 Snowflake 애플리케이션을 생성합니다.

    2. Snowflake에서 새 SCIM 보안 통합을 생성하고 새 액세스 토큰을 생성합니다.

    3. Copy 를 클릭하여 새 토큰을 복사합니다.

    4. Okta에서 Okta를 SCIM ID 공급자로 구성하는 방법에서의 설명과 같이 새 액세스 토큰을 붙여넣은 후 확인합니다.

    5. Okta에서의 새로운 Snowflake 애플리케이션을 사용하여 Okta에서 Snowflake로 사용자와 역할을 프로비저닝합니다.

다음 항목: