여러 계정 간 보안 통합 및 네트워크 정책 복제
여러 계정 간 보안 통합 및 네트워크 정책 복제 (Replication of security integrations & network policies across multiple accounts)
이 토픽은 보안 통합을 복제하는 방법과 각 객체를 사용한 장애 조치/복구(failover/failback)에 대한 정보를 제공하며, 다른 계정 수준 객체(예: 사용자, 역할, 웨어하우스)를 사용한 복제와 장애 조치/복구에 익숙하다고 가정해요.
출처: Snowflake 문서 - Replication of security integrations & network policies across multiple accounts
본문
Business Critical 기능
계정 객체 복제와 장애 조치/복구에는 Business Critical Edition(이상)이 필요해요. 업그레이드 문의는 Snowflake Support에 연락해요.
자세한 내용은 여러 계정 간 복제와 장애 조치 소개 를 참고해요.
이 객체와 서비스는 리전(region) 간과 클라우드 플랫폼(cloud platform) 간에 지원돼요.
개요
Snowflake는 Federated SSO(즉 SAML2 및 OIDC), OAuth, SCIM에 대한 네트워크 정책과 보안 통합의 복제를 지원하며, 각 네트워크 정책과 통합에 대해 장애 조치/복구를 활성화해요.
네트워크 정책과 각 보안 통합으로 복제 및 장애 조치/복구를 테스트하는 일반적인 접근 방식은 다음과 같아요.
- 복제를 위한 소스 계정과 타깃 계정을 확인하고 연결 URL을 확인해요.
- 소스 계정에서 단계를 완료해요.
- 타깃 계정에서 단계를 완료해요.
- 장애 조치/복구를 테스트해요.
네트워크 정책과 보안 통합은 사용 사례가 다르므로 소스 계정과 타깃 계정의 정확한 단계는 각 객체에 대해 약간씩 다르다는 점에 유의해요.
자세한 내용은 다음을 참고해요.
- SAML2 보안 통합 복제
- OIDC 보안 통합 복제
- SCIM 보안 통합 복제
- OAuth 보안 통합 복제
- 네트워크 정책 복제
- ServiceNow용 Snowflake 커넥터의 통합 및 객체 복제
SAML2 보안 통합 복제
SAML2 보안 통합을 복제하면 SAML2 보안 통합 정의에서 연결 URL(connection URL) 을 지정해 소스 계정과 타깃 계정을 아이덴티티 프로바이더(identity provider)에 연결해요.
아이덴티티 프로바이더를 업데이트해 연결 URL을 지정하고 사용자가 소스 계정에 존재하도록 하는 것이 중요해요. 이러한 업데이트가 없으면 사용자 검증이 발생할 수 없어 사용자가 타깃 계정에 접근하지 못하게 돼요.
현재 제한 사항: Snowflake에 대한 SAML SSO의 경우, 연결 URL을 지정하는 SAML2 보안 통합의 복제는 현재 기본 연결(primary connection)에서만 지원되며 보조 연결에서는 지원되지 않아요. 장애 조치의 경우 결과가 보조 연결을 기본 연결로 승격하는 것이라는 점에 유의해요. 장애 조치 후 SAML SSO는 새 기본 연결에서 작동해요.
기본 및 보조 연결 모두에 SAML SSO가 필요하면 두 Snowflake 계정에서 SAML2 보안 통합을 독립적으로 만들고 관리해요.
이 절차에서는 다음을 가정해요.
- 소스 계정: https://example-northamericawest.snowflakecomputing.com/
- 타깃 계정: https://example-northamericaeast.snowflakecomputing.com/
- 연결 URL: https://example-global.snowflakecomputing.com
- 타깃 계정에 보조 연결이 존재하지 않음.
이 절차는 다음을 수행하는 대표적인 예시예요.
- SAML2 보안 통합을 소스 계정에서 타깃 계정으로 복제.
- 장애 조치 테스트.
- 소스 계정의 보조 연결을 기본 연결로 승격.
소스 계정 단계(IdP 단계 포함):
- 소스 계정이 이미 데이터베이스 장애 조치/복구 및 클라이언트 리디렉션 으로 구성되어 있으면 다음 단계로 건너뛰어요. 그렇지 않으면 ALTER CONNECTION 명령으로 장애 조치를 활성화해요.
ALTER CONNECTION global
ENABLE FAILOVER TO ACCOUNTS example.northamericaeast;
- 아이덴티티 프로바이더의 대표 예로 Okta를 사용해, 연결 URL을 지정하는 Okta의 Snowflake 애플리케이션 을 만들어요. Okta 필드를 다음과 같이 업데이트해요.
- Label : Snowflake
- Subdomain : example-global
- Browser plugin auto-submit : 사용자가 로그인 페이지에 도달할 때 자동 로그인을 활성화하려면 체크박스를 선택해요.
- 소스 계정에서 saml2_snowflake_issuer_url 및 saml2_snowflake_acs_url 보안 통합 속성에 연결 URL을 지정하도록 SAML2 보안 통합을 업데이트해요.
CREATE OR REPLACE SECURITY INTEGRATION my_idp
TYPE = saml2
ENABLED = true
SAML2_ISSUER = 'http://www.okta.com/exk6e8mmrgJPj68PH4x7'
SAML2_SSO_URL = 'https://example.okta.com/app/snowflake/exk6e8mmrgJPj68PH4x7/sso/saml'
SAML2_PROVIDER = 'OKTA'
SAML2_X509_CERT = 'MIIDp...'
SAML2_SP_INITIATED_LOGIN_PAGE_LABEL = 'OKTA'
SAML2_ENABLE_SP_INITIATED = true
SAML2_SNOWFLAKE_ISSUER_URL = 'https://example-global.snowflakecomputing.com'
SAML2_SNOWFLAKE_ACS_URL = 'https://example-global.snowflakecomputing.com/fed/login';
- Okta에서 Snowflake 애플리케이션을 사용자에게 할당해요. 자세한 내용은 사용자에게 앱 통합 할당 을 참고해요.
- Okta의 Snowflake 애플리케이션에 지정된 사용자와 소스 계정의 사용자에 대해 소스 계정으로의 SSO가 작동하는지 확인해요. SSO는 IdP 시작 및 Snowflake 시작 SSO 흐름 모두에서 작동해야 한다는 점에 유의해요. 자세한 내용은 지원되는 SSO 워크플로우 를 참고해요.
- 소스 계정에서 장애 조치 그룹이 아직 없으면 보안 통합을 포함하는 장애 조치 그룹을 만들어요. 이 예제는 대표적이며 복제에 필요하거나 필요하지 않을 수 있는 다른 계정 객체를 포함한다는 점에 유의해요. 장애 조치 그룹이 이미 있으면 통합을 포함하도록 변경 해요.
CREATE FAILOVER GROUP FG
OBJECT_TYPES = users, roles, warehouses, resource monitors, integrations
ALLOWED_INTEGRATION_TYPES = security integrations
ALLOWED_ACCOUNTS = example.northamericaeast
REPLICATION_SCHEDULE = '10 MINUTE';
타깃 계정 단계:
- 복제 전에 SHOW USERS 및 SHOW INTEGRATIONS 명령을 각각 실행해 타깃 계정에 존재하는 사용자와 보안 통합의 수를 확인해요.
- 보조 연결을 만들어요. 자세한 내용은 CREATE CONNECTION 을 참고해요.
CREATE CONNECTION global AS REPLICA OF example.northamericawest.global;
- 타깃 계정에 보조 장애 조치 그룹을 만들어요. 자세한 내용은 CREATE FAILOVER GROUP 을 참고해요.
CREATE FAILOVER GROUP fg
AS REPLICA OF example.northamericawest.fg;
- 보조 장애 조치 그룹을 만들면 초기 새로고침이 자동으로 실행돼요. 타깃 계정에서 보조 장애 조치 그룹을 수동으로 새로고침하려면 다음 문을 실행해요. 자세한 내용은 ALTER FAILOVER GROUP 명령을 참고해요.
ALTER FAILOVER GROUP fg REFRESH;
- 새로고침 작업이 성공하면 타깃 계정에 소스 계정에 추가된 새 사용자와 이전에 타깃 계정에 없었던 사용자가 포함되어야 해요. 마찬가지로 타깃 계정에는 연결 URL을 지정하는 SAML2 보안 통합이 포함되어야 해요. 다음 명령을 실행해 새로고침 작업이 성공했는지 확인해요.
- SHOW INTEGRATIONS(새 통합 1개가 포함되어야 함)
- SHOW USERS(추가된 새 사용자 수가 포함되어야 함)
- DESCRIBE INTEGRATION(통합 my_idp에 대해)
- 타깃 계정의 보조 연결을 기본 연결로 승격해요. 다음 명령을 실행한 후 사용자는 SAML SSO를 사용해 새 타깃 계정에 인증할 수 있어요.
ALTER CONNECTION global PRIMARY;
OIDC 보안 통합 복제
Snowflake는 SAML2 및 OAuth 보안 통합과 동일한 접근 방식으로 복제 및 장애 조치 그룹을 사용해 OIDC 보안 통합을 소스 계정에서 타깃 계정으로 복제하는 것을 지원해요. 장애 조치 그룹에 integrations 를 포함하고 ALLOWED_INTEGRATION_TYPES = security integrations 를 지정해요. 장애 조치 그룹 설정 단계는 이 토픽의 SAML2 보안 통합 복제 를 참고해요.
OIDC 통합이 타깃 계정으로 복제되면 OIDC_CLIENT_SECRET(휴지 상태에서 암호화됨)을 포함한 통합 속성이 함께 복제돼요.
사용자 지정 프로바이더(OIDC_PROVIDER='CUSTOM')의 경우 OIDC_REDIRECT_URIS 가 계정별로 생성돼요. 통합이 타깃 계정으로 복제된 후 해당 계정의 리디렉션 URI를 IdP에 등록해요. 타깃 계정에서 DESC INTEGRATION 을 실행해 정확한 값을 얻어요.
관리형 프로바이더(OIDC_PROVIDER='GOOGLE' 또는 OIDC_PROVIDER='MICROSOFT')의 경우 Snowflake가 OAuth 클라이언트 구성을 관리해요. Google에 계정별 리디렉션 URI를 등록하지 않아요.
클라이언트 리디렉션: OIDC_PROVIDER='CUSTOM'을 사용하는 OIDC 통합은 Client Redirect를 인식하지 않아요. IdP에 등록된 OIDC_REDIRECT_URIS 는 통합이 생성된 계정에 바인딩돼요. Client Redirect를 통해 보조 계정으로 장애 조치하면 보조 계정의 리디렉션 URI를 IdP에 별도로 등록해야 해요(또는 계정과 무관한 관리형 프로바이더를 사용). SAML2 통합의 경우 기본 및 보조 ACS URL이 모두 SAML2_SNOWFLAKE_OTHER_ACS_URLS 로 광고되지만, OIDC에는 현재 동등한 기능이 없어요.
이 절차에서는 다음을 가정해요.
- 소스 계정: https://example-northamericawest.snowflakecomputing.com/
- 타깃 계정: https://example-northamericaeast.snowflakecomputing.com/
- 타깃 계정에 보조 연결이 존재함(즉 새로고침 작업만 필요함).
- OIDC 보안 통합이 소스 계정에 이미 존재함.
이 절차는 다음을 수행하는 대표적인 예시예요.
- OIDC 보안 통합 복제.
- 장애 조치 그룹 새로고침.
- 타깃 계정에 대한 IdP 리디렉션 URI 업데이트(사용자 지정 프로바이더만 해당).
- 타깃 계정의 보조 연결을 기본 연결로 승격.
소스 계정 단계:
- 장애 조치 그룹이 이미 security integrations 를 지정하면 다음 단계로 건너뛰어요. 이는 이 토픽에서 SAML SSO 또는 SCIM 용으로 이미 장애 조치 그룹을 구성했다면 해당돼요. 그렇지 않으면 ALTER FAILOVER GROUP 명령으로 기존 장애 조치 그룹을 수정해 security integrations 를 지정해요.
ALTER FAILOVER GROUP fg SET
OBJECT_TYPES = users, roles, warehouses, resource monitors, integrations
ALLOWED_INTEGRATION_TYPES = security integrations;
타깃 계정 단계:
- 보조 장애 조치 그룹을 새로고침해 타깃 계정에 OIDC 보안 통합을 포함하도록 업데이트해요.
ALTER FAILOVER GROUP fg REFRESH;
- 사용자 지정 프로바이더의 경우 타깃 계정의 복제된 통합에 대해 DESC INTEGRATION 을 실행하고 OIDC_REDIRECT_URIS 값을 IdP에 등록해요.
- 타깃 계정의 사용자에 대해 OIDC SSO가 작동하는지 확인해요.
- 선택적으로, 타깃 계정의 보조 장애 조치 그룹과 보조 연결을 기본으로 승격해요.
- 장애 조치 그룹:
ALTER FAILOVER GROUP fg PRIMARY; - 연결:
ALTER CONNECTION global PRIMARY;
- 장애 조치 그룹:
- 이전 단계를 완료했고 사용자 지정 프로바이더를 사용한다면 장애 조치 후 타깃 계정에서 OIDC SSO를 다시 확인해요.
SCIM 보안 통합 복제
SCIM 보안 통합을 복제하면 타깃 계정이 소스 계정에서 이루어진 SCIM 업데이트(예: 새 사용자 추가, 새 역할 추가)를 타깃 계정 새로고침 후 반영할 수 있게 돼요.
SCIM 보안 통합을 복제한 후에는 두 Snowflake 계정 모두 아이덴티티 프로바이더로부터 SCIM 업데이트를 받을 수 있는 능력을 갖게 돼요. 그러나 Snowflake는 하나의 계정만 기본(primary)(즉 소스) 계정으로 지정할 수 있으며, 아이덴티티 프로바이더로부터 SCIM 업데이트를 받는 것은 기본 계정이에요.
SCIM 통합을 복제한 후 SCIM 업데이트를 받을 다른 계정을 기본 계정으로 선택적으로 지정할 수 있어요. 타깃 계정은 새로고침 후에만 소스 계정으로부터 SCIM 업데이트를 받을 수 있다는 점에 유의해요.
이 절차에서는 다음을 가정해요.
- 소스 계정: https://example-northamericawest.snowflakecomputing.com/
- 타깃 계정: https://example-northamericaeast.snowflakecomputing.com/
- 연결 URL: https://example-global.snowflakecomputing.com
- 타깃 계정에 보조 연결이 존재함(즉 새로고침 작업만 필요함).
- 아이덴티티 프로바이더가 SCIM 프로비저닝 기본 URL로 연결 URL(https://example-global.snowflakecomputing.com)을 사용하도록 구성됨(소스 계정 URL을 직접 사용하지 않음). 장애 조치 후 연결을 새 기본 계정으로 승격하면 아이덴티티 프로바이더를 재구성할 필요 없이 프로비저닝 요청이 다시 라우팅돼요.
인증 자격 증명: 원래 기본 계정에서 발급된 자격 증명(SCIM 접근 토큰, 프로그래밍 방식 접근 토큰(PAT))은 장애 조치 후에도 새 기본 계정에서 계속 작동해요. 자격 증명을 다시 생성하거나 아이덴티티 프로바이더 구성을 업데이트할 필요가 없어요.
이 절차는 다음을 수행하는 대표적인 예시예요.
- SCIM 보안 통합을 소스 계정에서 타깃 계정으로 복제.
- Okta에서 새 사용자 추가, 새 사용자를 소스 계정으로 푸시, 새 사용자를 타깃 계정으로 복제.
- 장애 조치 그룹 새로고침.
- 타깃 계정의 보조 연결을 기본 연결로 승격.
소스 계정 단계:
- SHOW CONNECTIONS 를 실행해 소스 계정의 연결이 기본 연결인지 확인해요. 기본 연결이 아니면 ALTER CONNECTION 명령으로 소스 계정의 연결을 기본 연결로 승격해요.
- Okta SCIM 보안 통합이 소스 계정에 이미 구성되어 있으면 다음 단계로 건너뛰어요. 그렇지 않으면 소스 계정에서 Okta SCIM 보안 통합을 구성해요.
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');
Snowflake용 Okta SCIM 애플리케이션을 업데이트해야 합니다. 자세한 내용은 Okta 구성 을 참고해요.
- Okta에서 Snowflake용 Okta 애플리케이션에 새 사용자를 만들어요. Snowflake에서 SHOW USERS 명령을 실행해 사용자가 Snowflake로 푸시되는지 확인해요.
- 장애 조치 그룹은 SCIM 보안 통합이 복제되도록 ALLOWED_INTEGRATION_TYPES = security integrations 를 포함해야 해요. 장애 조치 그룹이 이미 security integrations 를 지정하면(예: SAML SSO 용으로 이미 구성했다면) 다음 단계로 건너뛰어요. 그렇지 않으면 ALTER FAILOVER GROUP 명령으로 기존 장애 조치 그룹을 수정해 security integrations 를 지정해요.
ALTER FAILOVER GROUP fg SET
OBJECT_TYPES = users, roles, warehouses, resource monitors, integrations
ALLOWED_INTEGRATION_TYPES = security integrations;
- 이 시점에서 소스 계정의 새 사용자가 타깃 계정에 있는지 확인하기 위해 (이 토픽의) SCIM에 대한 타깃 계정 단계 에 표시된 대로 보조 장애 조치 그룹을 선택적으로 새로고침할 수 있어요. 지금 보조 장애 조치 그룹을 새로고침하면 이 순서로 새 사용자를 추가하는 소스 계정의 변경이 타깃 계정에 표시되는지 쉽게 확인할 수 있어요. 다만 아이덴티티 프로바이더에서 다른 사용자 수정이나 역할 할당 업데이트와 같은 추가 작업이 필요하다면 지금 그 작업을 계속한 다음 나중에 한 번에 보조 장애 조치 그룹을 새로고침할 수 있어요.
타깃 계정 단계:
- 복제 전에 SHOW USERS 및 SHOW INTEGRATIONS 명령을 각각 실행해 타깃 계정에 존재하는 사용자와 보안 통합의 수를 확인해요.
- 보조 장애 조치 그룹을 새로고침해 타깃 계정에 새 사용자(및 Okta와 소스 계정에서 이루어진 다른 변경)를 포함하도록 업데이트해요.
ALTER FAILOVER GROUP fg REFRESH;
- SHOW USERS 명령을 실행해 새 사용자가 타깃 계정에 추가되었는지 확인해요.
- 선택적으로, 타깃 계정에서 보조 장애 조치 그룹을 기본으로 승격해요. 이렇게 하면 타깃 계정이 새 소스 계정으로 승격돼요.
ALTER FAILOVER GROUP fg PRIMARY;
- 이전 단계를 완료했다면 타깃 계정에서 보조 연결을 기본으로 승격해요.
ALTER CONNECTION global PRIMARY;
- 4단계와 5단계를 완료했다면 원래 소스 계정에서 다음 ALTER FAILOVER GROUP 명령을 실행해 반대 방향으로 복제를 재개해요.
ALTER FAILOVER GROUP fg RESUME;
OAuth 보안 통합 복제
OAuth 보안 통합 복제에는 Snowflake OAuth 보안 통합과 External OAuth 보안 통합이 모두 포함돼요.
다음을 유의해요.
Snowflake OAuth: 복제 및 장애 조치/복구 구성 후 OAuth 클라이언트를 통해 소스 계정이나 타깃 계정에 연결하는 사용자는 타깃 계정에 다시 인증할 필요가 없어요.
External OAuth: 복제 및 장애 조치/복구 구성 후 OAuth 클라이언트를 통해 소스 계정이나 타깃 계정에 연결하는 사용자는 타깃 계정에 다시 인증해야 할 수도 있어요.
OAuth 인증 서버가 갱신 토큰(refresh token)을 발급하도록 구성되어 있지 않으면 재인증이 필요할 가능성이 높아요. 따라서 OAuth 클라이언트가 소스 및 타깃 Snowflake 계정에 연결할 수 있도록 OAuth 인증 서버가 갱신 토큰을 발급하는지 확인해요.
이 절차에서는 다음을 가정해요.
- 소스 계정: https://example-northamericawest.snowflakecomputing.com/
- 타깃 계정: https://example-northamericaeast.snowflakecomputing.com/
- 연결 URL: https://example-global.snowflakecomputing.com
- 타깃 계정에 보조 연결이 존재함(즉 새로고침 작업만 필요함).
- Snowflake OAuth 또는 External OAuth 보안 통합이 소스 계정에 이미 존재함.
이 절차는 다음을 수행하는 대표적인 예시예요.
- OAuth 보안 통합 복제.
- 장애 조치 그룹 새로고침.
- 타깃 계정의 보조 연결을 기본 연결로 승격.
소스 계정 단계:
- 장애 조치 그룹이 이미 security integrations 를 지정하면 다음 단계로 건너뛰어요. 이는 이 토픽에서 타깃 계정의 SAML SSO 또는 SCIM 목적으로 이미 장애 조치 그룹을 구성했다면 해당돼요. 그렇지 않으면 ALTER FAILOVER GROUP 명령으로 기존 장애 조치 그룹을 수정해 security integrations 를 지정해요.
ALTER FAILOVER GROUP fg SET
OBJECT_TYPES = users, roles, warehouses, resource monitors, integrations
ALLOWED_INTEGRATION_TYPES = security integrations;
타깃 계정 단계:
- 보조 장애 조치 그룹을 새로고침해 타깃 계정에 OAuth 보안 통합 객체를 포함하도록 업데이트해요.
ALTER FAILOVER GROUP fg REFRESH;
- 선택한 OAuth 클라이언트를 사용해 각 Snowflake 계정에 연결할 수 있는지 확인해요.
- 선택적으로, 타깃 계정의 보조 장애 조치 그룹과 보조 연결을 기본으로 승격해요. 이렇게 하면 타깃 계정이 새 소스 계정으로 승격돼요.
- 장애 조치 그룹:
ALTER FAILOVER GROUP fg PRIMARY; - 연결:
ALTER CONNECTION global PRIMARY;
- 장애 조치 그룹:
- 이전 단계를 완료했다면 선택한 OAuth 클라이언트를 사용해 각 Snowflake 계정에 연결할 수 있는지 다시 확인해요.
네트워크 정책 복제
네트워크 정책을 소스 계정에서 타깃 계정으로 복제하면 관리자가 수신 요청의 발생지 네트워크 식별자에 따라 타깃 계정에 대한 접근을 제한할 수 있어요.
네트워크 정책 참조 및 할당 복제
네트워크 정책을 복제하면 네트워크 정책 객체 와 네트워크 정책 참조/할당이 복제돼요. 예를 들어 네트워크 정책이 소스 계정의 네트워크 규칙을 참조하고 두 객체가 모두 타깃 계정에 존재하면 네트워크 정책은 타깃 계정에서 동일한 네트워크 규칙을 사용해요. 마찬가지로 네트워크 정책이 사용자에게 할당되고 사용자가 소스 및 타깃 계정 모두에 존재하면 네트워크 정책을 복제하면 네트워크 정책이 타깃 계정의 사용자에게 할당돼요.
네트워크 정책 참조 및 할당을 복제한다는 것은 참조된 객체와 네트워크 정책이 할당된 객체도 복제된다고 가정해요. 지원 객체 유형을 제대로 복제하지 않으면 Snowflake는 타깃 계정에서 새로고침 작업을 실패시켜요.
참조된 객체나 네트워크 정책이 할당된 객체가 타깃 계정에 아직 존재하지 않으면 그 객체 유형을 네트워크 정책과 같은 복제/장애 조치 그룹에 포함해요. 다음 예제는 지원 객체가 타깃 계정에 아직 존재하지 않는 경우 필요한 설정을 보여줘요.
네트워크 규칙을 사용하는 네트워크 정책 — 복제/장애 조치 그룹에는 network policies 와 databases 가 포함되어야 해요. 네트워크 규칙은 스키마 수준 객체이며 포함된 데이터 베이스와 함께 복제돼요. 예:
CREATE FAILOVER GROUP fg
OBJECT_TYPES = network policies, databases
ALLOWED_DATABASES = testdb2
ALLOWED_ACCOUNTS = myorg.myaccount2;
계정에 할당된 네트워크 정책 — 복제/장애 조치 그룹에는 network policies 와 account parameters 가 포함되어야 해요. 네트워크 정책이 네트워크 규칙을 사용하면 databases 도 포함해야 해요. 예:
CREATE FAILOVER GROUP fg
OBJECT_TYPES = network policies, account parameters, databases
ALLOWED_DATABASES = testdb2
ALLOWED_ACCOUNTS = myorg.myaccount2;
사용자에 할당된 네트워크 정책 — 복제/장애 조치 그룹에는 network policies 와 users 가 포함되어야 해요. 네트워크 정책이 네트워크 규칙을 사용하면 databases 도 포함해야 해요. 예:
CREATE FAILOVER GROUP fg
OBJECT_TYPES = network policies, users, databases
ALLOWED_DATABASES = testdb2
ALLOWED_ACCOUNTS = myorg.myaccount2;
보안 통합에 할당된 네트워크 정책 — 네트워크 정책 복제는 복제/장애 조치 그룹에 integrations , security integrations , network policies 가 포함되어 있는 경우 Snowflake OAuth 및 SCIM 보안 통합 에 지정된 네트워크 정책에 적용돼요. 네트워크 정책이 네트워크 규칙을 사용하면 databases 도 포함해야 해요.
CREATE FAILOVER GROUP fg OBJECT_TYPES = network policies, integrations, databases ALLOWED_DATABASES = testdb2 ALLOWED_INTEGRATION_TYPES = security integrations ALLOWED_ACCOUNTS = myorg.myaccount2;
예제
이 예제에서는 다음을 가정해요.
- 소스 계정: https://example-northamericawest.snowflakecomputing.com/
- 타깃 계정: https://example-northamericaeast.snowflakecomputing.com/
- 연결 URL: https://example-global.snowflakecomputing.com
- 타깃 계정에 보조 연결이 존재함(즉 새로고침 작업만 필요함).
- 네트워크 정책이 소스 계정에 존재함.
- Snowflake OAuth 및/또는 SCIM 보안 통합이 소스 계정에 이미 존재하고 통합이 네트워크 정책을 지정함.
이 절차 예제는 다음을 수행해요.
- 네트워크 트래픽을 제한하는 데 사용하는 네트워크 규칙과 함께 네트워크 정책을 복제.
- 네트워크 정책이 할당된 보안 통합을 복제.
- 장애 조치 그룹 새로고침.
- 네트워크 정책 활성화 확인.
- 소스 계정의 보조 연결을 기본 연결로 승격.
소스 계정 단계:
- SHOW NETWORK POLICIES 명령을 실행해 네트워크 정책이 소스 Snowflake 계정에 존재하는지 확인해요.
- SHOW INTEGRATIONS 명령을 실행해 보안 통합을 식별한 다음 Snowflake OAuth 보안 통합에 대해 DESCRIBE INTEGRATION 명령을 실행해 Snowflake OAuth 및/또는 SCIM 보안 통합이 네트워크 정책을 포함하는지 확인해요.
- ALTER FAILOVER GROUP 명령으로 네트워크 정책과 계정 파라미터를 포함하도록 장애 조치 그룹을 업데이트해요.
ALTER FAILOVER GROUP fg SET
OBJECT_TYPES = users, roles, warehouses, resource monitors, integrations, network policies, account parameters
ALLOWED_INTEGRATION_TYPES = security integrations;
타깃 계정 단계:
- 네트워크 정책 객체와 네트워크 정책을 지정하는 Snowflake OAuth 보안 통합을 포함하도록 보조 장애 조치 그룹을 새로고침해요.
ALTER FAILOVER GROUP fg REFRESH;
- SHOW NETWORK POLICIES 명령을 실행해 네트워크 정책 객체가 존재하는지 확인하고, 보안 통합에 대해 DESCRIBE SECURITY INTEGRATION 명령을 실행해 Snowflake OAuth 보안 통합이 복제된 네트워크 정책을 지정하는지 확인해요.
- 활성화된 네트워크 정책 식별 에 표시된 대로 네트워크 정책 활성화를 확인해요.
- 선택한 Snowflake OAuth 클라이언트를 사용해 각 Snowflake 계정에 연결할 수 있는지 확인해요.
- 선택적으로 타깃 계정의 보조 장애 조치 그룹과 보조 연결을 기본으로 승격해요. 이렇게 하면 타깃 계정이 새 소스 계정으로 승격돼요.
- 장애 조치 그룹:
ALTER FAILOVER GROUP fg PRIMARY; - 연결:
ALTER CONNECTION global PRIMARY;
- 장애 조치 그룹:
- 이전 단계를 완료했다면 선택한 Snowflake OAuth 클라이언트를 사용해 각 Snowflake 계정에 연결할 수 있는지 다시 확인해요.
ServiceNow용 Snowflake 커넥터의 통합 및 객체 복제
ServiceNow용 Snowflake 커넥터 를 사용하면 Snowflake가 ServiceNow에서 데이터를 수집(ingest)할 수 있어요. 커넥터에는 Snowflake 계정에 다음 객체가 필요해요.
- 시크릿(Secret).
- type = api_authentication 인 보안 통합.
- API 통합.
- 수집된 데이터를 저장할 데이터베이스.
- 커넥터가 사용할 웨어하우스.
- 이러한 객체에 대한 접근을 관리할 계정 역할.
커넥터를 설치하기 전에 이러한 객체를 만들고 타깃 계정으로 복제할 수 있어요. 이 객체들을 복제한 후 타깃 계정에 커넥터를 설치할 수 있어요. 설치는 Snowflake가 제공하는 공유에 의존하므로 커넥터를 타깃 계정에 설치해야 해요. 커넥터 설치 중에 공유에서 데이터베이스를 만들어야 하며, 공유에서 만든 데이터베이스는 복제할 수 없어요.
계정 객체의 복제를 관리하는 방법에 따라 복제/장애 조치 그룹을 한 개 이상 가질 수 있어요. 단일 복제 그룹은 객체의 복제 관리를 중앙화하고 일부 객체가 복제되고 다른 객체는 복제되지 않는 시나리오를 피해요. 그렇지 않으면 모든 객체가 타깃 계정으로 복제되도록 복제 작업을 신중하게 조정해야 해요.
예를 들어 데이터베이스용 복제 그룹을 만들 수 있어요. 이 복제 그룹(예: rg1)은 시크릿을 포함하는 데이터베이스와 ServiceNow 데이터를 저장할 데이터베이스를 지정해요. 다른 복제 그룹(예: rg2)은 사용자, 역할, 통합 객체와 사용자에 대한 이러한 역할의 권한 부여를 지정해요. 이 시나리오에서 통합을 먼저 복제한 다음 시크릿 데이터베이스, 사용자, 역할을 포함하도록 타깃 계정을 새로고침하기로 결정하면 복제 새로고침 작업이 성공해요.
그러나 통합을 복제하기 전에 시크릿을 포함하는 사용자와 역할 및 데이터베이스를 그룹에서 복제하면 보안 통합이 복제될 때까지 플레이스홀더 시크릿이 사용돼요. 플레이스홀더 시크릿은 댕글링 참조를 방지해요. 보안 통합이 복제되면 플레이스홀더 시크릿이 실제 시크릿으로 교체돼요.
이 절차는 다음을 수행하는 대표적인 예시예요.
- 시크릿과 수집된 데이터를 포함하는 통합 및 데이터베이스 복제.
- 장애 조치 그룹 새로고침.
- 소스 계정의 보조 연결을 기본 연결로 승격.
- 복제 후 커넥터 설치 및 사용.
이 절차에서는 다음을 가정해요.
- 소스 계정: https://example-northamericawest.snowflakecomputing.com/
- 타깃 계정: https://example-northamericaeast.snowflakecomputing.com/
- 연결 URL: https://example-global.snowflakecomputing.com
- 타깃 계정에 보조 연결이 존재함(즉 새로고침 작업만 필요함).
- 인증 및 접근 제한을 위한 네트워크 정책용 다른 보안 통합은 이미 복제됨.
소스 계정 단계:
- 각 객체 유형에 대해 SHOW 명령을 실행해 커넥터용 객체가 소스 Snowflake 계정에 존재하는지 확인해요.
show secrets in database secretsdb;
show security integrations;
show api integrations;
show tables in database destdb;
show warehouses;
show roles;
secretsdb 는 시크릿을 포함하는 데이터베이스의 이름이고 destdb 는 ServiceNow에서 수집된 데이터를 포함하는 데이터베이스의 이름이라는 점에 유의해요.
- ALTER FAILOVER GROUP 명령으로 API 통합과 시크릿 및 수집된 데이터를 포함하는 데이터베이스를 포함하도록 장애 조치 그룹을 업데이트해요.
ALTER FAILOVER GROUP fg SET
OBJECT_TYPES = databases, users, roles, warehouses, resource monitors, integrations, network policies, account parameters
ALLOWED_DATABASES = secretsdb, destdb
ALLOWED_INTEGRATION_TYPES = security integrations, api integrations;
타깃 계정 단계:
- 통합 및 데이터베이스를 타깃 계정으로 복제하도록 보조 장애 조치 그룹을 새로고침해요.
ALTER FAILOVER GROUP fg REFRESH;
- 다음 SHOW 명령을 사용해 복제된 객체가 존재하는지 확인해요.
show secrets;
show security integrations;
show api integrations;
show databases;
show tables in database destdb;
show roles;
- 선택한 방법(예: Snowflake CLI, 브라우저, SnowSQL)으로 각 Snowflake 계정에 연결할 수 있는지 확인해요.
- 선택적으로 타깃 계정의 보조 장애 조치 그룹과 보조 연결을 기본으로 승격해요. 이렇게 하면 타깃 계정이 새 소스 계정으로 승격돼요.
- 장애 조치 그룹:
ALTER FAILOVER GROUP fg PRIMARY; - 연결:
ALTER CONNECTION global PRIMARY;
- 장애 조치 그룹:
- 이전 단계를 완료했다면 각 Snowflake 계정에 연결할 수 있는지 다시 확인해요. 이 시점에서 타깃 계정에는 복제된 객체가 포함되고 사용자는 로그인할 수 있어요. 그러나 커넥터를 사용하려면 타깃 계정에서 추가 단계가 있어요.
- Snowflake 계정을 호스팅하는 클라우드 플랫폼에서 API 통합과 연결된 원격 서비스를 업데이트해요. 자세한 내용은 API 통합에 대한 원격 서비스 업데이트 를 참고해요.
- 커넥터를 수동으로 또는 Snowsight로 설치해요. 자세한 내용은 다음을 참고해요.
- 커넥터를 수동으로 설치
- Snowsight로 커넥터 설치
- Snowflake에서 ServiceNow 데이터 접근 을 참고해요.
더 알아보기 (Learn more)
- 여러 계정 간 복제와 장애 조치 소개 — 복제 개념과 복제된 객체
- 복제 고려 사항 — 복제된 객체의 동작과 제약
- 여러 계정 간 데이터베이스 및 계정 객체 복제 — 복제 구성 워크플로우
- 스테이지, 파이프, 로드 이력 복제 — 데이터 파이프라인 객체 복제