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 데이터에 액세스하는 모든 앱을 나타냅니다. 이 정의에는 사용자 지정 웹 애플리케이션, 서드 파티 다중 테넌트 애플리케이션, 데스크톱 애플리케이션, 로컬 스크립트, 클라우드의 워크로드가 포함됩니다.
사용 가능한 인증 방법에 대해 설명할 때 이 항목에서는 두 가지 유형의 애플리케이션을 구분합니다.
- 워크로드 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 . 강력한 옵션 |
|
서드 파티 IdP를 인증 서버로 구성하기 위해서는 전문 지식이 필요합니다. |
프로그래밍 방식 액세스 토큰(PAT) |
|
|
키 페어 |
|
|
서비스 간 애플리케이션에 대한 인증 선택하기¶
서비스 간 애플리케이션은 사용자와 상호 작용하지 않으며 서비스에 대한 전용 인증 방법이 있습니다. 다음 테이블에는 서비스 간 애플리케이션에 사용할 수 있는 인증 방법과 관련된 장점 및 문제점이 나와 있습니다. 이러한 인증 방법에 대한 개요는 애플리케이션의 인증 방법 개요 섹션을 참조하세요.
참고
서비스 간 애플리케이션에 대한 Snowflake 사용자 오브젝트를 생성하는 경우 ``TYPE = SERVICE``를 지정합니다. 사용자 유형에 대한 자세한 내용은 사용자 유형 섹션을 참조하세요.
메서드 |
장점 |
문제점 |
|---|---|---|
워크로드 ID 페더레이션 . 기본 설정 옵션 |
|
없습니다. |
외부 OAuth . 강력한 옵션 |
|
서드 파티 IdP를 인증 서버로 구성하기 위해서는 전문 지식이 필요합니다. |
키 페어 |
|
장기 자격 증명과 관련된 보안 위험은 네트워크 정책, 강력한 저장소 및 순환 전략과 같은 다른 보안 조치를 통해 완화해야 합니다. 프로그래밍 방식 액세스 토큰과 달리, 키 페어에는 추가 조치가 *필요*하지 않으므로 인증의 보안 수준이 떨어질 수 있습니다. |
프로그래밍 방식 액세스 토큰(PAT) |
|
|