Appliquer les meilleures pratiques de sécurité de Stockage Azure

Effectué

Nous avons passé en revue la procédure permettant de créer et d’utiliser une signature d’accès partagé (SAS) et les avantages qu’elle peut présenter pour votre solution de sécurité du stockage.

Il est important de comprendre que des risques potentiels existent quand vous utilisez une signature SAS dans votre application.

  • Si un SAS est compromis, toute personne qui l'obtient peut accéder au stockage.

  • Si une signature SAS fournie à une application cliente expire et que l’application n’est pas en mesure d’en récupérer une nouvelle à partir de votre service, la fonctionnalité de l’application risque d’être entravée.

Regardez cette vidéo pour découvrir des idées supplémentaires sur la façon de sécuriser votre stockage. Cette vidéo repose sur les conseils et astuces Azure #272 Bonnes pratiques de sécurité Azure.

Recommandations concernant la gestion des risques

Examinons quelques recommandations permettant d’atténuer les risques lors de l’utilisation d’une signature SAS.

Recommandation Description
Toujours utiliser le protocole HTTPS pour la création et la distribution Si une signature SAS est transmise via le protocole HTTP et interceptée, un attaquant risque de l’intercepter et de l’utiliser. Ces attaques de l’intercepteur peuvent compromettre des données sensibles ou permettre à l’utilisateur malveillant d’altérer les données.
Référencer les stratégies d’accès stockées si possible Les stratégies d’accès stockées vous donnent la possibilité de révoquer les autorisations sans avoir à régénérer les clés de compte de stockage Azure. Définissez une date d’expiration éloignée dans le futur pour la clé du compte de stockage.
Définir des délais d’expiration à court terme pour une signature SAS non planifiée Si une signature SAS est compromise, vous pouvez atténuer les attaques en limitant la validité de la signature SAS à une période courte. Cette pratique est importante si vous ne pouvez pas référencer une stratégie d’accès stockée. Des heures d’expiration avec une échéance à court terme permettent également de limiter la quantité de données pouvant être écrites dans un objet blob en limitant le temps disponible pour le chargement vers ce dernier.
Demander aux clients de renouveler automatiquement la signature SAS Demandez aux clients de renouveler la signature SAS bien avant la date d’expiration. En la renouvelant de manière anticipée, vous leur laissez le temps de réessayer si le service fournissant la signature SAS n’est pas disponible.
Planifier soigneusement la date de début de la signature SAS Si vous définissez la date de début d’une signature SAS sur l’heure actuelle, des défaillances peuvent être observées par intermittence pendant les premières minutes en raison des variations d’horloge (différences de l’heure actuelle sur différentes machines). En règle générale, définissez une heure de début située au moins 15 minutes dans le passé. Vous pouvez également ne définir aucune heure de début spécifique, ce qui entraîne la validité immédiate de la signature SAS dans tous les cas. Les mêmes conditions s’appliquent généralement à l’heure d’expiration. Vous pouvez observer jusqu’à 15 minutes de variation d’horloge (dans un sens ou dans l’autre) sur une demande. Pour les clients qui utilisent une version d’API REST antérieure à 2012-02-12, la durée maximale pour une signature SAS qui ne référence pas une stratégie d’accès stockée est d’une heure. Toutes les stratégies spécifiant une période plus longue échouent.
Définissez les autorisations d’accès minimales pour les ressources Une bonne pratique en matière de sécurité consiste à fournir à l’utilisateur les privilèges minimaux requis. Si un utilisateur a besoin d'un accès en lecture à une seule entité, accordez-lui un accès en lecture à cette seule entité, plutôt qu'un accès en lecture/écriture/suppression à toutes les entités. Cette pratique permet également de limiter les dégâts si une signature SAS est compromise, car son pouvoir est moindre si elle tombe entre les mains d’un attaquant.
Comprendre la facturation des comptes pour l’utilisation, notamment une signature SAS Accordez des autorisations limitées pour atténuer les risques liés aux actions éventuelles d’utilisateurs malveillants. Les autorisations de lecture et d’écriture peuvent entraîner des frais de facturation. Utilisez une SAP de courte durée pour réduire cette menace.
Valider les données écrites avec une signature SAS Quand une application cliente écrit des données dans votre compte de stockage Azure, n’oubliez pas que ces données peuvent être une source de problèmes. Si votre application nécessite des données validées ou autorisées, validez les données après leur écriture, mais avant leur utilisation. Cette pratique assure également une protection contre l'écriture de données endommagées ou malveillantes dans votre compte, soit par un utilisateur qui a acquis correctement la signature d'accès partagé, soit par un utilisateur qui exploite sa divulgation.
Ne pas partir du principe qu’une signature SAS est toujours la meilleure option Dans certains scénarios, les risques associés à une opération particulière sur votre compte de stockage Azure sont plus importants que les avantages de l’utilisation d’une signature SAS. Pour ces opérations, créez un service de niveau intermédiaire qui écrit dans votre compte de stockage après avoir effectué la validation des règles métier, l'authentification et un audit. Il est également parfois plus simple de gérer l’accès par d’autres moyens. Si vous souhaitez que l’ensemble des objets blob dans un conteneur soient lisibles publiquement, vous pouvez rendre le conteneur public, au lieu de fournir une signature SAS d’accès à chaque client.
Superviser vos applications avec Azure Storage Analytics Vous pouvez utiliser la journalisation et les métriques pour observer tout pic des échecs d’authentification. Vous pouvez constater des pics dus à une interruption de votre service fournisseur SAS ou à la suppression accidentelle d’une stratégie d’accès stockée.