Snowflake 인증 개요

다음 섹션에서는 사용자와 애플리케이션이 Snowflake에 액세스하는 데 사용할 수 있는 인증 방법을 설명합니다. 또한 사용 사례에 가장 적합한 인증 방법을 선택하는 데 도움이 되는 주요 고려 사항도 제공합니다.

Snowsight 에 대한 인증 선택하기

Snowsight 는 Snowflake의 사용자 인터페이스입니다. 이 섹션에서는 사용자가 Snowsight 에 로그인하는 데 사용할 수 있는 인증 방법에 대한 개요를 제공한 후 메서드를 비교합니다.

참고

Snowsight 에 인증하는 사용자에 대한 Snowflake 사용자 오브젝트를 생성하는 경우 ``TYPE = PERSON``을 지정합니다. 사용자 유형에 대한 자세한 내용은 사용자 유형 섹션을 참조하세요.

Single sign-on(SSO)

Snowsight 용 SSO를 통해 사용자는 Snowflake로 직접 인증하는 대신 서드 파티 ID 공급자(IdP)를 사용하여 인증합니다. 사용자가 Snowsight 에 액세스할 때, 로그인 페이지에는 Snowflake 관리 비밀번호 대신 IdP로 인증하는 옵션이 포함되어 있습니다. IdP는 사용자의 ID를 확인한 후 Security Assertion Markup Language(SAML) 어설션을 Snowflake에 전송합니다. Snowflake및 IdP에 이전에 설정된 신뢰 관계가 있는 경우 Snowflake는 어설션을 사용자 ID의 증거로 허용하고 사용자가 Snowsight 에 액세스할 수 있도록 허용합니다.

일부 조직에서는 동일한 IdP를 사용하여 조직의 모든 애플리케이션에 대한 SSO 환경을 제공합니다. 이러한 조직에서는 직원이 IdP를 사용하여 Snowsight 에 액세스할 수 있도록 Snowflake를 새 서비스 공급자(SP)로 간단하게 추가할 수 있습니다.

다단계 인증(MFA)이 있는 사용자 이름 및 비밀번호

비밀번호 인증을 통해 사용자는 비밀번호 정책에 의해 적용되는 요구 사항을 준수하는 문자열을 입력하여 Snowsight 에 액세스할 수 있습니다. 이 인증 방법의 보안을 강화하기 위해 Snowflake는 모든 비밀번호 사용자에 대한 MFA가 필요합니다. MFA를 통해 사용자는 비밀번호를 입력한 다음 두 번째 인증 요소를 사용하여 ID를 확인합니다. 예를 들어, 사용자는 컴퓨터에 저장된 암호 키를 두 번째 인증 요소로 사용할 수 있습니다.

다음 테이블에서는 사용자가 Snowsight 에 로그인하는 데 사용할 수 있는 인증 방법을 비교합니다.

메서드

장점

문제점

Single Sign-On . 기본 설정 옵션

조직이 인증을 중앙에서 관리할 수 있습니다. 사용자가 Snowflake뿐만 아니라 조직의 모든 애플리케이션에 동일한 IdP로 인증합니다.

이미 IdP를 사용하여 애플리케이션에 SSO를 제공하는 조직에 적합합니다.

서드 파티 IdP를 구성해야 합니다.

MFA가 포함된 비밀번호

간단한 구현.

Snowflake에서 비밀번호를 관리하는 경우 조직은 모든 애플리케이션에 대해 인증 설정을 반복해야 합니다.

애플리케이션의 인증 방법 개요

이 항목에서 *애플리케이션*은 Snowsight 사용자 인터페이스를 통하지 않고 프로그래밍 방식으로 Snowflake 데이터에 액세스하는 모든 앱을 나타냅니다. 이 정의에는 사용자 지정 웹 애플리케이션, 서드 파티 다중 테넌트 애플리케이션, 데스크톱 애플리케이션, 로컬 스크립트, 클라우드의 워크로드가 포함됩니다.

사용 가능한 인증 방법에 대해 설명할 때 이 항목에서는 두 가지 유형의 애플리케이션을 구분합니다.

  • 사용자와 상호 작용하고 해당 사용자를 대신하여 Snowflake에 인증하는 *대화형 애플리케이션*(예: 분석가와 상호 작용하는 비즈니스 인텔리전스(BI)).

  • 사용자와 상호 작용하지 않고 서비스에 대한 전용 인증 방법이 있는 *서비스 간 애플리케이션*(예: CI/CD 파이프라인).

워크로드 ID 페더레이션(WIF)

워크로드 ID 페더레이션은 시크릿이 없는 인증의 한 형태이며, 클라우드 워크로드에 이미 사용 가능한 단기 자격 증명을 활용하므로 매우 안전합니다. 시크릿을 관리하고 순환할 필요가 없습니다.

워크로드가 AWS EC2, Microsoft Azure VMs 또는 Google Cloud VMs와 같은 클라우드 공급자에서 실행 중인 경우, 워크로드 ID 페더레이션을 사용하면 클라우드 공급자의 기본 ID 메커니즘을 사용하여 워크로드가 Snowflake에 인증할 수 있습니다. 예를 들어, AWS EC2에서 실행 중인 워크로드는 워크로드와 연결된 AWS ID 및 액세스 관리(IAM) 역할에서 증명(즉, ID의 증거)을 얻을 수 있습니다. 워크로드의 드라이버는 기본 ID 메커니즘에서 증명을 얻은 다음 Snowflake로 전송하여 워크로드를 인증합니다.

워크로드 ID 페더레이션을 사용하면 Kubernetes에서 실행 중인 작업 및 워크로드 GitHub 작업과 같은 서드 파티 워크로드가 *OIDC 페더레이션*이라는 프로세스에서 OpenID Connect 호환 ID 공급자(IdP)로 인증할 수 있습니다. Snowflake는 IdP에 의해 생성된 ID 토큰을 워크로드 ID의 증거로 허용합니다.

다음에 적합:

  • 서비스 간 애플리케이션

Snowflake를 인증 서버로 사용하는 OAuth(Snowflake OAuth)

Snowflake OAuth는 `OAuth2.0 인증 프레임워크<https://datatracker.ietf.org/doc/html/rfc6749>`_ 보안을 제공합니다. Snowflake OAuth를 통해 Snowflake는 Snowflake 사용자를 인증하는 인증 서버이자 해당 사용자의 데이터에 액세스하기 위해 클라이언트의 액세스 토큰을 허용하는 리소스 서버 역할을 수행합니다. Snowflake OAuth를 통해 클라이언트는 인증 코드 권한 부여 유형을 사용할 수 있습니다.

Snowflake는 인증 서버이므로 애플리케이션과 상호 작용하는 사용자는 Snowflake 사용자 인터페이스를 사용하여 인증합니다. Single Sign-On(SSO) 또는 비밀번호로 사용자를 인증하도록 Snowflake를 구성할 수 있습니다. SSO 및 비밀번호 인증의 장점과 문제에 대한 정보는 Snowsight 에 대한 인증 선택하기 섹션을 참조하세요.

다음에 적합:

  • 대화형 애플리케이션

서드 파티 인증 서버를 사용하는 OAuth(외부 OAuth)

외부 OAuth는 OAuth 2.0 보안을 제공하지만 Snowflake가 아닌 서드 파티 IdP는 인증 서버 역할을 수행합니다. 애플리케이션은 서드 파티 IdP로부터 액세스 토큰을 얻은 후 토큰을 사용하여 Snowflake에 리소스로 액세스합니다.

서비스 간 애플리케이션은 클라이언트 자격 증명 부여 유형을 사용하여 자체 Snowflake 데이터에 액세스할 수 있습니다. 대화형 애플리케이션은 인증 코드 권한 부여 유형을 사용하여 애플리케이션을 사용하는 사용자의 Snowflake 데이터에 액세스할 수 있습니다.

다음에 적합:

  • 대화형 애플리케이션

  • 서비스 간 애플리케이션

키 페어 인증

키 페어 인증은 개인 키와 공용 키인 *암호화 키 페어*를 사용합니다. 개인 키는 애플리케이션에서 보관하는 시크릿이며, 공용 키는 Snowflake 사용자 오브젝트와 연결됩니다. 인증하는 동안 애플리케이션은 개인 키가 있다는 증거를 보내고, Snowflake는 개인 키가 Snowflake 사용자와 연결된 공용 키와 일치하는지 확인하여 응답합니다. 이 인증 방법을 사용하면 비밀번호를 전송하거나 저장할 필요가 없으므로 자격 증명 도용의 위험이 줄어듭니다.

다음에 적합:

  • 서비스 간 애플리케이션

표준 사용 사례는 아니지만 키 페어 인증은 대화형 애플리케이션에도 사용할 수 있습니다.

프로그래밍 방식 액세스 토큰(PATs)

PAT는 애플리케이션이 비밀번호 없이 인증할 수 있는 한시적인 자격 증명입니다. PAT는 MFA 또는 더 안전한 인증 방법이 작동하지 않는 경우 단일 요소 비밀번호의 드롭인 대체 수단으로 사용할 수 있습니다. PAT는 단기 자격 증명이기 때문에 비밀번호보다 강력하고, 추가 보안 조치를 구현해야 하며, 특정 액세스 제어 역할로 범위를 지정할 수 있습니다.

다음에 적합:

  • 대화형 애플리케이션

  • 서비스 간 애플리케이션

대화형 애플리케이션에 대한 인증 선택하기

대화형 애플리케이션은 사용자와 상호 작용하고 해당 사용자를 대신하여 Snowflake에 인증하는 애플리케이션입니다. 다음 테이블은 대화형 애플리케이션에 사용할 수 있는 인증 방법과 관련된 이점과 문제를 제공합니다. 이러한 인증 방법에 대한 개요는 애플리케이션의 인증 방법 개요 섹션을 참조하세요.

참고

대화형 앱을 사용하는 사용자를 위한 Snowflake 사용자 오브젝트를 생성하는 경우 ``TYPE = PERSON``을 적용합니다. 사용자 유형에 대한 자세한 내용은 사용자 유형 섹션을 참조하세요.

메서드

장점

문제점

Snowflake OAuth . 강력한 옵션

  • 외부 OAuth보다 더 간단하게 구현할 수 있습니다.

  • VS 코드에서 실행되는 스크립트와 같은 로컬 애플리케이션은 관리자 설정 없이 OAuth의 보안을 제공하는 Snowflake OAuth의 기본 제공 구현을 사용할 수 있습니다. 자세히 알아보기

  • 드라이버 제한을 방지합니다.

  • 사용자는 Single Sign-On(SSO)을 통해 서드 파티 IdP의 보안 인증 방법을 사용할 수 있습니다.

없습니다.

외부 OAuth . 강력한 옵션

  • IdP가 지원하는 경우 애플리케이션을 사용하는 사용자는 시크릿 형식의 인증을 사용할 수 있습니다.

  • 애플리케이션을 위한 인증 서버로 서드 파티 IdP를 이미 사용하는 조직에 적합합니다.

서드 파티 IdP를 인증 서버로 구성하기 위해서는 전문 지식이 필요합니다.

프로그래밍 방식 액세스 토큰(PAT)

  • 단일 요소 비밀번호를 쉽게 대체합니다.

  • Snowflake에서 생성된 자격 증명이므로 Snowflake 외부에서 재사용할 수 없습니다.

  • 특정 액세스 제어 역할로 범위를 지정하여 도용되는 경우의 피해를 제한할 수 있습니다.

  • Snowflake에서는 수명이 긴 시크릿을 사용할 때의 위험을 완화하기 위해 추가적인 보안 조치를 구현해야 합니다.

  • `GitHub 시크릿 스캐너 프로그램<https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partnership-program/secret-scanning-partner-program>`_은 공용 리포지토리에서 유출된 Snowflake PATs를 자동으로 감지하고 비활성화하며 Snowflake 관리자에게 알립니다.

  • 키-페어와 달리 클라이언트와 서버 모두에서 보안되어야 합니다.

  • 키-페어와 달리, 시크릿은 요청에서 Snowflake로 전송되어야 하므로 노출이 증가합니다.

  • 도용된 경우 소유권이 있는 사용자가 애플리케이션을 가장할 수 있습니다.

  • 장기 자격 증명과 관련된 보안 위험은 강력한 저장 및 순환 전략과 같은 다른 보안 조치를 통해 완화해야 합니다.

  • 네트워크 정책이 필요하므로 다중 테넌트 클라우드 애플리케이션이 있는 경우 고객에게 해당 주소 범위를 허용하는 네트워크 정책을 생성할 수 있도록 IP 주소를 제공해야 합니다.

  • PATs를 허용하는 입력 필드는 256자 이상이어야 합니다.

키 페어

  • 유연한 인증 방법입니다.

  • 요청에 노출되지 않는 비밀번호 없는 자격 증명입니다.

  • 대화형 애플리케이션에는 일반적으로 사용되지 않습니다.

  • 장기 자격 증명과 관련된 보안 위험은 네트워크 정책, 강력한 저장소 및 순환 전략과 같은 다른 보안 조치를 통해 완화해야 합니다. 프로그래밍 방식 액세스 토큰과 달리, 키 페어에는 추가 조치가 *필요*하지 않으므로 인증의 보안 수준이 떨어질 수 있습니다.

서비스 간 애플리케이션에 대한 인증 선택하기

서비스 간 애플리케이션은 사용자와 상호 작용하지 않으며 서비스에 대한 전용 인증 방법이 있습니다. 다음 테이블에는 서비스 간 애플리케이션에 사용할 수 있는 인증 방법과 관련된 장점 및 문제점이 나와 있습니다. 이러한 인증 방법에 대한 개요는 애플리케이션의 인증 방법 개요 섹션을 참조하세요.

참고

서비스 간 애플리케이션에 대한 Snowflake 사용자 오브젝트를 생성하는 경우 ``TYPE = SERVICE``를 지정합니다. 사용자 유형에 대한 자세한 내용은 사용자 유형 섹션을 참조하세요.

메서드

장점

문제점

워크로드 ID 페더레이션 . 기본 설정 옵션

  • 시크릿 없는 인증.

  • 관리자가 클라이언트 IDs 및 시크릿을 지속적으로 보호하고 순환할 필요가 없습니다.

없습니다.

외부 OAuth . 강력한 옵션

  • IdP가 지원하는 경우 애플리케이션은 시크릿 형식의 인증을 사용할 수 있습니다.

  • 애플리케이션을 위한 인증 서버로 서드 파티 IdP를 이미 사용하는 조직에 적합합니다.

서드 파티 IdP를 인증 서버로 구성하기 위해서는 전문 지식이 필요합니다.

키 페어

  • 유연한 인증 방법입니다.

  • 요청에 노출되지 않는 비밀번호 없는 자격 증명입니다.

장기 자격 증명과 관련된 보안 위험은 네트워크 정책, 강력한 저장소 및 순환 전략과 같은 다른 보안 조치를 통해 완화해야 합니다. 프로그래밍 방식 액세스 토큰과 달리, 키 페어에는 추가 조치가 *필요*하지 않으므로 인증의 보안 수준이 떨어질 수 있습니다.

프로그래밍 방식 액세스 토큰(PAT)

  • 단일 요소 비밀번호를 쉽게 대체합니다.

  • Snowflake에서 생성된 자격 증명이므로 Snowflake 외부에서 재사용할 수 없습니다.

  • 특정 액세스 제어 역할로 범위를 지정하여 도용되는 경우의 피해를 제한할 수 있습니다.

  • Snowflake에서는 수명이 긴 시크릿을 사용할 때의 위험을 완화하기 위해 추가적인 보안 조치를 구현해야 합니다.

  • `GitHub 시크릿 스캐너 프로그램<https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partnership-program/secret-scanning-partner-program>`_은 공용 리포지토리에서 유출된 Snowflake PATs를 자동으로 감지하고 비활성화하며 Snowflake 관리자에게 알립니다.

  • 키-페어와 달리 클라이언트와 서버 모두에서 보안되어야 합니다.

  • 키-페어와 달리, 시크릿은 요청에서 Snowflake로 전송되어야 하므로 노출이 증가합니다.

  • 도용된 경우 소유권이 있는 사용자가 애플리케이션을 가장할 수 있습니다.

  • 장기 자격 증명과 관련된 보안 위험은 강력한 저장 및 순환 전략과 같은 다른 보안 조치를 통해 완화해야 합니다.