Meilleures pratiques pour la migration de l’authentification à facteur simple¶

Exemples de requêtes pour des listes d’utilisateurs à risque¶

Snowflake a récemment ajouté deux nouveaux scanners : un pour les utilisateurs personne et un pour les utilisateurs service. Cela permet aux clients d’avoir des listes distinctes d’utilisateurs utilisant la connexion par mot de passe à facteur unique, en fonction du type d’utilisateur.

Vous pouvez renvoyer une liste des utilisateurs à risque pour chaque type.

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
;

Répartition des utilisateurs selon le TYPE et la méthode d’authentification utilisée¶

En plus de la requête précédente, il est utile de dresser la liste de la répartition des utilisateurs en fonction des types d’utilisateurs et des méthodes d’authentification utilisées. Cela aide les clients à élaborer des stratégies de migration des utilisateurs vers des méthodes d’authentification plus fortes telles que SAML et OAuth. Par exemple, si un utilisateur apparaît comme risqué (parce qu’il a un mot de passe dans Snowflake) mais que cet utilisateur n’utilise que l’authentification SAML, il est conseillé de supprimer ce mot de passe de Snowflake dès que possible.

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
;

Considérations relatives à la migration¶

Voici quelques éléments à prendre en compte lorsque vous planifiez votre migration :

• Tout d’abord, définissez les types d’utilisateurs (cette opération peut être automatisée via SCIM).

• Deuxièmement, vérifiez les méthodes d’authentification prises en charge par vos applications : Snowflake prend en charge une variété de méthodes d’authentification, telles que OAuth, SAML, paire de clés, MFA, etc. Cependant, l’application qui se connecte à Snowflake doit également prendre en charge des méthodes d’authentification forte. Il y a deux cas d’utilisation :

  • L’application prend déjà en charge SAML et/ou OAuth. Nous vous encourageons à migrer vers cette authentification dès que possible.

  • L’application est ancienne et ne prend pas en charge les méthodes d’authentification forte telles que SAML ou OAuth ; elle ne prend en charge que les mots de passe. Dans ce cas, il vous est conseillé de mettre à jour votre ancienne application. En attendant, vous pouvez utiliser les politiques réseau, la rotation des mots de passe et les fonctions de protection contre les fuites de mots de passe jusqu’à la mise à jour de l’application.

• Ensuite, les clients doivent prendre en compte les éléments suivants pour les utilisateurs locaux (créés manuellement dans Snowflake et qui n’ont pas accès à SAML ou OAuth) :

  • Pour une application qui prend en charge SSO, passez l’utilisateur local en utilisateur compatible SSOet tenez compte des temps d’arrêt lorsque du changement.

  • Pour passer les utilisateurs locaux en utilisateurs compatibles SSO, assurez-vous que ces utilisateurs existent dans votre IdP et qu’ils sont ensuite provisionnés dans Snowflake manuellement, ou de préférence automatiquement, via SCIM.

  • Désactivez les utilisateurs locaux non utilisés.

• Snowflake prend en charge les politiques d’authentification, les politiques réseau et les politiques de mot de passe au niveau de l’utilisateur et du compte. Considérez d’abord les politiques de niveau utilisateur afin de procéder à une migration progressive (les politiques de niveau utilisateur sont prioritaires par rapport aux politiques de niveau compte) :

  • Snowflake recommande des politiques réseau de niveau utilisateur pour les applications qui on recours à des utilisateurs service (TYPE = SERVICE ou LEGACY_SERVICE).

  • Pour les utilisateurs humains (TYPE = PERSON ou NULL), vous pouvez commencer par des politiques réseau au niveau de l’utilisateur, puis appliquer des politiques réseau au niveau du compte pour protéger toutes les populations d’utilisateurs qui n’ont pas de politiques spécifiques au niveau utilisateur.

  • Le même concept avec les politiques de MFA commence par des politiques de niveau utilisateur.

• Si vous disposez d’une application ancienne qui ne prend pas en charge l’authentification unique, Snowflake recommande d’utiliser les jetons d’accès programmatique (PATs), qui sont par défaut liés à des rôles spécifiques, nécessitent une politique réseau et sont limités dans le temps.

Définir le type d’utilisateur¶

La première étape de la phase de protection consiste à définir les types d’utilisateurs automatiquement via SCIM ou manuellement :

ALTER USER svc_user1 SET TYPE = SERVICE;
ALTER USER user1@example.COM SET TYPE = PERSON;
-- LEGACY APPLICATION ONLY

En outre, vous pouvez désormais définir le type d’utilisateur administrateur lors de la création d’un compte :

CREATE ACCOUNT <name> [ ADMIN_USER_TYPE = PERSON | SERVICE | LEGACY_SERVICE | NULL ];

Supprimer les mots de passe locaux lorsqu’ils ne sont pas nécessaires¶

Exploitez les requêtes sous Répartition des utilisateurs selon TYPE et la méthode AuthN utilisés et Liste des utilisateurs à risque, sur la base des résultats du Trust Center, pour commencer à nettoyer tout mot de passe dans Snowflake pour un utilisateur qui utilise déjà SAML, OAuth, ou une paire de clés exclusivement.

Créer des politiques d’authentification pour les utilisateurs service¶

Snowflake recommande l’utilisation de OAuth pour les utilisateurs de services programmatiques, et vous pouvez l’appliquer avec des politiques d’authentification :

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;

Les clients peuvent toujours utiliser des paires de clés pour l’authentification avec les utilisateurs SERVICE, mais ils doivent combiner cela avec les politiques réseau et procéder à une rotation régulière de leurs clés.

Créez des politiques d’authentification pour appliquer la MFA aux utilisateurs humains¶

Snowflake recommande à ses clients d’utiliser leurs propres fournisseurs d’identité SAML (IdPs) avec toute solution MFA prise en charge par leur IdP. L’exemple de politique d’authentification suivant aide les clients à :

• Appliquer la MFA native de Snowflake à tout utilisateur humain qui utilise des mots de passe natifs de Snowflake.

• Compter sur le IdP SAML du client pour imposer la MFA aux utilisateurs de l’authentification unique.

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

Les clients doivent prendre en considération une situation d’urgence au cas où le IdP du client serait hors ligne afin que leurs administrateurs de compte puissent toujours se connecter à leurs comptes Snowflake.

CREATE AUTHENTICATION POLICY ACCOUNTADMIN_BREAKGLASS_MFA
  AUTHENTICATION_METHODS = ('PASSWORD')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD') -- enforce Snowflake MFA for native passwords only
  MFA_ENROLLMENT = 'REQUIRED';

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

Créer une politique de mot de passe¶

Dans le cas d’un ancien système ou d’une situation d’urgence où vous devez utiliser des mots de passe natifs de Snowflake, veuillez utiliser les politiques de mot de passe de Snowflake pour correspondre aux politiques de mot de passe de l’organisation, si elles sont différentes des politiques par défaut.

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

Créer une politique de session¶

Snowflake vous recommande de créer des politiques de session pour appliquer la réauthentification après une période d’inactivité spécifique. Il ne s’agit là que d’un exemple ; vous pouvez personnaliser les politiques au niveau de chaque utilisateur.

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

Créer des politiques réseau pour les utilisateurs service¶

En général, les utilisateurs services ou d’accès programmatique doivent provenir d’adresses IP autorisées (ou VPCE ID, LinkID, et ainsi de suite, dans le cas d’une connectivité privée).

Snowflake recommande de créer des politiques réseau de niveau utilisateur service pour restreindre l’accès à ces utilisateurs d’accès programmatique à partir de sources autorisées et fiables. Les clients doivent envisager d’appliquer des règles réseau dans les zones de préparation internes également.

Les connexions peuvent provenir de réseaux privés ou publics, selon que le client utilise ou non une connectivité privée. N’oubliez pas que vous pouvez autoriser la connectivité publique et privée en même temps en ajoutant plusieurs règles de réseau qui incluent les IPs (publiques ou privées) et/ou le balises CSP (telles que 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' )
;

Créer des politiques réseau au niveau compte¶

Les politiques de niveau compte fonctionnent comme des politiques réseau de sécurité par défaut pour les utilisateurs auxquels aucune politique réseau n’est directement appliquée. La meilleure pratique consiste à garder ces politiques aussi restrictives et courtes que possible tout en utilisant des politiques au niveau de l’utilisateur pour répondre aux besoins spécifiques de l’utilisateur.

Snowflake ne recommande pas d’élaborer d’énormes politiques réseau de niveau compte pour répondre à tous les besoins de l’organisation ; au lieu de cela, activez des politiques de niveau utilisateur pour avoir des contrôles plus granulaires.

Comme pour les politiques réseau de niveau utilisateur, les connexions peuvent provenir de réseaux privés ou publics, selon que le client utilise ou non une connectivité privée. N’oubliez pas que vous pouvez autoriser la connectivité publique et privée en même temps en ajoutant plusieurs règles de réseau qui incluent les IPs (publiques ou privées) et/ou le balises CSP (telles que 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' )
;

Protéger les utilisateurs service¶

Les utilisateurs disposant de TYPE=SERVICE sont exemptés des politiques d’application de MFA au niveau du compte et disposent de restrictions permettant d’améliorer la sécurité des cas d’utilisation non interactifs. Notamment, les utilisateurs de type SERVICEne peuvent pas se connecter à l’aide d’un mot de passe ou de SSO SAML. Voir l’avertissement ci-dessous.

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

Appliquer des politiques de mot de passe et de session au niveau du compte¶

L’administrateur de la sécurité de Snowflake doit appliquer des politiques de base en matière de mots de passe et de sessions au niveau du compte, puis remplacer ces politiques par des politiques de niveau utilisateur, le cas échéant.

ALTER ACCOUNT SET
SESSION POLICY = SESSION_POLICY_ACCOUNT;
PASSWORD POLICY = PASSWORD_POLICY_ACCOUNT;

Tester les utilisateurs service¶

À ce stade, des politiques de mot de passe et de session sont appliquées au compte ; les utilisateurs programmatiques du service sont exemptés de MFA; ils disposent de leurs propres politiques d’authentification spécifiques et de politiques réseau qui garantissent que les connexions sont établies à partir de sources fiables et utilisent les méthodes d’authentification recommandées, telles que OAuth ou une paire de clés.

L’administrateur de sécurité doit tester quelques utilisateurs service pour s’assurer du bon déroulement des opérations et pour confirmer que les connexions proviennent de sources fiables et qu’elles utilisent des méthodes d’authentification appropriées. Les administrateurs doivent utiliser LOGIN_HISTORY, en plus du Trust Center, pour confirmer que les utilisateurs service sont protégés par les politiques réseau.

SELECT *
  FROM TABLE(INFORMATION_SCHEMA.LOGIN_HISTORY(TIME_RANGE_START =>
    DATEADD('HOURS',-1,CURRENT_TIMESTAMP()),CURRENT_TIMESTAMP()))
  ORDER BY EVENT_TIMESTAMP;

Protéger le compte avec la mise en œuvre de la MFA¶

Pour appliquer la MFA à tous les utilisateurs qui ne sont pas de typeSERVICE, appliquez la politique d’application MFA au niveau du compte.

Ces politiques permettent de garantir que tous les utilisateurs interactifs humains activent la MFA soit à partir de leur propre IdP, soit à partir de la MFA native de Snowflake.

ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;

Si vous souhaitez appliquer la double MFA à vos utilisateurs hautement privilégiés, tels que les administrateurs de comptes, appliquez la MFA à ce niveau d’utilisateur. Toutefois, vous devez trouver un équilibre entre les procédures d’urgence en cas de défaillance de votre IdP et vos exigences en matière de sécurité.

ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;

Pour une situation d’urgence :

ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;

Appliquer des politiques réseau de niveau compte¶

Pour finir, il est temps d’appliquer des politiques réseau au niveau du compte afin de protéger tous les autres utilisateurs qui ne disposent pas de politiques réseau explicites.

ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;

Désactiver les utilisateurs inactifs¶

Le scanner CIS du Trust Center (1.8) surveille les utilisateurs qui n’ont pas été actifs au cours des 90 derniers jours. Comme le montre le diagramme suivant, vous pouvez cliquer sur Open a Worksheet pour afficher la requête qui répertorie les utilisateurs inactifs :

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 vous recommande vivement de désactiver ces utilisateurs.