Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes¶

Vue d’ensemble¶

Snowflake prend en charge la réplication des stratégies de politiques réseau et des intégrations de sécurité pour SSO (c’est-à-dire SAML2), OAuth et SCIM fédérés, ainsi que l’activation du basculement/de la restauration pour chaque politique réseau et intégration.

L’approche générale pour tester la réplication et le basculement/la restauration avec chaque politique réseau et intégration de sécurité est la suivante :

1. Identifiez le compte source et le compte cible pour la réplication, et identifiez l’URL de connexion.

2. Effectuez les étapes dans le compte source.

3. Effectuez les étapes dans le compte cible.

4. Tester le basculement/la restauration.

Notez qu’étant donné que les politiques réseau et les intégrations de sécurité ont des cas d’utilisation différents, les étapes exactes pour le compte source et le compte cible en ce qui concerne chaque objet diffèrent légèrement.

Pour plus de détails, voir :

• Réplication des intégrations de sécurité SAML2

• Réplication des intégrations de sécurité SCIM

• Réplication des intégrations de sécurité OAuth

• Réplication des politiques réseau

• Réplication des intégrations et objets pour le connecteur Snowflake pour ServiceNow

Réplication des intégrations de sécurité SAML2¶

La réplication d’une intégration de sécurité SAML2 lie le compte source et le compte cible au fournisseur d’identité en spécifiant la l’URL de connexion dans la définition de l’intégration de sécurité SAML2.

Il est important de mettre à jour le fournisseur d’identité pour spécifier l’URL de connexion et de préciser que les utilisateurs existent dans le compte source. Sans ces mises à jour, la vérification de l’utilisateur ne peut pas avoir lieu, ce qui aura pour conséquence l’impossibilité pour l’utilisateur d’accéder au compte cible.

Limites actuelles

Pour le SSO SAML vers Snowflake, la réplication d’une intégration de sécurité SAML2 qui spécifie l’URL de connexion n’est prise en charge que sur la connexion principale actuelle et non sur la connexion secondaire. Notez que pour le basculement, le résultat est la promotion d’une connexion secondaire pour servir de connexion principale Après le basculement, le SSO SAML fonctionne sur la nouvelle connexion principale.

Si le SSO SAML est nécessaire pour les connexions principales et secondaires, créez et gérez les intégrations de sécurité SAML2 indépendamment sur les deux comptes Snowflake.

Pour cette procédure, supposez ce qui suit :

• Compte source : https://example-northamericawest.snowflakecomputing.com/

• Compte cible : https://example-northamericaeast.snowflakecomputing.com/

• URL de connexion : https://example-global.snowflakecomputing.com

• Une connexion secondaire n’existe pas dans le compte cible.

Cette procédure est un exemple représentatif de ce qu’il faut faire :

• Répliquez une intégration de sécurité SAML2 du compte source au compte cible.

• Testez le basculement.

• Promouvez la connexion secondaire dans le compte source pour en tant que connexion principale.

Étapes du compte source (inclut les étapes IdP) :

1. Si le compte source est déjà configuré pour le basculement/la restauration de la base de données et la redirection des clients, passez à l’étape suivante.

   Sinon, activez le basculement en utilisant une commande ALTER CONNECTION :

   alter connection global
   enable failover to accounts example.northamericaeast;
   

   Copy

2. En utilisant Okta comme exemple représentatif pour le fournisseur d’identité, créez une application Snowflake dans Okta qui spécifie l’URL de connexion. Mettez à jour les champs Okta comme suit :

   • Label : Snowflake

   • Subdomain : example-global

   • Browser plugin auto-submit : cochez la case pour activer la connexion automatique lorsqu’un utilisateur arrive sur la page de connexion.

3. Dans le compte source, mettez à jour l’intégration de sécurité SAML2 pour spécifier l’URL de connexion pour les propriétés d’intégration de sécurité saml2_snowflake_issuer_url et 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. Dans Okta, attribuez l’application Snowflake à des utilisateurs. Pour plus de détails, voir Attribuer une intégration d’application à un utilisateur.

5. Vérifiez que le SSO vers le compte source fonctionne pour les utilisateurs qui sont spécifiés dans l’application Snowflake dans Okta et les utilisateurs du compte source.

   Notez que le SSO devrait fonctionner à la fois pour les flux SSO initiés par IdP ceux initiés par Snowflake. Pour plus de détails, voir Workflows SSO pris en charge.

6. Dans le compte source, si un groupe de basculement n’existe pas encore, créez un groupe de basculement pour inclure les intégrations de sécurité. Notez que cet exemple est représentatif et inclut d’autres objets de compte qu’il peut être nécessaire ou non de répliquer.

   Si un groupe de basculement existe déjà, modifiez le groupe de basculement pour inclure les intégrations.

   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

Étapes du compte cible :

1. Avant la réplication, vérifiez le nombre d’utilisateurs et d’intégrations de sécurité présents dans le compte cible en exécutant les commandes SHOW USERS et SHOW INTEGRATIONS , respectivement.

2. Créez une connexion secondaire. Pour plus de détails, voir CREATE CONNECTION.

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

   Copy

3. Créez un groupe de basculement secondaire dans le compte cible. Pour plus de détails, voir CREATE FAILOVER GROUP.

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

   Copy

4. Lors de la création d’un groupe de basculement secondaire, une actualisation initiale est automatiquement exécutée.

   Pour actualiser manuellement un groupe de basculement secondaire dans le compte cible, exécutez l’instruction suivante. Pour plus de détails, voir la commande ALTER FAILOVER GROUP.

   alter failover group fg refresh;
   

   Copy

5. Si l’opération d’actualisation réussit, le compte cible devrait inclure les nouveaux utilisateurs qui ont été ajoutés au compte source et qui n’étaient pas présents auparavant dans le compte cible. De même, le compte cible doit inclure l’intégration de sécurité SAML2 qui spécifie l’URL de connexion.

   Vérifiez que la réussite de l’opération d’actualisation en exécutant les commandes suivantes :

   • SHOW INTEGRATIONS (devrait inclure une nouvelle intégration)

   • SHOW USERS (devrait inclure le nombre de nouveaux utilisateurs ajoutés)

   • DESCRIBE INTEGRATION (pour l’intégration myidp).

6. Promouvez la connexion secondaire dans le compte cible en tant que connexion principale. Après avoir exécuté la commande suivante, les utilisateurs peuvent utiliser SSO SAML pour s’authentifier sur le nouveau compte cible.

   alter connection global primary;
   

   Copy

Réplication des intégrations de sécurité SCIM¶

La réplication d’une intégration de sécurité SCIM permet au compte cible d’incorporer les mises à jour SCIM effectuées sur le compte source (par exemple, l’ajout de nouveaux utilisateurs, l’ajout de nouveaux rôles) après l’actualisation du compte cible.

Après avoir répliqué l’intégration de sécurité SCIM, les deux comptes Snowflake ont la possibilité de recevoir des mises à jour SCIM du fournisseur d’identité. Cependant, Snowflake ne permet de spécifier qu’un seul compte comme compte principal (c’est-à-dire source) et c’est le compte principal qui reçoit les mises à jour SCIM du fournisseur d’identité.

Vous pouvez éventuellement désigner un autre compte comme compte principal pour recevoir les mises à jour SCIM après avoir répliqué l’intégration SCIM. Notez que le compte cible peut recevoir des mises à jour SCIM du compte source seulement après avoir actualisé le compte cible.

Pour cette procédure, supposez ce qui suit :

• Compte source : https://example-northamericawest.snowflakecomputing.com/

• Compte cible : https://example-northamericaeast.snowflakecomputing.com/

• URL de connexion : https://example-global.snowflakecomputing.com

• Une connexion secondaire existe dans le compte cible (c’est-à-dire que seules des opérations d’actualisation sont nécessaires).

Cette procédure est un exemple représentatif de ce qu’il faut faire :

• Répliquez une intégration de sécurité SCIM du compte source au compte cible.

• Ajoutez un nouvel utilisateur dans Okta, poussez le nouvel utilisateur vers le compte source et répliquez le nouvel utilisateur vers le compte cible.

• Actualisez le groupe de basculement.

• Promouvez la connexion secondaire dans le compte cible en tant que connexion principale.

Étapes du compte source :

1. Exécutez SHOW CONNECTIONS pour vérifier que la connexion du compte source est la connexion principale. S’il ne s’agit pas de la connexion principale, utilisez la commande ALTER CONNECTION pour promouvoir la connexion dans le compte source afin qu’elle serve de connexion principale.

2. Si une intégration de sécurité SCIM Okta est déjà configurée dans le compte source, passez à l’étape suivante.

   Sinon, configurez une intégration de sécurité Okta SCIM dans le compte source.

   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

   Veillez à mettre à jour l’application Okta SCIM pour Snowflake. Pour plus de détails, voir Configuration Okta.

3. Dans Okta, créez un nouvel utilisateur dans l’application Okta pour Snowflake.

   Vérifiez que l’utilisateur est poussé vers Snowflake en exécutant une commande SHOW USERS dans Snowflake.

4. Si le groupe de basculement spécifie déjà security integrations, passez à l’étape suivante. Ce serait le cas si vous aviez déjà configuré le groupe de basculement pour les besoins du SAML SSO dans le compte cible (dans cette rubrique).

   Sinon, modifiez le groupe de basculement existant en utilisant une commande ALTER FAILOVER GROUP pour spécifier security integrations.

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

   Copy

5. À ce stade, vous pouvez éventuellement actualiser le groupe de basculement secondaire comme indiqué dans les étapes du compte cible pour SCIM afin de vous assurer que le nouvel utilisateur du compte source se trouve dans le compte cible.

   Le choix d’actualiser le groupe de basculement secondaire permet maintenant de vérifier facilement que la modification du compte source, l’ajout d’un nouvel utilisateur dans cette séquence, est visible dans le compte cible.

   Cependant, si vous devez ou préférez effectuer des tâches supplémentaires dans le fournisseur d’identité, telles que la modification d’autres utilisateurs ou la mise à jour d’affectations de rôles, vous pouvez continuer à effectuer ces tâches maintenant, puis actualiser le groupe de basculement secondaire en une seule opération ultérieurement.

Étapes du compte cible :

1. Avant la réplication, vérifiez le nombre d’utilisateurs et d’intégrations de sécurité présents dans le compte cible en exécutant les commandes SHOW USERS et SHOW INTEGRATIONS , respectivement.

2. Actualisez le groupe de basculement secondaire pour mettre à jour le compte cible afin d’inclure le nouvel utilisateur (et toute autre modification apportée dans Okta et le compte source).

   alter failover group fg refresh;
   

   Copy

3. Vérifier que le nouvel utilisateur est ajouté au compte cible en exécutant une commande SHOW USERS.

4. En option, promouvez le groupe de basculement secondaire et la connexion secondaire du compte cible en groupe principal et connexion principale. Cela va promouvoir le compte cible en tant que nouveau compte source.

   Groupe de basculement :

   alter failover group fg primary;
   

   Copy

   Connexion :

   alter connection global primary;
   

   Copy

Réplication des intégrations de sécurité OAuth¶

La réplication des intégrations de sécurité OAuth comprend les intégrations de sécurité OAuth Snowflake et les intégrations de sécurité External OAuth.

Remarques :

Snowflake OAuth

Après la réplication et la configuration du basculement/de la restauration, un utilisateur se connectant au compte source ou au compte cible via un client OAuth n’a pas besoin de se réauthentifier sur le compte cible.

OAuth externe

Après la réplication et la configuration du basculement/de la restauration, un utilisateur se connectant au compte source ou au compte cible via un client OAuth peut avoir besoin de s’authentifier à nouveau sur le compte cible.

Une ré-authentification sera probablement nécessaire si le serveur d’autorisation OAuth n’est pas configuré pour émettre un jeton d’actualisation. Par conséquent, assurez-vous que le serveur d’autorisation OAuth émet des jetons d’actualisation afin que le client OAuth puisse se connecter aux comptes Snowflake source et cible.

Pour cette procédure, supposez ce qui suit :

• Compte source : https://example-northamericawest.snowflakecomputing.com/

• Compte cible : https://example-northamericaeast.snowflakecomputing.com/

• URL de connexion : https://example-global.snowflakecomputing.com

• Une connexion secondaire existe dans le compte cible (c’est-à-dire que seules des opérations d’actualisation sont nécessaires).

• Les intégrations de sécurité Snowflake OAuth ou External OAuth existent déjà dans le compte source.

Cette procédure est un exemple représentatif de ce qu’il faut faire :

• Répliquez une intégration de sécurité OAuth.

• Actualisez le groupe de basculement.

• Promouvez la connexion secondaire dans le compte cible en tant que connexion principale.

Étapes du compte source :

1. Si le groupe de basculement spécifie déjà security integrations, passez à l’étape suivante. C’est le cas si vous avez déjà configuré le groupe de basculement pour les besoins du SSO SAML dans le compte cible (dans cette rubrique) ou SCIM (également dans cette rubrique).

   Sinon, modifiez le groupe de basculement existant en utilisant une commande ALTER FAILOVER GROUP pour spécifier security integrations.

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

   Copy

Étapes du compte cible :

1. Actualisez le groupe de basculement secondaire pour mettre à jour le compte cible afin d’inclure les objets d’intégration de sécurité OAuth.

   alter failover group fg refresh;
   

   Copy

2. Vérifiez la connexion à chaque compte Snowflake en utilisant le client OAuth de votre choix.

3. En option, promouvez le groupe de basculement secondaire et la connexion secondaire du compte cible en groupe principal et connexion principale. Cela va promouvoir le compte cible en tant que nouveau compte source.

   Groupe de basculement :

   alter failover group fg primary;
   

   Copy

   Connexion :

   alter connection global primary;
   

   Copy

4. Si vous avez terminé l’étape précédente, vérifiez que vous pouvez vous connecter à chaque compte Snowflake en utilisant le client OAuth de votre choix.

Réplication des politiques réseau¶

La réplication d’une politique réseau du compte source au compte cible permet aux administrateurs de restreindre l’accès au compte cible en fonction de l’adresse de l’identificateur de réseau de l’origine d’une demande entrante.

Réplication des intégrations et objets pour le connecteur Snowflake pour ServiceNow¶

Le connecteur Snowflake pour ServiceNow permet à Snowflake d’ingérer des données de ServiceNow. Le connecteur nécessite les objets suivants dans votre compte Snowflake :

• Secret.

• Intégration de sécurité de type = api_authentication

• Intégration API.

• Base de données pour stocker les données ingérées.

• Entrepôt pour le connecteur à utiliser.

• Rôles de compte pour gérer l’accès à ces objets.

Vous créez ces objets avant d’installer le connecteur et vous pouvez répliquer ces objets sur le compte cible. Après avoir répliqué ces objets, vous pouvez installer le connecteur dans le compte cible. Le connecteur doit être installé dans le compte cible, car l’installation dépend d’un partage fourni par Snowflake. Vous devez créer une base de données à partir du partage lors de l’installation du connecteur et vous ne pouvez pas répliquer une base de données créée à partir d’un partage.

Selon la façon dont vous souhaitez gérer la réplication des objets de compte, vous pouvez avoir un ou plusieurs groupes de réplication ou de basculement. Un seul groupe de réplication centralise la gestion de la réplication des objets et évite les scénarios où certains objets sont répliqués et d’autres ne le sont pas. Sinon, vous devez coordonner l’opération de réplication avec soin pour vous assurer que tous les objets sont répliqués sur le compte cible.

Par exemple, vous pouvez avoir un groupe de réplication pour les bases de données. Ce groupe de réplication (par exemple rg1) spécifie la base de données qui contient le secret et la base de données pour stocker les données ServiceNow. L’autre groupe de réplication (par exemple rg2) spécifie l’utilisateur, le rôle et les objets d’intégration et les attributions de ces rôles aux utilisateurs. Dans ce scénario, si vous répliquez d’abord les intégrations, puis décidez d’actualiser le compte cible pour inclure la base de données secrète, les utilisateurs et les rôles, l’opération d’actualisation de la réplication réussit.

Toutefois, si vous répliquez les utilisateurs, les rôles et la base de données contenant le secret dans un groupe avant de répliquer l’intégration, un secret de remplacement est utilisé jusqu’à ce que l’intégration de sécurité soit répliquée ; le secret de remplacement évite une référence pendante. Une fois que l’intégration de sécurité est répliquée, le secret de remplacement est remplacé par le vrai secret.

Cette procédure est un exemple représentatif de ce qu’il faut faire :

• Répliquez les intégrations et les bases de données contenant les données secrètes et ingérées.

• Actualisez le groupe de basculement.

• Promouvez la connexion secondaire dans le compte source pour en tant que connexion principale.

• Installez et utilisez le connecteur après la réplication.

Pour cette procédure, supposez ce qui suit :

• Compte source : https://example-northamericawest.snowflakecomputing.com/

• Compte cible : https://example-northamericaeast.snowflakecomputing.com/

• URL de connexion : https://example-global.snowflakecomputing.com

• Une connexion secondaire existe dans le compte cible (c’est-à-dire que seules des opérations d’actualisation sont nécessaires).

• D’autres intégrations de sécurité pour l’authentification et les politiques réseau pour restreindre l’accès sont déjà répliquées.

Étapes du compte source :

1. Vérifiez que les objets du connecteur existent dans le compte Snowflake source en exécutant les commandes SHOW sur chacun de ces types d’objets.

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

   Copy

   Notez que secretsdb est le nom de la base de données qui contient le secret et destdb est le nom de la base de données qui contient les données ingérées de ServiceNow.

2. Mettez à jour le groupe de basculement pour inclure les intégrations API et les bases de données contenant les données secrètes et ingérées à l’aide d’une commande 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

Étapes du compte cible :

1. Actualisez le groupe de basculement secondaire pour répliquer les intégrations et les bases de données sur le compte cible.

   alter failover group fg refresh;
   

   Copy

2. Vérifiez que les objets répliqués existent à l’aide des commandes SHOW suivantes.

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

   Copy

3. Vérifiez la connexion à chaque compte Snowflake en utilisant la méthode de votre choix (par exemple un navigateur, SnowSQL).

4. En option, promouvez le groupe de basculement secondaire et la connexion secondaire du compte cible en groupe principal et connexion principale. Cela va promouvoir le compte cible en tant que nouveau compte source.

   Groupe de basculement :

   alter failover group fg primary;
   

   Copy

   Connexion :

   alter connection global primary;
   

   Copy

5. Si vous avez terminé l’étape précédente, vérifiez que vous pouvez vous connecter à chaque compte Snowflake.

   À ce stade, le compte cible contient les objets répliqués et les utilisateurs peuvent se connecter. Cependant, il existe des étapes supplémentaires dans le compte cible pour utiliser le connecteur.

6. Mettez à jour le service distant associé à l’intégration API dans la plate-forme Cloud qui héberge votre compte Snowflake.

   Pour plus de détails, reportez-vous à Mise à jour du service distant pour les intégrations API.

7. Installez le connecteur manuellement ou avec Snowsight. Pour plus de détails, reportez-vous à :

   • Installer le connecteur manuellement

   • Installer le connecteur avec Snowsight

8. Accès aux données ServiceNow dans Snowflake.