단일 요소 인증에서 마이그레이션하기 위한 모범 사례¶
이 섹션에서는 고객이 Snowflake 기능을 활용하여 강력한 인증을 시행하고 자격 증명 도용의 위험을 완화하는 방법에 대한 모범 사례를 제공합니다. 이 정보는 비밀번호 전용 인증에서 벗어나기 위한 최신 Snowflake 전략을 강조하는 단일 요소 비밀번호 로그인 사용 중단에 대한 계획 과 함께 사용하십시오.
이 가이드의 샘플 쿼리는 Snowflake 고객을 돕기 위한 예시이며 프로덕션 환경에서 구현하기 위한 것이 아닙니다.
소개¶
이 문서 에서 언급했듯이 Snowflake는 계정 보안을 쉽게 유지할 수 있는 3가지 핵심 요소에 중점을 둡니다.
프롬프트: 보안 모범 사례를 사용하지 않는 사용자의 경우 보안 모범 사례(예: 다단계 인증 구성(MFA))를 채택하는 것이 좋습니다.
적용: 관리자가 기본적으로 보안을 쉽게 적용할 수 있도록 합니다(예: 모든 사용자에게 MFA 를 사용하도록 요구).
모니터: 보안 정책의 준수 여부에 대한 가시성을 제공합니다(예: MFA 를 구성하지 않은 사용자를 감사).
다음 정보는 주로 Snowflake Trust Center 를 사용하여 모니터링하는 모범 사례와 인증 및 네트워크 정책을 활용하는 시행 단계에 중점을 둡니다.
Snowflake 연결 세션 수명 주기¶
다음 다이어그램에 표시된 것처럼 드라이버, 커넥터 또는 Snowsight 를 통해 Snowflake에 연결할 수 있습니다.

사용자 또는 서비스가 Snowflake에 연결되면 다음과 같은 일이 발생합니다.
구성된 경우 네트워크 정책 이 적용됩니다. 사용자 수준의 네트워크 정책이 계정 수준의 네트워크 정책보다 우선한다는 점에 유의하십시오.
구성된 경우 인증 정책 이 적용됩니다. 사용자 수준 인증 정책이 계정 수준 인증 정책보다 우선한다는 점에 유의하십시오.
사용자 또는 서비스가 Snowflake 네이티브 비밀번호 인증을 사용하는 경우 비밀번호 정책 이 구성된 경우 적용됩니다.
위의 제어를 통해 사용자 또는 서비스가 허용되고 승인된 경우 세션 정책 이 적용되어 비활성 기간이 지난 후 사용자가 재인증하는 방법을 제어합니다. 사용자 수준 세션 정책이 계정 수준 세션 정책보다 우선합니다.
네트워크 및 인증 정책: 일반 가이드라인¶
모든 경우에 다음 가이드라인을 고려하십시오. 자세한 내용은 3단계: 보호 섹션을 참조하십시오.
Snowflake는 구성 및 적용을 강력히 권장합니다.
PERSON (인간), SERVICE, LEGACY_SERVICE 를 구분하기 위한 사용자 TYPE 특성.
PERSON: MFA 가 적용되는 사용자를 통한 대화형 인증의 경우. 이 글을 작성하는 시점의 기본값은 NULL 이며, MFA 적용 시점에서 는PERSON 으로 취급됩니다.
SERVICE: 프로그래밍 방식의 액세스를 사용하는 서비스 간 인증용. 해당 사용자는 MFA 적용에서 제외되지만 더 이상 비밀번호 인증을 지원하지 않습니다. 이러한 사용자는 OAuth 또는 키 페어만 지원합니다.
LEGACY_SERVICE: 비밀번호 전용 인증을 지원하는 유일한 사용자 유형입니다(MFA 적용 제외). 이는 마이그레이션 도구로만 사용되며, 고객은 네트워크 정책을 통해 해당 사용자를 보호하고 유출된 비밀번호 보호 기능으로 모니터링해야 합니다.
참고
LEGACY_SERVICE 는 마이그레이션 도구로 사용되어야 하며, 2025년 11월에 지원 중단 될 예정입니다.
고객 특성을 통한 자동 프로비저닝 및 사용자 유형 설정을 위한 SCIM
네트워크 정책을 통해 사용자와 서비스가 가능한 한 승인되고 신뢰할 수 있는 출처에서만 제공되도록 하십시오.
인증 정책은 OAuth 및 SAML 같이 수명이 짧은 자격 증명을 활용하는 강력한 인증 방법을 시행합니다.
조직의 비밀번호 정책을 적용하기 위한 비밀번호 정책.
유휴 세션 시간을 제한하는 세션 정책.
서비스 사용자의 경우 고객은 가급적 OAuth 같이 수명이 짧은 자격 증명을 사용하는 것이 좋습니다. 키 페어 와 같은 장기 자격 증명의 경우 고객은 해당 키를 정기적으로 교체하고 가능한 한 네트워크 정책과 결합하는 것이 좋습니다.
인간 상호 작용 사용자의 경우, 고객은 자체 SAML 페더레이션 인증 을 활용하여 자체 ID 공급자와 함께, 그리고 자체 MFA 를 활용하여 자신의 Snowflake 계정을 조직 전체의 ID 공급자와 통합해야 합니다.
break glass 사용 사례 및 기본 비밀번호를 사용하는 고객의 경우, Snowflake는 break glass 사용자를 위해 Snowflake 기본 MFA 를 사용할 것을 적극 권장합니다.
고객은 내부 보안 정책에 따라 자격 증명을 정기적으로 교체해야 합니다.
고객은 항상 Trust Center 를 사용하여 위험한 사용자를 모니터링하고 조직의 보안 운영 센터와 Snowflake 계정을 통합해야 합니다.
더 강력한 인증을 위한 Snowflake 북극성¶
2025년에 Snowflake는 고객을 돕기 위한 추가 기능을 지원할 예정입니다.
2025년 상반기¶
기본 MFA 지원을 개선하여 DUO 를 넘어 패스키 및 인증자 앱 지원으로 확장합니다(2025년 4월 말 일반 공급을 목표로 비공개 미리 보기 중).
드라이버와 커넥터에서 기본 OAuth 지원을 통해 OAuth 구성 및 도입을 간소화합니다.
다음과 같은 새로운 기능이 Trust Center에 추가되었습니다.
이메일 알림(공개 미리 뷰는 2025년 4월 말 대상).
파트너와 함께하는 확장자 및 맞춤형 스캐너 패키지(현재 비공개 미리 보기 중이며, 2025년 7월 말경 일반 공급 목표).
고객 조직 수준의 Trust Center(2025년 4월 말 비공개 미리 보기로 제공).
2025년 후반¶
머신 러닝 이상 징후 탐지를 사용하도록 Trust Center를 개선했습니다.
SAML, OAuth, Snowsight 로 사용자 경험을 개선합니다.
워크로드 ID 및 OIDC 를 지원하여 고객이 Azure 관리 ID, AWS 역할 및 GCP 서비스 계정과 같은 기본 CSP ID를 사용하여 자격 증명 없이도 워크로드를 Snowflake에 쉽게 연결할 수 있습니다.
mTLS 를 지원하는 고객의 리소스에 대해 mTLS 를 인바운드와 아웃바운드 양방향으로 지원합니다.
Snowflake는 회사가 적절하다고 판단하는 경우 위의 목록과 일정을 업데이트하고 변경할 수 있는 권리를 보유하며, 향후 자세한 내용을 공유할 예정입니다.
인증 및 네트워크 정책 적용을 위한 모범 사례¶
보다 강력한 인증 태세로 마이그레이션하려면 다음 네 가지 단계를 따를 것을 권장합니다.
위험한 사용자를 감지하십시오.
중단을 최소화할 수 있도록 마이그레이션을 계획하십시오.
Snowflake에서 사용자를 보호하십시오.
위험한 사용자를 지속적으로 모니터링하십시오.

1단계: 감지¶
Snowflake는 두 가지 주요 기능을 도입했습니다.
Threat Intelligence 스캐너 패키지: 이 스캐너는 다음 다이어그램의 논리에 따라 위험한 사용자를 식별합니다. 이 섹션에는 위험한 사용자를 목록으로 나열하고 위험한 이유를 설명하는 샘플 쿼리도 포함되어 있습니다.
비밀번호 유출 방지: 다크웹에서 발견된 사용자 비밀번호를 확인하고 자동으로 비활성화합니다. 이를 통해 비밀번호 유출을 방지하고 데이터 유출 가능성을 제한할 수 있습니다. 비밀번호가 유출된 사용자는 계정 관리자에게 연락하여 비밀번호를 재설정할 수 있습니다.
고객은 Threat Intelligence 스캐너를 켜고 스캔 빈도를 사용자 지정해야 합니다. 일반적으로 이 스캐너는 일주일에 한 번 실행하여 현재 위험한 사용자 상태를 보고해야 합니다. 모든 신뢰도 스캐너의 결과는 SNOWFLAKE.TRUST_CENTER
스키마에 저장됩니다. 고객은 Snowflake 기본 경고를 활용하여 보안 관리자에게 자동으로 알림을 보내거나 위험한 사용자가 감지될 경우 작업을 수행할 수 있습니다.
위험 사용자 목록에 대한 샘플 쿼리¶
Snowflake는 최근 개인 사용자를 위한 스캐너와 서비스 사용자를 위한 스캐너 두 가지를 새롭게 추가했습니다. 이를 통해 고객은 사용자 유형에 따라 단일 요소 비밀번호 로그온을 사용하는 사용자 목록을 별도로 생성할 수 있습니다.
각 유형별로 위험한 사용자의 목록을 반환할 수 있습니다.
위험 사용자 목록¶
SELECT *
FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
WHERE event_id =
(SELECT event_id FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
WHERE scanner_id = 'THREAT_INTELLIGENCE_NON_MFA_PERSON_USERS'
ORDER BY event_id DESC LIMIT 1) AND total_at_risk_count != 0
;
위험 서비스 사용자 목록¶
SELECT *
FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
WHERE event_id =
(SELECT event_id FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
WHERE scanner_id = 'THREAT_INTELLIGENCE_PASSWORD_SERVICE_USERS'
ORDER BY event_id DESC LIMIT 1 ) and total_at_risk_count != 0
;
TYPE 의 사용자 분포 및 사용되는 인증 방법¶
이전 쿼리 외에도 사용자 유형 및 사용되는 인증 방법에 따른 사용자 분포를 목록으로 작성하는 것이 유용합니다. 이를 통해 고객은 SAML 및 OAuth 같은 더 강력한 인증 방법으로 사용자를 마이그레이션하는 전략을 세울 수 있습니다. 예를 들어, 사용자가 Snowflake에 비밀번호가 있어 위험으로 표시되지만 해당 사용자가 SAML 인증만 사용하고 있는 경우 가능한 한 빨리 Snowflake에서 해당 비밀번호를 제거하는 것이 좋습니다.
WITH users AS (
SELECT DISTINCT
user_id
, name
, login_name
, type
, email
FROM
SNOWFLAKE.ACCOUNT_USAGE.USERS
WHERE
DELETED_ON IS NULL)
SELECT
u.user_id
, a.event_timestamp
, a.user_name
, u.type
, a.reported_client_type
, a.first_authentication_factor
, a.second_authentication_factor
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY AS a
JOIN USERS u ON a.user_name = u.name
;
2단계: 마이그레이션 계획¶
마이그레이션 계획은 1단계: 감지 에서 시작됩니다. 위험한 사용자를 식별한 후 네트워크 및 인증 정책: 일반 가이드라인 준수 계획을 세우십시오. 비밀번호나 키 페어와 같은 정적 자격 증명을 가능한 한 사용하지 말고, 단일 로그인(연동 인증)을 활용해야 합니다. 예를 들어, 상호작용형 사용자의 경우 SAML 를, 프로그램 방식(SERVICE) 및 상호작용형(PERSON) 사용자의 경우 OAuth 를 적용할 수 있습니다.
일부 레거시 애플리케이션을 지원하기 위해 정적 자격 증명(키 페어 또는 비밀번호)을 사용해야 하는 경우 계획에 다음 사항을 고려하십시오.
가능하면 네트워크 정책을 활용하십시오.
조직의 정책에 따라 정적 자격 증명을 교체하십시오.
마이그레이션 고려 사항¶
마이그레이션을 계획할 때 염두에 두어야 할 몇 가지 고려 사항은 다음과 같습니다.
먼저 사용자 유형 을(이는 SCIM 을 통해 자동화할 수 있음) 설정합니다.
둘째, 애플리케이션이 지원하는 인증 방법을 확인하십시오. Snowflake는 OAuth, SAML, 키 페어, MFA 등 다양한 인증 방법 을 지원합니다. 그러나 Snowflake에 연결하는 애플리케이션도 강력한 인증 방법을 지원해야 합니다. 두 가지 사용 사례가 있습니다.
앱은 이미 SAML 및/또는 OAuth 를 지원합니다. 가능한 한 빨리 해당 인증으로 마이그레이션하는 것이 좋습니다.
이 앱은 레거시 앱으로 SAML 또는 OAuth 같은 강력한 인증 방법을 지원하지 않으며, 비밀번호만 지원합니다. 이 경우 레거시 애플리케이션을 업데이트하는 것이 좋습니다. 그 동안에는 애플리케이션을 업데이트할 때까지 네트워크 정책, 비밀번호 로테이션, 비밀번호 유출 방지 기능을 활용할 수 있습니다.
다음으로 고객은 로컬 사용자(SAML 또는 OAuth 가 활성화되지 않은 Snowflake에서 수동으로 생성한 사용자)를 위해 다음 사항을 고려해야 합니다.
SSO 를 지원하는 애플리케이션의 경우 로컬 사용자를 SSO 지원 사용자로 변환하고 사용자를 변환할 때 다운타임을 고려하십시오.
로컬 사용자를 SSO 사용으로 변환하려면 해당 사용자가 IdP 에 있는지 확인한 다음 SCIM 을 통해 수동으로 또는 가급적 자동으로 Snowflake에서 프로비저닝합니다.
사용하지 않는 로컬 사용자를 비활성화합니다.
Snowflake는 사용자 수준과 계정 수준 모두에서 인증 정책, 네트워크 정책, 비밀번호 정책을 지원합니다. 사용자 수준 정책을 먼저 고려하여 점진적으로 마이그레이션하십시오(사용자 수준 정책이 계정 수준 정책보다 우선합니다):
Snowflake는 서비스 사용자를 사용하는 애플리케이션에 사용자 수준의 네트워크 정책을 권장합니다(TYPE = SERVICE 또는 LEGACY_SERVICE).
인간 사용자(TYPE = PERSON 또는 NULL)의 경우 사용자 수준의 네트워크 정책으로 시작한 다음 계정 수준에서 네트워크 정책을 적용하여 사용자 수준별 정책이 없는 모든 사용자 집단을 보호할 수 있습니다.
MFA 정책과 동일한 개념으로 사용자 수준 정책부터 시작합니다.
싱글 사인온을 지원하지 않는 레거시 애플리케이션이 있는 경우, 기본적으로 특정 역할에 연결되어 있으며, 네트워크 정책이 필요하고, 시간 제한이 있는 프로그래밍 방식 액세스 토큰(PATs) 을 사용하는 것이 좋습니다.
3단계: 보호¶
다음 다이어그램은 권장 인증 모범 사례를 탐색하는 데 도움이 됩니다. 보시다시피, Snowflake는 항상 연합 인증 및 승인을 먼저 사용할 것을 권장합니다.

Snowflake 계정 유출 위험을 완화하려면 다음 단계를 따르십시오.
사용자 유형 설정하기¶
보호 단계의 첫 번째 단계는 SCIM 또는 수동으로 사용자 유형을 자동으로 설정하는 것입니다.
ALTER USER svc_user1 SET TYPE = SERVICE;
ALTER USER user1@example.COM SET TYPE = PERSON;
-- LEGACY APPLICATION ONLY
또한 이제 계정을 생성할 때 관리자 사용자 유형을 설정할 수 있습니다.
CREATE ACCOUNT <name> [ ADMIN_USER_TYPE = PERSON | SERVICE | LEGACY_SERVICE | NULL ];
팁
많은 고객의 서비스 사용자 이름에는 일반적으로 일정한 패턴(예: local_svc_user1
)이 있습니다. 이 명명 패턴을 활용하여 SERVICE 유형을 대규모로 설정할 수 있습니다.
로컬 비밀번호가 필요하지 않은 경우 제거하기¶
Trust Center 결과에 따라 TYPE 및 AuthN 사용 방법별 사용자 분포 및 위험 사용자 목록의 쿼리를 활용하여 이미 SAML, OAuth 또는 키페어만 사용하고 있는 사용자에 대해 Snowflake에서 비밀번호를 정리할 수 있습니다.
서비스 사용자를 위한 인증 정책 생성하기¶
Snowflake는 프로그래밍 방식 서비스 사용자에게 OAuth 사용을 권장하며, 인증 정책을 통해 이를 적용할 수 있습니다.
CREATE AUTHENTICATION POLICY PROGRAMMATIC_ACCESS_USER_AUTH
CLIENT_TYPES = ('DRIVERS', 'SNOWSQL')
AUTHENTICATION_METHODS = ('OAUTH')
SECURITY_INTEGRATIONS = ('<OAUTH SECURITY INTEGRATIONS>');
ALTER USER <SERVICE_USER> SET AUTHENTICATION POLICY PROGRAMMATIC_ACCESS_USER_AUTH;
고객은 여전히 SERVICE 사용자와의 인증에 키쌍을 사용할 수 있지만 네트워크 정책과 결합하고 정기적으로 키를 교체해야 합니다.
참고
키 페어 또는 OAuth 를 지원하지 않는 레거시 시스템이 있고 인증에 비밀번호를 사용해야 하는 경우 인증 방법 PASSWORD
으로 추가 인증 정책을 생성하여 해당 특정 프로그래밍 방식 사용자에게 적용하십시오. 이 접근법을 네트워크 및 인증 정책: 일반 가이드라인 와 결합하십시오.
인증 정책을 생성해 사용자에게 MFA 적용하기¶
Snowflake는 고객이 IdP 에서 지원하는 MFA 솔루션과 함께 자체 SAML ID 공급자(IdPs)를 사용할 것을 권장합니다. 다음 인증 정책 예제는 고객에게 도움이 됩니다.
Snowflake 네이티브 비밀번호를 사용하는 모든 사용자에게 MFA 를 적용합니다.
고객 SAML IdP 를 통해 싱글 사인온 사용자에게 MFA 를 적용하십시오.
CREATE AUTHENTICATION POLICY HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA
AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
SECURITY_INTEGRATIONS = ('<SAML SECURITY INTEGRATIONS>')
MFA_AUTHENTICATION_METHODS = ('PASSWORD'); -- enforce Snowflake MFA for native passwords only
MFA_ENROLLMENT = 'REQUIRED';
고객은 고객 IdP 가 오프라인 상태일 때 계정 관리자가 계속 Snowflake 계정에 로그인할 수 있도록 차단 유리 상황을 고려해야 합니다.
CREATE AUTHENTICATION POLICY ACCOUNTADMIN_BREAKGLASS_MFA
AUTHENTICATION_METHODS = ('PASSWORD')
MFA_AUTHENTICATION_METHODS = ('PASSWORD') -- enforce Snowflake MFA for native passwords only
MFA_ENROLLMENT = 'REQUIRED';
SSO 에 대한 MFA¶
참고
보다 엄격한 정책을 원한다면 MFA 적용 정책을 추가로 생성해 사용자 수준에서 직접 적용할 수 있습니다(예: IdP 고객이 MFA 를 지원하지 않는 경우 IdP 수준에서 MFA 적용과 관계없이 사용자에게 MFA 을 적용하는 경우). (일부 고객은 계정 관리자 등 권한이 높은 사용자에게 이 옵션을 사용하여 MFA 를 2배로 사용할 수 있습니다.)
CREATE AUTHENTICATION POLICY ACCOUNTADMIN_DOUBLE_MFA
AUTHENTICATION_METHODS = ('PASSWORD', 'SAML')
SECURITY_INTEGRATIONS = ('<SAML SECURITY INTEGRATIONS>')
MFA_AUTHENTICATION_METHODS = ('PASSWORD', 'SAML') -- double MFA
MFA_ENROLLMENT = 'REQUIRED';
비밀번호 정책 만들기¶
레거시 시스템을 사용 중이거나 Snowflake 기본 비밀번호를 사용해야 하는 상황인 경우, 조직 비밀번호 정책이 기본 정책과 다르면 Snowflake 비밀번호 정책을 활용하여 조직 비밀번호 정책과 일치시키십시오.
CREATE PASSWORD POLICY password_policy_account
PASSWORD_MIN_LENGTH = 32
-- PASSWORD_MAX_LENGTH = <integer>
PASSWORD_MIN_UPPER_CASE_CHARS = 6
PASSWORD_MIN_LOWER_CASE_CHARS = 6
PASSWORD_MIN_NUMERIC_CHARS = 4
PASSWORD_MIN_SPECIAL_CHARS = 8
PASSWORD_MIN_AGE_DAYS = 10
PASSWORD_MAX_AGE_DAYS = 30
PASSWORD_MAX_RETRIES = 3
PASSWORD_LOCKOUT_TIME_MINS = 30
PASSWORD_HISTORY = 24
COMMENT = '<string_literal>';
세션 정책 만들기¶
특정 기간 동안 활동이 없으면 재인증을 강제하는 세션 정책을 생성하는 것이 좋습니다. 이는 예시일 뿐이며 개별 사용자 수준에서 정책을 사용자 지정할 수 있습니다.
CREATE SESSION POLICY session_policy_account
SESSION_IDLE_TIMEOUT_MINS = 240 -- Snowflake clients and programmatic clients
SESSION_UI_IDLE_TIMEOUT_MINS = 20 -- For the Snowflake web interface
COMMENT = '<string_literal>';
서비스 사용자를 위한 네트워크 정책 생성하기¶
일반적으로 서비스 또는 프로그램 접속 사용자는 승인된 IP 주소(또는 비공개 연결의 경우 VPCE ID, LinkID 등)에서 접속해야 합니다.
Snowflake는 서비스 사용자 수준의 네트워크 정책을 생성하여 승인되고 신뢰할 수 있는 출처의 프로그래밍 방식 액세스 사용자에 대한 액세스를 제한할 것을 권장합니다. 고객은 내부 스테이지에서도 네트워크 규칙을 적용하는 것을 고려해야 합니다.
참고
내부 스테이지에 대한 네트워크 규칙은 AWS 리전의 Snowflake에서만 지원되며, Azure의 경우 공개 액세스 차단을 고려할 수 있으며, GCP 서비스 제어가 있는 경우 Snowflake 지원팀에 문의하십시오.
클라우드의 동적 특성으로 인해 일부 클라우드 공급자는 Snowflake 네트워크 정책에 목록에 포함할 IP 주소 범위를 제공할 수 없는 경우가 있습니다. 이러한 시나리오의 경우 네트워크 및 인증 정책 일반 가이드라인을 따르십시오. 또는 도구에서 비공개 연결을 지원하는 경우 비공개 연결을 고려하십시오.
고객이 비공개 연결을 사용하는지 여부에 따라 비공개 또는 공용 네트워크에서 연결이 이루어질 수 있습니다. 관련 IPs (공개 또는 비공개) 및/또는 CSP 태그(예: VPCE ID, LinkIDs)를 포함하는 여러 네트워크 규칙을 추가하여 공개 연결과 비공개 연결을 동시에 허용할 수 있다는 점에 유의하십시오.
-- ACCESS FROM PUBLIC IP ADDRESSES
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_PUBLIC
TYPE = IPV4
VALUE_LIST = ( 'PUBLIC IP1' , 'XX.XX.XX.XX/24' [ , ... ] )
MODE = INGRESS
;
-- ACCESS FROM PRIVATE NETWORK
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_PL
TYPE = AWSVPCEID
VALUE_LIST = ( 'VPCE-123ABC3420C1931' , 'VPCE-123ABC3420C1932' )
MODE = INGRESS
;
-- RESTRICT ACCESS TO INTERNAL STAGE USING VPCE ID
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_INTERNAL_STAGE
TYPE = AWSVPCEID
VALUE_LIST = ( 'VPCE-123ABC3420C1933' )
MODE = INTERNAL_STAGE
;
CREATE NETWORK POLICY PROGRAMMATIC_ACCESS_USER_NET_POLICY
ALLOWED_NETWORK_RULE_LIST =
(
'PROGRAMMATIC_ACCESS_USER_NET_RULE_PUBLIC',
'PROGRAMMATIC_ACCESS_USER_NET_RULE_PL',
'PROGRAMMATIC_ACCESS_USER_NET_RULE_INTERNAL_STAGE'
)
--BLOCKED_NETWORK_RULE_LIST = ( 'OPTIONAL BLOCKED LIST OF IPS' )
;
계정 수준에서 네트워크 정책 생성하기¶
계정 수준 정책은 네트워크 정책이 직접 적용되지 않은 사용자에 대한 기본 보안 네트워크 정책으로 작동합니다. 가장 좋은 방법은 이러한 정책을 가능한 한 제한적이고 짧게 유지하면서 사용자 수준 정책을 사용하여 특정 사용자의 요구를 처리하는 것입니다.
Snowflake는 조직의 모든 요구 사항을 충족하기 위해 거대한 계정 수준의 네트워크 정책을 구축하는 대신 사용자 수준의 정책을 통해 보다 세밀하게 제어할 수 있도록 하는 것을 권장합니다.
사용자 수준의 네트워크 정책과 마찬가지로 고객이 비공개 연결을 사용하는지 여부에 따라 비공개 또는 공용 네트워크에서 연결이 이루어질 수 있습니다. 관련 IPs (공개 또는 비공개) 및/또는 CSP 태그(예: VPCE ID, LinkIDs)를 포함하는 여러 네트워크 규칙을 추가하여 공개 연결과 비공개 연결을 동시에 허용할 수 있다는 점에 유의하십시오.
-- ACCESS FROM PUBLIC IP ADDRESSES
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_PUBLIC
TYPE = IPV4
VALUE_LIST = ( 'PUBLIC IP1' , 'XX.XX.XX.XX/24' [ , ... ] )
MODE = INGRESS
;
-- ACCESS FROM PRIVATE NETWORK
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_PL
TYPE = AWSVPCEID
VALUE_LIST = ( 'VPCE-123ABC3420C1934' , 'VPCE-123ABC3420C1936' )
MODE = INGRESS
;
-- RESTRICT ACCESS TO INTERNAL STAGE USING VPCE ID
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_INTERNAL_STAGE
TYPE = AWSVPCEID
VALUE_LIST = ( 'VPCE-123ABC3420C1937')
MODE = INTERNAL_STAGE
;
CREATE NETWORK POLICY ACCOUNT_LEVEL_NET_POLICY
ALLOWED_NETWORK_RULE_LIST =
(
'HUMAN_ACCESS_ACCOUNT_NET_RULE_PUBLIC',
'HUMAN_ACCESS_ACCOUNT_NET_RULE_PL',
'HUMAN_ACCESS_ACCOUNT_NET_RULE_INTERNAL_STAGE'
)
--BLOCKED_NETWORK_RULE_LIST = ( 'OPTIONAL BLOCKED LIST OF IPS' )
;
서비스 사용자 보호¶
TYPE=SERVICE
사용자는 계정 수준 MFA 적용 정책에서 제외되며 비대화형 사용 사례의 보안 상태를 개선하기 위한 제한 사항이 적용됩니다. 특히 SERVICE 타입 사용자는 비밀번호나 SAML SSO 를 사용하여 로그인할 수 없습니다. 아래 주의 사항을 참조하십시오.
-- FOR EVERY SERVICE PROGRAMMATIC ACCESS USER
ALTER USER SERVICE_USER_1 SET
TYPE = SERVICE
NETWORK_POLICY = PROGRAMMATIC_ACCESS_USER_NET_POLICY
AUTHENTICATION POLICY = PROGRAMMATIC_ACCESS_USER_AUTH;
레거시 애플리케이션을 위한 서비스 사용자¶
OAuth 를 지원하지 않는 레거시 애플리케이션이 있는 경우, LEGACY_SERIVCE 로 비밀번호를 사용하는 대신 프로그래밍 방식 액세스 토큰(PATs) 을 사용하십시오.
PATs 에는 보안을 보강하기 위한 많은 제한이 있습니다. PAT 를 생성하면 특정 역할에 동점되고, 시간 제한이 있으며, 해당 특정 사용자(계정 수준 또는 사용자 수준)에 적용되는 네트워크 정책에 연결됩니다.
PAT 를 복사하여 기존 애플리케이션의 비밀번호 필드에 사용할 수 있습니다. 이러한 기존 애플리케이션의 경우 LEGACY_SERVICE 또는 비밀번호 전용 인증을 사용할 필요가 없습니다.
조심
SERVICE 유형 사용자는 비밀번호를 인증 수단으로 사용할 수 없으므로 더 강력한 인증 방식을 지원하지 않는 레거시 시스템의 경우 고객은 대신 PAT 를 사용하는 것이 좋습니다.
참고
LEGACY_SERVICE 는 2025년 11월부터 더 이상 사용되지 않습니다.
계정 수준에서 비밀번호 및 세션 정책 적용하기¶
Snowflake 보안 관리자는 계정 수준에서 기본 비밀번호 및 세션 정책을 적용한 다음 필요에 따라 이러한 정책을 사용자 수준 정책으로 재정의해야 합니다.
ALTER ACCOUNT SET
SESSION POLICY = SESSION_POLICY_ACCOUNT;
PASSWORD POLICY = PASSWORD_POLICY_ACCOUNT;
서비스 사용자 테스트¶
이 단계에서 계정에는 비밀번호 및 세션 정책이 적용되어 있으며, 서비스 프로그래밍 방식 사용자는 MFA 에서 면제되고, 신뢰할 수 있는 소스에서 연결이 설정되고 OAuth 또는 키 페어와 같은 권장 인증 방법이 사용되도록 하는 자체 인증 정책 및 네트워크 정책이 적용됩니다.
보안 관리자는 몇 명의 서비스 사용자를 테스트하여 원활한 운영을 보장하고 연결이 신뢰할 수 있는 출처에서 이루어지고 적절한 인증 방법을 사용하는지 확인해야 합니다. 관리자는 Trust Center 외에 LOGIN_HISTORY 를 사용하여 서비스 사용자가 네트워크 정책에 의해 보호되고 있는지 확인해야 합니다.
SELECT *
FROM TABLE(INFORMATION_SCHEMA.LOGIN_HISTORY(TIME_RANGE_START =>
DATEADD('HOURS',-1,CURRENT_TIMESTAMP()),CURRENT_TIMESTAMP()))
ORDER BY EVENT_TIMESTAMP;
MFA 적용으로 계정 보호하기¶
SERVICE 유형이 아닌 모든 사용자에게 MFA 를 적용하려면 계정 수준에서 MFA 적용 정책을 적용하십시오.
이러한 정책을 통해 모든 대화형 사용자는 자체 IdP 또는 기본 Snowflake MFA 에서 MFA 를 활성화할 수 있습니다.
ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;
계정 관리자와 같이 권한이 높은 사용자에게 MFA 를 이중으로 적용하려면 이 사용자 수준에서 MFA 를 적용하십시오. 하지만 IdP 사이트가 다운될 경우를 대비한 프로시저와 보안 요구 사항 간에 균형을 맞춰야 합니다.
ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;
긴급 상황의 경우:
ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;
계정 수준 네트워크 정책 적용하기¶
마지막으로 명시적 네트워크 정책이 없는 다른 모든 사용자를 보호하기 위해 계정 수준에서 네트워크 정책을 적용해야 합니다.
ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;
사용하지 않는 사용자 비활성화하기¶
Trust Center CIS 스캐너(1.8)는 지난 90일 동안 활동하지 않은 사용자를 모니터링합니다. 다음 다이어그램과 같이 Open a Worksheet 를 클릭하면 비활성 사용자를 나열하는 쿼리가 표시됩니다.
SELECT
F.VALUE:ENTITY_ID::VARCHAR AS ENTITY_ID,
F.VALUE:ENTITY_NAME::VARCHAR AS ENTITY_NAME,
F.VALUE:ENTITY_OBJECT_TYPE::VARCHAR AS ENTITY_OBJECT_TYPE,
F.VALUE:ENTITY_DETAIL AS ENTITY_DETAIL
FROM
SNOWFLAKE.TRUST_CENTER.FINDINGS,
LATERAL FLATTEN(INPUT => AT_RISK_ENTITIES) AS F;
Snowflake에서는 해당 사용자를 비활성화할 것을 적극 권장합니다.
4단계: 지속적인 모니터링¶
Trust Center 위협 인텔리전스 스캐너 패키지를 활용하여 MFA 및 네트워크 정책 시행을 모니터링할 수 있습니다. 유출된 비밀번호 보호 기능을 통해 Snowflake는 다크 웹에서 도난당한 자격 증명을 모니터링하고 다크 웹에서 발견된 것과 일치하는 비밀번호 해시를 가진 모든 사용자를 비활성화합니다. 또한 사용자 지정 쿼리와 함께 Snowflake 기본 경고를 활용하여 추가 위생 경고를 구축할 수도 있습니다.
유형이 특별히 설정되지 않은 사용자
비밀번호 또는 키 페어와 같은 정적 자격 증명을 사용하는 애플리케이션
LEGACY_SERVICE 에 새 사용자가 추가되었습니다
레거시 애플리케이션에 정기적으로 연락하여 더 강력한 승인으로 업그레이드하기