Prise en main
Prise en main
Activez Tri-Secret Secure sur votre compte Snowflake avec DuoKey XKS MPC
Vue d'ensemble
Snowflake fournit un processus d'auto-enregistrement pour Tri-Secret Secure qui utilise une série de fonctions SYSTEM$. Ce guide vous accompagne à chaque étape — du déploiement de votre DuoKey XKS Proxy à l'activation de TSS sur votre compte Snowflake.
Processus d'auto-enregistrement TSS
Activation étape par étape de Tri-Secret Secure avec DuoKey XKS
Prérequis
Prérequis
- Édition Snowflake Business Critical (ou supérieure) sur AWS
- Rôle ACCOUNTADMIN dans Snowflake
- Accès à DuoKey Cockpit avec XKS Proxy déployé
- DuoKey MPC Vault opérationnel avec au moins une clé AES-256
- Compte AWS avec les autorisations KMS dans la même région que Snowflake
- Accès à l'AWS CLI ou à la console pour les opérations KMS et IAM
Tri-Secret Secure est une décision de sécurité majeure. Une fois activé, votre compte Snowflake dépend de votre CMK pour toutes les opérations cryptographiques. Assurez-vous que votre DuoKey XKS Proxy et votre MPC Vault sont prêts pour la production, avec une haute disponibilité, avant de continuer.
Guide pas à pas
Étape 1 : Déployer DuoKey XKS Proxy
Configurez votre DuoKey XKS Proxy avec MPC Vault comme gestionnaire de clés backend. Cette étape est identique au déploiement standard de DuoKey AWS XKS.
- Déployer DuoKey XKS Proxy (endpoint public ou endpoint VPC)
- Configurer DuoKey Cockpit pour router les requêtes XKS vers MPC Vault
- Créer une clé AES-256 dans le MPC Vault pour la CMK Snowflake
- Vérifier que l'endpoint de contrôle de santé du XKS Proxy renvoie 200 OK
- Noter l'External Key ID attribué à votre clé
Reportez-vous au guide Prise en main d'AWS XKS pour des instructions détaillées de déploiement du XKS Proxy.
Étape 2 : Créer une CMK adossée à XKS dans AWS KMS
Créez une clé AWS KMS qui utilise votre DuoKey XKS Proxy comme External Key Store.
-- 1. Create the External Key Store in AWS KMS (if not already done)
aws kms create-custom-key-store \
--custom-key-store-name "duokey-xks-snowflake" \
--custom-key-store-type "EXTERNAL_KEY_STORE" \
--xks-proxy-uri-endpoint "https://your-xks-proxy.example.com" \
--xks-proxy-uri-path "/kms/xks/v1" \
--xks-proxy-connectivity "PUBLIC_ENDPOINT" \
--xks-proxy-authentication-credential \
AccessKeyId=AKIAEXAMPLE,RawSecretAccessKey=your-secret
-- 2. Connect the key store
aws kms connect-custom-key-store \
--custom-key-store-id "cks-1234567890abcdef0"
-- 3. Create the CMK in the External Key Store
aws kms create-key \
--origin "EXTERNAL_KEY_STORE" \
--custom-key-store-id "cks-1234567890abcdef0" \
--xks-key-id "your-external-key-id-from-duokey"
Notez le Key ARN renvoyé par create-key. Vous en aurez besoin à l'étape suivante.
Étape 3 : Enregistrer la CMK dans Snowflake
Utilisez la fonction SYSTEM$REGISTER_CMK_INFO pour enregistrer votre clé AWS KMS auprès de Snowflake. Vous devez disposer du rôle ACCOUNTADMIN.
-- Switch to ACCOUNTADMIN role
USE ROLE ACCOUNTADMIN;
-- Register the CMK ARN
SELECT SYSTEM$REGISTER_CMK_INFO(
'arn:aws:kms:eu-west-1:123456789012:key/mrk-1234abcd5678efgh'
);
| Paramètre | Description | Exemple |
|---|---|---|
| Key ARN | ARN complet de votre clé AWS KMS adossée à XKS | arn:aws:kms:eu-west-1:123456789012:key/mrk-... |
| Région | Doit correspondre à la région de votre compte Snowflake | eu-west-1 |
| Type de clé | Doit être une clé de chiffrement symétrique AES-256 | SYMMETRIC_DEFAULT |
Après l'enregistrement, Snowflake envoie un e-mail de confirmation contenant l'ARN de la CMK et la fenêtre d'activation de 72 heures :
Étape 4 : Récupérer la configuration et appliquer la politique IAM
Récupérez la configuration spécifique à Snowflake, puis appliquez la politique IAM à votre clé AWS KMS afin que Snowflake puisse l'utiliser.
-- Get the required IAM configuration
SELECT SYSTEM$GET_CMK_CONFIG();
Ceci renvoie un document JSON contenant l'instruction de politique IAM qui doit être attachée à votre clé KMS. Appliquez-la dans AWS :
{
"Sid": "AllowSnowflakeAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::SNOWFLAKE_ACCOUNT_ID:root"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKeyWithoutPlaintext",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "snowflake.eu-west-1.amazonaws.com"
}
}
}
Appliquez la politique exacte renvoyée par SYSTEM$GET_CMK_CONFIG(). L'ARN du principal et les conditions sont propres à votre compte Snowflake.
Étape 5 : Vérifier la connectivité
Confirmez que Snowflake peut atteindre votre CMK via AWS KMS et DuoKey XKS Proxy :
SELECT SYSTEM$VERIFY_CMK_INFO();
| Résultat | Signification | Action |
|---|---|---|
| PASSED | Snowflake peut utiliser votre CMK avec succès | Passer à l'étape 6 |
| FAILED — Key not found | L'ARN de la clé AWS KMS est incorrect | Vérifier l'ARN dans REGISTER_CMK_INFO |
| FAILED — Access denied | La politique IAM n'a pas été appliquée correctement | Réappliquer la politique de GET_CMK_CONFIG |
| FAILED — Connection error | XKS Proxy injoignable ou défaillant | Vérifier l'état de DuoKey XKS Proxy |
Lorsque la vérification réussit, la feuille de calcul Snowflake affiche « Verification successful » :
Étape 6 : Attendre 72 heures
Snowflake impose une période d'attente obligatoire de 72 heures entre l'enregistrement et l'activation. Il s'agit d'une mesure de sécurité destinée à prévenir tout verrouillage accidentel. Vous ne pouvez pas ignorer cette étape.
Vous pouvez vérifier l'état actuel avec SYSTEM$GET_CMK_INFO() — cela confirme que la CMK est pré-enregistrée et affiche la date d'activation la plus proche :
Pendant la période d'attente :
- Vérifiez que votre DuoKey XKS Proxy est stable et supervisé
- Testez vos procédures de révocation et de récupération de clé
- Assurez-vous que votre équipe d'exploitation comprend la dépendance à TSS
- Configurez des alertes pour la santé et la latence du XKS Proxy
Étape 7 : Activer Tri-Secret Secure
Après la période d'attente de 72 heures, activez TSS :
USE ROLE ACCOUNTADMIN;
SELECT SYSTEM$ACTIVATE_CMK_INFO();
La fonction renvoie : « Key rotation has started. Account admins will receive a notification email when rekeying is complete. »
Feuille de calcul Snowflake montrant l'activation réussie de Tri-Secret Secure via SYSTEM$ACTIVATE_CMK_INFO()
Une fois activé, Snowflake commence à re-chiffrer toutes les données avec la clé maître composite. Ce processus est automatique et transparent, mais votre CMK doit rester accessible pendant toute la période de re-chiffrement.
Après l'activation
Une fois le re-chiffrement terminé, Snowflake envoie un e-mail de confirmation attestant que Tri-Secret Secure est pleinement actif et que votre compte a été re-chiffré avec la CMK activée :
E-mail de confirmation de Snowflake — TSS est activé et le compte a été re-chiffré avec la CMK
Vérifier l'état de TSS
SELECT SYSTEM$GET_CMK_INFO();
Après une activation réussie, la fonction renvoie : « CMK with ARN: arn:aws:kms:... is activated for Tri-Secret Secure » :
Feuille de calcul Snowflake — SYSTEM$GET_CMK_INFO() confirme que la CMK est activée pour Tri-Secret Secure
Ceci confirme :
- L'ARN et la région de la CMK
- L'état d'activation
- Que Tri-Secret Secure est pleinement opérationnel
Le coupe-circuit en action — XKS Proxy désactivé
L'une des fonctionnalités les plus puissantes de Tri-Secret Secure avec DuoKey XKS est la capacité de révoquer instantanément l'accès de Snowflake à vos données en déconnectant l'External Key Store. Voici une démonstration concrète de ce qui se produit lorsque le XKS Proxy est désactivé.
Étape 1 : Déconnecter l'External Key Store dans AWS KMS
Depuis la console AWS KMS, déconnectez l'External Key Store relié au DuoKey XKS Proxy. L'état de la connexion passe à « Disconnected » :
Console AWS KMS — l'External Key Store est déconnecté avec succès, coupant le lien vers DuoKey XKS Proxy
Étape 2 : Snowflake est immédiatement verrouillé
Avec le XKS Proxy déconnecté, Snowflake ne peut plus accéder à la CMK. Toutes les données deviennent totalement inaccessibles — les utilisateurs voient une erreur d'accès refusé et ne peuvent interroger aucune donnée :
Snowflake est totalement verrouillé — « Access is denied to the customer managed key (CMK) for this account »
Ceci démontre la véritable puissance du chiffrement contrôlé par le client : en déconnectant simplement le XKS Proxy, vous rendez toutes les données Snowflake illisibles. Aucune suppression de données n'est nécessaire — il s'agit du crypto-shredding en action. Reconnecter le key store restaure l'accès instantanément.
Leçons de la fuite de données Snowflake de 2024 : Mi-2024, des attaquants ont utilisé des identifiants volés pour accéder à plus de 165 comptes clients Snowflake (dont AT&T, Ticketmaster, Santander), exfiltrant des centaines de millions d'enregistrements. Si ces clients avaient activé Tri-Secret Secure avec DuoKey XKS, un simple clic pour déconnecter l'External Key Store aurait immédiatement verrouillé les attaquants — rendant toutes les données cryptographiquement inaccessibles, exactement comme illustré ci-dessus. Consultez l'analyse complète de la fuite pour plus de détails.
Procédures d'urgence
Pour empêcher immédiatement Snowflake d'accéder à vos données :
- DuoKey Cockpit : Désactivez la clé CMK dans DuoKey MPC Vault — effet immédiat
- AWS KMS : Désactivez la clé KMS — prend effet en quelques secondes
- AWS IAM : Supprimez la politique IAM de Snowflake — prend effet en quelques minutes
Après la révocation, Snowflake ne peut plus générer de nouvelles clés maîtres composites. Les clés mises en cache existantes expireront, rendant toutes les données inaccessibles.
Supervision
| Quoi surveiller | Où | Seuil d'alerte |
|---|---|---|
| Santé du XKS Proxy | DuoKey Cockpit | Toute réponse différente de 200 |
| Latence du XKS Proxy | DuoKey Cockpit / CloudWatch | > 100 ms en moyenne |
| État de la clé KMS | Console AWS KMS / CloudTrail | Clé désactivée ou suppression en attente |
| Opérations sur la CMK | AWS CloudTrail | Appels Decrypt ou Encrypt inattendus |
| État du MPC Vault | DuoKey Cockpit | Nœud hors ligne ou quorum perdu |