Sécurité du compte de service Snowflake, partie 2

Sécurité du compte de service Snowflake, partie 2


Dans Partie 1, nous avons couvert les objectifs de haut niveau et les méthodes d’attaque des comptes de service. Dans la partie 2, nous discutons des atténuations de défense en profondeur de ces méthodes.

À la fin de ce blog, vous serez en mesure d’appliquer des atténuations sécurisées par défaut aux menaces affectant les comptes de service Snowflake.

Le tableau suivant de la partie 1 met en évidence les objectifs et les méthodes que nous souhaitons atténuer :

Atténuations sécurisées par défaut

Ces atténuations sécurisées par défaut aident à prévenir et à limiter l’utilisation abusive des informations d’identification par le vol et les attaques par anticipation :

  • Le moindre privilège
  • Forte accréditation de courte durée
  • Prévention de la transmission des identifiants
  • Empêchement de l’accès humain

Le moindre privilège

Atténue

La stratégie de cybersécurité moderne suppose que les adversaires sont intelligents et que des violations sont possibles. Nos priorités sont de :

  • Rendre l’architecture sécurisée par défaut en réduisant le nombre de scénarios possibles
  • Appliquer des mécanismes de défense en profondeur appropriés aux scénarios possibles restants

Cela signifie que les comptes ne disposent que des autorisations minimales nécessaires pour effectuer la l’opération en cours. (Les opérations sont des interactions avec la base de données Snowflake causées par des éléments tels que les appels d’API, le traitement par lots et le chargement de données).

Assurez-vous soigneusement que chaque opération est bien définie et dispose des autorisations minimales nécessaires. Cela garantit que lorsque un identifiant est volé, le dommage est intentionnellement limité.

Utilisez ces bonnes pratiques pour concevoir des comptes de service Snowflake :

  • Séparez les autorisations de lecture et d’écriture en créant des rôles en lecture seule et en écriture seule.
  • Étendre l’accès aux données sur les rôles en lecture seule et en écriture seule à ce qui est nécessaire pour un opération unique.
  • Créez des rôles distincts pour la gestion des données sensibles.
  • Appliquez des politiques réseau qui ajoutent des adresses IP spécifiques à la liste blanche pour limiter les emplacements réseau à partir desquels les comptes de service peuvent être utilisés.

L’application de ces bonnes pratiques nous donne les garanties suivantes :

  • Les informations d’identification en écriture seule ne peuvent pas être utilisées pour lire des données hors de portée par des attaquants
  • Les informations d’identification en lecture seule ne peuvent pas être utilisées pour écrire hors de portée par les attaquants
  • Les informations d’identification en lecture seule limitées à des champs spécifiques ne peuvent pas être utilisées pour lire des champs hors de portée par des attaquants
  • Les informations d’identification en écriture seule limitées à des champs spécifiques ne peuvent pas être utilisées pour modifier des champs hors de portée par des attaquants
  • Les informations d’identification volées ne peuvent pas être utilisées en dehors du périmètre du réseau

Forte accréditation de courte durée

Atténue

Le moindre privilège restreint la espace dans lequel un identifiant volé peut être utilisé. Maintenant, nous nous concentrons sur la restriction de la temps un justificatif est utile.

Moins un identifiant est utile, moins il peut apporter de valeur à un attaquant. Un identifiant est considéré comme utile lorsqu’il contient activement des autorisations permettant l’accès aux données. Il n’est pas considéré comme utile lorsqu’il ne peut être utilisé que pour demander de nouvelles informations d’identification utiles. Être forcé d’acquérir les informations d’identification à plusieurs reprises peut également augmenter le coût de la réalisation d’une attaque.

Utilisez ces bonnes pratiques pour vous assurer que les identifiants de courte durée sont utilisés par les comptes de service Snowflake :

  • Stockez les informations d’identification dans une plate-forme de stockage secrète spécialement conçue, telle que HashiCorp Vault, KMS ou SSM.
  • Assurez-vous que les schémas d’authentification basés sur un mot de passe exploitent des valeurs fortes générées de manière aléatoire.
  • Privilégiez les identifiants à usage unique. La durée de vie utile des informations d’identification ne doit pas dépasser la durée de vie de l’opération.

L’application de ces bonnes pratiques garantit que les identifiants volés pourront être utilisés pendant une durée limitée, connue à l’avance des défenseurs.

Snowflake a écrit un exemple de plugin pour Hashicorp Vault, une plate-forme de gestion des secrets, afin que vous puissiez voir comment ces informations d’identification limitées dans le temps fonctionnent spécifiquement avec Snowflake. Nous explorerons l’utilisation de cela plus en profondeur dans la partie 3 de cette série d’articles de blog.

Empêcher la transmission des informations d’identification

Atténue

Les informations d’identification qui ne sont jamais transmises sur le réseau ne peuvent pas être interceptées par des attaquants. Il est également peu probable qu’ils apparaissent dans les fichiers journaux.

Les schémas d’authentification à clé publique tels que les paires de clés RSA ne transmettent jamais le matériel de clé privée sur le réseau. Au lieu de cela, seule une signature est transmise. Étant donné que la clé privée n’est pas transmise, elle n’apparaîtra pas dans les journaux de débogage ou de suivi qui incluent le trafic HTTP brut.

Utilisez ces bonnes pratiques lors du déploiement de l’authentification par paire de clés pour les comptes de service Snowflake :

  • Stockez les clés privées et les mots de passe clés dans une plate-forme de stockage secrète spécialement conçue à cet effet, telle que HashiCorp Vault, KMS ou SSM.
  • Chiffrez la clé privée avec une phrase de passe.
  • Utilisez l’automatisation pour limiter la validité des clés publiques et privées à des heures ou des minutes, et alternez-les sans interaction humaine.

L’application de ces meilleures pratiques garantit que les informations d’identification ne peuvent pas être interceptées sur le réseau.

Empêcher l’accès humain

Atténue

Le test avec un compte de service machine est pratique, mais il crée des problèmes d’auditabilité et de sécurité. De plus, il n’est pas possible d’identifier tous les endroits où un identifiant partagé peut exister, ni même qui l’utilise actuellement.

Par conséquent, empêchez les initiés de divulguer ou de voler des informations d’identification en les empêchant d’accéder directement aux informations d’identification.

Utilisez ces bonnes pratiques lors du déploiement de l’authentification par paire de clés pour les comptes de service Snowflake :

  • Éliminer les humains du cycle de vie de la gestion des informations d’identification du compte de service grâce à l’automatisation
  • Restreindre les opérateurs humains à un accès en écriture seule aux informations d’identification du compte de service dans les plates-formes de stockage de secrets spécialement conçues

L’application de ces meilleures pratiques garantit que les opérateurs humains ne peuvent jamais voir les informations d’identification du compte de service.

Atténuations et fonctionnalités de sécurité Snowflake

Snowflake prend en charge les approches de haut niveau suivantes pour l’authentification des comptes de service :

De plus, Snowflake fournit des politiques de réseau pour contrôler d’où les comptes peuvent se connecter.

Les deux tableaux suivants couvrent les atténuations fournies par chaque approche, dans quelle mesure relative, et les avantages et les inconvénients de chacune :

Screen Shot 2020 06 08 at 10.31.09 AM

Screen Shot 2020 06 08 at 12.02.37 PM

Conclusion

Les comptes de service seront avec nous pendant longtemps. Tant que vous comprenez parfaitement les risques, vous pouvez les gérer en toute sécurité. Snowflake vous a fourni un ensemble complet de fonctionnalités qui peuvent vous aider à atténuer les risques lorsque vous tirez pleinement parti de ces fonctionnalités. Comme toujours, vous pouvez contacter votre équipe Snowflake pour en savoir plus sur ces fonctionnalités et obtenir de l’aide.


Références:

1: https://developer.mastercard.com/blog/why-mastercard-doesnt-use-oauth-20/

2 : https://tools.ietf.org/html/rfc6819#section-4.1

3 : https://tools.ietf.org/html/rfc6819#section-4.1.3

4 : https://docs.snowflake.com/en/user-guide/odbc-parameters.html#required-connection-parameters

5 : https://stackoverflow.com/questions/15093440/change-keystore-password-from-no-password-to-a-non-blank-password

6 : https://docs.snowflake.com/en/user-guide/network-policies.html#managing-user-level-network-policies

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.