Partager via

Stockage isolé

  • Article

Pour les applications de bureau, le stockage isolé est un mécanisme de stockage de données qui offre une isolation et une sécurité en définissant des méthodes standardisées pour associer du code à des données enregistrées. La standardisation offre également d'autres avantages. Les administrateurs peuvent utiliser des outils conçus pour manipuler un stockage isolé afin de configurer l'espace de stockage du fichier, de définir des stratégies de sécurité et de supprimer des données inutilisées. Grâce au stockage isolé, votre code ne nécessite plus de chemins d'accès uniques pour spécifier des emplacements sécurisés dans le système de fichiers. En outre, les données sont protégées des autres applications qui possèdent uniquement un accès au stockage isolé. Les informations codées en dur concernant l'emplacement de la zone de stockage d'une application ne sont pas nécessaires.

Important

Le stockage isolé n’est pas disponible pour les applications Windows 8.x Store. À la place, utilisez les classes de données d’application des espaces de noms Windows.Storage inclus dans l’API Windows Runtime pour stocker des données locales et des fichiers. Pour plus d’informations, consultez Données d’applications dans le Centre de développement Windows.

Magasins et compartiments de données

Lorsqu’une application stocke des données dans un fichier, le nom de fichier et l’emplacement de stockage doivent être choisis avec soin afin de réduire la possibilité que l’emplacement de stockage soit connu d’une autre application et, par conséquent, vulnérable en termes d’endommagement. Sans un système standard pour gérer ces problèmes, improviser des techniques adéquates qui minimisent les conflits de stockage peut être complexe et les résultats peuvent être incertains.

Grâce au stockage isolé, les données sont toujours isolées par utilisateur et par assembly. Les informations d'identification telles que l'origine ou le nom fort de l'assembly déterminent l'identité de l'assembly. Les données peuvent également être isolées par domaine d'application, en utilisant des informations d'identification similaires.

Lors de l'utilisation du stockage isolé, votre application enregistre des données dans un seul compartiment de données associé à un aspect de l'identité du code, tel que son éditeur ou sa signature. Le compartiment de données est une abstraction et non un emplacement de stockage spécifique ; il est composé d'au moins un fichier de stockage isolé, appelé un magasin, contenant des emplacements de répertoire réels où sont stockées les données. Par exemple, une application peut comprendre un compartiment de données qui lui est associé, et un répertoire du système de fichiers implémente le magasin qui préserve réellement les données de cette application. Les données enregistrées dans le magasin peuvent être de tout type, à partir des informations sur les préférences de l'utilisateur à des informations sur l'état de l'application. Pour le développeur, l'emplacement du compartiment de données est transparent. Les magasins résident généralement sur le client, mais une application serveur peut utiliser des magasins isolés pour stocker des informations en empruntant l'identité de l'utilisateur légitime. Le stockage isolé peut également stocker des informations sur un serveur avec le profil itinérant d'un utilisateur, de sorte que les informations se déplacent avec l'utilisateur itinérant.

Quotas pour le stockage isolé

Un quota représente une limite de la quantité de stockage isolé pouvant être utilisée. Le quota inclut des octets d'espace de fichier ainsi que la surcharge associée au répertoire et d'autres informations du magasin. Le stockage isolé utilise des quotas d'autorisation qui représentent des limites de stockage définies via des objets IsolatedStoragePermission . Lors d'une tentative d'écriture de données qui dépassent le quota, l'exception IsolatedStorageException est levée. La stratégie de sécurité, modifiable à l'aide de l'outil .NET Framework Configuration Tool (Mscorcfg.msc) détermine les autorisations accordées au code. Le code possédant une autorisation IsolatedStoragePermission ne peut pas utiliser davantage de stockage que celui autorisé par la propriété UserQuota . Toutefois, dans la mesure où le code peut ignorer des quotas d'autorisation en présentant diverses identités d'utilisateur, les quotas d'autorisation servent d'indications sur la façon dont le code doit se comporter et ne représentent pas une limite définitive du comportement du code.

Les quotas ne sont pas appliqués sur les magasins itinérants. C'est pourquoi, pour que le code les utilise, le niveau d'autorisation requis est un peu plus haut. Les valeurs d'énumération AssemblyIsolationByRoamingUser et DomainIsolationByRoamingUser spécifient une autorisation appropriée pour utiliser le stockage isolé lorsqu'il s'agit d'un utilisateur itinérant.

Accès sécurisé

Le stockage isolé permet aux applications qui ne disposent pas d'un niveau de confiance suffisant de stocker des données d'une façon contrôlée par la stratégie de sécurité de l'ordinateur. Ceci est particulièrement utile pour les composants téléchargés qu'un utilisateur doit exécuter avec précaution. La stratégie de sécurité accorde rarement ce genre d'autorisation de code lorsque vous accédez au système de fichiers en utilisant des mécanismes d'E/S standard. Toutefois, l'autorisation d'utiliser le stockage isolé est accordée par défaut au code s'exécutant à partir de l'ordinateur local, d'un réseau local ou d'Internet.

Les administrateurs peuvent limiter la quantité de stockage isolé disponible pour un utilisateur ou une application, en fonction d'un niveau de confiance approprié. En outre, les administrateurs peuvent supprimer toutes les données rendues persistantes d'un utilisateur. Pour créer le stockage isolé ou y accéder, l'autorisation IsolatedStorageFilePermission appropriée doit être accordée au code.

Pour accéder au stockage isolé, le code doit posséder tous les droits de système d'exploitation de la plateforme native. Les listes de contrôle d'accès (ACL) qui contrôlent les utilisateurs autorisés à utiliser le système de fichiers doivent être respectées. Les applications .NET possèdent déjà des droits de système d’exploitation pour accéder au stockage isolé, sauf si elles effectuent un emprunt d’identité (spécifique à la plateforme). Dans ce cas, l'application doit garantir que l'identité de l'utilisateur empruntée possède les droits de système d'exploitation appropriés pour accéder au stockage isolé. Cet accès permet au code exécuté ou téléchargé à partir du Web de lire et d'écrire facilement dans une zone de stockage liée à un utilisateur particulier.

Pour contrôler l'accès au stockage isolé, le Common Language Runtime utilise des objets IsolatedStorageFilePermission . Chaque objet possède des propriétés qui spécifient les valeurs suivantes :

  • Utilisation autorisée, qui indique le type d'accès autorisé. Les valeurs sont des membres de l'énumération IsolatedStorageContainment . Pour plus d'informations sur ces valeurs, consultez le tableau de la section suivante.

  • Quota de stockage, comme décrit dans la section précédente.

Le runtime exige l'autorisation IsolatedStorageFilePermission lors de la première tentative d'ouverture d'un magasin par le code. Il détermine s’il doit ou non accorder cette autorisation, en fonction du niveau de fiabilité du code. Si l'autorisation est accordée, l'utilisation autorisée et les valeurs de quota de stockage sont déterminées par la stratégie de sécurité et par la demande du code de l'autorisation IsolatedStorageFilePermission. La configuration de la stratégie de sécurité est définie à l'aide de l'outil .NET Framework Configuration Tool (Mscorcfg.msc). Tous les appelants de la pile des appels sont vérifiés pour garantir que chaque appelant possède au moins l'utilisation autorisée appropriée. Le runtime vérifie également le quota imposé au code qui a ouvert ou créé le magasin dans lequel le fichier doit être enregistré. Si ces conditions sont remplies, l'autorisation est accordée. Le quota est revérifié à chaque fois qu'un fichier est écrit dans le magasin.

Le code d'application n'est pas nécessaire pour demander l'autorisation, car le Common Language Runtime accorde l'autorisation IsolatedStorageFilePermission appropriée selon la stratégie de sécurité. Toutefois, il existe de bonnes raisons de demander des autorisations spécifiques nécessaires à votre application, notamment l'autorisation IsolatedStorageFilePermission.

Utilisation autorisée et risques pour la sécurité

L'utilisation autorisée spécifiée par l'autorisation IsolatedStorageFilePermission détermine le degré d'autorisation du code pour créer et utiliser le stockage isolé. Le tableau suivant illustre la correspondance entre l'utilisation autorisée spécifiée dans l'autorisation et les types d'isolation. En outre, il résume les problèmes de sécurité associés à chaque utilisation autorisée.

Utilisation autorisée Types d'isolation Impact sur la sécurité
None Aucune utilisation de stockage isolé n'est autorisée. Aucun impact sur la sécurité.
DomainIsolationByUser Isolation par utilisateur, par domaine et par assembly. Chaque assembly possède un sous-magasin distinct dans le domaine. Les magasins utilisant cette autorisation sont également implicitement isolés par l'ordinateur. Ce niveau d'autorisation laisse les ressources ouvertes à une surutilisation non autorisée, même si les quotas appliqués rendent cette surutilisation plus difficile. C'est une attaque de refus de service.
DomainIsolationByRoamingUser Identique à DomainIsolationByUser, mais le magasin est enregistré à un emplacement itinérant si les profils utilisateurs itinérants sont activés et si les quotas ne sont pas appliqués. Dans la mesure où les quotas doivent être désactivés, les ressources de stockage sont plus vulnérables à une attaque de refus de service.
AssemblyIsolationByUser Isolation par utilisateur et par assembly. Les magasins utilisant cette autorisation sont également implicitement isolés par l'ordinateur. Les quotas sont appliqués à ce niveau pour empêcher une attaque de refus de service. Un assembly identique d'un autre domaine peut accéder à ce magasin, ce qui permet la divulgation d'informations entre des applications.
AssemblyIsolationByRoamingUser Identique à AssemblyIsolationByUser, mais le magasin est enregistré à un emplacement itinérant si les profils utilisateurs itinérants sont activés et si les quotas ne sont pas appliqués. Identique à AssemblyIsolationByUser, mais le risque d'attaque par déni de service augmente sans les quotas.
AdministerIsolatedStorageByUser Isolation par utilisateur. Généralement, seuls les outils d'administration ou de débogage utilisent ce niveau d'autorisation. L'accès avec cette autorisation permet au code d'afficher ou de supprimer un fichier de stockage isolé d'un utilisateur ou des répertoires (sans tenir compte de l'isolation d'assembly). Les risques comprennent notamment une divulgation d'informations et une perte de données.
UnrestrictedIsolatedStorage Isolation par tous les utilisateurs, domaines et assemblys. Généralement, seuls les outils d'administration ou de débogage utilisent ce niveau d'autorisation. Cette autorisation permet un compromis total de tous les magasins isolés pour tous les utilisateurs.

Sécurité des composants de stockage isolés en ce qui concerne les données non approuvées

Cette section s’applique aux frameworks suivants :

  • .NET Framework (toutes les versions)
  • .NET Core 2.1+
  • .NET 5+

.NET Framework et .NET Core offrent un stockage isolé comme mécanisme de conservation des données pour un utilisateur, une application ou un composant. Il s’agit d’un composant hérité principalement conçu pour les scénarios de sécurité d’accès au code désormais déconseillés.

Un certain nombre d’API et d’outils de stockage isolés peuvent être utilisés pour lire des données au-delà des limites d’approbation. Par exemple, la lecture de données à partir d’une étendue à l’échelle de l’ordinateur peut agréger des données à partir d’autres comptes d’utilisateurs, éventuellement moins approuvés, sur l’ordinateur. Les composants ou applications qui lisent à partir d’étendues de stockage isolées à l’échelle de l’ordinateur doivent être conscients des conséquences de la lecture de ces données.

API sensibles à la sécurité qui peuvent lire à partir de l’étendue de l’ordinateur

Composants ou applications qui appellent l’une des API suivantes lues à partir de l’étendue de l’ordinateur :

L'outil de stockage isolé storeadm.exe est impacté s'il est appelé avec le commutateur /machine, comme indiqué dans le code suivant :

storeadm.exe /machine [any-other-switches]

L’outil de stockage isolé est fourni dans le cadre de Visual Studio et du SDK .NET Framework.

Si l’application n’implique pas d’appels aux API précédentes, ou si le workflow n’implique pas l’appel à storeadm.exe de cette manière, ce document ne s’applique pas.

Impact dans les environnements multi-utilisateurs

Comme mentionné précédemment, l’impact sur la sécurité de ces API résulte de la lecture des données écrites à partir d’un environnement d’approbation à partir d’un autre environnement d’approbation. Le stockage isolé utilise généralement l’un des trois emplacements suivants pour lire et écrire des données :

  1. %LOCALAPPDATA%\IsolatedStorage\ : par exemple, C:\Users\<username>\AppData\Local\IsolatedStorage\, pour l’étendue User.
  2. %APPDATA%\IsolatedStorage\ : par exemple, C:\Users\<username>\AppData\Roaming\IsolatedStorage\, pour l’étendue User|Roaming.
  3. %PROGRAMDATA%\IsolatedStorage\ : par exemple, C:\ProgramData\IsolatedStorage\, pour l’étendue Machine.

Les deux premiers emplacements sont isolés par utilisateur. Windows garantit que différents comptes d’utilisateur sur la même machine ne peuvent pas accéder aux dossiers de profil utilisateur des autres. Deux comptes d’utilisateur différents qui utilisent les magasins User ou User|Roaming ne voient pas les données des autres et ne peuvent pas interférer avec les données des autres.

Le troisième emplacement est partagé entre tous les comptes d’utilisateur sur l’ordinateur. Différents comptes peuvent lire et écrire à cet emplacement, et ils peuvent voir les données des autres.

Les chemins d’accès précédents peuvent différer en fonction de la version de Windows utilisée.

Considérez maintenant un système multi-utilisateur avec deux utilisateurs inscrits, Mallory et Bob. Mallory a la possibilité d’accéder à son répertoire C:\Users\Mallory\ de profil utilisateur, et elle peut accéder à l’emplacement de stockage partagé à l’échelle de l’ordinateur C:\ProgramData\IsolatedStorage\. Elle ne peut pas accéder au répertoire C:\Users\Bob\ du profil utilisateur de Bob.

Si Mallory souhaite attaquer Bob, elle peut écrire des données dans l’emplacement de stockage à l’échelle de l’ordinateur, puis tenter d’inciter Bob à le lire à partir du magasin à l’échelle de la machine. Quand Bob exécute une application qui lit à partir de ce magasin, cette application fonctionne sur les données que Mallory y a placées, mais à partir du contexte du compte utilisateur de Bob. Le reste de ce document traite des différents vecteurs d’attaque et des étapes que les applications peuvent effectuer pour réduire le risque de ces attaques.

Notes

Pour qu’une telle attaque ait lieu, Mallory a besoin de ce qui suit :

  • Un compte utilisateur sur l’ordinateur.
  • La possibilité de placer un fichier dans un emplacement connu sur le système de fichiers.
  • Savoir que Bob exécutera à un moment donné une application qui tente de lire ces données.

Il ne s’agit pas de vecteurs de menace qui s’appliquent aux environnements de bureau mono-utilisateur standard, comme les PC domestiques ou les stations de travail d’entreprise mono-employé.

Élévation de privilège

Une attaque par élévation de privilèges se produit lorsque l’application de Bob lit le fichier de Mallory et tente automatiquement d’effectuer une action en fonction du contenu de cette charge utile. Considérez une application qui lit le contenu d’un script de démarrage à partir du magasin à l’échelle de l’ordinateur et qui transmet ce contenu à Process.Start. Si Mallory peut placer un script malveillant à l’intérieur du magasin à l’échelle de la machine, lorsque Bob lance son application :

  • Son application analyse et lance le script malveillant de Mallory dans le contexte du profil utilisateur de Bob.
  • Mallory accède au compte de Bob sur l’ordinateur local.

Denial of service (déni de service)

Une attaque par déni de service se produit lorsque l’application de Bob lit le fichier de Mallory et se bloque ou cesse de fonctionner correctement. Considérez à nouveau l’application mentionnée précédemment, qui tente d’analyser un script de démarrage à partir du magasin à l’échelle de l’ordinateur. Si Mallory peut placer un fichier avec du contenu mal formé à l’intérieur du magasin à l’échelle de la machine, elle peut :

  • Amener l’application de Bob à lever une exception tôt dans le chemin de démarrage.
  • Empêcher le lancement de l’application en raison de l’exception.

Elle empêche donc Bob de lancer l’application sous son propre compte utilisateur.

Divulgation d’informations

Une attaque par divulgation d’informations se produit lorsque Mallory peut tromper Bob pour qu’il divulgue le contenu d’un fichier auquel Mallory n’a normalement pas accès. Considérez que Bob a un fichier secret C:\Users\Bob\secret.txt que Mallory veut lire. Elle connaît le chemin d’accès à ce fichier, mais elle ne peut pas le lire, car Windows lui interdit d’accéder au répertoire du profil utilisateur de Bob.

Au lieu de cela, Mallory place un lien physique dans le magasin à l’échelle de la machine. Il s’agit d’un type spécial de fichier qui lui-même ne contient aucun contenu, mais qui pointe vers un autre fichier sur le disque. Lors de la tentative de lecture du lien physique, le fichier lit le contenu du fichier ciblé par le lien à la place. Après avoir créé le lien physique, Mallory ne peut toujours pas lire le contenu du fichier, car elle n’a pas accès à la cible (C:\Users\Bob\secret.txt) du lien. Toutefois, Bob a accès à ce fichier.

Lorsque l’application de Bob lit à partir du magasin à l’échelle de l’ordinateur, elle lit maintenant par inadvertance le contenu de son fichier secret.txt, comme si le fichier lui-même avait été présent dans le magasin à l’échelle de l’ordinateur. Lorsque l’application de Bob se ferme, si elle tente de réenregistrer le fichier dans le magasin à l’échelle de l’ordinateur, elle place en réalité une copie réelle du fichier dans le répertoire *C:\ProgramData\IsolatedStorage*. Étant donné que ce répertoire est lisible par n’importe quel utilisateur sur l’ordinateur, Mallory peut désormais lire le contenu du fichier.

Meilleures pratiques pour se défendre contre ces attaques

Important : Si votre environnement a plusieurs utilisateurs mutuellement non approuvés, n’appelez pas l’API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine) et n’appelez pas l’outil storeadm.exe /machine /list. Les deux supposent qu’ils travaillent sur des données approuvées. Si un attaquant peut amorcer une charge utile malveillante dans le magasin à l’échelle de l’ordinateur, cette charge utile peut entraîner une attaque d’élévation de privilèges dans le contexte de l’utilisateur qui exécute ces commandes.

Si vous travaillez dans un environnement multi-utilisateur, reconsidérez l’utilisation des fonctionnalités de stockage isolé qui ciblent l’étendue Ordinateur. Si une application doit lire des données à partir d’un emplacement à l’échelle de l’ordinateur, préférez lire les données à partir d’un emplacement accessible en écriture uniquement par les comptes d’administrateur. Le répertoire %PROGRAMFILES% et la ruche de Registre HKLM sont des exemples d’emplacements accessibles en écriture pour les administrateurs seulement, et lisibles par tout le monde. Les données lues à partir de ces emplacements sont donc considérées comme fiables.

Si une application doit utiliser l’étendue Ordinateur dans un environnement multi-utilisateur, validez le contenu de tout fichier que vous lisez à partir du magasin à l’échelle de l’ordinateur. Si l’application désérialise des graphes d’objets à partir de ces fichiers, envisagez d’utiliser des sérialiseurs plus sûrs, comme XmlSerializer, au lieu de sérialiseurs dangereux comme BinaryFormatter ou NetDataContractSerializer. Soyez prudent avec les graphes d’objets profondément imbriqués ou les graphes d’objets qui effectuent l’allocation de ressources en fonction du contenu du fichier.

Emplacements de stockage isolé

Il est parfois utile de vérifier une modification apportée au stockage isolé en utilisant le système de fichiers du système d'exploitation. Vous devrez peut-être également avoir besoin de connaître l'emplacement des fichiers de stockage isolé. Cet emplacement dépend du système d'exploitation. Le tableau suivant illustre les emplacements racine du stockage isolé sur quelques systèmes d'exploitation courants. Examinez les répertoires Microsoft\IsolatedStorage sous cet emplacement racine. Vous devez modifier les paramètres de dossier pour afficher les fichiers et les dossiers cachés afin de visualiser le stockage isolé dans le système de fichiers.

Système d’exploitation Emplacement dans le système de fichiers
Windows 2000, Windows XP, Windows Server 2003 (mise à niveau de Windows NT 4.0) Magasins itinérants =

<SYSTEMROOT>\Profiles\<user>\Application Data

Magasins non itinérants =

<SYSTEMROOT>\Profiles\<user>\Local Settings\Application Data
Windows 2000 - Nouvelle installation (et mises à niveau de Windows 98 et Windows NT 3.51) Magasins itinérants =

<SYSTEMDRIVE>\Documents and Settings\<user>\Application Data

Magasins non itinérants =

<SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data
Windows XP, Windows Server 2003 - Nouvelle installation (et mises à niveau de Windows 2000 et Windows 98) Magasins itinérants =

<SYSTEMDRIVE>\Documents and Settings\<user>\Application Data

Magasins non itinérants =

<SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data
Windows 8, Windows 7, Windows Server 2008, Windows Vista Magasins itinérants =

<SYSTEMDRIVE>\Users\<user>\AppData\Roaming

Magasins non itinérants =

<SYSTEMDRIVE>\Users\<user>\AppData\Local

Création, énumération et suppression du stockage isolé

.NET fournit trois classes dans l’espace de noms System.IO.IsolatedStorage pour vous aider à exécuter des tâches qui impliquent le stockage isolé :

Les classes de stockage isolé vous permettent de créer, d'énumérer et de supprimer le stockage isolé. Les méthodes permettant d'effectuer ces tâches sont disponibles par l'intermédiaire de l'objet IsolatedStorageFile . Avec certaines opérations, vous devez disposer de l'autorisation IsolatedStorageFilePermission qui représente le droit d'administrer le stockage isolé ; vous pouvez également être amené à disposer de droits de système d'exploitation pour accéder au fichier ou au répertoire.

Pour obtenir une série d’exemples illustrant les tâches de stockage isolé courantes, consultez les rubriques « comment » sous Rubriques connexes.

Scénarios de stockage isolé

Le stockage isolé est utile dans de nombreuses situations, notamment dans ces quatre scénarios :

  • Contrôles téléchargés. Les contrôles de code managé téléchargés à partir d'Internet ne sont pas autorisés à écrire sur le disque dur via les classes E/S ordinaires, mais ils peuvent utiliser le stockage isolé pour rendre persistants les paramètres des utilisateurs et les états des applications.

  • Stockage de composant partagé. Les composants partagés entre plusieurs applications peuvent utiliser le stockage isolé pour fournir un accès contrôlé aux magasins de données.

  • Stockage serveur. Les applications serveur peuvent utiliser le stockage isolé pour fournir des magasins individuels à de nombreux utilisateurs qui effectuent des demandes à l'application. Dans la mesure où le stockage isolé est toujours isolé par l'utilisateur, le serveur doit emprunter l'identité de l'utilisateur qui effectue la demande. Dans ce cas, les données sont isolées en fonction de l'identité de l'entité de sécurité, qui est identique à l'identité utilisée par l'application pour établir une distinction entre ses utilisateurs.

  • Profil itinérant. Les applications peuvent également utiliser le stockage isolé avec des profils d'utilisateur itinérant. Ainsi, les magasins isolés d'un utilisateur peuvent être itinérants avec le profil.

N’utilisez pas le stockage isolé dans les situations suivantes :

  • Pour stocker des secrets de grande valeur, tels que des clés ou des mots de passe non chiffrés, car le stockage isolé n'est pas protégé contre le code à niveau de confiance extrêmement élevé, contre le code non managé ou contre les utilisateurs de confiance de l'ordinateur.

  • Pour stocker du code.

  • Pour enregistrer les paramètres de configuration et de déploiement, qui sont contrôlés par les administrateurs. (les préférences de l'utilisateur ne sont pas considérées comme des paramètres de configuration car les administrateurs ne les contrôlent pas).

De nombreuses applications utilisent une base de données pour stocker et isoler des données. Dans ce cas, une ou plusieurs lignes d'une base de données peuvent représenter le stockage d'un utilisateur spécifique. Vous pouvez utiliser le stockage isolé plutôt qu'une base de données lorsque le nombre d'utilisateurs est petit, lorsque la surcharge de l'utilisation d'une base de données est significative ou lorsque aucune base de données n'existe. Le stockage isolé peut également être utilisé lorsque l'application nécessite un stockage plus flexible et plus complexe que celui proposé par une ligne d'une base de données.

Intitulé Description
Types d'isolation Décrit les divers types d'isolation.
Procédure : obtenir des magasins pour le stockage isolé Donne un exemple d'utilisation de la classe IsolatedStorageFile pour obtenir un magasin isolé par utilisateur et par assembly.
Procédure : énumérer des magasins pour le stockage isolé Indique comment utiliser la méthode IsolatedStorageFile.GetEnumerator pour calculer la taille de tout le stockage isolé de l'utilisateur.
Procédure : supprimer des magasins dans le stockage isolé Indique comment utiliser la méthode IsolatedStorageFile.Remove de deux façons différentes pour supprimer des magasins isolés.
Procédure : anticiper des conditions d’espace insuffisant avec le stockage isolé Illustre comment mesurer l'espace restant dans un magasin isolé.
Procédure : créer des fichiers et des répertoires dans un stockage isolé Propose plusieurs exemples pour créer des fichiers et des répertoires dans un magasin isolé.
Procédure : rechercher des fichiers et des répertoires existants dans un stockage isolé Illustre comment lire la structure de répertoire et les fichiers dans le stockage isolé.
Procédure : lire et écrire des fichiers dans un stockage isolé Fournit un exemple d'écriture d'une chaîne dans un fichier de stockage isolé et de sa lecture ultérieure.
Procédure : supprimer des fichiers et des répertoires dans un stockage isolé Indique comment supprimer des fichiers et des répertoires d'un stockage isolé
Fichier et flux de données E/S Explique comment accéder aux flux de données et de fichiers de façon synchrone et asynchrone.

Informations de référence