Sécuriser votre Azure Table Storage

Azure Table Storage fournit un stockage clé-valeur NoSQL pour les données structurées et non relationnelles. La sécurité des tables partage les fondamentaux avec les autres services de données stockage Azure, mais présente quelques particularités – notamment une surface d’autorisation Microsoft Entra ID distincte et un chevauchement avec l’API Azure Cosmos DB for Table – qui méritent d’être soulignées.

Note

Cet article traite des pratiques de sécurité spécifiques à Azure Table Storage. Pour des conseils de sécurité au niveau du compte, consultez Sécuriser votre compte stockage Azure.

Sécurité spécifique au service

Azure Table Storage et Azure Cosmos DB for Table API exposent tous deux un modèle de données de table similaire, mais leurs capacités de sécurité diffèrent considérablement. Choisissez la plateforme qui répond à vos exigences de sécurité dès le début du projet. La migration des données entre elles n’est pas anodine.

  • Utilisez Azure Cosmos DB pour Table lorsque vous avez besoin d’un débit dédié, d’une distribution globale ou d’une isolation réseau plus fine par charge de travail de table : Cosmos DB for Table API est une ressource distincte avec ses propres terminaux privés, pare-feu et configuration IAM, indépendante de tout compte de stockage. Cela vous offre un périmètre d’impact isolé lorsque la charge de travail liée à Table a des exigences en matière de réseau ou de gouvernance différentes de celles des charges de travail qui partagent votre compte de stockage à usage général. Pour plus d’informations, consultez Présentation d’Azure Cosmos DB pour Table.

  • Utilisez Azure Table Storage lorsque vous avez besoin de co-localisation au niveau du compte avec blobs, fichiers et files d’attente : Table Storage réside dans un compte de stockage général, donc un ensemble unique de règles réseau, de terminaux privés et de politiques d’identité s’appliquent à tous les quatre services de données. Cosmos DB for Table est une ressource distincte avec une configuration de sécurité indépendante.

Gestion de l’identité et de l’accès

  • Utilisez Microsoft Entra ID pour autoriser les opérations de données de table : l’autorisation Entra ID supprime le besoin de clés de compte dans le code de l’application et fournit des traces d’audit basées sur l’identité. Attribuez les rôles intégrés Lecteur des données de table de stockage ou Contributeur aux données de table de stockage au niveau de la table lorsque cela est possible. Pour plus d’informations, voir Autoriser l’accès aux tables à l’aide de Microsoft Entra ID.

  • Attribuer des rôles d’étendue à des tables spécifiques : l’étendue au niveau de la table est prise en charge pour les rôles de données intégrés dans la table. Lorsqu’un service n’a besoin d’accéder qu’à une seule table, attribuez le rôle à la ressource de table plutôt qu’au compte.

  • Étendez les jetons SAS à des plages de partitions et de clés de ligne spécifiques : le SAS de table prend en charge les restrictions de plage de clés de partition et de clés-lignes. Utilisez-les pour limiter un jeton aux lignes d’un seul locataire dans une table multilocataire, ou à une tranche de données spécifique. Pour plus d’informations, consultez Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAS).

  • N’accordez que les opérations de table nécessaires : un SAS de table prend en charge séparément les autorisations query, add, update et delete. Un appelant en mode lecture ne doit conserver que query, jamais update ni delete.

Protection de données

Table Storage stocke les entités sous forme de simples ensembles de propriétés, sans ACL propres à chaque entité. Prenez en compte la sécurité dans votre stratégie de partitionnement plutôt que d’essayer de réadapter le contrôle d’accès.

  • Partitionnez les tables en fonction des limites d’accès : lorsqu’une table sert plusieurs locataires ou niveaux de classification, choisissez une clé de partition qui regroupe les entités par locataire ou par classification. Associez cela aux restrictions de plage de clés de partition imposées par les SAS pour garantir l’isolation entre locataires sans avoir à créer une table distincte pour chaque locataire.

  • Ne stockez pas de secrets ou de données personnelles inutiles dans les propriétés de l’entité : Les entités sont visibles pour tout principal possédant query ou read ayant accès à la table ou à la partition. Stockez les secrets dans Azure Key Vault avec des références dans l’entité, et minimisez les données personnelles que vous placez dans les propriétés interrogables.

  • Chiffrez les valeurs de propriétés sensibles au niveau de l’application : Pour les valeurs de propriété qui doivent rester confidentielles, chiffrez la valeur dans le client avec une clé de Key Vault avant insertion ou mise à jour. Ce chiffrement est indépendant du chiffrement côté stockage appliqué à l’ensemble de la table. Pour plus d’informations sur les clés, consultez À propos des clés.

Enregistrement et surveillance

  • Activez les paramètres de diagnostic pour les opérations de table : envoyer StorageRead, StorageWrite, et StorageDelete catégories vers Log Analytics. Alertez en cas de méthodes d’autorisation inattendues, en particulier l’accès à la clé partagée sur les comptes où il devrait être désactivé. Pour plus d’informations, voir Monitoring Azure Table Storage.

  • Alerte lors d’opérations de suppression ou de mise à jour à fort volume : Une activité massive DeleteEntityUpdateEntity ou déviée de la base de la table peut indiquer une destruction ou une altération des données. Établissez une base de référence et alertez les écarts.

Étapes suivantes

  • Dernière mise à jour :