Replicação de integrações de segurança e políticas de redes em múltiplas contas¶

Visão geral¶

O Snowflake oferece suporte à replicação de políticas de rede e integrações de segurança para SSO federado (isto é, SAML2), OAuth e SCIM, além de habilitar o failover/failback para cada integração e política de redes.

A abordagem geral para testar replicação e failover/failback com cada política de redes e integração de segurança é a seguinte:

1. Identificar a conta de origem e a conta de destino para replicação, bem como identificar a URL de conexão.

2. Concluir as etapas na conta de origem.

3. Concluir as etapas na conta de destino.

4. Testar o failover/failback.

Observe que, como as políticas de redes e as integrações de segurança têm casos de uso diferentes, as etapas exatos para a conta de origem e a conta de destino com relação a cada objeto podem ter algumas diferenças.

Para obter mais detalhes, consulte:

• Replicação de integrações de segurança SAML2

• Replicação de integrações de segurança SCIM

• Replicação de integrações de segurança OAuth

• Replicação de políticas de redes

• Replicação de integrações e objetos do Conector Snowflake para ServiceNow

Replicação de integrações de segurança SAML2¶

A replicação de uma integração de segurança SAML2 vincula a conta de origem e a conta de destino ao provedor de identidade, especificando a URL de conexão na definição de integração de segurança SAML2.

É importante atualizar o provedor de identidade para especificar a URL de conexão e é importante que os usuários existam na conta de origem. Sem essas atualizações, a verificação do usuário não ocorre, o que resultará na incapacidade do usuário de acessar a conta de destino.

Limitações atuais

Para SSO de SAML para o Snowflake, só há suporte para replicar uma integração de segurança SAML2 que especifica a URL de conexão na conexão primária atual, e não há suporte na conexão secundária. Observe que, para failover, o resultado promove uma conexão secundária para servir como conexão primária. Após o failover, o SSO de SAML trabalha na nova conexão primária.

Se o SSO de SAML for necessário tanto para conexões primárias quanto secundárias, então crie e gerencie integrações de segurança SAML2 independentemente em ambas as contas Snowflake.

Para esse procedimento, considere o seguinte:

• Conta de origem: https://example-northamericawest.snowflakecomputing.com/

• Conta de destino: https://example-northamericaeast.snowflakecomputing.com/

• URL de conexão: https://example-global.snowflakecomputing.com

• Não existe uma conexão secundária na conta de destino.

Este procedimento é um exemplo representativo para fazer o seguinte:

• Replicar uma integração de segurança SAML2 da conta de origem para a conta de destino.

• Testar o failover.

• Promover a conexão secundária na conta de origem para servir como conexão primária.

Etapas da conta de origem (inclui etapas de IdP):

1. Se a conta de origem já estiver configurada para Failover/failback do banco de dados e redirecionamento do cliente, pule para a próxima etapa.

   Caso contrário, habilite o failover usando um comando ALTER CONNECTION:

   alter connection global
   enable failover to accounts example.northamericaeast;
   

   Copy

2. Usando Okta como exemplo representativo do provedor de identidade, crie um Aplicativo Snowflake no Okta que especifique a URL de conexão. Atualize os campos Okta da seguinte forma:

   • Label: Snowflake

   • Subdomain: example-global

   • Browser plugin auto-submit: marque a caixa para ativar o login automático quando um usuário chega à página de login.

3. Na conta de origem, atualizar a integração de segurança SAML2 para especificar a URL de conexão para as propriedades de integração de segurança saml2_snowflake_issuer_url e saml2_snowflake_acs_url.

   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';
   

   Copy

4. No Okta, atribua o aplicativo Snowflake aos usuários. Para obter mais detalhes, consulte Atribuir uma integração de aplicativo a um usuário.

5. Verifique se o SSO para a conta de origem funciona para usuários especificados no aplicativo Snowflake no Okta e usuários na conta de origem.

   Note que o SSO deve funcionar tanto para os fluxos SSO iniciados por IdP e iniciados pelo Snowflake. Para obter mais detalhes, consulte Fluxos de trabalho SSO suportados.

6. Na conta de origem, se ainda não existir um grupo de failover, crie um grupo de failover para incluir integrações de segurança. Observe que esse exemplo é representativo e inclui outros objetos de conta que podem ou não ser necessários para replicar.

   Se já existir um grupo de failover, altere o grupo de failover para incluir integrações.

   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';
   

   Copy

Etapas da conta de destino:

1. Antes da replicação, verifique o número de usuários e integrações de segurança presentes na conta de destino executando os comandos SHOW USERS e SHOW INTEGRATIONS, respectivamente.

2. Crie uma conexão secundária. Para obter mais detalhes, consulte CREATE CONNECTION.

   create connection GLOBAL as replica of example.northamericawest.global;
   

   Copy

3. Crie um grupo secundário de failover na conta de destino. Para obter mais detalhes, consulte CREATE FAILOVER GROUP.

   create failover group fg
   as replica of example.northamericawest.fg;
   

   Copy

4. Ao criar um grupo secundário de failover, uma atualização inicial é executada automaticamente.

   Para atualizar manualmente um grupo secundário de failover na conta de destino, execute a seguinte instrução. Para obter mais detalhes, consulte o comando ALTER FAILOVER GROUP.

   alter failover group fg refresh;
   

   Copy

5. Se a operação de atualização for bem-sucedida, a conta de destino deve incluir novos usuários que foram adicionados à conta de origem e não estavam anteriormente presentes na conta de destino. Da mesma forma, a conta de destino deve incluir a integração de segurança SAML2 que especifica a URL de conexão.

   Verifique se a operação de atualização foi bem-sucedida executando os seguintes comandos:

   • SHOW INTEGRATIONS (deve incluir 1 nova integração)

   • SHOW USERS (deve incluir o número de novos usuários adicionados)

   • DESCRIBE INTEGRATION (para a integração myidp)

6. Promova a conexão secundária na conta de destino para servir como conexão primária. Após executar o seguinte comando, os usuários podem usar o SSO de SAML para se autenticar na nova conta de destino.

   alter connection global primary;
   

   Copy

Replicação de integrações de segurança SCIM¶

A replicação de uma integração de segurança SCIM permite que a conta de destino incorpore atualizações SCIM que são feitas na conta de origem (por exemplo, adição de novos usuários, adição de novas funções) após a atualização da conta de destino.

Depois de replicar a integração de segurança SCIM, ambas as contas Snowflake têm a capacidade de receber atualizações SCIM do provedor de identidade. Entretanto, o Snowflake permite especificar apenas uma conta como primária (ou seja, de origem) e é a conta primária que recebe atualizações SCIM do provedor de identidade.

Opcionalmente, você pode designar uma conta diferente como a conta primária para receber atualizações SCIM após a replicação da integração SCIM. Observe que a conta de destino só pode receber atualizações SCIM da conta de origem depois de atualizar a conta de destino.

Para esse procedimento, considere o seguinte:

• Conta de origem: https://example-northamericawest.snowflakecomputing.com/

• Conta de destino: https://example-northamericaeast.snowflakecomputing.com/

• URL de conexão: https://example-global.snowflakecomputing.com

• Existe uma conexão secundária na conta de destino (ou seja, só são necessárias operações de atualização).

Este procedimento é um exemplo representativo para fazer o seguinte:

• Replique uma integração de segurança SCIM da conta de origem para a conta de destino.

• Adicione um novo usuário no Okta, mova o novo usuário para a conta de origem e replique o novo usuário para a conta de destino.

• Atualize o grupo de failover.

• Promova a conexão secundária na conta de destino para servir como conexão primária.

Etapas da conta de origem:

1. Execute SHOW CONNECTIONS para verificar se a conexão na conta de origem é a conexão primária. Se não for a conexão primária, use o comando ALTER CONNECTION para promover a conexão na conta de origem para servir como a conexão primária.

2. Se uma integração de segurança SCIM no Okta já estiver configurada na conta de origem, pule para a próxima etapa.

   Caso contrário, configure uma integração de segurança Okta SCIM na conta de origem.

   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

   Certifique-se de atualizar o aplicativo Okta SCIM para o Snowflake. Para obter mais detalhes, consulte Configuração do Okta.

3. No Okta, crie um novo usuário no aplicativo Okta para o Snowflake.

   Verifique se o usuário foi movido para Snowflake executando um comando SHOW USERS no Snowflake.

4. Se o grupo de failover já especificar security integrations, pule para a próxima etapa. Esse é o caso se você já tiver configurado o grupo de failover para as finalidades do SSO de SAML na conta de destino (neste tópico).

   Caso contrário, modifique o grupo de failover existente usando um comando ALTERFAILOVERGROUP para especificar security integrations.

   alter failover group fG set
     object_types = users, roles, warehouses, resource monitors, integrations
     allowed_integration_types = security integrations;
   

   Copy

5. Neste ponto, você pode opcionalmente atualizar o grupo secundário de failover como mostrado nas etapas da conta de destino para SCIM a fim de garantir que o novo usuário na conta de origem esteja na conta de destino.

   A escolha de atualizar o grupo secundário de failover agora permite uma verificação fácil para garantir que a alteração na conta de origem, acrescentando um novo usuário nessa sequência, seja visível na conta de destino.

   Entretanto, se você precisar ou preferir fazer o trabalho adicional no provedor de identidade, como modificar outros usuários ou atualizar atribuições de funções, você pode continuar a fazer esse trabalho agora e depois atualizar o grupo secundário de failover em uma operação posterior.

Etapas da conta de destino:

1. Antes da replicação, verifique o número de usuários e integrações de segurança presentes na conta de destino executando os comandos SHOW USERS e SHOW INTEGRATIONS, respectivamente.

2. Atualize o grupo secundário de failover para atualizar a conta de destino para incluir o novo usuário (e quaisquer outras alterações que foram feitas no Okta e na conta de origem).

   alter failover group fg refresh;
   

   Copy

3. Verifique se o novo usuário foi adicionado à conta de destino executando um comando SHOW USERS.

4. Opcionalmente, promova o grupo secundário de failover e a conexão secundária na conta de destino para primário. Isso promoverá a conta de destino para servir como a nova conta de origem.

   Grupo de failover:

   alter failover group fg primary;
   

   Copy

   Conexão:

   alter connection global primary;
   

   Copy

Replicação de integrações de segurança OAuth¶

A replicação das integrações de segurança OAuth inclui tanto as integrações de segurança Snowflake OAuth quanto as integrações de segurança OAuth externo.

Observe o seguinte:

Snowflake OAuth

Após a replicação e configuração do failover/failback, um usuário conectado à conta de origem ou à conta de destino por meio de um cliente OAuth não precisa se autenticar novamente na conta de destino.

OAuth externo

Após a replicação e configuração do failover/failback, um usuário conectado à conta de origem ou à conta de destino por meio de um cliente OAuth pode precisar se autenticar novamente na conta de destino.

A reautenticação provavelmente será necessária se o servidor de autorização OAuth não estiver configurado para emitir um token de atualização. Portanto, certifique-se de que o servidor de autorização OAuth emite tokens de atualização para que o cliente OAuth possa se conectar às contas Snowflake de origem e destino.

Para esse procedimento, considere o seguinte:

• Conta de origem: https://example-northamericawest.snowflakecomputing.com/

• Conta de destino: https://example-northamericaeast.snowflakecomputing.com/

• URL de conexão: https://example-global.snowflakecomputing.com

• Existe uma conexão secundária na conta de destino (ou seja, só são necessárias operações de atualização).

• As integrações de segurança Snowflake OAuth ou OAuth externo já existem na conta de origem.

Este procedimento é um exemplo representativo para fazer o seguinte:

• Replique uma integração de segurança OAuth.

• Atualize o grupo de failover.

• Promova a conexão secundária na conta de destino para servir como conexão primária.

Etapas da conta de origem:

1. Se o grupo de failover já especificar security integrations, pule para a próxima etapa. Esse é o caso se você já tiver configurado o grupo de failover para as finalidades do SSO de SAML na conta de destino (neste tópico) ou SCIM (também neste tópico).

   Caso contrário, modifique o grupo de failover existente usando um comando ALTERFAILOVERGROUP para especificar security integrations.

   alter failover group fG set
     object_types = users, roles, warehouses, resource monitors, integrations
     allowed_integration_types = security integrations;
   

   Copy

Etapas da conta de destino:

1. Atualize o grupo secundário de failover para atualizar a conta de destino para incluir os objetos de integração de segurança OAuth.

   alter failover group fg refresh;
   

   Copy

2. Verifique a conexão com cada conta Snowflake usando o cliente OAuth de sua escolha.

3. Opcionalmente, promova o grupo secundário de failover e a conexão secundária na conta de destino para primário. Isso promoverá a conta de destino para servir como a nova conta de origem.

   Grupo de failover:

   alter failover group fg primary;
   

   Copy

   Conexão:

   alter connection global primary;
   

   Copy

4. Se você concluiu a etapa anterior, verifique novamente se você consegue se conectar com cada conta Snowflake usando o cliente OAuth de sua escolha.

Replicação de políticas de redes¶

A replicação de uma política de redes da conta de origem para a conta de destino permite aos administradores restringir o acesso à conta de destino com base no identificador de rede da origem de uma solicitação recebida.

Replicação de integrações e objetos do Conector Snowflake para ServiceNow¶

O Conector Snowflake para ServiceNow permite que o Snowflake faça a ingestão de dados do ServiceNow. O conector exige os seguintes objetos em sua conta Snowflake:

• Segredo.

• Integração de segurança de type = api_authentication.

• Integração de API.

• Banco de dados para armazenar os dados ingeridos.

• Warehouse para o conector a ser utilizado.

• Funções de conta para gerenciar o acesso a esses objetos.

Você cria estes objetos antes de instalar o conector e pode replicar estes objetos para a conta de destino. Depois de replicar estes objetos, você pode instalar o conector na conta de destino. O conector deve ser instalado na conta de destino porque a instalação depende de um compartilhamento que o Snowflake fornece. Você precisa criar um banco de dados a partir do compartilhamento durante a instalação do conector e não pode replicar um banco de dados que seja criado a partir de um compartilhamento.

Dependendo de como você deseja gerenciar a replicação de objetos de conta, você pode ter um ou mais grupos de replicação ou failover. Um único grupo de replicação centraliza o gerenciamento da replicação dos objetos e evita cenários onde alguns objetos são replicados e outros não. Caso contrário, você deve coordenar cuidadosamente a operação de replicação para garantir que todos os objetos sejam replicados para a conta de destino.

Por exemplo, você pode ter um grupo de replicação para bancos de dados. Este grupo de replicação (por exemplo, rg1) especifica o banco de dados que contém o segredo e o banco de dados para armazenar os dados ServiceNow. O outro grupo de replicação (por exemplo, rg2) especifica o usuário, a função e os objetos de integração e as concessões dessas funções aos usuários. Neste cenário, se você replicar as integrações primeiro e depois decidir atualizar a conta de destino para incluir o banco de dados do segredo, usuários e funções, a operação de atualização da replicação será bem-sucedida.

No entanto, se você replicar os usuários e funções e o banco de dados que contém o segredo em um grupo antes de replicar a integração, um segredo de espaço reservado será usado até que a integração de segurança seja replicada; o segredo do espaço reservado evita uma referência pendente. Depois que a integração de segurança for replicada, o segredo do espaço reservado será substituído pelo segredo real.

Este procedimento é um exemplo representativo para fazer o seguinte:

• Replique as integrações e os bancos de dados que contêm o segredo e os dados ingeridos.

• Atualize o grupo de failover.

• Promover a conexão secundária na conta de origem para servir como conexão primária.

• Instale e use o conector após a replicação.

Para esse procedimento, considere o seguinte:

• Conta de origem: https://example-northamericawest.snowflakecomputing.com/

• Conta de destino: https://example-northamericaeast.snowflakecomputing.com/

• URL de conexão: https://example-global.snowflakecomputing.com

• Existe uma conexão secundária na conta de destino (ou seja, só são necessárias operações de atualização).

• Outras integrações de segurança para políticas de autenticação e rede para restringir o acesso já estão replicadas.

Etapas da conta de origem:

1. Verifique se os objetos para o conector existem na conta Snowflake de origem executando comandos SHOW em cada um desses tipos de objetos.

   show secrets in database secretsdb;
   show security integrations;
   show api integrations;
   show tables in database destdb;
   show warehouses;
   show roles;
   

   Copy

   Observe que secretsdb é o nome do banco de dados que contém o segredo e destdb é o nome do banco de dados que contém os dados ingeridos do ServiceNow.

2. Atualize o grupo de failover para incluir integrações de API e os bancos de dados contendo o segredo e os dados ingeridos usando um comando ALTER FAILOVER GROUP.

   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;
   

   Copy

Etapas da conta de destino:

1. Atualize o grupo secundário de failover para replicar as integrações e bancos de dados para a conta de destino.

   alter failover group fg refresh;
   

   Copy

2. Verifique a existência dos objetos replicados usando os seguintes comandos SHOW.

   show secrets;
   show security integrations;
   show api integrations;
   show database;
   show tables in database destdb;
   show roles;
   

   Copy

3. Verifique a conexão com cada conta Snowflake usando o método de sua escolha (por exemplo, navegador, SnowSQL).

4. Opcionalmente, promover o grupo secundário de failover e a conexão secundária na conta de destino para primário. Isso promoverá a conta de destino para servir como a nova conta de origem.

   Grupo de failover:

   alter failover group fg primary;
   

   Copy

   Conexão:

   alter connection global primary;
   

   Copy

5. Se você tiver concluído a etapa anterior, verifique novamente se você consegue se conectar com cada conta Snowflake.

   Neste ponto, a conta de destino contém os objetos replicados e os usuários podem fazer o login. No entanto, há etapas adicionais na conta de destino para usar o conector.

6. Atualize o serviço remoto associado com a integração de API na plataforma de nuvem que hospeda sua conta Snowflake.

   Para obter mais detalhes, consulte Atualização do serviço remoto para integrações de API.

7. Instale o conector manualmente ou com Snowsight. Para obter mais detalhes, consulte:

   • Instalação do conector manualmente

   • Instalação do conector com Snowsight

8. Acesso aos dados do ServiceNow no Snowflake.