Dans l'article précédent sur les Network Policies, on a vu comment restreindre les connexions par IP. Ça filtre le depuis "où" mais pas au "comment" car si quelqu'un a le password d'un compte ACCOUNTADMIN et qu'il se connecte depuis une IP autorisée, il peut s'authentifier.
Et là, le password seul ne suffit pas. Surtout pour les comptes admins et les comptes de service.
Dans cet article, on va voir deux mécanismes, le MFA (pour les users) et le Key Pair (pour les comptes de service).
MFA : Multi-Factor Authentication
Le MFA dans Snowflake fonctionne avec Duo Security et c'est le service MFA intégré nativement. Quand le MFA est activé pour un utilisateur, il doit entrer son password + valider via l'app Google Authenticator, Duo Mobile ou autre sur son téléphone.
Comment un utilisateur active le MFA
Un user peut le faire lui-même depuis Snowsight. Il va dans son profil, et active le MFA. Snowflake lui demande d'installer Duo Mobile ou Google Auth. et de scanner un QR code. Et Donc avant chaque connexion, il doit valider via l'app.
Forcer le MFA avec une Authentication Policy
Compter sur les utilisateurs pour activer le MFA eux-mêmes n'est jamais une bonne idée. Un admin peut le forcer via une Authentication Policy :
USE ROLE ACCOUNTADMIN;
-- Créer la policy qui force le MFA
CREATE OR REPLACE AUTHENTICATION POLICY policy_mfa_obligatoire
MFA_AUTHENTICATION_METHODS = ('TOTP')
CLIENT_TYPES = ('SNOWFLAKE_UI')
COMMENT = 'MFA obligatoire';
MFA_AUTHENTICATION_METHODS = ('TOTP') veut dire que Snowflake va exiger un code TOTP (Time-based One-Time Password) pour s'authentifier.
CLIENT_TYPES = ('SNOWFLAKE_UI') veut dire que le MFA est exigé quand l'utilisateur se connecte via l'interface web (Snowsight). Tu peux aussi ajouter 'SNOWFLAKE_CLI' et 'DRIVERS' si tu veux couvrir SnowSQL et les connecteurs.
Appliquer la policy
Au niveau d'un utilisateur (par exemple, tous les admins) :
ALTER USER admin_IB SET AUTHENTICATION POLICY = policy_mfa_obligatoire;Au niveau du compte (pour tout le monde) :
ALTER ACCOUNT SET AUTHENTICATION POLICY = policy_mfa_obligatoire;
Un utilisateur perd son téléphone
Dans le cas ou un utilisateur ne peut plus se connecter parce qu'il n'a plus accès à son téléphone. Un admin peut temporairement bypasser le MFA le temps qu'il reconfigure son appareil :
USE ROLE SECURITYADMIN;
-- Bypasser le MFA pendant 60 minutes
ALTER USER utilisateur_bloque SET MINS_TO_BYPASS_MFA = 60;
Le user a 60 minutes pour se connecter sans MFA, et donc aller dans ses préférences, et réactiver un nouveau devise. Après les 60 minutes, le bypass expire automatiquement.
Vérifier qui a le MFA activé
-- Voir les propriétés d'un utilisateur
DESCRIBE USER admin_IB;
-- Lister tous les utilisateurs et leur statut MFA
SELECT NAME, HAS_MFA, DISABLED, DEFAULT_ROLE
FROM SNOWFLAKE.ACCOUNT_USAGE.USERS
WHERE DELETED_ON IS NULL
ORDER BY HAS_MFA;
Authentification par Key Pair
Le password (avec ou sans MFA), c'est bien pour les humains. Mais pour les comptes de service (Qlik sense, PowerBI, Airflow, DBT, Fivetran, un script Python...), un password qui traîne dans un fichier de config, c'est un grand risque.
L'authentification par (paire de clés RSA) résout ce problème. Au lieu d'un password, le compte de service utilise une clé privée pour prouver son identité. La clé publique correspondante est enregistrée dans Snowflake.
Générer une paire de clés
# Générer la clé privée (chiffrée)
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -v2 aes256
# Extraire la clé publique
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
Associer la clé publique à un utilisateur
USE ROLE SECURITYADMIN;
ALTER USER QLIK_SVC SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w0BAQE...';
Nb : tu colles ici le contenu de rsa_key.pub sans les lignes -----BEGIN PUBLIC KEY----- et -----END PUBLIC KEY-----, et sans retours à la ligne.
Rotation de clés
Snowflake supporte deux clés publiques en parallèle (RSA_PUBLIC_KEY et RSA_PUBLIC_KEY_2). Ça te permet de faire une rotation sans interruption :
-- 1) Ajouter la nouvelle clé en position 2
ALTER USER QLIK_SVC SET RSA_PUBLIC_KEY_2 = 'MIIBIjANBgkqhkiG9w...nouvelle...';
-- 2) Mettre à jour le client (Qlik Sense) pour utiliser la nouvelle clé privée
-- 3) Une fois que tout fonctionne, supprimer l'ancienne clé
ALTER USER QLIK_SVC UNSET RSA_PUBLIC_KEY;
-- 4) Déplacer la nouvelle clé en position 1
ALTER USER QLIK_SVC SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w...nouvelle...';
ALTER USER QLIK_SVC UNSET RSA_PUBLIC_KEY_2;Vérifier les clés associées à un utilisateur
DESCRIBE USER QLIK_SVC;Tu verras les propriétés RSA_PUBLIC_KEY et RSA_PUBLIC_KEY_FP (le fingerprint de la clé).
Se connecter avec Key Pair en Python
from snowflake.snowpark import Session
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
# Lire la clé privée
with open("rsa_key.p8", "rb") as key_file:
private_key = serialization.load_pem_private_key(
key_file.read(),
password=b"ton_passphrase",
backend=default_backend()
)
private_key_bytes = private_key.private_bytes(
encoding=serialization.Encoding.DER,
format=serialization.PrivateFormat.PKCS8,
encryption_algorithm=serialization.NoEncryption()
)
connection_params = {
"account": "mon_compte",
"user": "QLIK_SVC",
"private_key": private_key_bytes,
"role": "QLIK_ROLE",
"warehouse": "WH_QLIK",
"database": "ANALYTICS_DB"
}
session = Session.builder.configs(connection_params).create()
print(session.sql("SELECT CURRENT_USER(), CURRENT_ROLE()").collect())Pas de password dans le code. Juste la clé privée (qui elle-même est chiffrée par une passphrase).
Aller plus loin : Formation Snowflake
J'ai regroupé tous mes articles Snowflake dans un parcours complet.
👉 Formation Snowflake : tous les modules pas à pas
Vous voulez que je vous accompagne sur votre projet data (Snowflake, ingestion, modélisation, performance, coûts, gouvernance) ?
