Réplication des intégrations de sécurité et des politiques de réseau à travers plusieurs comptes

Cette rubrique fournit des informations sur la manière de répliquer des intégrations de sécurité, ainsi que sur l’utilisation du basculement/de la restauration avec chacun de ces objets. Elle suppose que vous avez déjà des connaissances sur la réplication et le basculement/la restauration avec d’autres objets de niveau compte (par exemple, utilisateurs, rôles, entrepôts).

Pour plus de détails, voir Réplication et basculement de compte.

Ces objets et services sont pris en charge à travers les régions et les plates-formes Cloud.

Dans ce chapitre :

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 :

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.

Les étapes suivantes sont un exemple représentatif pour montrer comment faire ce qui suit :

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

É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;
    
  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;
    
  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;
    
  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 :

  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;
    

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).

Les étapes suivantes sont un exemple représentatif pour montrer comment faire ce qui suit :

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

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

    Connexion :

    alter connection global primary;
    

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.

Les étapes suivantes sont un exemple représentatif pour montrer comment faire ce qui suit :

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

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

    Connexion :

    alter connection global primary;
    
  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.

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 IP de l’utilisateur lors de la connexion à Snowflake.

La réplication de la politique réseau réplique l’objet de politique réseau et toute référence/affectation de politique réseau. Par exemple, si une politique réseau est attribuée à un utilisateur et que l’utilisateur existe à la fois dans le compte source et dans le compte cible, la réplication de la politique réseau attribue la politique réseau à l’utilisateur dans le compte cible.

La réplication des politiques réseau s’applique également aux politiques réseau spécifiées dans Snowflake OAuth et dans les intégrations de sécurité SCIM, à condition que l’opération de réplication spécifie les intégrations de sécurité et les politiques réseau. Après avoir répliqué la politique réseau et les intégrations de sécurité qui spécifient une politique réseau, les intégrations de sécurité du compte cible spécifient la même politique réseau.

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 politiques réseau existent dans le compte source.

  • L’intégration de sécurité Snowflake OAuth et/ou SCIM existe déjà dans le compte source et l’intégration spécifie une politique réseau.

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

  • Répliquez les politiques réseau et une intégration de sécurité qui spécifie une politique réseau.

  • Actualisez le groupe de basculement.

  • Vérifiez l’activation de la politique réseau.

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

Étapes du compte source :

  1. Vérifiez que les politiques réseau existent dans le compte Snowflake source en exécutant une commande SHOW NETWORK POLICIES.

  2. Vérifiez que les intégrations de sécurité Snowflake OAuth et/ou SCIM incluent une politique réseau en exécutant une commande SHOW INTEGRATIONS pour identifier l’intégration de sécurité, puis exécutez une commande DESCRIBE INTEGRATION sur l’intégration de sécurité Snowflake OAuth.

  3. Mettez à jour le groupe de basculement pour inclure network policies en utilisant une commande ALTER FAILOVER GROUP.

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

Étapes du compte cible :

  1. Actualisez le groupe de basculement secondaire pour mettre à jour le compte cible afin d’inclure les objets de politique réseau et l’intégration de sécurité Snowflake OAuth qui spécifie la politique réseau.

    alter failover group fg refresh;
    
  2. Vérifiez que l’objet de politique réseau existe en exécutant une commande SHOW NETWORK POLICIES, et vérifiez que l’intégration de sécurité Snowflake OAuth spécifie la politique réseau répliquée en exécutant une commande DESCRIBE SECURITY INTEGRATION sur l’intégration de sécurité.

  3. Vérifiez l’activation de la politique réseau comme indiqué dans Identification d’une politique réseau activée au niveau du compte ou de l’utilisateur.

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

  5. 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;
    

    Connexion :

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

Revenir au début