Dépannage des erreurs 403 dans Stockage Blob Azure

Résumé

Cet article fournit des conseils pour résoudre les erreurs HTTP 403 dans Stockage Blob Azure. Il comprend une liste de contrôle complète des causes et solutions potentielles, couvrant l’authentification, l’autorisation, les restrictions réseau, les stratégies de chiffrement, etc.

Lorsque vous accédez à Stockage Blob Azure, vous pouvez rencontrer des erreurs HTTP 403 qui empêchent les clients de lire, d’écrire ou de gérer des données. Ces erreurs peuvent provenir de divers problèmes de configuration ou d’autorisation, notamment les attributions de rôles, les paramètres de jeton, les restrictions réseau, les stratégies de chiffrement, etc. Cet article fournit une liste de contrôle complète et des conseils de dépannage pour vous aider à identifier la cause racine des erreurs 403 et à les résoudre efficacement. Si vous connaissez déjà le code d’erreur ou la catégorie de cause, utilisez les liens de la liste de contrôle de diagnostic pour accéder directement à la section appropriée.

Environ 403 erreurs

Une erreur 403 est un code d’état HTTP qui inclut la chaîne 403 (par exemple). Forbidden (403) Chaque erreur 403 est accompagnée d’un code d’erreur plus spécifique, tel que UnauthorizedBlobOverwrite ou QueryParameterSasMandatory. Ces codes d’erreur détaillés peuvent vous aider à affiner la cause du problème. Les articles suivants décrivent les types les plus courants d’erreurs 403 :

Une erreur 403 peut provenir d’opérations de plan de contrôle ou de plan de données . Les opérations de plan de contrôle sont des requêtes Azure Resource Manager, telles que la création d’un compte de stockage ou la mise à jour de ses propriétés. Les opérations de plan de contrôle impliquent des demandes adressées au point de terminaison du service de stockage, telles que le chargement ou le téléchargement de blobs. Vous pouvez utiliser les journaux des ressources Azure pour trouver des détails d’erreur, notamment des informations sur le principal de sécurité, la clé ou le SAS utilisé pour l’autorisation.

Les échecs d’authentification se produisent lorsqu’il existe des problèmes liés aux informations d’identification, aux jetons ou aux méthodes d’authentification.

Erreur Causes et solutions
Message d’erreur
Le serveur n'a pas pu authentifier la requête. Vérifiez que la valeur de l’en-tête d’autorisation est formée correctement, avec la signature.

Code d’erreur
Échec de l’authentification

Détails de l’erreur
L’heure <date> d’expiration signée doit être après l’heure de début signée <date>		 Jeton expiré : le jeton SAP a passé son délai d’expiration. Générez un nouveau jeton SAP avec une heure d’expiration ultérieure.

Décalage d’horloge : les différences de temps entre les systèmes peuvent faire apparaître les jetons expirés tôt. Envisagez d’ajouter du temps de latence à l’expiration.

Heure de début à l’avenir : évitez de définir une heure de début si la SAP est utilisée immédiatement.
Message d’erreur
Le serveur n'a pas pu authentifier la requête. Vérifiez que la valeur de l’en-tête d’autorisation est formée correctement, avec la signature.

Code d’erreur
Échec de l’authentification

Détails de l’erreur
Signature MAC trouvée dans la requête HTTP ' xyz...' n’est pas identique à une signature calculée.		 Clé de compte incorrecte : vérifiez que vous utilisez la clé primaire ou secondaire correcte pour le compte de stockage.

Clés régénérées : si les clés d’accès de stockage ont été récemment régénérées, mettez à jour votre application avec la nouvelle clé.

Problèmes d’encodage : vérifiez que la clé de compte est correctement encodée et mise en forme.
Message d’erreur
Le serveur n'a pas pu authentifier la requête. Vérifiez que la valeur de l’en-tête d’autorisation est formée correctement, avec la signature.

Code d’erreur
Échec de l’authentification

Détails de l’erreur
Le champ SAS 'sv' n’est pas bien formé.		 Format SAS non valide : utilisez des kits de développement logiciel (SDK) Azure officiels ou des outils tels que l’Explorateur Stockage pour générer des jetons SAP.

Erreurs de construction manuelles : si vous construisez manuellement des jetons SAP, vérifiez tous les champs requis et leurs formats.

Incompatibilité de version : vérifiez que le sv paramètre (version) correspond à la version de votre bibliothèque cliente de stockage.
Message d’erreur
Le serveur n'a pas pu authentifier la requête. Vérifiez que la valeur de l’en-tête d’autorisation est formée correctement, avec la signature.

Code d’erreur
Échec de l’authentification

Détails de l’erreur
La ressource signée spécifiée n’est pas autorisée pour ce niveau de ressource		 SAS de service ou SAS de compte : vous utilisez un SAS de service (pour des blobs ou des conteneurs spécifiques) pour des opérations au niveau du compte.

Incompatibilité d’étendue : générez le type SAS approprié pour votre opération. Utilisez un SAS de compte pour les opérations au niveau du compte (lister les conteneurs), et utilisez un SAS de service pour des opérations spécifiques sur des objets blob ou des conteneurs.
Message d’erreur
L’authentification basée sur une clé n’est pas autorisée sur ce compte de stockage.

Code d’erreur
AuthentificationBaséeSurCléNonPermise		 Restriction de stratégie : le compte de stockage est configuré pour interdire l’authentification par clé partagée.

Basculez vers Microsoft Entra ID : utilisez l’authentification Microsoft Entra ID au lieu des clés de compte.

Activer la clé partagée : si nécessaire, réactivez l’accès à la clé partagée dans la configuration du compte de stockage.

Les échecs d’autorisation se produisent lorsqu’un client dispose d’informations d’identification valides, mais qu’il dispose d’autorisations insuffisantes pour l’opération demandée.

Erreur Causes et solutions
Message d’erreur
Cette demande n’est pas autorisée à effectuer cette opération à l’aide de cette autorisation.

Code d’erreur
AuthorizationPermissionMismatch		 Autorisations manquantes : le jeton SAP n’inclut pas l’autorisation requise (lecture, écriture, suppression, liste).

Exigences relatives aux opérations : certaines opérations nécessitent plusieurs autorisations (par exemple, le remplacement d’un objet blob nécessite à la fois l’écriture et la suppression).

Vérifiez les autorisations SAP : vérifiez le sp champ (autorisations) de votre jeton SAP inclut toutes les autorisations nécessaires.

Rôle RBAC Azure insuffisant : l’utilisateur ou le principal de service n’a pas le rôle requis pour l’opération.

Pour les opérations de lecture, utilisez le lecteur de données Blob de stockage.
Pour les opérations d’écriture, utilisez le rôle Storage Blob Data Contributor.
Pour les opérations de gestion, utilisez Storage Blob Data Owner.

Étendue d’attribution de rôle : vérifiez que les rôles sont affectés à l’étendue appropriée (abonnement, groupe de ressources, compte de stockage ou conteneur).
Message d’erreur
Cette demande n’est pas autorisée à effectuer cette opération à l’aide de ce service.

Code d’erreur
IncompatibilitéDuServiceD'Autorisation		 Type de service incorrect : le jeton SAP a été créé pour un autre service stockage Azure.

Incompatibilité des champs de service : vérifiez le ss champ (services) dans votre jeton SAP.
Utiliser b pour le service Blob
Utiliser f pour le service de fichiers
Utiliser q pour le service de file d'attente
Utiliser t pour le service Table.
Message d’erreur
Cette requête n’est pas autorisée à effectuer cette opération

Code d’erreur
Échec de l’autorisation		 Accès réseau public désactivé : le compte de stockage n’autorise pas l’accès au réseau public.

Restrictions d’adresse IP : votre adresse IP n’est pas incluse dans les plages d’adresses IP autorisées.

Restrictions de réseau virtuel : l’accès est limité à des réseaux virtuels ou sous-réseaux spécifiques.

Par défaut, le trafic vers tous les sous-réseaux est bloqué. Les demandes adressées aux ressources d’un sous-réseau reçoivent une erreur 403 jusqu’à ce que vous ajoutiez une règle qui autorise le trafic vers ce sous-réseau.

Règles de pare-feu : le pare-feu du compte de stockage bloque votre demande.

Liste de contrôle complète pour le diagnostic des erreurs 403

Si vous recevez une erreur autre que les erreurs décrites dans les sections précédentes, ou si les causes et solutions décrites dans ces sections ne vous aident pas à résoudre votre erreur, utilisez cette liste de contrôle comme guide pour identifier la cause et trouver une solution.

  • Transfert de fichiers sécurisé : si le transfert sécurisé est nécessaire, assurez-vous que les demandes sont effectuées via HTTPS. (En savoir plus).

  • Contrôle d’accès en fonction du rôle Azure : vérifiez que le principal de sécurité a le rôle RBAC Azure approprié. (En savoir plus).

  • Jetons de signature d’accès partagé (SAP) : vérifiez l’expiration, les autorisations et la méthode de génération du jeton. (En savoir plus).

  • SAS de délégation d’utilisateur : Confirmez les champs, autorisations et l’état de la clé requis pour la SAS de délégation d’utilisateur. (En savoir plus).

  • Stratégies d’accès stockées : passez en revue les paramètres de stratégie d’accès stocké et le délai de propagation. (En savoir plus).

  • Listes de contrôle d’accès (ACL) : vérifiez que les entrées et autorisations de liste de contrôle d’accès sont correctes pour le client. (En savoir plus).

  • Autorisation de clé partagée : si vous utilisez une clé de compte, vérifiez que l’autorisation de clé partagée est autorisée. (En savoir plus).

  • Point de terminaison de réseau public : vérifiez l’accès au point de terminaison public, les règles de pare-feu et le périmètre de sécurité réseau. (En savoir plus).

  • Points de terminaison privés : validez le sous-réseau de point de terminaison privé et la configuration des ressources. (En savoir plus).

  • Étendues de chiffrement : passez en revue les paramètres d’étendue de chiffrement et l’état de la clé gérée par le client. (En savoir plus).

  • Comptes désactivés : vérifiez que le compte de stockage ou l’abonnement n’est pas désactivé. (En savoir plus).

  • Azure Databricks et Azure RBAC : définissez les rôles au niveau du groupe de ressources, du compte ou du conteneur. (En savoir plus).

  • Vérifier l’étendue des opérations de copie : vérifiez si les paramètres du compte limitent l’étendue des opérations de copie. (En savoir plus).

Jetons SAP

Les causes courantes des erreurs 403 lorsque vous utilisez des jetons SAP sont les suivantes :

  • Expiration ou heure de début du jeton SAP inappropriée : L’expiration et les heures de début du jeton SAP ne sont pas définies correctement pour l’utilisation prévue.

  • Autorisations manquantes : Toutes les autorisations nécessaires ne sont pas sélectionnées pour le jeton SAP.

  • Autorisations insuffisantes : Le client tente une opération qui n’est pas autorisée par le jeton SAP. Par exemple, le client essaye d’écrire dans un objet blob avec un SAS qui autorise uniquement les opérations de lecture. Certaines actions nécessitent une autorisation supplémentaire. Par exemple, pour qu’un client remplace un objet blob, le jeton SAP doit autoriser l’autorisation d’écriture et de suppression.

  • Méthode de génération de jeton : Vous n'avez pas généré le jeton SAP à l'aide d'un kit de développement logiciel (SDK) ou d'un outil officiel (par exemple, Explorateur Stockage). Pour éviter les erreurs dans la chaîne de signature, envisagez d’utiliser des sdk officiels pour générer des jetons SAP. Si vous construisez manuellement des jetons SAP, utilisez la dernière version et les bibliothèques du service de stockage. Consultez Délégation d’accès avec une signature d’accès partagé.

  • Jeton SAP expiré : Le client utilise un jeton SAP qui a expiré.

  • Décalage d’horloge : De légers écarts temporels entre l’hôte qui génère le SAS et le service de stockage peuvent rendre le SAS non valide ou le faire expirer plus tôt que prévu.

  • Heure de début SAS incorrecte : Évitez de définir une heure de début si le SAS est destiné à une utilisation immédiate, car les différences d’horloge peuvent le rendre invalide.

  • Délai d’expiration court : La définition d’une durée d’expiration courte peut entraîner une expiration prématurée en raison des différences d’horloge.

  • Incompatibilité de version : Le sv paramètre (version) du jeton SAP doit correspondre à la version de la bibliothèque cliente de stockage en cours d’utilisation. Utilisez toujours la dernière version de la bibliothèque.

  • Clés d’accès régénérées : Si vous régénérez des clés d’accès au stockage, vous pouvez invalider les jetons SAP existants, en particulier ceux avec des délais d’expiration longs.

  • Signature incorrecte : La signature SAP ou clé partagée est incorrectement formée, encodée ou contient des paramètres non valides.

  • Adresse IP non autorisée : La requête provient d’une adresse IP non autorisée par le jeton SAP. Vérifiez que le champ « sip » correspond à l’adresse IP du client.

  • Interférence par une stratégie d’accès stockée : Un conteneur avec des stratégies d’accès stockées peut remplacer l’autorisation donnée par une SAP. Par exemple, une stratégie d’accès stockée sur un conteneur peut révoquer l’autorisation avant la date et l’heure d’expiration SAS.

Consultez les meilleures pratiques lors de l’utilisation de SAP.

Jetons SAP de délégation d’utilisateur

Les causes courantes des erreurs 403 lorsqu’elles sont associées aux jetons SAP de délégation d’utilisateur sont les suivantes :

  • Champs obligatoires manquants : Vérifiez que tous les champs obligatoires spécifiques à la SAP de délégation d’utilisateur sont présents : skoid, , sktidskt, et ske. En cas d’absence, l’authentification échoue.

  • Version de l’API non prise en charge : Seules les versions de l’API REST ultérieures à « 2018-11-09 » sont prises en charge pour la SAS de délégation d’utilisateur.

  • Jeton non valide : Les heures de début st et de fin se du jeton SAS doivent se trouver dans les heures de début skt et de fin ske de la clé de délégation.

  • Minutage de la demande : L’heure de début de la requête doit se trouver dans la fenêtre de temps valide du jeton SAP.

  • Incompatibilité de signature : La signature SAP fournie par le client doit correspondre à la signature générée par le service de stockage. Par exemple, une SAP créée pour le conteneur X échoue si elle est utilisée pour accéder au conteneur Y.

  • Autorisation SAP insuffisante : Le jeton SAP doit autoriser l’opération demandée. Par exemple, une autorisation « Lecture » ne peut pas être utilisée pour une demande « Écriture ». Vérifiez le champ « sp ».

  • Rôle RBAC Azure insuffisant : L’utilisateur doit disposer du rôle Azure nécessaire pour l’opération demandée. Par exemple, une opération d’écriture nécessite le rôle Contributeur aux données Blob de stockage.

  • Authentification OAuth : Vérifiez que les autorisations OAuth (Azure RBAC) sont passées pour l’opération demandée.

  • Clé révoquée : La requête est effectuée après la révocation ou l’expiration de la clé de délégation de l’utilisateur.

Consultez Créer une SAS de délégation d'utilisateur.

Politiques d'accès enregistrées

Lorsque vous utilisez des stratégies d’accès stockées, passez en revue les éléments suivants :

  • Paramètres de stratégie : Vérifiez que les autorisations, l’heure de début et l’heure d’expiration définies dans la stratégie d’accès stockée sont correctes pour votre scénario.

  • Jeton SAP : Vérifiez que le jeton SAP associé à la stratégie correspond aux autorisations et à la fenêtre de temps prévues.

Après avoir appliqué ou mis à jour une stratégie d’accès stockée, autorisez jusqu’à 30 secondes pour que la stratégie prenne effet. Pendant cet intervalle, toute SAP associée à la stratégie peut échouer avec une erreur 403 (Interdit) jusqu’à ce que la stratégie devienne active.

Pour plus d’informations, consultez Définir une stratégie d’accès stockée.

Listes ACL

Lorsque vous utilisez des listes de contrôle d’accès pour autoriser l’accès aux fichiers et répertoires, passez en revue les éléments suivants.

  • Appartenance au principal de sécurité : Le principal de sécurité utilisé par le client doit apparaître dans une entrée de liste de contrôle d’accès pour le fichier ou le répertoire cible. Si l’entrée ACL inclut uniquement des groupes de sécurité, le principal doit être membre de l’un de ces groupes.

  • Autorisations correctes : L’entrée de liste de contrôle d’accès associée au principal de sécurité accorde le niveau d’autorisation approprié pour l’opération prévue.

  • Le sticky bit n’est pas activé : Les ACL comportent un paramètre appelé « sticky bit », qui peut également provoquer des erreurs 403. Si le bit sticky est activé sur un répertoire, seul le propriétaire de l’élément enfant, le propriétaire du répertoire ou le superutilisateur ($superuser) peut supprimer ou renommer des éléments enfants. Pour en savoir plus, consultez l’erreur d’autorisation 403 Accès refusé lorsque le bit sticky est activé dans ADLS Gen2.

Pour plus d’informations sur les listes de contrôle d’accès, consultez listes de contrôle d’accès (ACL) dans Azure Data Lake Storage Gen2.

Point de terminaison de réseau public

Si le client reçoit une erreur 403 lors de l’accès à un compte de stockage via son point de terminaison public, passez en revue les éléments suivants.

  • Règles de pare-feu : Si les règles de pare-feu sont activées, assurez-vous que le client effectue des requêtes à partir d’une adresse IP ou d’un sous-réseau autorisé. Si le compte de stockage autorise le trafic uniquement à partir d’un sous-réseau de réseau virtuel spécifique, toute tentative d’accès aux données à partir d’un réseau public est interdite. Par exemple, si un utilisateur tente d’accéder au compte de stockage à partir du portail Azure (qui utilise le réseau du navigateur) ou à partir d’un ordinateur local, une erreur 403 s’affiche, sauf si vous ajoutez l’adresse IP du réseau de navigateur ou de l’ordinateur local aux règles d’adresse IP. Consultez les règles de pare-feu stockage Azure.

  • Accès source et de destination : Pour les opérations qui copient des données entre des comptes de stockage, le client doit disposer d’un accès réseau aux comptes source et de destination.

  • Azure l'accès au service : si l'erreur 403 provient d'autres services qui doivent interagir avec le serveur principal de votre compte de stockage, vérifiez que le service est ajouté en tant qu'instance de ressource autorisée ou qu'une exception de sécurité réseau pour les services de Azure approuvés est configurée. Consultez les services Azure approuvés.

  • Règles de périmètre de sécurité réseau : Si le compte de stockage fait partie d’un périmètre de sécurité réseau, ces règles remplacent les paramètres de pare-feu. Même si le client est autorisé par le pare-feu, une règle de périmètre de sécurité réseau restrictive peut toujours entraîner une erreur 403. Activez les journaux de ressources pour identifier la règle à l’origine du problème. Voir Journaux de diagnostic pour le périmètre de sécurité réseau.

  • Stratégies de point de terminaison de service : Si une stratégie de point de terminaison de service est définie pour le groupe de ressources, l’abonnement ou le compte de stockage, passez en revue les règles de stratégie. Supprimez la politique ou assurez-vous que le compte de stockage est inclus. Les modifications apportées aux stratégies de point de terminaison de service peuvent prendre jusqu’à 15 minutes. Consultez les stratégies de point de terminaison de service de réseau virtuel pour stockage Azure.

Points de terminaison privés

Si le client reçoit une erreur 403 lors de l’accès à un compte de stockage via un point de terminaison privé, passez en revue les éléments suivants.

  • Paramètres DNS (Domain Name System) : Assurez-vous que la résolution DNS du nom du compte de stockage est résolue en adresse IP privée. Une configuration DNS peut résoudre le compte de stockage vers le point de terminaison public. Mettez à jour la configuration DNS afin que les clients du réseau accèdent réellement au point de terminaison privé. Consultez les modifications DNS pour les points de terminaison privés.

  • Connectivité de réseau virtuel hub : Pour copier des objets blob entre des comptes de stockage avec des points de terminaison privés dans différents réseaux virtuels spoke à partir d’une machine virtuelle dans un réseau virtuel Hub, vérifiez la connectivité réseau et passez en revue les journaux d’erreurs pour CannotVerifyCopySource. Consultez Copier des objets blob entre des comptes de stockage dans une architecture hub-spoke à l’aide de points de terminaison privés.

  • Points de terminaison privés pour chaque ressource de stockage : Vérifiez que le compte de stockage dispose de points de terminaison privés pour la ressource Data Lake Storage et la ressource Stockage Blob. Certaines opérations peuvent être redirigées entre les points de terminaison, ce qui nécessite que les deux soient présentes.

  • Accès source et de destination : Lors de la copie d’objets blob entre des comptes de stockage, le client doit disposer d’un accès réseau aux deux comptes. Si vous utilisez une liaison privée pour un seul compte, vérifiez également l’accès réseau à l’autre compte.

Pour la résolution des problèmes généraux, consultez Résoudre les problèmes de connectivité de point de terminaison privé Azure.

Étendues de chiffrement

Lorsque vous utilisez des étendues de chiffrement, passez en revue les éléments suivants.

Comptes désactivés

Une erreur 403 peut se produire si vous tentez d’accéder aux données d’un compte de stockage ou d’un abonnement désactivé. Les raisons courantes d’un abonnement désactivé incluent le crédit expiré, l’atteinte d’une limite de dépense, des factures en retard, le dépassement de votre limite de carte de crédit ou l’administrateur de compte qui annule l’abonnement.

Attributions de rôles Azure Databricks et RBAC Azure

Une erreur 403 peut se produire si votre abonnement inclut un espace de noms Azure Databricks. Les rôles définis au niveau de l’abonnement ne donnent pas accès aux données blob. Attribuez plutôt des rôles au niveau du groupe de ressources, du compte de stockage ou du conteneur. Pour réaffecter un rôle, accédez au compte de stockage dans le portail Azure, sélectionnez Contrôle d’accès (IAM) et ajoutez l’attribution de rôle dans l’étendue du conteneur ou du compte de stockage.

Voir aussi

  • Last updated on