AWS resserre la sécurité par défaut sur Redshift

Lucas Morel

L’accessibilité du public aux données du service d’entrepôt de données gérées a été désactivée.

Les améliorations de la sécurité d’Amazon pour son service d’entrepôt de données gérées AWS Redshift sont des ajouts les bienvenus, explique un expert.

Loris Degioanni, directrice de la technologie chez Sysdig, a déclaré à Infoworld que les défauts de sécurité améliorés d’AWS pour Amazon Redshift sont une «évolution nécessaire pour l’adoption accélérée du cloud que nous avons vue dans les organisations ayant une expertise de sécurité variable. Les configurations sécurisées sont la première ligne de défense, et en appliquant les meilleures pratiques dès le premier jour, ces modifications renforcent le changement d’esprit à gauche Sysdig a longtemps défendu. Cependant, la sécurité ne s’arrête pas à de fortes valeurs par défaut – la surveillance continue, la priorisation des risques et la détection des menaces en temps réel sont essentielles. »

Redshift permet aux organisations de stocker et d’analyser leurs données en utilisant leur choix d’outils d’intelligence commerciale. Selon Hginsights, un peu plus de 27 700 organisations utilisent le rouge -hif.

Les changements

Les trois modifications sont dans les paramètres par défaut de Redshift pour les clusters nouvellement créés, les groupes de travail sans serveur Redshift et les clusters restaurés à partir d’instantanés:

  • L’accessibilité du public aux données a été désactivée. Les clusters nouvellement créés ne seront accessibles que dans le cloud privé virtuel (VPC) d’un client. Si un administrateur a besoin d’un accès public, il doit remplacer explicitement la valeur par défaut et définir le paramètre «accessible en bourse» à «True» lors de l’exécution des opérations d’API «CreateCluster» ou «RestorefromClustersNapshot». Notez que si les applications Redshift sont dans un VPC autre que celui d’Amazon, les clients peuvent configurer l’accès Cross-VPC
    Avec un cluster accessible au public, AWS recommande aux administrateurs d’utiliser toujours des groupes de sécurité ou des listes de contrôle d’accès au réseau (ACLS de réseau) pour restreindre l’accès;
  • Le chiffrement de la base de données est activé par défaut. En d’autres termes, la capacité de créer des grappes non cryptées dans la console de décalage vers le rouge a disparu. Lorsqu’un administrateur utilise la console, la CLI, l’API ou la CloudFormation pour créer un cluster provisionné sans spécifier une clé de service de gestion de clé AWS (AWS KMS), le cluster sera automatiquement crypté avec une clé appartenant à AWS. La clé appartenant à AWS est gérée par AWS.
  • Les connexions sécurisées sont appliquées par défaut. Cela applique le cryptage de la communication entre les applications d’un client et l’entrepôt de données Amazon Redshift pour aider à protéger la confidentialité et l’intégrité des données transmises entre les applications du client et Amazon Redshift.
    Un nouveau groupe de paramètres par défaut nommé «Default.redshift-2.0» est créé pour les clusters nouvellement créés ou restaurés, avec le paramètre «require_ssl» défini sur «true» par défaut. Les nouveaux clusters créés sans un groupe de paramètres spécifié utiliseront automatiquement le groupe de paramètres «default.redshift-2.0», qui sera automatiquement sélectionné dans la console Redshift. Ce changement se reflétera également dans les opérations d’API «CreateCluster» et «RestorefromClustersNapshot», ainsi que dans les opérations Console Console, AWS CLI et AWS correspondantes.

Pour les clients utilisant des groupes de paramètres existants ou personnalisés, Redshift continuera d’honorer la valeur «Require SSL» spécifiée dans le groupe de paramètres du client. Cependant, AWS recommande aux administrateurs de mettre à jour ce paramètre à «vrai» pour améliorer la sécurité des connexions. Les administrateurs ont toujours la possibilité de modifier cette valeur dans leurs groupes de paramètres personnalisés selon les besoins. La procédure est décrite dans le guide de gestion du redshift Amazon pour la configuration des options de sécurité pour les connexions.

Amazon a également noté que ceux qui créaient des clusters non cryptés en utilisant des scripts automatisés ou en utilisant le partage de données avec des clusters non cryptés pourraient être affectés par les modifications. « Si vous créez régulièrement de nouveaux clusters de consommateurs non cryptés et que vous les utilisez pour le partage de données, passez en revue vos configurations pour vérifier que les grappes productrices et de consommateurs sont toutes deux cryptées pour réduire les chances que vous subissiez des perturbations dans vos charges de travail de partage de données », a-t-il conseillé.

Lorsqu’on lui a demandé pourquoi ces modifications sont apportées, Sirish Chandrasekaran, vice-président de Redshift, a déclaré que les défauts de sécurité supplémentaires aideront les clients à respecter les meilleures pratiques en matière de sécurité des données dès le premier jour sans nécessiter une configuration supplémentaire, réduisant le risque de erreurs de configuration potentielles.

Hors de la boîte, Redshift est livré avec un certain nombre de capacités de sécurité, y compris la prise en charge de l’authentification multi-facteurs, le chiffrement des données au repos, le contrôle d’accès et la gestion de l’identité et la fédération pour l’authentification unique. Mais ces outils et d’autres sont inutiles à moins qu’ils soient utilisés et correctement configurés.

Recommandations

Dans une série de blogs, Palo Alto Networks a fait un certain nombre de recommandations aux administrateurs de redshift:

  • Assurez-vous qu’ils savent exactement quels utilisateurs et rôles ont la possibilité d’utiliser la commande «Redshift: getClusterCredentials» et «Redshift-data». Un attaquant peut utiliser cette commande pour générer des informations d’identification temporaires pour accéder à un cluster Redshift;
  • Les administrateurs de Redshift peuvent créer des utilisateurs et des groupes et ne leur attribuer que les privilèges dont ils ont besoin. Les administrateurs doivent créer un utilisateur par identité, donc en cas d’incident de sécurité, il sera possible de suivre et de surveiller les données accédées, ou même d’empêcher un accès non autorisé avant qu’il ne se produise;
  • Étant donné que Redshift peut autoriser les rôles d’identité et d’accès qui permettent à un cluster de données d’accéder aux sources de données externes, assurez-vous que ces rôles sont limités à ceux qui ont besoin de cet accès.

Palo Alto Networks a également fourni plus de détails sur le contrôle d’accès dans un article de blog, et Sysdig a offert ces conseils sur les meilleures pratiques de sécurité de Redshift.

Enfin, Degioanni de Sysdig a prodigé cette prudence supplémentaire: «Bien que les fournisseurs de cloud fournissent un niveau de sécurité pour leur infrastructure et services sous-jacents, les organisations restent responsables de la protection de leurs propres applications et données dans le cadre d’un modèle de responsabilité partagé. Parce que les attaques peuvent se produire rapidement – parfois en quelques minutes – avoir une visibilité en temps réel dans les charges de travail de production est crucial pour détecter les risques actifs et répondre aux menaces au fur et à mesure qu’ils se produisent. »