AWS renforce la sécurité par défaut de Redshift

Si les experts en cybersécurité pointent régulièrement les problèmes de configuration des buckets S3 d’AWS, les entrepôts de données de Redshift constituent un point de vigilance. Dans ce cadre, le fournisseur de cloud a renforcé la protection de ce service cloud en désactivant l’accès public. Pour Loris Degioanni, directeur de la technologie chez Sysdig, cette évolution est la bienvenue et « nécessaire pour accompagner l'adoption accélérée du cloud dans les entreprises ayant une expertise variable en matière de sécurité ».

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 changements renforcent l'état d'esprit shift-left longtemps défendu par Sysdig. « Cependant, la sécurité ne se limite pas à de solides paramètres par défaut : la surveillance continue, la hiérarchisation des risques et la détection des menaces en temps réel sont essentielles », a ajouté l’expert. Redshift permet aux entreprises de stocker et d'analyser leurs données à l'aide des outils de business intelligence de leur choix. Selon HGInsights, un peu plus de 27 700 entreprises utilisent ce service.

Les changements

Les modifications concernent les paramètres par défaut de Redshift pour les clusters récemment créés, les groupes de travail Redshift Serverless et les clusters restaurés à partir de snapshots :

-L'accès public aux données a été désactivé. Les clusters récents ne seront accessibles qu'à l'intérieur du cloud privé virtuel (VPC) d'un client. Si un administrateur a besoin d'un accès public, il doit explicitement remplacer la valeur par défaut et définir le paramètre « PubliclyAccessible » sur « true » lors des opérations API « CreateCluster » ou « RestoreFromClusterSnapshot ». À noter que si les applications Redshift se trouvent dans un VPC autre que celui d'Amazon, les clients peuvent configurer l'accès inter-VPC.

-Avec un cluster accessible au public, AWS recommande aux administrateurs de toujours utiliser des groupes de sécurité ou des listes de contrôle d'accès au réseau (Access control list, ACL) pour limiter l'accès.

-Le chiffrement des bases de données est activé par défaut. En d'autres termes, il n'est plus possible de créer des clusters non chiffrés dans la console Redshift. Lorsqu'un administrateur utilise la console, la CLI, l'API ou CloudFormation pour créer un cluster provisionné sans spécifier de clé via Key Management Service (KMS) du fournisseur, le cluster sera automatiquement chiffré avec une clé appartenant et gérée par AWS.

-Les connexions sécurisées sont appliquées par défaut. Cela permet de chiffrer les communications entre les applications d'un client et l'entrepôt de données Redshift afin de protéger la confidentialité et l'intégrité des données transmises entre les applications du client et Redshift.

-Un groupe de paramètres par défaut dénommé « default.redshift-2.0 » est créé pour les clusters récemment créés ou restaurés, avec le paramètre « require_ssl » réglé sur « true » par défaut. Les clusters créés sans groupe de paramètres spécifié utiliseront automatiquement le groupe de paramètres « default.redshift-2.0 », qui sera sélectionné dans la console Redshift. Ce changement sera également reflété dans les opérations API « CreateCluster » et « RestoreFromClusterSnapshot », ainsi que dans les opérations correspondantes de la console AWS CLI et AWS CloudFormation.

Aider les clients à sécuriser dès le démarrage leurs clusters Redshift

Pour les clients qui utilisent des groupes de paramètres existants ou personnalisés, Redshift continuera à respecter 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 en le fixant sur la valeur « true » pour améliorer la sécurité des connexions. Les administrateurs peuvent toujours modifier cette valeur dans leurs groupes de paramètres personnalisés si nécessaire. La procédure est décrite dans le guide Redshift Management proposé par Amazon pour configurer les options de sécurité des connexions. Amazon a aussi indiqué que les personnes qui créent des clusters non chiffrés à l'aide de scripts automatisés ou qui utilisent le partage de données avec des clusters non chiffrés pourraient être affectées par ces changements. « Les utilisateurs qui créent régulièrement des clusters non chiffrés et les utilisent pour le partage de données, doivent revoir leurs configurations pour vérifier que les clusters du producteur et du consommateur sont tous deux chiffrés afin de réduire les risques d'interruption de leurs charges de travail de partage de données », a conseillé le fournisseur.

Interrogé sur les raisons de ces changements, le vice-président de Redshift, Sirish Chandrasekaran a expliqué que les paramètres de sécurité par défaut aideront les clients à adhérer aux meilleures pratiques de sécurité des données dès le premier jour, sans nécessiter de configuration supplémentaire, ce qui réduira le risque d'éventuelles erreurs de paramétrage. Redshift est livré avec un certain nombre de fonctionnalités de sécurité, notamment la prise en charge de l'authentification multifactorielle, le chiffrement des données au repos, le contrôle d'accès et la gestion des identités, ainsi que la fédération pour l'authentification SSO (Single Sign-On) unique. Mais ces outils et d'autres ne servent à rien s'ils ne sont pas utilisés et correctement configurés.

Plusieurs recommandations de Sysdig et de Palo Alto Networks

Dans une série de blogs, Palo Alto Networks a formulé un certain nombre de recommandations à l'intention des administrateurs de Redshift :

-s'assurer qu'ils savent exactement quels utilisateurs et quels rôles peuvent utiliser la commande « redshift:GetClusterCredentials » et « redshift-data », un attaquant pouvant utiliser cette commande pour générer des identifiants temporaires afin d'accéder à un cluster Redshift.

-Les administrateurs de Redshift peuvent créer des utilisateurs et des groupes et leur attribuer uniquement les privilèges dont ils ont besoin. Les administrateurs devraient créer un utilisateur par identité, de sorte qu'en cas d'incident de sécurité, ils pourront suivre et contrôler les données auxquelles on a accédé, voire d'empêcher tout accès non autorisé avant qu'il ne se produise.

-Redshift peut autoriser des rôles d'identité et d'accès qui permettent à un cluster de données d'accéder à des sources de données externes, mais il faut s'assurer que ces rôles sont limités aux seules personnes ayant besoin de cet accès.

Palo Alto Networks a également fourni plus de détails sur le contrôle d'accès dans un blog, et Sysdig a donné ce conseil sur les meilleures pratiques de sécurité pour Redshift. Enfin, M. Degioanni de Sysdig, a fait cette mise en garde supplémentaire : « Même si les fournisseurs de cloud offrent un niveau de sécurité pour leur infrastructure et leurs services sous-jacents, les entreprises restent responsables de la protection de leurs propres applications et données dans le cadre d'un modèle de responsabilité partagée. Les attaques pouvant survenir rapidement, parfois en quelques minutes, la visibilité en temps réel sur les charges de travail de production est essentielle pour détecter les risques actifs et répondre aux menaces dès qu'elles se produisent. »